Datenmodellierung: Die dritte Normalform reicht nicht (Teil 2)

Universalschlüssel-Tabellen sind nur bedingt einsetzbar

11.01.1991

Die Meinung, daß in der betrieblichen Praxis Relationen selten sind, die der dritten Normalform genügen, aber die fünfte verletzen, ist weit verbreitet. Als äußerst unwahrscheinlich wird das Auftreten solcher Relationen angesehen, die der vierten, aber nicht der fünften Normalform entsprechen. Otto Rauh zitiert in seinem Beitrag Chris Date, der in seiner "Einführung" sogar von pathologischen Fällen spreche. Der erste Teil dieses Beitrags erschien in der CW Nr. 1 vom 4. Januar 1991.

Wir wollen nun dasselbe Beispiel mit Hilfe der synthetischen Normalisierung lasen und die Ergebnisse der beiden Ansätze vergleichen. Das Ergebnis des ersten Schritts ist in Abbildung 3 dargestellt.

Sie enthält alle funktionalen Abhängigkeiten bereits in der gewünschten redundanzfreien Form. Wir müssen nur noch aus jeder Zeile ein Relationsschema machen.

Die Attribute auf der linken Seite machen wir zu Schlüsseln, die auf der rechten Seite zu Nichtschlüssel-Merkmalen. Alle Schemata liegen mindestens in der dritten Normalform vor. Ein maschineller Normalisierer hätte Probleme, die Schemata mit sinnvollen Namen auszustatten. Da uns die Zusammenhänge bereits aus dem E/R-Modell bekannt sind, können wir die Namen wählen, die wir dort für die Objektarten verwendet hatten (Abbildung 4).

Offensichtlich hat uns der zweite Normalisierungsschritt nahezu dasselbe Ergebnis gebracht wie die E/R-Modellierung. Allerdings fehlen drei Schemata, die im E/R-Modell als Objektarten enthalten sind, nämlich Quartierzuordnung, Einweisung und Schulung.

Wir kommen später darauf zurück und führen zunächst die Normalisierung zu Ende. Es muß nun im dritten Schritt geprüft werden, ob eines der Relationenschemata einen Universalschlüssel enthält. Machen wir uns zunächst klar, was einen solchen Schlüssel auszeichnet: Damit er jede Zeile der Universalrelation eindeutig identifizieren kann, müssen alle übrigen Attribute von ihm funktional abhängig sein. Ein Blick auf die Relationenschemata und die funktionalen Abhängigkeiten zeigt sofort, daß keines der Schemata einen solchen Schlüssel enthält. Wir müssen also ein Schema mit dem Universalschlüssel hinzufügen.

In unserem Beispiel ist es recht einfach, diesen Schlüssel zu finden. Wir brauchen nur die Vereinigung aller Schlüsselattribute des Datenbankschemas zu nehmen.

