Datenmodellierung: Entity-Relationship-Grundlagen

1. Was Datenmodellierung leistet, bevor SQL geschrieben wird

Datenmodellierung mit dem Entity-Relationship-Ansatz ist der konzeptionelle Schritt, der vor jeder einzelnen CREATE TABLE Anweisung stattfinden sollte. Statt direkt Tabellen und Spalten zu entwerfen, identifiziert man zunaechst die relevanten Objekte der Fachdomaene, ihre Eigenschaften und wie sie zueinander in Beziehung stehen. Dieser Zwischenschritt wirkt fuer erfahrene Entwickler manchmal wie unnoetiger Overhead, zahlt sich aber in jedem Projekt aus, das ueber ein Wochenendprojekt hinausgeht, weil er Modellierungsfehler sichtbar macht, bevor sie in Migrationsskripten und Anwendungscode eingebettet sind.

Das Ergebnis der Datenmodellierung ist ein Entity-Relationship-Diagramm, kurz ER-Diagramm, das drei Grundbausteine verwendet: Entitaeten als Rechtecke, Attribute als Eigenschaften dieser Entitaeten und Beziehungen als Verbindungen zwischen Entitaeten. Dieses Diagramm ist bewusst datenbankunabhaengig, es enthaelt keine SQL-Datentypen und keine Implementierungsdetails wie Indizes. Erst im zweiten Schritt, dem Mapping auf ein relationales Schema, werden aus diesem konzeptionellen Modell konkrete Tabellen mit Spalten, Primaerschluesseln und Fremdschluesseln.

2. Entitaeten und Attribute definieren

Eine Entitaet ist ein eigenstaendiges Objekt der Fachdomaene, ueber das die Datenbank Informationen speichern soll, zum Beispiel ein Buch, ein Autor oder ein Bibliotheksmitglied. Die Faustregel bei der Datenmodellierung: Wenn ein Objekt eine eigene Identitaet hat und unabhaengig von anderen Objekten existieren kann, ist es ein guter Kandidat fuer eine eigene Entitaet. Ein Buch existiert unabhaengig davon, ob es gerade ausgeliehen ist, also ist "Buch" eine Entitaet. Der Ausleihvorgang selbst verbindet zwei Entitaeten miteinander und wird typischerweise zu einer eigenen Entitaet, sobald er eigene Attribute wie ein Ausleihdatum traegt.

Attribute sind die Eigenschaften einer Entitaet: ein Buch hat einen Titel, eine ISBN und ein Erscheinungsjahr, ein Mitglied hat einen Namen und eine E-Mail-Adresse. Jede Entitaet braucht mindestens ein Attribut oder eine Kombination von Attributen, die sie eindeutig identifiziert, den sogenannten Schluesselkandidaten. Bei der Datenmodellierung unterscheidet man einfache Attribute, die einen einzelnen atomaren Wert tragen, von zusammengesetzten Attributen wie einer Adresse, die sich aus Strasse, Postleitzahl und Ort zusammensetzt, und von mehrwertigen Attributen, die spaeter typischerweise in eine eigene Tabelle ausgelagert werden, weil relationale Datenbanken keine Listen in einer einzelnen Spalte gut unterstuetzen.

3. Beziehungen: Verben zwischen Entitaeten

Eine Beziehung beschreibt, wie zwei oder mehr Entitaeten miteinander interagieren, und wird im ER-Diagramm meist mit einem Verb benannt: ein Mitglied "leiht" ein Buch "aus", ein Autor "schreibt" ein Buch. Diese sprachliche Formulierung ist kein Zufall, sondern ein nuetzlicher Trick der Datenmodellierung: Wenn sich eine Beziehung nicht in einem einfachen Verb ausdruecken laesst, ist oft die Modellierung selbst noch unklar und sollte ueberarbeitet werden, bevor sie in ein Schema uebersetzt wird.

Beziehungen koennen unaer sein, wenn eine Entitaet mit sich selbst in Beziehung steht, etwa wenn ein Buch eine Fortsetzung eines anderen Buchs ist, binaer, wenn genau zwei Entitaeten beteiligt sind, was der weitaus haeufigste Fall ist, oder ternaer, wenn drei Entitaeten gleichzeitig an einer einzigen Beziehung beteiligt sind, etwa ein Mitglied, ein Buch und ein konkretes Exemplar bei einer Ausleihe an einem bestimmten Standort. Ternaere Beziehungen sind in der Datenmodellierung selten wirklich notwendig, oft laesst sich dieselbe Information sauberer durch zwei binaere Beziehungen ausdruecken, was das spaetere Mapping auf Tabellen erheblich vereinfacht.

4. Kardinalitaet und Crow's-Foot-Notation

Kardinalitaet beschreibt, wie viele Instanzen einer Entitaet an einer Beziehung mit wie vielen Instanzen einer anderen Entitaet teilnehmen koennen. Die drei Grundformen sind 1:1, 1:n und n:m. Ein Beispiel fuer 1:1: Jedes Bibliotheksmitglied hat genau eine Mitgliedskarte, und jede Mitgliedskarte gehoert genau einem Mitglied. Ein Beispiel fuer 1:n: Ein Autor kann mehrere Buecher geschrieben haben, aber in einem vereinfachten Modell hat jedes Buch genau einen Hauptautor. Ein Beispiel fuer n:m: Ein Mitglied kann viele Buecher ausleihen, und ein Buch kann im Lauf der Zeit von vielen unterschiedlichen Mitgliedern ausgeliehen werden.

Die Crow's-Foot-Notation, die krähenfussartige Notation, ist der in der Praxis am weitesten verbreitete Standard fuer Datenmodellierung-Diagramme. Ein einzelner Strich an einem Ende der Verbindungslinie bedeutet "genau eins", ein Kreis bedeutet "null oder optional", und der namensgebende Krähenfuss, drei sich auffaechernde Linien, bedeutet "viele". Kombiniert ergeben sich die vertrauten Symbole: ein Strich plus Kreis bedeutet "null oder eins", ein Krähenfuss plus Strich bedeutet "eins oder mehr", ein Krähenfuss plus Kreis bedeutet "null oder mehr". Diese Notation macht auf einen Blick sichtbar, ob eine Beziehung optional oder verpflichtend ist, eine Information, die spaeter direkt in NOT NULL Constraints uebersetzt wird.

5. Schwache Entitaeten und Identifizierung

Eine schwache Entitaet ist eine Entitaet, die ohne eine andere, sie identifizierende Entitaet nicht sinnvoll existieren kann und keinen eigenen, vollstaendig unabhaengigen Primaerschluessel besitzt. Ein typisches Beispiel in der Datenmodellierung eines Bibliothekssystems: ein physisches Exemplar eines Buchs. Ein Exemplar hat eine Inventarnummer, die aber nur innerhalb eines bestimmten Buchs eindeutig ist, nicht global. Ohne Bezug auf das zugehoerige Buch ist die Inventarnummer allein nicht aussagekraeftig.

Im ER-Diagramm werden schwache Entitaeten mit einem doppelt umrandeten Rechteck markiert, und die identifizierende Beziehung mit einer doppelt umrandeten Raute. Bei der Umsetzung in SQL wird der Primaerschluessel der schwachen Entitaet meist als zusammengesetzter Schluessel modelliert, bestehend aus dem Fremdschluessel zur besitzenden Entitaet plus einem lokalen Diskriminator. In der Praxis vergibt man heute aber haeufig trotzdem einen globalen Surrogate Key fuer schwache Entitaeten, weil das nachgelagerte JOINs vereinfacht, waehrend man die fachliche Abhaengigkeit weiterhin ueber eine NOT NULL Fremdschluesselspalte erzwingt. Diese pragmatische Abweichung ist ein bewusster Kompromiss zwischen reiner Datenmodellierung-Theorie und praktischer Implementierung.

