Le schéma en étoile est la façon recommandée d'organiser les données d'un modèle sémantique Power BI. Il rend le modèle plus rapide, les mesures DAX plus simples et le volet Données plus lisible pour les auteurs de rapports. La plupart des difficultés rencontrées en DAX viennent d'un modèle qui ne respecte pas cette organisation.

Un schéma en étoile place au centre une table de faits, entourée de tables de dimension.

Dans l'exemple ci-dessous (en anglais), les ventes (Sales) sont les faits : quantité (Order Quantity) et montant (Sales Amount). Les autres tables sont des dimensions : produit (Product), client (Customer), etc. Toutes leurs colonnes offrent des regroupements possibles : vous pouvez ainsi afficher la somme des montants par produit, par catégorie (Category) ou par couleur (Color).

La clé de la dimension (ProduitClé, ProduitID) se retrouve dans la table de faits et sert à créer la relation. Dans un modèle Power BI, ce n'est pas le nom de la table qui fait d'elle une dimension ou un fait, mais sa place dans la relation : la dimension est du côté « un », la table de faits du côté « plusieurs » (à un produit correspondent plusieurs ventes). Voir la page Relations.

La normalisation consiste à stocker les données de façon à éviter les répétitions. Dans l'exemple ci-dessous, la table des lignes de commande (à gauche) est normalisée : chaque produit vendu y figure par sa clé, et ses caractéristiques sont dans la table Produit (à droite).

Une version dénormalisée des deux tables, obtenue en les liant par la colonne ProduitClé, se présente ainsi :

Un schéma en étoile est un compromis : les faits restent séparés des dimensions, mais chaque dimension est dénormalisée en une seule table. Si vos données proviennent d'une extraction « à plat », utilisez Power Query pour séparer les faits et les dimensions.

Dans le vocabulaire dimensionnel, une mesure est une colonne de faits qui stocke les valeurs à totaliser. Dans Power BI, une mesure est une formule DAX qui réalise cette totalisation au moment de la requête et renvoie une valeur unique. Masquez les colonnes numériques des tables de faits et créez des mesures explicites : vous contrôlez ainsi l'agrégation (un prix unitaire ne doit jamais être additionné).

Une relation exige une colonne sans doublon du côté de la dimension. Si la dimension n'en possède pas, ajoutez une colonne d'index dans Power Query (Ajouter une colonne > Colonne d'index, fonction M Table.AddIndexColumn), puis reportez-la dans la table de faits par une fusion avant de créer la relation. La page Slowly Changing Dimension détaille la différence entre clé de substitution et clé naturelle.

Une dimension en flocon est un ensemble de tables normalisées pour une même entité, par exemple Catégorie, Sous-catégorie et Produit. Microsoft recommande de les fusionner en une seule table de dimension : le modèle est plus performant, le volet Données plus clair, et vous pouvez créer une hiérarchie Catégorie > Sous-catégorie > Produit, impossible entre plusieurs tables.

[Capture : vue Modèle avec trois tables Catégorie, Sous-catégorie et Produit reliées en chaîne (flocon), à côté d'une table Produit unique avec sa hiérarchie]

Une même dimension peut jouer plusieurs rôles, par exemple la table de dates pour la date de commande et la date d'expédition. Deux approches existent :

La page Table de dates compare les deux approches et montre leur mise en œuvre.

Une dimension fourre-tout regroupe en une seule table plusieurs petites dimensions aux valeurs peu nombreuses : état de commande, sexe, groupe d'âge. Elle allège le modèle et réduit le nombre de tables exposées. On part du produit cartésien de toutes les valeurs, on ajoute une clé de substitution, puis on reporte cette clé dans la table de faits par fusion. Dans Power Query, le produit cartésien s'obtient par des jointures externes entières, puis une colonne d'index.

Une dimension dégénérée est un attribut de la table de faits utilisé pour filtrer ou regrouper, comme le numéro de commande. On le laisse dans la table de faits plutôt que de créer une table à part : c'est une exception admise à la séparation entre faits et dimensions.

Une table de faits sans faits ne contient que des clés de dimension, sans colonne à totaliser. Elle sert à enregistrer des événements (les connexions d'un client à un site web, que l'on compte), ou de table pont entre deux dimensions liées en plusieurs-à-plusieurs, par exemple entre commerciaux et régions. La page Sécurité RLS et OLS en montre un usage avec une table de droits.

Le modèle de vente du support contient une table de faits Ventes (date, clé produit, clé client, quantité, montant) et trois dimensions : Date, Produit (avec catégorie et sous-catégorie fusionnées) et Client. Chaque dimension est reliée à Ventes par une relation un-à-plusieurs, à sens unique. Les colonnes Quantité et Montant sont masquées, et les mesures Quantité vendue et CA HT les remplacent.