Was ist Datenbanknormalisierung? Was sind die Normalformen?

Bei der Datenbanknormalisierung handelt es sich um eine strukturierte Reihe von Schritten zur optimalen Gestaltung eines Datenbankmodells. Durch Datenbanknormalisierung können Datenbankadministratoren, Dateningenieure und Datenarchitekten ein Framework zum Speichern der Daten einer Anwendung so modellieren und entwerfen, dass die Datenbankschicht der Anwendung mit maximaler Effizienz funktioniert.

In diesem Zusammenhang bezieht sich das Datenmodell auf die Reihe von Beziehungen und konzeptionellen Einheiten, die für den Geschäftsanwendungsfall spezifisch sind, den die Daten darstellen. Im Fall von Retail-Banking-Daten können dies beispielsweise Finanztransaktionen und Informationen zu Kundensparkonten sein.

Da die meisten Websites und Softwareanwendungen auf die Speicherung von Daten angewiesen sind, um effizient zu funktionieren, bleibt die Datenbanknormalisierung ein entscheidender Schritt in der Datenverwaltung.

Es ist erwähnenswert, dass es auch eine sechste Normalform (6NF) gibt. Da 6NF jedoch noch nicht standardisiert ist, habe ich es nicht in diese Definition aufgenommen.

Verwandte Lektüre aus dem Tech Dictionary von Built In: Was ist Datenarchitektur?

Der Datenbanknormalisierungsprozess ist aus vielen Gründen ein entscheidender Schritt in unserem Datenbankmanagement. Die Datenbanknormalisierung hilft uns:

Datenbankanomalien sind Fehler, die beim Ändern von Daten auftreten, beispielsweise beim Einfügen, Aktualisieren oder Löschen bestimmter Datenwerte oder Attribute. Diese Änderungen können zu falschen oder fehlenden Daten führen. Durch die Normalisierung der Daten kann verhindert werden, dass die Datenbank im täglichen Betrieb unter diesen Problemen leidet.

Funktionale Abhängigkeiten sind Beziehungen zwischen Datenbankattributen, bei denen es sich um die konzeptionellen und physischen Einheiten handelt, die die Daten darstellen. Das Attribut eines Kunden könnte seine Telefonnummer oder Privatadresse sein.

So funktioniert es: Ein Attribut (A) ist funktional von einem anderen Attribut (B) abhängig, wenn Sie durch Kenntnis des Werts von B den Wert von A eindeutig bestimmen können. Dieser Prozess funktioniert nicht umgekehrt. Mit anderen Worten: Funktionale Abhängigkeiten stellen Beziehungen zwischen Daten dar. Diese lassen sich am besten durch Normalisierung organisieren oder verwalten, ein Prozess, den ich weiter unten demonstriere.

Beim Datenbankdesign möchten wir vermeiden, dass viele Teile der Datenbank (und ihrer Daten) von mehreren anderen Teilen der Datenbank abhängen. Mit anderen Worten: Wir wollen ein eng gekoppeltes System vermeiden.

In einem eng gekoppelten System kann ein Teil des Systems ausfallen oder nicht mehr funktionieren, was dazu führen kann, dass viele andere Teile ausfallen, was sich letztendlich negativ auf die Datenbankleistung auswirkt.

Durch die Normalisierung können Datenbankadministratoren ein lose gekoppeltes System erreichen, das modularer und weniger voneinander abhängig ist. Diese lose Kopplung hilft bei der Betriebsdiagnose und der Ursachenanalyse von Problemen, wenn sie unvermeidlich auftreten.

Mehr Datenbank 101 von unseren ExpertenWas ist eine relationale Datenbank?

Bei der Datenbankverwaltung beziehen sich Redundanzen meist auf doppelte Daten im System, die wir durch Normalisierung vermeiden können. Die Vermeidung doppelter Daten ist wichtig, da wir dadurch zusätzliches Geld und Speicherressourcen sparen können, die für deren Pflege erforderlich sind. Außerdem besteht das Risiko, dass wir die Datenkonsistenz an mehreren Stellen aktualisieren/aufrechterhalten müssen, anstatt das Datenmodell zu vereinfachen.

Ein positiver Nebeneffekt all dessen ist die Vermeidung von Fehlern, Systemproblemen und letztendlich sogar möglichen Ausfallzeiten der Softwareanwendung. Aufgrund von Fehlern auf der Datenbankebene kann es zu Systemausfällen kommen, wenn die Daten nicht ordnungsgemäß normalisiert werden. Dieser Aspekt verbindet die ordnungsgemäße Verwaltung und Speicherung von Anwendungsdaten in den Back-End-Systemen direkt mit dem Kundenerlebnis im Front-End – und letztendlich mit dem Markterfolg des Unternehmens, das die Anwendung besitzt.

