Modèle en étoile Power BI : concevoir des relations qui donnent les bons totaux

Écrire le grain avant de tracer les relations

« Une ligne correspond à une ligne de facture » est un grain exploitable. « Une ligne correspond aux ventes » reste ambigu. Précisez si un produit peut apparaître plusieurs fois dans une facture, comment les avoirs sont représentés et quelle date porte l’événement.

Dans un exemple fictif, la table FaitVente contient une ligne par détail de facture. Les dimensions Client, Produit et Date décrivent les axes de lecture. Les objectifs mensuels appartiennent à un autre grain. Les joindre comme s’ils étaient des ventes détaillées peut répéter les objectifs autant de fois qu’il existe de lignes.

Séparer faits et dimensions

Les dimensions doivent présenter des identifiants cohérents avec les faits. Le côté « un » d’une relation exige une clé unique dans le scénario correspondant. Une clé dupliquée est un signal à examiner, pas une invitation à passer immédiatement en plusieurs-à-plusieurs.

Référence technique : Microsoft : schéma en étoile pour Power BI ; Microsoft : relations des modèles

Pourquoi une jointure peut doubler le chiffre d’affaires

Supposons qu’une vente de 100 euros référence un produit présent deux fois dans un référentiel. Une fusion mal maîtrisée peut produire deux lignes de 100 euros. Le total devient 200 sans nouvelle vente. Le graphique n’a aucun moyen de deviner que l’une de ces lignes est indésirable.

Comptez les lignes et comparez les montants avant et après chaque rapprochement. Recherchez les clés dupliquées et les clés sans correspondance. Si une relation plusieurs-à-plusieurs est justifiée par le métier, modélisez-la explicitement et testez la propagation des filtres. Ne l’utilisez pas pour masquer un référentiel incohérent.

Traiter les dates comme une dimension métier

Une commande peut avoir une date de saisie, une date de livraison et une date de facturation. Le rapport doit préciser laquelle pilote chaque indicateur. Une dimension Date facilite les regroupements, mais il faut encore organiser les relations et mesures en fonction des rôles temporels.

Microsoft documente les propriétés attendues des tables de dates et les approches possibles. Vérifiez notamment la continuité des dates et l’unicité lorsque votre scénario l’exige. Décidez aussi du calendrier métier : mois calendaires, exercice décalé ou autres conventions. Une date techniquement valide peut appartenir à la mauvaise période de gestion.

Référence technique : Microsoft : tables de dates

Les contrôles à conserver dans la recette

Conservez des exemples dont le résultat est attendu et explicable. Une comparaison globale seule peut manquer des erreurs qui se compensent. Vérifiez plusieurs découpes métier et notez les écarts que vous avez acceptés.

1. Documenter le grain de chaque fait.
2. Contrôler l’unicité des clés de dimensions et les références manquantes.
3. Comparer un total global à la source.
4. Rejouer le même contrôle sous un filtre produit, client et période.
5. Tester les cas sans données et les changements de référentiel.

Quand déplacer le travail vers la plateforme Data ?

Si plusieurs rapports recréent les mêmes dimensions ou corrigent les mêmes codes, préparez des données partagées en amont. Cela réduit le nombre d’endroits où une règle doit changer. Ce déplacement demande toutefois un propriétaire et des tests, sinon vous centralisez une erreur.

Pour comprendre le rôle des calculs, consultez DAX et Power Query. Pour un indicateur concret, le guide Power BI fournit un point de départ. La gouvernance des données aide à attribuer les définitions et les responsabilités.