Qu'est-ce que la modélisation dimensionnelle ?
La modélisation dimensionnelle est une technique de conception de bases de données optimisée pour les requêtes analytiques. Contrairement aux bases de données transactionnelles normalisées (OLTP), les modèles dimensionnels sont volontairement dénormalisés pour maximiser les performances de lecture et faciliter la compréhension par les utilisateurs métier.
Développée par Ralph Kimball dans les années 1990, cette approche structure les données autour de deux concepts fondamentaux : les tables de faits et les tables de dimensions.
Le schéma en étoile (Star Schema)
Le schéma en étoile est la forme la plus simple et la plus performante de modélisation dimensionnelle. Il se compose d'une table de faits centrale, directement reliée à plusieurs tables de dimensions non normalisées.
Dans le schéma ci-dessus, la table FAIT_VENTES est au cœur du modèle. Elle contient les clés étrangères vers chaque dimension (id_date, id_produit, id_client, id_magasin) et les mesures métier (montant, quantité, marge, remise).
Avantages du schéma en étoile
- Performance des requêtes : moins de jointures SQL, le moteur de base de données charge moins de pages
- Lisibilité : les utilisateurs métier comprennent intuitivement la structure
- Compatibilité BI : Power BI, Oracle OAS et OBIEE gèrent nativement ce type de modèle
- Agrégation simple : GROUP BY sur les dimensions pour obtenir n'importe quelle granularité
Schéma en flocon (Snowflake Schema)
Le schéma en flocon est une variante dans laquelle les dimensions sont normalisées — elles sont décomposées en sous-tables. Par exemple, une dimension Produit peut être divisée en tables Produit, Catégorie, Sous-catégorie et Marque.
Tables de faits : les différents types
| Type | Description | Exemple |
|---|---|---|
| Transactionnelle | Une ligne par événement métier | Chaque ligne de commande |
| Instantané périodique | Snapshot à intervalles réguliers | Stock en fin de mois |
| Accumulating snapshot | Suivi d'un processus en plusieurs étapes | Cycle de vie d'une commande |
| Factless | Enregistre des événements sans mesures | Présence d'un employé |
Les dimensions à évolution lente (SCD)
Un client peut changer de région, un produit peut être rebrandé. Comment gérer ces changements historiques ? Les Slowly Changing Dimensions (SCD) offrent plusieurs stratégies :
- SCD Type 1 : Écrasement — on met à jour la valeur, on perd l'historique. Simple, adapté aux corrections d'erreurs.
- SCD Type 2 : Versioning — on ajoute une nouvelle ligne avec des dates de validité (date_debut, date_fin). Préserve l'historique complet. Le plus utilisé.
- SCD Type 3 : On ajoute une colonne "ancienne valeur". Limité à un seul changement historique.
-- Fermer la ligne existante UPDATE DIM_CLIENT SET date_fin = GETDATE(), is_current = 0 WHERE id_client_src = @id AND is_current = 1; -- Insérer la nouvelle version INSERT INTO DIM_CLIENT (id_client_src, nom, region, segment, date_debut, date_fin, is_current) VALUES (@id, @nom, @new_region, @segment, GETDATE(), '9999-12-31', 1);
Bonnes pratiques à retenir
- Clés de substitution (surrogate keys) : N'utilisez jamais les clés métier comme clés primaires des dimensions. Créez des clés entières auto-incrémentées.
- Dimension Calendrier : Toujours créer une dimension Date complète et prépeuplée — ne calculez jamais les attributs temporels dans vos requêtes.
- Conformité des dimensions : Une dimension partagée entre plusieurs faits (ex: DIM_DATE) doit être identique — c'est le concept de "conformed dimension" de Kimball.
- Grain de la table de faits : Définissez précisément le grain (niveau de détail) avant de créer la table. Le grain doit être stable dans le temps.
- Évitez les NULL dans les faits : Remplacez-les par des valeurs par défaut (0 pour les mesures additives, -1 pour les clés FK inconnues).
Conclusion
La modélisation dimensionnelle reste, en 2026, la meilleure approche pour concevoir un Data Warehouse orienté analytique. Le schéma en étoile offre le meilleur compromis entre performance, lisibilité et compatibilité avec les outils BI modernes comme Power BI ou Oracle OAS.
Chez ANAILYNIS, chaque projet de Data Warehouse commence par une phase de modélisation rigoureuse avec l'équipe métier : identifier les processus à mesurer, définir les grains, lister les dimensions et construire la Bus Matrix. C'est ce fondement qui garantit la pérennité de votre investissement BI.
Besoin d'un accompagnement BI ?
ANAILYNIS vous accompagne dans la conception, le déploiement et la formation sur vos projets BI — Power BI, Oracle OAS, Data Warehouse.
Contacter ANAILYNIS →