"Le modèle de données Power BI : anatomie d'un schéma en étoile bien construit"

La plupart des échecs de projets Power BI ne tiennent pas à la complexité des formules DAX, mais à un modèle de données mal construit. Le schéma en étoile — l'approche de modélisation dimensionnelle popularisée par Ralph Kimball — est la structure qui fonctionne le plus efficacement avec le moteur de Power BI. Cet article aborde le schéma en étoile, les tables de faits et de dimensions, les décisions de direction des relations et les erreurs fréquentes, dans une perspective d'entreprise.

01. Pourquoi le schéma en étoile ? Le point de vue du moteur VertiPaq

Le cœur de Power BI est VertiPaq, un moteur de compression en colonnes. Il compresse et stocke les données colonne par colonne, et traite les requêtes en parallèle.

VertiPaq compresse très efficacement les valeurs répétées : dans une table de 10 millions de lignes, si la colonne « Catégorie de produit » ne contient que 8 valeurs distinctes, le taux de compression atteint 99 %. Mais si cette même colonne est conservée dans une table « à plat », fusionnée avec le nom du produit et les informations fournisseur, le motif de répétition se casse et la compression chute brutalement.

Le schéma en étoile maximise précisément cette compression : il isole les attributs répétitifs dans des tables de dimensions et conserve les événements mesurables dans la table de faits. Résultat : un modèle 5 à 10 fois plus petit et des requêtes 3 à 5 fois plus rapides.

02. Tables de faits et de dimensions : regard anatomique

La table de faits conserve les événements métier mesurables : ventes, commandes, encaissements, production. Chaque ligne représente un événement et contient :

• des mesures numériques (quantité, montant, coût, nombre) ;
• des clés étrangères pointant vers les tables de dimensions.

La table de dimensions conserve les axes « qui, quoi, où, quand » de l'événement :

• Client (nom, secteur, ville)
• Produit (référence, catégorie, marque)
• Date (année, trimestre, mois, jour, indicateur de jour férié)
• Magasin ou entrepôt (emplacement, région, type)

Dans un schéma en étoile idéal, la table de faits est étroite et longue (des millions de lignes mais seulement 8 à 15 colonnes), tandis que les tables de dimensions sont larges et courtes (des milliers de lignes, 20 à 40 colonnes).

03. La dimension Date : un standard incontournable

Tout modèle Power BI sérieux doit comporter une table de dimension Date distincte. Ce n'est pas un petit détail : c'est une brique indispensable au fonctionnement des fonctions DAX de time intelligence (YTD, SAMEPERIODLASTYEAR, DATESYTD, PARALLELPERIOD).

Une table Date correcte :

• couvre une plage de dates continue sur la période d'analyse (une ligne par jour) ;
• est marquée comme « table de dates » dans le modèle ;
• comporte les colonnes année, trimestre, nom du mois, numéro du mois, semaine, jour, indicateur de jour ouvré ;
• établit une relation un-à-plusieurs avec les champs date des tables de faits.

Sans table Date, vous ne pouvez pas écrire de DAX de time intelligence ; et si vous le faites malgré tout, les résultats seront imprévisibles.

04. Direction des relations et cardinalité

Établir une relation entre deux tables suppose trois décisions :

• la cardinalité (un-à-plusieurs, un-à-un, plusieurs-à-plusieurs) ;
• le sens du filtre croisé (simple ou bidirectionnel) ;
• le caractère actif ou inactif de la relation.

Dans un schéma en étoile standard, toutes les relations doivent être en un-à-plusieurs (de la dimension vers les faits) et à sens unique. La relation bidirectionnelle paraît séduisante, mais elle complexifie le modèle, ralentit les requêtes et produit des comportements inattendus sur les totaux.

Les relations plusieurs-à-plusieurs sont particulièrement à éviter ; si elles sont réellement nécessaires, il faut les convertir en relations à sens unique via une table de liaison. Il ne peut y avoir qu'une seule relation active entre deux tables ; pour une seconde, la fonction USERELATIONSHIP est nécessaire.

05. Le schéma en flocon : quand est-il acceptable ?

Le schéma en flocon est une structure où les tables de dimensions se subdivisent elles-mêmes en sous-dimensions (Produit → Catégorie → Catégorie principale). La théorie classique le privilégiait pour sa normalisation.

Dans Power BI, le flocon réduit l'avantage de compression de VertiPaq et complique l'écriture du DAX. Règle générale : dénormalisez autant que possible les tables de dimensions (préférez une seule table large).

Le flocon reste acceptable lorsqu'une même sous-dimension est partagée par plusieurs dimensions principales — par exemple si « Région » vaut à la fois pour « Client » et pour « Magasin ». Une table Région distincte reste alors plus propre que la dénormalisation.

06. Cinq erreurs de modélisation fréquentes

Les erreurs les plus courantes rencontrées sur le terrain :

• Fusionner faits et dimensions dans une seule table (modèle à plat) : les performances s'effondrent et la compression diminue
• Utiliser la colonne date de la table de faits comme dimension Date : la time intelligence se casse
• Placer des champs numériques dans une dimension : les mesures comme le montant ou le prix doivent impérativement se trouver dans la table de faits
• Rendre les relations bidirectionnelles : complexité et lenteur
• Utiliser une clé composite : plutôt que de fabriquer une clé à partir de deux champs, il faut produire une clé de substitution unique à la source

Corriger ces cinq erreurs améliore d'un facteur deux à trois la taille comme la vitesse du modèle.

07. Valider le modèle : Vertipaq Analyzer et bonnes pratiques

Ne vous contentez pas de construire le modèle : mesurez son comportement. Vertipaq Analyzer, outil gratuit intégré à DAX Studio, montre l'espace occupé par chaque colonne. Les colonnes les plus volumineuses sont généralement :

• du texte à forte cardinalité (nom de client, description de produit) ;
• des colonnes date-heure (l'heure est conservée alors que la date suffirait) ;
• des colonnes d'identifiants (uniques, donc incompressibles).

Le Best Practices Analyzer, dans Tabular Editor, vérifie automatiquement les bonnes pratiques du schéma en étoile et liste les manquements. Il doit être exécuté avant chaque mise en production.