In Klasse 9 hast du gelernt, eine fertige Datenbank abzufragen. Jetzt geht es einen Schritt zurück: Wie entwirft man eine Datenbank? Und wie erkennt man, ob ein Entwurf gut oder schlecht ist?
Dieses Modul behandelt zwei grundlegende Themen der Datenbanktheorie, die auch klausurrelevant sind:
Entity-Relationship-Modell: Entitäten, Attribute, Beziehungen, Kardinalitäten (1:1, 1:n, n:m). Wie beschreibt man die reale Welt als Datenbankschema?
1NF, 2NF, 3NF: Wie erkennt man Redundanzen und Anomalien in Tabellen — und wie behebt man sie durch Zerlegung?
Am Ende von N erkennst du: Das normalisierte Schema ist genau die Datenbank, mit der du in Modul 01–03 gearbeitet hast.
Das Entity-Relationship-Modell (ERM) beschreibt, welche Dinge (Entitäten) in einer Datenbank gespeichert werden, welche Eigenschaften (Attribute) sie haben, und wie sie miteinander in Beziehung stehen.
Entität = ein eindeutig identifizierbares Objekt der realen Welt (z.B. ein Schüler, ein Buch)
Attribut = eine Eigenschaft einer Entität (z.B. Name, Geburtsdatum)
Primärschlüssel = das Attribut, das eine Entität eindeutig identifiziert (unterstrichen)
Beziehung = eine Verknüpfung zwischen zwei Entitäten (z.B. „tätigt" zwischen Schüler und Ausleihe)
Bevor wir modellieren, legen wir die Regeln fest:
① Ein Schüler kann mehrere Ausleihen haben (zu verschiedenen Zeitpunkten)
② Jede Ausleihe bezieht sich auf genau ein Buch
③ Ein Buch existiert als ein einziges Exemplar — es kann zu einem Zeitpunkt nur in einer aktiven Ausleihe sein
④ Daraus folgt: kein n:m zwischen Schüler und Buch — stattdessen zwei 1:n-Beziehungen über die Ausleihe
ER-Diagramm der Schulbibliothek · Ausleihe in der Mitte · zwei 1:n-Beziehungen · kein n:m
Klicke auf eine Karte, um die Definition zu sehen:
1:1 — einer Entität auf der linken Seite entspricht genau eine auf der rechten (selten)
1:n — einer Entität links entsprechen mehrere rechts; aber jede rechts gehört zu genau einer links
n:m — mehrere links entsprechen mehreren rechts (benötigt Zwischentabelle)
Bestimme die Kardinalität der folgenden Beziehungen:
Ein Schüler kann mehrere Bücher ausleihen. Jede Ausleihe gehört zu genau einem Schüler.
Ein Schüler kann viele Bücher ausleihen. Ein Buch kann von vielen Schülern (nacheinander) ausgeliehen werden.
Jeder Schüler hat genau einen Schülerausweis. Jeder Ausweis gehört zu genau einem Schüler.
Ein Autor kann viele Bücher geschrieben haben. Jedes Buch hat in unserem Schema genau einen Autor.
Ein Lehrer unterrichtet viele Klassen. Eine Klasse hat viele Lehrer.
Jedes Land hat genau eine Hauptstadt. Jede Hauptstadt gehört zu genau einem Land.
Jeder Entitätstyp wird zu einer Tabelle. Der Primärschlüssel wird übernommen.
Bei 1:n: Der Fremdschlüssel wandert auf die n-Seite (z.B. SchuelerID in Ausleihe).
Bei n:m: Es entsteht eine neue Zwischentabelle mit den Primärschlüsseln beider Seiten als zusammengesetztem Primärschlüssel.
Ordne den ER-Konzepten die richtige SQL-Entsprechung zu. Klicke zuerst links, dann rechts:
Eine schlecht entworfene Datenbank hat Redundanzen — dieselbe Information steht mehrfach drin. Das führt zu Anomalien:
Einfügeanomalie — man kann einen Datensatz nicht einfügen, ohne andere Daten zu erfinden
Änderungsanomalie — ändert man einen Wert, muss man ihn an vielen Stellen ändern
Löschanomalie — löscht man einen Datensatz, verliert man unbeabsichtigt andere Informationen
Die Normalformen sind Regeln, die sicherstellen, dass eine Tabelle gut strukturiert ist.
Für die Normalisierung erweitern wir die Spielregeln: Ein Schüler kann jetzt mehrere Bücher gleichzeitig ausleihen. Das macht das Modell realistischer — und zeigt, warum eine naive Tabelle schnell an ihre Grenzen stößt.
Ein Bibliotheksmitarbeiter erfasst Ausleihen in Excel — so wie es ihm natürlich erscheint: eine Zeile pro Ausleihe, alle ausgeliehenen Bücher kommagetrennt in einer Zelle. Keine IDs, keine Nummern, einfach drauflosgetippt.
Die roten Felder enthalten Listen — mehrere Werte in einer Zelle. Das ist das Problem.
| AusleihNr | Datum | Schüler | Klasse | Bücher | Rückgabedatum |
|---|---|---|---|---|---|
| 2001 | 12.04.2026 | Anna Weber | 7a | Tschick, Krabat | 26.04.2026 |
| 2002 | 13.04.2026 | Ben Klein | 8b | Die Welle | 27.04.2026 |
| 2003 | 14.04.2026 | Clara Neumann | 7a | Momo; Tintenherz | 28.04.2026 |
Die Spalte Bücher enthält mehrere Werte in einer Zelle — sie ist nicht atomar. Das führt zu konkreten Problemen:
• Wie findet man alle Ausleihen des Buches „Krabat"? Man müsste jeden Zellinhalt manuell durchsuchen.
• Was wenn ein Buch einen Preis bekommt? Man kann ihn nicht eindeutig einer Zeile zuordnen.
• Wie zählt man, wie oft „Tschick" ausgeliehen wurde? Unmöglich mit SQL.
→ Lösung: 1NF — jede Zelle darf nur einen Wert enthalten.
Anna Weber gibt beide Bücher am 26.04. zurück. Was passiert, wenn sie eine Verlängerung bekommt? Das Rückgabedatum steht in beiden Zeilen — man muss es an zwei Stellen ändern. Vergisst man eine, sind die Daten widersprüchlich.
Ein neues Buch soll in die Bibliothek aufgenommen werden — es wurde noch nie ausgeliehen. Wo trägt man es ein? Es gibt keine Zeile ohne Ausleihe. Man kann das Buch nicht erfassen, ohne eine Ausleihe zu erfinden.
Ben Klein gibt „Die Welle" zurück und die Ausleihe wird gelöscht. Damit verschwindet auch die Information, dass Ben Klein in der 8b ist — obwohl er noch Schüler ist. Löscht man eine Ausleihe, verliert man Schülerdaten.
Eine Tabelle ist in 1NF, wenn alle Attributwerte atomar sind — nicht weiter zerlegbar, keine Listen, keine Wiederholungsgruppen.
Was wir tun: Jedes Buch bekommt eine eigene Zeile. Eine Ausleihe mit zwei Büchern ergibt zwei Zeilen — mit derselben AusleihNr.
| AusleihNr ¹ | Datum | Schüler | Klasse | Buch ² | Rückgabedatum |
|---|---|---|---|---|---|
| 2001 | 12.04.2026 | Anna Weber | 7a | Tschick | 26.04.2026 |
| 2001 | 12.04.2026 | Anna Weber | 7a | Krabat | 26.04.2026 |
| 2002 | 13.04.2026 | Ben Klein | 8b | Die Welle | 27.04.2026 |
| 2003 | 14.04.2026 | Clara Neumann | 7a | Momo | 28.04.2026 |
| 2003 | 14.04.2026 | Clara Neumann | 7a | Tintenherz | 28.04.2026 |
¹² = zusammengesetzter Schlüssel (AusleihNr, Buch) · Rot = redundante Wiederholung — dieselben Werte stehen mehrfach
Die Mehrfachwerte in Bücher wurden aufgelöst. Jetzt steht pro Zelle nur ein Wert — 1NF ist erfüllt.
Der zusammengesetzte Schlüssel ist (AusleihNr, Buch). Aber:
• Datum, Schüler, Klasse, Rückgabedatum hängen nur von AusleihNr ab — nicht vom Buch.
• Deshalb stehen diese Werte mehrfach in der Tabelle (rot markiert).
• Ändert sich z.B. das Rückgabedatum von Ausleihe 2001, muss man zwei Zeilen anpassen. Vergisst man eine, sind die Daten inkonsistent.
→ Das verletzt die 2NF. Lösung: Tabellen aufteilen.
Eine Tabelle ist in 2NF, wenn jedes Nicht-Schlüssel-Attribut voll funktional abhängig vom gesamten Schlüssel ist — nicht nur von einem Teil.
Was wir tun: Wir trennen Ausleihdaten von den ausgeliehenen Büchern in zwei Tabellen. Dabei führen wir numerische IDs ein — Texte als Schlüssel sind fehleranfällig.
AUSLEIHE
| AusleihNr | Datum | Schüler | Klasse | Rückgabedatum |
|---|---|---|---|---|
| 2001 | 12.04.2026 | Anna Weber | 7a | 26.04.2026 |
| 2002 | 13.04.2026 | Ben Klein | 8b | 27.04.2026 |
| 2003 | 14.04.2026 | Clara Neumann | 7a | 28.04.2026 |
⚠ Gelb: Klasse hängt vom Schüler ab, nicht von AusleihNr — transitive Abhängigkeit.
AUSLEIHPOSITION
| AusleihNr | Buch |
|---|---|
| 2001 | Tschick |
| 2001 | Krabat |
| 2002 | Die Welle |
| 2003 | Momo |
| 2003 | Tintenherz |
Die Ausleihdaten (Datum, Schüler, Klasse, Rückgabedatum) wurden von den einzelnen Büchern getrennt. In AUSLEIHPOSITION steht nur noch, welche Bücher zu welcher Ausleihe gehören — 2NF ist erfüllt.
In der Tabelle AUSLEIHE gilt:
AusleihNr → Schüler → Klasse
Die Klasse hängt nicht direkt von der AusleihNr ab — sie hängt vom Schüler ab. Anna Weber ist immer in 7a, egal bei welcher Ausleihe. Wenn Anna in die 8a versetzt wird, müssen alle ihre Ausleihen geändert werden.
Außerdem: Buchtitel stehen mehrfach in AUSLEIHPOSITION. Sobald man Autor oder ISBN ergänzt, stünden Buchdaten redundant in jeder Zeile.
→ Das verletzt die 3NF. Lösung: Schüler und Bücher in eigene Tabellen auslagern.
Warum hängt Rückgabedatum in der Tabelle AUSLEIHE voll von AusleihNr ab?
Eine Tabelle ist in 3NF, wenn kein Nicht-Schlüssel-Attribut transitiv vom Primärschlüssel abhängt — d.h. kein Nicht-Schlüssel-Attribut darf von einem anderen Nicht-Schlüssel-Attribut bestimmt werden.
Was wir tun: Schülerdaten und Buchdaten werden in eigene Tabellen ausgelagert. In AUSLEIHE und AUSLEIHPOSITION stehen danach nur noch Fremdschlüssel.
SCHÜLER ✓ NEU
| SchülerNr | Name | Klasse |
|---|---|---|
| S1 | Anna Weber | 7a |
| S2 | Ben Klein | 8b |
| S3 | Clara Neumann | 7a |
Name und Klasse stehen genau einmal. Wird eine Klasse geändert, reicht eine Zeile.
BUCH ✓ NEU
| BuchNr | Titel | Autor |
|---|---|---|
| B1 | Tschick | Wolfgang Herrndorf |
| B2 | Krabat | Otfried Preußler |
| B3 | Die Welle | Morton Rhue |
| B4 | Momo | Michael Ende |
| B5 | Tintenherz | Cornelia Funke |
Buchdaten stehen genau einmal. Autor, Erscheinungsjahr, ISBN können einfach ergänzt werden.
AUSLEIHE ✓ BEREINIGT
| AusleihNr | Datum | SchülerNr | Rückgabedatum |
|---|---|---|---|
| 2001 | 12.04.2026 | S1 | 26.04.2026 |
| 2002 | 13.04.2026 | S2 | 27.04.2026 |
| 2003 | 14.04.2026 | S3 | 28.04.2026 |
Statt Name und Klasse steht hier nur noch SchülerNr als Fremdschlüssel.
AUSLEIHPOSITION ✓ BEREINIGT
| AusleihNr | BuchNr |
|---|---|
| 2001 | B1 |
| 2001 | B2 |
| 2002 | B3 |
| 2003 | B4 |
| 2003 | B5 |
Statt Buchtitel steht hier nur noch BuchNr als Fremdschlüssel.
Die transitive Kette AusleihNr → Schüler → Klasse wurde aufgelöst: Schülerdaten haben eine eigene Tabelle. Die redundanten Buchtitel in AUSLEIHPOSITION wurden durch Fremdschlüssel ersetzt.
Jetzt gilt:
SchülerNr → Name, Klasse
BuchNr → Titel, Autor
AusleihNr → Datum, SchülerNr, Rückgabedatum
(AusleihNr, BuchNr) → einzelne Ausleihposition
Kein Attribut hängt mehr indirekt von einem Schlüssel ab. 3NF ist erfüllt.
| Normalform | Problem vorher | Änderung |
|---|---|---|
| 0NF | Mehrere Bücher in einer Zelle | Bücher in einzelne Zeilen aufteilen |
| 1NF | Ausleihdaten hängen nur von AusleihNr ab, nicht vom ganzen Schlüssel | Ausleihe und Ausleihposition trennen |
| 2NF | Klasse hängt von Schüler ab; Buchtitel mehrfach | Schüler und Bücher in eigene Tabellen auslagern |
| 3NF | Keine transitiven Abhängigkeiten mehr | Struktur ist sauber normalisiert ✓ |
Eine Tabelle hat den zusammengesetzten Schlüssel (BestellNr, ProduktNr). Das Attribut Produktname hängt nur von ProduktNr ab. Welche Normalform ist verletzt?
ENDERGEBNIS IN 3NF
Schüler(SchülerNr, Name, Klasse)
Buch(BuchNr, Titel, Autor)
Ausleihe(AusleihNr, Datum, SchülerNr, Rückgabedatum)
Ausleihposition(AusleihNr, BuchNr)
Kein Attribut hängt mehr indirekt von einem Schlüssel ab. Keine Redundanz. Keine Anomalien.
Du hast die Blöcke M (ER-Modell) und N (Normalisierung) bearbeitet. Hier ist dein Ergebnis:
M · ER-MODELL
N · NORMALISIERUNG
Weiter in Modul 05: LEFT JOIN · GROUP BY · HAVING