Découvrez le schéma en étoile et son importance pour Power BI

Cet article s’adresse aux modélisateurs de données Power BI Desktop. Il décrit la conception de schéma en étoile et sa pertinence pour le développement de modèles sémantiques Power BI optimisés pour les performances et la facilité d’utilisation.

Important

Les modèles sémantiques Power BI dépendent de Power Query pour importer ou se connecter aux données. Cela signifie que vous devez utiliser Power Query pour transformer et préparer les données sources, ce qui peut être difficile lorsque vous avez de grands volumes de données ou que vous devez implémenter des concepts avancés tels que les dimensions à variation lente (décrites plus loin dans cet article).

Lorsque vous rencontrez ces défis, nous vous recommandons de commencer par développer un entrepôt de données et des processus d’extraction, de transformation et de chargement (ETL) pour charger régulièrement l’entrepôt de données. Votre modèle sémantique peut ensuite se connecter à l’entrepôt de données. Pour plus d’informations, consultez Modélisation dimensionnelle dans Microsoft Fabric Warehouse.

Conseil

Cet article n’a pas pour but d’aborder par le menu la conception de schémas en étoile. Pour plus d’informations, reportez-vous directement au contenu publié et largement adopté, comme The Data Warehouse Toolkit : The Definitive Guide to Dimensional Modeling (3ème édition, 2013) par Ralph Kimball et d’autres auteurs.

Vue d’ensemble du schéma en étoile

Le schéma en étoile est une approche de modélisation mature largement adoptée par les entrepôts de données relationnels. Les modélisateurs doivent classer leurs tables de modèle en tant que table de dimension ou table de faits.

• Les tables de dimension décrivent les entités d’entreprise : les choses que vous modélisez. Les entités peuvent inclure des produits, des personnes, des lieux et des concepts, y compris le temps lui-même. La table la plus cohérente que vous trouverez dans un schéma en étoile est une table de dimension de date. Une table de dimension contient une colonne clé (ou des colonnes) qui agit comme un identificateur unique et d’autres colonnes. Les autres colonnes prennent en charge le filtrage et le regroupement de vos données.
• Les tables de faits stockent des observations ou des événements, et peuvent être des commandes commerciales, des soldes boursiers, des taux de change, des températures, etc. Une table de faits contient des colonnes de clés de dimension liées aux tables de dimensions, ainsi que des colonnes de mesures numériques. Les colonnes clés de dimension déterminent la dimensionnalité d’une table de faits, tandis que les valeurs clés de dimension déterminent sa granularité. Par exemple, considérez une table de faits conçue pour stocker des cibles de vente qui ont deux colonnes Date clés de dimension et ProductKey. Il est facile de comprendre que la table a deux dimensions. Toutefois, vous ne pouvez pas déterminer la granularité sans tenir compte des valeurs clés de dimension. Dans cet exemple, considérez que les valeurs stockées dans la Date colonne sont le premier jour de chaque mois. Dans ce cas, la granularité se situe au niveau produit/mois.

En règle générale, les tables de dimension contiennent un nombre relativement petit de lignes. Les tables de faits, d’autre part, peuvent contenir un grand nombre de lignes et continuer à croître au fil du temps.

Normalisation et dénormalisation

Pour comprendre certains concepts du schéma en étoile décrits dans cet article, il est important de connaître ces deux termes : normalisation et dénormalisation.

La normalisation est le terme utilisé pour décrire les données stockées de manière à réduire les données répétitives. Considérez une table de produits qui a une colonne de valeur clé unique, comme la clé de produit et d’autres colonnes qui décrivent les caractéristiques du produit, telles que le nom du produit, la catégorie, la couleur et la taille. Une table de ventes est considérée normalisée quand elle stocke uniquement des clés, comme la clé de produit. Dans l’image suivante, notez que seule la ProductKey colonne enregistre le produit.

