Weniger Redundanz dank Datenbank-Normalisierung
Einer der Grundbegriffe der relationalen Datenmodellierung ist die Normalisierung. Im relationalen Datenbankmodell zeichnet sich gutes Datenbankdesign durch ein Minimum an Redundanz aus. Der Grund: Redundante Daten führen zu semantischen Anomalien. Diese wiederum erschweren die automatische Datenverarbeitung sowie die Pflege der Datenbank. Normalisierung ist eine Strategie, Redundanzen in relationalen Datenbanken zu beseitigen. Wir zeigen Ihnen, wie Sie dabei vorgehen.
Was ist 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.
In der Datenbank des Onlineshops werden die Rechnungsdaten den Attributen Rechnungsnummer (R.-Nr.), Datum, Kunde, Kundennummer (K.-Nr.), Adresse, Rechnungspositionsnummer (P.-Nr.), Artikel, Artikelnummer (Art.-Nr.), Anzahl (Anz.) und Preis zugeordnet. Jede Zeile der Tabelle steht für einen Datensatz. Ein solcher Datensatz wird als Tupel bezeichnet.
Der oben dargestellte Datenbankausschnitt fungiert als Beispiel für ein schlechtes Datenbankdesign. Bereits auf den ersten Blick fällt auf, dass die Tabelle zahlreiche Redundanzen aufweist. Hinzu kommt, dass die Wertebereiche in den Spalten Kunde und Adresse mehrwertige Daten enthalten. Man spricht von einer nicht normalisierten Datenbank.
Der größte Nachteil nichtnormalisierter Datenbanken ist der erhöhte Speicherbedarf infolge redundanter Werte. Außerdem lassen sich Attribute, die mehrwertige Daten enthalten, schlecht auslesen und miteinander in Beziehung setzen.
Beispiel: Beide Kunden im oben aufgeführten Datenbankausschnitt sind in Musterhausen ansässig. Doch da diese Information nicht separat erhoben wurde, lässt sich die Datenbank nicht ohne Weiteres nach Kunden aus demselben Ort filtern.
Um doppelte und mehrwertige Wertebereiche zu vermeiden, sind im Rahmen relationaler Datenbankmodelle drei aufeinander aufbauende Normalformen entwickelt worden.
Bei einer Normalform handelt es sich um einen definierten Zielzustand. Für jede Normalform wurden spezielle Anforderungen festgelegt, die erfüllt sein müssen, wenn dieser Zielzustand eintreten soll. Eine Datenbank entspricht also genau dann der 1., 2. oder 3. Normalform, wenn alle Voraussetzungen für die jeweilige Normalform erfüllt sind.
Als Normalisierung bezeichnet man die Überführung einer Datenbanktabelle in eine Normalform höheren Grades. Die Überführung in eine Normalform geringeren Grades wird Denormalisierung genannt.
Normalisierung: So normalisieren Sie Ihre Datenbank
Um Ihnen die Überführung einer relationalen Datenbank in die 1., 2. und 3. Normalform zu veranschaulichen, spielen wir die einzelnen Stufen der Normalisierung anhand eines Beispiels durch. Ausgangspunkt ist der oben aufgeführte Datenbankausschnitt.
1. Normalform (1NF)
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.
Die zahlreichen Hervorhebungen zeigen: Unsere Ausgangstabelle verletzt beide Voraussetzungen und entspricht somit nicht der 1. Normalform.
Soll der aufgeführte Datenbankausschnitt gemäß der 1. Normalform normalisiert werden, ist folgendes Vorgehen erforderlich:
- Teilen Sie alle mehrwertigen Daten auf separate Spalten auf.
- Überprüfen Sie die Werte einer jeden Spalte auf Gleichartigkeit.
Um die Datensätze der Beispieltabelle in eine atomare Form zu bringen, müssen die Attribute Kunde und Adresse in die spezifischeren Attribute Vorname und Nachname bzw. Straße, Hausnummer (H.-Nr.), Postleitzahl (PLZ) und Ort aufgeteilt werden.
Ab wann ein Wert als atomar angesehen wird, hängt vom Nutzungskontext ab. Ist eine Trennung von Vor- und Nachname beispielweise nicht erforderlich, kann auch der vollständige Name einer Person als atomar gelten. In der Praxis empfiehlt es sich jedoch, mehrteilige Werte in kleinstmögliche Einheiten zu unterteilen.
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.
Das Ergebnis ist eine Tabelle, die zwar der 1. Normalform entspricht, aufgrund doppelter Werte jedoch noch immer keine effiziente Datenverarbeitung erlaubt. Es empfiehlt sich daher, die Tabelle in die 2. Normalform zu überführen, um die Redundanzen zu beseitigen.
Die 1. Normalform schreibt atomare Wertebereiche vor und ermöglicht dadurch Datenbankabfragen. Daten, die Teil eines nichtatomaren Wertebereichs sind, lassen sich nicht separat abfragen.
2. Normalform (2NF)
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:
- 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.
- 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“.
Die Rechnungsnummer (R.-Nr.) findet sich nach der Normalisierung in beiden Tabellen und verknüpft diese miteinander. Während das Attribut in der Tabelle „Rechnung“ als Primärschlüssel fungiert, kommt es in der Tabelle „Rechnungsposition“ als Fremdschlüssel zum Einsatz und ist zugleich Teil des zusammengesetzten Primärschlüssels der Tabelle.
Die Verknüpfung via Fremdschlüssel ermöglicht ein gemeinsames Abfragen beider Tabellen. Man spricht von einem Join.
Die Beispieldaten entsprechen nun der 2. Normalform. Gänzlich beseitigen ließen sich die Redundanzen dadurch aber noch nicht. Ziel einer Normalisierung ist daher in der Regel die 3. Normalform.
3. Normalform (3NF)
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.
In unserem Beispiel mag es wenig effizient erscheinen, zwei Tabellen in vier Tabellen aufzuspalten. Und tatsächlich fallen Redundanzen bei den Daten von lediglich zwei Kunden kaum ins Gewicht. Doch stellen Sie sich vor, Sie möchten mehrere Hunderttausend Datensätze zu Kunden oder zu Ihrem Produktsortiment konsistent und widerspruchsfrei in einer relationalen Datenbank verarbeiten! Dies gelingt in der Regel nur mit einem Datenbankschema, das der 3. Normalform entspricht.
Beachten Sie, dass sich doppelte Werte in relationalen Datenbanken oft nicht vollständig vermeiden lassen. Wenn Sie das durchgespielte Datenbankbeispiel betrachten, werden Sie feststellen, dass die Verknüpfung von Datenbanktabellen durch Fremdschlüssel mit Redundanzen verbunden sein kann. Man spricht in diesem Fall von Schlüsselredundanzen.
Auch wenn die Normalisierung von Datenbanken mit einem höheren Programmieraufwand verbunden ist, gilt 3NF – die 3. Normalform – allgemein als Standard für relationale Datenbankschemata, von dem nur in Ausnahmefällen abgewichen wird. Beispielsweise werden Datenbanken, die der 3. Normalform entsprechen, mitunter in die 2. Normalform denormalisiert. Der Grund dafür ist, dass Joins über mehrere Tabellen bei sehr großen Datenbanken zeitaufwendig sind. Durch die Denormalisierung wird die Anzahl der Tabellen und damit auch die Abfragezeit verkürzt.
Weitere Normalformen
In der Praxis endet die Normalisierung meist mit der 3. Normalform. Die folgenden Normalformen beziehen sich auf Datenbankschemata mit speziellen Gegebenheiten und kommen daher nur in Ausnahmenfällen zur Anwendung.
Boyce-Codd-Normalform (3.5NF)
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.
Die Boyce-Codd-Normalform verhindert Redundanzen, die dadurch entstehen, dass identifizierende Schlüsselattribute durch sich überlappende Schlüsselkandidaten mehrfach aufgeführt werden müssen. Im oben aufgeführten Beispiel verhindert die Überführung in 3.5NF doppelte Werte in der Spalte Zulieferer.
Von einer trivialen Abhängigkeit spricht man, wenn ein Attribut von sich selbst voll funktional abhängig ist. Da dies bei jedem Datenbankzustand für jedes Attribut stets der Fall ist, entsprechen triviale Abhängigkeiten in der Logik einer Tautologie.
4. Normalform
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.
Wie das Beispiel zeigt, beseitigt die 4. Normalform Redundanz, die durch mehrwertige Abhängigkeiten entsteht – in diesem Fall speziell in der Spalte Postleitzahl (PLZ).
Wir gehen bei diesem (zugegebenermaßen etwas konstruierten) Beispiel davon aus, dass für jeden Kunden nur eine Postleitzahl eingetragen werden kann. Hätten die Kunden hingegen die Möglichkeit, sich verschiedene Produkte an unterschiedliche Zustellorte liefern zu lassen, bestünde eine Abhängigkeit zwischen Artikelnummer sowie Postleitzahl und die Ausgangstabelle entspräche auch ohne Normalisierung bereits 4NF.
5. Normalform
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.
Bei der Rekonstruktion der Ausgangstabelle müssen wir zwangsläufig davon ausgehen, dass jeder am Projekt beteiligte Mitarbeiter jede seiner Qualifikationen einbringt, sofern diese vom jeweiligen Projekt erfordert werden. Die Information, dass Herr Krause die PHP-Programmierung für das TYPO3-Projekt allein übernommen hat, ist verlorengegangen. Die Ausgangstabelle lässt sich somit nicht verlustfrei zerlegen und entspricht damit bereits der 5. Normalform.
In der Praxis werden Sie nur selten auf Datenbankschemata stoßen, die die Voraussetzungen für 4NF erfüllen, aber nicht der 5. Normalform entsprechen. Interessant ist 5NF jedoch für Anwendungsfälle, bei denen aus vorhandenen Daten neue Informationen gewonnen werden sollen.
Das Beispiel zeigt immerhin, das sowohl Frau Schmidt als auch Herr Müller PHP-Kenntnisse besitzen, die sie, da sie in das TYPO3-Projekt eingebunden sind, zukünftig auch dort einbringen könnten – eine Information, die sich das Unternehmen dafür zunutze machen könnte, die Software-Entwicklung in diesem Projekt effizienter zu gestalten.
Vor- und Nachteile der Normalisierung
Ziel der Normalisierung ist die Reduktion doppelter Werte. Überführen Sie Ihre Datenbank in eine der aufgeführten Normalformen, hat dies den Vorteil, dass das Zielschema weniger Redundanz aufweist als das Ausgangsschema. Normalisierung erleichtert Ihnen somit die Pflege Ihrer Datenbank.
Andererseits geht die Normalisierung von Datenbanken immer mit der Auslagerung von Attributen in separate Tabellen einher. Dies erfordert möglicherweise die Integration von Fremdschlüsseln und kann somit zu Schlüsselredundanzen führen. Der zentrale Nachteil jedoch ist, dass logisch zusammengehörige Daten in einer normalisierten Datenbank nicht mehr zusammen gespeichert werden. Möchte man Daten, die auf verschiedene Tabellen aufgeteilt wurden, zusammenführen, ist zunächst ein Join erforderlich.
Per Datenbankabfragen über Joins lassen sich komplexe Informationen herausfiltern. In der Umsetzung sind Joins jedoch aufwendiger als einfache Abfragen. Hinzu kommt ein deutlich größerer Zeitaufwand, wenn Joins über eine Vielzahl von Datenbanktabellen erfolgen.