Dritte Normalform (3NF)
Einführung
Du öffnest eine Artikeltabelle in einer Datenbank und siehst, dass der Lieferantenname und die Stadt in mehreren Zeilen identisch sind. Beim nächsten Update zieht der Lieferant um – und du musst denselben Ort an zehn Stellen ändern. Ein Datensatz bleibt übersehen, und plötzlich stimmen die Daten nicht mehr.
Problem: Obwohl die Tabelle formal in der Zweiten Normalform ist, treten Fehler, Redundanzen und Inkonsistenzen auf. Irgendetwas fehlt noch, um die Struktur wirklich sauber zu machen.
Genau hier setzt die Dritte Normalform (3NF) an. Sie sorgt dafür, dass jede Tabelle nur ein Konzept abbildet und keine Attribute indirekt voneinander abhängen. Du lernst, wie du diese versteckten Abhängigkeiten erkennst, auflöst und so eine wartungsarme, konsistente Datenbankstruktur erreichst.
Lernziele
Nach dieser Lerneinheit kannst du:
- transitive Abhängigkeiten erklären und erkennen – verstehen, wie indirekte Abhängigkeiten entstehen und sie in Tabellen identifizieren.
- die 3NF begründen – prüfen, ob eine Relation in 2NF ist und das 3NF-Kriterium korrekt anwenden.
- Tabellen in die 3NF überführen – abhängige Attribute auslagern und passende Schlüssel definieren.
- Anomalien vermeiden – erklären, wie 3NF Redundanzen beseitigt und Datenintegrität sichert.
Warum die Zweite Normalform nicht ausreicht
In den vorherigen Lerneinheiten haben wir die Grundlagen für eine saubere und effiziente Datenbankstruktur gelegt. Das übergeordnete Ziel der Normalisierung ist es, Redundanzen zu beseitigen, um Datenanomalien zu verhindern und die Datenintegrität sicherzustellen.
Blicken wir kurz auf den Fortschritt, den wir bereits erzielt haben:
- Normalform (1NF): Wir haben sichergestellt, dass alle Datenwerte atomar sind und keine Wiederholungsgruppen existieren. Jede Zeile (jeder Datensatz) ist durch einen Kandidatenschlüssel eindeutig identifizierbar.
Ein Kandidatenschlüssel ist ein minimaler Attributsatz, der jeden Datensatz einer Tabelle eindeutig identifiziert (keine überflüssigen Attribute enthalten). Es kann mehrere Kandidatenschlüssel pro Tabelle geben; einer davon wird als Primärschlüssel ausgewählt. Alle anderen bleiben als Alternativschlüssel möglich und sichern die Eindeutigkeit ebenfalls ab.
- Normalform (2NF): Aufbauend auf der 1NF haben wir partielle Abhängigkeiten beseitigt. Das bedeutet, dass alle Nichtschlüsselattribute vom gesamten Kandidatenschlüssel voll funktional abhängig sind. Dieses Prinzip greift insbesondere bei zusammengesetzten Schlüsseln.
Warum die Zweite Normalform nicht ausreicht
Nach diesen Schritten scheint die Datenbank bereits gut strukturiert zu sein. Es können sich jedoch weiterhin Probleme verbergen. Betrachten wir eine Tabelle, die bereits vollständig der 2. Normalform entspricht, aber dennoch ein subtiles, jedoch schwerwiegendes Problem aufweist.
Tabelle 1: Artikeltabelle (in 2NF)
| ArtikelID (PK) | Bezeichnung | LieferantenID | LieferantenName | LieferantenOrt |
|---|---|---|---|---|
| 101 | Hammer “Thor” | 55 | BauMax GmbH | Stuttgart |
| 102 | Schraubenset A | 55 | BauMax GmbH | Stuttgart |
| 103 | Säge “Schnittfest” | 78 | Werkzeug-Welt AG | München |
| 104 | Zange “Greifer” | 55 | BauMax GmbH | Stuttgart |
Diese Tabelle befindet sich in der 2. Normalform. Der Primärschlüssel ArtikelID ist nicht zusammengesetzt, daher können keine partiellen Abhängigkeiten existieren. Dennoch fällt sofort eine Redundanz auf:
Die Informationen zum Lieferanten BauMax GmbH aus Stuttgart wiederholen sich bei jedem Artikel, den dieser Lieferant liefert.
Diese Redundanz ist kein Verstoß gegen die 2NF, deutet aber auf eine andere Art von strukturellem Problem hin. Genau dieses Problem führt uns zur Notwendigkeit der Dritten Normalform.
Annahme: Jeder Artikel hat genau einen Lieferanten. Auf dieser Geschäftsregel basiert die funktionale Abhängigkeit ArtikelID → LieferantenID.
Das Kernproblem: Transitive Abhängigkeiten verstehen
Das Problem in unserer Beispieltabelle wird durch eine sogenannte transitive Abhängigkeit verursacht.
Definition: Eine transitive Abhängigkeit liegt vor, wenn ein Nichtschlüsselattribut funktional von einem anderen Nichtschlüsselattribut abhängt. Formal ausgedrückt: Wenn A → B und B → C gilt, dann besteht eine transitive Abhängigkeit A → C. Hierbei ist A ein Kandidatenschlüssel, B und C sind Nichtschlüsselattribute.
In einfacheren Worten bedeutet das: Ein Attribut ist nur indirekt über ein anderes Attribut vom Schlüssel abhängig – also indirekt, nicht direkt.
Eine funktionale Abhängigkeit verlangt Eindeutigkeit der rechten Seite je linker Seite (funktional), aber keine Eins-zu-Eins-Zuordnung.
Beispiel: In einer Mitarbeitertabelle gilt:
- Über die MitarbeiterID (A) lässt sich eindeutig die AbteilungsID (B) ermitteln → A → B
- Über die AbteilungsID (B) lässt sich eindeutig der Abteilungsleiter (C) ermitteln → B → C
Daraus folgt: Der Abteilungsleiter (C) ist indirekt, also transitiv, von der MitarbeiterID (A) abhängig. Der Abteilungsleiter hängt nicht direkt vom Mitarbeiter ab, sondern von der Abteilung, in der der Mitarbeiter tätig ist.
Übertragung auf Tabelle 1:
Tabelle 1: Artikeltabelle (in 2NF)
| ArtikelID (PK) | Bezeichnung | LieferantenID | LieferantenName | LieferantenOrt |
|---|---|---|---|---|
| 101 | Hammer “Thor” | 55 | BauMax GmbH | Stuttgart |
| 102 | Schraubenset A | 55 | BauMax GmbH | Stuttgart |
| 103 | Säge “Schnittfest” | 78 | Werkzeug-Welt AG | München |
| 104 | Zange “Greifer” | 55 | BauMax GmbH | Stuttgart |
- ArtikelID (A) bestimmt eindeutig die LieferantenID (B) → ArtikelID → LieferantenID
- LieferantenID (B) bestimmt eindeutig LieferantenName und LieferantenOrt (C) → LieferantenID → LieferantenName, LieferantenOrt
Schlussfolgerung: LieferantenName und LieferantenOrt sind transitiv von der ArtikelID abhängig, da sie über die LieferantenID bestimmt werden.
Diese transitive Abhängigkeit ist kein theoretisches Detail, sondern ein Hinweis auf einen konzeptionellen Fehler im Datenmodell:
Die Tabelle vermischt zwei unterschiedliche Entitäten – Artikel und Lieferanten. Ein zentrales Ziel der Normalisierung ist es, sicherzustellen, dass jede Tabelle genau ein Konzept abbildet.
Die 3. Normalform zwingt uns, diese Trennung vorzunehmen, indem sie transitive Abhängigkeiten eliminiert.
Anomalien durch transitive Abhängigkeiten
Warum sind transitive Abhängigkeiten so problematisch? Weil sie, genau wie die in der 2NF behandelten partiellen Abhängigkeiten, zu Anomalien führen – also zu Fehlern und Inkonsistenzen bei der Datenpflege.
Tabelle 1: Artikeltabelle (in 2NF)
| ArtikelID (PK) | Bezeichnung | LieferantenID | LieferantenName | LieferantenOrt |
|---|---|---|---|---|
| 101 | Hammer “Thor” | 55 | BauMax GmbH | Stuttgart |
| 102 | Schraubenset A | 55 | BauMax GmbH | Stuttgart |
| 103 | Säge “Schnittfest” | 78 | Werkzeug-Welt AG | München |
| 104 | Zange “Greifer” | 55 | BauMax GmbH | Stuttgart |
Anhand unserer Tabelle 1 lassen sich die drei klassischen Anomalien klar erkennen:
1. Änderungsanomalie (Update Anomaly)
Problem: Wenn die BauMax GmbH von Stuttgart nach Berlin umzieht, muss der Ort in allen Datensätzen geändert werden, in denen dieser Lieferant vorkommt. Gefahr: Wird ein Datensatz vergessen, entstehen widersprüchliche Angaben – die Datenbank wird inkonsistent.
Anomalien durch transitive Abhängigkeiten
Tabelle 1: Artikeltabelle (in 2NF)
| ArtikelID (PK) | Bezeichnung | LieferantenID | LieferantenName | LieferantenOrt |
|---|---|---|---|---|
| 101 | Hammer “Thor” | 55 | BauMax GmbH | Stuttgart |
| 102 | Schraubenset A | 55 | BauMax GmbH | Stuttgart |
| 103 | Säge “Schnittfest” | 78 | Werkzeug-Welt AG | München |
| 104 | Zange “Greifer” | 55 | BauMax GmbH | Stuttgart |
Anhand unserer Tabelle 1 lassen sich die drei klassischen Anomalien klar erkennen:
2. Einfügeanomalie (Insertion Anomaly)
Problem: Ein neuer Lieferant (Heimwerker-König KG aus Hamburg) soll angelegt werden, liefert aber noch keine Artikel. Gefahr: Da ArtikelID der Primärschlüssel ist, kann der Lieferant ohne Artikel nicht gespeichert werden. Geschäftsinformationen gehen verloren.
Anomalien durch transitive Abhängigkeiten
Tabelle 1: Artikeltabelle (in 2NF)
| ArtikelID (PK) | Bezeichnung | LieferantenID | LieferantenName | LieferantenOrt |
|---|---|---|---|---|
| 101 | Hammer “Thor” | 55 | BauMax GmbH | Stuttgart |
| 102 | Schraubenset A | 55 | BauMax GmbH | Stuttgart |
| 103 | Säge “Schnittfest” | 78 | Werkzeug-Welt AG | München |
| 104 | Zange “Greifer” | 55 | BauMax GmbH | Stuttgart |
Anhand unserer Tabelle 1 lassen sich die drei klassischen Anomalien klar erkennen:
3. Löschanomalie (Deletion Anomaly)
Problem: Wenn der Artikel Säge “Schnittfest” gelöscht wird, verschwindet damit auch der einzige Datensatz zum Lieferanten Werkzeug-Welt AG. Gefahr: Informationen über den Lieferanten gehen unbeabsichtigt verloren.
Diese drei Anomalien zeigen: Eine Datenbank, die sich zwar in der 2NF befindet, aber noch transitive Abhängigkeiten enthält, bleibt in der Praxis fehleranfällig und schwer wartbar.
Definition der Dritten Normalform (3NF)
Nachdem wir das Problem und seine Folgen analysiert haben, kommen wir nun zur Lösung – der Dritten Normalform (3NF).
Formale Definition: Eine Relation befindet sich genau dann in der 3. Normalform (3NF), wenn sie
- in der 2. Normalform (2NF) ist und
- kein Nichtschlüsselattribut transitiv von einem Kandidatenschlüssel abhängt.
Alternativ formuliert: Für jede funktionale Abhängigkeit X → A gilt: X ist ein Superkey oder A ist ein Primattribut (Teil eines Kandidatenschlüssels).
Definition der Dritten Normalform (3NF)
Merksatz: „The key, the whole key, and nothing but the key.“
Dieser Satz beschreibt die Stufen der Normalisierung in knapper Form:
- The key (1NF): Jedes Tupel ist eindeutig identifizierbar – atomare Werte, eindeutige Schlüssel.
- The whole key (2NF): Jedes Attribut hängt vom gesamten Schlüssel ab, nicht nur von einem Teil.
- Nothing but the key (3NF): Jedes Attribut beschreibt ausschließlich die durch den Schlüssel identifizierte Entität – keine andere.
Damit wird das Prinzip „eine Tabelle, ein Konzept“ umgesetzt.
In der Praxis führt die 3NF zu einer robusten, wartungsarmen Struktur.
Die Umsetzung
Die Vorgehensweise: Der Weg zur 3. Normalform
Die Überführung einer Tabelle von der zweiten in die dritte Normalform ist ein klarer, systematischer Prozess. Das Ziel ist es, alle Nicht-Schlüsselattribute, die transitiv von einem Kandidatenschlüssel abhängen, in eine eigene Tabelle auszulagern. Diese Vorgehensweise ist eine Kernkompetenz für die Abschlussprüfung.
-
Ausgangslage prüfen: Vergewissere dich, dass die Tabelle in der 2. Normalform ist. Das ist die Grundvoraussetzung.
-
Transitive Abhängigkeiten aufspüren: Suche nach Attributen, die sich nicht direkt auf den Primärschlüssel beziehen, sondern ein anderes Attribut in der Zeile beschreiben. Die Schlüsselfrage lautet: „Welche Spalten beschreiben hier ein anderes Konzept?“
-
Neue Tabelle erstellen: Erstelle für dieses „andere Konzept“ eine neue Tabelle und verschiebe alle zugehörigen Spalten dorthin.
-
Schlüssel definieren und verknüpfen: In der Regel wird das Attribut, das die beiden Konzepte verbindet, in der neuen Tabelle zum Primärschlüssel (bei 1:n-Beziehungen). In der ursprünglichen Tabelle bleibt es als Fremdschlüssel erhalten, um die Beziehung zwischen den Tabellen zu sichern. Hinweis: Bei m:n-Beziehungen wird ein zusammengesetzter Schlüssel verwendet.
Anwendungsbeispiel: Normalisierung einer Artikeltabelle
Gehen wir diesen Prozess nun anhand eines typischen Prüfungsbeispiels durch. Solche Aufgaben, bei denen eine gegebene Tabelle in die 3. Normalform überführt werden muss, sind ein Klassiker in der AP2.
Ausgangssituation: Die Tabelle Artikel (in 2NF)
Unsere Ausgangsbasis ist die folgende Tabelle. Sie ist bereits in der 2. Normalform, da sie einen einfachen Primärschlüssel (ArtikelNr) hat und somit keine partiellen Abhängigkeiten existieren können.
| ArtikelNr (PK) | Bezeichnung | Preis | ArtGruppeID | ArtGruppeBez | RabattProzent |
|---|---|---|---|---|---|
| 4001 | Bohrmaschine X5 | 129.99 | 10 | Elektrowerkzeuge | 5 |
| 4002 | Akkuschrauber Y7 | 89.99 | 10 | Elektrowerkzeuge | 5 |
| 5011 | Schraubenschlüssel | 19.99 | 20 | Handwerkzeuge | 3 |
| 5012 | Hammer Z1 | 24.99 | 20 | Handwerkzeuge | 3 |
| 4003 | Stichsäge Z9 | 119.99 | 10 | Elektrowerkzeuge | 5 |
Schritt 1: Transitive Abhängigkeiten identifizieren
Wir schauen uns die Tabelle genau an und stellen fest, dass einige Spalten nicht direkt den Artikel beschreiben, sondern die Artikelgruppe.
| ArtikelNr (PK) | Bezeichnung | Preis | ArtGruppeID | ArtGruppeBez | RabattProzent |
|---|---|---|---|---|---|
| 4001 | Bohrmaschine X5 | 129.99 | 10 | Elektrowerkzeuge | 5 |
| 4002 | Akkuschrauber Y7 | 89.99 | 10 | Elektrowerkzeuge | 5 |
| 5011 | Schraubenschlüssel | 19.99 | 20 | Handwerkzeuge | 3 |
| 5012 | Hammer Z1 | 24.99 | 20 | Handwerkzeuge | 3 |
| 4003 | Stichsäge Z9 | 119.99 | 10 | Elektrowerkzeuge | 5 |
Die Attribute ArtGruppeBez und RabattProzent hängen nicht von der ArtikelNr ab. Ein Hammer hat keinen eigenen Rabatt, sondern er gehört zu einer Gruppe (Handwerkzeuge), und diese Gruppe hat einen Rabatt.
Das ist eine klassische transitive Abhängigkeit: ArtikelNr → ArtGruppeID → (ArtGruppeBez, RabattProzent)
Schritt 2: Abhängige Attribute in eine neue Tabelle auslagern
Da die Attribute ArtGruppeID, ArtGruppeBez und RabattProzent ein eigenes Konzept („Artikelgruppe“) beschreiben, lagern wir sie in eine neue, separate Tabelle aus.
Neue Tabelle Artikelgruppen:
| ArtGruppeID | ArtGruppeBez | RabattProzent |
|---|---|---|
| 10 | Elektrowerkzeuge | 5 |
| 20 | Handwerkzeuge | 3 |
Die Redundanzen sind hier bereits beseitigt. Jede Artikelgruppe kommt nur noch einmal vor.
Die ursprüngliche Tabelle Artikel sieht jetzt so aus:
| ArtikelNr (PK) | Bezeichnung | Preis | ArtGruppeID |
|---|---|---|---|
| 4001 | Bohrmaschine X5 | 129.99 | 10 |
| 4002 | Akkuschrauber Y7 | 89.99 | 10 |
| 5011 | Schraubenschlüssel | 19.99 | 20 |
| 5012 | Hammer Z1 | 24.99 | 20 |
| 4003 | Stichsäge Z9 | 119.99 | 10 |
Schritt 3: Schlüssel definieren und Tabellen verknüpfen
Im letzten Schritt definieren wir die Schlüssel formal, um die Beziehung zwischen den beiden Tabellen herzustellen:
- In der neuen Tabelle Artikelgruppen wird ArtGruppeID zum Primärschlüssel (PK).
- In der Tabelle Artikel bleibt ArtGruppeID als Fremdschlüssel (FK) erhalten. Dieser verweist auf den Primärschlüssel in der Tabelle Artikelgruppen.
Endergebnis: Zwei Tabellen in der 3. Normalform
Tabelle Artikel (final in 3NF)
| ArtikelNr (PK) | Bezeichnung | Preis | ArtGruppeID (FK) |
|---|---|---|---|
| 4001 | Bohrmaschine X5 | 129.99 | 10 |
| 4002 | Akkuschrauber Y7 | 89.99 | 10 |
| 5011 | Schraubenschlüssel | 19.99 | 20 |
| 5012 | Hammer Z1 | 24.99 | 20 |
| 4003 | Stichsäge Z9 | 119.99 | 10 |
Tabelle Artikelgruppen (neu in 3NF)
| ArtGruppeID (PK) | ArtGruppeBez | RabattProzent |
|---|---|---|
| 10 | Elektrowerkzeuge | 5 |
| 20 | Handwerkzeuge | 3 |
Wir haben die Normalisierung erfolgreich abgeschlossen. Beide Tabellen sind nun in der 3. Normalform, da es keine transitiven Abhängigkeiten mehr gibt.
Das Ergebnis: Vorteile und Struktur der 3NF
Durch die Aufteilung der ursprünglichen Tabelle in zwei separate, aber verknüpfte Tabellen haben wir die transitive Abhängigkeit beseitigt. Analysieren wir nun, wie diese neue Struktur die zuvor beschriebenen Anomalien verhindert:
-
Keine Änderungsanomalie mehr: Wenn sich der Rabatt für alle „Elektrowerkzeuge“ von 5 % auf 6 % ändert, muss nur noch ein einziger Datensatz in der Tabelle Artikelgruppen aktualisiert werden. Diese Änderung gilt sofort konsistent für alle Artikel, die über den Fremdschlüssel mit dieser Gruppe verknüpft sind.
-
Keine Einfügeanomalie mehr: Wir können problemlos eine neue Artikelgruppe, z. B. Gartenwerkzeuge mit der ID 30 und 0 % Rabatt, in die Tabelle Artikelgruppen einfügen – auch wenn es noch keinen einzigen Artikel dieser Gruppe gibt.
-
Keine Löschanomalie mehr: Wenn wir den letzten Artikel aus der Gruppe Handwerkzeuge (z. B. den Hammer und den Schraubenschlüssel) aus der Tabelle Artikel löschen, bleibt der Datensatz für die Artikelgruppe Handwerkzeuge in der Tabelle Artikelgruppen bestehen. Wichtige Geschäftsinformationen über unsere Sortimentsstruktur gehen nicht verloren.
Vorteile der 3. Normalform
- Reduzierte Redundanz: Informationen zu Artikelgruppen werden nur einmal gespeichert.
- Verbesserte Datenintegrität: Das Risiko von Inkonsistenzen durch fehlerhafte Änderungen wird minimiert.
- Einfachere Datenpflege: Änderungen, Einfügungen und Löschungen sind ohne unerwünschte Nebeneffekte möglich.
- Erhöhte Flexibilität: Das Datenbankmodell ist leichter erweiterbar, da jedes Konzept in einer eigenen Tabelle gekapselt ist.
Zusammenfassung
Zusammenfassung:
Die Dritte Normalform (3NF) – Konzept und Notwendigkeit
Die 3NF ergänzt die 2NF, indem sie transitive Abhängigkeiten eliminiert. Ziel ist es, Redundanzen zu vermeiden, Anomalien zu verhindern und Datenintegrität zu sichern.
- 1NF sorgt für atomare Werte und eindeutige Identifikation über Kandidatenschlüssel.
- 2NF beseitigt partielle Abhängigkeiten bei zusammengesetzten Schlüsseln.
- 3NF stellt sicher, dass jedes Nichtschlüsselattribut direkt vom (Kandidaten‑)Schlüssel abhängt und nicht indirekt über ein anderes Attribut.
- Praxisnutzen: weniger Doppeleinträge, konsistente Änderungen, klare Trennung der Konzepte pro Tabelle.
Transitive Abhängigkeiten – Erkennen und Einordnen
Transitive Abhängigkeiten sind der zentrale Grund, warum 2NF oft nicht ausreicht. Du identifizierst sie, wenn ein Attribut ein anderes Nichtschlüsselattribut beschreibt.
- Definition: A → B und B → C impliziert A → C (A = Kandidatenschlüssel; B, C = Nichtschlüsselattribute).
- Symptom: Eine Tabelle vermischt Konzepte (z. B. Artikel und Lieferantendaten in einer Relation).
- Faustregel: „Welche Spalten beschreiben hier ein anderes Konzept?“ Wenn ja, liegt oft eine transitive Abhängigkeit vor.
[Schlüssel A] -> [Nichtschlüssel B] -> [Nichtschlüssel C]indirekt:
A -> C(transitiv)
Abschließend gilt: Transitive Abhängigkeiten sind strukturelle Hinweise, dass du Tabellen entlang der Konzepte trennen solltest.
Anomalien durch transitive Abhängigkeiten
Transitive Abhängigkeiten führen zu typischen Pflegeproblemen. Du vermeidest diese, indem du betroffene Attribute auslagerst.
- Änderungsanomalie: Eine Information muss an vielen Stellen aktualisiert werden → Risiko inkonsistenter Daten.
- Einfügeanomalie: Fachinformationen lassen sich ohne passenden Schlüssel nicht separat speichern.
- Löschanomalie: Mit dem Löschen eines Datensatzes gehen fachliche Informationen ungewollt verloren.
| Anomalie | Ursache (transitiv) | Auswirkung | Gegenmaßnahme in 3NF |
|---|---|---|---|
| Änderung | Wiederholte, von B abhängige C‑Attribute | Inkonsistente Angaben | C in eigene Tabelle, Referenz beibehalten |
| Einfügen | Konzept C benötigt A‑Datensatz | Fachinfo fehlt ohne A | Tabelle für C anlegen (eigenständiges Konzept) |
| Löschen | C hängt an A‑Datensatz | Verlust von C‑Information | Entkopplung über separate C‑Tabelle |
Diese Gegenüberstellung zeigt, dass die Beseitigung transitiver Abhängigkeiten die Wartbarkeit direkt verbessert.
Definition der 3NF und Merksatz
Die 3NF lässt sich formal und pragmatisch fassen. Beide Sichtweisen helfen dir in Prüfung und Praxis.
- Formale Definition: Eine Relation ist in 3NF, wenn sie in 2NF ist und kein Nichtschlüsselattribut transitiv von einem Kandidatenschlüssel abhängt.
- Alternative Formulierung: Für jede FD X → A gilt: X ist ein Superkey oder A ist Primattribut (Teil eines Kandidatenschlüssels).
- Merksatz: „The key, the whole key, and nothing but the key.“
Der Merksatz verdeutlicht die Stufen: Schlüssel vorhanden (1NF), Abhängigkeit vom ganzen Schlüssel (2NF), nur Schlüsselabhängigkeiten (3NF).
Vorgehensweise: Schritt für Schritt zur 3NF
Die Überführung in 3NF folgt einem klaren, prüfungsrelevanten Ablauf. Du gehst systematisch vor und dokumentierst deine Entscheidungen.
- 1) 2NF prüfen: Atomarität, eindeutiger (Kandidaten‑)Schlüssel, keine partiellen Abhängigkeiten.
- 2) Transitive Abhängigkeiten finden: Attribute identifizieren, die ein anderes Konzept als den Schlüsselträger beschreiben.
- 3) Neue Tabelle definieren: Diese Attribute in eine eigene Relation auslagern; Konzept klar benennen.
- 4) Schlüssel & Beziehungen festlegen: Verbindendes Attribut wird in der neuen Tabelle PK; in der Ursprungstabelle bleibt es als FK erhalten (bei m:n: Zwischentabelle mit zusammengesetztem Schlüssel).
Am Ende sollte jede Tabelle genau ein fachliches Konzept repräsentieren und nur dazugehörige Attribute enthalten.
Vorteile der 3NF in der Praxis
Mit 3NF erhöhst du Qualität und Erweiterbarkeit der Datenbank. Änderungen werden zentral und sicher durchgeführt.
- Redundanzreduktion: Fachinformationen liegen genau einmal vor.
- Integrität & Konsistenz: Einheitliche Änderungen ohne Schattenkopien.
- Pflege & Erweiterbarkeit: Klare Zuständigkeiten pro Tabelle, einfachere Migrationen und Erweiterungen.
Gerade in Prüfungen solltest du diese Vorteile kurz benennen und auf die beseitigten Anomalien beziehen.
Ausblick:
In der nächsten Lerneinheit geht es um die Boyce-Codd-Normalform (BCNF), eine erweiterte Form der dritten Normalform. Du lernst, wie sie funktionale Abhängigkeiten noch strenger definiert und dadurch Anomalien bei Datenänderungen verhindert. Außerdem erfährst du, wann die BCNF über die dritte Normalform hinaus notwendig ist und wie sie zur höchsten Konsistenz und Datenqualität in relationalen Datenbanken beiträgt.