Relations de modèle dans Power BI Desktop

Cet article s'adresse aux modélisateurs de données qui travaillent avec l'importation de données dans Power BI Desktop. Il s’agit d’une rubrique de conception de modèle importante qui est essentielle pour fournir des modèles intuitifs, précis et optimaux.

Pour une discussion plus approfondie sur la conception optimale des modèles, notamment les rôles de table et les relations, consultez Comprendre le schéma en étoile et l’importance de Power BI.

Objectif de relation

Une relation de modèle propage les filtres appliqués sur la colonne d’une table de modèle à une autre table de modèle. Les filtres se propagent tant qu’il existe un chemin de relation à suivre, ce qui peut impliquer la propagation vers plusieurs tables.

Les chemins de relation sont déterministes, ce qui signifie que les filtres sont toujours propagés de la même façon et sans variation aléatoire. Toutefois, les relations peuvent être désactivées ou avoir un contexte de filtre modifié par les calculs de modèle qui utilisent des fonctions DAX (Data Analysis Expressions) particulières. Pour plus d’informations, consultez la section Fonctions DAX pertinentes plus loin dans cet article.

Important

Les relations de modèle n’appliquent pas l’intégrité des données. Pour plus d’informations, consultez la section Évaluation des relations plus loin dans cet article, qui explique comment les relations de modèle se comportent lorsqu’il existe des problèmes d’intégrité des données avec vos données.

Voici comment les relations propagent des filtres avec un exemple animé.

Dans cet exemple, le modèle se compose de quatre tables : Catégorie, Produit, Année et Ventes. La table Category est liée à la table Product et la table Product est liée à la table Sales . La table Year est également liée à la table Sales . Toutes les relations sont un-à-plusieurs (les détails qui sont décrits plus loin dans cet article).

Une requête, éventuellement générée par un visuel de carte Power BI, demande la quantité totale de ventes pour les commandes de vente effectuées pour une seule catégorie, Cat-A et pour une seule année , CY2018. C’est pourquoi vous pouvez voir les filtres appliqués aux tables Catégorie et Année . Le filtre de la table Category se propage à la table Product pour isoler deux produits affectés à la catégorie Cat-A. Ensuite, les filtres de table Product se propagent à la table Sales pour isoler seulement deux lignes de vente pour ces produits. Ces deux lignes de vente représentent les ventes de produits attribués à la catégorie Cat-A. Leur quantité combinée est de 14 unités. En même temps, le filtre de la table Year se propage pour filtrer davantage la table Sales , ce qui génère uniquement la seule ligne de vente affectée aux produits attribués à la catégorie Cat-A et qui a été commandé en année CY2018. La valeur de quantité retournée par la requête est de 11 unités. Lorsque plusieurs filtres sont appliqués à une table (comme la table Sales dans cet exemple), il s’agit toujours d’une opération AND, nécessitant que toutes les conditions soient vraies.

Appliquer des principes de conception de schéma en étoile

Nous vous recommandons d’appliquer des principes de conception de schéma en étoile pour produire un modèle comprenant des tables de dimensions et de faits. Il est courant de configurer Power BI pour appliquer des règles qui filtrent les tables de dimension, ce qui permet aux relations de modèle de propager efficacement ces filtres aux tables de faits.

L’image suivante est le diagramme de modèle du modèle de données d’analyse des ventes Adventure Works. Il montre une conception de schéma en étoile comprenant une table de faits unique nommée Sales. Les quatre autres tables sont des tables de dimension qui prennent en charge l’analyse des mesures de vente par date, état, région et produit. Notez que les relations de modèle connectent toutes les tables. Ces relations propagent des filtres (directement ou indirectement) à la table Sales .

Tables déconnectées

Il est rare qu’une table de modèle ne soit pas associée à une autre table de modèle. Une telle table dans une conception de modèle valide est décrite comme une table déconnectée. Une table déconnectée n’est pas destinée à propager des filtres à d’autres tables de modèle. Au lieu de cela, elle accepte des « entrées utilisateur » (peut-être avec un visuel de segment), ce qui permet aux calculs de modèle d’utiliser les valeurs d’entrée de manière significative. Par exemple, considérez une table déconnectée chargée avec une plage de valeurs de taux de change monétaires. Tant qu’un filtre est appliqué pour filtrer par une valeur de taux unique, une expression de mesure peut utiliser cette valeur pour convertir des valeurs de vente.

