Datenbanknormalisierung - Database normalization

Datenbanknormalisierung ist der Prozess der Strukturierung einer Datenbank , meist einer relationalen Datenbank , nach einer Reihe sogenannter Normalformen , um die Datenredundanz zu reduzieren und die Datenintegrität zu verbessern . Es wurde zuerst von Edgar F. Codd als Teil seines relationalen Modells vorgeschlagen .

Die Normalisierung beinhaltet das Organisieren der Spalten (Attribute) und Tabellen (Beziehungen) einer Datenbank, um sicherzustellen, dass ihre Abhängigkeiten durch Datenbankintegritätseinschränkungen ordnungsgemäß durchgesetzt werden. Dies wird durch die Anwendung einiger formaler Regeln entweder durch einen Syntheseprozess (Erzeugung eines neuen Datenbankentwurfs) oder Zerlegung (Verbesserung eines bestehenden Datenbankentwurfs) erreicht.

Ziele

Ein grundlegendes Ziel der ersten Normalform, die von Codd 1970 definiert wurde, bestand darin, die Abfrage und Manipulation von Daten mit einer "universellen Daten-Untersprache" zu ermöglichen, die auf Logik erster Ordnung basiert . ( SQL ist ein Beispiel für eine solche Daten-Untersprache, wenn auch eine, die Codd als ernsthaft fehlerhaft ansah.)

Die Ziele der Normalisierung jenseits von 1NF (erste Normalform) wurden von Codd wie folgt formuliert:

1. Um die Sammlung von Beziehungen von unerwünschten Einfüge-, Aktualisierungs- und Löschabhängigkeiten zu befreien.
2. Um die Notwendigkeit einer Neustrukturierung der Relationssammlung zu reduzieren, da neue Datentypen eingeführt werden, und damit die Lebensdauer von Anwendungsprogrammen erhöht wird.
3. Um das relationale Modell für Benutzer informativer zu machen.
4. Um die Sammlung von Beziehungen neutral für die Abfragestatistiken zu machen, wobei sich diese Statistiken im Laufe der Zeit ändern können.

—  EF Codd, "Weitere Normalisierung des relationalen Datenbankmodells"

Eine Update-Anomalie . Mitarbeiter 519 wird mit unterschiedlichen Adressen in verschiedenen Datensätzen angezeigt.

Eine Insertionsanomalie . Solange das neue Fakultätsmitglied, Dr. Newsome, nicht für mindestens eine Lehrveranstaltung zuständig ist, können keine Daten erfasst werden.

Eine Löschanomalie . Alle Informationen über Dr. Giddens gehen verloren, wenn sie vorübergehend keinen Kursen mehr zugeordnet werden.

Wenn versucht wird, eine Relation zu ändern (zu aktualisieren, einzufügen oder zu löschen), können die folgenden unerwünschten Nebeneffekte in Relationen auftreten, die nicht ausreichend normalisiert wurden:

• Anomalie aktualisieren. Dieselben Informationen können in mehreren Zeilen ausgedrückt werden; Daher können Aktualisierungen der Beziehung zu logischen Inkonsistenzen führen. Beispielsweise kann jeder Datensatz in einer Beziehung "Mitarbeiterfähigkeiten" eine Mitarbeiter-ID, eine Mitarbeiteradresse und eine Qualifikation enthalten; Daher muss eine Adressänderung für einen bestimmten Mitarbeiter möglicherweise auf mehrere Datensätze angewendet werden (einer für jede Qualifikation). Wenn die Aktualisierung nur teilweise erfolgreich ist – die Adresse des Mitarbeiters wird in einigen Datensätzen aktualisiert, in anderen nicht –, bleibt die Beziehung in einem inkonsistenten Zustand. Insbesondere liefert die Beziehung widersprüchliche Antworten auf die Frage, wie die Adresse dieses bestimmten Mitarbeiters lautet. Dieses Phänomen wird als Update-Anomalie bezeichnet.
• Einfügungsanomalie. Es gibt Umstände, unter denen bestimmte Tatsachen überhaupt nicht erfasst werden können. Beispielsweise kann jeder Datensatz in einer "Fakultät und ihre Kurse" eine Fakultäts-ID, einen Fakultätsnamen, ein Einstellungsdatum der Fakultät und einen Kurscode enthalten. Daher können die Details jedes Fakultätsmitglieds, das mindestens einen Kurs unterrichtet, aufgezeichnet werden, aber ein neu eingestelltes Fakultätsmitglied, dem noch keine Kurse zugewiesen wurden, können aufgezeichnet werden, es sei denn, der Kurscode wird auf null gesetzt . Dieses Phänomen wird als Insertionsanomalie bezeichnet.
• Löschanomalie. Das Löschen von Daten, die bestimmte Tatsachen darstellen, erfordert unter Umständen die Löschung von Daten, die völlig andere Tatsachen darstellen. Die im vorherigen Beispiel beschriebene Beziehung "Fakultät und ihre Kurse" leidet unter dieser Art von Anomalie, denn wenn ein Fakultätsmitglied vorübergehend keine Kurse mehr zugewiesen bekommt, müssen die letzten Datensätze, in denen dieses Fakultätsmitglied auftaucht, effektiv gelöscht werden auch das Fakultätsmitglied zu löschen, es sei denn, das Feld Kurscode ist auf null gesetzt. Dieses Phänomen wird als Deletionsanomalie bezeichnet.

