10.1 Redundanz trotz 2NF

Ganz abstrakt und auf das Wesentliche reduziert, drückt die folgende Abbildung das Problem bei Relationen aus, die nicht in 3NF sind: Es gibt eine Determinante, die nicht Schlüssel und nicht Schlüsselattribut ist (im ersten Beispiel D, im zweiten B). Da eine solche Determinante typischerweise mehrere gleiche Ausprägungen hat, wird die davon abhängige Attributsausprägung in C mehrfach erfasst.

Redundanz durch "NSA-Determinanten"

Solche "fortgesetzten" funktionalen Abhängigkeiten werden transitive genannt (vgl. unten). Relationen mit einem solchen Strukturmerkmal werden wie folgt normalisiert:

Transitive Abhängigkeit

Die Determinante, die nicht Schlüsselattribut ist, bildet zusammen mit dem von ihr abhängigen Attribut eine neue Relation. In der Ursprungsrelation muss diese Determinante (die nach der Normalisierung keine mehr ist) ebenfalls stehen bleiben. Dort wird sie zum Fremdschlüssel und sichert so den Zusammenhalt zwischen den Daten bzw. verhindert Datenverluste.

Regel -Von der 2NF zue 3NF

Hierzu die obigen Relationen in 3NF:

10.2 Beispiel Auftragsköpfe

Im vorigen Abschnitt ergab sich bei der Herbeiführung der 2NF u.a. die folgende Relation, die hier um ein Attribut und einige Tupel ergänzt wurde:

AuftrKöpfe (#AuftrNr, AuftrDatum, KuNr, KuName, Ort)

AuftrNr: Auftragsnummer

AuftrDatum: Datum des Auftrags

KuNr: Kundennummer

KuName: Kundenname

Sie hält Informationen zu Aufträgen fest, genauer zu den Auftragsköpfen, und zu den Kunden. Es gelten die folgenden funktionalen Abhängigkeiten:

AuftrNr => AuftrDatum

AuftrNr => KuNr

AuftrNr => KuName

KuNr => KuName

AuftrNr => Ort

KuNr => Ort

Die Relation ist ohne Zweifel in 2NF. Die trotzdem noch vorliegende Redundanz kommt daher, dass dieselbe Kundennummer natürlich sehr oft vorkommen kann und für jedes Vorkommen der Kundennamen und der Wohnort des Kunden erfasst wird. Die Ursache liegt darin, dass ein Nichtschlüsselattribut (NSA), KuNr, Determinante ist und dass es "fortgesetzte" funktionale Abhängigkeiten gibt:

Redundanz

AuftrNr => KuNr => KuName und

AuftrNr => KuNr => Ort

Die Bezeichnung transitive Abhängigkeit, erfolgt in Anlehnung an den entsprechenden Begriff der Mathematik.

transitive Abhängigkeit

Zur Erinnerung (an die Schulalgebra): transitiv bedeutet eine Beziehung über ein anderes Element hinweg. A und B sind in (irgendeiner) transitiven Beziehung (bez), wenn für diese gilt. A bez C bez B.

Sie wird so dargestellt:

AuftrNr --> :: --> KuName

AuftrNr --> :: --> Ort

Um dieses Defizit beseitigen zu können, muss die Relation in zwei Relationen zerlegt werden. Die "NSA-Determinante" zusammen mit dem funktional abhängigen Attribut Ort ergibt die neue Relation Kunden_5NF.

Kunden_5NF (#KuNr, KuName, Ort)

Die "alte" Relation verliert das Attribut KuName und behält die ursprüngliche Determinante KuNr als Fremdschlüssel.

Aufträge_5NF (#AuftrNr, AuftragsDatum, KuNr)

Die folgende Abbildung zeigt den ganzen Normalisierungsschritt einschließlich des dabei entstehenden kleinen Modellfragments.

KuNr: Kundennummer
KuName: Name des Kunden

10.3 Beispiel Angestellte

Das nächste Beispiel betrifft eine Relation mit Informationen zu Angestellten. Im Rahmen eines Modellierungsvorhabens habe sich folgende Relation ergeben:

Angestellte (#PersNr, Abteilung, AbtLeiter, Name, VName, Alter, Wohnort, Straße)

Mit der Festlegung, dass hier nur der Hauptwohnsitz erfasst wird, dass also jede/r nur eine Adresse hat, gelten folgende funktionalen Abhängigkeiten:

PersNr => Name

PersNr => VName

PersNr => Abteilung

PersNr => AbtLeiter

PersNr => Alter

PersNr => Wohnort

PersNr => Straße

Somit gilt:

PersNr => Abteilung => AbtLeiter

und damit die folgende transitive Abhängigkeit:

PersNr --->::---> AbtLeiter

Die Redundanz liegt hier in der Mehrfacherfassung des Zusammenhangs

Abteilung => AbtLeiter

Bei jedem Eintrag einer Abteilung wird auch der Abteilungsleiter eingetragen. Das folgende FA-Diagramm mit den vollen funktionalen Abhängigkeiten macht dieses Strukturmerkmal deutlich. Die störende funktionale Abhängigkeit ist hervorgehoben.

Störend: NSA als Determinante.

Die Beseitung erfolgt auf die oben vorgestellte Weise: Die Determinante (hier Abteilung) wird zum Schlüssel einer neuen Relation (Abteilungen), in die auch die von ihr abhängigen Attribute kommen.

Sie bleibt aber auch in der "alten" Relation zurück - als Fremdschlüssel.

10.4 Beispiel Aufträge / Artikel / Kunden

Zum Abschluss dieses Abschnitts nun noch ein größeres Beispiel für den Weg von der 1NF zur 3NF. Im Rahmen eines Modellierungsvorhabens habe sich folgende Relation ergeben:

Von 1NF zu 3NF

Aufträge_1NF (#(AuftrNr, PosNr), Menge, AuftrDatum, KuNr, KuName, ArtNr, ArtBez, Preis)

Wenn man sie betrachtet und dies vielleicht auch mit einem FA-Diagramm (vgl. die nächste Abbildung) erkennt man, dass gleich mehrere Strukturdefizite vorliegen:

Die funktionalen Abhängigkeiten von AuftrNr signalisieren den Verstoß gegen die 2NF und die daraus folgenden Redundanzen. Die transitiven Abhängigkeiten von KuNr und ArtNr zeigen zwei Verstöße gegen die 3NF, was ebenfalls zu Redundanzen führt.

Man erkennt diese Defizite entweder gleich im FA-Diagramm oder bei der Betrachtung der einfachen und vollen funktionalen sowie der transitiven Abängigkeiten:

AuftrNr, PosNr => ArtNr //in Ordnung

AuftrNr, PosNr => Menge //in Ordnung

AuftrNr, PosNr --> AuftrDatum //einfache funktionale Abhängigkeit: 2NF?

AuftrNr, PosNr --> KuNr //einfache funktionale Abhängigkeit: 2NF?

AuftrNr, PosNr --> KuName //einfache funktionale Abhängigkeit: 2NF?

AuftrNr, PosNr -->::--> ArtBez //transitive Abhängigkeit: 3NF?

AuftrNr, PosNr -->::--> Preis //transitive Abhängigkeit: 3NF?

AuftrNr => AuftrDatum

AuftrNr => KuNr

AuftrNr => KuName

KuNr => KuName //NSA als Determinante: 3NF?

ArtNr => ArtBez //NSA als Determinante: 3NF?

ArtNr => Preis //NSA als Determinante: 3NF?

Die Herbeiführung der 3NF erfolgt wie oben beschrieben. Für den Schlüssel der Ausgangsrelation und für jede Determinante, die nicht Schlüssel ist, wird eine eigene Relation angelegt und die Determinanten werden zu Schlüsseln:

Normalisierung zur 3NF

#(AuftrNr, PosNr) //Schlüssel der Relation Auftragsköpfe

#AuftrNr //Schlüssel der Relation Aufträge

#KuNr //Schlüssel der Relation Kunden

#ArtNr //Schlüssel der Relation Artikel

An diese Schlüssel werden die voll funktional abhängigen Attribute angehängt:

#(AuftrNr, PosNr), ArtNr, Menge

#AuftrNr, AuftrDatum, KuNr

#KuNr, KuName

#ArtNr, ArtBez, Preis

Danach werden die früheren Determinanten zu Fremdschlüsseln:

#(AuftrNr, PosNr), ArtNr, Menge

#AuftrNr, AuftrDatum, KuNr

#KuNr, KuName

#ArtNr, ArtBez, Preis

Mit den Relationenbezeichnungen liegt dann die Lösung vor. Vgl. die Abbildung. Alle Relationen sind auch bereits in 5NF, wie in der Abbildung angegeben.

Die nächste Abbildung zeigt die grafische Darstellung des Datenmodells. Hier wird insbesondere die durch die Zerlegung entstandene Notwendigkeit deutlich, für Auswertungen die Relationen zu verknüpfen.

Das ist sozusagen der Preis, den man für die redundanzfreien Datenbestände zahlen muss. Die Abbildung zeigt im unteren Teil auch die FA-Diagramme aller entstandenen Relationen. Alle sind in der 5NF und weisen auch darüberhinaus keine Defizite auf.

10.5 Definition 3NF

Hier nun die formale Fassung der oben eingeführten Definitionen. Zuerst die der transitiven Abhängigkeit:

A, B und C seien Attribute einer Relation R. C heißt transitiv abhängig von A, in Zeichen:

Definition: transitive Abhängigkeit

A --->::---> C,

falls es ein Attribut B aus R gibt mit dem gilt:

A => B => C (für A <> B <> C)

Entsprechendes gilt für Attributkombinationen, wenn also für A, B oder C mehrere Attribute stehen. Liegen solche Strukturen nicht vor oder wurden sie beseitigt, ist eine Relation in dritter Normalform:

Eine Relation ist in dritter Normalform (3NF), falls sie in 2NF ist und falls keine transitiven Abhängigkeiten zwischen dem Schlüssel und Nichtschlüsselattributen (NSA) bestehen (alternativ: ... falls kein NSA Determinante ist).

Definition: 3NF

Somit gilt:

• in einer 3NF-Relation ist kein Nichtschlüsselattribut (NSA) transitiv von einem Schlüssel abhängig, d.h. jedes NSA beinhaltet eine Eigenschaft, die dem zugrundeliegenden Objekt als Ganzes zukommt.
• Eine Relation ist genau dann in 3NF, wenn alle NSA gegenseitig unabhängig und voll abhängig vom Schlüssel sind.
• "A relation R is in third normal form (3NF) if and only if, for all time, each tuple of R consists of a primary key value that identifies some entity, together with a set of zero or more mutually independent attribute values that describe the entity in some way" [Date 1990, S. 367].

Damit ist dann der Bezug auf ein Objekt im relationalen Sinn voll hergestellt. Im FA-Diagramm äußert sich dies so, dass Pfeile nur vom Schlüssel ausgehen, so wie oben als Idealstrukturen gezeigt.

Relationale Objekt- und Beziehungsklasse

Ganz zu Beginn des Kapitels, bei der Einführung des Relationenbegriffs, wurde als ein Modellierungsschritt genannt, dass jede Objektklasse und jede Beziehungsklasse in genau eine Relation "eingefüllt" wird. Ist dies geschehen, entsprechen sich (Objekt-/Beziehungs-)Klasse und Relation noch sehr genau.

Objektklasse vs. Relation I

Wird dann die 1NF herbeigeführt sind u.U. Attribute mit Mehrfacheinträgen weggenommen und in eigene Relationen getan worden. Die Übereinstimmung von (Objekt-/Beziehungs-)Klasse und Relation ist nicht mehr voll gegeben. Die Klasse wird durch zwei oder drei Relationen beschrieben.

Objektklasse vs. Relation II

Genauso bei der Herbeiführung der 2NF und 3NF. Die Attribute der (Objekt-/Beziehungs-)Klasse werden, falls nötig, auf verschiedene Relationen verteilt, diesmal aber, weil in der Ausgangsrelation verschiedene Objekt-/Beziehungs­klassen zusammen beschrieben wurden.

Objektklasse vs. Relation III

Insgesamt gilt, dass die ursprüngliche Beschreibung der (Objekt-/Beziehungs-)­Klasse sich nach den Normalisierungsschritten nicht mehr in einer Relation, sondern in mehreren (unter Umständen zahlreichen) befindet.

Normalisierung durch Zerlegung

Soweit die Betrachtung der ersten drei Normalformen. Dies sind gleichzeitig auch die wichtigsten, zumindest für die Praxis der Datenhaltung. Wie zu erkennen ist bedeutet Normalisierung, dass Relationen in eine höhere Normalform gebracht werden und dass dies meist durch Zerlegung geschieht. Diese Zerlegung sollte aber gewissen Regeln genügen. Die wichtigsten seien hier nochmals zusammengefasst:

• Es darf keine Information verloren gehen. D.h., es muss durch entsprechende Schlüssel/Fremdschlüssel-Anordnung erreicht werden, dass die zerlegten Relationen gegebenenfalls wieder verknüpft werden können.
• Es darf durch die Zerlegung in keinem Bereich des Datenmodells ein Rückschritt bezüglich der Normalformen erfolgen.
• Nach jeder Zerlegung ist zu prüfen, ob die neu entstandenen Relationen nicht mit anderen, schon bestehenden, verschmolzen werden können. Grundsätzlich gilt, dass für eine relationale Objekt- oder Beziehungsklasse immer nur eine Relation vorhanden sein darf.