Erläuterung

Jedes Attribut der Relation muss einen atomaren Wertebereich haben, und die Relation muss frei von Wiederholungsgruppen sein. (Anm.: statt „atomar“ wird auch die Bezeichnung „atomisch“ verwendet.)

Atomar heißt, dass zusammengesetzte, mengenwertige oder geschachtelte Wertebereiche (also Relationen wertige Attributwertebereiche) nicht erlaubt sind. In einer Relation, die sich in 1NF befindet, gibt es kein Attribut, dessen Wertebereich in weitere (sinnvolle) Teilbereiche aufgespaltet werden kann.

Beispiel: Die Adresse darf nicht als einzelnes Attribut verwendet werden, sondern muss – sofern es der zugrunde liegende Prozess erfordert und erlaubt – in PLZ, Ort, Straße, Hausnummer etc. aufgeteilt werden.

Frei von Wiederholungsgruppen bedeutet, dass Attribute, die gleiche oder gleichartige Information enthalten, in eine andere Relation ausgelagert werden müssen.

Ein Beispiel für eine Wiederholungsgruppe wäre eine Spalte { Telefon }, die mehrere Telefonnummern enthält oder auch eine Spaltengruppe { Telefon1, Telefon2, Telefon3 }, wobei im letzteren Fall anzumerken ist, dass es sich dabei nicht notwendigerweise um eine Wiederholungsgruppe handeln muss (siehe Alternative Formulierungen).

Praktischer Nutzen

Abfragen der Datenbank werden durch die 1NF erleichtert bzw. überhaupt erst ermöglicht, wenn die Attributwertebereiche atomar sind. So ist es beispielsweise in einem Feld, das einen ganzen Namensstring aus Titel, Vorname und Nachname enthält, schwierig bis unmöglich, nach Nachnamen zu sortieren.

Alternative Formulierungen

Alle Attribute enthalten atomare Inhalte, und die Relation hat eine feste Breite. Diese Formulierung bezieht sich darauf, dass es niemals nötig sein darf, weitere Attribute in die Relation aufzunehmen, weil die Wiederholungszahl der Wiederholungsgruppe zu klein wird (z. B.: es wird bei drei Attributen Telefon1–3 eine 4. Telefonnummer für eine Person bekannt). Sie ist insofern interessant, als sie helfen kann zu entscheiden, ob tatsächlich eine Wiederholungsgruppe vorliegt: Obwohl z. B. { .., Telefon1, Telefon2, Telefon3,.. } sehr stark das Vorhandensein einer Wiederholungsgruppe impliziert, könnte es bei lediglich anderen Attributnamen klar werden, dass – freilich unter dem Licht der Anwendung – dem nicht so sein muss: { .., Telefon, Fax, Mobil,.. }

Eine weitere Variante entsteht durch folgenden Zusatz: .. und die Relation einen Primärschlüssel hat. Obwohl diese Formulierung so nicht bei Codd nachgelesen werden kann, handelt es sich um eine Erweiterung, die zu ausgesprochen praxistauglichen Datenstrukturen führt.

Negativbeispiel: 1NF verletzt

• Das Feld Album enthält die Attributwertebereiche Interpret und Albumtitel.
• Das Feld Titelliste enthält eine Menge von Titeln.

Dadurch hat man ohne Aufspaltung folgende Probleme bei Abfragen:

• Zur Sortierung nach Albumtitel muss das Feld Album in Interpret und Albumtitel aufgeteilt werden.
• Die Titel können (mit einfachen Mitteln) nur alle gleichzeitig als Titelliste oder gar nicht dargestellt werden.

Lösung

Die Attributwertebereiche werden in atomare Attributwertebereiche aufgespalten:

• Das Feld Album wird in die Felder Albumtitel und Interpret gespalten.
• Das Feld Titelliste wird in die Felder Track und Titel gespalten sowie auf mehrere Datensätze aufgeteilt.

Da jetzt jeder Attributwertebereich atomar ist sowie die Tabelle einen eindeutigen Primärschlüssel (Verbundschlüssel aus den Spalten CD_ID und Track) besitzt, befindet sich die Relation in 1NF.

Erläuterung

