Éditeur de diagramme entité-association Mermaid
Un diagramme entité-association montre les tables, leurs colonnes et la façon dont elles se joignent. Il convient quand le sujet est un schéma de base de données et que les questions intéressantes portent sur les clés et les cardinalités — un à plusieurs, facultatif, ou via une table de jonction. Pour des types avec comportement et héritage, prenez plutôt un diagramme de classes.
Un schéma de commandes normalisé avec table de jonction
La partie qui mérite l'attention est le `}o--||` de LIGNE_COMMANDE : c'est ainsi qu'on exprime honnêtement une relation plusieurs-à-plusieurs, par une table de jonction dotée de ses propres colonnes, au lieu de faire croire que deux tables se relient directement. Stocker le prix unitaire sur la ligne et pas seulement sur l'article est la décision que le diagramme doit rendre visible.
erDiagram
CLIENT ||--o{ COMMANDE : "passe"
COMMANDE ||--|{ LIGNE_COMMANDE : "contient"
ARTICLE ||--o{ LIGNE_COMMANDE : "figure dans"
CLIENT ||--o{ ADRESSE : "se fait livrer à"
CLIENT {
int id PK
string courriel UK "stocké en minuscules"
string nom
datetime cree_le
}
COMMANDE {
int id PK
int client_id FK
string etat
decimal montant_total
}
LIGNE_COMMANDE {
int commande_id PK, FK
int article_id PK, FK
int quantite
decimal prix_unitaire "prix au moment de la commande"
}
ARTICLE {
int id PK
string reference UK
string libelle
}
ADRESSE {
int id PK
int client_id FK
string code_postal
}Exemples commentés
1. Deux entités et une association
Toute association ER exige un libellé après les deux-points : il n'est pas facultatif, contrairement à une arête d'organigramme. Cela se lit comme une phrase : CLIENT passe COMMANDE.
erDiagram
CLIENT ||--o{ COMMANDE : "passe"2. Ajouter des colonnes
Chaque ligne d'attribut s'écrit `type nom`, et les deux parties sont obligatoires. `PK`, `FK` et `UK` marquent les clés ; une chaîne entre guillemets à la fin est un commentaire.
erDiagram
CLIENT ||--o{ COMMANDE : "passe"
CLIENT {
int id PK
string courriel UK
string nom
}
COMMANDE {
int id PK
int client_id FK
datetime passee_le "en UTC"
}3. Une cardinalité qui dit quelque chose
Les deux caractères les plus proches de chaque entité sont sa cardinalité. Cet exemple dit qu'une commande doit avoir au moins une ligne, mais qu'un client peut n'avoir aucune commande : une contrainte réelle, que le schéma devrait imposer et que le diagramme devrait montrer.
erDiagram
CLIENT ||--o{ COMMANDE : "passe"
COMMANDE ||--|{ LIGNE_COMMANDE : "contient"
LIGNE_COMMANDE }o--|| ARTICLE : "référence"4. Plusieurs-à-plusieurs par table de jonction
Mermaid sait dessiner un plusieurs-à-plusieurs direct, mais un schéma n'en comporte quasiment jamais : il y a une table de jonction en dessous. La dessiner est plus honnête et vous donne un endroit où poser les colonnes qui appartiennent à la relation elle-même.
erDiagram
ETUDIANT ||--o{ INSCRIPTION : "s'inscrit à"
COURS ||--o{ INSCRIPTION : "se suit via"
INSCRIPTION {
int etudiant_id PK, FK
int cours_id PK, FK
datetime inscrit_le
string note "nulle jusqu'à la correction"
}
ETUDIANT {
int id PK
string nom
}
COURS {
int id PK
string code UK
}5. Associations réflexives
Une table peut s'associer à elle-même : une ligne hiérarchique, un arbre de catégories, un fil de commentaires. Le libellé de l'association compte ici plus que d'habitude, puisque les deux extrémités sont la même entité.
erDiagram
EMPLOYE ||--o{ EMPLOYE : "encadre"
EMPLOYE {
int id PK
int responsable_id FK "nul pour la direction"
string nom
string intitule_de_poste
}Référence de syntaxe du diagramme ER
La cardinalité s'écrit avec deux caractères à chaque extrémité de l'association et se lit du centre vers l'extérieur. La paire de gauche décrit l'entité de gauche ; celle de droite décrit l'entité de droite.
| Syntaxe | Signification |
|---|---|
| erDiagram | Ouvre le diagramme. Sensible à la casse : `erdiagram` ne marche pas. |
| A ||--o{ B : "libellé" | Association. Le libellé est obligatoire. |
| || | Exactement un. |
| o| | Zéro ou un. |
| }| | Un ou plusieurs. |
| }o | Zéro ou plusieurs. |
| -- | Association identifiante — trait plein. |
| .. | Association non identifiante — trait pointillé. |
| A { ... } | Bloc d'attributs de l'entité A. |
| int id PK | Attribut : type, puis nom, puis marque de clé facultative. |
| PK / FK / UK | Clé primaire, étrangère, unique. |
| int id PK, FK | Plusieurs marques de clé, séparées par une virgule. |
| string courriel "commentaire" | La chaîne entre guillemets en fin de ligne commente la colonne. |
| A ||--o{ B : "appartient à" | Les guillemets sont OBLIGATOIRES dès que le libellé contient une espace. Sans eux, il est coupé à la première espace et chaque mot restant devient une entité fantôme. |
Six erreurs qui cassent un diagramme ER
L'ER a la grammaire la plus stricte des six types : ce qui passe ailleurs y est refusé net. Mais c'est aussi lui qui abrite l'erreur silencieuse la plus coûteuse pour qui écrit en français. Tout est reproduit avec Mermaid 11.12.2.
Ce que vous voyez
Le diagramme se dessine, le libellé est coupé et des entités inconnues apparaissent
Pourquoi
Un libellé d'association contenant une espace et dépourvu de guillemets. C'est l'erreur qui vous gênera le plus en français, parce que presque tous nos verbes relationnels appellent une préposition : « appartient à », « figure dans », « se fait livrer à ». Mesuré : `CLIENT ||--o{ COMMANDE : appartient à` ne produit aucune erreur, réduit le libellé à « appartient » et crée une entité fantôme nommée « à ». Avec trois mots, cela fait deux entités fantômes. Deux tables se dessinent en quatre boîtes et rien ne vous prévient.
Correction
Mettez entre guillemets tout libellé contenant une espace. En français cela revient à les mettre presque toujours ; il est plus simple d'en faire une règle que de trancher au cas par cas.
erDiagram
CLIENT ||--o{ COMMANDE : appartient àerDiagram
CLIENT ||--o{ COMMANDE : "appartient à"Ce que vous voyez
Parse error, se terminant par : Expecting 'COLON', 'STYLE_SEPARATOR', got 'NEWLINE'
Pourquoi
Une association sans libellé. Contrairement à une arête d'organigramme, les deux-points et le libellé sont obligatoires : sans eux, la ligne se termine simplement trop tôt.
Correction
Ajoutez les deux-points et un groupe verbal, entre guillemets s'il contient une espace.
erDiagram
CLIENT ||--o{ COMMANDEerDiagram
CLIENT ||--o{ COMMANDE : "passe"Ce que vous voyez
Parse error, se terminant par : got 'UNICODE_TEXT'
Pourquoi
Un jeton de cardinalité invalide. Seuls `||`, `o|`, `}|` et `}o` (et leurs miroirs) sont valides ; tout le reste échoue. `oo` est la faute habituelle, née de l'attente que la notation soit symétrique.
Correction
Utilisez l'une des quatre paires. `||--o{` — exactement un vers zéro ou plusieurs — couvre la plupart des clés étrangères.
erDiagram
CLIENT ||--oo{ COMMANDE : "passe"erDiagram
CLIENT ||--o{ COMMANDE : "passe"Ce que vous voyez
Parse error, se terminant par : Expecting 'ATTRIBUTE_WORD', got 'BLOCK_STOP'
Pourquoi
Un attribut avec un nom mais sans type. Les attributs ER s'écrivent `type nom`, et le type n'est pas facultatif — ce qui surprend les gens venus des bases sans schéma.
Correction
Donnez un type à chaque attribut. Inventez-le si le schéma réel n'en a pas : `string`, `int`, `json`.
erDiagram
CLIENT {
courriel
}erDiagram
CLIENT {
string courriel
}Ce que vous voyez
Parse error, se terminant par : Expecting 'NON_IDENTIFYING', 'IDENTIFYING', got 'UNICODE_TEXT'
Pourquoi
Le trait entre les deux marques de cardinalité est faux. Il doit faire exactement deux caractères : `--` pour une association identifiante ou `..` pour une non identifiante. Un tiret seul n'est pas une version courte de `--`, c'est une erreur de syntaxe.
Correction
Utilisez `--` ou `..` entre les paires de cardinalité.
erDiagram
CLIENT ||-o{ COMMANDE : "passe"erDiagram
CLIENT ||--o{ COMMANDE : "passe"Ce que vous voyez
La cardinalité se dessine mais décrit la contrainte inverse
Pourquoi
Les deux caractères les plus proches de chaque entité appartiennent à cette entité, et il est très facile de les lire à l'envers. `CLIENT ||--o{ COMMANDE` dit qu'un client a zéro ou plusieurs commandes. Retournez-le en `CLIENT }o--|| COMMANDE` et vous avez affirmé que tout client appartient à exactement une commande, ce qui n'a aucun sens — et se dessine sans broncher.
Correction
Lisez du centre vers l'extérieur : les marques qui touchent CLIENT décrivent combien de clients, pas combien de commandes.
erDiagram
CLIENT }o--|| COMMANDE : "passe"erDiagram
CLIENT ||--o{ COMMANDE : "passe"Notes sur le rendu
Mesuré sur le Mermaid 11.12.2 qu'utilise ce site.
Le placement est dicté par les associations, pas par le nombre d'entités
Une chaîne d'entités reliées l'une à l'autre se dessine en colonne haute : quarante entités donnent un viewBox d'environ 116×7315, contre 116×470 pour trois. Mais ces mêmes quarante entités reliées à une unique table centrale produisent quelque chose de bien plus large et bas. C'est le seul type de diagramme ici où la forme de vos données change la forme de l'image plus que sa taille : un schéma qui ne tient pas se corrige plus souvent en changeant quelles associations vous dessinez qu'en réduisant leur nombre.
En français, presque tous les libellés réclament des guillemets
Cela mérite d'être répété, parce que c'est l'erreur silencieuse la plus coûteuse de cette page. En anglais les libellés d'association tiennent souvent en un mot — places, contains, references — et les guillemets passent, dans la documentation anglaise, pour une coquetterie. En français la plupart sont des groupes verbaux à préposition, qui se brisent sans guillemets. La règle pratique : mettez toujours le libellé entre guillemets et vous n'aurez plus à y penser.
Les noms d'entités sont sensibles à la casse et s'écrivent par convention en capitales
`CLIENT` et `client` sont deux entités distinctes, et mentionner les deux dans le même diagramme donne deux boîtes sans avertissement. La convention des capitales n'est pas imposée par Mermaid, mais elle mérite d'être tenue précisément parce qu'elle rend visible une référence en minuscules écrite par inadvertance. Les accents fonctionnent sans problème dans les noms d'entités et de colonnes ; en revanche, décidez dès le départ si le schéma porte des accents ou non, et ne mélangez pas.
La grammaire est la plus stricte des six types
Les libellés d'association sont obligatoires, les types d'attributs aussi, et les jetons de cardinalité forment un ensemble fermé. Comparé au Gantt, où presque tout se dessine et où les erreurs sont muettes, l'ER échoue tôt et bruyamment. C'est une qualité : si un diagramme ER se dessine, il y a de fortes chances que ce soit celui que vous vouliez — à l'exception notable des libellés sans guillemets.
Les étiquettes sont du HTML, donc l'export PNG redessine
Les tableaux d'attributs des entités sont dessinés dans un `<foreignObject>` du SVG : les navigateurs ne peuvent donc pas les rasteriser directement sur un canvas. L'export PNG de ce site rendait auparavant un fichier SVG sans rien dire ; il redessine désormais d'abord avec des étiquettes en texte SVG simple et produit un PNG correct et à taille réelle, à la typographie à peine différente.
Quand un autre diagramme convient mieux
S'il vous faut de l'héritage, des interfaces ou des méthodes, ce diagramme est le mauvais : l'ER n'a aucun de ces concepts. Prenez un diagramme de classes, en acceptant qu'il modélise votre code et non vos tables.
Si le schéma est vaste, un ER de la totalité est une fresque murale que personne ne lit. Dessinez les cinq tables concernées par ce que vous expliquez et laissez le reste de côté ; un diagramme est un argument, pas un inventaire.
Et si la vraie question est comment les données circulent entre les systèmes plutôt que comment elles sont stockées, un organigramme avec un sous-graphe par système y répondra, et un ER non.
Autres types de diagrammes
Écrit par Dominik Malsch · Dernière mise à jour: