Boyce Codd Normalform (BCNF)

Hinweis

Diese Lerneinheit behandelt die Boyce-Codd-Normalform, oft auch als BCNF oder 3.5NF bezeichnet.

Für deine IHK-Abschlussprüfung ist die sichere Beherrschung der ersten drei Normalformen (1NF, 2NF, 3NF) entscheidend. Die BCNF ist in der Regel nicht prüfungsrelevant, wird hier aber der Vollständigkeit halber behandelt.

Sie rundet dein Wissen ab und gibt dir ein tieferes Verständnis für die letzten Feinheiten des relationalen Datenbankdesigns, die in besonders komplexen Szenarien eine Rolle spielen können.

Einführung

In deiner Kursdatenbank steht dreimal “Prof. Müller lehrt Datenbanken” - einmal für jeden Studenten. Müller wechselt das Fach, du änderst zwei Zeilen… und übersiehst die dritte.

Mögliche Redundanz trotz Normalform — Bildrechte: Ausbildung-in-der-IT.de (KI-unterstützt)

Die Tabelle ist in 3NF - und trotzdem entsteht Redundanz. Die BCNF erkennt dieses Problem und löst es durch Zerlegung: Jede Information wird nur noch einmal gespeichert.

Lernziele

Nach dieser Lerneinheit kannst du:

1. BCNF präzise definieren und von der 3NF abgrenzen.

2. Funktionale Abhängigkeiten und Schlüsselkandidaten ermitteln.

3. BCNF-Verletzungen sicher erkennen und begründen.

4. Relationen normgerecht in BCNF zerlegen und die Korrektheit validieren.

Warum die 3NF manchmal nicht ausreicht

In den meisten Fällen reicht die 3NF aus, um Datenanomalien zu vermeiden. Es gibt jedoch spezielle Konstellationen, in denen sie nicht genügt. Diese treten auf, wenn alle drei folgenden Bedingungen gleichzeitig erfüllt sind:

1. Die Relation besitzt mehrere (mindestens zwei) Schlüsselkandidaten.
2. Diese Schlüsselkandidaten sind zusammengesetzt, also aus mehreren Attributen gebildet.
3. Die Schlüsselkandidaten überlappen sich, das heißt, sie teilen sich mindestens ein gemeinsames Attribut.

In einer solchen Situation kann es vorkommen, dass eine funktionale Abhängigkeit existiert, deren linke Seite kein Superschlüssel ist. Obwohl die Tabelle formal in der 3NF bleibt, entstehen Redundanzen und damit potenzielle Änderungsanomalien. Um diese Lücke zu schließen, wurde die BCNF von Raymond F. Boyce und Edgar F. Codd entwickelt.

Definition der Boyce-Codd-Normalform (BCNF)

Die Boyce-Codd-Normalform (BCNF) beseitigt das Schlupfloch der 3NF. Ihre Definition ist einfacher, aber strenger:

Eine Relation ist in der Boyce-Codd-Normalform (BCNF), wenn für jede nichttriviale funktionale Abhängigkeit X → Y gilt: X ist ein Superschlüssel.

Im Unterschied zur 3NF entfällt hier die Ausnahme, dass Y ein Primattribut sein darf. Damit stellt die BCNF sicher, dass jede Determinante (linke Seite einer funktionalen Abhängigkeit) selbst eindeutig identifizierend ist. Nur so lassen sich alle Redundanzen vermeiden.

Schlüsselkonzepte im Detail

Um die BCNF korrekt anwenden zu können, ist es wichtig, die Begriffe Determinante und Superschlüssel genau zu verstehen.

Determinante:

• In einer funktionalen Abhängigkeit X → Y ist X die Determinante. Sie bestimmt eindeutig den Wert von Y. Wenn du also den Wert von X kennst, kannst du Y eindeutig ableiten.

Schlüsselkonzepte im Detail

Superschlüssel:

