Dimensional Modeling:
the Star Schema Explained

What is dimensional modeling?

Dimensional modeling is a database design technique optimized for analytical queries. Unlike normalized transactional databases (OLTP), dimensional models are deliberately denormalized to maximize read performance and make the structure intuitive for business users.

Developed by Ralph Kimball in the 1990s, this approach structures data around two fundamental concepts: fact tables and dimension tables.

The Star Schema

The star schema is the simplest and most performant form of dimensional modeling. It consists of a central fact table directly linked to several non-normalized dimension tables.

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).

Star Schema advantages

• Query performance: fewer SQL joins, the database engine loads fewer pages
• Readability: business users intuitively understand the structure
• BI compatibility: Power BI, Oracle OAS and OBIEE natively support this model type
• Simple aggregation: GROUP BY on dimensions to obtain any granularity

The Snowflake Schema

The snowflake schema is a variant in which dimensions are normalized — they are broken down into sub-tables. For example, a Product dimension can be split into Product, Category, Sub-category and Brand tables.

Tables de faits : les différents types

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.