Datenbanken Normalform CHAOS

Diskutiere Datenbanken Normalform CHAOS im Plauderecke Bereich.

Bitte aktiviere JavaScript!
O

ocsme

Guten Tag zusammen,
leider wusste ich derzeit nicht wohin mit diesem Post.
Ich habe ein verständnis Problem zu den Normalformen in Datenbanken.
Hier einmal ein Aufgaben Beispiel:

Gegeben sei das Relationenschema "R" mit folgenden, atomaren Attributen:
R: {[PersNr, Name, Rang, Raum, VorlNr, VorlTag, Hörsaal, AssiPersNr, AssiName, HiwiMatrNr]}
Für R gelten folgende FDs (fnktionalen Abhängigkeiten):
1. PersNr -> Name, Rang, Raum
2. Raum -> PersNr
3. VorlNr -> PersNr
4. VorlNr, VorlTag -> Hörsaal
5. AssiPersNr -> AssiName, PersNr
6. HiwiMatrNr -> AssiPersNr
Frage: In welcher Normalform befindet sich das Relationenschema R?
1. Normalform: Das Schema befindet sich in der ersten Normalform da diese Verlangt das alle Attribute atomar sein sollen.

So nun komme ich schon nicht mehr wirklich weiter. Denn die 2te Normalform sagt ja aus:
Definition 2te Normalform:
wenn die Tabellen in der ersten Normalform sind und wenn zusätzlich alle Nichtschlüssel-Attribute voll funktional vom Primärschlüssel abhängig sind. Umgekehrt formuliert heißt dies: Eine Tabelle ist noch nicht in zweiter Normalform, wenn sie einen zusammengesetzten Primärschlüssel hat und ein Nichtschlüssel-Attribut nicht vom ganzen Primärschlüssel, sondern nur von einem Teilschlüssel abhängt.
Der Schlüssel für das Schema sieht wie folgt aus: (HiwiMatrNr, VorlNr, VorlTag) -> R.
Nun würde ich aber behaupten dass das Schema nicht in der 2ten Normalform ist da:
VorlNr, VorlTag -> Hörsaal
Hier wird ein Nichtschlüssel-Attribute nur von einem Teil des Primärschlüssel funktional bestimmt.

Nun habe ich aber gelesen das:
In diesem Fall wird das Nichtschlüssel-Attribut mit dem Primärschlüssel-Teil, von dem es funktional abhängig ist, in eine eigene Tabelle herausgezogen.
Das wäre hier ja der Fall. Denn VorlNr -> PersNr würde auch gegen die 2te Normalform verstoßen. Doch auch hier wurde ja der Teil des Primärschlüssels mit dem Nichtschlüssel-Attribut in eine Tabelle geschrieben.
Dadurch würde ich an dieser Stelle sagen das die drei Tabellen hier keine Probleme verursachen im Sinne der 2ten Normalform:
HiwiMatrNr -> AssiPersNr
VorlNr -> PersNr
VorlNr, VorlTag -> Hörsaal

Nun würde ich behaupten das die 2te Normalform erfüllt ist für das Relationenschema nun prüfen wir auf die 3te Normalform:
Definition 3te Normalform:
Die dritte Normalform verlangt, dass ein Relationenschema in der 2. NF ist und kein Nicht-Schlüsselattribut von einem anderen Nicht-Schlüsselattribut funktional abhängig ist.
Das würde ich nun so verstehen das hier nun das Problem ist mit:
Raum -> PersNr
AssiPersNr -> AssiName, PersNr
PersNr -> Name, Rang, Raum

Denn diese 3 FDs sind links wie rechts Nichtschlüssel-Attribute, diese dürfen in der 3ten Normalform nicht existieren.

Ist das so korrekt? Oder habe ich hier misst verstanden?
Beziehen sich die Normalformen immer auf den Primärschlüssel? Denn man liest so oft von Schlüssel, Primärschlüssel oder auch Superschlüssel. Ich dachte das die Superschlüssel nur eine Teilmenge der Schlüsselkandidaten sind und diese wieder eine Teilmenge von Primärschlüssel anders gesagt:
Superschlüssel:
Menge von Attributen (Feldern) in einer Relation (Tabelle), die die Tupel (Zeilen) in dieser Relation eindeutig identifizieren
Schlüsselkandidat (Kandidatenschlüssel):
Eine minimale Teilmenge der Attribute eines Superschlüssels (Schlüsselkandidaten ⊆ Superschlüssel).
Primärschlüssel:
Der ausgewählte Schlüsselkandidat, der in Folge für die Abbildung der Relationen verwendet wird.
Wenn der Post hier Falsch ist wäre ich sehr Dankbar Ihn woanders hin zu verschieben :)
 
mihe7

mihe7