Eine Relation ist genau dann in der zweiten Normalform, wenn die erste Normalform vorliegt und kein Nichtprimärattribut (Attribut, das nicht Teil eines Schlüsselkandidaten ist) funktional von einer echten Teilmenge eines Schlüsselkandidaten abhängt.

Anders gesagt: Jedes nicht-primäre Attribut (nicht Teil eines Schlüssels) ist jeweils von allen ganzen Schlüsseln abhängig, nicht nur von einem Teil eines Schlüssels. Wichtig ist hierbei, dass die Nichtschlüsselattribute wirklich von allen Schlüsseln vollständig abhängen.

Somit gilt, dass Relationen in der 1NF, deren Schlüsselkandidat(en) nicht zusammengesetzt sind, sondern lediglich aus jeweils (einem) einzelnen Attribut(en) bestehen, automatisch die 2NF erfüllen.

In einer Relation R(A,B) ist das Attribut B von dem Attribut A funktional abhängig, falls zu jedem Wert des Attributs A genau ein Wert des Attributs B gehört. In einer Relation R(S1,S2,B) ist das Attribut B von den Schlüsselattributen S1 und S2 voll funktional abhängig, wenn B von den zusammengesetzten Attributen (S1,S2) funktional abhängig ist, nicht aber von einem einzelnen Attribut S1 oder S2.

Diese informelle Definition kann wie folgt präzisiert werden:

Eine Relation ist genau dann in zweiter Normalform, wenn sie

1. in der ersten Normalform ist und
2. für jedes Attribut ${\displaystyle a}$ der Relation gilt:
   • ${\displaystyle a}$ ist Teil eines Schlüsselkandidaten oder
   • ${\displaystyle a}$ ist von einem Schlüsselkandidaten abhängig und
     ${\displaystyle a}$ ist nicht von einer echten Teilmenge eines Schlüsselkandidaten abhängig.

${\displaystyle a}$ ist voll funktional abhängig von jedem Schlüsselkandidaten (wobei die Schlüsselkandidaten KC auch durch die Kombination mehrerer Attribute gebildet werden können). Die 2NF eliminiert alle partiellen funktionalen Abhängigkeiten, d. h. kein Nichtschlüsselattribut ist funktional abhängig von Teilen des Schlüsselkandidaten.

Falls ein Schlüsselkandidat zwei Attribute besitzt, können bei der Zerlegung in die 2NF höchstens drei Relationen entstehen. Falls ein Schlüsselkandidat drei Attribute besitzt, können bei der Zerlegung in die 2NF höchstens sieben Relationen entstehen. Das sind jeweils die Anzahl der Teilmengen einer gegebenen Menge minus 1 (leere Menge) und entspricht der Anzahl der Elemente der Potenzmenge (${\displaystyle 2^{n}}$) als Obergrenze.

Praktischer Nutzen

Die 2NF erzwingt wesentlich „monothematische“ Relationen im Schema: jede Relation modelliert nur einen Sachverhalt.

Dadurch werden Redundanz und die damit einhergehende Gefahr von Inkonsistenzen reduziert. Nur noch logisch/sachlich zusammengehörige Informationen finden sich in einer Relation. Dadurch fällt das Verständnis der Datenstrukturen leichter. Jedoch wird beim Planen eines Datenmodelles die 2. Normalform meistens übersprungen, daher kommt sie, verglichen mit der 1. und 3. Normalform, eher selten vor.

Negativbeispiel: 2NF verletzt

• Der Primärschlüssel der Relation ist aus den Feldern CD_ID und Track zusammengesetzt. (Grundsätzlich darf ein Primärschlüssel aus mehreren Attributen bestehen, jedoch entsteht daraus im genannten Beispiel ein Konflikt.)
• Die Felder Albumtitel, Interpret und Erscheinungsjahr sind vom Feld CD_ID abhängig, aber nicht vom Feld Track. Dieser (Punkt 2) verletzt die 2. Normalform, da die drei nicht-primären Attribute nicht nur von einem Teil des Schlüssels (hier CD_ID) abhängen dürfen. Wäre der Schlüssel nicht zusammengesetzt (siehe Punkt 1), so könnte dies nicht passieren.

Probleme, die sich daraus ergeben

Die Informationen aus diesen drei Feldern sind, wie am Beispiel der CD Not That Kind zu erkennen, mehrfach vorhanden, d. h. redundant. Dadurch besteht die Gefahr, dass die Integrität der Daten verletzt wird. So könnte man den Albumtitel für das Lied Not That Kind in I Don’t Mind ändern, ohne jedoch die entsprechenden Einträge für die Titel I’m Outta Love und Cowboys & Kisses zu ändern (Update-Anomalie).

In diesem Fall wäre ein Zustand erreicht, den man als Dateninkonsistenz bezeichnet. Über die komplette Tabelle betrachtet, „passen“ die Daten nicht mehr zusammen.

Lösung

Die Daten in der Tabelle werden in zwei Tabellen aufgeteilt: CD und Lied. Die Tabelle CD enthält nur noch Felder, die voll funktional von CD_ID abhängen, hat also CD_ID als Primärschlüssel. Auch der Albumtitel allein sei eindeutig, also ein Schlüsselkandidat. Da keine weiteren (zusammengesetzten) Schlüsselkandidaten existieren, liegt die Tabelle damit automatisch in der 2. Normalform vor. Die Tabelle „Lied“ enthält schließlich nur noch Felder, die voll funktional von CD_ID und Track abhängen, liegt also auch in der 2. Normalform vor. Mit Hilfe dieser verlustfreien Zerlegung sind auch die genannten Redundanzen der Daten beseitigt.

Das Attribut CD_ID aus der Tabelle Lied bezeichnet man als Fremdschlüssel, der auf den Primärschlüssel der Tabelle CD verweist. Zugleich stellen die Attribute CD_ID und Track den zusammengesetzten Primärschlüssel der Tabelle Lied dar.

Erläuterung

Eine Relation befindet sich in der 3. Normalform, wenn sie die 2. NF erfüllt und keine funktionalen Abhängigkeiten der Nichtschlüssel-Attribute (hellgraue Zellen in der Tabelle) untereinander bestehen. Solche Abhängigkeiten bezeichnet man auch als transitive Abhängigkeiten. Weiterhin müssen alle Nichtschlüssel voll funktional abhängig vom Schlüsselattribut sein.

Ein Attribut ${\displaystyle A_{2}}$ ist vom Schlüsselkandidaten ${\displaystyle P_{1}}$ transitiv abhängig, wenn es eine Attributmenge ${\displaystyle A_{1}}$ gibt, sodass ${\displaystyle (P_{1}\rightarrow A_{1})}$ und ${\displaystyle (A_{1}\rightarrow A_{2})}$.

Hierbei handelt es sich um eine Abhängigkeit, bei der ein Attribut ${\displaystyle A_{2}}$ über eine Attributmenge ${\displaystyle A_{1}}$ von einem Schlüsselkandidaten ${\displaystyle P_{1}}$ der Relation abhängig ist (ohne dass zugleich auch ${\displaystyle P_{1}}$ direkt von ${\displaystyle A_{1}}$ abhängig, also ${\displaystyle A_{1}}$ ein Schlüsselkandidat ist). Das heißt: Wenn die Attributmenge ${\displaystyle A_{1}}$ von der Attributmenge ${\displaystyle P_{1}}$ abhängt und Attribut ${\displaystyle A_{2}}$ von ${\displaystyle A_{1}}$, dann ist ${\displaystyle A_{2}}$ transitiv abhängig von ${\displaystyle P_{1}}$. Formal ausgedrückt: ${\displaystyle (P_{1}\rightarrow A_{1})\wedge (A_{1}\rightarrow A_{2})\Rightarrow P_{1}\rightarrow A_{2}}$.

Einfach gesagt: Ein Nichtschlüsselattribut darf nicht von einer Menge aus Nichtschlüsselattributen abhängig sein. Ein Nichtschlüsselattribut darf also nur direkt von einem Primärschlüssel (bzw. einem Schlüsselkandidaten) abhängig sein.

Siehe auch: Transitive Relation, Synthesealgorithmus

Negativbeispiel: 3NF verletzt

Offensichtlich lässt sich der Interpret einer CD aus der CD_ID bestimmen, das Gründungsjahr der Band/Interpreten hängt wiederum vom Interpreten und damit transitiv von der CD_ID ab.

Das Problem ist hierbei wieder Datenredundanz. Wird zum Beispiel eine neue CD mit einem existierenden Interpreten eingeführt, so wird das Gründungsjahr redundant gespeichert.

Lösung

Diese Lösung gilt nur, wenn man davon ausgeht, dass der Interpret weltweit eindeutig ist. Ansonsten müsste man eine synthetische ID in der Tabelle Künstler hinzufügen, die dann den Fremdschlüssel in der Tabelle CD stellt, wie folgt:

Die Relation wird aufgeteilt, wobei die beiden voneinander abhängigen Daten in eine eigene Tabelle ausgelagert werden. Der Schlüssel der neuen Tabelle muss als Fremdschlüssel in der alten Tabelle erhalten bleiben.

An der Tabelle „Lied“ wurden keine Änderungen bei der Übertragung in die 3. Normalform vorgenommen. Sie ist hier nur der Vollständigkeit halber gelistet.

Erläuterung

Ein Relationenschema ist in der Boyce-Codd-Normalform, wenn es in der 3NF ist und jede Determinante (Attributmenge, von der andere Attribute funktional abhängen) ein Schlüsselkandidat ist (oder die Abhängigkeit ist trivial).

Die BCNF (nach Raymond F. Boyce und Edgar F. Codd) verhindert, dass Teile zweier aus mehreren Feldern zusammengesetzten Schlüsselkandidaten voneinander abhängig sind.

Die Überführung in die BCNF ist zwar immer verlustfrei möglich, aber nicht immer abhängigkeitserhaltend. Die Boyce-Codd-Normalform war ursprünglich als Vereinfachung der 3NF gedacht, führte aber zu einer neuen Normalform, die diese verschärft: Eine Relation ist automatisch frei von transitiven Abhängigkeiten, wenn alle Determinanten Schlüsselkandidaten sind.

Negativbeispiel: BCNF verletzt

In diesem Beispiel gibt es eine einfache Datenbank, in der die Vereinszugehörigkeit von Sportlern gespeichert wird. Es sollen die folgenden Bedingungen gelten:

• jeder Verein bietet nur eine Sportart an.
• ein Sportler kann in verschiedenen Vereinen spielen, aber nur, wenn diese Vereine unterschiedliche Sportarten anbieten. Damit wird sichergestellt, dass der Sportler nie gegen einen Verein spielt, in dem er selbst Mitglied ist.

Aus den oben genannten Bedingungen folgt, dass das Attribut Sportart funktional abhängig vom Attribut Verein ist (Verein → Sportart), d. h. Verein ist eine Determinante. Jedoch ist Verein kein Schlüsselkandidat. Mögliche Schlüsselkandidaten sind {Name,Verein} und {Name,Sportart}. Eine Konvertierung in BCNF ist möglich, indem (Name, Verein) als Primärschlüssel verwendet und die Relation aufgeteilt wird:

Lösung

Zerlegungsalgorithmus

Es existiert ein Algorithmus, der relationale Schemata durch Zerlegung (engl. decomposition) in die Boyce-Codd-Normalform überführt. Alle Schemata werden dabei solange aufgespalten, bis keines mehr die BCNF bricht. Jede Aufspaltung erfolgt anhand einer, die BCNF verletzenden, funktionalen Abhängigkeit. Die Attribute der verletzenden Abhängigkeit bilden das erste neue Schema, und die restlichen Attribute plus die Determinante ein weiteres Schema. Die beiden neuen Schemata enthalten von den ursprünglichen funktionalen Abhängigkeiten lediglich solche, welche nur Attribute des jeweiligen Schemas nutzen, der Rest geht verloren.

Folgender Pseudocode beschreibt den Zerlegungsalgorithmus:

1:	Gegeben ist ein relationales Schema ${\displaystyle R=({\overline {R}},{\mathcal {F}})}$, mit der Menge aller Attribute ${\displaystyle {\overline {R}}}$ und der Menge der funktionalen Abhängigkeiten ${\displaystyle {\mathcal {F}}}$ über diesen Attributen.
2:	Die Ergebnismenge Dekomposition, bestehend aus den zerlegten Schemata, wird mit ${\displaystyle R}$ initialisiert.
3:	Solange es ein Schema ${\displaystyle S}$ in der Menge Dekomposition gibt, das nicht in der BCNF ist, führe folgende Zerlegung aus:
4:	Sei ${\displaystyle {\overline {X}}{\overline {Y}}\subseteq {\overline {S}}}$ eine Attributmenge für die eine funktionale Abhängigkeit ${\displaystyle {\overline {X}}\rightarrow {\overline {Y}}}$ definiert ist, welche der BCNF widerspricht.
5:	Ersetze ${\displaystyle S}$ in der Ergebnismenge Dekomposition durch zwei neue Schemata ${\displaystyle S_{1}=({\overline {X}}{\overline {Y}},{\mathcal {F}}_{1})}$, ein Schema bestehend nur aus den Attributen der Abhängigkeit, welche die BCNF ursprünglich verletzt hat; und ${\displaystyle S_{2}=(({\overline {S}}-{\overline {Y}})\cup {\overline {X}},{\mathcal {F}}_{2})}$, ein Schema mit allen Attributen, außer denen die nur in der abhängigen Menge ${\displaystyle {\overline {Y}}}$ und nicht in der Determinante ${\displaystyle {\overline {X}}}$ enthalten sind. Die Menge der funktionalen Abhängigkeiten ${\displaystyle {\mathcal {F}}_{1}}$ enthält nur noch die Abhängigkeiten, welche lediglich Attribute aus ${\displaystyle {\overline {X}}{\overline {Y}}}$ enthalten, entsprechendes gilt für ${\displaystyle {\mathcal {F}}_{2}}$. Damit fallen alle Abhängigkeiten weg, welche Attribute aus beiden Schemata benötigen.
6:	Ergebnis: Dekomposition – eine Menge von relationalen Schemata, welche in der BCNF sind.

Durchlauf des Algorithmus am obigen Beispiel (ohne Darstellung aller trivialen Abhängigkeiten):

• 1: R = ( { Name, Sportart, Verein }, { ( { Name, Sportart } → { Verein } ), ( { Verein } → { Sportart } ), ( { Name, Verein } → { Name, Verein } ) } )
• 2: Dekomposition = { R }
• 3: da R aus Dekomposition nicht die BCNF erfüllt mache folgendes:
  • 4,5: { Verein } → { Sportart } ist die Abhängigkeit, die die Verletzung der BCNF bedingt, damit ist ${\displaystyle S_{1}}$ = ( { Verein, Sportart }, { ( { Verein } → { Sportart }) } ) und ${\displaystyle S_{2}}$ = ( { Name, Verein }, { ( { Name, Verein } → { Name, Verein } ) } )
• 6: Ergebnis: ${\displaystyle {\text{Dekomposition}}:=\{S_{1},S_{2}\}}$

Unterschied zur 3NF

Die BCNF-Normalform ist strenger hinsichtlich der erlaubten funktionalen Abhängigkeiten: in Relationsschemata in 3NF können einige Informationen doppelt vorkommen, in der BCNF jedoch nicht.

Erläuterung

Ein Relationenschema ist dann in der 4. Normalform, wenn es in der BCNF ist und nur noch triviale mehrwertige Abhängigkeiten (MWA) enthält.

Einfach ausgedrückt: Es darf innerhalb einer Relation nicht mehrere 1:n- oder m:n-Beziehungen zu einem Schlüsselwert geben, die thematisch/inhaltlich nichts miteinander zu tun haben. Gehört etwa zu einem Schlüsselwert i-mal Attribut a, aber davon unabhängig auch j-mal Attribut b, ist die 4NF verletzt.

Anschaulich ausgedrückt: Die 4NF untersucht n-äre Beziehungen (mehr als zwei Tabellen stehen gleichzeitig in Beziehung) und ob diese korrekt modelliert wurden.

Negativbeispiel: 4NF verletzt

Zu einer Personennummer gibt es mehrere Haustiere und Fahrzeuge. Haustiere und Fahrzeuge einer Person haben aber prinzipiell nichts miteinander zu tun; man sagt, sie sind »voneinander unabhängig«. Als Primärschlüssel kommt nur eine Kombination aus allen drei Attributen in Frage, somit ist die Tabelle in 3NF. Personnummer → Haustier ist dabei eine mehrwertige Abhängigkeit, Personnummer → Fahrzeug auch. Da diese beiden MWAs unabhängig voneinander sind, ist die 4NF verletzt.

Die Beispielgrafik zeigt die fehlerhafte Modellierung der mehrwertigen Abhängigkeiten und die korrekte Lösung. Zwischen Haustier und Fahrzeug besteht keine Beziehung, somit war die Beziehung „besitzt“ falsch modelliert.

Lösung

Hinweis

Folgendes Relationsschema erfüllt die 4NF, obwohl auch hier mehrere MWAs vorliegen:

Person → Partner und Person → Kind sind zwar zwei MWAs, aber diese beiden sind auch untereinander abhängig: Partner → Kind. Solche untereinander abhängigen MWAs werden erst in 5NF gelöst.

Erläuterung

Eine Relation ist in 5NF, wenn sie in der 4NF ist und keine mehrwertigen Abhängigkeiten enthält, die voneinander abhängig sind.

Einfach ausgedrückt: Es darf innerhalb einer Relation nicht mehrere 1:n- oder m:n-Beziehungen zu einem Schlüsselwert geben, die thematisch/inhaltlich miteinander verknüpft sind. Gehört etwa zu einem Schlüsselwert i-mal Attribut a, aber davon abhängig auch j-mal Attribut b, ist die 5NF verletzt.

Die 5NF verlangt also vereinfachte Relationen, aus denen aber durch Projektions- und Verbundoperationen alle Informationen der ursprünglichen Relation wiederherstellbar sein müssen. Sie ist somit sehr generell gehalten und dadurch (vorerst) die letzte Normalform. So können Relationen in einzelne Abfragen aufgeteilt werden und durch spätere Verbundsoperationen wieder zusammengefügt werden, wobei eine Teilmenge des so genannten kartesischen Produkts entsteht.

Die 5NF unterstützt in soweit die Konsistenz, als dass sich durch das Aufteilen auch neue Kombinationen ergeben können, falls beim Hinzufügen einer Information sich theoretisch auch andere Kombinationen ergeben würden, die aber nicht berücksichtigt werden, wenn alle Attribute in einer einzigen Tabelle der Relation stehen.

Negativbeispiel: 5NF verletzt

Die folgende Relation zeigt, welche Lieferanten welche Bauteile an welches Projekt liefern können:

Die Relation muss weiter zerteilt werden, denn es ist auch vom Projekt abhängig, welche Teile bei diesem benötigt werden. Wichtig ist auch, dass sich die Relation aufteilen lässt, ohne dass Informationen verloren gehen.

Lösung

Um diese Relation in die 5. Normalform umzuwandeln, müssen drei Relationen erstellt werden (Lieferant–Teil, Teil–Projekt und Lieferant–Projekt).

• Welche Teile kann welcher Lieferant liefern?

• Welche Teile werden von welchem Projekt benötigt?

• Welche Projekte können von welchem Lieferanten beliefert werden?

Hinweis

Anders als bei der Umformung zwischen den bisherigen Normalformen wird durch diese Umwandlung etwas anderes durch die neuen Relationen ausgedrückt als zuvor in der 4. Normalform.

Das merkt man leicht, wenn man die drei Relationen aus dem Beispiel oberhalb wieder vereinigt:

Neu ist das Tupel: Müller – Nagel – Projekt 1.

Denn Müller könnte theoretisch das Projekt 1 mit Nägeln beliefern, da

• er auch Projekt 2 mit Nägeln beliefert und
• Projekt 1 auch Nägel benötigt (die jedoch bisher von Maier geliefert wurden).

Die Überführung in 5NF ist also nur dann möglich, wenn man die Möglichkeiten der Verbindungen aus drei Beziehungen ausdrücken möchte und nicht eine konkrete Verbindung zwischen den dreien haben möchte. Diese Aufteilung ergibt bei der richtigen Anwendung neue Informationen, wie hier, dass Müller Projekt 1 auch mit Nägeln beliefern könnte.