Dictionnaire de données

Objectif

Le dictionnaire de données fixe, pour chaque élément de données, un nom canonique, les valeurs qu'il peut prendre, le format et la longueur qui les contraignent et le sens que l'organisation lui donne. Il attaque un problème: un élément porte rarement le même sens d'un système à l'autre. Le champ client du CRM désigne le ménage, celui de la facturation désigne le payeur, celui du portail désigne l'utilisateur connecté et les trois portent le même nom. Ce flou a un coût: une interface qui rapproche deux de ces systèmes est fausse au niveau du champ tout en paraissant correcte, un rapport consolidé additionne des grandeurs qui ne mesurent pas la même chose et une migration transporte des valeurs dont personne ne sait plus ce qu'elles signifient.

La technique soutient toute décision qui suppose de savoir ce qu'un champ contient: spécifier une interface entre deux applications, écrire une exigence qui mentionne un attribut, valider une saisie, cadrer une reprise de données, consolider un indicateur produit par plusieurs sources, défendre devant un auditeur la définition d'une grandeur réglementée. Sans dictionnaire, la question « qu'est-ce que ce champ, exactement » reçoit une réponse ad hoc, différente selon l'équipe et le jour. La technique sert les tâches d'analyse des exigences et de définition de la conception, où elle spécifie la structure et le contenu des données d'une solution.

Le livrable est le dictionnaire lui-même: une entrée par élément de données, primitif ou composite, chacune portant son nom, ses alias, ses valeurs et significations et sa définition, augmentée pour les composites de leur règle de composition. Il prend la forme d'un tableau ou d'un jeu de tableaux liés, tenu dans un tableur, un wiki ou un outil spécialisé, et il est fréquemment apparié à un modèle de données. Le BABOK le désigne aussi comme un référentiel de métadonnées: son contenu est la description gouvernée des données de l'organisation, leur nom, leur format, leurs valeurs admises et leur sens. Son bénéfice se mesure à un test: un développeur, un analyste ou un auditeur qui rencontre un champ inconnu trouve en une minute son sens, ses valeurs admises et son propriétaire, sans interroger la personne qui a écrit le système il y a douze ans.

Usage

Quand l'utiliser

• Intégration entre plusieurs systèmes: le même champ doit signifier la même chose des deux côtés de l'interface.
• Reprise ou migration de données: établir ce que contient chaque champ source avant de le transporter.
• Indicateur consolidé de plusieurs sources: fixer la définition unique de la grandeur avant d'additionner des chiffres.
• Modèle de données en construction: donner aux attributs de l'entité leur format, leur longueur et leurs valeurs admises.
• Périmètre réglementaire ou audité: la définition d'un champ doit être défendable et tracée devant un contrôleur.
• Système hérité sans documentation: reconstituer le sens des colonnes avant toute évolution ou tout remplacement.
• Alias multiples pour un même champ: plusieurs métiers nomment différemment la même donnée, un nom canonique s'impose.
• Travail analytique sur des données sources: l'analyse dépend de ce que chaque champ contient exactement.

Quand ne pas l'utiliser

• Ambiguïté située au niveau du terme métier: c'est le travail du glossaire, le format du champ ne tranchera rien.
• Application isolée, jetable, propre à une seule équipe: lire le schéma directement, le dictionnaire coûte plus qu'il ne rend.

Description

L'entrée du dictionnaire: quatre champs

Le BABOK consigne quatre informations pour chaque élément de données (§10.12.3.2) et les donne toutes les quatre comme obligatoires. Une entrée amputée de l'un de ces champs cesse de rendre le service pour lequel le dictionnaire existe.

