Detaillierte Erklärung des MySQL-Datenbankparadigmas

Vorwort:

Ich habe oft von Datenbankparadigmen gehört, sie aber nie im Detail verstanden. Allgemeine Datenbankbücher oder Datenbankkurse führen in paradigmenbezogene Inhalte ein, und Paradigmen tauchen häufig in Datenbankprüfungsfragen auf. Ich frage mich, ob Sie das Paradigma klar verstanden haben? In diesem Artikel lernen wir Datenbankparadigmen kennen.

1. Einführung in das Datenbankparadigma

Um eine Datenbank mit weniger Redundanz und einer sinnvollen Struktur zu erstellen, müssen beim Entwurf der Datenbank bestimmte Regeln beachtet werden. In einer relationalen Datenbank wird diese Regel als Paradigma bezeichnet. Ein Paradigma ist eine Zusammenfassung, die eine bestimmte Designanforderung erfüllt. Um eine gut strukturierte relationale Datenbank zu entwerfen, müssen bestimmte Paradigmen erfüllt sein.

Der englische Name des Paradigmas lautet Normal Form, abgekürzt NF. Es wurde vom Briten EF Codd 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 sechs gängige Paradigmen für relationale Datenbanken: erste Normalform (1NF), zweite Normalform (2NF), dritte Normalform (3NF), Buss-Codd-Normalform (BCNF), vierte Normalform (4NF) und fünfte Normalform (5NF, auch bekannt als perfekte Normalform). Die minimale Normalform ist die erste Normalform (1NF). Die erste Normalform, die mehr Spezifikationsanforderungen erfüllt, wird als zweite Normalform (2NF) bezeichnet und die verbleibenden Normalformen sind ähnlich.

2. Detaillierte Erklärung gängiger Paradigmen

Beim Entwurf einer Datenbank beziehen wir uns auf die Paradigmenanforderungen. Dies bedeutet jedoch nicht, dass es besser ist, je höher das Paradigmenniveau ist. Ein zu hohes Paradigma hat zwar bessere Einschränkungen für Datenbeziehungen, macht aber auch die Beziehungen zwischen Tabellen komplizierter, was dazu führt, dass jedes Mal mehr Tabellen bearbeitet werden müssen und die Datenbankleistung abnimmt. Normalerweise folgt beim Entwurf relationaler Datenbanken die höchste Ebene BCNF, und 3NF ist die gebräuchlichste. Das heißt, im Allgemeinen sind die ersten drei Paradigmen für uns ausreichend. Sehen wir uns die ersten drei häufig verwendeten Paradigmen genauer an.

Erste Normalform (1NF)

Das erste Paradigma ist das grundlegendste Paradigma. Wenn alle Feldwerte in einer Datenbanktabelle nicht zerlegbare atomare Werte sind, bedeutet dies, dass die Datenbanktabelle die erste Normalform erfüllt. 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 doppelten Attributen eine neue Entität definiert werden muss.

Beispiel: Angenommen, ein Unternehmen möchte die Namen und Kontaktdaten seiner Mitarbeiter speichern. Es wird eine Tabelle wie diese erstellt:

Zwei Mitarbeiter (Jon und Lester) haben zwei Mobiltelefonnummern, daher speichert das Unternehmen sie in derselben Tabelle, wie in der obigen Tabelle gezeigt. Dann entspricht die Tabelle nicht 1NF, da die Regel besagt: „Jedes Attribut einer Tabelle muss einen atomaren (einzelnen) Wert haben“, und der emp_mobile-Wert für die Mitarbeiter von Jon & Lester verstößt gegen diese Regel. Um die Tabelle 1NF-konform zu machen, sollten wir über die folgenden Tabellendaten verfügen:

Zweite Normalform (2NF)

