Definition:
Das Normalisieren von Domänen ist eine analytische Methode, um ausgehend von der realen Welt durch immer weitergehendes Zerlegen eine formale Struktur als Modell dieser Wirklichkeit zu finden.
Eine Konferenz ist der Teil der realen Welt der betrachtet werden soll. Zu ihrer Organisation ist eine Menge der dafür anfallenden Daten so zu unterteilen, d.h. formell zu strukturieren, daß sich ein fehlerfreies Modell dieser Konferenz ergibt. Unter Verwendung dieses Modells wird anschließend die Organisation der Konferenz mittels eines DBMS unterstützt.
Zur Illustration der folgenden Ausführungen wird das oben bereits erwähnte Beispiel einer Konferenzorganisation gewählt. Hier wird nur ein Teil der gesamten Organisation betrachtet, der aber durchaus real ist (SC.01).
Gegeben sei eine Tabelle der Veranstaltungen mit den dazugehörigen Veranstaltunsleitern und –sekretären und deren Hotelsunterbringung. Diese Tabelle hat zunächst folgendes Aussehen:
VNU: Veranstaltungsnummer, Schlüsselfeld
PNU: Personennummer, Schlüsselfeld
HAN: Hotel - Anschrift, beinhaltet u.a. Anschriftenkopf, Ort, Straße
Der Aufbau einer Datenbank in der oben angeführten Form führt zu folgenden Problemen, die die Arbeit mit ihr erschweren, wenn nicht sogar unmöglich machen:
- Durch Mehrfachspeicherung derselben Daten wird sehr viel Platz benötigt. Allein die vollständige Adresse des Hotels "Leipzig" wird fünf mal gespeichert.
- Diese Mehrfachspeicherung führt zu Problemen bei Arbeiten an den Daten, wie Speichern, Löschen und Ändern. Soll der Name "Meier" z.B. in"Meyer" geändert werden, so muß das in allen drei Eintragungen für "Meier" erfolgen. Diese Forderung scheint in dem Beispiel trivial lösbar. Bei einer umfangreichen und komplexen realen Anwendung ist das aber nicht, oder nur mit hohem Aufwand abzusichern.
- Es bestehen der Realität widersprechende Zusammenhänge in der Datensammlung. Es ist logisch und organisatorisch zumindest bedenklich, die Anschrift eines Hotels durch den Titel einer Veranstaltung zu erfahren, deren Leader in diesem Hotel wohnt.
- Speziell für die Arbeit auf Kleinrechnern kommt hinzu, daß die Verwaltung derart langer Records nur eingeschränkt, wenn nicht ganz unmöglich ist (SC.02).
Zweck des Normalisierens ist es, diese Probleme durch folgende Punkte zu vermeiden:
- Elimination von Redundanz (Doppelspeicherung von Daten)
- Elimination von Anomalien im Zusammenhang mit Speicheroperationen (Speichern, Löschen. Ändern von Daten)
- Das eindeutige Festhalten realitätskonformer Sachverhalte, d.h. das Ermitteln von Domänen, die keine Möglichkeit bieten, realitätskonforme, funtionale Abhängigkeiten zu verletzen. (Ist bestimmend für die Richtigkeit einer Datenbank).
In dem Beispiel enthält jeder Datensatz "Veranstaltung" eine mehrstellige Menge "Funktion" mit dem Namen und dem Hotel des Funktionsträgers. Innerhalb des DBMS DTR sind diese Menge durch die Anwendung der "OCCURS" - Klausel aufbaubar. Beim Normalisieren besteht als erstes die Forderung nach Beseitigung dieser mehrstelligen Mengen, um die 1. Normalform zu erreichen.
Definition:
D.h., diese Domäne enthält keine mehrstelligen Mengen als Felder (Felder, die wieder Domänen sein können; in DTR: enthält keine Hierarchien, d.h. keine OCCURS - Klauseln).
Vorgehen:
- Starte mit der übergeordneten Domäne.
- Nimm ihr Primärschlüselfeld und erweitere damit jede unmittelbar untergeordnete Domäne (Sohndomäne) zu einer Selbständigen Domäne.
- Streiche alle untergeordneten Domänen aus der Vaterdomäne.
- Wende 1-3 solange auf die Sohndomäne an, bis alle untergeordneten Domänen verschwunden sind.
Erläuterung:
Domäne D mit Record R (S. F1, F2, H(U1, U2))
| Feld | Art |
|---|---|
| S: | Schlüsselfeld |
| F1, 2: | normale Felder |
| H: | Hierarchie mit den Feldern U1, U2 |
Zustand in der ersten Normalform:
| Domäne | Record |
|---|---|
| D1 | R1 (S, F1, F2) |
| D2 | R2 (S, U1, U2) |
Achtung:
Beispiel in der ersten Normalform:
- Domäne: "Veranstaltung"
- Domäne: "Funktion"
Bei der Verwendung mehrstelliger Mengen innerhalb eines Records ergibt sich das Problem des Neueintragens von Elementen dieser Mengen (z.B. 2. Secretary in Veranstaltung 1). Trotz dieser Angabe eines maximal möglichen Mengenumfangs, kann nie gesichert werden, daß später nicht doch die Eintragung eines Elements notwendig ist, mit dem diese Grenze überschritten wird. Sind die Domänen in der ersten Normalform, treten diese Probleme nicht mehr auf.
Durch Bildung einer Sicht auf die Domäne Veranstaltung und die Domäne Funktion und Verkopplung beider durch das Schlüsselfeld VNU ist die Erstellung der Ausgangstabelle wieder möglich.
Nach dem Erreichen der ersten Normalform sind die Redundanz, Speicher- und funktionalen Probleme noch nicht beseitigt. (Die Domäne "Veranstaltung" ist, wie später ersichtlich, bereits in der zweiten und dritten Normalform und wird nicht mehr betrachtet) Deshalb ist es notwendig, weiter zu normalisieren. Dazu werden die funktionalen Abhängigkeiten der Daten- von den Schlüsselfeldern in der Domäne "Funktion" betrachtet.
Das Feld "Funktion" hängt sowohl von der Veranstaltung (VNU), als auch von dem Funktionsträger (PNU) ab.
Die Felder Name, Hotel und HAN hängen dagegen nur vom Funktionsträger (PNU) ab, nicht jedoch von der Veranstaltung (VNU), in der diese Funktion ausgeübt wird.
Diese Unterscheidung ist bei der Erstellung der zweiten Normalform wichtig.
Definition:
D.h. es darf keine Teilabhängigkeit der Art geben, daß ein Feld (oder mehrere) nur von einem Teil der Schlüsselfelder abhängt und keine Abhängigkeit zum restlichen Teil der Schlüsselfelder hat.
Vorgehen:
Spalte diese Domäne in zwei Sohndomänen auf, so daß:
- eine Sohndomäne aus allen Schlüsselfeldern und den von allen Schlüsselfeldern abhängigen Feldern besteht.
- eine Sohndomäne aus einem Teil der Schlüsselfelder und den nur von diesem Teil abhängigen Feldern besteht.
Erläuterung:
Domäne D mit Record R (S1, S2, F1, F2, F3, F4, F5)
Fn: normale Felder mit den funktionalen Abhängigkeiten:
| Feld | funktional abhängig von |
|---|---|
| F1,2 | S1, S2 |
| F3 | S1 |
| F4,5 | S2 |
Zustand in der zweiten Normalform:
| Domäne | Record |
|---|---|
| D1 | R1 (S1, S2, F1, F2) |
| D2 | R2 (S1, F3) |
| D3 | R3 (S2, F4, F5) |
Beispiel in der zweiten Normalform:
- Domäne: "Funktion" (neu)
- Domäne: "Teilnehmer"
Deutlich zu sehen ist die Verringerung von Doppelspeicherungen und damit von unnötiger Redundanz und Speicheranomalien. Gleichzeitig hat sich auch die logische Struktur der DB verbessert. Alle Teilnehmer werden jetzt in einer Domäne gespeichert, unabhängig davon, ob sie während der Konferenz eine Funktion ausüben oder nicht. Dieser Teilbestand ist nur aus der dafür vorgesehenen Domäne "Funktion" zu erfahren.
Nach dem Erreichen der zweiten Normalform sind jedoch nicht alle Redundanzprobleme und Speicheranomalien beseitigt. Z.B. wird die Anschrift der Hotels bei jedem Teilnehmer und damit unnötig oft gespeichert (Hotel "Leipzig"). Außerdem besteht das logische Problem, daß auf die Anschrift eines Hotels über die Nummer eines in diesem Hotel wohnenden Teilnehmer zugegriffen werden muß.
Die Anschrift ist damit über den Hotelnamen transitiv abhängig von dem Schlüsselfeld (PNU).
Um zu Domänen in der dritten Normalform zu gelangen, muß diese Transitivität beseitigt werden.
Definition
D.h. es besteht keine wechselseitige Abhängigkeit von Nichtschlüsselelementarfeldern untereinander.
Da es, wie unten erläutert wird, zwei verschiedene Wege gibt, diese Transitivität zu beseitigen, ist die folgende Definition ebenfalls wichtig.
Definition
Vorgehen:
Spalte die Domäne so in zwei Sohndomänen auf, daß es zwischen den dann jeweils enthaltenen Nichtschlüsselelementarfeldern keine transitive Abhängigkeit mehr gibt und in keiner der Sohndomänen Felder vorkommen, die in der Vaterdomäne transitiv abhängig waren.
Erläuterung:
Domäne D mit Record R (S, F1, F2)
| Feld | Art |
|---|---|
| S: | Schlüsselfeld |
| F1, 2: | normale Felder |
und
| Feld | abhängig |
|---|---|
| F1 | = F1(S) |
| F2 | = F2 (F1) = F2 (F1 (S)) |
Transitivität: F2 über F1 von S abhängig
Zustand in der dritten Normalform:
| Domäne | Record |
|---|---|
| D1 | R1 (S, F1) |
| D2 | R2 (F1, F2) |
F1 ist jetzt Schlüsselfeld
Möglich, aber durch das Optimalitätskriterium verboten wäre auch:
| Domäne | Record |
|---|---|
| D1 | R1 (S, F1) |
| D2 | R2 (S, F2) |
(F2 hing in D2 transitiv von S ab)
Beispiel in der 3. Normalform:
Die Domäne "Funktion" aus der 2. Normalform ist bereits in der dritten Normalform. Betrachtet wird nur die Domäne "Teilnehmer" der 2. Normalform.
- Domäne "Teilnehmer" (neu):
- Domäne "Hotel":
- Domäne "Hotel 2":
Die Domäne "Hotel" sieht bei der Verletzung des Optimalitätskriteriums so aus:
Diese Anordnung ist, obwohl auch hier die dritte Normalform erreicht wurde, logisch unsinnig. Die Hotelanschrift wäre über die PNU eines in dem Hotel wohnenden Teilnehmers zu erfahren. Außerdem treten noch Mehrfachspeicherungen (Anschrift des Hotels "Leipzig") auf.
Auf diese Normalform nach Fagin wird nicht eingegangen. Sie scheinen für die bearbeiteten Probleme nicht notwendig zu sein und ihre Bedeutung ist in der Literatur zumindest umstritten (WE.01).
Zusammengefaßt wird hier das Konferenzbeispiel in der normalisierten Anordnung gezeigt.
- Domäne "Veranstaltung":
- Domäne "Funktion":
- Domäne "Teilnehmer"
- Domäne "Hotel":
