Créer et gérer des relations dans Power BI Desktop
Quand vous avec plusieurs tables, vous êtes souvent amené à effectuer des analyses avec des données de toutes ces tables. Les relations entre ces tables sont nécessaires pour obtenir des résultats précis et afficher les informations correctes dans vos rapports. Dans la plupart des cas, vous n’avez rien à faire. La fonctionnalité de détection automatique s’en charge pour vous. Vous pouvez cependant parfois être amené à créer des relations vous-même ou à apporter des modifications à une relation. Dans les deux cas, il est important de comprendre le fonctionnement des relations dans Power BI Desktop et comment les créer et les modifier.
Détection automatique pendant le chargement
Si vous interrogez plusieurs tables en même temps, quand les données sont chargées, Power BI Desktop tente de trouver et de créer des relations pour vous. Les options de relation Cardinalité, Direction du filtrage croisé et Rendre cette relation active sont définies automatiquement. Power BI Desktop examine les noms des colonnes des tables que vous interrogez pour déterminer s’il existe des relations potentielles. S’il en existe, ces relations sont automatiquement créées. Si Power BI Desktop ne peut pas déterminer avec un niveau de confiance élevé qu’il existe une correspondance, il ne crée pas la relation. Vous pouvez néanmoins utiliser la boîte de dialogue Gérer les relations pour créer ou modifier manuellement des relations.
Créer une relation avec la fonctionnalité Détection automatique
Sous l’onglet Modélisation, sélectionnez Gérer les relations>Détection automatique.
Créer une relation manuellement
Sous l’onglet Modélisation, sélectionnez Gérer les relations>Nouveau.
Dans la boîte de dialogue Créer une relation, dans la première liste déroulante des tables, sélectionnez une table. Sélectionnez la colonne que vous voulez utiliser dans la relation.
Dans la deuxième liste déroulante des tables, sélectionnez l’autre table que vous voulez dans la relation. Sélectionnez l’autre colonne que vous voulez utiliser, puis OK.
Par défaut, Power BI Desktop configure automatiquement les options Cardinalité (direction), Direction du filtrage croisé et Rendre cette relation active pour votre nouvelle relation. Vous pouvez cependant modifier ces paramètres si nécessaire. Pour plus d’informations, consultez Présentation des options supplémentaires.
Si aucune des tables sélectionnées pour la relation n’a des valeurs uniques, vous voyez l’erreur suivante : Une des colonnes doit avoir des valeurs uniques. Au moins une table dans une relation doit avoir une liste distincte et unique de valeurs de clés. C’est une exigence commune à toutes les technologies de base de données relationnelle.
Si vous rencontrez cette erreur, vous pouvez la résoudre de différentes manières :
- Utilisez Supprimer les doublons pour créer une colonne avec des valeurs uniques. L’inconvénient de cette approche est que vous pourriez perdre des informations lors de la suppression de lignes en double. Souvent, une clé (ligne) est dupliquée pour une bonne raison.
- Ajoutez une table intermédiaire composée de la liste des valeurs de clés distinctes dans le modèle, qui sera ensuite liée aux deux colonnes d’origine de la relation.
Pour plus d’informations, voir ce billet de blog.
Autrement, dans les dispositions de diagramme dans la vue Modèle, vous pouvez glisser et déposer une colonne d’une table vers une colonne dans une autre table pour créer une relation.
Modifier une relation
Il existe deux façons de modifier une relation dans Power BI.
La première méthode pour modifier une relation consiste à utiliser l’option Modifier les relations dans le volet Propriétés dans la vue Modèle, où vous pouvez sélectionner une ligne quelconque entre deux tables pour afficher les options de relation dans le volet Propriétés. Veillez à développer le volet Propriétés pour afficher les options de relation.
Vous pouvez également voir une démonstration vidéo des relations d’édition dans le volet Propriétés.
L’autre méthode de modification d’une relation consiste à utiliser la boîte de dialogue Éditeur de relation, que vous pouvez ouvrir de nombreuses façons à partir de Power BI Desktop. La liste suivante présente différentes façons d’ouvrir la boîte de dialogue Éditeur de relation :
Dans la vue Rapport, effectuez l’une des opérations suivantes :
- Sélectionnez le ruban Modélisation>Gérer les relations, sélectionnez la relation, puis sélectionnez Modifier.
- Sélectionnez une table dans la liste Champs, sélectionnez le ruban Outils de table>Gérer les relations, sélectionnez la relation, puis choisissez Modifier.
Dans la vue Données, sélectionnez le ruban Outils de table>Gérer les relations, sélectionnez la relation, puis choisissez Modifier.
Dans la vue Modèle, effectuez l’une des opérations suivantes :
- Sélectionnez le ruban Accueil>Gérer les relations, sélectionnez la relation, puis choisissez Modifier.
- Double-cliquez sur une ligne entre deux tables.
- Cliquez avec le bouton droit sur une ligne entre deux tables, puis choisissez Propriétés.
- Sélectionnez une ligne entre deux tables, puis choisissez Ouvrir l’Éditeur de relation dans le volet Propriétés.
Enfin, vous pouvez également modifier une relation à partir de n’importe quel affichage, cliquer avec le bouton droit ou sélectionner les points de suspension pour accéder au menu contextuel d’une table, puis sélectionner Gérer les relations, sélectionner la relation, puis choisir Modifier.
L’image suivante montre une capture d’écran de la fenêtre Modifier la relation.
Modification des relations à l’aide de différentes méthodes
L’utilisation de la boîte de dialogue Modifier les relations est une expérience plus guidée pour la modification des relations dans Power BI, actuellement en préversion. Vous pouvez voir un aperçu des données de chaque table. Lorsque vous sélectionnez différentes colonnes, la fenêtre valide automatiquement la relation et offre des sélections de cardinalité et de filtre croisé appropriées.
La modification des relations dans le volet Propriétés est une approche simplifiée de la modification des relations dans Power BI. Vous voyez uniquement les noms de table et les colonnes à partir desquelles vous pouvez choisir, vous ne voyez pas d’aperçu des données, et les choix de relation que vous effectuez ne sont validés que lorsque vous sélectionnez Appliquer les modifications. L’utilisation du volet Propriétés et de son approche simplifiée réduit le nombre de requêtes générées lors de la modification d’une relation, ce qui peut être important pour des scénarios de Big Data, en particulier lors de l’utilisation de connexions DirectQuery. Les relations créées à l’aide du volet Propriétés peuvent également être plus avancées que les relations dont la création est autorisée dans la boîte de dialogue Modifier les relations.
Vous pouvez également sélectionner plusieurs relations dans les dispositions de diagramme de la vue modèle en appuyant sur la touche Ctrl et en sélectionnant plusieurs lignes pour choisir plusieurs relations. Les propriétés courantes peuvent être modifiées dans le volet Propriétés et l’option Appliquer les modifications traite les modifications en une seule transaction.
Des relations uniques ou multiples peuvent également être supprimées en appuyant sur la touche Supprimer du clavier. Comme vous ne pouvez pas annuler l’action de suppression, une boîte de dialogue vous invite à confirmer la suppression des relations.
Important
La modification de relations dans la fonctionnalité du volet Propriétés est actuellement en préversion. Pendant la période de préversion, les fonctionnalités et la documentation sont susceptibles de changer. Vous devez activer cette fonctionnalité dans Power BI Desktop en accédant à Fichier > Options et paramètres > Options > Fonctionnalités en préversion, puis, dans la section GLOBAL, activez la case à cocher en regard du volet Relation.
Configurer d’autres options
Quand vous créez ou modifiez une relation, vous pouvez configurer d’autres options. Par défaut, Power BI Desktop configure automatiquement d’autres options en fonction de sa meilleure estimation, qui peut être différente pour chaque relation en fonction des données contenues dans les colonnes.
Cardinalité
L’option Cardinalité peut avoir une des valeurs suivantes :
Plusieurs à un (*:1) : Une relation plusieurs-à-un est le type de relation par défaut le plus courant. Elle signifie que la colonne d’une table donnée peut avoir plusieurs instances d’une valeur, tandis que la table liée, souvent appelée table de recherche, n’a qu’une seule instance d’une valeur.
Un à un (1:1) : Dans une relation un-à-un, la colonne d’une table n’a qu’une seule instance d’une valeur particulière et la table liée n’a qu’une seule instance d’une valeur donnée.
Un à plusieurs (1:*) : Dans une relation un-à-plusieurs, la colonne d’une table n’a qu’une seule instance d’une valeur particulière, tandis que la table liée peut avoir plusieurs instances d’une valeur.
Plusieurs à plusieurs (*:*) : Avec les modèles composites, vous pouvez établir des relations plusieurs-à-plusieurs entre des tables, ce qui élimine la nécessité d’avoir des valeurs uniques dans les tables. Les solutions de contournement précédentes, comme la présentation de nouvelles tables uniquement pour établir des relations, sont également supprimées. Pour plus d’informations, consultez Relations avec une cardinalité plusieurs-à-plusieurs.
Pour plus d’informations sur le changement de cardinalité, consultez Présentation des options supplémentaires.
Direction du filtrage croisé
L’option Direction du filtrage croisé peut avoir une des valeurs suivantes :
Les deux : Pour le filtrage, les deux tables sont traitées comme s’il s’agissait d’une même table. La valeur Les deux fonctionne bien avec une seule table qui a autour d’elle plusieurs tables de recherche. Un exemple est une table des ventes effectuées avec une table de recherche pour son département. Cette configuration est souvent appelée « configuration de schéma en étoile » (une table centrale avec plusieurs tables de recherche). Cependant, si vous avez deux tables ou plus qui ont aussi des tables de recherche (certaines en commun), vous n’allez pas utiliser la valeur Les deux. Pour continuer avec l’exemple précédent, vous avez également une table de ventes budgétées qui enregistre le budget cible pour chaque service. Et la table des services est connectée à la fois à la table des ventes et à la table du budget. Évitez le paramètre Les deux pour ce type de configuration.
À sens unique : Il s’agit de la direction par défaut la plus courante, qui signifie que les choix de filtrage dans les tables connectées agissent sur la table où les valeurs sont agrégées. Si vous importez un modèle de données Power Pivot dans Excel 2013 ou version antérieure, toutes les relations ont une seule direction.
Pour plus d’informations sur la modification de la direction du filtrage croisé, consultez Présentation des options supplémentaires.
Rendre cette relation active
Quand cette option est cochée, la relation fait office de relation par défaut active. S’il existe plusieurs relations entre deux tables, la relation active offre un moyen à Power BI Desktop de créer automatiquement des visualisations qui incluent les deux tables.
Pour plus d’informations sur le moment où il faut rendre active une relation particulière, consultez Présentation des options supplémentaires.
Présentation des relations
Une fois que vous avez relié deux tables par une relation, vous pouvez utiliser les données des deux tables comme s’il s’agissait d’une seule. Vous n’avez alors plus à vous soucier des détails de la relation ou de l’aplatissement de ces tables en une seule avant de les importer. Dans de nombreux cas, Power BI Desktop peut créer automatiquement des relations pour vous. Cependant, si Power BI Desktop ne peut pas déterminer avec un fort degré de certitude qu’une relation entre deux tables doit exister, il ne crée pas la relation automatiquement. Dans ce cas, vous devez le faire.
Nous allons suivre un rapide didacticiel pour mieux illustrer le fonctionnement des relations dans Power BI Desktop.
Conseil
Vous pouvez effectuer cette leçon vous-même :
- Copiez la table ProjectHours (Heures projet) suivante dans une feuille de calcul Excel (à l’exclusion du titre), sélectionnez toutes les cellules, puis sélectionnez Insérer>Tableau.
- Dans la boîte de dialogue Créer un tableau, sélectionnez OK.
- Sélectionnez une cellule du tableau, sélectionnez Création du tableau>Nom du tableau, puis entrez ProjectHours.
- Faites de même pour le tableau CompanyProject (Projet entreprise).
- Importez les données avec l’option Obtenir des données dans Power BI Desktop. Sélectionnez les deux tables comme source de données, puis sélectionnez Charger.
La première table, ProjectHours, contient les tickets de travail qui enregistrent le nombre d’heures qu’une personne a travaillé sur un projet particulier.
HeuresProjet
| Ticket | SoumisPar | Heures | Projet | DateSoumission |
|---|---|---|---|---|
| 1001 | Brewer, Alan | 22 | Blue | 1/1/2013 |
| 1002 | Brewer, Alan | 26 | Red | 2/1/2013 |
| 1003 | Ito, Shu | 34 | Yellow | 12/4/2012 |
| 1004 | Brewer, Alan | 13 | Orange | 1/2/2012 |
| 1005 | Bowen, Eli | 29 | Violet | 1/10/2013 |
| 1006 | Bento, Nuno | 35 | Green | 2/1/2013 |
| 1007 | Hamilton, David | 10 | Yellow | 1/10/2013 |
| 1008 | Han, Mu | 28 | Orange | 1/2/2012 |
| 1009 | Ito, Shu | 22 | Purple | 2/1/2013 |
| 1010 | Bowen, Eli | 28 | Green | 10/1/2013 |
| 1010 | Bowen, Eli | 9 | Blue | 10/15/2013 |
La seconde table, CompanyProject, est une liste de projets affectés d’une priorité : A, B ou C.
ProjetEntreprise
| NomProjet | Priorité |
|---|---|
| Blue | A |
| Rouge | B |
| Green | C |
| Jaune | C |
| Purple | B |
| Orange | C |
Notez que chaque table possède une colonne de projet. Chacune a un nom légèrement différent, mais les valeurs semblent identiques. Cette différence est importante, et nous y reviendrons bientôt.
Nos deux tables étant importées dans un modèle, nous allons maintenant créer un rapport. La première chose que nous voulons obtenir est le nombre d’heures soumises par priorité de projet ; nous sélectionnons donc les champs Priority (Priorité), Hours (Heures) et Fields (Secteurs).
Si nous regardons notre table dans le canevas de rapport, nous constatons que le nombre d’heures est de 256 pour chaque projet et que c’est également le total. Ce nombre est clairement incorrect. Pourquoi ? La raison en est que nous ne pouvons pas calculer une somme de valeurs à partir d’une table (Hours (Heures) dans la table Project), ventilées selon les valeurs d’une autre table (Priority (Priorité) dans la table CompanyProject) sans une relation entre ces deux tables.
Nous allons donc créer une relation entre ces deux tables.
Vous vous souvenez de ces colonnes communes aux deux tables avec un nom de projet et comportant des valeurs similaires ? Nous allons utiliser ces deux colonnes pour créer une relation entre nos tables.
Pourquoi ces colonnes ? Si nous regardons la colonne Project (Projet) de la table ProjectHours, nous y voyons des valeurs comme Blue (Bleu), Red (Rouge), Yellow (Jaune), Orange, etc. Comme vous pouvez le constater, plusieurs lignes contiennent la même valeur. Nous avons donc de nombreuses valeurs de couleur pour Project.
Si nous regardons la colonne ProjName de la table CompanyProject, nous voyons qu’elle ne contient qu’une seule occurrence de chacune des valeurs de couleur pour le nom du projet. Chaque valeur de couleur de cette table est unique ; cela est important, car nous pouvons créer une relation entre les deux tables. Dans ce cas, il s’agit d’une relation plusieurs-à-un. Dans une relation plusieurs-à-un, au moins une colonne d’une des tables doit contenir des valeurs uniques. D’autres options existent pour certaines relations, que nous examinerons ultérieurement. Pour le moment, nous allons créer une relation entre les colonnes du projet dans chacune de nos deux tables.
Pour créer la relation
Sous l’onglet Modélisation, sélectionnez Gérer les relations.
Dans Gérer les relations, cliquez sur Nouveau pour ouvrir la boîte de dialogue Créer une relation, où nous pouvons sélectionner les tables, les colonnes et autres paramètres que nous souhaitons pour notre relation.
Dans la première liste déroulante, sélectionnez ProjectHours comme première table, puis la colonne Project. Il s’agit du côté plusieurs de notre relation.
Dans la deuxième liste déroulante, CompanyProject est présélectionné comme deuxième table. Sélectionnez la colonne ProjName (Nom du projet). Il s’agit du côté un de notre relation.
Acceptez les valeurs par défaut pour les autres paramètres, puis sélectionnez OK.
Dans la boîte de dialogue Gérer les relations, sélectionnez Fermer.
Pour que la démonstration soit le plus explicite, nous avons créé la relation manuellement. Vous auriez pu sélectionner Détection automatique dans la boîte de dialogue Gérer les relations. En fait, la fonctionnalité Détection automatique aurait créé automatiquement la relation pour vous quand vous avez chargé les données si les deux colonnes avaient le même nom.
À présent, réexaminons la table dans notre canevas de rapport.
Ça va beaucoup mieux maintenant, non ?
Quand nous additionnons les heures par Priority (Priorité), Power BI Desktop recherche chaque instance des valeurs de couleur uniques dans la table de recherche CompanyProject, recherche chaque instance de chacune de ces valeurs dans la table ProjectHours, puis calcule une somme totale pour chaque valeur unique.
La fonctionnalité Détection automatique aurait peut-être pu vous éviter tout ce travail.
Présentation des options supplémentaires
Quand une relation est créée, manuellement ou avec la fonctionnalité Détection automatique, Power BI Desktop configure automatiquement les options supplémentaires en fonction des données de vos tables. Ces options de relation supplémentaires se trouvent dans la partie inférieure des boîtes de dialogue Créer une relation et Modifier une relation.
Power BI définit généralement ces options automatiquement et vous n’aurez pas besoin de les ajuster. Il existe toutefois plusieurs situations dans lesquelles vous pouvez souhaiter configurer vous-même ces options.
Mises à jour automatiques des relations
Vous pouvez gérer la façon dont Power BI traite et ajuste automatiquement les relations dans vos rapports et modèles. Pour spécifier la façon dont Power BI gère les options des relations, sélectionnez Fichier>Options et paramètres>Options dans Power BI Desktop, puis sélectionnez Chargement des données dans le volet gauche. Les options pour Relations apparaissent.
Vous pouvez sélectionner et activer trois options :
Importer des relations à partir de sources de donnée au premier chargement : Cette option est activée par défaut. Quand cette option est sélectionnée, Power BI vérifie les relations définies dans votre source de données, comme les relations de clé étrangère/clé primaire dans votre entrepôt de données. Si ces relations existent, elles sont reflétées dans le modèle de données Power BI quand vous chargez les données pour la première fois. Cette option vous permet de commencer rapidement à travailler avec votre modèle, au lieu de vous demander de trouver ou de définir ces relations vous-même.
Mettre à jour ou supprimer des relations pendant l’actualisation des données : Cette option est désélectionnée par défaut. Si vous le sélectionnez, Power BI recherche les modifications apportées aux relations de la source de données quand votre modèle sémantique est actualisé. Si ces relations ont été modifiées ou supprimées, Power BI reflète ces modifications dans son propre modèle de données, en les mettant à jour ou en les supprimant pour qu’elles correspondent.
Avertissement
Si vous utilisez la sécurité au niveau des lignes qui s’appuie sur les relations définies, nous vous déconseillons de sélectionner cette option. Si vous supprimez une relation sur laquelle s’appuient vos paramètres de sécurité au niveau des lignes (RLS), votre modèle peut devenir moins sécurisé.
Détecter automatiquement les nouvelles relations une fois les données chargées : Cette option est décrite dans Détection automatique pendant le chargement.
Les futures mises à jour des données nécessitent une cardinalité différente
Normalement, Power BI Desktop peut déterminer automatiquement la meilleure cardinalité pour la relation. Si vous avez besoin de remplacer le paramétrage automatique parce que vous savez que les données vont changer dans le futur, vous pouvez le changer avec le contrôle Cardinalité. Examinons un exemple où nous devons sélectionner une cardinalité différente.
La table CompanyProjectPriority (Priorité projet entreprise) est une liste de tous les projets de l’entreprise, avec leur priorité. La table ProjectBudget contient l’ensemble des projets pour lesquels un budget a été approuvé.
PrioritéProjetEntreprise
| NomProjet | Priorité |
|---|---|
| Blue | A |
| Rouge | B |
| Green | C |
| Jaune | C |
| Purple | B |
| Orange | C |
BudgetProjet
| ProjetsApprouvés | AllocationBudget | DateAllocation |
|---|---|---|
| Blue | 40,000 | 12/1/2012 |
| Red | 100,000 | 12/1/2012 |
| Vert | 50,000 | 12/1/2012 |
Si nous créons une relation entre la colonne Approved Projects (Projets approuvés) de la table ProjectBudget et la colonne ProjectName (Nom du projet) de la table CompanyProjectPriority, Power BI définit automatiquement Cardinalité sur Un à un (1:1) et Direction du filtrage croisé sur Les deux.
La raison pour laquelle Power BI définit ces paramètres est que pour Power BI Desktop, la meilleure combinaison des deux tables est la suivante :
| NomProjet | Priorité | AllocationBudget | DateAllocation |
|---|---|---|---|
| Bleu | A | 40,000 | 12/1/2012 |
| Red | B | 100 000 | 12/1/2012 |
| Green | C | 50,000 | 12/1/2012 |
| Yellow | C | ||
| Purple | B | ||
| Orange | C |
Il existe une relation un-à-un entre nos deux tables, car la colonne ProjName (Nom du projet) de la table combinée ne contient pas de valeurs répétées. La colonne ProjName est unique, car chaque valeur n’y apparaît qu’une seule fois ; ainsi, les lignes des deux tables peuvent être combinées directement sans aucune duplication.
Toutefois, supposons que les données sont censées changer à la prochaine actualisation. Une version actualisée de la table ProjectBudget a maintenant des lignes supplémentaires pour les projets Blue (Bleu) et Red (Rouge) :
BudgetProjet
| ProjetsApprouvés | AllocationBudget | DateAllocation |
|---|---|---|
| Blue | 40,000 | 12/1/2012 |
| Red | 100,000 | 12/1/2012 |
| Vert | 50,000 | 12/1/2012 |
| Blue | 80,000 | 6/1/2013 |
| Red | 90,000 | 6/1/2013 |
Ces lignes supplémentaires signifient que la meilleure combinaison des deux tables se présente maintenant comme ceci :
| NomProjet | Priorité | AllocationBudget | DateAllocation |
|---|---|---|---|
| Bleu | A | 40,000 | 12/1/2012 |
| Red | B | 100 000 | 12/1/2012 |
| Green | C | 50,000 | 12/1/2012 |
| Yellow | C | ||
| Purple | B | ||
| Orange | C | ||
| Blue | A | 80000 | 6/1/2013 |
| Red | B | 90000 | 6/1/2013 |
Dans cette nouvelle table combinée, la colonne ProjName a des valeurs répétées. Les deux tables d’origine n’auront pas de relation un à un une fois la table actualisée. Dans ce cas, comme nous savons que ces mises à jour ultérieures vont introduire des doublons dans la colonne ProjName, nous voulons définir la Cardinalité sur Plusieurs à un (*:1), avec le côté plusieurs sur ProjectBudget et le côté un sur CompanyProjectPriority.
Ajustement de la direction du filtrage croisé pour un jeu complexe de tables et de relations
Pour la plupart des relations, la direction du filtrage croisé est définie sur Les deux. Toutefois, dans certaines circonstances rares, vous devrez peut-être définir cette option différemment de sa définition par défaut. Par exemple, si vous importez un modèle à partir d’une ancienne version de Power Pivot, où chaque relation est définie sur une seule direction.
La valeur Les deux permet à Power BI Desktop de traiter tous les aspects des tables connectées comme s’il s’agissait d’une même table. Dans certaines situations cependant, Power BI Desktop ne peut pas définir la direction du filtrage croisé d’une relation sur Les deux tout en conservant un ensemble non ambigu de valeurs par défaut pour la création de rapports. En règle générale, la direction du filtrage croisé d’une relation n’est pas définie sur Les deux si cela risque de créer une ambiguïté. Si la valeur par défaut de la direction du filtrage croisé ne fonctionne pas pour vous, essayez en la définissant sur une table particulière ou sur Les deux.
Le filtrage croisé À sens unique fonctionne dans de nombreuses situations. En fait, si vous importez un modèle de données Power Pivot dans Excel 2013 ou version antérieure, toutes les relations sont définies sur À sens unique. Dans le cas d’une direction à sens unique, les choix de filtrage dans les tables connectées agissent sur la table où se produit l’agrégation. Parfois, le filtrage croisé peut être un peu difficile à comprendre. Nous allons donc étudier un exemple.
Dans le cas du filtrage croisé à sens unique, si vous créez un rapport qui totalise les heures des projets, vous pouvez choisir de totaliser (ou de filtrer) sur la table CompanyProject et sa colonne Priority (Priorité), ou sur la table CompanyEmployee et sa colonne City (Localité). Si toutefois vous souhaitez obtenir le nombre d’employés par projet (ce qui est moins fréquent), cela ne fonctionne pas. Vous obtenez une colonne de valeurs identiques. Dans l’exemple ci-dessous, la direction du filtrage croisé des deux relations est définie sur une direction à sens unique, vers la table ProjectHours. Dans les Valeurs, le champ Project (Projet) est défini sur Count (Total) :
La spécification du filtrage s’étendra de CompanyProject à ProjectHours (comme l’illustre l’image ci-dessous), mais ne remontera pas jusqu’à CompanyEmployee.
Cependant, si vous définissez la direction du filtrage croisé sur Les deux, cela fonctionne. La valeur Les deux permet à la spécification du filtrage de remonter jusqu’à CompanyEmployee.
Avec la direction du filtrage croisé définie sur Les deux, notre rapport apparaît désormais correct :
Le filtrage croisé dans les deux directions convient pour un modèle de relations entre tables tel que le modèle présenté précédemment. Ce schéma est généralement appelé « schéma en étoile », comme celui-ci :
La direction du filtrage croisé ne fonctionne pas correctement avec un modèle plus général fréquent dans les bases de données, comme dans le diagramme ci-après :
Si vous disposez d’un modèle de tables comme celui-ci, avec des boucles, le filtrage croisé peut créer un ensemble de relations ambigu. Par exemple, si vous additionnez les valeurs d’un champ de la table X et que vous choisissez de filtrer par un champ de la table Y, il est difficile de savoir si le filtrage doit passer par la table supérieure ou inférieure. Un exemple courant de ce genre de modèle est une TableX (une table des ventes avec des données réelles) et une TableY (une table contenant des données de budget). Les tables intermédiaires sont des tables de recherche utilisées par les deux tables, par exemple Division ou Région.
Comme dans le cas des relations actives/inactives, Power BI Desktop n’autorise pas la définition d’une relation Les deux si cela crée une ambiguïté dans les rapports. Vous pouvez gérer cette situation de plusieurs manières différentes. Voici les deux manières les plus courantes :
- Supprimez les relations ou marquez-les comme inactives pour réduire l’ambiguïté. Vous pourrez peut-être ensuite définir le filtrage croisé d’une relation sur Les deux.
- Importez une table deux fois (avec un nom différent la deuxième fois) pour éliminer les boucles. Ceci fait du modèle de relations un schéma en étoile. Avec un schéma en étoile, toutes les relations peuvent être définies sur Les deux.
Relation active incorrecte
Quand Power BI Desktop crée automatiquement des relations, il rencontre parfois plus d’une relation entre deux tables. Quand cette situation se produit, une seule des relations est définie comme étant active. La relation active fait office de relation par défaut. Ainsi, quand vous choisissez des champs dans deux tables différentes, Power BI Desktop peut créer automatiquement une visualisation pour vous. Toutefois, dans certains cas, la relation sélectionnée automatiquement peut être incorrecte. Utilisez la boîte de dialogue Gérer les relations pour définir une relation comme active ou inactive, ou définissez la relation active dans la boîte de dialogue Modifier la relation.
Pour garantir qu’il y a une relation par défaut, Power BI Desktop n’autorise qu’une seule relation active entre deux tables à un moment donné. Ainsi, vous devez d’abord définir la relation actuelle comme inactive, puis définir la relation de votre choix comme relation active.
Examinons un exemple. La première table est ProjectTickets (Tickets projet) et la deuxième est EmployeeRole (Rôle employé).
TicketsProjet
| Ticket | OuvertPar | SoumisPar | Heures | Projet | DateSoumission |
|---|---|---|---|---|---|
| 1001 | Perham, Tom | Brewer, Alan | 22 | Blue | 1/1/2013 |
| 1002 | Roman, Daniel | Brewer, Alan | 26 | Red | 2/1/2013 |
| 1003 | Roth, Daniel | Ito, Shu | 34 | Yellow | 12/4/2012 |
| 1004 | Perham, Tom | Brewer, Alan | 13 | Orange | 1/2/2012 |
| 1005 | Roman, Daniel | Bowen, Eli | 29 | Violet | 1/10/2013 |
| 1006 | Roth, Daniel | Bento, Nuno | 35 | Green | 2/1/2013 |
| 1007 | Roth, Daniel | Hamilton, David | 10 | Yellow | 1/10/2013 |
| 1008 | Perham, Tom | Han, Mu | 28 | Orange | 1/2/2012 |
| 1009 | Roman, Daniel | Ito, Shu | 22 | Purple | 2/1/2013 |
| 1010 | Roth, Daniel | Bowen, Eli | 28 | Green | 10/1/2013 |
| 1010 | Perham, Tom | Bowen, Eli | 9 | Blue | 10/15/2013 |
RôleEmployé
| Employé | Rôle |
|---|---|
| Bento, Nuno | Chef de projet |
| Bowen, Eli | Chargé de projet |
| Brewer, Alan | Chef de projet |
| Hamilton, David | Chargé de projet |
| Han, Mu | Chargé de projet |
| Ito, Shu | Chargé de projet |
| Perham, Tom | Parrain de projet |
| Roman, Daniel | Parrain de projet |
| Roth, Daniel | Parrain de projet |
Il existe en fait ici deux relations :
- Entre Employee (Employé) dans la table EmployeeRole et SubmittedBy dans la table ProjectTickets.
- Entre OpenedBy dans la table ProjectTickets et Employee (Employé) dans la table EmployeeRole.
Si nous ajoutons les deux relations au modèle (OpenedBy en premier), la boîte de dialogue Gérer les relations indique que la relation OpenedByest active :
Maintenant, si nous créons un rapport qui utilise les champs Role (Rôle) et Employee (Employé) de la table EmployeeRole, et le champ Hours (Heures) de la table ProjectTickets dans une visualisation de table sur le canevas de rapport, nous voyons seulement les sponsors des projets, car eux seuls ont ouvert un ticket de projet.
Nous pouvons changer la relation active, de façon à remplacer OpenedBy par SubmittedBy. Dans Gérer les relations, décochez la relation ProjectTickets(OpenedBy) à EmployeeRole(Employee) et cochez la relation EmployeeRole(Employee) à Project Tickets(SubmittedBy) .
Voir toutes vos relations dans la vue Relation
Parfois, votre modèle comporte plusieurs tables avec des relations complexes. La vue Relation de Power BI Desktop montre toutes les relations de votre modèle, leur direction et leur cardinalité, dans un diagramme personnalisable et facile à comprendre.
Pour plus d’informations, consultez Utiliser la vue Relation dans Power BI Desktop.
Résolution des problèmes
Cette section fournit des instructions et des informations de dépannage concernant l’utilisation de relations dans Power BI.
Les relations entre champs ne peuvent pas être déterminées
Power BI tente d’afficher les données pertinentes dans les visuels en déduisant les relations du modèle utilisé. Parfois, de telles inférences ne sont pas évidentes et vous pouvez être surpris d’obtenir une erreur indiquant l’absence de relation entre certaines colonnes dans votre visuel.
Pour expliquer comment Power BI détermine si les champs sont liés, nous allons utiliser un exemple de modèle et examiner quelques scénarios dans les sections suivantes. L’image suivante montre l’exemple de modèle que nous utiliserons dans les exemples de scénarios.
Scénario 1 : schéma en étoile traditionnel et aucune contrainte de mesure fournie. En vous référant à l’exemple de modèle dans l’image précédente, examinons d’abord les tables Vendor - Purchases - Product dans la partie droite de l’image. Cet exemple est un schéma en étoile traditionnel avec la table de faits (Purchases) et deux tables de dimension (Product et Vendor). La relation entre les tables de dimension et la table de faits est une relation Un à plusieurs (un produit correspond à plusieurs achats, un fournisseur correspond à plusieurs achats). Dans ce type de schéma, nous pouvons répondre à des questions du type Quelles sont les ventes pour le produit X ?, Quelles sont les ventes pour le fournisseur Y ? et Quels sont les produits vendus par le fournisseur Y ?.
Si vous souhaitez mettre en corrélation Products et Vendors, examinez la table Purchases pour voir s’il existe une entrée avec le même produit et le même fournisseur. Un exemple de requête pourrait ressembler à ceci :
Correlate Product[Color] with Vendor[Name] where CountRows(Purchases)>0
where CountRows(Purchases)>0 est une contrainte implicite que Power BI ajoute pour garantir que les données retournées sont pertinentes.
En effectuant cette corrélation par le biais de la table Purchases, nous pouvons retourner des paires Product-Vendor qui ont au moins une entrée dans une table de faits, c’est-à-dire des paires qui ont un sens du point de vue des données. Les combinaisons Product-Vendor pour lesquelles aucune vente n’a été réalisée ne sont pas affichées (ces combinaisons absurdes sont inutiles pour l’analyse).
Scénario 2 : schéma en étoile traditionnel et contrainte de mesure fournie. Dans l’exemple précédent du scénario 1, si l’utilisateur fournit une contrainte sous la forme d’une colonne résumée (Sum/Average/Count of Purchase Qty par exemple) ou une mesure de modèle (Distinct Count of VendID), Power BI peut générer une requête semblable à l’exemple suivant :
Correlate Product[Color] with Vendor[Name] where MeasureConstraint is not blank
Dans ce cas, Power BI tente de retourner des combinaisons qui ont des valeurs significatives pour la contrainte fournie par l’utilisateur (non vide). Power BI n’a pas besoin d’ajouter sa propre contrainte implicite CountRows(Purchases)>0, comme ce qui a été fait dans le scénario 1 précédent, car la contrainte fournie par l’utilisateur est suffisante.
Scénario 3 : schéma non en étoile et aucune contrainte de mesure fournie. Dans ce scénario, nous portons notre attention sur le centre du modèle où se trouvent les tables Sales - Product - Purchases, une table de dimension (Product) et deux tables de faits (Sales et Purchases). Comme il ne s’agit pas d’un schéma en étoile, nous ne pouvons pas répondre aux mêmes types de questions que dans le scénario 1. Supposons que nous essayons de mettre en corrélation Purchases et Sales, étant donné que Purchases a une relation Plusieurs à un avec Product et que Product a une relation Un à plusieurs avec Sales. Sales et Purchases ont indirectement une relation Plusieurs à plusieurs. Nous pouvons lier un Product à plusieurs Purchases et un Product à plusieurs ventes, mais nous ne pouvons pas lier une Sale à plusieurs Purchases ou vice versa. Nous pouvons uniquement lier plusieurs Purchases à plusieurs Sales.
Dans ce cas, si nous essayons de combiner Purchase[VenID] et Sales[CustID] dans un visuel, Power BI n’a pas de contrainte concrète à appliquer en raison de la relation Plusieurs à plusieurs entre ces tables. Bien que des contraintes personnalisées puissent être appliquées pour divers scénarios (ces contraintes ne provenant pas nécessairement des relations établies dans le modèle), Power BI ne peut pas déduire une contrainte par défaut en se basant uniquement sur les relations. Si Power BI tentait de retourner toutes les combinaisons des deux tables, il en résulterait une jointure croisée importante et le retour de données non pertinentes. Au lieu de cela, Power BI génère une erreur semblable à la suivante dans le visuel.
Scénario 4 : schéma non en étoile et contrainte de mesure fournie. Si nous prenons l’exemple du scénario 3 et ajoutons une contrainte fournie par l’utilisateur sous forme de colonne résumée (Count of Product[ProdID] par exemple) ou d’une mesure de modèle (Sales[Total Qty]), Power BI peut générer une requête qui ressemble à ceci : Correlate Purchase[VenID] et Sales[CustID] où MeasureConstraint n’est pas vide.
Dans ce cas, Power BI respecte la contrainte de l’utilisateur comme étant la seule contrainte que Power BI doit appliquer et retourne les combinaisons qui produisent des valeurs non vides. L’utilisateur a guidé Power BI vers le scénario qu’il souhaite, et Power BI applique les instructions.
Scénario 5 : contrainte de mesure fournie, mais partiellement liée aux colonnes. Dans certains cas, la contrainte de mesure fournie par l’utilisateur n’est pas entièrement liée à toutes les colonnes du visuel. Une mesure de modèle est toujours associée à tout. Power BI traite cela comme une boîte noire quand il tente de trouver des relations entre les colonnes du visuel, et suppose que l’utilisateur sait ce qu’il fait en l’utilisant. Cependant, les colonnes résumées sous la forme de Sum, Average et les résumés similaires choisis à partir de l’interface utilisateur ne peuvent être liées qu’à un sous-ensemble des colonnes/tables utilisées dans le visuel en fonction des relations de la table à laquelle cette colonne appartient. En tant que telle, la contrainte s’applique à certains jumelages de colonnes, mais pas à tous. Dans ce cas, Power BI tente de trouver les contraintes par défaut qu’il peut appliquer pour les colonnes qui ne sont pas liées par la contrainte fournie par l’utilisateur (comme dans le scénario 1). S’il n’en trouve pas, l’erreur suivante est retournée.
Résolution des erreurs de relation
Quand vous voyez l’erreur Impossible de déterminer les relations entre les champs, vous pouvez suivre les étapes suivantes pour tenter de résoudre l’erreur :
Vérifiez votre modèle. Est-il configuré correctement pour permettre à votre analyse d’apporter des réponses à vos questions ? Pouvez-vous modifier certaines des relations entre les tables ? Pouvez-vous éviter de créer une relation indirecte Plusieurs à plusieurs ?
Envisagez de convertir votre schéma en forme de V inversé en deux tables et d’utiliser une relation directe Plusieurs à plusieurs entre elles, comme décrit dans Appliquer des relations plusieurs à plusieurs dans Power BI Desktop.
Ajoutez une contrainte au visuel sous la forme d’une colonne résumée ou d’une mesure de modèle.
Si une colonne résumée est ajoutée et que l’erreur subsiste, songez à utiliser une mesure de modèle.
Contenu connexe
Pour plus d’informations sur les modèles et les relations, consultez les articles suivants :
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour