Die Regel für die 1NF besagt, dass Ihre Tabellen von Anfang an richtig strukturiert sein müssen, wie bei einer sauberen Tabelle.

Regel: Jede Spalte muss einen eindeutigen Namen haben und jede Zelle darf nur einen einzigen, unteilbaren Wert enthalten.

Gelöstes Problem: Es kann keine Liste von Elementen in eine einzelne Zelle eingefügt werden. In einer Tabelle mit Bestellungen können Sie beispielsweise nicht „Milch, Eier, Brot“ in einer Zelle unter der Spalte „Bestellte Produkte“ auflisten. Stattdessen muss jedes Produkt eine eigene Zeile erhalten, damit die Daten durchsuchbar und verwaltbar sind.

Die 2NF-Regel gilt nur, wenn Ihre Tabelle einen zusammengesetzten Schlüssel verwendet – einen Primärschlüssel, der aus zwei oder mehr kombinierten Spalten besteht (z. B. eine Bestell-ID plus eine Produkt-ID). Ein Primärschlüssel ist die Spalte oder eine Gruppe von Spalten, deren Werte jede Zeile in einer Tabelle eindeutig identifizieren. Eine Nicht-Schlüsselspalte ist eine Spalte, die nicht Teil des Primärschlüssels ist.

Regel: Eine Tabelle muss bereits in 1NF sein und alle Nicht-Schlüsselspalten müssen vom gesamten zusammengesetzten Schlüssel abhängen, nicht nur von einem Teil davon.

Gelöstes Problem: Daten sollten nur dort gespeichert werden, wo sie hingehören. Wenn Sie eine Tabelle haben, in der der Schlüssel (OrderID, ProductID) lautet, sollte diese keine Spalten wie „Produktpreis“ enthalten, da der Preis nur von der ProductID und nicht von der OrderID abhängt. Die Lösung besteht darin, die ProduktID und den Produktpreis in eine separate Tabelle „Produkte“ zu verschieben, wobei die ProduktID der einzige Primärschlüssel ist. So wird der Preis des Produkts nicht unnötig für jede Bestellung wiederholt, die das relevante Produkt enthält.

Die 3NF-Regel ist das häufigste Ziel für das Datenbankdesign und will indirekte Beziehungen zwischen Datenpunkten entfernen.

Regel: Eine Tabelle muss in 2NF sein und Nicht-Schlüsselspalten dürfen nur vom Primärschlüssel abhängen, nicht von einer anderen Nicht-Schlüsselspalte.

Gelöstes Problem: Es muss vermieden werden, dass ein nicht-Schlüssel-Datenelement den Wert eines anderen nicht-Schlüssel-Datenelements bestimmt. Nehmen wir eine Tabelle „Angestellte“ an, in der eine Büro-ID (eine Nicht-Schlüsselspalte) und der Standort des Büros (eine weitere Nicht-Schlüsselspalte) gespeichert sind. Der Bürostandort wird durch die Büro-ID bestimmt, nicht durch die Mitarbeiter-ID (der Primärschlüssel der Tabelle). Diese indirekte Verknüpfung ist eine transitive Abhängigkeit. Um das zu vermeiden erstellen Sie eine neue Tabelle „Büros“, die nur die Büro-ID und den Bürostandort enthält, und verknüpfen die beiden Tabellen über die Büro-ID. So müssen Sie den Standort des Büros nur an einer Stelle aktualisieren, falls er sich einmal ändert.