Datenbankentwicklung durch Normalisierung (nur im LK)

In den bisherigen Stunden haben wir Datenbanken analysiert und aus ihnen Daten abgefragt. Wir wollen nun einen Schritt weiter gehen. Liegt bereits ein relationales Datenmodell - beispielsweise als Tabelle vor, kann es durch Normalisierung schrittweise umgestaltet werden. Dabei werden vorhandene Relationen analysiert und gegebenenfalls so umstrukturiert, dass ein gut strukturiertes und redundanzarmes relationales Datenmodell entsteht. Die Grundlagen der Normalisierung gehen auf Arbeiten von Edgar F. Codd zurück.

Bildlink: © IBM, Quelle: IBM Heritage - Edgar F. Codd als Peron der Zeitgeschichte.

Anomalien und Redundanzen in nicht normalisierten Tabellen

Schauen wir uns aber zunächst an einem Beispiel an, welche Probleme in Datensammlungen auftreten können, die nicht normalisiert wurden.

Eine Schule verwaltet Lernangebote in der folgenden Relation:

Welche Auswirkungen auf die Datenintegrität (Widerspruchsfreiheit) hat ...

1. das Einfügen des neuen Kurses "3D-Druck":
   → Dies ist derzeit nicht möglich, da SNr Schlüssel ist. Der Kurs muss also durch einen Schüler belegt sein, um ihn einzufügen. 
2. der Abgang/das Löschen der Schülerin Nr. 5 Paula Jürgens:
   → Dies hat zur Folge, dass neben den Schülerdaten auch die Daten des Töpferkurses gelöscht werden. 
3. das Ändern des Namens wegen Heirat der Lehrerin Lempel zu Lempel-Schmidt:
   → Dies muss in der Tabelle mehrfach geändert werden. Werden dieselben Informationen mehrfach gespeichert, können bei Änderungen widersprüchliche Werte entstehen. Der Datenbestand ist dann inkonsistent.

Das Ändern, Einfügen und Löschen von Daten kann also zu Problemen und Fehlern führen. Man bezeichnet diese Probleme als Änderungs-, Einfüge- und Löschanomalien. Außerdem werden bestimmte Informationen mehrfach gespeichert. Solche Redundanzen können zu Inkonsistenzen führen und sollen bei der Normalisierung soweit sinnvoll reduziert werden. 

• Änderungsanomalie: Dieselbe Information ist mehrfach gespeichert und wird nicht an allen Stellen gleichzeitig geändert.
• Einfügeanomalie: Eine Information kann nicht gespeichert werden, ohne zugleich weitere, eigentlich unabhängige Daten einzutragen.
• Löschanomalie: Beim Löschen eines Datensatzes geht unbeabsichtigt zusätzliche Information verloren.

Prozess der Normalisierung

Um unnötige Redundanzen zu reduzieren und Anomalien zu vermeiden, werden Relationen schrittweise normalisiert. Im Unterricht betrachten wir die ersten drei Normalformen.

In unserem Fall liegt nur die Relation Lernangebotsübersicht vor:

1. Normalform

Eine Relation befindet sich in der ersten Normalform (1. NF), wenn jeder Attributwert atomar ist.
Ein Attributwert ist atomar, wenn er im verwendeten Datenmodell als einzelner, nicht weiter zu zerlegender Wert behandelt wird. Mehrere Werte in einem Attribut erschweren zudem die eindeutige Zuordnung zusammengehöriger Angaben.

Mehrfachwerte werden so aufgelöst, dass jedes Tabellenfeld nur noch einen einzelnen Wert enthält. Dazu können beispielsweise zusätzliche Zeilen gebildet oder die betreffenden Daten in eine eigene Relation ausgelagert werden. 

Relation Lernangebotsübersicht kann durch Hinzufügen von Zeilen (oder durch Auslagern der nichtatomaren Attribute mit dem vorhandenen Schlüssel) in eine neue Relation in die erste Normalform überführt werden:

Beobachtungen:

• • Die Herstellung der 1. Normalform beseitigt die Mehrfachwerte, kann aber zunächst zu zusätzlichen Redundanzen führen.
  • Nach dem Aufteilen ist SNr allein nicht mehr als Primärschlüssel geeignet, da eine Schülernummer mehrfach vorkommen kann. Die Kombination aus SNr und LANr kann die Zeilen eindeutig identifizieren und bildet daher einen zusammengesetzten Schlüssel.

2. Normalform

Eine Relation befindet sich in der zweiten Normalform, falls 

1. 1. die Relation in der ersten Normalform ist und
   2. jedes Nichtschlüsselattribut voll funktional vom gesamten Primärschlüssel abhängig ist. 

