Ein Entity-Relationship-Diagramm vermittelt Datenstruktur und Kardinalität. Es unterstützt Entwurf und Einarbeitung, ersetzt aber keine ausführbaren Migrationen. Das Diagramm erklärt wichtige Einschränkungen; die Datenbankdefinition bleibt die maßgebliche Quelle.
Entitäten und Attribute modellieren
erDiagram
CUSTOMER ||--o{ ORDER : places
ORDER ||--|{ ORDER_ITEM : contains
PRODUCT ||--o{ ORDER_ITEM : appears_in
CUSTOMER { uuid id PK string email UK }
ORDER { uuid id PK uuid customer_id FK string status }
ORDER_ITEM { uuid order_id FK uuid product_id FK int quantity }
PRODUCT { uuid id PK string name decimal price }Attributtypen sind beschreibend. Verwenden Sie das Teamvokabular, erwarten Sie aber nicht, dass das Diagramm Präzision, Indizes, Standardwerte oder Check-Constraints erzwingt.
Kardinalität an beiden Enden lesen
CUSTOMER ||--o{ ORDER bedeutet: Jede Bestellung gehört genau einem Kunden, ein Kunde kann keine oder viele Bestellungen haben. Das Lesen beider Seiten macht Optionalität sichtbar. Beziehungsbeschriftungen dokumentieren die Aussage und sind keine Fremdschlüsselnamen.
Die richtige Schema-Menge zeigen
Auditspalten, technische Indizes und Integrationsfelder überladen Übersichten. Zeigen Sie die zum Verständnis nötigen Schlüssel und Attribute und verlinken Sie Migrationen oder generierte Schemadokumentation für Details.
Annahmen mit der Datenbank prüfen
Optionalität, Eindeutigkeit und Richtung müssen echten Constraints entsprechen. „Genau eins“ ist irreführend, wenn der Fremdschlüssel nullable ist. Unsichere Beziehungen sollten im Text als solche markiert werden.
Die ER-Vorlage im Mermaid-Editor validiert die Syntax und exportiert skalierbares SVG.