Dies ist eine alte Version des Dokuments!

---

Normalisierung beschreibt den Vorgang, Tabellen einer Datenbank dahingehend zu strukturieren, sodass sie keine vermeidbaren Redundanzen enthalten. Normalisierte Tabellen sorgen für eine konsistente und fehlerunanfällige Datenhaltung. ======Beispiel====== Ein Entwickler hat die Aufgabe bekommen, die Datenbank für das Wirtschaftssystem der Firma Failution zu implementieren. Die Firma möchte folgenden Informationen seiner Kunden speichern: * Kunden * Name * Firma * Adresse * Notiz (//Hinweis auf offene Rechnung//) * Bestellung * Datum * Bezahlung schon abgeschlossen - ja/nein? * Artikel * Bezeichnung * Details * Einzelpreis * Auslaufartikel - ja/nein? ^KND_Name^KND_Firma^KND_Adresse^KND_Notiz^KND_Notiz2^BST_Datum^BST_Bezahlt^ART_1^ART_2^ |Max Mustermann|Mustermann Consulting|Musterstrasse 1, 12345 Musterstadt| | |10.10.2010|1|10x Thin-Client BAER (1.6 Ghz,Sound,VGA,USB) 199.99|15x Thin-Client NP (1.0 Ghz,Sound,VGA+DVI,USB) 179.99 Auslauf| |Theodor Tester|Test-Solutions AG|Testweg 16, 55353 Testort|Offene Rechnung| |15.02.2011| |1x Thin-Client BAER (1.6 Ghz,Sound,VGA,USB) 199.99| | COPY ======1.Normalform====== Die erste Normalform liegt vor, wenn eine Tabelle die folgenden Bedingungen erfüllt: * Es dürfen keine Spalten mit gleichen Inhalten vorliegen * Die Werte dürfen nicht weiter teilbar sein (//man sagt auch, sie müssen **atomar** sein//) * Es dürfen keine doppelten Einträge/Zeilen enthalten sein Der oben angezeigt Entwurf erfüllt keine der drei Bedingungen - die Gründe sind: * Es sind Spalten mit gleichen Inhalten vorhanden - es gibt zwei Spalten für Notizen: **KND_Notiz** und **KND_Notiz2**. * Es gibt Werte, die sich weiter teilen ließen. Das Feld **KND_Name** lässt sich in zwei seperate Felder für den Vor- und Nachnamen des Kunden aufteilen, ferner vereint das Feld **KND_Adresse** neben der Adresse auch die Hausnummer, die PLZ und den Ortnamen. Die Spalte **Artikel** enthält neben der Artikelbezeichnung auch die Artikeldetails und Anzahl der erworbenen Artikel. Alle Bestellungspositionen werden mittels Komma getrennt aufgelistet - die Einzelpreise werden auf ähnliche Art und Weise mittels Komma getrennt und aufgelistet. * Es gibt doppelte Einträge - die letzten beiden Datensätze sind identisch - hier hat sich der Entwickler wohl vertippt und somit eine unnötige Redundanz erschaffen. Solche Mehrfach-Einträge lassen sich mit dem Verwenden eines **Primärschlüssels** vermeiden. Beherzigt man die oben genannten drei Regeln lässt sich das Konzept wie folgt überarbeiten: ^ID^KND_Vorname^KND_Nachname^KND_Firma^KND_Strasse^KND_HausNr^KND_PLZ^KND_Ort^KND_Notiz^BST_Datum^BST_Bezahlt^ART_Anzahl^ART_Bez^ART_Details^ART_Auslauf^ART_Preis^ |1|Max|Mustermann|Mustermann Consulting|Musterstrasse|1|12345|Musterstadt| |10.10.2010|ja|10|Thin-Client BAER|1.6 Ghz,Sound,VGA,USB|nein|199.99| |2|Max|Mustermann|Mustermann Consulting|Musterstrasse|1|12345|Musterstadt| |10.10.2010|ja|15|Thin-Client NP|1.0 Ghz,Sound,VGA+DVI,USB|ja|179.99| |3|Theodor|Tester|Test-Solutions AG|Testweg|16|55353|Testort|Offene Rechnung|15.02.2011|nein|1|Thin-Client BAER|1.6 Ghz,Sound,VGA,USB|nein|199.99| Was wurde geändert? * Es wurde ein Primärschlüssel **ID** eingefügt, somit gibt es einzigartige Einträge (//kein Eintrag gleicht dem anderen, da er eine andere ID hat//) * Die Felder für den Kundennamen, die Kundenadresse, Kundennotizen und das Feld mit Informationen über die bestellten Artikel wurden in **atomare** Felder aufgeteilt * Die Felder **ART1** und **ART2** waren "//doppelt//", es waren zwei Felder mit dem selben informationstechnischen Nutzen - sie sollten Informationen über bestellte Artikel beinhalten. Sie wurden aufgeteilt, für alle Artikelinformationen (//Bezeichnung, Details, Auslaufartikel, Preis//) gibt es nun dedizierte Felder.