zweite normalform

[spinxy]

hmm...also ich hab mir das jetzt durchgelesn und die erste nf ist mir ja noch klar aber die 2?? kann mir das wer in normalen worten ohne die blöden formeln und so erklären, vll anhand eines bsp.? im buch auf s. 179 is ja auch ein bsp. dazu aber da ist mir auch nicht klar warum das bsp. so nicht sein darf :confused:

lg

[mmp]

Naja, soweit ich das verstanden habe ist es eigentlich ganz einfach.

Bei der 2ten Normalform kommt es darauf an, dass alle Attribute von den gleichen Schlüsseln abhängen.
Beim Bsp auf Seite 179 ist der Schlüssel von StudentenBelegung die VorNr und die MtrNR.
Name und Semester ist zwar von der MatNR abhängig aber nicht von der VorNr und deshalb muss man das ganze aufsplitten.

Hoffe ich erzähl hier keinen blödsinn aber ich hab das so interpretiert.

PS.: Die Seite hat mir auch geholfen:
www.byteshift.de/web-design/de/Normalisierung#2._Normalform_(2NF)

[Fup]

Ich versteh die NF schon, aber mir sind diese Schlüsseln nicht ganz klar.

Zweite NF ist es ja dann, wenn jedes Nichtschlüssel-Attribut voll funktional abhängig ist von jedem Kandidatenschlüssel der Relation.

Name und Semester sind eindeutig funktional abhängig von MatrNr, d.h. MatrNr ist ein Kandidatenschlüssel.
MatrNr und VorlNr zusammen sind zwar Schlüssel, aber kein Kandidatenschlüssel (nicht minimal) und verletzen daher die NF.
ODER
Name und Semester sind nur von einem Teil des Schlüssels abhängig, nur MatrNr, daher nicht in 2.NF.

[ein_stein2000]

also wenn i das richtig gecheckt hab, dann is jo die 2te NF nix anderes, als eine form, wo es keine Datenredundanz gibt ... und das is jo ein grundprinzipt der datenbanken oda nit?!

also is die 2te NF eh trivial :D

[Fup]

Das Beispiel in FD's

1) MatrNr -> Name
2) MatrNr -> Semester
3) MatrNr,VorlNr -> Name, Semester

Die 3.FD kann man Linksreduzieren auf MatrNr -> Name, Semester, da die Nichtschlüssel-Attribute voll funktional abhängig von MatrNr sind. VorlNr ist dazu nicht notwendig und würde nur zu Redundanzen führen.

[oopster]

Zweite NF ist es ja dann, wenn jedes Nichtschlüssel-Attribut voll funktional abhängig ist von jedem Kandidatenschlüssel der Relation.

Ich schätzte das hat folgenden Grund:

Semester und Name sind NICHT abhängig von VorNr --> daher ist die Def. von 2.NF verletzt, da ja MatrNr und VorlNr Kandidatenschlüssel sind.

[oopster]

Das Beispiel in FD's

1) MatrNr -> Name
2) MatrNr -> Semester
3) MatrNr,VorlNr -> Name, Semester

Die 3.FD kann man Linksreduzieren auf MatrNr -> Name, Semester, da die Nichtschlüssel-Attribute voll funktional abhängig von MatrNr sind. VorlNr ist dazu nicht notwendig und würde nur zu Redundanzen führen.
äh nein, das würde ich so nicht sagen, da ja VorlNr dann gar nicht mehr als Attribut vorkommen würde. Eher: die 3. FD geht so nicht, ich denke die Vorlesungsnr bestimmt da gar nix, daher muss man die in ne eigene Relation dann geben:

MatrNr,Name, Semester
MatrNr,VorlNr

sag ich mal so ins blaue ohne

[Fup]

Ja du hast schon recht, VorlNr kommt dann überhaupt nicht mehr vor. Das ist aber für den Kandidatenschlüssel auch notwendig, da er minimal sein soll und VorlNr nicht dazu beiträgt.

Im Buch auf S. 178 steht auch "... diese FD ist linksreduziert".

Genau, dadurch, dass VorlNr jetzt nicht mehr vorhanden ist, muss man eine neue Relation erstellen.

[maxx]

hier gibts eine wirklich gute beschreibung in sehr einfachen worten:

http://de.wikipedia.org/wiki/Normalisierung
hoffe sie hilft euch weiter

[sneaky]

hier gibts eine wirklich gute beschreibung in sehr einfachen worten:

http://de.wikipedia.org/wiki/Normalisierung
hoffe sie hilft euch weiter

danke für den link, der war echt superhilfreich!! :thumb:

weil ich mir noch nicht ganz sicher bin, hab ich das 2NF beispiel vom Jänner 03 A gemacht, stimmt das so?


Student(Martrikelnummer, StudentVorname, StudentNachname)
Note(LVANr, Martrikelnummer, Note)


:confused: :confused: :confused: