Aide de Tableau Desktop et de la création Web

Les relations multi-faits (relations entre plusieurs tables de faits) vous permettent de créer des sources de données comportant plus d’une table de base. L’utilisation de plusieurs tables de base dans votre modèle de données vous permet d’effectuer une analyse multi-faits dans Tableau.

En établissant des arborescences de tables, ancrées dans une table de base, vous pouvez modéliser des structures de données couvrant différents domaines conceptuels et utiliser leurs caractéristiques communes pour les connecter. Ce type d’analyse est souvent appelé analyse multi-faits, dimensions conformes ou dimensions partagées. Dans Tableau, c’est ce que nous appelons un modèle de données avec relations multi-faits car vous utilisez des relations pour le construire. Un modèle de données avec relations multi-faits contient toujours plusieurs tables de base. Les tables de base sont les tables les plus à gauche du modèle de données. Pour des conseils qui vous aideront à déterminer les tables à utiliser comme tables de base, consultez Dans quels cas utiliser un modèle avec relations multi-faits.

Un modèle de données à plusieurs tables de base avec surlignage de l’arborescence d’une table de base.

Niveaux de relation

Les modèles de données à plusieurs tables de base offrent une grande flexibilité quant à la manière dont les éléments de données peuvent être liés (ou non) les uns aux autres.

Remarque : la relation à tout niveau n’est pertinente que dans les modèles de données comportant plusieurs tables de base. Avant les modèles de données avec relations multi-faits, tous les éléments étaient liés (au sein d’une seule source de données), ou bien aucun ne l’était (fusion à travers plusieurs sources de données).

Relation dans le modèle de données

Les tables peuvent être liées, non liées ou partagées en fonction de la structure du modèle de données. Dans une source de données, la relation entre les tables est une constante. Pour un bref aperçu : 

• Les tables liées sont dans la même arborescence.
  • Avant la version 2024.2, toutes les sources de données étaient des sources de données à table de base unique comportant une seule arborescence, et dans une source de données à table de base unique, toutes les tables sont liées.
• Les tables non liées sont dans des arborescences différentes. Les tables de base sont toujours non liées les unes aux autres. Les tables situées en aval d’une table de base exactement ne sont pas non plus liées aux tables d’autres arborescences.
• Les tables partagées ont plusieurs relations entrantes et appartiennent à plus d’une arborescence.
  • Les tables en aval d’une table avec plusieurs relations entrantes sont également considérées comme des tables partagées.

Relation pendant l’analyse

Les champs peuvent être liés, non liés, liés de manière ambiguë ou ils peuvent servir de champs d’assemblage. La relation entre un groupe de champs est déterminée feuille par feuille en fonction de la structure du modèle de données, des champs activement utilisés (c’est-à-dire sur les étagères sous forme de piles) et de la nature de ces champs (dimensions ou mesures).

Pour créer une visualisation avec des champs à partir de plusieurs tables, Tableau doit effectuer des jointures en arrière-plan pour calculer les valeurs. Le type de jointure utilisé dépend de la relation des champs. Pour un bref aperçu : 

• Quand des champs liés sont utilisés dans une visualisation, les dimensions font l’objet d’une jointure interne et les valeurs de mesures sont décomposées par les dimensions.
  • C’est un peu plus compliqué que cela : des jointures supplémentaires peuvent être nécessaires en arrière-plan pour garantir qu’aucune valeur de mesure n’est laissée de côté. Par contre, dans une visualisation qui ne comporte que des dimensions, les dimensions liées font l’objet d’une jointure interne et c’est l’idée principale à retenir ici.
  • Il s’agit du même comportement que les modèles à table de base unique.
