(letzte Änderung an dieser Seite: 28.10.2023)
(letzte Synchronisation der PDF-Präsentation: 02.08.2017)
Falls keine PDF-Präsentation zu sehen ist, klicken Sie zum Download hier: Direktdownload PDF-Präsentation
Vorbemerkung: In der Oberstufe des Wirtschaftsgymnasiums wird in Baden-Württemberg nur die 1NF, 2NF und 3NF erwartet, weshalb hier auch nur diese NF behandelt werden.
Die wesentlichen Schritte und Hilfsfragen für den Normalisierungsprozess sind im folgenden Struktogramm festgehalten. Weitere Erläuterungen zu den einzelnen Schritten und zur Terminologie unten.
Beim Prozess der Normalisierung werden die Daten einer Datenbank so geordnet, dass eine möglichst komprimierte (= redundanzfreie), eindeutige, nachvollziehbare und konsistente Struktur entsteht. Beispiel: Wenn ein Kunde zum wiederholten Male einen Artikel bestellt, sollte in seiner Bestellung nur ein Verweis auf den Artikel stehen - und nicht mehrfach sämtliche Artikeldetails.
Fa. XY speichert in einer Datenbank alle getätigten Bestellungen. Aus Gründen der Vereinfachung interessiert vorerst bei jeder Bestellung nur Datum, Kunde, Rechnungsbetrag und Zahlungsweise (nicht: bestellte Artikel).
Bevor Sie weiterlesen: Betrachten Sie die folgende Relation (= "Tabelle"):
Bestellung | Kunde |
---|---|
13.05.2010, 28.59 Euro | Josef Schmitt, Kundennr. 1774 |
13.09.2010, 99.01 Euro | Muriel Sauter, Kundennr. 131 |
Äußern Sie sich bezüglich der Eignung für die Verwaltung der Bestellvorgänge. Begründen Sie Ihr Urteil schriftlich - was an dieser Tabelle ist vorteilhaft, was nachteilhaft?
Hinweise:
Sortieren; Dateneingabe durch verschieden Personen; Vornehmen von Änderungen; Aufwand bei der Dateneingabe; Fehleranfälligkeit; Berechnung von Gesamtsummen usw. ...
Nicht normalisierte Datenstrukturen werden auch als "chaotisch" bezeichnet, da sie ungeordnet und fehleranfällig sind.
Beispiel:
Bestellung | Kunde | Rechnung |
---|---|---|
01.09.10 | Josef Schmitt, München, Kundennummer 1377 |
31.99, Kreditkarte |
01.09.10 | Marina Maier, Hamburg, Kundenummer: 19991 |
188.45, Vorkasse |
03.09.10 | Hannes Huber, Hamburg, Kundennummer: 573 |
20.55, Kreditkarte |
07.09.10 | Josef Schmitt, München, Kundennummer 1377 |
61.99, Kreditkarte |
Diese Struktur hat einige gravierende Nachteile:
Daten sind redundant (d.h. mehrfach) gespeichert. Daraus können sich Anomalien ergeben, die im Sinne eines ökonomischen Verwaltens zu vermeiden sind:
Definition: Eine Relation ist dann in der 1. Normalform, wenn alle Attribute nur einfache Attributwerte aufweisen. Das Nichtvorhandensein von Daten ist zulässig.
Redundanzen werden beseitigt, indem man dafür sorgt, dass alle Attribute nur einen Wert haben. Es darf also nicht - wie im obigen Fall - einem Attribut gleichzeitig ein Name, eine Stadt und eine Kundennummer (etc.) zugeordnet sein. Alle Attribute werden atomisiert. Kein Attributwertebereich darf anschließend in weitere sinnvolle Teilbereiche aufgespalten werden können.
Best.- Datum |
Nach- name |
Vor- name |
Wohn- ort |
Kunden- Nr. |
Re.- betrag |
Zahlungs- weise |
---|---|---|---|---|---|---|
01.09.10 | Schmitt | Josef | München | 1377 | 31.99 | Kreditkarte |
01.09.10 | Maier | Marina | Hamburg | 19991 | 188.45 | Vorkasse |
03.09.10 | Huber | Hannes | Hamburg | 573 | 20.55 | Kreditkarte |
07.09.10 | Schmitt | Josef | München | 1377 | 61.99 | Kreditkarte |
Der Primärschlüssel setzt sich hier zusammen aus Bestelldatum und Kundennummer - kennt man eine Kombination aus diesen beiden Attributen, kann man eine Bestellung genau zuordnen. Streng genommen müsste beim Bestelldatum noch die genaue Uhrzeit festgehalten sein, damit ein Kunde auch mehrmals pro Tag bestellen kann.
Definition: Eine Relation befindet sich in der 2. Normalform, wenn sie sich in der 1. Normalform befindet und jedes Attribut vom gesamten Primärschlüssel abhängt.
Es ist also zu überprüfen: Die Relation muss sich in der 1. Normalform befinden und ...
Beispiel: Würde man in der Relation oben (1NF) ein Attribut "Bestell_ID" hinzufügen, durch das jede Bestellung eindeutig identifizierbar wäre, hätten wir die 2. NF erreicht.
Beispiel: In der Relation oben (1NF) ist der Rechnungsbetrag vom gesamten Primärschlüssel abhängig - weder Bestelldatum noch Kundennummer allein reicht aus, um eine Bestellung eindeutig zu identifizieren.
Beispiel: Der Nachname ist nur von einem Teilschlüssel abhängig, nämlich der Kundennummer; das Bestelldatum hat keinen Einfluss auf den Nachnamen. Damit befindet sich die Relation nicht in der 2. Normalform.
Das Beispiel oben (1NF) verletzt also die 2NF. So sind die Daten von Herrn Schmitt redundant (= mehrfach vorhanden). Wenn Herr Schmitt in eine andere Stadt umzieht, müssten bei allen entsprechenden Bestellvorgängen eine Änderung vorgenommen werden. Werden diese aufwändigen Änderungen nicht vorgenommen, entstehen Fehler in der Relation (Änderungs-Anomalie). Ebenso droht eine Einfüge-Anomalie, wenn ein neuer Kunde angelegt werden soll, der keine Bestellung tätigt (denn dann kann ein Teilschlüssel - das Bestelldatum - nicht belegt werden).
Für das aktuelle Beispiel muss die Relation also zerlegt werden:
Bestellungsdatum | Knummer | Rechnungsbetrag | Zahlungsweise |
---|---|---|---|
01.09.10 | 1377 | 31.99 | Kreditkarte |
01.09.10 | 19991 | 188.45 | Vorkasse |
03.09.10 | 573 | 20.55 | Kreditkarte |
07.09.10 | 1377 | 61.99 | Kreditkarte |
"Knummer" fungiert hier als Fremdschlüssel, der auf den Primärschlüssel der Relation "Kunden" verweist:
Nachname | Vorname | Wohnort | Knummer |
---|---|---|---|
Schmitt | Josef | München | 1377 |
Maier | Marina | Hamburg | 19991 |
Huber | Hannes | Hamburg | 573 |
Es wäre auch möglich, einfach der Relation oben (1NF) einen einfachen Primärschlüssel hinzuzufügen (z.B. Bestell_ID); dann würde sich die Aufteilung der Relationen in den Schritt der 3NF verlagern.
Die beiden Relationen "Bestellungen" und "Kunden" befinden sich in der 2. Normalform, weil sie entweder nur über einen einfachen Primärschlüssel verfügen (Relation "Kunden" hat als Primärschlüssel "Knummer") oder alle Nicht-Schlüssel-Attribute vom gesamten (zusammengesetzten) Primärschlüssel abhängen (Relation "Bestellungen" hat als Primärschlüssel "Bestellungsdatum" und "Knummer").
Definition: Die Relation befindet sich in der 3. Normalform, wenn sie sich in der 2NF befindet und alle Nichtschlüsselattribute (= alle Attribute, die nicht zum Primärschlüssel gehören) direkt von dem/einem Schlüssel abhängen (und nicht: von einem Nichtschlüsselattribut) - wenn also keine transitive Abhängigkeit zwischen einem Nichtschlüsselattribut und einem Schlüssel besteht.
Begriff: "transitive Abhängigkeit": Attribut B ist von A funktional abhängig, Attribut C von B funktional abhängig - dann besteht zwischen Attribut C und A eine transitive Abhängigkeit.
In der folgenden Relation ist KundeName transitiv abhängig von BestellID:
BestellID [A] | KundeNummer [B] | KundeName [C] | Re-Betrag |
---|---|---|---|
1 | 1377 | Schmitt | 61.99 |
2 | 1377 | Schmit | 70.00 |
3 | 124 | Müller | 99.50 |
Angenommen, wir hätten zur Realisierung der 2NF die Relation nicht in zwei Relationen aufgeteilt, sondern einfach einen einfachen Primärschlüssel hinzugefügt (BestellID), dann sähe die Relation so aus:
BestellID | Best.- Datum |
Nach- name |
Vor- name |
Wohn- ort |
Kunden- Nr. |
Re.- betrag |
Zahlungs- weise |
---|---|---|---|---|---|---|---|
1 | 01.09.10 | Schmitt | Josef | München | 1377 | 31.99 | Kreditkarte |
2 | 01.09.10 | Maier | Marina | Hamburg | 19991 | 188.45 | Vorkasse |
3 | 03.09.10 | Huber | Hannes | Hamburg | 573 | 20.55 | Kreditkarte |
4 | 07.09.10 | Schmitt | Josef | München | 1377 | 61.99 | Kreditkarte |
Diese Relation verletzt die 3. Normalform, weil Nachname, Vorname und Wohnort transitiv abhängig von BestellID sind (denn sie sind funktional abhängig vom Nichtschlüsselattribut Kundennummer). So lässt sich etwa der Nachname aus der Kundennummer bestimmen. Da sich die Kundennummer aus der BestellID bestimmen lässt, besteht eine transitive Abhängigkeit.
Auch hier sind Redundanzen zu beseitigen. Bei der wiederholten Bestellung eines Kunden müssen die transitiv abhängigen Attribute (in diesem Fall: die Kundendaten) wiederholt eingetragen werden und sind damit mehrfach vorhanden.
Die voneinander abhängigen Daten werden in eine eigene Relation ausgelagert, wobei der Primärschlüssel der neuen Relation als Fremdschlüssel in der alten Relation verbleibt:
BestellID | Bestellungsdatum | Knummer | Rechnungsbetrag | Zahlungsweise |
---|---|---|---|---|
1 | 01.09.10 | 1377 | 31,99 | Kreditkarte |
2 | 01.09.10 | 19991 | 188,45 | Vorkasse |
3 | 03.09.10 | 573 | 20,55 | Kreditkarte |
Nachname | Vorname | Wohnort | Knummer |
---|---|---|---|
Schmitt | Josef | München | 1377 |
Maier | Marina | Hamburg | 19991 |
Huber | Hannes | Hamburg | 573 |
Hier einige Links mit guten Beispielen bzw. verständlichen Erklärungen: