Normalisierung: 1. Normalform

Wenn aus einem ER-Modell ein Datenbankschema entsteht, kann es passieren, dass dieses Schema noch nicht „sauber" ist. Es kann redundante Daten enthalten, mehrwertige Felder, oder Strukturen, die später zu Problemen führen werden – ähnlich wie das Excel-Beispiel aus Lektion 1. Normalisierung ist der systematische Prozess, mit dem ein Schema in eine „gesunde" Form gebracht wird. Es gibt sechs Normalformen (1NF bis 6NF), aber in der Praxis und in der IHK-Prüfung reichen die ersten drei – sie lösen 99 % der Probleme.

Diese Lektion behandelt die erste Normalform (1NF) – die Grundlage. Sie hat genau eine, sehr einfache Regel: Jede Zelle einer Tabelle darf nur einen einzigen, atomaren Wert enthalten. Klingt trivial, ist es aber nicht – die häufigsten Anfänger-Tabellen verletzen genau diese Regel.

1) Die Regel der 1. Normalform

Eine Tabelle ist in der 1. Normalform (1NF), wenn drei Bedingungen erfüllt sind:

1. Jedes Attribut enthält nur atomare Werte – also einzelne, unteilbare Daten. Keine Listen, keine Mehrfachwerte, keine zusammengesetzten Strings in einer Zelle.
2. Es gibt keine Wiederholungsgruppen – also keine Spalten wie telefon1, telefon2, telefon3.
3. Jede Zeile ist eindeutig identifizierbar – also: Es gibt einen Primärschlüssel.

Klingt einfach, ist es im Prinzip auch. Schwierig wird es, wenn aus einer Excel-Tabelle eine Datenbank werden soll: Excel hat all die schlechten Gewohnheiten, die in einer Datenbank verboten sind. Genau deswegen ist 1NF die erste Hürde, an der reale Migrationsprojekte stolpern.

2) Drei typische Verstöße erkennen

Die 1NF wird auf drei klassische Arten verletzt. Wer diese drei Muster auf einen Blick erkennt, hat die Lektion verstanden:

3) Verstöße direkt im Validator markieren

Schauen wir uns eine konkrete Tabelle an, die alle drei Probleme gleichzeitig hat. Die roten Felder sind die Verstöße – diese Tabelle ist nicht in der 1NF:

4) Before/After – die Lösung im Vergleich

Klick zwischen dem fehlerhaften Schema und der korrigierten 1NF-Version. Du siehst, was passieren muss: Spalten aufteilen, eine zweite Tabelle für die Telefone anlegen, Beziehung per Fremdschlüssel herstellen:

5) Was bringt die 1NF konkret?

Die Mühe lohnt sich. Sobald eine Tabelle in 1NF ist, werden Abfragen, die vorher unmöglich oder umständlich waren, plötzlich trivial:

• Filtern: SELECT * FROM kunden WHERE stadt = 'Köln' – funktioniert sofort, weil stadt eine eigene Spalte ist.
• Zählen: SELECT kunden_id, COUNT(*) FROM telefon GROUP BY kunden_id – „Wie viele Telefonnummern pro Kunde?" in einer Zeile.
• Sortieren: ORDER BY plz – funktioniert, weil PLZ eine eigene Spalte ist.
• Aggregation: Statistiken pro Stadt, pro PLZ-Bereich, pro Telefonart – alles ein GROUP BY entfernt.
• Eindeutige Werte: SELECT DISTINCT stadt FROM kunden – liefert alle Städte ohne Duplikate.

Ohne 1NF müsste man Strings mit LIKE '%Köln%' durchsuchen oder mit SUBSTRING-Funktionen zerlegen. Das ist langsam (kein Index hilft), fehleranfällig (was wenn jemand „Coelln" geschrieben hat?) und schwer zu warten. Die 1NF ist also nicht nur Theorie – sie ist die Grundlage guter SQL-Performance.

6) Sonderfall: Wann ist eine Aufteilung übertrieben?