• Quand des champs non liés sont utilisés dans une visualisation, les dimensions font l’objet d’une jointure croisée. Les mesures de valeurs sont définies au niveau de la table (c’est-à-dire qu’elles sont agrégées localement en une seule valeur pour l’ensemble de leur table) et répétées.
  • Il est également possible que les champs ne soient pas encore liés ou soient liés de manière ambiguë, ce qui signifie que, pour la combinaison de champs actifs, il existe plusieurs façons de résoudre les relations entre leurs tables. Face à un cas ambigu, Tableau traite les champs comme non liés.
• Lorsque les champs sont assemblés sur la base d’un champ partagé, les dimensions font l’objet d’une jointure externe. Les valeurs de mesures sont agrégées au niveau des dimensions selon lesquelles elles peuvent être décomposées et répétées.
  • Les dimensions d’assemblage sont similaires aux champs de liaison dans la fusion de données. Les résultats sont calculés pour chaque paire de champs liés, puis les valeurs non liées sont assemblées entre les valeurs partagées de la dimension partagée entre elles.

Tous ces concepts et définitions sont abordés en détail plus loin dans cette rubrique.

Indicateurs de relation au niveau des champs

Il existe plusieurs indices visuels qui peuvent vous aider à comprendre le degré de relation entre les champs que vous utilisez dans une analyse.

Indicateurs de relation sur une feuille de calcul

• Icône Non lié : Tableau utilise une icône Non lié pour indiquer que les éléments de la vue ne sont pas tous liés. Si vous voyez une icône Non lié sur une pile dans la vue ou dans le volet Données, vous pouvez survoler l’icône pour obtenir plus d’informations.
  • L’icône Lié indique que le champ rassemble des champs non liés.
• Noms des champs en gris clair : les noms de champs sont affichés en texte gris clair dans le volet Données lorsqu’ils ne sont liés à aucun des champs utilisés sur les étagères. Vous pouvez toujours utiliser ces champs pour l’analyse dans cette visualisation, mais, lors de l’analyse, les champs non liés sont évalués différemment des champs liés. Au survol, ces champs affichent également une icône Non lié.

Remarque : dans les versions précédentes de Tableau, les noms de champs en gris clair indiquaient que les champs étaient masqués et que l’option Afficher les champs masqués avait été sélectionnée. Les champs masqués, lorsqu’ils sont affichés, sont désormais indiqués par une icône en forme d’œil cliquable .

Boîte de dialogue d’avertissement de relation

Lorsque des champs non liés sont utilisés ensemble dans une visualisation, Tableau affiche une boîte de dialogue d’avertissement pour vous informer que les champs ne sont pas liés. Cet avertissement apparaît chaque fois que vous ajoutez un champ non lié pour éviter les jointures croisées accidentelles susceptibles d’avoir un impact sur les performances.

• Si vous souhaitez utiliser des champs non liés sans assemblage, cliquez sur Ajouter pour continuer à ajouter le champ à la visualisation.
• Si vous souhaitez assembler des champs non liés, la meilleure pratique consiste à placer le champ d’assemblage avant un champ qui est sinon non lié. La boîte de dialogue ne s’affiche pas si le champ d’assemblage est déjà utilisé. Consultez Comment les jointures sont utilisées pour chaque niveau de relation pour plus d’informations sur la façon dont l’assemblage évite les jointures croisées.

Si plusieurs champs ont été ajoutés ou sont déjà présents dans la vue, la zone Détails apparaît dans la boîte de dialogue. Développez-la pour afficher plus d’informations sur la relation entre tous les champs utilisés et identifier d’où vient le problème de non-relation.

Pour empêcher l’affichage du message d’avertissement, sélectionnez l’option Ne plus afficher ce message. Vous pouvez toujours réactiver ces messages d’avertissement de la manière suivante :

• Dans Tableau Desktop, ouvrez le menu Aide > Paramètres et performances > Réinitialiser les messages ignorés.
• Dans un navigateur, effacez les données mises en cache. Par exemple, dans Chrome, ouvrez le menu à 3 points > Supprimer les données de navigation... > Choisissez Images et fichiers mis en cache > Supprimer les données.

Relation au niveau de la table dans le modèle de données

