Normalformen von Datenbanken

Möchte man Informationen innerhalb einer Datenbank hinterlegen, so bieten sich hierfür gewisse Regeln an, die als Normalformen bezeichnet werden und der Vermeidung von Redundanzen und Anomalien dienen. Um diese Regeln genauer nachvollziehen zu können, konstruieren wir uns ein Beispiel und wenden die Regeln Schritt für Schritt darauf an. Zunächst kreieren wir uns einen Satz von Daten einer künstlichen Person. Ein solcher Datensatz wird innerhalb einer relationalen Datenbank als Tupel bezeichnet.

 

Wir erschaffen einen:

  • Dr. Daniel Müller

  • Geboren am 01.01.1980

  • Wohnhaft in 12345 Neustadt, Kunstallee 1

  • Männlich, 174 cm groß, Gewicht von 77 kg

  • Festnetznummer 02345/98765

  •  Mobil 0176/54329876

 

Nun stellt sich die Frage, auf welche Art man diese Daten in einer Datenbank speichern würde.

Generell werden Daten in einer Datenbank in Relationen gespeichert, weshalb diese als “relationale Datenbanken” bezeichnet werden. Diese Relationen werden typischerweise in Tabellen gespeichert, deren Attributbezeichner dem Spaltenkopf entsprechen und somit das Attribut klar identifizieren.

Ohne die Regeln der Datenbankspeicherung zu kennen, würden wir also unseren Dr. Daniel Müller in der Zeile (dem Tupel) einer Tabelle speichern, welche Personendaten enthält.

Ein solche Speicherung entspricht der Nullten Normalform. Diese Normalform enthält keine festen Regeln, wie Daten gespeichert werden müssen, sondern verlangt lediglich den kompletten Satz an Daten zu hinterlegen.

Wie man auf den ersten Blick erkennen kann, birgt diese Art der Speicherung gewisse Risiken. Das Vorliegen mehrerer Informationen in ein und derselben Zelle kann einerseits zu Redundanz führen, weil man sich nachträglich entscheiden könnte eine zusätzliches Arttribut einzuführen, welches einer dieser mehrfach gespeicherten Informationen entspricht, andererseits wird der explizite Zugriff auf eine der Informationen innerhalb einer solchen Spalte erschwert.

Um diese Risiken zu umgehen, wenden wir die erste Normalform an, welche verlangt, jede Information in einem eigenen Attribut zu speichern. Da diese Form die kleinstmögliche, sinnvoll nicht weiter unterteilbare Speicherung verlangt, wird sie als atomare Normalform bezeichnet.

Durch diese Anwendung wurden sämtliche Informationen elementar in der Datenbank hinterlegt und sind individuell abrufbar.

Ein weiterer Weg diese Daten zu hinterlegen identifiziert zunächst sämtliche vollständig funktionalen Abhängigkeiten. Diese Abhängigkeiten werden anschließend so aufgeteilt, dass alle Attribute vollständig funktional einem Primärschlüssel zuordenbar sind.

Zunächst verdeutlichen wir uns die funktionale Abhängigkeit, um im Anschluss die vollständige funktionale Abhängigkeit zu verstehen.

Von funktionaler Abhängigkeit spricht man, wenn zwei Attribute A und B Elemente eines Relationsschemas R sind und A den Wert des von ihm abhängigen Attributs B eindeutig festlegt. Dabei bezeichnet man das Attribut A als Determinante des Attributs B.

Wir möchten uns dazu ein neues Beispiel erstellen, in dem verschiedene Fahrzeuge gespeichert werden.

In unserem Beispiel ist durch die Zuordnung eines Typs auf die Attributwerte PKW bzw. Zweirad die Anzahl der Räder eindeutig bestimmt. Diese Abhängigkeit ist in diesem Fall funktional. Wie sieht jedoch die Zuordenbarkeit des Typs von den vorherigen Attributen Bezeichner und Hersteller aus?

Die Typzuordnung lässt sich durch die Bezeichnerspezifikation in den ersten 3 Fällen leicht abhandeln. Im vierten Beispiel jedoch ergibt sich ein Problem. Der Bezeichner “Mokka” lässt eine Vielzahl von möglichen Typen zu, z.B. Süßspeise, Stadt im Jemen, Getränk, etc.

Ohne die Information, dass es sich bei der Tabelle um Fahrzeugtypen handeln soll, lässt sich nur mit der Information aus dem Bezeichner demnach kein eindeutiger Typ zuordnen. Erst in Verbindung mit dem Attribut Hersteller lässt sich die Typzuordnung eindeutig vollziehen.