-- Weak entity modeled with a composite key: local number only
-- unique within its owning book, not globally
CREATE TABLE book_copies (
    book_id       INT NOT NULL,
    copy_number   INT NOT NULL,
    condition     VARCHAR(20) NOT NULL DEFAULT 'good',
    PRIMARY KEY (book_id, copy_number),
    FOREIGN KEY (book_id) REFERENCES books(book_id)
);

-- Pragmatic alternative: global surrogate key, dependency still enforced
CREATE TABLE book_copies_surrogate (
    copy_id       INT PRIMARY KEY AUTO_INCREMENT,
    book_id       INT NOT NULL,  -- NOT NULL enforces the identifying relationship
    copy_number   INT NOT NULL,
    condition     VARCHAR(20) NOT NULL DEFAULT 'good',
    FOREIGN KEY (book_id) REFERENCES books(book_id),
    UNIQUE (book_id, copy_number)
);

6. Von der Entitaet zur Tabelle: Mapping-Regeln

Der Uebergang vom ER-Diagramm zur relationalen Tabelle folgt einem festen Satz von Regeln. Jede starke Entitaet wird zu einer eigenen Tabelle, jedes einfache Attribut wird zu einer Spalte, und der gewaehlte Schluesselkandidat wird zum Primaerschluessel. Eine 1:n-Beziehung wird abgebildet, indem die Fremdschluesselspalte auf der "n"-Seite der Beziehung eingefuegt wird, also in der Tabelle, die potenziell viele Instanzen hat: Da ein Autor viele Buecher schreiben kann, bekommt die books-Tabelle eine author_id-Spalte, nicht umgekehrt.

Eine 1:1-Beziehung laesst sich auf zwei Arten abbilden: entweder man legt den Fremdschluessel mit einer zusaetzlichen UNIQUE-Constraint in eine der beiden Tabellen, oder man erwaegt, ob die beiden Entitaeten inhaltlich so eng zusammengehoeren, dass eine Zusammenlegung in eine einzige Tabelle sinnvoller ist. Diese Entscheidung haengt oft davon ab, ob die zweite Entitaet optionale, selten benoetigte Attribute traegt, die man aus Performance-Gruenden getrennt halten moechte. In jedem Fall bleibt die Datenmodellierung-Regel bestehen: Der Fremdschluessel referenziert immer den Primaerschluessel der Zieltabelle, nie umgekehrt.

-- 1:n mapping: foreign key goes on the "many" side
CREATE TABLE authors (
    author_id   INT PRIMARY KEY AUTO_INCREMENT,
    full_name   VARCHAR(150) NOT NULL
);

CREATE TABLE books (
    book_id     INT PRIMARY KEY AUTO_INCREMENT,
    title       VARCHAR(255) NOT NULL,
    isbn        VARCHAR(20) NOT NULL UNIQUE,
    author_id   INT NOT NULL,
    FOREIGN KEY (author_id) REFERENCES authors(author_id)
);

-- 1:1 mapping: foreign key with a UNIQUE constraint
CREATE TABLE members (
    member_id   INT PRIMARY KEY AUTO_INCREMENT,
    full_name   VARCHAR(150) NOT NULL,
    email       VARCHAR(255) NOT NULL UNIQUE
);

CREATE TABLE membership_cards (
    card_id     INT PRIMARY KEY AUTO_INCREMENT,
    member_id   INT NOT NULL UNIQUE,  -- UNIQUE enforces 1:1
    issued_on   DATE NOT NULL,
    FOREIGN KEY (member_id) REFERENCES members(member_id)
);

7. n:m-Beziehungen und Zwischentabellen

