Modélisation de la voûte de données

Modèle simple de voûte de données avec deux hubs (bleu), un lien (vert) et quatre satellites (jaune)

La voûte de données tente de résoudre le problème de la gestion des changements dans l’environnement en séparant les clés métier (qui ne mutent pas aussi souvent, parce qu’elles identifient de manière unique une entité commerciale) et les associations entre ces clés commerciales, des attributs descriptifs de ces clés.

Les clés métier et leurs associations sont des attributs structurels, formant le squelette du modèle de données. La méthode du coffre-fort de données a comme l’un de ses principaux axiomes que les clés métier réelles ne changent que lorsque l’entreprise change et sont donc les éléments les plus stables à partir desquels on peut dériver la structure d’une base de données historique. Si vous utilisez ces clés comme colonne vertébrale d’un entrepôt de données, vous pouvez organiser le reste des données autour d’elles. Cela signifie que le choix des clés correctes pour les hubs est d’une importance capitale pour la stabilité de votre modèle. Les clés sont stockées dans des tables dont la structure est soumise à quelques contraintes. Ces tables de clés sont appelées hubs.

HubsEdit

Les hubs contiennent une liste de clés commerciales uniques ayant une faible propension à changer. Les hubs contiennent également une clé de substitution pour chaque élément du hub et des métadonnées décrivant l’origine de la clé métier. Les attributs descriptifs des informations sur le Hub (tels que la description de la clé, éventuellement en plusieurs langues) sont stockés dans des structures appelées tables satellites qui seront abordées ci-dessous.

Le Hub contient au moins les champs suivants :

• une clé de substitution, utilisée pour connecter les autres structures à cette table.
• une clé métier, le pilote de ce hub. La clé métier peut se composer de plusieurs champs.
• la source d’enregistrement, qui peut être utilisée pour voir quel système a chargé chaque clé métier en premier.
• en option, vous pouvez également avoir des champs de métadonnées avec des informations sur les mises à jour manuelles (utilisateur/heure) et la date d’extraction.

Un hub n’est pas autorisé à contenir plusieurs clés métier, sauf lorsque deux systèmes délivrent la même clé métier mais avec des collisions qui ont des significations différentes.

Les hub devraient normalement avoir au moins un satellite.

Exemple de hubEdit

C’est un exemple pour un hub-table contenant des voitures, appelé « Car » (H_CAR). La clé de commande est le numéro d’identification du véhicule.

LinksEdit

Les associations ou les transactions entre les clés métier (reliant par exemple les hubs du client et du produit entre eux par la transaction d’achat) sont modélisées à l’aide de tables de liens. Ces tables sont fondamentalement des tables de jointure many-to-many, avec quelques métadonnées.

Les liens peuvent se lier à d’autres liens, pour traiter les changements de granularité (par exemple, l’ajout d’une nouvelle clé à une table de base de données changerait le grain de la table de base de données). Par exemple, si vous avez une association entre le client et l’adresse, vous pourriez ajouter une référence à un lien entre les hubs pour le produit et la société de transport. Il pourrait s’agir d’un lien appelé « Livraison ». Référencer un lien dans un autre lien est considéré comme une mauvaise pratique, car cela introduit des dépendances entre les liens qui rendent le chargement parallèle plus difficile. Puisqu’un lien vers un autre lien est la même chose qu’un nouveau lien avec les hubs de l’autre lien, dans ces cas, créer les liens sans référencer d’autres liens est la solution préférée (voir la section sur les pratiques de chargement pour plus d’informations).

Les liens lient parfois les hubs à des informations qui ne sont pas en soi suffisantes pour construire un hub. Cela se produit lorsqu’une des clés métier associées par le lien n’est pas une vraie clé métier. À titre d’exemple, prenons un bon de commande avec « numéro de commande » comme clé, et des lignes de commande auxquelles on associe un numéro semi-aléatoire pour les rendre uniques. Disons, « numéro unique ». Cette dernière clé n’est pas une véritable clé commerciale, elle n’est donc pas un hub. Cependant, nous devons l’utiliser afin de garantir une granularité correcte pour le lien. Dans ce cas, nous n’utilisons pas un hub avec une clé de substitution, mais nous ajoutons la clé métier « numéro unique » elle-même au lien. Cela n’est fait que lorsqu’il n’y a aucune possibilité d’utiliser la clé métier pour un autre lien ou comme clé pour des attributs dans un satellite. Cette construction a été appelée un « peg-legged link » par Dan Linstedt sur son forum (maintenant défunt).

