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 entspricht der Datenbank aus Modul 01–03 – bis auf eine Tabelle, die durch das erweiterte Szenario dazukommt.
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.
| AusleiheID | DatumAusleihe | Schüler | Klasse | Bücher | DatumRueckgabe |
|---|---|---|---|---|---|
| 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 |
| 2004 | 02.05.2026 | Anna Weber | 7a | Momo | 16.05.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 wird in die 8a versetzt. Ihre Klasse steht in zwei Zeilen (Ausleihe 2001 und 2004) — man muss sie 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.
Ordne jede Situation der passenden Anomalie zu. Alle Situationen beziehen sich auf die 0NF-Tabelle oben. Pro Situation zählt der erste Klick.
① Der Nachname von Anna Weber war falsch geschrieben. Er muss in Ausleihe 2001 und in Ausleihe 2004 korrigiert werden.
② Ausleihe 2003 wird nach der Rückgabe gelöscht. Danach ist nirgends mehr gespeichert, dass Clara Neumann in der 7a ist.
③ Tim Berg (9c) soll als Leser erfasst werden, hat aber noch nichts ausgeliehen. Es gibt keine Zeile, in die er passt.
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 AusleiheID.
| AusleiheID ¹ | DatumAusleihe | Schüler | Klasse | Buch ² | DatumRueckgabe |
|---|---|---|---|---|---|
| 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 |
| 2004 | 02.05.2026 | Anna Weber | 7a | Momo | 16.05.2026 |
¹² = zusammengesetzter Schlüssel (AusleiheID, 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 (AusleiheID, Buch). Aber:
• DatumAusleihe, Schüler, Klasse, DatumRueckgabe hängen nur von AusleiheID 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.
AUSLEIHE
| AusleiheID | DatumAusleihe | Schüler | Klasse | DatumRueckgabe |
|---|---|---|---|---|
| 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 |
| 2004 | 02.05.2026 | Anna Weber | 7a | 16.05.2026 |
⚠ Gelb: Klasse hängt vom Schüler ab, nicht von AusleiheID — transitive Abhängigkeit.
AUSLEIHPOSITION
| AusleiheID | Buch |
|---|---|
| 2001 | Tschick |
| 2001 | Krabat |
| 2002 | Die Welle |
| 2003 | Momo |
| 2003 | Tintenherz |
| 2004 | Momo |
Die Ausleihdaten (DatumAusleihe, Schüler, Klasse, DatumRueckgabe) 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:
AusleiheID → Schüler → Klasse
Die Klasse hängt nicht direkt von der AusleiheID 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 beide Ausleihen (2001 und 2004) geändert werden.
Außerdem: Buchtitel stehen mehrfach in AUSLEIHPOSITION („Momo“ bei 2003 und 2004). 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 DatumRueckgabe in der Tabelle AUSLEIHE voll von AusleiheID 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. Dabei führen wir IDs als Schlüssel ein (SchuelerID, BuchID) — Texte als Schlüssel sind fehleranfällig. In AUSLEIHE und AUSLEIHPOSITION stehen danach nur noch Fremdschlüssel.
SCHUELER ✓ NEU
| SchuelerID | Name | Klasse |
|---|---|---|
| 1 | Anna Weber | 7a |
| 2 | Ben Klein | 8b |
| 3 | Clara Neumann | 7a |
Name und Klasse stehen genau einmal. Wird eine Klasse geändert, reicht eine Zeile.
BUCH ✓ NEU
| BuchID | Titel | Autor |
|---|---|---|
| 1 | Tschick | Wolfgang Herrndorf |
| 2 | Krabat | Otfried Preußler |
| 3 | Die Welle | Morton Rhue |
| 4 | Momo | Michael Ende |
| 5 | Tintenherz | Cornelia Funke |
Buchdaten stehen genau einmal. Autor, Erscheinungsjahr, ISBN können einfach ergänzt werden.
AUSLEIHE ✓ BEREINIGT
| AusleiheID | DatumAusleihe | SchuelerID | DatumRueckgabe |
|---|---|---|---|
| 2001 | 12.04.2026 | 1 | 26.04.2026 |
| 2002 | 13.04.2026 | 2 | 27.04.2026 |
| 2003 | 14.04.2026 | 3 | 28.04.2026 |
| 2004 | 02.05.2026 | 1 | 16.05.2026 |
Statt Name und Klasse steht hier nur noch SchuelerID als Fremdschlüssel.
AUSLEIHPOSITION ✓ BEREINIGT
| AusleiheID | BuchID |
|---|---|
| 2001 | 1 |
| 2001 | 2 |
| 2002 | 3 |
| 2003 | 4 |
| 2003 | 5 |
| 2004 | 4 |
Statt Buchtitel steht hier nur noch BuchID als Fremdschlüssel.
Die transitive Kette AusleiheID → Schüler → Klasse wurde aufgelöst: Schülerdaten haben eine eigene Tabelle. Die redundanten Buchtitel in AUSLEIHPOSITION wurden durch Fremdschlüssel ersetzt.
Jetzt gilt:
SchuelerID → Name, Klasse
BuchID → Titel, Autor
AusleiheID → DatumAusleihe, SchuelerID, DatumRueckgabe
(AusleiheID, BuchID) → 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 AusleiheID 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
Schueler(SchuelerID, Name, Klasse)
Buch(BuchID, Titel, Autor)
Ausleihe(AusleiheID, DatumAusleihe, SchuelerID, DatumRueckgabe)
Ausleihposition(AusleiheID, BuchID)
Kein Attribut hängt mehr indirekt von einem Schlüssel ab. Keine Redundanz. Keine Anomalien.
Im erweiterten Szenario darf eine Ausleihe mehrere Bücher enthalten – deshalb braucht es die Tabelle AUSLEIHPOSITION.
In der Datenbank aus Modul 01–03 gilt dagegen Geschäftsregel ②: Jede Ausleihe bezieht sich auf genau ein Buch. Dann ist AUSLEIHPOSITION überflüssig – BuchID wandert als Fremdschlüssel direkt in AUSLEIHE (1:n, Fremdschlüssel auf die n-Seite):
Ausleihe(AusleiheID, SchuelerID, BuchID, DatumAusleihe, DatumRueckgabe)
Das ist genau das Schema aus dem ER-Modell in Block M. Die Geschäftsregeln bestimmen, welches Schema bei der Normalisierung herauskommt.
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