Normalisierung (Datenbank)

aus Wikipedia, der freien Enzyklopädie

Unter Normalisierung eines relationalen Datenbankschemas versteht man die schrittweise Zerlegung einer Relation (in Praxis: Tabelle) mittels Normalisierungsalgorithmen (siehe z. B. Synthesealgorithmus (3NF), Zerlegungsalgorithmus (BCNF)) in mehrere Relationen auf der Grundlage funktionaler Abhängigkeiten. Eine Normalisierung ist notwendig, um Redundanzen der Daten zu vermeiden, die einen erhöhten Speicherplatz benötigen, das Durchsuchen und Analysieren der Daten verlängern und bei der Änderung von Daten zu Inkonsistenzen führen können.

Das Relationenschema wird dabei in die erste, zweite, dritte usw. Normalform überführt. Damit eine Relation eine Normalform erfüllt, muss sie die Kriterien der gewünschten Normalform und die Kriterien der „vorherigen“ Normalformen erfüllen.

Neben den Abhängigkeiten, die für diese Normalformen „bereinigt“ wurden, gibt es noch weitere, wie zum Beispiel die Inklusionsabhängigkeit, die Template-Abhängigkeit und die Domain-Key-Normalform (DKNF).

Inhaltsverzeichnis 1 Allgemeines 2 Normalformen 2.1 Erste Normalform (1NF) 2.1.1 Beispiel 2.1.2 Verletzung der 1NF 2.1.3 Lösung 2.2 Zweite Normalform (2NF) 2.2.1 Beispiel 2.2.2 Verletzung der 2NF 2.2.3 Lösung 2.3 Dritte Normalform (3NF) 2.3.1 Beispiel 2.3.2 Verletzung der 3NF 2.3.3 Lösung 2.4 Boyce-Codd-Normalform (BCNF) 2.4.1 Beispiel 2.4.2 Verletzung der BCNF 2.4.3 Zerlegungsalgorithmus 2.5 Vierte Normalform (4NF) 2.5.1 Beispiel 2.5.2 Verletzung der 4NF 2.5.3 Lösung 2.5.4 Hinweis 2.6 Fünfte Normalform (5NF) 2.6.1 Beispiel 2.6.2 Verletzung der 5NF 2.6.3 Lösung 2.6.4 Hinweis 3 Bemerkungen 4 Merkspruch 5 Merkregeln 6 Quellen 7 Literatur 8 Weblinks

[Bearbeiten] Allgemeines

Bei der Normalisierung werden Spalten von Tabellen innerhalb der Datenbank in neue Spalten aufgeteilt, z. B. Adressen in Postleitzahl, Ort und Straße, oder diese Spalten mit anderen Tabellen verknüpft, z. B. ein Kunde über eine eindeutige Nummer mit einer Kundentabelle.

Der Sinn der Normalisierung besteht darin, Redundanzen (gleiche, mehrmals vorhandene Information) zu verringern und Anomalien (einander widersprechende Dateninhalte) zu verhindern, um so die Wartung einer Datenbank zu vereinfachen sowie die Konsistenz der Daten zu gewährleisten.

Wenn sich beispielsweise die Adresse eines Kunden ändert, so müsste man ggf. alle Datensätze nach diesem Kunden durchsuchen und die Adresseinträge aktualisieren. Bei einer normalisierten Datenbank gibt es dafür nur einen einzigen Eintrag. Außerdem ist der Speicherbedarf ungleich geringer, wenn der Datensatz einer Tabelle z. B. "Auftrag" auf einen Datensatz einer anderen Tabelle z. B. "Kunde" verweist, anstatt diesen gesamten Datensatz selbst zu enthalten.

Da es mehrere Aufträge vom gleichen Kunden geben könnte, würden ansonsten je Auftrag immer wieder die Daten des Kunden kopiert werden (Redundanz). Gäbe es außerdem in der Datenbank mehrere Adressen zu einem Kunden, könnte es zu widersprüchlichen oder falschen Ausgaben kommen - die Daten wären dann nicht konsistent.

In einigen Anwendungsfällen ist es aber auch sinnvoll, auf eine Normalisierung zu verzichten oder die Normalisierung durch eine Denormalisierung rückgängig zu machen, um

