La modélisation de données est-elle morte ?

Avons-nous encore besoin de modèles de données ? Quelle est la valeur des modèles ? Pourquoi la modélisation de données a-t-elle échoué par le passé ? Comment créer des modèles de données ? Comment créer de la valeur grâce à la modélisation ? Je tente de répondre à tout cela dans la présentation suivante.

La modélisation de données est-elle morte ?

La question intéressante est : la modélisation de données est-elle morte ? Et ce n’est pas une question hypothétique. Tout a commencé il y a quelques années lorsque j’étais à une conférence aux États-Unis, et de très célèbres data modelers, qui travaillaient pour de grandes compagnies d’assurance depuis 30-40 ans, demandaient : « La modélisation de données est-elle morte ? » Ils faisaient leur travail, créaient de la valeur, mais ne se sentaient plus appréciés. La valeur de la modélisation de données n’était plus perçue comme avant.

Commençons par comprendre ce qu’est la modélisation de données et pourquoi nous en avons besoin. Pour le contexte, je travaille pour un outil d’automatisation de data warehouse appelé Datavault Builder. Nous croyons au travail sur des modèles métier et à leur conversion automatique en code fonctionnel. C’est ma perspective personnelle.

Permettez-moi de partager mon expérience professionnelle et une histoire simplifiée de la modélisation de données. J’ai commencé à travailler dans le domaine du data warehousing en 2000. J’ai d’abord travaillé pour une institution financière où nous nous concentrions sur la réconciliation de données. Plus tard, j’ai transitionné vers le travail sur des variables de télécommunications et j’ai dirigé une équipe de data management pour un opérateur télécom. Nous avons traité des tâches plus complexes.

En 2012, j’ai été confronté à des défis de data warehousing agile et near real-time. J’ai essayé d’utiliser Data Vault comme paradigme de modélisation, et cela a bien fonctionné. Cependant, nous avons réalisé que l’automatisation était nécessaire pour qu’il soit efficace. Cette prise de conscience en 2012 a posé les fondations de Datavault Builder. Depuis, je suis dans l’entreprise et nous développons cet outil.

Aujourd’hui, mon rôle inclut des activités pre-sales et post-sales, ainsi que la conduite de présentations pour former les gens et favoriser les échanges au sein de la communauté.

Que sont les modèles de données ?

Que signifient les modèles pour moi ? Ils donnent du sens à des choses complexes en les simplifiant. Un modèle est généralement une représentation simplifiée de quelque chose de plus compliqué. Si vous cherchez « ontologie » sur Wikipedia, vous trouverez différents types d’éléments : classes ou concepts, propriétés, relations, axiomes et contraintes. Ces éléments de base de la modélisation de données sont restés cohérents tout au long de l’histoire. Cela signifie que si vous apprenez la modélisation de données à un moment donné, vous serez bien préparé pour de nombreuses années.

Prenons l’exemple d’un arbre. Un vrai arbre avec toutes ses feuilles et branches a des milliers d’aspects différents. Capturer un vrai arbre dans une base de données serait énorme et souvent inutile à des fins analytiques. Nous pouvons créer un modèle plus simple représentant les caractéristiques clés. Même avec cette représentation simplifiée, vous reconnaîtriez l’arbre. Compter les arbres serait simple. Ce niveau de simplicité suffit pour de nombreuses applications.

Il existe une belle image qui illustre la relation entre la chose réelle et son modèle. Elle dit « Ceci n’est pas une pipe » ; c’est une image d’une pipe. C’est une représentation simplifiée en deux dimensions, mais vous reconnaissez ce que c’est. Cependant, il est important de se rappeler que ce n’est pas la chose réelle.

Maintenant, considérons la forêt sur cette image. Nous pouvons simplifier le concept : dans une forêt, il y a beaucoup d’arbres. Un forestier prend soin de la forêt, ou de plusieurs forêts. Différentes espèces d’arbres existent, et il y a des propriétaires. Avec cette image simple, vous comprenez déjà le concept de base.

Cela devient un moyen de communication. Différentes personnes de divers secteurs métier de la même entreprise peuvent se réunir et discuter en s’assurant qu’elles ont la même compréhension. Cette couche leur permet de trouver un terrain d’entente entre IT et métier.

D’où vient tout cela ? Certains affirment qu’Edgar F. Codd est le père des bases de données relationnelles. Il a écrit un livre influent dans les années 1970. Tous les approches ultérieures de modélisation de données reposent sur les mêmes principes : la modélisation de données concerne l’identification et la description des choses, et l’établissement de relations entre elles. Elle implique aussi le travail sur ACID et la normalisation.

Normalisation

La normalisation implique de diviser les données en clés primaires pour l’identification, clés étrangères pour établir les relations, et attributs pour décrire les choses. Un objectif principal de la normalisation est d’éliminer la duplication. Par exemple, au lieu de répéter la description complète d’un type de client pour chaque client, nous pouvons créer une table séparée pour les types de clients et y faire référence par une relation.

Codd s’intéressait aux systèmes OLTP (online transaction processing). Plus tard, de nouveaux systèmes ont émergé visant à fournir de meilleures vues et capacités de reporting. La vitesse est cruciale, car les systèmes data warehousing couvrent une longue période et nous voulons suivre les changements historiques.

Dans le monde du data warehousing, nous préférons utiliser progressivement les business keys pour identifier les entités, garantissant la stabilité dans le temps, même si les systèmes IT sont remplacés.

Le Data Warehouse 3NF

