11.1 Redundanz trotz 2NF

Auch eine Relation, die in 2NF ist, kann noch Redundanzen und Anomalien aufweisen. Betrachten wir z.B. die Relation Kundenaufträge_2NF aus dem Datenmodell Aufträge.

Hier gelten folgende funktionalen Abhängigkeiten:

AuftrNr => AuftragsDatum

AuftrNr => KundenNr

AuftrNr => KundenName

KundenNr => KundenName

Die Relation ist ohne Zweifel in 2NF. Die trotzdem noch vorliegende Redundanz liegt darin, dass dieselbe Kundennummer natürlich sehr oft vorkommen kann und für jedes Vorkommen der Kundennamen erfasst wird.

Redundanz

Als besonderes Strukturmerkmal halten wir fest, dass ein Nichtschlüsselattribut (NSA), KundenNr, Determinante ist und dass eine „fortgesetzte“ funktionale Abhängigkeit besteht:

AuftrNr => KundenNr => KundenName

Eine solche „fortgesetzte“ funktionale Abhängigkeit wird transitive Abhängigkeit zwischen AuftrNr und KundenName genannt (in Anlehnung an den entsprechenden Begriff der Mathematik) und so dargestellt:

Transitive Abhängigkeit

AuftrNr --->::--> KundenName

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.

11.1.1 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, Vorname, 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 => Vorname

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 Grafik visualisiert auch sehr deutlich den Verstoß gegen die oben schon dargestellte Idealstruktur. Die entsprechende „störende“ funktionale Abhängigkeit wurde durch einen „Blitz“ markiert.

Auch hier ist also wieder ein Nichtschlüsselattribut (NSA) Determinante.

11.1.2 Beispiel Online-Datenbanken

Das folgende Beispiel betrifft wieder die Relation zu Online-Datenban­ken:

