;
chevron-bottomchevron-leftchevron-rightdownloadfacebookinstagramlink-outlinkedinminusplus
Accessibilité Tous les articles

Data Vault: Bonnes pratiques pour créer des liens - Partie 3

Publication

Mai 2011

Publié par

Luc Durand

Cet article est le troisième d'une série d’articles traitant d’une alternative à la modélisation d'entrepôts de données : l'approche Data Vault.

Dans le premier article, nous avons globalement présenté l’approche Data Vault et les trois types d’entités de cette approche : d’une part, les entités structurelles représentées par les hubs qui identifient les concepts d’affaires utilisés par un ou plusieurs secteurs de l’organisation et les liens qui associent les concepts d’affaires; d’autre part, les entités descriptives représentées par les satellites qui décrivent et contextualisent les hubs et les liens.

La figure 1 montre un exemple de modèle Data Vault. Les entités Étudiant, Admission et Programme sont des hubs et l’entité Admission Programme est un lien.

Restez à l’affût des dernières tendances analytiques

Dans le deuxième article, nous nous sommes attardés plus spécifiquement aux hubs. Ce troisième article traite des liens entre les hubs.

Un lien est une entité dépendante représentant une interaction entre au moins deux concepts dont elle dépend.

Comme dans le cas d’un modèle étoilé, la granularité d’un lien (son niveau de détail) est dictée par les hubs en relation avec le lien.

Voici des critères à respecter pour être un bon lien.

Un lien :

  • Est associée à au moins deux concepts (hubs) parents (remarque : dans le cas d’un lien hiérarchique, on peut associer deux fois au même hub);
  • Ne contient aucun élément de données descriptif (exemple : la date de début et de fin de la relation). Les satellites d’un lien contiennent la partie descriptive;
  • Est le seul type d’entités contenant les relations entre concepts;
  • Est utilisé peu importe la cardinalité de la relation entre deux concepts. Elle ne considère pas des cardinalités plus spécifiques qu’une relation plusieurs à plusieurs. Un changement de cardinalité n’affectera donc aucunement le modèle (remarque : une règle de cardinalité plus spécifique peut être documentée au niveau des métadonnées);
  • Contient toujours au minimum deux informations permettant la traçabilité : la source d’où provient le lien et quand l’instance du lien a été amenée dans l’entrepôt;
  • Est implanté par des clefs étrangères qui pointent vers les identifiants (internes) des hubs en relation;
  • Est défini avec le grain le plus fin possible, sauf pour des liens redondants définis à une granularité plus élevée pour des raisons de performance;
  • Est créé si le grain change et l’ancien lien demeure ce qui permet d’éviter la réingénierie du modèle existant et assure la vérifiabilité.

Plusieurs de ces critères font en sorte que la structure existante du modèle n’a pas besoin d’une réingénierie lorsque des changements surviennent dans l’environnement d’affaires. La structure du modèle Data Vault est conçue de telle sorte que lorsque des changements surviennent, ceux-ci n’ont pas d’impacts sur les parties existantes du modèle. Des liens sont ajoutés sans réviser les structures existantes. La structure est donc flexible et les nouveautés sont ajoutées avec beaucoup moins d’efforts. Il n’y a aucun besoin de conversion de données existantes dans la nouvelle structure.

Dans le prochain article de la série, nous présenterons le troisième type d’entités d’un modèle Data Vault : les satellites.