Toutefois, si la table de ventes stocke des détails sur les produits qui vont au-delà de la clé, elle est considérée comme étant dénormalisée. Dans l’image suivante, notez que les ProductKey autres colonnes liées au produit enregistrent le produit.

Quand vous sourcez des données à partir d’un fichier d’exportation ou d’une extraction de données, elles représentent probablement un jeu de données dénormalisé. Dans ce cas, utilisez Power Query pour transformer et mettre en forme les données sources en plusieurs tables normalisées.

Comme décrit dans cet article, vous devez vous efforcer de développer des modèles sémantiques Power BI optimisés avec des tables qui représentent des données de fait et de dimension normalisées. Toutefois, il existe une exception dans laquelle une dimension flocon de neige peut être dénormalisée afin de produire une table de modèle unique.

Pertinence du schéma en étoile pour les modèles sémantiques Power BI

La conception de schémas en étoile et de nombreux concepts associés présentés dans cet article sont très importants pour le développement de modèles Power BI qui sont optimisés du point de vue des performances et de la convivialité.

Considérez que chaque visuel de rapport Power BI génère une requête envoyée au modèle sémantique Power BI. En règle générale, les requêtes filtrent, regroupent et résument les données du modèle. Un modèle bien conçu fournit des tables pour le filtrage et le regroupement et des tables pour la totalisation. Cette conception répond bien aux principes des schémas en étoile :

• Les tables de dimension activent le filtrage et le regroupement.
• Les tables de faits activent la synthèse.

Il n’existe aucune propriété de table que les modélisateurs définissent pour définir le type de table en tant que dimension ou fait. Elle est en fait déterminée par les relations de modèle. Une relation de modèle établit un chemin de propagation de filtre entre deux tables, et il s’agit de la propriété de cardinalité de la relation qui détermine le type de table. Une cardinalité de relation courante est un-à-plusieurs ou son opposé, plusieurs-à-un. Le côté « un » est toujours une table de dimension tandis que le côté « plusieurs » est toujours une table de faits.

Une conception de modèle bien structurée inclut des tables qui sont des tables de dimension ou des tables de faits. Évitez de combiner les deux types pour une même table. Nous vous recommandons également de vous efforcer de fournir le bon nombre de tables avec les bonnes relations en place. Il est également important que les tables de faits chargent toujours des données à un grain cohérent.

Enfin, il est important de comprendre que la conception optimale du modèle relève pour partie de la science et pour partie de l’art. Vous pouvez parfois vous éloigner des directives fournies lorsque cela s’avère judicieux.

Il existe de nombreux concepts liés à la conception de schéma en étoile qui peuvent être appliqués à un modèle sémantique Power BI. Ces concepts sont les suivants :

• Mesures
• Clés de substitution
• Dimensions en flocon
• Dimensions de rôle actif
• Dimension à variation lente
• Dimensions fourre-tout
• Dimensions de fait
• Tables de faits sans faits

Mesures

Dans la conception d’un schéma en étoile, une mesure est une colonne de table de faits qui stocke les valeurs à totaliser. Dans un modèle sémantique Power BI, une mesure a une définition différente, mais similaire. Un modèle prend en charge les mesures explicites et implicites.

• Les mesures explicites sont expressément créées et sont basées sur une formule écrite dans DAX (Data Analysis Expressions) qui permet de résumer. Les expressions de mesure utilisent souvent des fonctions d’agrégation DAX telles que SUM, MINMAX, , AVERAGEet d’autres pour produire un résultat de valeur scalaire au moment de la requête (les valeurs ne sont jamais stockées dans le modèle). Une expression de mesure peut aller de simples agrégations de colonnes à des formules plus sophistiquées qui remplacent la propagation de relation et/ou de contexte de filtre. Pour plus d’informations, consultez les concepts de base de DAX dans Power BI Desktop.
• Les mesures implicites sont des colonnes qui peuvent être résumées par un visuel de rapport ou un Q&A. Ils offrent une commodité pour vous en tant que développeur de modèles, comme dans de nombreuses instances, vous n’avez pas besoin de créer des mesures (explicites). Par exemple, la colonne ventes Sales Amount des revendeurs Adventure Works peut être résumée de nombreuses façons (somme, nombre, moyenne, médiane, min, max et autres), sans avoir à créer une mesure pour chaque type d’agrégation possible.

