Weniger Redundanz dank Datenbank-Normalisierung

Bei der Normalisierung handelt es sich um einen Ansatz des Datenbankdesigns, der bei relationalen Datenbanken zur Vermeidung von Redundanzen zum Einsatz kommt.

Das relationale Datenbankmodell ist das am weitesten verbreitete Konzept zur computergestützten Datenverwaltung. In relationalen Datenbanken werden Informationen als Datensätze in Tabellen gespeichert, die über Schlüssel miteinander in Beziehung stehen. Ein Datensatz besteht dabei aus mehreren Wertebereichen, die über Tabellenspalten bestimmten Attributen zugeordnet sind.

Folgende Tabelle zeigt die gespeicherten Rechnungsdaten eines fiktiven Betriebsausstatters. Max Mustermann hat für seinen Betrieb 10 Monitore, 12 Mousepads und 1 Bürostuhl bestellt. Die Bestellung von Erika Musterfrau umfasst 2 Laptops und 2 Headsets.

Eine Tabelle einer relationalen Datenbank entspricht der 1. Normalform (1NF), wenn folgende Voraussetzungen erfüllt sind:

• Alle Daten liegen atomar vor.
• Alle Tabellenspalten beinhalten gleichartige Werte.

Ein Datensatz gilt als atomar, wenn jede Information (jeder Sachverhalt) einem separaten Datenfeld zugeordnet ist.

Nachstehend finden Sie unsere Tabelle zu den Rechnungsdaten, in der wir alle Wertebereiche rot hervorgehoben haben, die entweder nichtatomar sind oder die keine gleichwertigen Daten enthalten.

In der Spalte Preis finden sich Angaben in Euro und in Cent. Entscheiden Sie sich für genau eine Art der Angabe, um gleichartige Wertebereiche herzustellen.

Eine Tabelle, die der 2. Normalform entsprechen soll, muss alle Voraussetzungen der 1. Normalform und zusätzlich folgende Bedingung erfüllen:

• Jedes Nichtschlüsselattribut muss vom Primärschlüssel voll funktional abhängig sein.

In der Einleitung wurde eine relationale Datenbank als ein System einzelner Tabellen definiert, die anhand von Schlüsseln miteinander in Beziehung stehen.

Schlüssel dienen bei relationalen Datenbanken der eindeutigen Identifizierung von Datensätzen (Tupeln). Ein Schlüssel, der es ermöglicht, die einzelnen Zeilen einer Datenbanktabelle eindeutig zu benennen, wird Superschlüssel genannt. Ein solcher Schlüssel kann sich aus den Werten einer einzelnen Spalte ergeben oder aus der Summe der Werte mehrerer Spalten.

In unserem Beispiel ergibt sich ein möglicher Superschlüssel beispielsweise aus den Attributen Rechnungsnummer (R.-Nr.), Kundennummer (K.-Nr.) und Rechnungspositionsnummer (P.-Nr.). Wir haben den Superschlüssel in der nachfolgenden Tabelle farblich hervorgehoben.

Ein Schlüssel aus Rechnungsnummer, Kundennummer und Rechnungspositionsnummer mit den Werten {124, 12, 1} ermöglicht es beispielsweise, den Datensatz, der für den Laptop-Kauf von Erika Musterfrau steht, eindeutig zu benennen:

Für solch eine eindeutige Identifizierung sind jedoch nicht sämtliche Angaben des ausgewählten Superschlüssels erforderlich. Bereits eine Kombination aus Rechnungsnummer und Rechnungspositionsnummer – also eine Teilmenge des Superschlüssels – würde dafür ausreichen, die einzelnen Datensätze zu identifizieren. Solche Schlüssel mit einer minimalen Anzahl an Attributen werden Schlüsselkandidaten oder Alternativschlüssel genannt.

In der Regel wird pro Tabelle ein Schlüsselkandidat für die Abbildung der Tabelle ausgewählt. Ideal ist eine fortlaufende Nummerierung. Ein solcher Schlüssel wird als Primärschlüssel bezeichnet und gibt die Reihenfolge der Datensätze an.

Der Primärschlüssel kann wie jeder Schlüsselkandidat als einteiliger oder – wie in unserem Beispiel – als zusammengesetzter Schlüssel vorliegen. Unsere Beispieltabelle verwendet einen zusammengesetzten Primärschlüssel, der sich aus Rechnungsnummer und Rechnungspositionsnummer ergibt.