Dieses Beispiel verdeutlicht die Forderung nach vollständiger funktionaler Abhängigkeit. Wäre der Typ nur durch die Information des Bezeichners identifizierbar, ist die Abhängigkeit vom Hersteller sinnlos. Das Beispiel des Bezeichners “Mokka” verdeutlicht jedoch, dass die Erstellung eines eindeutigen Schlüssels je nach Dateninhalt beliebig kompliziert sein kann. Die zweite Normalform verlangt daher zusätzlich zur vollständigen funktionalen Abhängigkeit nach einem minimalen Primärschlüssel. Typischerweise wird ein solcher Schlüssel über eine ID generiert und entspricht i.d.R einer Ganzzahl dessen Wert zwingend nur einmalig vergeben werden darf.

Wenden wir diese Forderung auf unser Fallbeispiel an, wird die Tabelle schlicht um ein Attribut mit Namen Personen ID erweitert, dessen Wert in jeder Tabelle einmalig vergeben wird und damit den betreffenden Datensatz eindeutig identifiziert.

Die dritte hier vorzustellende Normalform konzentriert sich auf eine Balance zwischen Vermeidung von Anomalien und Redundanzen und der Performance der Abfragen von SQL-Statements.

Eine Datenbank liegt genau dann in der dritten Normalform vor, wenn sie die Bedingungen der zweiten Normalform erfüllt und zusätzlich das Vorliegen transitiver Abhängigkeiten verhindert. Eine transitive Abhängigkeit liegt vor, wenn der Wert eines Attributs Z vom Attribut Y funktional abhängig ist, dieses Attribut Y seinerseits wiederum von Attribut X abhängt.

 

X fungiert demnach als Determinante für das Attribut Y, welches als Determinante für das Attribut Z dient.

Die von der dritten Normalform geforderte Vermeidung von transitiven Abhängigkeiten führt dazu das sämtliche Attribute, die eine solche transitive Abhängigkeit aufweisen in einen eigenen Datensatz ausgelagert werden. In diesem Datensatz stellt die Determinante dieser Attribute (im Beispiel Y) den Primärschlüssel dar und wird in der ursprüglichen Tabelle als Fremdschlüssel referenziert. Über diese Referenz wird die Relation zwischen den Tabellen hergestellt und die Datenkonsistenz erhalten. Angewendet auf unsere künstliche Person lassen sich die Daten wie folgt speichern:

Letzlich ist die Art der Datenspeicherung nicht zwingend an die Anwendung einer der vorgestellten Formen gebunden. Die Struktur einer Datenbank muss sich immer an den Anforderungen der Speicherung und des Abrufs der darin enthaltenen Daten orientieren. Diese Struktur lässt eine Aufhebung von Normalformen zu, wobei zu beachten ist, dass dabei mit den auftretenden Nachteilen, welche die Regeln der Normalformen verhindern, umgegangen werden muss.

Die Aufhebung von Redundanzen ist keinen festen Regeln unterworfen, wie dies bei den Normalformen der Fall war. In unserem Beispiel wurden die Daten der KörperID erfasst. Dies könnte z.B. bei einer medizinischen Datenbank von Interesse sein. Die Struktur einer solchen Datenbank könnte einen schnellen Zugriff auf Kontaktdaten einfordern, wodurch die zusätzliche Speicherung, beispielsweise der Mobilfunknummer, in der Personentabelle verlangt wird. Dadurch wird die selbe Information sowohl in der Tabelle PersonenID als auch KontaktID gespeichert, was per Definition redundant ist. Allerdings ist der Abruf von Daten innerhalb einer Tabelle performanter, als der Abruf von Daten, die mittels JOIN aus mehreren Tabellen vereint werden müssen. Je nach Häufigkeit des Zugriffs ist es für den Datenbankarchitekten demnach sinnvoll, Redundanzen bewusst einzuführen und die Gefahr einer Anomalie in Kauf zu nehmen.

Die drei häufigsten Anomalien sind die Einfüge-, Update- und Löschanomalie. Würde man im Beispiel die Telefonnummer des Patienten nur innerhalb der Kontakttabelle ändern und in der Personentabelle unverändert lassen, würden die Werte der beiden identischen Attribute Mobilfunknummer nicht mehr übereinstimmen. Die bewusste Inkaufnahme von Redundanzen ist demnach risikobehaftet und muss immer gegen das Auftreten von Anomalien abgewogen werden.

Das fachliche Design einer Datenbank ist immer abhängig von den Anforderungen an die Datenbank und die erwartete Performance. Die vorgestellten Normalformen dienen zur sinnreichen Konzeption eines solchen Designs und helfen, die Datenkonsistenz zu erhalten und Fehler zu vermeiden. Dabei sollte man sich immer bewusst sein, dass die Regeln dieser Normalformen nicht bindend sind und je nach Konzept und Bedarf zum Teil oder gänzlich verworfen werden können.