• Ein Superschlüssel ist eine Kombination aus einem oder mehreren Attributen, die zusammen jeden Datensatz in einer Tabelle eindeutig identifizieren.

  • Ein entscheidendes Merkmal des Superschlüssels ist, dass er auch “überflüssige” Attribute enthalten darf, solange die Eindeutigkeit gewahrt bleibt. Wenn beispielsweise die {MitarbeiterID} einen Datensatz eindeutig identifiziert, dann sind auch die Attributmengen {MitarbeiterID, Nachname} und {MitarbeiterID, Geburtsdatum} Superschlüssel. Sie erfüllen die Bedingung der Eindeutigkeit, auch wenn sie nicht minimal sind.

Abgrenzung: Superschlüssel vs. Schlüsselkandidat

• Ein Schlüsselkandidat ist ein minimaler Superschlüssel. Das bedeutet, er identifiziert einen Datensatz eindeutig, aber sobald du ein Attribut entfernst, geht diese Eindeutigkeit verloren. Jeder Schlüsselkandidat ist also ein Superschlüssel, aber nicht jeder Superschlüssel ist ein Schlüsselkandidat.

Die klare Trennung dieser Begriffe ist entscheidend, um zu erkennen, wann eine Relation die Anforderungen der BCNF erfüllt und wann eine funktionale Abhängigkeit zu einer Verletzung dieser Normalform führt.

⏳ Lädt Dataview-Inhalt...

Schritt-für-Schritt-Anleitung: Überführung in die BCNF

Ausgangssituation: Die „Student–Fach–Professor“-Beziehung

Wir betrachten eine Relation, die speichert, welcher Student welches Fach bei welchem Professor belegt. Die Geschäftsregeln lauten:

1. Ein Student kann mehrere Fächer belegen.
2. Für jedes Fach wird einem Studenten genau ein Professor zugewiesen.
3. Jeder Professor lehrt genau ein Fach (z. B. Prof. Meier lehrt nur Datenbanken).
4. Ein Fach kann von mehreren Professoren gelehrt werden.

Relation: Student_Fach_Prof (MatrNr, Fach, Professor)

Beispieldaten (Ausgangszustand):

MatrNr	Fach	Professor
101	Datenbanken	Prof. Meier
101	Mathe	Prof. Gauss
102	Datenbanken	Prof. Codd
103	Mathe	Prof. Gauss

Diese Tabelle soll nun auf BCNF-Konformität überprüft werden.

Schritt 1: Analyse der funktionalen Abhängigkeiten (FAs)

Aus den Regeln ergeben sich folgende funktionale Abhängigkeiten:

• FA 1: {MatrNr, Fach} → {Professor} Begründung: Ein Student hat in einem bestimmten Fach genau einen Professor.
• FA 2: {Professor} → {Fach} Begründung: Jeder Professor lehrt genau ein Fach.

Aktueller Tabellenstand: (noch unverändert)

MatrNr	Fach	Professor
101	Datenbanken	Prof. Meier
101	Mathe	Prof. Gauss
102	Datenbanken	Prof. Codd
103	Mathe	Prof. Gauss

Schritt 2: Bestimmung der Schlüsselkandidaten

Wir prüfen, welche Attributkombinationen alle anderen Attribute der Relation bestimmen können (Attributhülle).

• Prüfung von {MatrNr, Fach}:

  1. Die Hülle enthält {MatrNr, Fach} selbst.
  2. Wegen FA 1 ({MatrNr, Fach} → {Professor}) kommt {Professor} hinzu.
  3. Ergebnis: Die Hülle ist {MatrNr, Fach, Professor}. Da dies alle Attribute der Relation sind, ist {MatrNr, Fach} ein Schlüsselkandidat.

• Prüfung von {MatrNr, Professor}:

  1. Die Hülle enthält {MatrNr, Professor} selbst.
  2. Wegen FA 2 ({Professor} → {Fach}) kommt {Fach} hinzu.
  3. Ergebnis: Die Hülle ist {MatrNr, Professor, Fach}. Da dies ebenfalls alle Attribute der Relation sind, ist auch {MatrNr, Professor} ein Schlüsselkandidat.

Wir haben somit zwei sich überlappende, zusammengesetzte Schlüsselkandidaten identifiziert: {MatrNr, Fach} und {MatrNr, Professor}. Dies ist die klassische Konstellation, in der eine BCNF-Verletzung auftreten kann.

Tabellenstand (logisch identisch, aber Analyseergebnis hinzugefügt):

MatrNr	Fach	Professor	Schlüsselkandidaten
101	Datenbanken	Prof. Meier	{MatrNr, Fach}, {MatrNr, Professor}
101	Mathe	Prof. Gauss	{MatrNr, Fach}, {MatrNr, Professor}
102	Datenbanken	Prof. Codd	{MatrNr, Fach}, {MatrNr, Professor}
103	Mathe	Prof. Gauss	{MatrNr, Fach}, {MatrNr, Professor}

Schritt 3: Überprüfung der 3NF

• In 1NF, da alle Werte atomar sind.
• In 2NF, da kein Nicht-Schlüsselattribut von nur einem Teil eines zusammengesetzten Schlüssels abhängt. (Hier sind alle Attribute Teil eines Schlüssels, sogenannte Primattribute, daher kann es keine partielle Abhängigkeit geben).
• In 3NF. Um dies zu prüfen, wenden wir die 3NF-Regel auf jede funktionale Abhängigkeit (FD) an:
  • FA 1: {MatrNr, Fach} → {Professor}. Die Determinante {MatrNr, Fach} ist ein Schlüsselkandidat. 3NF-konform.
  • FA 2: {Professor} → {Fach}. Die Determinante {Professor} ist kein Schlüsselkandidat. Wir prüfen die 3NF-Ausnahmeregel: Ist das abhängige Attribut (Fach) ein Primattribut (Teil eines Schlüsselkandidaten)? Ja, Fach ist Teil des Schlüsselkandidaten {MatrNr, Fach}. Daher ist auch diese Abhängigkeit 3NF-konform.

Zwischenergebnis: Die Tabelle erfüllt die Anforderungen der 3NF vollständig, ist aber möglicherweise nicht BCNF-konform.

Tabellenstand (unverändert):

MatrNr	Fach	Professor
101	Datenbanken	Prof. Meier
101	Mathe	Prof. Gauss
102	Datenbanken	Prof. Codd
103	Mathe	Prof. Gauss

Schritt 4: Identifikation der BCNF-Verletzung

Nun prüfen wir jede funktionale Abhängigkeit nach der BCNF-Regel: Jede Determinante muss ein Superschlüssel sein.

• FA 1: {MatrNr, Fach} → {Professor} {MatrNr, Fach} ist ein Superschlüssel → BCNF-konform

• FA 2: {Professor} → {Fach} {Professor} allein ist kein Superschlüssel, da er MatrNr nicht eindeutig bestimmt → BCNF-Verletzung!

Diese Abhängigkeit führt zu Redundanzen: Die Zuordnung „Prof. Gauss → Mathe“ ist mehrfach gespeichert.

Tabellenstand mit markierter Redundanz:

MatrNr	Fach	Professor	Redundanz?
101	Mathe	Prof. Gauss	Redundanz
103	Mathe	Prof. Gauss	Redundanz

Schritt 5: Zerlegung der Relation

Die verletzende Abhängigkeit {Professor} → {Fach} wird in eine eigene Tabelle ausgelagert. Die verbleibenden Attribute bilden eine zweite Tabelle, wobei Professor als Fremdschlüssel erhalten bleibt.

Zerlegungsschritte:

1. Erstelle eine neue Relation Prof_Lehrt_Fach aus der verletzenden Abhängigkeit {Professor} → {Fach}. Der Primärschlüssel ist die Determinante {Professor}.
2. Erstelle eine zweite Relation Student_Belegt_Bei aus den verbleibenden Attributen der Ursprungstabelle (MatrNr) und der Determinante der ausgelagerten Abhängigkeit (Professor).
3. Professor in der Tabelle Student_Belegt_Bei fungiert nun als Fremdschlüssel, der auf den Primärschlüssel der Prof_Lehrt_Fach-Tabelle verweist. So bleibt die ursprüngliche Information erhalten.

Neuer Tabellenstand:

Tabelle 1: Prof_Lehrt_Fach (nach Zerlegung)

