Aide pour la relation bidirectionnelle

Cet article vous cible en tant que modélisateur de données qui fonctionne avec Power BI Desktop. Il vous fournit une aide pour créer des relations de modèle bidirectionnelles au bon moment. Une relation bidirectionnelle est une relation qui filtre dans les deux directions.

Notes

La présentation des relations de modèle n’est pas abordée dans cet article. Si vous ne connaissez pas bien les relations, leurs propriétés ni la façon de les configurer, nous vous recommandons de lire d’abord l’article Relations de modèle dans Power BI Desktop.

Il est également important de comprendre la conception de schémas en étoile. Pour plus d’informations, consultez Comprendre le schéma en étoile et son importance pour Power BI.

En règle générale, nous vous recommandons de minimiser l’utilisation des relations bidirectionnelles. Cela est dû au fait qu’ils peuvent avoir un impact négatif sur les performances des requêtes de modèle, et peuvent fournir des expériences déroutantes pour vos utilisateurs de rapport.

Toutefois, il existe trois scénarios où le filtrage bidirectionnel peut résoudre des exigences spécifiques :

• Relations de modèle spéciales
• Options de segment « avec données »
• Analyse de dimension à dimension

Relations de modèle spéciales

Les relations bidirectionnelles jouent un rôle important lors de la création des deux types de relations de modèle spéciales suivantes :

• Un-à-un : toutes les relations un-à-un doivent être bidirectionnelles : il n’est pas possible de les configurer autrement. En règle générale, nous vous déconseillons de créer ces types de relations. Pour obtenir une discussion complète et d’autres modèles de conception, consultez guide de relation un-à-un.
• Relation plusieurs à plusieurs : lors de la connexion de deux tables de dimension, une table de pontage est nécessaire. Un filtre bidirectionnel est requis pour garantir la propagation des filtres dans la table de pontage. Pour plus d’informations, consultez guide de relation plusieurs à plusieurs.

Options de segment « avec données »

Les relations bidirectionnelles peuvent fournir des filtres qui limitent les options aux endroits où existent des données. (Si vous êtes familiarisé avec les tableaux croisés dynamiques et les segments Excel, il s’agit du comportement par défaut lors de l’approvisionnement de données à partir d’un modèle sémantique Power BI ou d’un modèle Analysis Services.) Pour vous aider à expliquer ce qu’il signifie, commencez par prendre en compte le diagramme de modèle suivant.

La première table est nommée Customer., et contient trois colonnes : Country-Region, Customeret CustomerCode. La deuxième table est nommée Productet contient trois colonnes : Color, Productet SKU. La troisième table est nommée Saleset contient quatre colonnes : CustomerCode, OrderDate, Quantityet SKU. Les tables Customer et Product sont des tables de dimension, chacune ayant une relation un-à-plusieurs avec la table Sales. Chaque relation filtre dans une seule direction.

Pour mieux décrire le fonctionnement du filtrage bidirectionnel, le diagramme de modèle a été modifié afin d’afficher les lignes de la table. Tous les exemples de cet article sont basés sur ces données.

Les détails des lignes pour les trois tables sont décrits dans la liste à puces suivante :

• La table Customer comporte deux lignes :
  • CustomerCodeCUST-01, CustomerCustomer-1, Country-RegionÉtats-Unis
  • CustomerCodeCUST-02, CustomerCustomer-2, Country-RegionAustralie
• La table Product comporte trois lignes :
  • SKU CL-01, ProductT-shirt, ColorVert
  • SKU CL-02, ProductJeans, ColorBleu
  • SKUAC-01, ProductChapeau, ColorBleu
• La table Sales comporte trois lignes :
  • OrderDate 1er janvier 2019, CustomerCodeCUST-01, SKUCL-01, Quantity10
  • OrderDate2 février 2019, CustomerCodeCUST-01, SKUCL-02, Quantity20
  • OrderDatele 3 mars 2019, CustomerCodeCUST-02, SKUCL-01, Quantity30

Puis, considérons la page de rapport suivante :

La page se compose de deux segments et d’un visuel de carte. Le premier segment est basé sur le champ Country-Region et comporte deux options : Australie et États-Unis. Le segment actuel est Australie. Le deuxième segment est basé sur le champ Product et comporte trois options : chapeau, Jeans et T-shirt. Aucun élément n’est sélectionné (ce qui signifie qu’aucun produit n’est filtré). Le visuel de la carte affiche une quantité de 30.

