unterrichtsmaterialien für den informatikunterricht: präsentationen, übungen, projekte

navigieren

durchsuchen

syndikation

RSS (coming soon)

admin

Login

Normalisierung

Falls über diesem Text keine PDF-Präsentation zu sehen ist, wurde diese von Ihrem Browser direkt runtergeladen (wenn Sie z.B. mit Safari@Mac surfen). Sie könnnen zum Download auch hier klicken: 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.

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

Ä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:

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.

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

"Knummer" fungiert hier als Fremdschlüssel, der auf den Primärschlüssel der Relation "Kunden" verweist:

Relation 2: Kunden

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 A 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 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:

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

Relation 2: Kunden

Links zur Normalisierung/zu den Normalformen

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

• sql-und-xml.de - Zweite Normalform - verständliche Erklärungen zu allen Normalformen
• Normalisierung einer relationalen Datenbank - Unterrichtsmaterial bei Lehrer-Online (unter Verwendung von Access, schrittweise Normalisierung bis zur 3. Normalform)
• Ausführliche Beschreibung zum Vorgehen bei der Entwicklung einer Datenbank, u.a. zu den Normalformen
• Andreas Weber: 2. Normalform - strukturierte Darstellung der Normalisierung
• sqldocu.com - Normalformen
• tinohempel.de - Normalisierung - Gute Schritt-für-Schritt-Anleitungen zur Herstellung der einzelnen Normalformen
• Wikipedia: Normalisierung - mit guten Beispielen für Verletzungen der einzelnen NF