Professor	Fach
Prof. Meier	Datenbanken
Prof. Gauss	Mathe
Prof. Codd	Datenbanken

Tabelle 2: Student_Belegt_Bei (nach Zerlegung)

MatrNr	Professor
101	Prof. Meier
101	Prof. Gauss
102	Prof. Codd
103	Prof. Gauss

Schritt 6: Validierung der BCNF-Konformität

• Prof_Lehrt_Fach: Jede funktionale Abhängigkeit (Professor → Fach) hat einen Superschlüssel als Determinante.
• Student_Belegt_Bei: Jede funktionale Abhängigkeit ({MatrNr, Professor} → …) hat einen Superschlüssel als Determinante.

Endzustand (vollständig BCNF-konform):

Prof_Lehrt_Fach
Professor	Fach
Prof. Meier	Datenbanken
Prof. Gauss	Mathe
Prof. Codd	Datenbanken

Student_Belegt_Bei
MatrNr	Professor
101	Prof. Meier
101	Prof. Gauss
102	Prof. Codd
103	Prof. Gauss

Beide Tabellen erfüllen nun die Boyce-Codd-Normalform (BCNF). Redundanzen wurden beseitigt. Jede Änderung an Professoren oder Fächern lässt sich konsistent und ohne Anomalien durchführen.

⏳ Lädt Dataview-Inhalt...

Zusammenfassung

Zusammenfassung:

Theoretische Grundlagen der Boyce-Codd-Normalform (BCNF)

Die Boyce-Codd-Normalform (BCNF) ist eine Verschärfung der Dritten Normalform (3NF). Sie stellt sicher, dass alle Redundanzen, die aus funktionalen Abhängigkeiten entstehen, vollständig beseitigt werden. Als höchste Normalform, die ausschließlich auf funktionalen Abhängigkeiten basiert, sorgt sie für maximale Datenintegrität.

• Ziel der Normalisierung: Redundanz minimieren und Anomalien (Einfüge-, Änderungs- und Löschanomalien) vermeiden.

• Bezug zur 3NF: Eine Relation ist in der 3NF, wenn sie in der 2NF ist und keine transitiven Abhängigkeiten aufweist.

• Ausnahmeregelung der 3NF: Eine Abhängigkeit X → Y ist erlaubt, wenn Y ein Primattribut ist, auch wenn X kein Superschlüssel ist.

• BCNF-Regel: Für jede nichttriviale funktionale Abhängigkeit X → Y muss X ein Superschlüssel sein. Keine Ausnahmen erlaubt.

• Begriffe:

  • Determinante: Die Attributmenge X in einer Abhängigkeit X → Y, die Y bestimmt.
  • Superschlüssel: Eine Attributkombination, die jede Zeile eindeutig identifiziert.
  • Schlüsselkandidat: Minimaler Superschlüssel; kein Attribut kann entfernt werden, ohne die Eindeutigkeit zu verlieren.

Die BCNF wird vor allem dann relevant, wenn mehrere überlappende, zusammengesetzte Schlüsselkandidaten existieren. In solchen Fällen können trotz 3NF Redundanzen auftreten.

Kernaussagen

• Die 3NF verhindert viele, aber nicht alle Redundanzen.
• Die BCNF schließt die verbleibende Lücke: Jede Determinante muss ein Superschlüssel sein.
• Der Übergang von 3NF zu BCNF erfolgt durch Zerlegung in kleinere, logisch verknüpfte Tabellen.
• Eine Relation in BCNF gewährleistet maximale Datenintegrität und minimale Redundanz.

Die BCNF ist somit ein zentraler Schritt für die saubere und wartungsfreundliche Gestaltung relationaler Datenbanken.

Ausblick:

In der nächsten Lerneinheit lernst du, wie die ersten drei Normalformen – also 1NF, 2NF und 3NF – in der Praxis angewendet werden. Du erfährst, wie du reale Datentabellen schrittweise normalisierst, Redundanzen vermeidest und klare Beziehungen zwischen Tabellen herstellst. Dabei wird gezeigt, wie diese Prinzipien helfen, Datenbanken effizient, konsistent und wartungsfreundlich zu gestalten.

---