Folien



(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.

Vorgehen: Normalisieren bis zur 3. Normalform

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.

Struktogramm: Normalisieren bis zur 3. Normalform

Definition

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.

Beispiel: Bestellungen der Fa. XY

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).

Vorüberlegung: Qualitätskriterien für eine Datentabelle

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. ...

Ausgangszustand: Chaos

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:

  • Einfüge-Anomalie: Entitäten können nur dann eingetragen werden, wenn zu allen Attributen Werte vorliegen. Im Beispiel kann ohne Bestellung kein neuer Kunde angelegt werden - das führt zu einem unvollständigen Datensatz (ähnliches, häufiges Problem: Es kann kein neuer Artikel angelegt werden, wenn kein Kunde dafür da ist).
  • Änderungs-Anomalie: Änderungen müssen teilweise mehrfach vorgenommen werden. Wenn Herr Schmitt umzieht und mehrfach bestellt hat, muss die neue Adresse mehrfach eingetragen werden. Wird diese (sehr aufwändige!) Prozedur nicht vorgenommen, entstehen in der Relation inkonsistente Daten (d.h. Daten, die nicht übereinstimmen) = Änderungs-Anomalie.
  • Lösch-Anomalie: Beim Löschen eines Datensatzes gehen Daten verloren, die gar nicht gelöscht werden sollen. Wenn Herr Schmitt seine Bestellung vom 1.9.2010 storniert und dieser Datensatz gelöscht wird, sind auch die Kundendaten von Herrn Schmitt verschwunden.

1. Normalform

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.

2. Normalform

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 ...

  • Fall 1: ... besitzt einen einfachen Primärschlüssel. Dann befindet sie sich automatisch in der 2. Normalform (da alle Attribute der Relation von diesem einfachen Primärschlüssel abhängen).
    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.
  • Fall 2: ... besitzt einen zusammengesetzten Primärschlüssel. Wenn alle Attribute der Relation, die nicht Teil des Schlüssels sind, direkt vom gesamten Primärschlüssel abhängen, befindet sich die Relation in der 2. Normalform.
    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.
  • Fall 3:... besitzt einen zusammengesetzten Primärschlüssel. Wenn eines oder einige Attribute der Relation, die nicht Teil des Schlüssels sind, nur von einem Teilschlüssel (d.h.: einem Attribut der Attribute, die gemeinsam den Primärschlüssel bilden) abhängen, dann muss aus diesem Teilschlüssel eine neue Relation gebildet werden.
    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:

Relation 1: Bestellungen

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:

Relation 2: Kunden

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").

3. Normalform

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
  • BestellID bestimmt KundeNummer eindeutig (= funktionale Abhängigkeit).
  • KundeNummer bestimmt KundeName eindeutig (= funktionale Abhängigkeit).
  • Damit: BestellID bestimmt KundeName mittelbar. Da KundeName von KundeNummer bestimmt wird, nicht aber vom Primärschlüssel BestellID, ist die Abhängigkeit zwischen BestellID und KundeName transitiv.

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:

Relation 1: Bestellungen

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

Relation 2: Kunden

Nachname Vorname Wohnort Knummer
Schmitt Josef München 1377
Maier Marina Hamburg 19991
Huber Hannes Hamburg 573

Links zur Normalisierung/zu den Normalformen

Hier einige Links mit guten Beispielen bzw. verständlichen Erklärungen:

Übungen

Alle Übungen finden Sie in der Materialsammlung (dort auch alle zusätzlichen Dateien wie Bilder, Klassendiagramme oder HTML-Vorlagen!).

Die aktuelle Übung können Sie hier als txt-File herunterladen.


***** Übungen: Normalisierung *****

DB_03-1: Definition 1NF

Erklären Sie in eigenen Worten: Was bedeutet "1. Normalform"?




DB_03-2: 1. Normalform herstellen

Gegeben sei folgende Relation:

+-----------+---------------------------+
|KundenNr   |Kunde                      |
+-----------+---------------------------+
|1          |Josef Schmitt, Blochweg 3, |
|           |79312 Emmendingen          |
+-----------+---------------------------+
|2          |Ann Woll, Hauptstraße 15,  |
|           |79312 Emmendingen          |
+-----------+---------------------------+

a) Beschreiben Sie, wo die Nachteile dieser Struktur liegen.
b) Bringen Sie die Relation in die 1. Normalform.




DB_03-3: 1. Normalform anwenden

