Normalisierung in SQL: 1NF, 2NF, 3NF & BCNF

Normalisierung ist ein systematischer Prozess, um sicherzustellen, dass ein relationales Datenbankmodell effizient, für allgemeine Abfragen geeignet und frei von unerwünschten Merkmalen wie Einfügungs-, Aktualisierungs- und Löschanomalien ist, die zum Verlust der Integrität der Daten führen. Dieser Normalisierungsprozess trägt auch dazu bei, Datenredundanz zu eliminieren und die Wahrscheinlichkeit von Inkonsistenzen nach Einfüge-, Aktualisierungs- oder Löschvorgängen zu verringern.

Betrachten Sie zum besseren Verständnis folgendes Schema: Student (Name, Adresse, Fach, Note)

Dieses Schema weist einige Probleme oder Ineffizienzen auf.

1) Redundanz : Die Adresse des Studenten wird für jedes Fach, für das er eingeschrieben ist, wiederholt.

2) Aktualisierungsanomalie : Möglicherweise haben wir die Adresse in einem Tupel (Zeile) aktualisiert, während sie in den anderen Zeilen unverändert gelassen wurde. Somit hätten wir nicht für jeden Schüler eine durchgehend eindeutige Adresse.

3) Einfügungsanomalie : Wir werden die Adresse eines Studenten nicht aufzeichnen, ohne sich für mindestens ein Fach zu registrieren. Wenn sich ein Student für ein neues Fach einschreiben möchte, ist es ebenfalls möglich, dass eine andere Adresse eingefügt wird.

4) Löschanomalie : Entscheidet sich ein Student, alle immatrikulierten Fächer abzubrechen, geht bei der Löschung auch die Adresse des Studenten verloren.

Daher ist es wichtig, die Benutzerdaten durch Beziehungen darzustellen, die nach Tupel-Hinzufügungs-, -Lösch- oder -Aktualisierungsoperationen keine Anomalien erzeugen. Dies kann nur durch eine sorgfältige Analyse der Integritätsbedingungen, insbesondere der Datenabhängigkeiten der Datenbank, erreicht werden.

Die Relationen sollten so gestaltet sein, dass nur solche Attribute gruppiert werden, die natürlicherweise zusammen existieren. Dies kann meist durch ein grundlegendes Verständnis der Bedeutung aller Datenattribute erreicht werden. Wir brauchen jedoch noch einige formale Maßnahmen, um unser Designziel sicherzustellen.

Normalisierung ist diese formale Maßnahme. Es beantwortet die Frage, warum eine bestimmte Gruppierung von Attributen besser ist als jede andere.

Heute gibt es sieben Normalformen:

• Erste Normalform (1NF)
• Zweite Normalform (2NF)
• Dritte Normalform (3NF)
• Boyce-Codd-Normalform (BCNF)
• Vierte Normalform (4NF)
• Fünfte Normalform (5NF)
• Sechster oder Domänenschlüssel Normalform (6NF)

Lesen Sie: Arten von Ansichten in SQL

Erste Normalform (1NF oder Minimalform)

• Es gibt keine Reihenfolge von oben nach unten für die Zeilen und von links nach rechts für die Spalten.
• Es gibt keine doppelten Zeilen.
• Jeder Zeilen- und Spaltenschnittpunkt enthält genau einen Wert aus der zutreffenden Domäne oder einen Nullwert. Diese Bedingung gibt an, dass alle Spaltenwerte atomar oder skalar sein oder nur einen einzigen Wert enthalten sollen. Hier ist keine Wiederholung von Informationen oder Werten in mehreren Spalten erlaubt.
• Alle Spalten sind regulär (dh Zeilen haben keine versteckten Komponenten wie Zeilen-IDs, Objekt-IDs oder versteckte Zeitstempel).

Nehmen wir ein Beispiel für ein Schema, das nicht normalisiert ist. Angenommen, ein Designer möchte die Namen und Telefonnummern von Kunden aufzeichnen. Sie definieren eine Kundentabelle wie gezeigt:

Hier ist es nicht in 1 NF. Die Spalte „Telefonnummern“ ist nicht atomar oder hat keinen Skalarwert, dh sie hatte mehr als einen Wert, was in 1 NF nicht zulässig ist.

Um es 1 NF zu machen

• Wir werden zuerst unsere einzelne Tabelle in zwei Teile aufteilen (zerlegen).
• Jede Tabelle sollte nur Informationen zu einer Entität enthalten.

Sich wiederholende Gruppen von Telefonnummern kommen in diesem Design nicht vor. Stattdessen wird jeder Link zwischen Kunde und Telefonnummer in einem eigenen Datensatz angezeigt.

Checkout: Die häufigsten Fragen und Antworten zu SQL-Interviews

Zweite Normalform

Jede Normalform hat mehr einschränkende Kriterien als ihre Vorgänger. Jede Tabelle, die sich in der zweiten Normalform (2NF) oder höher befindet, ist per Definition auch in 1NF. Andererseits kann eine Tabelle, die in 1NF ist, in 2NF sein oder nicht; wenn es in 2NF ist, kann es in 3NF sein oder nicht und so weiter.

Eine 1NF-Tabelle befindet sich genau dann in 2NF, wenn keines ihrer nicht primären Attribute funktional von einem Teil (einer richtigen Teilmenge) eines Kandidatenschlüssels abhängig ist. (Ein Nicht-Prime-Attribut gehört zu keinem Kandidatenschlüssel.)

