Beschreibung der Grundlagen der Datenbanknormalisierung
In diesem Artikel wird die Terminologie für die Datenbanknormalisierung für Anfänger erläutert. Ein grundlegendes Verständnis dieser Terminologie ist hilfreich, wenn der Entwurf einer relationalen Datenbank erläutert wird.
Beschreibung der Normalisierung
Normalisierung ist der Vorgang des Organisierens von Daten in einer Datenbank. Es umfasst das Erstellen von Tabellen und das Einrichten von Beziehungen zwischen diesen Tabellen gemäß Regeln, die sowohl zum Schutz der Daten als auch zur Flexiblerisierung der Datenbank durch die Vermeidung von Redundanz und inkonsistenten Abhängigkeiten konzipiert sind.
Redundante Daten belegen unnötig Speicherplatz und verursachen Wartungsprobleme. Wenn Daten, die an mehreren Stellen vorhanden sind, geändert werden müssen, müssen die Daten an allen Speicherorten auf die gleiche Weise geändert werden. Eine Änderung einer Kundenadresse etwa ist einfacher zu implementieren, wenn diese Daten nur in der Tabelle „Kunden“ und nirgendwo sonst in der Datenbank gespeichert werden.
Was ist eine „inkonsistente Abhängigkeit“? Während es für eine Benutzerin bzw. einen Benutzer intuitiv ist, in der Tabelle „Kunden“ nach der Adresse eines bestimmten Kunden zu suchen, ist es möglicherweise nicht sinnvoll, dort nach dem Gehalt des Mitarbeitenden zu suchen, der diesen Kunden anruft. Das Gehalt des Mitarbeiters hängt mit dem Mitarbeiter zusammen oder ist davon abhängig und sollte daher in die Tabelle „Mitarbeiter“ verschoben werden. Inkonsistente Abhängigkeiten können den Zugriff auf Daten erschweren, da der Pfad zur Suche nach den Daten möglicherweise fehlt oder unterbrochen ist.
Es gibt einige Regeln für die Datenbanknormalisierung. Jede Regel wird als „Normalform“ bezeichnet. Bei Einhaltung der ersten Regel wird die Datenbank als „erste Normalform“ bezeichnet. Wenn die ersten drei Regeln beachtet werden, wird die Datenbank als „dritte Normalform“ bezeichnet. Obwohl auch andere Stufen der Normalisierung möglich sind, gilt die dritte Normalform als die höchste Stufe, die für die meisten Anwendungen erforderlich ist.
Wie bei vielen formalen Regeln und Spezifikationen ist es in realen Szenarien nicht immer möglich, diese perfekt einzuhalten. Im Allgemeinen erfordert die Normalisierung zusätzliche Tabellen, und einige Kunden finden dies umständlich. Wenn Sie sich entscheiden, gegen eine der ersten drei Normalisierungsregeln zu verstoßen, müssen Sie sicherstellen, dass Ihre Anwendung alle Probleme vorwegnimmt, die auftreten können, z. B. redundante Daten und inkonsistente Abhängigkeiten.
Die folgenden Beschreibungen enthalten Beispiele.
Erste Normalform
- Entfernen Sie wiederholte Gruppen in einzelnen Tabellen.
- Erstellen Sie eine separate Tabelle für jeden Satz verwandter Daten.
- Identifizieren Sie jeden Satz verwandter Daten mit einem Primärschlüssel.
Verwenden Sie nicht mehrere Felder in einer einzigen Tabelle, um ähnliche Daten zu speichern. Um beispielsweise ein Bestandselement nachzuverfolgen, das aus zwei möglichen Quellen stammen kann, kann ein Bestandsdatensatz Felder für „Lieferantencode 1“ und „Lieferantencode 2“ enthalten.
Was geschieht, wenn Sie einen dritten Lieferanten hinzufügen? Das Hinzufügen eines Felds ist nicht die Antwort, denn dies erfordert Programm- und Tabellenänderungen und bietet keine reibungslose Anpassung für eine dynamische Anzahl von Lieferanten. Platzieren Sie stattdessen alle Lieferanteninformationen in einer separaten Tabelle namens „Lieferant“, und verknüpfen Sie den Bestand mit den Lieferanten durch einen Elementnummernschlüssel, oder umgekehrt Lieferanten mit dem Bestand durch einen Lieferantencodeschlüssel.
Zweite Normalform
- Erstellen Sie separate Tabellen für Wertesätze, die für mehrere Datensätze gelten.
- Setzen Sie diese Tabellen mit einem Fremdschlüssel in Beziehung.
Datensätze sollten nicht von einem anderen als dem Primärschlüssel einer Tabelle (ggf. einem Verbundschlüssel) abhängen. Betrachten Sie beispielsweise die Adresse eines Kunden in einem Buchhaltungssystem. Die Adresse wird von der Tabelle „Kunden“ benötigt, aber auch von den Tabellen „Bestellungen“, „Versand“, „Rechnungen“, „Kontenabrechnung“ und „Sammlungen“. Anstatt die Adresse des Kunden als separaten Eintrag in jeder dieser Tabellen zu speichern, speichern Sie sie an einem einzigen Ort, entweder in der Tabelle „Kunden“ oder in einer separaten Tabelle „Adressen“.
Dritte Normalform
- Entfernen Sie Felder, die nicht vom Schlüssel abhängen.
Werte in einem Datensatz, die nicht Teil des Schlüssels dieses Datensatzes sind, gehören nicht zur Tabelle. Im Allgemeinen sollten Sie in Betracht ziehen, diese Felder in einer separaten Tabelle zu platzieren, wenn der Inhalt einer Gruppe von Feldern auf mehr als einen einzelnen Datensatz in der Tabelle angewendet werden kann.
Beispielsweise können in einer Tabelle für die Mitarbeiterrekrutierung der Name und die Adresse eines Kandidaten enthalten sein. Sie benötigen jedoch eine vollständige Liste der Adressen für Gruppen-Mailings. Wenn Universitätsinformationen in der Tabelle „Kandidaten“ gespeichert werden, gibt es keine Möglichkeit, die Universitäten aufzulisten, von denen keine aktuellen Kandidaten kommen. Erstellen Sie also eine separate Tabelle „Universitäten“, und verknüpfen Sie sie mit der Tabelle „Kandidaten“ durch einen Schlüssel der Universitäts-Codes.
AUSNAHME: Das Einhalten der dritten Normalform ist zwar theoretisch wünschenswert, aber nicht immer praktisch. Wenn Sie über eine Tabelle „Kunden“ verfügen und alle möglichen Abhängigkeiten zwischen Feldern ausschließen möchten, müssen Sie separate Tabellen für Städte, Postleitzahlen, Vertriebsmitarbeiter, Kundenklassen und alle anderen Faktoren erstellen, die in mehreren Datensätzen dupliziert auftreten könnten. Theoretisch ist eine Normalisierung erstrebenswert. Die Existenz von vielen kleinen Tabellen kann jedoch die Leistung beeinträchtigen oder die Kapazitäten der Anzahl offener Dateien und des Speichers überschreiten.
Es ist möglicherweise sinnvoller, die dritte Normalform nur auf Daten anzuwenden, die sich häufig ändern. Wenn einige abhängige Felder verbleiben, entwerfen Sie Ihre Anwendung so, dass der Benutzer alle verwandten Felder überprüfen muss, wenn eines geändert wird.
Andere Normalisierungsformen
Eine vierte Normalform, auch als „Boyce-Codd Normal Form“ (BCNF) bezeichnet, und eine fünfte Normalform existieren zwar, werden aber in der Praxis selten berücksichtigt. Das Ignorieren dieser Regeln kann zu einem weniger perfekten Datenbankdesign führen, sollte sich jedoch nicht auf die Funktionalität auswirken.
Normalisieren einer Beispieltabelle
Diese Schritte veranschaulichen den Prozess der Normalisierung einer fiktiven Tabelle von Studenten.
Nicht normalisierte Tabelle:
Student# Berater Ber.-Büro Klasse1 Klasse2 Klasse3 1022 Jones 412 101-07 143-01 159-02 4123 Smith 216 101-07 143-01 179-04 Erste Normalform: Keine sich wiederholenden Gruppen
Tabellen sollten nur zwei Dimensionen haben. Da ein Student zu mehreren Klassen gehört, sollten diese Klassen in einer separaten Tabelle aufgeführt werden. Die Felder „Klasse1“, „Klasse2“ und „Klasse3“ in den obigen Datensätzen sind Hinweise darauf, dass es Probleme mit dem Design gibt.
Tabellenkalkulationen verwenden häufig die dritte Dimension, Tabellen sollten dies jedoch nicht. Eine weitere Möglichkeit, dieses Problem zu betrachten, besteht in einer one-to-many-Beziehung, wobei die „einfache“ Seite und die „mehrfache“ Seite nicht in dieselbe Tabelle gehören. Erstellen Sie stattdessen eine andere Tabelle in erster Normalform, indem Sie die wiederholte Gruppe (Class#) eliminieren, wie im folgenden Beispiel gezeigt:
Student# Berater Ber.-Büro Klasse# 1022 Jones 412 101-07 1022 Jones 412 143-01 1022 Jones 412 159-02 4123 Smith 216 101-07 4123 Smith 216 143-01 4123 Smith 216 179-04 Zweite Normalform: Redundante Daten eliminieren
Beachten Sie die mehrfachen Class#-Werte für jeden Student#-Wert in der obigen Tabelle. Class# ist funktional nicht von Student# (Primärschlüssel) abhängig, daher befindet sich diese Beziehung nicht in der zweiten Normalform.
In den folgenden Tabellen wird die zweite Normalform veranschaulicht:
Studenten:
Student# Berater Ber.-Büro 1022 Jones 412 4123 Smith 216 Registrierung:
Student# Klasse# 1022 101-07 1022 143-01 1022 159-02 4123 101-07 4123 143-01 4123 179-04 Dritte Normalform: Daten eliminieren, die nicht vom Schlüssel abhängig sind
Im letzten Beispiel ist „Ber.-Büro“ (die Büronummer des Beraters) funktional vom Attribut „Berater“ abhängig. Die Lösung besteht darin, dieses Attribut aus der Tabelle „Studenten“ in die Tabelle „Fakultät“ zu verschieben, wie unten dargestellt:
Studenten:
Student# Berater 1022 Jones 4123 Smith Fakultät:
Name Raum Abt. Jones 412 42 Smith 216 42