ERD-Designer

Entwerfen Sie ein relationales Schema ohne Datenbankserver: Fügen Sie Tabellen hinzu, geben Sie ihnen Spalten mit Typen, Schlüsseln und Standardwerten und verbinden Sie sie dann durch Beziehungen. Das Entity-Relationship-Diagramm zeichnet sich bei jeder Eingabe neu, und dasselbe Modell wird exportiert als CREATE TABLE-DDL für MySQL, PostgreSQL, SQL Server, SQLite oder Oracle, als Mermaid-erDiagram-Quelltext oder als übertragbares Schema-JSON, das Sie hier wieder importieren oder im Migrationsgenerator öffnen können. Alles läuft lokal.
Was ist ein ERD? ERD steht für Entity-Relationship-Diagramm und ist die Entwurfszeichnung einer Datenbank, nicht die Aufzeichnung einer fertigen. Ein passender Vergleich ist ein Bauplan: Die laufende Datenbank ist das Gebäude, das ERD ist der Plan, und niemand gießt zuerst Beton und misst danach. Diese Seite ist der Zeichentisch für diesen Plan — Sie formen das Modell hier, und die DDL, der Mermaid-Quelltext und das Schema-JSON werden alle aus diesem einen Modell ausgegeben, sodass das Bild nicht vom erzeugten SQL abweichen kann.
Dasselbe Diagramm auf drei Ebenen. Ein konzeptuelles ERD benennt nur die Dinge, die zählen, und wie sie zusammenhängen, in Worten, die ein Nicht-Programmierer prüfen kann. Ein logisches ERD fügt die Schlüssel hinzu, die jedes Ding identifizieren, und löst Viele-zu-viele-Verbindungen auf, bleibt dabei aber frei vom Dialekt einer Engine. Ein physisches ERD ergänzt, was ein bestimmtes Produkt verlangt — Typbreiten, Standardwerte, Nullbarkeit, Eindeutigkeitsbedingungen, Löschregeln — und genau diese Ebene exportieren Sie hier, wenn Sie MySQL, PostgreSQL, SQL Server, SQLite oder Oracle wählen.
Woher die Kästchen kommen. Lesen Sie eine Beschreibung des Systems und unterstreichen Sie die Substantive: Kunde, Rechnung, Produkt, Sendung. Das sind die Tabellen. Die Fakten und Eigenschaften, die einem Substantiv anhängen — ein Rechnungsdatum, ein Stückpreis, eine E-Mail-Adresse — sind seine Spalten. Ein Verb, das zwei Substantive verbindet, wie in “eine Bestellung wird von einem Kunden aufgegeben”, ist eine Beziehung, und sie wird gespeichert, indem der identifizierende Schlüssel der Elternzeile als Fremdschlüssel in die Kinderzeile kopiert wird.
Wenn eine Verbindung viele-zu-viele ist. Ein Rezept verwendet viele Zutaten, und eine Zutat taucht in vielen Rezepten auf; deshalb kann keine der beiden Tabellen den Schlüssel der anderen behalten, ohne sich zu wiederholen. Die Antwort ist eine dritte Entität, deren einzige Aufgabe es ist, beides zu paaren — die Verbindungstabelle (oder Zuordnungstabelle) mit je einem Fremdschlüssel pro Seite, oft mit diesem Schlüsselpaar als eigenem Primärschlüssel. Ein Modell, das größtenteils aus solchen Paartabellen besteht, ist völlig normal: Eine Viele-zu-viele-Linie auf einem Whiteboard muss im echten Schema immer zu einem Kasten werden.
Warum sich der Aufwand vor der DDL lohnt. Eine falsche Linie in einer Zeichnung kostet eine Minute zum Ausradieren; derselbe Fehler, der nach dem Release gefunden wird, kostet eine Migration über Live-Daten. Ein Diagramm ist außerdem das einzige Artefakt, das auch Nicht-Entwickler prüfen können, und Fehler in Beziehungen — eine falsch herum stehende Kardinalität, ein fehlender eindeutiger Schlüssel, Kinderzeilen, die ohne Elternteil bleiben können — erscheinen hier als offensichtlich falsche Linien, während sie in einer 400-zeiligen DDL-Datei zwischen den Constraints untergehen.
Vorwärts oder rückwärts? Dieser Designer arbeitet vorwärts: erst das Modell, dann die DDL. Die Seite SQL zu ERD arbeitet in die andere Richtung — Sie fügen bestehende CREATE TABLE-Anweisungen ein, und sie baut das Diagramm neu auf, was der schnellere Weg ist, sobald die Datenbank bereits existiert.
1 — Tabellen
Bearbeiten Tabellenname Spalten Beziehungen Actions
2 — Spalten
Spalte Typ PK AI NN UQ Standard Actions
PK = Primärschlüssel, AI = Autoinkrement / Identität, NN = nicht null, UQ = eindeutig
3 — Beziehungen (Fremdschlüssel)
Kindertabelle Kinderspalte Actions Elterntabelle Elternspalte Bei Löschung Actions
Ein Fremdschlüssel wird in der DDL zu einer Zeile CONSTRAINT ... FOREIGN KEY.
4 — Export
Mermaid-erDiagram-Quelltext
Das JSON-Modell ist das Austauschformat der Datenbank-Werkzeugfamilie: Fügen Sie es als Vorher-/Nachher-Schema in den Migrationsgenerator ein oder importieren Sie es hier erneut, um später weiter zu bearbeiten.