Les liens contiennent les clés de substitution pour les hubs qui sont liés, leur propre clé de substitution pour le lien et les métadonnées décrivant l’origine de l’association. Les attributs descriptifs des informations sur l’association (comme l’heure, le prix ou le montant) sont stockés dans des structures appelées tables satellites qui sont discutées ci-dessous.

Exemple de lienEdit

Voici un exemple pour une table de liens entre deux hubs pour les voitures (H_CAR) et les personnes (H_PERSON). Le lien est appelé « conducteur » (L_DRIVER).

SatellitesEdit

Les hubs et les liens forment la structure du modèle, mais n’ont pas d’attributs temporels et ne détiennent aucun attribut descriptif. Ils sont stockés dans des tables séparées appelées satellites. Ceux-ci sont constitués de métadonnées les reliant à leur hub ou lien parent, de métadonnées décrivant l’origine de l’association et des attributs, ainsi que d’une chronologie avec les dates de début et de fin de l’attribut. Alors que les hubs et les liens fournissent la structure du modèle, les satellites fournissent la « viande » du modèle, le contexte des processus métier qui sont capturés dans les hubs et les liens. Ces attributs sont stockés à la fois en ce qui concerne les détails de l’affaire ainsi que la chronologie et peuvent aller de très complexe (tous les champs décrivant le profil complet d’un client) à très simple (un satellite sur un lien avec seulement un indicateur de validité et une chronologie).

En général, les attributs sont regroupés dans les satellites par système source. Cependant, les attributs descriptifs tels que la taille, le coût, la vitesse, le montant ou la couleur peuvent changer à des rythmes différents, vous pouvez donc également répartir ces attributs dans différents satellites en fonction de leur taux de changement.

Toutes les tables contiennent des métadonnées, décrivant au minimum le système source et la date à laquelle cette entrée est devenue valide, ce qui donne une vue historique complète des données lorsqu’elles entrent dans l’entrepôt de données.

Exemple de satelliteModifier

Voici un exemple pour un satellite sur le lien conducteurs entre les hubs pour les voitures et les personnes, appelé « Assurance conducteur » (S_DRIVER_INSURANCE). Ce satellite contient des attributs spécifiques à l’assurance de la relation entre la voiture et la personne qui la conduit, par exemple un indicateur pour savoir s’il s’agit du conducteur principal, le nom de la compagnie d’assurance pour cette voiture et cette personne (il pourrait également s’agir d’un hub séparé) et un résumé du nombre d’accidents impliquant cette combinaison de véhicule et de conducteur. Est également incluse une référence à une table de consultation ou de référence appelée R_RISK_CATEGORY contenant les codes de la catégorie de risque dans laquelle cette relation est considérée comme relevant.

.

.

(*) au moins un attribut est obligatoire.(**) le numéro de séquence devient obligatoire s’il est nécessaire pour renforcer l’unicité pour plusieurs satellites valides sur le même hub ou lien.

Tables de référenceModification

Les tables de référence sont une partie normale d’un modèle de coffre-fort de données sain. Elles sont là pour empêcher le stockage redondant de données de référence simples qui sont beaucoup référencées. Plus formellement, Dan Linstedt définit les données de référence comme suit :

Toute information jugée nécessaire pour résoudre les descriptions à partir des codes, ou pour traduire les clés en (sic) une manière cohérente. Beaucoup de ces champs sont de nature « descriptive » et décrivent un état spécifique des autres informations plus importantes. En tant que telles, les données de référence vivent dans des tables séparées des tables brutes de Data Vault.

Les tables de référence sont référencées à partir de Satellites, mais jamais liées avec des clés étrangères physiques. Il n’y a pas de structure prescrite pour les tables de référence : utilisez ce qui fonctionne le mieux dans votre cas spécifique, allant de simples tables de consultation à de petits coffres de données ou même des étoiles. Elles peuvent être historiques ou sans historique, mais il est recommandé de s’en tenir aux clés naturelles et de ne pas créer de clés de substitution dans ce cas. Normalement, les voûtes de données ont beaucoup de tables de référence, comme tout autre Data Warehouse.

Exemple de référenceEdit

C’est un exemple de table de référence avec des catégories de risque pour les conducteurs de véhicules. Elle peut être référencée à partir de n’importe quel satellite du coffre-fort de données. Pour l’instant, nous la référençons à partir du satellite S_DRIVER_INSURANCE. La table de référence est R_RISK_CATEGORY.

.

(*) au moins un attribut est obligatoire.