Normalisierung (Datenbank)
Unter Normalisierung eines relationalen Datenbankschemas versteht man die schrittweise erfolgende Zerlegung von Relationen (in der Datenbank: Tabellen), auch 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 ein Relationenschema eine Normalform erfüllt, muss es 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).
Vorgehen
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 (z. B. einander widersprechende Dateninhalte) zu verhindern, um so die Wartung einer Datenbank zu vereinfachen sowie die Konsistenz der Daten zu gewährleisten.
Beispiel
Deutlich wird dies an einem einfachen Beispiel: Eine Datenbank enthält Kunden und deren Adressen sowie Aufträge, die den Kunden zugeordnet sind. Würde jeder Auftrag direkt die Adresse des Kunden speichern, müsste man bei einer Adressänderung alle Datensätze nach diesem Kunden durchsuchen und die Adresseinträge aktualisieren. Bei einer normalisierten Datenbank gibt es dafür nur einen einzigen Eintrag, hier die Kundentabelle. Weiterhin ist der Speicherbedarf geringer, wenn der Datensatz einer Tabelle z. B. "Auftrag" auf einen Datensatz einer anderen Tabelle z. B. "Kunde" verweist, anstatt diese Daten 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 speziellen Anwendungsfällen kann es wiederum sinnvoll sein, auf eine Normalisierung zu verzichten oder diese 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, oder
- Besonderheiten des Geschäftsprozesses abzubilden.
Zum Beispiel ist beim Speichern von Adressen der Name des Ortes abhängig von der Postleitzahl. Nach der 3. Normalform müsste man bei der Adresse jeweils nur die Postleitzahl speichern und in einer separaten Tabelle die Zuordnung {PLZ, Ort}. Aus Gründen der Performance verzichtet man jedoch meist auf diese Trennung.
VORSICHT! Postleitzahlen sind, zumindest in Deutschland, kein eindeutiges Kriterium, da es mehrere Beispiele gibt, daß benachbarte Gemeinden die gleiche Postleitzahl aufweisen (z.B. 15732 Eichwalde und 15732 Schulzendorf - bis vor wenigen Jahren sogar noch 15732 Waltersdorf). Eine direkte Abhängigkeit von PLZ und Ort gibt es daher nicht bzw. nur bedingt.
Normalformen
Zurzeit gebräuchliche Normalformen sind:
- 1. Normalform (1NF)
- 2. Normalform (2NF)
- 3. Normalform (3NF)
- Boyce-Codd (BCNF)
- 4. Normalform (4NF)
- 5. Normalform (5NF)
Zum einen dienen sie der Beurteilung der Qualität eines betrachteten Datenbankschemas.
Des Weiteren helfen sie, Fehler beim Erzeugen neuer Schemata zu vermeiden.
Außerdem können mit Hilfe der Normalisierung Datenstrukturen aus nichtrelationalen Quellen gewonnen werden, die formal korrekt sind und die Daten aus ihren jeweiligen nichtrelationalen Quellen, aus denen sie entstanden sind (z. B. Formulardaten oder Spreadsheets), aufnehmen können. Da sich in solchen Quellen aber meistens Anomalien verbergen, weil sie ja eben nicht normalisiert sind, gestaltet sich das in der Praxis fast immer schwieriger als es die theoretische Anleitung vermuten lässt.
Nachfolgend werden die Kriterien der jeweiligen Normalformen erklärt. Dabei ist zu beachten, dass jede Normalform die Kriterien der "vorherigen" Normalformen mit einschließt.
Erste Normalform (1NF)
Jedes Attribut der Relation muss einen atomaren Wertebereich haben. (Statt „atomar“ wird auch die Bezeichnung „atomisch“ verwendet.[1])
Das heißt, zusammengesetzte, mengenwertige oder geschachtelte Wertebereiche (relationenwertige Attributwertebereiche) sind nicht erlaubt. Kurz: Kein Attributwertebereich kann in weitere (sinnvolle) Teilbereiche aufgespalten werden (Beispiel: Die Adresse darf nicht als Attribut verwendet werden, sondern muss – sofern es das zugrunde liegende Geschäftsmodell erfordert – in PLZ, Ort, Straße, Hausnummer aufgeteilt werden).
Dass die Relation frei von Wiederholungsgruppen sein muss, bedeutet, dass Attribute, die gleiche oder gleichartige Information enthalten, in eine andere Relation ausgelagert werden müssen.
Beispiele dafür könnten sein: { .., Telefon1, Telefon2, Telefon3,.. }. In diesem Fall umfasst die Gruppe nur ein Attribut und tritt dreimal auf. { .., Ländervorwahl1, Netzvorwahl1, Telefon1, Durchwahl1, Ländervorwahl2, Netzvorwahl2, Telefon2, Durchwahl2, .. } ist ein Beispiel für eine Wiederholungsgruppe mit 4 Attributen, die zweimal auftritt.
Ob Inhalte atomar sind bzw. ob tatsächlich eine Wiederholungsgruppe vorliegt, lässt sich oft nur im Licht der Anwendung entscheiden: Wo z. B. für praktisch jede kommerzielle Anwendung eine Spalte "Telefonnummer" (ohne Vor- & Durchwahlen) als atomar betrachtet werden darf, könnte es für einen Telekommunikationsbetreiber durchaus sinnvoll sein, weiter aufzuteilen: { .., Zifferngruppe1, Zifferngruppe2, Zifferngruppe3,.. }.
Praktischer Nutzen
Abfragen der Datenbank werden durch die 1NF erleichtert bzw. überhaupt erst ermöglicht, da die Attributwertebereiche atomar sind. So ist es beispielsweise in einem Feld, das einen ganzen Namensstring aus Titel, Vorname und Zuname enthält schwierig bis unmöglich, nach Zunamen zu sortieren.
Alternative Formulierungen
Alle Attribute enthalten atomare Inhalte, und die Relation hat eine feste Breite. Diese Formulierung bezieht sich darauf, dass niemals weitere Attribute in die Relation aufgenommen werden müssen, weil die Wiederholungszahl der Wiederholungsgruppe zu klein wird (z. B.: es wird bei drei Attributen Telefon1-3 eine 4. Telefonnummer für eine Person bekannt). Sie ist insofern interessant, als sie helfen kann zu entscheiden, ob tatsächlich eine Wiederholungsgruppe vorliegt: Obwohl z. B. { .., Telefon1, Telefon2, Telefon3,.. } sehr stark das Vorhandensein einer Wiederholungsgruppe impliziert, könnte es bei lediglich anderen Attributnamen klar werden, dass - freilich unter dem Licht der Anwendung - dem nicht so sein muss: { .., Telefon, Fax, Mobil,.. }
Eine weitere Variante entsteht durch folgenden Zusatz: .. und die Relation einen Primärschlüssel hat. Obwohl diese Formulierung so nicht bei Codd nachgelesen werden kann, handelt es sich um eine Erweiterung, die zu ausgesprochen praxistauglichen Datenstrukturen führt.
Beispiel
| CD_ID | Album | Titelliste |
|---|---|---|
| 4711 | 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} |
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.
Lösung
| CD_ID | Albumtitel | Interpret | Track | Titel |
|---|---|---|---|---|
| 4711 | Not That Kind | Anastacia | 1 | Not That Kind |
| 4711 | Not That Kind | Anastacia | 2 | I'm Outta Love |
| 4711 | 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.
Zweite Normalform (2NF)
Eine Relation ist in der zweiten Normalform, wenn die erste Normalform vorliegt und jedes Nichtschlüsselattribut von jedem Schlüsselkandidaten voll funktional abhängig ist.
Anders gesagt: Jedes nicht-primäre Attribut (nicht Teil eines Schlüssels) ist jeweils vom ganzen Schlüssel abhängig, nicht von nur einem Teil eines Schlüssels. (Genau das ist die „VOLLE funktionale Abhängigkeit.“)
In einer Relation R(A,B) ist das Attribut B von dem Attribut A funktional abhängig, falls zu jedem Wert des Attributs A genau ein Wert des Attributs B gehört. (funktional abhängig) In einer Relation R(S1,S2,B) ist das Attribut B von den Attributen(Schlüsseln) S1,S2 voll funktional abhängig, wenn B von den zusammengesetzten Attributen (S1,S2) funktional abhängig ist, nicht aber von einem einzelnen Attribut S1 oder S2. (voll funktional abhängig)
Diese informelle Definition kann wie folgt präzisiert werden:
Eine Relation ist genau dann in zweiter Normalform, wenn sie
- in der ersten Normalform ist und
- für jeden Schlüsselkandidaten (Key Candidate, KC) und jedes Attribut der Relation gilt:
- gehört zu KC oder
- ist nicht von einer echten Teilmenge von KC abhängig.
Man sagt: ist voll funktional abhängig von jedem Schlüsselkandidaten (wobei die Schlüsselkandidaten KC auch durch die Kombination mehrerer Attribute gebildet werden können).
Praktischer Nutzen:
Die 2. NF erzwingt wesentlich "monothematische" Relationen im Schema: jede Relation modelliert nur einen Sachverhalt.
Dadurch werden Redundanz und die damit einhergehende Gefahr von Inkonsistenzen reduziert. Nur noch logisch/sachlich zusammengehörige Information findet sich in einer Relation. Dadurch fällt das Verständnis der Datenstrukturen leichter.
Beispiel
| CD_ID | Albumtitel | Interpret | Track | Titel |
|---|---|---|---|---|
| 4711 | Not That Kind | Anastacia | 1 | Not That Kind |
| 4711 | Not That Kind | Anastacia | 2 | I'm Outta Love |
| 4711 | Not That Kind | Anastacia | 3 | Cowboys & Kisses |
| 4712 | Wish You Were Here | Pink Floyd | 1 | Shine On You Crazy Diamond |
Verletzung der 2NF
Der Primärschlüssel der Relation ist aus den Feldern CD_ID und Track zusammengesetzt. Die Felder Albumtitel 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 in I Don’t Mind ändern, ohne jedoch die passenden Einträge bei den Liedern I'm Outta Love und Cowboys & Kisses zu ändern (Update-Anomalie).
| CD_ID | Albumtitel | Interpret | Track | Titel |
|---|---|---|---|---|
| 4711 | I Don’t Mind | Anastacia | 1 | Not That Kind |
| 4711 | Not That Kind | Anastacia | 2 | I'm Outta Love |
| 4711 | 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.
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.
|
|
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.
Dritte Normalform (3NF)
Die dritte Normalform ist erreicht, wenn sich das Relationenschema in 2NF befindet, und jedes Nichtschlüsselattribut von keinem Schlüsselkandidaten transitiv abhängt.
Hierbei handelt es sich um eine Abhängigkeit, bei der ein Attribut über ein anderes Attribut von einem Schlüsselkandidaten der Relation abhängig ist (ohne dass zugleich auch direkt von abhängig ist). Das heißt: Wenn Attribut von Attribut (dem Primärattribut) abhängt und Attribut von , dann ist transitiv abhängig von . Formal ausgedrückt: .
Einfach gesagt: Ein Nichtschlüsselattribut darf nicht von einer Menge abhängig sein, die ausschließlich aus Nichtschlüsselattributen besteht. Ein Nichtschlüsselattribut darf also nur direkt von einem Schlüssel abhängen.
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 Relationen wiedergegeben.
Außerdem werden verbliebene thematische Durchmischungen in der Relation behoben: nach der 3NF sind die Relationen des Schemas zuverlässig monothematisch.
Beispiel
| CD_ID | Albumtitel | Interpret | Jahr der Gründung |
|---|---|---|---|
| 4711 | Not That Kind | Anastacia | 1999 |
| 4713 | Freak of Nature | Anastacia | 1999 |
| 4712 | Wish You Were Here | Pink Floyd | 1964 |
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 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.
Lösung
|
|
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.
Boyce-Codd-Normalform (BCNF)
Eine Relation ist in BCNF, wenn sie die Voraussetzungen der 3NF erfüllt, und jede Determinante (Attributmenge, von der andere Attribute funktional abhängen) ein Superschlüssel ist (oder die Abhängigkeit ist trivial). Superschlüssel ist eine Menge von Attributen, die die gesamte Relation funktional bestimmt.
Die BCNF (nach Raymond F. Boyce und Edgar F. Codd) verhindert, dass Teile zweier aus mehreren Feldern zusammengesetzten Schlüsselkandidaten voneinander abhängig sind.
Die Überführung in die BCNF ist zwar immer verlustfrei möglich, aber nicht immer abhängigkeitserhaltend. Die Boyce-Codd-Normalform war ursprünglich als Vereinfachung der dritten Normalform gedacht, führte aber zu einer neuen Normalform, die die 3NF verschärft.
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.
| Name | Sportart | Verein |
|---|---|---|
| Schuster | Fußball | FC Musterhausen |
| Leitner | Fußball | FC Musterhausen |
| Leitner | Eishockey | EC Beispielstadt |
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:
Lösung
|
|
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 Pseudocode beschreibt den Zerlegungsalgorithmus: [2]
| 1: | Gegeben ist ein relationales Schema , mit der Menge aller Attribute und der Menge der Funktionalen Abhängigkeiten über diesen Attributen. |
| 2: | Die Ergebnismenge Dekomposition, bestehend aus den zerlegten Schemata, wird mit R initialisiert. |
| 3: | Solange es ein Schema S in der Menge Dekomposition gibt, das nicht in der BCNF ist, führe folgende Zerlegung aus: |
|
Sei eine Attributmenge für die eine funktionale Abhängigkeit definiert ist, welche der BCNF widerspricht. |
|
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 = ( { Verein, Sportart }, { ( { Verein } → { Sportart }) } ) und = ( { Name, Verein }, { ( { Name, Verein } → { Name, Verein } ) } )
- 6: Ergebnis:
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 oder die nicht-trivialen mehrwertigen Abhängigkeiten von Superschlüsseln ausgehen. Einfach gesagt: Es darf nicht mehrere, voneinander unabhängige, -Beziehungen zu einem Schlüsselwert geben in einer Relation, z.B. gehört zu einem Schlüsselwert mal Attribut , aber davon unabhängig auch -mal Attribut ).
Beispiel
| Personnummer | Haustier | Fahrzeug |
|---|---|---|
| 1 | Katze | Volkswagen |
| 1 | Katze | Ferrari |
| 1 | Pelikan | Volkswagen |
| 1 | Pelikan | Ferrari |
| 2 | Hund | Porsche |
Verletzung der 4NF
Zu einer Personnummer gibt es mehrere Haustiere und Fahrzeuge. Haustier und Fahrzeug sind aber unabhängig voneinander. Personnummer → Haustier ist dabei eine mehrwertige Abhängigkeit (MWA), Personnummer → Fahrzeug auch. Diese beiden MWAs sind unabhängig voneinander, also können wir diese Tabelle in die 4NF aufspalten.
Lösung
|
|
Hinweis
Folgende Relation erfüllt die 4NF:
| Personnummer | Partner | Kind |
|---|
Person → Partner und Person → Kind sind zwar zwei MWAs, aber diese beiden sind auch untereinander abhängig: Partner → Kind. Solche untereinander abhängigen MWAs werden erst in 5NF gelöst.
Fünfte Normalform (5NF)
Die 5NF vereinfacht Relationen soweit, dass durch Projektions- und Verbundoperationen 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.
Beispiel
Die folgende Relation zeigt, welche Lieferanten welche Bauteile an welches Projekt liefern können:
| Lieferant | Teil | Projekt |
|---|---|---|
| Müller | Schraube | Projekt 1 |
| Müller | Nagel | Projekt 2 |
| Maier | Nagel | Projekt 1 |
Verletzung der 5NF
Die Relation kann weiter zerteilt werden, ohne dass Information verloren geht.
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 |
|---|---|
| Müller | Schraube |
| Müller | Nagel |
| Maier | Nagel |
- Welche Teile werden von welchem Projekt benötigt?
| Teil | Projekt |
|---|---|
| Schraube | Projekt 1 |
| Nagel | Projekt 2 |
| Nagel | Projekt 1 |
- Welche Projekte können von welchem Lieferanten beliefert werden?
| Lieferant | Projekt |
|---|---|
| Müller | Projekt 1 |
| Müller | Projekt 2 |
| Maier | Projekt 1 |
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.
Bemerkungen
Schwächen im Datenmodell aufgrund fehlender Normalisierung können – neben den typischen Anomalien – einen höheren Aufwand bei einer späteren Weiterentwicklung bedeuten. Andererseits kann beim Datenbankentwurf aus Performance-Überlegungen bewusst auf Normalisierungsschritte verzichtet werden. Typisches Beispiel dafür ist das Sternschema im Data-Warehouse.
Die Erstellung eines normalisierten Schemas wird durch automatische Ableitung aus einem konzeptuellen Datenmodell gestützt; hierzu dient in der Praxis ein erweitertes Entity-Relationship-Modell (ERM) oder ein Klassendiagramm der Unified Modeling Language (UML) als Ausgangspunkt. Das aus dem konzeptionellen Entwurf abgeleitete Relationenschema kann dann mit Hilfe der Normalisierungen überprüft werden; es existieren jedoch Formalismen und Algorithmen, die diese Eigenschaft bereits sicherstellen können. Statt des ursprünglichen ER-Modells (Chen, 1976) werden heute erweiterte ER-Modelle verwendet: Das Structured-ERM (SERM), das E3R-Modell, das EER-Modell sowie das von der SAP AG verwendete SAP-SERM.
Befindet sich ein Relationenschema nicht in einer der Normalformen, so nennt man diese Form auch NF² (Non-First-Normal-Form) bzw. UNF (Unnormalisierte Form).
Der Prozess der Normalisierung und Zerlegung einer Relation in die 1NF, 2NF und 3NF muss die Wiederherstellbarkeit der ursprünglichen Relation erhalten, das heißt die Zerlegung muss verlustfrei und abhängigkeitstreu sein.
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 (Der Schlüssel, der ganze Schlüssel und nichts als der Schlüssel - so wahr mir Codd helfe.):
- 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
Merkregeln
- Ist die Tabelle in 1. Normalform und besteht der Primärschlüssel aus nur einem Attribut, so liegt automatisch die 2. Normalform vor.
- Ist eine Tabelle in 2. Normalform und besitzt sie außer dem Primärschlüssel höchstens ein weiteres Attribut, so liegt die Tabelle in 3. Normalform vor.
Siehe auch
Quellen
- ↑ Paul Alpar: Datenorganisation und Datenbanken, S. 31 (PDF)
- ↑ Philip M. Lewis, Arthur Bernstein, Michael Kifer: Databases and transaction processing: an application-oriented approach. Addison-Wesley, 2002, ISBN 0-201-70872-8, S. 232.
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
Weblinks
- Der Königsweg: Normalisierung, Hochschule der Medien Stuttgart
- Access: Grundlagen der Datenbanknormalisierung, Microsoft Hilfe und Support
- Normalisierung von Datenbanken, Richard-Wossidlo-Gymnasium Ribnitz-Damgarten
- Erklärung der Normalformen, Ziemer's Informatik
- Database Normalizer, Computerprogramm für Windows zur Normalisierung
