Die Normalformen für relationale Datenbanksysteme sollen dabei helfen, ein gutes Datenmodell zu erstellen. Das Ziel ist es, eine konsistente Datenhaltung zu ermöglichen mit so wenig Redundanzen wie möglich. Die Normalisierung hilft also dabei, die Wartbarkeit und die Performance der Datenbank zu verbessern, ist jedoch keine Pflicht.
Die Normalformen für relationale Datenbanksysteme wurden ursprünglich von Edgar F. Codd entworfen. Anfangs hatte dieser 3 Normalformen entwickelt, die aufeinander aufbauen. Wenn also die 2. Normalform erfüllt ist, so muss die 1. Normalform auch erfüllt sein. Inzwischen wurden noch 2 weitere Normalformen ergänzt, die im Folgenden nun erläutert werden.
Erste Normalform
Eine Relation ist in der ersten Normalform, wenn diese Atomar ist. Dass bedeutet, dass ein Wert sich nicht weiter unterteilen lässt, daher sind für die erste Normalform keine mengenwertige Attribute zugelassen.
Folgendes ist somit nicht in der ersten Normalform:
| Vater | Mutter | Kinder |
| Berd | Maria | Elli, Gustav |
| Hugo | Berta | Tilo, Lukas |
Wenn wir diese Relation nun in die erste Normalform bringen wollen, müssen wir die Einträge trennen:
| Vater | Mutter | Kind |
| Berd | Maria | Elli |
| Berd | Maria | Gustav |
| Hugo | Berta | Tilo |
| Hugo | Berta | Lukas |
Zweite Normalform
Die zweite Normalform liegt vor, wenn die erste Normalform vorliegt und jedes Nichtschlüsselattribut voll funktional abhängig vom Primärschlüssel ist. Was das bedeutet, werden wir am folgenden Beispiel erläutern:
| Kundennummer | Name | Ort | Produktnummer | Marke | Name |
| 101 | Müller | Hannover | 555 | Samsung | Galaxy S10 |
| 102 | Hubert | Berlin | 784 | Apple | Iphone 11 |
Ein Schlüsselattribut ist eine eindeutige Kennung für einen Datensatz. Nehmen wir die Person Müller aus Hannover. Der Name Müller und der Ort Hannover sind nicht eindeutig einer Person zugeordnet, weshalb hier nun eine Kundennummer vergeben wird. Diese Kundennummer steht eindeutig für die Person und kann nur einmal auftreten.
In der obigen Tabelle sind die Schlüsselattribute unterstrichen und alle anderen sind Nichtschlüsselattribute. Hier können wir nun also schon erkennen, dass das Attribut Marke nicht funktional abhängig von der Kundennummer ist. Daher also nicht an diese Nummer gebunden ist und eigentlich nichts mit einer Person zu tun hat. Die obige Tabelle ist also nicht in der zweiten Normalform. Im Folgenden werden die Tabellen aufgeteilt, um die zweite Normalform herzustellen. Zuerst werden die Kunden von den Produkten isoliert und dann durch eine Rechnungstabelle den Bezug für den Kauf hergestellt.
| Kundennummer | Name | Ort |
| 101 | Müller | Hannover |
| 102 | Hubert | Berlin |
| Produktnummer | Marke | Name |
| 555 | Samsung | Galaxy S10 |
| 784 | Apple | Iphone 11 |
| Rechnr. | Kundennummer | Produktnummer |
| 1 | 101 | 555 |
| 2 | 102 | 784 |
Dritte Normalform
Wenn eine Datenbank in der dritten Normalform vorliegt, gilt sie als normalisiert. Diesen Zustand sollte jede Datenbank erfüllen, auch wenn es etwas mehr Arbeit bedeutet.
Eine Relation befindet sich in der dritten Normalform, wenn die zweite Normalform vorliegt und kein Nichtschlüsselattribut transitiv von einem Kandidatenschlüssel abhängt. Durch diese Normalisierung werden weitere Redundanzen entfernt. Folgende Tabelle befindet sich in der zweiten, aber nicht in der dritten Normalform:
| Kundennummer | Name | Alter | Postleitzahl | Ortsname |
| 101 | Müller | 42 | 30163 | Hannover |
Hier ist der Ortsname abhängig von der Postleitzahl. Name, Alter und Postleitzahl von der Kundennummer. Somit ist der Ortsname transitiv abhängig von einem Schlüsselkandidaten. Daher müsste es wiefolgt aussehen:
| Kundennummer | Name | Alter | Postleitzahl |
| 101 | Müller | 42 | 30163 |
| Postleitzahl | Ortsname |
| 30163 | Hannover |
Nun haben wir die drei wichtigsten Normalformen durchgesprochen. Für weiterführende Informationen, solltet ihr euch die Boyce Codd Normalform anschauen. Sie ist eine Erweiterung dieser drei Normalformen. Für weitere Informationen über Datenbanken, könnt ihr hier vorbeischauen.