Partager via


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.

Diagramme montrant les lignes de table pour la table de dimension dégénérée Sales. La conception est décrite dans le paragraphe suivant.

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.)

Diagramme montrant deux tables : Ventes et Commande vente. Une relation un-à-un concerne les colonnes ID de numéro de 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.

Diagramme montrant un modèle qui contient deux tables où les données de ligne s’étendent sur plusieurs tables. La conception est décrite dans le paragraphe suivant.

La première table est nommée Productet contient trois colonnes : Color, Productet SKU. La deuxième table est nommée Product Categoryet 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.

Diagramme montrant les tables Product et Product Category et certaines lignes de données. Les détails de la ligne sont décrits dans le paragraphe suivant.

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, ProductT-shirt, ColorVert
    • SKU CL-02, ProductJeans, ColorBleu
    • SKUAC-01, ProductChapeau, ColorBleu
  • La table Product Category comporte deux lignes :
    • SKU CL-01, CategoryVêtements
    • SKUAC-01, CategoryAccessoires

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.

Diagramme montrant le volet Données avec deux tables et un visuel de table qui comprend quatre colonnes. La valeur de la catégorie pour la référence SKU du produit CL-02 est VIDE.

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.

  1. 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.

    Diagramme montrant les données consolidées dans une table de dimension Produit unique.

  2. 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.

  3. 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.

    Diagramme montrant le volet Données de la table Produit. Il affiche également un visuel de table avec quatre colonnes. La valeur de la catégorie pour la référence SKU du produit CL-02 est désormais étiquetée comme Indéfinie.

  4. 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 et Product.

    Diagramme montrant le panneau de données. La table Produits inclut la hiérarchie Produits.

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.

Diagramme montrant le volet Données où le champ Catégorie se trouve dans un dossier d’affichage nommé 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.

Diagramme montrant une relation un-à-un entre les groupes sources, qui est une relation limitée.

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.

Diagramme montrant deux visuels de tableau, décrits dans le paragraphe suivant.

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.

Pour plus d’informations en rapport avec cet article, consultez les ressources suivantes :