La raison d’être d’un data dictionary réside dans la nécessité de construire un vocabulaire commun entre tous les acteurs d’un projet sur l’aspect particulier des données.

Le partage d’un vocabulaire commun facilite la communication entre tous les acteurs du projet. Il constitue un facteur clé de succès pour éviter les ambiguïtés dues à des interprétations différentes des concepts manipulés au sein d’un projet de développement d’application.

La mise en place d’un data dictionary est indissociable de la mise en place d’un glossaire propre au projet. Le data dictionary n’est en fait qu’un subset du glossaire projet.

Plus d’explications dans mon blogpost précédent : “Pourquoi et qu’est-ce qu’un data dictionary ?”

Comment construire un data dictionary ?

La construction d’un data dictionary peut s’appuyer sur quelques notions simples et normalement bien connues.

Le diagramme de contexte

Les premières opportunités pour commencer à alimenter le data dictionary résident dans les flux identifiés via le diagramme de contexte. En effet, les données entrantes et sortantes du système à construire constituent autant d’éléments permettant l’établissement d’un modèle de données métier (business data model). Voir aussi que ces données alimentent indirectement la définition des besoins fonctionnels. En effet, les données doivent être alimentées, consultées et mises à jour. Elles sont aussi l’objet de calculs. Autant de fonctionnalités à prévoir qui ne peuvent être exécutées sans disposer des données (la matière première du métier).

Si le projet couvre plusieurs domaines métiers un diagramme de contexte sera établi par domaine métier.

Le modèle de données conceptuel ou la définition des entités métiers

Pour chaque domaine métier, l’étape suivante est d’établir le modèle conceptuel de données (conceptual data model) en précisant pour chaque classe l’ensemble des entités ainsi que les relations entre classes. Idéalement sous la forme d’un diagramme entités-relations en UML. Comme dit précédemment, l’ensemble de ces données permettra d’identifier l’essentiel des fonctionnalités à prévoir (alimentation, consultation, mises à jour, traitements).

La définition des attributs au sein des entités métiers (modèle de données logique)

La troisième étape consiste à définir la signification de chaque classe, attribut et association du data model. Les définitions données dans le data dictionary devront (idéalement) avoir une valeur universelle dans tout le projet. Si tel n’est pas le cas, et ce n’est pas rare (les significations peuvent varier d’un domaine métier à l’autre), il convient de relever les différentes définitions existantes dans le scope du projet et de les mettre en évidence. Il s’agira alors, dans la mesure du possible, de procéder à une unification. Mais des divergences peuvent devoir rester. Il faut alors impérativement en être conscient et bien entendu les documenter.

La localisation des données (modèle de données physique)

La quatrième étape consiste à préciser la localisation physique des données : dans quelle base de données et quelle table se trouvent les classes et attributs.

Cette étape doit aussi s’intéresser à l’existence de dupliquas éventuels et donc faire la différence entre source authentique (la source dans laquelle se trouve la vérité sur la donnée) et les doublons éventuels.

Les règles métiers

La cinquième étape s’intéressera à l’identification des contraintes et règles métiers (business rules) sur les entités de données.

Quelles informations faire figurer dans le data dictionary ?

Le contenu du data dictionary découle des explications données au point précédent :

Pour chaque domaine métier, le context diagram et le modèle conceptuel de données.

Pour chaque classe du modèle entités- relations (qui formalise le modèle conceptuel de données), l’ensemble des attributs.

Pour chaque classe et chaque attribut, un nom et une définition claire (donc non ambigüe et éventuellement multilingue).

L’ensemble des relations entre les classes.

Pour chaque relation un nom et une définition claire (non ambigüe et éventuellement multilingue).

Pour chaque classe la liste des moyens d’alimentation, de mise à jour et de consultation.

Ceci suppose de recenser :

• l’ensemble des data flows (qui devraient avoir été recensés lors de l’établissement du diagramme de contexte) – de type batch (flat files ?) ou remote  (web services ?);
• l’ensemble des écrans (inventaire élaboré au fur et à mesure des itérations sur le projet) – on parlera de services de présentation dans le cadre d’une architecture SOA.

Autres informations possibles :

• les limitations de droit d’accès sur les données sensibles. Mais ceci demande d’avoir identifié les rôles métier dans l’organisation. Remarque : ceci montre encore une fois que l’approche par les données permet la découverte organisée de toute une série d’informations de première importance pour l’analyse fonctionnelle.
• les tags XML utilisés dans les échanges au format XML si d’application.

Quels moyens pour la mise en place du data dictionary ?

L’établissement des diagrammes de contexte et des diagrammes de classes sera réalisé avec un outil de dessin de type Visio ou, plus élaboré, Enterprise Architect, Visual Paradigm ou autre.