Minimieren Sie das Redesign beim Erweitern der Datenbankstruktur

Eine vollständig normalisierte Datenbank ermöglicht es, ihre Struktur zu erweitern, um neue Datentypen aufzunehmen, ohne die bestehende Struktur zu sehr zu ändern. Dadurch werden Anwendungen, die mit der Datenbank interagieren, nur minimal beeinträchtigt.

Normalisierte Beziehungen und die Beziehung zwischen einer normalisierten Beziehung und einer anderen spiegeln reale Konzepte und ihre Wechselbeziehungen wider.

Normalformen

Codd führte das Konzept der Normalisierung und das, was heute als bekannt ist die erste Normalform (1NF) im Jahr 1970 Codd gingen auf die definieren zweite Normalform (2NF) und die dritte Normalform (3NF) im Jahr 1971 und Codd und Raymond F. Boyce definierte 1974 die Boyce-Codd-Normalform (BCNF).

Informell wird eine relationale Datenbankrelation oft als "normalisiert" bezeichnet, wenn sie der dritten Normalform entspricht. Die meisten 3NF-Beziehungen sind frei von Einfügungs-, Aktualisierungs- und Löschanomalien.

Die Normalformen (von am wenigsten normalisiert bis am meisten normalisiert) sind:

	UNF (1970)	1NF (1970)	2NF (1971)	3NF (1971)	EKNF (1982)	BCNF (1974)	4NF (1977)	ETNF (2012)	5NF (1979)	DKNF (1981)	6NF (2003)
Primärschlüssel (keine doppelten Tupel )
Atomare Spalten (Zellen können keine Tabellen als Werte haben)
Jede nicht-triviale funktionale Abhängigkeit beginnt entweder nicht mit einer richtigen Teilmenge eines Kandidatenschlüssels oder endet mit einem Primattribut (keine partiellen funktionalen Abhängigkeiten von Nichtprimatattributen von Kandidatenschlüsseln)
Jede nicht-triviale funktionale Abhängigkeit beginnt entweder mit einem Superschlüssel oder endet mit einem Prim-Attribut (keine transitiven funktionalen Abhängigkeiten von Nicht-Prime-Attributen von Kandidatenschlüsseln)
Jede nicht-triviale funktionale Abhängigkeit beginnt entweder mit einem Superschlüssel oder endet mit einem elementaren Primattribut											N / A
Jede nicht-triviale funktionale Abhängigkeit beginnt mit einem Superschlüssel											N / A
Jede nicht triviale mehrwertige Abhängigkeit beginnt mit einem Superschlüssel											N / A
Jede Join-Abhängigkeit hat eine Superkey-Komponente											N / A
Jede Join-Abhängigkeit hat nur Superkey-Komponenten											N / A
Jede Einschränkung ist eine Folge von Domäneneinschränkungen und Schlüsseleinschränkungen
Jede Join-Abhängigkeit ist trivial

Beispiel für eine schrittweise Normalisierung

Normalisierung ist eine Datenbankentwurfstechnik, die verwendet wird, um eine relationale Datenbanktabelle bis zu einer höheren Normalform zu entwerfen . Der Prozess ist progressiv, und eine höhere Ebene der Datenbanknormalisierung kann nur erreicht werden, wenn die vorherigen Ebenen erfüllt wurden.

Das bedeutet, dass bei Daten in nicht normalisierter Form (der am wenigsten normalisierten) und dem Ziel, den höchsten Normalisierungsgrad zu erreichen, der erste Schritt darin besteht, die Einhaltung der ersten Normalform sicherzustellen , der zweite Schritt darin besteht, sicherzustellen, dass die zweite Normalform erfüllt ist. und so weiter in der oben genannten Reihenfolge, bis die Daten der sechsten Normalform entsprechen .

Es ist jedoch erwähnenswert, dass Normalformen jenseits von 4NF hauptsächlich von akademischem Interesse sind, da die Probleme, die es zu lösen gibt, in der Praxis selten auftreten.

Bitte beachten Sie, dass die Daten im folgenden Beispiel absichtlich so gestaltet wurden, dass sie den meisten normalen Formen widersprechen. Im wirklichen Leben ist es durchaus möglich, einige der Normalisierungsschritte überspringen zu können, da die Tabelle nichts enthält, was der gegebenen Normalform widerspricht. Es kommt auch häufig vor, dass die Behebung einer Verletzung einer Normalform auch eine Verletzung einer höheren Normalform im Prozess behebt. Außerdem wurde in jedem Schritt eine Tabelle für die Normalisierung ausgewählt, was bedeutet, dass am Ende dieses Beispielprozesses möglicherweise noch einige Tabellen vorhanden sind, die die höchste Normalform nicht erfüllen.

Ausgangsdaten

Lassen Sie eine Datenbanktabelle mit der folgenden Struktur existieren:

Für dieses Beispiel wird angenommen, dass jedes Buch nur einen Autor hat.

Als Voraussetzung für die Konformität mit dem relationalen Modell muss eine Tabelle einen Primärschlüssel besitzen , der eine Zeile eindeutig identifiziert. Zwei Bücher können denselben Titel haben, aber eine ISBN-Nummer identifiziert ein Buch eindeutig, sodass es als Primärschlüssel verwendet werden kann:

Befriedigend 1NF

Um die erste Normalform zu erfüllen , muss jede Spalte einer Tabelle einen einzelnen Wert haben. Spalten, die Wertegruppen oder verschachtelte Datensätze enthalten, sind nicht zulässig.

In der Anfangstabelle enthält Betreff eine Reihe von Betreffwerten, was bedeutet, dass er nicht konform ist.

Um das Problem zu lösen, werden die Themen in eine separate Thementabelle extrahiert :

Der Betreff- Tabelle wird eine Fremdschlüsselspalte hinzugefügt, die sich auf den Primärschlüssel der Zeile bezieht, aus der der Betreff extrahiert wurde. Daher werden dieselben Informationen dargestellt, jedoch ohne Verwendung nicht einfacher Domänen.

Statt einer Tabelle in nicht normalisierter Form gibt es nun zwei Tabellen nach 1NF.

Befriedigend 2NF

Die Book- Tabelle hat einen Kandidatenschlüssel (der daher der Primärschlüssel ist ), den zusammengesetzten Schlüssel {Title, Format} . Betrachten Sie das folgende Tabellenfragment:

Alle Attribute, die nicht Teil des Kandidatenschlüssels sind, hängen vom Titel ab , aber nur der Preis hängt auch vom Format ab . Um 2NF zu entsprechen und Duplikate zu entfernen, muss jedes Nicht-Kandidatenschlüsselattribut vom gesamten Kandidatenschlüssel abhängen, nicht nur von einem Teil davon.

Um diese Tabelle zu normalisieren, machen Sie {Title} zu einem (einfachen) Kandidatenschlüssel (dem Primärschlüssel), sodass jedes Nicht-Kandidatenschlüsselattribut vom gesamten Kandidatenschlüssel abhängt, und entfernen Sie Price in einer separaten Tabelle, damit seine Abhängigkeit von Format sein kann konserviert:

Jetzt entspricht die Book- Tabelle 2NF .

Befriedigend 3NF

Die Book- Tabelle hat immer noch eine transitive funktionale Abhängigkeit ({Author Nationality} ist abhängig von {Author}, die von {Title} abhängig ist). Ein ähnlicher Verstoß besteht für das Genre ({Genre Name} ist abhängig von {Genre ID}, das von {Title} abhängig ist). Daher befindet sich die Book- Tabelle nicht in 3NF. Um es in 3NF zu schaffen, verwenden wir die folgende Tabellenstruktur, wodurch die transitiven funktionalen Abhängigkeiten eliminiert werden, indem {Author Nationality} und {Genre Name} in ihre eigenen jeweiligen Tabellen eingefügt werden:

Befriedigende EKNF