Dans un modèle de données comportant plusieurs tables de base, chaque table de base définit un ensemble de tables liées et formant une arborescence conceptuelle. Ces arborescences doivent être connectées par une table partagée au minimum pour garantir que la source de données globale est une entité unique.

Ce qui aurait pu être auparavant deux sources de données à fusionner à l’aide de champs de liaison peut désormais constituer une source de données unique avec deux arborescences, reliées par les tables partagées contenant ces champs communs.

Conseil : le mode de liaison des tables dans le modèle de données a un impact sur la manière dont leurs champs peuvent être liés dans l’analyse. Il peut être utile de revenir à l’onglet Source de données pendant l’analyse pour voir comment une table s’intègre dans le modèle de données global.

Voyons quelles tables sont liées, non liées ou partagées à l’aide de cet exemple de source de données. Il y a deux arborescences, une établie par la table de base A et une par la table de base B.

Tables non liées

Les tables de base sont fondamentalement indépendantes. De même, les tables qui existent uniquement dans une seule arborescence ne sont pas liées aux tables des autres arborescences.

La table A et la table X ne sont pas liées	La table B et la table X ne sont pas liés

Tables liées

Les tables de la même arborescence sont considérées comme liées.

La table A et la table S sont liées	La table B et la table S sont liées (via la table A)

Tables partagées

Les tables partagées ont plusieurs relations entrantes. Ces tables appartiennent à plusieurs arborescences et sont partagées entre elles.

La table S et la table T sont partagées.

Relation au niveau du champ dans l’analyse

La relation entre les champs est déterminée feuille par feuille en fonction de la structure du modèle de données, des champs activement utilisés (c’est-à-dire des champs présents dans la visualisation sous forme de piles sur les étagères) et de la nature de ces champs (dimensions ou mesures). L’impact de la relation avec les champs sur les résultats d’une visualisation est abordé dans la section suivante.

Passons en revue quelques scénarios utilisant le même exemple de source de données. Le nom de chaque champ indique de quelle table il provient, par exemple FieldB de la table B. Les champs peuvent être des dimensions ou des mesures, sauf indication contraire.

Champs liés

À un haut niveau, les champs sont liés lorsque Tableau peut déterminer clairement comment les évaluer ensemble en fonction d’un chemin de relation au sein d’une seule arborescence.

Par exemple, FieldB (de la table B) et FieldS (de la table S) sont liés.

Champs non liés

À un haut niveau, les champs ne sont liés en aucun cas lorsqu’ils ne sont pas liés. Cela peut s’expliquer par le fait que les champs proviennent de tables non liées, par exemple utilisant des champs provenant de deux tables de base. Dans ce cas, les champs des différentes tables de base ne sont fondamentalement pas liés.

Par exemple, FieldA et FieldX ne sont pas liés.

Les champs peuvent également être traités comme non liés pendant un moment donné, par exemple dans les cas de relations ambiguës ou de relation non encore établie. Pour la plupart, vous pouvez compter sur les indicateurs de relation pour vous alerter lorsque les champs ne sont pas liés dans le contexte d’une visualisation.

Dimension d’assemblage

L’assemblage est la manière dont Tableau évalue les champs de tables non liées dans un modèle de données multi-faits lors de l’analyse. Dans une visualisation, l’utilisation d’une dimension d’une table partagée assemble des champs qui sont sinon non liés et leur permet d’être évalués simultanément dans la même visualisation. Considérez cela comme une juxtaposition des résultats de deux arborescences en fonction d’une dimension qu’elles partagent.

Par exemple, si une visualisation est créée avec FieldA et FieldX, ces deux champs ne sont pas liés. L’ajout de DimensionS introduit un champ d’assemblage.

• FieldA et DimensionS sont évalués ensemble.
• FieldX et DimensionS sont évalués ensemble.
• Ces résultats intermédiaires sont rassemblés en fonction des valeurs de DimensionS.
• FieldA et FieldX sont maintenant assemblés.

Conseil : les meilleures pratiques consistent à utiliser un champ d’assemblage dans la visualisation avant de faire apparaître un champ non lié. Par exemple, faites glisser d’abord DimensionS, ou FieldA puis DimensionS puis FieldX, au lieu de FieldA puis FieldX puis DimensionS. Si vous ajoutez le champ d’assemblage en premier, Tableau saura ainsi toujours comment évaluer les relations et évitera les problèmes de performances potentiels liés à l’évaluation conjointe de dimensions non liées avec des jointures croisées.

L’assemblage exige qu’une dimension d’une table partagée soit active dans la visualisation. Les champs placés sur l’étagère Filtres ou sur la propriété Infobulle de la fiche Repères ne sont pas considérés comme actifs à des fins d’assemblage.

Champs non encore liés

Les champs ont également plusieurs manières d’être liés, mais sans l’être encore. Cela se produit lorsqu’il existe plusieurs relations possibles entre deux tables partagées (ou tables partagées en aval).

Considérez FieldS et FieldT. Leurs tables sont liées les unes aux autres à la fois par l’arborescence définie par la table de base A et par l’arborescence définie par la table de base X.

Dans une visualisation contenant uniquement FieldS et FieldT, il n’y a pas d’information quant à l’arborescence à utiliser pour les relier. Sans informations supplémentaires, Tableau ne peut pas évaluer s’il convient de relier ces champs via l’arborescence de la table de base A ou l’arborescence de la table de base B.

FieldS et FieldT sont traités comme non liés bien qu’il existe plusieurs relations potentielles.

Ces champs pouvant potentiellement être liés, mais non encore liés, sont évalués comme non liés, car Tableau ne peut pas déterminer clairement leur chemin de relation. À la différence des champs véritablement non liés qui peuvent uniquement être assemblés, les champs non encore liés peuvent être résolus, et être directement liés.

Domaines liés de manière ambiguë

Les champs peuvent également être liés de manière ambiguë. Cela se produit lorsqu’il existe plusieurs relations actives possibles entre des tables partagées (ou des tables partagées en aval). À la différence des champs non encore liés, qui peuvent être considérés comme hypo-liés ou sous-liés, les champs liés de manière ambiguë sont hyper-liés ou sur-liés.

Considérez FieldS et FieldT. Leurs tables sont liées les unes aux autres à la fois par l’arborescence définie par la table de base A et par l’arborescence définie par la table de base X.

Dans une visualisation contenant les champs FieldA, FieldX, FieldS et FieldT, il y a trop d’informations pour déterminer l’arborescence à utiliser pour les relier. À moins de réduire les informations, Tableau ne peut pas évaluer s’il convient de relier ces champs via l’arborescence de la table de base A ou celle de la table de base B.

FieldS et FieldT sont traités comme non liés bien qu’il existe plusieurs relations actives.

Les champs liés de manière ambiguë sont évalués comme des champs non liés, car Tableau ne peut pas déterminer clairement leur chemin de relation. À la différence des champs véritablement non liés qui peuvent uniquement être assemblés, les champs liés de manière ambiguë peuvent être résolus, et être directement liés.

Mesure à partir d’une table partagée

Lorsqu’une dimension est utilisée à partir d’une table partagée, elle rassemble les champs de ses tables en amont non liées. Cependant, la mesure ne peut pas servir de champ d’assemblage, et la valeur d’une mesure dépend de ses dimensions liées.

Dans une visualisation avec DimensionA et DimensionX, ces deux dimensions ne sont pas liées. Si la mesure MeasureS est extraite de Table S, elle n’est pas liée à la combinaison de DimensionA et DimensionX ensemble. Bien qu’elle puisse être liée à l’un ou l’autre indépendamment, elle ne peut pas être liée simultanément aux deux dans la même visualisation.

Une mesure partagée peut être considérée comme un type d’ambiguïté ou de sur-relation et est résolue de la même manière.

Résoudre les relations confuses entre les champs

Chaque fois qu’il y a une incertitude sur la manière de relier les champs, Tableau ne prend pas de décision arbitraire et les traite plutôt comme non liés. Il est souvent préférable de relier ces champs en clarifiant l’incertitude autour de l’arborescence à utiliser.

Vous pouvez résoudre des champs non encore liés en ajoutant un champ pour déterminer l’arborescence à utiliser. Vous pouvez résoudre des champs liés de manière ambiguë en supprimant des champs pour déterminer l’arborescence à utiliser.

Exemple :

Résolution de champs non encore liés : ajouter un champ

• Dans une visualisation de FieldS et FieldT, l’ajout d’un champ de la Table A, B ou C à la visualisation rend l’arborescence de la Table de base A active et résout l’ambiguïté entre FieldS et FieldT.
• Sinon, l’utilisation d’un champ de la Table X résout le chemin souhaité entre FieldS et FieldT via l’arborescence de la Table de base X.

Résolution de champs liés de manière ambiguë : supprimer un ou plusieurs champs

• Dans une visualisation de FieldA, FieldX, FieldS et FieldT, la suppression de FieldX rend uniquement l’arborescence de la Table de base A active et résout le chemin souhaité entre FieldS et FieldT.
• Sinon, l’utilisation de FieldA résout le chemin souhaité entre FieldS et FieldT via l’arborescence de la Table de base X.

Résolution d’une mesure partagée : supprimer un ou plusieurs champs

• Dans une visualisation de DimensionA, DimensionX et MeasureS, la suppression de DimensionX active uniquement l’arborescence de la Table de base A et résout le chemin souhaité entre DimensionA et MeasureS.
• Sinon, la suppression de DimensionA résout le chemin souhaité entre DimensionX et MeasureS via l’arborescence de la Table de base X.

Non encore lié	Lié de manière ambiguë	Relation résolue sur une seule arborescence
		Lié via la table de base A	Lié via la table de base X

La résolution d’une incertitude est similaire à l’utilisation d’une expression de niveau de détail (LOD) FIXED. Dans une expression LOD FIXED, vous indiquez à Tableau le niveau de détail auquel agréger en définissant la déclaration de dimension. L’incertitude est résolue en modifiant la structure de la visualisation de manière à rendre une seule arborescence active, indiquant ainsi à Tableau les chemins de relation qu’il peut prendre en compte pour effectuer l’analyse.

Assemblage vs. résolution de l’incertitude

L’assemblage et la résolution de l’incertitude sont des moyens de gérer l’absence de relation. Elles ont des résultats différents :

Assemblage	Résolution de l’incertitude
FieldA et FieldX non liés assemblés par DimensionS	FieldS et FieldT évalués via l’arborescence définie par la table de base A
Juxtapose de champs non liés en fonction d’attributs partagés	Réduit le chemin de relation à utiliser en cas d’options multiples (ambiguïté ou mesure partagée), ou établit un chemin de relation là où il n’y en avait pas (non encore lié).
Utilise une logique de tables de base multiples pour calculer les résultats	Utilise une logique de table de base unique pour calculer les résultats
L’analyse implique des tables non liées	L’analyse implique des tables partagées

Comment les jointures sont utilisées pour chaque niveau de relation

Une fois que la relation au niveau du champ est déterminée, Tableau doit évaluer les résultats pour créer la visualisation réelle. Les requêtes utilisées pour calculer les valeurs affichées dans une visualisation reposent sur des jointures. Le fait que les champs soient liés, non liés ou assemblés a un impact différent sur les jointures effectuées. N’oubliez pas que les champs liés de manière ambiguë et non encore liés sont traités comme non liés dans ce contexte.

Pour expliquer les relations et les jointures, cette section couvre les tables et leurs champs, ainsi que les valeurs de ces champs. Considérez le modèle de données suivant avec deux tables de base, Classes et Clubs, et une table partagée, Students.

