Les bases du schéma en étoile : faits, dimensions et déclaration du grain

Ce que c'est

La modélisation dimensionnelle divise les données en mesures d'événements métier et en contexte descriptif de ces événements : qui, quoi, où, quand, pourquoi et comment. Dans une base de données relationnelle, cela devient un schéma en étoile : des tables de faits au centre, chacune reliée par des clés étrangères aux tables de dimensions qui l'entourent. Le guide Power BI cité le formule de façon opérationnelle : une table de faits contient des colonnes de clés de dimension qui se rattachent aux tables de dimensions, et des colonnes de mesures numériques ; les colonnes de clés déterminent la dimensionnalité de la table de faits et les valeurs des clés sa granularité ; les tables de dimensions sont relativement petites, les tables de faits volumineuses et croissantes. La page du Kimball Group sur le grain, citée en référence, rend explicite la première étape de conception : déclarer le grain établit exactement ce que représente une ligne de la table de faits, devient un contrat contraignant, et doit précéder le choix des dimensions et des faits ; le grain atomique, le niveau le plus fin saisi par le processus, est recommandé car il résiste aux requêtes imprévisibles. La page sur les faits, citée en référence, classe les mesures : les mesures additives peuvent être sommées selon n'importe quelle dimension ; les mesures semi-additives, comme les soldes, selon toutes les dimensions sauf le temps ; les mesures non additives, comme les ratios, ne se somment pas du tout, si bien qu'il faut stocker leurs composants additifs et calculer le ratio après l'agrégation.

Pourquoi c'est important

Les analystes et les outils de BI peuvent agréger un schéma en étoile sans connaître les systèmes sources : filtrer sur des attributs de dimension, sommer des mesures, grouper selon n'importe quelle dimension. Un schéma opérationnel normalisé impose des jointures multiples dont la sémantique diffère selon la requête, et une table qui mélange des grains (lignes de commande et en-têtes de commande) compte en double dès que quelqu'un la somme.

Comment l'appliquer

• Formuler le grain en une phrase (« une ligne par ligne de commande et par jour ») et rejeter toute mesure ou dimension qui ne s'y conforme pas ; placer un grain différent dans une table de faits distincte.
• Donner à chaque dimension une clé de substitution entière, conserver la clé naturelle de la source comme attribut, et inclure une dimension de date avec des attributs calendaires plutôt que de les recalculer dans chaque requête.
• Stocker les dimensions dégénérées (numéro de commande) directement sur le fait ; réserver les tables de dimensions aux entités possédant des attributs descriptifs.
• Définir une seule fois les dimensions conformes et les réutiliser à travers les tables de faits, afin que les résultats de processus différents s'alignent sur les mêmes lignes.

Pièges

Éclater les dimensions en sous-tables normalisées (flocon de neige) économise peu de stockage et coûte des jointures. Les clés étrangères NULL cassent les filtres ; utiliser un membre de dimension explicite « inconnu ». Les moyennes et les pourcentages stockés comme des faits ne peuvent pas être réagrégés correctement.

Clés de substitution dans les pipelines rejouables

Une clé tirée d'une séquence est attribuée dans l'ordre de chargement ; rejouer ou recharger une dimension hors ordre modifie donc les clés et rend orphelins les faits chargés entre-temps. Dans les pipelines conçus pour des relances idempotentes, dériver la clé de substitution de façon déterministe à partir de la clé naturelle (et de valid_from pour les lignes de type 2), généralement sous forme de hachage ; dbt_utils.generate_surrogate_key en est l'implémentation courante. Les chargements de dimensions et de faits restent alors rejouables indépendamment, et les faits peuvent être dotés de leur clé dès le chargement, sans recherche. Conserver des clés de séquence entières lorsque les chargements sont sérialisés et que la performance des jointures sur un entier étroit importe, et ne jamais mélanger les deux schémas au sein d'une même dimension.