Lösungsskizze_SS15.pdf

Exams
Uploaded by Carle B. Navy 12689 at 2019-02-17
Description:

Lösungsskizze der Altklausur aus dem Sommersemester 2015. Bei Fehlern oder Verbesserungen gerne Bescheid geben :)

 0
89
13
Download
BCE ist auch Schlüssel, oder?
Raum nimmt doch 0..1 mal teil an der hat-büro beziehung. Daraus folgt doch ganz klar, dass ein Professor nicht unbedingt ein Büro haben muss.
View 2 more comments
Aber dennoch ja, wenn ich mir das jetzt genauer anguck, dann hast du Recht, ein Proffessor MUSS immer ein Büro haben, nur muss nicht jeder Raum das Büro eines Professors sein.
Ja da ist es genau so jeder professor muss genau ein raum haben also ein büro aber in einem raum kann auch kein prof ein büro haben
SELECT stadt, count(*) as gesamtZahl FROM( SELECT DISTINCT abflug as stadt, id FROM Flugstrecken UNION SELECT DISTINCT flugziel as stadt, id FROM Flugstrecken ) JOIN Buchungen b ON b.f_id = id GROUP BY stadt ORDER BY gesamtZahl ASC;
Sollte doch falsch sein, da sich aufgrund des Pfeils jedem Gebäude 1..N Räume zuordnen lassen, allerdings nicht umgekehrt
View 1 more comment
Ja ist denk ich falsch. Die "hat" beziehung ist Schlüssel und direktional => Es kann unterschiedliche Räume mit der selben RaumNr geben, die aber zu versch. Gebäuden gehören. Deshalb reicht es nicht aus die RaumNr des Büros zu kennen um das Gebäude zu finden.
Ich glaube die korrekte Antwort ist "Richtig". Ein Professor nimmt exakt einmal an der "hat-Büro" Beziehung teil. Ich finde also den Raum. Ein Raum nimmt exakt einmal in der "hat" Beziehung teil. Ich finde also ein Gebäude Ich glaube im übrigen, dass es keine zwei Räume mit der selben Nummer geben kann, denn die Raum-Nummer ist ein Schlüssel.
Warum wird die ID nur bei Fahrzeug als Schlüssel gekennzeichnet?
weil wasser und landfahrzeuge eine spezialisierung von der entitiy Fahrzeug sind das wird mit den dreiecken dargestellt. Also wird dann nur die id von fahrzeug benötigt, da jedes land und wasserfahrzeug auch gleichzeitig ein fahrzeug ist. also als beispiel eine mercedes c klasse mit einer motorleistung von 204 ps ist ein fahrzeug mit id 3. Es ist also in fahrzeug enthalten hat ber auch noch eine zuladung ist also auch ein landfahrzeug und deshalb auch in der entitiy landfahzeug enthalten es ist der selbe mercedes mit der id 3 also wird nur eine id benötigt.
Count und sum sind doch Aggregatfunktionen. So wie du die Anfrage stellst würde ich denken, dass dein Ergebnis mehrere Hans Schnee's gibt (pro Buchung) jedoch die Gesamtzahl der Buchungen und die Summe der Preise nur ein Ergebnis liefert. Somit sollte dein code nicht kompilierbar sein., da das ergebnis ein Table mit x Zeilen "Hans Schnee" aber nur jew 1 Zeile Gesamtkosten und Gesamtpreis gibt. Oder habe ich einen Denkfehler?
das sollte so wie es da steht schon stimmen verstehe aber deine frage nich ganz
okay jetzt nach mermaligem lesen verstehe ich was du meinst. also kompilieren wird das denke ich schon bin mir aber da nicht sicher, nur dass dann wenn hans schnee x mal in buchung vorkommt das das auch x mal ausgegeben wird mit der selben anzahl an buchungen und dem selben summe vom preis wie gesagt bin mir da allerdings nicht sicher. also wäre es schöner wenn man noch ein Group by name, vorname einbaut
Ist ja nicht nötig, wenn die Relation Passagier nur einen Eintrag namens Hans Schnee hat.
View 1 more comment
Hatte nach der Aufgabenstellung gedacht, dass in der Relation Passagier nur der Hans Schnee enthalten ist... . Habe mich vertan.
Trotzdem wäre bei dem Search ein "Group by" bestimmt sauberer. Hier bekommt man ja so sonst mehrere Ergebnistupel raus.
Muss die Menge aber nicht minimal sein ? {A, F} überdeckt {A, C, E} und {D, F} überdeckt {D, C, E}
Das ist die Aufgabe aus der 3.Übung 2019:
Es fehlt auch noch der Schlüssel {BCE} (s. Übung 3, SS19)
Ist das wirklich ein Schlüssel?
Nein, da GE+ = {G, E, F, C} != {A, B, C, D, E, F, G}
Stimmt, {GF} ist KEIN Schlüssel!
Ist nicht ganz korrekt, siehe Übungslösungen vom Blatt 3 von SS2019.
Hier der Ausschnitt
Das müsste doch union all sein oder nicht?
Normal schon. Jedes Tupel (Stadt, Passagiere) kommt in der Relation mit den Daten aus der Aufgabenstellung nur einmal vor, daher funktioniert das in diesem Fall. Falls aber bspw. Freiburg als Abflug und Flugziel von nur insg. einer Person gebucht werden würde, dürfte das Ergebnis nicht mehr stimmen. Ebenso würde ich einen LEFT JOIN bevorzugen, weil man nicht sicher sein kann, dass alle Flugstrecken von mindestens einer Person gebucht werden (ist aber eher unwahrscheinlich im echten Leben).
in der aufgabenstellung steht explizit dass die lösungen unabhängig vom datenbank inhalt sein müssen also muss hier ein union all hin, da sonst die lösung verfälscht werden würde, denn wenn z.b karslruhe genau so viele ankommende wie abreisende passagiere hat, würde es nur einmal wegen dem union aufgelsitet werden dann würden die anzahl der abfliegenden und ankommenden nicht addiert werden.
Ich habe Professor und Raum noch verschmolzen. Dann gibt es zwar ein paar null-Werte in der Relation, aber es sollte trotzdem passen nicht?
ich denke dass geht nicht, da Raum_Nr und Name dann jeweils ein Schlusselkanidat sind das bedeutet name und raum_nr dürfen nicht null sein. jedoch dar nach dem er modell aber ein raum keinem prof zugeordnet sein das würde in deinem relationale modell dann nicht realisiert werden können, da name nicht null sein darf, da es ein schlusselkanidat ist. Nehmen wir aber mal an name wäre kein schlüssel kanidat dann hätte dies aber zur folge, dass ein raum mehr als einem prof zugeordent werden kann, was ebenfall im er-modell nicht möglich ist. Also sollte man prof und raum nicht verschmelzen
Die Kanten im Serialisierbarkeitsgraph gehen doch von der späteren zur früheren Transaktion, warum ist w1 dann hier als erstes?
Laut Aufgabenstellung gehen die Kanten von früheren zu späteren Operation.