Das zweite Paradigma geht einen Schritt weiter als das erste Paradigma. Das zweite Paradigma erfordert die Gewährleistung, dass jede Spalte in der Datenbanktabelle mit dem Primärschlüssel in Beziehung steht und nicht nur mit einem Teil des Primärschlüssels (hauptsächlich bei zusammengesetzten Primärschlüsseln). Das heißt, in einer Datenbanktabelle kann nur ein Datentyp gespeichert werden, und mehrere Datentypen können nicht in derselben Datenbanktabelle gespeichert werden.

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

Die obige Tabelle beschreibt die Beziehung zwischen Mitarbeitern, Arbeitsabteilungen und Führungskräften. Als Primärschlüssel dieser Tabelle bezeichnen wir die Daten, die eine Zeile einer Tabelle in der Datenbank eindeutig darstellen können. Die Kopfspalte in der Tabelle hat keinen Bezug zum Primärschlüssel. Daher entspricht die Tabelle nicht der zweiten Normalform. Um die obige Tabelle der zweiten Normalform anzupassen, muss sie in zwei Tabellen aufgeteilt werden:

-- Mitarbeiter ist der Primärschlüssel +----------+----------+
| Mitarbeiter | Abteilung |
+----------+----------+
| Braun | Buchhaltung |
| Grün | Ingenieurwesen |
| Jones | Buchhaltung |
| Schmied | Ingenieurwesen |
+----------+----------+

-- Abteilung ist der Primärschlüssel+-------------+-------+
| Abteilung | Leiter |
+-------------+----------+
| Buchhaltung | Jones |
| Ingenieurwesen | Schmied |
+-------------+----------+

Dritte Normalform (3NF)

Unter der Voraussetzung der Erfüllung von 2NF müssen alle Felder außer dem Primärschlüssel unabhängig voneinander sein, d. h. es muss sichergestellt werden, dass jede Datenspalte in der Datentabelle direkt und nicht indirekt mit dem Primärschlüssel verknüpft ist.

Kurz gesagt erfordert die dritte Normalform (3NF), dass eine Relation keine nicht-primären Schlüsselinformationen enthält, die bereits in anderen Relationen enthalten sind. Beispielsweise gibt es eine Abteilungsinformationstabelle, in der jede Abteilung Informationen wie die Abteilungsnummer (dept_id), den Abteilungsnamen und das Abteilungsprofil enthält. Nachdem Sie die Abteilungsnummer in der Mitarbeiterinformationstabelle aufgeführt haben, können Sie der Mitarbeiterinformationstabelle keinen Abteilungsnamen, kein Abteilungsprofil und keine anderen abteilungsbezogenen Informationen mehr hinzufügen. Wenn die Abteilungsinformationstabelle nicht vorhanden ist, sollte sie auch gemäß der dritten Normalform (3NF) erstellt werden, da sonst viele Datenredundanzen auftreten.

3. Über Anti-Paradigma

Die Vorteile dieses Paradigmas liegen auf der Hand: Es vermeidet viele Datenredundanzen, spart Speicherplatz und sorgt für die Datenkonsistenz. Normalisierte Tabellen sind im Allgemeinen kleiner und passen besser in den Speicher, sodass Vorgänge schneller ausgeführt werden. Bedeutet dies also, dass das Datenbankdesign optimal ist, solange alle Tabellen auf 3NF standardisiert sind? Das ist nicht unbedingt der Fall. Ein höheres Paradigma bedeutet eine feinere Aufteilung der Tabellen, es werden mehr Tabellen in einer Datenbank benötigt und Benutzer müssen ursprünglich zusammengehörige Daten auf mehrere Tabellen verteilen. 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.

Daher folgen wir beim Entwurf einer Datenbank nicht vollständig den Paradigmenanforderungen und führen manchmal auch ein Anti-Paradigmen-Design durch. Verbessern Sie die Leseleistung der Datenbank, indem Sie redundante oder doppelte Daten hinzufügen und die Anzahl der Verknüpfungstabellen während zugehöriger Abfragen reduzieren.

Oben finden Sie eine ausführliche Erläuterung des MySQL-Datenbankparadigmas. Weitere Informationen zum MySQL-Datenbankparadigma finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!