Eine Datenbank wirkt oft erst dann kompliziert, wenn Tabellen, Schlüssel und Beziehungen gleichzeitig im Raum stehen. Ein sauber geplantes Entity-Relationship-Modell bringt Ordnung hinein und zeigt, welche Daten gespeichert werden, wie sie zusammenhängen und welche Regeln gelten. Ich zeige dir, wie du ein ER-Modell erstellen kannst, Kardinalitäten korrekt bestimmst und das Ergebnis anschließend in ein belastbares relationales Datenbankschema überführst.
Ein gutes ER-Modell macht Datenstrukturen früh sichtbar
- Entitäten beschreiben wichtige Objekte wie Kunden, Bestellungen oder Artikel.
- Attribute halten die Eigenschaften dieser Objekte fest.
- Kardinalitäten zeigen, wie viele Objekte miteinander verbunden sein dürfen.
- Eine m:n-Beziehung wird in relationalen Datenbanken meist durch eine zusätzliche Zwischentabelle aufgelöst.
- Die Prüfung mit konkreten Beispieldaten deckt Modellierungsfehler früh auf.
So lässt sich ein ER-Modell erstellen
Ein ER-Modell ist die fachliche Skizze einer Datenbank. Es beschreibt zunächst, was gespeichert werden soll und wie die Informationen zusammengehören. Technische Details wie konkrete SQL-Datentypen oder Indizes kommen erst später.
Ich arbeite dabei mit drei Grundbausteinen. Eine Entität ist ein unterscheidbares Objekt, etwa ein Kunde. Ein Attribut beschreibt eine Eigenschaft dieses Objekts, zum Beispiel Name oder E-Mail-Adresse. Eine Beziehung erklärt, wie Entitäten miteinander verbunden sind, etwa „Kunde gibt Bestellung auf“.
| Baustein | Leitfrage | Beispiel |
|---|---|---|
| Entität | Was soll eindeutig gespeichert werden? | Kunde |
| Attribut | Welche Eigenschaften sind relevant? | Kunden-ID, Name, E-Mail |
| Beziehung | Wie hängen Objekte fachlich zusammen? | Kunde gibt Bestellung auf |
| Kardinalität | Wie viele Objekte dürfen beteiligt sein? | Ein Kunde hat null bis viele Bestellungen |
Entitäten nicht mit einzelnen Datensätzen verwechseln
„Kunde“ ist ein Entitätstyp, während „Kunde mit der ID 1042“ eine konkrete Entität beziehungsweise ein Datensatz ist. Diese Unterscheidung ist wichtig, weil das Diagramm die Struktur für viele Datensätze beschreibt, nicht nur für einen einzelnen Fall.
In der Praxis nehme ich nur Objekte auf, die für den vorgesehenen Anwendungsfall wirklich gebraucht werden. Ein Onlineshop benötigt beispielsweise Kunden, Bestellungen und Artikel. Die Lieblingsfarbe eines Kunden gehört dagegen nur dann ins Modell, wenn sie für Prozesse oder Auswertungen tatsächlich eine Rolle spielt.
Vom Fachtext zum Diagramm in sechs sauberen Schritten
Ein ER-Diagramm sollte nicht aus dem Bauch heraus entstehen. Ich beginne immer mit den Geschäftsregeln und übersetze erst danach die Sprache des Fachbereichs in Entitäten, Attribute und Beziehungen.
- Anwendungsbereich festlegen: Schreibe in ein bis drei Sätzen auf, welchen Ausschnitt die Datenbank abbilden soll. Eine Lagerverwaltung braucht andere Informationen als ein CRM-System.
- Substantive markieren: In einer Anforderungsbeschreibung sind Substantive oft gute Kandidaten für Entitäten. Aus „Kunden bestellen Artikel“ können Kunde, Bestellung und Artikel entstehen.
- Attribute ergänzen: Sammle nur Eigenschaften, die zum jeweiligen Objekt gehören. Eine Bestellnummer gehört zur Bestellung, nicht zum Kunden.
- Primärschlüssel bestimmen: Jede Entität braucht ein Attribut oder eine Attributkombination, die jeden Datensatz eindeutig identifiziert. Meist verwende ich eine stabile ID.
- Beziehungen formulieren: Beschreibe jede Verbindung als Verb, zum Beispiel „Kunde gibt Bestellung auf“ oder „Artikel ist Bestandteil einer Bestellung“.
- Kardinalitäten prüfen: Lege fest, ob eine Beziehung zwingend oder optional ist und wie viele Objekte auf jeder Seite erlaubt sind.
Der wichtigste Schritt ist für mich die Formulierung der Regeln in ganzen Sätzen. „Ein Kunde kann mehrere Bestellungen haben“ ist präziser als eine schnell gezeichnete Linie. Aus solchen Sätzen lassen sich Optionalität und Kardinalität deutlich zuverlässiger ableiten.
Attribute auf fachliche Bedeutung prüfen
Ein gutes Attribut enthält möglichst einen klaren Wert. Statt eines Feldes „Adresse“ mit Straße, Hausnummer, Postleitzahl und Ort in einem langen Text können getrennte Attribute sinnvoll sein, wenn später nach Ort oder Postleitzahl gefiltert werden soll.
Mehrere Werte in einer Spalte sind ein Warnsignal. Eine Liste wie „Telefonnummern = 030..., 017...“ lässt sich nur schwer prüfen und auswerten. In diesem Fall ist eine eigene Entität „Telefonnummer“ oft die sauberere Lösung.
Kardinalitäten richtig lesen und auflösen
Die Kardinalität beschreibt, wie viele Entitäten an einer Beziehung beteiligt sein dürfen. In der Chen-Notation werden häufig 1:1, 1:n und m:n verwendet. In Crow’s-Foot-Diagrammen zeigen Symbole zusätzlich, ob eine Beziehung optional ist.
| Beziehung | Bedeutung | Typisches Beispiel | Relationale Umsetzung |
|---|---|---|---|
| 1:1 | Ein Objekt gehört höchstens zu einem Objekt der anderen Seite. | Person und Reisepass | Fremdschlüssel in einer der beiden Tabellen |
| 1:n | Ein Objekt kann mit vielen Objekten verbunden sein. | Kunde und Bestellung | Fremdschlüssel auf der n-Seite |
| m:n | Viele Objekte stehen mit vielen Objekten in Beziehung. | Bestellung und Artikel | Zusätzliche Zwischentabelle |
Die Zahlen allein reichen nicht immer aus. Zwischen „0 und n“ sowie „1 und n“ liegt fachlich ein großer Unterschied. Ein Kunde darf beispielsweise keine Bestellung haben, eine Bestellung muss aber immer genau einem Kunden zugeordnet sein.
Bei einer m:n-Beziehung entsteht in der relationalen Datenbank eine Zwischentabelle. Sie kann außerdem eigene Attribute besitzen. Bei einer Bestellung und ihren Artikeln wären das etwa Menge, Einzelpreis und Rabatt. Diese Werte gehören nicht ausschließlich zur Bestellung oder zum Artikel, sondern zur konkreten Kombination aus beiden.
Die richtige Frage für jede Seite
Ich lese eine Beziehung immer in beide Richtungen. „Ein Auftrag enthält mehrere Positionen“ beantwortet nur die eine Seite. Danach muss ich fragen, ob eine Position zu genau einem Auftrag gehört oder auch mehreren Aufträgen zugeordnet werden darf. Erst beide Antworten ergeben eine belastbare Kardinalität.
Ein durchgängiges Beispiel mit Kunde, Bestellung und Artikel
Schauen wir uns einen kleinen Onlineshop an. Ein Kunde kann mehrere Bestellungen aufgeben. Jede Bestellung gehört genau einem Kunden. Eine Bestellung enthält mindestens einen Artikel, und ein Artikel kann in vielen Bestellungen vorkommen.
Damit ergeben sich zunächst drei Entitäten und eine zusätzliche Entität für die m:n-Beziehung:
- Kunde: kunden_id, name, e_mail
- Bestellung: bestell_id, bestelldatum, status, kunden_id
- Artikel: artikel_id, bezeichnung, aktueller_preis
- Bestellposition: bestell_id, artikel_id, menge, einzelpreis
Die Bestellposition ist mehr als eine technische Hilfstabelle. Sie hält fest, welcher Artikel in welcher Bestellung enthalten war. Der aktuelle Artikelpreis kann sich später ändern, deshalb sollte der zum Kaufzeitpunkt gültige Einzelpreis in der Position gespeichert werden.
| Tabelle | Primärschlüssel | Wichtige Fremdschlüssel |
|---|---|---|
| Kunde | kunden_id | keine |
| Bestellung | bestell_id | kunden_id |
| Artikel | artikel_id | keine |
| Bestellposition | bestell_id + artikel_id | bestell_id, artikel_id |
Die zusammengesetzte Schlüsselstruktur der Bestellposition verhindert, dass derselbe Artikel innerhalb derselben Bestellung versehentlich doppelt als separate Position angelegt wird. Alternativ kann die Position eine eigene positions_id erhalten. Dann sollte zusätzlich eine Eindeutigkeitsregel für bestell_id und artikel_id gelten, sofern doppelte Positionen fachlich nicht erlaubt sind.
Vom ER-Diagramm zu Tabellen und SQL
Das ER-Modell beschreibt die fachliche Struktur. Für die Implementierung wird es in Tabellen, Spalten, Primärschlüssel und Fremdschlüssel übersetzt. Ich behandle diesen Schritt als Kontrollpunkt, weil dabei unklare Beziehungen sofort auffallen.
- Für jeden starken Entitätstyp entsteht normalerweise eine eigene Tabelle.
- Bei einer 1:n-Beziehung kommt der Primärschlüssel der 1-Seite als Fremdschlüssel in die n-Tabelle.
- Eine m:n-Beziehung wird durch eine Zwischentabelle mit mindestens zwei Fremdschlüsseln ersetzt.
- Beziehungsattribute werden dort gespeichert, wo die Beziehung technisch abgebildet wird.
- Pflichtfelder, Eindeutigkeit und Löschregeln werden als Integritätsbedingungen festgelegt.
Ein vereinfachter Ausschnitt könnte so aussehen:
CREATE TABLE Bestellung (
bestell_id INTEGER PRIMARY KEY,
kunden_id INTEGER NOT NULL,
bestelldatum DATE NOT NULL,
status VARCHAR(30) NOT NULL,
FOREIGN KEY (kunden_id) REFERENCES Kunde(kunden_id)
);
CREATE TABLE Bestellposition (
bestell_id INTEGER NOT NULL,
artikel_id INTEGER NOT NULL,
menge INTEGER NOT NULL,
einzelpreis DECIMAL(10,2) NOT NULL,
PRIMARY KEY (bestell_id, artikel_id),
FOREIGN KEY (bestell_id) REFERENCES Bestellung(bestell_id),
FOREIGN KEY (artikel_id) REFERENCES Artikel(artikel_id)
);Die konkreten Datentypen hängen vom verwendeten Datenbanksystem ab. Für Geldbeträge nutze ich grundsätzlich einen exakten Dezimaltyp und keine Gleitkommazahl, weil Rundungsfehler bei Rechnungen problematisch werden können.
Lesen Sie auch: Eclipse Dataspace Connector - Souveräner Datenaustausch erklärt
Normalisierung als Plausibilitätsprüfung
Normalisierung soll unnötige Redundanzen und widersprüchliche Daten vermeiden. Wenn die Kundenadresse in jeder Bestellung vollständig wiederholt wird, müsste eine Adressänderung an vielen Stellen nachgezogen werden. Das ist ein typischer Hinweis auf eine ungünstige Struktur.
Eine normalisierte Datenbank ist aber nicht automatisch für jede Auswertung optimal. Für umfangreiche Analysen können bewusst vorberechnete Tabellen oder Datenmodelle sinnvoll sein. Im operativen System würde ich jedoch erst für klare fachliche Regeln und konsistente Daten sorgen und erst danach über Performance-Optimierungen nachdenken.
Typische Fehler, die später teuer werden
Die meisten Probleme entstehen nicht durch fehlende Diagrammkenntnisse, sondern durch unklare Annahmen. Ein Modell kann grafisch ordentlich aussehen und trotzdem fachlich falsche Aussagen enthalten.
- Zu früh Tabellen zeichnen: Wer sofort Spalten anlegt, übersieht häufig Beziehungen oder modelliert technische Details, bevor die Fachlogik geklärt ist.
- m:n-Beziehungen direkt stehen lassen: Relationale Datenbanken brauchen dafür normalerweise eine Zwischentabelle.
- Falsche Kardinalität: „Ein Kunde hat eine Bestellung“ kann bedeuten, dass genau eine oder beliebig viele Bestellungen erlaubt sind. Die Geschäftsregel muss das eindeutig klären.
- Redundante Attribute: Derselbe Wert sollte nicht ohne guten Grund in mehreren Entitäten gespeichert werden.
- Ungeeignete Schlüssel: Namen, E-Mail-Adressen oder Artikelnummern können sich ändern. Ein stabiler künstlicher Schlüssel ist oft robuster.
- Beziehungen ohne Verb: Eine Linie zwischen zwei Kästen erklärt wenig. Die Beziehung sollte sich als verständlicher Satz lesen lassen.
Zum Schluss teste ich das Modell mit mindestens fünf realistischen Szenarien. Dazu gehören ein neuer Kunde, ein Kunde ohne Bestellung, eine Bestellung mit mehreren Artikeln, ein gelöschter Artikel und eine Änderung historischer Preise. Wenn sich diese Fälle nicht eindeutig abbilden lassen, ist das Modell noch nicht fertig.
Auch Grenzfälle gehören dazu. Darf eine Bestellung ohne Position gespeichert werden? Was passiert beim Löschen eines Kunden? Soll ein Artikel, der bereits verkauft wurde, wirklich gelöscht oder nur als inaktiv markiert werden? Solche Entscheidungen gehören in die Modellierung, nicht erst in den Programmcode.
Ein guter Testfall zeigt, ob das Modell wirklich trägt
Ein belastbares ER-Modell muss nicht besonders groß sein. Es muss die fachlichen Regeln eindeutig ausdrücken, unnötige Wiederholungen vermeiden und sich ohne Verrenkungen in Tabellen überführen lassen.
- Jede Entität hat einen eindeutigen Schlüssel.
- Jede Beziehung lässt sich als klarer Satz formulieren.
- Optionalität und maximale Anzahl sind auf beiden Seiten geprüft.
- m:n-Beziehungen besitzen eine passende Zwischentabelle.
- Historische Werte werden nicht versehentlich durch aktuelle Werte überschrieben.
Mein wichtigster Praxistipp lautet deshalb, das Diagramm nicht nur anzuschauen, sondern mit echten Beispielsätzen und Grenzfällen zu lesen. Wenn ein fachlicher Prozess dabei ohne Zusatzannahmen abgebildet werden kann, ist die Grundlage für eine stabile Datenbank und verlässliche Datenanalyse gelegt.