Die elementare Schlüsselnormalform (EKNF) liegt streng zwischen 3NF und BCNF und wird in der Literatur nicht viel diskutiert. Es soll „die herausragenden Qualitäten von 3NF und BCNF erfassen“ und gleichzeitig die Probleme beider vermeiden (nämlich, dass 3NF „zu nachsichtig“ und BCNF „anfällig für Rechenkomplexität“ ist). Da es in der Literatur selten erwähnt wird, ist es in diesem Beispiel nicht enthalten.

Befriedigend 4NF

Angenommen, die Datenbank gehört einem Buchhändler-Franchise mit mehreren Franchisenehmern, die Geschäfte an verschiedenen Standorten besitzen. Deshalb hat sich der Händler entschieden, eine Tabelle hinzuzufügen, die Daten zur Verfügbarkeit der Bücher an verschiedenen Standorten enthält:

Da diese Tabellenstruktur aus einem zusammengesetzten Primärschlüssel besteht, enthält sie keine Nicht-Schlüsselattribute und ist bereits in BCNF (und erfüllt somit auch alle bisherigen Normalformen ). Unter der Annahme, dass in jedem Bereich alle verfügbaren Bücher angeboten werden, ist der Titel jedoch nicht eindeutig an einen bestimmten Ort gebunden und die Tabelle genügt daher nicht 4NF .

Das bedeutet, dass zur Erfüllung der vierten Normalform auch diese Tabelle zerlegt werden muss:

Nun wird jeder Datensatz eindeutig durch einen Superkey identifiziert , daher ist 4NF erfüllt.

ETNF . befriedigend

Angenommen, die Franchisenehmer können auch Bücher von verschiedenen Lieferanten bestellen. Die Relation soll auch der folgenden Einschränkung unterliegen:

• Wenn ein bestimmter Lieferant einen bestimmten Titel liefert
• und der Titel wird an den Franchisenehmer geliefert
• und der Franchisenehmer vom Lieferanten beliefert wird ,
• dann überlässt der Lieferant dem Franchisenehmer das Eigentum .

Diese Tabelle befindet sich in 4NF , aber die Lieferanten-ID entspricht der Verknüpfung ihrer Projektionen: {{Lieferanten-ID, Buch}, {Buch, Franchisenehmer-ID}, {Franchisenehmer-ID, Lieferanten-ID}}. Keine Komponente dieser Join-Abhängigkeit ist ein Superschlüssel (der einzige Superschlüssel ist die gesamte Überschrift), sodass die Tabelle die ETNF nicht erfüllt und weiter zerlegt werden kann:

Die Zerlegung erzeugt eine ETNF-Compliance.

Erfüllt 5NF

Um eine Tabelle zu erkennen, die die 5NF nicht erfüllt , ist es normalerweise notwendig, die Daten gründlich zu untersuchen. Angenommen, die Tabelle aus dem 4NF-Beispiel mit einer kleinen Änderung in den Daten und lassen Sie uns untersuchen, ob sie 5NF erfüllt :

Das Zerlegen dieser Tabelle verringert Redundanzen, was zu den folgenden zwei Tabellen führt:

Die Abfrage, die diese Tabellen verbindet, würde die folgenden Daten zurückgeben:

Der JOIN gibt drei Zeilen mehr zurück, als er sollte; Das Hinzufügen einer weiteren Tabelle zur Verdeutlichung der Beziehung führt zu drei separaten Tabellen:

Was wird der JOIN jetzt zurückgeben? Es ist eigentlich nicht möglich, diese drei Tabellen zu verbinden. Das heißt, es war nicht möglich, den Franchisenehmer- Buchstandort ohne Datenverlust zu zerlegen , daher genügt die Tabelle bereits 5NF .

CJ Date hat argumentiert, dass nur eine Datenbank in 5NF wirklich "normalisiert" ist.

Befriedigende DKNF

Schauen wir uns die Book- Tabelle aus den vorherigen Beispielen an und sehen wir, ob sie die Domänenschlüssel-Normalform erfüllt :

Die Dicke wird logischerweise durch die Anzahl der Seiten bestimmt. Das bedeutet, dass es von Pages abhängt, die kein Schlüssel ist. Lassen Sie uns eine Beispielkonvention festlegen, die besagt, dass ein Buch mit bis zu 350 Seiten als "schlank" und ein Buch mit mehr als 350 Seiten als "dick" angesehen wird.

Diese Konvention ist technisch gesehen eine Einschränkung, aber weder eine Domäneneinschränkung noch eine Schlüsseleinschränkung; Daher können wir uns nicht auf Domäneneinschränkungen und Schlüsseleinschränkungen verlassen, um die Datenintegrität zu wahren.

