3.1 Datenbanknormalisierung
Normalform ist eine Eigenschaft einer Beziehung in einem relationalen Datenmodell, die sie im Hinblick auf Redundanz charakterisiert und möglicherweise zu logisch fehlerhaften Ergebnissen bei der Stichprobenentnahme oder Änderung von Daten führt. Unter Normalform versteht man den Satz von Anforderungen, die eine Relation (Tabellen in einer Datenbank) erfüllen muss.
Der Prozess der Konvertierung von Datenbankbeziehungen in eine Form, die den Normalformen entspricht, wird als Normalisierung bezeichnet. Durch die Normalisierung soll die Struktur der Datenbank auf eine Form gebracht werden, die eine minimale logische Redundanz bietet . Sie ist nicht dazu gedacht, die Leistung zu verringern oder zu steigern oder das physische Volumen der Datenbank zu verringern oder zu erhöhen .
Das ultimative Ziel der Normalisierung besteht darin, die potenzielle Inkonsistenz der in der Datenbank gespeicherten Informationen zu reduzieren. Der allgemeine Zweck des Normalisierungsprozesses ist wie folgt:
- Ausschluss bestimmter Arten von Entlassungen;
- einige Update-Anomalien beheben;
- Entwicklung eines Datenbankprojekts, das eine ausreichend „hochwertige“ Darstellung der realen Welt darstellt, intuitiv ist und als gute Grundlage für spätere Erweiterungen dienen kann;
- Vereinfachung des Verfahrens zur Anwendung der erforderlichen Integritätsbeschränkungen.
Redundanzen werden in der Regel beseitigt, indem Beziehungen so zerlegt werden, dass in jeder Beziehung nur primäre Fakten gespeichert werden (d. h. Fakten, die nicht von anderen gespeicherten Fakten abgeleitet werden).
Obwohl Normalisierungsideen für den Datenbankentwurf sehr nützlich sind, sind sie keineswegs ein universelles oder umfassendes Mittel zur Verbesserung der Qualität eines Datenbankentwurfs. Dies liegt daran, dass es in der Datenbankstruktur eine zu große Vielfalt an möglichen Fehlern und Mängeln gibt, die durch Normalisierung nicht behoben werden können.
Trotz dieser Überlegungen ist die Theorie der Normalisierung eine sehr wertvolle Errungenschaft der relationalen Theorie und Praxis, da sie wissenschaftlich strenge und fundierte Kriterien für die Qualität eines Datenbankprojekts und formale Methoden zur Verbesserung dieser Qualität bereitstellt. Dadurch hebt sich die Normalisierungstheorie von den rein empirischen Designansätzen ab, die in anderen Datenmodellen angeboten werden. Darüber hinaus lässt sich argumentieren, dass es im gesamten Bereich der Informationstechnologie praktisch keine Methoden zur Bewertung und Verbesserung von Designlösungen gibt, die hinsichtlich der formalen Strenge mit der Theorie der Normalisierung relationaler Datenbanken vergleichbar sind.
Die Normalisierung wird manchmal mit der Begründung kritisiert, es sei „nur gesunder Menschenverstand“ und jeder kompetente Fachmann werde „natürlich“ eine vollständig normalisierte Datenbank entwerfen, ohne die Abhängigkeitstheorie anwenden zu müssen.
Wie Professor Christopher Date feststellte, handelt es sich bei der Normalisierung jedoch genau um die Prinzipien des gesunden Menschenverstands, die einen reifen Designer in seinem Kopf leiten, das heißt, die Prinzipien der Normalisierung sind formalisierter gesunder Menschenverstand . Mittlerweile ist es eine sehr schwierige Aufgabe, die Prinzipien des gesunden Menschenverstandes zu identifizieren und zu formalisieren, und der Erfolg bei der Lösung ist eine bedeutende Errungenschaft.
3.2 Erste Normalform
Die erste Normalform (1NF) ist die grundlegende Normalform einer Beziehung im relationalen Datenmodell.
Eine Beziehungsvariable liegt genau dann in der ersten Normalform vor, wenn in jedem gültigen Wert dieser Variablen jedes Beziehungstupel genau einen Wert für jedes der Attribute enthält.
In einem relationalen Modell liegt eine Relation gemäß der Definition des Relationsbegriffs immer in der ersten Normalform vor.
Die verschiedenen Tabellen stellen möglicherweise keine korrekten Darstellungen von Beziehungen dar und sind dementsprechend möglicherweise nicht in 1NF enthalten. Gemäß der Definition von Christopher Date für einen solchen Fall ist eine Tabelle genau dann normalisiert (d. h. liegt in der ersten Normalform vor), wenn es sich um eine direkte und wahre Darstellung einer Beziehung handelt. Genauer gesagt muss die betreffende Tabelle die folgenden fünf Bedingungen erfüllen:
- Es gibt keine Reihenfolge der Zeilen von oben nach unten (mit anderen Worten, die Reihenfolge der Zeilen übermittelt keine Informationen).
- Es gibt keine Reihenfolge der Spalten von links nach rechts (mit anderen Worten, die Reihenfolge der Spalten enthält keine Informationen).
- Keine doppelten Zeilen.
- Jeder Schnittpunkt einer Zeile und einer Spalte enthält genau einen Wert aus der entsprechenden Domäne (und sonst nichts).
- Alle Spalten sind „regulär“.
Die „Regelmäßigkeit“ aller Spalten einer Tabelle bedeutet, dass es keine „versteckten“ Komponenten in der Tabelle gibt, auf die nur durch den Aufruf eines speziellen Operators zugegriffen werden kann, anstatt auf reguläre Spaltennamen zu verweisen, oder die zu Nebenwirkungen für Zeilen führen oder Tabellen beim Aufruf von Standardoperatoren.
Die ursprüngliche nicht normalisierte Tabelle (d. h. keine korrekte Darstellung einer Beziehung):
Mitarbeiter | Telefonnummer |
---|---|
Iwanow I.I. |
283-56-82 390-57-34 |
Petrov P.P. | 708-62-34 |
Sidorov S.S. |
Eine auf 1NF reduzierte Tabelle, die die korrekte Darstellung einer Beziehung darstellt:
Mitarbeiter | Telefonnummer |
---|---|
Iwanow I.I. | 283-56-82 |
Iwanow I.I. | 390-57-34 |
Petrov P.P. | 708-62-34 |
3.3 Zweite Normalform
Eine Beziehungsvariable liegt genau dann in der zweiten Normalform vor, wenn sie in der ersten Normalform vorliegt und jedes Nicht-Schlüsselattribut irreduzibel von (jedem) seinem Kandidatenschlüssel abhängig ist .
Irreduzibilität bedeutet, dass der potenzielle Schlüssel keine kleinere Teilmenge von Attributen enthält, aus denen diese funktionale Abhängigkeit ebenfalls abgeleitet werden kann. Für eine irreduzible funktionale Abhängigkeit wird häufig das entsprechende Konzept der „vollständigen funktionalen Abhängigkeit“ verwendet.
Wenn der Kandidatenschlüssel einfach ist, also aus einem einzigen Attribut besteht, dann ist jede funktionale Abhängigkeit davon irreduzibel (vollständig). Handelt es sich bei dem Kandidatenschlüssel um einen zusammengesetzten Schlüssel, dann darf es gemäß der Definition der zweiten Normalform keine Nichtschlüsselattribute der Relation geben, die von einem Teil des zusammengesetzten Kandidatenschlüssels abhängen.
Ein Beispiel für die Konvertierung einer Beziehung in die zweite Normalform
Das Attributpaar {Firmenniederlassung, Position} soll den Primärschlüssel in der folgenden Beziehung bilden:
Unternehmenszweig | Berufsbezeichnung | Gehalt | Verfügbarkeit eines Computers |
---|---|---|---|
Niederlassung in Tomsk | Reiniger | 20000 | Nein |
Niederlassung in Moskau | Programmierer | 40000 | Essen |
Niederlassung in Tomsk | Programmierer | 25000 | Essen |
Nehmen wir an, das Gehalt hängt von der Branche und der Position ab und die Verfügbarkeit eines Computers hängt nur von der Position ab.
Es besteht eine funktionale Abhängigkeit Position -> Computer, bei der die linke Seite (Determinante) nur ein Teil des Primärschlüssels ist, was gegen die Bedingung der zweiten Normalform verstößt.
Um auf 2NF zu reduzieren, sollte die ursprüngliche Beziehung in zwei Beziehungen zerlegt werden:
Unternehmenszweig | Berufsbezeichnung | Gehalt |
---|---|---|
Niederlassung in Tomsk | Reiniger | 20000 |
Niederlassung in Moskau | Programmierer | 40000 |
Niederlassung in Tomsk | Programmierer | 25000 |
Berufsbezeichnung | Verfügbarkeit eines Computers |
---|---|
Reiniger | Nein |
Programmierer | Essen |
Programmierer | Essen |
3.4 Dritte Normalform (3NF)
Eine Beziehungsvariable R liegt genau dann in 3NF vor, wenn die folgenden Bedingungen zutreffen:
- Rliegt in der zweiten Normalform vor.
- kein Nicht-SchlüsselattributRsteht nicht in transitiver funktionaler Abhängigkeit vom KandidatenschlüsselR.
Erläuterungen zur Definition:
Ein Nicht-Schlüsselattribut einer Relation R ist ein Attribut, das zu keinem der Kandidatenschlüssel von R gehört.
Die funktionale Abhängigkeit der Menge von Attributen Z von der Menge von Attributen X (geschrieben X → Z, ausgesprochen „x bestimmt z“) ist transitiv, wenn es eine solche Menge von Attributen Y gibt, dass X → Y und Y → Z. In diesem In diesem Fall ist keine der Mengen X, Y und Z eine Teilmenge der anderen, d. h. die funktionalen Abhängigkeiten X → Z, X → Y und Y → Z sind nicht trivial, und es gibt auch keine funktionale Abhängigkeit Y → X.
Eine Definition von 3NF, die der von Codd entspricht, aber anders formuliert ist, wurde 1982 von Carlo Zaniolo gegeben. Danach ist eine Relationsvariable genau dann in 3NF, wenn jede ihrer funktionalen Abhängigkeiten X → A mindestens eine der folgenden Bedingungen erfüllt:
- X enthält A (d. h. X → A ist eine triviale funktionale Abhängigkeit)
- X – Superschlüssel
- A ist ein Schlüsselattribut (d. h. A ist Teil eines Kandidatenschlüssels).
Zaniolos Definition definiert klar den Unterschied zwischen 3NF und der strengeren Boyce-Codd-Normalform (BCNF): BCNF schließt die dritte Bedingung („A ist ein Schlüsselattribut“) aus.
Eine einprägsame und traditionell beschreibende Zusammenfassung von Codds 3NF-Definition wurde von Bill Kent gegeben: Jedes Nicht-Schlüsselattribut „sollte Informationen über den Schlüssel, den vollständigen Schlüssel und nichts als den Schlüssel liefern “.
Die Bedingung der Abhängigkeit vom „vollständigen Schlüssel“ von Nicht-Schlüsselattributen stellt sicher, dass die Beziehung in der zweiten Normalform vorliegt; und die Bedingung dafür, dass sie von „nichts als dem Schlüssel“ abhängen, ist, dass sie sich in der dritten Normalform befinden.
Chris Date spricht von Kents Zusammenfassung als einem „intuitiv attraktiven Merkmal“ von 3NF und stellt fest, dass sie mit einer leichten Modifikation auch als Definition der strengeren Boyce-Codd-Normalform dienen kann: „Jedes Attribut muss Informationen über einen Schlüssel liefern.“ , ein vollständiger Schlüssel und nichts anderes als der Schlüssel.
Kents Version der 3NF-Definition ist weniger streng als die Boyce-Codd-Normalformversion der Formulierung von Data, da erstere nur besagt, dass Nicht-Schlüsselattribute von Schlüsseln abhängen.
Primäre Attribute (die Schlüssel oder Teile davon sind) müssen überhaupt nicht funktional abhängig sein; Jeder von ihnen stellt Informationen über den Schlüssel bereit, indem er den Schlüssel selbst oder einen Teil davon bereitstellt. Hierbei ist zu beachten, dass diese Regel nur für Nicht-Schlüsselattribute gilt, da bei der Anwendung auf alle Attribute alle komplexen Alternativschlüssel vollständig deaktiviert werden, da jedes Element eines solchen Schlüssels gegen die Bedingung „vollständiger Schlüssel“ verstößt.
Betrachten Sie als Beispiel die Beziehungsvariable R1:
Mitarbeiter | Abteilung | Telefon |
---|---|---|
Grischin | Buchhaltung | 22.11.33 |
Wassiljew | Buchhaltung | 22.11.33 |
Petrow | Liefern | 44-55-66 |
Jeder Mitarbeiter gehört ausschließlich einer Abteilung an; Jede Abteilung verfügt über ein einziges Telefon. Das Mitarbeiterattribut ist der Primärschlüssel. Mitarbeiter haben keine persönlichen Telefone und die Telefonnummer des Mitarbeiters hängt ausschließlich von der Abteilung ab.
Im Beispiel bestehen folgende funktionale Abhängigkeiten: Mitarbeiter → Abteilung, Abteilung → Telefon, Mitarbeiter → Telefon.
Die Beziehungsvariable R1 liegt in der zweiten Normalform vor, da jedes Attribut eine irreduzible funktionale Abhängigkeit vom potenziellen Schlüsselmitarbeiter aufweist.
Die Beziehung Mitarbeiter → Telefon ist transitiv, daher liegt die Beziehung nicht in der dritten Normalform vor.
Die Aufteilung von R1 führt zu zwei Beziehungsvariablen, die in 3NF vorliegen:
Abteilung | Telefon |
---|---|
Buchhaltung | 22.11.33 |
Liefern | 44-55-66 |
Mitarbeiter | Abteilung |
---|---|
Grischin | Buchhaltung |
Wassiljew | Buchhaltung |
Petrow | Liefern |
Die anfängliche Beziehung R1 kann bei Bedarf leicht durch Zusammenfügen der Beziehungen R2 und R3 erhalten werden.
GO TO FULL VERSION