Partager via

Appliquer des relations plusieurs à plusieurs dans Power BI Desktop

  • Article

Les relations avec une cardinalité plusieurs à plusieurs dans Power BI Desktop vous permettent de joindre des tables qui utilisent une cardinalité plusieurs à plusieurs. Vous pouvez créer plus facilement et intuitivement des modèles de données qui contiennent deux ou plusieurs sources de données. Les relations avec une cardinalité plusieurs à plusieurs font partie des fonctionnalités plus larges des modèles composites dans Power BI Desktop. Pour plus d’informations sur les modèles composites, consultez l’article Utiliser des modèles composites dans Power BI Desktop

Capture d’écran d’une relation plusieurs à plusieurs dans le volet Modifier la relation.

Ce qu’une relation avec une cardinalité plusieurs à plusieurs permet de résoudre

Avant que n’existent les relations avec une cardinalité plusieurs à plusieurs, la relation entre deux tables était définie dans Power BI. Au moins une des colonnes de table impliquées dans la relation devait contenir des valeurs uniques. Souvent, cependant, aucune colonne ne contenait de valeurs uniques.

Par exemple, deux tables pouvaient avoir une colonne libellée CountryRegion. Pourtant, les valeurs de CountryRegion n’étaient pas uniques dans ces tables. Pour joindre ces tables, vous aviez besoin de créer une solution de contournement, pouvant consister à introduire des tables supplémentaires contenant les valeurs uniques nécessaires. Avec les relations avec une cardinalité plusieurs à plusieurs, vous pouvez joindre de telles tables directement si vous utilisez une relation avec une cardinalité plusieurs à plusieurs.

Utiliser des relations avec une cardinalité plusieurs à plusieurs

Quand vous définissez une relation entre deux tables dans Power BI, vous devez définir la cardinalité de la relation. Par exemple, la relation entre ProductSales et Product (qui utilise les colonnes ProductSales[ProductCode] et Product[ProductCode]) serait définie en tant que relation Plusieurs à 1. Nous définissons la relation de cette façon, car chaque produit a de nombreuses ventes et la colonne de la table Product (ProductCode) est unique. Quand vous définissez une cardinalité de relation de type plusieurs à 1, 1 à plusieurs ou 1 à 1, Power BI la valide de sorte que celle que vous choisissez corresponde aux données réelles.

Par exemple, examinons le modèle simple dans cette image :

Capture d’écran de la table ProductSales et Product dans l’affichage Relation.

Imaginons maintenant que la table Product affiche seulement deux lignes, comme suit :

Capture d’écran d’un visuel de table Product avec deux lignes.

Imaginez également que la table Sales a seulement quatre lignes, dont une ligne pour un produit C. En raison d’une erreur d’intégrité référentielle, le produit C n’existe pas dans la table Product.

Capture d’écran d’un visuel de table Sales avec quatre lignes.

Les colonnes ProductName et Price (à partir de la table Product), ainsi que la quantité (Qty) totale pour chaque produit (à partir de la table ProductSales) se présenteraient comme suit :

Capture d’écran d’un visuel montrant le nom, le prix et la quantité du produit.

Comme vous pouvez le voir dans l’image précédente, une ligne ProductName vide est associée aux ventes du produit C. Cette ligne vide tient compte des considérations suivantes :

  • Toutes les lignes de la table ProductSales pour lesquelles aucune ligne correspondante n’existe dans la table Product. Il existe un problème d’intégrité référentielle, comme nous le voyons pour le produit C dans cet exemple.

  • Toutes les lignes de la table ProductSales pour lesquelles la colonne clé étrangère est Null.

Pour ces raisons, la ligne vide dans les deux cas tient compte des ventes où ProductName et Price sont inconnus.

Parfois, les tables sont jointes par deux colonnes, pourtant aucune colonne n’est unique. Considérez par exemple ces deux tables :

  • La table Sales affiche les données de ventes par État (State), chaque ligne contenant le montant des ventes pour le type de vente dans l’État concerné. Les États incluent CA, WA et TX.

    Capture d’écran d’une table Sales affichant des ventes par État.

  • La table CityData affiche des données sur les villes, y compris la population et l’État (comme les États de CA, de WA et de New York).

    Capture d’écran d’une table Sales affichant la ville, l’État et la population.

Une colonne État figure désormais dans les deux tables. Il est raisonnable de vouloir créer des rapports sur les ventes totales par État et par population totale de chaque État. Toutefois, il existe un problème : la colonne État n’est pas unique dans les deux tables.

Solution de contournement précédente

Avant la version de juillet 2018 de Power BI Desktop, vous ne pouviez pas créer une relation directe entre ces tables. Une solution de contournement courante consistait à :

  • Créer une troisième table contenant uniquement les ID d’État uniques. La table pouvait être :

    • Une table calculée (définie à l’aide du langage DAX [Data Analysis Expressions]).
    • Une table basée sur une requête définie dans l’Éditeur Power Query, pouvant afficher les ID uniques provenant d’une des tables.
    • L’ensemble combiné.

  • Lier ensuite les deux tables d’origine à cette nouvelle table, à l’aide de relations plusieurs à 1 classiques.

Vous pouviez laisser la table de la solution de contournement visible. Vous pourriez également masquer la table de la solution de contournement afin qu’elle n’apparaisse pas dans la liste Champs. Si vous masquiez la table, la relation plusieurs à 1 était généralement définie pour filtrer dans les deux directions et vous pouviez utiliser le champ State d’une des deux tables. Ce filtrage croisé qui s’ensuivrait se propagerait à l’autre table. Cette approche est illustrée dans l’image suivante :

Capture d’écran d’une table Sate masquée en mode Relation.

Un visuel affichant le champ State (État) (à partir de la table CityData), ainsi que la Population totale et les ventes (Sales) totales ressemblerait alors à ce qui suit :

Capture d’écran montrant une table avec des données State, Population et Sales.

Notes

Étant donné que l’État issu de la table CityData est utilisé dans cette solution de contournement, seuls les États de cette table sont listés, ce qui explique l’exclusion de TX. De plus, contrairement aux relations plusieurs à 1, alors que la ligne totale inclut toutes les ventes (y compris celles de TX), les détails n’incluent pas de ligne vide couvrant les lignes qui ne correspondent pas. De même, aucune ligne vide ne couvre les ventes pour lesquelles il existe une valeur Null pour l’État.

Supposons que vous ajoutez également City à ce visuel. Bien que la population par ville (City) soit connue, les ventes (Sales) indiquées pour City reprennent les ventes (Sales) pour l’État (State) correspondant. Ce scénario se produit normalement lorsque le regroupement de colonnes n’est pas lié à une mesure d’agrégation, comme illustré ici :

Capture d’écran d’une table montrant la population et les ventes de l’état et de la ville.

Supposons que vous définissez la nouvelle table Sales comme la combinaison de tous les États ici et qu’elle est visible dans la liste Champs. Le même visuel afficherait State (État) (dans la nouvelle table), la population totale et les ventes (Sales) totales :

Capture d’écran d’un visuel montrant l’état, le remplissage et les ventes.

Comme vous pouvez le voir, TX (dont les données Sales sont connues mais pas les données Population) et New York (dont les données Population sont connues mais pas les données Sales) seraient inclus. Cette solution de contournement n’est pas optimale et présente plusieurs problèmes. Pour les relations avec une cardinalité plusieurs à plusieurs, les problèmes liés sont traités, comme décrit dans la section suivante.

Pour plus d’informations sur l’implémentation de cette solution de contournement, consultez Conseils sur les relations plusieurs-à-plusieurs.

Utiliser une relation avec une cardinalité plusieurs à plusieurs au lieu de la solution de contournement

Vous pouvez lier des tables directement, telles que celles que nous avons décrites précédemment, sans devoir recourir à des solutions de contournement similaires. Il est désormais possible de définir la cardinalité de la relation sur plusieurs à plusieurs. Ce paramètre indique qu’aucune table ne contient de valeurs uniques. Pour ces relations, vous pouvez toujours contrôler quelle table filtre l’autre. Vous pouvez également appliquer un filtrage bidirectionnel, où chaque table filtre l’autre.

