Anwendung in der Praxis

Einführung

In jedem Unternehmen – ob Buchhandel, Online-Shop oder Kreativagentur – werden täglich Kundendaten, Bestellungen und Artikel verwaltet. Ohne klare Struktur entsteht schnell Datenchaos: doppelte Einträge, widersprüchliche Informationen oder fehlerhafte Auswertungen.

Von chaotischen Papierstapeln zu strukturierten Datenablagen — Bildrechte: Ausbildung-in-der-IT.de (KI-unterstützt)

Genau hier setzt die Normalisierung an – sie schafft Ordnung in der Datenflut und bildet die Grundlage für saubere, effiziente Datenbanken.

In dieser Lerneinheit lernst du, wie dieser Prozess Schritt für Schritt funktioniert und warum er in der Praxis unverzichtbar ist.

Lernziele

Nach dieser Lerneinheit kannst du:

• typische Datenanomalien erkennen und erklären.
• Tabellen in die 1NF überführen und den minimalen Primärschlüssel bestimmen.
• funktionale Abhängigkeiten analysieren und Tabellen in die 2NF zerlegen.
• transitive Abhängigkeiten identifizieren und die 3NF korrekt herstellen.

Ausgangslage: Die unstrukturierte Bestellliste der „Kreativ&Kompakt GmbH“

Die Problemstellung

Wir beginnen mit der ursprünglichen, nicht normalisierten Tabelle (UNF), in der die „Kreativ&Kompakt GmbH“ ihre Bestellungen erfasst. Diese Tabelle ist ein typisches Beispiel für eine „flache Liste“, wie sie oft am Anfang eines Datenbankprojekts steht – eine einfache, aber hochgradig fehleranfällige Struktur.

Tabelle 1: Rohdaten_Bestellungen (UNF)

BestellNr	Bestelldatum	KundenInfo	Artikel (Menge, ArtNr, ArtBezeichnung, Einzelpreis)	Gesamtpreis
B001	01.03.2024	K17-Schmidt, Jan-Kaiserstr. 5, 53113 Bonn	(200, A10, Block A4, 0.45), (100, A15, Block A5, 0.30)	120.00
B002	01.03.2024	K23-Müller, Eva-Händelstr. 67, 53115 Bonn	(50, A50, Kugelschreiber, 1.40)	70.00
B003	03.03.2024	K17-Schmidt, Jan-Kaiserstr. 5, 53113 Bonn	(100, A10, Block A4, 0.50)	50.00

Analyse der Schwachstellen – Die drei Anomalien

Diese Struktur führt in der Praxis unweigerlich zu Problemen, den sogenannten Anomalien. Bevor wir die Regeln der Normalisierung anwenden, ist es entscheidend zu verstehen, warum diese Regeln existieren. Sie sind die Lösung für konkrete, alltägliche Datenmanagement-Probleme.

• Änderungsanomalie: Kunde Jan Schmidt (K17) zieht um. Um seine Adresse zu aktualisieren, müssen wir jeden einzelnen Datensatz, in dem er vorkommt, aufspüren und manuell ändern. Wird auch nur ein Eintrag übersehen, entstehen inkonsistente Daten – die Datenbank „weiß“ nicht mehr, welche Adresse die richtige ist.
• Einfügeanomalie: Ein neuer Artikel, „Radiergummi“ (A60), soll in den Katalog aufgenommen werden. In dieser Struktur ist das unmöglich, solange der Artikel nicht bestellt wurde. Logisch getrennte Informationen (hier: Artikel) können nicht unabhängig voneinander gespeichert werden.
• Löschanomalie: Kundin Eva Müller storniert ihre einzige Bestellung (B002). Wenn wir diesen Datensatz löschen, gehen nicht nur die Bestelldaten verloren, sondern auch alle Informationen über den Artikel „Kugelschreiber“ (A50). War dies die einzige Bestellung des Artikels, ist er danach komplett aus der Datenbank verschwunden.

Der erste Schritt: Überführung in die 1. Normalform (1NF)

Die erste Normalform (1NF) ist der grundlegende „Aufräumschritt“. Sie hat zwei fundamentale Regeln, um das eben gesehene Chaos zu beseitigen.