Classes	Clubs	Students
Champs : Class, une dimension avec les valeurs Nesting Basics, Advanced Songs, Flying for Fledglings et Alarm Calls 101 Length, une mesure Student, une dimension utilisée pour établir une relation avec la table Student	Champs : Club, une dimension avec les valeurs Photography, Travel, Juggling, Art et First Aid Dues, une mesure Student, une dimension utilisée pour établir une relation avec la table Student	Champs : Bus Rider, une dimension avec des valeurs Oui ou Non Student, une dimension avec les valeurs Finch, Cardinal, Sparrow, Robin et Jay. Utilisé pour établir la relation aux deux autres tables Age, une mesure

Ce modèle très simple illustre comment la logique de jointure de haut niveau est calculée pour les modèles de données de relations multi-faits. Pour plus d’informations sur les bases des jointures utilisées dans les modèles de données de table de base unique basés sur des relations, consultez Fonctionnement de l’analyse pour les sources de données multi-tables qui utilisent des relations.

Les dimensions liées utilisent des jointures internes

Les dimensions liées font l’objet d’une jointure interne. Les jointures internes laissent de côté toutes les valeurs de dimensions qui ne sont pas partagées entre les deux tables.

• Tableau utilise une logique supplémentaire pour garantir que les valeurs de mesures ne sont pas perdues. Cette section utilise uniquement des dimensions pour démontrer comment Tableau applique les jointures internes aux dimensions liées.

L’exemple suivant montre comment les dimensions liées renvoient uniquement les lignes présentes dans les données. Aucun étudiant n’est dans le cours Alarm Calls 101. Elle n’est donc pas présente dans les résultats. Cardinal et Jay ne sont dans aucun cours. Ils ne sont donc pas présents dans les résultats.

Les dimensions non liées utilisent des jointures croisées

Les dimensions non liées (elles-mêmes, sans dimension de couture) sont jointes entre elles.

Dans une jointure croisée, chaque valeur d’une dimension est combinée avec chaque valeur de l’autre dimension, même si la combinaison résultante n’existe pas réellement dans les données. Dans cet exemple, la jointure croisée ajoute une ligne pour chaque combinaison possible de Class et de Club.

Il est important de reconnaître à quel moment une jointure croisée se produit dans votre analyse. Bien qu’il y ait une ligne pour Advanced Songs + First Aid dans le tableau des résultats pour la jointure croisée, aucun étudiant ne participe réellement à cette combinaison d’activités (nous en verrons la preuve dans l’exemple d’assemblage de la section suivante).

Pourquoi est-il important de reconnaître que les résultats de jointure croisée ne sont pas tous basés sur les données ? Imaginez que vous essayiez d’établir un emploi du temps pour les cours et les clubs afin qu’il n’y ait aucun conflit pour les étudiants. Il n’y a aucun étudiant en Advanced Songs et First Aid, vous pouvez donc ignorer ce résultat et programmer ce cours et ce club simultanément. La jointure croisée ne représente pas les combinaisons de valeurs qui existent réellement dans les données.

De plus, les jointures croisées peuvent avoir un impact sur les performances en cas de cardinalité élevée (un grand nombre de valeurs uniques). Imaginez effectuer une jointure croisée entre chaque numéro de téléphone et chaque adresse e-mail de vos contacts. Cela représenterait une explosion de combinaisons et une opération potentiellement coûteuse.

Les dimensions assemblées utilisent des jointures externes

Les dimensions non liées (en présence d’une dimension d’assemblage) font l’objet d’une jointure externe.

Dans cet exemple, la table Classes et la table Clubs sont liées à la table Students partagée mais ne sont pas liées entre elles, donc les champs Class et Club ne sont pas liés. L’ajout de la dimension Student permet à Tableau de savoir quelles valeurs de Class et de Club doivent être juxtaposées dans l’analyse. Nous appelons ce comportement de jointure externe un assemblage.

