SQL Schwere Probleme mit den Normalformen

[Shakall]

Hallo,
ich habe folgendes Problem.
Ich schreibe demnächst eine Klassenarbeit über das Thema "Normalformen" dazu muss ich die ersten 3 Normalformen perfekt verstehen um sie richtig anwenden zu können.

Ich weiß es gibt tausende videos im Internet aber das ist leider für mich nicht verständlich genug , dass ich mir sicher sagen kann "Ich habe es verstanden!"

Die erste Normalform besagt ja das alle Attribute atomar sein sollen , das heißt das zb bei Adresse wenn da stehen würde " 20095 Hamburg " das man die Spalte in Postleitzahl und Ort ergänzen würde und somit die Spalte Adresse wegfallen würde.

Außerdem soll man ein eindeutigen Primärschlüssel finden das wäre zb die ID.

So habe ich die erste Normalform verstanden und ich glaube sie richtig verstanden zu haben.

Ab der zweiten Normalform geht für mich das Problem los.. da verstehe ich sogut wie nichts egal was ich lese egal welches youtube video ich mir anschaue

hier mal 2 Beispielaufgaben

 

[AboveUsOnlySky]

Ich beziehe mich mal auf das untere Bild:

Die 3NF ist verletzt. Bei jedem neuen Bucheintrag würde man die Sachgebiet_ID und das Sachgebiet wieder mitspeichern. Das führt zu Datenredundanz. Aus dem Sachgebiet (incl. ID als Primärschlüssel, der wird in der alten Tabelle ebenfalls als Schlüssel geführt) müsste man eine eigene Tabelle machen. (ID, Sachgebiet)

 

[hongkongfui]

richtig.
gleiches beim ersten bild.
filialnummer UND filialort ist nicht nötig, denn mit der nummer liegt der ort schon fest.
daher wird das getrennt.

stell dir vor, du legst einen neuen kunden an.
ordnest ihm eine filialnummer zu. brauchst du dann noch den filialort in seinem datensatz?
nein! denn der ist mit der filialnummer schon eindeutig festgelegt.

 

[Shakall]

unverständlich!

 

[AboveUsOnlySky]

Als kurze Fragestellung und vielleicht auch zum leichteren Verständnis

Warum möchtest Du in einer umfangreichen Tabelle für Bücher 1.000.000 x das Sachgebiet "Garten" speichern?

Warum sollte man das tun?

 

[PW-toXic]

Zu Bild 1:

Informell: Die Tabelle beschreibt zwei Sachverhalte, nämlich:
a) Ein Kunde hat in Läden eingekauft.
b) Ein Laden hat einen Ort.
Damit ist die Tabelle (informell) nicht in der 2. Normalform

Problem:
Wenn Kunde 2 nun auch in Laden 1 einkauft, befindet sich der Ort des Ladens 1 mindestens 2 mal in der Tabelle -> Redundanz. Dadurch können Inkonsistenzen entstehen, so dass ein Laden gleichzeitig an zwei Orten ist.

Formell:
Das Attribut "laden_ort" ist abhängig von "laden_id". "laden_id" ist jedoch eine echte Teilmenge des Schlüssels, und somit nicht in der 2. Normalform.

Lösung:
Tabellen:
a) "Laden-Kunden-Zuordnung": laden_id, kunden_id (Schlüssel: laden_id, kunden_id)
b) "Laden-Details": laden_id, laden_ort" (Schlüssel: laden_id)


Alles unter der Annahme, dass ich es richtig interpretiert habe, dass ein Kunde in einem Laden gekauft hat, und das hier modelliert werden soll.

 

[ygbr]

2NF: Der Primärschlüssel setzt sich zusammen aus kunde_id und laden_id. Die zweite Normalform ist deshalb verletzt, weil laden_ort nur von laden_id abhängig ist und nicht vom Primärschlüssel, abgesehen von der sich ergebenden Redundanz. Zum Thema Redundanz: Unser ERP-System speichert aktuelle Kundenstammdaten wie Name, Adresse, usw. *) allein schon aus Gründen der Revisionssicherheit. Kundenstammdaten werden ab und zu auch mal geändert z.B. die Adresse.

Edit:
*) in Bewegungsdaten

 

[Schiller72]

Naja bei Relationalen Datenbank (Management) Systemen geht es ja vordringlich darum große Datensätze möglichst effektiv (für spätere Suchen) und vor allem nicht redundant abzulegen. Daher werden ja mehrere Tabellen angelegt und miteinander über Schlüssel verknüpft.
Ansonsten könnte man ja eine große Tabelle nehmen und dort alle Daten eintragen, z.B. mit Excel.

In Bezug auf Bild 2 hier eine Lösung, die AboveUsOnlySky schon schreib, hier noch mal zur Verdeutlichung als Bild.

 

[ygbr]

OK, ich bezog mich in meinem Beispiel eher auf OLTP Datenbanken mit dem relativ häufigen Fall der Stammdatenänderung. Ändere mal die PLZ, Straße oder sonst was und drucke ältere Rechnungen wiederholt aus, dann erhälst Du bei referenzierten Stammdaten falsche, nämlich die aktuellen und nicht die damaligen, Adressen. Um das in der Datenbank revisionssicher zu machen, musst Du entweder redundant speichern, mit einer Stammdatenversionierung arbeiten oder extern archivieren. Einige ERP-Systeme bieten die Stammdatenversionierung von Haus aus an. Was OLAP betrifft, vor Allem die multidimensionalen Würfel, da gebe ich Dir natürlich Recht.

 

[Shakall]

Für mich ist alles hier unlogisch!

Ergänzung (30. März 2014)

Ok , ich denke gestern war einfach kein guter Tag für mich.

Heute ist es mir viel klarer geworden.
Vielen dank nochmal an PW-toXic , der mir versucht hat das schritt für schritt zu erklären!

Was ich jedoch leider noch nicht verstehe , ist was so der unterschied zwischen der 2 und 3 normalform ist.

Ist im zweiten bild wo sachgebiet aufgelistet wird nur die 2 normalverletzt und deswegen gleich die dritte normalform verletzt oder wie ist es genau ?

 

[PW-toXic]

Sachgebiet ist voll funktional abhängig von sachgebiet_id

Sachgebiet ist NICHT Teil des Schlüssels. Die 2. Normalform behandelt aber nur Fälle in denen Nichtschlüssel-Attribute partiell funktional abhängig vom Schlüssels sind. Daher kann deswegen die 2. Normalform nicht verletzt sein.

Die 3. Normalform verlangt, dass es keine transitiven Abhängigkeiten zum Schlüssel gibt. Was ist transitiv?
* Hai frisst Goldfisch;
* Wal frisst Hai
* => (daraus folgt) Wal frisst Goldfisch.

In dieser Aufgabe:
* Sachgebiet ist voll funktional abhängig von sachgebiet_id
* Sachgebiet_id ist voll funktional abhängig von buch_id
* => (daraus folgt) Sachgebiet ist transitiv funktional abhängig von buch_id
* => die 3. Normalform ist verletzt.