Bevor eine einzige Tabelle in einer Datenbank angelegt wird, sollte ein Datenmodell stehen. Das wichtigste Werkzeug dafür ist das Entity-Relationship-Diagramm (ERD) – eine visuelle Landkarte deiner Daten und ihrer Beziehungen. Ein durchdachtes ERD erspart dir später teure Umbauten und sorgt dafür, dass deine Daten konsistent bleiben. Dieser Ratgeber erklärt die Bausteine eines ER-Diagramms und wie daraus ein sauberes SQL-Schema entsteht.
Die drei Grundbausteine
Ein ER-Diagramm beschreibt einen Ausschnitt der realen Welt mit drei Elementen:
- Entitäten: Die "Dinge", über die du Daten speicherst – etwa
Kunde,BestellungoderProdukt. In der Datenbank wird daraus meist eine Tabelle. - Attribute: Die Eigenschaften einer Entität – beim Kunden zum Beispiel
name,email,geburtsdatum. Daraus werden Spalten. - Beziehungen: Wie Entitäten miteinander verbunden sind – ein Kunde "tätigt" Bestellungen, eine Bestellung "enthält" Produkte.
Genau dieses Modell baust du grafisch mit dem ERD-Editor: Du legst Tabellen mit Spalten an, definierst Schlüssel und Beziehungen und exportierst das fertige Modell direkt als SQL oder JSON – ein schneller Weg vom Konzept zum lauffähigen Schema.
Schlüssel: Primär- und Fremdschlüssel
Damit Datensätze eindeutig identifizierbar und miteinander verknüpfbar sind, brauchst du Schlüssel.
Primärschlüssel
Der Primärschlüssel (Primary Key) identifiziert jeden Datensatz einer Tabelle eindeutig. Häufig ist das eine fortlaufende id. Ein Primärschlüssel darf nie leer (NULL) sein und kommt pro Tabelle nur einmal vor.
Fremdschlüssel
Ein Fremdschlüssel (Foreign Key) ist eine Spalte, die auf den Primärschlüssel einer anderen Tabelle verweist. So entsteht die eigentliche Verbindung: Eine Bestellung speichert die kunde_id und zeigt damit auf den passenden Kunden. Fremdschlüssel sorgen für referentielle Integrität – die Datenbank verhindert, dass eine Bestellung auf einen nicht existierenden Kunden verweist.
Kardinalitäten: 1:1, 1:n und n:m
Die Kardinalität beschreibt, wie viele Datensätze einer Entität mit wie vielen der anderen verbunden sein können. Es gibt drei Grundtypen:
- 1:1 (eins zu eins): Jeder Datensatz auf einer Seite gehört zu höchstens einem auf der anderen – etwa Person zu Reisepass.
- 1:n (eins zu viele): Der häufigste Fall. Ein Kunde hat viele Bestellungen, aber jede Bestellung gehört genau einem Kunden. Umgesetzt wird das per Fremdschlüssel auf der "n"-Seite.
- n:m (viele zu viele): Ein Produkt kann in vielen Bestellungen vorkommen, eine Bestellung kann viele Produkte enthalten. Das lässt sich nicht direkt abbilden – man braucht eine Zwischentabelle (auch Junction- oder Verknüpfungstabelle), die zwei 1:n-Beziehungen daraus macht.
Normalisierung: Redundanz vermeiden
Ein gutes Datenmodell speichert jede Information nur einmal. Die Normalisierung ist ein systematisches Verfahren, um Redundanz und Anomalien zu beseitigen. Die wichtigsten Normalformen:
- 1. Normalform: Jedes Attribut enthält nur einen einzigen, unteilbaren Wert – keine Listen in einer Zelle.
- 2. Normalform: Jedes Nicht-Schlüssel-Attribut hängt vom gesamten Primärschlüssel ab.
- 3. Normalform: Kein Nicht-Schlüssel-Attribut hängt von einem anderen Nicht-Schlüssel-Attribut ab.
In der Praxis reicht die 3. Normalform für die meisten Anwendungen. Gespeichert wird die Stadt zum Beispiel nicht doppelt in jeder Bestellung, sondern einmal beim Kunden – Änderungen müssen dann nur an einer Stelle erfolgen.
Vom ERD zum SQL-Schema
Steht das Diagramm, ist der Schritt zur Datenbank fast mechanisch: Jede Entität wird eine CREATE TABLE-Anweisung, jedes Attribut eine Spalte mit passendem Datentyp, der Primärschlüssel wird als PRIMARY KEY markiert und Beziehungen werden über FOREIGN KEY-Constraints umgesetzt. Wer den generierten SQL-Code anschließend lesbar formatieren möchte, nutzt den SQL Formatter.
Typische Fehler beim Datenmodellieren
- Fehlende Zwischentabellen: n:m-Beziehungen direkt verbinden zu wollen, führt zu Datenchaos.
- Alles in eine Tabelle: Eine riesige "Mega-Tabelle" mit Dutzenden Spalten ist schwer wartbar und voller Redundanz.
- Keine Indizes auf Fremdschlüsseln: macht Joins langsam, sobald die Datenmenge wächst.
- Unklare Benennung: Einheitliche Namenskonventionen (Singular vs. Plural, snake_case) von Anfang an erleichtern die Pflege enorm.
Weitere Werkzeuge für Datenbanken und Entwicklung findest du gebündelt unter kotsch.tech/webtools.
Häufige Fragen
Brauche ich ein ERD für kleine Projekte?
Schon ein grobes Diagramm mit drei, vier Tabellen hilft, Denkfehler vor dem Coden zu finden. Bei wachsenden Projekten wird ein ERD praktisch unverzichtbar.
Was ist der Unterschied zwischen logischem und physischem Modell?
Das logische Modell beschreibt Entitäten und Beziehungen unabhängig von der Datenbank. Das physische Modell ergänzt konkrete Datentypen, Indizes und Engine-Details für ein bestimmtes Datenbanksystem.
Kann ich aus bestehenden Tabellen ein ERD erzeugen?
Ja, viele Werkzeuge können ein vorhandenes Schema per Reverse Engineering einlesen und als Diagramm darstellen – nützlich, um eine fremde Datenbank schnell zu verstehen.