Tables de faits & dimensions :
structurer pour analyser
Avant de se lancer dans Power Query ou dans du DAX, il est essentiel de maîtriser un point clé : la structure des tables de faits et des dimensions. Ces deux types de tables définissent non seulement la logique de votre modèle, mais aussi la facilité avec laquelle vos utilisateurs pourront explorer et analyser leurs données.
1. Table de faits : là où tout se mesure
La table de faits, c’est l’endroit où l’on calcule. C’est elle qui contient les données que vous additionnez, comptez, comparez, moyenez.
Une bonne table de faits doit être :
- A la maille la plus fine possible,
- Composée uniquement de dates, de codes et de montants,
- Dépourvue d’attributs métiers (noms, adresses, pays, catégories…).
👉 Ces attributs n’ont rien à faire dans des millions de lignes. 👉 Ils vivent dans les dimensions, là où ils ne sont stockés qu’une seule fois.
Les dates permettent de se relier à la table calendrier. Les codes relient la table de faits à ses dimensions. Les montants sont utilisés dans les mesures.
« C’est tout. Simple, propre, efficace. »
2. Les dimensions : vos axes d’analyse
Les dimensions servent à décrire les faits : le temps, les produits, les clients, les zones, les catégories…
Elles contiennent :
- Un code (clé primaire),
- Des attributs pour filtrer, regrouper et comprendre.
Exemple sur les produits :
- Un code produit,
- Une catégorie,
- Une sous-catégorie.
Une fois cette organisation en place, la table de faits peut être entièrement masquée : les utilisateurs filtreront via les dimensions, et les mesures feront le reste.
3. Structure : une colonne = un seul sens
Pour les tables de faits, la règle est simple : une colonne doit toujours représenter une seule information.
❌ Exemple à éviter :
- Colonne France
- Colonne Allemagne
- Colonne Italie … chacune contenant des montants.
Dans ce cas, chaque colonne a deux sens : pays + valeur → structure inutilisable dans un modèle propre.
✔️ À la place :
- Une colonne Pays
- Une colonne Montant
4. Une seule granularité par table
Si vos données n’ont pas le même niveau de détail, ne les mélangez pas dans la même table.
Exemple :
- Des ventes au jour
- Un budget au mois
Ce sont deux tables de faits différentes.
💡 Astuce : pour éviter les relations plusieurs-à-plusieurs : Convertir les périodes en date. Par exemple, janvier devient une date (1er jour du mois), le budget annuel devient une date également au 1er janvier, etc. Ainsi, toutes les tables se relient proprement à la table calendrier par la date.
5. Exemple concret : étoile dégradée vs flocon propre
Dans la vraie vie, on rencontre souvent ce cas :
- Des transactions journalières / Un budget mensuel,
- Des ventes à la maille fine des produits / Un budget par catégorie, etc…
- Et une volonté de tout relier pour pouvoir les comparer.
On a alors deux possibilités :
- 👉 Un modèle en flocon,
- 👉 Ou un modèle en étoile… mais avec des relations plusieurs-à-plusieurs.
Version 1 — Modélisation en étoile… mais relations plusieurs-à-plusieurs
Ici, tout semble “bien” visuellement (une étoile), mais :
- Le budget n’a pas la même granularité que les factures,
- Les mêmes dimensions sont utilisées pour filtrer les deux,
- J’ai créé des relations plusieurs-à-plusieurs (unidirectionnelles bien entendu) pour les relier.
👉 Le modèle fonctionne, mais cela peut ne pas convenir à tous les cas de figure, notamment en cas de forte volumétrie (par exemple >10 000 valeurs distinctes sur une dimension).
Version 2 — Modélisation en flocon : propre, cohérente, sans M2M
En séparant davantage les tables et en introduisant la bonne granularité (ex : budgets mensuels alignés sur une date = 1er du mois, à la maille des modèles et des concessions), on obtient un modèle “en flocon” :
- Les tables de dimension sont mieux structurées,
- Chaque fait est filtré par la bonne dimension,
- Toutes les relations redeviennent 1→*,
- Aucune relation plusieurs-à-plusieurs.
👉 Le résultat :
- Modèle plus stable,
- Filtres plus clairs,
- Mesures plus simples,
- Sans dégrader les performances, au contraire.
- Attention à bien remettre les bons attributs dans les bonnes dimensions au moment de la séparation 😉
En résumé
Les tables de faits et les dimensions sont le socle d’un modèle Power BI performant et réellement orienté Self-Service BI. Une bonne séparation des rôles, des faits minimalistes, des dimensions bien construites et des granularités cohérentes simplifient tout : les relations, le DAX, les performances et l’expérience utilisateur.
Avant d’incorporer vos données, posez-vous une question simple :
“Mes tables permettent-elles aux utilisateurs de comprendre et d’explorer les faits facilement, sans effort et sans ambiguïté ?”
C’est souvent ici que se joue la différence entre un modèle fragile… et un modèle robuste, durable et agréable à utiliser.
🗓️ Prochain article : « Power Query : un modèle propre et documenté »
Nous verrons :
- Comment organiser vos requêtes intelligemment,
- Comment documenter votre modèle dès Power Query,
- Quelles bonnes pratiques appliquent les pros,
- Et comment préparer un modèle clair, stable et facile à maintenir.
🔗 Retrouvez la série facilement via le tag : SelfServiceBI