À propos des modèles de données avec relations multi-faits
Les relations multi-faits vous permettent de créer des sources de données avec plusieurs tables de base. L’utilisation de plusieurs tables de base dans votre modèle de données vous permet d’effectuer une analyse multi-facteurs dans Tableau.
En créant des arborescences de tables ancrées dans une table de base, vous pouvez modéliser des structures de données avec différents domaines conceptuels et les connecter à l’aide de leurs caractéristiques partagées. Ce type d’analyse est souvent désigné sous le terme d’analyse multi-facteurs, de dimensions conformes ou de dimensions partagées. Dans Tableau, c’est ce que nous appelons un modèle de données avec relations multi-faits, parce que vous utilisez des relations pour créer ce modèle de données. 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 Quand utiliser un modèle de relations multi-faits.
Niveaux de relation
Les modèles de données avec des tables de base multiples permettent de déterminer la relation (ou l’absence de relation) entre les éléments de données avec beaucoup plus de souplesse.
Remarque : Le niveau de relation n’est pertinent que dans les modèles de données avec des tables de base multiples. Avant les modèles de données avec relations multi-faits, tous les éléments étaient liés (dans 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 sont connexes, non connexes 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. Voici une brève présentation :
- Les tables connexes 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 connexes.
- Les tables non connexes sont dans des arborescences différentes. Les tables de base sont toujours non associées les unes aux autres. Les tables situées en aval d’une table de base exactement ne sont pas non plus associées aux tables d’autres arborescences
- Les tables partagées ont plusieurs relations entrantes et appartiennent à plusieurs arborescences.
- 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 associés, non associés, pas encore associés, associés de manière ambiguë ou ils peuvent agir comme des 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. Voici une brève présentation :
- Quand des champs associés sont utilisés dans une visualisation, les dimensions font l’objet d’une jointure interne et les valeurs de mesure 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 connexes 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 associés sont utilisés dans une visualisation, les dimensions font l’objet d’une jointure croisée. Les valeurs de mesures 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 des champs ne soient pas encore associés ou qu’ils le soient de manière ambiguë, ce qui signifie que pour la combinaison de champs actifs, il y a différentes façons de résoudre les relations entre leurs tables. Face à un cas ambigu, Tableau traite les champs comme non associé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 des données. Les résultats sont calculés pour chaque paire de champs associés, puis les valeurs non associé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.
Dans Tableau, les mesures sont des agrégations : elles sont agrégées jusqu’à la granularité définie par les dimensions de la vue. La valeur d’une mesure dépend donc du contexte des dimensions. Par exemple, le « nombre de boîtes de céréales » varie selon qu’il s’agit du stock total ou du nombre de boîtes par marque.
Les dimensions sont généralement des champs de catégorie, tels que le pays ou la marque. Dans Tableau, les dimensions définissent la granularité ou la niveau de détail de la vue. Nous souhaitons généralement regrouper nos données en repères selon une combinaison de catégories. Les dimensions que nous utilisons pour créer la vue déterminent le nombre de repères que nous avons.
Lorsqu’une mesure est utilisée sans aucune dimension, on dit qu’elle est limitée à une table. Cela signifie que sa valeur est la valeur entièrement agrégée pour toute la table. Dès qu’on utilise une dimension telle qu’une marque dans la visualisation, la mesure est ventilée avec précision. Le nombre total de boîtes de céréales est désormais établi par marque.
L’agrégation fait référence à la manière dont les données sont combinées. Dans Tableau, l’agrégation par défaut est SOMME. Vous pouvez remplacer l’agrégation par d’autres options, notamment : moyenne, médiane, total distinct, minimum, etc. La granularité fait référence au degré de détail ou de décomposition de la mesure, qui est contrôlé par les dimensions. Dès lors que la granularité de la mesure n’est pas définie au niveau des lignes (c’est-à-dire désagrégée), sa valeur doit être agrégée.
Exemple
Quelle est la valeur du « nombre de boîtes de céréales »?
Eh bien, cela dépend du type d’agrégation et de la granularité définie par les dimensions.
- Agrégations :
- somme (ou total)
- moyenne
- Granularité :
- limitée à une table / entièrement agrégée (les barres bleues dans l’exemple)
- Ventilée selon la dimension de la marque (les barres colorées dans l’exemple)
Indicateurs de relation au niveau des champs
Plusieurs indices visuels 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 associé : Tableau utilise une icône Non associé pour indiquer que les éléments de la vue ne sont pas tous liés. Si vous voyez une icône Non associé 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 Associé indique que le champ assemble des champs non associés.
- Noms des champs en gris clair : les noms de champs s’affichent en 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 associés sont évalués différemment des champs associés. Au passage de la souris, ces champs affichent également une icône Non associé.
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 associé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 associés. Ce message apparaît à chaque fois que vous ajoutez un champ non associé afin d’éviter les jointures croisées accidentelles qui pourraient affecter les performances.
- Si vous souhaitez utiliser des champs non associés sans assemblage, cliquez sur Ajouter pour continuer à ajouter le champ à la visualisation.
- Si vous souhaitez assembler des champs non associés, il est conseillé de faire d’abord apparaître le champ d’assemblage avant le champ non associé. La boîte de dialogue ne s’affiche pas si le champ d’assemblage est déjà utilisé. Pour plus d’informations sur l’utilisation de l’assemblage pour éviter les jointures croisées, consultez Comment les jointures sont utilisées pour chaque niveau de relation.
Lorsque plusieurs champs sont ajoutés ou sont déjà présents dans la vue, la zone Détails apparaît dans la boîte de dialogue. Agrandissez la boîte de dialogue pour en savoir davantage sur la relation entre tous les champs utilisés et identifier l’origine du problème de non-relation.
Pour que le message d’avertissement n’apparaisse plus du tout, sélectionnez l’option Ne plus afficher cette boîte de dialogue. Vous pouvez toujours faire réapparaître ces messages d’avertissement en les réactivant comme suit :
- Dans Tableau Desktop, ouvrez le menu Aide > Paramètres et performances > Réinitialiser les messages ignorés.
- Dans un navigateur, effacez vos données mises en cache. Par exemple, dans Chrome, ouvrez le Menu à 3 points > Supprimer les données de navigation... > sélectionnez « 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 avec plusieurs tables de base, chaque table de base définit un ensemble de tables connexes 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 associé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 connexes, non connexes ou partagées à l’aide de cet exemple de source de données. Il existe deux arborescences, l’une créée par la table de base A et l’autre par la table de base B.
Tables non connexes
Les tables de base sont fondamentalement indépendantes. De même, les tables qui existent uniquement dans une seule arborescence ne sont pas associées aux tables des autres arborescences.
La table A et la table X ne sont pas connexes | La table B et la table X ne sont pas connexes |
Tables connexes
Les tables de la même arborescence sont considérées comme étant connexes.
La table A et la table S sont connexes | La table B et la table S sont connexes (par l’intermédiaire de 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 des champs 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 les 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 Champ B de la Table B. Les champs peuvent être des dimensions ou des mesures, sauf indication contraire.
Champs associés
À un haut niveau, les champs sont associé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, Champ B (de la Table B) et Champ S (de la Table S) sont associés.
Champs non associés
À un haut niveau, les champs ne sont associés en aucun cas lorsqu’ils ne sont pas associés. Cela peut s’expliquer par le fait que les champs proviennent de tables non associé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 associés.
Par exemple, Champ A et Champ X ne sont pas associés.
Les champs peuvent également être traités comme étant non associés pendant un moment donné, comme dans les cas de relation ambiguë ou pas encore établie. Pour la plupart, vous pouvez compter sur les indicateurs de relation pour vous alerter lorsque les champs ne sont pas associés dans le contexte d’une visualisation.
Dimension d’assemblage
L’assemblage est la manière dont Tableau évalue les champs de tables non associés 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 non associé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 Champ A et Champ X, ces deux champs ne sont pas associés. L’ajout de Dimension S introduit un champ d’assemblage.
- Champ A et Dimension S sont évalués ensemble.
- Champ X et Dimension S sont évalués ensemble.
- Ces résultats intermédiaires sont rassemblés en fonction des valeurs de Dimension S.
- Champ A et Champ X 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 associé. Par exemple, faites glisser d’abord Dimension S ou Champ A, puis Dimension S puis Champ X, au lieu de Champ A, puis Champ X puis Dimension S. 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 associées et de 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 pas encore associés
Les champs peuvent également être associés de plusieurs façons, mais ne le sont pas encore. Cela se produit lorsqu’il existe plusieurs relations possibles entre deux tables partagées (ou les tables partagées en aval).
Considérez Champ S et Champ T. Leurs tables sont associé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 Champ S et Champ T, il n’existe aucune information pour déterminer quelle arborescence utiliser pour les associer. 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.
Champ S et Champ T sont traités comme des champs non associés même s’il existe plusieurs relations potentielles.
Les champs pouvant être associés mais qui ne le sont pas encore sont considérés comme des champs non associés, car Tableau ne peut pas déterminer clairement leur chemin de relation. À la différence des champs véritablement non associés et qui ne peuvent qu’être assemblés, les champs pas encore associés peuvent être résolus et les champs peuvent être directement associés.
Champs associés de manière ambiguë
Les champs peuvent également être associés de manière ambiguë. Cela se produit lorsque plusieurs relations actives sont possibles entre des tables partagées (ou des tables partagées en aval). À la différence des champs non encore associés, qui peuvent être qualifiés d’hypo-associés ou de sous-associés, les champs associés de manière ambiguë sont hyper-associés ou trop associés.
Considérez Champ S et Champ T. Leurs tables sont associé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 Champ A, Champ X, Champ S et Champ T, il existe beaucoup trop d’informations pour déterminer quelle arborescence utiliser pour les associer. Si on ne réduit pas ces informations, Tableau ne peut pas déterminer s’il faut associer ces champs via l’arborescence de la table de base A ou l’arborescence de la table de base B.
Champ S et Champ T sont traités comme des champs non associés même lorsqu’il existe plusieurs relations actives.
Les champs associés de manière ambiguë sont considérés comme des champs non associés, car Tableau ne peut pas déterminer clairement leur chemin de relation. À la différence des champs non véritablement associés et qui ne peuvent qu’être assemblés, les champs associés de manière ambiguë peuvent être résolus et les champs peuvent être directement associés.
Mesure provenant d’une table partagée
Lorsqu’une dimension est utilisée à partir d’une table partagée, elle rassemble les champs de ses tables non associées en amont. Cependant, une mesure ne peut pas être assemblée, et la valeur d’une mesure dépend de ses dimensions associées.
Dans une visualisation contenant Dimension A et Dimension X, ces deux dimensions ne sont pas associées. Si Mesure S est extrait de Table S, il n’y a pas de relation quand on fusionne Dimension A et Dimension X. Même si les deux mesures n’ont pas de relation directe, elles peuvent être associées simultanément dans la même visualisation.
Une mesure partagée peut être vue comme une forme d’ambiguïté ou de surrelation et la résolution s’effectue de la même façon.
Résoudre les relations ambiguës entre les champs
Lorsque Tableau rencontre des incertitudes sur la manière d’associer les champs, il ne fait pas d’associations arbitraire et les considère plutôt comme des champs non associés. Souvent, il vaut mieux associer ces champs en clarifiant l’incertitude autour de l’arborescence à utiliser.
Pour résoudre les champs qui ne sont pas encore associés, il suffit d’ajouter un champ pour déterminer quelle arborescence utiliser. Pour résoudre les champs associés de manière ambiguë, il suffit de supprimer des champs pour déterminer quelle arborescence utiliser.
Exemple :
Résoudre les cas pas encore associés : ajouter un champ
- Dans une visualisation qui contient Champ S et Champ T, lorsque vous ajoutez un champ de la table A, B ou C à la visualisation, cela active l’arborescence de la table de base A et résout le chemin souhaité entre Champ S et Champ T.
- Une autre solution consiste à utiliser un champ de Table X pour résoudre le chemin souhaité entre Champ S et Champ T dans l’arborescence de la table de base X.
Résoudre une relation ambiguë : supprimer un ou plusieurs champs
- Dans une visualisation contenant Champ A, Champ X, Champ S et Champ T, la suppression de Champ X active uniquement l’arborescence de la table de base A et résout le chemin souhaité entre Champ S et Champ T.
- Alternativement, la suppression de Champ A résout le chemin souhaité entre Champ S et Champ T via l’arborescence de la table de base X.
Résoudre une mesure partagée : supprimer un ou plusieurs champs
- Dans une visualisation contenant Dimension A, Dimension X et Mesure S, la suppression de Dimension X active uniquement l’arborescence de la table de base A et résout le chemin souhaité entre Dimension A et Mesure S.
- Alternativement, la suppression de Dimension A résout le chemin souhaité entre Dimension X et Mesure S via l’arborescence de la table de base X.
Pas encore associé | Associé de manière ambiguë | Relation résolue sur une seule arborescence | |
Associé via la table de base A | Associé 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.
Assembler ou résoudre l’incertitude
L’assemblage et la résolution de l’incertitude sont des moyens de gérer l’absence de relation. Ils ont des résultats différents :
Assemblage | Résolution de l’incertitude |
Juxtapose des champs non associé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 lorsqu’il n’en existait pas (pas 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 associé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 le calcul des valeurs affichées dans une visualisation reposent sur des jointures. Le fait que les champs soient associés, non associés ou assemblés a un impact différent sur les jointures effectuées. N’oubliez pas que les champs associés de manière ambiguë ou pas encore associés sont traités comme non associé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 :
| Champs :
| Champs :
|
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 avec relations multi-faits. Pour plus d’informations sur les bases des jointures utilisées dans les modèles de données à table de base unique basés sur les relations, consultez Fonctionnement de l’analyse pour les sources de données multi-tables qui utilisent des relations.
Pour ce modèle de données avec trois tables, on pourrait être tenté de le configurer comme un modèle avec une table de base unique, comme Classes-Students-Clubs ou Clubs-Students-Classes, ou avec Students comme table de base. En général, les modèles de données avec relations multi-faits sont conçus pour des types spécifiques de schémas de données ou de scénarios d’analyse. Si votre modèle de données présente les caractéristiques les mieux adaptées à un modèle de données avec relations multi-faits, configurez-le de cette manière pour que vos tables de base restent théoriquement non associées. Toutefois, si vos données ne nécessitent pas ce type de structure, il serait plus simple d’utiliser un modèle à table de base unique.
Dans ce cas particulier, ces tables ne contiennent aucun élément, dans les données ou dans le modèle, qui nécessite vraiment des tables de base multiples. Nous utilisons ce modèle comme exemple pour rester simple et nous concentrer sur la logique de jointure. On peut aussi imaginer qu’il existe une autre table connexe, Rooms, que nous ignorons simplement pour ne pas compliquer inutilement la discussion.
Toutefois, il est recommandé d’utiliser un modèle de relation multi-faits uniquement lorsque vos données l’exigent.
Les dimensions associées utilisent des jointures internes
Les dimensions associé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 associées.
L’exemple suivant montre comment les dimensions associées renvoient uniquement les lignes présentes dans les données. Aucun étudiant n’est dans le cours Alarm Calls 101. Il n’est donc pas présent 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 associées utilisent des jointures croisées
Les dimensions non associées (seules, sans aucune dimension assemblée) font l’objet d’une jointure croisée.
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 qui en résulte 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 la table 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, lorsqu’il existe une cardinalité élevée (un grand nombre de valeurs uniques), les jointures croisées peuvent affecter les performances. Imaginez que vous puissiez effectuer une jointure croisée entre chaque numéro de téléphone et chaque adresse de courriel dans vos contacts. Cela peut entraîner une explosion du nombre de combinaisons et une opération potentiellement coûteuse.
Les dimensions assemblées utilisent des jointures externes
Les dimensions non associé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 associées à la table partagée Students mais ne sont associées entre elles, donc les champs Class et Club ne sont pas associé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ù les 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 associé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 associé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 avec relations multi-faits.
Les détails essentiels sont :
- Les valeurs de mesures sont ventilées uniquement par dimensions associées.
- Les valeurs de mesures se répètent pour les dimensions non associé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 associées
Considérez le sous-ensemble de valeurs de dimensions renvoyées pour une jointure interne sur les dimensions associé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 associées
Les valeurs de mesures sont répétées pour les valeurs de dimensions non associées.
Si nous examinons la mesure Length de la table Classes et les valeurs non associé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 de 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 d’un modèle de données avec des relations multi-faits sont définis par table (ne sont pas omniprésents). Pour cette raison, les résultats du filtrage peuvent être différents pour une connexion en direct et une 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 associés aux champs utilisés pour définir l’ensemble. Si vous choisissez Ajouter à l’ensemble, Tableau ajoutera uniquement les champs associé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 cette 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 associé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 non valide dans le contexte d’une visualisation spécifique (en présence d’une dimension non associée). Lorsque cela se produit, la pile LOD devient rouge. Vous pouvez mettre à jour l’expression LOD pour supprimer les conflits de champs non associé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ème résolu | Corrigé à partir de |
Extraits Source de données locale (dans un classeur) : toute tentative d’extraction d’une source de données avec relations multi-faits générera une erreur « Aucune table de ce type ». Source de données publiée : l’extraction d’une source de données publiée avec relations multi-faits semble réussir, mais il peut arriver que les valeurs des champs soient échangées. |
Si ces problèmes persistent dans Tableau Desktop ou Tableau Server, mettez à niveau vers une version du 24 juillet 2024 ou ultérieure. |
Expressions de niveau de détail EXCLUDE Seuls les expressions LOD INCLUDE doivent être validées en présence de champs non associés. Cependant, les expressions LOD EXCLUDE peuvent également être marqués à tort comme non valides dans les mêmes conditions. | |
Calculs d’utilisateurs imbriqués Les calculs d’utilisateurs imbriqués ne sont pas disponibles dans les sources de données publiées avec un modèle de données utilisant des relations multi-faits. |
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 associé, 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 contenant des relations multi-faits. Il se peut que vous ne soyez pas en mesure créer de 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.