Datenbankschema modellieren: so wird es für dein ganzes Team lesbar

Ein Schema-Diagramm ist eines der nützlichsten Dokumente, die ein Backend-Team besitzen kann, und eines der ersten, das veraltet. Jemand zeichnet es vor dem Launch, es bekommt einen Ehrenplatz im Wiki, und zwanzig Migrationen später beschreibt es eine Datenbank, die es nicht mehr gibt.

Der andere Fehlerfall ist schlimmer: Das Diagramm bleibt technisch aktuell, wird aber zu Spaghetti. Fremdschlüssel-Linien laufen quer durch drei Tabellen, um eine vierte zu erreichen, Kardinalität wird geraten statt gezeigt, und niemand erkennt auf einen Blick, ob ein Nutzer viele Bestellungen hat oder genau eine. LetDraw ist darauf ausgelegt, Schema-Diagramme sowohl lesbar als auch korrekt zu halten, damit es sich lohnt, sie aufzubewahren.

Tabellen, die wissen, dass sie Tabellen sind

Eine ER-Tabelle in LetDraw ist kein Kasten mit eingetipptem Text. Sie ist ein echtes Tabellenelement mit typisierten Spalten und Schlüsselmarkierungen, die Struktur ist also Teil der Form und keine Zeichnung, die du von Hand synchron halten musst.

• Typisierte Spalten. Jede Zeile trägt einen Namen und einen Typ, sodass id bigint sich wie ein Schema liest und nicht wie ein Label.
• Schlüsselmarkierungen. Primär- und Fremdschlüssel sind an der Spalte markiert, sodass der Leser die Join-Fläche sieht, ohne danach zu suchen.
• Direkt bearbeitbar. Füge eine Spalte hinzu, ändere einen Typ oder benenne ein Feld um, und das Layout zieht mit. Du bearbeitest ein Modell, du schiebst keine Rechtecke herum.

Weil die Spalten strukturiert sind, lassen sich die Beziehungen zwischen Tabellen korrekt statt dekorativ zeichnen. Hier kommt die Kardinalität ins Spiel.

Krähenfuß-Notation für die Kardinalität, nativ dargestellt

Eine Beziehung zwischen zwei Tabellen ist nur nützlich, wenn sie dir die Form der Daten verrät. Ein Nutzer zu vielen Bestellungen ist eine völlig andere Welt als ein Nutzer zu einer Bestellung, und ein Diagramm, das beides verwischt, ist schlechter als gar keins. LetDraw zeichnet die Krähenfuß-Notation nativ auf die Beziehungslinie, sodass sich 1:n, 1:1 und n:m direkt am Verbinder ablesen lassen.

Eine Beziehungslinie sollte dir die Form der Daten verraten, nicht nur, dass sich zwei Tabellen berühren.

Wenn du Code statt Tabellen modellierst, zeichnet dieselbe Verbinder-Engine echte UML-Klassendiagramme mit hohlen Pfeilspitzen für Vererbung und den anderen Standardspitzen. Du musst kein Dreieck von Hand zeichnen und hoffen, dass es an der richtigen Stelle landet; die Notation ist nativ, also sieht ein Vererbungspfeil für alle, die UML lesen, wie Vererbung aus.

Fremdschlüssel-Linien, die um deine Tabellen herumführen

Dieses Detail entscheidet, ob ein Schema-Diagramm mehr als zehn Tabellen überlebt. Wächst ein Schema, zieht der naive Ansatz eine gerade Linie von einem Schlüssel zum anderen, und diese Linien schneiden schnell durch jede Tabelle, die im Weg steht. Das Bild wird zum Knoten.

LetDraw nutzt intelligentes Routing für Fremdschlüssel-Verbinder, sodass eine Beziehungslinie deine Tabellen als Hindernisse behandelt und um sie herumführt. Der Join zwischen orders.user_id und users.id bleibt sichtbar, selbst wenn ein Dutzend Tabellen dazwischen liegen. Das Diagramm wird mit wachsendem Schema dichter, aber nicht unleserlich, und genau darum zeichnet man es ja.

Beginne mit dem SQL, das du schon geschrieben hast

Du musst keine einzige Tabelle von Hand platzieren. Öffne den Dialog "Aus Code generieren", füge deine CREATE TABLE-Anweisungen ein, und LetDraw baut das ER-Diagramm für dich: Tabellen mit typisierten Spalten, markierte Schlüssel und Beziehungen, die aus den Fremdschlüsseln gezeichnet werden. Hier ist die DDL hinter der Abbildung oben.

CREATE TABLE users (
  id          bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  email       text NOT NULL UNIQUE,
  created_at  timestamptz NOT NULL DEFAULT now()
);

CREATE TABLE orders (
  id          bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  user_id     bigint NOT NULL REFERENCES users (id),
  total_cents integer NOT NULL,
  status      text NOT NULL DEFAULT 'pending'
);
-- user_id REFERENCES users(id) becomes the crow's-foot relationship

Diese REFERENCES-Klausel liest LetDraw, um die 1:n-Linie zu platzieren, komplett mit dem Krähenfuß auf der orders-Seite. Ab da ist es eine normale Zeichnung, die du verfeinerst und dann auslieferst:

• Ordne Tabellen neu an, gruppiere die, die zu einem Bounded Context gehören, und kommentiere die kniffligen Joins
• Füge Tabellen hinzu, die in der DDL noch fehlen, und zeichne ihre Beziehungen von Hand mit denselben Krähenfuß-Spitzen
• Exportiere als PNG, SVG oder PDF für ein Design-Dokument, oder wandle das Diagramm zurück in Mermaid oder D2, wenn du es wieder als Code willst

Warum sich ein lesbares Schema lohnt

Ein Schema-Diagramm ist ein Vertrag darüber, wie deine Daten zusammenpassen, und es zahlt sich nur aus, wenn Leute ihm vertrauen. Typisierte Spalten und markierte Schlüssel machen es präzise; Krähenfuß-Kardinalität macht es ehrlich in Bezug auf die Form der Daten; intelligentes Routing hält es lesbar, während es wächst. Generiere den ersten Entwurf aus dem SQL, das du ohnehin pflegst, und die Kosten, es aktuell zu halten, sinken nahezu auf null, und nur so bleibt ein solches Diagramm lebendig.

Füge deine CREATE TABLE-Anweisungen ein und sieh zu, wie sich das ER-Diagramm von selbst zusammensetzt, samt Schlüsseln.