Heute schauen wir uns nochmal – diesmal ausführlicher – das wichtige Thema an: Vorteile und Nachteile der Normalisierung, damit du besser verstehst, wie diese Konzepte im echten Leben angewendet werden. Also, anschnallen – los geht’s!
Beseitigung von Daten-Redundanz
Wenn Daten in einer Tabelle nicht normalisiert sind, kann es passieren, dass dieselbe Info in mehreren Zeilen doppelt vorkommt. Zum Beispiel kann in einer Bestellungen-Tabelle die Kundenadresse für jede Bestellung wiederholt werden. Normalisierung beseitigt solche Dopplungen, indem gemeinsame Daten in eigene Tabellen ausgelagert werden.
Beispiel:
-- Vor der Normalisierung
CREATE TABLE orders (
order_id SERIAL PRIMARY KEY,
customer_name TEXT,
customer_address TEXT,
order_date DATE
);
-- Nach der Normalisierung
CREATE TABLE customers (
customer_id SERIAL PRIMARY KEY,
customer_name TEXT,
customer_address TEXT
);
CREATE TABLE orders (
order_id SERIAL PRIMARY KEY,
customer_id INT REFERENCES customers(customer_id),
order_date DATE
);
Warum ist das wichtig? Weniger doppelte Daten heißt weniger Fehlerquellen. Wenn sich die Adresse eines Kunden ändert, musst du die Info nur an einer Stelle updaten.
Sicherstellung der Daten-Integrität
Wenn Daten auf logische Tabellen verteilt sind, lassen sich deren Beziehungen easy verwalten. Mit Foreign Keys bleibt die Daten-Integrität automatisch erhalten. Zum Beispiel kannst du nicht aus Versehen einen Kunden löschen, auf den sich noch Bestellungen beziehen.
Beispiel:
-- Der Foreign Key sorgt dafür, dass beim Löschen eines Kunden auch die zugehörigen Bestellungen gelöscht werden
ALTER TABLE orders
ADD CONSTRAINT fk_customer FOREIGN KEY (customer_id)
REFERENCES customers(customer_id)
ON DELETE CASCADE;
Du kannst dir sicher sein, dass die DB-Struktur keine "verwaisten" Daten zulässt.
Updates werden einfacher
Wenn deine Datenbank normalisiert ist, werden Updates easy und weniger fehleranfällig. Zurück zum Kunden-Beispiel – wenn ein Kunde seine Adresse ändert, aktualisierst du den Eintrag nur in einer Tabelle. In nicht-normalisierten Tabellen vergisst du vielleicht, die Adresse in manchen Zeilen zu ändern, was zu Inkonsistenzen führt.
Minimierung von Anomalien
Insert-Anomalien: In einer nicht-normalisierten Tabelle kann es passieren, dass du keinen Datensatz hinzufügen kannst, ohne unnötige Infos anzugeben. Zum Beispiel kannst du keine Bestellung anlegen, solange du den Kundennamen nicht kennst.
Update-Anomalien: Beim Aktualisieren von Daten können Fehler auftreten. Zum Beispiel bleibt der Kundenname in einer Zeile alt, wenn du ihn nur in einer anderen Zeile änderst.
Delete-Anomalien: Das Löschen eines Datensatzes kann zum Verlust wichtiger Infos führen. Zum Beispiel verschwindet der Kundenname beim Löschen einer Bestellung, wenn alles in einer Tabelle gespeichert ist.
Reduzierung des Datenvolumens
Normalisierung verkleinert oft die Datenbankgröße, weil doppelte Daten wegfallen. Das ist gerade bei großen Datenmengen ein wichtiger Punkt.
Nachteile der Normalisierung
1. Komplexere Datenbank-Struktur
Mit der Zeit kann Normalisierung zu einer komplexen DB-Struktur mit tausenden(!) verknüpften Tabellen führen. Um Daten zu bekommen, die früher in einer Tabelle waren, brauchst du dann komplexe SQL-Queries mit mehreren JOINs.
Beispiel für Komplexität:
-- Query, um Infos zu Bestellungen mit Produkt- und Kategorie-Details zu bekommen
SELECT
o.order_id,
o.order_date,
c.customer_name,
p.product_name,
cat.category_name,
oi.quantity,
oi.unit_price
FROM orders o
JOIN customers c ON o.customer_id = c.customer_id
JOIN order_items oi ON o.order_id = oi.order_id
JOIN products p ON oi.product_id = p.product_id
JOIN categories cat ON p.category_id = cat.category_id;
Wenn die Zahl der Tabellen und Beziehungen steigt, kann die Query-Laufzeit deutlich zunehmen.
2. Performance-Einbußen bei häufigen Joins
Oft sind Joins (JOIN) ziemlich ressourcenhungrig, besonders wenn die Tabellen groß sind und keine Indizes haben. In Analytics-Systemen, wo Queries Millionen Zeilen verarbeiten, führt Normalisierung zu spürbaren Performance-Strafen.
3. Zusätzlicher Aufwand für Denormalisierung
Wenn eine normalisierte DB-Struktur für Analytics genutzt wird, muss sie oft temporär denormalisiert werden, um analytische Queries zu beschleunigen. Das kann das Anlegen von VIEWs oder Aggregations-Tabellen beinhalten.
Beispiel:
-- Denormalisierte View für Analytics
CREATE VIEW orders_with_customers AS
SELECT
o.order_id,
o.order_date,
c.customer_name,
c.customer_address
FROM
orders o
JOIN
customers c ON o.customer_id = c.customer_id;
4. Hohe Einstiegshürde
Für Einsteiger wirkt Normalisierung oft kompliziert. Statt einer Tabelle mit allen Daten musst du mit mehreren Tabellen und deren Beziehungen klarkommen. Das kann die Entwicklung verlangsamen, besonders wenn das Team noch nicht so fit in Datenbanken ist.
5. Manchmal ist Redundanz sogar praktisch
In echten Projekten ist es manchmal besser, redundante Daten zu behalten, um die Performance zu boosten. Wenn eine App oft Daten braucht, die nur durch komplexe Joins zu bekommen sind, ist es manchmal besser, sie direkt in einer Tabelle zu speichern.
GO TO FULL VERSION