Die zweite Normalform besteht nun darin, eines der oben angesprochenen Defizite zu beseitigen. Nach dessen Beseitigung ist die Relation in 2NF.

10.1 Definition

Definition 10.1-1: Zweite Normalform (2NF)
Eine Relation ist in zweiter Normalform (2NF), falls jedes Nichtschlüsselattribut voll funktional abhängig ist vom (gesamten) Schlüssel.
Alternativ: ... falls kein (echtes) Schlüsselattribut Determinante für Nichtschlüsselattribute ist.

Somit müssen in einer Relation mit 1NF und ohne 2NF einfache funktionale Abhängigkeiten bestehen. Werden diese beseitigt, beschreibt jedes Attribut dann das Objekt, das durch den Primärschlüssel identifiziert wird und nicht ein anderes, das durch einen Teil des Schlüssels identifiziert wird. Ist diese Bedingung erfüllt, können die oben angeführten Anomalien nicht auftreten.

Relationen in 1NF, die nicht in 2NF sind, können in diese überführt werden. Dies erreicht man dadurch, dass die Attribute der Relation so in verschiedenen Relationen neu angeordnet werden, dass a) obige 2NF-Bedingung erfüllt ist und b) keine Information verloren geht.

10.2 Beispiele AUFTRÄGE und ANGEBOT

10.2.1 Aufträge

Betrachten wir nun nochmals obige Relation Aufträge_1NF.

Sie soll nun schrittweise in die höheren Normalformen gebracht werden.

Sie ist tatsächlich in 1NF und nicht in 2NF, da von dem Schlüsselattribut AuftragsNr funktionale Abhängigkeiten ausgehen, dieses also Determinante ist:

AuftragsNr => AuftragsDatum

AuftragsNr => KundenNr

AuftragsNr => KundenName

Damit bestehen auch einfache funktionale Abhängigkeiten, deren Existenz immer ein Hinweis auf einen Verstoß gegen die 2NF ist:

AuftragsNr, PosNr --> AuftragsDatum

AuftragsNr, PosNr --> KundenNr

AuftragsNr, PosNr --> KundenName

Ein solches Defizit ist in den FA-Diagrammen besonders leicht erkennbar.

Diese Relation wird nun schrittweise normalisiert (und nicht, wie oben in der Vertiefung, auf einmal). Zuerst nochmals die ursprüngliche Relation in textlicher Notation:

AUFTRÄGE_1NF (#(AuftragsNr, PosNr), ProduktNr, ProduktBez, Menge, AuftragsDatum, KundenNr, KundenName),

Um die 2NF zu erreichen, müssen die funktionalen Abhängigkeiten von Schlüsselteilen beseitigt werden. Dazu wird das Attribut (und Determinante) AuftragsNr mit allen von ihm funktional abhängigen Attributen in eine neue Relation Kundenaufträge gestellt. Diese ist dann auf jeden Fall in 2NF, eine evtl. höhere Normalform wird später geprüft.

Für diese Relation gilt: Schlüssel ist AuftragsNr, Nichtschlüsselattribute (NSA) sind AuftragsDatum, KundenNr, KundenName

Folgende funktionale Abhängigkeiten bestehen:

AuftrNr => AuftragsDatum

AuftrNr => KundenNr

AuftrNr => KundenName

KundenNr => KundenName

Die funktionalen Abhängigkeiten zeigen, dass die volle Abhängigkeit aller Nichtschlüsselattribute vom Schlüssel gegeben ist.

Die restlichen Attribute von Aufträge_1NF bilden dann eine Relation Auftragspositionen, in der die einzelnen Auftragspositionen festgelegt sind. Die AuftragsNr verbleibt hier ebenfalls und ist nun einfaches Schlüsselattribut und Fremdschlüssel.

Für diese Relation gilt: Schlüssel ist #(AuftragsNr, PosNr), Schlüsselattribute (SA) sind AuftragsNr, PosNr.

Außerdem bestehen folgende vollen funktionalen Abhängigkeiten:

AuftragsNr, PosNr => ProduktNr

AuftragsNr, PosNr => Menge

AuftragsNr, PosNr => ProduktBez

ProduktNr => ProduktBez

Die Verknüpfung der beiden nun entstandenen Relationen und damit die eventuelle Wiederherstellung der alten „Zusammenhänge“ erfolgt über das Attribut AuftragsNr, das ja in beiden Relationen vorkommt (àSQL-Notation):

Kundenaufträge.AuftragsNr

bzw.

Auftragspositionen.AuftragsNr

Damit ergibt sich auch der in Auftragspositonen angegebene Fremdschlüssel.

Die folgende Abbildung zeigt das sich daraus ergebende kleine Datenmodell.

10.2.2 ANGEBOT

Obige Relation

ANGEBOT_1NF (#(NameHost, NameODB), RetrSpr, DBTyp, Vertrag, Umfang),

muss in die zwei Relationen ODB_2NF und Angebot_2NF umgewandelt werden:

ANGEBOT_2NF (#(NameHost, NameODB), RetrSpr, Vertrag)

ODB_2NF (#NameODB, DBTyp, Umfang)

Wie bei allen Zerlegungen ist darauf zu achten, dass durch die Zerlegung keine Information verloren geht. In der Relation Angebot sind jetzt die Attribute, die das Angebotsverhältnis ("Host bietet Datenbank an") modellieren. Die Attribute von Relation ODB, die natürlich sehr schnell an Zahl zunehmen, beschreiben die Online-Datenbanken an sich.

Hier nochmals die Ausgangsrelation, danach die beiden in 2NF befindlichen Relationen.

Beide sind tatsächlich bereits in einer höheren Normalform. Die beiden neuen Relationen stellen ein kleines Datenmodell dar, das Online-Datenbanken genannt werden soll:

10.3 Faustregel

Die 2NF ist immer dann von vorneherein erfüllt, falls jeder Schlüssel aus einem einzigen Attribut besteht, denn in diesem Fall ist die funktionale Abhängigkeit immer die volle funktionale Abhängigkeit und da das Attribut Schlüssel ist, sind alle NSA voll von ihm abhängig (nicht aber die anderen Schlüsselattribute).

Eine Zerlegung einer Relation wie oben gezeigt wird Projektion genannt. Grundsätzlich gilt, dass jede Relation, die in 1NF ist und nicht in 2NF, durch Projektionen immer in 2NF-Relationen zerlegt werden kann. Die Originalrelation kann durch einen sog. Verbund wiederhergestellt werden (ein Verbund zweier Relationen entspricht der oben eingeführten relationalen Verknüpfung zweier Relationen).

10.4 Beispiel PROJEKTMITARBEIT

10.4.1 Variante 1

Ein weiteres Beispiel: Die Relation Projektmitarbeit_1NF erfasst Informationen zu Angestellten und ihrer Mitwirkung in Projekten:

Es bedeuten:

Funktion: Funktion der Person im Projekt

FunktionsBeschr: Genauere Klärung der Funktion / textlich

NameProj: Eindeutiger Name des Projekts

ProjDauer: Dauer des Projekts in Monaten

ProjZugeh: Anzahl Monate, die die jeweilige Person dem Projekt angehört

ProjBudget:Budget des Projekts in Millionen Euro

Die Abkürzung BPR bei der Funktionsspezifikation bedeuetet Business Process Reengineering.

Das folgende FA-Diagramm gibt die vollen funktionalen Abhängigkeiten an.

Daneben existieren die folgenden einfachen funktionalen Abhängigkeiten:

PersonalNr, NameProj --> Name

PersonalNr, NameProj --> ProjBudget

PersonalNr, NameProj --> ProjDauer

In welcher Normalform ist diese Relation? Die 1NF ist erfüllt. Ein Verstoß gegen sie wäre im FA-Diagramm nicht erkennbar, weshalb FA-Diagramme nur bei Relationen eingesetzt werden, die in 1NF sind.

Die 2NF ist nicht erfüllt, weil die NSA Name, ProjBudget und ProjDauer nicht voll f.a. sind vom Schlüssel.

Exkurs: Anomalien in diesem Beispiel

Einfüge-Anomalie

Wird ein neues Projekt gestartet, so kann es erst eingetragen werden, wenn die erste Person, die im Projekt mitarbeitet, ebenfalls bekannt ist.

Lösche-Anomalie

Angenommen, ein Projekt ist vorübergehend ohne Personal, z.B. weil die Mitarbeiter aus dem Projekt gekündigt haben, neue aber noch nicht bestimmt sind. Dann verschwindet, wenn die Projektzugehörigkeit der letzten Person gelöscht wird, auch die Information über das Projekt.

Aktualisierungsanomalien

Falls die ProjDauer eines Projekts verändert wird, muss diese Information nicht nur an einer Stelle geändert werden, sondern an mehreren. Gleiches gilt für das Projektbudget. Falls ein Mitarbeiter seinen Namen verändert, z.B. durch Heirat, gilt dasselbe.

Diese Relation wird normalisiert in die drei Relationen

Projektmitarbeit_2NF,

Projekte_2NF und

Personal_2NF.

Zuerst die tabellarische Darstellung der sich ergebenden Relationen:

Die durchgestrichenen Zeilen sind jetzt - gegenüber der Ausgangsrelation, überflüssig.

Hier die FA-Diagramme der neuen Relationen:

Das Datenmodell:

Textliche Darstellung:

PROJEKTMITARBEIT_2NF (#(PersonalNr, NameProj), Funktion, FunktBeschreibung, ProjZugeh)

PERSONAL (#PersonalNr, Name)

PROJEKTE (#NameProj, ProjDauer, ProjBudget)

10.4.2 Variante 2

Wie sehr eine kleine Veränderung der Semantik die Modellierung verändert, soll das folgende Beispiel zeigen. Es handelt sich um das obiges Beispiel mit folgenden Änderungen:

• Ein neues Attribut FunktionsSpez beschreibt die Tätigkeit der Person im jeweiligen Projekt.
• Eine Person kann in verschiedenen Projekten dieselbe Funktion haben
• Eine Person kann im selben Projekt mehrere Funktionen ausüben

Hier einige Beispielsdaten:

Schlüssel der Relation:

#(PersonalNr, NameProj, Funktion)

Die Gesamtheit der funktionalen Abhängigkeiten in dieser Relation zeigt das folgende FA-Diagramm.

Die Abhängigkeit des Attributs FunktionsSpez von den drei Attributen Funktion, PersonalNr und NameProj soll hier so sein. D.h. dass sich die Funktionsspezifikation erst aus der Kombination der drei entsprechenden Attributsausprägungen feststellen lässt.

Textliche Darstellung:

PROJEKTMITARBEIT_1NF (#(PersonalNr, NameProj, Funktion), FunktionsSpez, Name, ProjZugeh, ProjBudget, ProjDauer)

Die Überführung der Relation in die 2NF führt zu folgenden Relationen.

Nachfolgend – zur Verdeutlichung – zugehörige Tabellen mit Beispielsdaten.

Hier noch die übliche textliche Notation:

FUNKTIONSSPEZ (#(PersonalNr, Funktion, FunktionsSpez))

PROJEKTMITARBEIT (#(PersonalNr, NameProj), Funktion, ProjZugeh)

PERSONAL (#PersonalNr, Name)

PROJEKTE (#NameProj, ProjDauer, ProjBudget)

Zum Schluss das im Rahmen der Normalisierung entstandene Datenmodell.

10.5 Zerlegung und Zusammengehörigkeit

Der Normalisierungsschritt von der 1NF zur 2NF ist immer mit einer Zerlegung der Relation verbunden. Immer wird die „störende“ Determinante, die Teil des Schlüssels ist, mit den von ihr abhängigen Attributen herausgenommen und zu einer neuen Relation gemacht.

Auch die weiteren Normalisierungsschritte führen meist zu Zerlegungen. Für alle diese Zerlegungen sind nun zwei Regeln zu beachten:

• Die Zerlegung darf zu keinem Informationsverlust führen. Dies wird i.d.R. durch entsprechende Schlüssel/Fremdschlüssel realisiert.
• Kommt es vor, dass eine neu entstehende Relation eine Objekt- oder Beziehungsklasse beschreibt, die bereits in einer anderen Relation angelegt ist, dann werden die beiden Relationen zusammengeführt. Denn es gilt: nur eine Relation für eine Objekt- oder Beziehungsklasse!

Identisch sind zwei Relationen in diesem Sinne, wenn sie denselben Schlüssel haben.