Regel 1: Atomarität herstellen

Die 1NF verlangt, dass jeder Attributwert (jede Zelle) atomar, also unteilbar ist. Es darf keine Listen oder Wiederholungsgruppen in einer Zelle geben.

• Auflösung zusammengesetzter Attribute: Die Spalte KundenInfo wird in ihre logischen Bestandteile zerlegt: KundenNr, Kundenname, Strasse, PLZ, Ort.
• Auflösung von Wiederholungsgruppen: Die Spalte Artikel enthält eine Liste von Artikeln. Wir lösen diese auf, indem wir für jeden bestellten Artikel eine eigene Zeile anlegen.
• Entfernung abgeleiteter Attribute: Die Spalte Gesamtpreis wird entfernt, da ihr Wert aus Menge und Einzelpreis berechnet werden kann. Das Speichern berechenbarer Werte führt zu Redundanz und potenziellen Änderungsanomalien.

Nach Anwendung dieser Regel sieht unsere Tabelle wie folgt aus:

Tabelle 1.1: Zwischenschritt nach Herstellung der Atomarität

BestellNr	Bestelldatum	KundenNr	Kundenname	Strasse	PLZ	Ort	ArtikelNr	ArtBezeichnung	Menge	Einzelpreis
B001	01.03.2024	K17	Schmidt, Jan	Kaiserstr. 5	53113	Bonn	A10	Block A4	200	0.45
B001	01.03.2024	K17	Schmidt, Jan	Kaiserstr. 5	53113	Bonn	A15	Block A5	100	0.30
B002	01.03.2024	K23	Müller, Eva	Händelstr. 67	53115	Bonn	A50	Kugelschreiber	50	1.40
B003	03.03.2024	K17	Schmidt, Jan	Kaiserstr. 5	53113	Bonn	A10	Block A4	100	0.50

Regel 2: Eindeutigkeit schaffen – Den Primärschlüssel definieren

Jeder Datensatz in einer Tabelle der 1NF muss durch einen Primärschlüssel eindeutig identifizierbar sein.

• Herleitung des Primärschlüssels: Die BestellNr allein reicht nicht mehr aus, um eine Zeile eindeutig zu identifizieren (siehe B001). Die Kombination aus BestellNr und ArtikelNr ist jedoch eindeutig, da wir annehmen, dass ein Artikel pro Bestellung nur einmal vorkommt (eine höhere Stückzahl wird über Menge abgebildet). Somit wird unser zusammengesetzter Primärschlüssel: $PK = \{BestellNr, ArtikelNr\}$.

• Prüfungstipp AP 2: Der minimale Primärschlüssel In der Prüfung müssen Sie die Wahl des Primärschlüssels begründen. Betonen Sie, dass der Schlüssel minimal sein muss. Ein nicht-minimaler Schlüssel (z.B. {BestellNr, ArtikelNr, KundenNr}) würde die Analyse der funktionalen Abhängigkeiten im nächsten Schritt verfälschen und sicher zu Fehlern bei der Überführung in die 2NF führen. Die korrekte Bestimmung des minimalen Primärschlüssels ist die wichtigste Weichenstellung für den gesamten Prozess.

Das Endergebnis der 1. Normalform:

Tabelle 2: Bestellungen_1NF (Primärschlüssel fett markiert)

BestellNr	ArtikelNr	Bestelldatum	KundenNr	Kundenname	Strasse	PLZ	Ort	ArtBezeichnung	Menge	Einzelpreis
B001	A10	01.03.2024	K17	Schmidt, Jan	Kaiserstr. 5	53113	Bonn	Block A4	200	0.45
B001	A15	01.03.2024	K17	Schmidt, Jan	Kaiserstr. 5	53113	Bonn	Block A5	100	0.30
B002	A50	01.03.2024	K23	Müller, Eva	Händelstr. 67	53115	Bonn	Kugelschreiber	50	1.40
B003	A10	03.03.2024	K17	Schmidt, Jan	Kaiserstr. 5	53113	Bonn	Block A4	100	0.50

