Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
Beispielklausur Lösungen / Fragen
Hallo Leute,
hier können wir Lösungsvorschläge sowie Fragen zur Beispieklausur besprechen. Ich habe die Beispielklausur aus der Studon Gruppe
“Konzeptionelle Modellierung [KonzMod], 2010WS”
Mein Lösungsvorschlag zu Datenmodellierung Aufgabe b)
Sendeanstalt (Name, Adresse)
Reporter( PersNr, Name, Name [Sendeanstalt], seit)
…Name [Sendeanstalt] NOT NULL
Live-Reportage (Titel, Ort)
Sendeslot (Datum, Beginn, Ende)
Werbepartner (ID, Name)
Werbespot ist schwaches Entity, bin mir nicht 100% sicher obs so stimmt
Werbespot ( Titel, bezahlt [Werbepartner], Dauer)
gezeigt_in(Datum, Beginn, Ende [Sendeslot], Titel, bezahlt [Werbespot])
on_air (PersNr [Reporter], Titel [Live-Reportage], Datum, Beginn, Ende [Sendeslot])
Was habt ihr?
Seh ich kritisch, weil du ja nicht 2mal das gleiche Attribut (hier Name) haben kannst, also müsste man dem Fremdschlüssel wohl nen anderen Namen geben.
Zur Syntax:
Bei den letzten beiden Relationen müsste man das denke ich so schreiben:
gezeigt_in((Datum, Beginn, Ende )[Sendeslot], (Titel, bezahlt )[Werbespot])
on_air (PersNr [Reporter], Titel [Live-Reportage], (Datum, Beginn, Ende )[Sendeslot])
Und um beim dreistelligen Beziehungstyp die Abhängigkeiten mitreinzukriegen sollte man das irgendwie so machen:
on_air (PersNr [Reporter], Titel [Live-Reportage],(Datum, Beginn, Ende )[Sendeslot])
(Titel [Live-Reportage],(Datum, Beginn, Ende )[Sendeslot]) UNIQUE
Ist es ok, wenn man den Fremschlüssel einfach so umbennent? Eigentlich müsste der ID heißen, steht so zumindest im ER-Diagram.
Ergänzung: (Datum, Beginn, Ende)[Sendeslot] NOT NULL.
Hat jemand schon die Aufgabe mit dem Sequenzdiagramm und den Traces gemacht?
Wie genau verhält sich der Operator loop(1, 3)? Falls zu Beginn [valCond] = false, wird er dann überhaupt ausgeführt (wegen der 1 in Klammern) oder gehts gleich weiter mit dem nächsten Operator? Die Frage bezieht sich den 3. Trace (o1 → p1).
Lösungsvorschlag: 0 1 1 1 0 1
Wer was anderes hat bitte posten!
So weit ich weiß ja. Wenn man jetzt mehrere verschiedene Tabellen hätte und alle hätten eien Primärschlüssel ID und ich wollte in einer Tablle lauter Fremdschlüssel auf diese Tabellen packen, dann muss ich deren Attribute ja umbenennen.
Durch das Umbennen hat man es später in SQL halt ggf. etwas leichter bzw. schwerer. Denn wenn die Attribute gleich heißen, dann schreibt man halt einfach SELECT * FROM A natural join B. Wenn sie nicht gleich heißen muss man halt bspw. SELECT * FROM A join B using A.attname = B.att schreiben. Gut ist auch nicht wirklich länger, aber es zeigt, dass es offensichtlich gestattet ist Fremdschlüssel mit einem anderen Namen zu versehen als der Primärschlüssel ;).
Ja das mit der Loop habe ich mich auch schon gefragt. Außerdem bin ich mir ein bisschen unsicher, ob valCond und errCond in irgendeiner Weise zusammen hängen. Aber ich gehe einfach mal davon aus, dass nicht oder?
Ich hätte jetzt die gleiche Lösung wie Maddoc, aber bei der Ausführung der Loop-Schliefe bin ich mir wie gesagt auch unsicher. Allerdings konnte ich dazu bisher auch nichts wirkliches finden. In allen möglichen Referenzen steht immer nur, dass loop halt zur Iteration genutzt wird. Aber eine detailliere Beschreibung habe ich noch nicht wirklich gefunden.
Ich würde genau wegen der loop 0 1 0 1 0 1 sagen, weil die Schleife ja 1 mal ausgeführt werden muss.
Hier ist das zumindest so beschrieben: UML sequence diagrams overview of graphical notation - lifeline, message, execution specification, interaction use, etc.
Also ist bei loop(x,y) x die minimale Anzahl an Ausführungen und y die maximale Anzahl
- Danke für den Link
- UML scheint sich bei dem Thema auch nicht so wirklich entscheiden zu können:
Das Kommentar auf der Seite dazu:
Nach der Aussage wäre Trace c) gültig …
Wenn man des n bisschen genauer liest hast du recht.
Habs vorhin nur so grob überflogen. Aber in dem Fall is c wohl richtig auch wenns imho keinen sinn ergibt das dann überhaupt hinzuschreiben, eig müsste dann ja immer 0 an erster stelle stehen
Keine Ahnung 
Was haltet ihr von dieser halb-reflexiven Beziehung zwischen Heimverein, Gastverein und Begegnung?
Attachment:
Bspklausur1.png: https://fsi.cs.fau.de/unb-attachments/post_91549/Bspklausur1.png
Interessant ;).
Bei mir ist Begenung ein schwaches Entity geworden mit Datum als partiellem Schlüssel und einem Heimverein und Gastverein als definierende Beziehungen. Denn ohne Vereine gibts keine Begegnung. Das war mein Ansatz.
Aber dieses halb-reflexive finde ich jetzt nicht schlecht. Keine Ahnung, ob es richtig ist, aber meiner Meinung nach sieht es gut aus ;).
Mit der Variante gibt es dann aber max. ein Spiel pro Tag. Wenn das stimmt dann müsste es passen
Habe Gestern nochmal in der Übung gefragt. Hier was ich in Erfahrung bringen konnte:
Sendeanstalt (Name, Adresse)
Reporter( PersNr, Name, Name [Sendeanstalt], seit) Hier steht zweimal Name, jedoch ist das eine ein Attribut, das andere ein FS. Sollte gehen
…Name [Sendeanstalt] NOT NULL
Live-Reportage (Titel, Ort)
Sendeslot (Datum, Beginn, Ende)
Werbepartner (ID, Name)
Werbespot ( Titel, bezahlt [Werbepartner], Dauer) [color=crimson] FS umbenennen ist ok, also richtig
[/color]
gezeigt_in ((Datum, Beginn, Ende )[Sendeslot], (Titel, bezahlt) [Werbespot])
on_air (PersNr [Reporter], Titel [Live-Reportage], (Datum, Beginn, Ende) [Sendeslot]) Theoretisch richtig, praktisch falsch
Grund: Man soll unnötige Ausprägungen von Relationen bei allen Beziehungen vermeiden. Man Sollte also lieber 2x 1-N Beziehungen in Live Reportage einbauen
Somit lässt man on_air als eigene Relation weg und modelliert es wie folgt in Live-Reportage:
Live-Reportage (Titel, Ort, PersNr [Reporter], (Datum, Beginn, Ende) [Sendeslot])
…PersNr [Reporter] NOT NULL
…Datum [Sendeslot] NOT NULL
…Beginn [Sendeslot] NOT NULL
…Ende [Sendeslot] NOT NULL
@schmidti159: Danke für den Hinweis mit den Klammern
[quote=Maddoc]
Mit der Variante gibt es dann aber max. ein Spiel pro Tag. Wenn das stimmt dann müsste es passen
[/quote]Hm. Hab nicht “bestimmtes Datum” gelesen, sondern “bestimmendes Datum”.
Edit: kuenstliche Schluessel sind verboten. Sind damit auch zusammengesetzte Schluessel gemeint? Sonst koennte man davon ausgehen, dass zwei Mannschaften nur einmal pro Tag gegeneinander spielen und Begegnung mit einem zusammengesetzten Schluessel aus Datum, Heim- und Gastmannschaft versehen.
Abgesehen davon, dass wir das nie irgendwie behandelt haben (weder auf Folien noch Übungen) -.- hat es allerdings einen ganz praktischen Vorteil: die totale Teilnahme lässt sich modellieren …
@ Wirklich künstlich ist der Schlüssel nicht, also müsste es schon ok sein. Sonst könnten wir ja auch gar keine schwachen Entitäten mehr modellieren.
Das ist ein berechtigter Einwand…
Hab das ER fast genauso wie Malte. Ist ja alles recht einfach bis auf die Begegnungen. Zwei Anmerkungen:
-
Das “N” bei “Verein” “spielt in” “Spieler” ist nicht spezifiziert. Ich habs weggelassen, obwohl es logisch ist
-
Wenn ich die Angabe lese: “Vereine treffen in Begegnungen aufeinander” habe ich erst an einen rekursiven Beziehungstyp gedacht. Habe es entsprechened modelliert. Was meint ihr dazu:
Attachment:
Unbenannt.png: https://fsi.cs.fau.de/unb-attachments/post_91564/Unbenannt.png
Mit deinem Modell können zwei Vereine höchstens einmal aufeinandertreffen.
Und in jeder Begegnung koennen beliebig viele Heim- und Gastvereine spielen. Waer ein ziemliches Chaos auf dem Feld. 
[quote=OMG]
- Das „N“ bei „Verein“ „spielt in“ „Spieler“ ist nicht spezifiziert. Ich habs weggelassen, obwohl es logisch ist
[/quote]Du musst ja eine Kardinalitaeten angeben. Und wenn nichts dasteht, woraus eine 1 folgt, schreibst du halt N.
xD na das will ja keiner 
Ich gucke mir nochmal Maltes Lösung genauer an.