Un diagramme entité-relation communique la structure et la cardinalité des données. Il aide à concevoir et à intégrer une équipe, mais ne remplace pas les migrations exécutables. Considérez-le comme une explication ; la définition de la base reste la source de vérité.
Modéliser entités et attributs
erDiagram
CUSTOMER ||--o{ ORDER : places
ORDER ||--|{ ORDER_ITEM : contains
PRODUCT ||--o{ ORDER_ITEM : appears_in
CUSTOMER { uuid id PK string email UK }
ORDER { uuid id PK uuid customer_id FK string status }
ORDER_ITEM { uuid order_id FK uuid product_id FK int quantity }
PRODUCT { uuid id PK string name decimal price }Les types d’attribut sont descriptifs. Utilisez le vocabulaire de l’équipe sans supposer que le diagramme impose précision, index, valeur par défaut ou contrainte particulière.
Lire la cardinalité aux deux extrémités
CUSTOMER ||--o{ ORDER signifie qu’une commande appartient à un seul client et qu’un client peut avoir zéro ou plusieurs commandes. Lire les deux côtés révèle l’optionalité. Les libellés décrivent la relation ; ils ne sont pas des noms de clés étrangères.
Montrer la bonne quantité de schéma
Les colonnes d’audit, index techniques et champs d’intégration surchargent une vue d’ensemble. Montrez les clés et attributs nécessaires, puis liez les migrations ou le schéma complet pour les détails.
Vérifier les hypothèses dans la base
L’optionalité, l’unicité et la direction doivent correspondre aux contraintes réelles. « Exactement un » est trompeur si la clé étrangère accepte NULL. Signalez les relations incertaines dans le texte plutôt que d’en faire des règles.
Utilisez le modèle ER de l’éditeur Mermaid pour valider la syntaxe et exporter un SVG évolutif.