Um eine Datenbanktabelle in die 2. Normalform zu überführen, gilt es jedoch nicht nur, den Primärschlüssel und alle Nichtschlüsselattribute zu ermitteln, sondern auch deren Beziehung zueinander. Gehen Sie folgendermaßen vor:

1. Prüfen Sie, ob alle Nichtschlüsselattribute voll funktional vom Primärschlüssel abhängig sind. Eine solche Abhängigkeit ist nur dann gegeben, wenn alle Attribute des Primärschlüssels dafür notwendig sind, das Nichtschlüsselattribut eindeutig zu identifizieren. Dies bedeutet auch, dass Tabellen mit einteiligen Primärschlüsseln automatisch der 2. Normalform entsprechen, wenn alle Voraussetzungen für die 1. Normalform gegeben sind.
    
2. Lagern Sie alle Nichtschlüsselattribute, die nicht voll funktional vom gesamten Primärschlüssel abhängig sind, in separate Tabellen aus.

Wenn Sie sich die Beispieltabelle genau anschauen, werden Sie feststellen, dass die Voraussetzungen für die 2. Normalform aus folgenden Gründen nicht erfüllt sind: Die Spalte Datum ist lediglich von der Rechnungsnummer (R.-Nr.), nicht aber von der Rechnungspositionsnummer (P.-Nr.) abhängig. Das Gleiche gilt für die Kundendaten Vorname, Nachname, Straße, Hausnummer (H.-Nr.), Postleitzahl und Ort.

Um die Datentabelle in die 2. Normalform zu überführen, lagern wir alle Attribute, die lediglich von der Rechnungsnummer abhängig sind, in eine separate Tabelle mit dem Namen „Rechnung“ aus.

Die Tabelle mit den verbleibenden Daten nennen wir „Rechnungsposition“.

Soll eine Tabelle in die 3. Normalform überführt werden, müssen alle Voraussetzungen der 1. und 2. Normalform erfüllt sein und zusätzlich die folgende Bedingung:

• Kein Nichtschlüsselattribut darf von einem Schlüsselkandidaten transitiv abhängig sein.

Eine transitive Abhängigkeit besteht dann, wenn ein Nichtschlüsselattribut von einem anderen Nichtschlüsselattribut – und damit mittelbar von dessen Schlüsselkandidaten – abhängig ist.

Unser Datenbankschema verletzt die Bedingungen der 3. Normalform gleich an mehreren Stellen:

In der Tabelle „Rechnung“ sind Vorname und Nachname sowie die Attribute Straße, Hausnummer (H.-Nr.), Postleitzahl und Ort nicht nur vom Primärschlüssel (der Rechnungsnummer), sondern auch von der Kundennummer abhängig.

In der Tabelle „Rechnungsposition“ sind die Attribute Artikel und Preis nicht nur vom Primärschlüssel abhängig, der sich aus Rechnungsnummer und Rechnungspositionsnummer ergibt, sondern auch von der Artikelnummer. Auch hier ist die spezifische Bedingung der 3. Normalform verletzt.

Um alle Abhängigkeiten zwischen Nichtschlüsselattributen zu beseitigen, lagern wir die entsprechenden Attribute in separate Tabellen aus, die durch Fremdschlüssel miteinander verknüpft werden. Es ergeben sich somit die vier normalisierten Tabellen „Rechnung“, „Kunde“, „Rechnungsposition“ und „Artikel“.

Primärschlüssel der Tabelle „Rechnung“ ist eine fortlaufende Rechnungsnummer. Jeder Rechnungsnummer ist das Datum der Rechnungsstellung sowie eine Kundennummer zugeordnet.

Nähere Angaben zum jeweiligen Kunden werden in der Tabelle „Kunde“ gespeichert. Die Tabellen „Rechnung“ und „Kunde“ sind über die Kundennummer miteinander verknüpft. Diese fungiert in der Tabelle „Kunde“ als Primärschlüssel und kommt in der Tabelle „Rechnung“ als Fremdschlüssel zum Einsatz.

