Diagramme entités-relations

Objectif

Le diagramme entités-relations donne une image neutre, indépendante de toute technologie, de l'information dont une organisation a besoin et de la manière dont elle se tient ensemble: les choses dont le métier garde trace (les entités), ce que l'on retient sur chacune (les attributs) et les règles qui les relient (les relations et leurs cardinalités). Il répond à une question que la prose d'un cahier des charges laisse floue: de quelles entités parle-t-on, laquelle dépend de laquelle et combien d'occurrences de l'une se rattachent à une occurrence de l'autre.

Sa valeur se joue à deux moments. Au niveau conceptuel, c'est un artefact d'élicitation et de communication: un vocabulaire commun entre les experts du domaine, qui confirment ou infirment les entités et les relations, et ceux qui construiront la solution. Aux niveaux logique et physique, le même modèle devient le point de départ d'un schéma relationnel, la structure des données persistantes que la base implémentera. Le livrable est le diagramme accompagné des définitions qui le documentent, celles des entités et des attributs, tenues le plus souvent dans un dictionnaire de données.

Usage

Quand l'utiliser

• Données structurées et persistantes au cœur du changement: enregistrements, transactions ou données de référence à cadrer.
• Vocabulaire de données manquant ou disputé: fixer les entités et leurs relations pour que tout le monde parle des mêmes choses.
• Conception d'une base de données relationnelle: poser le schéma persistant en amont, l'ERD logique et physique le porte jusqu'à la base.
• Migration ou intégration de données: reconstruire la structure réelle d'un système existant avant toute décision de reprise.
• Règle métier de dénombrement: la cardinalité rend explicite et discutable le combien de X par Y.

Quand ne pas l'utiliser

• Le sujet est un comportement ou un flux, non des données: modéliser la suite des activités, prendre un modèle de processus comme BPMN ou un cas d'utilisation.
• Le modèle d'objets doit porter des opérations (un comportement attaché aux données): prendre le diagramme de classes UML, qui seul les exprime.
• Le public strictement métier a besoin de sens, non de structure: fixer le vocabulaire avec un modèle de concepts, que ce public lit, là où l'ERD lui impose une structure informatique.

Description

Les éléments du dessin

Un ERD se lit à partir d'un petit nombre de formes, et un business analyste en rencontre plus souvent qu'il n'en construit. Savoir le lire suffit à valider un modèle qu'on lui présente.

• L'entité, un rectangle nommé d'un substantif au singulier tiré du métier (Patient, Ordonnance, Facture): quelque chose de physique, d'organisationnel, d'abstrait ou un événement, dont l'organisation garde trace.
• L'attribut, une propriété retenue sur l'entité, listée sous son nom: le nom du patient, la date d'une séance, le montant d'une facture.
• L'identifiant unique, le ou les attributs qui distinguent chaque occurrence des autres. Dans les termes du modèle relationnel, c'est la clé primaire; il figure en tête des attributs de l'entité.
• La relation, une ligne nommée entre deux entités, qui se lit comme une locution verbale dans les deux sens: un patient reçoit des séances, une séance concerne un patient.
• La cardinalité, portée par le symbole à chaque bout de la ligne. C'est l'élément qui porte le sens et celui qu'un lecteur pressé néglige à tort.

Lire la cardinalité en pattes-de-corbeau

La notation en pattes-de-corbeau code la cardinalité par un symbole en deux parties à chaque extrémité de la relation. La marque au contact de l'entité donne le maximum: une barre pour un, la patte-de-corbeau, cette fourche à trois branches dont les pointes s'ouvrent contre la case de l'entité, pour plusieurs. La marque posée en retrait sur le trait donne le minimum: un cercle pour zéro (relation facultative), une barre pour un (relation obligatoire). En parcourant le trait vers l'entité, on lit donc le minimum puis le maximum, et les quatre combinaisons se lisent ainsi: cercle puis fourche pour zéro-ou-plusieurs, barre puis fourche pour un-ou-plusieurs, deux barres pour exactement-un, cercle puis barre pour zéro-ou-un.

