Qu’est-ce qu’un diagramme d’entité-association (ERD) ?
Un Diagramme d’entité-association (ERD) est un plan structurel utilisé pour concevoir, documenter et analyser les schémas de bases de données relationnelles. Il décrit les tables de données spécifiques (entités) au sein d’une application, les colonnes (attributs) imbriquées dans ces tables, ainsi que les règles d’intégrité référentielle qui les relient. Rédigé en utilisant la notation standard notation d’ingénierie des informations (IE), elle utilise clairement notation en pied de corbeau des têtes pour illustrer les contraintes de données et les dépendances entre plusieurs tables.
Avec Mermaid.js, vous pouvez définir les index de table de production, les types de données et les connexions de clés étrangères à l’aide d’un bloc de texte clair et déclaratif. Le moteur gère automatiquement la taille des conteneurs de mise en page à plusieurs colonnes et route les lignes de connexion sans que les étiquettes de texte se superposent.
Guide de syntaxe principale : éléments et constructions
La création d’un schéma de base de données valide et entièrement exécutable dans Mermaid repose sur des blocs d’entités structurales, des mappages de types de données, des balises d’index et des opérateurs de cardinalité.
1. Déclaration des entités et des colonnes de table
Vous initialisez une toile ERD à la première ligne en utilisant le mot-clé erDiagram mot-clé. Pour définir une table, écrivez le nom de l’entité suivi d’une accolade ouverte, puis listez vos configurations de colonnes de manière séquentielle sur des lignes distinctes :
erDiagram
USERS {
int id
string email
timestamp created_at
}
2. Marquage des clés primaires, des clés étrangères et des commentaires
Le moteur ERD de Mermaid vous permet d’attribuer des balises d’indexation structurelle directement après la définition du nom de colonne et du type de données. Vous pouvez également ajouter un commentaire facultatif à une colonne en l’entourant de guillemets doubles :
PK— Marque explicitement une colonne comme clé primaire de la table.FK— Marque une colonne comme clé étrangère liée à une table parente.
erDiagram
ORDERS {
int id PK
int user_id FK "Lien vers USERS.id"
string coupon_code
}
3. Maîtriser les modificateurs de cardinalité en forme de pied de corbeau
Pour connecter les tables et appliquer les règles d’intégrité référentielle, cartographiez leurs relations à l’aide d’opérateurs de ligne spécialisés. Les têtes de caractère forment des formes visuelles en pied de corbeau qui définissent les contraintes de multiplicité des données :
||--||**Exactement un vers exactement un :** Une correspondance stricte et obligatoire 1:1.||--o|**Exactement un vers zéro ou un :** Une dépendance 1:1 facultative.||--|{**Exactement un vers un ou plusieurs :** Une liaison parentale obligatoire 1:N.||--o{**Exactement un vers zéro, un ou plusieurs :** Une relation 1:N standard et facultative.
Meilleures pratiques pour les schémas de données relationnelles
- Maintenez une casse de table cohérente : Gardez les noms d’entités prévisibles. Utilisez des chaînes en majuscules (par exemple,
USER_ACCOUNTS) ou snake_case en minuscules strictes (par exemple,user_accounts) pour correspondre à votre code d’infrastructure SQL du monde réel. - Incluez toujours les types de données : Évitez de déclarer du texte de colonne brut sans types. Déclarez explicitement des définitions telles que
int,varchar, oubooleangarantit que vos diagrammes d’architecture servent de référence technique précise. - Gardez les étiquettes de relation au verbe : Lors du lien entre éléments, fournissez une courte chaîne de verbe à l’infinitif en minuscules dans votre affectation de relation (par exemple,
||--o{ : "contient") pour documenter le mappage de la logique métier.
Exemples réels de diagrammes ERD Mermaid.js
Exemple 1 : Modèle transactionnel central pour e-commerce (Clés et mappages)
Ce plan fonctionnel modélise une boucle transactionnelle centrale pour une base de données e-commerce, en montrant comment les utilisateurs, les commandes et les systèmes de suivi des paiements sont liés à l’aide de contraintes strictes en forme de pied de corbeau.
erDiagram
CUSTOMERS {
int id PK
string email
string password_hash
}
ORDERS {
int id PK
int customer_id FK
decimal total_amount
string status
}
TRANSACTION_LEDGERS {
int id PK
int order_id FK
string reference_token
string gateway
}
CUSTOMERS ||--o{ ORDERS : "place"
ORDERS ||--|| TRANSACTION_LEDGERS : "génère"
Analyse syntaxique : Ce schéma définit clairement les limites des transactions. Les règles de mappage indiquent qu’un client peut passer zéro ou plusieurs commandes au fil du temps (||--o{), tandis qu’un enregistrement de commande individuel doit générer exactement une entrée correspondante dans le registre des transactions (||--||).
Exemple 2 : Schéma d’un système de gestion de contenu d’entreprise (intersection plusieurs-à-plusieurs)
Ce plan avancé de base de données décrit l’architecture d’une plateforme de gestion de contenu. Il détaille comment résoudre des configurations complexes plusieurs-à-plusieurs en introduisant une entité de mappage explicite pont.
erDiagram
POSTS {
int id PK
string title
string slug
text body_content
}
CATEGORIES {
int id PK
string name
string description
}
POST_CATEGORY_MAPPINGS {
int post_id PK, FK
int category_id PK, FK
timestamp assigned_at
}
COMMENTS {
int id PK
int post_id FK
string author_name
text comment_body
}
POSTS ||--o{ POST_CATEGORY_MAPPINGS : "contient"
CATEGORIES ||--o{ POST_CATEGORY_MAPPINGS : "classe"
POSTS ||--o{ COMMENTS : "attache" 
Analyse syntaxique : Pour gérer la relation plusieurs-à-plusieurs entre `POSTS` et `CATEGORIES`, le script introduit une table d’intersection (`POST_CATEGORY_MAPPINGS`). Cette boîte de mappage utilise des clés composées agissant simultanément comme clés primaires et étrangères (PK FK), reliant les nœuds externes à l’aide de connexions standard en forme de pied de corbeau un-à-plusieurs.