Diagrammes entité-association

Un diagramme entité-association décrit les choses qu'un système stocke et les liens entre elles. Trois ingrédients, pas davantage :

La valeur tient presque entièrement dans le troisième. Tout le monde sait énumérer les entités de son domaine ; la discussion commence à « une commande peut-elle exister sans client ? », et un diagramme entité-association force cette question à être répondue par un symbole plutôt que laissée confortablement vague dans un document.

Les attributs sont faciles. C'est avec les clés qu'un modèle entité-association gagne sa place, car une clé est une affirmation sur l'identité - et c'est dans l'identité que se cachent les malentendus métier.

Chaque extrémité d'une relation porte deux symboles : celui de l'extérieur dit combien et celui de l'intérieur dit si c'est optionnel. Une barre vaut un, un pied-de-corbeau vaut plusieurs, un cercle vaut zéro.

Ce dernier point attrape presque tout le monde et a son propre article - la notation pied-de-corbeau - sur quelle extrémité est laquelle, les relations identifiantes ou non, et la résolution d'un plusieurs-à-plusieurs.

La plupart des diagrammes entité-association confus sont deux niveaux sous un même manteau. Décider lequel vous tracez règle une douzaine de petites disputes avant qu'elles ne commencent.

Vous n'avez pas toujours besoin des trois. Un petit service peut aller droit au logique. Ce qui ne marche jamais, c'est de montrer un diagramme conceptuel à un développeur qui a besoin du physique, ou un physique à un décideur métier qui voulait vérifier si un client peut avoir deux adresses.

Ils se ressemblent et disent des choses différentes. Un diagramme de classes décrit des types dans un programme : comportement, héritage, visibilité, navigabilité. Un diagramme entité-association décrit les données au repos : clés, cardinalité, intégrité référentielle. Le recouvrement est réel, la divergence aussi.

1. Des noms d'entités au pluriel. Customer est l'entité ; customers est la table. Les mélanger rend les phrases de relation illisibles.
2. Un plusieurs-à-plusieurs non résolu dans un modèle logique. Aucune base ne sait le stocker. Résolvez-le et nommez l'entité de jonction d'après ce qu'elle signifie - Enrolment, pas StudentCourse.
3. Toutes les relations optionnelles. Un modèle où rien n'est obligatoire n'encode aucune règle, et les contraintes finissent éparpillées dans le code applicatif.
4. Des attributs qui sont en fait des entités. Si « adresse » a besoin de cinq sous-champs et peut apparaître deux fois, c'est une entité.
5. Modéliser les tables de reporting. Un modèle de lecture dénormalisé appartient au modèle physique avec une note expliquant pourquoi, pas au logique où on le prendra pour le domaine.