ER-Diagramm-Beispiel: eine Datenbank für einen Onlineshop Schritt für Schritt entwerfen

Im ER-Diagramm wird ein Datenbankentwurf geprüft, bevor daraus Migrationen werden. Eine Tabellenliste sagt dir, was existiert. Das Diagramm zeigt, wie die Tabellen voneinander abhängen: welche Zeile welche andere braucht, was fehlen darf und wo sich eine n:m-Beziehung versteckt.

Dieser Guide entwirft eine kleine Onlineshop-Datenbank von einfachen Anforderungen bis zum fertigen Entity-Relationship-Diagramm und erklärt die Notation dort, wo sie auftaucht. Der Shop ist nur das Beispiel; die Methode funktioniert für jedes Schema.

Wann du ein ER-Diagramm brauchst

Eine Tabellenliste reicht, solange ein Schema eine Handvoll Tabellen hat und ein Team daran arbeitet. Zeichne das Diagramm, wenn Leute außerhalb dieses Teams die Daten verstehen müssen, wenn du einen Entwurf prüfst, bevor Migrationen entstehen, oder wenn ein Schema so gewachsen ist, dass es niemand mehr im Kopf hat.

Es gibt zwei verbreitete Notationen. Die Chen-Notation stammt aus Peter Chens Artikel von 1976, der das Entity-Relationship-Modell eingeführt hat. Sie zeichnet Entitäten als Rechtecke und Beziehungen als Rauten und eignet sich für die konzeptionelle Modellierung. Die Krähenfuß-Notation (Crow's Foot) zeichnet Tabellen als Boxen und setzt die Kardinalität an die Enden der Linien. Sie wird meist Gordon Everest (1976) zugeschrieben und ist die Notation, die die meisten Datenbank-Designtools verwenden. Dieser Guide nutzt die Krähenfuß-Notation.

Schritt 1: Anforderungen in einfachen Sätzen

Schreib die Regeln zuerst als Sätze auf. Aus jedem wird eine Tabelle, eine Spalte oder eine Linie.

1. Ein Kunde registriert sich mit einer E-Mail-Adresse und kann mehrere Adressen speichern.
2. Ein Kunde gibt Bestellungen auf. Jede Bestellung wird an eine der Adressen des Kunden geliefert.
3. Eine Bestellung enthält ein oder mehrere Produkte, jeweils mit Menge und gezahltem Preis.
4. Jedes Produkt gehört zu einer Kategorie.
5. Eine Bestellung kann mehrere Zahlungsversuche haben, und bei den meisten ist einer erfolgreich.

Schritt 2: Entitäten und Schlüssel

Die Substantive werden zu Entitäten: Kunden, Adressen, Bestellungen, Bestellpositionen, Produkte, Kategorien und Zahlungen. Jede bekommt einen Primärschlüssel. Nutze für die meisten Tabellen Surrogatschlüssel (eine Identity-Spalte) und natürliche eindeutige Schlüssel dort, wo das Geschäft schon einen hat: die E-Mail eines Kunden, die SKU eines Produkts.

Bestellpositionen sind die Ausnahme. Eine Bestellposition hat keine eigene Identität; sie ist die Verbindung zwischen einer Bestellung und einem Produkt. Ihr Primärschlüssel ist das Paar (order_id, product_id).

Schritt 3: Beziehungen und Kardinalität

Jeder Fremdschlüssel ist eine Linie. Die Symbole an den Enden sagen, wie viele Zeilen auf der jeweiligen Seite stehen können:

Lies eine Beziehung von einer Tabelle über die Linie bis zum Symbol am anderen Ende: „ein Kunde gibt null oder viele Bestellungen auf“, und zurück: „jede Bestellung wird von genau einem Kunden aufgegeben“.

Ein NOT-NULL-Fremdschlüssel bedeutet „genau eins“ auf der referenzierten Seite, ein Fremdschlüssel, der NULL sein darf, bedeutet „null oder eins“. „Eins oder viele“ auf der anderen Seite ist eine Geschäftsregel, die kein Fremdschlüssel erzwingt. Schreib sie deshalb ins Diagramm, wo Leser sie sehen.

Schritt 4: Die n:m-Beziehung

Bestellungen und Produkte stehen in einer n:m-Beziehung: Eine Bestellung enthält viele Produkte, und ein Produkt taucht in vielen Bestellungen auf. Relationale Datenbanken modellieren das mit einer Tabelle in der Mitte. Hier gibt es diese Tabelle schon aus einem besseren Grund als reiner Verknüpfung: order_items trägt die Menge und den Stückpreis beim Checkout, also Fakten, die zum Paar gehören und zu keiner Seite allein.

Schritt 5: Entscheidungen, die du aufschreiben solltest

Manche Entscheidungen sind in der Spaltenliste unsichtbar und führen zu Bugs, wenn niemand sie kennt:

• Preis-Snapshot. order_items.unit_price kopiert den Produktpreis beim Checkout. Eine spätere Preisänderung darf alte Bestellungen nicht verändern.
• Adressen werden nicht an Ort und Stelle bearbeitet. Sobald eine Bestellung auf eine Adresse verweist, würde das Bearbeiten dieser Zeile umschreiben, wohin frühere Bestellungen gegangen sind. Eine Änderung legt eine neue Adresszeile an.
• Zahlungen sind Versuche. Eine Zeile pro Versuch, mit Status, damit fehlgeschlagene und wiederholte Zahlungen sichtbar bleiben.
• Geld ist numeric. Die PostgreSQL-Dokumentation empfiehlt numeric für Geldbeträge, weil der Typ exakt rechnet.

Schritt 6: Die DDL

Die zwei zentralen Tabellen in PostgreSQL:

CREATE TABLE orders (
  id                  bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  customer_id         bigint NOT NULL REFERENCES customers (id),
  shipping_address_id bigint NOT NULL REFERENCES addresses (id),
  status              text NOT NULL DEFAULT 'pending'
                      CHECK (status IN ('pending', 'paid', 'shipped', 'cancelled')),
  currency            char(3) NOT NULL,
  total               numeric(12,2) NOT NULL CHECK (total >= 0),
  placed_at           timestamptz NOT NULL DEFAULT now()
);

CREATE TABLE order_items (
  order_id   bigint NOT NULL REFERENCES orders (id) ON DELETE CASCADE,
  product_id bigint NOT NULL REFERENCES products (id),
  quantity   integer NOT NULL CHECK (quantity > 0),
  unit_price numeric(12,2) NOT NULL,  -- copied from products.price at checkout
  PRIMARY KEY (order_id, product_id)
);

CREATE INDEX ON orders (customer_id);
CREATE INDEX ON order_items (product_id);

PostgreSQL legt für eine Fremdschlüsselspalte nicht von selbst einen Index an. Die beiden CREATE INDEX-Zeilen sind deshalb wichtig für Joins und für Löschvorgänge in den referenzierten Tabellen. order_items.order_id ist durch den Primärschlüssel abgedeckt, dessen Index mit dieser Spalte beginnt. ON DELETE CASCADE sagt, dass eine Bestellposition ihre Bestellung nicht überleben kann.

Das Diagramm

So liest du es:

• Kunden (oben links) haben null oder viele Adressen und geben null oder viele Bestellungen auf.
• Bestellungen (Mitte) gehen an genau eine Adresse, enthalten eine oder viele Bestellpositionen und haben null oder viele Zahlungen.
• Bestellpositionen verbinden jede Bestellung mit Produkten, und jedes Produkt gehört zu genau einer Kategorie.
• Die Notiz enthält die Entscheidungen aus Schritt 5, direkt neben den Tabellen, die sie betreffen.

So zeichnest du ein lesbares ER-Diagramm

• Benenne Beziehungen mit Verben. „aufgegeben von“, „geliefert an“, „bezahlt“ machen aus Linien Sätze.
• Markiere Schlüssel in den Attributen. PK- und FK-Marker zeigen auf einen Blick, zu welcher Spalte eine Linie gehört.
• Gruppiere Tabellen nach Domäne. Kunden und Adressen, Bestellung und Zahlung, der Katalog. Halte jede Gruppe zusammen, damit die Linien kurz bleiben.
• Lass Rauschen weg. Audit-Spalten wie created_by und updated_at, Soft-Delete-Flags in jeder Tabelle und technische Tabellen fügen Zeilen hinzu, aber kein Verständnis.
• Zeichne die n:m-Tabelle. Wer sie hinter einer direkten Linie zwischen Bestellungen und Produkten versteckt, versteckt auch die Menge und den Preis-Snapshot.
• Zeig Geschäftsregeln, die das Schema nicht ausdrücken kann. „Eine oder viele“ Positionen pro Bestellung und „Adressen werden nicht bearbeitet“ sind Regeln, die alle kennen müssen.

Halte es mit dem Schema synchron

Ein von Hand gezeichnetes ER-Diagramm ist nach der nächsten Migration veraltet. Erzeuge den ersten Entwurf stattdessen aus dem Schema. Das kostenlose Tool SQL als ER-Diagramm liest CREATE-TABLE-Anweisungen oder einen kompletten pg_dump und zeichnet pro Tabelle eine Karte mit PK-, FK- und UK-Markern sowie pro Fremdschlüssel eine Linie. Außerdem gibt es Tools für PostgreSQL, Prisma und DBML. Die erzeugten Krähenfuß-Enden folgen den Spalten: Ein NOT-NULL-Fremdschlüssel ist Pflicht, einer, der NULL sein darf, optional. Regeln, die das SQL nicht enthält, etwa „eine oder viele“ Positionen, ergänzt du von Hand.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und leg ein Diagramm an.
2. Um mit dem Schema zu starten, füge die CREATE-TABLE-Anweisungen in das Tool SQL als ER-Diagramm ein und wähle In Archboard öffnen. Um von Hand zu zeichnen, füge für jede Tabelle eine Entität aus dem Entity-Relationship-Pack hinzu, mit einem Attribut pro Zeile und PK- und FK-Markern.
3. Verbinde jeden Fremdschlüssel mit der Tabelle, die er referenziert, und stell die Linienenden auf Krähenfuß-Marker: genau eins an der referenzierten Tabelle, null oder viele auf der Fremdschlüsselseite und eins oder viele, wo eine Geschäftsregel es verlangt.
4. Beschrifte jede Linie mit einem Verb, etwa „aufgegeben von“ oder „geliefert an“.
5. Füge einen Markdown-Block aus dem Basis-Pack mit den Designentscheidungen hinzu.

Das Beispiel nutzt 8 Diagramm-Nodes und bleibt damit im Free-Plan. Wie sich ein Schema in den Rest eines Systems einfügt, zeigt das Beispiel für ein System-Design-Diagramm.

FAQ

Was ist der Unterschied zwischen einem ER-Diagramm und einem Datenbankschema-Diagramm? In der Praxis überschneiden sie sich. Ein ER-Diagramm kann konzeptionell sein und Entitäten und Beziehungen zeigen, bevor es Tabellen gibt; ein Schemadiagramm zeigt die tatsächlichen Tabellen, Spalten und Schlüssel. Das Krähenfuß-Diagramm in diesem Guide ist beides.

Sollte jede Tabelle einen Surrogatschlüssel haben? Die meisten Tabellen profitieren davon, weil sich natürliche Schlüssel ändern. Verknüpfungstabellen wie order_items nutzen stattdessen oft das Paar der Fremdschlüssel als Primärschlüssel.

Wie stelle ich eine n:m-Beziehung dar? Mit der Tabelle in der Mitte und zwei 1:n-Linien. Benenne die mittlere Tabelle nach dem, was sie darstellt, etwa Bestellpositionen, nicht nach den zwei Tabellen, die sie verbindet.

Zeichne ich jede Spalte? Zeichne Schlüssel und die Spalten, die den Entwurf erklären. Lass Audit- und technische Spalten weg, außer das Diagramm handelt von ihnen.

Chen oder Krähenfuß? Chen für konzeptionelle Diskussionen mit Leuten, die nicht in Tabellen denken, Krähenfuß für alles, was eine Datenbank werden soll.

Kostenlos starten — ein Seat, keine Kreditkarte.