Utilisations de la conception de la modélisation du coffre-fort de données
- Claude Paugh
- 24 juil.
- 10 min de lecture
Data Vault est un véritable paradigme de conception, et non une technologie. Il peut être utilisé sur n'importe quelle base de données relationnelle ou lac de données. Sa création est née de la volonté de trouver une meilleure façon d'entreposer les données et de s'éloigner des schémas en étoile, en amas d'étoiles, en constellation et en flocon de neige (et non de la société de base de données) fréquemment utilisés dans les entrepôts de données.
Ce faisant, il propose un modèle différent qui exclut, ou du moins limite, les utilisateurs finaux de l'équation. Les requêtes peuvent être difficiles pour les utilisateurs finaux, et l'organisation des entités n'est pas intuitive. Il peut remplacer un entrepôt de données ou un magasin de données d'exploitation, si le public cible principal est constitué d'ingénieurs et non d'utilisateurs finaux. Il ne s'agit certainement pas d'un remplacement pour un Data Mart.
Pourquoi s'en passer, ne fonctionnent-ils pas ? Comme pour beaucoup de choses dans le secteur technologique, la réponse à leur efficacité dépend du cas d'utilisation. À quoi sert-on ? Les acteurs, consommateurs et producteurs, déterminent généralement les paramètres du cas d'utilisation, c'est-à-dire les axes et les limites.
Dans le cas des variantes de schémas en étoile mentionnées précédemment, le cas d'utilisation se concentre sur les utilisateurs finaux. Soit ils accèdent aux données de manière ponctuelle à l'aide d'outils et de requêtes interactifs, soit ils utilisent également les rapports produits. Pour vous donner une idée du schéma ci-dessus, voici un diagramme en étoile simple. Les trois tables du haut représentent les données sources du schéma en étoile, surlignées en vert.
Les variations sont illustrées dans le schéma suivant, à l'exception de Snowflake. Snowflake ajoute des tables de référence non dimensionnelles à celles ci-dessous, qui, dans la plupart des cas, sont liées à des dimensions. Par exemple, différentes tables de types permettent de catégoriser les données au sein de dimensions. Pensez aux types d'expédition (aérienne, terrestre, maritime) et à leurs caractéristiques.
Étoile : un fait aux multiples dimensions
Amas d'étoiles - Faits multiples avec dimensions
Constellation d'étoiles : de multiples faits et dimensions connexes
Comme vous pouvez probablement le déduire, ces trois conceptions sont axées sur la création et la fourniture d’analyses aux consommateurs, qu’il s’agisse d’un outil interactif utilisant des requêtes ou des rapports.
En coulisses, du point de vue de l'utilisateur final, de nombreuses opérations de nettoyage et de transformation de la qualité des données sont nécessaires pour pouvoir écrire des données dans les tables de dimensions (Dim). Ceci avant de pouvoir alimenter les analyses dans les tables de faits (Facts).
Étant donné que toutes les dimensions et tous les faits utilisent des clés « stupides » ou de substitution, ce qui est quasiment la norme dans la conception de magasins et d'entrepôts, il est possible de créer des doublons. En effet, il existe des cas d'utilisation où les doublons sont valides, et le modèle de conception de clé de substitution s'y prête. Il est particulièrement utile pour les données de séries chronologiques, car les valeurs d'horodatage peuvent être identiques, mais la séquence les différencie.
Qualité des données
Les contrôles de qualité des données doivent être précis, sinon des distorsions peuvent facilement infecter vos données. Si vous exécutez des modèles de ML à partir de données déformées, ils dériveront et ne produiront pas les résultats escomptés. Des dérives excessives indiquent généralement des problèmes de qualité des données ou la sensibilité du modèle de ML. C'est au moins en partie l'un des avantages des modèles de conception Data Vault : ils évitent les doublons et garantissent l'unicité de certaines classifications de données, réduisant ainsi les efforts de qualité des données. En théorie, cela devrait contribuer à prévenir les problèmes de dérive.
Il ne s'agit que d'un aspect, l'unicité, et elle ne traite pas spécifiquement de la validation du contenu des données. Par exemple, si une colonne ne doit contenir que des valeurs de 9 caractères alphanumériques, une validation est nécessaire, ou si une colonne est limitée à une liste de valeurs, une inspection est tout de même nécessaire. Les types de validation de la qualité des données les plus courants sont l'inspection des valeurs des colonnes en raison de contraintes (longueur, type de données, nombre de mots, etc.). Si toutes vos sources de données proviennent d'une base de données relationnelle avec des contraintes appliquées aux colonnes, cela simplifie grandement le travail de qualité des données. Mais cela arrive très rarement.
Les données proviennent de formats structurés, semi-structurés et non structurés. On peut donc dire que les utilitaires d'inspection ont une longue durée de vie devant eux. L'utilisation d'expressions régulières, ou regex, sous diverses formes, des scripts Python au SQL, est assez courante pour ceux qui souhaitent développer une solution maison. Il existe divers frameworks et utilitaires de validation de données Python, comme Pydantic et Cerberus, pour n'en citer que quelques-uns. De nombreux outils de qualité des données ont existé au fil des ans, mais leur prix semble trop élevé pour être adoptés et, par conséquent, ils ont été rachetés par des entreprises bien plus importantes et intégrés à leurs produits. Informatica , IBM , SAS et Ab Initio ont acquis des produits de qualité des données et de business intelligence au cours des deux dernières décennies.
Les autres contrôles de qualité des données les plus courants concernent le nombre d'enregistrements. Il s'agit essentiellement de vérifier la correspondance des entrées et des sorties lors du chargement. C'est l'un des rares contrôles génériques de qualité des données que vous pouvez effectuer, car une fois les transformations lancées, les comptages spécifiques disparaissent. Il est nécessaire de disposer d'un profil du ratio entrées/sorties de la transformation afin de pouvoir calculer la plage de comptages que les résultats de la transformation peuvent comporter. Comme je l'ai mentionné précédemment, la qualité des données a été l'un des facteurs déterminants lors de la création de Data Vault, mais il en existe plusieurs autres.
Coffre-fort de données
Son créateur, Dan Linstedt , le décrit comme « un ensemble de tables normalisées, orienté vers les détails, avec un suivi historique et des liens uniques, prenant en charge un ou plusieurs domaines fonctionnels. Il s'agit d'une approche hybride englobant le meilleur de la troisième forme normale (3NF) et du schéma en étoile ». Selon Dan, il s'inspire d'une vision simpliste des neurones, des dendrites et des synapses.
Data Vault présente plusieurs avantages, notamment le fait que toutes les relations sont pilotées par des clés et que le modèle de conception peut s'adapter à des bases de données de plusieurs pétaoctets (Po). Data Vault est un exemple de modélisation par ancrage, une approche agile de la modélisation des données, qui permet de capturer les changements sans nécessairement avoir d'impact généralisé sur le modèle existant. Il est également piloté par les processus métier, ce qui, idéalement, devrait être le cas d'un schéma en étoile et de ses variantes.
La méthodologie de modélisation est similaire à celle des modèles de données entité-relation : il s'agit de créer un modèle logique représentant le processus métier et les éléments de données qui y sont impliqués. Data Vault est une approche hautement normalisée pour la création d'un modèle basé sur les entités, offrant une grande flexibilité, car il n'y a pas de répétition des éléments de données dans le schéma.
Un autre avantage de cette pratique de modélisation est qu'elle garantit une auditabilité et une traçabilité complètes. Elle est également conforme à la norme SEI CMM niveau 5 (architecture répétable, cohérente et redondante) et fournit des modèles conformes aux normes Sarbanes-Oxley, HIPPA et BASIL II.
De quoi s'agit-il exactement ? Data Vault est un ensemble de hubs, de satellites et de liens représentant le processus métier modélisé lors de la phase de modélisation logique des données (prérequis). Il doit être représentatif du ou des domaines sur lesquels vous travaillez ; étude de cas hypothétique ci-dessous. Son utilisation optimale concerne les bases de données opérationnelles ou les entrepôts de données ; il ne remplace pas les schémas en étoile.
Vous trouverez ci-dessous un flux de données hypothétique provenant d'un gestionnaire d'actifs négociant des actions, des obligations, des contrats à terme, des options, etc. Étant donné que certaines transactions financières sont désormais 24h/24 et 7j/7 et qu'une part importante est algorithmique, le « trader » du diagramme est en réalité un logiciel. Le courtier et le teneur de marché peuvent également être une seule et même entreprise, et plusieurs banques dépositaires peuvent être impliquées dans des transactions institutionnelles importantes.
Il arrive qu'une banque dépositaire soit un tiers dont le seul but est de relayer des fonds entre deux ou plusieurs banques dépositaires. C'est souvent le cas sur les marchés internationaux. Ces nuances ajoutent simplement des parties prenantes à la transaction, mais ne modifient pas le processus en lui-même.
L'exemple ci-dessous représente un modèle de données logique attribué, basé sur le diagramme de flux de données ci-dessus. J'ai ajouté les attributs communs qui me semblent particulièrement pertinents, mais cela inclut généralement des éléments supplémentaires qui ajoutent du détail au modèle, mais qui pourraient ajouter du bruit à cet exemple. Je les ai donc laissés de côté.
La traduction du LDM ci-dessus au format physique d'un coffre-fort de données est présentée ci-dessous. Généralement, le LDM se traduit au format physique par une conversion entité-table très similaire, sauf dans les cas où des relations logiques plusieurs-à-plusieurs doivent être implémentées physiquement avec une table associative. Une dénormalisation physique peut alors également se produire, mais cette phase résulte généralement de cycles de tests qui détectent des problèmes de performances. Sans jeu de mots, la dénormalisation n'est pas une pratique courante : on ne commence pas par là ; elle est réactive ou suit un modèle établi.
L'implémentation d'un modèle physique dans un coffre-fort de données est très différente de celle d'un modèle LDM. Vous remarquerez qu'elle ne ressemble pas à un schéma en étoile ni à ses dérivés.
Data Vault suit quelques concepts fondamentaux dans son modèle de conception :
Les conceptions de Data Vault ne remplacent pas l'OLAP implémenté dans les schémas en étoile et leurs dérivés, ni l'OLTP, leur point fort en tant qu'entrepôt de données ou base de données opérationnelle. Il s'agit en quelque sorte d'une approche hybride.
Il est optimisé pour le stockage et non pour les requêtes pilotées par l'utilisateur, en partie en raison d'une stricte adhésion à la troisième forme normale (3NF).
Trois types d'entités : hub, satellite et liens. Vous pouvez utiliser des tables de référence prenant en charge les satellites statiques, par exemple les tables de pays ou de devises, les codes postaux, les poids et mesures.
Les hubs sont des tables dont les données sont peu modifiées. Ils doivent contenir une clé métier. On peut les comparer à des dimensions à évolution très lente.
Les liens sont des associations entre des clés métier, qui sont généralement des hubs, mais pas toujours. Il s'agit d'une entité associative qui résout les relations entre les clés.
Les satellites sont destinés aux attributs temporels et descriptifs, tels que les données générées par la date et l'heure, similaires au contenu des transactions. Ils peuvent entretenir des relations avec d'autres satellites, des données de référence et des liens vers des hubs.
Des liens existent entre les hubs, la table de liens absorbant les clés primaires des hubs. Les hubs peuvent avoir des satellites comme enfants.
Les liens peuvent avoir des satellites comme enfants, mais pas comme parents. La clé primaire du lien est absorbée par le satellite.
Chaque table possède une date de chargement et une source d'enregistrement pour chaque ligne. Elles doivent créer une clé unique lorsqu'elles sont ajoutées à la clé « naturelle » ou « métier » d'une table. Pour les tables sans clé « naturelle », vous pouvez utiliser la clé de substitution. Utilisez des contraintes de clé unique ou des index de clé unique pour forcer cette contrainte (ce dernier point est ma contribution), en supposant que vous utilisiez un SGBD relationnel.
Si vous implémentez le modèle dans un lac de données sans contraintes ni index, vous pouvez utiliser des définitions de partitions et, bien sûr, intégrer la logique nécessaire à votre code. À moins que vous n'écriviez pour Apache Iceberg, où les contraintes peuvent être implémentées dans sa couche de métadonnées.
Selon la base de données de documents que vous utilisez, vous pouvez également utiliser des contraintes.
Pratiques de chargement des données
L'ordre de chargement des tables est important, surtout si vous utilisez des contraintes à l'aide de clés/index. Les hubs sont chargés en premier, ce qui permet de créer des clés de substitution en parallèle. L'étape suivante concerne les liens, avec le chargement des valeurs d'attributs et la création d'associations entre les hubs. Enfin, les satellites, situés à l'extrémité réceptrice des liens ou des hubs, peuvent être chargés en parallèle.
Afin de garantir l'unicité des enregistrements, rappelez-vous que le hachage 3NF est couramment utilisé dans le cadre du traitement ETL/ELT pour comparer le hachage de l'enregistrement entrant à celui des enregistrements actuellement présents dans la table. Les enregistrements ne sont jamais supprimés du coffre-fort de données.
Cas d'utilisation : les principaux cas d'utilisation des coffres-forts de données sont les entrepôts de données opérationnels (ODS) et les entrepôts de données d'entreprise (EDW). Ces deux cas sont parfaitement compatibles pour plusieurs raisons :
L'adhésion stricte à la troisième forme normale (3NF) n'implique pas de champs dénormalisés ou dupliqués dans les tables, ce qui conduit à une utilisation du stockage plus efficace.
Des contrôles d'unicité des données sont intégrés au processus de chargement lorsque des hachages sont utilisés pour confirmer si vous avez déjà stocké cet enregistrement particulier, évitant ainsi toute duplication d'enregistrements. Cela réduit également l'espace de stockage.
L'interrogation des tables dans un coffre-fort de données peut s'avérer complexe pour les utilisateurs finaux. Des connaissances SQL plus avancées sont nécessaires pour interroger les tables dans un coffre-fort de données, contrairement aux utilisateurs finaux classiques. L'accès aux données est plus réservé aux ingénieurs, ce qui le rend peu convivial. Pour exposer les données aux utilisateurs finaux, un SGBDR traditionnel permet de créer des vues pour simplifier leur accès.
Moins d'enregistrements stockés signifie moins de données analysées par les requêtes, donc le temps de récupération pour la sortie avec une requête efficace a moins de travail à faire par rapport à une structure dénormalisée.
Sa conception de table est plus adaptée aux ingénieurs. Elle met l'accent sur la normalisation et les structures qui reflètent un stockage efficace des données plutôt qu'un flux de processus métier.
Je pense que le modèle de conception Data Vault a tout son intérêt, notamment dans les cas où l'on souhaite conserver le maximum de données possible, que ce soit dans un lac de données ou un SGBDR. Il est probablement le plus efficace pour résoudre ce problème, par rapport à tout schéma en étoile ou dérivé d'un schéma en étoile. Le cas ODS concerne généralement des données d'une semaine à plusieurs mois, et il est également bien adapté à ce cas, car la normalisation est bénéfique à tous les niveaux. Ces utilisations spécifiques méritent d'être évaluées.