Eine n:m-Beziehung laesst sich in einem relationalen Schema nicht direkt abbilden, weil eine einzelne Spalte immer nur einen einzigen Fremdschluessel-Wert tragen kann. Die Loesung, die jede Datenmodellierung an dieser Stelle anwendet, ist eine eigene Zwischentabelle, oft auch Verbindungstabelle oder Assoziationstabelle genannt, die zwei Fremdschluessel enthaelt, jeweils einen auf jede der beteiligten Entitaeten. Diese Zwischentabelle loest die n:m-Beziehung strukturell in zwei 1:n-Beziehungen auf: ein Mitglied hat viele Zeilen in der Ausleihtabelle, ein Buch hat ebenfalls viele Zeilen in derselben Tabelle.

Der zusammengesetzte Primaerschluessel der Zwischentabelle besteht typischerweise aus beiden Fremdschluesseln, es sei denn, die Beziehung selbst traegt zusaetzliche Attribute, die eine eigene Identitaet rechtfertigen, wie ein Ausleihdatum, ein Rueckgabedatum oder ein Bearbeiterstatus. In diesem Fall bekommt die Zwischentabelle oft einen eigenen Surrogate-Primaerschluessel, und die beiden Fremdschluessel bilden stattdessen einen zusammengesetzten UNIQUE-Index, um Mehrfachausleihen desselben Buchs durch dasselbe Mitglied zum selben Zeitpunkt zu verhindern.

-- n:m mapping: junction table resolves the many-to-many relationship
CREATE TABLE loans (
    loan_id      INT PRIMARY KEY AUTO_INCREMENT,
    member_id    INT NOT NULL,
    book_id      INT NOT NULL,
    borrowed_on  DATE NOT NULL,
    returned_on  DATE,  -- NULL means the book is still checked out
    FOREIGN KEY (member_id) REFERENCES members(member_id),
    FOREIGN KEY (book_id) REFERENCES books(book_id)
);

-- Prevent the same member from having two open loans of the same book
CREATE UNIQUE INDEX idx_one_active_loan
    ON loans (member_id, book_id)
    WHERE returned_on IS NULL;

8. Vollstaendiges Beispiel: das Bibliothekssystem als DDL

Setzt man alle bisherigen Schritte der Datenmodellierung zusammen, entsteht ein vollstaendiges, konsistentes Schema fuer das Bibliothekssystem: authors und books in einer 1:n-Beziehung, members und membership_cards in einer 1:1-Beziehung, und members mit books ueber die loans-Zwischentabelle in einer n:m-Beziehung. Jede dieser Tabellen entstand direkt aus einer im ER-Diagramm identifizierten Entitaet oder Beziehung, ohne dass waehrend der Implementierung neue strukturelle Entscheidungen improvisiert werden mussten.

Dieser methodische Weg, erst konzeptionell modellieren und dann mechanisch auf Tabellen abbilden, reduziert das Risiko von Nacharbeiten erheblich. Wird spaeter eine neue Anforderung ergaenzt, etwa dass ein Buch mehrere Autoren haben kann, zeigt das ER-Diagramm sofort, dass sich die Kardinalitaet von 1:n zu n:m aendert und eine neue Zwischentabelle noetig wird, statt dass diese Erkenntnis erst beim Schreiben einer fehlschlagenden Abfrage auffaellt.

-- A query enabled directly by the modeled relationships:
-- all currently active loans with member and book details
SELECT
    m.full_name  AS member_name,
    b.title      AS book_title,
    l.borrowed_on
FROM loans AS l
JOIN members AS m ON m.member_id = l.member_id
JOIN books   AS b ON b.book_id   = l.book_id
WHERE l.returned_on IS NULL
ORDER BY l.borrowed_on;

-- Complete library schema derived directly from the ER diagram
CREATE TABLE authors (
    author_id  INT PRIMARY KEY AUTO_INCREMENT,
    full_name  VARCHAR(150) NOT NULL
);

CREATE TABLE books (
    book_id    INT PRIMARY KEY AUTO_INCREMENT,
    title      VARCHAR(255) NOT NULL,
    isbn       VARCHAR(20) NOT NULL UNIQUE,
    author_id  INT NOT NULL,
    FOREIGN KEY (author_id) REFERENCES authors(author_id)
);