So nun komme ich schon nicht mehr wirklich weiter.
Der Hörsaal wird von VorlNr, VorlTag bestimmt - ein zusammengesetzter Schlüssel. PersNr nur von einem Teil des Schlüssels VorlNr. Damit ist die 2. NF nicht erfüllt.

Nun würde ich behaupten das die 2te Normalform erfüllt ist für das Relationenschema nun prüfen wir auf die 3te Normalform
Wenn die 2. NF nicht erfüllt ist, ist auch die 3. NF nicht erfüllt.
 
O

ocsme

Der Hörsaal wird von VorlNr, VorlTag bestimmt - ein zusammengesetzter Schlüssel. PersNr nur von einem Teil des Schlüssels VorlNr. Damit ist die 2. NF nicht erfüllt.
Deswegen hab ich ja geschrieben das ich das hier gelesen habe:
In diesem Fall wird das Nichtschlüssel-Attribut mit dem Primärschlüssel-Teil, von dem es funktional abhängig ist, in eine eigene Tabelle herausgezogen.

Denn wir haben eine ähnliche Aufgabe. Dort ist der Primärschlüssel auch ein aus 3 Attributen zusammengesetzer Schlüssel und auch dort wird der Hörsaal von VorlNr, VorlTag bestimmt. Doch durch den Synthese Algorithmus wäre das dann "angeblich" in der 3ten Normalform.
Hier mal das Beispiel mit dem Synthese Algorithmus:
FDs:
PersNr -> Name, Rang, Raum
AssiPersNr -> AssiName
Raum -> PersNr
VorlNr -> PersNr
VorlNr, VorlTag -> Hörsaal
DiplomatenMatrNr -> AssiPersNr

Nach anwendung des Synthese Algorithmus haben wir:
Tabelle Profs: PersNr, Name, Rang, Raum
Tabelle Assi: AssiPersNr, AssiName
Tabelle Vorlesungen: VorlNr, PersNr
Tabelle Stundenplan: VorlNr, VorlTag, Hörsaal
Tabelle Diplomanten: DiplomantenMatrNr, AssiPersNr
Schlüssel für dieses Relationenschema: DiplomantenMatrNr, VorlNr, VorlTag

Das ganze in FDs geschrieben ergibt Trivialerweise dieses:
PersNr -> Name, Rang, Raum
AssiPersNr -> AssiName
VorlNr -> PersNr
VorlNr, VorlTag -> Hörsaal
DiplomantenMatrNr -> AssiPersNr

Primärschlüssel: DiplomantenMatrNr, VorlNr, VorlTag

Mit der Argumentation von oben wäre der Synthese Algorithmus hier ja nun fehlerhaft! Denn auch hier könnte man nun Argumentieren das VorlNr, VorlTag -> Hörsaal (Hörsaal von einem zusammengesetzten Schlüssel funktional abhängig ist).
Für die 3te Normalform wird die 2te Normalform vorausgesetzt.
Wo ist der Fehler?
Ich verstehe mal wieder nur noch Bahnhof :(
 
Zuletzt bearbeitet:
H

httpdigest

Deswegen hab ich ja geschrieben das ich das hier gelesen habe:
In diesem Fall wird das Nichtschlüssel-Attribut mit dem Primärschlüssel-Teil, von dem es funktional abhängig ist, in eine eigene Tabelle herausgezogen.
Das ist der Schritt, den man tun muss, um eben die 2. Normalform zu erreichen. Das heißt nicht, dass das hier getan wurde.
Der Satz hätte lieber so lauten sollen:
Um in diesem Fall die 2. Normalform zu erreichen, muss das Nichtschlüssel-Attribut mit dem Primärschlüssel-Teil, von dem es funktional abhängig ist, in eine eigene Tabelle herausgezogen werden.
 
O

ocsme

achso.
Also wenn man wie im ersten Beispiel ein Relationenschema bekommt was so aussah ist es in der 1ten Normalform und nicht in der 2ten. Denn dort sind ja mehrere Nichtschlüssel-Attribute von nur einer Teilmenge des Primärschlüssels abhängig.

Wenn man das ganze nun "heilt" sieht es zwar immer noch so aus als wäre es nicht für die 2te Normalform genüge, doch durch das anwenden des Synthese Algorithmus weiß man ja es sollte in der 3ten Normalform sein :)

Hab ich das so weit richtig verstanden?

Oh und wieder Verwirrung:
Die BCNF verlangt, dass ein Relationenschema in der 3 NF ist und des weiteren auch keine funktionalen Abhängigkeiten zu nur einem Teil eines Schlüssels bestehen.
Das bezieht sich nun auf das "heilen" der Tabellen oder? Also das in der 3ten Normalform es immer noch FDs gibt die nur zu einem Teil des Primärschlüssels abhängig sind oder?
Damit wäre dieses Beispiel hier:
PersNr -> Name, Rang, Raum
AssiPersNr -> AssiName
VorlNr -> PersNr
VorlNr, VorlTag -> Hörsaal
DiplomantenMatrNr -> AssiPersNr

