Basierend auf dem Datenbankentwurf von E. F. Codd wurde eine Technik zum Datenbankentwurf entwickelt, die als Normalisierung bezeichnet wird. Die Normalisierung und das ER-Modell (entity-relationship model) stellen unabhängige Methoden dar, eine normalisierte Datenbank zu erzeugen. Das Ziel der Normalisierung ist es, ein funktionierendes, robustes und einfach zu wartendes (relationales) Datenbankmodell zu erzeugen.
Es gibt mehrere Normalisierungsstufen, die aufeinander aufbauen. Diese Normalisierungsstufen werden als Normalformen bezeichnet. Durch Umstrukturierung der Datenbank gelangt man von einer Stufe zur nächsten. Heute eingesetzte Datenbanken werden üblicherweise in die dritten Normalform gebracht, obwohl noch weitere Normalformen (beispielsweise 4. oder 5. Normalform, Boyce/Codd Normalform [BCNF]) existieren. Diese sind aber eher von theoretischem als von praktischem Interesse. Normalisierte Datenbanken bieten folgende Vorteile:
Meist fängt man beim Datenbankentwurf nicht mit einer völlig unstrukturierten Datenmenge an, die über die erste oder zweite Normalform bis hin zur dritten Normalform gebracht wird. Intuitiv erstellt man bereits beim ersten Entwurf eine Datenbank, die zwischen der ersten und dritten Normalform angesiedelt ist.
Ein Datenbankmodell, das sich in der ersten Normalform befindet, muss folgende Anforderungen erfüllen:
Zusammengefasst in einem Satz lautet die Definition der ersten Normalform:
»Jedes in der Datenbank enthaltene Attribut ist elementar.«
Über die erste Normalform werden die Daten geordnet und Primärschlüssel zur Datenbank hinzugefügt. Eine Datenbank in der ersten Normalform ist gegen einige Arten der Update-Anomalie immun, bietet aber keinen Schutz vor Delete- oder Insert-Anomalien. Daher ist die erste Normalform für die meisten Anwendungen nicht geeignet.
Damit ein Datenbankmodell sich in der zweiten Normalform befindet, muss es folgende Anforderungen erfüllen:
»Jedes Attribut ist entweder von einem Schlüssel abhängig oder selbst ein Schlüssel.«
Über die zweite Normalform werden die Daten der Datenbank zu Tabellen gruppiert. Eine Relation, die in der ersten Normalform ist und einen Schlüssel besitzt, der nur aus einem einzigen Attribut besteht, ist automatisch in der zweiten Normalform. Besitzt die Relation einen zusammengesetzten Schlüssel, so müssen alle Attribute, die nicht Schlüssel sind, von allen Komponenten des Schlüssels abhängen.
Datenbanken in der zweiten Normalform sind gegenüber Delete-Anomalien anfällig, die durch transitive Abhängigkeiten verursacht werden können. Unter transitiver Abhängigkeit versteht man eine Abhängigkeit eines Attributs von einem anderen, das von einem dritten Attribut abhängig ist. Transitive Abhängigkeiten werden durch Überführung der Datenbank in die dritte Normalform eliminiert.
Ein Datenbankmodell befindet sich in der dritten Normalform, wenn es folgende Anforderungen erfüllt:
»Jedes Attribut, das kein Schlüssel ist, muss nicht-transitiv vom Primärschlüssel abhängen.«
Bei der Überführung in diese Normalform werden Attribute, die in einer Tabelle vom gleichen Schlüssel abhängig sind und untereinander auch eine Abhängigkeit besitzen, in eigene Tabellen ausgelagert. Hierdurch werden Redundanzen innerhalb einer Tabelle vermieden. Dass Attribute nicht voneinander funktional abhängig sein dürfen, kann man auch so beschreiben, dass man jedes Attribut eines Datensatzes (Tupels) unabhängig von den anderen Attributen verändern kann. Die meisten implementierten Datenbanken befinden sich in dieser Normalform.
Oft normalisiert man beim Entwurf das Datenbankmodell zunächst, um dann gezielt an einigen Stellen wieder zu denormalisieren. Das ist notwendig, um die Leistung und den Datendurchsatz gegenüber einer vollständig normalisierten Datenbank zu erhöhen. Man sollte sich bei der Denormalisierung allerdings darüber im Klaren sein, welche Änderungsanomalien man damit wieder zulässt.
Eine andere mögliche Vorgehensweise besteht darin, zunächst mit dem vollständig normalisierten Modell zu arbeiten und bei Leistungseinbußen gezielt an denjenigen Stellen zu denormalisieren, an denen diese auftreten.
ziemer's informatik berät Sie gern in allen Fragen des IT-Projektmanagements, der objektorientierten Softwareentwicklung (auch Expertisen), sowie des Qualitätsmanagements und der Qualitätssicherung. Bitte besuchen Sie unsere Kontaktseite.