Wann man die Regeln brechen sollte: Datenbanknormalisierung in der Praxis

Die drei Normalformen sind die grundlegendsten Designprinzipien in der Datenbankmodellierung. Was genau sind also die drei Normalformen? Und müssen wir uns in der realen Entwicklung strikt daran halten? In diesem Artikel wollen wir dieses Thema eingehend erörtern.

Die drei Normalformen

1. Erste Normalform (1NF: Sicherstellung der Atomarität in jeder Spalte)

Die erste Normalform erfordert, dass jedes Feld (jede Spalte) in jeder Tabelle atomar sein muss, d. h. die Werte in jedem Feld dürfen nicht weiter unterteilt werden. Mit anderen Worten, jedes Feld darf nur einen einzigen Wert speichern – es darf keine Mengen, Arrays oder sich wiederholende Gruppen enthalten.

Betrachten Sie zum Beispiel die folgende Schülertabelle:

In dieser Tabelle enthält das Feld 'Telefonnummer' mehrere Nummern, was gegen die Anforderung der 1NF nach Atomarität verstößt. Um die 1NF zu erfüllen, sollten Telefonnummern in einzelne Datensätze aufgeteilt oder in eine neue Tabelle verschoben werden.

Design nach Erfüllung der 1NF:

Schülertabelle

Telefontabelle

2. Zweite Normalform (2NF: Jede Spalte muss von dem gesamten Primärschlüssel abhängen)

Die zweite Normalform erfordert, dass die Tabelle bereits die 1NF erfüllt und partielle Abhängigkeiten eliminiert – Felder, die keine Primärschlüssel sind, müssen von dem gesamten Primärschlüssel abhängen, nicht nur von einem Teil davon. Dies gilt typischerweise für Tabellen mit zusammengesetzten Primärschlüsseln.

Betrachten Sie zum Beispiel die folgende Tabelle 'Bestelldetails':

In dieser Tabelle ist der zusammengesetzte Primärschlüssel (Bestell-ID, Produkt-ID). Der Produktname und der Einzelpreis hängen nur von der Produkt-ID ab, nicht vom gesamten Primärschlüssel, was zu einer partiellen Abhängigkeit führt – was gegen die 2NF verstößt.

Design nach Erfüllung der 2NF:

Bestelldetailtabelle

Produkttabelle

3. Dritte Normalform (3NF: Eliminierung transitiver Abhängigkeiten)

Die dritte Normalform erfordert, dass die Tabelle bereits die 2NF erfüllt und transitive Abhängigkeiten eliminiert – Felder, die keine Primärschlüssel sind, sollen nicht von anderen Feldern abhängen, die keine Primärschlüssel sind. Mit anderen Worten, jedes Feld, das kein Primärschlüssel ist, muss direkt von dem Primärschlüssel abhängen, nicht indirekt über ein anderes Feld, das kein Primärschlüssel ist.

Betrachten Sie zum Beispiel die folgende Mitarbeitertabelle:

In dieser Tabelle hängt der Abteilungsname von der Abteilungs-ID ab, die wiederum von dem Primärschlüssel (Mitarbeiter-ID) abhängt, wodurch eine transitive Abhängigkeit entsteht – die gegen die 3NF verstößt.

Design nach Erfüllung der 3NF:

Mitarbeitertabelle

Abteilungstabelle

Durch das Verschieben der Abteilungsinformationen in eine separate Tabelle wird die transitive Abhängigkeit eliminiert und die Datenbankstruktur entspricht der dritten Normalform.

Zusammenfassend lässt sich sagen, dass die drei Normalformen sind:

• 1NF: Sicherstellen, dass jedes Feld atomare Werte enthält.
• 2NF: Eliminieren von partiellen Abhängigkeiten – jedes Nicht-Schlüsselfeld muss von dem gesamten Primärschlüssel abhängen.
• 3NF: Eliminieren von transitiven Abhängigkeiten – Nicht-Schlüsselfelder sollen nur von dem Primärschlüssel abhängen.

