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 (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 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. 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 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 des 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 corrélation au niveau du champ

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.
• 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. Ce message apparaît à chaque fois que vous ajoutez un champ non lié afin de vous rappeler de valider l’utilisation de champs non liés dans votre analyse. Le message d’avertissement ne vous empêche pas de poursuivre, mais vous aide à éviter d’éventuels problèmes de performances. Par exemple, l’utilisation de champs non liés avec une cardinalité élevée peut entraîner des jointures croisées qui auront un impact sur les performances du classeur.

Cliquez sur Ajouter pour continuer à ajouter le champ à la visualisation. Si vous ne souhaitez plus voir le message, sélectionnez l’option Ne plus afficher ce message. Pour faire réapparaître ces messages d’avertissement, il vous suffit de les réactiver : ouvrez le menu Aide > Paramètres et performances > Réinitialiser les messages ignorés.

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.

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é, comme dans les cas de relation ambiguë. 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.

Champs 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.

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.

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 possibles entre deux tables partagées (ou les tables en aval d’une table partagée) et qu’elles peuvent être considérées comme non encore liées dans le contexte de la visualisation.

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 existe une ambiguïté 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 liés de manière ambiguë : il existe plusieurs relations potentielles.

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, les champs liés de manière ambiguë peuvent être résolus et les champs peuvent être directement liés.

Résoudre l’ambiguïté

Il est possible de résoudre l’ambiguïté en ajoutant un champ pour déterminer quelle arborescence utiliser.

Exemple :

• 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.
• Alternativement, l’utilisation d’un champ de la table X résout l’ambiguïté entre FieldS et FieldT pour baser l’arborescence de la table X.

Lié de manière ambiguë	Ambiguïté 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 ambiguïté 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’ambiguïté 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’ambiguïté

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

Assemblage	Résolution de l’ambiguïté
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
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ë 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.

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

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 connus de la version 2024.2

Extraits

Avertissement : les sources de données avec des relations multi-faits doivent être des connexions en direct, et non des 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.

Il existe un correctif prévu pour ce comportement.

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.

Expressions de niveau de détail EXCLUDE

Seules les expressions LOD INCLUDE doivent être validées en présence de champs non liés. Cependant, les expressions LOD EXCLUDE peuvent également être marquées à tort comme non valides dans les mêmes conditions. Il existe un correctif prévu pour ce comportement.

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 basés sur des relations multi-faits. 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