Da keines dieser Attribute von einem anderen funktional abhängig ist, ist auch keines überflüssig. Das zusätzliche Schema lautet also: UK (K#, R#, RTermin, M#, B #, Ortsname, Q #).

Damit ist die Synthese abgeschlossen. Auch UK befindet sich offensichtlich in der dritten Normalform, denn es enthält keinerlei Nichtschlüssel-Merkmale.

Es ist nicht leicht, UK einen Sinn zuzusprechen. Uns führt die Überlegung weiter, daß die Universalrelation auch Informationen enthalten kann, die sich nicht in funktionalen Abhängigkeiten niederschlagen. Solche Informationen wären in unserem vorläufigen Datenbankschema von Abbildung 4 nicht unbedingt berücksichtigt, weil dieses nur aufgrund der funktionalen Abhängigkeiten zusammengestellt wurde.

Die zusätzlichen Informationen können nur über UK in die Datenbank eingebracht werden. Beim Vergleich der Relationenschemata mit den Objektarten hatten wir bereits festgestellt, daß für die Objektarten Quartierzuordnung, Schulung und Einweisung keine Relationenschemata vorhanden waren. Wir sind damit in der Lage, dem Schema UK einen Sinn zu geben - oder sollten wir besser Unsinn sagen? Kommt in UK zum Beispiel die Zeile "K50, R22, 3.10.1990, M5, B10, Leipzig, Q7" vor, so bedeutet dies, daß

- der Kunde K50 auf der Reise R22/3.10.1990 in Leipzig im Quartier Q7 wohnt und

- Mitarbeiter M5 eine Schulung für die Reiseart R22 erhalten hat und

- M5 auf dem Bus B10 eingewiesen wurde.

Hätten Sie das vermutet? Wenn ja, dann könnten Sie als Datenbank-Anwender diese Relation mit den richtigen Daten versorgen. Allerdings hätten Sie noch mit weiteren Problemen zu kämpfen. Sie könnten zum Beispiel gar nicht eingeben, daß K50 bei der betreffenden Reise im Quartier Q7 wohnt, wenn nicht irgendein Mitarbeiter eine Schulung für die Reiseart R22 erhalten hat und auf irgendeinem Bus eingewiesen wurde. Da UK nur aus Schlüsselattributen besteht, müssen alle Attribute mit Werten versehen werden.

Formal können wir die Zusammenhänge in UK mit dem Begriff der Verbundabhängigkeit ausdrucken. Grob gesprochen bedeutet eine Verbundabhängigkeit, daß sich die Gesamtaussage einer Relation aus mehreren, durch ein logisches "Und" verbundenen Einzelaussagen ableiten läßt. Dem logischen "Und" entspricht in der Relationenalgebra die Verbundoperation.

Wenn wir eine Relation, in der eine Verbundabhängigkeit gilt, entsprechend den Einzelaussagen in schmälere Relationen zerlegen, so ist es möglich, durch Verbund wieder die Gesamtaussage abzuleiten.

UK läßt sich in drei Schemata zerlegen, aus denen sich durch Verbund wieder UK gewinnen läßt. Diese sind

(K#, R#, RTermin, Ortsname, Q#),

(M#, R#)

(M#, B#).

Ein Blick auf die Objektartenliste des E/R-Modells in Abbildung 2 (siehe CW Nr. 1 vom 4. Januar 1990, Seite 12) zeigt, daß diese Schemata genau den Objektarten Quartierzuordnung, Schulung und Einweisung entsprechen. Die Bedingungen der fünften Normalform verlangen in unserem Beispiel, daß die Zerlegung durchgeführt wird. Der Datenbank-Anwender hat es dann mit drei getrennten Tabellen zu tun und kann dem Kunden K50 auch dann ein Quartier zuordnen, wenn noch kein Mitarbeiter eine Schulung für dessen Traumreise erhalten hat.

Ist die Universalschlüsseltabelle unsinnig? Die Frage ist sicher berechtigt, wenn wir an die Fallstudie denken, sie läßt sich jedoch nicht allgemein beantworten. Die Universalschlüssel-Tabelle ist sozusagen eine Kiste, in die alle Informationen gesteckt werden müssen, welche in den übrigen Tabellen nicht untergebracht werden können. Das Problem ist, daß der Datenbank-Entwurf selbst keine Hinweise enthält, was in die Kiste gehört.

Eine Kiste mit Informationen

Wir kommen nochmals auf Dates Beispiel zurück, um diesen Sachverhalt genauer herauszustellen. Nehmen wir an, wir hätten eine Universalrelation (L#, T#, P# -> LName, TName, PName) mit den funktionalen Abhängigkeiten L# -> LName, T# -> TName und P# -> PName. L# steht darin für Lieferantennummer, T# für Teilenummer und P# für Projektnummer. Nach dem Synthesealgorithmus bilden wir daraus die Relationenschemata (L#: LName), T# -> TName) und (P# -> PName) und fügen, da keines der Schemata einen Universalschlüssel enthält, das Schema (L#, T#, P#) hinzu.

Was in (L#, T#, P#) zu speichern ist, kann aus den funktionalen Abhängigkeiten nicht ersehen werden. Wir kennen nur die Attribute, nicht aber die Gesetzmäßigkeiten, nach denen sie kombiniert werden.

Die von Date zitierte Regelung besagt zum Beispiel folgendes:

Wenn

a) Lieferant L1 das Teil T1 liefert und

b) L1 das Projekt P1 beliefert und

c) T1 für P1 geliefert wird, dann soll auch gelten

d) L1 liefert T1 für P1.

Wenn also die Zeile <L1, T1, P1> in der Tabelle vorkäme, wäre dies darauf zurückzuführen, daß die drei voneinander unabhängigen Tatsachen a, b und c alle gegeben sind. Formal ausgedruckt, liegt in (L#, T#, P#) die Verbundabhängigkeit (L#, T#), (L#, P#), (T#, P#) vor. Um die fünfte Normalform zu erreichen, müßten wir in (L#, T#), (L#, P#) und (T#, P#) zerlegen. Dies hätte den Vorteil, daß wir auch Einzeltatsachen wie a speichern könnten, ohne daß gleichzeitig b und c gegeben sind.

Besser mit E/R-Methode normalisieren

Die Gemeinsamkeit zwischen diesem Fall und dem Reisebüro. Beispiel liegt darin, daß mehrere unabhängige Aussagen in einer Tabelle zusammengeworfen werden oder - formal ausgedrückt - schädliche Verbund. Abhängigkeiten gegeben sind.

Wie wäre nun (L#, T#, P#) zu behandeln, wenn die genannte Regelung nicht vorhanden wäre, und Lieferungen wie in jedem normalen Unternehmen abgewickelt würden? Die Tabelle enthält in diesem Fall keine voneinander unabhängigen Aussagen und ist auch ungeteilt problemlos mit Daten zu versorgen. Die einzige Einschränkung, die bei der Eingabe der Lieferungen beachtet werden muß, ist die, daß jede Kombination aus L#, T# und P# nur einmal vorkommen darf.

Eine weitere Variante: Besteht zwischen Lieferanten, Teilen und Projekten überhaupt kein Zusammenhang, so könnte (L#, T#, P #) nur mit dem kartesischen Produkt aus L#, T# und P# gefüllt werden. Wir würden damit die Verbundtreue hinsichtlich der Universalrelation herstellen, aber diese selbst wäre sinnlos.

Die Universalschlüsseltabelle ist sinnvoll und gut zu verwenden, wenn sie nur einen einzigen unabhängigen Sachverhalt erfaßt. Sie ist unzweckmäßig, wenn sie mehrere unabhängige Sachverhalte aufnehmen soll, und sie ist unsinnig, wenn überhaupt keine Zusammenhänge zu berücksichtigen sind. Wie ist nun die im Titel gestellte Frage zu beantworten? Offensichtlich genügt die dritte Normalform nicht, wenn die Datenbank Informationen enthalten soll, die sich nicht in funktionalen Abhängigkeiten niederschlagen. Und wir können ergänzen, so paradox es klingen mag: Wir normalisieren besser mit der E/R-Methode als mit der Normalisierung selbst.