Cet article est le cinquième d'une série d'articles traitant de l'approche Data Vault de modélisation d'entrepôts de données.

Nous avons tout d’abord introduit l’approche Data Vault et nous avons ensuite décrit plus en détail chacun des 3 types d’entités qui la composent : les hubs qui représentent les concepts d’affaires, les liens qui associent les concepts d’affaires entre eux et les satellites qui décrivent et contextualisent les hubs et les liens.

Comment se positionne cette approche de modélisation d’entrepôt de données par rapport aux deux approches classiques : la modélisation par sujet d’Inmon et la modélisation dimensionnelle de Kimball? N’ayez crainte, je n’ai pas l’intention de reprendre le vieux débat idéologique entre les partisans d’Inmon et ceux de Kimball. Disons plutôt que les adeptes des 2 clans peuvent y trouver leur compte…

En soi, l’architecture hubs-liens-satellites, rappelons-le, est flexible, stable et extensible. Mais revenons à l’objectif fondamental d’un modèle Data Vault : obtenir un entrepôt de données brutes non transformées qui permet une reconstitution facile et à n’importe lequel moment dans le temps de l’état des données tel qui se retrouvait dans les sources. Les données ne sont que regroupées dans la structure hubs-liens-satellites. Trois conséquences importantes de cette façon de faire :

  • Il y a traçabilité complète et facile avec l’image des sources à un moment donné.
  • Comme il n’y a aucune transformation et étant donné que les transformations sont ce qu’il y a de plus complexe dans un ETL, le temps de développement des ETL est très court et les nouvelles données arrivent très rapidement dans l’entrepôt.
  • La structure permet de montrer au grand jour les problèmes de qualité des données sans essayer de les corriger ou de les contourner.

La modélisation dimensionnelle n’a pas le même objectif. Celle-ci est orientée vers l’usage/l’interrogation de données transformées. L’accent est sur la simplicité et la performance des interrogations. Étant donné que le modèle dimensionnel utilise des données transformées, la traçabilité avec les sources est plus difficile à obtenir. À l’inverse, bien qu’il soit possible d’obtenir un certain niveau de performance et que l’architecture du modèle Data Vault soit relativement simple, l’approche Data Vault n’atteint pas le niveau de performance et de simplicité des modèles dimensionnels.

Comment obtenir le meilleur des deux mondes? La réponse : en maintenant les 2 types d’entrepôt. Mais attention, il ne s’agit pas ici de répéter l’erreur commise si souvent par le passé qui consistait à bâtir un entrepôt normalisé par sujet et en déduire des modèles dimensionnels! Il y a une différence fondamentale : l’effort pour amener les données des sources dans l’entrepôt normalisé est élevé et l’effort pour passer du modèle normalisé au modèle en étoile était également loin d’être négligeable. Autre problème : la traçabilité de la donnée n’est pas assurée.

La figure 1 résume l’usage combiné des deux approches. Comme on a déjà mentionné, les nouvelles données sont amenées rapidement dans l’entrepôt Data Vault. Nul besoin d’attendre après l’implantation des transformations. De plus, l’ETL requis pour passer du modèle Data Vault au modèle dimensionnel est plus simple que dans un ETL classique entre les sources et une structure dimensionnelle.

datavault5graphic

Figure 1 Combinaison des approches Data Vault et dimensionnelle

Qu’en est-il du modèle normalisé en sujet? En fait, le modèle Data Vault est en soi une version améliorée du modèle normalisé classique. Il est plus simple et plus flexible tout en offrant les mêmes avantages.

En somme, l’entrepôt de données idéal utilise conjointement l’approche Data Vault d’entrepôt de données brutes combiné avec la simplicité et la performance des modèles dimensionnels.

Téléchargez notre livre blanc sur l'approche de modélisation Data Vault
Partager cet article
  


CONTACT

agileDSS Inc.
407, rue McGill, bureau 500.
Montréal (QC) H2Y 2G3.

info@agiledss.com
(514) 788-1337