Une relation se lit dans les deux sens, et chaque sens se lit sur le symbole du bout opposé. Pour savoir combien de séances se rattachent à un patient, on lit le symbole côté séance; pour savoir combien de patients se rattachent à une séance, on lit le symbole côté patient. La règle de dénombrement de chaque côté est un fait métier: dire qu'une séance relève d'exactement une ordonnance et qu'une ordonnance en autorise une à plusieurs, c'est énoncer deux règles que le métier doit confirmer, chacune de son côté.

Ce que le dessin ne montre pas

Le premier piège tient à la cardinalité elle-même. Poser une borne sans la valider dans les deux sens produit un modèle qui a l'air complet et ment: un maximum « plusieurs » mis par défaut là où le métier n'admet qu'un seul cas fige une règle que personne n'a confirmée. Le second est le mélange des niveaux: faire entrer dans un modèle de données conceptuel des clés étrangères, des types de colonnes ou des index le rend illisible au métier, exactement la limite que le BABOK signale, et fige une conception physique bien trop tôt. Le troisième est l'attribut rangé dans la mauvaise entité ou l'entité sans identifiant propre, d'où sortent les incohérences classiques d'un modèle. Le quatrième est la relation plusieurs-à-plusieurs laissée telle quelle: elle cache presque toujours une entité intermédiaire, dite associative, qui porte ses propres attributs et que personne n'a nommée. Le dernier est la dérive de nommage, entités au pluriel, entités qui sont en réalité des processus, relations sans nom; les noms d'un ERD viennent du vocabulaire du métier.

Un dernier point relève du vocabulaire de lecture plus que de la construction: on croise parfois des structures de sous-type et de sur-type ou des entités faibles. Un lecteur les reconnaît sans avoir à en maîtriser la construction pour valider un modèle.

La notation n'est pas universelle

Le même modèle se dessine dans plusieurs notations, et les confondre est un piège en soi. La notation de Chen, celle de l'article fondateur, dessine les relations par des losanges. La notation en pattes-de-corbeau, due à Everest puis popularisée par la méthode de Barker et les ateliers Oracle, est celle que retient la figure du BABOK et celle que l'on trace effectivement au tableau. Le diagramme de classes UML, enfin, porte la même information sous une troisième forme, et son vocabulaire change: là où l'ERD parle de relation et de cardinalité, la classe parle d'association et de multiplicité, pour la même idée de bornes minimale et maximale. La règle pratique tient en une ligne: lire la légende, ne pas mélanger deux notations sur un même dessin.

Cette dernière confusion en recouvre une plus profonde, celle de l'ERD et du diagramme de classes UML. L'ERD modélise des données: des entités, leurs attributs, leurs relations. Le diagramme de classes ajoute le comportement, les opérations qu'une classe exécute, l'émission d'une facture, l'ouverture d'un compte. Un domaine où ce que l'on fait des données compte autant que leur structure relève du diagramme de classes; un schéma de base de données relève de l'ERD. Le business analyste travaille le plus souvent au niveau conceptuel, parfois logique, et laisse le niveau physique à l'administrateur de base de données.

Considérations IA

Un modèle de langue rend plusieurs services concrets sur cette technique. Il ébauche un premier ERD à partir d'un dictionnaire de données ou d'un texte d'exigences, propose des entités et des attributs manquants, engendre le langage de définition de données (DDL) d'un modèle de données conceptuel et, à l'inverse, rétro-conçoit un ERD depuis le schéma d'une base existante. Il traduit aussi d'une notation à l'autre, de Chen vers les pattes-de-corbeau ou vers UML. Sur un système hérité sans documentation, le gain de temps est réel et le brouillon obtenu se corrige plus vite qu'une page blanche ne se remplit.

La limite est nette et elle est de nature métier: les cardinalités ne se devinent pas. Une machine qui lit un schéma déduit ce que la base contient, y compris les erreurs de structure qu'elle a accumulées, mais elle ne peut pas confirmer qu'une ordonnance couvre bien un seul patient, parce que la réponse tient à la manière dont le cabinet fonctionne. Le minimum et le maximum de chaque côté d'une relation sont des faits que seuls les experts du domaine valident. Restent aussi hors de portée de l'automatisation les décisions de périmètre, ce que le modèle retient et ce qu'il laisse dehors, et la classification de sensibilité des données: un ERD de cabinet médical porte un numéro AVS et des données de santé, dont le traitement engage la protection des données bien au-delà de ce qu'un modèle sait juger seul.

Exemples

Le dessin se lit le mieux sur un cas. Le concept qu'il rend visible est la lecture d'une relation dans les deux sens: un même trait porte deux règles de dénombrement, une par extrémité, et chacune se lit sur le symbole du bout opposé. Le domaine retenu est un cabinet de physiothérapie de Suisse romande, avec quatre entités, le patient, l'ordonnance, la séance et le physiothérapeute.

La relation entre l'ordonnance et la séance porte les deux règles à lire. Côté séance, le symbole est une patte-de-corbeau précédée d'une barre: une ordonnance autorise une à plusieurs séances, jamais zéro, ce qui dit qu'une ordonnance sans séance n'a pas lieu d'être enregistrée. Côté ordonnance, le symbole est une double barre: chaque séance relève d'exactement une ordonnance, ni zéro ni deux. Les deux autres relations se lisent de même. Un patient reçoit zéro à plusieurs séances et chaque séance concerne exactement un patient; un physiothérapeute réalise zéro à plusieurs séances et chaque séance est réalisée par exactement un physiothérapeute. La séance est le point où trois relations se rejoignent, et chacune de ses extrémités « exactement-un » dit que la séance ne peut exister sans son patient, son ordonnance et son physiothérapeute.

Visualisations

La forme porte le sens, ce qui permet de valider un modèle sans le lire ligne à ligne. La silhouette donne le type, un rectangle nommé pour une entité, l'identifiant en tête de ses attributs. Le trait nommé donne la relation, et son symbole à deux marques donne la règle de dénombrement, le maximum au contact de l'entité, la marque de minimum en retrait sur le trait. Un relecteur qui connaît les pattes-de-corbeau parcourt ainsi tout un schéma des yeux et repère une cardinalité douteuse sans ouvrir une seule définition, ce qui fait de la notation un langage partagé.

Coût

Outils

Un tableau blanc ou une feuille suffit à la première ébauche conceptuelle: quelques entités et leurs relations se posent et se corrigent debout, avec le métier. Les outils de schéma généralistes, diagrams.net, Lucidchart ou Visio, portent des gabarits entités-relations et donnent un dessin propre, mais ils s'arrêtent au dessin. Les ateliers de modélisation de données et outils de génie logiciel assisté vont plus loin: Sparx Enterprise Architect, erwin Data Modeler, ER/Studio, MySQL Workbench, l'outil de modélisation d'Oracle SQL Developer ou dbdiagram.io engendrent le schéma de la base à partir du modèle et le rétro-conçoivent depuis une base existante. Le partage des rôles est simple: l'outil de schéma suffit tant que l'ERD sert de support de discussion au niveau conceptuel, l'atelier de modélisation devient nécessaire dès que le modèle doit rester synchronisé avec une base réelle.

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.15 Data Modelling: le diagramme entités-relations comme l'une des deux notations d'un modèle de données, la liste de ses éléments, la cardinalité et sa lecture dans les deux sens, ainsi que les forces et limites énoncées de son emploi.
• Peter Chen, « The Entity-Relationship Model: Toward a Unified View of Data », ACM Transactions on Database Systems, vol. 1, n° 1 (1976), pp. 9-36: l'article fondateur du modèle entités-relations et de ses concepts de base.
• Gordon C. Everest, « Basic Data Structure Models Explained with a Common Example », Proc. Fifth Texas Conference on Computing Systems (1976): l'origine de la notation de cardinalité en pattes-de-corbeau.
• Richard Barker, CASE*Method: Entity Relationship Modelling, Addison-Wesley (1990), ISBN 978-0201416961: la référence de la variante Barker/Oracle des pattes-de-corbeau qu'un business analyste rencontre dans les chaînes d'outils Oracle et de génie logiciel assisté.