L’assemblage est similaire à la fusion des données dans la mesure où des résultats intermédiaires sont regroupés en vue des résultats globaux. Par contre, contrairement à la fusion, l’assemblage est une jointure externe, et non une jointure gauche, et n’ignore pas des valeurs d’un côté ou de l’autre. Il n’y a pas de concept de sources de données primaires ou secondaires lorsqu’il s’agit d’une seule source de données, si bien que les deux champs non liés ont la même priorité.

Les résultats intermédiaires font l’objet d’une jointure externe

Qu’est-ce qui entre dans la jointure externe pour les champs assemblés ? Une jointure interne immédiate est calculée tour à tour pour chacun des champs non liés et pour le champ d’assemblage, puis ces résultats intermédiaires font l’objet d’une jointure externe en fonction des valeurs de la dimension d’assemblage.

Exemple

Une jointure interne pour Student et Class...

...et une jointure interne pour Student et Club...

...font ensuite l’objet d’une jointure externe sur Student.

Jointures supplémentaires pour conserver les mesures

Outre la logique de jointure pour les dimensions, les mesures peuvent introduire des jointures supplémentaires. Lorsque les relations ont été introduites pour la première fois dans Tableau, l’un des principes de base était que les valeurs de mesures ne sont pas perdues. Cela vaut également dans les modèles de données de relations multi-faits.

Les détails essentiels sont :

• Les valeurs des mesures sont ventilées uniquement par dimensions liées.
• Les valeurs de mesures se répètent pour les dimensions non liées.
• Les valeurs de dimensions qui seraient supprimées dans des visualisations comportant uniquement des dimensions peuvent être renvoyées si des valeurs de mesures pertinentes leur sont associées.

Remarque : n’oubliez pas que les mesures sont des agrégations. Elles sont calculées au niveau de détail (granularité) défini par la combinaison de dimensions dans la visualisation. C’est ce qu’on appelle une mesure décomposée par une dimension. Lorsqu’une mesure est utilisée sans aucune dimension, on dit qu’elle est au niveau de la table. Cela signifie que la valeur de la mesure est la valeur entièrement agrégée. Dès que nous utilisons une dimension dans la visualisation, la mesure est décomposée de manière plus granulaire en fonction des valeurs de dimensions. La valeur d’une mesure dans une analyse dépend donc du contexte des dimensions.

Mesures liées

Considérez le sous-ensemble de valeurs de dimensions renvoyées pour une jointure interne sur les dimensions liées Student et Class. Il existe trois valeurs d’étudiants, Finch, Robin et Sparrow, et trois valeurs de cours, Advanced Songs, Nesting Basics et Flying for Fledgelings.

Si on ajoute la mesure Length à partir de la table Class, nous voyons que les quatre cours sont affichés et qu’il y a une valeur null pour Student. La mesure Length de chaque cours s’affiche, au niveau de Class.

Si on ajoute plutôt la mesure Age à partir de la table Student, nous voyons que les cinq étudiants sont affichés et qu’il y a deux valeurs null pour Class. Les résultats conservent chaque étudiant, même s’il n’est pas dans un cours. La valeur Age de chaque étudiant s’affiche, au niveau de Student.

Mesures non liées

Les valeurs de mesures sont répétées pour les valeurs de dimensions non liées.

Si nous examinons la mesure Length de la table Classes et les valeurs non liées de la dimension Club, la mesure est au niveau de la table et répétée sur toutes les valeurs de dimensions de Club.

En présence d’une dimension d’assemblage, les mesures peuvent être à la fois décomposées et répétées.

Ici, la mesure Age provient de la table Students et est décomposée par niveau d’étudiant. Chaque fois qu’un étudiant est répété en fonction des dimensions de Class et Club, la valeur Age est répétée.

Résolution des problèmes

Considérations relatives à l’utilisation de modèles de données avec relations multi-faits

