1. Beispiel einer nicht-normalisierten Datenbank, die Kundendaten und gekaufte Artikel enthält id Name Adresse Art-nr Artikel Preis 1 Fritz Meier A-Str. 5, 12345 A-Stadt 1234 Tasse 2,50 1 Fritz Meier A-Str. 5, 12345 A-Stadt 1234 Tasse 2,50 1 Fritz Meier A-Str. 5, 12345 A-Stadt 1235 Teller 2,90 1 Fritz Meier A-Str. 5, 12345 A-Stadt 1238 Besteck 11,00 2 Anna Müller B-Str. 23, 12345 A-Stadt 1234 Tasse 2,50 2 Anna Müller B-Str. 23, 12345 A-Stadt 1235 Teller 2,90 2 Anna Müller B-Str. 23, 12345 A-Stadt 1235 Teller 2,90 2 Anna Müller B-Str. 23, 12345 A-Stadt 1235 Teller 2,90 3 Tanja Mey C-Str. 12, 23111 B-Stadt 1235 Teller 2,90 4 Karl Schmidt D-Str. 12, 23112 B-Stadt 1238 Besteck 11,00 ... Redundante Daten belegen unnötig Speicherplatz und verursachen Wartungsprobleme. Wenn Daten, die mehrfach und an verschiedenen Speicherorten existieren, geändert werden müssen, müssen alle Vorkommen dieser Daten auf exakt die gleiche Weise geändert werden. Eine Kundenadresse ist viel einfacher zu ändern, wenn die entsprechenden Daten nur in der Tabelle "Kunden" und an keiner anderen Stelle der Datenbank gespeichert sind. Wenn "Fritz" in die "E-Str. 122, 23113 B-Stadt" umzieht, müssten in obiger Tabelle gleich 4 Einträge geändert werden; und bei so einer (schlechten!) Datenorganisation, wäre zu befürchten, dass die vier zu ändernden Einträge nicht ordentlich untereinander stehen, sondern womöglich an vielen Stelle verstreut. 1. Normalform - Eliminierung offensichtlicher Wiederholungen, Aufteilung in separate Tabellen, Darstellung atomarer Daten Tabelle Kunden id Vorname Nachname Str. Hausnr. PLZ Stadt 1 Fritz Meier A-Str. 5 12345 A-Stadt 2 Anna Müller B-Str. 23 12345 A-Stadt 3 Tanja Mey C-Str. 12 23111 B-Stadt 4 Karl Schmidt D-Str. 12 23112 B-Stadt Tabelle Kunde_kauft_Artikel id Art-nr Artikel Preis 1 1234 Tasse 2,50 1 1234 Tasse 2,50 1 1235 Teller 2,90 1 1238 Besteck 11,00 2 1234 Tasse 2,50 2 1235 Teller 2,90 2 1235 Teller 2,90 2 1235 Teller 2,90 3 1235 Teller 2,90 4 1238 Besteck 11,00 2. Normalform - Erstellen separater Tabellen und Herstellen einer Beziehung zwischen diesen Tabellen mit einem Fremdschlüssel. Tabelle Kunden id Vorname Nachname Str. Hausnr. PLZ Stadt 1 Fritz Meier A-Str. 5 12345 A-Stadt 2 Anna Müller B-Str. 23 12345 A-Stadt 3 Tanja Mey C-Str. 12 23111 B-Stadt 4 Karl Schmidt D-Str. 12 23112 B-Stadt Tabelle Artikel Art-nr Artikel Preis 1234 Tasse 2,50 1235 Teller 2,90 1238 Besteck 11,00 Tabelle Umsatz id Art-nr Stückzahl 1 1234 2 1 1235 1 1 1238 1 2 1234 1 2 1235 3 ... 3. Normalform - Auflösung transitiver Abhängigkeiten Tabelle Kunden id Vorname Nachname Str. Hausnr. PLZ 1 Fritz Meier A-Str. 5 12345 2 Anna Müller B-Str. 23 12345 3 Tanja Mey C-Str. 12 23111 4 Karl Schmidt D-Str. 12 23112 Tabelle PLZ PLZ Stadt 12345 A-Stadt 23111 B-Stadt 23112 B-Stadt Tabelle Artikel Art-nr Artikel Preis 1234 Tasse 2,50 1235 Teller 2,90 1238 Besteck 11,00 Tabelle Umsatz id Art-nr Stückzahl 1 1234 2 1 1235 1 1 1238 1 2 1234 1 2 1235 3 ... ========================== 2. Beispiel einer nicht-normalisierten Datenbank, die belegte Kurse und Berater von Studenten darstellt Matrikelnr zugeordneter Berater Ber-Raum Kurse1 Kurse2 Kurse3 1022 Müller 412 101-07 143-01 159-02 4123 Schmidt 216 201-01 211-02 214-01 1. NF Matrikelnr zugeordneter Berater Ber-Raum Kurs 1022 Müller 412 101-07 1022 Müller 412 143-01 1022 Müller 412 159-02 4123 Schmidt 216 201-01 4123 Schmidt 216 211-02 4123 Schmidt 216 214-01 2. NF Tabelle Studenten Matrikelnr zugeordneter Berater Ber-Raum 1022 Müller 412 4123 Schmidt 216 Tabelle Belegung Matrikelnr Kurs 1022 101-07 1022 143-01 1022 159-02 4123 201-01 4123 211-02 4123 214-01 3. NF Im 2. Beispiel ist Ber-Raum (die Büronummer des Studienberaters) funktionell abhängig vom Attribut "zugeordneter Berater". Die Lösung besteht darin, dieses Attribut von der Tabelle "Studenten" in die Tabelle "Berater" zu verschieben. Tabelle Studenten Matrikelnr Ber-Raum 1022 412 4123 216 Tabelle Berater Ber-Raum zugeordneter Berater 412 Müller 216 Schmidt Tabelle Belegung Matrikelnr Kurs 1022 101-07 1022 143-01 1022 159-02 4123 201-01 4123 211-02 4123 214-01 Auch in diesem Beispiel ist die dritte Normalform zwar in der Theorie wünschenswert, jedoch nicht immer in der Praxis. Viele kleine Tabellen können zu einer Leistungsminderung führen oder die Kapazität hinsichtlich der geöffneten Dateien und des verfügbaren Speichers überschreiten. In jedem Fall ist für einen Menschen die 2. NF leichter lesbar (übersichtlicher und verständlicher) als die 3. NF. Es ist möglicherweise sinnvoller, die dritte Normalform nur auf Daten anzuwenden, die sich häufig ändern. Bleiben einige abhängige Felder erhalten, gestalten Sie Ihre Anwendung so, dass der Benutzer alle Felder überprüfen muss, wenn eines der zueinander in Beziehung stehenden Felder geändert wird.