• Nom: le nom unique de l'élément, celui auquel les éléments composites se réfèrent. C'est la clé du dictionnaire: deux éléments distincts ne peuvent pas porter le même nom, sous peine de rendre toute composition ambiguë.
• Alias: les noms alternatifs employés par les parties prenantes pour désigner le même élément. Le champ existe parce que l'organisation, elle, ne renonce pas à ses habitudes: le service client dit « numéro d'assuré », la comptabilité dit « NAVS13 », le système alémanique affiche « AHV-Nummer ». Enregistrer les trois en alias d'un seul nom canonique fait remonter la duplication silencieuse au moment où elle se voit encore.
• Valeurs et significations: la liste des valeurs admises, sous forme de liste énumérée ou de description du format autorisé, longueur et nombre de caractères compris. Quand les valeurs sont abrégées ou codées, leur signification est explicitée: un élément dont les valeurs admises sont 1, 2 et 3 est inexploitable tant que le dictionnaire ne dit pas que 1 vaut « prospect », 2 « client actif » et 3 « client résilié ». Ce champ porte le plus de travail et le plus de valeur.
• Description: la définition de l'élément dans le contexte de la solution. Elle dit ce que l'élément mesure, désigne ou identifie dans ce système, pour cette organisation. La norme ISO/IEC 11179-4 fixe les règles d'écriture de cette définition. Une définition d'élément de données dit ce que le concept est. Une formulation qui se borne au négatif ne définit rien: « ce champ n'est pas la date de résiliation » laisse ouvert tout ce que le champ contient. Elle est au singulier. Elle est une phrase ou un syntagme descriptif. Elle se suffit à elle-même, c'est-à-dire qu'elle se comprend sans ouvrir une autre entrée. Elle est exempte de raisonnement circulaire: le terme défini ne réapparaît pas dans sa propre définition. Elle ne loge ni la justification, ni la procédure de saisie, ni l'usage fonctionnel du champ, qui ont chacun leur place ailleurs. La première de ces règles est celle que l'on viole le plus souvent.

Un dictionnaire réel ajoute presque toujours deux colonnes que le BABOK ne nomme pas et que la pratique impose: le propriétaire et les règles de validation qui s'appliquent à la valeur, quand elles vont au-delà du format (un chiffre de contrôle, une plage, une dépendance à un autre élément). Les deux servent la maintenance, qui est le point faible structurel de la technique.

Le propriétaire tranche trois questions qu'aucune lecture du schéma ne tranche: quelles valeurs sont admises, ce que l'élément signifie quand deux systèmes en donnent des lectures divergentes et si un changement de format part en réalisation. Son autorité tient à sa place dans l'organisation: le service qui répond du processus où la donnée naît est le seul qui puisse engager l'entreprise sur la définition de cette donnée. Le dictionnaire enregistre cette responsabilité et la rend consultable.

Éléments primitifs, éléments composites et la notation de composition

Un élément primitif est atomique: il porte une valeur unique, contrainte par un format et une longueur, et il ne se décompose plus utilement pour l'organisation. Un élément composite est construit à partir d'autres éléments, primitifs ou eux-mêmes composites, assemblés selon une règle de composition. La règle est écrite dans une notation compacte. Cette notation fait du dictionnaire une structure.