Die Tabelle erfüllt nun die Regeln der 1NF. Das Problem der Redundanz ist jetzt aber noch offensichtlicher: Die Kundendaten von Jan Schmidt und die Bezeichnung für „Block A4“ sind mehrfach vorhanden. Dies lösen wir im nächsten Schritt.

Hilfestellung und Self-Check nach der 1. Normalform

• Die Atomaritäts-Prüfung: Schau dir jede einzelne Zelle deiner Tabelle an. Gibt es wirklich nirgendwo mehr Werte, die du logisch trennen könntest (z.B. Vor- und Nachname in einer Zelle)? Stell dir vor, du müsstest die Daten nach jedem einzelnen Informationsteil filtern oder sortieren können. Wenn das geht, sind deine Werte atomar.
• Die Primärschlüssel-Prüfung: Ist dein gewählter Primärschlüssel wirklich minimal? Frag dich: „Könnte ich eine der Spalten aus meinem zusammengesetzten Schlüssel entfernen und die Zeile wäre immer noch eindeutig identifizierbar?“ Wenn die Antwort „Ja“ ist, ist dein Schlüssel noch nicht minimal. Das ist eine der häufigsten Fehlerquellen in der Prüfung!
• Akzeptiere die Redundanz: Deine Tabelle sieht jetzt wahrscheinlich unübersichtlicher aus als vorher, weil sich viele Daten wiederholen. Das ist völlig normal und sogar ein gutes Zeichen! Die 1. Normalform deckt Redundanzen schonungslos auf, die du im nächsten Schritt gezielt beseitigen wirst.

Von der 2NF zur finalen 3NF

Der Weg zur 2. Normalform (2NF)

Funktionale Abhängigkeiten verstehen („The whole key“)

Die zweite Normalform (2NF) hat eine zentrale Anforderung: Jedes Nichtschlüsselattribut muss vom gesamten Primärschlüssel voll funktional abhängig sein. Es darf keine Attribute geben, die nur von einem Teil eines zusammengesetzten Primärschlüssels abhängen. Dieser Schritt trennt die vermischten logischen Konzepte (Entitäten) voneinander.

Wir analysieren unsere Tabelle Bestellungen_1NF systematisch mit der Frage: „Benötige ich zur eindeutigen Bestimmung dieses Attributs sowohl die BestellNr als auch die ArtikelNr, oder reicht ein Teil davon?“

• Abhängig vom gesamten Schlüssel {BestellNr, ArtikelNr}:
  • Menge: Die Menge bezieht sich auf einen bestimmten Artikel in einer bestimmten Bestellung.
  • Einzelpreis: Der Preis kann pro Bestellung variieren (z.B. durch Rabatte), daher hängt er von der Kombination ab.
• Abhängig nur von BestellNr (partielle Abhängigkeit):
  • Bestelldatum, KundenNr, Kundenname, Strasse, PLZ, Ort: All diese Informationen beschreiben die Bestellung als Ganzes, unabhängig vom Artikel.
• Abhängig nur von ArtikelNr (partielle Abhängigkeit):
  • ArtBezeichnung: Die Bezeichnung eines Artikels hängt ausschließlich von seiner Nummer ab.

Umsetzung: Logische Einheiten bilden und auslagern

Wir lagern alle Attribute, die nur von einem Teil des Primärschlüssels abhängen, zusammen mit diesem Teilschlüssel in neue Tabellen aus.

Schritt 1: Auslagerung der Artikeldaten Alle Attribute, die nur von ArtikelNr abhängen, bilden die neue Tabelle Artikel.

Neue Tabelle Artikel

ArtikelNr (PK)	ArtBezeichnung
A10	Block A4
A15	Block A5
A50	Kugelschreiber

Schritt 2: Auslagerung der Bestelldaten Alle Attribute, die nur von BestellNr abhängen, bilden die neue Tabelle Bestellungen.

Neue Tabelle Bestellungen

BestellNr (PK)	Bestelldatum	KundenNr	Kundenname	Strasse	PLZ	Ort
B001	01.03.2024	K17	Schmidt, Jan	Kaiserstr. 5	53113	Bonn
B002	01.03.2024	K23	Müller, Eva	Händelstr. 67	53115	Bonn
B003	03.03.2024	K17	Schmidt, Jan	Kaiserstr. 5	53113	Bonn

Schritt 3: Erstellung der Beziehungstabelle In der Ursprungstabelle verbleiben nur die Attribute, die vom gesamten Schlüssel abhängen. Sie wird zur Beziehungstabelle Bestellpositionen.

Neue Tabelle Bestellpositionen

BestellNr (PK, FK)	ArtikelNr (PK, FK)	Menge	Einzelpreis
B001	A10	200	0.45
B001	A15	100	0.30
B002	A50	50	1.40
B003	A10	100	0.50

• Prüfungstipp AP 2: Die 2NF-Checkliste Die Überführung in die 2NF ist eine häufige Fehlerquelle. Nutze diese Checkliste:
  1. Prüfung: Liegt ein zusammengesetzter Primärschlüssel vor? (Falls nein, ist eine Tabelle in 1NF automatisch auch in 2NF).
  2. Identifikation: Schreibe jeden Teil des Primärschlüssels separat auf.
  3. Zuordnung: Ordnen Sie jedes Nichtschlüsselattribut dem kleinstmöglichen Schlüssel(teil) zu, von dem es funktional abhängt.
  4. Auslagerung: Bilde für jeden Teilschlüssel eine neue Tabelle mit den zugeordneten Attributen.
  5. Beibehaltung: Die Attribute, die vom gesamten Schlüssel abhängen, verbleiben in der (jetzt verkleinerten) Beziehungstabelle.

Das Ergebnis ist die folgende Struktur in der 2. Normalform. Die meisten Redundanzen sind beseitigt, aber die Tabelle Bestellungen enthält immer noch doppelte Kundendaten.

Hilfestellung und Self-Check nach der 2. Normalform

• Die „Ganze Schlüssel“-Prüfung: Nimm jede deiner neuen Tabellen und schau dir die Nichtschlüsselattribute an. Frag dich bei jedem Attribut: „Beschreibt diese Information wirklich den gesamten Primärschlüssel dieser Tabelle oder nur einen Teil davon?“ Jedes Attribut, das nur von einem Teil des Schlüssels abhängt, befindet sich in der falschen Tabelle.
• Hast du eine reine Beziehungstabelle? Typischerweise entsteht bei diesem Schritt eine Tabelle, deren Primärschlüssel nur aus Fremdschlüsseln besteht. Diese Tabelle verknüpft die anderen Tabellen miteinander und enthält nur noch Attribute, die genau diese Verknüpfung beschreiben (z.B. eine Menge oder ein individueller Preis).
• PK-FK-Beziehungen prüfen: Hast du in den neuen Tabellen die Primärschlüssel (PK) korrekt gesetzt? Hast du daran gedacht, die entsprechenden Spalten in den Beziehungstabellen als Fremdschlüssel (FK) zu kennzeichnen? Eine saubere Kennzeichnung ist in der Prüfung entscheidend für die volle Punktzahl.

⏳ Lädt Dataview-Inhalt...

Transitive Abhängigkeiten eliminieren: (3NF)

Die letzte Redundanzquelle aufspüren (Motto: „Nothing but the key“)

Die dritte Normalform (3NF) baut auf der 2NF auf. Die Regel lautet: Kein Nichtschlüsselattribut darf von einem anderen Nichtschlüsselattribut funktional abhängig sein. Eine solche indirekte Abhängigkeit nennt man transitive Abhängigkeit.

Wir prüfen jede Tabelle und fragen: „Beschreiben alle Attribute hier direkt den Primärschlüssel, oder beschreiben sie ein anderes Attribut in der Tabelle?“

In der Tabelle Bestellungen identifizieren wir eine solche Abhängigkeit:

• Die Attribute Kundenname, Strasse, PLZ und Ort beschreiben nicht direkt die Bestellung (BestellNr), sondern den Kunden (KundenNr).
• Die Abhängigkeitskette lautet: BestellNr → KundenNr → Kundenname. Der Kundenname ist also nur transitiv (indirekt) vom Primärschlüssel BestellNr abhängig.

Umsetzung: Finale Auslagerung

Wir lösen die transitive Abhängigkeit auf, indem wir alle Attribute, die den Kunden beschreiben, in eine eigene Tabelle Kunden auslagern. Dieser Prozess erfolgt in zwei logischen Schritten:

Ausgangslage: Die Tabelle Bestellungen nach der 2. Normalform Wir beginnen mit der Tabelle Bestellungen, wie sie am Ende des Schrittes zur 2NF vorliegt. Wichtig ist hier: Die Spalte KundenNr ist zu diesem Zeitpunkt noch ein ganz normales Attribut, das die Bestellung beschreibt. Sie ist noch kein Fremdschlüssel.

BestellNr (PK)	Bestelldatum	KundenNr	Kundenname	Strasse	PLZ	Ort
B001	01.03.2024	K17	Schmidt, Jan	Kaiserstr. 5	53113	Bonn
B002	01.03.2024	K23	Müller, Eva	Händelstr. 67	53115	Bonn
B003	03.03.2024	K17	Schmidt, Jan	Kaiserstr. 5	53113	Bonn

Schritt 1: Erstellung der neuen Kunden-Tabelle

• Was wird gemacht? Wir erstellen eine komplett neue Tabelle namens Kunden. In diese Tabelle verschieben wir alle Spalten, die direkt den Kunden beschreiben (Kundenname, Strasse, PLZ, Ort). Die KundenNr wird in dieser neuen Tabelle zum eindeutigen Primärschlüssel (PK).
• Warum wird das gemacht? Damit schaffen wir einen zentralen Ort für alle Kundeninformationen. Jede Information über einen Kunden (wie seine Adresse) wird nun nur noch ein einziges Mal gespeichert. Dies löst die Redundanz und die damit verbundene Änderungsanomalie auf.

Ergebnis von Schritt 1: Die neue Tabelle Kunden

KundenNr (PK)	Kundenname	Strasse	PLZ	Ort
K17	Schmidt, Jan	Kaiserstr. 5	53113	Bonn
K23	Müller, Eva	Händelstr. 67	53115	Bonn

Umsetzung: Finale Auslagerung

Schritt 2: Bereinigung der Bestellungen-Tabelle

• Was wird gemacht? Wir gehen zurück zur Bestellungen-Tabelle und entfernen die Spalten, die wir gerade in die Kunden-Tabelle ausgelagert haben (Kundenname, Strasse, PLZ, Ort). Die Spalte KundenNr bleibt jedoch erhalten.
• Warum wird das gemacht? Die KundenNr dient nun als Brücke oder Verknüpfung zwischen den beiden Tabellen. Ihre Rolle ändert sich: Sie ist jetzt kein beschreibendes Attribut mehr, sondern ein Fremdschlüssel (FK). Ihre einzige Aufgabe ist es, auf den entsprechenden Datensatz in der Kunden-Tabelle zu verweisen. So weiß die Datenbank, welche Bestellung zu welchem Kunden gehört, ohne alle Kundendetails wiederholen zu müssen.

Ergebnis von Schritt 2: Die bereinigte Tabelle Bestellungen

BestellNr (PK)	Bestelldatum	KundenNr (FK)
B001	01.03.2024	K17
B002	01.03.2024	K23
B003	03.03.2024	K17

Das finale Datenmodell in der 3. Normalform

Nach diesem letzten Schritt ist unser Datenmodell vollständig in die 3. Normalform überführt. Es ist nun redundanzfrei, konsistent und robust.

Tabelle 4: Das Datenmodell in 3NF

Tabelle Kunden

KundenNr (PK)	Kundenname	Strasse	PLZ	Ort
K17	Schmidt, Jan	Kaiserstr. 5	53113	Bonn
K23	Müller, Eva	Händelstr. 67	53115	Bonn

Tabelle Artikel (unverändert aus 2NF)

ArtikelNr (PK)	ArtBezeichnung
A10	Block A4
A15	Block A5
A50	Kugelschreiber

Tabelle Bestellungen (bereinigt)

BestellNr (PK)	Bestelldatum	KundenNr (FK)
B001	01.03.2024	K17
B002	01.03.2024	K23
B003	03.03.2024	K17

Tabelle Bestellpositionen (unverändert aus 2NF)

BestellNr (PK, FK)	ArtikelNr (PK, FK)	Menge	Einzelpreis
B001	A10	200	0.45
B001	A15	100	0.30
B002	A50	50	1.40
B003	A10	100	0.50

Hilfestellung und Self-Check nach der 3. Normalform

• Die „Nichts als der Schlüssel“-Prüfung: Geh jede deiner Tabellen einzeln durch. Schau dir die Nichtschlüsselattribute an. Gibt es eine Spalte, die eine andere Nichtschlüsselspalte beschreibt anstatt des Primärschlüssels? Der klassische Fall ist ein Ort, der nicht direkt von einer Kunden-ID abhängt, sondern von der Postleitzahl. Solche transitiven Abhängigkeiten musst du in eine eigene Tabelle auslagern.
• Jede Tabelle = Ein Konzept: Schau dir deine finalen Tabellen an. Repräsentiert jede Tabelle genau ein reales Konzept (z.B. Kunden, Produkte, Bestellungen)? Wenn eine Tabelle immer noch mehrere Konzepte vermischt, ist sie wahrscheinlich noch nicht in der 3. Normalform.

Fazit

Wir haben eine fehleranfällige Liste in ein robustes Datenmodell in der 3. Normalform überführt. Die Vorteile sind:

• Redundanzfreiheit: Jede Information (z.B. eine Kundenadresse) ist nur einmal gespeichert.
• Datenintegrität: Änderungen müssen nur an einer Stelle vorgenommen werden, was Inkonsistenzen vermeidet.
• Vermeidung von Anomalien: Die Einfüge-, Änderungs- und Löschanomalien sind eliminiert.
• Flexibilität und Wartbarkeit: Das Modell ist leichter zu verstehen, zu pflegen und zu erweitern.

Für die Praxis und die Prüfung ist die 3. Normalform der etablierte Standard. Höhere Normalformen existieren, sind aber nur für Spezialfälle relevant. In manchen Situationen (z.B. Data Warehouses) werden Datenbanken aus Performance-Gründen sogar bewusst „denormalisiert“, um komplexe Abfragen (JOINs) zu beschleunigen.

Abschließender Prüfungstipp AP 2

In der Abschlussprüfung erhalten Sie nicht nur Punkte für das richtige Endergebnis, sondern insbesondere für den nachvollziehbaren Lösungsweg. Eine gute Dokumentation zeigt dem Prüfer, dass Sie den Prozess verstanden haben und sichert Ihnen wertvolle Teilpunkte, selbst wenn ein kleiner Fehler passiert.

Hinweise:

1. Ausgangslage (1NF): Geben Sie die Tabelle in der 1. Normalform an. Bestimmen und begründen Sie den minimalen Primärschlüssel.
2. Übergang zur 2NF: Identifizieren und listen Sie die funktionalen Abhängigkeiten auf. Begründen Sie die Aufteilung der Tabellen mit den gefundenen partiellen Abhängigkeiten.
3. Struktur in 2NF: Zeichnen Sie die neuen Tabellen. Kennzeichnen Sie Primär- (PK) und Fremdschlüssel (FK) eindeutig.
4. Übergang zur 3NF: Benennen Sie die transitive Abhängigkeit, die Sie gefunden haben (z.B. BestellNr → KundenNr → Kundenname).
5. Finale Struktur in 3NF: Präsentieren Sie das endgültige Schema mit allen Tabellen, PKs und FKs. Eine Skizze der Beziehungen kann hier hilfreich sein.

⏳ Lädt Dataview-Inhalt...

Zusammenfassung

Zusammenfassung:

Ausgangslage (UNF) und Anomalien

Die Ausgangstabelle war eine flache Liste mit zusammengefassten Feldern und Wiederholungsgruppen. Diese Struktur erzeugt Änderungs‑, Einfüge‑ und Löschanomalien.

• UNF-Merkmale: Nicht-atomare Felder (KundenInfo), Wiederholungsgruppe Artikel, abgeleitetes Attribut Gesamtpreis.
• Änderungsanomalie: Adressänderung eines Kunden erfordert Mehrfachpflege; Inkonsistenzen drohen.
• Einfügeanomalie: Neue Artikel können ohne Bestellung nicht erfasst werden.
• Löschanomalie: Löschen einer Einzelbestellung kann Artikelwissen verlieren. Zum Start ist klar: Ohne Atomarität und saubere Schlüssel entstehen Redundanzen und Inkonsistenzen.

1. Normalform (1NF): Atomarität und Schlüssel

Ziel der 1NF ist die Atomarität aller Attribute und die eindeutige Identifizierbarkeit jeder Zeile. Listen werden aufgelöst, berechnete Felder entfernt.

• Atomarisierung: Zerlegung von KundenInfo in KundenNr, Kundenname, Strasse, PLZ, Ort.
• Auflösung Wiederholungsgruppe: Aus jedem Artikel in einer Bestellung wird eine eigene Zeile.
• Entfernung abgeleiteter Werte: Gesamtpreis entfällt (berechenbar aus Menge × Einzelpreis).
• Primärschlüssel (minimal): {BestellNr, ArtikelNr}; die Kombination ist eindeutig, Einzelteile sind nicht ausreichend. Nach 1NF sind die Daten strukturiert, Redundanzen sind aber weiter sichtbar (z. B. Kundendaten, Artikelbezeichnungen).

2. Normalform (2NF): Volle Abhängigkeit vom gesamten Schlüssel

In 2NF dürfen Nichtschlüsselattribute nicht nur von einem Teil eines zusammengesetzten Schlüssels abhängen. Teilabhängigkeiten werden ausgelagert.

• Vom Gesamtschlüssel abhängig: Menge, Einzelpreis (positionsspezifisch und je Bestellung variabel).

• Nur von BestellNr abhängig: Bestelldatum, KundenNr, Kundenname, Strasse, PLZ, Ort.

• Nur von ArtikelNr abhängig: ArtBezeichnung.

• Zerlegung:

  • Artikel(**ArtikelNr** PK, ArtBezeichnung)
  • Bestellungen(**BestellNr** PK, Bestelldatum, KundenNr, Kundenname, Strasse, PLZ, Ort)
  • Bestellpositionen(**BestellNr** PK/FK, **ArtikelNr** PK/FK, Menge, Einzelpreis) Damit sind Teilabhängigkeiten beseitigt; Kundendaten liegen jedoch noch doppelt innerhalb Bestellungen vor.

3. Normalform (3NF): Keine transitiven Abhängigkeiten

In 3NF darf kein Nichtschlüsselattribut von einem anderen Nichtschlüsselattribut abhängen. Transitiven Ketten wird durch weitere Auslagerung begegnet.

• Identifizierte Kette: BestellNr → KundenNr → Kundenname/Strasse/PLZ/Ort.
• Auslagerung: Neue Tabelle Kunden(**KundenNr** PK, Kundenname, Strasse, PLZ, Ort).
• Bereinigung: Bestellungen(**BestellNr** PK, Bestelldatum, KundenNr FK). Durch die Trennung ist jede Information genau einmal hinterlegt; KundenNr verknüpft Bestellung und Kunde.

Prüfungsrelevante Hinweise und Checks

Für die AP solltest du zentrale Entscheidungsregeln und Begründungen sicher anwenden. Die folgenden Punkte stützen typische Prüfungsaufgaben.

• Minimaler Primärschlüssel: Begründung, warum {BestellNr, ArtikelNr} minimal und ausreichend ist.
• 2NF-Checkliste: Zusammengesetzten Schlüssel prüfen, Teilabhängigkeiten identifizieren, passende Tabellen bilden, Gesamtschlüssel‑Attribute in der Beziehungstabelle belassen.
• 3NF-Nachweis: Transitive Ketten explizit benennen (z. B. BestellNr → KundenNr → Kundenname) und deren Auflösung begründen. Diese Begründungen bringen Teilpunkte auch bei kleinen Fehlern und zeigen methodische Sicherheit.

---