Filtres d’extrait par table

Tous les filtres d’extrait pour un extrait de modèle de données avec relations multi-faits sont des filtres par table (non omniprésents). Par conséquent, les résultats du filtrage peuvent être différents entre la connexion en direct et la connexion à un extrait.

Calculs au niveau des lignes

Les calculs au niveau des lignes ne peuvent faire référence qu’à des champs partageant la même table de base en amont. Autrement dit, les calculs au niveau des lignes ne peuvent pas être effectués sur plusieurs arborescences.

Champs combinés

Tous les champs d’un champ combiné doivent partager une table en amont. Autrement dit, vous ne pouvez pas créer un champ combiné en utilisant des champs situés dans des arborescences différentes.

Ensembles

Les ensembles ne peuvent être créés qu’avec une définition impliquant des champs qui partagent la même table de base en amont. Cependant, dans une visualisation, l’option Ajouter à l’ensemble peut être disponible à partir d’un repère lorsque ce dernier est défini par des champs non liés aux champs utilisés pour définir l’ensemble. Si vous choisissez Ajouter à l’ensemble, Tableau ajoutera uniquement les champs liés à la définition de l’ensemble. Ceci est différent du comportement de l’option Ajouter à l’ensemble dans les sources de données à table de base unique, lorsque l’option ajoute tout ce qui définit le repère.

Valider les expressions de niveau de détail INCLUDE

Les expressions LOD INCLUDE ne peuvent pas être évaluées sur des champs non liés. Étant donné que la relation entre les champs est évaluée feuille par feuille, il est possible qu’une expression LOD valide dans le volet Données ou dans l’éditeur de calcul devienne invalide dans le contexte d’une visualisation spécifique (en présence d’une dimension non liée). Lorsque cela se produit, la pile LOD devient rouge. Vous pouvez mettre à jour l’expression LOD pour supprimer les conflits de champs non liés, modifier la structure de la visualisation ou supprimer l’expression LOD de la visualisation.

Mise à jour des sources de données publiées

Il est recommandé de créer une copie d’une source de données publiée existante si vous comptez la modifier pour en faire un modèle de données avec relations multi-faits dans le cas où ses classeurs connectés n’ont pas tous besoin du nouveau modèle de données. Ne mettez pas à jour la version existante de la source de données à moins que tous ses classeurs n’aient besoin des nouvelles tables. Publiez la source de données modifiée en tant que nouvelle source de données et créez de nouveaux classeurs à partir de celle-ci. Cela empêchera les classeurs existants d’être convertis pour utiliser VDS au lieu du serveur de données lorsqu’ils n’ont pas besoin de la fonctionnalité, évitant ainsi le risque d’une baisse des performances.

Problèmes résolus

Problèmes connus de la version 2024.2

Indicateurs de relation avec plusieurs fiches Repères

Lorsqu’une visualisation est créée avec plusieurs mesures sur l’étagère Lignes ou sur l’étagère Colonnes, chaque mesure obtient sa propre fiche Repères. La logique utilisée pour déterminer les indicateurs de relation (l’icône Non lié, le texte dans les infobulles et la boîte de dialogue d’avertissement de relation) peut ne pas donner les résultats attendus en fonction de la fiche Repères ouverte. La visualisation elle-même, cependant, est correctement calculée en fonction de la relation entre chaque paire de champs. Il existe un correctif prévu pour ce comportement.

BatchQueryProcessor

BatchQueryProcessor doit être activé pour prendre en charge les modèles de données avec relations multi-faits. Il s’agit d’un comportement attendu pour lequel aucun correctif n’est actuellement prévu.

Tableau Pulse

Pulse peut ne pas fonctionner avec les modèles de données avec relations multi-faits. Il se peut que vous ne soyez pas en mesure de créer une définition de métrique ou que les métriques créées soient vides. Il ne s’agit pas d’un comportement attendu, mais aucun correctif n’est encore prévu.

Autres articles de cette section