Concepteur ERD

Concevez un schéma relationnel sans serveur de base de données — ajoutez des tables, donnez-leur des colonnes avec types, clés et valeurs par défaut, puis reliez-les par des relations. Le diagramme entité-relation se redessine à mesure que vous saisissez, et le même modèle s’exporte en DDL CREATE TABLE pour MySQL, PostgreSQL, SQL Server, SQLite ou Oracle, en source Mermaid erDiagram, ou en JSON de schéma portable que vous pouvez réimporter ici ou ouvrir dans le générateur de migrations. Tout s’exécute localement.
Qu’est-ce qu’un ERD ? ERD est l’abréviation de diagramme entité-relation, et c’est le dessin de conception d’une base de données plutôt que le relevé d’une base finie. Une comparaison utile est le plan d’un bâtiment : la base en fonctionnement est le bâtiment, l’ERD est le plan, et personne ne coule le béton avant de mesurer après coup. Cette page est la planche à dessin de ce plan — vous façonnez le modèle ici, et le DDL, la source Mermaid et le JSON de schéma sont tous imprimés à partir de ce même modèle, si bien que le schéma ne peut pas s’écarter du SQL qu’il produit.
Le même diagramme à trois niveaux. Un ERD conceptuel ne nomme que les choses importantes et leurs liens, dans des termes qu’un non-développeur peut vérifier. Un ERD logique ajoute les clés qui identifient chaque chose et résout les liens plusieurs-à-plusieurs, tout en restant indépendant du dialecte de tout moteur. Un ERD physique précise ce qu’exige un produit donné — largeurs de types, valeurs par défaut, nullabilité, contraintes d’unicité, règles de suppression — et c’est le niveau que vous exportez ici lorsque vous choisissez MySQL, PostgreSQL, SQL Server, SQLite ou Oracle.
D’où viennent les boîtes. Lisez la description du système et soulignez les noms : client, facture, produit, expédition. Ce sont les tables. Les faits et qualités rattachés à un nom — une date de facture, un prix unitaire, une adresse e-mail — sont ses colonnes. Un verbe qui relie deux noms, comme dans « une commande est passée par un client », est une relation, et elle se stocke en recopiant la clé d’identification de la ligne parente dans la ligne enfant sous forme de clé étrangère.
Quand un lien est plusieurs-à-plusieurs. Une recette utilise plusieurs ingrédients, et un ingrédient apparaît dans plusieurs recettes, si bien qu’aucune des deux tables ne peut conserver la clé de l’autre sans se répéter. La réponse est une troisième entité dont l’unique rôle est d’associer les deux — la table de jonction (ou associative), qui porte une clé étrangère par côté, souvent avec cette paire de clés comme clé primaire propre. Un modèle composé surtout de tables d’association est tout à fait normal : une ligne plusieurs-à-plusieurs tracée sur un tableau blanc doit toujours devenir une boîte dans le schéma réel.
Pourquoi s’en soucier avant l’existence du DDL. Un mauvais trait sur un dessin coûte une minute à effacer ; la même erreur découverte après la mise en production coûte une migration sur des données vivantes. Un diagramme est aussi le seul artefact que les non-développeurs peuvent relire, et les défauts de relations — une cardinalité inversée, une clé unique manquante, des lignes enfants qui peuvent exister sans parent — apparaissent ici comme de mauvais traits évidents, alors que dans un fichier DDL de 400 lignes ils se cachent parmi les contraintes.
En avant ou en arrière ? Ce concepteur va vers l’avant : on modélise d’abord, le DDL sort ensuite. La page voisine SQL vers ERD fait le chemin inverse — collez des instructions CREATE TABLE existantes et elle reconstruit le diagramme, ce qui est plus rapide une fois la base déjà existante.
1 — Tables
Modifier Nom de la table Colonnes Relations Actions
2 — Colonnes
Colonne Type PK AI NN UQ Valeur par défaut Actions
PK = clé primaire, AI = incrément automatique / identité, NN = non nul, UQ = unique
3 — Relations (clés étrangères)
Table enfant Colonne enfant Actions Table parente Colonne parente À la suppression Actions
Une clé étrangère devient une ligne CONSTRAINT ... FOREIGN KEY dans le DDL.
4 — Export
Source Mermaid erDiagram
Le modèle JSON est le format d’échange de la famille d’outils de base de données — collez-le dans le Générateur de migrations comme schéma avant/après, ou réimportez-le ici pour continuer à l’éditer plus tard.