Normalisierungen

[Jumper]

Könnte bitte wer die Normalisierungen erklären, nicht so konfus wie im Buch? Besser gesagt wie ich die Relationenschemata aufteile um Verbundtreu und Abhängikeitstreue zu gewährleisten und trotzdem die Integritätsbedingung zu garantieren! Danke

[laborg]

jope bspe wären toll...war ned in da vorlesung ...

gruss laborg

[enola]

hallo!
heute in der vo waren doch ein paar leute, die sich bei den bsp. mit den normalformen anscheinend auskennen. könnte die bitte irgendwer erklären, dass buch hilft da wirklich nicht weiter.
ewiger dank im voraus!!

[laborg]

bis zu welcher nf müssmas können?5?

gruss laborg

[GetStoopid]

das is ne gute frage, weil er hat ja gesagt "normalformen werden net sooo intensiv geprüft" und ich hab auch absolut keine ahnung von normalformen =(

[Walter Huber]

und noch jemand der sich nicht damit auskennt. wann kommt endlich wer der es erklären kann?

[MarvinTheRobot]

da gibtsn pdf...... da steht einiges drin.....

auch hier gibts viel info....

http://www.bib.informatik.tu-darmstadt.de/ttt/AZ154.HTM#g873

wie schon wer anderer in irgendeinem thread gepostet hat..... suchen via google liefert verdammt viele ergebnisse. ;) :D

mfg, Phil.

[Walter Huber]

hab die pdfs eh schon kurz überflogen, aber das ist genauso kompliziert wie in der vo. hat nicht wer eine erklärung für deppen wie mich?

[MarvinTheRobot]

also ich weiss nicht, ich find das mit den normalformen auch irgendwie blöd. aber ich versuch das mal einzudeutschen....

bitte sofort korrigieren sofern ich das falsch verstanden hab...

Die Attribute der Relation müssen atomar sein (ist eine schon vorausgesetze Eigenschaft von Relationen). Strukturierte Attribute (wie Adresse) müssen aufgeteilt werden in ihre Teilattribute (z.B. in PLZ, Ort, Straße und Hausnummer). Relationen in erster Normalform werden auch oft als flache Relationen bezeichnet. Aufgrund von funktionalen Abhängigkeiten (PLZ bestimmt Ort) ergeben sich in 1NF-Relationen Redundanzen.


Des heisst nix anderes als dass pro Spalte nur ein Wert vorhanden sein sollte (eben atomar-klein)

Problem dabei ist, wenn ich zum beispiel PLZ und Ort (Die sind ja eindeutig kombiniert, zu jeder PLZ gibts nur einen Ort) in je einem Feld hab und dann aus einem Datensatz die Straße lösche, lösche ich die PLZ und den Ort auch mit, wenn dieser Datensatz der einzige war der diese PLZ und diesen Ort enthalten hat...

Somit sind Ort und PLZ futsch. könnte man durch eine eigene Tabelle in der nur PLZ und Ort stehen natürlich verbessern und das wär dann die Zerlegung der Relation.

Wenn ich da jetz vollkommenen blödsinn hingeschrieben hab, bitte sagts mir das, dann mach ich nämlich gar net weiter... :D

mfg, Phil.

[gck]

Also, ich probiers mal!

Bei Normalisierung von Datenbanken geht es darum, redundante Datensätze zu vermeiden, weil die aus versch. Gründen gefährlich sein können! Das steht aber verständlich im Buch!

1NF
Die 1. NF besagt nur, dass jedes Attribut einer Relation KEINE nicht atomare Datenstruktur sein darf, i.e. es darf nicht noch weiter zerteilbar sein. Ints, chars, varchars (trotz substring()) etc.. gelten als atomar, nicht atomar sind etwa arrays oder ähnliches.
Gibt es nur atomare Attributtypen, ist die Relation in 1NF

