Relations de modèle dans Power BI Desktop

Cet article s’adresse principalement aux modélisateurs de données d’importation qui utilisent Power BI Desktop. Il s’agit d’une rubrique essentielle pour qui souhaite concevoir des modèles intuitifs, précis et optimisés.

Pour en savoir plus sur la conception de modèles optimisés, notamment sur les relations et les rôles de table, consultez Découvrez le schéma en étoile et son importance pour Power BI.

Finalité des relations

Une relation de modèle propage des filtres appliqués à la colonne d’une table de modèle à une autre table de modèle. La propagation des filtres se poursuit tant qu’il y a un chemin de relation à suivre et peut viser 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. Cependant, les relations peuvent être désactivées ou le contexte de filtre peut être modifié par les calculs de modèle qui utilisent des fonctions DAX particulières. Pour plus d’informations, consultez la rubrique Fonctions DAX à prendre en considération 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 rubrique Évaluation des relations plus loin dans cet article, qui explique comment les relations de modèle se comportent lorsque vos données présentent des problèmes d’intégrité.

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

Dans cet exemple, le modèle se compose de quatre tables : Category, Product, Year et Sales. La table Category est associée à la table Product, et la table Product est associée à la table Sales. La table Year est également associée à la table Sales. Toutes les relations sont de type un-à-plusieurs (vous trouverez des détails à ce sujet 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 passées pour une même catégorie, Cat-A, et une même année, 2018. C’est pourquoi des filtres sont appliqués au niveau des tables Catégorie et Année. Le filtre au niveau de la table Category se propage à la table Product pour isoler deux produits relevant de la catégorie Cat-A. Les filtres de la table Product sont ensuite propagés à la table Sales pour isoler seulement deux lignes de ventes de ces produits. Ces deux lignes de ventes représentent les ventes de produits relevant de la catégorie Cat-A. Leur quantité totale est de 14 unités. Dans le même temps, le filtre de la table Year est propagé pour filtrer un peu plus la table Sales, ce qui donne une seule ligne de vente pour les produits relevant de la catégorie Cat-A et qui ont été commandés au cours de l’année CY2018. La quantité retournée par la requête est de 11 unités. Il est à noter que lorsque plusieurs filtres sont appliqués à une table (comme la table Sales de cet exemple), il s’agit toujours d’une opération AND, qui exige que toutes les conditions soient remplies.

Appliquer les principes de conception des schémas en étoile

Nous vous recommandons d’appliquer les principes de conception des schémas en étoile pour produire un modèle comprenant des tables de dimension et de faits. Il est courant de configurer Power BI pour appliquer des règles qui filtrent les tables de dimensions, 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 d’Adventure Works. Elle présente 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 permet l’analyse des mesures de vente par date, état, région et produit. Notez que les relations du modèle connectent toutes les tables. Ces relations propagent les 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. Dans une conception de modèle valide, une telle table est décrite comme étant 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 la valeur d’entrée de manière significative. Prenons l’exemple d’une table déconnectée qui est chargée avec une plage de valeurs de taux de change. Tant qu’un filtre est appliqué pour filtrer en fonction d’une valeur de taux unique, une expression de mesure peut utiliser cette valeur pour convertir des valeurs de ventes.

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 relation

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

Notes

Il n’est pas possible d’associer une colonne à une autre colonne d’une même table. Ce concept est parfois confondu avec la possibilité de définir une contrainte de clé étrangère de base de données relationnelle qui est une table faisant référence à elle-même. Vous pouvez utiliser ce concept de base de données relationnelle pour stocker des relations parent-enfant (par exemple, chaque enregistrement d’employé est associé à un employé auquel il rend compte). Toutefois, vous ne pouvez pas utiliser de relations de modèle pour générer une hiérarchie de modèles basée sur ce type de relation. Pour créer une hiérarchie parent-enfant, consultez Fonctions parent et enfant.

Types de données de colonnes

Le type de données de la colonne « from » et « to » de la relation doit être le même. L’utilisation de 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 par-dessus. Tous les objets dépendants du modèle apparaissent toujours en tant que DateHeure dans le moteur (par exemple, les relations, les groupes, etc.). Ainsi, si un utilisateur sélectionne Date dans l’onglet Modélisation pour ces colonnes, elles ne sont toujours pas enregistrées comme étant la même date, car la partie heure des données est toujours prise en compte par le moteur. En savoir plus sur la façon dont les types Date/heure sont gérés. Pour corriger ce comportement, les types de données des colonnes doivent être mis à jour dans l’Éditeur Power Query pour supprimer la partie Heure des données importées, de sorte que les valeurs apparaissent identiques lorsque le moteur traite les données.

Cardinalité

Chaque relation de modèle est définie avec un type de cardinalité. Il existe quatre types de cardinalité différents qui représentent les caractéristiques des données des colonnes de départ et d’arrivée. 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.

Notes

Si une opération d’actualisation de données tente de charger des valeurs en double dans une colonne du côté « un », l’actualisation des données échoue entièrement.

Les quatre types (et leurs notations raccourcies) sont décrits dans la liste à puces suivante :

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

Quand 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 de façon à identifier les colonnes contenant des valeurs uniques. Pour les modèles Importer, il utilise des statistiques de stockage internes ; pour les modèles DirectQuery, il envoie des requêtes de profilage à la source de données. Parfois, cependant, Power BI Desktop peut se tromper. Ce peut être le cas quand des tables doivent encore être chargées de données, ou parce que des colonnes censées contenir des valeurs en double contiennent en fait des valeurs uniques. Dans les deux cas, vous pouvez mettre à jour le type de cardinalité tant que des colonnes du côté « un » contiennent des valeurs uniques (ou que des lignes de données doivent encore être chargées dans la table).

Cardinalité un à plusieurs (et plusieurs à un)

Les types de cardinalité Un-à-plusieurs et Plusieurs-à-un sont pour ainsi dire identiques, et ce sont aussi les plus courants.

Au moment de configurer une relation un à plusieurs ou plusieurs à un, vous devez choisir celle qui correspond à l’ordre dans lequel vous avez associé les colonnes. Réfléchissez à la façon dont vous configureriez la relation entre la table Product et la table Sales à partir de la colonne ProductID commune à chaque table. Le type de cardinalité serait Un-à-plusieurs, car la colonne ProductID de la table Product contient des valeurs uniques. Si les tables étaient associées dans le sens inverse, de Sales à Product, la cardinalité serait Plusieurs-à-un.

Cardinalité un à un

Une relation un à un indique que les deux colonnes contiennent des valeurs uniques. Ce type de cardinalité n’est pas courant et ne correspond sûrement pas à une conception de modèle optimale du fait du stockage de données redondantes.

Pour plus d’informations sur l’utilisation de ce type de cardinalité, consultez Aide sur les relations un-à-un.

Cardinalité plusieurs à plusieurs

Une relation plusieurs à plusieurs signifie que les deux colonnes peuvent contenir des valeurs en double. Ce type de cardinalité n’est pas souvent employé. Il est généralement utile pour concevoir des modèles complexes. Vous pouvez l’utiliser pour associer des faits plusieurs à plusieurs ou associer des faits de grain supérieur. Par exemple, lorsque les faits relatifs aux objectifs de ventes sont stockés au niveau de la catégorie de produit et que la table de dimensions de produit est stockée au niveau du produit.

Pour obtenir des conseils sur l’utilisation de ce type de cardinalité, lisez les conseils au sujet des relations Plusieurs-à-plusieurs.

Remarque

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

Conseil

Dans la vue de modèle Power BI Desktop, vous pouvez interpréter le type de cardinalité d’une relation en fonction des indicateurs (1 ou *) présents de chaque côté de la ligne de la relation. Pour identifier les colonnes qui sont associées, sélectionnez ou placez le curseur sur la ligne de la relation de façon à mettre les colonnes en évidence.

Direction du filtrage croisé

Chaque relation de modèle doit être définie avec une direction de filtre croisé. Votre sélection détermine la ou les directions dans lesquelles les filtres vont se propager. Les options de filtrage croisé possibles dépendent du type de cardinalité.

Type de cardinalité	Options de filtrage croisé
Un-à-plusieurs (ou Plusieurs-à-un)	Unique Les deux
Un-à-un	Les deux
Plusieurs-à-plusieurs	Unique (Table1 à Table2) Unique (Table2 à Table1) Les deux

La direction de filtrage croisé Unique indique « une seule direction », tandis que Les deux indique « deux directions ». Une relation qui filtre dans les deux directions est généralement dite bidirectionnelle.

Pour les relations un à plusieurs, la direction de filtre croisé est toujours du côté « un » et éventuellement du côté « plusieurs » (bidirectionnelle). Pour les relations un à un, la direction de filtre croisé part toujours des deux tables. Enfin, pour les relations plusieurs à plusieurs, la direction de filtre croisé peut démarrer de l’une ou l’autre des tables, ou des deux. Notez que lorsque le type de cardinalité comporte un côté « un », les filtres se propagent toujours de ce côté-là.

Lorsque la direction de filtre croisé est définie sur Les deux, une propriété supplémentaire devient disponible. Elle 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 RLS, consultez Sécurité au niveau des lignes (RLS) avec Power BI Desktop.

Vous pouvez modifier une direction de filtre croisé de relation, y compris la désactivation de la propagation de filtre, à l’aide d’un calcul de modèle. Pour ce faire, il convient d’utiliser la fonction DAX CROSSFILTER.

Gardez à l’esprit que les relations bidirectionnelles peuvent avoir un impact négatif sur les performances. De plus, toute tentative de configuration d’une relation bidirectionnelle peut engendrer des chemins de propagation de filtre ambigus. Dans ce cas, il se peut que Power BI Desktop ne puisse pas valider la modification de la relation et vous alerte avec un message d’erreur. Pourtant, il peut parfois arriver que Power BI Desktop vous autorise à définir des chemins de relation ambigus entre des tables. La résolution de l’ambiguïté du chemin de relation est décrite plus loin dans cet article.

L’utilisation du filtrage bidirectionnel n’est recommandée qu’en cas de nécessité. Pour plus d’informations, consultez Guide des relations bidirectionnelles.

Conseil

Dans la vue de modèle Power BI Desktop, vous pouvez interpréter la direction du filtrage croisé d’une relation à partir des flèches située le long de la ligne de la relation. La présence d’une flèche simple indique un filtre à direction unique dans le sens de la flèche ; une flèche double indique une relation bidirectionnelle.

Rendre cette relation active

Seul un chemin de propagation de filtre peut être actif entre deux tables de modèle. Il est possible d’introduire des chemins de relation supplémentaires, mais vous devez définir ces relations comme inactives. Les relations inactives ne peuvent être rendues actives qu’à l’occasion de l’évaluation du calcul d’un modèle. Pour ce faire, il convient d’utiliser la fonction DAX USERELATIONSHIP.

Généralement, nous vous recommandons de définir des relations actives chaque fois que cela est 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 actives signifie que les tables de dimensions de rôle actif doivent être dupliquées dans votre modèle.

Dans certains cas, toutefois, vous pouvez définir une ou plusieurs relations inactives pour une table de dimensions de rôle actif. Vous pouvez envisager cette conception dans les cas suivants :

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

Pour plus d’informations, consultez Guide des relations actives et inactives.

Conseil

Dans la vue de modèle Power BI Desktop, vous pouvez interpréter l’état actif ou inactif d’une relation. Une relation active est représentée par une ligne pleine ; une relation inactive est représentée par une ligne en pointillés.

Supposer une intégrité référentielle

La propriété Intégrité référentielle supposée est disponible uniquement pour les relations un à plusieurs et un à un entre deux tables de modes de stockage DirectQuery appartenant au même source source. Vous ne pouvez activer cette propriété que lorsque la colonne côté « plusieurs » ne contient pas de valeurs NULL.

Quand elle est activée, les requêtes natives envoyées à la source de données joignent les deux tables en utilisant une INNER JOIN plutôt qu’une OUTER JOIN. En règle générale, l’activation de cette propriété a pour effet d’améliorer les performances des requêtes, même si celles-ci dépendent des spécificités de la source de données.

Activez toujours cette propriété quand il y a une contrainte de clé étrangère de base de données entre les deux tables. Même quand il n’existe pas de contrainte de clé étrangère, 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 vient à être compromise, la jointure interne éliminera les lignes sans correspondance entre les tables. Par exemple, imaginez une table de modèle Sales avec une valeur de colonne ProductID qui n’existe pas dans la table Product associée. la propagation de filtre de la table Product vers la table Sales élimine les lignes de ventes de produits inconnus et les résultats de ventes s’en trouvent sous-estimés.

Pour plus d’informations, consultez Paramètres Intégrité référentielle supposée dans Power BI Desktop.

Fonctions DAX à prendre en considération

Plusieurs fonctions DAX présentent un intérêt pour les relations de modèle. Chaque fonction est décrite brièvement dans la liste à puces suivante :

• RELATED : Récupère la valeur du côté « un » d’une relation. Elle est utile lors de l’implication de calculs à partir de différentes tables évaluées dans le contexte de ligne.
• RELATEDTABLE : Récupère 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 qui aide à influencer son utilisation.) C’est utile quand votre modèle comprend une table de dimension qui remplit un 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é des chemins de filtre.
• CROSSFILTER : modifie la direction du filtrage croisé de la relation (à une ou les deux) ou désactive la propagation de filtre (aucune). Elle 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 en une seule. L’objectif de cette fonction est de prendre en charge les relations à plusieurs colonnes dans des modèles DirectQuery quand des tables appartiennent au même groupe source.
• TREATAS : applique le résultat d’une expression de table comme filtres aux colonnes d’une table non associée. Elle est utile dans des scénarios avancés lorsque vous souhaitez créer une relation virtuelle lors de l’évaluation d’un calcul spécifique.
• Fonctions parent et enfant : famille de fonctions associées qui permettent de générer des colonnes calculées pour établir une hiérarchie parent-enfant. Vous pouvez ensuite utiliser ces colonnes pour créer une hiérarchie de niveau fixe.

Évaluation des relations

Du point de vue de l’évaluation, les relations de modèle peuvent être considérées comme régulières ou limitées. Il ne s’agit pas d’une propriété de relation configurable. De fait, elle est déduite 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 cela peut avoir des implications en termes de performances ou des conséquences en cas de compromission de l’intégrité des données. Ces implications et les conséquences de l’intégrité sont décrites dans cette rubrique.

Tout d’abord, une théorie de modélisation est nécessaire pour comprendre parfaitement les évaluations des relations.

Un modèle Importer ou DirectQuery obtient toutes ses données du cache Vertipaq ou de la base de données source. Dans les deux cas, Power BI peut déterminer qu’il existe un côté « un » dans une relation.

En revanche, un modèle Composite peut comprendre des tables qui utilisent différents modes de stockage (Importer, DirectQuery ou Double) ou plusieurs sources DirectQuery. Chaque source, dont le cache Vertipaq de données importées, est considérée comme étant un groupe source. Les relations de modèle peuvent ensuite être classifiées en tant que groupe intrasource ou groupe intersource. Une relation de groupe intrasource lie deux tables au sein d’un même groupe source, tandis qu’une relation de groupe intersource lie des tables dans deux groupes sources. Notez que les relations dans les modèles Importer ou DirectQuery sont toujours de type groupe intrasource.

Voici un exemple d’un tableau 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, tandis que le groupe source DirectQuery en contient deux. Il existe une relation de groupe intersource pour associer une table du groupe source Vertipaq à une table du groupe source DirectQuery.

Relations régulières

Une relation de modèle est dite régulière quand le moteur de requête peut déterminer le côté « un » d’une relation. Il a la confirmation que la colonne du côté « un » contient des valeurs uniques. Toutes les relations de groupe intrasource de type un à plusieurs sont des relations régulières.

Dans l’exemple suivant, il existe deux relations régulières, toutes deux représentées par la lettre R. Les relations englobent la relation Un-à-plusieurs contenue dans le groupe source Vertipaq et la relation Un-à-plusieurs contenue dans la source DirectQuery.

Pour les modèles Importer, 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 où les données sont actualisé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 des tables au moment de la requête.

Au moment de la requête, les relations régulières autorisent une extension de table. L’extension de table entraîne la création d’une table virtuelle en incluant les colonnes natives de la table de base, puis en les développant dans les tables associées. Pour les tables d’importation, une expansion de table s’effectue dans le moteur de requête. Dans le cas des tables DirectQuery, cette opération s’effectue dans la requête native envoyée à la base de données source (tant que la propriété Intégrité référentielle supposée n’est pas activée). Le moteur de requête agit ensuite sur la table étendue, en appliquant les filtres et en effectuant un regroupement en fonction des valeurs contenues dans les colonnes de la table étendue.

Notes

Les relations inactives sont aussi étendues, même quand la relation n’est pas utilisée par un calcul. Les relations bidirectionnelles n’ont aucun impact sur l’extension de table.

Pour les relations un à plusieurs, l’extension de table se produit du côté « plusieurs » vers le côté « un » en utilisant la sémantique LEFT OUTER JOIN. Quand il n’existe pas de correspondance de valeur entre le côté « plusieurs » et le côté « un », une ligne virtuelle vide est ajoutée à la table du côté « un ». Ce comportement s’applique uniquement aux relations régulières, non aux relations limitées.

Si l’extension de table concerne aussi les relations intrasources un à un, elle utilise la sémantique FULL OUTER JOIN. Ce type de jointure garantit que des lignes virtuelles vides sont ajoutées de chaque côté, si nécessaire.

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

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

Dans cet exemple, le modèle se compose de trois tables : Category, Product et Sales. La table Category est liée à la table Product par une relation Un-à-plusieurs, et la table Product est liée à la table Sales par une relation Un-à-plusieurs. La table Category contient deux lignes, la table Product en contient trois et la table Sales en contient cinq. Il existe des correspondances de valeurs des deux côtés des relations, ce qui signifie qu’il n’existe pas de violations d’intégrité référentielle. Une table étendue s’affiche au moment de la requête. La table est constituée des colonnes des trois tables. Il s’agit en fait d’une perspective dénormalisée des données contenues dans les trois tables. Une nouvelle ligne est ajoutée à la table Sales et sa valeur d’identificateur de production (9) n’a pas de correspondance dans la table Product. Il s’agit d’une violation d’intégrité référentielle. Dans la table étendue, la nouvelle ligne contient des valeurs (vides) pour les colonnes des tables Category et Product.

Relations limitées

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

• La relation utilise un type de cardinalité plusieurs à plusieurs (même si une colonne ou les deux contiennent des valeurs uniques)
• La relation est de type groupe intersource (ce qui ne peut être le cas que des modèles composites).

Dans l’exemple suivant, il existe deux relations limitées, toutes deux représentées par la lettre L. Les deux relations incluent la relation plusieurs à plusieurs contenue dans le groupe source Vertipaq et la relation de groupe intersource un à plusieurs.

Pour les modèles Importer, des 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.

Les relations limitées ne font jamais l’objet d’une extension de table. Les jointures de tables sont effectuées en utilisant la sémantique INNER JOIN. C’est pour cette raison qu’il n’y a pas d’ajout de lignes virtuelles vides pour compenser des 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 colonne du côté « un ».
• L’application de la sécurité au niveau des lignes est soumise à des restrictions de topologie.

Conseil

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 de type parenthèse ( ) 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 entre les tables de modèle (et donc des ambiguïtés). Pendant l’évaluation de l’ambiguïté, Power BI choisit le chemin de propagation de filtre en fonction de sa priorité et de son poids.

Priorité

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 correspondance de règle détermine le chemin suivi par Power BI. Chaque règle ci-dessous décrit comment les filtres circulent d’une table source vers une table cible.

1. Un chemin composé de relations un-à-plusieurs.
2. Un chemin composé de relations un-à-plusieurs ou plusieurs-à-plusieurs.
3. Un chemin composé de relations plusieurs-à-un.
4. Un chemin composé de relations un-à-plusieurs de la table source vers une table intermédiaire, suivie de relations plusieurs-à-un de la table intermédiaire vers la table cible.
5. Un chemin 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.

Quand une relation est ajoutée à tous les chemins disponibles, elle n’est prise en compte dans aucun chemin.

Poids

Chaque relation dans un chemin a un poids. Par défaut, chaque poids de relation est égal, sauf si la fonction USERELATIONSHIP est utilisée. Le poids du chemin est le maximum de tous les poids de relation le long du chemin. Power BI utilise les poids de chemin pour résoudre l’ambiguïté entre plusieurs chemins de même niveau de priorité. Il ne choisit pas de chemin avec une priorité inférieure, mais le chemin avec le poids le plus élevé. Le nombre de relations dans le chemin n’affecte pas le poids.

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

Considérez l'exemple suivant. La mesure Product Sales attribue 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])
)

Notes

Si Power BI détecte plusieurs chemins qui ont 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 poids de relation avec la fonction USERELATIONSHIP, ou en supprimant ou modifiant les relations du modèle.

Préférences en matière de performances

La liste suivante classe les performances de propagation de filtre, des plus rapides aux plus lentes :

1. Relations de groupe intrasource Un à plusieurs
2. Relations de modèle plusieurs à plusieurs avec une table intermédiaire et impliquant au moins une relation bidirectionnelle
3. Relations de cardinalité Plusieurs-à-plusieurs
4. Relations de groupe intersource

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
• Aide pour la relation un-à-un
• Conseils sur les relations Plusieurs-à-plusieurs
• Aide pour les relations actives et inactives
• Aide pour les relations bidirectionnelles
• Aide à la résolution des problèmes de relations
• Vidéo : Les comportements appropriés et déconseillés concernant les relations Power BI
• Vous avez des questions ? Essayez d’interroger la communauté Power BI
• Vous avez des suggestions ? Envoyez-nous vos idées pour améliorer Power BI