Les données ne sont pas toujours parfaites, malheureusement. Il y aura donc des moments où vous sélectionnerez la cardinalité que vous souhaitez utiliser pour joindre deux tables et obtiendrez des résultats étranges lorsque vous créerez vos tableaux de bord.
Il est impossible de couvrir toutes les multiples raisons qui peuvent provoquer cette erreur. Donc, si vous voyez ce message, voici quelques conseils pour essayer de vous aider à résoudre ce problème, si vous le rencontrez :
- Pour une cardinalité un-à-plusieurs, assurez-vous que les valeurs du champ du côté « un » de la relation existent pour toutes les valeurs correspondantes du côté « plusieurs ».
- Pour une cardinalité un à un, vérifiez qu’il n’y a pas de valeurs en double pour les champs de part et d’autre de la relation de table.
- Pour une cardinalité un-à-un, assurez-vous qu’il n’y a pas de valeurs vides ou nulles pour les champs de part et d’autre de la relation de table.
- Pour une cardinalité un-à-plusieurs, assurez-vous que les valeurs du champ du côté « un » de la relation ne contiennent pas de valeurs vides ou nulles.
Gestion des relations entre les tables
La gestion des relations dans Power BI Desktop est souvent la clé pour créer un modèle de données efficace. Il n’entre cependant pas dans le cadre de ce livre de fournir un cours complet sur la modélisation des données. Néanmoins, voici quelques conseils à garder à l’esprit lors de la création de vos modèles de données initiaux :
- Il peut être utile de penser en termes de tables principales et de tables de recherche. Dans le modèle de données que vous avez vu dans ce chapitre, vous pouvez considérer certaines tables comme des tables de correspondance pour les données principales, telles que les tables Couleurs, Pays et Clients.
- Les tables de consultation contiennent généralement une série de valeurs qui ne sont pas répétées dans la table (une liste de pays, par exemple). Ces valeurs sont appelées le côté “un” d’une relation et sont liées à une autre table où elles sont référencées à de nombreuses reprises. D’où le tableau qui contient les références multiples est appelé le côté “plusieurs” de la relation. Ceci est également appelé la cardinalité d’une relation par les concepteurs de bases de données et d’entrepôts de données.
- Si vous examinez la Figure (la vue Modèle de Power BI Desktop), vous pouvez voir que les différents types de relation sont indiqués dans la jointure entre les tables associées. Un petit 1 à la fin d’une relation indique le côté “un” d’une relation, et un astérisque indique le côté “plusieurs” de la relation.
- Si vos données source contiennent de nombreuses tables de recherche qui descendent en cascade à travers une série de relations (un cas classique est la catégorie
➤ Sous-catégorie ➤ Hiérarchie de produits que vous trouvez dans de nombreux magasins
environnements), pour éviter de trop compliquer le modèle de données, vous
peut préférer fusionner plusieurs tables en une seule table à l’aide de Power BI Desktop Query avant de développer le modèle de données dans Power BI Desktop lui-même.
- Parfois, et cela peut être le cas lors de l’importation de données à partir de bases de données relationnelles, vous devez joindre des tables sur plusieurs champs. Cela n’est pas possible dans Power BI Desktop. Cependant, vous pouvez souvent trouver des solutions de contournement, en utilisant à nouveau Power BI Desktop Query avant de modéliser les données. Dans de tels cas, vous pouvez fusionner des tables en créant des jointures à l’aide de plusieurs champs , par exemple.
- Les données importées des entrepôts de données peuvent avoir une structure intégrée de faits (tables principales contenant des métriques) et de dimensions (contenant des éléments de recherche). Cependant, vous souhaiterez peut-être « aplatir » des hiérarchies complexes de dimensions et créer ici également des tableaux à un seul niveau d’éléments de recherche à l’aide de Power BI Desktop Query.
- Parfois, vous voudrez peut-être utiliser le même tableau deux fois dans des contextes différents. Par exemple, une table de dates peut être utile pour joindre une date de vente et une date d’achat. Dans de tels cas, vous pouvez réimporter la date
table une seconde fois (et donnez-lui un autre nom), puis créez deux jointures distinctes à partir d’une table de recherche vers les deux tables de recherche différentes. Cela vous permet de filtrer et d’agréger les données selon des critères de date distincts. Une table de recherche comme celle-ci est souvent appelée une dimension de jeu de rôle.
- Il est possible de créer plusieurs relations entre une table et une autre et de spécifier qu’une seule d’entre elles est active. Vous pouvez ensuite forcer un calcul à appliquer une relation non active à l’aide de la fonction USERELATIONSHIP() dans DAX. Cependant, nous commençons déjà à atteindre des niveaux plus complexes de modélisation des données, donc je ne mentionnerai ici que la possibilité.
Direction du filtre croisé
Vous pouvez voir les deux options de filtrage croisé dans la Figure . Ceux-ci vous permettent de spécifier si les filtres s’appliqueront à toutes les tables d’un ensemble joint de tables ou uniquement à la table où une agrégation est en cours.
IMAGE
Image . Direction du filtre croisé dans les relations entre les tables
Les deux options sont décrites dans le Tableau .
Tableau . Options de direction du filtre croisé
Option de direction du filtre croisé | Description |
Seul | Les filtres sur la table liée s’appliqueront à la table où les agrégations de données ont lieu, mais pas l’inverse. |
Tous les deux | À des fins de filtrage, les deux tables sont considérées comme s’il s’agissait d’une seule table plus grande. toutes les données de toutes les tables seront filtrées. |
Autres options de relation
Les options fondamentales restantes pour les relations sont
- Rendre cette relation active
- Supposer l’intégrité référentielle
Rendre cette relation active
Dans certains modèles de données, il peut y avoir plusieurs relations (sur différents champs) entre les tables. Cependant, une seule de ces relations peut être active à la fois. Le fait de cliquer sur la case à cocher « Rendre cette relation active » indique à Power BI Desktop que la relation sélectionnée est la relation active. D’autres relations peuvent cependant être utilisées dans le code DAX.
Assumer l’intégrité référentielle
Cette option n’est disponible que lors de l’utilisation de DirectQuery (que vous avez appris à utiliser au chapitre 4). Par définition, cette option s’applique uniquement à une base de données relationnelle. L’activation de cette option permet à Power BI Desktop d’envoyer des requêtes plus efficaces à la source de données sous-jacente. Cela signifie que les données sont mises à jour plus rapidement. Pour que cela fonctionne, il y a quelques exigences de base :
- Les données du champ “de” dans la relation ne peuvent jamais être nulles ou vides.
- Pour chaque élément de données dans le champ « de », il y a une valeur correspondante dans le champ « à ».
- Le champ “de” est du côté “plusieurs” dans une relation un-à-plusieurs, ou la relation est un type de jointure un-à-un.
Remarque Vous devez savoir que la définition de l’option « supposer l’intégrité référentielle » lorsque les données sous-jacentes ne satisfont pas aux exigences précédentes n’empêchera pas l’application de l’option, ni même le renvoi des données. cependant, les résultats peuvent être erronés.
Réimportation des tables associées
Il y a un point assez important à faire pour conclure ce chapitre. En effet, si vous supprimez un ensemble de tables associées et que vous les réimportez ensuite sans importer les relations, Power BI Desktop ne se souviendra pas des relations qui existaient auparavant. Par conséquent, vous devrez recréer manuellement toutes les relations.
Il en va de même si vous supprimez et réimportez une table que vous avez liée à une table existante dans Power BI Desktop : une fois qu’une relation a été supprimée via le processus de suppression d’une table, vous devrez la recréer.
Propriétés de table et de champ
Les modèles de données Power BI peuvent rapidement devenir extrêmement complexes. Par conséquent, il peut être utile (pour ne pas dire fondamental) de les documenter de manière approfondie. Le volet Propriétés de la vue Modèle vous permet justement de faire ceci :
- Basculez vers la vue Modèle.
- Cliquez sur le tableau que vous souhaitez documenter.
- Dans le volet Propriétés, cliquez dans le champ Description et entrez une description. Le volet Propriétés ressemblera à celui illustré à la Figure .
IMAGE
Image . Le volet Propriétés
Cliquer sur un nom de champ vous permet de documenter le champ sélectionné de la même manière. Le volet Propriétés vous permet également de définir les attributs suivants du champ sélectionné :
- Le type de données
- La mise en forme numérique
- La visibilité du champ (ceci s’applique également aux tables)
- La catégorisation des données
- Le récapitulatif par défaut
- La colonne Trier par (si nécessaire)