Nicht in der BCNF. Da
VorlNr -> PersNr und
VorlNr, VorlTag -> Hörsaal und
DiplomantenMatrNr -> AssiPersNr
nur von einem Teil des Primärschlüssels abhängig sind!
PersNr und AssiPersNr muss man dazu nicht weiter betrachten oder?
 
Zuletzt bearbeitet:
mihe7

mihe7

Hab ich das so weit richtig verstanden?
Du machst das viel zu kompliziert. Es gibt Normalformen und für eine Relation kann angegeben werden, in welcher NF sie vorliegt. Wenn eine Relation eine NF verletzt, kann man sich überlegen, was man tun muss, damit das nicht mehr der Fall ist.

Damit wäre dieses Beispiel hier:
PersNr -> Name, Rang, Raum
AssiPersNr -> AssiName
VorlNr -> PersNr
VorlNr, VorlTag -> Hörsaal
DiplomantenMatrNr -> AssiPersNr
... nicht in der 2. NF, somit auch nicht in der 3. NF und somit auch nicht in BCNF...

Dazu musst Du nur

VorlNr -> PersNr
VorlNr, VorlTag -> Hörsaal

betrachten. Die erste Abhängigkeit bedeutet, dass die Vorlesung die PersNr bestimmt. Eine Vorlesung wird also nicht von verschiedenen Dozenten gehalten, sondern nur von einem. Natürlich kann ein Dozent verschiedene Vorlesungen halten. Die zweite Abhängigkeit bedeutet, dass eine Vorlesung an einem Vorlesungstag nur in einem Hörsaal stattfindet.

Würde man das jetzt in eine Tabelle klatschen, wie würde diese aussehen? Der Dozent mit der PersNr 4711 würde mit Vorlesung 42 am Tag 1 den Hörsaal 5 belegen, am Tag 2 den Hörsaal 6.
PersNrVorlNrVorlTagHörsaal
47114215
47114226
47114235
47114445
48124317
48124325

Für jeden Termin muss also die Personalnummer wiederholt werden, obwohl diese durch die VorlNr bereits bestimmt wird. Daher ist die 2. NF verletzt, denn die Tabelle enthält zwei.

Wir können also einen Vorlesungskatalog aufstellen:

VorlNrPersNr
424711

und einen Terminplan angeben:
VorlNrVorlTagHörsaal
4215
4226

Schon wird die Personalnummer nicht mehr wiederholt.
 
O

ocsme

Achso hab ich das Falsch aufgeschrieben?
Also wenn man sich die Funktionalen Abhängigkeiten so anschaut:
PersNr -> Name, Rang, Raum
AssiPersNr -> AssiName
VorlNr -> PersNr
VorlNr, VorlTag -> Hörsaal
DiplomantenMatrNr -> AssiPersNr
Ist es nicht mal in der 2ten Normalform wegen wie oben schon 2x beschrieben THX @mihe7

Doch wir haben ja nach dem Synthese Algorithmus diese Tabellen:
Profs mit folgenden Spalten: PersNr, Name, Rang, Raum
Assis mit folgenden Spalten: AssiPersNr, AssiName
Vorlesungen mit folgenden Spalten: VorlNr, PersNr
Stundenplan mit folgenden Spalten: VorlNr, VorlTag, Hörsaal
Diplomanten mit folgenden Spalten: DiplomantenMatrNr, AssiPersNr

Dann wäre es ja genauso wie du es oben Beschrieben hast :)
Nun ist das Relationenschemata R in der 3ten Normalform oder?
 
mihe7

mihe7

Dann wäre es ja genauso wie du es oben Beschrieben hast :)
Ja, wobei meine Transformation erst einmal zur 2. NF führt. Beispielsweise wäre DiplomantenMatrNr, AssiPersNr, AssiName in der 2. NF. Das Schema hätte als einzigen Schlüssekandidaten DiplomantenMatrNr. Hier ist die 3. NF verletzt, denn AssiName ist transitiv von DiplomantenMatrNr abhängig (DiplomantenMatrNr -> AssiPersNr -> AssiName). Am Ende erhältst Du die von Dir angegebenen Schemata.

Achso hab ich das Falsch aufgeschrieben?
Den Abschnitt hatte ich aus #5 und nicht aus #3 genommen :(
 
O

ocsme

Danke für deine Mühe.
Dann war es mein Fehler weil ich hier mit 1000 verschiedenen Schreibweisen um mich werfe :(
Ich denke ich habe das nun so weit verstanden. Hoffentlich :D

Was ich noch nicht verstehe ist die Dekomposition von Relationen. Also das Zerlegen.
Wir haben Beispielsweise ein Relationenschemata gegeben {A, B, C, D,E} für dieses gelten die folgenden FDs:
A,B,C -> E
A -> B
D -> E
Das Schema wird nun in zwei Schmata Zerlegt
R1 = {A,B,C} und R2 = {C,D,E}
a) Ist diese Zerlegung verlustfrei?
b) Ist diese Zerlegung abhängigkeits-bewahrend ?

Was muss ich dafür tun also wie geht man bei so etwas vor?

Kann mir das jemand vielleicht erklären?
 
mihe7

mihe7

Achtung, mit Vorsicht zu genießen:

a) verlustfrei würde bedeuten, dass Du die ursprüngliche Relationen durch einen Join wiederherstellen könntest. Das ist hier nicht der Fall, denn das einzig gemeinsame Attribut wäre C; von C alleine ist aber kein anderes Attribut funktional abhängig. Es müsste C->D,E gelten, damit die Abbildung verlustfrei wäre.

b) "abhängkeits-bewahrend"... A,B,C -> E kann weder durch R1 noch durch R2 dargestellt werden. Folglich geht diese Abhängigkeit durch die Zerlegung verloren.
 
O

ocsme

Danke für die gute Erklärung. Ob ich das so wirklich verstanden hab ist eine andere Frage. Leider finde ich auch keine wirklich andere Aufgaben zu diesem Thema :(

Was wäre wenn in FD 1 das hier stehen würde? A, B, C -> D,E
Dann wären die beiden Schema doch verlustfrei oder? Also ich meine WENN es so wäre:
FD 1: A,B,C -> D,E
FD 2: A -> B
FD 3: D -> E
und die Schema gleich: R1 = {A,B,C} und R2 = {C,D,E}
Ist diese dann noch verlustfrei? Auch wenn A,B,C -> D,E gilt?
Denn wenn ich jetzt so überlege und würde von C -> D,E die Attributehülle bilden ist diese wieder eine Teilmenge von FD1.

abhängkeits-bewahrend wäre dieses Schema aber immer noch nicht (würde ich nun sagen), da man immer noch nicht FD1 auf R1 noch auf R2 darstellen kann.

Wäre das korrekt?
Glaube das ist auch Falsch denn du hast oben ja geschrieben das von dem Attribute C alleine keine anderen Attribute funktional abhängig sind! Also damit es verlustfrei wäre müsste man nur das so machen:
FD 1: A,B,C -> D,E
FD 2: A -> B
FD 3: D -> E
FD 4: C -> D,E


Wenn man eine Menge an FDs bekommen hat, kann man dann die Zerlegung berechnen? Das basiert doch alles auf der Mengenlehre somit ist das ganze doch Mathematik das sollte doch irgendwie funktionieren oder?
 
Zuletzt bearbeitet:
O

ocsme

Ich hab noch eine Aufgabe bei der bin ich nun total Verwirrt!

Folgendes Relationenschema sei gegeben: R : {[A,B,C,D,E,F,G,H,I,J]}
Folgende FDs stellen eine minimale Basis zu R dar:
1. E,F -> G
2. A -> B,C,D
3. D -> A
4. E -> A
5. J -> H
6. H -> I,A

Der Primärschlüssel sollte dann A,E,F,J sein.

1. Frage von mir ist das eine Minimale Basis? Denn J -> H -> I, A ist doch Transitiv kann man das H dann nicht weg lassen?

a) Geben Sie eine Zerlegung an, bei der die zerlegten Schemata in der 3. Normalform sind:

aus FD1 folgt R1: {[E,F,G]}
aus FD2 und FD3 folgt R2: {[A,B,C,D]}
aus FD4 folgt R3: {[E,A]}
aus FD5 folgt R4: {[J,H]}
aus FD6 folgt R5: {[H,I,A]}
2. Stimmt das?

b) Gilt für Ihre Zerlegung auch, dass alle zerlegten Relationen in der BCNF sind?

Bei der BCNF werden nur noch noch (Super-)Schlüsselabhängigkeiten erlaubt.
Ist der BCNF genüge wenn auch etwas nur zum Teil des Primärschlüssels abhängig wäre?
Doch hier würde ich sagen das so die BCNF nicht erfüllt ist denn H -> I,A H ist kein Schlüsselattribut!

Ich verstehe hier echt nur noch Bahnhof :(
 
Zuletzt bearbeitet:
mihe7

mihe7

Was wäre wenn in FD 1 das hier stehen würde? A, B, C -> D,E
Dann wären die beiden Schema doch verlustfrei oder?
Nein. Wie immer: Visualisieren! Hier mal einfach mit einem konkreten Beispiel.

Schema {RECHNR, KDNR, RECHPOS, ARTNR, PREIS} soll zerlegt werden. Es gilt

FD1: RECHNR, KDNR, RECHPOS -> ARTNR, PREIS
FD2: RECHNR -> KDNR
FD3: ARTNR -> PREIS

Jetzt zerlegst Du in {RECHNR, KDNR, RECHPOS} und {RECHPOS, ARTNR, PREIS}. Wie um alles in der Welt willst Du hier die Ursprungstabelle mit einem JOIN wiederherstellen? Und ja, FD1 ist verloren.

Also damit es verlustfrei wäre müsste man nur das so machen:
Jein, "machen"... Du kannst ja nicht nach belieben funktionale Abhängigkeiten einführen. Das würde für das konkrete Beispiel bedeuten: hey, die Zerlegung ist nicht verlustfrei, also bestimme ich mal eben, dass RECHPOS->ARTNR, PREIS gilt.

Umgekehrt wird ein Schuh draus: würde RECHPOS->ARTNR, PREIS gelten, dann wäre die Zerlegung verlustfrei. Tut es aber nicht. Du kannst aber eine verlustfreie Zerlegung angeben: {RECHNR, KDNR, RECHPOS, ARTNR}, {ARTNR, PREIS} wegen ARTNR->PREIS.

1. Frage von mir ist das eine Minimale Basis?
Was verstehen die unter Basis? Ich kenne halt die Menge der funktionalen Abhängigkeiten Fd und die Menge der von FD implizierten Abhängigkeiten (Closure F⁺)

Denn J -> H -> I, A ist doch Transitiv kann man das H dann nicht weg lassen?
Nein. Wie oben: eine FA sucht man sich nicht einfach aus. Sie existiert oder eben nicht.

Eine Rechnung wird für einen einzigen Kunden ausgestellt. Daraus ergibt sich eine funktionale Abhängigkeit Rechnung -> Kunde: gib mir eine Rechnung und ich kann Dir eindeutig sagen, welcher Kunde gemeint ist.

Eine Rechnung enthält mehrere Positionen -> hier gibt es keine funktionale Abhängigkeit, denn es kann ja mehrere Positionen zu einer Rechnung geben. Sprich: gibst Du mir eine Rechnung kann ich Dir noch lange nicht sagen, ob nun Position 1, 2 oder 5 gemeint ist.

Die Position ist erst durch die Kombination aus Rechnung und Position bestimmt. Kenne ich aber Rechnung und Position, dann kann ich Dir eindeutig sagen, welcher Artikel gemeint ist: Rechnung, Position -> Artikel und wegen Artikel -> Preis kann ich Dir sogar sagen, welcher Preis gemeint ist.
 
O

ocsme

Minimale Basis = kanonische Überdeckung.

Dann sollten aus #13 meine Zerlegung aber doch korrekt sein wenn ich das nun richtig verstanden habe.
Nur würde ich jetzt sagen das es auch in der BCNF ist weil H -> I, A und wenn A ein Kandidatenschlüssel ist, ist H auch einer und somit sind alles Kandidatenschlüssell.

Denn in einer "Lösung" zu dieser Aufgabe wurde bei der Zerlegung aus den beiden FDs
5. J -> H
6. H -> I,A

Die Tabellen:
aus FD5 folgt R4: {[J,A]}
aus FD6 folgt R5: {[I,A]}

Ist so etwas Korrekt? Wenn Ja wieso? Denn ich hätte gesagt das geht nicht. Denn dann dürfte man ja auch an den FDs:
2. A -> B,C,D
3. D -> A

rum spielen.

Der Post #13 verwirrt mich total :( Jetzt habe ich dieses Semester schon die C Programmierung sein lassen wenn jetzt auch noch Einführung in Datenbanken nicht klappt wäre das echt doof :(:eek:
 
mihe7

mihe7

Der Primärschlüssel sollte dann A,E,F,J sein.
Das A ist wegen E->A zu viel.

Ist so etwas Korrekt? Wenn Ja wieso?
Nein, das H kann ja nicht einfach unter den Tisch fallen gelassen werden. {J,H,I,A} mit Primärschlüssel J kann wegen 6. nicht in 3. NF sein.

Das ist wie im Beispiel oben, wenn man den Artikel noch um die Bezeichnung erweitert und J=(RECHNR, RECHPOS) wählt:

(RECHNR, RECHPOS)->ARTNR (entspricht J->H) und ARTNR -> ARTBEZ, PREIS

ARTBEZ, PREIS sind keine Schlüsselattribute aber von (RECHNR, RECHPOS) transitiv abhängig. Damit kann das Schema {RECHNR, RECHPOS, ARTNR, ARTBEZ, PREIS) nicht in der 3. NF sein. Die Schemata {RECHNR, RECHPOS, ARTNR} und {ARTNR, ARTBEZ, PREIS} schon.
 
O

ocsme

Okay hoffe ein aller Letzes mal. Das ist wieder die Aufgabe aus #13 Hoffe nur jetzt Richtig.

Folgendes Relationenschema sei gegeben: R : {[A,B,C,D,E,F,G,H,I,J]}
Folgende FDs stellen eine minimale Basis zu R dar:
1. E,F -> G
2. A -> B,C,D
3. D -> A
4. E -> A
5. J -> H
6. H -> I,A
Der Primärschlüssel sollte dann E,F,J sein.

a) Geben Sie eine Zerlegung an, bei der die zerlegten Schemata in der 3. Normalform sind:
aus FD1 folgt R1: {[E,F,G]}
aus FD2 und FD3 folgt R2: {[A,B,C,D]}
aus FD4 folgt R3: {[E,A]}
aus FD5 folgt R4: {[J,H]}
aus FD6 folgt R5: {[H,I,A]}