Abgebildet sind zwei beispielhafte Datensätze einer Relation "Artikel". Wenn Sie diese Relation in die 1NF bringen - wie viele Attribute wird die Relation insgesamt haben?
Artikelnummer: 1
Artikel: Luftmatratze, Gewicht inkl. Verpackung 3kg,
Garantie: 2 Jahre Garantie
Artikelpreis: 31.70 Euro, enthalten 19% Mehrwertsteuer

Artikelnummer: 2
Artikel: "Michael Kohlhaas", 250 Seiten, Gewicht inkl. Verpackung 250g
Artikelpreis: 6.90 Euro, enthalten 7% Mehrwertsteuer




DB_03-4: Definition 2NF

Erklären Sie in eigenen Worten: Was bedeutet "2. Normalform"?




DB_03-5: 2. Normalform herstellen I

Gegeben sei folgende Relation "LCD_Flachbildschirme":

+-------------------------------------------------------+
|Hersteller |Seriennummer |TypBez |Preis      |
+-------------------------------------------------------+
|Sony       |123456789 |Blinkmaster 3C |199.00     |
+-------------------------------------------------------+
|Samsung    |138829919      |Summerspecial I|189.00 | +-------------------------------------------------------+
|Sony       |188549921 |Blinkmaster 3C |239.99     |
+-------------------------------------------------------+
|Sony       |139929191 |110C         |219.00     |
+-------------------------------------------------------+

a) Identifizieren Sie den Primärschlüssel.
b) Befindet sich die Relation in der 2NF? Wenn nein: Bringen Sie die Relation in die 2NF.




DB_03-6: 2. Normalform herstellen II

Gegeben sei folgende Relation "Lexikoneintraege", wo eine Übersicht über die Einträge verschiedener Lexika (Brockhaus, Meyers ...) vorhanden sind.

+-----------------------------------------------+
|Buch_ID|Seite  |Artikelname    |Lexikontitel   |
+-----------------------------------------------+
|1      |137    |Windkraftwerk  |Brockhaus      |
+-----------------------------------------------+
|1      |85     |Goethe         |Brockhaus      |
+-----------------------------------------------+
|2      |137    |Goethe         |Meyer          |
+-----------------------------------------------+
|2      |289    |Wasserwerk     |Meyer          |
+-----------------------------------------------+
|2      |289    |Windkraftwerk  |Meyer          |
+-----------------------------------------------+

a) Identifizieren Sie den Primärschlüssel.
b) Befindet sich die Relation in der 2NF? Wenn nein: Bringen Sie die Relation in die 2NF.




DB_03-7: Definition 3NF

Erklären Sie in eigenen Worten: Was bedeutet "3. Normalform"?




DB_03-8: 3. Normalform herstellen I

Gegeben sei folgende Relation "Lagerbestand":
+---------------------------------------------------+
|ID |Artikel    |Anzahl |Lieferant  |Lieferant_Ort  |
+---------------------------------------------------+
|1  |Locher     |2      |Herlitz    |Wiesbaden      |
+---------------------------------------------------+
|2  |Tacker     |13     |Bürohaus M |München        |
+---------------------------------------------------+
|3  |Klebstoff  |3      |Herlitz    |Wiesbaden      |
+---------------------------------------------------+
|4  |Ordner     |6      |Leitz      |Hamburg        |
+---------------------------------------------------+

a) Identifizieren Sie den Primärschlüssel.
b) Bestehen transitive Abhängigkeiten? Wenn ja: Beseitigen Sie diese Abhängigkeiten und stellen Sie die 3NF her.




DB_03-9: 3. Normalform herstellen II

Gegeben sei folgende Relation "Verliehene_Buecher":
+---------------------------------------------------+
|ID |Titel      |LeiherName |Seitenzahl |Regal-Nr.  |
+---------------------------------------------------+
|1  |Robinson   |Martina    |189        |1          |
+---------------------------------------------------+
|2  |Faust I    |Josef      |113        |5          |
+---------------------------------------------------+
|3  |USA-Reisen |Josef      |288        |7          |
+---------------------------------------------------+
|4  |Helmut Kohl|Rico       |95         |7          |
+---------------------------------------------------+

a) Identifizieren Sie den Primärschlüssel.
b) Bestehen transitive Abhängigkeiten? Wenn ja: Beseitigen Sie diese Abhängigkeiten und stellen Sie die 3NF her.