Dans le volet Données , les mesures explicites sont représentées par l’icône de calculatrice, tandis que les mesures implicites sont représentées par le symbole sigma (∑).

Toutefois, il existe trois raisons intéressantes pour lesquelles vous pouvez créer des mesures, même pour des résumés au niveau des colonnes simples :

• Lorsque vous savez que vos auteurs de rapports interrogent le modèle sémantique à l’aide d’expressions multidimensionnelles (MDX), le modèle doit inclure des mesures explicites. Cela est dû au fait que MDX ne peut pas obtenir de résumé des valeurs de colonne. Notamment, MDX est utilisé lors de l’exécution de l’analyse dans Excel , car les tableaux croisés dynamiques émettent des requêtes MDX.

• Lorsque vous savez que vos auteurs de rapports créent des rapports paginés Power BI à l’aide du concepteur de requêtes MDX, le modèle sémantique doit inclure des mesures explicites. Seul le concepteur de requêtes MDX prend en charge les agrégats de serveur. Par conséquent, si les auteurs de rapports doivent faire évaluer les mesures par Power BI (et non par le moteur de rapport paginé), ils doivent utiliser le concepteur de requêtes MDX.

• Lorsque vous souhaitez contrôler la façon dont vos auteurs de rapports résument les colonnes de manière spécifique. Par exemple, la colonne des ventes Unit Price de revendeur (qui représente un taux unitaire) peut être résumée, mais uniquement à l’aide de fonctions d’agrégation spécifiques. Il ne doit jamais être additionné, mais il est approprié de résumer à l’aide d’autres fonctions d’agrégation telles que min, max ou average. Dans cette instance, le modélisateur peut masquer la Unit Price colonne et créer des mesures pour toutes les fonctions d’agrégation appropriées.

  Cette approche de conception fonctionne bien pour les rapports créés dans le service Power BI et pour Questions et réponses. Toutefois, les connexions dynamiques Power BI Desktop permettent aux auteurs de rapports d’afficher des champs masqués dans le volet Données, ce qui peut entraîner un contournement de cette approche de conception.

Clés de substitution

Une clé de substitution est un identificateur unique que vous ajoutez à une table pour prendre en charge la modélisation de schémas en étoile. Par définition, elle n’est ni définie ni stockée dans les données sources. En règle générale, les clés de substitution sont ajoutées aux tables de dimension des entrepôts de données relationnels afin de fournir un identificateur unique pour chaque ligne de la table de dimension.

Les relations de modèle sémantique Power BI sont basées sur une seule colonne unique d’une table, qui propage les filtres à une seule colonne d’une autre table. Lorsqu’une table de dimension dans votre modèle sémantique n’inclut pas de colonne unique, vous devez ajouter un identificateur unique pour devenir le côté « un » d’une relation. Dans Power BI Desktop, vous pouvez obtenir cette exigence en ajoutant une colonne d’index Power Query.

Vous devez fusionner cette requête avec la requête côté « plusieurs » afin de pouvoir y ajouter également la colonne d’index. Lorsque vous chargez ces requêtes sur le modèle sémantique, vous pouvez ensuite créer une relation un-à-plusieurs entre les tables de modèle.

Dimensions en flocon

Une dimension en flocon est un ensemble de tables normalisées pour une entité métier unique. Par exemple, Adventure Works classe les produits par catégorie et sous-catégorie. Les produits sont affectées à des sous-catégories, et les sous-catégories sont à leur tour affectés à des catégories. Dans l’entrepôt de données relationnelles Adventure Works, la dimension de produit est normalisée et stockée dans trois tables associées : DimProductCategory, DimProductSubcategoryet DimProduct.

En faisant appel à votre imagination, vous pouvez vous figurer les tables normalisées positionnées à l’extérieur de la table de faits, formant une conception en flocon.

Dans Power BI Desktop, vous pouvez choisir d’imiter une conception de dimension flocon (peut-être parce que vos données sources le font) ou de combiner les tables sources pour former une table de modèle dénormalisée unique. En règle générale, une table de modèle unique présente plus d’avantages que plusieurs tables de modèle. La décision la plus optimale peut dépendre des volumes de données et des exigences de facilité d’utilisation du modèle.

Quand vous choisissez de simuler une conception de dimension en flocon :

• Power BI charge davantage de tables, ce qui est moins efficace du point de vue du stockage et des performances. Ces tables doivent inclure des colonnes pour prendre en charge les relations du modèle, ce qui peut agrandir la taille de ce dernier.
• Les chaînes de propagation de filtres de relation plus longues doivent être parcourues, ce qui peut être moins efficace que les filtres appliqués à une seule table.
• Le volet Données présente davantage de tables de modèles aux auteurs de rapports, ce qui peut entraîner une expérience moins intuitive, en particulier lorsque les tables de dimension flocons ne contiennent qu’une ou deux colonnes.
• Il n’est pas possible de créer une hiérarchie qui comprend des colonnes de plusieurs tables.

Quand vous choisissez d’effectuer une intégration à une table de modèle unique, vous pouvez également définir une hiérarchie qui englobe les niveaux de granularité les plus bas et élevé de la dimension. Éventuellement, le stockage de données dénormalisées redondantes peut entraîner une augmentation de la taille de stockage du modèle, en particulier pour les tables de dimension volumineuses.

Dimension à variation lente

Une dimension à variation lente (ou SCD) est une dimension qui gère correctement le changement des membres de dimension au fil du temps. Elle s’applique lorsque les valeurs d’entité métier changent lentement au fil du temps de manière non planifiée. Un bon exemple de SCD est une dimension client, car ses colonnes de détails de contact telles que l’adresse e-mail et le numéro de téléphone changent rarement. En revanche, certaines dimensions sont considérées comme changeant rapidement lorsqu’un attribut de dimension change souvent, comme le prix du marché d’une action. L’approche de conception courante dans ces cas consiste à stocker les valeurs d’attribut à variation rapide dans une mesure de table de faits.

La théorie de la conception de schémas en étoile fait référence à deux types de SCD courants : type 1 et type 2. Une table de dimension peut être type 1 ou type 2, ou prendre en charge les deux types simultanément pour différentes colonnes.

SCD de type 1

Une SCD de Type 1 reflète toujours les valeurs les plus récentes ; ainsi, quand des modifications sont détectées dans les données sources, les données de la table de dimension sont remplacées. Cette approche de conception est courante pour les colonnes qui stockent des valeurs complémentaires, telles que l’adresse e-mail ou le numéro de téléphone d’un client. Quand l’adresse e-mail ou le numéro de téléphone d’un client change, la table de dimension met à jour la ligne du client avec les nouvelles valeurs. C’est comme si le client avait toujours eu ces informations de contact.

Une actualisation non incrémentielle d’une table de dimension de modèle Power BI obtient le résultat d’un SCD de type 1. Elle actualise les données de la table afin que les valeurs les plus récentes soient chargées.

SCD de type 2

Une SCD de Type 2 prend en charge la gestion de versions des membres de dimension. Si le système source ne stocke pas les versions, il s’agit généralement du processus de chargement de l’entrepôt de données qui détecte les modifications et gère correctement la modification dans une table de dimension. Dans ce cas, la table de dimension doit utiliser une clé de substitution pour fournir une référence unique à une version du membre de dimension. Elle comprend également des colonnes qui définissent la validité de la plage de dates de la version (par exemple, StartDate et EndDate) et éventuellement une colonne d’indicateur (par exemple, IsCurrent) pour filtrer facilement en fonction des membres de dimension actuels.

Par exemple, Adventure Works affecte chaque vendeur à une région de vente. Quand un vendeur change de région, une version du vendeur doit être créée pour que les faits historiques restent associés à l’ancienne région. Pour prendre en charge une analyse historique précise des ventes par vendeur, la table de dimension doit stocker les versions des vendeurs et leur(s) région(s) associée(s). La table doit également inclure des valeurs de date de début et de fin pour définir la durée de validité. Les versions actuelles peuvent définir une date de fin vide (ou 12/31/9999), qui indique que la ligne est la version actuelle. La table doit également avoir une clé de substitution, car la clé métier (dans cette instance, l’ID d’employé) ne sera pas unique.

Il est important de comprendre que quand les données sources ne stockent pas de versions, vous devez utiliser un système intermédiaire (comme un entrepôt de données) pour détecter et stocker les modifications. Le processus de chargement de table doit conserver les données existantes et détecter les modifications. Quand une modification est détectée, le processus de chargement de table doit faire expirer la version actuelle. Il enregistre ces modifications en mettant à jour la valeur EndDate et insère une nouvelle version dont la valeur StartDate commence par la valeur EndDate précédente. En outre, les faits connexes doivent utiliser une recherche basée sur le temps pour récupérer la valeur de clé de dimension correspondant à la date de fait. Un modèle sémantique Power BI utilise Power Query et ne peut donc pas produire ce résultat. Toutefois, il peut charger des données à partir d’une table de dimension SCD de type 2 préchargée.

Conseil

Pour savoir comment implémenter une table de dimension SCD Type 2 dans un entrepôt Fabric, consultez Gérer les modifications historiques.

Le modèle sémantique Power BI doit prendre en charge l’interrogation des données historiques pour un membre, quelle que soit la modification et pour une version du membre, qui représente un état particulier du membre dans le temps. Dans le contexte d’Adventure Works, cette conception vous permet d’interroger les données du vendeur, quelle que soit la région de vente affectée, ou pour une version particulière du vendeur.

Pour atteindre cette exigence, la table de dimension de modèle sémantique Power BI doit inclure une colonne pour filtrer l’vendeur et une autre colonne pour filtrer une version spécifique de l’vendeur. Il est important que la colonne de version fournit une description non ambiguë, comme David Campbell (12/15/2008-06/26/2019) ou David Campbell (06/27/2019-Current). Il est également important de former les consommateurs et les auteurs de rapports aux principes de base de la dimension SCD de type 2 et de leur montrer comment obtenir des conceptions de rapport appropriées en appliquant des filtres corrects.

Il s’agit d’une bonne pratique de conception pour inclure une hiérarchie qui permet aux visuels d’explorer le niveau de version.

Dimensions de rôle actif

Une dimension de rôle actif est une dimension qui peut filtrer des faits liés différemment. Par exemple, dans Adventure Works, la table de dimension de date a trois relations avec les faits de vente des revendeurs. La même table de dimension peut être utilisée pour filtrer les faits par date de commande, date d’expédition ou date de livraison.

Dans un entrepôt de données, l’approche de conception acceptée consiste à définir une table de dimension de date unique. Au moment de la requête, le « rôle » de la dimension de date est établi par la colonne de faits que vous utilisez pour joindre les tables. Par exemple, quand vous analysez les ventes par date de commande, la jointure de la table est associée à la colonne des dates de commandes client des revendeurs.

Dans un modèle sémantique Power BI, cette conception peut être imitée en créant plusieurs relations entre deux tables. Dans l’exemple Adventure Works, les tables Date et Reseller Sales auraient trois relations.

Bien que cette conception soit possible, il ne peut y avoir qu’une seule relation active entre deux tables de modèle sémantique Power BI. Toutes les autres relations doivent être définies comme étant inactives. La présence d’une relation active unique signifie qu’il existe une propagation de filtre par défaut de la date aux ventes de revendeurs. Dans cette instance, la relation active est définie sur le filtre le plus courant utilisé par les rapports, qui, dans Adventure Works, est la relation de date de commande.

La seule façon d’utiliser une relation inactive consiste à définir une expression Dax qui utilise la fonction USERELATIONSHIP. Dans notre exemple, le développeur de modèle doit créer des mesures pour permettre l’analyse des ventes des revendeurs par date d’expédition et date de livraison. Ce travail peut être fastidieux, en particulier quand la table des revendeurs définit de nombreuses mesures. Il crée également un volet Données encombrés qui a une surabondance de mesures. Il existe également d’autres limitations :

• Lorsque les auteurs de rapports s’appuient sur la synthèse des colonnes plutôt que sur la définition de mesures, ils ne peuvent pas obtenir de résumé pour les relations inactives sans écrire de mesure au niveau du rapport. Les mesures au niveau du rapport peuvent être définies uniquement lors de la création de rapports dans Power BI Desktop.
• Avec un seul chemin de relation actif entre les données des ventes des revendeurs et les données des dates, il n’est pas possible de filtrer simultanément les ventes des revendeurs par différents types de dates. Par exemple, vous ne pouvez pas produire un visuel qui trace les ventes par date de commande par ventes livrées.

Pour surmonter ces limitations, une technique de modélisation Power BI commune consiste à créer une table de dimension pour chaque instance de jeu de rôles. Vous pouvez créer chaque table de dimension en tant que requête de référencement à l’aide de Power Query ou d’une table calculée à l’aide de DAX. Le modèle peut contenir une Date table, une Ship Date table et une Delivery Date table, chacune avec une relation unique et active avec leurs colonnes de table de ventes de revendeur respectives.

Cette approche de conception ne nécessite pas que vous définissiez plusieurs mesures pour différents rôles de date et autorise un filtrage simultané par différents rôles de date. Toutefois, un prix mineur à payer avec cette approche de conception est qu’il y aura une duplication de la table de dimension de date, ce qui entraîne une augmentation de la taille de stockage du modèle. Étant donné que les tables de dimension stockent généralement moins de lignes par rapport aux tables de faits, il s’agit rarement d’un problème.

Nous vous recommandons de suivre les bonnes pratiques de conception lors de la création de tables de dimension de modèle pour chaque rôle :

• Assurez-vous que les noms de colonne sont explicites. Bien qu’il soit possible d’avoir une Year colonne dans toutes les tables de dates (les noms de colonnes sont uniques dans leur table), il n’est pas auto-décrivant par défaut les titres visuels. Envisagez de renommer des colonnes dans chaque table de rôles de dimension afin que la Ship Date table ait une colonne d’année nommée Ship Year, et ainsi de suite.
• En cas de pertinence, assurez-vous que les descriptions de table fournissent des commentaires aux auteurs de rapports (via des info-bulles du volet de données ) sur la configuration de la propagation du filtre. Cette clarté est importante lorsque le modèle contient une table nommée génériquement, telle Dateque , utilisée pour filtrer de nombreuses tables de faits. Dans le cas où cette table a, par exemple, une relation active avec la colonne de date de la commande client du revendeur, envisagez de fournir une description de table comme Filters reseller sales by order date.

Pour plus d’informations, consultez Guide des relations actives et inactives.

Dimensions fourre-tout

Une dimension fourre-tout est utile quand il existe de nombreuses dimensions, en particulier composées de quelques attributs (peut-être un seul) ayant peu de valeurs. Les bons candidats incluent des colonnes d’état des commandes ou des colonnes démographiques client comme le sexe ou le groupe d’âge.

L’objectif de conception d’une dimension de courrier indésirable consiste à consolider de nombreuses petites dimensions en une seule dimension afin de réduire la taille de stockage du modèle et de réduire également l’encombrement du volet données en exposant moins de tables de modèle.

Une table de dimension indésirable est généralement le produit cartésien de tous les membres d’attribut de dimension, avec une colonne clé de substitution pour identifier de manière unique chaque ligne. Vous pouvez générer la dimension dans un entrepôt de données, ou en utilisant Power Query pour créer une requête qui effectue des jointures de requêtes externes entières, puis ajoute une clé de substitution (colonne d’index).

Vous chargez cette requête sur le modèle en tant que table de dimension. Vous devez également fusionner cette requête avec la requête de fait afin que la colonne d’index soit chargée sur le modèle pour prendre en charge la création d’une relation de modèle « un-à-plusieurs ».

Dimensions dégénérées

Une dimension dégénérée fait référence à un attribut de la table de faits requise pour le filtrage. Dans Adventure Works, le numéro de commande client des revendeurs est un bon exemple. Dans cette instance, il n’est pas judicieux de créer une table indépendante composée de cette seule colonne, car elle augmenterait la taille de stockage du modèle et entraînerait un encombrement du volet Données .

Dans le modèle sémantique Power BI, il peut être approprié d’ajouter la colonne numéro de commande client à la table de faits pour autoriser le filtrage ou le regroupement par numéro de commande client. Il s’agit d’une exception à la règle précédemment introduite que vous ne devez pas combiner de types de tables (généralement, les tables de modèle doivent être soit dimension ou fait).

Toutefois, si la table des ventes des revendeurs Adventure Works a un numéro de commande et des colonnes de numéros de ligne de commande, et qu’elle est requise pour le filtrage, la création d’une table de dimension dégénérée serait une bonne conception. Pour plus d’informations, consultez l’Aide sur les relations un-à-un (dégénérer les dimensions).

Tables de faits sans faits

Une table de faits sans faits n’inclut aucune colonne de mesure. Elle contient uniquement des clés de dimension.

Une table de faits sans faits peut stocker les observations définies par les clés de dimension. Par exemple, à une date et une heure particulières, un client particulier s’est connecté à votre site web. Vous pouvez définir une mesure pour compter les lignes de la table de faits factless pour effectuer une analyse du moment et du nombre de clients connectés.

Une utilisation plus attrayante d’une table de faits factless consiste à stocker des relations entre les dimensions, et il s’agit d’une approche de conception de modèle sémantique Power BI que nous vous recommandons de définir des relations de dimension plusieurs-à-plusieurs. Dans une conception de relation de dimension plusieurs-à-plusieurs, la table de faits sans faits est appelée table de pontage.

Par exemple, considérez que les vendeurs peuvent être attribués à une ou plusieurs régions de vente. La table de pontage est conçue comme une table de faits sans faits composée de deux colonnes : clé de vendeur et clé de région. Les valeurs dupliquées peuvent être stockées dans les deux colonnes.

Cette approche de conception plusieurs-à-plusieurs est bien documentée et peut être obtenue sans table de pontage. Toutefois, l’approche de table de pontage est considérée comme la meilleure pratique lors de la liaison de deux dimensions. Pour plus d’informations, consultez l’aide sur les relations plusieurs-à-plusieurs (associer deux tables de type dimension).

Contenu connexe

Pour plus d’informations sur la conception de schéma en étoile ou la conception de modèle sémantique Power BI, consultez les articles suivants :

• Article Wikipedia sur la modélisation dimensionnelle
• Relations de modèle dans Power BI Desktop
• Aide pour la relation un-à-un
• Conseils sur les relations Plusieurs-à-plusieurs
• Aide pour les relations bidirectionnelles
• Aide pour les relations actives et inactives
• Modélisation dimensionnelle dans Microsoft Fabric Warehouse
• Des questions ? Essayez de demander à la communauté Fabric
• Vous avez des suggestions ? Contribuer aux idées pour améliorer Fabric