Eine zentrale Tabelle unserer Beispieldatenbank ist die Tabelle „Rechnungsposition“. Diese enthält die Information, welche Artikel der jeweiligen Rechnung zuzuordnen sind und wie viele Artikel bestellt wurden. Der fortlaufende Primärschlüssel der Tabelle „Rechnungsposition“ ergibt sich aus der Rechnungsnummer und der Rechnungspositionsnummer. Die jeweiligen Artikel sind lediglich als Artikelnummern aufgeführt, die als Fremdschlüssel fungieren und die Tabelle „Rechnungsposition“ mit der Tabelle „Artikel“ verknüpfen.

Die Tabelle „Artikel“ schließlich beinhaltet Detailinformationen zu den jeweiligen Artikeln, etwa die Artikelbezeichnung und den Preis. Als Primärschlüssel fungiert die fortlaufende Artikelnummer.

Bei der Boyce-Codd-Normalform handelt es sich um eine Verschärfung der 3. Normalform. Bei 3NF gilt:

• Kein Nichtschlüsselattribut darf von einem Schlüsselkandidaten transitiv abhängig sein.

Bei der Boyce-Codd-Normalform heißt es stattdessen:

• Kein Attribut darf von einem Schlüsselkandidaten transitiv abhängig sein, es sei denn, es handelt sich um eine triviale Abhängigkeit.

Relevant ist die Boyce-Codd-Normalform ausschließlich für Datenbanktabellen mit mehreren zusammengesetzten Schlüsselkandidaten, bei denen sich die Schlüssel überlappen; also für den Fall, dass ein und dasselbe Attribut Teilmenge zweier Schlüsselkandidaten ist.

Datenbanktabellen, die der 3. Normalform entsprechen und keine mehrteiligen Schlüsselkandidaten aufweisen, stellen somit automatisch Vertreter der Boyce-Codd-Normalform dar.

Die unten stehende Tabelle weist zwei Schlüsselkandidaten auf, die sich jeweils aus zwei Attributen zusammensetzen.

• Zulieferernummer (Z.-Nr.) und Artikelnummer
• Zulieferer und Artikelnummer

Beide Schlüssel ermöglichen eine Identifikation jedes einzelnen Datensatzes. Einziges Nichtschlüsselattribut ist die Anzahl. Da das Attribut Anzahl von keinem der Schlüsselkandidaten transitiv abhängig ist, entspricht die Tabelle 3NF.

Die Boyce-Codd-Normalform hingegen liegt nicht vor, da eine Abhängigkeit zwischen den Attributen Zulieferernummer (Z.-Nr.) und Zulieferer besteht. Das Attribut Zulieferernummer (Z.-Nr.) ist damit transitiv abhängig vom Schlüsselkandidaten, der sich aus Zulieferer und Artikelnummer ergibt; das Attribut Zulieferer hingegen vom Schlüsselkandidaten, der aus Zulieferernummer (Z.-Nr.) und Artikelnummer resultiert.

Vermeiden lassen sich die transitiven Abhängigkeiten, wenn wir die Ausgangstabelle in die Tabellen „Anzahl“ und „Zulieferer“ aufteilen, sodass keine sich überschneidenden Schlüsselkandidaten mehr vorliegen.

Eine Datenbanktabelle entspricht der 4. Normalform, wenn die Voraussetzungen der Boyce-Codd-Normalform erfüllt sind und zusätzlich folgende Bedingung:

• Es liegen keine mehrwertigen Abhängigkeiten vor, es sei denn, diese sind trivial.

Eine mehrwertige Abhängigkeit (multivalued dependency) liegt immer dann vor, wenn zwei Attribute, die nicht miteinander in Beziehung stehen, vom selben Attribut abhängig sind.

Wir verdeutlichen dies an einem Beispiel:

Folgende Tabelle zeigt pro Kunde an, welche Artikel bestellt wurden und an welchen Zustellort diese geliefert werden müssen.

Der Kunde mit der Kundenummer 234 hat beispielsweise die Artikel 1-0023-D und 2-0023-D bestellt, die an seine Adresse mit der Postleitzahl 12345 geliefert werden sollen. Für den Kunden 567 gehen die Artikel 1-0023-D, 3-0023-D, 4-0023-D und 5-0023-D an den Lieferort 56789.

