Normalisierung

Die Grundlage eines sauberen Designs

Die Normalisierung ist ein systematischer Prozess zur Strukturierung von Datenbanken, um Redundanzen zu vermeiden und die Datenkonsistenz zu gewährleisten. Sie erfolgt in mehreren Schritten, den sogenannten Normalformen (NF). Für die meisten Anwendungen ist die dritte Normalform (3NF) ausreichend und stellt einen guten Kompromiss zwischen Struktur und Performance dar.

Wir entwickeln das Prinzip an einem Gegenbeispiel: einer unnormalisierten Tabelle für Bestellungen.

Ausgangstabelle – Eine Problemstruktur

Betrachten Sie die folgende Tabelle, die alle Informationen zu Bestellungen in einer einzigen Tabelle speichert:

Diese Struktur weist mehrere Probleme auf:

• Redundanz: Kundendaten (Name, Email) wiederholen sich bei jeder Bestellung.
• Anomalien: Bei einer Adressänderung müssten mehrere Zeilen aktualisiert werden.
• Löschprobleme: Würde der letzte Bestelleintrag eines Kunden gelöscht, gingen alle Kundendaten verloren.

Erste Normalform (1NF)

Die erste Normalform fordert:

• Jede Spalte enthält nur atomare (unteilbare) Werte.
• Jede Zeile ist eindeutig identifizierbar (Primärschlüssel).
• Es gibt keine wiederholenden Gruppen oder Arrays.

Unsere Tabelle verletzt die 1NF bereits nicht, da alle Werte atomar sind und der Primärschlüssel über (bestellung_id, produkt) gebildet werden könnte. Das eigentliche Problem liegt tiefer.

Zweite Normalform (2NF)

Die zweite Normalform baut auf der 1NF auf und fordert zusätzlich: Alle Nicht-Schlüsselattribute müssen vom gesamten Primärschlüssel abhängen, nicht nur von einem Teil (bei zusammengesetzten Primärschlüsseln).

In unserer Tabelle hängen kunde und kunde_email nur von bestellung_id ab, nicht vom Produkt. Sie gehören daher nicht in diese Tabelle.

Lösung: Wir extrahieren die Kundendaten in eine eigene Tabelle.

CREATE TABLE kunden_2nf (
    id INT PRIMARY KEY,
    name VARCHAR(100),
    email VARCHAR(255)
);

CREATE TABLE bestellungen_2nf (
    id INT PRIMARY KEY,
    kunden_id INT,
    FOREIGN KEY (kunden_id) REFERENCES kunden_2nf(id)
);

CREATE TABLE positionen_2nf (
    bestellung_id INT,
    produkt VARCHAR(100),
    menge INT,
    preis DECIMAL(10,2),
    PRIMARY KEY (bestellung_id, produkt),
    FOREIGN KEY (bestellung_id) REFERENCES bestellungen_2nf(id)
);

CREATE TABLE kunden_2nf (
    id INT PRIMARY KEY,
    name VARCHAR(100),
    email VARCHAR(255)
);

CREATE TABLE bestellungen_2nf (
    id INT PRIMARY KEY,
    kunden_id INT,
    FOREIGN KEY (kunden_id) REFERENCES kunden_2nf(id)
);

CREATE TABLE positionen_2nf (
    bestellung_id INT,
    produkt VARCHAR(100),
    menge INT,
    preis DECIMAL(10,2),
    PRIMARY KEY (bestellung_id, produkt),
    FOREIGN KEY (bestellung_id) REFERENCES bestellungen_2nf(id)
);

Dritte Normalform (3NF)

Die dritte Normalform baut auf der 2NF auf und fordert: Alle Nicht-Schlüsselattribute müssen direkt vom Primärschlüssel abhängen, nicht transitiv über andere Nicht-Schlüsselattribute.

In der Tabelle positionen_2nf haben wir ein Problem: Der preis hängt vom produkt ab, nicht direkt von der bestellung_id. Wird der Preis eines Produkts geändert, müssten wir alle Positionen aktualisieren.

Lösung: Wir extrahieren die Produkte in eine eigene Tabelle.

CREATE TABLE produkte_3nf (
    id INT PRIMARY KEY,
    name VARCHAR(100),
    preis DECIMAL(10,2)
);

CREATE TABLE positionen_3nf (
    id INT PRIMARY KEY,
    bestellung_id INT,
    produkt_id INT,
    menge INT,
    einzelpreis DECIMAL(10,2), -- Der Preis zum Zeitpunkt der Bestellung (Historisierung)
    FOREIGN KEY (bestellung_id) REFERENCES bestellungen_2nf(id),
    FOREIGN KEY (produkt_id) REFERENCES produkte_3nf(id)
);

CREATE TABLE produkte_3nf (
    id INT PRIMARY KEY,
    name VARCHAR(100),
    preis DECIMAL(10,2)
);

CREATE TABLE positionen_3nf (
    id INT PRIMARY KEY,
    bestellung_id INT,
    produkt_id INT,
    menge INT,
    einzelpreis DECIMAL(10,2), -- Der Preis zum Zeitpunkt der Bestellung (Historisierung)
    FOREIGN KEY (bestellung_id) REFERENCES bestellungen_2nf(id),
    FOREIGN KEY (produkt_id) REFERENCES produkte_3nf(id)
);

Dies ist genau die Struktur, die wir in unserem bestellsystem verwendet haben. Sie entspricht der dritten Normalform und ist ein solides Design für eine transaktionale Anwendung.

ER-Diagramme – Datenbanken visualisieren

Ein Entity-Relationship-Diagramm (ER-Diagramm) ist eine grafische Darstellung der Datenbankstruktur. Es zeigt die Entitäten (Tabellen), ihre Attribute (Spalten) und die Beziehungen zwischen ihnen. ER-Diagramme sind in der Praxis unverzichtbar für die Kommunikation im Team, die Dokumentation und die Planung vor der Implementierung.

Notationselemente

• Entität: Ein Rechteck, das eine Tabelle repräsentiert (z. B. Kunde, Bestellung).
• Attribut: Eine Ellipse, die eine Spalte repräsentiert. Primärschlüssel werden unterstrichen.
• Beziehung: Eine Raute, die die Verbindung zwischen Entitäten beschreibt.
• Kardinalität: Gibt die Beziehungszahl an (1:n, n:m, 1:1).

Praktische Erstellung mit phpMyAdmin

phpMyAdmin bietet eine integrierte Funktion zur Visualisierung von ER-Diagrammen.

1. Öffnen Sie phpMyAdmin und wählen Sie Ihre Datenbank bestellsystem.
2. Klicken Sie auf den Reiter Mehr und dann auf Designer (oder Relationen anzeigen, je nach Version).
3. Sie sehen eine grafische Darstellung Ihrer Tabellen und der Fremdschlüsselbeziehungen.

Alternativ können Sie ein ER-Diagramm auch über die SQL-Abfrage mit Tools wie mysqldump oder externen Programmen wie DBeaver (das wir später ansprechen) generieren.

Für die Dokumentation Ihrer eigenen Projekte empfiehlt es sich, ein ER-Diagramm zu zeichnen – sei es auf Papier, mit Zeichentools oder direkt in der Entwicklungsumgebung.