Definition:
Ein Relationstyp ist in der 1. Normalform, wenn alle Attribute maximal einen Wert haben. Am Kreuzungspunkt einer Spalte mit einer Reihe darf also maximal ein Datenwert stehen. Das Nichtvorhandensein von Daten ist zulässig.
Mit anderen Worten: Wiederholungsgruppen sind nicht erlaubt. [3]
Ein kleines Beispiel:
Es sollen alle Bestellformulare eines Versandhandels in einer Datenbank
gespeichert werden. Eine einzelne Bestellung enthält die Kundennummer, das
Datum, die Auftragsnummer und natürlich die bestellten Artikel sowie deren
Anzahl (weitere evtl. notwendige Werte werden der Einfachheit einfach mal
unterschlagen). Siehe dazu auch folgende Tabelle Auftrag.
Auftrag | ||||
AuftragNr | Datum | KundenNr | ArtikelNr | Anzahl |
---|---|---|---|---|
4711 | 03.10.1999 | 12345 | 4692 | 5 |
0567 | 2 | |||
5671 | 3 | |||
0579 | 1 | |||
0815 | 01.03.1998 | 54321 | 8971 | 2 |
5324 | 5 | |||
0579 | 9 |
Um die Wiederholungsgruppen zu vermeiden, wird die Relation Auftrag in zwei
gesonderte Relationen aufgespalten. Dadurch würden sich die folgenden beiden
Tabellen ergeben:
best. Artikel | |
ArtikelNr | Anzahl |
---|---|
4692 | 5 |
0567 | 2 |
5671 | 3 |
0579 | 1 |
8971 | 2 |
5324 | 5 |
0579 | 9 |
Auftrag | ||
AuftragNr | Datum | KundenNr |
---|---|---|
4711 | 3.10.1999 | 12345 |
0815 | 1.3.1998 | 54321 |
Jetzt ist aber die Zuordnung verloren gegangen. Wer hat welche(n) Artikel
bestellt?
Dieses Problem ist einfach zu lösen: Wir müssen nur festhalten, welche Artikel zu welcher Bestellung gehören. Da die AuftragNr eindeutig ist, nehmen wir diese als Primärschlüssel für Auftrag. Nun fügen wir noch dieser Spalte entsprechend ihrer Werte der Relation best. Artikel hinzu, und schon haben wir wieder unsere Zuordnung.
In dieser Konstellation wird die Spalte AuftragNr in best. Artikel als Fremdschlüssel bezeichnet.
Weiterhin wurde schon gefordert, daß jede Zeile eindeutig ansprechbar sein muß. Wie aber ist das in unserem Fall der bestellten Artikel zu erreichen?
Nun, die AuftragsNr und die ArtikelNr kommen zwar mehrfach vor, trotzdem ist die Lösung aber ganz einfach: Die Kombination aus AuftragsNr und ArtikelNr muß eindeutig sein. Wenn wir also diese Kombination wählen, ist die o.g. Forderung erfüllt. Diese Kombination wird übrigens als zusammengesetzter Primärschlüssel bezeichnet.
Damit ergeben sich für unser Beispiel die folgenden beiden Relationen:
best. Artikel | ||
# AufragNr | # ArtikelNr | Anzahl |
---|---|---|
4711 | 4692 | 5 |
4711 | 0567 | 2 |
4711 | 5671 | 3 |
4711 | 0579 | 1 |
0815 | 8971 | 2 |
0815 | 5324 | 5 |
0815 | 0579 | 9 |
Auftrag | ||
# AuftragNr | Datum | KundenNr |
---|---|---|
4711 | 3.10.1999 | 12345 |
0815 | 1.3.1998 | 54321 |
[ top ]
Definition:
Ein Relationstyp ist in der 2. Normalform, wenn er in der 1. Normalform ist und jedes Attribut vom gesamten Primärschlüssel abhängt.
Relationstypen, die in der 1. Normalform sind, sind automatisch in der 2. Normalform, wenn ihr Primärschlüssel nicht zusammengesetzt ist. [3]
Ein kleines Beispiel:
Neben der AuftragNr, der ArtikelNr und der Menge soll auch der Hersteller des
Artikels gespeichert werden. Damit würde sich die folgende Artikel-Tabelle
ergeben.
AuftragNr und ArtikelNr sind der zusammengesetzte Primärschlüssel.
best. Artikel | |||
# AuftragNr | # ArtikelNr | Menge | Hersteller |
---|---|---|---|
4711 | 4692 | 5 | Blech-AG |
4711 | 0567 | 2 | Keramik GmbH |
4711 | 5671 | 3 | Baustoff KG |
4711 | 0579 | 1 | Keramik GmbH |
0815 | 8971 | 2 | Keramik GmbH |
0815 | 5324 | 5 | Baustoff KG |
0815 | 0579 | 9 | Keramik GmbH |
In diesem Beispiel ist das Attribut Hersteller nur vom Teilschlüssel
ArtikelNr und nicht auch von AuftragNr abhängig. Damit die Relation der 2. NF
genügt, muß das Attribut Hersteller aus der Relation herausgenommen und der
(neuen) Relation Artikel zugeordnet werden.
Daraus würden dann die folgenden zwei Relationen entstehen:
best. Artikel | ||
# AufragNr | # ArtikelNr | Anzahl |
---|---|---|
4711 | 4692 | 5 |
4711 | 0567 | 2 |
4711 | 5671 | 3 |
4711 | 0579 | 1 |
0815 | 8971 | 2 |
0815 | 5324 | 5 |
0815 | 0579 | 9 |
Artikel | |
# ArtikelNr | Hersteller |
---|---|
4692 | Blech-AG |
0537 | Keramik GmbH |
5671 | Baustoff KG |
0579 | Keramik GmbH |
8971 | Keramik GmbH |
5324 | Keramik GmbH |
[ top ]
Definition:
Die 3. Normalform ist erfüllt, wenn die 2. Normalform erfüllt ist und die Nicht-Schlüssel-Attribute funktional unabhängig voneinander sind.
Sind A und B Attribute eines Relationstyps, so ist B funktional abhängig von A, wenn für jedes Vorkommen ein und desselben Wertes von A immer derselbe Wert von B auftreten muß.
Eine funktionale Abhängigkeit kann auch von einer Gruppe von Attributen bestehen. [3]
Ein kleines Beispiel:
Zu den einzelnen Artikeln sollen die ArtikelNr, die Bezeichnung, der Hersteller
und die HerstellerNr gespeichert werden. Als Primärschlüssel wird die ArtikelNr
verwendet. Würde man die zusätzliche Spalte einfach in die vorhandene Tabelle
Artikel einfügen, ergäbe sich damit folgende Tabelle:
Artikel | |||
# ArtikelNr | Bezeichnung | HerstellerNr | Hersteller |
---|---|---|---|
4692 | Putzeimer | 5410 | Blech-AG |
0567 | Waschbecken | 5647 | Keramik GmbH |
5671 | Gummi | 6740 | Baustoff KG |
0579 | Teller | 5647 | Keramik GmbH |
8971 | Tasse | 5647 | Keramik GmbH |
5324 | Badewanne | 5647 | Keramik GmbH |
Wie man unschwer erkennen kann, ist der Herstellername funktional abhängig von der HerstellerNr und nicht von der ArtikelNr.
Was jetzt kommt, ist nicht schwer zu erraten: Die Tabelle Artikel wird in die beiden Tabellen Artikel und Hersteller aufgespalten. Das heißt, es ergeben sich folgende Tabellen:
Artikel | ||
# ArtikelNr | Bezeichnung | HerstellerNr |
---|---|---|
4692 | Putzeimer | 5410 |
0567 | Waschbecken | 5647 |
5671 | Gummi | 6740 |
0579 | Teller | 5647 |
8971 | Tasse | 5647 |
5324 | Badewanne | 5647 |
Hersteller | |
# HerstellerNr | Hersteller |
---|---|
5410 | Blech-AG |
5647 | Keramik GmbH |
6740 | Baustoff KG |
[ top ]
Definition:
Die 4. Normalform ist erfüllt, wenn die 3. Normalform erfüllt ist und wenn keine paarweise auftretenden mehrwertigen Abhängigkeiten vorhanden sind.
Sind A, B und C Attribute eines Relationstypes, so ist C mehrwertig abhängig von A, falls für jeden Wert von A für alle Werte von B, die zusammen mit diesem Wert von A auftreten, jeweils die gleiche Wertemenge von C auftreten muß. Für verschiedene Werte von A können unterschiedliche Wertemengen von C auftreten.
Bei Verstoß gegen die 4. Normalform können Gruppeninkonsistenzen auftreten. [3]
Kurzes Beispiel:
Disposition | ||
ArtikelNr | Lager | AuftragNr |
---|---|---|
04532 | SFO-4 | 2063 |
04532 | NYC-4 | 2063 |
04532 | SFO-4 | 2267 |
04532 | NYC-4 | 2267 |
53944 | ORD-1 | 2088 |
53944 | SFO-1 | 2088 |
53944 | LAX-1 | 2088 |
53944 | ORD-1 | 2070 |
53944 | SFO-1 | 2070 |
53944 | LAX-1 | 2070 |
In der Relation Disposition sind folgende Informationen festgehalten:
Es soll nicht ausgesagt werden, aus welchem Lager der Artikel für einen Auftrag kommt.
Folgende mehrwertige Abhängigkeiten liegen vor:
Für jeden Artikel muß für alle Aufträge, für die der Artikel bestellt ist, jeweils die gleiche Gruppe von Lagern auftreten.
Für jeden Artikel muß für alle Lager, in denen der Artikel aufbewahrt wird, jeweils die gleiche Gruppe von Aufträgen auftreten.
Damit die Relation der 4. NF genügt, muß sie in zwei neue Relationen (Artikel-Lager und Artikel-Auftrag) aufgespalten werden. Die erste Relation beschreibt, in welchem Zusammenhang Artikel und Lager stehen; die zweite den Zusammenhang zwischen Artikel und Auftrag.
[ top ]
Definition:
Ein Relationstyp ist in der 5. Normalform, wenn er in der 4. Normalform ist und er sich unter keinen Umständen durch Kombination einfacherer Relationstypen mit unterschiedlichen Schlüsseln bilden läßt. [3]
Das ist doch eigentlich selbsterklärend, oder? ;-)
[ top ]
Im Prinzip kann man die Tabellen, die man nach den fünf Normalisierungen erhalten hat, 1:1 in der DB verwenden. Es ist jedoch zu prüfen, ob man in der Normalisierungswut die Tabellen nicht zu sehr auseinandergerissen hat. Tabellen, die denselben Primärschlüssel haben, können ohne weiteres zusammengelegt werden, ohne gegen eine Normalisierungsform zu verstoßen.
Bei umfangreichen Datenbeständen mit hohen Zugriffszahlen kann es sich jedoch
teilweise empfehlen, aus Performancegründen wieder eine gewisse Denormalisierung
herzustellen. Da wir aber keine so hohen Zugriffszahlen und Datenbestände haben,
daß der Server überlastet werden könnte, können wir diesen Schritt getrost
übergehen.
Hierbei kann man sagen, daß es weniger problematisch ist, mit sich nicht
ändernden Daten gegen die Normalformen zu verstoßen. Bei diesen entfällt nämlich
das Problem, daß beim Ändern nicht alle Daten verändert werden und dadurch
Widersprüche entstehen. Trotzdem sollte man sich immer im klaren darüber sein,
wann man gegen die Normalformen verstoßen hat!
[ top ]