Eine normalisierte Datenbank trägt auch dazu bei, Effizienzgewinne zu erzielen. Beispielsweise muss Ihr System möglicherweise eine kleinere Reihe von Vorgängen ausführen, um die Daten für Kunden zu modellieren, bereitzustellen und zu verarbeiten. Ein kleinerer Satz an Vorgängen aufgrund gut normalisierter Daten erfordert auch weniger Rechenleistung, was zu Kosteneinsparungen bei der Software-Infrastruktur (oder dem Stack) führt, auf der die Datenbankanwendung ausgeführt wird. Aus diesem Grund ist die Datenbanknormalisierung auch direkt mit Einsparungen bei den Betriebskosten verbunden.

Nachdem wir nun die Vorteile der Normalisierung verstanden haben, gehen wir die Schritte zur Normalisierung unserer Datenbanken durch. Wir bezeichnen diese als Normalformen.

In diesem Schritt sind unsere Daten noch nicht normalisiert, also voller Redundanzen und immer noch in ihrer Rohform, ohne dass irgendeine Struktur oder Modellierungslogik darauf angewendet wird.

Der Wechsel von 0NF zu 1NF umfasst:

Schauen wir uns ein Beispiel dafür an, was nötig ist, um Daten von 0NF auf 1NF zu verschieben, indem wir Bücher als Beispieldatensatz verwenden.

Unten sehen Sie, dass die Tabelle Daten in Null-Normalform darstellt, da jedes Buch mehrere Autoreninformationen über verschiedene Attribute (Autor 1 und Autor 2) speichert, bei denen es sich um sich wiederholende Spalten derselben Daten handelt. Darüber hinaus gibt es Spalten wie „Autorname“, in denen mehrere Werte gespeichert sind. Dies muss korrigiert werden.

Wir beseitigen Redundanzen, indem wir die Daten in eine Büchertabelle (und die Erstellung einer Buch-ID-Kennung) und eine Buchautorentabelle aufteilen. Die Büchertabelle verfügt jetzt über eine Buch-ID-Kennung, während in der Buchautorentabelle alle Autoren-ID-Informationen in einer einzigen Spalte (der Autoren-ID) sowie zusätzliche Autorenattribute (Name des Autors, Geschlecht und geografischer Standort) gespeichert werden.

In diesem Beispiel haben wir nur ein Buch, aber die Struktur bleibt erhalten, wenn wir die Anzahl der von uns gespeicherten Bücher erhöhen.

Lernen Sie von den Experten von Built In. Was ist eine nicht relationale Datenbank?

Der Wechsel von 1NF zu 2NF umfasst:

Diese Daten sind nicht vollständig funktional abhängig, da wir gemäß der oben besprochenen funktionalen Abhängigkeitsdefinition den Namen des Autors nicht eindeutig anhand bestimmter anderer Attribute, wie z. B. der Buch-ID, bestimmen können.

Das liegt daran, dass BookID zwei verschiedene Autoren hat, was bedeutet, dass wir die Daten korrekt in ihre zweite Normalform bringen müssen.

Um den Wert eines Attributs eindeutig aus dem Wert seines Schlüssels zu bestimmen, teilen wir die Daten weiter auf und erstellen die Tabelle „Autoren“. Mit den Daten in diesem Formular sind wir nun in der Lage:

Der Wechsel von 2NF zu 3NF umfasst:

Sobald wir die Daten anhand der dritten Normalformregeln erneut auswerten, stellen wir fest, dass es ein Nicht-ID-Feld (Provinz) gibt, das den Wert des Attributs „Land“ eindeutig bestimmt. Daher ist das Land funktional von der Spalte „Provinz“ abhängig, einer Nicht-ID-Spalte.

Indem wir diese Abhängigkeit beseitigen, können wir die Daten in der dritten Normalform erhalten. Dazu erstellen wir eine Provinztabelle mit den Provinzwerten, die als Provinz-ID festgelegt sind, und behalten die Provinz-ID in der Autorentabelle bei. Schließlich verknüpfen wir die Daten und vermeiden die transitive Abhängigkeit, die wir in der zweiten Normalform gesehen haben.

Der Übergang von der 3NF zur Boyce-Codd-Normalform umfasst Folgendes:

Der Unterschied zwischen dieser Form und der dritten Normalform ist subtil. Wie in der dritten Normalform geht es uns in erster Linie um die Beseitigung funktionaler Abhängigkeiten von Nicht-Schlüsselattributen, wohingegen wir uns hier um die Beseitigung funktionaler Abhängigkeiten von potenziellen Schlüsselattributen kümmern.

Zu diesem Zeitpunkt sind unsere Daten bereits extrem normalisiert. Wenn wir also über diesen Punkt hinausgehen, gelangen wir in den Bereich der Übernormalisierung, d.

In der Praxis werden diese beiden letzten Formen nicht verwendet. Theoretisch sollen sie die Zahl der Datenbankanomalien noch weiter reduzieren. Wenn Sie tiefer in die theoretischen Details eintauchen möchten, finden Sie hier einige hilfreiche Ressourcen:

In der allgemeinen Praxis definiert die erste Normalform bis zur Boyce-Codd-Normalform den Satz von Schritten, die am häufigsten verwendet werden, um Normalisierungsvorteile zu erzielen. Die vierte und fünfte Form sind in der Praxis seltener anzutreffen.