CREATE TABLE members (
    member_id  INT PRIMARY KEY AUTO_INCREMENT,
    full_name  VARCHAR(150) NOT NULL,
    email      VARCHAR(255) NOT NULL UNIQUE
);

CREATE TABLE membership_cards (
    card_id    INT PRIMARY KEY AUTO_INCREMENT,
    member_id  INT NOT NULL UNIQUE,
    issued_on  DATE NOT NULL,
    FOREIGN KEY (member_id) REFERENCES members(member_id)
);

CREATE TABLE loans (
    loan_id      INT PRIMARY KEY AUTO_INCREMENT,
    member_id    INT NOT NULL,
    book_id      INT NOT NULL,
    borrowed_on  DATE NOT NULL,
    returned_on  DATE,
    FOREIGN KEY (member_id) REFERENCES members(member_id),
    FOREIGN KEY (book_id) REFERENCES books(book_id)
);

9. Haeufige Modellierungsfehler

Der haeufigste Fehler in der Datenmodellierung ist, ein Attribut zu einer eigenen Entitaet zu machen, obwohl es keine eigene Identitaet und keine eigenen Beziehungen zu anderen Entitaeten hat. Eine Buchgattung wie "Roman" oder "Sachbuch" ist meist nur ein Attribut, keine eigene Entitaet, es sei denn, das System muss Gattungen mit eigenen Eigenschaften wie einer Beschreibung oder einem verantwortlichen Lektorat verwalten. Die Testfrage: Braucht dieses Konzept einen eigenen Primaerschluessel und eigene Attribute, oder reicht ein einzelner Wert in einer Spalte der uebergeordneten Entitaet.

Ein zweiter haeufiger Fehler ist, eine n:m-Beziehung faelschlich als 1:n zu modellieren, weil zum Zeitpunkt der Modellierung nur ein einziges Beispiel pro Seite bekannt ist. Ein Buch hat "meistens" einen Autor, also wird die Beziehung als 1:n modelliert, bis ein Buch mit zwei Co-Autoren auftaucht und das Schema nachtraeglich umgebaut werden muss. Die Faustregel: Bei jeder Beziehung explizit fragen, ob "genau einer" wirklich fachlich garantiert ist oder nur der haeufigste Fall im aktuellen Datenbestand. Ein dritter Fehler ist, Fremdschluessel-Spalten ohne NOT NULL zu belassen, obwohl die Kardinalitaet im Diagramm eine verpflichtende Beziehung zeigt, was die im ER-Diagramm sorgfaeltig dokumentierte Kardinalitaet im finalen Schema wieder verwaessert.

10. Zusammenfassung

Datenmodellierung mit Entity-Relationship-Diagrammen trennt bewusst die konzeptionelle Frage "was gibt es in dieser Fachdomaene und wie haengt es zusammen" von der technischen Frage "wie sieht die konkrete Tabelle aus". Entitaeten werden zu Tabellen, Attribute zu Spalten, Beziehungen zu Fremdschluesseln, und die Kardinalitaet einer Beziehung entscheidet, auf welcher Seite der Fremdschluessel landet und ob eine Zwischentabelle noetig ist. Die Crow's-Foot-Notation macht dabei auf einen Blick sichtbar, ob eine Beziehung optional oder verpflichtend ist.

Der groesste praktische Nutzen der Datenmodellierung zeigt sich nicht beim ersten Entwurf, sondern bei spaeteren Anforderungsaenderungen: Ein sauber gepflegtes ER-Diagramm macht sofort sichtbar, welche Kardinalitaet sich aendert und welche Tabellen betroffen sind, statt dass diese Erkenntnis erst beim Debuggen einer kaputten Abfrage entsteht. Wer Entitaeten, Attribute und Beziehungen konsequent vor der Implementierung durchdenkt, spart in wachsenden Systemen erheblichen Migrationsaufwand.

11. FAQ: Entity-Relationship-Grundlagen der Datenmodellierung