Diagrammes entité-relation : guide pratique de la conception de bases de données

Un schéma de base de données écrit sans diagramme est une supposition. Vous pourriez obtenir les tables correctement du premier coup, mais vous manquerez presque certainement une relation, mal placer une clé étrangère, ou construire une structure qui résiste aux requêtes dont votre application a réellement besoin. Les diagrammes entité-relation — diagrammes ER — sont l'outil standard pour concevoir et communiquer la structure d'une base de données avant d'écrire une seule ligne de SQL.

Les diagrammes ER sont utiles non seulement pour la conception initiale mais tout au long du cycle de vie d'un système : intégration d'ingénieurs qui doivent comprendre un schéma existant, planification des migrations, identification des problèmes de normalisation, et documentation du modèle de données pour les parties prenantes non techniques.

Qu'est-ce qu'un diagramme ER ?

Un diagramme ER (diagramme entité-relation) est une représentation visuelle des entités dans une base de données et des relations entre elles. Il montre quelles données le système stocke, quels attributs chaque entité possède, et comment les entités se rapportent les unes aux autres.

Le concept a été introduit par Peter Chen en 1976 et a été étendu et adapté par les outils de base de données et les praticiens depuis. Deux styles de notation dominent la pratique moderne : la notation Chen (conception conceptuelle) et la notation patte de corbeau (axée sur l'implémentation, utilisée par la plupart des outils modernes).

Les diagrammes ER opèrent à différents niveaux d'abstraction :

Niveau	Objectif	Audience
Conceptuel	Entités et relations de haut niveau	Parties prenantes, PMs
Logique	Attributs, clés, cardinalité ajoutés	Architectes de base de données
Physique	Types de données, index, clés étrangères, prêt pour SQL	Développeurs, DBAs

Concepts clés

Entités

Une entité est une chose sur laquelle la base de données stocke des informations. Elle correspond à une table dans la base de données implémentée.

Entité forte : Existe indépendamment. A sa propre clé primaire. Exemple : Client, Produit, Commande
Entité faible : Dépend d'une autre entité pour son existence. Exemple : LigneCommande dépend de Commande

Conventions de nommage des entités :

Utilisez des noms singuliers (Commande, pas Commandes)
PascalCase est courant pour les noms d'entités
Nommez ce que la ligne représente, pas la collection

Attributs

Les attributs sont les propriétés d'une entité. Ils correspondent aux colonnes dans la table implémentée.

Type d'attribut	Description	Exemple
Simple	Valeur unique, atomique	`prenom`, `prix`
Composé	Composé de sous-attributs	`adresse` = rue + ville + code postal
Dérivé	Calculé à partir d'autres attributs	`age` dérivé de `dateNaissance`
Multi-valué	Peut avoir plusieurs valeurs	`telephones` (une personne peut en avoir plusieurs)
Attribut clé	Identifie de manière unique une instance	`clientId`, `email`

Dans les diagrammes ER physiques, spécifiez les types de données avec les noms des attributs :

Client
├── clientId    INT PRIMARY KEY
├── email       VARCHAR(255) UNIQUE NOT NULL
├── prenom      VARCHAR(100) NOT NULL
├── nom         VARCHAR(100) NOT NULL
├── creeLe      TIMESTAMP DEFAULT NOW()
└── statut      ENUM('actif', 'inactif', 'banni')

Relations

Une relation définit comment deux entités sont associées. Elle correspond à une contrainte de clé étrangère (ou une table de jonction pour les relations plusieurs-à-plusieurs) dans le schéma implémenté.

Les relations ont :

Un nom : décrit l'association (passe, contient, appartient à)
Une cardinalité : combien d'instances de chaque entité peuvent participer
Une participation : si la participation est obligatoire (totale) ou optionnelle (partielle)

Cardinalité

La cardinalité est le concept le plus important dans la modélisation ER. Elle définit la relation numérique entre les instances d'entités.

Cardinalité	Signification	Exemple
Un-à-Un	Une instance A est liée à exactement une instance B	`Utilisateur` a un `Profil`
Un-à-Plusieurs	Une instance A est liée à plusieurs instances B	`Client` passe plusieurs `Commandes`
Plusieurs-à-Un	Plusieurs instances A sont liées à une instance B	Plusieurs `Commandes` appartiennent à un `Client`
Plusieurs-à-Plusieurs	Plusieurs instances A sont liées à plusieurs B	`Étudiants` sont inscrits dans plusieurs `Cours`

Les relations plusieurs-à-plusieurs ne peuvent pas être implémentées directement dans une base de données relationnelle. Elles nécessitent une table de jonction (également appelée table de jointure ou entité associative) :

Étudiant ──< Inscription >── Cours

La table Inscription contient les clés étrangères vers Étudiant et Cours, plus tous les attributs de l'inscription elle-même (comme dateInscription ou note).

Styles de notation

Notation Chen

La notation Chen est la notation académique originale. Elle utilise des formes géométriques :

Rectangle : Entité
Ellipse : Attribut
Losange : Relation
Ligne : Connexion
Double ellipse : Attribut multi-valué
Ellipse pointillée : Attribut dérivé
Double rectangle : Entité faible
Double losange : Relation identifiante (pour les entités faibles)

Exemple ASCII de notation Chen :

 (clientId)   (email)    (prenom)
      |             |         |
      └─────────────┴─────────┘
                    |
              ┌─────────┐
              │  Client │
              └────┬────┘
                   │
              <  passe  >
                   │
              ┌─────────┐
              │ Commande│
              └─────────┘

La notation Chen est utile pour la modélisation conceptuelle car elle rend explicites les relations et les attributs. Elle devient encombrée pour les grands schémas.

Notation patte de corbeau

La notation patte de corbeau est le style dominant dans les outils de base de données modernes (MySQL Workbench, dbdiagram.io, ERDPlus). Elle code la cardinalité directement sur la ligne de relation à l'aide de symboles à chaque extrémité.

Symboles de la patte de corbeau :

Symbole en bout de ligne   Signification
─────────────────         ──────────────────────────────
      ──|                 Exactement un (obligatoire)
      ──o                 Zéro ou un (optionnel)
      ──<                 Plusieurs (un ou plus)
      ──o<                Zéro ou plus (plusieurs optionnels)
      ──|<                Un ou plus (plusieurs obligatoires)
      ──||                Exactement un (des deux côtés)

Exemple patte de corbeau — relations e-commerce :

Client ||──o< Commande ||──|< LigneCommande >|──|| Produit

Lecture : un Client a zéro ou plusieurs Commandes ; chaque Commande a une ou plusieurs LignesCommande ; chaque LigneCommande référence exactement un Produit.

Entité complète avec patte de corbeau :

┌─────────────┐       ┌─────────────┐       ┌──────────────────┐
│   Client    │       │  Commande   │       │  LigneCommande   │
│─────────────│       │─────────────│       │──────────────────│
│ PK id       │       │ PK id       │       │ PK id            │
│    email    │||──o<─│ FK clientId │||──|<─│ FK commandeId    │
│    nom      │       │ FK adresseId│       │ FK produitId     │
│    creeLe   │       │    statut   │       │    quantite      │
│    statut   │       │    total    │       │    prixUnitaire  │
└─────────────┘       │    creeLe   │       └──────────────────┘
                      └─────────────┘

La notation patte de corbeau est préférée pour les diagrammes ER logiques et physiques car elle est plus compacte que la notation Chen et reflète directement la structure du schéma SQL.

Le diagramme ER dans le processus de conception de base de données

Les diagrammes ER s'intègrent dans la conception de base de données à plusieurs étapes :

1. Recueil des exigences Travaillez avec les parties prenantes pour identifier les éléments que le système doit suivre. Chaque nom dans les exigences est une entité potentielle. Chaque fait sur un nom est un attribut potentiel.

2. Conception conceptuelle Dessinez les entités et les relations sans vous préoccuper des détails d'implémentation. Concentrez-vous sur ce que les données signifient, pas sur la façon dont elles sont stockées.

3. Conception logique Ajoutez les attributs, définissez les clés primaires, résolvez les relations plusieurs-à-plusieurs en tables de jonction, spécifiez la cardinalité.

4. Conception physique Ajoutez les types de données, les index, les contraintes et les spécifications NULL/NOT NULL. Le diagramme ER à cette étape doit se mapper directement au DDL SQL.

5. Révision et affinement Validez le schéma par rapport aux requêtes réelles : pouvez-vous récupérer les données dont votre application a besoin efficacement ? Le schéma prend-il en charge toutes les opérations requises ?

Guide de création étape par étape

Étape 1 : Identifier les entités

Lisez les exigences ou les user stories et mettez en évidence les noms qui représentent des concepts distincts que le système suit. Commencez par les plus évidents.

Pour un système e-commerce :

Client, Produit, Commande, Catégorie, Avis, Adresse, Paiement

Règles générales :

S'il a plusieurs instances, c'est probablement une entité (pas un attribut)
S'il a ses propres attributs, c'est probablement une entité
Si d'autres entités y font référence indépendamment, c'est une entité

Étape 2 : Définir les attributs pour chaque entité

Pour chaque entité, listez ses propriétés. Identifiez :

La clé primaire (identifiant unique, généré par le système ou naturel)
Les attributs obligatoires (NOT NULL en SQL)
Les attributs optionnels
Les attributs pouvant être composés (adresse) ou multi-valués (tags)

Évitez de stocker des données dérivées sauf si les performances l'exigent. age est dérivable de dateNaissance ; stocker les deux crée des problèmes de cohérence.

Étape 3 : Cartographier les relations

Pour chaque paire d'entités qui interagissent, définissez la relation :

Nommez la relation (groupe verbal du point de vue d'une entité)
Déterminez la cardinalité (un-à-un, un-à-plusieurs, plusieurs-à-plusieurs)
Déterminez la participation (chaque côté est-il obligatoire ou optionnel ?)

Écrivez-la comme une phrase et vérifiez qu'elle est logique dans les deux sens :

« Un Client passe zéro ou plusieurs Commandes »
« Une Commande est passée par exactement un Client »

Étape 4 : Résoudre les relations plusieurs-à-plusieurs

Chaque relation plusieurs-à-plusieurs devient une table de jonction. Identifiez les attributs de la relation elle-même (le cas échéant) — ceux-ci deviennent des colonnes dans la table de jonction.

Étudiant ──< Inscription >── Cours

Attributs d'Inscription :
- dateInscription
- note
- statut (actif, retiré, terminé)

Étape 5 : Attribuer des types de données et des contraintes

Pour chaque attribut, spécifiez :

Type de données (INT, VARCHAR(n), DECIMAL(10,2), TIMESTAMP, BOOLEAN)
NULL / NOT NULL
Valeurs par défaut
Contraintes d'unicité
Contraintes de vérification (ex. : prix > 0)

Étape 6 : Valider par rapport aux requêtes

Rédigez les requêtes clés que votre application exécutera et tracez-les dans le schéma. Si une requête nécessite plusieurs jointures qui auraient pu être évitées avec une meilleure conception, révisez le schéma.

Vérifiez :

Pouvez-vous récupérer l'historique complet des commandes d'un client ?
Pouvez-vous trouver tous les produits d'une catégorie ?
Pouvez-vous calculer les totaux des commandes à partir des lignes ?
Pouvez-vous générer des rapports de revenus par plage de dates ?

Considérations sur la normalisation

La normalisation est le processus de structuration d'un schéma pour réduire la redondance des données et améliorer l'intégrité. Les trois formes normales les plus couramment appliquées :

Première forme normale (1NF) : Chaque colonne contient des valeurs atomiques. Pas de groupes répétés. Chaque ligne est identifiable de manière unique.

Deuxième forme normale (2NF) : Satisfait 1NF. Chaque attribut non-clé dépend entièrement de la clé primaire entière (pertinent pour les clés composites).

Troisième forme normale (3NF) : Satisfait 2NF. Pas de dépendances transitives — les attributs non-clés dépendent uniquement de la clé primaire, pas d'autres attributs non-clés.

Exemple de violation de 3NF : stocker villeClient dans la table Commande. La ville dépend du client, pas de la commande. Si le client déménage, vous devez mettre à jour chaque enregistrement de commande.

Quand dénormaliser : La normalisation optimise pour la cohérence en écriture. Les charges de travail analytiques à lecture intensive bénéficient parfois de structures dénormalisées (vues matérialisées, tables de reporting) qui évitent les jointures coûteuses. Prenez cette décision délibérément, pas par accident.

Erreurs courantes

Utiliser des clés naturelles comme clés primaires. Les adresses e-mail changent. Les numéros de sécurité sociale ne doivent pas être stockés. Les noms ne sont pas uniques. Utilisez des clés de substitution (entiers auto-incrémentés ou UUID) comme clés primaires et ajoutez des contraintes d'unicité aux identifiants naturels.

Stocker des listes dans une seule colonne. Une colonne tags contenant des valeurs séparées par des virgules viole 1NF. Utilisez plutôt une table de jonction (ProduitTag).

Attributs manquants dans la table de jonction. Lors de la résolution d'une relation plusieurs-à-plusieurs, les équipes créent souvent une table de jonction simple avec seulement deux clés étrangères. Pensez aux attributs appartenant à la relation elle-même — date d'inscription, quantité de commande, niveau de permission.

Confondre entités et attributs. Adresse dans un système simple pourrait être des attributs sur Client. Dans un système où plusieurs clients partagent une adresse, ou où les adresses ont leur propre cycle de vie, Adresse devrait être une entité séparée.

Pas de prise en compte de la suppression douce. De nombreux systèmes doivent conserver les enregistrements après « suppression » pour des raisons d'audit ou réglementaires. Décidez à l'avance d'utiliser un horodatage supprimeLe ou un indicateur estActif, et appliquez-le de manière cohérente.

Sur-normalisation pour les petits ensembles de données. Extraire chaque chaîne répétée dans une table de recherche ajoute de la complexité sans bénéfice pour les ensembles de données qui ne dépasseront jamais quelques milliers de lignes. Appliquez votre jugement, pas des règles mécaniques.

Ignorer la conception des index. Le diagramme ER montre la structure, pas les performances. Après finalisation du schéma, identifiez les colonnes qui seront utilisées dans les clauses WHERE et les conditions JOIN et ajoutez-leur des index.

Exemple concret : schéma e-commerce

Le schéma suivant couvre les entités fondamentales d'un système e-commerce typique.

┌──────────────┐     ┌──────────────┐     ┌───────────────────┐
│    Client    │     │   Commande   │     │   LigneCommande   │
│──────────────│     │──────────────│     │───────────────────│
│ PK id        │     │ PK id        │     │ PK id             │
│    email     │||─o<│ FK clientId  │||─|<│ FK commandeId     │
│    prenom    │     │ FK adresseId │     │ FK produitId      │
│    nom       │     │    statut    │     │    quantite       │
│    creeLe    │     │    sousTotal │     │    prixUnitaire   │
│    statut    │     │    taxe      │     └────────┬──────────┘
└──────────────┘     │    expedition│              │
                     │    total     │         exactement un
                     │    creeLe    │              │
                     └──────────────┘     ┌────────┴──────────┐
                                          │      Produit      │
┌──────────────┐                          │───────────────────│
│   Adresse    │                          │ PK id             │
│──────────────│                          │ FK categorieId    │
│ PK id        │                          │    nom            │
│ FK clientId  │                          │    description    │
│    ligne1    │                          │    sku            │
│    ligne2    │                          │    prix           │
│    ville     │                          │    stockQte       │
│    region    │                          │    estActif       │
│    codePostal│                          └────────┬──────────┘
│    pays      │                                   │
│    estDefaut │                              plusieurs │ appartient à
└──────────────┘                                   │ un
                                          ┌────────┴──────────┐
┌──────────────┐                          │    Categorie      │
│   Paiement   │                          │───────────────────│
│──────────────│                          │ PK id             │
│ PK id        │                          │ FK parentId       │
│ FK commandeId│                          │    nom            │
│    methode   │                          │    slug           │
│    montant   │                          └───────────────────┘
│    statut    │
│    traiteLe  │
└──────────────┘

Décisions de conception clés dans ce schéma :

Adresse est une entité séparée (les clients peuvent avoir plusieurs adresses ; les commandes référencent l'adresse utilisée au moment de l'achat)
LigneCommande.prixUnitaire est stocké séparément de Produit.prix (les prix changent ; l'historique des commandes doit refléter ce qui a été facturé)
Categorie a un parentId auto-référentiel pour les catégories hiérarchiques
Paiement est séparé de Commande car une commande peut impliquer plusieurs tentatives de paiement

Créer des diagrammes ER avec Flowova

Concevoir un schéma manuellement ou dans un éditeur de texte brut est lent. Le générateur de diagrammes ER de Flowova vous permet de décrire votre modèle de données en langage naturel et produit un diagramme structuré à affiner. Commencez par votre liste d'entités, décrivez les relations entre elles, et obtenez un schéma visuel que vous pouvez partager avec votre équipe pour révision.

Conclusion

Les diagrammes ER sont la fondation d'une bonne conception de base de données. Ils vous obligent à être explicite sur les données que le système stocke, ce qui rend chaque enregistrement unique, et comment les entités se rapportent les unes aux autres — avant que ces décisions deviennent coûteuses à modifier en SQL. Commencez au niveau conceptuel avec des entités et des relations, passez au niveau logique en ajoutant des attributs et en résolvant les jointures plusieurs-à-plusieurs, puis ajoutez les types de données et les contraintes pour la conception physique. Validez par rapport aux requêtes réelles, appliquez la normalisation là où elle compte, et documentez le schéma pour que le prochain ingénieur puisse le comprendre sans lire les fichiers de migration.

Ressources associées

Symboles et significations des organigrammes — Référence de notation standard
Types d'organigrammes — Quand utiliser différents types de diagrammes
Guide des diagrammes de séquence — Modéliser les interactions système
Générateur de diagrammes ER — Créer des diagrammes ER avec l'IA