Lorsque les utilisateurs du rapport segmentent par Australie, vous pouvez limiter le segment de produit aux options d'affichage où les données sont liées aux ventes australiennes. C’est ce que l’on entend par afficher les options de segment « avec données ». Vous pouvez obtenir ce comportement en définissant la relation entre les tables Product et Sales pour filtrer les dans les deux sens.

Le segment de produit affiche désormais une seule option : t-shirt. Cette option représente le seul produit vendu aux clients australiens.

Tout d’abord, nous vous recommandons de déterminer soigneusement si cette conception fonctionne pour vos utilisateurs de rapports. Certains utilisateurs des rapports trouvent l’expérience déroutante, car ils ne comprennent pas pourquoi les options des segments apparaissent ou disparaissent de manière dynamique lorsqu’ils interagissent avec d’autres segments.

Si vous décidez d’afficher les options de segment « avec des données », nous vous déconseillons de configurer des relations bidirectionnelles. Les relations bidirectionnelles nécessitent davantage de traitement et peuvent donc avoir un impact négatif sur les performances des requêtes, en particulier lorsque le nombre de relations bidirectionnelles dans le modèle augmente.

Il existe un meilleur moyen d’obtenir le même résultat : au lieu d'utiliser des filtres bidirectionnels, vous pouvez appliquer un filtre de niveau visuel au segment de produit lui-même.

Considérons maintenant que la relation entre les tables Product et Sales ne filtre plus dans les deux sens. Et la définition de mesure suivante a été ajoutée à la table Sales.

Total Quantity = SUM(Sales[Quantity])

Pour afficher les options du segmentateur de produit « avec des données », il suffit de le filtrer par la mesure Total Quantity à l’aide de la condition « n’est pas vide ».

Analyse de dimension à dimension

Un autre scénario impliquant des relations bidirectionnelles consiste à traiter une table de faits comme une table de pont . De cette façon, il permet d'analyser les données de la table de dimensions dans le contexte de filtrage d'une autre table de dimensions.

À l’aide de l’exemple de modèle de cet article, réfléchissez à la façon dont les questions suivantes peuvent être traitées :

• Combien de couleurs ont été vendues aux clients australiens ?
• Combien de pays/régions ont acheté des jeans ?

Il est possible de répondre à ces deux questions sans faire un résumé des données dans la table de faits de pontage. Toutefois, ils nécessitent que les filtres se propagent d’une table de dimension à l’autre. Lorsque des filtres se propagent via la table de faits, la synthèse des colonnes de la table de dimension peut être obtenue à l’aide de la fonction DAX DISTINCTCOUNT, et éventuellement des fonctions DAX MIN et MAX.

Comme la table des faits se comporte comme une table de liaison, vous pouvez appliquer les conseils concernant les relations plusieurs à plusieurs pour relier deux tables de dimension. Il faudra configurer au moins une relation pour filtrer dans les deux sens. Pour plus d’informations, consultez guide de relation plusieurs à plusieurs.

Toutefois, comme décrit dans cet article, cette conception aura probablement un impact négatif sur les performances et sur l’expérience utilisateur concernant les options de segments « avec des données ». Par conséquent, à la place, nous vous recommandons d’activer le filtrage bidirectionnel dans une définition de mesure à l’aide de la fonction DAX CROSSFILTER. Vous pouvez utiliser la fonction CROSSFILTER pour modifier les directions de filtre( ou même désactiver la relation) pendant l’évaluation d’une expression.

Considérez la définition de mesure suivante ajoutée à la table Sales. Dans cet exemple, la relation de modèle entre les tables Customer et Sales a été configurée pour filtrer dans une seule direction .

Different Countries Sold =
CALCULATE(
    DISTINCTCOUNT(Customer[Country-Region]),
    CROSSFILTER(
        Customer[CustomerCode],
        Sales[CustomerCode],
        BOTH
    )
)

Pendant l’évaluation de la mesure Different Countries Sold, la relation entre les tables Customer et Sales exerce un filtrage dans les deux sens.

Le visuel de tableau suivant présente les statistiques pour chaque produit vendu. La colonne Quantity est simplement la somme des valeurs de quantité. La colonne Different Countries Sold représente le nombre distinct de valeurs pays-région de tous les clients qui ont acheté le produit.

Contenu connexe

Pour plus d’informations en rapport avec cet article, consultez les ressources suivantes :

• Relations de modèle dans Power BI Desktop
• Comprendre le schéma en étoile et son importance pour Power BI
• Aide pour la relation un-à-un
• Conseils sur les relations Plusieurs-à-plusieurs
• Aide à la résolution des problèmes de relations
• Vous avez des questions ? Essayez de poser des questions à la communauté Fabric
• Vous avez des suggestions ? Envoyez-nous vos idées pour améliorer Fabric