3NF et Data Vault : rien à craindre

De temps en temps nous recevons une question intéressante : Datavault Builder supporte-t-il 3NF ? La réponse est oui — et voici comment.

3NF et Data Vault : rien à craindre

De temps en temps nous recevons une question intéressante de la part de personnes intéressées par Datavault Builder : l’outil d’automatisation DWH supporte-t-il le 3NF ? La réponse intéressante est : oui. Bien que nous ayons activement décidé de ne pas créer de cœur 3NF, parce que nous croyons que diviser les données en fonctions individuelles comme les clés (hubs), les relations (links) et le contexte/attributs (satellites) résout de nombreux problèmes des DWH 3NF. Cela inclut la création de modèles, qui peuvent maintenant être créés à partir de différents points de départ et peuvent facilement grandir ensemble, ainsi qu’une maintenance plus facile en cas de changements de modèle et également l’indépendance des chemins de chargement individuels. Et ce ne sont que trois des nombreux avantages. Nous demandons donc généralement quelle est l’exigence métier pour utiliser 3NF. La plupart des réponses peuvent se résumer au fait que les consommateurs de données étaient habitués à un cœur 3NF et ne sont pas sûrs de pouvoir aussi gérer les requêtes depuis un modèle Data Vault.

Utilisez des interfaces

C’est le moment de souligner clairement : personne ne devrait interroger directement le cœur. À mon avis, ce n’était déjà pas le cas pour les modèles Inmon et cela s’applique encore plus explicitement aux cœurs Data Vault. Clairement, des interfaces doivent être créées pour les requêtes. Elles amènent les données dans un format optimisé pour les requêtes et les rapports. Très souvent ces interfaces sont créées comme un modèle dimensionnel puisque de nombreux outils de reporting modernes sont optimisés pour cela. Cependant, comme nous avons un niveau de normalisation plus élevé dans le Data Vault, nous pouvons également fournir des interfaces à un niveau plus fin comme 3NF.

Architecture Data Vault cœur-vers-interface : génération automatique de couches d’interface 3NF et dimensionnelles à partir du même modèle

Comment créer une couche 3NF

Si vous avez capturé les cardinalités attendues dans la modélisation Data Vault (un-à-plusieurs, plusieurs-à-plusieurs, etc.), vous avez même toutes les informations pour traduire de manière déterministe un modèle Data Vault en interface 3NF :

  • La business key du hub ou le hash est assigné comme PK

  • Toutes les business keys/hashes des hubs connectés en plusieurs-à-un ou un-à-un deviennent des clés étrangères

  • Tous les champs des satellites deviennent des attributs

Data Vault vers 3NF : les business keys des hubs deviennent les PK, les liens plusieurs-à-un deviennent des clés étrangères, les champs des satellites deviennent des attributs

Que vous créiez ceci comme une vue As-of-Now ou As-of-Then n’a pas d’importance. Vous pouvez simplement parcourir la liste des hubs et créer la vue 3NF par hub sans aucune entrée utilisateur. Si vous ajoutez maintenant un satellite dans le Data Vault, vous devez simplement régénérer la vue pour ce hub. Facile à créer, facile à ajuster. Comme nous offrons des APIs pour toutes les fonctions dans Datavault Builder, il est facile de les utiliser pour créer des vues d’interface entièrement automatiquement selon vos propres règles. En théorie, les consommateurs de données ne sauront jamais que leurs données sont stockées au format Data Vault.

Data Vault et 3NF ?

Notre réponse est donc : oui, nous supportons 3NF pour présenter les données, mais utilisez toujours un Data Vault pour les stocker. Cela pourrait bien être le message pour convaincre aussi les consommateurs de données qui veulent l’assurance qu’ils peuvent continuer à travailler avec leurs approches existantes. Et si cela ne fonctionne pas, vous pourriez même cacher à leurs yeux la façon dont vous organisez votre back-office. Après tout, quand nous allons faire les courses, nous ne visitons pas l’entrepôt du centre commercial mais nous nous réjouissons des étagères bien achalandées.