Qu’est-ce qu’un diagramme d’entité-relation (ERD) ?
Un Diagramme d’entité-relation (ERD) est un plan structurel utilisé pour concevoir, documenter et analyser des bases de données relationnelles. Il visualise les tables (entités) au sein d’un système, les colonnes spécifiques (attributs) qu’elles contiennent, et la manière dont ces tables sont liées entre elles. Dans PlantUML, les ERD sont rédigés à l’aide de la notation d’ingénierie des informations (IE), qui met en œuvre la notation standard notation en pied de corbeau pour représenter les contraintes relationnelles.
Que vous conceviez un magasin de données pour un microservice, optimisiez les chemins de jointure SQL, ou cartographiez une architecture de data warehouse à l’échelle de l’entreprise, un ERD UML piloté par le texte garantit que vos schémas de base de données sont parfaitement clairs. Avec VPasCode, vous pouvez définir vos tables de base de données, les clés d’index et les relations logiques à l’aide d’une syntaxe claire et déclarative. Le moteur gère automatiquement la taille des boîtes de tableaux et achemine vos chaînes de connecteurs de clés étrangères sans lignes de disposition superposées.
Guide de syntaxe principale : éléments et constructions
La construction d’un ERD de style IE robuste dans PlantUML repose sur des blocs d’entités structurés, des désignations explicites de clés et des modificateurs de cardinalité en pied de corbeau.
1. Déclaration des entités (tables de base de données)
Vous déclarez une table de base de données à l’aide du mot-clé entitysuivi du nom de la table et d’un ensemble d’accolades. À l’intérieur des accolades, vous listez les colonnes de votre table. Pour rendre votre schéma propre et lisible, utilisez un séparateur horizontal (--) pour séparer vos clés primaires/étrangères des attributs de données standards :
entity "users" as users_table {
id : INT [PK]
--
email : VARCHAR(255)
created_at : TIMESTAMP
}
2. Déclaration des clés primaires et étrangères
Bien que les indicateurs textuels comme `[PK]` ou `[FK]` fonctionnent bien, le moteur IE de PlantUML prend également en charge des icônes visuelles de clés. Placer un astérisque (*) avant un attribut le désigne comme une colonne **obligatoire (non nulle)**, tandis qu’une chaîne de texte propre ou une étiquette ajoute un contexte d’indexation explicite :
entité "orders" {
* id : INT <<PK>>
--
* user_id : INT <<FK>>
code_remise : VARCHAR(50)
}
3. Mappage de la cardinalité et des relations en forme de pied de corbeau
Pour connecter les tables et appliquer les contraintes d’intégrité référentielle, utilisez une combinaison de tirets, de crochets et de caractères de barre verticale. Dans la notation IE, ces symboles forment des têtes distinctes de **pied de corbeau** qui représentent les relations de base de données :
||--||**Exactement un vers exactement un :** Un mappage strict et obligatoire un-à-un.||--o|**Exactement un vers zéro ou un :** Un mappage un-à-un facultatif.||--|{**Exactement un vers un ou plusieurs :** Une dépendance obligatoire un-à-plusieurs.||--o{**Exactement un vers zéro, un ou plusieurs :** Une relation un-à-plusieurs standard et facultative.
table_utilisateurs ||--o{ commandes : "place"
Meilleures pratiques pour des schémas de base de données propres
- Respectez les conventions de casse : Gardez vos déclarations d’entités prévisibles. Utilisez snake_case en minuscules (par exemple,
order_items) pour les tables réelles mappées en SQL, ou utilisez CamelCase en majuscules pour les modèles conceptuels du domaine. - Documentez toujours les clés étrangères : Lorsque vous liez deux tables, spécifiez toujours la colonne clé étrangère dans le bloc de la table enfant. Cela fournit des contextes de référence clairs aux équipes d’ingénierie lors des migrations de données.
- Contrôlez l’espacement des pieds de corbeau : Les schémas de base de données complexes avec des dizaines de tables peuvent rapidement devenir encombrés. Si vos lignes de relation commencent à se croiser de manière inhabituelle, remplacez vos connecteurs en tiret double (
--) par trois ou quatre tirets (---) pour éloigner les tables et permettre au moteur de mise en page de disposer davantage d’espace pour organiser la grille.
Exemples réels de diagrammes ERD PlantUML
Exemple 1 : Modèle relationnel central de commerce électronique (Clés et mappages)
Ce plan fonctionnel modélise une boucle de transaction de base de données de commerce électronique centrale, en montrant comment les utilisateurs, les commandes et les registres de paiement sont liés entre eux à l’aide de relations de type « pied de corbeau » strictes.
@startuml
' Geler le rendu des boîtes d'entité en carrés modernes nets
hide circle
skinparam LINETYPE ortho
entity "utilisateurs" as user {
* id : INT <<PK>>
--
* email : VARCHAR(100)
* hash_mot_de_passe : VARCHAR(255)
téléphone : VARCHAR(20)
}
entity "commandes" as order {
* id : INT <<PK>>
--
* id_utilisateur : INT <<FK>>
* montant_total : DECIMAL(10,2)
statut : VARCHAR(50)
}
entity "registres_de_paiement" as ledger {
* id : INT <<PK>>
--
* id_commande : INT <<FK>>
* référence_transaction : VARCHAR(100)
passerelle : VARCHAR(50)
}
' Définir les liens du schéma relationnel
user ||--o{ order : "place"
order ||--|| ledger : "génère"
@enduml
Analyse syntaxique : La directive hide circle désactive les bulles par défaut des éléments de classe UML, tandis que skinparam LINETYPE ortho force les chemins de relation à adopter des angles droits nets de 90 degrés. Le schéma montre clairement qu’un utilisateur peut passer zéro ou plusieurs commandes (||--o{), tandis qu’une commande doit avoir exactement un enregistrement de registre de paiement associé (||--||).
Exemple 2 : Schéma de système avancé de gestion de contenu (Intersection Many-to-Many)
Ce plan d’entreprise avancé modélise la topologie complète d’un système de gestion de contenu (CMS). Il montre comment gérer proprement les architectures many-to-many en utilisant une table de mappage intermédiaire.
@startuml
hide circle
skinparam LINETYPE ortho
entity "articles" as post {
* id : INT <<PK>>
--
* id_auteur : INT <<FK>>
* titre : VARCHAR(255)
slug : VARCHAR(255)
contenu : TEXT
}
entity "catégories" as category {
* id : INT <<PK>>
--
* nom : VARCHAR(100)
description : VARCHAR(255)
}
entity "mappings_post_catégories" as mapping {
* id_article : INT <<PK>><<FK>>
* id_catégorie : INT <<PK>><<FK>>
--
attribué_le : TIMESTAMP
}
entity "commentaires" as comment {
* id : INT <<PK>>
--
* id_article : INT <<FK>>
nom_auteur : VARCHAR(100)
* contenu : TEXT
}
' Structures de liens relationnels
post ||--o{ mapping : "contient"
category ||--o{ mapping : "catégorise"
post ||--o{ comment : "attache"
@enduml
Analyse syntaxique : Ce modèle modélise une relation classique many-to-many entre les articles et les catégories. Au lieu de les connecter directement, il introduit une table intermédiaire (mappings_post_catégories) où les deux colonnes agissent comme une clé primaire composée. Les indicateurs de type « pied de corbeau » cartographient explicitement les relations en cascade jusqu’à la couche des commentaires.