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.
Braindump “Lerngruppe”
Denke es wird mehreren so gehen, dass sie sich Lösungen für die braindumps wünschen.
Darum will ich uns hier die Möglichkeit erschließen unsere eigenen Lösungen zusammen zu tragen.
MfG
Attachment:
braindump_ss12-signed.pdf: https://fsi.cs.fau.de/unb-attachments/post_128135/braindump_ss12-signed.pdf
1 Like
Habe da noch ein paar Fehler gesehen, aber super Sache. 
Ich hatte auch vor meinen Lösungsvorschlag von SS12 und anderen Braindumps später hier reinzuhauen (also noch vor der Klausur). Da bist du mir dann wohl zuvorgekommen. 
Ich werde meine Lösung einmal in ne „schöne“ PDF-Datei packen und es mit deinen Lösungen vergleichen und dann auch hochladen.
Edit:
Eventuell können wir uns darauf einigen, dass wir DropBox/CIP o.ä. verwenden (biete mich an :D), weil ein Bearbeiten von alten Beiträgen hier im Forum (scheinbar?) nicht möglich ist und so trotzdem immer auf die aktuelle Version verwiesen werden würde.
Hab selbst noch viele kleine fehler gefunden. Aber bin im umgang mit pdf’s nich so geschickt/erfahren.
Darum liste ichs mal auf:
1.4 totale teilnahme von B nicht von C
1.7 (0…2):(0…1)
3 B totale Teilnahme (unsicher)
7.1 c) 3. statt SA (schlüsselatt.) müsse da NSA stehen
Zusätzlich hab ich noch Aufgabe 9 gelöst
mit den opperatoren:
par um a, b, x, y (gestrichelte Linie nach a) und
critical um x, y
In welche Relation kommt bei einer 1:1 beziehung der fremdschlüssel?
Kann er auch in beide?
MfG
Der Fremdschlüssel kann bei 1:1 in beide Relationen kommen. Es gibt aber auch Beziehungen, die auf einer Seite nicht total sind, auf anderer aber schon. Dann wäre es empfehlenswert, den Fremdschlüssel auf der totalen Seite hinzuschreiben, da sonst die Totalität verlorengeht.
1 Like
Jop is richtig.
Danke für die schnellen Antworten.
Hier noch die SQL-Aufgabe. Feedback erwünscht(da sehr unsicher)!
MfG
Attachment:
Braindump ss12 sql.pdf: https://fsi.cs.fau.de/unb-attachments/post_128184/Braindump ss12 sql.pdf
Ich habe auch den Braindump durchgerechnet, meine Lösung steht in diesem Ordner.
und Aufgabe 2 ER-Diagramm
Attachment:
Unbenannt.jpg: https://fsi.cs.fau.de/unb-attachments/post_128196/Unbenannt.jpg
Tolle Lösung - wesentlich ordentlicher als bei mir^^
zu aufgabe 2 müsste Favouritenliste nicht ein schwaches entity sein?
zu aufgabe 3 B totale Teilnahme an D? (da bkey not null)
NOT NULL hat mit totaler Teilnahme nichts zu tun, siehe Skript zum Thema Mapping. Und ein schwaches Entity kann man machen, muss man aber nicht. Allerdings müsste ich ohne schwaches Entity noch einen Schlüssel hinzufügen.
kann mir jemand sagen ob die Aufgabe anbei richtig gelöst ist
Attachment:
ER_2011_08_03.jpg: https://fsi.cs.fau.de/unb-attachments/post_128230/ER_2011_08_03.jpg
[quote=[hedgehogs dilemma = 42]]
kann mir jemand sagen ob die Aufgabe anbei richtig gelöst ist
[/quote]
Sieht größtenteils richtig aus, meine Lösung sieht so aus (im Anhang).
Was ziemlich sicher bei dir falsch sein dürfte ist die ternäre Beziehung bzw. genauer gesagt die Kardinalitäten.
Denn du hast jetzt modelliert:
Pro Bewertung und Autor gibt es ein Rezept.
Das heißt die Kombination aus Autor und Bewertung bestimmen das Rezept. Ein Autor kann aber mehrere Rezepte mit derselben Berwertung (z.b. 5pkt) bewerten.
Wo ich mir noch nicht sicher bin, was aber eigentlich so sein muss ohne einen neuen Schlüssel einzufügen:
Das ist das schwache Entity in der tenären Beziehung, denn strenggenommen steht nur dort, dass eine Bewertung über Autor und Rezept identifiziert werden, es steht jedoch nicht da, dass es keine Bewertung ohne Autor geben kann (z.B. wenn der Autor sich gelöscht hat).
Aber ansonsten müsste man einen neuen Schlüssel einfügen, was nicht explizit erlaubt ist, daher habe ich es auch so modelliert.
Bei deiner 2. tenären Beziehung bin ich mir überhaupt nicht sicher ob das stimmt oder nicht.
Eigentlich habe ich über diese Möglichkeit gar nicht nachgedacht beim Modellieren. 
Aber so gesehen dürfte die nicht falsch sein, denn damit sagst du ja nur aus:
Pro Rezepteintrag und Rezept gibt es eine Zutat (was wahr ist) und Pro Zutat und Rezept gibt es einen Rezepteintrag (was auch wahr ist).
Auch die letzte “Bedingung”: Pro Zutat und Rezepteintrag gibt es mehrere Rezepte ist ansich ja nicht falsch, es kann ja durchaus sein, dass genau diesselbe Zutat und derselbe Rezepteintrag in mehreren Rezepten vorkommt???
Wäre super wenn jemand die letzte Ungereimtheit noch aufklären könnte. 
Attachment:
EER_11_08.png: https://fsi.cs.fau.de/unb-attachments/post_128231/EER_11_08.png
@ [hedgehogs dilemma = 42]:
“Steht in” ist meiner Meinung nach eine M:N-Beziehung, denn man kann nicht unbedingt aus der Aufgabenstellung herauslesen, dass ein Rezept in höchstens einem Kochbuch steht. Bei “gehört zu” bin ich mir nicht ganz sicher mit den Kardinalitäten, ich denke aber, dass das so aussieht:
Zu einem Autor und einer Bewertung gehören beliebig viele Rezepte => N auf der Seite vom Rezept.
Zu einer Bewertung und einem Rezept gehören beliebig viele Autoren => M (bitte nicht nochmals N) auf der Seite vom Autor.
Zu einem Autor und einem Rezept gehört höchstens eine Bewertung => 1 auf der Seite von der Bewertung.
@ Shadow992:
Ich wäre sehr vorsichtig mit Attributen bei Beziehungstypen - das kann sehr leicht nach hinten losgehen. Die 2. ternäre Beziehung wäre imo. Pflicht, ich hätte noch über ein schwaches Entity bei Eintrag nachgedacht. Man kann die Sache mit dem schwachen Entity aber an dieser Stelle nicht unbedingt herauslesen.
@Rezept
„Ein Rezept steht in einem Kochbuch.“ klingt für mich nach „genau einem oder keinem“ aber gut ist wohl bissel interpretierbar.
@Attribute in Beziehungstypen
Mag sein, aber so wie ich das sehe ist es dennoch nicht falsch oder?
Zumindest wenn ich mir das gemappt vorstelle, wird damit genau das ausgedrückt, was ausgedrückt werden sollte.
[quote=Shadow992][…]@Attribute in Beziehungstypen
Mag sein, aber so wie ich das sehe ist es dennoch nicht falsch oder?[…][/quote]
Das ist imo. schon falsch, siehe Skript 2 Seite 25.
An einer Position kann eine Zutat in mehreren Rezepten stehen, somit müsste über Rezept eine N stehen.
An einer Position steht in einem Rezept höchstens eine Zutat, somit steht über Zutat eine 1.
In einem Rezept kommt eine Zutat höchstens an einer Position vor, somit steht über Position eine 1.
In dem Fall geht ohne einen ternären Beziehungstyp zu viel Information verloren.
Jetzt bin ich echt verwirrt.
Dieses Arzt-Beispiel macht durchaus Sinn, wenn ich mir das gemappt vorstelle sähe es so aus:
Arzt(ArztID,Name)
Patient(PID,Name)
untersucht(ArztID,PID,Datum)
Versuche ich dort jetzt 2x denselben Patienten mit demselben Arzt einzufügen (weil er mehrfach untersucht wird), gibts Probleme weil der Primärschlüssel nicht mehr eindeutig ist.
Aber bei unserem Beispiel gibt es da keine Probleme, weil die Bedingung von vornherein ist, dass eine Zutat genau einmal im Rezept vorkommt.
Also:
Rezept(RName)
Zutat(ZName)
enhält(RName,ZName,Menge,Position)
Also so sehe ich das zumindest gerade, eventuell steh ich auch gerade aufn Schlauch.
Edit:
„[…] In einem Rezept kommt eine Zutat höchstens an einer Position vor, somit steht über Position eine 1. […]“
So wie ich das sehe heißt es auch nicht, dass die Position „eindeutig“ ist, sondern nur „bestimmt“. Wenn ich da einmal drüber nachdenke kann es ja sehr wohl sein, dass mehrere Zutaten an derselben Position stehen (weil sie z.b. gleichzeitig verarbeitet werden).
Edit2:
Über mein Edit lässt sich wohl streiten, ist wieder so eine Interpretationssache.
Aber die Frage Ternär vs Beziehungs-Attribute bleibt trotzdem.
Vergiss das Mapping, sonst wirst du nur noch mehr verwirrt.
So, wie du das modellieren willst, ist die Beziehung eine Beziehung zwischen Rezept und Zutat. Bei einem binären Beziehungstyp hast du rein aus logischer Sicht - und auch in der Aufgabenstellung steht das genauso drin - die folgende Information:
- In einem Rezept können beliebig viele Zutaten vorkommen.
- Eine Zutat kann in beliebig vielen Rezepten vorkommen.
Im Klartext hast du also eine M:N-Beziehung. Wie willst du ohne ternäre Beziehungstypen einschränken, dass eine Zutat in einem Rezept an höchstens einer Position vorkommt?
Zu deinem 1. Edit denke ich, dass du Recht hast, jedoch denke ich, dass die N nicht auf der Seite der Position, sondern auf der Seite der Zutat steht.
Eine Zutat steht in einem Rezept an genau einer Position => 1 über Position.
Eine Position kann in einem Rezept auch gleichzeitig mit N Zutaten belegt sein => N über Zutat.
Dankeschön für die Erklärung, von der Seite hatte ich es gar nicht betrachtet.
Danke für die schnellen Antworten.
Hatte wegen den Kardinalitäten einen Knoten im Kopf.
Passt das jetzt so wie anbei?
@Chayyam - ein Rezept steht in einem Kochbuch — würde ich als N:1 Beziehung sehen, aber wie shadow meinte - das is ja interpretierbar
@shadow and Chayyam - müsste die Modellierung von shadow nicht doch stimmen:
Aus den Folien:
Arzt kann einen Patienten mehrfach untersuchen !
Modell hier bedeutet:
Beziehung „Untersucht“ besteht zwischen Arzt A und Patient P oder sie
besteht nicht wenn sie besteht hat sie ein Datum
Übertragen auf unser Problem:
Zutat kann ja in einem Rezept nur 1mal auftauchen
Modell hier bedeutet:
Beziehung “enthält” besteht zwischen Rezept A und Zutat P oder sie besteht nicht,
wenn sie besteht hat sie eine Position
Attachment:
ER_2011_08_03.jpg: https://fsi.cs.fau.de/unb-attachments/post_128250/ER_2011_08_03.jpg
