Comment construire un data dictionary ?

Rappel : pourquoi un data dictionnary ?

La raison d’être d’un data dictionnary 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 dictionnary est indissociable de la mise en place d’un glossaire propre au projet. Le data dictionnary 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 dictionnary ?

La construction d’un data dictionnary 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 dictionnary 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 dictionnary 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 dictionnary ?

Le contenu du data dictionnary 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 dictionnary ?

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.