Bereits dreimal wurde ich in meinem schulischen Werdegang mit der Thematik «Normalformen von Datenbanken» konfrontiert. Die Vorstellung der aufeinander aufbauenden Normalisierungsschritte verlief dabei in allen drei Fällen erstaunlich ähnlich: Der Dozent erläutert ausführlich, wie man sich von der ursprünglichen Datenstruktur Schritt für Schritt zur dritten Normalform hocharbeitet, bricht seine Ausführungen dann ab und verweist auf Literatur zu den restlichen – anscheinend weniger relevanten – Normalformen. Da jeder dieser Vorfälle meine Neugier zur Thematik weiter geweckt hat und es eventuell noch andere Leuten so gehen könnte, möchte ich im Folgenden kurz die Erkenntnisse aus meinem Selbststudium zu diesem Thema präsentieren.
Die BCNF-Normalform
Namentlich etwas schräg in der Landschaft stehend folgt auf die 3. Normalform die Boyce-Codd-Normalform (BCNF). Die BCNF setzt voraus, dass jedes determinierende Attribut ein Schlüsselkandidat der Relation ist.
Im oben aufgeführten Beispiel ist das Produkt durch den Shop determiniert, da jeder Shop auf ein Produkt spezialisiert ist (Annahme). Der Shop selbst ist in Tabelle 1 jedoch kein Schlüsselkandidat, da er ohne die Lieferanteninformation nicht eindeutig zur Identifikation eines Datensatzes genutzt werden kann.
Für die Überführung in die BCNF wird die ursprüngliche Relation in zwei neue Relationen aufgeteilt. In Tabelle 3: «Shop – Produkt Beziehung», ist das Attribut «Shop» nun ein Schlüsselkandidat, sodass die BCNF erfüllt ist. Sämtliche Einträge aus Tabelle 1 bleiben nach wie vor rekonstruierbar.
Die 4. Normalform
Als nächster Normalisierungsschritt folgt die – eigentlich bereits an Position der BCNF erwartete – 4. Normalform. Einfach erklärt stellt die 4NF zusätzlich sicher, dass die Attribute, welche gemeinsam innerhalb einer Relation abgebildet werden, zwingend auch einen inhaltlichen Zusammenhang haben.
Tabelle 4 zeigt auf, welche Lieferanten welche Produkte in welche Regionen liefern. Da wir in unserem Beispiel davon ausgehen, dass die Lieferregion unabhängig von der Produktpalette definiert wird, verletzt die Tabelle die 4NF, da zwei inhaltlich unabhängige Attribute in derselben Relation abgebildet sind.
Zur Überführung in die 4NF erfolgt erneut eine Aufteilung in zwei neue Relationen. Die Tabellen 4 und 5 zeigen die Produkte respektive Lieferregionen pro Lieferanten und weisen somit in beiden Fällen inhaltliche Abhängigkeiten zwischen den einzelnen Attributen auf ohne das Informationen aus den ursprünglichen Datensätzen verlorenen gegangen wären.
Die 5. Normalform
Nicht ganz überraschend folgt auf die 4. Normalform die (bislang) letzte 5. Normalform. Im Gegensatz zur 4NF, bei welcher wir inhaltlich voneinander unabhängige Attribute aus der gleichen Relation entfernt haben, müssen wir in der 5NF sicherstellen, dass in einer Relation nicht mehrere inhaltlich verknüpfte Beziehungen zum Schlüssel bestehen.
Tabelle 7 zeigt, welche Lieferanten welche Produkte an welche Kunden liefern. Sowohl das Produkt als auch der Kunde sind abhängig vom Lieferanten. Beide Beziehungen sind jedoch auch abhängig voneinander, da der Kunde den Produktbedarf definiert.
Um das Schema in die 5NF zu bringen, wird jede Beziehung in einer eigenen Relation abgebildet. Dadurch ist sichergestellt, dass sich die Abhängigkeiten innerhalb einer Relation nicht gegenseitig beeinflussen. Im Gegensatz zu den vorherigen Normalformen lässt sich die ursprüngliche Tabelle aus der 5NF nicht zwingend wiederherstellen, da im obigen Beispiel beispielsweise eine Zeile «Amazon, USB-Stick, Schule» entstehen würde, die ursprünglich nicht existierte.
Fazit: Nachdem ich mich etwas ausgiebiger mit den höheren Normalformen einer Datenbank auseinandergesetzt habe, kann ich gut nachvollziehen, warum darauf in keinem meiner Kurse genauer eingegangen wurde. Obwohl jeder Schritt zur weiteren Normalisierung einer Datenbank Sinn machte, spürte ich, wie die möglichen Anwendungsfälle bei jedem weiteren Schritt abnahmen und ich mir die Beispiele regelrecht aus den Fingern saugen musste. Obwohl ich hier keine auantitativen Aussagen dazu machen kann, inwiefern die Geschwindigkeit einer Datenbank durch diese letzten Normalisierungsschritte weiter erhöht werden kann, denke ich, dass wir im Sinne eines gesunden Aufwand-Ertragsverhältnisses mit der 3NF doch sehr gut bedient sind.
