Normalformen im Datenbankdesign verstehen: Ein umfassender Leitfaden

Verschiedene Normalformen im Datenbankdesign

Im Datenbankdesign ist Normalisierung der Prozess der Organisation von Daten, um Redundanz und Abhängigkeit zu minimieren und die Datenintegrität zu verbessern. Der Prozess umfasst die Aufteilung großer Tabellen in kleinere, überschaubare Tabellen und die Herstellung von Beziehungen zwischen ihnen. Dadurch wird sichergestellt, dass die Datenbank frei von Anomalien wie Einfüge-, Aktualisierungs- und Löschanomalien ist.

Die verschiedenen Normalformen repräsentieren bestimmte Normalisierungsgrade. Jede Normalform baut auf der vorherigen auf und hat ihre eigenen Regeln. Nachfolgend finden Sie eine Erklärung der häufigsten Normalformen:

---

1. Erste Normalform (1NF)

1NF ist die grundlegendste Ebene der Normalisierung. Sie konzentriert sich auf die Eliminierung doppelter Daten und stellt sicher, dass die Daten in einer Tabelle so organisiert sind, dass jede Spalte atomare Werte enthält (keine sich wiederholenden Gruppen).

• Regeln von 1NF:
  1. Jede Tabellenzelle sollte einen einzelnen Wert (Atomizität) enthalten.
  2. Jeder Datensatz (Zeile) muss eindeutig sein.
  3. Jede Spalte sollte Werte eines einzelnen Typs enthalten (z. B. alle Ganzzahlen, alle Zeichenfolgen).
  4. Keine sich wiederholenden Spaltengruppen oder mehrere Werte in einer einzelnen Spalte.

Beispiel für 1NF:

Vor 1NF:

OrderID	Products	Quantities
1	Apple, Banana	2, 3
2	Orange	5

---

Nach der Konvertierung in 1NF:

OrderID	Product	Quantity
1	Apple	2
1	Banana	3
2	Orange	5

---

2. Zweite Normalform (2NF)

2NF baut auf 1NF auf, indem es partielle Abhängigkeiten eliminiert. Eine teilweise Abhängigkeit liegt vor, wenn ein Nicht-Primärattribut (eine Spalte, die nicht Teil des Primärschlüssels ist) nur von einem Teil des Primärschlüssels abhängig ist (im Fall zusammengesetzter Primärschlüssel). Um 2NF zu erreichen, muss der Tisch zunächst die Anforderungen von 1NF erfüllen.

• Regeln von 2NF:
  1. Die Tabelle muss in 1NF sein.
  2. Jedes Nicht-Primär-Attribut muss voll funktionsfähig vom gesamten Primärschlüssel abhängig sein (partielle Abhängigkeiten eliminieren).

Beispiel für 2NF:

Vor 2NF (partielle Abhängigkeit):

OrderID	Product	CustomerName	Price
1	Apple	John	10
1	Banana	John	5
2	Orange	Jane	8

---

Hier hängt CustomerName nur von der OrderID und nicht vom vollständigen Primärschlüssel (OrderID, Produkt) ab. Um dies zu beseitigen, teilen wir die Tabelle.

Nach 2NF:
Tabellen:

• Bestellungen (OrderID, CustomerName)
• Bestelldetails (Bestell-ID, Produkt, Preis)

Bestelltabelle:

OrderID	CustomerName
1	John
2	Jane

---

OrderDetails-Tabelle:

OrderID	Product	Price
1	Apple	10
1	Banana	5
2	Orange	8

---

3. Dritte Normalform (3NF)

3NF baut auf 2NF auf und befasst sich mit transitiven Abhängigkeiten, die auftreten, wenn ein Nicht-Primärattribut von einem anderen Nicht-Primärattribut abhängt. Ein Nicht-Primär-Attribut sollte nur vom Primärschlüssel abhängen. Eine Tabelle ist in 3NF, wenn sie in 2NF ist und alle transitiven Abhängigkeiten entfernt sind.

• Regeln von 3NF:
  1. Die Tabelle muss in 2NF sein.
  2. Kein Nicht-Prime-Attribut sollte von einem anderen Nicht-Prime-Attribut abhängen (transitive Abhängigkeiten entfernen).

Beispiel für 3NF:

Vor 3NF (Transitive Abhängigkeit):

OrderID	Product	Category	Supplier
1	Apple	Fruit	XYZ
2	Carrot	Vegetable	ABC