Le BABOK nomme trois mécanismes de composition et ne donne de symbole que pour la séquence: la séquence (l'ordre imposé des éléments primitifs concaténés dans la structure composite, marqué par un signe plus, comme dans Customer Name = First Name + Middle Name + Family Name), la répétition (un ou plusieurs éléments peuvent apparaître plusieurs fois) et l'élément optionnel (il peut ou non figurer dans une instance donnée du composite). La notation classique de l'analyse structurée, dont la technique est issue et que Tom DeMarco a fixée en 1978, ajoute un quatrième opérateur, la sélection, et donne à chacun des quatre un symbole. La plupart des dictionnaires réels emploient cette notation à quatre opérateurs.

La discipline qui donne son intérêt à la notation tient en une règle: un composite référence des éléments déjà inventoriés par leur nom, il ne les redéfinit jamais en ligne. Écrire Adresse client = Rue + Numéro + (Complément) + NPA + Localité + Canton suppose que les six éléments existent chacun comme entrée du dictionnaire, avec leur format et leurs valeurs. Recopier « quatre chiffres, plage 1000 à 9999 » dans la définition de l'adresse au lieu de nommer NPA réintroduit la duplication que la technique existe pour supprimer et garantit que les deux copies divergeront.

Rapport aux techniques voisines

Ces techniques travaillent le même matériau et se confondent facilement.

Le glossaire définit les termes métier, pour des humains, en prose: il dit ce qu'est un client, ce qu'est une police, ce qu'est un sinistre. Il est le point d'entrée d'un vocabulaire partagé. Le dictionnaire de données définit les éléments de données et leur structure: le format, la longueur, les valeurs admises, la composition. Les deux convergent souvent sur le même mot: le glossaire dit ce qu'un client est pour l'entreprise, le dictionnaire dit quels champs le décrivent et quelles valeurs sont admises dans chacun.

La modélisation des concepts capture le vocabulaire et le sens: des concepts nominaux, des concepts verbaux qui les relient en faits, indépendamment de toute représentation technique et lisibles par des gens du métier qui refuseraient un diagramme de classes. Le modèle de concepts répond à « de quoi parlons-nous et qu'affirmons-nous à ce sujet ». Le dictionnaire de données répond à « quels champs portent cela, dans quel format, avec quelles valeurs ». Le second se construit mieux quand le premier existe. Les règles métier s'écrivent dans le vocabulaire du premier et se valident contre les valeurs admises du second.

La modélisation des données donne la structure et les relations: les entités, leurs attributs, les cardinalités, les clés. Le dictionnaire définit les éléments dont ces attributs sont faits. Le BABOK note que le dictionnaire s'emploie souvent conjointement à un diagramme entité-association et peut en être extrait. En pratique la répartition est nette: la cardinalité entre Client et Police n'a aucune place dans un dictionnaire, et le format exact du numéro AVS n'a aucune place dans un diagramme entité-association. Le contrôle croisé vérifie que chaque attribut du modèle se résout en une entrée du dictionnaire.

Construire et maintenir le dictionnaire

1. Délimiter la population d'éléments
   Une solution, un domaine ou l'entreprise entière: la décision commande tout le reste, et une ambition d'entreprise sans gouvernance d'entreprise produit un document mort. Le BABOK range cette portée parmi les limites de la technique: faute d'avoir considéré les métadonnées qu'appellent les autres scénarios d'usage, un dictionnaire garde peu de valeur à l'échelle de l'entreprise. Partir des artefacts qui référencent déjà des éléments (modèles de données, spécifications d'interface, formulaires, rapports, schémas de bases).
2. Inventorier d'abord les éléments primitifs
   Pour chaque champ rencontré, saisir le nom, les alias en usage, les valeurs et significations (énumération ou format avec longueur et plage) et la description dans le contexte de la solution.
3. Résoudre les synonymes et les homonymes avant d'arrêter les noms
   Deux équipes nomment différemment le même élément: choisir un nom canonique, verser les autres en alias. Deux équipes emploient le même nom pour deux choses différentes: scinder en deux éléments aux noms désambiguïsés. C'est l'étape à plus haute valeur et celle que l'on saute le plus souvent.
4. Construire les éléments composites
   À partir des primitifs résolus, avec la notation de composition, en référençant chaque constituant par son nom. Poser la sélection au bon niveau: quand deux cas de figure appellent des constituants différents, l'alternative porte sur les groupes entiers.
5. Croiser avec le modèle de données
   Lorsqu'il existe ou se construit en parallèle: chaque attribut du modèle doit se résoudre en une entrée, et le dictionnaire ne doit pas porter d'élément qu'aucun modèle ni aucune interface n'utilise. Les entrées mortes pourrissent le plus vite, parce que personne ne remarque qu'elles sont fausses.
6. Désigner une personne par élément ou par domaine
   Le BABOK signale l'effort de tenue à jour comme la limite de la technique: la discipline de maintenance suppose une personne responsable de l'exactitude et de la complétude de chaque entrée. Une équipe ne répond de rien.
7. Publier et raccrocher le dictionnaire aux artefacts qui le consomment
   Un dictionnaire consulté est un dictionnaire atteignable depuis l'endroit où la question se pose: l'exigence, la spécification d'interface, le rapport, le schéma. Isolé dans son propre document, il n'est ouvert que par celui qui l'a écrit.
8. Maintenir sur déclencheur
   Le changement qui modifie le schéma est le changement qui met à jour l'entrée, dans la même demande de fusion ou le même ticket. Une tâche séparée « revoir le dictionnaire » est une tâche que l'on repousse.
9. Auditer périodiquement le dictionnaire contre le schéma réel
   Une comparaison automatisée entre ce qui est documenté et ce que la base contient (types, longueurs, contraintes, valeurs observées) rattrape la dérive avant qu'une partie prenante ne fasse confiance à une définition fausse.

Quand le système porte déjà son dictionnaire

Certains systèmes déclarent eux-mêmes la structure de leurs données, sous une forme lisible par une machine et exacte par construction. Le dictionnaire s'y extrait au lieu de s'y rédiger, et le travail se déplace vers la moitié que la machine ne porte pas: le nom canonique, les alias, la signification des valeurs et le propriétaire.

Le catalogue d'une base relationnelle

Tout système de gestion de bases de données relationnelles décrit son propre schéma dans des tables système interrogeables en SQL. La norme ISO/IEC 9075-11 normalise cet accès sous le nom d'INFORMATION_SCHEMA, et chaque moteur y ajoute ses propres vues, qu'Oracle appelle son data dictionary. Une requête sur ces vues rend, pour chaque colonne de chaque table, le type, la longueur, la précision, le caractère obligatoire ou facultatif, les clés et les contraintes. Cette moitié de l'entrée est exacte à l'instant où elle est lue: le format documenté et le format effectif sont le même objet.

Les valeurs admises s'en déduisent en partie. Une contrainte CHECK énumère les valeurs admises d'une colonne codée, et une clé étrangère vers une table de référence rend mieux encore, puisque cette table porte le code et son libellé côte à côte. La signification, elle, se trouve là où quelqu'un l'a mise. Le nom de la colonne la suggère sans jamais la garantir: dat_resil se devine, se lit de trois façons et ne fait autorité sur aucune. Les commentaires de schéma (COMMENT ON TABLE et COMMENT ON COLUMN chez Oracle, PostgreSQL et Db2, les propriétés étendues chez SQL Server) sont le seul endroit où une définition voyage dans le même script que la structure qu'elle décrit, donc le seul endroit où les deux ne peuvent pas diverger. Là où l'équipe tient cette discipline, une partie du champ Description arrive avec le schéma.

Ce cas déplace le coût de la technique sans le supprimer. L'étape 2 devient une extraction de quelques minutes, l'étape 9 devient continue et gratuite, l'essentiel de l'effort se reporte sur les étapes 3 et 6, soit les synonymes, les homonymes et la responsabilité de l'exactitude. Une entrée extraite est exacte sur le format et muette sur le sens. Prendre le nom d'une colonne pour une définition produit un dictionnaire dont chaque ligne a l'air documentée.

Le dictionnaire actif d'un progiciel

Un dictionnaire est actif quand le système est engendré à partir de lui plutôt que rapporté à lui. Certains progiciels de gestion intégrés tiennent le dictionnaire de cette manière. L'ABAP Dictionary de SAP en est le cas de référence.

La conséquence renverse celle du dictionnaire tenu à la main. La documentation de SAP énonce le premier effet: modifier un domaine existant affecte tous ses utilisateurs, et les clés étrangères qui s'appuient sur les champs concernés peuvent devenir incohérentes. Un changement de longueur ou de type va plus loin et impose la conversion des tables concernées. Élargir le domaine d'un numéro de fournisseur touche toutes les tables dont un champ en dérive, plus les écrans et les interfaces qui en affichent les libellés. La plateforme garantit ici la propriété que le dictionnaire manuel poursuit par la discipline: une définition écrite une fois et une seule. Le prix en est la portée: un changement de format est global par construction, donc il ne se pilote pas module par module.

Deux précisions valent d'être posées, parce que la confusion entre elles se paie cher. D'abord, un objet du dictionnaire se modifie par le développement et se transporte comme du code; sur un domaine livré par l'éditeur, l'opération est une modification du standard. Promettre un « simple paramétrage » pour allonger un champ revient à promettre une conversion de tables. Ensuite, la longueur employée par le métier ne se règle presque jamais au dictionnaire. Le numéro de client repose sur un domaine de dix caractères qui ne bouge pas; à travers le groupe de comptes, la plage de numéros et le choix entre attribution interne et externe, le paramétrage fixe le nombre de caractères effectivement utilisés à l'intérieur de ce format. Une plage externe à six chiffres produit un numéro que l'utilisateur lit 123456 et que la base stocke 0000123456, la routine de conversion attachée au domaine complétant les zéros de tête.

Une entrée qui recopie CHAR(10) depuis le dictionnaire est exacte et trompeuse: elle donne le format du contenant et tait la règle qui gouverne les valeurs, laquelle vit dans le paramétrage. Elle tait aussi que l'élément a deux formes, une interne et une externe, dont la seconde est celle que le métier nomme et que tout fichier d'échange transporte. Le champ Valeurs et significations se remplit donc depuis le paramétrage, et le champ Alias enregistre les deux formes. Le même écart se retrouve à l'échelle de l'objet: depuis l'introduction du partenaire d'affaires comme objet pivot, un client et un fournisseur sont deux rôles d'une même partie, qui porte son propre numéro à côté du numéro de client et du numéro de fournisseur. Trois identifiants désignent alors la même partie, et le dictionnaire ne dit pas lequel le métier appelle « le numéro ».

Le dictionnaire actif rend en revanche ce que peu de sources rendent: des libellés déjà traduits, une documentation par élément et une garantie d'exactitude technique. Ce qu'il tait reste entier: le nom que le métier emploie, le propriétaire de la définition et l'usage réel du champ. Un champ standard détourné vers un autre usage par l'entreprise se lit correct au dictionnaire et faux dans les données.

Le dictionnaire dans une initiative analytique

La colonne des règles de validation que la pratique ajoute aux quatre champs du BABOK a son ancrage: le Guide to Business Data Analytics de l'IIBA (§3.4) étend l'entrée aux règles métier et aux règles de validation, y compris pour les éléments dérivés et transformés. La colonne du propriétaire relève de la pratique seule.

Le guide nomme la règle métier à côté de la règle de validation, et le modèle à six colonnes ne lui donne pas de colonne. La question se pose dès la première entrée dérivée. La règle qui calcule un élément dérivé se loge dans Valeurs et significations, à côté du format et de la liste des valeurs admises, parce qu'elle dit ce que l'élément vaut. Les règles de validation gardent ce qui rejette une valeur candidate: un chiffre de contrôle, une plage, une dépendance à un autre élément. La règle métier qui gouverne l'élément sans le calculer ni le contraindre appartient au référentiel des règles métier, que le dictionnaire cite par le nom de la règle au lieu de la recopier.

Le guide ajoute une question que le dictionnaire d'une solution unique n'a pas à poser: où se trouve l'élément. Dans une initiative analytique, le dictionnaire localise chaque élément à travers les systèmes de l'organisation, ce qui en fait l'inventaire de ce qui existe réellement avant que la question de recherche ne soit formulée. Croisé avec un modèle entités-relations, il dit comment joindre les données de plusieurs sources: le type, le format et la longueur décident si la jointure est possible.

Ce qui fait échouer l'exercice

La divergence silencieuse d'avec le schéma réel

C'est le piège central, mortel parce qu'il est invisible. Le dictionnaire est écrit une fois, à la clôture du projet, puis le schéma évolue: une colonne est élargie, une énumération gagne une valeur, un champ est détourné de son usage d'origine et personne ne touche l'entrée correspondante. Le dictionnaire périmé coûte alors plus cher que l'absence de dictionnaire, parce qu'il est encore consulté et cru: un développeur lit le format documenté, construit une validation dessus et se trompe d'une manière qui a l'air autorisée. Sans dictionnaire, la même personne serait allée regarder le système. Les étapes 8 et 9 existent pour cette seule raison.

Dupliquer le glossaire

Écrire dans la Description ce que « client » signifie pour l'entreprise produit deux documents qui se contrediront dès que l'un sera mis à jour et pas l'autre. La Description reste bornée à l'élément dans le contexte des données de la solution, et le débat sur le terme métier renvoie au glossaire.

L'aveuglement aux homonymes

Traiter le client du CRM et le client de la facturation comme un seul élément parce qu'ils portent le même nom produit une intégration fausse au niveau du champ, tandis que le dictionnaire, lui, annonce une cohérence parfaite. L'étape 3 est la seule parade.

Le composite qui recopie ses constituants

Recopier les constituants en clair dans la définition d'un composite ruine l'unicité de la source et rétablit la duplication que la technique supprime.

La sélection posée trop bas

Écrire l'alternative entre deux identifiants, puis exiger de tous les cas les attributs d'un seul, produit une règle de composition qui admet un cas et le rend aussitôt invalide. L'alternative se pose sur le groupe entier des constituants qui dépendent du cas retenu.

Le glissement vers le catalogue d'entreprise sans la gouvernance correspondante

Vouloir tenir à la main, en plus des quatre champs, la traçabilité amont-aval, des indicateurs de qualité et des droits d'accès produit un document trop lourd pour être maintenu. Ces dimensions relèvent d'une plateforme de catalogage et de son modèle de responsabilité.

La valeur codée dont la signification n'est jamais écrite

Une énumération 1, 2, 3 sans sa légende transforme le dictionnaire en index vide. Le BABOK le dit explicitement: une valeur abrégée porte l'explication de son sens.

Considérations IA

La rétro-ingénierie est l'usage le plus net. Un modèle de langage lit un schéma de base de données (noms de colonnes, types, contraintes, index), lit le code qui l'écrit et le lit, observe un échantillon de valeurs et produit un premier jet d'entrées: un nom canonique proposé, des alias repérés dans les différents systèmes, un format et une longueur déduits du type, une énumération reconstituée depuis les valeurs distinctes rencontrées. Sur un schéma hérité de plusieurs centaines de colonnes non documentées, ce premier jet transforme un chantier de plusieurs semaines en une revue de quelques jours.

La détection de dérive est l'usage à plus haute valeur, parce qu'il attaque le piège central de la technique. Comparer en continu ce que le dictionnaire déclare (format, longueur, valeurs admises) et ce que le schéma vivant contient réellement (type effectif, contrainte effective, distribution des valeurs observées) est un travail mécanique, répétitif et ingrat, exactement le genre de vigilance que l'attention humaine ne soutient pas sur la durée et qu'une chaîne outillée soutient sans effort. Une valeur inconnue apparue dans une colonne énumérée, une longueur dépassée, une colonne disparue: chacun de ces écarts se remonte comme une alerte au propriétaire de l'élément.

Le troisième usage porte sur les synonymes et les homonymes entre systèmes. Confronté à deux schémas ou à deux dictionnaires existants, un modèle signale les paires « ces deux champs décrivent probablement la même chose sous deux noms » et les cas « ce nom désigne deux choses différentes dans ces deux bases », à partir des noms, des types, des distributions de valeurs et du contexte. Il accélère l'étape 3 en produisant les candidats; l'arbitrage reste humain.

La limite est nette et porte sur le sens. La signification faisant autorité d'un élément de données est un fait d'entreprise. Un modèle qui observe une colonne statut_client contenant les valeurs 1, 2 et 3, constate que les lignes à 3 n'ont plus d'activité récente et conclut que « 3 signifie probablement résilié » a produit une conjecture présentée comme une définition, indiscernable dans le dictionnaire d'une valeur que le métier a confirmée. La colonne peut tout aussi bien coder un statut de blocage administratif hérité d'un système remplacé en 2014. Aucun modèle ne peut trancher, parce que la réponse est une décision que l'organisation a prise ou qu'elle doit prendre. Chaque entrée rédigée par une machine est une proposition adressée au propriétaire de l'élément, qui la confirme avant qu'elle n'entre au dictionnaire comme un fait. Le même principe vaut pour la sensibilité des données: exposer un schéma de production, ses échantillons et ses distributions à un service externe est une décision de protection des données, prise avant l'usage.

Exemples

L'exemple est le dictionnaire d'un assureur maladie de Suisse romande, restreint aux éléments qui décrivent une personne assurée et ses coordonnées. Chaque entrée porte les quatre champs du BABOK (nom, alias, valeurs et significations, description) et les deux que la pratique ajoute (propriétaire, règles de validation). Le format et la longueur vivent dans « Valeurs et significations »: le BABOK y range la description des formats autorisés, nombre de caractères compris. Les identifiants suisses éprouvent cette colonne champ par champ, parce que leur format est contraint et que la contrainte est vérifiable.

Une lecture involontaire sort du tableau. « Numéro de police » est la désignation cadastrale romande du numéro de bâtiment, et « police » est le contrat d'assurance. Dans le dictionnaire d'un assureur, un seul mot français désigne ces deux choses sans rapport, et l'une des deux apparaît aussi dans la cardinalité entre Client et Police. C'est un homonyme du français, et la parade est celle de l'étape 3: écarter l'alias ou le retenir en le désambiguïsant, « Numéro de police du bâtiment ». Le tableau retient la seconde issue. Seul le champ Alias a fait remonter le conflit.

Les éléments composites se construisent ensuite à partir de ces primitifs, sans jamais en redéfinir aucun. Ensemble, ces règles emploient les quatre opérateurs de la notation.

Un trou de validation sort de la mise en composition. Le tableau des primitifs demande déjà la confirmation de l'adresse électronique avant qu'elle serve de canal. La dépendance de présence, en revanche, n'apparaît qu'à la composition: Coordonnées client rend l'E-mail facultatif, tandis que Canal préféré autorise de le choisir. Le canal préféré ne peut donc valoir « E-mail » que si l'adresse est renseignée.

Visualisations

L'arbre de composition montre d'un coup d'œil ce que la notation dit en une ligne, et il rend visible ce que la ligne cache: la profondeur. Assuré référence Adresse client et Coordonnées client, qui référencent à leur tour des primitifs, et cette imbrication distingue un dictionnaire d'une simple liste de champs. La nature du lien se lit sur le connecteur: Complément est optionnel dans cette composition, et le même élément primitif serait obligatoire dans une autre. La sélection exige l'arbre plus nettement encore. Elle contraint un groupe de branches, dont exactement une est retenue, et aucune marque posée sur un élément isolé ne peut énoncer cette contrainte.

L'arbre est aussi l'instrument de contrôle du dictionnaire, et il révèle des défauts qu'un tableau de règles lues ligne à ligne laisse passer. Une feuille orpheline, un constituant qui n'apparaît nulle part comme entrée du dictionnaire, est une redéfinition en ligne: le composite a recopié son constituant en clair. Un primitif que nul composite ne référence est soit une entrée morte, un élément qu'aucun modèle ni aucune interface n'utilise et que l'étape 5 prescrit d'écarter, soit le signe qu'un composite a été oublié. Un cycle, un composite qui par une chaîne de références finit par se référencer lui-même, est une composition circulaire, indétectable dans un jeu de règles pris une à une et immédiate à l'œil sur l'arbre. Ces trois contrôles rattrapent ce que l'étape 9 rattraperait plus tard, contre le schéma réel et pour plus cher.

Coût

Outils

Un tableur partagé ou une page de wiki suffisent tant que le périmètre est borné, l'équipe unique et le schéma stable. Le coût de licence est nul, la structure du dictionnaire se plie aux colonnes et le tri par nom ou par alias fait remonter les doublons. La limite est connue d'avance: la maintenance est manuelle, donc elle repose sur la discipline, donc elle cède la première fois qu'une livraison est pressée. Ce choix se défend quand la volatilité du schéma est faible, et il se paie quand elle ne l'est pas.

La couche suivante vit dans le code. dbt docs et les outils équivalents de la couche de transformation génèrent la documentation des éléments depuis le schéma modélisé, à chaque construction: la description est écrite dans le même dépôt que la transformation, elle est revue dans la même demande de fusion et elle ne peut pas dériver du schéma puisqu'elle en est extraite. C'est la réponse structurelle au piège central, et elle convient dès que les données vivent déjà dans une chaîne de transformation. Les registres de schémas (pour les données d'événement et de flux) vont plus loin sur un périmètre plus étroit: ils versionnent la définition structurelle et refusent à la production un message non conforme, ce qui offre une protection forte contre la dérive, sur ce seul segment de données et sans porter les alias ni la description métier.

Les catalogues de données se justifient quand le périmètre est l'entreprise, que plusieurs systèmes doivent être recoupés et que l'organisation peut investir dans un modèle de responsabilité. Collibra et Alation sont les plateformes commerciales établies: elles collectent automatiquement les métadonnées techniques des schémas vivants, ce qui attaque la dérive, et posent au-dessus des flux de gouvernance (propriétaire, validation, cycle de vie de la définition). DataHub et OpenMetadata offrent la même famille de fonctions en logiciel libre et sont l'option à considérer quand le prix de licence est le point bloquant, au prix de l'exploitation de la plateforme.

Le cadre de référence de tout cet outillage est la norme ISO/IEC 11179, qui définit les registres de métadonnées: la partie 1 pose le cadre général, et la partie 4 fixe les règles d'écriture d'une définition d'élément de données. Le DAMA-DMBOK, référentiel de la gestion des données, place le dictionnaire dans le chapitre de la gestion des métadonnées et en donne le modèle de responsabilité. Les deux valent la lecture avant de choisir une plateforme, parce qu'ils décrivent ce que la plateforme est censée porter.

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.12 Data Dictionary.
• ISO/IEC 11179-1, Information technology - Metadata registries (MDR) - Part 1: Framework: le cadre normatif des registres de métadonnées, dont le dictionnaire de données est la forme la plus courante.
• ISO/IEC 11179-4, Information technology - Metadata registries (MDR) - Part 4: Formulation of data definitions: les règles d'écriture d'une définition d'élément de données, référence directe du champ Description.
• ISO/IEC 9075-11, Information technology - Database languages SQL - Part 11: Information and definition schemas (SQL/Schemata): la norme qui définit l'INFORMATION_SCHEMA, l'accès normalisé au catalogue d'une base relationnelle.
• DAMA International, DAMA-DMBOK: Data Management Body of Knowledge, chapitre de la gestion des métadonnées: le modèle de responsabilité et de gouvernance des référentiels de métadonnées.
• SAP, ABAP Keyword Documentation, ABAP Dictionary: Technical Attributes of Domains: les attributs techniques portés par un domaine et la portée d'une modification sur tous les champs qui en dérivent.
• Tom DeMarco, Structured Analysis and System Specification, Yourdon Press, 1978: la source de la notation de composition classique à quatre opérateurs (séquence, répétition, optionnel, sélection).
• IIBA, Guide to Business Data Analytics, §3.4 Data Dictionary: l'extension de l'entrée aux règles métier et de validation (éléments dérivés compris) et la localisation d'un élément à travers plusieurs systèmes.