Nous allons voir maintenant le processus de modélisation dimensionnelle en 4 étapes.

1. Sélectionner le processus d’entreprise à modéliser. Le but étant de servir l’utilisateur et que celui-ci utilise l’entrepôt de données pour ses questions, le premier modèle dimensionnel à construire doit répondre aux questions les plus pressantes de l’utilisateur et les données doivent être les plus faciles à extraire.
2. Déclaration du grain. Il faut utiliser les données les plus atomiques à notre disposition. Ne pas agréger les données en faisant des sommes et en perdant de la finesse et de l’information. Le but n’est pas de présenter à l’utilisateur tous les détails du processus, mais de lui offrir la possibilité d’analyser aussi facilement que possible selon diverses manières, à l’aide de coupes en tranches et en dés du cube de données.
3. Identification des dimensions. « L’énoncé précis du grain détermine les dimensions principales de la table de faits. » D’autres dimensions peuvent être ajoutées si elles ne prennent qu’une seule valeur pour chaque combinaison des dimensions élémentaires.
4. Identifications des faits. Les faits sont des quantités numériques généralement additives. Les pourcentages, les ratios sont des données non additives.et doivent être stockées dans la table de faits en séparant numérateur et dénominateur pour n’avoir que des quantités additives.

La dimension date apparaît dans quasiment tous les entrepôts de données. Si la table contient les jours des 10 ans à venir, son nombre de lignes est de 3650 seulement. C’est donc une dimension relativement petite. Ses attributs peuvent être : une clé primaire entière, la date, la description textuelle de la date, le jour de la semaine, les n° de jour, de semaine et de mois dans l’époque, les n° de jour dans le mois calendrier, dans l’année calendrier, le nom du mois, le n° du mois dans l’année, le trimestre, l’année, des indicateurs de jour férié, de jour de semaine, une saison particulière pour l’entreprise, un événement majeur…

Pour gérer l’heure de la journée, il est préférable d’ajouter une table de dimension supplémentaire, et de ne pas les mettre dans la table date qui aurait alors 5 256 000 lignes !

Il y a plusieurs intérêts à prendre une clé primaire entière : étant utilisée dans la jointure avec la table de faits, plus la clé est petite, plus on économise de la place dans la table de faits (4 octets économisés sur 1 milliard de lignes fait 4Go d’économie !). Cela permet aussi de traiter l’absence de date avec une clé particulière plutôt qu’une valeur nulle. D’une façon générale, il faut éviter les clés null dans la table de faits. Pour indiquer qu’une dimension ne s’applique pas à un fait, il est conseillé d’ajouter une ligne particulière dans la table dimension (ex. : ajouter une ligne pas de promotion dans la dimension promotion).
Les tables dimensions étant de petites tailles, leurs attributs doivent être autant que possible des champs en texte clair et non des codes (qu’il faut ensuite décodés ou que l’utilisateur doit connaître et se souvenir). Il n’y a aucun besoin d’économie de place dans les tables dimensions.

Pour analyser ses données, l’utilisateur pratique le forage (datamining). Un forage vers le bas dans un marché d’informations consiste à ajouter des intitulés (valeurs de champ) de la table de dimension dans la requête. Le forage vers le haut est l’inverse : retirer des intitulés. Le forage permet une navigation dans une hiérarchie.

« Il est courant de représenter de multiples hiérarchies dans une table de dimension. »

Dimension dégénérée : cette notion apparaît lorsqu’un champ de la table de faits permettant d’identifier de façon unique une ligne (ex. n° de facture ou de commande). Ces numéros d’identification opérationnels sont les clés de dimensions vides, c-à-d ne pointant pas sur une table de dimension. La dimension engendrée par ces clés est dite dégénérée.

Voici différents cas d’extension du modèle dimensionnel :

1. Ajout de nouveaux attributs de dimension (nouvelles colonnes dans la table dimension). Les applications existantes requêtant sur l’entrepôt de données ne sont pas impactées. Si ces nouveaux attributs ne sont disponibles qu’à partir d’une date donnée, il convient de mettre un libellé particulier (par ex . « non disponible ») pour les anciens enregistrements.
2. Ajout de nouvelles dimensions. Cela implique d’ajouter une nouvelle clé étrangère dans la table de faits.
3. Ajout de nouveaux faits. Si ces faits sont au même grain que les faits existants, il suffit d’ajouter autant de colonnes dans la table de faits. S’ils n’apparaissent qu’à partir d’une certaine date, il suffit de mettre la valeur null dans les lignes de faits antérieurs. S’ils ne sont pas au même grain, il est fortement conseillé de les mettre dans une table de faits à part.
4. Si une dimension devient plus granulaire, la table de faits devient probablement aussi plus granulaire et elle doit être reconstruite. Les applications existantes ne seront cependant pas impactées.
5. Ajout d’une nouvelles source de données avec les dimensions existantes et de nouvelles dimensions imprévues. Dans ce cas, il faut créer une nouvelle table de faits et conserver l’ancienne.

Modèle dimensionnel en flocons de neige. Ce modèle résulte de la normalisation en 3ième forme normale des dimensions. Il est déconseillé de normaliser les tables de dimension pour plusieurs raisons :

1. La multiplication des tables de dimension peut perturber les utilisateurs.
2. Les SGDB ^[1] auront un traitement moins optimisé.
3. L’économie d’espace réalisée est négligeable comparée à la taille de la table de faits.
4. La navigation à l’intérieur d’une dimension est plus difficile.
5. Les flocons de neige empêchent l’utilisation des index sous forme de bitmaps (utiles pour les champs de faible cardinalité).

Les tables de dimensions doivent donc rester plates.

A éviter également : dépasser 25 dimensions. En général, on peut s’en sortir avec moins de 15 dimensions.

Toute jointure entre des tables de dimension et des tables de faits doit se baser sur des clés entières artificielles sans signification. Eviter les codes opérationnels qui prennent plus de place et peuvent ne pas être pérennes. Aussi l’absence d’une dimension n’a pas de code opérationnel associé. De plus les clés entières permettent de meilleures performances.

Source : Ralph Kimball et Margy Ross, « Entrepôts de données, guide pratique de modélisation dimensionnelle ^[2]« , 2ième édition.