---

Hier hängt Lieferant von der Kategorie ab, nicht direkt von der Bestell-ID. Um dieses Problem zu lösen, teilen wir die Tabelle.

Nach 3NF:
Tabellen:

• Bestellungen (Bestell-ID, Produkt, Kategorie)
• Kategorie (Kategorie, Lieferant)

Bestelltabelle:

OrderID	Product	Category
1	Apple	Fruit
2	Carrot	Vegetable

---

Kategorietabelle:

Category	Supplier
Fruit	XYZ
Vegetable	ABC

---

4. Boyce-Codd-Normalform (BCNF)

BCNF ist eine strengere Version von 3NF. Eine Tabelle ist in BCNF, wenn:

• Es ist in 3NF.
• Für jede funktionale Abhängigkeit muss die linke Seite ein Kandidatenschlüssel sein (d. h. ein minimaler Superschlüssel).

Einfacher ausgedrückt befasst sich BCNF mit Situationen, in denen sich eine Tabelle in 3NF befindet, aber dennoch einige Abhängigkeiten aufweist, die Attribute beinhalten, die keine Kandidatenschlüssel sind.

• BCNF-Regeln:
  1. Die Tabelle muss in 3NF vorliegen.
  2. Jede Determinante muss ein Kandidatenschlüssel sein.

Beispiel für BCNF:

Vor BCNF:

CourseID	Instructor	Room
101	Dr. Smith	A1
102	Dr. Smith	B1
101	Dr. Johnson	A2

---

Hier bestimmt Instructor Raum, aber Instructor ist kein Kandidatenschlüssel, was gegen BCNF verstößt. Um BCNF zu erreichen, trennen wir die Abhängigkeiten in verschiedene Tabellen.

Nach BCNF:
Tabellen:

• Kurse (Kurs-ID, Dozent)
• Räume (Lehrer, Raum)

Kurstabelle:

CourseID	Instructor
101	Dr. Smith
102	Dr. Smith
101	Dr. Johnson

---

Zimmertabelle:

Instructor	Room
Dr. Smith	A1
Dr. Smith	B1
Dr. Johnson	A2

---

5. Vierte Normalform (4NF)

4NF befasst sich mit mehrwertigen Abhängigkeiten, die auftreten, wenn ein Attribut mehrere Werte eines anderen Attributs bestimmt und diese Werte unabhängig voneinander sind. Eine Tabelle ist in 4NF, wenn:

• Es ist in BCNF.
• Es gibt keine mehrwertigen Abhängigkeiten.

Beispiel für 4NF:

Vor 4NF (mehrwertige Abhängigkeit):

StudentID	Subject	Hobby
1	Math	Painting
1	Science	Cycling

---

Nach 4NF:
Tabellen:

• Studenten (Studenten-ID, Fach)
• StudentsHobbies (Studentenausweis, Hobby)

Schülertisch:

StudentID	Subject
1	Math
1	Science

---

Tabelle „StudentenHobbys“:

StudentID	Hobby
1	Painting
1	Cycling

---

Fazit

Im Datenbankdesign ist die Normalisierung ein grundlegender Prozess zur effizienten Organisation von Daten. Die verschiedenen Normalformen – 1NF, 2NF, 3NF, BCNF und 4NF – stellen sicher, dass Daten ohne Redundanz gespeichert werden, die Integrität gewahrt bleibt und einfach zu verwalten ist. Jede Normalform baut auf der vorherigen auf, indem sie bestimmte Arten von Abhängigkeiten oder Anomalien beseitigt. Während die Normalisierung die Datenqualität verbessert, ist es wichtig, sie mit Leistungsaspekten in Einklang zu bringen und sich manchmal für die Denormalisierung zu entscheiden, wenn dies zur Optimierung erforderlich ist.

Hallo, ich bin Abhay Singh Kathayat!
Ich bin ein Full-Stack-Entwickler mit Fachwissen sowohl in Front-End- als auch in Back-End-Technologien. Ich arbeite mit einer Vielzahl von Programmiersprachen und Frameworks, um effiziente, skalierbare und benutzerfreundliche Anwendungen zu erstellen.
Sie können mich gerne unter meiner geschäftlichen E-Mail-Adresse erreichen: kaashshorts28@gmail.com.

Das obige ist der detaillierte Inhalt vonNormalformen im Datenbankdesign verstehen: Ein umfassender Leitfaden. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!