Verletzung der drei Normalformen

In der Praxis verbessert die Befolgung der drei Normalformen (1NF, 2NF, 3NF) zwar die Datenkonsistenz und reduziert Redundanz, aber es gibt Fälle, in denen die Verletzung dieser Normalformen von Vorteil sein kann – um die Leistung zu verbessern, das Design zu vereinfachen oder spezifische Geschäftsanforderungen zu erfüllen.

Im Folgenden sind gängige Gründe und Beispiele für die absichtliche Verletzung von Normalformen aufgeführt:

Leistungsoptimierung

In Anwendungen mit hoher Parallelität und großem Umfang kann die strikte Befolgung der Normalformen zu häufigen Join-Operationen führen, was die Abfragezeit und die Systemlast erhöhen kann. Um die Leistung zu verbessern, können Designer Daten denormalisieren, um Joins zu reduzieren.

In einem E-Commerce-System mit Ordersund Users-Tabellen würde ein striktes 3NF-Design beispielsweise nur die User IDin der Orders-Tabelle speichern und einen Join erfordern, um Benutzerdetails abzurufen.

Um die Abfrageleistung zu verbessern, könnten wir den Benutzernamen und die Adresse redundant in der Orders-Tabelle speichern, um einen Join mit der Users-Tabelle zu vermeiden.

Design nach Verletzung der 3NF:

Vereinfachung von Abfragen und Entwicklung

Eine strikte Normalisierung kann zu komplexen Datenbankschemata führen, was die Entwicklung und Wartung erschwert. Um die Logik zu vereinfachen und den Entwicklungsaufwand zu reduzieren, kann eine angemessene Redundanz eingeführt werden.

In einem Content-Management-System (CMS) sind beispielsweise die Tabellen Articlesund Categoriesin der Regel getrennt. Wenn Kategorienamen häufig mit Artikeln abgefragt werden, erhöht ein Join die Komplexität. Das Speichern des Kategorienamens direkt in der Articles-Tabelle vereinfacht die Frontend-Logik.

Design nach Verletzung der 3NF:

Berichterstattung und Data Warehousing

In Data Warehouses und Berichtssystemen sind schnelle Lesevorgänge und Aggregationen von entscheidender Bedeutung. Um die Leistung zu optimieren, werden häufig denormalisierte Strukturen verwendet, wie z. B. Stern- oder Schneeflockenschemata – die nicht mit strikten Normalformen übereinstimmen.

Beispielsweise könnte ein Verkaufs-Data-Warehouse eine Faktentabelle enthalten, die Dimensionsdaten für eine schnelle Berichtgenerierung enthält.

Design nach Verletzung der 3NF:

Hier vermeidet das direkte Speichern von Produktname und Kategorie Joins mit Dimensionstabellen, was die Effizienz der Berichtgenerierung erhöht.

Besondere Geschäftsanforderungen

Einige Geschäftsszenarien erfordern schnelle Antworten für bestimmte Abfragen oder Operationen. Eine angemessene Redundanz hilft, diese Anforderungen zu erfüllen.

Um beispielsweise in einem Echtzeit-Handelssystem schnell Kontostände zu berechnen, könnten wir den aktuellen Saldo in der Users-Tabelle speichern, anstatt ihn zur Laufzeit aus Transaktionsdatensätzen zu berechnen.

Design nach Verletzung der 3NF:

Obwohl Transaktionsdetails woanders gespeichert werden, vermeidet die Pflege eines Aktuellen Saldos in der Benutzertabelle kostspielige Laufzeitberechnungen.

Ausbalancieren von Lese- und Schreibleistung

In Systemen, in denen Lesevorgänge Schreibvorgänge deutlich überwiegen, wird Redundanz manchmal akzeptiert, um die Leseleistung zu verbessern – auch wenn dies die Schreibkomplexität erhöht.

Beispielsweise zeigen Social-Media-Plattformen die Anzahl der Freunde eines Benutzers auf seinem Profil an. Dies jedes Mal zu berechnen ist ineffizient. Stattdessen wird die Anzahl der Freunde direkt in der Users-Tabelle gespeichert.

Design nach Verletzung der 3NF:

Dies ermöglicht eine schnelle Anzeige ohne Echtzeitberechnung.

Schnelle Iteration und Flexibilität

Startups oder sich schnell entwickelnde Produkte benötigen oft flexible und schnell anpassbare Datenbanken. Übermäßige Normalisierung kann Geschwindigkeit und Anpassungsfähigkeit behindern. Redundantes Design kann die Entwicklungsgeschwindigkeit und Agilität verbessern.

Beispielsweise könnten in einer E-Commerce-Plattform in der Frühphase Versandadressen direkt in der Orders-Tabelle gespeichert werden, anstatt eine separate Addresses-Tabelle zu verwenden.

Design nach Verletzung der 3NF:

Dies vereinfacht die Entwicklung und unterstützt eine schnelle Produkteinführung. Die Normalisierung kann später bei Bedarf angewendet werden.

Reduzierung der Komplexität und Verbesserung der Verständlichkeit

Übermäßige Normalisierung kann ein Schema schwer verständlich und wartbar machen. Mäßige Redundanz kann das Design vereinfachen und das Verständnis und die Kommunikation im Team verbessern.

Beispielsweise kann in einem Schulverwaltungssystem das Aufteilen von Klasseninformationen auf mehrere Tabellen verwirrend sein. Um dies zu vereinfachen, können der Klassenname und der Klassenlehrer direkt in der Students-Tabelle gespeichert werden.

Design nach Verletzung der 3NF:

Durch das direkte Speichern von Klassennameund Klassenlehrerwird die Anzahl der Tabellen reduziert und das Design vereinfacht.

Zusammenfassung

In diesem Artikel haben wir die drei Normalformen des Datenbankdesigns anhand von Beispielen analysiert. Sie dienen als grundlegende Prinzipien für den Entwurf relationaler Datenbanken. In realen Projekten halten wir uns jedoch aufgrund von Leistungsbedürfnissen, vereinfachtem Design, schneller Iteration oder spezifischer Geschäftslogik oft nicht strikt daran.

Letztendlich ist die Systemarchitektur ein Kompromiss – zwischen Geschäftsanforderungen, Datenkonsistenz, Leistung und Entwicklungseffizienz. Wir müssen praktische Designentscheidungen basierend auf unserem Anwendungskontext treffen.

---

Wir sind Leapcell, Ihre erste Wahl für das Hosten von Backend-Projekten.

Leapcell ist die Serverless-Plattform der nächsten Generation für Webhosting, asynchrone Aufgaben und Redis:

Multi-Sprachen-Unterstützung

• Entwickeln Sie mit Node.js, Python, Go oder Rust.

Stellen Sie unbegrenzt viele Projekte kostenlos bereit

• zahlen Sie nur für die Nutzung – keine Anfragen, keine Gebühren.

Unschlagbare Kosteneffizienz

• Pay-as-you-go ohne Leerlaufgebühren.
• Beispiel: 25 US-Dollar unterstützen 6,94 Millionen Anfragen bei einer durchschnittlichen Antwortzeit von 60 ms.

Optimierte Entwicklererfahrung

• Intuitive Benutzeroberfläche für mühelose Einrichtung.
• Vollständig automatisierte CI/CD-Pipelines und GitOps-Integration.
• Echtzeitmetriken und -protokollierung für umsetzbare Erkenntnisse.

Mühelose Skalierbarkeit und hohe Leistung

• Automatische Skalierung zur einfachen Bewältigung hoher Parallelität.
• Kein Betriebsaufwand – konzentrieren Sie sich einfach auf den Aufbau.

Erkunden Sie mehr in der Dokumentation!

Folgen Sie uns auf X: @LeapcellHQ