E/R-Diagramm

[Wang]

Hallo,

wir behandeln gerade E/R-Diagramme und müssen dazu eine Aufgabe lösen. Die folgende Aufgabe ist aus dem Vorjahr und ich habe leider Schwierigkeiten beim Verständnis der Lösung:

Lösung:

Mein Problem ist die Einsparung in "findetStattIn", denn warum wird das Attribut "AngID" aus der Entity "Dompteur" zum Primärschlüssel der Relation "Darbietung" und warum verschwindet dann das Attribut "ProgNr" aus dieser Relation ???:L
Davon mal abgesehen kann man in der Relation "Darbietung" nur noch einen Dompteur speichern, obwohl laut Diagramm ein Dompteur in einer oder mehreren Darbietungen auftreten kann ???:L

Ich hoffe Ihr könnt mir helfen, weil ich leider total auf der Strecke stehe...

Vielen Dank!

Gruß
Wang

 

[earlgrey_tea]

Aus dem Diagramm geht hervor, dass ein Dompteur m Vorstellungen haben kann. Somit kann man über den Namen (oder die ID) auch die Vorstellung selbst identifizieren. An dem gerichteten Pfeil von

trittAuf(Dompteur, Darbietung, Tier)

steht doch eine kleine Eins.

Es gab IMO auch vorher -- nach Diagramm -- keine Möglichkeit n Dompteure in m Vorstellungen auftreten zu lassen. Da hat sich nichts geändert.

 

[Wang]

Meinst Du nicht "Darbietung" statt "Vorstellung", denn es besteht ja nur eine (direkte) Relation zwischen "Dompteur" und "Darbietung"...?

Ich hatte die "many-to-one-relationship" aus dem Skript leider falsch interpretiert:
"Jedes Objekt auf der "many" Seite steht in Beziehung zu höchstens einem Objekt auf der "one"-Seite (im Allgemeinen nicht umgekehrt)"

Damit hast du Recht und nur in einer "many-to-many-relationship" könnte ein Dompteur mehrere Darbietungen haben.

Dennoch bleibt leider die Frage offen, warum in der Einsparung aus "findetStattIn" das Attribut "AngID" aus der Entity "Dompteur" zum Primärschlüssel der Relation "Darbietung" wird und warum dann das Attribut "ProgNr" aus dieser Relation verschwindet?

Wäre nett, wenn jemand seine Meinung posten würde...

 

[earlgrey_tea]

So wie ich das Diagramm verstehe, ist die Vorstellung der gesamte Abend (also rund zwei Stunden Zirkusunterhaltung). Die Darbietung ist aber nur eine Nummer aus dem Programm (siehe one to many in

findetStatt

). Wenn nun Darbietung und Dompteur voneinander getrennte Enitäten sein sollen, dann brauchen sie auch jeder einen Primärschlüssel. So weit nix neues.

Da es nach dm Diagramm aber keine Darbietung ohne Domptuer geben kann, hängt Darbietung von Dompteur direkt ab (dafür gibts nen Fachwort im Datenbankentwurf, hab ich aber leider vergessen). Wenn es also keine Entität Dompteur gibt, dann darf es auch keine Darbietung geben. Um dieser Beziehung Ausdruck zu geben, bekommt Darbietung den Primärschlüssel der Entität von der sie abhäbgt; in diesem Fall Dompteur.

 

[Wang]

Klingt plausibel.

Mir dämmert es nur noch nicht, warum dann das Attribut "ProgNr" aus der Relation "Darbietung" verschwunden ist; ist das sinnvoll oder einfach nur ein Versehen?

Gruß
Wang

 

[earlgrey_tea]

Darbietung hat zwar das Attribut "ProgNr" verloren, es sind aber Vorstellung und Uhrzeit hinzugekommen. Die Programmnummer ließe sich aus diesen beiden Informationen zweifelsfrei wieder herstellen, wenn man davon ausgeht, dass der Zirkus nur eine Manege und ein Zelt hat. Dann kann an einem Tag zu einer bestimmten Uhrzeit nur eine Zirkusnummer gezeigt werden. Die Programmnummer lässt sich also aus den anderen Informationen herleiten und ist somit überflüssig.

Ganz sicher bin ich mir dabei aber nicht!