Le secret pour construire un entrepôt de données distribué est d'utiliser des dimensions conformes. Dans un entrepôt distribué plusieurs sources de mesures différentes sont maintenues par différentes directions. Ces mesures sont habituellement présentées dans des tables de faits. Une direction peut suivre le nombre de produits fabriqués, une autre le nombre de produits dans le stock. Une troisième peut vouloir le nombre de produits vendus, et une quatrième le nombre de commentaires et plaintes liés à un produit. Clairement, toutes ces équipes ont un intérêt commun pour "le produit". Ainsi, nous pouvons construire un entrepôt de données distribué si nous parvenons à une définition unique du produit partagée par toutes les directions.
Il est important de souligner ce point. Nous pouvons construire un entrepôt de données distribué si ces quatre directions utilisent toutes la dimension "Produit" conforme. Et oui, ces directions ont besoin de standardiser toutes les autres dimensions qu'elles ont en commun, comme le temps et les clients. Mais nous nous concentrerons uniquement sur la dimension "Produit" dans cet article.
La manière la plus simple de standardiser la dimension "Produit" est que les quatre directions utilisent la même table de dimension. Mêmes clés, mêmes attributs, mêmes tout. Chacune de ces équipes, bien sur, doit ensuite convertir chaque clé Produit de sa table de fait en une clé de substitution publique utilisée dans la dimension standard "Produit".
Une manière plus complexe d'utiliser la dimension "Produit" est d'autoriser une de ces directions à utiliser un sous ensemble de la dimension. Supposons que la direction mesurant les commentaires, n'enregistre seulement ceux-ci qu'au niveau de la marque, et non au niveau du produit. Cela serait acceptable pour cette équipe d'utiliser une version tronquée de la table "Produit" qui contiendrait uniquement les informations au niveau de la marque. Bien sur, cela forcerait n'importe quelle application qui voudrait croiser les informations de ce datamart avec celles d'un autre datamart à rechercher le niveau le plus fin en commun de la dimension "Produit", qui est dans ce cas la marque et non le produit.
Le vrai avantage d'utiliser des dimensions standards est d'être capable de croiser différents datamarts (tables de faits). Si vous pouvez restreindre et grouper les caractéristiques d'un produit à un niveau identique dans différentes tables de faits, vous pouvez alors aligner les différentes réponses en utilisant les attributs de la dimension "Produit". Ainsi, dans un rapport vous pouvez afficher les produits fabriqués, les produits en stocks et les produits vendus à un niveau très détaillé, et si vous vous restreignez au niveau de la marque, vous pouvez inclure le nombre de plaintes.
Croiser les tables de faits est le point clé important dans l'utilisation d'un entrepôt de données distribué, et évite d'en avoir un centralisé.
Mais gérer une dimensions standard demande une grande discipline. Toute l'organisation a besoin d'un "responsable de dimension". Cette autorité est en charge de maintenir la dimension "Produit" et de la répliquer correctement dans les différents datamarts qui utilisent des tables de faits contenant des produits. Répliquer la dimension et maintenir sa cohérence, est une tache qui doit être prise très au sérieux.
Cela serait un désastre si vous croisiez les données de différents datamarts dont la moitié utiliseraient la dimension "Produit" d'hier et l'autre moitié auraient les données du jour. Les résultats seraient faux. Les libellés pourraient ne pas correspondre si la définition d'un des attributs a été modifiée. Par exemple, si un manager a changé la définition d'un des attributs du produit, le rapport utilisant cette information pour croiser différents datamarts pourrait retourner des valeurs erronées.
La morale de cette histoire est que si le responsable de la dimension avait modifié la table "Produit", alors toutes les tables agrégées affectées par ce changement auraient été mises à jour. Si un produit avait été déplacé d'une catégorie à une autre, alors ce n'est pas uniquement la table "Produit" qui aurait changé, mais toutes les tables de faits qui sont au niveau de la catégorie qui auraient été mises à jour.
Nous pouvons résumer les deux grandes responsabilités pour répliquer correctement des dimensions:
- tous les datamarts clients doivent déployer la dimension modifiée simultanément, ainsi si un utilisateur parcourt ces données, il le fera en utilisant des attributs de dimension conformes à travers tout le système.
- tous les datamarts clients doivent supprimer les agrégats affectés par ce changement dans la dimension, et rendre ces agrégats uniquement disponibles aux utilisateurs lorsqu'ils seront redevenus cohérents avec le contenu de la dimension.
Source originale: www.kimballgroup.com
Article original "Kimball Design Tip #19: Replicating dimensions correctly", publié le 5 février 2001.
Aucun commentaire:
Enregistrer un commentaire