Schémas de base de données : le diagramme entité-relation

À retenir — Le diagramme entité-relation (ERD) décrit la structure d'une base de données : les tables (entités), leurs colonnes (attributs) et surtout les relations entre elles, avec leur cardinalité exacte. C'est le plan que tout développeur et tout DBA lisent avant de toucher au schéma.

Le bon outil pour penser ses données

Avant d'écrire la moindre ligne de SQL, on dessine le modèle. L'ERD de Mermaid sert exactement à ça : poser les tables, leurs champs et la façon dont elles se relient. Il se déclare avec erDiagram.

erDiagram
    CLIENT ||--o{ COMMANDE : passe
    COMMANDE ||--|{ LIGNE_COMMANDE : contient
    PRODUIT ||--o{ LIGNE_COMMANDE : figure_dans

Trois entités, deux relations, et déjà tout le squelette d'une boutique. La force de l'ERD tient dans une notation : les pattes de corbeau (crow's foot) aux extrémités, qui encodent précisément la cardinalité.

Lire la notation crow's foot

Chaque extrémité d'une relation se compose de deux symboles : un pour le minimum, un pour le maximum.

On combine deux extrémités pour former une relation complète :

erDiagram
    A ||--|| B : un-à-un
    C ||--o{ D : un-à-plusieurs
    E }o--o{ F : plusieurs-à-plusieurs

• ||--|| : un-à-un (un pays, une capitale).
• ||--o{ : un-à-plusieurs (un client, plusieurs commandes — la plus fréquente).
• }o--o{ : plusieurs-à-plusieurs (des étudiants, des cours).

:::tip[Lire une relation à voix haute] CLIENT ||--o{ COMMANDE se lit : « un CLIENT (le ||) passe zéro ou plusieurs COMMANDES (le o{) ». Lisez toujours du côté || vers le côté o{. Si la phrase a du sens dans les deux sens, votre cardinalité est probablement juste. :::

Décrire les attributs d'une entité

Le vrai intérêt arrive quand on remplit les entités avec leurs colonnes, entre accolades : type, nom, et éventuellement une clé et un commentaire.

erDiagram
    CLIENT {
        int id PK
        string nom
        string email UK
        date inscrit_le
    }
    COMMANDE {
        int id PK
        int client_id FK
        decimal montant
        string statut
    }
    CLIENT ||--o{ COMMANDE : passe

Les annotations de clé sont essentielles :

Le type (int, string, decimal, date, boolean…) précède le nom de la colonne — l'ordre inverse du flowchart, attention.

Commenter une colonne

On peut ajouter un commentaire entre guillemets après l'annotation de clé :

erDiagram
    PRODUIT {
        int id PK
        string sku UK "Référence unique fournisseur"
        string nom
        decimal prix "En euros, TTC"
        int stock "Quantité disponible"
    }

Ces commentaires transforment le diagramme en dictionnaire de données : un seul endroit qui dit à la fois la structure et le sens de chaque champ.

Gérer le plusieurs-à-plusieurs

Une relation plusieurs-à-plusieurs se matérialise presque toujours par une table de jonction en base. L'ERD permet de la montrer explicitement, ce qui reflète la réalité du SQL.

erDiagram
    ETUDIANT ||--o{ INSCRIPTION : a
    COURS ||--o{ INSCRIPTION : reçoit
    ETUDIANT {
        int id PK
        string nom
    }
    COURS {
        int id PK
        string intitule
    }
    INSCRIPTION {
        int etudiant_id FK
        int cours_id FK
        date date_inscription
        string note
    }

Plutôt qu'un }o--o{ direct entre ETUDIANT et COURS, on passe par INSCRIPTION — exactement ce que vous coderiez en base. Le diagramme devient un plan d'implémentation, pas une abstraction.

:::example[Cas concret : le schéma d'un blog complet] Un modèle réaliste et directement transposable en migration SQL.

erDiagram
    UTILISATEUR ||--o{ ARTICLE : rédige
    UTILISATEUR ||--o{ COMMENTAIRE : écrit
    ARTICLE ||--o{ COMMENTAIRE : reçoit
    ARTICLE }o--o{ TAG : porte

    UTILISATEUR {
        int id PK
        string pseudo UK
        string email UK
        datetime cree_le
    }
    ARTICLE {
        int id PK
        int auteur_id FK
        string titre
        text contenu
        boolean publie
        datetime publie_le
    }
    COMMENTAIRE {
        int id PK
        int article_id FK
        int auteur_id FK
        text texte
        datetime cree_le
    }
    TAG {
        int id PK
        string libelle UK
    }

:::

ERD ou diagramme de classes : lequel choisir ?

Les deux se ressemblent, mais ne servent pas le même propos.

Règle simple : si vos « classes » n'ont que des données et aucune méthode, et que vous pensez en tables, c'est un ERD qu'il vous faut.

Erreurs fréquentes

:::danger[Ce qui casse un ERD]

• Inverser type et nom : c'est int id PK, pas id int PK.
• Oublier les deux-points et le libellé de la relation : CLIENT ||--o{ COMMANDE : passe (le libellé est requis).
• Mal orienter les pattes de corbeau : le { (plusieurs) va du côté de la table qui a la clé étrangère.
• Noms d'entités en minuscules avec espaces : préférez LIGNE_COMMANDE en majuscules avec underscore. :::

En résumé

• L'ERD décrit une base de données : entités (tables), attributs (colonnes) et relations.
• La notation crow's foot encode la cardinalité : || un, o| zéro ou un, }| un ou plusieurs, }o zéro ou plusieurs.
• Les attributs se déclarent type nom CLÉ "commentaire" ; clés PK, FK, UK.
• Une relation plusieurs-à-plusieurs se modélise via une table de jonction, comme en SQL.
• Choisissez l'ERD (et non le diagramme de classes) dès que vous pensez en tables et clés.

Au chapitre suivant, on change complètement de registre avec le diagramme de Gantt : planifier un projet, ses tâches, leurs durées et leurs dépendances, directement en texte.