Die Datensätze lassen sich lediglich mit einem Superschlüssel identifizieren, der sich aus allen drei Attributen – Kundennummer, Artikelnummer und Postleitzahl – ergibt. Da es kein Nichtschlüsselattribut gibt, liegt 3NF vor. Zudem bestehen keine nichttrivialen transitiven Abhängigkeiten. 3.5NF ist somit ebenfalls gegeben. Es liegen jedoch mehrwertige Abhängigkeiten vor: Sowohl das Attribut Artikelnummer als auch das Attribut Postleitzahl sind vom Attribut Kundennummer (K.-Nr.) abhängig, stehen selber jedoch in keinerlei Beziehung zueinander.

Nachteil eines solchen Datenbankdesigns: Immer wenn für einen Kunden ein neuer Artikel aufgeführt wird, muss auch eine Postleitzahl in die Datenbank eingetragen werden. Es entstehen redundante Daten.

Reduzieren lassen sich diese Redundanzen, indem die Tabelle in 4NF überführt wird. Dazu müssen wir die Tabelle so aufteilen, dass keine oder nur noch triviale mehrwertige Abhängigkeiten bestehen. Wir legen daher zwei separate Tabellen an. Möglich ist dies, da Artikelnummer und Postleitzahl in keinerlei Beziehung zueinander stehen.

Eine Datenbanktabelle entspricht der 5. Normalform, wenn sie den Bedingungen der 4. Normalform genügt und zusätzlich folgende Bedingung erfüllt ist:

• Die Tabelle lässt sich nicht weiter aufteilen, ohne dass dabei Informationen verlorengehen.

Unter welchen Umständen ein solcher Fall eintritt, zeigen wir Ihnen anhand eines Beispiels. Für dieses gehen wir davon aus, dass ein Unternehmen eine Website auf Basis von TYPO3 sowie einen Magento-Webshop betreibt. Mit den Software-Projekten sind drei Mitarbeiter betraut: Frau Schmidt, Herr Müller und Herr Krause, die jeweils unterschiedliche Qualifikationen mitbringen.

Die Beispieltabelle zeigt, welcher Mitarbeiter in welchem Software-Projekt welche Qualifikation einbringt. Darüber hinaus lässt sich ablesen, welche Qualifikation für welches Projekt benötigt wird.

Frau Schmidt bringt in das Magento-Projekt ihre Kenntnisse in PHP und SQL ein und greift für die TYPO3-Website auf SQL und JavaScript zurück. Herr Müller übernimmt ebenfalls die PHP-Programmierung bei Magento und arbeitet bei TYPO3 mit JavaScript. Herr Krause schließlich ist nur in das TYPO3-Projekt eingebunden und übernimmt dort die PHP-Programmierung – das jedoch allein. Der Tabelle ist darüber hinaus zu entnehmen, dass für Magento Kenntnisse in PHP und SQL erforderlich sind, während das TYPO3-Projekt PHP-, SQL- und JavaScript-Kenntnisse erfordert.

Die Tabelle besitzt nur einen Schlüssel, der sich aus allen drei Attributen zusammensetzt, und entspricht somit mindestens 3NF sowie der Boyce-Codd-Normalform. Da außerdem keine Abhängigkeiten zwischen allen drei Attributen bestehen, stellt die Tabelle auch eine Vertreterin der 4. Normalform dar.

Nun gilt es zu prüfen, ob auch 5NF gegeben ist. Dazu zerlegen wir die Ausgangstabelle „Mitarbeiterqualifikation im Projekteinsatz“ in die drei Tabellen „Projekteinsatz“, „Mitarbeiterqualifikation“ und „Projektanforderung“.

Die Tabelle „Projekteinsatz“ zeigt an, welcher Mitarbeiter in welches Software-Projekt eingebunden ist.

Der Tabelle „Mitarbeiterqualifikation“ lässt sich entnehmen, welcher Mitarbeiter welche Programmier- bzw. Datenbanksprache beherrscht.

Welche Qualifikation für welches Projekt erforderlich ist, gibt die Tabelle „Projektanforderung“ an.

Auf den ersten Blick wirkt der Datenbankausschnitt nach der Zerlegung deutlich übersichtlicher. Doch weisen die im Rahmen der Normalisierung entstandenen Tabellen auch denselben Informationsgehalt auf wie die Ausgangstabelle?

Um das herauszufinden, müssen wir einen Join vornehmen – eine Datenbankabfrage über alle drei Tabellen. Das Ergebnis überrascht.