Die 1NF kennt zwei interessante Grauzonen, in denen erfahrene Datenbankentwickler unterschiedlich entscheiden:

• Adresse als Volltext: Wenn die Anwendung Adressen nur druckt (z. B. auf Rechnungen) und nie filtert, kann eine einzige Spalte adresse als VARCHAR(255) ausreichen. Streng genommen ist das nicht 1NF – aber wenn die Daten nie zerlegt werden müssen, ist die Aufteilung überflüssiger Overhead. In der IHK-Prüfung gilt: im Zweifel aufteilen.
• JSON-Spalten: Moderne DBMS wie PostgreSQL oder MySQL erlauben JSON-Spalten, die strukturierte Daten enthalten. Streng genommen verletzt das 1NF. Pragmatisch erlaubt es enorme Flexibilität, etwa für variable Produktattribute. Hier nähert sich SQL den NoSQL-Welten an.

Solche Grauzonen sind in der Praxis erlaubt – aber man sollte wissen, dass man von der reinen 1NF abweicht. In der IHK-Prüfung dagegen ist die Regel strikt: Wenn die Aufgabe sagt, in 1NF zu bringen, dann ALLE mehrwertigen und zusammengesetzten Felder auflösen.

7) Die 1NF und das Excel-Problem

Erinnerst du dich an die Excel-Tabelle aus Lektion 1? Sie hatte mehrere Probleme – aber das fundamentalste war: Sie war nicht in 1NF. Denselben Kunden in mehrere Zeilen zu schreiben, weil jede Zeile einer Bestellung entsprach, ist genau das Symptom einer fehlenden Normalisierung.

Die Lösung dort (Kunden in eine Tabelle, Bestellungen in eine andere, verknüpft per Fremdschlüssel) war nichts anderes als Normalisierung in Aktion. Die 1NF ist nur der erste Schritt; 2NF und 3NF in der nächsten Lektion lösen noch tieferliegende Redundanzprobleme. Aber ohne 1NF macht der ganze Rest keinen Sinn – sie ist die unverzichtbare Grundlage.

Praxistipp: Wenn dir ein Schema vorgesetzt wird, ist die erste Frage immer: „Ist das in 1NF?" Sobald du eine Zelle mit Komma-getrennten Werten oder durchnummerierte Spalten siehst (telefon1, telefon2, ...), weißt du: Hier wartet eine Normalisierungsaufgabe.

Zusammenfassung

Die 1. Normalform (1NF) ist die Grundvoraussetzung jedes gesunden Datenbankschemas. Eine Tabelle ist in 1NF, wenn drei Bedingungen erfüllt sind: (1) alle Werte sind atomar – keine Listen oder zusammengesetzten Strings in einer Zelle, (2) keine Wiederholungsgruppen wie telefon1, telefon2, telefon3, (3) jede Zeile hat einen Primärschlüssel. Die drei typischen Verstöße sind mehrwertige Zellen („0171-1, 030-5"), Wiederholungsgruppen (telefon1/2/3) und zusammengesetzte Werte („Hauptstr. 12, 50667 Köln"). Die Lösung ist immer: Daten auseinanderziehen – zusammengesetzte Werte in mehrere Spalten, mehrwertige Werte in eine eigene Tabelle mit Fremdschlüssel. Die 1NF macht SQL-Abfragen erst sinnvoll möglich: filtern, sortieren, zählen, aggregieren – alles braucht atomare Werte. Es gibt Grauzonen (JSON-Spalten, Volltext-Adressen), aber für IHK-Prüfungen gilt: im Zweifel strikt aufteilen.

Verwandte Lektionen: 2. und 3. Normalform · ER-Modell zu Schema · Denormalisierung · und mehrWeitere relevante LektionenWas ist eine Datenbank?Entity-Relationship-ModellCREATE TABLESELECT-GrundabfragenGROUP BY & HAVINGPrimary & Foreign KeyWarum NoSQL?