3 votes

Power BI doit-il avoir des branches épaisses ou fines dans le modèle de schéma en étoile ?

Cette question n'a pas de réponse satisfaisante. N'hésitez pas à y répondre ou à faire des commentaires.

Considérons le modèle de données suivant. Notre modèle comporte trois dimensions. Si vous devez les nommer, faites-le (A) produit, (B) marque, (C) région. B est un conteneur pour A, il s'agit donc d'une hiérarchie. Plusieurs produits dans une seule marque. Les tables désignées par A, B, C, AB, ABC sont des tables passerelles qui ne contiennent que des valeurs uniques.

Passons maintenant aux questions :

  1. La table de bridge AB est-elle nécessaire dans le modèle suivant ? Ne pourrait-on pas connecter les tables A et B directement à ABC.

  2. Est-ce une bonne idée de créer un produit cartésien pour toutes les dimensions ? dans le modèle en tant que Table de bridge centrale ?

  3. Devons-nous brancher le tableau Budget avec les dimensions AB sur le pont AB ou sur le pont ABC ? En fonction de la réponse à la première question.

  4. Comment intégrer le tableau de publicité dans le modèle ? En pontant ABC ou en créant spécialement une table de pont BC et en la connectant à ABC ?

Maintenant, le schéma :

   +-------+
   |       |
   |  A    +-----+
   |       |     |
   +-------+     |
                 |
                 v
   +-------+  +--+----+      +--------+      +------------+
   |       |  |       |      |        |      | Sales      |
   |  B    +-->  AB   +----->|  ABC   +----->|   ABC      |
   |       |  |       |      |        |      |            |
   +-------+  +--+----+      +---+----+      +------------+
                                 ^
                                 |
   +-------+                     |           +------------+
   |       |                     |           | Budget     |
   |  C    +---------------------+           |   AB       |
   |       |                                 |            |
   +-------+                                 +------------+

                                             +------------+
                                             | Advertizing|
                                             |   BC       |
                                             |            |
                                             +------------+

Pont DAX.

J'aime construire des tables de correspondance en DAX, et non en M. Il y a quelques raisons à cela. Premièrement, le code est simple. Deuxièmement, cela introduit une sorte d'ordre dans l'éditeur de requêtes parce que je n'y vois que les tables sources (pas les ponts).

Tableaux de correspondance - DAX ou M ?

La création d'un pont pour la dimension A se présente donc comme suit :

#A =
DISTINCT (
    UNION (
        TOPN ( 0, ROW ( "A", "Apple" ) ),
        DISTINCT ( Sales[A] ),
        DISTINCT ( Budget[A] ),
        DISTINCT ( Advertizing[A] )
    )
)

Le pont pour AB serait un produit cartésien de A et B ainsi créés :

AB =
CROSSJOIN (
    DISTINCT ( '#A'[A] ),
    DISTINCT ( '#B'[B] ),
    "A@B", COMBINEVALUES("@",'#A'[A], '#B'[B])
)

Mise à jour après réception de la première réponse.

Je ne veux pas modifier le contenu de ma question une fois que la prime a commencé. Après la première réponse, j'ai réalisé que les hiérarchies sont apparues dans ma question par accident et qu'elles vous détournent de ce que j'aimerais découvrir. Vous pouvez oublier les hiérarchies et traiter les dimensions A, B, C comme des dimensions indépendantes.

J'aimerais me concentrer sur la façon de construire un schéma en étoile dans le cas où nous avons de nombreuses dimensions indépendantes et quelques tables, disons des dictionnaires avec des dimensions jointes. Par exemple, nous pouvons avoir un budget de vente défini par la région et la marque, et un budget publicitaire défini par la couleur du produit. Devrions-nous construire une table centrale qui contienne toutes les dimensions (produit cartésien de ABC) ? Ou bien la table centrale doit-elle comporter des branches épaisses à plusieurs dimensions ? Dans le second cas, nous aurions [AB] -> [ABC] <- [BC].

4voto

Kosuke Sakai Points 1953

Mise à jour le 6 novembre 2019 selon le commentaire de l'OP

  1. La table de bridge AB est-elle nécessaire dans le modèle suivant ? Ne pourrions-nous pas relier les tables A et B directement à la table ABC ?

Non. Il n'est pas nécessaire d'avoir des tables de bridge telles que AB y ABC . Avec un modèle comme celui-ci, où il y a plusieurs tables de faits, il est recommandé de construire votre modèle avec plusieurs tables de faits. schéma en étoile . Il suffit d'établir des relations directes de type "un à plusieurs" entre les tables de dimensions et les tables de faits, telles que A -> Sales , B -> Sales , A -> Budget y B -> Budget . Remarquez que lorsque vous examinez chaque table de faits, la table de faits et toutes les tables de dimensions associées forment un schéma en étoile.

star schema model

  1. Est-il judicieux de créer un produit cartésien pour toutes les dimensions du modèle sous la forme d'un tableau central ?