b) Gilt für Ihre Zerlegung auch, dass alle zerlegten Relationen in der BCNF sind?
In der BCNF ist das Schmea nicht denn E->A ist nur von einem Teil des Schlüssels abhängig.

_____
So als ich b) gerade beantwortet habe, stelle ich mir schon wieder die Frage, das Teil ist doch nicht mal in der 3ten Normalform? Obwohl nach dem Synthese Algorithmus das Schema doch in der 3ten Normalform vorhanden sein soll.
Ich drehe mich nur noch im Kreis hab keine Lust mehr auf den misst hier!!!
Das gibt wohl keinen mehr obwohl das ganze sicherlich ein sehr Zentrales und wichtiges Thema ist naja!
 
O

ocsme

das geht überhaupt nicht.
h->i,a bekomme ich aber auch nicht gejoint! :rolleyes:
Muss da jetzt noch ein E mit rein? J,H,E
 
Zuletzt bearbeitet:
mihe7

mihe7

Vielleicht nochmal ausführlich. Wir haben ein Relationenschema {A,B,C,D,E,F,G,H,I}, d. h. die Tupel sind Elemente der Menge A x B x ... x H x I

Welche Attribute sind mindestens notwendig, um ein Tupel eindeutig zu identifizieren?

FD1 bedeutet, dass (E,F) die Werte von G bestimmt.
FDs 2 und 4 bedeuten, dass ein E die Werte für A, B, C, D bestimmt.
FDs 5 und 6 bedeuten, dass ein J die Werte für H, I, A bestimmt.

(wobei "X bestimmt Werte für Y" bedeutet: aus zwei gleichen Werten in X folgen zwangsweise gleiche Werte in Y)

Wir brauchen also mindestens E, F und J, um ein Tupel zu identifizieren, daher können wir schon mal eine erste Zerlegung angeben: {E,F,J} und die Details dazu {E,A,B,C,D}, {E,F,G} und {J,H,I,A} (Schlüsselfelder fett).

{E,F,J} muss in der 3. NF sein, da es einfach ein zusammengesetzter Schlüssel ist.

{E,A,B,C,D} verletzt die 3. NF, wegen der transitiven Abhängigkeit E->A, A->B,C,D. Kann man aufteilen: {E,A},{A,B,C,D}; die sind in der 3. NF

{E,F,G} ist in der 3. NF.

{J,H,I,A} verletzt die 3. NF, wegen der transitiven Abhängigkeit J -> H, H->I,A. Kann man aufteilen {J,H}, {H,I,A}; die sind in der 3. NF.

Ingesamt: {E,F,J}, {E,A}, {E,F,G}, {J,H}, {A,B,C,D}, {H,I,A}

Die Relation R lässt sich als JOIN über die Zerlegung darstellen. Die FDs gelten alle weiterhin:
{E,F,G}: E,F -> G
{A,B,C,D}: A -> B,C,D und D->A
{E,A}: E->A
{J,H}: J->H
{H,I,A}: H->I,A

Die Zerlegung verletzt auch nicht die BCNF, denn es gibt kein Schema mit mehr als einem zusammengesetzten Schlüsselkandidaten.
Das einzige Schema, das mehr als einen Schlüsselkandidaten besitzt, ist {A,B,C,D}. Dort ist die Identifizierung eines Tupels sowohl über A als auch über D möglich - allerdings ist weder A noch D ein zusammengesetzter Schlüssel, so dass sich diese schlecht überlappen können.

Umgekehrt gibt es zwei Schemata mit zusammengesetztem Schlüssel, {E,F,J} und {E,F,G}, die haben aber nur jeweils einen Sclüsselkandidaten.
 
O

ocsme

