Databases Reference
In-Depth Information
Im Fall (3) könnte man die Tatsache, dass z.B. die Kombination der Attribute
{wochentag, raum, stundenblock}
eindeutig sein muss, als Schlüssel modellieren. Es
empfiehlt sich allerdings nicht, so eine Kombination als Primärschlüssel festzule-
gen, da dieser bei jeder Raumverlegung seinen Wert verliert. Sinnvoller ist es dann
schon, ein (unveränderliches) künstliches Attribut als Primärschlüssel einzuführen.
Relationen mit mehreren Schlüsselkandidaten, die jeweils aus mehreren Attribu-
ten bestehen, die sich teilweise überlappen, können Probleme aufwerfen, die sich
nicht mit den geschilderten Normalformen lösen lassen. Der interessierte Leser sei
z.B. an [Date00] und [Date92] verwiesen. Im nächsten Abschnitt zeigen wir eine
Relation, in der es mehrere gegenseitige Ausschlussbedingungen gibt. Für solche
Relationen können die im Folgenden dargestellten Begriffe sehr viel komplexer
sein, als es aufgrund der angegebenen Beispiele erscheint. Andererseits treten sol-
che komplexen Beispiele in der Praxis eher selten auf.
3.4.3 Normalformen, vereinfachte Version
Für die Darstellung von unternehmensrelevanten Daten durch Relationen gibt es
im Prinzip beliebig komplexe und geschachtelte Möglichkeiten. Ein Datenmodell
ist aber nur dann vernünftig handhabbar, wenn es gewissen Kriterien genügt: Es
muss den drei im Folgenden angegebenen Normalformen genügen. Es gibt darü-
ber hinaus weitere Normalformen, die aber in diesem Rahmen nicht behandelt
werden.
Nach einem sauberen Entwurf gemäß dem Entity-Relationship-Modell aus Kapitel
3.2 sind die erzeugten Relationen häufig schon in der dritten Normalform. Da
andererseits die Attribute im Entwurf nach dem ER-Modell nicht systematisch
untersucht werden, kann es hier noch unerwünschte funktionale Abhängigkeiten
geben, die durch die Normalisierung beseitigt werden.
Wir erläutern zuerst die drei Normalformen und führen anschließend an einem
Beispiel eine Normalisierung vollständig durch.
1) Normalform (1NF)
Eine Relation ist in der ersten Normalform, wenn die Werte der Attribute elementar
sind.
Damit sind als Attribute z.B. Mengen, Folgen und Arrays ausgeschlossen. Einige
Beispiele dafür werden am Ende dieses Abschnitts dargestellt.
Als elementar gelten aber auch komplexe (d. h. aus Komponenten zusammenge-
setzte) Datentypen wie Datum oder Uhrzeit, sofern in der Regel jeweils der
gesamte Wert relevant ist und nicht die Komponenten wie Tag, Monat, Jahr oder
Stunden und Minuten.
Über diese Frage entbrennt in der Literatur immer wieder ein heftiger Streit - ist
zum Beispiel ein Datum eine elementare Größe oder nicht? Wir legen hier als Krite-
rium für »elementar« an, dass unter dem Gesichtspunkt des Datenbanksystems die