Beachten Sie, dass, wenn eine 1NF-Tabelle keine zusammengesetzten Kandidatenschlüssel hat (Kandidatenschlüssel, die aus mehr als einem Attribut bestehen), die Tabelle automatisch in 2NF ist.

Prüfen Sie, ob eine Relation R (A, B, C, D, E) mit FD Set as { BC ? D, Wechselstrom ? BE, B ? E } ist in 2NF?

• Wie wir sehen können, ist der Abschluss von AC (AC)+ = {A, C, B, E, D} durch Anwendung des Zugehörigkeitsalgorithmus. Aber keine seiner Teilmengen kann alle Beziehungsattribute selbst bestimmen, also ist AC der Kandidatenschlüssel für diese Beziehung. Darüber hinaus können weder A noch C von irgendeinem anderen Attribut der Relation abgeleitet werden, sodass es nur einen Kandidatenschlüssel gibt, der {AC} ist.
• Hier sind {A, C} die Hauptattribute und {B, D, E} die Nicht-Hauptattribute.
• Die Relation R befindet sich bereits in der 1. Normalform, da ein relationales DBMS in 1NF keine mehrwertigen oder zusammengesetzten Attribute zulässt.

BC ? D ist in der 2. Normalform, weil BC keine echte Teilmenge des Kandidatenschlüssels AC ist,

Wechselstrom ? BE ist in der 2. Normalform, da AC selbst der Kandidatenschlüssel ist, und

B ? E ist in der 2. Normalform B ist keine richtige Teilmenge des Kandidatenschlüssels AC.

Damit ist die gegebene Relation R in der 2. Normalform.

Dritte Normalform

Von einer Tabelle wird gesagt, dass sie in 3NF ist, wenn und nur wenn für jede ihrer funktionalen Abhängigkeiten.

X → A gilt mindestens eine der folgenden Bedingungen:

• X enthält A (d. h. X → A ist eine triviale funktionale Abhängigkeit), oder
• X ist eine Supertaste, oder
• A ist ein Primattribut (dh A ist in einem Kandidatenschlüssel vorhanden)

Eine andere Definition von 3NF besagt, dass jedes Nicht-Schlüsselattribut von R nicht transitiv (dh direkt abhängig) vom Primärschlüssel von R ist. Dies bedeutet, dass kein Nicht-Primärattribut (nicht Teil des Kandidatenschlüssels) funktional von anderen Nicht-Primärattributen abhängig ist. Wenn es zwei Abhängigkeiten gibt, so dass A ? B und BC, dann können wir aus diesen FDs A ableiten ? C. Diese Abhängigkeit AC ist transitiv.

Beispiel für 3NF:

Betrachten Sie die folgende Beziehung Order (Order#, Part, Supplier, UnitPrice, QtyOrdered) mit dem gegebenen Satz von FDs:

Befehl# ? Part, Supplier, QtyOrdered und Supplier, Part ? Einzelpreis)

Hier ist Order# der Schlüssel zur Beziehung.

Unter Verwendung der Axiome von Amstrong erhalten wir

Befehl# ? Teil, Bestellung ? Lieferant und Auftrag ? MengeBestellt.

Befehl# ? Teil, Lieferant und Lieferant, Teil ? Stückpreis, beide geben Order# ? Einzelpreis.

Somit sehen wir, dass alle Nicht-Prime-Attribute vom Schlüssel (Order#) abhängen. Es besteht jedoch eine transitive Abhängigkeit zwischen Order# und UnitPrice. Diese Beziehung ist also nicht in 3NF enthalten. Wie machen wir es in 3NF?

Wir können den Stückpreis eines von einem Lieferanten gelieferten Teils nicht speichern, es sei denn, jemand gibt eine Bestellung für dieses Teil auf. Wir müssen also die Tabelle zerlegen, damit sie 3NF wie folgt folgt.

Bestellung (Order#, Part, Supplier, QtyOrdered) und Price Master (Part, Supplier, UnitPrice).

Jetzt sind keine transitiven Abhängigkeiten mehr vorhanden. Die Beziehung ist in 3NF.

Lesen Sie auch: SQL für Data Science

Lernen Sie Softwarekurse online von den besten Universitäten der Welt. Verdienen Sie Executive PG-Programme, Advanced Certificate-Programme oder Master-Programme, um Ihre Karriere zu beschleunigen.

Fazit

Es gibt mehr zur Normalisierung, wie BCNF, 4NF, 5NF und 6NF. Kurz gesagt, BCNF ist nichts anderes als eine Erweiterung von 3NF, da die letzte Regel von 3NF hier nicht gilt. Alle funktionalen Abhängigkeiten müssen die Schlüsselattribute auf der linken Seite und keine auf der rechten Seite haben. (BCNF wird auch 3.5NF genannt). Normalformen ab 4NF werden in der Regelpraxis jedoch kaum umgesetzt.

Wenn Sie mehr über Full-Stack-Entwicklung erfahren möchten, schauen Sie sich das Executive PG-Programm in Full-Stack-Softwareentwicklung von upGrad & IIIT-B an, das für Berufstätige konzipiert ist und mehr als 500 Stunden strenge Schulungen, mehr als 9 Projekte, und Aufgaben, IIIT-B-Alumni-Status, praktische praktische Abschlussprojekte und Arbeitsunterstützung bei Top-Unternehmen.