En 1992, Bill Inmon, souvent appelé le père du data warehousing, est entré en scène. Il a commencé à construire le data warehouse et l’a défini comme « une collection de données orientée sujet, non volatile, intégrée et variant dans le temps en support des décisions de management ». Cette définition reste vraie pour de nombreux cas.

Inmon utilisait des bases en troisième forme normale, qui s’amélioraient à l’époque. Il a introduit les surrogate keys pour sauvegarder différentes versions d’informations. Le défi avec cette approche est la maintenabilité. Les clés étrangères sont utilisées, et dans un data warehouse entièrement historisé, tout changement à l’entité customer peut impacter toute l’historique des entités liées. Cet effet en cascade rend les changements extrêmement coûteux.

Le modèle dimensionnel

Quel était le but de ce que Kimball a appelé conformed dimensions ? Il a intégré toutes les données de différents systèmes IT dans une seule customer dimension, dénormalisant les données puisque le stockage est devenu beaucoup moins cher. La dénormalisation rend la requête plus simple avec moins de joins.

Kimball a aussi construit des fact tables épurées référençant différentes dimensions. La maintenabilité reste une préoccupation, surtout avec des dimensions historiques. L’impact est limité à la fact table et aux dimensions puisqu’elles sont des objets dénormalisés.

C’est là que Data Vault entre en jeu et suggère que nous devrions revenir au cœur normalisé et l’améliorer plutôt que de le remplacer. Pour la présentation, le modèle dimensionnel reste approprié, mais il devrait être créé de manière virtuelle ou reconstructible à partir du cœur normalisé.

Modélisation Data Vault

Nous revenons au concept de définition et d’identification, où un objet unique appelé Hub stocke uniquement la clé immuable. Les attributs avec historique sont stockés dans des tables séparées (satellites), et les relations sont stockées dans leur propre table de relation (links). En séparant les fonctions des données dans des objets distincts, Linstedt a obtenu des bénéfices en termes de maintenabilité.

Bien qu’il puisse ne pas être aussi efficace physiquement qu’un star ou snowflake, il offre des avantages en termes de maintenabilité.

L’évolution de la troisième forme normale au modèle Data Vault repose toujours sur le modèle dimensionnel pour les requêtes, qui peut être une vue virtuelle.

Autres approches de modélisation

Apart de ces approches, si vous voulez en savoir plus sur l’Anchor Modeling, je recommande de lire les anciens articles de Lars Rönnbäck. Il a abordé certains problèmes peu automatisés.

Il y a aussi BEAM et l’ensemble logical modeling. L’accent est mis sur un modèle conceptuel d’abord, l’identification des choses ensuite, puis l’ajout des relations et attributs.

La modélisation de données est-elle morte ?

Maintenant, la question finale : la modélisation de données est-elle morte ? Je crois que créer des modèles uniquement sur papier, sans connexion à une implémentation automatisée du monde réel, sans démontrer la valeur directement aux utilisateurs métier, n’est pas une approche efficace. Si vous n’automatisez pas le code, les développeurs auront du mal à comprendre la valeur des modèles.

Un autre problème est le temps qu’il faut pour créer des modèles de données avant de commencer l’implémentation, ce qui ne crée initialement aucune valeur. Au lieu de cela, nous devons adopter la modélisation de données agile, en liant les implémentations conceptuelles, logiques et physiques de manière automatisée.

Conceptuel, logique et physique

Pour moi, le modèle conceptuel est le point de départ du modèle logique, puis nous ajoutons les relations et définitions de clés. Ce qui est important, c’est qu’il y ait une relation directe entre eux, pas seulement du conceptuel au logique, mais aussi vers les implémentations physiques. Cela devrait se faire automatiquement.

Une connexion bidirectionnelle est nécessaire. Si nous voulons réinventer les modèles de données et les rendre efficaces, nous devons passer du conceptuel au logique au physique en temps réel.

CI/CD

Pour y parvenir, nous devons séparer nos environnements de développement, test et production. Si nous visons à devenir vraiment agiles, nous pouvons travailler avec Git et GitFlow, en adoptant une approche de développement distribué.

Dans le monde du data warehousing, nous n’avons pas d’équivalent direct au working folder de Java. Selon moi, l’équivalent est un sandbox.

Pipelines as Code

Une solution alternative proposée par d’autres est d’utiliser pipelines as code. Lorsque nous avons du code, nous pouvons utiliser l’approche working folder. Cependant, il y a un inconvénient majeur : il manque l’aspect modélisation, qui donne du sens au processus. Au lieu de se concentrer sur les besoins métier, la technologie prend le pas, et tout le sens est perdu.

Faire revivre les modèles

La première étape est d’établir un modèle de données agile, et c’est là que Data Vault entre en jeu. Il s’aligne avec le concept fondamental d’incorporation transparente de nouveaux éléments. Le couplage lâche des éléments garantit l’indépendance.

Le second aspect est d’automatiser la transformation d’un artefact de modélisation en artefact physique. Nous pouvons transformer un hub en sa représentation physique de manière déterministe. De même, nous pouvons prendre une table physique et la transformer en objet logique.

Maintenant, nous avons une approche similaire à ceux qui travaillent avec des data pipelines as code, mais avec une couche de sens supplémentaire. Cela comble le fossé et bénéficie aux développeurs et aux professionnels métier, redonnant vie à nos modèles de données.

C’est l’essence de la méthodologie Data Vault, et Datavault Builder facilite un processus de modélisation-vers-code entièrement automatisé.