Die Normalisierung ist eine Datenbankentwurfstechnik, mit der eine relationale Datenbanktabelle bis zu einer höheren Normalform entworfen wird. Der Prozess ist progressiv und ein höheres Maß an Datenbanknormalisierung kann nur erreicht werden, wenn die vorherigen Stufen erfüllt wurden.
Dies bedeutet, dass Daten in nicht normalisierter Form (am wenigsten normalisiert) vorliegen und das höchste Ziel angestrebt wird Normalisierungsgrad, der erste Schritt wäre, die Einhaltung der ersten Normalform sicherzustellen, der zweite Schritt wäre, 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 anzumerken, dass normale Formen jenseits von 4NF hauptsächlich von akademischem Interesse sind, da die zu lösenden Probleme in der Praxis selten auftreten.
Bitte beachten Sie, dass die Daten im folgenden Beispiel waren absichtlich entworfen, um den meisten normalen Formen zu 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 das Beheben einer Verletzung einer normalen Form auch eine Verletzung einer höheren normalen Form im Prozess behebt. Außerdem wurde bei 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.
Initial dataEdit
Lassen Sie eine Datenbanktabelle mit der folgenden Struktur:
| Titel | Autor | Nationalität des Autors | Format | Preis | Betreff | Seiten | Dicke | Herausgeber | Herausgeberland | Veröffentlichungstyp | Genre-ID | Genre-Name |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Beginn des Entwurfs und der Optimierung von MySQL-Datenbanken | Chad Russell | Amerikaner | Gebundene Ausgabe | 49,99 | MySQL,
Datenbank, Design |
520 | Dick | Apress | USA | E-Book | 1 | Tutorial |
In diesem Beispiel wird davon ausgegangen, dass jedes Buch nur einen Autor hat.
1NFEdit erfüllen
Um 1NF zu erfüllen, müssen die Werte in jeder Spalte einer Tabelle atomar sein. In der Anfangstabelle enthält Betreff eine Reihe von Betreffwerten, was bedeutet, dass sie nicht übereinstimmen.
Eine Möglichkeit, die 1NF zu erreichen, besteht darin, die Duplizitäten mithilfe sich wiederholender Gruppen in mehrere Spalten aufzuteilen. Betreff:
| Titel | Format | Autor | Nationalität des Autors | Preis | Betreff 1 | Betreff 2 | Betreff 3 | Seiten | Dicke | Publisher | Publisher-Land | Genre-ID | Genre-Name |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Beginn des Entwurfs und der Optimierung von MySQL-Datenbanken | Gebundene Ausgabe | Chad Russell | Amerikaner | 49,99 | MySQL | Datenbank | Design | 520 | Dick | Drücken Sie | USA | 1 | Tutorial |
Obwohl die Tabelle jetzt formal dem 1NF entspricht (ist atomar), ist das Problem mit dieser Lösung offensichtlich – wenn Ein Buch hat mehr als drei Themen. Es kann nicht zur Datenbank hinzugefügt werden, ohne seine Struktur zu ändern.
Um das Problem auf elegantere Weise zu lösen, müssen die in der Tabelle dargestellten Entitäten identifiziert und getrennt werden in ihre eigenen jeweiligen Tabellen. In diesem Fall würde dies zu Buch-, Betreff- und Herausgebertabellen führen:
| Titel | Format | Autor | Nationalität des Autors | Preis | Seiten | Dicke | Genre-ID | Genre-Name | Publisher-ID |
|---|---|---|---|---|---|---|---|---|---|
| Beginn von MySQL Datenbankdesign und -optimierung | Gebundene Ausgabe | Chad Russell | Amerikaner | 49.99 | 520 | Dick | 1 | Tutorial | 1 |
|
|
Durch einfaches Aufteilen der Anfangsdaten in mehrere Tabellen wird die Verbindung zwischen den Daten unterbrochen. Das heißt, die Beziehungen zwischen den neu eingeführten Tabellen müssen bestimmt werden. Beachten Sie, dass die Spalte „Publisher-ID“ in der Tabelle des Buches ein Fremdschlüssel ist, der eine Eins-zu-Eins-Beziehung zwischen einem Buch und einem Verlag realisiert.
Ein Buch kann sowohl für viele Themen als auch für ein Thema geeignet sein Dies bedeutet, dass auch eine Viele-zu-Viele-Beziehung definiert werden muss, die durch Erstellen einer Verknüpfungstabelle erreicht wird:
|
Anstelle einer Tabelle in nicht normalisierter Form gibt es jetzt 4 Tabellen, die dem 1NF entsprechen.
2NFEdit erfüllen
Die Buchtabelle enthält einen Kandidatenschlüssel (der daher der Primärschlüssel ist), den zusammengesetzten Schlüssel {Titel, Format}. Betrachten Sie das folgende Tabellenfragment:
| Title | Format | Autor | Nationalität des Autors | Preis | Seiten | Dicke | Genre-ID | Genre-Name | Publisher-ID |
|---|---|---|---|---|---|---|---|---|---|
| Beginn des Entwurfs und der Optimierung von MySQL-Datenbanken | Gebundene Ausgabe | Chad Russell | Amerikaner | 49,99 | 520 | Dick | 1 | Tutorial | 1 |
| Beginn des Entwurfs und der Optimierung von MySQL-Datenbanken | E-Book | Chad Russell | Amerikaner | 22,34 | 520 | Dick | 1 | Tutorial | 1 |
| Das relationale Modell für die Datenbankverwaltung: Version 2 | E-Book | EFCodd | Britisch | 13,88 | 538 | Dick | 2 | Populärwissenschaft | 2 |
| Das relationale Modell für die Datenbank Ma Management: Version 2 | Taschenbuch | EFCodd | Britisch | 39,99 | 538 | Dick | 2 | Populärwissenschaft | 2 |
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 Duplizitäten zu entfernen, muss jedes Nicht-Kandidatenschlüssel-Attribut 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 (der Primärschlüssel), damit jedes Nicht-Kandidatenschlüssel-Attribut vom gesamten Kandidatenschlüssel abhängt, und entfernen Sie Price in eine separate Tabelle, damit die Abhängigkeit vom Format erhalten bleibt:
|
|
Nun Die Buchtabelle entspricht 2NF.
3NFEdit erfüllen
Die Büchertabelle weist weiterhin eine transitive funktionale Abhängigkeit auf ({Autorennationalität} ist abhängig von {Autor}, die von {Titel abhängig ist }). Ein ähnlicher Verstoß besteht für das Genre ({Genre Name} ist abhängig von {Genre ID}, was von {Title} abhängt). Daher ist die Buchtabelle nicht in 3NF. Um es in 3NF zu schaffen, verwenden wir die folgende Tabellenstruktur, wodurch die transitiven funktionalen Abhängigkeiten beseitigt werden, indem {Author Nationality} und {Genre Name} in ihre jeweiligen Tabellen eingefügt werden:
| Titel | Autor | Seiten | Dicke | Genre-ID | Publisher-ID |
|---|---|---|---|---|---|
| Beginn des MySQL-Datenbankdesigns und Optimierung | Chad Russell | 520 | Dick | 1 | 1 |
| Das relationale Modell für die Datenbankverwaltung: Version 2 | EFCodd | 538 | Dick | 2 | 2 |
|
| Autor | Nationalität des Autors |
|---|---|
| Chad Russell | Amerikaner |
| EFCodd | Britisch |
| Gen. re ID | Genre-Name |
|---|---|
| 1 | Tutorial |
| 2 | Populärwissenschaft |
EKNFEdit erfüllen
Die Normalform des Elementarschlüssels (EKNF) liegt streng zwischen 3NF und BCNF und wird in der Literatur nicht viel diskutiert. Es ist beabsichtigt, „die herausragenden Eigenschaften von 3NF und BCNF zu erfassen“ und gleichzeitig die Probleme beider zu vermeiden (nämlich, dass 3NF „zu verzeihend“ und BCNF „anfällig für Rechenkomplexität“ ist). Da es in der Literatur selten erwähnt wird, In diesem Beispiel ist es nicht enthalten.
4NFEdit erfüllen
Angenommen, die Datenbank gehört einem Franchise-Unternehmen für Buchhändler, das mehrere Franchisenehmer hat, die Geschäfte an verschiedenen Standorten besitzen.Aus diesem Grund hat der Einzelhändler beschlossen, eine Tabelle hinzuzufügen, die Daten zur Verfügbarkeit der Bücher an verschiedenen Standorten enthält:
| Franchisenehmer-ID | Titel | Standort |
|---|---|---|
| 1 | Beginn des Entwurfs und der Optimierung von MySQL-Datenbanken | Kalifornien |
| 1 | Beginn des Entwurfs und der Optimierung von MySQL-Datenbanken | Florida |
| 1 | Beginn des Entwurfs und der Optimierung von MySQL-Datenbanken | Texas |
| 1 | Das relationale Modell für die Datenbankverwaltung: Version 2 | Kalifornien |
| 1 | Das relationale Modell für die Datenbankverwaltung: Version 2 | Florida |
| 1 | Das relationale Modell für die Datenbankverwaltung: Version 2 | Texas |
| 2 | Beginn des Entwurfs und der Optimierung von MySQL-Datenbanken | Kalifornien |
| 2 | Beginn des Entwurfs und der Optimierung von MySQL-Datenbanken | Florida |
| 2 | Beginn des Entwurfs und der Optimierung von MySQL-Datenbanken | Texas |
| 2 | Das relationale Modell für die Datenbankverwaltung: Version 2 | Kalifornien |
| 2 | Das relationale Modell für die Datenbankverwaltung: Version 2 | Florida |
| 2 | Das relationale Modell für die Datenbankverwaltung: Version 2 | Texas |
| 3 | Beginn des Entwurfs und der Optimierung von MySQL-Datenbanken | Texas |
Da diese Tabellenstruktur aus einem zusammengesetzten Primärschlüssel besteht, enthält sie keine Nichtschlüsselattribute und ist bereits in BCNF enthalten (und erfüllt daher auch alle vorherigen Normalformen). Wenn wir jedoch davon ausgehen, dass alle verfügbaren Bücher in jedem Bereich angeboten werden, stellen wir möglicherweise fest, dass der Titel nicht eindeutig an einen bestimmten Ort gebunden ist und die Tabelle daher 4NF nicht erfüllt.
Das bedeutet, dass Um die vierte Normalform zu erfüllen, muss diese Tabelle ebenfalls zerlegt werden:
|
|
||||||||||||
| Franchisenehmer-ID | Standort | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Kalifornien | ||||||||||||
| 1 | Florida | ||||||||||||
| 1 | Texas | ||||||||||||
| 2 | Kalifornien | ||||||||||||
| 2 | Florida | ||||||||||||
| 2 | Texas | ||||||||||||
| 3 | Texas |
Jetzt wird jeder Datensatz eindeutig durch einen Superkey identifiziert, sodass 4NF erfüllt ist.
ETNFEdit erfüllen
Angenommen, die Franchisenehmer können auch Bücher bei verschiedenen Lieferanten bestellen. Die Beziehung unterliegt auch der folgenden Einschränkung:
- Wenn ein bestimmter Lieferant einen bestimmten Titel
- liefert und der Titel dem Franchisenehmer
- und der Franchisenehmer wird vom Lieferanten geliefert,
- dann liefert der Lieferant den Titel an den Franchisenehmer.
| Lieferanten-ID | Titel | Franchisenehmer-ID |
|---|---|---|
| 1 | Beginn des Entwurfs und der Optimierung von MySQL-Datenbanken | 1 |
| 2 | Das relationale Modell für die Datenbankverwaltung: Version 2 | 2 |
| 3 | SQL lernen | 3 |
Diese Tabelle ist in 4NF, aber die Lieferanten-ID entspricht der Verknüpfung ihrer Projektionen: {{Lieferanten-ID, Buch}, {Buch, Franchisenehmer-ID}, {Franchisenehmer-ID, Lieferant ICH WÜRDE}}.Keine Komponente dieser Join-Abhängigkeit ist ein Superkey (der einzige Superkey ist die gesamte Überschrift), daher erfüllt die Tabelle den ETNF nicht und kann weiter zerlegt werden:
|
|
|
Die Zerlegung führt zur ETNF-Konformität.
5NFEdit erfüllen
Um eine Tabelle zu erkennen, die die 5NF nicht erfüllt, muss diese ist normalerweise notwendig, um die Daten gründlich zu untersuchen. Angenommen, die Tabelle aus dem 4NF-Beispiel enthält einige Änderungen an den Daten und wir prüfen, ob sie 5NF erfüllt:
| Franchisenehmer-ID | Titel | Standort |
|---|---|---|
| 1 | Beginn des Entwurfs und der Optimierung von MySQL-Datenbanken | Kalifornien |
| 1 | SQL lernen | Kalifornien |
| 1 | Das relationale Modell für die Datenbankverwaltung: Version 2 | Texas |
| 2 | Das relationale Modell für die Datenbankverwaltung: Version 2 | Kalifornien |
Wenn wir diese Tabelle zerlegen, verringern wir die Redundanzen und erhalten die folgenden zwei Tabellen:
|
|
Was passiert, wenn wir versuchen, diese Tabellen zu verbinden? Die Abfrage würde die folgenden Daten zurückgeben:
| Franchisenehmer-ID | Titel | Standort |
|---|---|---|
| 1 | Beginn des MySQL-Datenbankdesigns und Optimierung | Kalifornien |
| 1 | SQL lernen | Kalifornien |
| 1 | Das relationale Modell für die Datenbankverwaltung: Version 2 | Kalifornien |
| 1 | Das relationale Modell für die Datenbankverwaltung: Version 2 | Texas |
| 1 | SQL lernen | Texas |
| 1 | Beginn des Entwurfs und der Optimierung von MySQL-Datenbanken | Texas |
| 2 | Das relationale Modell für die Datenbankverwaltung: Version 2 | Kalifornien |
Anscheinend gibt JOIN drei Zeilen mehr zurück, als es sollte – versuchen wir, ano hinzuzufügen Weitere Tabelle zur Verdeutlichung der Beziehung.Am Ende haben wir drei separate Tabellen:
|
|
|
Was wird der JOIN jetzt zurückgeben? Es ist tatsächlich nicht möglich, diese drei Tabellen zu verbinden. Das bedeutet, dass es nicht möglich war, den Standort des Franchisenehmers – Buches ohne Datenverlust zu zerlegen. Daher erfüllt die Tabelle bereits 5NF.
CJ Date hat argumentiert, dass nur eine Datenbank in 5NF wirklich „normalisiert“ ist.
Befriedigung von DKNFEdit
Schauen wir uns die Buchtabelle aus den vorherigen Beispielen an und prüfen Sie, ob sie der Normalform des Domänenschlüssels entspricht:
| Titel | Seiten | Dicke | Genre-ID | Publisher-ID | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Beginn des Entwurfs und der Optimierung von MySQL-Datenbanken | 520 | Dick | 1 | 1 | ||||||||||||||||||||||||||
| Das relationale Modell für die Datenbankverwaltung: Version 2 | 538 | Dick | 2 | 2 | ||||||||||||||||||||||||||
| SQL lernen | 338 | Slim | 1 | 3 | ||||||||||||||||||||||||||
| SQL-Kochbuch | 636 | Dick | 1 | 3 |
|
|
Auf diese Weise wurde die Verletzung der Domänenintegrität beseitigt und die Tabelle befindet sich in DKNF.
6NFEdit erfüllen
Eine einfache und intuitive Definition der sechsten Normalform lautet: „Eine Tabelle befindet sich in 6NF, wenn die Zeile den Primärschlüssel und höchstens ein weiteres Attribut enthält.“
Dies bedeutet beispielsweise, dass die Publisher-Tabelle beim Erstellen des 1NF
| Publisher_ID | Name | Land |
|---|---|---|
| 1 | Drücken Sie | USA |
muss weiter sein zerlegt in zwei Tabellen:
|
|
Der offensichtliche Nachteil von 6NF ist die Verbreitung von Tabellen, die zur Darstellung der Informationen auf einer einzelnen Entität erforderlich sind. Wenn eine Tabelle in 5NF eine Primärschlüsselspalte und N Attribute hat, sind für die Darstellung derselben Informationen in 6NF N Tabellen erforderlich. Aktualisierungen mehrerer Felder für einen einzelnen konzeptionellen Datensatz erfordern Aktualisierungen mehrerer Tabellen. Einfügungen und Löschvorgänge erfordern in ähnlicher Weise Operationen über mehrere Tabellen hinweg. Aus diesem Grund sollte 6NF in Datenbanken, die für die Verarbeitung von Online-Transaktionen vorgesehen sind, nicht verwendet werden.
In Data Warehouses, die keine interaktiven Aktualisierungen zulassen und auf schnelle Abfragen bei großen Datenmengen spezialisiert sind Bestimmte DBMS verwenden eine interne 6NF-Darstellung, die als Columnar-Datenspeicher bezeichnet wird. In Situationen, in denen die Anzahl der eindeutigen Werte einer Spalte weitaus geringer ist als die Anzahl der Zeilen in der Tabelle, ermöglicht der spaltenorientierte Speicher durch Datenkomprimierung erhebliche Platzersparnisse. Der Spaltenspeicher ermöglicht auch die 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 tut dies der Datenbankdesigner jedoch nicht Sie müssen die 6NF-Normalisierung manuell durchführen, indem Sie separate Tabellen erstellen. Einige auf Warehousing spezialisierte DBMS, wie z. B. Sybase IQ, verwenden standardmäßig Spaltenspeicher, der Designer sieht jedoch nur eine einzige mehrspaltige Tabelle. In anderen DBMS wie Microsoft SQL Server 2012 und höher können Sie einen „Columnstore-Index“ für eine bestimmte Tabelle angeben.
