🗄️ Mermaid

Entity-Relationship-Diagramm

Entwerfen Sie Datenbankschemata, die Sinn ergeben

Dieses Beispiel im Editor öffnen Eines mit KI generieren

Was ist ein Entity-Relationship-Diagramm?

Ein ER-Diagramm zeigt Datenbankentitäten, ihre Attribute und die Kardinalität ihrer Beziehungen (eins-zu-viele, viele-zu-viele). Es ist der Bauplan jeder relationalen Datenbank.

ER-Diagramme gehören in den Pull Request, der eine Migration hinzufügt, und in die erste Stunde des Onboardings — oft erklärt sich ein Produkt am schnellsten über sein Datenmodell. Sie machen Kardinalitäten explizit: eine Adresse pro Kunde oder mehrere ist eine Geschäftsregel, kein Detail. Was sie nicht abbilden, ist das physische Design: keine Indizes, keine Partitionierung, keine Abfragemuster. Die Migrationsdatei bleibt die maßgebliche Quelle.

Live-Beispiel

Mermaid-Code

erDiagram
    CUSTOMER ||--o{ ORDER : places
    ORDER ||--|{ ORDER_LINE : contains
    PRODUCT ||--o{ ORDER_LINE : "ordered in"
    CUSTOMER {
      string id PK
      string email UK
    }
    ORDER {
      string id PK
      date created_at
    }

Live-Beispiel

Wann einsetzen

Ein neues Datenbankschema vor der ersten Migration entwerfen

Ein bestehendes Schema für neue Teammitglieder dokumentieren

Datenmodelle mit nicht-technischen Stakeholdern besprechen

Häufige Fehler

Kardinalität von der falschen Seite gelesen

In CUSTOMER ||--o{ ORDER : places bedeutet das || neben CUSTOMER einen Kunden pro Bestellung, das o{ neben ORDER null oder mehr Bestellungen pro Kunde. Jede Markierung zählt ihre eigene Entität, vom anderen Ende aus gesehen.

Eine Beziehung ohne Beschriftung

CUSTOMER ||--o{ ORDER allein ist ein Parse-Fehler: Mermaid erwartet einen Doppelpunkt. Schreiben Sie : places oder : "", wenn die Beziehung selbsterklärend ist. Das ist mit Abstand der häufigste Fehler in erDiagram.

Entitätsnamen mit Leerzeichen

ORDER LINE ||--o{ PRODUCT erzeugt keine Entität namens ORDER LINE — der Name wird am Leerzeichen getrennt. Setzen Sie ihn als "ORDER LINE" in Anführungszeichen oder nutzen Sie die Unterstrich-Konvention des übrigen Schemas.

Grundlegende Syntax

.mmd

erDiagram
    USER ||--o{ POST : writes
    USER {
      string id PK
      string email
    }

CUSTOMER ||--o{ ORDER : places
Jede Beziehung braucht eine Beschriftung nach dem Doppelpunkt; schreiben Sie : "", wenn es nichts Sinnvolles zu sagen gibt. Beschriftungen mit Leerzeichen gehören in Anführungszeichen, etwa : "ordered in".
ORDER { string id PK decimal total "in cents" }
Attribute bestehen aus Typ, Name, optionalen Schlüsselmarkierungen (PK, FK, UK, kommagetrennt) und einem Kommentar in Anführungszeichen. Die Typen sind freier Text, nichts wird validiert.
ORDER ||--|{ LINE : contains CUSTOMER }o..o{ PROMO : uses
Eine durchgezogene Linie steht für eine identifizierende Beziehung — das Kind kann nicht allein existieren. Punkte markieren eine nicht identifizierende Beziehung, bei der der Fremdschlüssel optional ist.
erDiagram direction LR
Standardmäßig läuft das Diagramm von oben nach unten. direction LR zieht ein breites Schema in die Waagerechte, was auf einer Dokumentationsseite meist besser passt als eine hohe Spalte aus Entitäten.

Fragen zu diesem Diagramm

Wie lese ich Kardinalitätssymbole wie ||--o{ ?

|| bedeutet genau eins, o| null oder eins, }| eins oder mehrere, }o null oder mehrere. CUSTOMER ||--o{ ORDER liest sich also als „ein Kunde gibt null oder mehrere Bestellungen auf“.

Kann ich ein ER-Diagramm aus SQL generieren?

Ja — fügen Sie Ihre CREATE-TABLE-Anweisungen ein oder beschreiben Sie Ihre Daten: Die KI erzeugt das entsprechende ER-Diagramm mit Schlüsseln und Beziehungen.

Kann ich ein ER-Diagramm zusammen mit meinen Migrationen versionieren?

Ja, und das ist der Hauptgrund, es als Text zu schreiben. Das Diagramm liegt neben der Migration, wird im Review zeilenweise gediffed, und eine Schemaänderung, die niemand nachgezogen hat, fällt im Diff sofort als fehlende Bearbeitung auf.

Kann ein Mermaid-ER-Diagramm Indizes und Constraints zeigen?

Nein. Es zeigt Entitäten, Attributtypen und die Markierungen PK, FK oder UK — sonst nichts: keine Indizes, Defaults, Check-Constraints oder Trigger. Betrachten Sie es als Karte des Schemas, nicht als Spezifikation, aus der sich eine Datenbank erzeugen ließe.

Wie modelliere ich eine Viele-zu-viele-Beziehung?

Entweder direkt mit }o--o{ oder über eine explizite Zwischenentität: STUDENT ||--o{ ENROLMENT und COURSE ||--o{ ENROLMENT. Nehmen Sie die zweite Form, sobald die Verknüpfung eigene Spalten trägt, etwa ein Einschreibedatum. Sie entspricht dann der Tabelle, die Sie ohnehin anlegen.

Was ist der Unterschied zwischen PK, FK und UK?

PK markiert den Primärschlüssel, FK einen Fremdschlüssel auf eine andere Entität, UK eine Eindeutigkeitsbedingung. Mermaid rendert sie nur als Beschriftungen — es prüft nie, ob ein FK zu einem Primärschlüssel im Diagramm passt. Die Konsistenz bleibt Ihre Aufgabe.

Entity-Relationship-Diagramm oder ein anderer Diagrammtyp?

Entity-Relationship-Diagramm oder Klassendiagramm?

Entscheiden Sie danach, was der Leser als Nächstes tut. Schreibt er SQL oder eine Migration, geben Sie ihm Entitäten, Schlüssel und Kardinalitäten. Schreibt er Anwendungscode, liegt ein Klassendiagramm mit Methoden und Vererbung näher an dem, was er tatsächlich tippen wird.

Entity-Relationship-Diagramm oder Flowchart?

Ein ER-Diagramm beantwortet „was wird gespeichert und wie hängt es zusammen“; ein Flowchart beantwortet „was passiert und in welcher Reihenfolge“. Kästen, die Substantive mit Attributen sind, gehören ins ER-Diagramm; Kästen, die Verben sind, gehören ins Flowchart. Im Zweifel entscheidet die Wortart.

Weitere Diagrammtypen entdecken

🔀 Flowchart 💬 Sequenzdiagramm 🧩 Klassendiagramm 🔄 Zustandsdiagramm 📅 Gantt-Diagramm 🥧 Kreisdiagramm 🧠 Mindmap 🌿 Git-Graph 🕰️ Zeitleiste 🚶 User Journey 🎯 Quadrantendiagramm

Erstellen Sie jetzt Ihr Entity-Relationship-Diagramm

Beschreiben Sie es in natürlicher Sprache — die KI schreibt den Mermaid-Code für Sie.

Mermaid Studio öffnen