Entschuldigung das ich mich jetzt erst melde :( Ich hab es natürlich nicht vergessen!

Ich muss das Thema noch mal komplett wiederholen. Verstehe zwar ansatzweise deine super Erklärung aber so richtig macht es einfach noch nicht klick :(

Was ich mich auch gerade Frage ist das die FDs gegen die 2ten Normalform verstoßen :(
Denn {E,F,J} ist doch der Primärschlüssel für das Relationenschemata. Nun ist aber mit der FD E,F -> G Ein nichtschlüssel-Attribut abhängig von nur einem Teil des Primärschlüssels oder sehe ich das schon wieder falsch.

Auf was bezieht sich das Wort Primär-Schlüssel denn dann?
Die zweite Normalform verlangt, dass jedes Nichtschlüssel-Attribut voll
funktional abhängig ist vom Primärschlüssel der Relation.
Irgendwie komme ich mit den ganzen Schlüssel begriffen nicht klar.
Die 2te Normalform verlangt den Primärschlüssel der Relation. Ist das nun der Primärschlüssel des Relationenschemata also wie oben E,F,J? Oder bezieht sich der Satz nur auf den Schlüssel der einen Relation (Tabelle)? Doch wieso sollte eine Tabelle mehrere Schlüssel besitzen. Ich bin total verwirrt o_O
 
Zuletzt bearbeitet:
O

ocsme

Guten Tag zusammen,

ich versuche mein Problem mal in "meinen" Worten zu fassen und vielleicht gibt es hier ja noch jemand der mir versucht zu Helfen, wenn nicht bleib ich eben Verwirrt :rolleyes:

1. Normalform Definition:
Die erste Normalform verlangt, dass alle Attribute atomare Wertebereiche (Domänen) haben.
Es dürfen keine Wertebereiche existieren die Mehrwertig sind wie z. B. Name = {Vorname, Nachname, Titel, Anrede, etc.}

2. Normalform Definition:
Die zweite Normalform verlangt, dass jedes Nichtschlüssel-Attribut voll funktional abhängig ist vom Primärschlüssel der Relation.
Es darf kein Nichtschlüssel-Attribut geben das nur von einer Teilmenge des Primärschlüssel funktional abhängig ist.
Hierzu eine Frage, wenn das Relationenschemata gegen die 2te Normalform verstößt kann man das Relationenschemata trotzdem in die 2te Normalform bringen, indem man diese Funktionale Abhängigkeit in eine eigene Tabelle (Relation) schreibt.
Nehmen wir an wir hätten für das Relationenschemata R den Primärschlüssel: {A,B,C} und diese FD:
A,B -> D,E,F
Hier wäre jetzt die 2te Normalform verletzt. Reicht es nun das ganze in eine Tabelle zu schreiben oder muss man das aufspalten? Also mit aufspalten meine ich:
A,B -> D
A,B -> E
A,B -> F
Dann müsste man so viele Tabellen erstellen wie nichtschlüssel-Attribute an der FD hängen.
Des weiteren was wäre wenn wir noch die FD C -> G hätten. Diese ist ja auch nur von einem Teil des Primärschlüssels abhängig somit verstoß gegen die 2te Normalform!

3. Normalform Definition:
Die dritte Normalform verlangt, dass ein Relationenschema in der 2. NF ist und kein Nicht-Schlüsselattribut von einem anderen Nicht-Schlüsselattribut funktional abhängig ist.
In dieser Normalform fliegen nun alle Nicht-Schlüsselattribute auf der linken Seite raus. Somit auch alle Transitiven Abhängigkeiten.

BCNF Definition:
Die BCNF verlangt, dass ein Relationenschema in der 3 NF ist und des weiteren auch keine funktionalen Abhängigkeiten zu nur einem Teil eines Schlüssels bestehen.
Hier würde ich sagen wenn wir schon nicht in die 2te Normalform gekommen sind und es "geheilt" haben, dadurch das wir diese Abhängigkeiten die gegen die 2te Normalfrom verstoßen in eine eigene Relation stecken, kommen wir NIE in die BCNF.
Denn da durch wird es immer Teilschlüssel Abhängigkeiten geben oder?
Das würde voraussetzen wenn wir untersuchen sollen in welcher Normalform das Schemata vorliegt und es nicht der 2ten Normalform gerecht wird das wir maximal bis in die 3te Normalform kommen. Wenn wir FDs bekommen die in der 3ten Normalform sind und mehrere Teilmengen des Primärschlüssels links stehen werden wir Nie in die BCNF kommen?
 
mihe7

mihe7

Reicht es nun das ganze in eine Tabelle zu schreiben
Ja.
Des weiteren was wäre wenn wir noch die FD C -> G hätten
Das gleiche.

Aus {A,B,C,D,E,F,G} wird z. B. wegen A,B->D,E,F zunächst {{A,B,C,G}, {A,B,D,E,F}} und wegen C->G dann {{A,B,C},{C,G},{A,B,D,E,F}}

In dieser Normalform fliegen nun alle Nicht-Schlüsselattribute auf der linken Seite raus.
Was heißt auf der linken Seite?

kommen wir NIE in die BCNF.
Denn da durch wird es immer Teilschlüssel Abhängigkeiten geben oder?
Doch. Bei der 2. NF geht es nur darum, dass jedes NSA nicht von Teilen des Schlüssels abhängig ist. Bei der BCNF geht es darum, dass kein Teil (EDIT: muss natürlich alle Teile heißen) des Schlüssels nur von solchen Attributen abhängig sein dürfen, die selbst Schlüsselkandidat sind. Ich finde es sehr schwer, hier geeignete Beispiele zu finden. Fiktiv: {A,B,C} mit A,B -> C und C->A wäre eine Verletzung, da A von C abhängig, C aber kein Schlüsselkanidat ist.
 
O

ocsme

Denke das hier hat einiges Entwirrt :)
Die 3 Tabellen {A,B,C},{C,G},{A,B,D,E,F}, die Tabelle {A,B,C} ist nur entstanden damit man von der einen auf die anderen Joinen kann sprich Thema: Verlustfrei.

Was heißt auf der linken Seite?
Echt doof formuliert von mir mhhh... Wenn wir einige FDs bekommen einer von diesen funktional zu einem Nichtschlüssel-Attribut abhängig ist, ist das Schema nicht in der 3ten Normalform.
Demnach sind FDs: Nichtschlüssel-Attribut -> Nichtschlüssel-Attribut ein Verstoß gegen die 3te Normalform.
Da dachte ich sofort an die transitivitäts Regel denn
A -> B
B -> C, D
B wäre in diesem falle kein Schlüssel dann dürfte doch B -> C, D ein Verstoß gegen 3te Normalform sein.

Was mir jetzt wieder einfällt ist was passiert wenn wir einen Mix hätten. Keine Ahnung ob so etwas überhaupt funktioniert.
Sagen wir A = Schlüssel und es gilt z. B. diese FD (B und C sind nicht Schlüssel-Attribute):
B -> A, C
Würde sagen das verstoßt auch gegen die 3te Normalform auch wenn 1 Schlüssel-Attribut dabei ist.

Was ich hier jetzt nicht verstehe ist du schreibst Kandidaten-Schlüssel. Ich dachte das wenn der Schlüssel z. B. {A,B,C} wäre und wir diese FDs hätten:
A -> I
B -> K
C -> Z
Dann haben wir 3 funktionale Abhängigkeiten die nur zu einem Teil des Schlüssels bestehen somit nicht BCNF.

Nun habe ich mal wieder die Definition gelesen und erkannt da steht:
Die BCNF verlangt, dass ein Relationenschema in der 3 NF ist und des weiteren auch keine funktionalen Abhängigkeiten zu nur einem Teil eines Schlüssels bestehen.
Eines Schlüssels, einer von mehreren! Die Kandidaten Schlüssel?
Wenn ich das richtig verstanden habe dann dürfen auf der Linken Seite der Funktionalen Abhängigkeiten nur noch superschlüssel stehen oder?

Danke nochmals das du mir versuchst das so zu erklären.
 
Zuletzt bearbeitet:
mihe7

mihe7

Demnach sind FDs: Nichtschlüssel-Attribut -> Nichtschlüssel-Attribut ein Verstoß gegen die 3te Normalform.
Ja.

Sagen wir A = Schlüssel und es gilt z. B. diese FD (B und C sind nicht Schlüssel-Attribute):
B -> A, C
Würde sagen das verstoßt auch gegen die 3te Normalform auch wenn 1 Schlüssel-Attribut dabei ist.
Ja.

Was ich hier jetzt nicht verstehe ist du schreibst Kandidaten-Schlüssel
Ein Relation kann ja mehrere Attributmengen besitzen, die einen Satz eindeutig identifizieren. Zum Beispiel kannst Du eine Kundennummer und eine UUID haben. Beide identifizieren den Kunden eindeutig, so dass sowohl die Kundennummer als auch die UUID als Schlüssel in Frage kommen -> Schlüsselkandidaten.

Dann haben wir 3 funktionale Abhängigkeiten die nur zu einem Teil des Schlüssels bestehen somit nicht BCNF.
Die wären aber noch nicht mal in der 2. NF :)

Eines Schlüssels, einer von mehreren! Die Kandidaten Schlüssel?
Ja.

Wenn ich das richtig verstanden habe dann dürfen auf der Linken Seite der Funktionalen Abhängigkeiten nur noch superschlüssel stehen oder?
Ja oder triviale Abhängigkeiten. Ich sehe gerade, dass die englische Version von Wikipedia da schöne Erklärungen und Beisipiele hat. https://en.wikipedia.org/wiki/Boyce–Codd_normal_form und https://en.wikipedia.org/wiki/Third_normal_form
 
O

ocsme

Okay dann würde ich sagen lassen wir es mal an dieser Stelle gut sein :)
Werde weiter zu dem Thema recherchieren und lernen, sollte ich noch weiter Fragen haben melde ich mich hier erneut :)

Danke das du so hartnäckig an der Sache geblieben bist und es mir so verständlich erklärt hast :) @mihe7
 
Thema: 

Datenbanken Normalform CHAOS

Passende Stellenanzeigen aus deiner Region:
Anzeige

Neue Themen

Anzeige

Anzeige
Oben