Normalisierung von Daten

[lilith2k3]

Irgendwie bereitet mir das Thema "Normalisierung" Kopfschmerzen.

Ich weiß nicht recht, ob ich die zweite von der dritten Normalisierung unterscheiden kann und bräuchte für Folgendes ein kurzes Feedback:

Ich habe einen Buchladen im Netz; nennen wir ihn der Einfachheit halber MamaZon

Um meine Bestellungen abzuwickeln habe ich eine Datenbank, wo alles drinsteht.

e.g. Kunde Heinz Müller aus 51103 Köln Kalk kauft heute ein paar Bücher (ISBN: 978-3-14-225042-7, 978-3427205609).

Weil ich keinen Schimmer habe, schreibe ich in die Datenbank:

"Heinz Müller, Albermann Strasse 3, 51103", "978-3-14-225042-7, 978-3427205609", "Buch, Buch"

Somit habe ich zwar die Bestellung drin, aber auch das Chaos.

Weil ich aufräumen will, fange ich an, zu atomarisieren und alles in die 1te NF zu bringen:

"Heinz", "Müller", "Albermann Strasse", "3", "51103", "Köln Kalk", "978-3-14-225042-7", "Buch"

"Heinz", "Müller", "Albermann Strasse", "3", "51103", "Köln Kalk", "978-3-42-7205609", "Buch"

Soweit so gut.

Dann fällt mir auf, das es sinn macht, nicht jedes mal den Namen und die Adresse bei der Bestellung schreiben zu müssen und auch nicht immer ISBN und Artikelbezeichnung, also gliedere ich das in separate Tabellen auf:

Tabelle: Adresse

"Heinz", "Müller", "Albermann Strasse", "3", "51103", "Köln Kalk"

Zusätzlich benötige ich, einen Primärschlüssel, um die ganzen Heinzens Müllers in meiner DB auseinanderzufuddeln. Dazu vergebe ich Kundennummern:

"1234567890ABCDEF", "Heinz", "Müller", "Albermann Strasse", "3", "51103", "Köln Kalk"

Dann friemele ich mir eine Bestelltabelle zusammen, wo ich Kunde und Produkt zusammenfasse:

"1234567890ABCDEF", "978-3-14-225042-7"

"1234567890ABCDEF", "978-3-42-7205609"

Auch hier benötige ich einen adäquaten PK, um Mehrfachbestellungen des gleichen Artikels, am gleichen Tag, etc. vorzubeugen; also sowas wie eine Auftragsnummer samt Anzahl oder Rechnungsposition.

Und zuguter letzt baue ich mir eine Tabelle, wo dann "978-3-42-7205609" bspw. "Buch" zugeordnet ist.

Wenn ich aus der 1. NF diese ganzen Ausgliederungen getätigt habe, habe ich die 2te NF erreicht?!

Aber das ist noch nicht die 3te NF ...

Ich könnte da zum Beispiel hingehen aus der Addresse die Postleitzahl und den Ort in einer Tabelle ausgliedern, so dass bei der Adresse nur die PLZ stehen bleibt.

Der Ort ist von der PLZ abhängig, aber nicht vom Kunden, der da wohnt. Also kommt das ganze in eine PLZ_Ortstabelle:

"51103", "Köln Kalk".

Wenn ich diese Ausgliederung vollbracht habe, sollte meine DB in der Dritten NF vorliegen, right?

Ich habe dann folgende Tabellen:

Kunde(Adresse), Bestellung, Produktbeschreibung, PLZ_Ortstabelle.

Ergibt das irgendwo Sinn?

Habe ich etwas übersehen?

Freue mich auf Feedback!

Bearbeitet 25. April 2012 von lilith2k3

[T3D]

Mit deiner eigentlichen fragen wie die Tabellen in den einzelnen Steps aussehen muessen kann ich dir leider nicht helfen, damit tu ich mich auch verdammt schwer (ist einfach viel zu lang her). Mir reichts meist wenn ich die in die 3. und Boyscott bringen kann.

