ER-Diagramm -> Relationenschema (Bsp 4 aus Musterlösung vo200206)

[Tiniiiii]

Zu Bsp 4 aus Musterlösung vo200206 (http://www.dbai.tuwien.ac.at/education/dm/ )

Hab anbei ein gif gepostet um mein Problem besser darzustellen: Ich check die eingeringelten Relationen nicht ganz ...

Warum ist bei gezeigt_auf nicht alles kursiv (weak)
und warum ist bei A-Termin Beginn auch weak???

Ist da vielleicht ein Fehler drin oder bin ich total daneben? :ausheck:

Würde mich sehr freuen wenn mir jemand dabei helfen könnte!

Thanx & lg

[Sensei]

heißt kursiv das es von einer weak-entity kommt oder was? dann is bei der angabe zum ersten UE-Bsp 2003 auch ein Fehler... Level is in Relation Kunde kursiv.


grr.... ich check das nicht, wann ein Fremdattribut als Schlüssel übernommen wird, und wann als kursives Attribut. Kann da wer weiterhelfen?

[Tiniiiii]

heißt kursiv das es von einer weak-entity kommt oder was?

Ja - so hab ich das zumindest verstanden ...

dann is bei der angabe zum ersten UE-Bsp 2003 auch ein Fehler... Level is in Relation Kunde kursiv.

Nein - da sehe ich keinen Fehler drin - es ist ja trotzdem ein weak-Attribut (um die Relation kostenfrei_bis wegsparen zu können) ... Das passt.

[Tiniiiii]

Und damit's nicht fad wird:

Zu Bsp 5 aus Musterlösung vo200206 (http://www.dbai.tuwien.ac.at/education/dm/ )

Warum ist hier bei:
Student (Matrikelnummer, StudentenName)
LVA (LVANr, LVATyp)
Note (Matrikelnummer, LVANr, Note)

nicht
Note (Matrikelnummer, LVANr, Note)

??? Nehmen die Vortragenden die weak-Entities anscheinend doch nicht so genau???

Angabe wieder als gif anbei ...

[Flowyes]

Zum 4. Bsp:
Es würde mich auch sehr interessieren, warum hier bei gezeigt_auf nicht alles kursiv ist.
Kursiv bedeutet Fremdschlüssel, und unterstrichen heißt Primärschlüssel, das ist mal klar...
D.h. bei A-Termin ist Beginn als Fremdschlüssel gekennzeichnet.
???
Beim 5. Bsp gibt's auch hier die selbe Verwirrung.
Wie geht das?
(oder vielleicht nehmen Sie des doch nicht so genau)

[Sensei]

Kursiv bedeutet Fremdschlüssel, und unterstrichen heißt Primärschlüssel, das ist mal klar...

1) Danke, das das jemand mal explizit sagt... war mir da nie ganz sicher

2) Wie erkennt man ob ein Schlüssel ein primärschlüssel ist oder nicht? Einfach nur durch den 'Sinn'? Da muss es doch auch irgendeine Regel geben

3) ob kursiv oder nicht... das erkennt man (zumindest bei meiner :D) Schrift nicht und die Hauptsache ist denk ich, dass es da steht und nicht bzw. schon unterstrichen ist. Wann jetzt was --> genau daran hapert's noch bei mir. Siehe 2)

BITTE gibt mir jemand eine Antwort zu 2)

[leviathan]

Nun ich hab das so verstanden. Etwas kann nur als Key dazukommen wenn die Betreffende entity weak ist. Wenn es keine Weak entity ist kommt es nur als fremdattribut dazu. Dies hat den folgenden Grund. Eine weak entity besagt das sie ein Fremdschlüssel braucht um eindeutig identifiziert zu werden. Hierbei muß man aber aufpassen, dass man nur die nötigen sachen dazugibt. Ich glaube das es hier keinen Algorithmus gibt mit den man das lösen kann. Der Tutor bei den ich war hat acuh gemeint das man da einfach schauen muß mit welchen Fremdschlüssel etwas eindeutig bestimmt werden. Ist es keine weak entity dann braucht es keinen Fremdschlüssel, denn es ist ja schon eindeutig. Im letzten Fall stellen die Attribute nur eine Art Zusatzinformation dar dienen aber nicht dazu die entity eindeutig zu bestimmen.

Ich hoffe ich habe es gut erklärt. Ich wüßte nicht wie ich es sonst erklären sollte.
lg leviathan

[Flowyes]

@Sensei:
ANTWORT ZU 2)
Ich glaub, dass ich noch einiges explizit ausdrücken könnte hier:
Ich weiß nicht, ob wir den Begriff Schlüselkandidat gelernt haben, wenn nicht ist es aber trotzdem sehr gut für das allgemeine Verständnis...
Also mit eigenen Worten:
Schlüssel: Attributmenge (also ein Attribut oder mehrere) mit denen man ein Tupel eindeutig identifizieren kann
Schlüsselkandidat: Schlüssel (wie oben erklärt), aber mit der zusätzlichen Eigenschaft, dass aus der Attributmenge, die den Schlüssel darstellt, kein Element (also Attribut) entfernt werden könnte (Minimalität), ohne, dass die Schlüsseleigenschaft (eindeutige Identifizierung) verloren geht!
Primärschlüssel: Ein Schlüsselkandidat. (Es können theoretisch mehrere geben für eine Relation, aber wegen der Definition vom Schlüsselkandidat, muss Primärschlüssel eindeutig und minimal sein)
Fremdschlüssel: Primärschlüssel einer anderen Relation
---
Beispiel: Im Bsp 2.1 - Theater hat die Vorführung den Primärschlüssel (stück.titel, zeit, theater.name)
Dabei sind stück.titel und theater.name Fremdschlüssel.

Primärschlüssel erkennst du also dadruch, dass du dir überlegst, ist der Schlüssel eindeutig und auch minimal? Also wäre es vielleicht möglich ein Attribut zu entfernen und ich hab noch immer einen Schlüssel? Wenn nein, und das Tupel ist noch immer eindeutig, dann ist das ein Primärschlüssel. Das ist eine feste Regel würd ich da sagen.

[Sensei]

Wow, Danke für die ausführliche Erklärung. Da wird einem ja einiges klar. :thumb:



Primärschlüssel erkennst du also dadruch, dass du dir überlegst, ist der Schlüssel eindeutig und auch minimal? Also wäre es vielleicht möglich ein Attribut zu entfernen und ich hab noch immer einen Schlüssel? Wenn nein, und das Tupel ist noch immer eindeutig, dann ist das ein Primärschlüssel. Das ist eine feste Regel würd ich da sagen.

Also läuft's dann im Endeffekt aber trotzdem drauf raus, dass man sich das ganze ÜBERLEGT. Ich hab immer gedacht, da gibt's bestimmt einen Algo, welcher irgendwie die Kardinalitäten verwendet, um dann zu zeigen, was als Schlüssel aufgenommen wird und was nur als Attribut.

Wenn du mir jetzt noch eine regel sagen könntest, von welchen benachbarten Entitys eine Weak-Entity die Schlüssel übernimmt, wär ich hochauf zufrieden. Z.b. im PO, Prf. 14.6.02, Bsp. 4:
Bild übernimmt nur die Keys vom Maler, nicht aber vom (auch direkten) nachbarn Vernisage oder Besitzer.
In dem Fallüberlegt man sich jetzt wieder, durch was das Bild eindeutig identifiziert wird usw., aber was, wenn (wie Havelka mal gesagt hat), ein total 'unsinniges' ER-Diagramm gegeben ist (also Attribute und Entitys z.b. 'a', 'b', 'c',...).
Dort tut man sich mit dem 'Sinn' schon etwas schwerer denk ich...

na wurscht, danke nochmal, vielleicht fällt ja noch was ein!

[Flowyes]

Ich hoffe, dass ich auch hier etwas klares sagen kann: (vor allem in der letzten Zeit hasse ich alles Unklare :mad: :) )

In diesem Beispiel, wo man sich die Dinge ÜBERLEGEN kann, ist es ja leicht zu erkennen, dass Bild den Primärschlüssel titel, maler.name hat. Klar, denn das reicht aus, um das Bild eindeutig zu identifizieren.
Frage: Was ist wenn blöde entities und attribute vorkommen (z.B. bla, Nolfi, tolschockt...) ?
Dann erreicht man mit der Vernunft natürlich wenig. Aber es geht trotzdem, dass man sich die Sache überlegt.
Nehmen wir an, beim obigen Beispiel (Bild, usw...) können wir uns nichts überlegen. Dann wissen wir aber trotzdem, wegen den Kardinalitäten, das das gleiche Bild auf mehreren Vernisagen gezeigt werden kann. D.h. wenn ich denk, vielleicht ist das Bild zusammen mit dem Malernamen nicht eindeutig, dann könnte ich vielleicht den Vernisagen.namen hinzunehmen um das Bild eindeutig zu machen. Aber so wird es sicher auch nicht eindeutig, denn : bild--[0,n]--<gezeigt_auf>---[1,n]--Vernisage
Also die Hinzunahme des vernisage.namens in die Schlüsselattributmenge kann i.a. das Bild nicht eindeutig machen.
Und zum Besitzer. Da haben wir sowieso Probleme mit nullwerten. Deswegen ist es naheliegend, dass das Bild doch nur 2 Attribute im Primärschlüssel hat.
Und so müsste das mehr oder weniger bei allen möglichen Diagrammen funktionieren...

[Sensei]

gute argumente... ok, ich denk ich lasses jetzt mal gut sein mit dem.... sollt jetzt denk ich hinhauen. danke vielmnals für sämtliche erklärungen!

cu