Non. Il est simplement redondant de faire un produit cartésien de toutes les tables de dimensions en une seule grande table de dimensions (que nous appellerons "table de dimensions commune").

Une table passerelle entre deux dimensions est généralement nécessaire lorsqu'il existe une relation de plusieurs à plusieurs entre les dimensions. Par exemple, lorsque Customer peut appartenir à plusieurs Category une table de bridge Customer Category serait nécessaire. Le scénario présenté par l'OP n'est pas un cas d'utilisation de la table de bridge.

Les inconvénients du tableau de dimensions des joints sont les suivants,

  • Il nécessite un stockage de données supplémentaire. Si A , B , C ont respectivement 100, 100 et 1000 lignes, le tableau de dimensions commun aura 10 millions de lignes. Supposons que vous vous tourniez ensuite vers l'ajout d'une nouvelle dimension de 100 lignes, le nombre de lignes de dimension sera de 1 milliard ! Ce n'est pas économique.

  • Elle nécessite des calculs supplémentaires. Lorsque nous voulons Sales filtré par A le moteur doit d'abord parcourir le tableau des dimensions communes pour extraire les lignes qui correspondent à la valeur filtrée de A ce qui représente potentiellement un grand nombre de lignes, puis le moteur scanne Sales tableau de faits avec la clé de relation contenue dans les lignes du tableau de dimensions communes extraites. Cela ne peut fonctionner que lorsque la taille des dimensions est très petite et que la table des faits est très grande. Mais dans de nombreux cas, les performances seront désastreuses.

  • Il s'agit d'une représentation non pertinente des données de l'entreprise. Je pense que c'est le plus grand inconvénient. Dans votre modèle, Budget n'est défini que dans la granularité des dimensions A y B . Il est absurde de penser qu'un Budget qui appartient à une instance de C . Toutefois, afin d'établir une relation entre le tableau des dimensions communes et les Budget nous devons modifier Budget pour qu'il soit lié à une instance spécifique de C .

  1. Faut-il ajouter le tableau Budget avec les dimensions AB au pont AB ou au pont ABC ? En fonction de la réponse à la première question.

Budget devrait être directement liée à A y B . Parce que la granularité des Budget est chaque A y B dans votre modèle.

  1. Comment intégrer la table de publicité dans le modèle ? En pontant ABC ou en créant spécialement une table de pont BC et en la connectant à ABC ?

Établir des relations B -> Advertising y C -> Advertising .


BTW, il n'y a en fait aucune relation de plusieurs à plusieurs dans votre modèle. Il peut y avoir plusieurs Sales les dossiers relatifs à un Product mais chaque Sales n'a qu'un seul enregistrement Product , de sorte que la relation entre Product y Sales est de type "one-to-many". Il en va de même pour les autres relations du modèle.

Il serait préférable de parler de "tables de faits multiples avec une granularité différente".


Ajouté le 6 novembre 2019 selon le commentaire de l'OP

Il semble que l'OP ne sache pas comment gérer plusieurs tables de faits avec une granularité différente. Je suggère que l'OP bénéficie de cet article par Marco Russo, mais j'essaie d'en résumer l'essentiel ici.

Fondamentalement, le modèle présenté par OP peut être simplifié en un modèle de schéma en étoile, dans lequel les tables de faits Sales , Budget y Advertising seront placés au centre de différentes étoiles.

Le problème réside dans le fait que certaines tables de dimensions sont partagées par différentes tables de faits, alors que certaines dimensions ne sont pas partagées. Par exemple, les dimensions A y B sont partagées par Sales y Budget considérant que C n'est pertinent qu'avec Sales . Imaginons que nous comparions Sales y Budget . Lorsque nous décomposons le rapport par C quelle valeur doit apparaître dans Budget ? La réponse peut varier en fonction de l'entreprise, mais nous pensons ici que nous attendons Budget ser vierge car nous n'avons pas de Budget définis au niveau de chaque C .

L'approche généralement acceptée pour ce type de scénario consiste à vérifier le contexte de filtrage dans la mesure et à ne renvoyer la valeur que si elle est filtrée par les dimensions pertinentes. Par exemple, calculer le total des Budget uniquement lorsque le contexte actuel n'a pas de filtre sur C .

[Total Budget] :=
IF (
    NOT ( ISFILTERED ( 'C' ) ),
    SUM ( 'Budget'[Amount] )
)

Références

Ajouté le 11 novembre 2019

Analyser les données avec Power BI et Power Pivot pour Excel Couvre en détail les modèles et les meilleures pratiques de modélisation des données.

Comprendre le schéma en étoile et son importance pour Power BI Illustre les caractéristiques et les avantages du schéma en étoile. Il énumère également d'autres modèles de modélisation courants.

Meilleure façon de travailler avec plusieurs tableaux de faits Un fil de discussion dans le forum communautaire Microsoft Power BI, où il est mentionné que la table de liens n'est pas une bonne pratique pour gérer des tables de faits multiples.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X