Le paramètre de scénario (« what-if ») Power BI Desktop est une fonctionnalité qui crée une table déconnectée. Pour plus d’informations, consultez Créer et utiliser un paramètre de scénario pour visualiser des variables dans Power BI Desktop.

Propriétés de la relation

Une relation de modèle associe une colonne d’une table à une colonne d’une autre table. (Il existe un cas spécialisé où cette exigence n’est pas vraie et s’applique uniquement aux relations multi-colonnes dans les modèles DirectQuery. Pour plus d’informations, consultez l’article de la fonction COMBINEVALUES DAX.)

Note

Il n’est pas possible de lier une colonne à une autre colonne dans la même table. Ce concept est parfois confondu avec la possibilité de définir une contrainte de clé étrangère dans une base de données relationnelle où la table se référence elle-même. Vous pouvez utiliser ce concept de base de données relationnelle pour stocker les relations hiérarchiques (par exemple, chaque enregistrement d'employé est lié à un employé auquel il rapporte). Toutefois, vous ne pouvez pas utiliser de relations de modèle pour générer une hiérarchie de modèles en fonction de ce type de relation. Pour créer une hiérarchie parent-enfant, consultez les fonctions Parent et Enfant.

Types de données de colonnes

Le type de données pour la colonne « from » et « to » de la relation doit être identique. L’utilisation des relations définies sur les colonnes DateTime peut ne pas se comporter comme prévu. Le moteur qui stocke les données Power BI, utilise uniquement les types de données DateTime ; Les types de données Date, Heure et Date/Heure/Fuseau horaire sont des constructions de mise en forme Power BI implémentées en haut. Tous les objets dépendants du modèle apparaissent toujours comme DateTime dans le moteur (par exemple, les relations, les groupes, etc.). Par conséquent, si un utilisateur sélectionne Date dans l’onglet Modélisation pour ces colonnes, il ne s’inscrit toujours pas comme étant la même date, car la partie heure des données est toujours considérée par le moteur. En savoir plus sur la façon dont les types date/heure sont gérés. Pour corriger le comportement, les types de données de colonne doivent être mis à jour dans l’Éditeur Power Query pour supprimer la partie Heure des données importées. Par conséquent, lorsque le moteur gère les données, les valeurs apparaissent identiques.

Cardinalité

Chaque relation de modèle est définie par un type de cardinalité. Il existe quatre options de type cardinalité, représentant les caractéristiques de données des colonnes « from » et « to » associées. Le côté « un » signifie que la colonne contient des valeurs uniques ; le côté « plusieurs » signifie que la colonne peut contenir des valeurs en double.

Note

Si une opération d’actualisation des données tente de charger des valeurs dupliquées dans une colonne latérale « un », l’actualisation complète des données échoue.

Les quatre options, ainsi que leurs notations abrégées, sont décrites dans la liste suivante :

• Un-à-plusieurs (1 :*)
• Plusieurs-à-un (* :1)
• Un-à-un (1:1)
• Plusieurs à plusieurs (*:*)

Lorsque vous créez une relation dans Power BI Desktop, le concepteur détecte et définit automatiquement le type de cardinalité. Power BI Desktop interroge le modèle pour savoir quelles colonnes contiennent des valeurs uniques. Pour les modèles d’importation, il utilise des statistiques de stockage internes ; pour les modèles DirectQuery, il envoie des requêtes de profilage à la source de données. Toutefois, Power BI Desktop peut parfois se tromper. Il peut y avoir des erreurs lorsque les tables ne sont pas encore chargées de données ou que les colonnes qui devraient avoir des valeurs en double ont actuellement des valeurs uniques. Dans les deux cas, vous pouvez mettre à jour le type de cardinalité tant que les colonnes du côté « un » contiennent des valeurs uniques (ou que la table n’ait pas encore été chargée de lignes de données).

Cardinalité un-à-plusieurs (et plusieurs-à-un)

Les options de cardinalité un-à-plusieurs et plusieurs-à-un sont essentiellement les mêmes, et elles sont également les types de cardinalité les plus courants.

Lorsque vous configurez une relation un-à-plusieurs ou plusieurs-à-un, choisissez celle qui correspond à l’ordre dans lequel vous avez associé les colonnes. Réfléchissez à la façon dont vous configurez la relation entre la table Product et la table Sales à l’aide de la colonne ProductID trouvée dans chaque table. Le type de cardinalité serait un-à-plusieurs, car la colonne ProductID de la table Product contient des valeurs uniques. Si vous avez associé les tables dans la direction inverse, Sales to Product, la cardinalité serait plusieurs-à-un.

Cardinalité un-à-un

Une relation un-à-un signifie que les deux colonnes contiennent des valeurs uniques. Ce type de cardinalité n’est pas courant et représente probablement une conception de modèle non optimale en raison du stockage de données redondantes.

Pour plus d’informations sur l’utilisation de ce type de cardinalité, consultez les instructions relatives à une relation un-à-un.

Cardinalité plusieurs-à-plusieurs

Une relation plusieurs-à-plusieurs signifie que les deux colonnes peuvent contenir des valeurs en double. Ce type de cardinalité est rarement utilisé. Il est généralement utile lors de la conception d’exigences de modèle complexes. Vous pouvez l'utiliser pour lier des faits de plusieurs-à-plusieurs ou pour relier des faits à grain plus fin. Par exemple, lorsque les faits cibles des ventes sont stockés au niveau de la catégorie de produit et que la table de dimension de produit est stockée au niveau du produit.

Pour obtenir des conseils sur l’utilisation de ce type de cardinalité, consultez les instructions relatives aux relations plusieurs-à-plusieurs.

Note

Le type de cardinalité plusieurs-à-plusieurs est pris en charge pour les modèles développés pour Power BI Report Server janvier 2024 et versions ultérieures.

Conseil / Astuce

Dans la vue de modèle Power BI Desktop, vous pouvez interpréter le type de cardinalité d’une relation en examinant les indicateurs (1 ou *) du côté de la ligne de relation. Pour déterminer les colonnes associées, sélectionnez ou pointez le curseur sur la ligne de relation pour mettre en surbrillance les colonnes.

Sens du filtre croisé

Chaque relation de modèle est définie avec une direction de filtre croisé. Votre paramètre détermine la ou les directions que les filtres propageront. Les options de filtre croisé possibles dépendent du type de cardinalité.

Type de cardinalité	Options de filtre croisé
Un-à-plusieurs (ou plusieurs-à-un)	Célibataire Les deux
One-to-one	Les deux
Many-to-many	Single (Table1 à Table2) Single (Table2 à Table1) Les deux

La direction du filtre croisé unique signifie « direction unique », et les deux signifient « les deux directions ». Une relation qui filtre dans les deux directions est généralement décrite comme bidirectionnelle.

Pour les relations un-à-plusieurs, la direction du filtre croisé est toujours du côté « un » et éventuellement du côté « plusieurs » (bidirectionnel). Pour les relations un-à-un, la direction du filtre croisé provient toujours des deux tables. Enfin, pour les relations plusieurs-à-plusieurs, le sens du filtre croisé peut provenir de l’une des tables ou des deux tables. Notez que lorsque le type de cardinalité inclut un côté « un », les filtres se propageront toujours de ce côté.

Lorsque la direction du filtre croisé est définie sur Les deux, une autre propriété devient disponible. Il peut appliquer un filtrage bidirectionnel lorsque Power BI applique des règles de sécurité au niveau des lignes (RLS). Pour plus d’informations sur la sécurité au niveau des lignes (RLS) avec Power BI Desktop.

Vous pouvez modifier la direction du filtre croisé d’une relation, y compris la désactivation de la propagation de filtres, à l’aide d’un calcul de modèle. Elle est obtenue à l’aide de la fonction CROSSFILTER DAX.

N’oubliez pas que les relations bidirectionnelles peuvent avoir un impact négatif sur les performances. En outre, la tentative de configuration d’une relation bidirectionnelle peut entraîner des chemins de propagation de filtre ambigus. Dans ce cas, Power BI Desktop peut ne pas valider la modification de la relation et vous avertira d’un message d’erreur. Toutefois, Power BI Desktop peut parfois vous permettre de définir des chemins de relation ambigus entre les tables. La résolution de l’ambiguïté du chemin de relation est décrite plus loin dans cet article.

Nous vous recommandons d’utiliser le filtrage bidirectionnel uniquement si nécessaire. Pour plus d’informations, consultez les instructions relatives aux relations bidirectionnelles.

Conseil / Astuce

Dans la vue des modèles de Power BI Desktop, vous pouvez interpréter la direction du filtre croisé d’une relation en observant les flèches le long de la ligne de relation. Une pointe de flèche unique représente un filtre à sens unique dans la direction de la pointe de flèche ; une flèche double représente une relation bidirectionnelle.

Rendre cette relation active

Il ne peut y avoir qu’un seul chemin de propagation de filtre actif entre deux tables de modèle. Toutefois, il est possible d’introduire des chemins de relation supplémentaires, bien que vous deviez définir ces relations comme inactives. Les relations inactives peuvent uniquement être actives pendant l’évaluation d’un calcul de modèle. Elle est obtenue à l’aide de la fonction USERELATIONSHIP DAX.

En règle générale, nous vous recommandons de définir des relations actives dans la mesure du possible. Ils élargissent l’étendue et le potentiel de la façon dont les auteurs de rapports peuvent utiliser votre modèle. L’utilisation de relations uniquement actives signifie que les tables de dimensions jouant plusieurs rôles doivent être dupliquées dans votre modèle.

Toutefois, dans des circonstances spécifiques, vous pouvez définir une ou plusieurs relations inactives pour une table de dimension de jeu de rôles. Vous pouvez prendre en compte cette conception lorsque :

• Il n’est pas nécessaire que les visuels de rapport filtrent simultanément par différents rôles.
• Vous utilisez la USERELATIONSHIP fonction DAX pour activer une relation spécifique pour les calculs de modèle pertinents.

Pour plus d’informations, consultez les instructions relatives aux relations actives et inactives.

Conseil / Astuce

Dans la vue de modèle Power BI Desktop, vous pouvez interpréter l’état actif et inactif d’une relation. Une ligne unie représente une relation active, et une ligne en pointillés représente une relation inactive.

Supposer l’intégrité référentielle

La propriété d’intégrité référentielle Assume est disponible uniquement pour les relations un-à-plusieurs et un-à-un entre deux tables en mode de stockage DirectQuery appartenant au même groupe source. Vous ne pouvez activer cette propriété que lorsque la colonne latérale « plusieurs » ne contient pas de valeurs NULL.

Lorsqu’elles sont activées, les requêtes natives envoyées à la source de données joignent les deux tables à l’aide d’un INNER JOINOUTER JOIN. En règle générale, l’activation de cette propriété améliore les performances des requêtes, bien qu’elle dépende des spécificités de la source de données.

Activez toujours cette propriété lorsqu’une contrainte de clé étrangère de base de données existe entre les deux tables. Même lorsqu’une contrainte de clé étrangère n’existe pas, envisagez d’activer la propriété tant que vous êtes certain de l’intégrité des données.

Important

Si l’intégrité des données doit être compromise, la jointure interne élimine les lignes sans correspondance entre les tables. Par exemple, considérez une table Sales model avec une valeur de colonne ProductID qui n’existe pas dans la table Product associée. Filtrer la propagation de la table Product vers la table Sales élimine les lignes de ventes pour les produits inconnus, ce qui entraîne une sous-estimation des résultats des ventes.

Pour plus d’informations, consultez Supposer les paramètres d’intégrité référentielle dans Power BI Desktop.

Fonctions DAX pertinentes

Plusieurs fonctions DAX sont pertinentes pour les relations de modèle. Chaque fonction est décrite brièvement dans la liste suivante :

• CONNEXE : Récupère la valeur du côté « un » d’une relation. Il est utile d’impliquer des calculs provenant de différentes tables évaluées dans le contexte de ligne.
• RELATEDTABLE : Récupérez une table de lignes du côté « plusieurs » d’une relation.
• USERELATIONSHIP : permet à un calcul d’utiliser une relation inactive. (Techniquement, cette fonction modifie le poids d’une relation de modèle inactive spécifique, ce qui contribue à influer sur son utilisation.) Il est utile lorsque votre modèle inclut une table de dimension à rôle et que vous choisissez de créer des relations inactives à partir de cette table. Vous pouvez également utiliser cette fonction pour résoudre l’ambiguïté dans les chemins de filtre.
• CROSSFILTER : modifie la direction du filtre croisé de relation (dans une direction ou dans les deux directions) ou désactive la propagation du filtre (aucune). Il est utile lorsque vous devez modifier ou ignorer les relations de modèle pendant l’évaluation d’un calcul spécifique.
• COMBINEVALUES : joint deux chaînes de texte ou plus à une chaîne de texte. L’objectif de cette fonction est de prendre en charge les relations à plusieurs colonnes dans les modèles DirectQuery lorsque les tables appartiennent au même groupe source.
• TREATAS : Applique le résultat d’une expression de table en tant que filtres aux colonnes d’une table non liée. Il est utile dans les scénarios avancés lorsque vous souhaitez créer une relation virtuelle pendant l’évaluation d’un calcul spécifique.
• Fonctions parent et enfant : famille de fonctions associées que vous pouvez utiliser pour générer des colonnes calculées pour naturaliser une hiérarchie parent-enfant. Vous pouvez ensuite utiliser ces colonnes pour créer une hiérarchie de niveau fixe.

Évaluation des relations

Les relations de modèle, du point de vue de l’évaluation, sont classées comme étant régulières ou limitées. Il ne s’agit pas d’une propriété de relation configurable. Il est en fait déduit du type de cardinalité et de la source de données des deux tables associées. Il est important de comprendre le type d’évaluation, car il peut y avoir des implications sur les performances ou des conséquences si l’intégrité des données est compromise. Ces implications et conséquences sur l’intégrité sont décrites dans cette section.

Tout d’abord, certaines théories de modélisation sont nécessaires pour comprendre pleinement les évaluations des relations.

Un modèle d’importation ou DirectQuery source toutes ses données à partir du cache Vertipaq ou de la base de données source. Dans les deux cas, Power BI est en mesure de déterminer qu’un côté « un » d’une relation existe.

Toutefois, un modèle composite peut comprendre des tables à l’aide de différents modes de stockage (importation, DirectQuery ou double) ou de plusieurs sources DirectQuery. Chaque source, y compris le cache Vertipaq des données importées, est considérée comme un groupe source. Les relations de modèle peuvent ensuite être classées en tant que groupe intra source ou groupe intergroupe source/croisé. Une relation de groupe intra source associe deux tables au sein d’un groupe source, tandis qu’une relation entre les groupes sources associe les tables entre deux groupes sources. Notez que les relations dans les modèles d’importation ou DirectQuery sont toujours intra-groupe source.

Voici un exemple de modèle composite.

Dans cet exemple, le modèle composite se compose de deux groupes sources : un groupe source Vertipaq et un groupe source DirectQuery. Le groupe source Vertipaq contient trois tables et le groupe source DirectQuery contient deux tables. Une relation entre groupes sources existe pour lier une table dans le groupe source Vertipaq à une table du groupe source DirectQuery.

Relations régulières

Une relation de modèle est régulière lorsque le moteur de requête peut déterminer le côté « un » de la relation. Il est confirmé que la colonne latérale « une » contient des valeurs uniques. Toutes les relations de groupe intra source un-à-plusieurs sont des relations régulières.

Dans l’exemple suivant, deux relations régulières sont marquées comme R. Les relations incluent la relation un-à-plusieurs contenue dans le groupe source Vertipaq et la relation un-à-plusieurs contenue dans la source DirectQuery.

Pour les modèles d’importation, où toutes les données sont stockées dans le cache Vertipaq, Power BI crée une structure de données pour chaque relation régulière au moment de l’actualisation des données. Les structures de données sont constituées de mappages indexés de toutes les valeurs de colonne à colonne, et leur objectif est d’accélérer la jointure de tables au moment de la requête.

Au moment de la requête, les relations normales permettent l’expansion de table. L’expansion de table entraîne la création d’une table virtuelle en incluant les colonnes natives de la table de base, puis en développant dans des tables associées. Pour les tables d’importation, l’extension de table est effectuée dans le moteur de requête ; pour les tables DirectQuery, elle est effectuée dans la requête native envoyée à la base de données source (tant que la propriété d’intégrité référentielle Assume n’est pas activée). Le moteur de requête agit ensuite sur la table développée, en appliquant des filtres et en regroupant les valeurs dans les colonnes de la table développée.

Note

Les relations inactives sont également élargies, même lorsqu'elles ne sont pas employées dans un calcul. Les relations bidirectionnelles n’ont aucun impact sur l’expansion de table.

Pour les relations un-à-plusieurs, l’expansion de table se déroule du « plusieurs » vers le « un » en utilisant la sémantique LEFT OUTER JOIN. Lorsqu’une valeur correspondante du côté « plusieurs » à « un » n’existe pas, une ligne virtuelle vide est ajoutée à la table latérale « un ». Ce comportement s’applique uniquement aux relations régulières, pas aux relations limitées.

L’expansion de table se produit également pour les relations de groupe intra-source un-à-un, mais en utilisant la sémantique FULL OUTER JOIN. Ce type de jointure garantit que les lignes virtuelles vides sont ajoutées de chaque côté, si nécessaire.

Les lignes virtuelles vides sont des membres inconnus. Les membres inconnus représentent des violations d’intégrité référentielle où la valeur côté « plusieurs » n’a pas de valeur côté « un » correspondant. Dans l’idéal, ces espaces ne doivent pas exister. Ils peuvent être éliminés en nettoyant ou en réparant les données sources.

Voici comment l’expansion de table fonctionne avec un exemple animé.

Dans cet exemple, le modèle se compose de trois tables : Catégorie, Produit et Ventes. La table Category est liée à la table Product avec une relation un-à-plusieurs, et la table Product est liée à la table Sales avec une relation un-à-plusieurs. La table Category contient deux lignes, la table Product contient trois lignes, et les tables Sales contiennent cinq lignes. Il existe des valeurs correspondantes des deux côtés de toutes les relations, ce qui signifie qu’il n’existe aucune violation d’intégrité référentielle. Une table élargie au moment de la requête est affichée. La table est constituée des colonnes provenant des trois tables. Il s’agit effectivement d’une perspective dénormalisée des données contenues dans les trois tables. Une nouvelle ligne est ajoutée à la table Sales et a une valeur d’identificateur de production (9) qui n’a aucune valeur correspondante dans la table Product . C’est une violation d’intégrité référentielle. Dans le tableau développé, la nouvelle ligne présente des valeurs (vides) pour les colonnes Catégorie et Produit.

Relations limitées

Une relation de modèle est limitée lorsqu’il n’y a pas de côté « un » garanti. Une relation limitée peut se produire pour deux raisons :

• La relation utilise un type de cardinalité plusieurs à plusieurs (même si une ou les deux colonnes ont des valeurs uniques).
• La relation est croisée entre les groupes sources (ce qui ne peut être le cas que pour les modèles composites).

Dans l’exemple suivant, deux relations limitées sont marquées comme L. Les deux relations incluent la relation plusieurs-à-plusieurs contenue dans le groupe source Vertipaq et la relation entre groupes sources un-à-plusieurs.

Pour les modèles d’importation, les structures de données ne sont jamais créées pour des relations limitées. Dans ce cas, Power BI résout les jointures de table au moment de la requête.

L’expansion de table ne se produit jamais pour des relations restreintes. Les jointures de table sont réalisées à l'aide de la sémantique INNER JOIN, et pour cette raison, les lignes virtuelles vides ne sont pas ajoutées pour compenser les violations d'intégrité référentielle.

Il existe d’autres restrictions liées aux relations limitées :

• La fonction DAX RELATED ne peut pas être utilisée pour récupérer les valeurs de la colonne du côté « un ».
• L’application de RLS a des restrictions de topologie.

Conseil / Astuce

Dans la vue de modèle Power BI Desktop, vous pouvez interpréter une relation comme étant limitée. Une relation limitée est représentée par des marques similaires à des parenthèses () après les indicateurs de cardinalité.

Résoudre l’ambiguïté du chemin de relation

Les relations bidirectionnelles peuvent introduire plusieurs chemins de propagation de filtre ambigus entre les tables de modèle. Lorsqu’il évalue l’ambiguïté, Power BI choisit le chemin de propagation du filtre en fonction de sa priorité et de son poids.

Priority

Les niveaux de priorité définissent une séquence de règles que Power BI utilise pour résoudre l’ambiguïté du chemin de relation. La première règle ayant une correspondance détermine le chemin que Power BI suivra. Dans la séquence suivante, chaque règle décrit comment les filtres circulent d’une table source vers une table cible.

1. Chemin constitué de relations un-à-plusieurs.
2. Chemin constitué de relations un-à-plusieurs ou plusieurs-à-plusieurs.
3. Chemin constitué de relations plusieurs-à-un.
4. Chemin d’accès composé de relations un-à-plusieurs de la table source vers une table intermédiaire suivie de relations plusieurs-à-un entre la table intermédiaire et la table cible.
5. Chemin d’accès composé de relations un-à-plusieurs ou plusieurs-à-plusieurs de la table source vers une table intermédiaire suivie de relations plusieurs-à-un ou plusieurs-à-plusieurs de la table intermédiaire vers la table cible.
6. Tout autre chemin.

Lorsqu’une relation est incluse dans tous les chemins d’accès disponibles, elle est supprimée de l’examen de tous les chemins d’accès.

Weight

Chaque relation dans un chemin a un poids. Par défaut, chaque poids de relation est égal à moins que la fonction USERELATIONSHIP soit utilisée. Le poids du chemin est le maximum de toutes les pondérations de relation le long du chemin. Power BI utilise les pondérations de chemin pour résoudre l’ambiguïté entre plusieurs chemins dans le même niveau de priorité. Il ne choisira pas un chemin avec une priorité inférieure, mais il choisira le chemin avec le poids supérieur. Le nombre de relations dans le chemin n’affecte pas le poids.

Vous pouvez influencer le poids d’une relation à l’aide de la fonction USERELATIONSHIP . Le poids est déterminé par le niveau d’imbrication de l’appel à cette fonction, où l’appel le plus profond reçoit le poids le plus élevé.

Considérez l'exemple suivant. La mesure Product Sales affecte un poids plus élevé à la relation entre Sales[ProductID] et Product [ProductID], suivie de la relation entre Inventory[ProductID] et Product[ProductID].

Product Sales = 
CALCULATE(
    CALCULATE(
        SUM(Sales[SalesAmount]), 
        USERELATIONSHIP(Sales[ProductID], Product[ProductID])
    ),
    USERELATIONSHIP(Inventory[ProductID], Product[ProductID])
)

Note

Si Power BI détecte plusieurs chemins ayant la même priorité et le même poids, il retourne une erreur de chemin ambiguë. Dans ce cas, vous devez résoudre l’ambiguïté en influençant les pondérations de relation à l’aide de la fonction USERELATIONSHIP , ou en supprimant ou en modifiant des relations de modèle.

Préférence de performance

La liste suivante classe les performances de propagation des filtres, de la plus rapide à la plus lente.

1. Relations de groupe un-à-plusieurs au sein de la source
2. Relations de modèle de type plusieurs-à-plusieurs réalisées à l'aide d'une table intermédiaire et impliquant au moins une relation bidirectionnelle
3. Relations de cardinalité plusieurs-à-plusieurs
4. Liens entre les groupes sources

Contenu connexe

Pour plus d’informations sur cet article, consultez les ressources suivantes :

• Comprendre le schéma en étoile et son importance pour Power BI
• Conseils de relation un-à-un
• Conseils sur les relations multiples
• Conseils relatifs aux relations actives et inactives
• Guidage sur les relations bidirectionnelles
• Conseils de résolution des problèmes de relation
• Vidéo : The Do’s and Don’ts of Power BI Relations
• Vous avez des questions ? Essayez d’interroger la communauté Power BI
• Vous avez des suggestions ? Contribuer aux idées pour améliorer Power BI