• die Performance (Verarbeitungsgeschwindigkeit) zu erhöhen oder
• Anfragen zu vereinfachen und damit die Fehleranfälligkeit zu verringern.

[Bearbeiten] Normalformen

Zur Zeit gebräuchliche Normalformen sind:

• 1. Normalform (1NF)
• 2. Normalform (2NF)
• 3. Normalform (3NF)
• Boyce-Codd (BCNF)
• 4. Normalform (4NF)
• 5. Normalform (5NF)

Im Zuge der mathematischen Erschließung von Datenbanken gibt es zwar im theoretischen Bereich noch einige weitere Normalformen, in der Praxis wird allerdings meist versucht, die 3NF zu erfüllen, weil bei höheren Normalformen der Erhalt der funktionalen Abhängigkeiten der Ursprungsrelation nicht mehr garantiert werden kann.

Sie dienen der Beurteilung der Qualität des betrachteten Datenbankschemas.

Nachfolgend werden die Kriterien der jeweiligen Normalformen erklärt. Dabei ist zu beachten, dass jede Normalform die Kriterien der vorherigen Normalformen mit einschließt.

[Bearbeiten] Erste Normalform (1NF)

Jedes Attribut der Relation muss einen atomaren Wertebereich haben. Das heißt, zusammengesetzte, mengenwertige oder geschachtelte Wertebereiche (relationenwertige Attributwertebereiche) sind nicht erlaubt. Kurz: Kein Attributwertebereich kann in weitere (sinnvolle) aufgespalten werden (z. B.: Adresse darf nicht als Attribut verwendet werden, sondern muss in PLZ, Ort, Straße, Hausnummer zerlegt werden).

In der Praxis werden Abfragen der Datenbank durch die 1NF erleichtert, da die Attributwertebereiche atomar sind.

[Bearbeiten] Beispiel

CD_Lieder

CD_ID	Album	Titelliste
4811	Anastacia - Not That Kind	{1. Not That Kind, 2. I'm Outta Love, 3. Cowboys & Kisses}
4712	Pink Floyd - Wish You Were Here	{1. Shine On You Crazy Diamond}

[Bearbeiten] Verletzung der 1NF

• Das Feld Album beinhaltet die Attributwertebereiche Interpret und Albumtitel.
• Das Feld Titelliste enthält eine Menge von Titeln.

Dadurch hat man ohne Aufspaltung folgende Probleme bei Abfragen:

• Zur Sortierung nach Albumtitel muss das Feld Album in Interpret und Albumtitel aufgeteilt werden.
• Die Titel können (mit einfachen Mitteln) nur alle gleichzeitig als Titelliste oder gar nicht dargestellt werden.

[Bearbeiten] Lösung

CD_Lieder

CD_ID	Albumtitel	Interpret	Track	Titel
4811	Not That Kind	Anastacia	1	Not That Kind
4811	Not That Kind	Anastacia	2	I'm Outta Love
4811	Not That Kind	Anastacia	3	Cowboys & Kisses
4712	Wish You Were Here	Pink Floyd	1	Shine On You Crazy Diamond

Die Attributwertebereiche werden in atomare Attributwertebereiche aufgespalten:

• Das Feld Album wird in die Felder Albumtitel und Interpret gespalten.
• Das Feld Titelliste wird in die Felder Track und Titel gespalten sowie auf mehrere Datensätze aufgeteilt.

Da jetzt jeder Attributwertebereich atomar ist sowie die Tabelle einen eindeutigen Primärschlüssel (Verbundschlüssel aus den Spalten CD_ID und Track) besitzt, befindet sich die Relation in 1NF.

[Bearbeiten] Zweite Normalform (2NF)

Eine Relation ist in zweiter Normalform, wenn die erste Normalform vorliegt und alle Nichtschlüsselattribute von jedem Schlüsselkandidaten voll funktional abhängig sind.

Einfacher gesagt: Alle nicht primären Attribute (nicht Teil des Schlüssels) sind vom ganzen Schlüssel abhängig, nicht von nur einem Teil des Schlüssels. (Genau das ist die „voll funktionale Abhängigkeit“: Ein Attribut ist vom ganzen Schlüssel abhängig.)

Diese informelle Definition kann wie folgt präzisiert werden:

Eine Relation ist genau dann in zweiter Normalform, wenn sie

1. in der ersten Normalform ist und
2. für jeden Schlüsselkandidaten (Key Candidate, KC) und jedes Attribut a der Relation gilt:
   • a gehört zu KC oder
   • a ist nicht von einer Teilmenge von KC abhängig.

Man sagt: a ist voll funktional abhängig von jedem Schlüsselkandidaten (wobei der Schlüsselkandidat KC auch durch die Kombination mehrerer Attribute gebildet werden kann).

Praktisch wird Datenredundanz und die damit einhergehende Gefahr der Dateninkonsistenz durch Anomalien behoben (aber nur teilweise, siehe spätere Normalformen). Nur logisch zusammenhängende Daten finden sich in einer Relation. Dadurch fällt das Verständnis der Datenstrukturen leichter.

[Bearbeiten] Beispiel

CD_Lieder

CD_ID	Album	Interpret	Track	Titel
4811	Not That Kind	Anastacia	1	Not That Kind
4811	Not That Kind	Anastacia	2	I'm Outta Love
4811	Not That Kind	Anastacia	3	Cowboys & Kisses
4712	Wish You Were Here	Pink Floyd	1	Shine On You Crazy Diamond

[Bearbeiten] Verletzung der 2NF

Der Primärschlüssel der Relation ist aus den Feldern CD_ID und Track zusammengesetzt. Die Felder Album und Interpret sind zwar vom Feld CD_ID abhängig, nicht aber vom Feld Track.

Probleme, die sich daraus ergeben:
Die Informationen aus diesen beiden Feldern sind, wie am Beispiel der CD Not That Kind zu erkennen, mehrfach vorhanden, d.h. redundant. Dadurch besteht die Gefahr, dass die Integrität der Daten verletzt wird. So könnte man den Namen der CD für das Lied Not That Kind ändern, ohne jedoch die passenden Einträge bei den Liedern I'm Outta Love und Cowboys & Kisses zu ändern (Update-Anomalie).

CD_Lieder (inkonsistent)

CD_ID	Album	Interpret	Track	Titel
4811	Not That Kind Album	Anastacia	1	Not That Kind
4811	Not That Kind	Anastacia	2	I'm Outta Love
4811	Not That Kind	Anastacia	3	Cowboys & Kisses
4712	Wish You Were Here	Pink Floyd	1	Shine On You Crazy Diamond

In diesem Fall ist ein Zustand erreicht, den man als Dateninkonsistenz bezeichnet. Über die komplette Tabelle betrachtet, „passen“ die Daten nicht mehr zusammen.

[Bearbeiten] Lösung

Die Daten in der Tabelle werden in zwei Tabellen aufgeteilt: CD und Lieder. Die Tabelle CD enthält nur noch Felder, die voll funktional von CD_ID abhängen, hat also nur noch CD_ID als Primärschlüssel und liegt damit automatisch in der 2. Normalform vor. Die Tabelle Lieder enthält schließlich nur noch Felder, die voll funktional von CD_ID und Track abhängen, liegt also auch in der 2. Normalform vor. Mit Hilfe dieser verlustfreien Zerlegung sind auch die genannten Redundanzen der Daten beseitigt.

CD CD_ID Album Interpret 4811 Not That Kind Anastacia 4712 Wish You Were Here Pink Floyd

Lieder CD_ID Track Titel 4811 1 Not That Kind 4811 2 I'm Outta Love 4811 3 Cowboys & Kisses 4712 1 Shine On You Crazy Diamond

Das Attribut CD_ID aus der Tabelle Lieder bezeichnet man als Fremdschlüssel, der auf den Primärschlüssel der Tabelle CD verweist. Zugleich stellen die Attribute CD_ID und Track den zusammengesetzten Primärschlüssel der Tabelle Lieder dar.

[Bearbeiten] Dritte Normalform (3NF)

Die dritte Normalform ist erreicht, wenn sich die Relation in 2NF befindet und man in den Relationen keine transitiven Abhängigkeiten hat. Hierbei handelt es sich um eine Abhängigkeit, bei der ein Attribut A₂ über ein anderes Attribut A₁ vom Primärschlüssel P₁ der Relation abhängig ist (ohne dass zugleich auch A₂ direkt von P₁ abhängig ist). D. h. wenn Attribut A₁ von Attribut P₁ (dem Primärattribut) abhängt und Attribut A₂ hängt von A₁ ab, dann ist A₂ transitiv abhängig von P₁. Formal ausgedrückt: .

Einfach gesagt: Kein Nichtprimärattribut darf von einer Menge abhängig sein, die ausschließlich aus Nichtprimärattributen besteht.

Siehe auch: Transitivität (Mathematik), Synthesealgorithmus-Normalform

Praktischer Nutzen:
Transitive Abhängigkeiten sind sofort ersichtlich, ohne dass man die Zusammenhänge der Daten kennen muss. Sie sind durch die Struktur der Tabellen wiedergegeben.

[Bearbeiten] Beispiel

CD

CD_ID	Album	Interpret	Gründungsjahr
4811	Not That Kind	Anastacia	1999
4713	Bad	Michael Jackson	1999
4712	Wish You Were Here	Pink Floyd	1965

[Bearbeiten] Verletzung der 3NF

Offensichtlich lässt sich der Interpret einer CD aus der CD_ID bestimmen, das Gründungsjahr der Band hängt dagegen vom Interpreten und damit nur transitiv von der CD_ID ab.

Das Problem ist hierbei wieder Datenredundanz. Wird zum Beispiel eine neue CD mit einem existierenden Interpreten eingeführt, so wird das Gründungsjahr zweimal gespeichert.

[Bearbeiten] Lösung

CD CD_ID Album Interpret 4811 Not That Kind Anastacia 4713 Bad Michael Jackson 4712 Wish You Were Here Pink Floyd

Künstler Interpret Gründungsjahr Anastacia 1999 Michael Jackson 1999 Pink Floyd 1965

Die Relation wird aufgeteilt, wobei die beiden voneinander abhängigen Daten in eine eigene Tabelle ausgelagert werden. Der Schlüssel der neuen Tabelle muss als Fremdschlüssel in der alten Tabelle erhalten bleiben.

[Bearbeiten] Boyce-Codd-Normalform (BCNF)

Die Boyce-Codd-Normalform (nach Raymond F. Boyce und Edgar F. Codd) war ursprünglich als Vereinfachung der dritten Normalform gedacht, führte aber zu einer neuen Normalform, die die 3NF verschärft. Alle Relationen können zwar in die dritte Normalform übertragen werden, aber nicht jede in die Boyce-Codd-Normalform.

In der BCNF soll verhindert werden, dass Teile zweier aus mehreren Feldern zusammengesetzter Schlüsselkandidaten voneinander abhängig sind.

Eine Relation ist in BCNF, wenn sie die Voraussetzungen der 3NF erfüllt und gleichzeitig jede Determinante (Menge von Attributen, von denen andere voll funktional abhängen) Schlüsselkandidat ist.

Die Überführung in die BCNF ist zwar immer verlustfrei möglich, aber häufig nicht abhängigkeitserhaltend.

[Bearbeiten] Beispiel

In diesem Beispiel gibt es eine einfache Datenbank, in der die Vereinszugehörigkeit von Sportlern gespeichert wird. Es sollen die folgenden Bedingungen gelten:

• jeder Verein bietet nur eine Sportart an.
• ein Sportler kann in verschiedenen Vereinen spielen, aber nur, wenn diese Vereine unterschiedliche Sportarten betreiben. Damit wird sichergestellt, dass der Sportler nie gegen einen Verein spielt, in dem er selbst Mitglied ist.

Sportler

Name	Sportart	Verein
Schuster	Fußball	FC Musterhausen
Leitner	Fußball	FC Musterhausen
Leitner	Eishockey	EC Beispielstadt

[Bearbeiten] Verletzung der BCNF

Aus den oben genannten Bedingungen folgt, dass das Attribut Sportart funktional abhängig vom Attribut Verein ist, d. h. Verein ist eine Determinante. Jedoch ist Verein kein Schlüsselkandidat.

Durch diese Konstellation ist die Relation nur in 3NF, nicht in BCNF. Jedoch ist eine Konvertierung in BCNF möglich, indem (Name, Verein) als Primärschlüssel verwendet und die Relation aufgeteilt wird:

Sportler

Name	Verein
Schuster	FC Musterhausen
Leitner	FC Musterhausen
Leitner	EC Beispielstadt

Verein

Verein	Sportart
FC Musterhausen	Fußball
EC Beispielstadt	Eishockey

[Bearbeiten] Zerlegungsalgorithmus

Es existiert ein Algorithmus der relationale Schemata durch Zerlegung (engl. decomposition) in die Boyce-Codd-Normalform überführt. Alle Schemata werden dabei solange aufgespalten, bis keines mehr die BCNF bricht. Jede Aufspaltung erfolgt anhand einer, die BCNF verletzenden, Funktionalen Abhängigkeit. Die Attribute der verletzenden Abhängigkeit bilden das erste neue Schema, und die restlichen Attribute plus die Determinante ein weiteres Schema. Die beiden neuen Schemata enthalten von den ursprünglichen funktionalen Abhängigkeiten lediglich solche, welche nur Attribute des jeweiligen Schemas nutzen, der Rest geht verloren.

Folgender Pseudokode beschreibt den Zerlegungsalgorithmus: ^[1]

1:	Gegeben ist ein relationales Schema , mit der Menge aller Attribute und der Menge der Funktionalen Abhängigkeiten über diese Attribute.
2:	Die Ergebnismenge Dekomposition, bestehend aus den zerlegten Schemata, wird mit R initialisiert.
3:	Solange es ein Schema S in der Menge Dekomposition gibt, welches nicht in der BCNF ist, führe folgende Zerlegung aus:
4:	Sei eine Attributmenge für die eine funktionale Abhängigkeit definiert ist, welche der BCNF widerspricht.
5:	Ersetze S in der Ergebnismenge Dekomposition durch zwei neue Schemata , ein Schema bestehend nur aus den Attributen der Abhängigkeit, welche die BCNF ursprünglich verletzt hat; und , ein Schema mit allen Attributen, außer denen die nur in der abhängigen Menge und nicht in der Determinante enthalten sind. Die Menge der funktionalen Abhängigkeiten enthält nur noch die Abhängigkeiten, welche lediglich Attribute aus enthalten, entsprechendes gilt für . Damit fallen alle Abhängigkeiten weg, welche Attribute aus beiden Schemata benötigen.
6:	Ergebnis: Dekomposition - eine Menge von relationalen Schemata, welche in der BCNF sind.

Durchlauf des Algorithmus am obigen Beispiel (ohne Darstellung aller trivialen Abhängigkeiten):

• 1: R = ( { Name, Sportart, Verein } , { ( { Name, Sportart } → { Verein } ), ( { Verein } → { Sportart } ), ( { Name, Verein } → { Name, Verein } ) } )
• 2: Dekomposition = { R }
• 3: da R aus Dekomposition nicht die BCNF erfüllt mache folgendes:
  • 4,5: { Verein } → { Sportart } ist die Abhängigkeit die die Verletzung der BCNF bedingt, damit ist S₁ = ( { Verein, Sportart }, { ( { Verein } → { Sportart }) } ) und S₂ = ( { Name, Verein }, { ( { Name, Verein } → { Name, Verein } ) } )
• 6: Ergebnis: Dekomposition: = {S₁,S₂}

[Bearbeiten] Vierte Normalform (4NF)

Die 4. Normalform beschreibt die mehrwertige Abhängigkeit (MWAs). Eine Datenbank ist dann in der 4. Normalform, wenn sie nur noch triviale mehrwertige Abhängigkeiten enthält.

Einfach gesagt: Es darf nicht mehrere, voneinander unabhängige, 1:n-Beziehungen in einer Relation geben (zu einem Schlüsselwert gehören n mal Attribut a, aber auch unabhängig davon n mal Attribut b).

[Bearbeiten] Beispiel

Besitz

Personnummer	Haustier	Fahrzeug
1	Katze	Golf
1	Katze	Ferrari
1	Pelikan	Golf
1	Pelikan	Ferrari
2	Hund	Porsche

[Bearbeiten] Verletzung der 4NF

Zu einer Personnummer gibt es mehrere Haustiere und Fahrzeuge. Haustier und Fahrzeug sind aber unabhängig voneinander. Person → Haustier ist dabei eine mehrwertige Abhängigkeit (MWA), Person → Fahrzeug auch. Diese beiden MWAs sind unabhängig voneinander, also können wir diese Tabelle in die 4NF aufspalten.

[Bearbeiten] Lösung

Haustier Personnummer Haustier 1 Katze 1 Pelikan 2 Hund

Fahrzeug Personnummer Fahrzeug 1 Golf 1 Ferrari 2 Porsche

[Bearbeiten] Hinweis

Folgende Relation erfüllt die 4NF:

Familie

Personnummer	Frau	Kind

Person → Frau und Person → Kind sind zwar zwei MWAs, aber diese beiden sind auch untereinander abhängig: Frau → Kind. Solche untereinander abhängigen MWAs werden erst in 5NF gelöst.

[Bearbeiten] Fünfte Normalform (5NF)

Die 5NF vereinfacht Relationen soweit, dass durch Projektions- und Verbundsoperationen die Informationen der ursprünglichen Relation wieder hergestellt werden. Sie ist somit sehr generell gehalten und dadurch (vorerst) die letzte Normalform. So können Relationen in einzelne Abfragen aufgeteilt werden und durch spätere Verbundsoperationen wieder zusammengefügt werden, wobei eine Teilmenge des so genannten kartesischen Produkts entsteht. Einfach gesagt: Eine Relation ist in 5NF, wenn sie sich nicht weiter in Relationen aufspalten lässt, ohne dass Information verloren geht.

[Bearbeiten] Beispiel

Die folgende Relation zeigt, welche Lieferanten welche Bauteile an welches Projekt liefern kann:

Lieferant	Teil	Projekt
Müller	Schraube	Projekt 1
Müller	Nagel	Projekt 2
Maier	Nagel	Projekt 1

[Bearbeiten] Verletzung der 5NF

Die Relation kann weiter zerteilt werden, ohne dass Information verloren geht.

[Bearbeiten] Lösung

Um diese Relation in die 5. Normalform umzuwandeln, müssen drei Relationen erstellt werden (Lieferant-Teil, Teil-Projekt und Lieferant-Projekt).

• Welche Teile kann welcher Lieferant liefern?

Lieferant-Teil

Lieferant	Teil
Müller	Schraube
Müller	Nagel
Maier	Nagel

• Welche Teile werden von welchem Projekt benötigt?

Teil-Projekt

Teil	Projekt
Schraube	Projekt 1
Nagel	Projekt 2
Nagel	Projekt 1

• Welche Projekte können von welchem Lieferanten beliefert werden?

Lieferant-Projekt

Lieferant	Projekt
Müller	Projekt 1
Müller	Projekt 2
Maier	Projekt 1

[Bearbeiten] Hinweis

Anders als bei der Umformung zwischen den bisherigen Normalformen wird durch diese Umwandlung etwas anderes durch die neuen Relationen ausgedrückt, als zuvor in der 4. Normalform.

Das merkt man leicht, wenn man die drei Relationen aus dem Beispiel oberhalb wieder vereinigt:

Lieferant	Teil	Projekt
Müller	Schraube	Projekt 1
Müller	Nagel	Projekt 2
Müller	Nagel	Projekt 1
Maier	Nagel	Projekt 1

Neu ist das Tupel: Müller – Nagel – Projekt 1.

Denn Müller könnte theoretisch das Projekt 1 mit Nägeln beliefern, da

• er auch Projekt 2 mit Nägeln beliefert und
• Projekt 1 auch Nägel benötigt (die jedoch bisher von Maier geliefert wurden).

Die Überführung in 5NF ist also nur dann möglich, wenn man die Möglichkeiten der Verbindungen aus drei Beziehungen ausdrücken möchte und nicht eine konkrete Verbindung zwischen den dreien haben möchte.

[Bearbeiten] Bemerkungen

In der Praxis der Datenmodellierung werden die erste, zweite, dritte und vierte Normalform beim Erstellen des Datenmodells meist schon intuitiv eingehalten. Sollte man ein „visuelles“ Verfahren benutzen (z. B. ERM) ist eine Normalisierung meist völlig überflüssig, da das abgeleitete Relationenschema sich bereits in einer Normalform (4NF) befindet. Die 1NF wird meist schon durch das verwendete Datenbankmodell bedingt.

Die Normalisierung dient eher zur mathematischen/theoretischen Aufarbeitung eines Datenbankmodells und zur Überprüfung eines relationalen Datenbankentwurfs. In der Praxis kommt Normalisierung überwiegend zu didaktischen Zwecken zur Anwendung. Es wird damit demonstriert, wie man auf keinen Fall ein Datenmodell entwirft – nämlich ausgehend von einer Universaltabelle. Die heutige Bedeutung ist nur noch historisch zu verstehen.

Eine alternative Herangehensweise zur Erstellung eines Datenmodells ist die Benutzung des Entity-Relationship-Modells (ERM) oder die Verwendung der Unified Modeling Language (UML) für den konzeptionellen Entwurf. Das aus dem konzeptionellen Entwurf abgeleitete Relationenschema kann dann mit Hilfe der Normalisierungen überprüft werden. Neben dem reinen ER-Modell gibt es auch das Structured-ERM (SERM), das E3R-Modell sowie das EER-Modell. Daneben ist auch das ERM, das von der SAP AG entwickelt wurde, sehr bekannt (SAP-SERM).

Befindet sich ein Relationenschema nicht in einer der Normalformen, befindet es sich in der NF² (Non-First-Normal-Form) bzw. UNF (Unnormalisierte Form).

Die englische Wikipedia enthält die gebräuchliche formale Definition der 3.NF (im Gegensatz zur informalen oben). Aus dieser ergibt sich, daß die 3.NF die 2.NF impliziert. Strukturell ist eigentlich die 2.NF nicht wirklich nötig, denn partielle Abhängigkeiten sind nur spezielle transitive Abhängigkeiten und die 2.NF verbietet also nur einige transitive Abhängigkeiten, hingegen die 3.NF alle.

[Bearbeiten] Merkspruch

Als eine Gedächtnisstütze für die Grade von Abhängigkeit vom Schlüssel in den ersten drei Normalformen wird gerne folgender Spruch genannt: the key, the whole key, and nothing but the key - so help me Codd:

• alle (impliziert: atomaren) Werte beziehen sich auf den Schlüssel - 1. NF
• bei zusammengesetzten Schlüsseln beziehen sie sich jeweils auf den gesamten Schlüssel - 2. NF
• die Werte hängen nur vom Schlüssel ab, und nicht von zusätzlichen Werten - 3. NF

[Bearbeiten] Merkregeln

1. Merkregel: Ist die Tabelle in 1. Normalform und besteht der Primärschlüssel aus nur einem Attribut so liegt automatisch die 2. Normalform vor.

2. Merkregel: Ist eine Tabelle in 2. Normalform und besitzt sie außer dem Primärschlüssel nur noch ein Attribut so liegt die Tabelle in 3. Normalform vor.

[Bearbeiten] Quellen

1. ↑ Philip M. Lewis, Arthur Bernstein, Michael Kifer: Databases and transaction processing: an application-oriented approach. Addison-Wesley, 2002, S. 232, ISBN 0-201-70872-8.

[Bearbeiten] Literatur

• Ramez Elmasri, Shamkant B. Navathe: Grundlagen von Datenbanksystemen. Pearson Studium, 2002, ISBN 3-8273-7021-3
• Alfons Kemper, Andre Eickler: Datenbanksysteme. Eine Einführung. Oldenbourg, München 2004, ISBN 3-486-27392-2
• Stefan M. Lang, Peter C. Lockemann: Datenbankeneinsatz. Springer, Berlin u. a. 1995, ISBN 3-540-58558-3

[Bearbeiten] Weblinks

• http://v.hdm-stuttgart.de/~riekert/lehre/db-kelz/chap4.htm
• http://www.tinohempel.de/info/info/datenbank/normalisierung.htm
• Microsoft KB-Artikel, in dem versucht wird die Normalform zu erklären
• Database Normalizer. Works with functional dependencies and implements normalization algorithms. Useful to validate normalization exercises