Aide pour la relation un-à-un
Cet article vous cible en tant que modélisateur de données qui fonctionne avec Power BI Desktop. Il vous fournit une aide pour l’utilisation des relations de modèle un-à-un. Une relation un-à-un peut être créée lorsque les deux tables contiennent chacune une colonne de valeurs communes et uniques.
Notes
La présentation des relations de modèle n’est pas abordée dans cet article. Si vous ne connaissez pas bien les relations, leurs propriétés ni la façon de les configurer, nous vous recommandons de lire d’abord l’article Relations de modèle dans Power BI Desktop.
Il est également important de comprendre la conception de schémas en étoile. Pour plus d’informations, consultez Comprendre le schéma en étoile et son importance pour Power BI.
Deux scénarios qui impliquent des relations un-à-un :
dimensions dégénérées: vous pouvez dériver une dimension dégénérée à partir d’une table de faits .
Données de ligne s'étendent sur plusieurs tables: une entité métier ou un sujet unique est chargé sous la forme de deux tables de modèles (ou plus), éventuellement parce que leurs données proviennent de différents magasins de données. Ce scénario peut être courant pour les tables de dimension . Par exemple, les détails du produit maître sont stockés dans un système de vente opérationnel et les détails supplémentaires du produit dans une autre source.
Toutefois, il est inhabituel de lier deux tables de faits à une relation un-à-un. C’est parce que les deux tables de faits doivent avoir la même dimensionnalité et la même granularité. En outre, chaque table de faits aurait besoin de colonnes uniques pour permettre la création de la relation de modèle.
Dimensions de fait
Lorsque des colonnes d’une table de faits sont utilisées pour le filtrage ou le regroupement, vous pouvez envisager de les rendre disponibles dans une table distincte. Ainsi, vous séparez les colonnes utilisées pour le filtrage ou le regroupement des colonnes utilisées pour résumer les lignes de faits. Grâce a cette séparation, vous pouvez effectuer les opérations suivantes :
- Réduisez l’espace de stockage.
- Simplifiez les calculs de modèle.
- Contribuer à améliorer les performances des requêtes.
- Offrez à vos auteurs de rapports une expérience de volet de données plus intuitive.
Considérez une table source nommée Sales
qui stocke les détails de référence de ligne de commande de vente dans deux colonnes.
La colonne OrderNumber
stocke le numéro de commande et la colonne OrderLineNumber
stocke une séquence de lignes dans l’ordre.
Dans l’image suivante, notez que les colonnes numéro de commande et numéro de ligne de commande n’ont pas été chargées dans la table Sales
. Au lieu de cela, leurs valeurs ont été utilisées pour créer une colonne de clés de substitution nommée OrderLineNumberID
. (La valeur de clé est calculée en multipliant le numéro de commande par 1 000, puis en ajoutant le numéro de la ligne de commande.)
La table de dimensions Sales Order
offre une expérience riche pour les auteurs de rapports avec deux colonnes : Sales Order
et Sales Order Line
. Ces colonnes particulières permettent de concevoir des rapports qui doivent être filtrés, groupés ou détaillés par ordre et par ligne d’ordre.
Étant donné que la table Sales Order
est dérivée des données de ventes, il doit y avoir exactement le même nombre de lignes dans chaque table. De plus, il doit y avoir des valeurs correspondantes entre chaque colonne OrderLineNumberID
.
Les données de ligne s’étendent sur les tables
Prenons un exemple qui implique deux tables de dimension en relation un-à-un : Product
et Product Category
. Chaque table représente les données importées et a une colonne SKU
(unité de conservation des stocks) qui contient des valeurs uniques.
Voici un diagramme de modèle partiel des deux tables.
La première table est nommée Product
et contient trois colonnes : Color
, Product
et SKU
. La deuxième table est nommée Product Category
et contient deux colonnes : Category
et SKU
. Une relation une-à-une relie les deux colonnes SKU
. La relation filtre dans les deux directions, comme toujours pour les relations un-à-un.
Pour vous aider à décrire le fonctionnement de la propagation du filtre de relation, l’image suivante révèle certaines lignes de table. Tous les exemples de cet article sont basés sur ces données.
Les détails des lignes pour les deux tables sont décrits dans la liste à puces suivante :
- La table
Product
comporte trois lignes :SKU
CL-01,Product
T-shirt,Color
VertSKU
CL-02,Product
Jeans,Color
BleuSKU
AC-01,Product
Chapeau,Color
Bleu
- La table
Product Category
comporte deux lignes :SKU
CL-01,Category
VêtementsSKU
AC-01,Category
Accessoires
Notez que la table Product Category
n’inclut pas de ligne pour la référence SKU du produit CL-02. Nous évoquerons les conséquences de cette ligne manquante plus loin dans cet article.
Dans le volet Données, les auteurs de rapports recherchent des champs liés au produit dans deux tables : Product
et Product Category
. Voyons ce qui se passe lorsque des champs des deux tables sont ajoutés à un visuel de table. Dans cet exemple, la colonne SKU
provient de la table Product
.
Notez que la valeur Category
pour la référence SKU du produit CL-02 est VIDE. Cela est dû au fait qu’il n’existe aucune ligne correspondante dans la table Product Category
pour ce produit.
Recommandations
Si cela est possible, nous vous recommandons d’éviter de créer des relations de modèle un-à-un lorsque des données de lignes s’étendent sur des tables de modèles. C’est parce que cette conception peut :
- Contribuer à encombrer le volet Données en ajoutant plus de tables que nécessaire.
- Compliquer la tâche des auteurs de rapports pour trouver des champs liés, puisqu’ils sont répartis sur plusieurs tables.
- Limitez la possibilité de créer des hiérarchies, car leurs niveaux doivent être basés sur des colonnes de la même table.
- Donner des résultats inattendus lorsqu’il y a une correspondance complète de lignes entre les tables.
Les recommandations varient selon que la relation un-à-un est de type groupe intrasource ou groupe intersource. Pour plus d’informations sur l’évaluation des relations, consultez Modèle de relations dans Power BI Desktop.
Relation un-à-un de groupe intrasource
Quand il existe une relation de groupe intrasource de type un-à-un entre des tables, nous recommandons de regrouper les donnés dans une même table de modèle. Pour ce faire, fusionnez les requêtes Power Query.
Les étapes suivantes présentent une méthodologie pour consolider et modéliser les données associées un-à-un.
Fusionner des requêtes : Lorsque les deux requêtes sont combinées, veillez à ce que les données de chaque requête soient complètes. Si une requête contient un ensemble complet de lignes (comme une liste maître), fusionnez l’autre requête avec elle. Définissez la transformation de fusion pour utiliser une jointure externe gauche , qui est le type de jointure par défaut. Ce type de jointure garantit que vous conservez toutes les lignes de la première requête et les complétez avec toutes les lignes correspondantes de la deuxième requête. Développez toutes les colonnes requises de la deuxième requête dans la première requête.
Désactiver le chargement des requêtes : Veillez à désactiver le chargement de la deuxième requête. Ainsi, elle ne chargera pas son résultat comme table de modèle. Cette configuration réduit la taille de stockage du modèle de données et aide à désencombrer le volet Données.
Dans notre exemple, les auteurs de rapports trouvent désormais une table unique nommée
Product
dans le volet Données. Elle contient tous les champs liés aux produits.Remplacer les valeurs manquantes : si la deuxième requête comporte des lignes sans correspondance, les valeurs Null apparaissent dans les colonnes introduites à partir de celle-ci. Si nécessaire, envisagez de remplacer les valeurs Null par une valeur de jeton. Le remplacement de valeurs manquantes est particulièrement important lorsque les auteurs de rapports filtrent ou regroupent par valeurs de colonnes, étant donné que les VIDES pourraient s’afficher dans les visuels du rapport.
Dans l’image suivante, notez que la catégorie de référence SKU produit CL-02 lit maintenant [Non défini]. Dans la requête, les catégories null ont été remplacées par cette valeur de texte de jeton.
Créer des hiérarchies : s’il y a des relations entre les colonnes de la table consolidée, envisagez de créer des hiérarchies. Ainsi, les auteurs de rapports peuvent rapidement identifier des opportunités d’approfondissement de visuels de rapports.
Dans notre exemple, les auteurs de rapports peuvent désormais utiliser une hiérarchie qui a deux niveaux :
Category
etProduct
.
Si vous souhaitez savoir comment séparer des tables vous aide à organiser vos champs, nous recommandons également la consolidation dans une seule table. Vous pouvez toujours organiser vos champs, mais en utilisant l’affichage des dossiers à la place.
Dans notre exemple, les auteurs de rapports peuvent trouver le champ Category
dans le dossier d’affichage Marketing
.
Si vous souhaitez quand même définir des relations de groupe intrasource un-à-un dans votre modèle, vérifiez si possible qu’il y a des lignes correspondantes dans les tables liées. Une relation de groupe intrasource un-à-un étant évaluée comme étant une relation régulière, les problèmes d’intégrité des données peuvent se traduire par des VIDES dans vos visuels de rapports. (Vous pouvez voir un exemple de regroupement VIDE dans le premier visuel de table présenté dans cet article.)
Relation un-à-un de groupe intersource
Quand il existe une relation de groupe intersource de type un-à-un entre des tables, il n’existe pas d’autre conception de modèle possible, à moins que vous regroupiez préalablement les données dans votre source de données. Power BI évaluera la relation de modèle un-à-un comme une relation limitée. Par conséquent, veillez à vous assurer qu’il existe des lignes correspondantes dans les tables associées, car les lignes sans correspondance sont supprimées des résultats de la requête.
Voyons ce qui se passe lorsque des champs des deux tables sont ajoutés à un visuel de table et qu’il existe une relation limitée entre ces tables.
Le premier visuel de table, qui utilise une relation de groupe inter-sources, affiche deux lignes uniquement. La référence SKU produit CL-02 est manquante, car il n’existe aucune ligne correspondante dans la table Product Category
. Le deuxième visuel de table, basé sur une table consolidée unique dans le modèle, affiche trois lignes.
Contenu connexe
Pour plus d’informations en rapport avec cet article, consultez les ressources suivantes :
- Relations de modèle dans Power BI Desktop
- Comprendre le schéma en étoile et son importance pour Power BI
- Aide à la résolution des problèmes de relations
- Vous avez des questions ? Essayez de poser votre question à la communauté Fabric
- Vous avez des suggestions ? Proposer des idées pour améliorer Fabric