Detaillierte Erklärung der Verwendung des MySQL-Paradigmas

1. Paradigma

Der englische Name des Paradigmas lautet „Normal Form“ und wurde vom Briten EF Codd (dem Vorläufer der relationalen Datenbank) zusammengefasst, nachdem er in den 1970er Jahren das relationale Datenbankmodell vorgeschlagen hatte. Das Paradigma ist die Grundlage der relationalen Datenbanktheorie und stellt zugleich die Regeln und Leitlinien dar, die wir beim Entwurf einer Datenbankstruktur befolgen müssen. Derzeit gibt es 8 Paradigmen, nämlich: 1NF, 2NF, 3NF, BCNF, 4NF, 5NF, DKNF und 6NF. Normalerweise werden nur die ersten drei Paradigmen verwendet, nämlich: das erste Paradigma (1NF), das zweite Paradigma (2NF) und das dritte Paradigma (3NF).

Erste Normalform (1NF)

Die erste Normalform ist tatsächlich die Grundlage relationaler Datenbanken, d. h. jede relationale Datenbank entspricht der ersten Normalform. Einfach ausgedrückt bedeutet die erste Normalform, dass die Daten in jeder Zeile untrennbar sind, in derselben Spalte nicht mehrere Werte vorhanden sein können und bei wiederholten Attributen eine neue Entität definiert werden muss.
Die folgende Datenbank entspricht nicht der ersten Normalform:

+------------+---------------------+
| Arbeitername | Unternehmen |
+------------+---------------------+
| John | ByteDance, Tencent |
| Mike | Tencent |
+------------+---------------------+

Die oben beschriebenen Daten bedeuten, dass Mike bei Tencent arbeitet und John sowohl bei ByteDance als auch bei Tencent arbeitet (sofern dies möglich ist). Dieser Ausdruck entspricht jedoch nicht der ersten Normalform, d. h. die Daten in der Spalte müssen untrennbar sein. Um der ersten Normalform zu entsprechen, muss er die folgende Form haben:

+------------+-----------+
| Arbeitername | Unternehmen |
+------------+-----------+
| Mike | Tencent |
| John | ByteDance |
| John | Tencent |
+------------+-----------+

Zweite Normalform (2NF)

Zunächst muss eine Datenbank die erste Normalform erfüllen, bevor sie die zweite Normalform erfüllen kann.
Schauen wir uns zunächst eine Tabelle an:

+----------+----------+----------+
| Mitarbeiter | Abteilung | Leiter |
+----------+----------+----------+
| Jones | Buchhaltung | Jones |
| Schmied | Ingenieurwissenschaften | Schmied |
| Braun | Buchhaltung | Jones |
| Grün | Ingenieurwesen | Schmied |
+----------+----------+----------+

In dieser Tabelle werden die Beziehungen zwischen Mitarbeitern, Arbeitsabteilungen und Führungskräften beschrieben. Die in dieser Tabelle dargestellte Beziehung ist im wirklichen Leben durchaus möglich. Betrachten wir nun eine Frage: Wenn Brown die Leitung der Buchhaltungsabteilung übernimmt, wie müssen wir die Tabelle dann ändern? Dieses Problem wird sehr lästig, weil wir feststellen werden, dass die Daten miteinander gekoppelt sind und es schwierig ist, eine gute Beurteilungsbedingung zu finden, die jede Zeile eindeutig bestimmen kann, um Ihre UPDATE-Anweisung auszuführen. Wir machen die Daten, die eine Zeile einer Tabelle in der Datenbank eindeutig darstellen können, zum Primärschlüssel dieser Tabelle. Daher entspricht eine Tabelle ohne Primärschlüssel nicht dem zweiten Paradigma. Dies bedeutet, dass eine Tabelle, die dem zweiten Paradigma entspricht, einen Primärschlüssel angeben muss.

Damit die obige Tabelle der zweiten Normalform entspricht, müssen wir sie daher in zwei Tabellen aufteilen:

+----------+----------+
| Mitarbeiter | Abteilung |
+----------+----------+
| Braun | Buchhaltung |
| Grün | Ingenieurwesen |
| Jones | Buchhaltung |
| Schmied | Ingenieurwesen |
+----------+----------+

+-------------+----------+
| Abteilung | Leiter |
+-------------+----------+
| Buchhaltung | Jones |
| Ingenieurwesen | Schmied |
+-------------+----------+