Aber ich wollt ne Anmerkung zu deine PLZ_Ort Tabelle machen, das funktioniert so naemlich nicht wirklich.

Wenn du dir mal "53534" anguckst sind folgende Orte moeglich: Bauler, Wirft, Pomster, Barweiler, Wiesemscheid, Hoffeld.

PLZ <-> Ort ist ne n:m Beziehung.

[Schnittcher]

Hallo,

also die PLZ und Orte werden heutzutage nicht mehr getrennt. Das wird in der Schule nur noch so unterrichtet wird aber in der Praxis nicht mehr getan.

(Wurde mir erst letzte Woche von einem Lehrer bei uns bestätigt)

Wenn ich mich nicht täusche ist folgendes schon in der 3. NF. (Siehe Anhang, ich habe das mal in Tabellen geschrieben)

Hättest du jetzt in der Kundentabelle zum Beispiel noch Kontodaten.

Dann könntest du diese noch weiter auslagern.

Also Kontonummer und BLZ in der Kunden Tabelle lassen und eine weitere Tabelle für Banken anlegen. Als Schlüssel die BLZ und noch eine Bezeichnung.

Ich hoffe ich habe jetzt keinen Blödsinn erzählt.

[flashpixx]

Weiterhin müssen Postleizahlen nicht zwingend numerisch sein Postleitzahl (bzw andere Nomenklaturen NUTS oder Amtlicher Gemeindeschlüssel )

PLZ sollten als Zeichenketten gespeichert werden. Ich empfehle den AGS zu verwenden, denn falls es zur Zusammenlegungen oder Trennungen von Gemeinden kommt, spielt die AGS die entsprechende Rolle. Anhand des AGS kann man die Postleitzahl ermitteln z.B. via OpenGeoDB Beispiele

[lilith2k3]

Vielen Dank soweit.

Also im Grunde scheine ich das ja dann doch verstanden zu haben:

1 NF: Atomisierung

2 NF: Thematische Ordnung (Kunden, Produkte, Bestellung) um Redundanzen der Einzeleinträge zu verringern. Einzelne Einträge werden erstmal unter einem PK subsummiert. Allerdings bestehen innerhalb der Zeilen noch Abhängigkeiten.

3 NF: Subthematische Ordnung (e.g. bei Internationalen Rufnummern Ländernamen und Ländervorwahlen ausgliedern), so dass in allen Tabellen alles nur noch von den jeweiligen Primärschlüsseln abhängig ist!?

Gut, mit den Postleitzahlen stimmt schon - doofes Beispiel. Aber mir ist auf die schnelle nix mehr eingefallen. Stimmt obige Gliederung denn?

Weil dann hätte ich es wider Erwarten doch verstanden *lol*

@Schnittcher

Intuitiv stimme ich Dir zu und behaupte, dass die so angegebene Tabelle in der 3NF vorliegt.

[Schnittcher]

Es müsste so sein.

[lilith2k3]

Dann sollte das ja auch korrekt sein:

Ist die Ausgangstabelle

und in der 3ten NF wäre dann das das Ergebnis:

Oops.. Da sind ja mehrere Autoren für ein Buch .. wenn wir den Fall ignorieren, sollte es aber stimmen *g*

Bearbeitet 25. April 2012 von lilith2k3

[Schnittcher]

An dieser Stelle würde ich mich jetzt fragen, da der Ort keine PLZ hat, würde man das nun hier auslagern?

Um an dieser Stelle Redundanzen zu vermeiden?

Aber so müsste es eig. richtig sein. Wie gesagt mir stellt sich nur diese eine Frage.

[dr.dimitri]

Von der Normalisierung abgesehen fällt sofort auf, dass die Tabellen Kunde und Bücher (man sollte sich durchgängig für Singular oder Plural entscheiden) einen fachlichen Wert als PrimaryKey verwenden. das mag vielleicht theoretisch ok sein, in der Praxis ist das häufig eine fatale Fehlentscheidung, da sich fachliche Werte im Laufe der Zeit auch ändern können. Daher niemals einen fachlichen Wert als PK verwenden.