Online-Datenbanken_2NF(#Name, #NameKurz, Sprache, Typ, Region, Produzent, ProdLand)

Auch diese Relation ist in 2NF, da - wie auch aus dem FA-Diagramm ersichtlich - alle Nichtschlüsselattribute voll funktional abhängig sind vom Primärschlüssel. Trotzdem weist sie Strukturmängel auf, wie auch die folgende tabellarische Darstellung deutlich macht (einige Attribute wurden aus Platzgründen weggelassen / vgl. das FA-Diagramm zu dieser Lösung weiter unten, bei der Überführung in die 3NF):

Anmerkung: Bitte nicht irritieren lassen von den zwei Schlüsseln. Diese stellen keinen Verstoß gegen die 2NF dar, denn es sind zwei konkurrierende Schlüssel. Verstöße gegen die 2NF basieren immer auf einem (aus mehreren Attributen) zusammengesetzten Schlüssel.

Die Strukturmängel bestehen darin, dass Nichtschlüsselattribute voneinander funktional abhängig sind, so wie hier

Produzent => ProdLand

und dass dadurch eine transitive Abhängigkeit entsteht:

Name --->::---> ProdLand

In einem solchen Fall treten wieder die oben besprochenen Anomalien auf:

Anomalien am Beispiel ODB_2NF

• Ein neuer Produzent mit seinem Land kann - wegen der Forderung der Objektintegrität - nicht eingetragen werden, ohne dass nicht zumindest eine seiner Datenbanken bekannt ist (Einfüge-Anomalie)
• Verlegt ein Produzent seinen Hauptsitz in ein anderes Land, muss das neue Land nicht nur an einer Stelle, sondern an mehreren geändert werden (Aktualisierungs-Anomalie)
• Müssen wir die letzte uns bekannte Online-Datenbank eines Produ-zenten löschen, verlieren wir auch die Information über seine Existenz und das Land, in dem er ansässig ist (Lösche-Anomalie).

Die Ursache dafür ist wieder die Redundanz, die sich aus einem solchen Strukturmerkmal ergibt: Wie auch die obige tabellarische Darstellung zeigt, wird ProdLand für jede Datenbank des Produzenten erfasst.

Die Schwierigkeiten entstehen wiederum dadurch, dass NameProd zwar Determinante, aber nicht Schlüsselattribut ist. Dadurch wird mit NameProd und ProdLand die Beschreibung einer zweiten Objektklasse aufgenommen, die z.B. mit weiteren Adressangaben fortgesetzt werden kann.

Formal erfasst wird dieses Strukturdefizit über den oben schon eingeführten Begriff der transitiven Abhängigkeit. Es gelten ja die funktionalen Abhängigkeiten (mit der Annahme, dass jede Online-Datenbank nur einen Produzenten hat):

Name => Produzent

Produzent => ProdLand

Ebenso gilt natürlich, dass von der Online-Datenbank auf das Land des Produzenten geschlossen werden kann:

Name => ProdLand

Insgesamt lässt sich damit wieder eine „Kette“ aufstellen:

Name ---> Produzent ---> ProdLand

Die transitive Abhängigkeit ist formal wie folgt definiert:

Definition 11.1-1: Transitive Abhängigkeit
A und C seien Attribute einer Relation R. C heißt transitiv abhängig von A, in Zeichen: A --->::---> C, falls es ein Attribut B aus R gibt mit dem gilt: A => B => C (A <> B <> C)

Entsprechendes gilt für Attributkombinationen, wenn also für A, B oder C mehrere Attribute stehen.

11.1.3 Beispiel ODB-HOST

Auch im folgenden Beispiel (einer Version der Relation Angebot) liegt eine transitive Abhängigkeit vor:

ODB-HOST_2NF (#(NameODB, NameHost), RetrSpr, TypRetrSpr)

Folgende Annahmen sollen gelten:

• Ein Host verwendet u.U. für verschiedene Online-Datenbanken unterschiedliche Retrievalsprachen (Abfragesprachen für Online-Datenbanken).
• Retrievalsprachen werden eindeutig typisiert (z.B.: "geeignet für Zeitreihen", "geeignet für datensatzorientierte Datenbanken", „geeignet für Textdatenbanken“, usw.)

Dann gelten die folgenden funktionalen Abhängigkeiten:

#(NameODB, NameHost) => RetrSpr

#(NameODB, NameHost) => TypRetrSpr

RetrSpr => TypRetrSpr

und damit

#(NameODB, NameHost) --->::---> TypRetrSpr

Das FA-Diagramm:

Das FA-Diagramm visualisiert sehr deutlich den Verstoß gegen die 3NF durch die funktionale Abhängigkeit, die von einem NSA ausgeht.

Die Beispiele machen deutlich, wodurch die transitiven Abhängigkeiten Schwierigkeiten bereiten: durch sie wird die Beschreibung einer weiteren Objekt- oder Beziehungsklasse eröffnet (hier z.B. durch RetrSpr =  > TypRetrSpr die der Retrievalsprachen), zusätzlich zu der eigentlich in der Relation beschriebenen (hier die der Beziehung zwischen Online-Datenbanken und ihren Anbietern. Dies führt dann zu der oben beschriebenen Redundanz in den Daten.

11.2 Definition 3NF

Liegen solche Strukturen nicht vor oder wurden sie beseitigt, ist eine Relation in dritter Normalform:

Definition 11.2-1: Dritte Normalform (3NF)
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).

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 in 3NF genau dann wenn alle NSA gegenseitig unabhängig und voll abhängig sind vom Schlüssel.
• "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 1986, 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 Primärschlüssel ausgehen, so wie oben als Idealstrukturen gezeigt.

Eine Relation mit einer transitiven Abhängigkeit wird wie folgt normalisiert: 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.

Regel - Von der 2NF zur 3NF

Betrachten wir dies anhand der obigen drei Beispiele.

11.3 Beispiele

11.3.1 Kundenaufträge

Zuerst die Relation in textlicher Notation:

Kundenaufträge_2NF (#AuftragsNr, AuftragsDatum, KundenNr, KundenName)

Das Nichtschlüsselattribut als Determinante war KundenNr:

KundenNr => KundenName

Die transitive Abhängigkeit:

AuftragsNr --->::---> KundenName

Damit muss die Relation in folgende zwei zerlegt werden:

Aufträge_3NF (#AuftragsNr, AuftragsDatum, KundenNr)

Kunden_3NF (#KundenNr, KundenName)

Das Attribut KundenNr wird zu einem Fremdschlüssel.

11.3.2 Angestellte

Die Relation zu den Angestellten hat das Attribut Abteilung, das gleichzeitig NSA und Determinante ist, und damit eine transitive Abhängigkeit zwischen PersNr und AbtLeiter (vgl. auch das FA-Diagramm oben):

Angestellte_2NF (#PersNr, Abteilung, AbtLeiter, Name, Vorname, Alter, Wohnort, Straße)

Abteilung => AbtLeiter

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

Die Relation muss in die folgenden zwei Relationen zerlegt werden:

Angestellte_3NF (#PersNr, Abteilung, Name, Vorname, Alter, Wohnort, Straße)

Abteilung_3NF (#Abteilung, AbtLeiter)

Hier die FA-Diagramme der neuen Relationen:

11.3.3 Online-Datenbanken

In der oben vorgestellten Relation Online-Datenbanken ist Produzent(enname) die „störende“ Determinante:

Online-Datenbanken_2NF(#Name, #NameKurz, Sprache, Typ, Region, Produzent, ProdLand)

Für die Überführung in die 3NF wird diese Relation in die folgenden zwei Relationen zerlegt:

ONLINE_DATENBANKEN_3NF (#Name, #NameKurz, Sprache, Typ, Region, Produzent)

PRODUZENTEN_3NF (#Produzent, ProdLand)

Etwaige hinzukommende Adressangaben wären dann an die Relation Produzent_3NF anzuhängen. Damit ergeben sich folgende FA-Diagramme:

11.3.4 ODB-HOST

Das obige Beispiel

ODB-Host_2NF (#(NameODB, NameHost), RetrSpr, TypRetrSpr)

wird zerlegt in

ODB-Host_3NF (#(NameODB, NameHost), RetrSpr)

und

RetrSpr_3NF (#RetrSpr, TypRetrSpr)

11.3.5 Personal

Zum Abschluss dieses Abschnitts nun noch ein größeres Beispiel für den Weg von der 1NF zur 3NF – mit ungewöhnlichem Schlüssel.

Im Rahmen eines Modellierungsvorhabens habe sich folgende Relation ergeben:

Personal (PersonalNr, Name, Wohnort, AbtNr, AbtName, NameProj, Projektraum)

Bedeutung der Attribute:

PersonalNr: Personalnummer

Name: Namensangaben der Beschäftigten

Wohnort: Wohnort der Beschäftigten (Erster Wohnsitz)

AbtNr: Abteilungsnummer

AbtName: Namen der Abteilungen

NameProj: Namen von Projekten

ProjRaum:Raum, in dem die Projektleitung angesiedelt ist

Zur Semantik:

• Ein Mitarbeiter kann in mehreren Projekten sein
• Ein Mitarbeiter ist nur genau einer Abteilung zugeordnet
• Die Projektleitung ist in genau einem Raum angesiedelt.

Damit gelten folgende einfachen (-->) und vollen (=>) funktionalen Abhängigkeiten:

PersonalNr => Name

PersonalNr => Wohnort

PersonalNr => AbtNr

PersonalNr => AbtName

AbtNr => AbtName

AbtName => AbtNr

NameProj => Projektraum

PersonalNr, NameProj --> Name

PersonalNr, NameProj --> Wohnort

PersonalNr, NameProj --> AbtNr

PersonalNr, NameProj --> AbtName

PersonalNr, NameProj --> Projektraum

Ein Schlüssel ist so definiert, dass durch ihn jedes Tupel eindeutig identifiziert wird. Also müssen in ihm die Determinanten zusammengefügt werden, von denen alle übrigen Attribute funktionell abhängig sind. Somit wird hier die Attributkombination (PersonalNr, NameProj) Schlüssel. Von diesem Schlüssel ist allerdings kein Attribut voll funktional abhängig, wie auch das folgende FA-Diagramm zeigt:

Schlüssel-bestimmung

Eine solche Relation ist - die 1NF mal vorausgesetzt - nicht in 2NF. Ihre Überführung in 2NF führt – ausgedrückt in FA-Diagrammen - zu folgendem Ergebnis:

Die Relation Pers-Proj_2NF, die sozusagen die Projektmitarbeit festhält, dient als Verbindungsrelation zwischen den anderen beiden Relationen.

Pers-Proj_2NF und Projekte_2NF befinden sich auch gleich in 3NF, während Pers_Abt_2NF nochmals zerlegt werden muss (diesmal in textlicher Notation):

Pers_3NF(#PersonalNr, Name, Wohnort, AbtNr)

und

Abt_3NF(#AbtNr, #AbtName)

Bei Abt_3NF sind beide Attribute Schlüsselattribute. Eines davon wird als Primärschlüssel festgelegt. Insgesamt ergibt sich damit das folgende relationale Datenmodell:

11.4 Vertiefung - „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 eine Relation „eingefüllt“ wird.

Ist dies geschehen, entsprechen sich (Objekt-/Beziehungs-)Klasse und Relation noch sehr genau.

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.

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 beschrieben wurden.

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

11.5 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.