Datenbankdesign - Normalisierung

1
Datenbankdesign - Normalisierung
In einer Datenbank sollen Daten einer realen Welt abgebildet werden. Dazu ist es
notwendig, die Struktur des zu bearbeitenden Teilausschnittes in einem möglichst
getreuen Modell darzustellen.
Es gibt zwei grundlegende Methoden die dazu dienen, einen Teilausschnitt der
realen Welt zu modellieren und für die Darstellung in einer Datenbank aufzubereiten.
Das Ergebnis der Modellierung ist eine Menge von Relationen mit zugehörigen
Attributen. Diese können dann in die jeweilige Struktur der Datenbank transformiert
werden.
Die hier dargestellte Methode ist die Normalisierung. Die Methode der EntityRelationship-Modellierung soll hier nur erwähnt werden. Beide Methoden
unterscheiden sich in der Vorgehensweise.
Das Entity-Relationship-Modell ist eine Top-Down-Methode (von oben nach unten).
Sie wird eingesetzt, wenn die Menge der Attribute noch nicht klar ist, oder die
Datenbank mehrere hundert Attribute enthalten soll.
Die Normalisierung wird eingesetzt, wenn die Attribute und deren Abhängigkeiten
bekannt sind, und daraus die Relationen entwickelt werden sollen. Das heißt, es wird
von der untersten Ebene ausgegangen und zur obersten Ebene hin gearbeitet. Diese
Vorgehensweise wird Bottom-Up (von unten nach oben) genannt.
Unter Normalisierung versteht man das Aufteilen von Attributen in Relationen, so dass
diese den Normalisierungsregeln entsprechen. Warum ist das notwendig? Durch die
Normalisierung entstehen Relationen, die
•
Keine überflüssigen Redundanzen enthalten
Damit wird zum einen der Aufwand bei Änderungen in der Datenmenge
reduziert. Eine Kundenadresse muss nur einmal verändert werden, und nicht
an verschiedenen Stellen mehrfach. Zum anderen wird das Speichervolumen
der Daten minimiert, wenn Werte nur einmal abgespeichert werden, und nicht
x-mal.
•
Frei von Update-Anomalien sind
Unter Update-Anomalien versteht man nicht beabsichtigte Auswirkungen auf
2
die Daten bei Änderungsoperationen (Einfügen, Ändern, Löschen).
•
Die Notwendigkeit der Umstrukturierung von Relationen verringern
Bevor die Datenbank aufgebaut werden kann, muss die Struktur in Form von
Relationen und ihrer Attribute festgelegt sein. Diese sollte so definiert werden,
dass spätere Änderungen nicht mehr notwendig sind. Damit sind dann auch
entsprechende Anwendungsprogramme bezüglich der verwendeten
Datenstrukturen nicht so änderungsanfällig.
Es gibt heute mehr als fünf Normalisierungsregeln, die aber in der Praxis nicht alle von
Bedeutung sind. Diese fünf bauen hierarchisch aufeinander auf: 1NF, 2NF, 3NF, 4NF,
5NF, wobei NF für Normalform und BCNF für Boyce/Codd Normalform stehen.
In jeder Normalisierungsstufe werden die Relationen auf bestimmte Merkmale hin
untersucht. Erfüllt eine Relation diese Anforderungen nicht, wird sie „normalisiert“. Das
heißt, sie wird so zerlegt, dass die entstehenden Teilrelationen die Bedingungen
erfüllen.
Erste Normalform
Eine Relation ist in der ersten Normalform, wenn alle Attribute nur einen Wert
enthalten. D.h., in jedem Feld darf nur ein Wert stehen und jeder Satz hat eine feste
Länge.
Zweite Normalform
Eine Relation ist in der zweiten Normalform, wenn sie sich in der ersten Normalform
befindet und jede Attribut, das nicht zum Schlüssel gehört, vom gesamten Schlüssel
abhängig ist Es darf kein Attribut geben, das nur von einem Teil des Schlüssels
abhängig ist. Unter Abhängigkeit versteht man, dass zu einem Wert des einen
Attributes genau ein Wert des anderen Attributs (oder Schlüssel) gehört. Zum Beispiel
ist das Einstellungsdatum eines Angestellten abhängig von diesem (Namen oder
Personalnummer).
Dritte Normalform
Eine Relation ist in der dritten Normalform, wenn sie sich in der zweiten Normalform
befindet und es keine Abhängigkeiten zwischen Attributen gibt, die nicht zum
Schlüssel gehören. Sie würde diese Anforderung nicht erfüllen, wenn z.B. das Attribut
Einstellungsdatum vom Attribut Name abhängig wäre und beide Attribute nicht im
Schlüssel enthalten sind.
3
Um diese Regeln zu verdeutlichen, werden im folgenden Abschnitt die Relationen
eines Beispiels zur Auftragsverwaltung betrachtet:
Anhand einer „Beispielwelt“ wird die Vorgehensweise bei der Normalisierung
dargestellt. Die Beispielwelt ist ein Ausschnitt aus der Auftragsverwaltung
Ausgangspunkt ist eine Firma, die Sportartikel vertreibt. Sie hat einen Kundenstamm,
an den sie eine Reihe von Produkten verkauft. Die Kunden bestellen die Ware bei der
Firma über Aufträge. Ein Auftrag kann mehrere Positionen umfassen. Pro Position wird
ein bestimmter Artikel in der zu bestellenden Menge angegeben. Das heißt, dass pro
Auftrag verschiedene Produkte bestellt werden können. Ein Produkt hat keinen
festen Preis. Der Preis pro Produkt gilt immer nur für einen bestimmten Zeitraum. Dabei
kann zu einem Zeitpunkt nur genau ein Preis aktuell sein. Aus dieser Beschreibung
ergeben sich folgende Ausgangsrelationen:
Ausgangslage:
Aufträge:
AuftragsNr
KundenNr
BestellDatum
LieferDatum
RechnungsNr
Kommentar
PositionsNr
ProduktNr
Verkaufspreis
Menge
Produkte:
ProduktNr
Bezeichnung
Beschreibung
Listenpreis
Mindestpreis
4
PreisGültigAb
PreisGültigBis
Kunden:
KundenNr
KundenName
Ort
Straße
Kreditrahmen
Diese drei Relationen müssen nun anhand der oben gegebenen
Normalformdefinitionen untersucht werden.
Erste Normalform
Hier muss geprüft werden, ob die Werte der einzelnen Attribute der Relation mehr als
einen Wert enthalten können.
Aufträge
Als Beispielwerte können dienen:
Auftra
gNr
Kunde
nNr
Bestell
Datum
Liefer
Datum
Rechnun
gsNr
306
100
01.08.2
007
15.08.2
007
108281
Komment
ar
Positions
Nr
Produk
tNr
Kunde
nPreis
Meng
e
1
20037
6
99,90
15
Daraus ist ersichtlich, dass keines der Attribute mehr als einen Wert enthält. Das heißt,
alle Attribute sind atomar und die Sätze haben eine feste Länge, d.h. es existieren
keine Wiederholungsgruppen. Die Relation Aufträge ist deshalb in der 1.NF.
Produkte
Als Beispielwerte dienen hierzu:
Produkt
Nr
Bezeichnung
Beschreibung
ListenPrei
s
MindestPre
is
PreisGültigA
b
PreisGültigB
is
5
200376
Kaisers
Schlittschuh
e Herren
keine
Sonderkondition
en
99,90
78,00
01.01.200
7
31.12.200
7
Auch hier sind in allen Attributen nur einzelne Werte angegeben. Die drei Wörter
„Kaisers Schlittschuhe Herren“ des Attributs Bezeichnung stellen einen Wert dar und
nicht drei verschiedene Wertebelegungen. Damit ist auch diese Relation in der 1.NF,
Kunden
Beispielwerte hierzu sind:
KundenNr
KundenName
Ort
Straße
KreditRahmen
100
Inter Sport
Düsseldorf
Bilker Allee 120
5000
Jedes Attribut enthält nur einen Wert. Auch hier gilt wieder, dass die Werte „Inter
Sport“ und „Bilker Allee 120“ in sich immer nur einen Wert verkörpern, und nicht zwei
bzw. drei verschiedene Werte. Die Relation Kunden ist in der 1.NF,
Zweite Normalform
Für die 2.NF muss getestet werden ob alle Attribute der Relation, die nicht zum
Schlüssel gehören, vom gesamten Schlüssel abhängig sind oder nur von einem Teil
des Schlüssels. Dazu müssen zuerst einmal die Primärschlüssel (oben nur Schlüssel
genannt) bekannt sein.
Aufträge
Zum Schlüssel gehören die Attribute AuftragsNr und PositionsNr, da jede einzelne
Position innerhalb eines Auftrags eindeutig identifizierbar sein muss. Betrachtet man
nun die einzelnen Attribute in Bezug auf ihr Verhältnis zu den beiden
Schlüsselattributen, so fällt auf, dass die Attribute KundenNr, BestellDatum,
LieferDatum, RechnungsNr und Kommentar nur von der AuftragsNr abhängen, aber
nicht von der PositionsNr. Für alle Positionen eines Auftrages sind diese Daten gleich.
Deshalb ist die Relation Aufträge nicht in der 2.NF.
Um dies zu erreichen, muss die Relation normalisiert werden, d.h. sie muss zerlegt
werden. Da die oben genannten Attribute nicht von der PositionsNr abhängig sind,
teilt man die Relation einfach in zwei Relationen auf: eine Relation, bei der alle
6
Attribute von AuftragsNr und PositionsNr abhängig sind und eine andere, bei der die
Attribute nur an die AuftragsNr geknüpft sind. Damit ergeben sich:
Aufträge:
AuftragsNr
KundenNr
BestellDatum
LieferDatum
RechnungsNr
Kommentar
Positionen:
PositionsNr
ProduktNr
Verkaufspreis
Menge
Der Schlüssel der Relationen setzt sich aus den Attributen AuftragsNr und PositionsNr
zusammen. Alle Attribute dieser Relation sind von beiden Schlüsseln abhängig. Diese
Relation ist deshalb in der 2.NF. In der Relation Aufträge besteht der Schlüssel nur aus
der Spalte AuftragsNr.
Sie ist schon deshalb in der 2.NF, da es keine Möglichkeit gibt, dass die anderen
Attribute von wenigem als diesem Schlüssel abhängig sind.
Produkte
Der Schlüssel der Relation Produkte besteht aus den Attributen ProduktNr und
PreisGültigAb, da für jedes Produkt in Abhängigkeit vom Datum unterschiedliche
Preise vorgegeben sind.
Da die Attribute Bezeichnung und Beschreibung nur von der ProduktNr abhängig
sind, nicht aber vom PreisGültigAb, befindet sich diese Relation nicht in der 2.NF.
Daraus folgt, dass sie normalisiert werden muss. Aus der Relation Produkte ergeben
sich die beiden Relationen:
7
Produkte:
ProduktNr
Bezeichnung
Beschreibung
Preise:
ProduktNr
ListenPreis
MindestPreis
Menge
PreisGültigAb
PreisGültigBis
Der Schlüssel der Relation Produkte wird durch das Attribut ProduktNr gebildet. Bei
Preise setzt sich der Schlüssel aus ProduktNr und PreisGültigAb zusammen. Damit sind
beide Relationen in der 2. NF.
Kunden
Den Schlüssel der Relation Kunden ist die KundenNr. Da der Schlüssel nur aus einem
Attribut besteht, ist diese Relation on der 2.NF:
Dritte Normalform
Die Relationen sind in der 3.NF, wenn sie in der 2.NR sind und es keine
Abhängigkeiten zwischen den Attributen gibt, die nicht zum Schlüssel gehören.
Aufträge
Die Relation Auftrage befindet sich in der 3. NF, da es keine Abhängigkeiten
zwischen den Attributen gibt.
8
Positionen
Diese Relation ist in der 3. NF, da es keine Abhängigkeiten zwischen ProduktNr,
VerkaufsPreis und Menge gibt. Aus der ProduktNr selbst kann z.B. nicht der
VerkaufsPreis abgeleitet werden.
Produkte
Die Relation Produkte befindet sich in der 3. NF, da es keine Abhängigkeiten
zwischen den Attributen gibt.
Preise
Die Relation Preise ist ebenfalls in der 3. NF. Es gibt keine Abhängigkeiten zwischen
den Attributen ListenPreis, MindestPreis und PreisGültigBis.
Kunden
Da es auch hier keine Abhängigkeiten zwischen den Attributen gibt, ist diese
Relation in der 3. NF.
Damit soll dieses Beispiel zur Illustration der Normalisierung abgeschlossen sein. In der
Praxis wird aus den schon vorne genannten Gründen kaum über die 3. NF hinaus
normalisiert.
Merksatz: “The key, the whole key and nothing but the key - so help me Codd.”