Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

04.01.1991 - 

Datenmodellierung: Die dritte Normalform reicht nicht (Teil 1)

Universalschlüssel-Tabellen sind nur bedingt einsetzbar

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.

Das Beispiel, das Date bringt, könnte uns in der Tat dazu bewegen, uns dieser Meinung anzuschließen. Date zitiert eine höchst ungewöhnliche organisatorische Regelung von Lieferverpflichtungen in einem Unternehmen, von der wir uns nicht vorstellen können, daß jemand mit gesundem Menschenverstand sie tatsächlich erlassen könnte. Der Datendesigner, der diese Regelung nicht vollständig erfaßt, läuft Gefahr, die fünfte Normalform (5NF) zu verletzen.

Leider ist die Verkennung ungewöhnlicher Zustände nicht die einzige Ursache für Verletzungen der 5NF. Auch wenn wir "normale" Zustände im Unternehmen haben, kann die Anwendung der üblichen Normalisierungsmethoden zu Verletzungen führen. In der Praxis ist eine synthetische Normalisierung die vorherrschende Methode, weil sie sich maschinell mit vertretbarem Aufwand durchfuhren läßt. Wir werden uns deshalb auf sie konzentrieren, obwohl unsere Schlüsse ebenfalls für die analytische Normalisierung gelten.

Mit der synthetischen Normalisierung lassen sich Datenbankschemata ermitteln, die garantiert der dritten Normalform entsprechen. (Für die vierte und fünfte Normalform gibt es noch keinen effizienten Algorithmus). Sie läuft, etwas grob dargestellt, in drei Schritten ab:

1. Zuerst werden alle Attribute mit ihren gegenseitigem funktionalen Abhängigkeiten zusammengestellt. Aus den funktionalen Abhängigkeiten werden die überflüssigen entfernt, also jene, die sich aus den übrigen ableiten lassen.

2. Dann werden die Relationenschemata gebildet. Alle Attribute, die von denselben Attributen abhängig sind, werden mit diesen in einem Schema zusammengefaßt. Die unabhängigen Attribute werden darin zu Schlüsselattributen.

3. Der dritte Schritt soll die sogenannte Verbundtreue gewährleisten. Die Normalisierung, auch die synthetische, geht von der Annahme aus, daß

sämtliche Informationen ursprünglich in einer einzigen Tabelle enthalten sind, die alle Attribute umfaßt (Universalrelation). Verbundtreue bedeutet, daß sich aus den Tabellen des Datenbank-Schemas diese Universalrelation wieder durch Verbundoperationen gewinnen lassen soll. Der Zweck der Verbundtreue ist also, daß von der ursprünglichen Information nichts durch die Normalisierung verlorengeht.

Ob ein Datenbank-Schema verbundtreu ist, läßt sich an den Schlüsseln der einzelnen Relationenschemata erkennen. Immer dann, wenn keines der Schemata einen Schlüssel für die Universalrelation (Universalschlüssel) enthält, ist Verbundtreue nicht gegeben. Die Theorie gibt uns auch eine Regel zur Herstellung der Verbundtreue vor: Wir fügen einfach ein Relationenschema mit einem Universalschlüssel hinzu. Wie wir sehen werden, liegt in diesem dritten Schritt die Crux der Normalisierungsalgorithmen.

Eine Fallstudie soll die Probleme verdeutlichen. Unsere Studie ist überschaubar, aber groß genug, um die in der Praxis entstehenden Probleme aufzuzeigen. Es handelt sich um das Datenmodell eines Reiseveranstalters, der eine Datenbank zur Verwaltung der Buchungen, zur Planung von Reisen und zur Planung und Verfolgung des Mitarbeitereinsatzes benötigt.

Bevor wir uns mit der Normalisierung dieser Datenbank beschäftigen, wollen wir uns die Zusammenhänge anhand eines Entity-Relationship-Modells klarmachen. Dieses Vorgehen hat den Vorteil, daß wir anschließend die Ergebnisse der beiden Ansätze vergleichen können.

Abbildung 1 zeigt das EIR-Diagramm, Abbildung 2 die dazugehörigen Attribute. Die unabhängigen Objektarten in diesem Modell sind Kunde, Reiseart, Bus, Mitarbeiter und Ort. Quartier ist eine ergänzende Objektart zu Ort (eine Charakteristik im Sinne von Codd [1]), alle anderen Objektarten sind Assoziationen, die ursprüngliche m:. .. :m-

Beziehungsarten zerlegen. Streckenort nimmt die Reiserouten für die Reisearten auf, in Reise sind die einzelnen Reisen mit ihren Terminen festgehalten. Schulung und Einweisung dienen der Einsatzplanung der Mitarbeiter.

Darin wird gespeichert, wann ein Mitarbeiter eine Schulung für eine bestimmte Reiseart beziehungsweise eine Einweisung in den Gebrauch eines bestimmten Busses erhalten hat.

Einsatz hält die tatsächlich geleisteten Einsätze der Mitarbeiter fest, und zwar differenziert nach Bussen und Reisen. Wenn ein Kunde eine Reise bucht, wird in Buchung ein Eintrag gemacht; gleichzeitig bekommt er bereits seine Quartiere auf allen Stationen der Reise zugeordnet. Hierfür dient die Objektart Quartierzuordnung.

Um ein EIR-Modell, wie das in den Abbildungen 1 und 2 dargestellt, in ein relationales Datenbank-Schema zu verwandeln, müssen wir nur die Objektarten in Tabellen verwandeln und für die Beziehungsarten Fremdschlüssel einfügen. In unserem Beispiel sind zufälligerweise bereits alle Fremdschlüssel vor handen, so daß die Liste von Abbildung 2 bereits das Datenbank-Schema darstellt.