2NF
Wenn eine Teilmenge des Schlüssels (oder ganze Schlüssel) ein Attribut eindeutig bestimmt i.e. in funktionaler Abhängigkeit (sie meine reply im zugehörighen Thread) dazu steht, ist dessen Speicherung in der Tabelle redundant und kann in eine eigene Tabelle ausgelagert werden.
D.h. du nimmst das funktional abhängige Attribut, tust es mit dem Teil des Schlüssels, der es bestimmt, in eine eigene Tabelle, und streichst das Attribut aus der Originaltabelle.
Das machst du so lange, bis es in der Ausgangstabelle und denen, die durch die Zerstückelung entstanden sind, keine nicht-trivialen FAs mehr gibt. Eine triviale FA ist X->X (klar, ein Attribut bestimmt sich selber!)

3NF
Es kann auch transitive Abhängigkeiten geben, ie. X->Y->Z. Wie das ausschaut, ist ziemlich logisch, wenn ihr verstanden habt, was eine funkt. Abh. ist.
In dem Fall nimmst du Z aus der Relation raus, gibst es in eine eigene Tabelle, und tust das Y als Schlüssel dazu. Das Y lässt du natürlich in der Originalrelation!

4NF
Es gibt (leider) auch mehrwertige Abhängigkeiten, d.h. X->>-Y, d.h. ein Attribut X bestimmt eine bestimmte Menge von möglichen Werten für Y bestimmt. Du kannst dir das so vorstellen: angenommen, du hast 4 Kinder: Wenn ich jetzt eine Relation mache, wo du und deine Kinder drinstehen, dann weiß ich: deinem Namen kann nur eines deiner 4 Kinder zugeordnet werden, es ist zwar nicht eindeutig, welches deiner 4 jeweils gemeint ist, aber da du nur 4 Kinder hast, MUSS es eines von denen sein!
Um diese mehrwertige Abh. zu killen, kopierst du die mehrwertige Seite in eine neue Tabelle, und die linke Seite dazu. Die mehrwertige Seite ist dann der Schlüssel: in dem Beispiel: die Spalte Kinder wird aus der Originalrelation gestrichen und in eine neue Tabelle kopiert, wo ihre Namen den Schlüssel bilden. Dann wird dein Name als Attribut dazukopiert. Damit gibt es für dich und deine 4 Kinder genau 4 Einträge in dieser neuen Tabellen, und keine Redundanzen: wenn in der Originaltabelle immer du, eines deiner Kinder, und irgendwelche Attribute, die ÜBERHAUPT NICHT von dem Namen des Kindes abhängig sind (etwa deine Automarke, ob du rauchst etc...), dann hätte das zu unnötigen Redundanzen geführt.
Das Beispiel im Buch drückt das eigentlich eh auch ganz gut aus, glaub ich. Eigentlich sind diese MVDs nicht *wirklich* viel anders von den FAs, nur dass eben diese "eindeutige" Bestimmungskomponente fehlt!

5NF
davon steht nix im Buch, deshalb glaub ich nicht, dass die kommt! Wenn ja, dazu weiß ich leider nix :)

Hoffentlich hilft das da oben etwas (und ist richtig)!

[MarvinTheRobot]

@ gck, ich würd nur gern wissen ob meins auch gestimmt hat. ;)

[Walter Huber]

bis zu 3 hab ich es kapiert.... aber ich denke das 4 eh nicht kommen wird... oder besser gesagt hoffe ich es ;)

[gck]

Original geschrieben von MarvinTheRobot


Problem dabei ist, wenn ich zum beispiel PLZ und Ort (Die sind ja eindeutig kombiniert, zu jeder PLZ gibts nur einen Ort) in je einem Feld hab und dann aus einem Datensatz die Straße lösche, lösche ich die PLZ und den Ort auch mit, wenn dieser Datensatz der einzige war der diese PLZ und diesen Ort enthalten hat...

Somit sind Ort und PLZ futsch. könnte man durch eine eigene Tabelle in der nur PLZ und Ort stehen natürlich verbessern und das wär dann die Zerlegung der Relation.

Wenn ich da jetz vollkommenen blödsinn hingeschrieben hab, bitte sagts mir das, dann mach ich nämlich gar net weiter... :D

mfg, Phil.

Ich bin mir nicht ganz sicher, was du da meinst: wenn du etwa PLZ und Ort in eine eigene Tabelle auslagerst (mit PLZ als Schlüssel) und PLZ auch in einer anderen Tabelle als Attribut hast, und du löscht aus dieser Tabelle den einzigen Eintrag, der diese PLZ referenziert, dann ist die PLZ in der anderen Tabelle schon noch da!! Du löscht ja immer nur von einer Tabelle! "Tabellenübergreifende" Anhängigkeiten dieser Art gibt es nicht, wenn was wo ein Fremdschlüssel ist, dann ist es trotzdem Teil seiner eigenen Tabelle und verschwindet so nicht!

[MarvinTheRobot]

hab ich gemeint..... sorry. ist so auf den folien erklärt.... (pdf von der uni linz....)


also wenn ich ort aus der tabelle adressen rausnehm, plz aber drin lass und eine neue tabelle mit ort und plz anleg wobei plz der schlüssel ist, dann müsste das doch passen oder? sorry oben hab ich das doch etwas konfus erklärt aber eigentlich DAS gemeint. ;-)

[steve]

eine transitive Abhängigkeit (3.NF) (x->y->z) ist also eine funktionale abhängigkeit, wobei aber beide elemente x und y _nicht_-schlüssel sind, oder? und das z der gesamte schlüssel (sonst wärs schon in der zweiten NF eliminiert worden)
funktionale abhängigkeiten (x->y) brauchen als x einen teil des schlüssels...

[gck]

@Marvin: ja, so wie dus jetzt sagst, ist es richtig!

@steve: nunja, eine transitive abhängigkeit ist k->x->y, wobei k ein Teil oder der ganze Schlüssel ist, x und y aber nur Attribute. Du hast sowas deswegen bei der zweiten Normalform nicht wegbekommen, weil jetzt zwar die FA k->x weg ist, aber k auch indirekt y bestimmt, was du in der 2NF nicht beachten musst! Deshalb musst du in der 3NF das y wieder aus der Tabelle in eine neue tun, zusammen mit dem x, was jetzt Schlüssel der neuen Tabelle ist! Das x wiederum ist schon wegen der Dann sind die depperten transitiven FAs auch weg! Eigentlich ist das auslöschen von trans. FAs nix anderes als "rekursives" Anwenden des Bringens auf 2NF, zumindest in gewissem Maße ;)

[laborg]

stimmt folgendes:

ausm buch s 76 . untere tabelle in 2nf gebracht
1013 16.09.2000
1011 18.02.1999
1014 3.05.2000

und als 2. tabelle die ganze tabelle ohne datum

?

thx
laborg

[VTEC]

Ich denke, es gehören 3 Tabellen gemacht, nämlich zusätzlich noch:

BestNr KNr. rausgezogen als eigene Tabelle

Das macht dann folgende 3 Tabellen:

Best.Nr, Datum
Best.Nr., KNr
Best.Nr., VersandID, ProdId

Im Buch auf S 77 ist die 3. Tabelle aber nicht drinnen, aber es kann ja eine konkrete Bestellung nur von einem Kunden getätigt werden, also gehörts auch ausgegliedert, denke ich.

*das_verdammte_Schmalspurbuch_weiterlies*:o

[maxi]

ja, sehe ich auch so:

bsp:
relation
AB__cdef
wobei noch abhängigkeiten bestehen:

B--> c (c hängt vom teil d.keys ab = not 2.NF)
e--> f (f hängt vom attribut e ab = transitiv, not 3.NF)
schritt 1)
AB_def
B_c
_______somit in 2.NF
schritt 2)
AB_de
e_f
B_c
________jetzt auch in 3.NF

trick: was einmal schlüssel ist, muss in anderer relation attribut sein, bzw. umgekehrt, je nachdem ob man von der 'obersten' od. 'untersten' relation ausgeht - dann ist verbundtreue u. abhängigkeitstreue gegeben (eigene interpretation)
lg, m

[vig]

.

[thita]

hat zufällig jemand die beispiele zu den normalformen aus der letzten vo mitgeschrieben?