Lösungen für Braindump

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.

Lösungen für Braindump
Gibt es eigentlich auch irgendwo die Lösungen für die Klausuren unter https://fsi.informatik.uni-erlangen.de/dw/pruefungen/bachelor/index ?? Wär super wenn man kontrollieren könnte was man selbst so fabriziert hat :smiley:
Danke schonmal :slight_smile:


Von offizieller Stelle her unwahrscheinlich, aber du kannst ja deine Vorschläge mit den anderen diskutieren :slight_smile:


Ich würde einfach hier im Forum suchen, da es bereits einige Lösungen zu bestimmten Braindumps gibt. Alternativ einfach selber einen Post erstellen - die Leute hier sind sehr hilfsbereit und es findet sich immer jemand, der Kommentare und Korrekturen beisteuert. Außerdem lernt man aus den Diskussionen meist mehr als wenn man nur eine vorgefertigte Musterlösung vor sich hat :wink:

2 „Gefällt mir“

Frage zur Beispielklausur im Studon:

Bei der E/R-Modellierung Aufgabe c) bin ich nicht sicher ob ich die Frage verstanden habe:

Sie haben zwei verschiedene Entity-Typen und einen Relationship-Typ der beide verbindet: Wie oft kann eine Entity-Ausprägung des einen Typs mit einer Entity-Ausprägung des anderen Typs eine Beziehung eingehen?

Hängt das nicht von der Kardinalität ab? Aber hier sind gar keine angegeben…


Noch eine Frage: Bei der Aufgabe zur Datenmodellierung soll man Begegnungen zwischen 2 Vereinen modellieren. Hier bin ich etwas verloren, da zwei Vereine miteinander in Beziehung gesetzt werden. Was nimmt man am besten: a) Entity b) Schwaches Entity c) Beziehungstyp. Wenn’s ein Entity ist braucht man dann zwei Beziehungstypen?


Vorlesung 2 zum ERM, Seite 24 könnte helfen.


Achso, Ausprägung bedeutet Instanz. D. h. es kann maximal eine geben, oder?


Wenn ich es richtig verstanden habe ja. Also keine Garantie :stuck_out_tongue:


[ot]„Instanz“ ist eine eher schiefe Direktübersetzung des englischen „instance“ - der treffendste deutsche Begriff wäre „Exemplar“. Aber „Instanz“ hat sich schon so stark festgesetzt, dass man es nicht mehr los wird. ;-)[/ot]


Wenn ich das richtig verstehe, bezieht sich deine Frage hauptsächlich auf’s Datum - normalerweise würde man sich ja denken, das geht einfach per rekursivem Beziehungstyp, aber hier muss das Datum selbst als Entity-Type vorkommen - siehe Hinweis.


Das Datum als eigener Entity-Typ? Wie sieht das konkret aus? Hätte es nach weiterem nachgrübeln jetzt als schwaches Entity namens Begegnung mit Attribut Datum, Heimtore und Gasttore mit einem identifizierenden Beziehungstyp gelöst, an dem Verein 2x teilnimmt (je 1x für Heimverein und Gastverein)…


Ja, das Datum oder halt die Begegnung. Ich dachte da an einen ternären Relationship-Type mit zwei Vereinen (Heim und Gast) und einer, meinetwegen, Begegnung. Diese hat das Datum als Schlüssel - man kann jetzt die Heimtore entweder da oder in den Relationship-Type packen. Ein schwaches Entity ist eigentlich eine ganz gute Idee, da ja keine Begegnung ohne Vereine existiert - das Datum wäre dann ein partieller Schlüssel.


Das wäre also crap?


  1. Bei dir muss jeder Verein mindestens einmal Gastverein und einmal Heimverein gewesen sein.
    (Totale Teilnahme halte ich für falsch.)
    [color=crimson]2. Bei dir kann ein Verein gegen 2 andere spielen, also in einer Begegnung.
    (Ich bin der Meinung, das gehört 1-1-N bzgl. Verein-Verein-Begegnung)[/color] EDIT: Das ist im großen und Ganzen nicht falsch, aber wem gehören dann die “Heimtore”?

  2. Zwei Vereine können nicht an mehreren Tagen gegeneinander spielen.
    (Datum als Attribut - Relationship-Instanz definiert sich durch Teilnehmer, nicht Attribute)

  3. Ein Spieler spielt bei dir in mehreren Vereinen. Ich glaube, du meinst das umgekehrt.
    (1-N → N-1)

  4. Es gibt bei dir Spieler, die nicht spielen. Die Angabe spricht von “Jeder Spieler”.
    (Partielle Teilnahme von Spieler halte ich für falsch.)

Das ist jetzt, was ich so spontan anmerken würde.
EDIT 2: Da folgern wir doch gleich was daraus! “Begegnung” muss sogar schwach sein, als Identifizierer haben wir die beiden Vereine - dann kann es mehrere Begegnungen pro Datum geben, die mit unterschiedlichen Vereinen stattfinden. Ich verstehe das jetzt so, dass zwei Vereine nur einmal pro “Datum” gegeneinander spielen.


Erst mal Danke für die Hinweise, Jerry. Ich habe jetzt mal auf Basis dessen versucht, eine korrekte Lösung zu erarbeiten:


Besser, aber warum unterscheidest du Heimvereine und Gastvereine? Wie stellst du sicher, dass du nicht zwei mal den selben Verein in den Entity-Sets hast?

Du weißt, dass ein Entity-Typ ruhig mehrmals am gleichen Relationship-Typ teilnehmen darf? Denk’ an die Begriffe “Rekursiver Beziehungstyp” und bei diesem Begriff immer auch an “Rollennamen”! :wink:

Desweiteren würde ich “hat” als Beziehungsnamen vermeiden, rein aus Stil - Es gibt ja “has-a”-Relationships, und eigentlich willst du ja sowas wie “spielen in” ausdrücken. Bedenke auch “is-instance-of” und “is-a”. Und natürlich “can-haz-a”, aber da brauchst du Cheezburger-Entities.

1 „Gefällt mir“

vielleicht könnt ihr den Code gebrauchen - war ursprünglich für den Braindump gedacht, flog dann aber raus, da wir doch nicht mehr so ganz motiviert waren, überall Lösungen zu machen :wink:

SS 2011, 6.1 SQL:

-- Verkaufszahlen der Filialen und Kaffeesorten über das Datum aggregieren
CREATE VIEW GesamtAnzahl AS
SELECT v.FilialId as FilialId, v.Kaffee AS Kaffee, sum(v.Anzahl) AS GAnzahl
FROM VERKAUF v
GROUP BY v.FilialId, v.Kaffee;

-- Filialen, die den minimalen Umsatz erfüllen
CREATE VIEW MinUmsatz AS
SELECT g.FilialId
FROM GesamtAnzahl g JOIN KAFFEE k USING(Kaffee)
GROUP BY g.FilialId
HAVING sum((k.preis - k.kosten) * g.GAnzahl) > 10000;

-- Nurnoch die richtigen Tupel auswählen und Gewinn berechnen ;-)
SELECT v.FilialId AS FilialId, v.Kaffee AS Kaffee, (k.preis - k.kosten) * g.GAnzahl AS Gewinn
FROM GesamtAnzahl g JOIN KAFFEE k USING(Kaffee) JOIN FILIALE f USING(FilialId)
WHERE f.Ort = 'Bielefeld' and g.FilialId IN (SELECT * FROM MinUmsatz);

Natürlich keine Garantie, aber vlt. etwas zum Vergleichen.


Noch mal Danke für die Hinweise, Jerry :wink:


Ich hab als Lösung für SS2011 6.1 SQL:

SELECT FilialID, Kaffee, SUM(Preis-Kosten)*SUM(Anzahl) as Gewinn,
FROM Kaffee JOIN Verkauf USING (Kaffee) JOIN Filiale USING (FilialID)
WHERE Ort = "Bielefeld"
GROUP BY FilialID, Kaffee
HAVING SUM(Preis-Kosten)*SUM(Anzahl) > 10000;

Geht das so auch oder wo ist der Fehler dabei?