Einführung in die Datenbanknormalisierung in den ersten drei normalen Formen

Das Ziel einer relationalen Datenbanknormalisierung ist es, zu erreichen und zu verbessern Datenintegrität und vermeiden Daten Redundanz Um mögliche Insertion, Aktualisierungs- oder Löschanomalien zu vermeiden. Eine relationale Datenbank wird durch Anwenden einer Reihe von Regeln, die als Normalformen bezeichnet werden, normalisiert. In diesem Artikel werden wir die ersten drei normalen Formen diskutieren.

In diesem Tutorial lernen Sie:

• Was ist die erste normale Form
• Was ist die zweite normale Form
• Was ist die dritte normale Form

Softwareanforderungen und Konventionen verwendet

Die erste normale Form

Angenommen, wir haben die folgende Tabelle, mit der wir Informationen über einige Filme speichern:

+----+--------------------+--------------------+------+ | id | Name | Genre | Jahr | +----+--------------------+--------------------+-- ----+ | 1 | Der Exorzist | Horror | 1973 | | 2 | Die üblichen Verdächtigen | Thriller, Neo-Noir | 1995 | | 3 | Star Wars | Space-Opera | 1977 | +----+--------------------+--------------------+------+ 

Die obige Tabelle befriedigt das nicht die Erste normale Form, Warum? Damit die erste normale Form erfüllt werden muss, muss jede Spalte einer Tabelle enthalten Atomic (unteilbare) Daten. In der zweiten Reihe unserer Tabelle, die Informationen über den Film „Die üblichen Verdächtigen“ enthält, können wir sehen, dass die Genre Die Spalte enthält Daten, die nicht atomar sind. Zwei Genres sind tatsächlich aufgeführt: Thriller und Neo-Noir. Nehmen wir in unserer Darstellung an, wir möchten zulassen, dass ein Film mit mehr als einem Genre in Verbindung gebracht wird. Wie lösen wir das Problem??

Das erste, was in den Sinn kommt. Diese Idee ist ziemlich schrecklich, da wir viele redundante Daten haben (wir sollten jedes Mal dieselben Filminformationen wiederholen, wenn wir sie mit einem neuen Genre verbinden möchten!).

Eine weitere etwas bessere Lösung wäre, eine neue Spalte hinzuzufügen, um beispielsweise a zu haben Genre1 Und Genre2 Säulen. Dies würde jedoch unter den anderen Dingen eine Grenze darstellen: Was ist, wenn ein Film unter mehr als zwei Genres aufgeführt werden sollte?

Eine intelligentere Möglichkeit, dieses Problem zu lösen, besteht darin, eine neue Tabelle zum Speichern von Genres -Informationen zu erstellen. Hier ist die "Genre" -Tabelle:

+----+-------------+ | id | Name | +----+--------------+| 1 | Horror | | 2 | Neo-Noir | | 3 | Space-Opera | | 4 | Thriller | +----+-------------+ 

Jetzt, da der zwischen Genre und Film a ist viel zu viel Beziehung (ein Film kann mit mehreren Genres verwandt sein, und ein Genre kann mit vielen verschiedenen Filmen zusammenhängen), um ihn ohne Datenreduktion auszudrücken. Wir können eine SO verwenden
genannt Übergangstabelle:

+----------+----------+ | Movie_id | Genre_id | +----------+----------+| 1 | 1 | | 2 | 2 | | 2 | 4 | | 3 | 3 | +----------+----------+ 

Unsere Junction-Tabelle hat die einzige Aufgabe, die viele zu viele Beziehung zwischen den beiden Tabellen oder Entitäten und Genre auszudrücken. Es wird nur aus zwei Spalten komponiert: Movie_id und Genre_id. Der Movie_id Spalte hat a Unbekannter Schlüssel Einschränkung zum Ausweis Säule der Film Tisch und die Genre_id hat eine fremde Schlüsselbeschränkung für die Ausweis Säule der Genre Tisch. Die beiden Spalten zusammen werden als verwendet als zusammengesetzt Primärschlüssel, daher kann die Beziehung zwischen einem Film und einem Genre nur einmal ausgedrückt werden. Zu diesem Zeitpunkt können wir die Spalte "Genre" aus der Tabelle "Film" entfernen:

+----+--------------------+------+ | id | Name | Jahr | +----+--------------------+------+| 1 | Der Exorzist | 1973 | | 2 | Die üblichen Verdächtigen | 1995 | | 3 | Star Wars | 1977 | +----+--------------------+------+ 

Die Tabelle befindet sich jetzt in der ersten normalen Form.

Die zweite normale Form

Die erste normale Form ist eine Voraussetzung für die zweite: Damit die zweite normale Form erfüllt werden muss Erste normale Form und es sollte keine geben Teilabhängigkeit von sekundären Attributen aus einer Teilmenge von beliebig Kandidatschlüssel.

Was ist eine teilweise Abhängigkeit? Beginnen wir damit, dass es in einem Tisch mehr als einen geben könnte Kandidatschlüssel. Ein Kandidatenschlüssel ist eine Spalte oder eine Reihe von Spalten, die zusammen in einer Tabelle als eindeutig identifiziert werden können: nur eine der
Kandidatenschlüssel werden als als Tabelle ausgewählt Primärschlüssel, die einzigartig identifiziert jede Zeile.

Die Attribute, die Teil von Kandidatenschlüssel sind Prime, während alle anderen genannt werden sekundär. Damit eine Beziehung in der zweiten normalen Form ist, sollte es kein sekundäres Attribut geben, das von einer Untergruppe abhängt
eines Kandidatenschlüssels.

Lassen Sie uns ein Beispiel sehen. Angenommen, wir haben eine Tabelle, mit der wir Daten über Fußballspieler und ihre Punktzahlen für jeden Spieltag für eine Fantasy -Fußballanwendung speichern, so etwas wie diese:

+-----------+------------+-----------+------------+---------+-------+ | Player_id | First_Name | last_name | Rolle | gameday | Punktzahl | +-----------+------------+-----------+------------ +----------+-------+| 111 | Cordaz | Alex | Torhüter | 18 | 6.50 | | 117 | Donnarumma | Gianluigi | Torhüter | 18 | 7.50 | | 124 | Handanovic | Samir | Torhüter | 18 | 7.50 | +-----------+------------+-----------+------------+---------+-------+ 

Schauen wir uns diesen Tisch an. Zunächst können wir sehen, dass es die erste normale Form erfüllt, da die Daten in jeder Spalte atomar sind. Die Daten in der enthalten Player_id Säule könnte verwendet werden, um einen Spieler einzigartig zu identifizieren, aber
Kann es als Primärschlüssel für die Tabelle verwendet werden?? Die Antwort lautet Nein! Hier konnten wir a benutzen zusammengesetzt Primärschlüssel stattdessen, hergestellt durch die Kombination der Player_id Und Spieltag Spalten, da ein und nur ein Eintrag für diesen Spieler für jeden Spieltag existieren können.

Erfüllt diese Tabelle die zweite normale Form? Die Antwort lautet Nein, lassen Sie uns sehen, warum. Wir haben zuvor gesagt, dass jedes Attribut, das nicht Teil von Kandidatenschlüssel ist sekundär und damit die Tabelle die zweite Normalität befriedigt
Form darf es nicht von a abhängig sein Teilmenge von jedem Kandidatenschlüssel, aber es muss vom Kandidatenschlüssel als Ganzes abhängen.

Lassen Sie uns das nehmen Rolle zum Beispiel Attribut. Es ist ein sekundäres Attribut, da es nicht Teil eines Kandidatenschlüssels ist. Wir können sagen, dass es funktional abhängig ist Player_id, Da sich der Spieler ändert, kann sich auch die assoziierte Rolle ändern. Es ist jedoch nicht abhängig von Spieltag, Dies ist die andere Komponente des zusammengesetzten Primärschlüssels, da auch wenn das Spielay die Rolle des Spielers verändert. Wir können das sagen Rolle ist funktionell abhängig von a Teilmenge des zusammengesetzten Primärschlüssels ist die zweite normale Form nicht erfüllt.

Um das Problem zu lösen, können wir eine separate Tabelle erstellen, mit der jeder Spieler ausschließlich beschrieben wird:

+-----------+------------+-----------+------------+ | Player_id | First_Name | last_name | Rolle | +-----------+------------+-----------+------------ + | 111 | Cordaz | Alex | Torhüter | | 117 | Donnarumma | Gianluigi | Torhüter | | 124 | Handanovic | Samir | Torhüter | +-----------+------------+-----------+------------+ 

Wir können diese Informationen jetzt aus der Punktzahltabelle entfernen und so aussehen lassen:

+-----------+---------+-------+ | Player_id | gameday | Punktzahl | +-----------+----------+-------+| 111 | 18 | 6.50 | | 117 | 18 | 7.50 | | 124 | 18 | 7.50 | +-----------+---------+-------+ 

Die zweite normale Form ist jetzt zufrieden.

Die dritte normale Form

Die zweite Normalform ist eine Voraussetzung für die dritte Normalform. Um in der dritten normalen Form zu sein, muss eine Tabelle bereits in der zweiten normalen Form sein und darf keine Attribute enthalten, die sind transitiv abhängig Auf der Tabelle Primärschlüssel. Was bedeutet das? Wir können sagen, wir haben eine transitive Abhängigkeit Wenn ein sekundäres Attribut nicht direkt vom Primärschlüssel der Tabelle abhängt, aber eine Abhängigkeit von einem anderen sekundären Attribut hat. Angenommen, wir fügen zwei neue Spalten hinzu Spieler Tabelle oben, so sieht es so aus:

+-----------+------------+-----------+------------+---------+-----------+ | Player_id | First_Name | last_name | Rolle | Club | Club_City | +-----------+------------+-----------+------------ +----------+-----------+| 111 | Cordaz | Alex | Torhüter | Croton | Croton | | 117 | Donnarumma | Gianluigi | Torhüter | Mailand | Milano | | 124 | Handanovic | Samir | Torhüter | Inter | Milano | +-----------+------------+-----------+------------+---------+-----------+ 

Wir haben die hinzugefügt Verein Und Club_City Spalten auf der Tabelle, um den mit einem Spieler verbundenen Verein und die Stadt, zu der der Club gehört. Leider befriedigt die Tabelle jetzt nicht die dritte normale Form, Warum? Es ist recht einfach: die Club_City Attribut hängt nicht direkt von ab Player_id, Das ist der Primärschlüssel der Tabelle, hat aber eine transitive Abhängigkeit davon über ein anderes sekundäres Attribut: Verein.

Wie man das Problem löst, damit die dritte normale Form erfüllt ist? Wir müssen lediglich eine andere Tabelle erstellen, wo Informationen über jeden Club aufgezeichnet werden können. Hier ist der "Club" -Tisch:

+-----------+-----------+ | Club_Name | Club_City | +-----------+-----------+| Croton | Croton | | Mailand | Milano | | Inter | Milano | +-----------+-----------+ 

Wir isolierte Clubinformationen in einer speziellen Tabelle. Als Hauptschlüssel für die Tabelle haben wir in diesem Fall die verwendet Club_Name Spalte. Im Spieler Tisch, die wir jetzt entfernen können Club_City Spalte und eine fremde Schlüsselbeschränkung in die Verein Spalte so, dass sie auf die verweist Club_Name Spalte in der Verein Tisch:

+-----------+------------+-----------+------------+---------+ | Player_id | First_Name | last_name | Rolle | Club | +-----------+------------+-----------+------------ + ---------+ | 111 | Cordaz | Alex | Torhüter | Croton | | 117 | Donnarumma | Gianluigi | Torhüter | Mailand | | 124 | Handanovic | Samir | Torhüter | Inter | +-----------+------------+-----------+------------+---------+ 

Die dritte normale Form ist jetzt zufrieden.

Schlussfolgerungen

In diesem Tutorial haben wir über die ersten drei normalen Formen einer relationalen Datenbank gesprochen und darüber, wie sie verwendet werden, um die Redundanz von Daten zu reduzieren und Anomalien zu löschen, Löschung und Aktualisierung zu vermeiden. Wir haben gesehen, was die Voraussetzungen jeder normalen Form sind, einige Beispiele für ihre Verstöße und wie man sie behebt. Andere normale Formen existieren jedoch über die dritte, in den häufigsten Anwendungen reicht es aus, die dritte normale Form zu erreichen, um ein optimales Setup zu erreichen.

Verwandte Linux -Tutorials:

• Dinge zu installieren auf Ubuntu 20.04
• Eine Einführung in Linux -Automatisierung, Tools und Techniken
• Mastering -Bash -Skriptschleifen beherrschen
• Dinge zu tun nach der Installation Ubuntu 20.04 fokale Fossa Linux
• Mint 20: Besser als Ubuntu und Microsoft Windows?
• Linux -Konfigurationsdateien: Top 30 am wichtigsten
• ZFS auf Ubuntu 20 konfigurieren.04
• Ubuntu 20.04 Tricks und Dinge, die Sie vielleicht nicht wissen
• Big Data Manipulation zum Spaß und Gewinn Teil 1
• Verschachtelte Schleifen in Bash -Skripten