Mit anderen Worten - nichts hindert uns daran, zum Beispiel "Dick" für ein Buch mit nur 50 Seiten anzugeben - und die Tabelle verstößt damit gegen DKNF .

Um dieses Problem zu lösen, wird eine Tabelle mit einer Aufzählung erstellt, die die Dicke definiert , und diese Spalte wird aus der ursprünglichen Tabelle entfernt:

Auf diese Weise wurde die Verletzung der Domänenintegrität beseitigt und die Tabelle befindet sich in DKNF .

Befriedigend 6NF

Eine einfache und intuitive Definition der sechsten Normalform ist, dass "eine Tabelle in 6NF ist, wenn die Zeile den Primärschlüssel und höchstens ein weiteres Attribut enthält" .

Das bedeutet zum Beispiel der Publisher- Tisch, der beim Erstellen des 1NF . entworfen wurde

muss weiter in zwei Tabellen zerlegt werden:

Der offensichtliche Nachteil von 6NF ist die Verbreitung von Tabellen, die erforderlich sind, um die Informationen über eine einzelne Entität darzustellen. Wenn eine Tabelle in 5NF eine Primärschlüsselspalte und N Attribute hat, erfordert die Darstellung derselben Informationen in 6NF N Tabellen; Aktualisierungen mit mehreren Feldern an einem einzelnen konzeptionellen Datensatz erfordern Aktualisierungen an mehreren Tabellen; und Einfügungen und Löschungen erfordern in ähnlicher Weise Operationen über mehrere Tabellen hinweg. Aus diesem Grund sollte 6NF in Datenbanken, die den Anforderungen der Online-Transaktionsverarbeitung dienen sollen, nicht verwendet werden.

In Data Warehouses , die keine interaktiven Aktualisierungen zulassen und die auf schnelle Abfragen großer Datenmengen spezialisiert sind, verwenden bestimmte DBMS jedoch eine interne 6NF-Darstellung – bekannt als Columnar Data Store . In Situationen, in denen die Anzahl der eindeutigen Werte einer Spalte weit geringer ist als die Anzahl der Zeilen in der Tabelle, ermöglicht die spaltenorientierte Speicherung durch Datenkomprimierung erhebliche Platzeinsparungen. Spaltenspeicher ermöglicht auch eine schnelle Ausführung von Bereichsabfragen (z. B. alle Datensätze anzeigen, bei denen eine bestimmte Spalte zwischen X und Y oder kleiner als X liegt.)

In all diesen Fällen muss der Datenbankdesigner jedoch die 6NF-Normalisierung nicht manuell durchführen, indem er separate Tabellen erstellt. Einige auf Warehousing spezialisierte DBMS wie Sybase IQ verwenden standardmäßig Spaltenspeicher, aber der Designer sieht immer noch nur eine einzige mehrspaltige Tabelle. Bei anderen DBMSs, wie z. B. Microsoft SQL Server 2012 und höher, können Sie einen "Columnstore-Index" für eine bestimmte Tabelle angeben.

Siehe auch

• Denormalisierung
• Datenbank-Refactoring

• Verlustfreie Join-Zerlegung

Hinweise und Referenzen

Weiterlesen

• Date, CJ (1999), Eine Einführung in Datenbanksysteme (8. Aufl.). Addison-Wesley Longman. ISBN  0-321-19784-4 .
• Kent, W. (1983) A Simple Guide to Five Normal Forms in Relational Database Theory , Communications of the ACM, vol. 26, S. 120–125
• H.-J. Schek, P. Pistor Datenstrukturen für ein integriertes Datenbankmanagement- und Informationsabrufsystem

Externe Links

• Kent, William (Februar 1983). "Ein einfacher Leitfaden für fünf Normalformen in der relationalen Datenbanktheorie" . Mitteilungen des ACM . 26 (2): 120–125. doi : 10.1145/358024.358054 . S2CID  9195704 .
• Grundlagen der Datenbanknormalisierung von Mike Chapple (About.com)
• Einführung in die Datenbanknormalisierung , Teil 2
• Eine Einführung in die Datenbanknormalisierung von Mike Hillyer.
• Ein Tutorial zu den ersten 3 Normalformen von Fred Coulson
• Beschreibung der Grundlagen der Datenbanknormalisierung von Microsoft
• Normalisierung in DBMS von Chaitanya (beginnersbook.com)
• Eine Schritt-für-Schritt-Anleitung zur Datenbanknormalisierung
• ETNF – Essentielle Tupel-Normalform