Le problème de la table plate
Beaucoup d’exports ressemblent à notre fichier ventes_plat.csv : une seule grande table où chaque ligne de vente répète le nom du magasin, sa région, le nom du produit, sa catégorie… Cela fonctionne pour un petit fichier, mais pose vite des problèmes :
- redondance : « Auvergne-Rhône-Alpes » est répété à chaque vente de Lyon ;
- incohérences : si une ligne écrit « Lyon » et une autre « LYON », vous obtenez deux magasins ;
- difficulté à ajouter d’autres faits : comment relier des objectifs mensuels par magasin à une table de ventes au détail ?
- calculs plus complexes en DAX, et des performances moins bonnes sur de gros volumes.
La solution, issue de la modélisation dimensionnelle (popularisée par Ralph Kimball), est le schéma en étoile.
Faits et dimensions
Une table de faits enregistre des événements que l’on mesure : une vente, une commande, un appel, une écriture comptable. Elle contient :
- des clés vers les dimensions (
CodeMagasin,CodeProduit,Date) ; - des valeurs numériques à agréger (
Quantite,PrixUnitaire,Montant) ; - beaucoup de lignes, et elle grandit avec le temps.
Une table de dimension décrit le contexte : qui, quoi, où, quand. Elle contient :
- une clé unique (une ligne par magasin, par produit, par jour) ;
- des attributs descriptifs pour filtrer et regrouper (
Region,Categorie,Mois) ; - relativement peu de lignes.
Dans notre fichier : FaitVentes (NumVente, Date, DateLivraison, CodeMagasin, CodeProduit, Quantite, PrixUnitaire), DimMagasin (CodeMagasin, Magasin, Region), DimProduit (CodeProduit, Produit, Categorie) et une table de dates.
La granularité
La granularité (grain) répond à la question : « que représente une ligne de la table de faits ? ». Ici : une ligne = un produit vendu dans un magasin lors d’une vente. Des objectifs, eux, sont définis par magasin et par mois : c’est une autre granularité, donc une autre table de faits.
Déclarez toujours la granularité avant de construire un modèle : mélanger deux granularités dans une même table conduit à des totaux faux.
L’étoile
DimProduit
|
DimMagasin — FaitVentes — Dates
Les dimensions entourent la table de faits et sont reliées directement à elle par des relations un-à-plusieurs (une ligne de dimension, plusieurs lignes de faits). Les filtres « descendent » des dimensions vers les faits : choisir la région Hauts-de-France filtre les ventes de Lille.
Si l’on reliait DimProduit à une table DimCategorie séparée, on obtiendrait un flocon (snowflake). Power BI le supporte, mais on préfère généralement aplatir la catégorie dans DimProduit : moins de relations, des filtres plus simples, un modèle plus lisible.
Avec un bon modèle, les mesures restent simples :
Total ventes = SUM ( FaitVentes[Montant] )
et fonctionnent quel que soit l’axe d’analyse choisi (magasin, produit, mois).
Exercices
Les solutions et les tests restent sur le serveur. Dans l'espace étudiant, ton code est exécuté et corrigé, et le tuteur donne des indices avant la solution.
Analyser la table plate
Jeu de données du cours : créez avec le Bloc-notes
C:\Formation\ventes_plat.csv(UTF-8) :NumVente,Date,DateLivraison,CodeMagasin,Magasin,Region,CodeProduit,Produit,Categorie,Quantite,PrixUnitaire V001,2026-01-03,2026-01-05,M1,Lyon,Auvergne-Rhône-Alpes,P01,Jus d'orange,Boissons,10,3 V002,2026-01-03,2026-01-06,M2,Lille,Hauts-de-France,P02,Pates,Epicerie,20,2 V003,2026-01-10,2026-01-12,M3,Nantes,Pays de la Loire,P03,Yaourt,Frais,30,1 V004,2026-01-17,2026-01-19,M1,Lyon,Auvergne-Rhône-Alpes,P04,Riz,Epicerie,15,2 V005,2026-01-24,2026-01-27,M2,Lille,Hauts-de-France,P05,Eau,Boissons,50,1 V006,2026-02-02,2026-02-04,M3,Nantes,Pays de la Loire,P01,Jus d'orange,Boissons,12,3 V007,2026-02-07,2026-02-09,M1,Lyon,Auvergne-Rhône-Alpes,P06,Fromage,Frais,8,6 V008,2026-02-14,2026-02-16,M2,Lille,Hauts-de-France,P03,Yaourt,Frais,25,1 V009,2026-02-21,2026-02-24,M3,Nantes,Pays de la Loire,P02,Pates,Epicerie,18,2 V010,2026-02-28,2026-03-03,M1,Lyon,Auvergne-Rhône-Alpes,P05,Eau,Boissons,40,1 V011,2026-03-06,2026-03-09,M2,Lille,Hauts-de-France,P04,Riz,Epicerie,10,2 V012,2026-03-13,2026-03-16,M3,Nantes,Pays de la Loire,P06,Fromage,Frais,5,6- Importez le fichier dans Power BI Desktop (table VentesPlat).
- Dans la vue Tableau, comptez le nombre de valeurs distinctes de
CodeMagasinet deCodeProduit(sélectionnez la colonne : la barre d’état ou le profil de colonne Power Query l’indique). - Classez chacune des 11 colonnes en : clé, attribut de dimension ou valeur de fait.
- Rédigez la granularité de la table en une phrase.
- Le nombre de magasins distincts est 3 et de produits distincts 6
- Region, Magasin, Produit, Categorie sont classés en attributs de dimension
- Quantite et PrixUnitaire sont classés en valeurs de fait
- La granularité mentionne vente, produit et magasin
Fait ou dimension ?
Laquelle de ces colonnes a sa place dans une table de faits ?
- Nom de la région
- Catégorie du produit
- Quantité vendue
- Nom du mois
Granularités différentes
Vous avez des ventes au jour par produit et des objectifs au mois par magasin. Que faites-vous ?
- Les mettre dans la même table
- Créer deux tables de faits reliées aux dimensions communes
- Supprimer les objectifs
- Dupliquer les objectifs sur chaque vente
Quiz de fin de leçon
Que décrit une table de dimension ?
- Les événements mesurés
- Le contexte : qui, quoi, où, quand
- Les mesures DAX
Dans un schéma en étoile, comment sont reliées les dimensions ?
- Directement à la table de faits
- Entre elles en chaîne
- Elles ne sont pas reliées
Qu’est-ce que la granularité ?
- Le nombre de colonnes
- Ce que représente une ligne de la table de faits
- La taille du fichier
La suite du cours
- Construire les tables de faits et de dimensions avec Power Query20 min
- Relations : cardinalité, direction de filtrage, relations actives20 min
- La table de dates20 min
- Bonnes pratiques : multi-faits, lisibilité et modes de stockage20 min