Les définitions sur les classes / attributs et le recensement des moyens d’accès sera réalisé dans un document Word par domaine métier ou dans un fichier Excel, les deux pouvant être complémentaires.

Les documents seront publiés dans un repository de type CMS. SharePoint par exemple.

Une mindmap comme point d’entrée peut être utile pour faciliter la navigation entre les domaines métiers et les entités.

– un facteur clé de succès (pour éviter les incompréhensions et les ambiguïtés) ;

– un gage de productivité (pour éviter que chacun ne doive se livrer aux mêmes recherches sur le sens des différents concepts intervenant dans le projet) ;

– un gage de qualité en uniformisant toute une série de conventions et contraintes à respecter par tous, ceci en vue d’éviter les interprétations divergentes.

Cette problématique est adressée en construisant un glossaire projet.

Un data dictionary n’est rien d’autre qu’un subset de ce glossaire, dont le scope est centré sur les données, matière première des applications à construire.

Un data dictionary est un repository qui contient des données sur les données (soit des méta données).

Les données traditionnellement stockées dans un data dictionary sont, sans être exhaustif :

• les noms des entités de données et les tables correspondantes de la ou des bases de données ;
• les attributs des entités et les colonnes correspondantes dans les tables ;
• les relations entre entités ;
• les dupliquas éventuels (auquel cas il convient de préciser la source maître) ;
• la signification métier des données, éventuellement dans plusieurs langues ;
• les domaines de valeurs si des contraintes existent de ce point de vue ;
• les autres contraintes (telles que les contrôles croisés entre données);
• les libellés à utiliser dans les écrans ;
• les dispositifs d’alimentation et de consultation ;
• les schémas XSD éventuels;
• …

Il est facile de comprendre que la présence d’un data dictionary aura un effet significatif immédiat sur les équipes de développement. Ainsi, par exemple, les développeurs sauront où aller chercher les données et quels intitulés leur donner dans les écrans. De même, quels contrôles appliquer dans les écrans d’encodage. Le data dictionary peut aller jusqu’à inclure les traductions des libellés dans les différentes langues utilisées par l’organisation.

Faut-il insister sur les heures perdues par tout un chacun lorsqu’une information vitale pour l’exercice de son activité est absente ou difficile à localiser ? Faut-il mettre en évidence les heures perdues à chercher et rechercher une information sortie de sa mémoire en interpellant / distrayant régulièrement des collègues (avec les effets collatéraux sur la productivité de ceux-ci) ou en « fouinant » dans une documentation de qualité médiocre ?

Faut-il aussi insister sur les effets absolument pervers de documentations personnelles construites par les uns et les autres sur de l’information en fait utile à tous ? Elles sont le plus souvent parcellaires, dispersées et soumises à interprétation personnelle, avec bien entendu des risques de désynchronisation par rapport à la dernière vérité et toutes les conséquences qui peuvent en découler en termes de divergence dans les implémentations des différentes parties d’un même projet.

Beaucoup d’efforts dans le cadre du master data management pourraient sans doute être épargnés si une attention plus grande était portée à l’effort transversal de documentation sur les données.

Les approches Agile, qui mettent exagérément l’accent sur la réduction du « time to market » au détriment de la qualité et de la documentation ne contribuent malheureusement pas à aller dans ce sens. Avec inévitablement des conséquences sur ce que j’appellerai “la dette fonctionnelle sur les données” et les efforts qui devront être fournis pour la corriger. Mieux vaut prévenir que guérir.

Dans le cadre des dispositifs B2B destinés à supporter les échanges entre partenaires, la présence d’un data dictionary est un facteur de succès déterminant. Comment en effet faire adhérer l’ensemble des partenaires à un format canonique sur le bus d’échange si celui-ci n’est pas clairement défini dans un data dictionary. Le glossaire de données (c’est le nom que nous lui avons donné) mis en place pour la Sécurité Sociale belge est là pour en témoigner. Vu le nombre d’intervenants impliqués, ce dispositif s’est avéré indispensable pendant la phase de développement et tout autant aujourd’hui dans les opérations de maintenance trimestrielle.

Bien entendu les efforts liés au data dictionary se doivent d’être « raisonnables », pour garantir le retour sur investissement d’un strict point de vue budgétaire. Comme pour toute initiative transversale, tout ce qui est fait doit être directement utile aux projets. Cela suppose une attention permanente à la maîtrise de sa complexité pour en garantir la facilité d’utilisation et de maintenance, sans quoi il sera vite abandonné par ceux que l’on veut servir.

J’espère vous avoir convaincu que le data dictionary, et au delà le glossaire d’enterprise, sont des initiatives transversales amplement justifiées. Elles ont un coût, certes, mais leur retour sur investissement est prouvé.

Dans un prochain blog nous nous intéresserons à la manière de construire un data dictionary.