Data Vault: Bonnes pratiques pour créer des hubs - Partie 2

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

Dans un premier article, nous avons globalement présenté l’approche Data Vault en tant qu’alternative à la modélisation par sujets et en schémas étoilés. Nous avons alors défini les trois types d’entités de cette approche :

• Les entités structurelles représentées par les hubs qui identifient les concepts d’affaires utilisés et communiqués par un ou plusieurs secteurs de l’organisation et les liens qui associent les concepts d’affaires en liant au moins 2 hubs. La figure 1 montre un exemple de modèle Data Vault. Les entités Stationnement et Employé sont des hubs et l’entité Stationnement Employé est un lien.
  
• Les entités descriptives représentées par les satellites qui décrivent les concepts d’affaires et les liens ainsi que leurs contextes d’utilisation.

Figure 1 : Exemple de modèle Data Vault

Deux idées centrales étaient à retenir :

• Il y a séparation des données structurelles par nature plus stables des données descriptives/contextuelles qui changent plus souvent. Séparer ce qui est stable de ce qui l’est moins est un principe très important d’une bonne architecture en général.
• Les données des systèmes sources sont gardées intactes. Il y a un chargement rapide depuis les sources avec réarrangement des données dans les hubs-liens-satellites, mais sans transformations ce qui permet de reconstituer telle quelle l’image des données sources à n’importe lequel moment dans le temps. Un entrepôt de type Data Vault est un entrepôt de données dit brut (« raw datawarehouse »).
  

Regardons maintenant de plus près chacun des types d’entité en commençant par le hub.

Un hub contient une clef naturelle permettant d’identifier uniquement (du moins, c’est à espérer!) une instance d’un concept d’affaires. Une clef naturelle est une clef visible et utilisée par l’organisation pour identifier une instance d'un concept. Par exemple, le numéro d’employé est utilisé pour identifier uniquement un employé dans différents contextes/processus : ressources humaines, gestion des stationnements, incidents, paye, système financier... Le numéro d’employé est donc le point de raccordement (de communication) du concept « employé » entre différentes unités d’affaires d’où l’appellation hub.

Une clef naturelle est différente des identifiants internes des systèmes sources qui sont, en principe, non visibles et spécifiques au système qui en génère les valeurs.

Dans un monde idéal, chaque concept se verrait attribuer la même clef, peu importe l’unité d’affaires, et la clef devrait être unique. En pratique, c’est loin d’être toujours le cas. Par exemple, la gestion des incidents pourrait utiliser sa propre clef naturelle pour les différentes ressources concernées.

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

Un hub :

• Représente un et un seul concept;
• Ne contient aucun élément de données descriptif (exemple : le nom d'un employé). Les satellites d’un hub contiennent la partie descriptive;
• Ne contient aucune relation. Les liens contiennent les relations entre les hubs et les satellites contiennent les relations entre la description d’un concept et le concept (hub) décrit;
• Contient idéalement une clef naturelle unique composée d'au moins un élément de données qui identifie le concept (exemple : le numéro du stationnement). Si, par exemple, dans deux sources une même valeur de clef naturelle ne correspond pas à la même instance de concept, il faut alors identifier uniquement les différentes instances en utilisant la clef naturelle combinée avec le nom de la source d’où provient la donnée.
• Contient toujours au minimum deux informations permettant la traçabilité : la source d’où provient la donnée et quand la donnée a été amenée dans le hub;
• Est associé à au moins un satellite pour le décrire.
  
  

Dans le prochain article, nous continuerons à décrire les types d’entités d’un modèle Data Vault.