Regel zum Prüfen der zweiten Bedingung: 
Voll funktional abhängig bedeutet: Kein Nichtschlüsselattribut darf bereits von einem echten Teil des zusammengesetzten Schlüssels abhängen. Hängt mindestens ein Nichtschlüsselattribut funktional nur von einem Teil des zusammengesetzten Schlüssels ab, liegt keine 2. Normalform vor.

Schrittfolge zur Herstellung der zweiten Normalform: 

1. 1. Festlegen/Feststellen des Primärschlüssel
      → Falls dieser nur aus einem Attribut besteht, so liegt 2. NF vor. 
   2. Untersuchen, ob aus Teilschlüsselattributen bereits weitere Attribute folgen.
      → Falls dies nicht der Fall ist, so liegt die 2. NF vor. 
      → Falls dies der Fall ist, so Schritt 3.
   3. Für jeden Teilschlüssel, von dem Nichtschlüsselattribute funktional abhängen, wird eine eigene Relation gebildet. Der Teilschlüssel wird Primärschlüssel dieser neuen Relation.
   4. Löschen der ausgelagerten Nichtschlüsselattribute in der Ausgangsrelation.
   5. Wiederholen des Vorgangs ab Schritt 2, bis alle Nichtschlüsselattribute vom gesamten Schlüssel funktional abhängig sind.

In der Relation Lernangebotsübersicht ist die Attributkombination SNr und LANr der neue Primärschlüssel. Aus dem Teilschlüssel LANr lässt sich bereits eindeutig auf das Attribut "Beschreibung" schließen. Aus SNr lässt sich eindeutig auf die Attribute "Name", "Vorname", "Klasse" und" Klassenlehrer" schließen. Somit sind zwei neue Relationsschemen Lernangebot und Schüler zu erzeugen und das verbleibende Schema Lernangebotsübersicht umzubenennen und so zu überarbeiten, dass die Attribute "Beschreibung", "Name", "Vorname", "Klasse" und "Klassenlehrer" gelöscht werden. Das Attribut Stunden bleibt in der Relation Teilnahme, da sein Wert erst durch die Kombination aus Schüler und Lernangebot bestimmt wird.

Beobachtung: Die Beschreibung eines Lernangebots wird nun nur noch einmal gespeichert. Ebenso werden die Stammdaten eines Schülers nicht mehr für jedes belegte Lernangebot wiederholt.

3. Normalform

Eine Relation befindet sich in der dritten Normalform, falls

1. 1. die Relation in der zweiten Normalform ist und
   2. kein Nichtschlüsselattribut transitiv vom Primärschlüssel abhängt. 

Eine transitive Abhängigkeit liegt beispielsweise vor, wenn ein Nichtschlüsselattribut ein anderes Nichtschlüsselattribut bestimmt.

Regel zum Prüfen der zweiten Bedingung:
Hängt ein Nichtschlüsselattribut von einem anderen Nichtschlüsselattribut ab und dadurch nur transitiv vom Primärschlüssel, liegt keine 3. NF vor! 

Schrittfolge zur Herstellung der dritten Normalform:

1. 1. Untersuchung, ob aus Nichtschlüsselattributen andere Nichtschlüsselattribute folgen. 
      → Falls dies nicht der Fall ist, so liegt bereits die 3. NF vor.
      → Falls dies der Fall ist, so Schritt 2.
   2. Bilden einer neuen Relation aus dem bestimmenden Nichtschlüsselattribut und den von ihm funktional abhängigen Attributen. Das bestimmende Attribut wird Primärschlüssel der neuen Relation.
   3. Löschen der ausgelagerten Nichtschlüsselattribute mit Ausnahme des Attributes, das in der neuen Relation Primärschlüssel ist.
   4. Wiederholen des Vorgangs ab Schritt 1, bis keine Abhängigkeiten mehr bestehen.

In den Relationen Teilnahme und Lernangebot kann keine transitive Abhängigkeit zwischen Nichtschlüsselattributen auftreten, da jeweils nur ein Nichtschlüsselattribut vorhanden ist. Beide Relationen befinden sich daher bereits in der 3. NF. In der Relation Schüler folgt aus dem Nichtschlüsselattribut "Klasse" jedoch der "Klassenlehrer". Somit ist eine neue Relation Klassenübersicht mit den Attributen "Klasse" (Primärschlüssel) und "Klassenlehrer" zu erzeugen und das verbleibende Schema Schüler so zu überarbeiten, dass das Attribut "Klassenlehrer" gelöscht wird.