🗄️ Mermaid

Diagramme entité-association

Concevez des schémas de base de données cohérents

Ouvrir cet exemple dans l’éditeur En générer un avec l’IA

Qu’est-ce qu’un Diagramme entité-association ?

Un diagramme ER montre les entités d’une base de données, leurs attributs et la cardinalité de leurs relations (un-à-plusieurs, plusieurs-à-plusieurs). C’est le plan de toute base relationnelle.

Le diagramme entité-association a sa place dans la pull request qui ajoute une migration, et dans la première heure d’onboarding : le moyen le plus rapide d’expliquer un produit, c’est souvent son modèle de données. Il rend la cardinalité explicite — une seule adresse par client ou plusieurs, c’est une règle métier, pas un détail. Ce qu’il ne porte pas, c’est la conception physique : ni index, ni partitionnement, ni schémas d’accès. Le fichier de migration reste la source de vérité.

Exemple en direct

Code Mermaid

erDiagram
    CUSTOMER ||--o{ ORDER : places
    ORDER ||--|{ ORDER_LINE : contains
    PRODUCT ||--o{ ORDER_LINE : "ordered in"
    CUSTOMER {
      string id PK
      string email UK
    }
    ORDER {
      string id PK
      date created_at
    }

Exemple en direct

Quand l’utiliser

Concevoir un nouveau schéma avant la première migration

Documenter un schéma existant pour les nouveaux arrivants

Discuter les modèles de données avec des interlocuteurs non techniques

Erreurs fréquentes

Cardinalité lue du mauvais côté

Dans CUSTOMER ||--o{ ORDER : places, le || placé côté CUSTOMER signifie un client par commande, et le o{ placé côté ORDER signifie zéro ou plusieurs commandes par client. Chaque marqueur compte sa propre entité, vue depuis l’autre bout.

Une relation sans libellé

CUSTOMER ||--o{ ORDER employé seul est une erreur d’analyse : Mermaid attend un deux-points. Écrivez : places, ou : "" quand la relation va de soi. C’est de loin l’échec le plus fréquent en erDiagram.

Un nom d’entité avec des espaces

ORDER LINE ||--o{ PRODUCT ne crée pas d’entité nommée ORDER LINE : le nom est coupé à l’espace. Mettez-le entre guillemets, "ORDER LINE", ou adoptez la convention avec tiret bas que suit déjà le reste du schéma.

Syntaxe de base

.mmd

erDiagram
    USER ||--o{ POST : writes
    USER {
      string id PK
      string email
    }

CUSTOMER ||--o{ ORDER : places
Toute relation attend un libellé après les deux-points ; écrivez : "" quand il n’y a rien d’utile à dire. Mettez entre guillemets les libellés contenant des espaces, comme : "commandé le".
ORDER { string id PK decimal total "in cents" }
Un attribut s’écrit type puis nom, suivis d’éventuels marqueurs de clé (PK, FK, UK, séparés par des virgules) et d’un commentaire entre guillemets. Les types sont du texte libre et rien n’est validé.
ORDER ||--|{ LINE : contains CUSTOMER }o..o{ PROMO : uses
Un trait plein marque une relation identifiante : l’enfant ne peut pas exister seul. Les pointillés marquent une relation non identifiante, où la clé étrangère est facultative.
erDiagram direction LR
Le sens par défaut va de haut en bas. direction LR étale un schéma large à l’horizontale, ce qui tient généralement mieux dans une page de documentation qu’une longue colonne d’entités.

Questions sur ce diagramme

Comment lire les symboles de cardinalité comme ||--o{ ?

|| signifie exactement un, o| zéro ou un, }| un ou plusieurs, }o zéro ou plusieurs. CUSTOMER ||--o{ ORDER se lit donc « un client passe zéro ou plusieurs commandes ».

Puis-je générer un diagramme ER depuis du SQL ?

Oui — collez vos instructions CREATE TABLE ou décrivez vos données : l’IA produit le diagramme ER correspondant avec clés et relations.

Puis-je versionner un diagramme ER avec mes migrations ?

Oui, et c’est la raison principale de l’écrire en texte. Le diagramme vit à côté de la migration, se compare ligne à ligne en revue, et un changement de schéma que personne n’y a reporté apparaît comme une modification manquante.

Un diagramme ER Mermaid peut-il montrer les index et les contraintes ?

Non. Il montre les entités, les types d’attributs et les marqueurs PK, FK ou UK, rien de plus : ni index, ni valeurs par défaut, ni contraintes de vérification, ni triggers. C’est une carte du schéma, pas une spécification dont on générerait une base.

Comment modéliser une relation plusieurs-à-plusieurs ?

Soit directement avec }o--o{, soit en modélisant l’entité de jonction : STUDENT ||--o{ ENROLMENT et COURSE ||--o{ ENROLMENT. Prenez la seconde forme dès que la jonction porte ses propres colonnes, comme une date d’inscription.

Quelle différence entre PK, FK et UK ?

PK marque la clé primaire, FK une clé étrangère qui pointe vers une autre entité, et UK une contrainte d’unicité. Mermaid les affiche comme de simples libellés : il ne vérifie jamais qu’une FK correspond à une clé primaire ailleurs dans le diagramme.

Diagramme entité-association ou un autre type de diagramme ?

Diagramme entité-association ou diagramme de classes ?

Choisissez selon ce que le lecteur s’apprête à faire. S’il écrit du SQL ou une migration, donnez-lui entités, clés et cardinalités. S’il écrit du code applicatif, un diagramme de classes avec méthodes et héritage est plus proche de ce qu’il va réellement taper.

Diagramme entité-association ou flowchart ?

Le diagramme entité-association répond à « qu’est-ce qui est stocké et comment est-ce relié » ; le flowchart répond à « que se passe-t-il et dans quel ordre ». Des boîtes qui sont des noms avec des attributs relèvent du premier ; des boîtes qui sont des verbes, du second.

Explorer les autres types de diagrammes

🔀 Flowchart (logigramme)💬 Diagramme de séquence 🧩 Diagramme de classes 🔄 Diagramme d’états 📅 Diagramme de Gantt 🥧 Diagramme circulaire 🧠 Carte mentale 🌿 Graphe Git 🕰️ Frise chronologique 🚶 Parcours utilisateur 🎯 Matrice à quadrants

Créez votre Diagramme entité-association maintenant

Décrivez-le en langage naturel — l’IA écrit le code Mermaid pour vous.

Ouvrir Mermaid Studio