Data governance catalog – trinité de définitions : tables, attributs et associations

Just eat the students, said Hufflepuff. There’s no doubt about whether they’re sentient.

HPMOR

Parfois j’ai des doutes si j’habite dans le monde réel ou plutôt dans La Matrix car certaines personnes semblent être vraiment des simulations ou des LLMs. J’ai parlé récemment avec des eXperts de Data Governance qui voulaient me convaincre qu’il n’y avait pas de raison de documenter « les tables » ou « les associations/relations entre les tables » dans un Data Governance Catalog (aka Catalogue de Données). Car selon eux, l’information existe qu’au niveau d’attributs (qu’ils appellent « données »).

Argh ! Ça m’a énervé !

Pour faire court, voici un théorème : à certain niveau d’abstraction, il n’y a aucune différence entre des tables, des attributs et des associations.

Preuve visuelle :

Mon point ici : le cœur de problème est toujours au niveau de définition des objets importants (indiqués par les cercles non-remplis sur le schéma ci-dessus). Le reste (les cercles remplis) est beaucoup plus gérable et toujours améliorable. En faisant le dictionnaire au niveau de champs, nous perdons l’essentiel du modèle – les granularités i.e. les définitions des objets.

Voici la preuve plus technique de « notre théorème » (si vous en avez besoin) :

  • nous pouvons toujours convertir un attribut en association (c’est juste parfois peu utile) : je peux prendre des valeurs uniques d’attributs et les sortir dans une table séparée. C’est ce que nous faisons systématiquement avec la nomenclature/valeurs multiples si nous voulons intégrer plusieurs SI dans un modèle unifié :
  • le processus peut être inversé avec la jointure,
  • nous pouvons convertir l’association en table et c’est ce que nous faisons si l’association commence à toucher plusieurs tables ou commence à avoir la cardinalité n-à-n :
  • etc (champ vers entité = parsing, entité vers champ = concaténation, soit sérialisation) :

Conclusions

Brièvement :

  • en absolue « quoi documenter » est un non-sujet ;
  • la documentation des granularités du cœur de modèle est le nerf de la guerre ;
  • limitation de la documentation aux champs (aka « données » comme certains le disent) est la profanation de l’idée de catalogue de données.

Bonne santé à vous et à vos catalogues de données.