Dans Power BI Desktop, la cardinalité par défaut est plusieurs à plusieurs quand elle détermine qu’aucune table ne contient de valeurs uniques pour les colonnes de la relation. Dans ce cas, un message d’avertissement confirme que vous voulez définir une relation, et que la modification n’est pas l’effet involontaire d’un problème de données.

Par exemple, quand vous créez une relation directe entre CityData et Sales (où les filtres devraient aller de CityData à Sales), Power BI Desktop affiche la boîte de dialogue Modifier la relation :

Capture d’écran de la boîte de dialogue Modifier la relation avec Cardinalité et Direction du filtrage croisé en évidence.

La vue Relation résultante montrerait alors la relation directe plusieurs à plusieurs entre les deux tables. L’aspect des tables dans la liste Champs et leur comportement ultérieur à la création des visuels sont similaires à ceux observables pendant l’application de la solution de contournement. Dans la solution de contournement, la table supplémentaire qui affiche les données des différents États (State) n’est pas rendue visible. Comme décrit précédemment, un visuel montrant des données State, Population et Sales s’afficherait :

Capture d’écran d’une table State, Population, and Sales.

Les principales différences entre les relations avec une cardinalité plusieurs à plusieurs et les relations plusieurs à une plus courantes sont les suivantes :

  • Les valeurs indiquées n’incluent pas de ligne vide tenant compte des lignes qui ne correspondent pas dans l’autre table. De plus, les valeurs ne tiennent pas compte des lignes dans lesquelles la colonne utilisée dans la relation dans l’autre table est Null.

  • Vous ne pouvez pas utiliser la fonction RELATED(), car plusieurs lignes pourraient être liées.

  • L’utilisation de la fonction ALL() sur une table ne supprime pas les filtres qui sont appliqués à d’autres tables reliées par une relation plusieurs à plusieurs. Dans l’exemple précédent, une mesure définie comme illustré ici ne supprimerait pas de filtres de colonnes dans la table CityData liée :

    Capture d’écran de l’exemple de script Sales total = Calculate(Sum(’Sales’[Sales]), All(’Sales’)).

    Un visuel montrant des données State, Sales et Sales total donnerait ce graphique :

    Capture d’écran d’un visuel de table montrant les valeurs State, Sales et Sales total résultant de la formule.

En tenant compte des différences indiquées plus haut, vérifiez que les calculs qui utilisent ALL(<Table>), tels que % du total général, retournent les résultats prévus.

Observations et limitations

Il existe quelques limitations pour cette version des relations avec une cardinalité plusieurs à plusieurs et des modèles composites.

Les sources (multidimensionnelles) Live Connect suivantes ne peuvent pas être utilisées avec les modèles composites :

  • SAP HANA
  • SAP Business Warehouse
  • SQL Server Analysis Services
  • Modèles sémantiques Power BI
  • Azure Analysis Services

Quand vous vous connectez à ces sources multidimensionnelles à l’aide de DirectQuery, vous ne pouvez pas vous connecter à une autre source DirectQuery ou la combiner avec des données importées.

Les limitations existantes sur l’utilisation de DirectQuery s’appliquent encore quand vous utilisez des relations avec une cardinalité plusieurs à plusieurs. De nombreuses limitations sont désormais appliquées par table, selon le mode de stockage de la table. Par exemple, une colonne calculée d’une table importée peut faire référence à d’autres tables, mais une colonne calculée d’une table DirectQuery ne peut faire référence qu’à des colonnes de la même table. D’autres limitations s’appliquent au modèle entier si aucune des tables du modèle n’est de type DirectQuery. Par exemple, les fonctionnalités QuickInsights et Questions et réponses ne sont pas disponibles sur un modèle si une des tables qu’il contient présente un mode de stockage de type DirectQuery.

Contenu connexe

Pour plus d’informations sur les modèles composites et DirectQuery, consultez les articles suivants :