Modélisation dimensionnelle 5

Notion de jeux de rôles : si la date apparaît plusieurs fois dans une ligne de la table de faits, il faut créer des vues différentes de la table Date, en prenant soin de nommer différemment à la fois la table et les colonnes (par ex. « jour de commande » et « jour de livraison »…).

Concernant la dimension Produit qui est très courante, ses caractéristiques sont :

• un grand nombre de colonnes de texte descriptives.
• une ou plusieurs hiérarchies en plus d’un grand nombre d’attributs non hiérarchisés.

Cette dimension peut posséder plusieurs milliers de lignes et quelques précautions doivent être prises lors de la création de cette table à partir d’un fichier maître.

• Faire correspondre à la clé Produit opérationnelle une clé Produit artificielle.
• Insérer des séquences de texte lisibles remplaçant ou complétant les codes numériques du fichier maître Produit opérationnel.
• Contrôler tous les champs de texte pour éviter les erreurs d’orthographe, de valeurs impossibles ou des versions différentes du même attribut.
• Documenter les définitions, les interprétations et les sources des attributs des produits dans les métadonnées de l’entrepôt.

La dimension adresse de livraison.

Il est normal d’avoir plusieurs hiérarchies indépendantes dans cette table. Une hiérarchie naturelle est la hiérarchie géographique avec le pays, la région, le département, la ville, le lieu. Une autre hiérarchie possible est une hiérarchie par entreprise (une adresse de facturation peut regrouper plusieurs adresses de livraison). Les différentes hiérarchies peuvent avoir différents niveaux. Il peut arriver que la relation entre adresse de facturation et de livraison ne soit pas strictement hiérarchique (i.e. plusieurs factures pour une livraison). Dans ce cas, le grain de la table de dimension peut être affiné au niveau de la combinaison adresse de facturation/adresse de livraison, si cette relation non strictement hiérarchique reste exceptionnelle.

Sinon, il est préférable de définir une dimension supplémentaire « Adresse de facturation ». Il est inutile de créer une table portant les relations entre les deux dimensions, la table de faits porte déjà cette relation et répond efficacement à la question des corrélations entre dimensions.

La dimension dégénérée du numéro de commande n’est reliée à aucune table de dimension (c’est le propre d’une dimension dégénérée) car toutes les informations de la commande sont conservées dans les autres dimensions. Par contre, elle peut servir à regrouper les articles commandés ensembles. D’une façon générale, les dimensions dégénérées sont réservées à l’identification des transactions. Elles ne doivent surtout pas servir à stocker un code sans que sa réelle signification soit décrite dans une autre table.

La dimension fourre-tout (junk dimension) sert à stocker les différents indicateurs et drapeaux (flags) trouvés dans les données opérationnelles. Eventuellement, si le nombre de lignes est conséquent, on pourra créer plusieurs dimensions fourre-tout. Cette dimension soulage la table de faits et évite aussi la création d’un trop grand nombre de dimensions pour gérer ces indicateurs. On peut aussi créer une dimension fourre-tout pour stocker les commentaires trouvés dans les données.

Les devises multiples peuvent être gérées facilement à l’aide d’une table de conversion stockant les changes chaque jour et en ajoutant une dimension Monnaie (par pays).

Les faits de granularité différente ne doivent jamais être mélangés dans une même table de faits. Ou bien il faut répartir les faits de plus haut niveau au niveau le plus fin, ou bien il faut les mettre dans des tables de faits séparées. La première solution est la meilleure car elle permet la navigation entre les niveaux ; mais elle nécessite de définir les modalités d’allocation (activity based costing). Cette allocation sur le niveau de détail devrait être faite par une équipe dédiée plus fonctionnelle et non par les développeurs de l’entrepôt.

La facturation est le processus idéal pour commencer un entrepôt de données dans les sociétés qui expédient des produits ou vendent des services. Une table de faits de transactions de facturation est une des tables les plus puissantes de l’entreprise. Elle combine les clients, les produits et les composantes de la rentabilité.

Une table de faits des instantanés récapitulatifs voit ses lignes régulièrement mises à jour, contrairement aux autres tables de faits. Ce type de table de faits est mieux adapté aux processus de courte durée de vie ayant un identifiant du début à la fin.

Gestion des unités de mesure : s’il existe différentes unités de mesure comme par exemple le nombre de produits, le nombre de cartons, le nombre de palettes, etc. alors il est conseillé de stocker les différents facteurs de conversion dans la table de faits directement et non dans une dimension. La gestion des changements de facteur s’en trouve simplifiée.

Il me semble qu’il est aussi possible de stocker directement les quantités (dans les différentes unités de mesure) plutôt que les facteurs. Mais alors l’étude des changements de facteurs (qui représentent des changements de conteneurs) est plus difficile. Le facteur de conversion apparaît donc plus fondamental ici.

Comparaison des 3 types de table de faits.

Les tables de transactions seules ne peuvent pas offrir des modèles dimensionnels efficaces. Elles stockent toutes les transactions.

Les tables de faits instantanés périodiques résument les faits à la fin d’une période (la journée souvent). Elles facilitent le suivi de l’évolution de l’activité.

Les tables de faits instantanés récapitulatifs couvrent un laps de temps indéterminé, correspondant à la durée de vie de la transaction de produit. Cette table possède souvent une colonne « date de mise à jour de la ligne ».

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