In diesen beiden Tabellen ist der Primärschlüssel der ersten Tabelle „Mitarbeiter“ und der Primärschlüssel der zweiten Tabelle „Abteilung“. In diesem Fall ist es sehr einfach, das obige Problem zu lösen.

Dritte Normalform (3NF)

Eine relationale Datenbank muss die zweite Normalform erfüllen, bevor sie die dritte Normalform erfüllen kann.
Vor der dritten Normalform schauen wir uns noch zwei Tabellen an:

+-----------+-------------+---------+---------+----------+
| Studenten-ID | Studentenname | Fach | Punktzahl |
+-----------+-------------+---------+---------+----------+
| 1 | Mike | Mathe | 96 |
| 2 | Johannes | Chinesisch | 85 |
| 3 | Kate | Geschichte | 100 |
+-----------+-------------+---------+---------+----------+

+-----------+--------------+-------+
| Subjekt-ID | Studenten-ID | Punktzahl |
+-----------+--------------+-------+
| 101 | 1 | 96 |
| 111 | 3 | 100 |
| 201 | 2 | 85 |
+-----------+--------------+-------+

Die Primärschlüssel der beiden obigen Tabellen sind studentid bzw. subjectid. Offensichtlich entsprechen beide Tabellen der zweiten Normalform.

Wir werden jedoch feststellen, dass diese beiden Tabellen doppelte und redundante Datenwerte aufweisen. Daher besteht die dritte Normalform darin, redundante Daten zu eliminieren. Insbesondere in der obigen Situation kann nur eine der beiden Tabellen die Daten der Score-Spalte enthalten. Wie verbinden wir also diese beiden Tabellen? Hier kommt der Fremdschlüssel ins Spiel. Wenn es in zwei Tabellen redundante und wiederholte Spalten gibt und eine Nicht-Primärschlüsselspalte in einer Tabelle der Primärschlüssel in der anderen Tabelle ist, können wir zur Beseitigung der redundanten Spalten diese Nicht-Primärschlüsselspalte als Brücke zwischen den beiden Tabellen verwenden, also als Fremdschlüssel. Durch Beobachtung können wir feststellen, dass „studentid“ der Primärschlüssel in der ersten Tabelle und ein Nicht-Primärschlüssel in der zweiten Tabelle ist und daher der Fremdschlüssel der zweiten Tabelle darstellt. Daher haben wir in der obigen Situation die folgende Schreibweise, die der dritten Normalform entspricht:

+-------------+----------+---------+
| Studenten-ID | Studentenname | Fach |
+-------------+----------+---------+
| 1 | Mike | Mathe |
| 2 | Johannes | Chinesisch |
| 3 | Kate | Geschichte |
+-------------+----------+---------+

+-----------+--------------+-------+
| Subjekt-ID | Studenten-ID | Punktzahl |
+-----------+--------------+-------+
| 101 | 1 | 96 |
| 111 | 3 | 100 |
| 201 | 2 | 85 |
+-----------+--------------+-------+

Es zeigt sich, dass nach dem Festlegen des Fremdschlüssels, selbst wenn die Score-Spalte in der ersten Tabelle gelöscht wird, der entsprechende Score-Wert über die Student-ID in der zweiten Tabelle gefunden werden kann. Dadurch wird die Datenredundanz eliminiert, ohne die Suche zu beeinträchtigen, und die dritte Normalform wird erfüllt.

2. Vor- und Nachteile von Paradigmen

Vorteile des Paradigmas

• Normalisierte Aktualisierungsvorgänge sind im Allgemeinen schneller als denormalisierte.
• Wenn die Daten gut normalisiert sind, gibt es kaum oder keine Datenduplizierung, sodass weniger Daten geändert werden müssen.
• Normalisierte Tabellen sind normalerweise kleiner und passen besser in den Speicher, sodass die Vorgänge schneller sind.
• Weniger redundante Daten bedeuten einen geringeren Bedarf an DISTINCT- oder GROUP BY-Anweisungen beim Abrufen tabellarischer Daten.

Nachteile des Paradigmas

• Der Nachteil der Normalisierung besteht darin, dass sie normalerweise eine Assoziation erfordert. Für jede etwas komplexere Abfrage ist möglicherweise mindestens ein Join auf einer normalisierten Datenbank erforderlich, möglicherweise auch mehr. Dies ist nicht nur kostspielig, sondern kann auch einige Indizierungsstrategien ungültig machen.
  

Dies ist das Ende dieses Artikels zur detaillierten Verwendung des MySQL-Paradigmas. Weitere relevante Inhalte zum MySQL-Paradigma finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!