Normalisierung (Datenbanknormalisierung)

Regeln für die Datennormalisierung

Die Regeln der Datennormalisierung erhöhen zwar die Duplizierung von Daten, führen aber nicht zu Datenredundanz, das heißt unnötiger Duplizierung. Die Normalisierung von Datenbanken ist in der Regel ein Verfeinerungsprozess nach der anfänglichen Identifizierung der Datenobjekte, die in der relationalen Datenbank enthalten sein sollen, der Ermittlung ihrer Beziehungen und der Definition der erforderlichen Tabellen und Spalten innerhalb jeder Tabelle.

Beispiel für Datennormalisierung

Wenn diese Tabelle dazu dient, den Preis der Artikel zu erfassen, und der Benutzer einen der Kunden löschen möchte, wird er auch den Preis löschen. Die Normalisierung der Daten bedeutet, dies zu verstehen und das Problem zu lösen, indem diese Tabelle in zwei Tabellen aufgeteilt wird, eine mit Informationen über jeden Kunden und das von ihm gekaufte Produkt und die zweite mit jedem Produkt und seinem Preis. Fügt man etwas hinzu oder löscht etwas in einer der beiden Tabellen, hat dies keine Auswirkungen auf die andere.

Die Normalisierungsgrade von relationalen Datenbanktabellen wurden definiert und umfassen:

Erste Normalform (1NF). Dies ist die Basisstufe der Datenbanknormalisierung und entspricht im Allgemeinen der Definition jeder Datenbank, nämlich:

• Sie enthält zweidimensionale Tabellen mit Zeilen und Spalten.
• Jede Spalte entspricht einem Unterobjekt oder einem Attribut des Objekts, das durch die gesamte Tabelle repräsentiert wird.
• Jede Zeile stellt eine eindeutige Instanz dieses Teilobjekts oder Attributs dar und muss sich in irgendeiner Weise von jeder anderen Zeile unterscheiden (das heißt es sind keine doppelten Zeilen möglich).
• Alle Einträge in einer Spalte müssen von der gleichen Art sein. Zum Beispiel sind in der Spalte Kunde nur Kundennamen oder -nummern erlaubt.

Zweite Normalform (2NF). Auf dieser Normalisierungsebene muss jede Spalte in einer Tabelle, die keine Determinante des Inhalts einer anderen Spalte ist, selbst eine Funktion der anderen Spalten in der Tabelle sein. In einer Tabelle mit drei Spalten, die beispielsweise die Kunden-ID, das verkaufte Produkt und den Preis des verkauften Produkts enthalten, ist der Preis eine Funktion der Kunden-ID (die zu einem Rabatt berechtigt) und des spezifischen Produkts. In diesem Fall sind die Daten in der dritten Spalte von den Daten in der ersten und zweiten Spalte abhängig. Diese Abhängigkeit tritt im 1NF-Fall nicht auf.

Die Spalte mit der Bezeichnung Kunden-ID wird als Primärschlüssel betrachtet, da es sich um eine Spalte handelt, die die Zeilen in dieser Tabelle eindeutig identifiziert, und sie erfüllt die anderen akzeptierten Anforderungen im Standard-Datenbankmanagementschema: Sie hat keine NULL-Werte und ihre Werte werden sich im Laufe der Zeit nicht ändern.

In dem obigen Beispiel werden die anderen Spaltenüberschriften als Schlüsselkandidaten betrachtet. Die Attribute dieser Schlüsselkandidaten, die sie eindeutig machen, werden als Primärattribute bezeichnet.

Dritte Normalform (3NF). Bei der zweiten Normalform sind Änderungen immer noch möglich, da eine Änderung an einer Zeile in einer Tabelle sich auf Daten auswirken kann, die sich auf diese Informationen aus einer anderen Tabelle beziehen. Wenn Sie zum Beispiel in der oben genannten Kundentabelle eine Zeile entfernen, die einen Kundenkauf beschreibt (zum Beispiel wegen einer Rückgabe), wird auch die Tatsache entfernt, dass das Produkt einen bestimmten Preis hat. In der dritten Normalform wird diese Tabellen in zwei Tabellen aufgeteilt, so dass die Produktpreise separat verfolgt werden können.

Zu den Erweiterungen der grundlegenden Normalformen gehören die Domänen-/Schlüssel-Normalform, bei der ein Schlüssel jede Zeile in einer Tabelle eindeutig identifiziert, und die Boyce-Codd-Normalform (BCNF), die die in der 3NF verwendeten Techniken verfeinert und erweitert, um einige Arten von Anomalien zu behandeln.

Die Fähigkeit der Datenbanknormalisierung, Datenanomalien, Datenredundanzen und Datenduplikate zu vermeiden oder zu reduzieren und gleichzeitig die Datenintegrität zu verbessern, hat sie seit vielen Jahren zu einem wichtigen Bestandteil des Werkzeugkastens von Datenentwicklern gemacht. Es ist eines der Markenzeichen des relationalen Datenmodells.

Das relationale Modell entstand in einer Zeit, in der Geschäftsunterlagen in erster Linie auf Papier geführt wurden. Die Verwendung von Tabellen war in gewisser Weise ein Versuch, die Art der auf Papier verwendeten Tabellen widerzuspiegeln, die als ursprüngliche Darstellung der (meist buchhalterischen) Daten dienten. Die Notwendigkeit, diese Art der Darstellung zu unterstützen, hat in dem Maße abgenommen, in dem die digitale Darstellung von Daten die papiergebundenen Datensätze ablöst.

Aber auch andere Faktoren haben dazu beigetragen, die Dominanz der Datenbanknormalisierung in Frage zu stellen. Im Laufe der Zeit haben die kontinuierlichen Kostensenkungen bei der Festplattenspeicherung sowie die neuen analytischen Architekturen die Vorherrschaft der Normalisierung beeinträchtigt.

Der Aufstieg der Denormalisierung als Alternative begann in den 1990er Jahren mit der Einführung von Data Warehouses. In jüngerer Zeit sind dokumentenorientierte NoSQL-Datenbanken entstanden; diese und andere nicht-relationale Systeme greifen häufig auf andere Speichertypen zurück. Mehr als in der Vergangenheit müssen Datenarchitekten und -entwickler beim Entwurf ihrer Systeme die Normalisierung und Denormalisierung von Daten abwägen.

Tools für die Datenbanknormalisierung

Datenmodellierungssoftware kann Funktionen enthalten, mit denen sich die Vorbereitung eingehender Daten für die Analyse automatisieren lässt. IT-Manager müssen dennoch einen Plan entwickeln, um häufige Probleme zu lösen, einschließlich der Datennormalisierung. Zu den Anbietern im Bereich der Datennormalisierung gehören 360Science, ApexSQL und viele Nischenentwickler.