Modélisation dimensionnelle : faits et dimensions
Le schéma en étoile place les mesures dans une table de faits entourée de dimensions descriptives. On le choisit pour des tableaux de bord simples à requêter et rapides à agréger.
- kimball
- étoile
- star schema
- fait
- dimension
- grain
- clé de substitution
Syntaxe
┌────────────┐ │ dim_date │ └─────┬──────┘┌─────────────┐ ┌─────┴──────┐ ┌─────────────┐│ dim_magasin ├─┤fait_ventes ├─┤ dim_produit │└─────────────┘ └────────────┘ └─────────────┘Table de faits : un événement mesuré, au grain déclaré clés vers les dimensions + mesures additives (quantité, montant)Dimension : le contexte pour filtrer et regrouper (qui, quoi, où, quand) une clé de substitution + des attributs descriptifsExemple
CREATE TABLE dim_produit (produit_sk INTEGER PRIMARY KEY, libelle TEXT, rayon TEXT);CREATE TABLE dim_magasin (magasin_sk INTEGER PRIMARY KEY, ville TEXT);CREATE TABLE dim_date (date_sk INTEGER PRIMARY KEY, jour TEXT, mois TEXT);-- Grain : une ligne = un produit sur un ticket de caisseCREATE TABLE fait_ventes ( date_sk INTEGER, magasin_sk INTEGER, produit_sk INTEGER, quantite INTEGER, montant REAL);INSERT INTO dim_produit VALUES (1, 'Café moulu', 'Épicerie'), (2, 'Thé vert', 'Épicerie'), (3, 'Mug', 'Maison');INSERT INTO dim_magasin VALUES (1, 'Lyon'), (2, 'Nantes');INSERT INTO dim_date VALUES (20261030, '2026-10-30', '2026-10'), (20261031, '2026-10-31', '2026-10');INSERT INTO fait_ventes VALUES (20261030, 1, 1, 2, 9.80), (20261030, 1, 3, 1, 7.50), (20261031, 2, 1, 1, 4.90), (20261031, 2, 2, 3, 11.70), (20261031, 1, 2, 1, 3.90);-- Chiffre d'affaires d'octobre par ville et par rayonSELECT m.ville, p.rayon, SUM(f.quantite) AS quantite, ROUND(SUM(f.montant), 2) AS caFROM fait_ventes fJOIN dim_magasin m ON m.magasin_sk = f.magasin_skJOIN dim_produit p ON p.produit_sk = f.produit_skJOIN dim_date d ON d.date_sk = f.date_skWHERE d.mois = '2026-10'GROUP BY m.ville, p.rayonORDER BY ca DESC;-- Nantes | Épicerie | 4 | 16.6-- Lyon | Épicerie | 3 | 13.7-- Lyon | Maison | 1 | 7.5À retenir
- Déclarez le grain avant toute colonne : « une ligne par produit et par ticket » décide de ce qu'on peut additionner et évite de mélanger des lignes de détail et des totaux.
- Les dimensions utilisent une clé de substitution (entier sans signification) plutôt que la clé de la source : elle survit à un changement de système et permet d'historiser (SCD de type 2).
- Une dimension date pré-remplie (jour, semaine, mois, jour férié) évite de recalculer ces attributs dans chaque requête et rend les filtres lisibles.
- Piège : additionner une mesure semi-additive comme un stock ou un solde sur plusieurs jours. On l'additionne entre magasins, mais dans le temps on prend la dernière valeur ou une moyenne.
Voir aussi
- Dimensions à variation lente (SCD)Une SCD gère les attributs de dimension qui changent rarement, comme la ville d'un client. Le type 1 écrase la valeur, le type 2 garde chaque version pour analyser le passé tel qu'il était.
- dbt : modèles, ref, sources et testsdbt transforme des requêtes SELECT versionnées en tables ou vues, dans le bon ordre et avec des tests. On l'emploie pour organiser la couche de transformation d'un entrepôt en ELT.
- ETL et ELTL'ETL transforme les données avant de les charger, l'ELT les charge brutes puis les transforme en SQL dans l'entrepôt. L'ELT domine depuis que les entrepôts cloud calculent à la demande.