Was ist ein Entitäts-Beziehungs-Diagramm (ERD)?
Ein Entitäts-Beziehungs-Diagramm (ERD) ist eine strukturelle Bauplanung, die zur Gestaltung, Dokumentation und Analyse relationaler Datenbanken verwendet wird. Sie visualisiert die Tabellen (Entitäten) innerhalb eines Systems, die spezifischen Spalten (Attribute), die sie enthalten, und wie diese Tabellen miteinander verknüpft sind. In PlantUML werden ERDs mithilfe der Information Engineering (IE)-Notation, die die Standard-Crow’s-Foot-Notation verwendet, um relationale Einschränkungen darzustellen.
Unabhängig davon, ob Sie einen Mikroservice-Datenspeicher entwerfen, SQL-Verknüpfungspfade optimieren oder eine unternehmensweite Datenlagerarchitektur aufbauen, stellt ein textbasiertes UML-ERD sicher, dass Ihre Datenbankschemata vollkommen klar sind. Mit VPasCode, können Sie Ihre Datenbanktabellen, Indexschlüssel und logischen Beziehungen mit einer sauberen, deklarativen Syntax definieren. Die Engine verarbeitet automatisch die Größenanpassung der Tabellenboxen und leitet Ihre Fremdschlüssel-Verbindungszeichenfolgen ohne überlappende Layoutlinien.
Kern-Syntaxleitfaden: Elemente und Konstrukte
Die Erstellung eines robusten IE-stiligen ERDs in PlantUML beruht auf strukturierten Entitätsblöcken, expliziten Schlüsselbezeichnungen und Crow’s-Foot-Kardinalitätsmodifikatoren.
1. Deklaration von Entitäten (Datenbanktabellen)
Sie deklarieren eine Datenbanktabelle mithilfe des entitySchlüsselwort, gefolgt vom Tabellennamen und einem Satz geschweifter Klammern. Innerhalb der Klammern listen Sie Ihre Tabellenspalten auf. Um Ihr Schema sauber und lesbar zu gestalten, verwenden Sie einen horizontalen Linien-Trenner (--), um Ihre Primär-/Fremdschlüssel von den Standard-Datenattributen zu trennen:
entity "users" as users_table {
id : INT [PK]
--
email : VARCHAR(255)
created_at : TIMESTAMP
}
2. Festlegen von Primär- und Fremdschlüsseln
Während Textindikatoren wie `[PK]` oder `[FK]` gut funktionieren, unterstützt auch die IE-Engine von PlantUML visuelle Schlüssel-Symbole. Durch Platzieren eines Sternchens (*) vor einem Attribut wird es als **verpflichtend (nicht null)** markiert, während ein sauberer Textstring oder ein Tag einen expliziten Index-Kontext hinzufügt:
Entität "orders" {
* id : INT <<PK>>
--
* user_id : INT <<FK>>
rabattcode : VARCHAR(50)
}
3. Abbildung der Crow’s-Foot-Kardinalität und -Beziehungen
Verwenden Sie zur Verbindung von Tabellen und zur Durchsetzung von Referenzintegritätsbeschränkungen eine Kombination aus Bindestrichen, eckigen Klammern und Pipe-Zeichen. In der IE-Notation bilden diese Symbole unterschiedliche **Crow’s-Foot**-Köpfe, die Datenbankbeziehungen darstellen:
||--||**Genau eine zu genau einer:** Eine strenge, obligatorische ein-zu-eins-Zuordnung.||--o|**Genau eine zu null oder einer:** Eine optionale ein-zu-eins-Zuordnung.||--|{**Genau eine zu einer oder mehreren:** Eine obligatorische ein-zu-viele-Abhängigkeit.||--o{**Genau eine zu null, einer oder mehreren:** Eine standardmäßige, optionale ein-zu-viele-Beziehung.
benutzer_tabelle ||--o{ bestellungen : "plaziert"
Best Practices für saubere Datenbank-Schemata
- Geben Sie Namenskonventionen aufrecht: Halten Sie Ihre Entitätsdeklarationen vorhersehbar. Verwenden Sie Kleinbuchstaben mit Unterstrichen (z. B.
bestellpositionen) für tatsächlich SQL-zugeordnete Tabellen oder Großbuchstaben mit CamelCase für konzeptionelle Domänenmodelle. - Dokumentieren Sie immer Fremdschlüssel: Wenn Sie zwei Tabellen verknüpfen, geben Sie den Fremdschlüssel-Spaltennamen immer innerhalb des Blocks der Kindtabelle an. Dies bietet für Entwicklungsteams während Datenmigrationen klare Referenzkontexte.
- Steuerung des Abstands der Crow’s-Foot-Symbole: Komplexe Datenbankschemata mit Dutzenden von Tabellen können schnell überfüllt werden. Wenn Ihre Beziehungslinien unnatürlich beginnen zu kreuzen, ersetzen Sie Ihre Doppelpunktkonnektoren (
--) durch drei oder vier Bindestriche (---) um die Tabellen auseinanderzudrängen und dem Layout-Engine mehr Platz zum Organisieren des Rasters zu geben.
Praxisbeispiele für PlantUML-ERD
Beispiel 1: Kern-Modell für E-Commerce-Relationen (Schlüssel & Zuordnungen)
Dieser funktionale Bauplan modelliert eine zentrale Transaktions-Schleife einer E-Commerce-Datenbank und zeigt, wie Benutzer, Bestellungen und Zahlungsprotokolle über strenge Crow’s-Foot-Beziehungen miteinander verknüpft sind.
@startuml
' Entity-Box-Darstellung in scharfen modernen Quadraten fixieren
hide circle
skinparam LINETYPE ortho
entity "Benutzer" as user {
* id : INT <<PK>>
--
* email : VARCHAR(100)
* password_hash : VARCHAR(255)
phone : VARCHAR(20)
}
entity "Bestellungen" as order {
* id : INT <<PK>>
--
* user_id : INT <<FK>>
* total_amount : DECIMAL(10,2)
status : VARCHAR(50)
}
entity "Zahlungsprotokolle" as ledger {
* id : INT <<PK>>
--
* order_id : INT <<FK>>
* transaction_reference : VARCHAR(100)
gateway : VARCHAR(50)
}
' Definiere relationale Schema-Verbindungen
user ||--o{ order : "stellt"
order ||--|| ledger : "erzeugt"
@enduml
Syntax-Aufschlüsselung: Die Anweisung hide circle deaktiviert die standardmäßigen UML-Klassen-Symbolblasen, während skinparam LINETYPE ortho zwingt Beziehungspfade zu sauberen 90-Grad-Ecken. Das Schema zeigt deutlich, dass ein Benutzer null oder mehr Bestellungen stellen kann (||--o{), während eine Bestellung genau ein zugehöriges Zahlungsprotokoll aufweisen muss (||--||).
Beispiel 2: Erweitertes Schema für ein Content-Management-System (Many-to-Many-Verknüpfung)
Dieser erweiterte Unternehmensbauplan zeigt die vollständige Topologie eines Content-Management-Systems (CMS). Er veranschaulicht, wie viele-zu-viele-Architekturen sauber durch Nutzung einer Zwischentabelle behandelt werden können.
@startuml
hide circle
skinparam LINETYPE ortho
entity "Beiträge" as post {
* id : INT <<PK>>
--
* author_id : INT <<FK>>
* title : VARCHAR(255)
slug : VARCHAR(255)
body : TEXT
}
entity "Kategorien" as category {
* id : INT <<PK>>
--
* name : VARCHAR(100)
description : VARCHAR(255)
}
entity "Beitrag-Kategorie-Zuordnungen" as mapping {
* post_id : INT <<PK>><<FK>>
* category_id : INT <<PK>><<FK>>
--
assigned_at : TIMESTAMP
}
entity "Kommentare" as comment {
* id : INT <<PK>>
--
* post_id : INT <<FK>>
author_name : VARCHAR(100)
* content : TEXT
}
' Relationale Verknüpfungsstrukturen
post ||--o{ mapping : "enthält"
category ||--o{ mapping : "kategorisiert"
post ||--o{ comment : "hängt an"
@enduml
Syntax-Aufschlüsselung: Dieser Bauplan modelliert eine klassische viele-zu-viele-Beziehung zwischen Beiträgen und Kategorien. Anstatt sie direkt zu verbinden, führt er eine Zwischentabelle (Beitrag-Kategorie-Zuordnungen), bei der beide Spalten als zusammengesetzter Primärschlüssel dienen. Die Crow’s-Foot-Indikatoren zeigen die kaskadierenden Beziehungen explizit bis zur Kommentar-Ebene hinunter.