Die erste Normalform (First Normal Form, 1NF) ist die erste Stufe der Datenbank-Normalisierung und stellt strenge Anforderungen an die Tabellenstruktur. Eine Tabelle ist in 1NF, wenn:
- Alle Daten sind atomar. Jeder Wert in einer Tabellenzelle muss unteilbar sein. Tschüss, "Listen in einer Zelle"! In einer Datenbank macht man sowas nicht.
- Jede Zeile ist eindeutig. Das heißt, die Tabelle braucht einen Primary Key oder einen eindeutigen Identifikator.
- Es gibt keine wiederholenden Datengruppen. Werte derselben Entität dürfen nicht in derselben Spalte mehrfach auftauchen.
Einfach gesagt: Stell dir vor, eine Datenbank-Tabelle ist dein Zimmer und atomare Werte sind einzelne Gegenstände: Lampe, Tisch, Buch. Wenn das Zimmer zugemüllt ist (zum Beispiel alles liegt in einem Haufen), findest du die Lampe nicht oder weißt nicht, ob du noch einen Ersatz-Tisch hast. Normalisierung hilft dir, "alles ordentlich ins Regal zu stellen".
Beispiel für einen 1NF-Verstoß
Stell dir vor, wir haben eine Studententabelle, in der wir Infos über die belegten Kurse speichern:
| student_id | name | courses |
|---|---|---|
| 1 | Maria | "Mathematik, Physik" |
| 2 | Rob | "Biologie, Chemie" |
Was ist an dieser Struktur schlecht? Die Kurse (Spalte courses) stehen als Komma-getrennte Liste in einer Zelle. Wenn wir jetzt z.B. alle Studierenden finden wollen, die Physik belegen, wird die Query zum Albtraum: Wir müssten komplizierte Textoperationen machen. Und wenn ein Student Physik aus der Liste löschen will – haben wir das nächste Problem. Solche Daten sind nicht atomar und verletzen damit die wichtigste Regel der 1NF.
Wie bringe ich die Tabelle in 1NF?
Um das Problem zu lösen, teilen wir die Daten auf einzelne Zeilen auf, sodass jeder Wert atomar ist:
| student_id | name | course |
|---|---|---|
| 1 | Maria | Mathematik |
| 1 | Maria | Physik |
| 2 | Rob | Biologie |
| 2 | Rob | Chemie |
Jetzt passt alles. Wir haben die Tabelle so umgebaut, dass jeder Wert in einer Zelle unteilbar ist. Das entspricht den Prinzipien der 1NF.
Ausführliches Beispiel für einen 1NF-Verstoß und die Korrektur
Nehmen wir an, wir haben eine Bestelltabelle eines Online-Shops:
| order_id | customer_name | items |
|---|---|---|
| 1001 | Otto Lin | "Notebook, Maus, Tastatur" |
| 1002 | Anna Song | "Smartphone, Hülle" |
Offensichtlich enthält items hier mehrere Werte als Komma-getrennte Liste, was gegen die 1NF verstößt.
Um die Daten in 1NF zu bringen, speichern wir jede Zeile für jeden Artikel in der Bestellung:
| order_id | customer_name | item |
|---|---|---|
| 1001 | Otto Lin | Notebook |
| 1001 | Otto Lin | Maus |
| 1001 | Otto Lin | Tastatur |
| 1002 | Anna Song | Smartphone |
| 1002 | Anna Song | Hülle |
Jetzt entspricht die Tabellenstruktur den Prinzipien der 1NF. Jede Bestellung und jeder Artikel sind als eigene Zeile gespeichert, und die Werte sind atomar.
Hinzufügen eines Primary Keys
Nach dem Umbau der Tabelle ist es wichtig, einen eindeutigen Identifikator (Primary Key) für jede Zeile hinzuzufügen, um die Eindeutigkeit zu garantieren. Im obigen Beispiel kann man die Kombination aus order_id und item als zusammengesetzten Primary Key nehmen. In der Praxis wird aber meistens ein eigenes Feld id angelegt.
| id | order_id | customer_name | item |
|---|---|---|---|
| 1 | 1001 | Otto Lin | Notebook |
| 2 | 1001 | Otto Lin | Maus |
| 3 | 1001 | Otto Lin | Tastatur |
| 4 | 1002 | Anna Song | Smartphone |
| 5 | 1002 | Anna Song | Hülle |
Praktische Aufgabe
Du hast eine Studententabelle mit Fächern, die sie belegen, alles in einer Zelle gespeichert:
| student_id | name | subjects |
|---|---|---|
| 1 | Polly | "Mathematik, Chemie" |
| 2 | Peter | "Physik, Informatik" |
Bring die Tabelle in eine Form, die der 1NF entspricht.
Nach der Umwandlung sollte die Tabelle so aussehen:
| student_id | name | subject |
|---|---|---|
| 1 | Polly | Mathematik |
| 1 | Polly | Chemie |
| 2 | Peter | Physik |
| 2 | Peter | Informatik |
Die häufigsten Fehler bei der Arbeit mit 1NF
Wenn du mit einer Datenbank arbeitest, können 1NF-Verstöße in folgenden Situationen auftreten:
- Speichern von Listen oder Arrays direkt in der Tabelle. Das ist der häufigste Fehler.
- Kein eindeutiger Identifikator für die Zeilen (Primary Key). Dadurch wird deine Tabelle anfällig für doppelte Daten.
- Verwendung mehrerer Spalten für die gleiche Information. Zum Beispiel "course_1", "course_2", "course_3" – statt einer sauberen Struktur.
Behalte diese Punkte im Kopf, dann bleibt deine Datenbank in der ersten Normalform.
Praktische Anwendung von 1NF
In echten Projekten ist 1NF superwichtig. Zum Beispiel:
- In CRM-Anwendungen müssen Kundendaten und deren Aktionen atomar sein. Das macht Analyse und Suche viel einfacher.
- In Online-Shops wird 1NF genutzt, um Infos zu Bestellungen, Produkten und Kunden effizient zu speichern.
- In Banksystemen müssen Daten zu Kunden, Konten und Transaktionen atomar sein, damit es keine Verwechslungen zwischen verschiedenen Vorgängen gibt.
Wenn du die Prinzipien der 1NF beachtest, kannst du Datenbanken bauen, die hohe Lasten aushalten und trotzdem easy zu benutzen bleiben. Alles cool, aber jetzt gibt’s Daten-Duplikate. Deshalb geht’s weiter mit der zweiten Normalform (2NF), wo klar wird, wie man partielle Abhängigkeiten in Tabellen löst.
Warum ist die Einhaltung der ersten Normalform (1NF) wichtig? Stell dir vor, du speicherst Daten in einer Tabelle, in der eine Zelle gleich mehrere Werte enthält – zum Beispiel eine Liste von Artikeln, die ein Kunde bestellt hat. So wird der Zugriff auf die Daten schwierig: Wenn du alle finden willst, die eine "Tastatur" bestellt haben, wird das zur Qual. Und wenn du einen Teil der Infos ändern oder löschen willst, ist ein Fehler schnell passiert. Wenn die Daten atomar gespeichert sind – also jedes Feld nur einen Wert enthält – wird die Arbeit damit viel zuverlässiger und verständlicher. Außerdem lassen sich solche Tabellen leichter skalieren, aktualisieren und bei Bedarf umbauen.
GO TO FULL VERSION