*** ER-Diagramm im Private RC Chat *** *** RelModel im Private RC Chat *** *** ER als Mail *** *** RM als Mail *** *** FKs als Mail *** *** Baeume als Mail *** Nur sehr fragmentarische Abdeckung der Aufgabenstellung ** Antwort und Bewertung bei Frage 2 Reise/Angebot/Klasse/Preis nicht reifiziert -1 Stop/LegtAn/Besichtigung nicht reifiziert -1 Preis und Besichtigung schön reifiziert, aber das dann auch verwenden ... Preis reifiziert ist gut. Zwischenstop/Besichtigung reifiziert ist gut. Zusammenhang Reise/Klasse/Preis fehlt -2 (den Preis nur bei Buchung abzulegen würde ja bedeuten, dass man vor der ersten Buchung keinen Preis speichern kann) Kardinalitäten bei "kostet" fehlen -1 Preis nicht abhängig von der Kabine, sondern von Klasse und Reise -1.5 Preis nicht an Schiff Klasse , sondern neue Bez. zwischen Reise (incl Schiff) und Klasse -1.5 Preis nicht an [Klasse], sondern neue Bez. zwischen Reise (incl Schiff) und Klasse -1.5 Klasse (Bezeichnung) und Reise (Code) nicht als attr, sind in den Beziehungen ja schon drin. Klassenpreis: Reise+Klasse nicht als Attribute, sondern die sind in den Beziehungen schon abgebildet -> [[weak]] Entity mit den beiden als <> Beziehungen -1 [[Preis]] muss ein Attribut mit dem Preis haben -1/2 Kardinalität Reise-kostet/Preis <0,*> -1/2 Kardinalität Klasse-kostet/Preis <0,*> -1/2 Kardinalität Klassenpreis-festgelegt <1,1> (weak, id) -1/2 Kardinalität Preis-Klasse <1,1> -1/2 Kardinalität Preis-Reise <1,1> -1/2 An welchem Tag die Reise an welchem Ort ist, fehlt ganz -2 Modellierung von legt_an als dreistellige Beziehung mit den Ausflügen ist nicht sinnvoll -> Zusammenhang zwischen Reise+Ort rausziehen -2 Zwischenstop muss eine Beziehung zu Reise haben (und weak sein) -1.5 Besichtigung/legt_an muss weak zu Reise sein mit <> -1 Besichtigung weak, also muss es eine <>-Beziehung geben (<> zu Reise) -1/2 Wenn [[Zwischenstop]] weak und <> zu Reise als <>, muss <1,1> sein -1/2 Kardinalität Besichtigung/legt_an - Reise <1,1> -1/2 Besichtigung/legt_an weak -> muss <>-Bez zu Reise haben -1/2 Besichtigung/legt_an weak zu Reise -> muss <1,1> sein -1/2 Besichtigung/legt_an Datum muss auch key sein -1/2 (zumal es auch 2 Tage am selben Ort bleiben kann) Besichtigung/legt_an nicht auch noch weak zu Ort (Reise+Datum genügt, kann ja nicht an einem Tag an zwei Orten sein) -1/2 Besichtigung/legt_an muss weak zu Reise mit key Datum sein, weak zu Ort reicht nicht -1/2 (kann 2 Tage am selben Ort bleiben oder nochmal vorbeikommen) Ort nicht als key (Reise+Datum genügt) -1/2 Besichtigung/legt_an Datum fehlt -1/2 (wenn nur als Beziehung) Besichtigung/legt_an Datum fehlt -1 (muss auch key sein) Kardinalität Besichtigung/legt_an - Ort <1,1> -1/2 Kardinalität Reise - Besichtigung/legt_an <0,*> -1/2 Kardinalität Ort - Besichtigung/legt_an <0,*> -1/2 Ausflug weak mit <> muss dann <1,1> sein -1/2 Wenn [[Ausflug]] weak -> muss eine <> Beziehung mit <1,1> haben -1/2 Wenn [[Ausflug]] weak und <> zu Reise als <>, muss <1,1> sein -1/2 Ausflug muss Beziehung zu Reise oder Reisetag haben (Preis kann bei jeder Reise ein anderer sein) -1.5 Ausflug muss Beziehung zu Reise (oder Reisetag/Stop) haben, Ort alleine bringt wenig -1 Ausflug.Bezeichnung muss auch Schlüssel sein -1/2 Ausflug.Datum muss auch Schlüssel sein (sonst Buchungen Sintra 24.5. oder 25.5. ggf nicht eindeutig) -1/2 Ausflug muss Datum (als Schlüssel) haben, sonst Buchungen nicht eindeutig -1/2 Ausflug muss Datum (als Schlüssel) haben (oder weak zu Reisetag), sonst Buchungen nicht eindeutig -1/2 Wenn [[Zwischenstop/Besichtigung]] schon als reifizierter Entitätstyp modelliert ist, Ausflug über <> dort anhängen, dann hat man das Datum passend von dort -1/2 Kardinalität Ausflug-Reise <1,1> (weak, id) -1/2 Kardinalität Ausflug-Ort <1,1> -1/2 Beziehung Ausflug-Reise nicht notwendig/sinnvoll, denn die ergibt sich Ausflug->Stop->Reise Beziehung Ausflug-Ort nicht notwendig/sinnvoll, denn die ergibt sich aus Reise+Datum Beziehung Ausflug zu Ort nicht identifizierend, die ist sowieso redundant (Reise+Datum) -1/2 Ausflugspreis fehlt -1/2 Kardinalität Besichtigung/legt_an-Ausflug <0,*> -1/2 Kardinalität Ausflug-Besichtigung/legt_an <1,1> -1/2 Kardinalität Reise-Ausflug <0,*> -1/2 Ausflug- <0,*> -moeglich (dann nicht weak) könnte man so modellieren, wenn mehrere Reisen denselben Ausflug (am selben Datum) anbieten, dann muss (Preis) aber an um auf unterschiedlichen Reisen einen unterschiedlichen Preis haben zu k"onnen. Wenn Kardinalität Ausflug-Zwischenstop <1,*>, dann muss der Preis an die Beziehung zum Zwischenstop -1/2 Wenn Kardinalität Ausflug-Reise <1,*>, dann muss der Preis an die Beziehung zur Reise -1/2 Ausflug mit Key (Bezeichnung, Datum) und <1,1> nicht-weak zu Reise ist etwas kritisch, wenn ein Ausflug an einem Tag für mehrere an diesem Tag an diesem Ort seiende Reisen angeboten wird - dann müssen daraus mehrere Ausflüge mit verschiedenen Namen werden. (dann folgt meistens im Relationalen Entwurf die Inkonsistenz (**)) Wenn [[Besichtigung (Reise, Datum)]] schon als reifizierter Entitätstyp modelliert ist, dann Ausflug nicht mit eigenem Datum an Reisen, sondern besser direkt an [[Besichtigung]] anhängen Ausflug besser mit Beziehung zu Reise (oder Reisetag/Stop), Ort alleine bringt wenig - dann muss man erst rausfinden, welche Reisen and dem Tag in dem Ort sind. Preis soll ja bei verschiedenen Reisen unterschiedlich sein können -1/2 [[Buchung]] warum weak (id ist ja key!) -1/2 Buchung: Klasse+Reise(Code)+Kabine sind keine Attribute, sondern Beziehungen -3 Beziehung zwischen Buchung und Reise fehlt -1.5 Wenn [[Preis]] schon als reifizierter Entitätstyp modelliert ist, dann Buchung nicht einzeln an Reise und Klasse, sondern direkt an [[Preis]] anhängen -1/2 Modellierung von Buchung nur als Beziehung, nicht als Entitätstyp: reicht nicht aus: geht ja mehrwertige Beziehungen (Mitreisende, Ausflugstickets) ein. -2P Buchung hat ID als key, also nicht auch noch weak mit <> zu Reise -1/2 Beziehung Buchung - Klasse fehlt -1.5 Beziehung Buchung - Reise fehlt -1.5 Die Beziehung Buchung (Reise,Klasse) hätte zum reifizierten [[Preis]] gehen müssen -1/2 Kardinalität Reise-Buchung <0,*> (am Anfang ja nichts) -1/2 Kardinalität Buchung-Reise <1,1> -1/2 Kardinalität Buchung-Klasse <1,1> - jede Buchung genau eine Klasse -1/2 Kardinalität Klasse-Buchung <0,*> -1/2 Kardinalität Preis/Angebot-Buchung <0,*> -1/2 Kardinalität Buchung-Preis/Angebot <1,1> -1/2 vertauscht -1/2 Beziehung Buchung - zugeordnete Kabine fehlt -1.5 Buchung.Kabine nicht (attr) sondern Beziehung -1 Kardinalität Buchung-Kabine <0,1> jede Buchung nur eine Kabine -1/2 Kardinalität Buchung-Kabine <0,1> zuerst null -1/2 Kardinalität Kabine-Buchung <0,*> -1/2 Beziehungen Buchung-Personen: Buchende bzw. mitreisende Personen separat, eine (hier wohl <1,1> buchende Person) fehlt -1.5 Kabine nicht in Beziehung zu Person (eine Person kann auf verschiedenen Reisen ja verschiedene Kabinen belegen), sondern zur jeweiligen Buchung -1 Kardinalität Buchung <1,1> -1/2 Hauptbucher ist eine Person -> nicht (attr) sondern Beziehung -1 Buchung.name nicht als (attr), sondern Beziehung zu Person -1 Mitreisende Personen fehlen -1.5 Kardinalität Buchung--Person <1,1> -1/2 Kardinalität Person- <0,*> -1/2 Kardinalität Person- <0,*> -1/2 Kardinalität Person- <0/1,*> -1/2 Mitreisende sind Personen -> nicht ((attr)) sondern Beziehung -1 Mitreisende nicht in Beziehung zu Kabine, sondern zu Buchung -1/2 Bewohner sind auch Personen -1/2 Kardinalität Ausflug-Buchung <0,*> -1/2 Kardinalität Buchung-Ausflug <0,*> -1/2 Ausflugsbuchungen fehlen -1.5 Anzahl Tickets fehlt -1/2 Anzahl Tickets nicht zu Buchung, sondern zu jeder Ausflugsbuchung -1/2 --Person geht so nicht, muss auch nicht abgelegt werden -1 Ausflugsbuchung zu reifizieren ist nicht notwendig (man kann ja das Attribut "Anzahl" an die Beziehung hängen) Reise - <1,*>- zu Buchung geht in der Realität nicht: zuerst muss eine Reise leer angelegt und angeboten werden, bevor die Kunden sie buchen können. -0.5 *** Relationales Modell ****************************************************** ** Antwort und Bewertung bei Frage 4 Nur sehr fragmentarische Abdeckung der Aufgabenstellung PK und FK over/underlined, aber die Referenzen, wohin die FKs gehen, fehlen (13 Referenzen -> -3.25P) FK overline auf XX fehlt -1/4 (fehlende Ref oben abgezogen) Beispieltupel fehlen -1P Notation der FK-Referenzen muss umgekehrt sein: referenzierendeTabelle(=wo es Foreign Key ist)(Spalte)-> referenzierte Tabelle(=wo es PK ist)(Spalte) jeweils -1/4 wenn ein FK in der Tabelle overlined ist, aber keine Referenz dafür angegeben PK fehlt -1/2 Tabelle Preis/Kosten/Angebot fehlt -2 Inkonsistent zum ER-Diagramm; dort war Preis an Kabine--Klasse (falsch), hier (richtig) Beziehung zwischen Reise und Klasse -1/2 Inkonsistent zum ER-Diagramm; dort war Preis an Reise-Kabine (falsch), hier (richtig) Beziehung zwischen Reise und Klasse -1/2 Preis zwischen Schiff/Klasse, nicht zwischen Reise/Klasse FF Klassenpreis: ok, PK OK, FKs fehlen 1P Preis ist nicht Teil des PK -1/2 Klasse muss auch Teil des Keys sein -1/2 FK Referenz Preis.^Reise^->Reise.Code fehlt (^FK^ ist da) -1/4 FK Referenz Preis.^Klasse^->Klasse.Bez fehlt (^FK^ ist da) -1/4 FK Preis->Reise fehlt -1/2 FK Preis->Klasse fehlt -1/2 Tabelle Stop/Besichtigung/Anlegen OK Tabelle Stop/Besichtigung/Anlegen fehlt -2 Inkonsistent zum ER-Diagramm; dort gab es keine Zwischenstops, kein Datum, ... -1/2 Spalte Reise fehlt (und muss im PK sein, ist FK) -1 Stop/Besichtigung: Reise muss auch im PK sein (ist ja im ER-D auch weak dazu) -1/2 Stop/Besichtigung: Reise muss auch im PK sein (zwei Reisen können an einem Tag am selben Ort sein) -1/2 wenn nur Reise key ist: Spalte Datum muss auch key sein -1/2 Spalte Datum fehlt (im ER-Modell ist das Attribut vorhanden, muss auch PK sein) -1/2 wenn Reise+Ort+Land PK sind und es im ER-D nur Beziehung war: Stop/Besichtigung: (Reise,Datum) ist der key, kann ja nicht an einem Tag an zwei Orten sein, -1/2 (Reise,Ort,Land) als key würde verbieten dass, wenn eine Reise auf dem Rückweg nochmal an einem Ort vorbeikommt, wo sie schon mal war. wenn Reise+Datum+Ort+Land PK sind und es im ER-D nur Beziehung war: Stop/Besichtigung: Ort/Land ist nicht Teil des keys, kann ja nicht an einem Tag an zwei Orten sein. -1/2 (und man muss/müsste (Ort,Name) nicht als FK überall mitschleppen) Inkonsistent (und Fehler) zum ER-D: dort war _Datum_ noch key, hier nicht -1/2 Ort/Land ist nicht Teil des keys FF (und man muss/müsste (Ort,Name) nicht als FK überall mitschleppen) Spalte Land muss dazu, ist Teil des PK der Tabelle "Ort", auch Teil FK -1/2 FK zu Ort fehlt -1/2 FK Referenz für ^Ort^ fehlt (dann wäre evtl aufgefallen, dass der FK nicht komplett ist) -1/4 FK Referenz Stop.^Reise^->Reise.Code fehlt (^FK^ ist da) -1/4 FK Referenz Stop.(^Ort^,^Land^)->Ort(Name,Land) fehlt (^FK^ ist da) -1/4 FK Referenz (Ort,Land) zusammen als zweistellige Referenz -1/4 Die Tabelle für die Ausflüge selber und ihre Preise fehlt -2 Ausflug: Bezeichnung muss im PK sein (vlg. ER-Diagramm) -1/2 Ausflug: Reise muss auch Teil des PK sein (im ER-D weak) -1/2 Ausflug: Reise muss auch Teil des PK sein (mehrwertige Beziehung) -1/2 Ausflug: Reise und Datum muss auch Teil des PK sein -1/2 Spalte "Reise" fehlt, muss im PK sein, und muss FK sein (Preis kann bei jeder Reise ein anderer sein) (FF aus ER-D, Vereinfachung) -1 (**-1) Ausflug: Verbindung/Spalte Reise fehlt -1/2 (teilw. FF, Vereinfachung) Inkonsistenz zum ER-D: im ER-D hat Ausflug Keys (Bezeichnung, Datum) und ist nicht weak zu Reise, also dürfte Reise nicht Teil des Keys werden -1/2 (**-2) (so ist es aber besser) FK Referenz Ausflug.Reise fehlt -1/4 Inkonsistenz zum ER-D: im ER-D ist Datum Teil des Keys (Bezeichnung, Datum), hier nicht (falsch) -1/2 Inkonsistent zum ER-Diagramm; dort war Ausflug (nicht optimal) nicht weak zu Reise, hier ist Reise jetzt (besser) auch key. -1/2 Wenn Datum schon im ER-D nicht key von Ausflug ist (FF): Ausflug: Datum muss auch Teil des PK sein (FF aus ER-D) Wenn Datum schon im ER-D key von Ausflug ist (FF): Ausflug: Datum muss auch Teil des PK sein (im ER-D war es das noch) -1/2 Datum muss auch Spalte und Teil des PK sein, (sonst Buchungen Sintra 24.5. oder 25.5.? ggf nicht eindeutig) -1/2 Datum muss auch Teil des PK sein, (sonst Buchungen (Sintra 24.5. oder 25.5.?) ggf nicht eindeutig) -1/2 FK Ausflug(Reise, Datum) -> Stop/Besichtigung(Reise,Datum) fehlt -1/2 FK Ausflug(Reise, Datum) -> Stop/Besichtigung(Reise,Datum) fehlt -1/2 (FF, aber Vereinfachung) [wenn mit "Zwischenstops" irgendwas schon nicht stimmt, meistens falscher PK] FK Referenz (Reise, Datum) -> Besichtigung zusammen als zweistellige Referenz -1/4 Ort nicht im PK, Reise kann ja an einem Tag nur an einem Ort sein Preis nicht Teil des PK -1/2 Ausflug.Ort ist nicht der vollständige Key -1/2 Ausflug.^Ort^->Ort.name ist nicht der vollständige Key -1/4 Für FK Ort muss Spalte Land dazu und (Ort,Land) sind FK -1/2 Ausflug.Ort(+Land) redundant (Reise,Datum genügt als FK auf Besichtigung) FF damit auch Ausflugsbuchungen.Ort redundant FF Anstatt Spalte Ausflugstickets (1:n) muss es eine separate Tabelle sein -2.5 Buchung: PK ist nur id -1/2 Buchung: Spalte Reise (und FK) fehlt -1 Buchung: Spalte Klasse (und FK) fehlt -1 FK Buchung.Person fehlt -1/2 FK Referenz Buchung.^Person^ fehlt (^FK^ ist da) -1/2 FK Buchung.Reise fehlt -1/4 FK Buchung.Klasse fehlt -1/4 FK Referenz Buchung.^Reise^ -> Reise.Code fehlt (^FK^ ist da) -1/4 FK Referenz Buchung.^Klasse^ -> Klasse.Bez fehlt (^FK^ ist da) -1/4 FK Referenz Buchung.(^Reise^,^Klasse^) -> Angebote/Preis (Reise,Klasse) fehlt (beide ^FK^ sind da) -1/4 FK Referenz Buchung.(^Reise^,^Klasse^) -> Angebote/Preis (Reise,Klasse) fehlt -1/2 [höchst. eine Einzelref da] (FK Buchung.Reise/Klasse ist auch nicht da) FK Referenz Buchung.(^Reise^,^Klasse^) -> Angebote/Preis (Reise,Klasse) fehlt (beide ^FK^ sind da, Einzelreferenzen fehlen auch) -1/2 FK Referenz Buchung(Reise, Klasse) -> Preis fehlt, FF aus Preis-Tabelle, -1/4 wg. Vereinfachung FK Referenz Buchung(Reise, Klasse) -> Preis fehlt, FF aus Buchung in separater Tabelle, -1/4 wg. Vereinfachung FK Referenz für Name fehlt (^FK^ ist da) -1/4 Inkonsistent zum ER-Diagramm; dort war Buchung-Klasse <1,*> (falsch), hier ist Klasse eine Spalte in Buchung -1/2 Gebuchte Klasse müsste zu Buchung mit rein (FF aus falscher <1,*>-Kardinalität) -1/2 da es die FKs vereinfacht (dann (Reise,Klasse) --1/4 nicht separat abziehen) ## DANN prüfen ob PK=beide Attrs richtig gemacht wurde! Buchung: zugeordnete Kabine fehlt FF, -1 wg. Vereinfachung Buchung: zugeordnete Kabine fehlt -1 wg. Vereinfachung (ggf -1/2 wegen Inkonsistenz zum ER-D abziehen) (Buchung: zugeordnete Kabine in separate Tabelle FF aus ER-D) wenn Buchung.Kabine -> Kabine.Nr oder nur ^Kabine^ angegeben ist: FK Referenz Buchung.^Kabine^->wohin fehlt (^FK^ ist da) -1/4 Buchung.^Kabine^->Kabine.Nr ist nicht der vollständige Key -1/4 beide Fälle: Für FK Kabine muss Spalte Schiff dazu und (Kabine+Schiff) sind FK -1/2 wenn Kabine als Spalte, aber nicht als FK gekennzeichnet und keine Referenz: Kabine muss Teil eines FK sein - dazu muss Spalte Schiff dazu und (Kabine+Schiff) sind FK -1 FK Referenz (Kabine,Schiff) zusammen als zweistellige Referenz -1/4 FK Referenz (Kabine,Schiff) fehlt -1/4 Spalte Mitreisende muss separate Tabelle sein (mehrwertig!) -1.5 Spalte Ausflugstickets muss separate Tabelle sein (mehrwertig!) -2.5 Spalte Tickets ist redundant (ergibt sich ja aus der Anzahl Einträge in "reisend") Tabelle Mitreisende fehlt -2 PK Mitreisende ist (Buchung,Person) -1/2 FK Mitreisende.Buchung fehlt -1/2 FK Mitreisende.Person fehlt -1/2 Tabelle Ausflugsbuchungen fehlt -2.5 Ausflugsbuchung: ## wenn FK nur auf Bezeichnung, und auch nur Bezeichnung als Spalte: es müssten die PKs der beiden beteiligten Relationen (Buchung ID; Bezeichung, Reise, Datum) als Spalten da sein und ein passender key gebildet werden -1 ### dann auch (***) abziehen Bezeichnung und Datum müssen auch Teil des Keys sein -1/2 ## wenn Reise schon bei "Ausflug" nicht dabei: Spalte Reise (auch als FK für Ausflug) fehlt FF, Vereinfachung -1/2 FK Ausflugstickets.Buchung fehlt -1/2 FK Referenz Ausflugstickets.^Buchung^->Buchung.Nr fehlt (^FK^ ist da) -1/4 FK Ausflugsbuchungen->Ausflug fehlt -1/2 (***-1) FK Referenz->Ausflug unvollständiger FK (Bezeichnung ist nur ein Teil des Ausflug-Keys) -1/4 (***-2) Spalte Datum wird (auch als Teil des Keys!) vermisst, sonst Buchungen (Sintra 24.5. oder 25.5.?) ggf nicht eindeutig -1/2 (nicht als FF gewertet, da es beim Eintragen der Tupel auffallen sollte) FK Referenz Ausflugsbuchung.(^Ausflug^,^datum^)->wohin fehlt (^FK^ sind da) -1/4 Spalte(n) Datum, Reise fehlen (ist bei Ausflug im PK) und müssen im FK sein -1 FK Referenz Ausflugsbuchung(^Reise^,^Datum^,^Ausflug^) -> Ausflug(Reise, Datum, Bezeichnung) fehlt (^FK^ sind da) -1/4 FK -> Ausflug fehlt -1/2 (wenn nicht alle ^FK^ markiert sind) Ausflugsbuchung: Reise ist nicht Teil des PK (folgt funktional aus Buchungs-ID) -1/4 FK Referenz (Bezeichnung,Reise,Datum) zusammen als dreistellige Referenz -1/4 *************** CREATE TABLE *************** PK ist nur id (FF) Reise, Klasse, Person NOT NULL (sind ja nicht im PK, also nicht zugesichert) -1/2 Gebuchte Klasse müsste zu Buchung mit rein (FF aus falscher Kardinalität) -1/2 wg Vereinfachung Spalte Klasse fehlt FF, -1/2 wegen Gebuchte Kabine fehlt FF, -1/2 wg. Vereinfachung Vereinfachung Spalte Reise fehlt FF, -1/2 wg Vereinfachung FK REF für Klasse fehlt, am besten gleich als (Reise,Klasse) -> Angebote/Preis(Reise, Klasse) -1/2 (nur abziehen wenn weder REF für (Klasse) noch für (Reise, Klasse)) FK REF (Reise,Klasse) -> Angebote/Preis(Reise, Klasse) fehlt FF Vereinfachung -1/4 alle FK REFs fehlen -1.5 FK Person fehlt -1/2 Gebuchte Kabine fehlt FF, -1/2 wg. Vereinfachung FK REF (Reise,Klasse) -> Angebote/Preis(Reise, Klasse) fehlt FF Vereinfachung -1/4 Kabine wg falscher Kardinalität in separater Tabelle, FF, -1/2 wg Vereinfachung FK für Kabine fehlt komplett -1/2 FK für Kabine fehlt komplett FF -1/4 Kabine alleine ist kein FK, Spalte Schiff fehlt (Kabine.(Schiff,Nr) ist dort key) FF -1/4 FK Referenz (Kabine,Schiff) zusammen als zweistellige Referenz -1/4 Spalte Mitreisende muss separate Tabelle sein (mehrwertig!) FF Spalte Mitreisende muss separate Tabelle sein (mehrwertig!) - war in Aufgabe 3 aber nicht da -1/2 Spalte Tickets muss separate Tabelle sein (mehrwertig!) FF Spalte Tickets muss separate Tabelle sein (mehrwertig!) - war in Aufgabe 3 aber nicht da -1/2 Spalte Ausflüge muss separate Tabelle sein (mehrwertig!) FF Spalte Ausflüge muss separate Tabelle sein (mehrwertig!) - war in Aufgabe 3 aber nicht da -1/2 #### Queries Algebra als Upload in Aufgabe 14 Bäume zu Anfragen (1), (4), (6), (8) - Bewertungen und Punkte siehe dort Baum zu Anfrage (4) - Bewertung und Punkte siehe dort nicht zielführend 0P jeweils -1/2P wenn Tabellenname/Spaltenname mit dem eigenen Schema in Aufgabe 3 nicht übereinstimmen Land auch überprüfen -1/2 Land auch überprüfen FF Datum überprüfen -1/2 Schiff soll ausgegeben werden -1/2 Wenn man annimmt, dass Start/Ziel nicht in Zwischenstopp dabei sind, muss man es so etwas umständlich machen Zwischenstops, nicht Start/Zielorte -1 Algebra: (Land FF) Renaming code/reise fehlt -1/2 renaming name/Schiff fehlt -1/2 kein renaming notwendig ok Das aliasing x.name etc existiert in der relationalen Algebra nicht -> renaming, equijoin -1/2 Kein(e) Renaming(s) der Spalten für das/die Equi(!)joins: Stop.Reise=Reise.code -1/2 (Schiff hätte man nicht mal gebraucht, Reise.Schiff ausgeben) Projektion auf Name nicht eindeutig (Schiff.name, Ort.name) -> vorher projizieren order wegrenamen -1/2 Anfragen (2) SUM Name auch ausgeben -1/2 sum(preis) -1/2 Die Klasse der Buchung muss auch mit der Klasse, für die der Kabinenpreis gilt, übereinstimmen (sonst Summe über alle Klassen!) -1/2 Da die Klasse nicht in Buchung abgelegt ist und auch nicht als Join-Bed auftritt, würden die Preise aller Klassen aufsummiert -1 Join über Reise fehlt -1/2 (Tabelle Reise hätte man hier nicht benötigt) Preis ist in "Kostentabelle, nicht in "(Reise)Buchung/HatGebucht" -1/2 Die Tabelle heisst bei Ihnen nicht Buchung sondern booking, Spaltennamen auch anders -1/2 Preis ist in "Kostentabelle, nicht in "Buchung/HatGebucht" sum(preis), nicht count(preis) -1/2 GROUP BY name fehlt -1 Tabelle Buchung hat keine Spalte Preis -> mit "BietetAn" joinen (dann wäre evtl auch aufgefallen, dass in Buchung auch die Reise fehlt) 1.5P Anfragen (3) NEG GB Innen fehlt die Vergleichsbedingung mit aussen -1 Wenn für ein (neu gekauftes) Schiff bisher noch keine Reisen gespeichert sind, fehlt es -1/2 Problem mit Land FF Das sind alle Schiffe, die mindestens eine Reise gemacht haben, die einen Stop in GB hatten 0.5P Das sind alle Schiffe, die mindestens eine Reise gemacht haben, die mindestens einen Stop ausserhalb GB hatten 1P Das sind alle Schiffe, die mindestens eine Reise gemacht haben, die keinen Stop in GB hatte 2P Es geht nicht um GB als Ziel, sondern um Stops in GB -> innen ein Join mit Zwischenstops notwendig. 2P, da Struktur mit NOT IN prinzipiell richtig. erster Teil bis Zeile XXX richtig 1.5P Anfragen (4) NEG GB Algebra Renaming vor dem minus fehlt -1/2 pi[Schiff] links vor dem minus fehlt -1/2 rechts noch pi[Schiff] -1/2 Renaming code/reise fehlt -1/2 Präfixing "Ort.Land" gibts in der Algebra nicht. -1/4 da es in dem Fall garnicht benötigt würde Projektion auf Name nicht eindeutig (Schiff.name, Ort.name) -> vorher projizieren order wegrenamen -1/2 rechter Unterbaum des minus Projektion auf dieselben Attrs wie links -1/2 Bei minus müssen beide Unterbäume dieselben Spalten haben -1/2 Das wären alle Schiffe, die eine Reise durchgeführt haben, die keinen Stop in GB hatte -1 (pi[Schiff] muss unter das minus) linker Teil richtig 1.5P Anfragen (5) DIV Balkonkabinen Zeile 1 müsste ein distinct rein, wenn man die Personen aus "Buchung" nimmt -1/2 Das sind alle Personen die (mindestens) einmal auf einem Schiff gebucht haben, das Balkonkabinen hat 1P Das sind alle Personen die (mindestens) einmal eine Balkonkabine gebucht haben 1P Das sind alle Personen, die auf jeder Reise ein Schiff gebucht hatten, das Balkonkabinen hat 2P Das sind alle Personen, die nie auf einem Schiff gebucht haben, das Balkonkabinen hat 1P mittleres SELECT: das Schiff muss Balkonkabinen haben -1 Zeile 12: die Buchung selber muss nicht unbedingt eine Balkonkabine sein -1/2 mittleres SELECT: Schiff hat keine Spalte Kabinenklasse -> Tabelle "Kabine" nehmen -1/2 inneres SELECT: Reisen.Person gibt es nicht -> Buchung mit reinnehmen -1 die vorgegebene Tabelle "Klasse" hat keine Spalte k.Schiff -A über Kabine gehen -1 In Buchung gibt es keine Spalte "Schiff" -> innen Buchung, Reise verwenden und Schiff prüfen -1 Strukturell richtig 4P Buchung aussen statt ganz innen: ganz innen: dort Buchung dazu und statt b.id=r.code (Buchungsnummer=Reise-Code) b.reise nehmen und statt r.code=s.name muss es r.schiff sein (dann: alle Buchungen, so dass es kein Balkon-Schiff gibt, das nicht bei der Reise zu DIESER Buchung verwendet wurde) der Test auf Balkon muss auf die mittlere Ebene -1/2 strukturell fast richtig 3P Reise darf nicht auf die mittlere Ebene, sondern ganz innen. Das sind die Personen, die ALLE Reisen, die mit einem Schiff mit Balkonkabinen durchgeführt wurde, gebucht haben. Also wohl niemand. 3P Innen darf "Schiff" nicht nochmal im FROM stehen, das ist ja schon auf der mittleren Ebene -1 Zeile 5: nicht "Schiff" (dort keine Angabe über Kabinenklassen), sondern "Kabine" oder Preise/Angebote 4.5P Es gibt eine Möglichkeit, die hier notwendige "relationale Division" mit COUNT zu machen, die ist aber anders (und etwas hinterhältig, weil man die Bedingung "hat Balkonkabinen" zweimal reinbringen muss). Anfrage (6) Dass es eine Division ist, ist richtig, rechts: Kabine und sigma richtige Bestandteile, div: links/rechts vertauscht -1 pi[person,schiff] fehlt vor der Division -1 dieser Ausdruck ist nicht zulässig und auch nicht zielführend Das sind alle Personen, die einmal eine Reise auf einem Schiff mit Balkonkabinen gebucht hatten. 1P Anfragen (7) alle Reisen mit Stop in P DISTINCT fehlt -1/2 from: buchende Personen, nicht alle Personen -1/2 (die Tabelle "Reise" hätte man garnicht gebraucht) Das sind alle Personen, die mindestens eine Reise gebucht haben, bei der ein Ort in Portugal angelaufen wurde 1P Das sind alle Personen, die mindestens eine Reise gebucht haben, bei der kein Ort in Portugal angelaufen wurde 1P Das sind alle Personen, die nie eine Reise gemacht haben, die einen Stop hatte der nicht in Portugal war 1P Strukturell falsch - wenn die Bedingungen zu den Tabellen passen würden, gäbe es alle Personen aus die einmal eine Reise gemacht haben, die keinen Stop in Portugal hatte 1P richtig bis Zeile 5 Mitte, und dann NOT EXISTS Besichtigung ... 3P strukturell ok 2.5P Anfragen (8) hier geht es nicht mit Division, weil die rechte Seite ("Soll") von der linken Seite (Buchungen einer Person) abhängt. Das Ergebnis hier wären diejenigen Personen, die ALLE Reisen, die einen Stop in P hatten, mitgemacht haben. 1P Die Signaturen des linken und rechten Unterbaums ergeben auch nichts, mit dem man sinnvoll eine div machen kann. Das geht nicht als Division. Das Ergebnis sind diejenigen Personen, die ALLE(!) Reisen, die einen Stop in P hatten/haben, gebucht haben. 1P Das wären eher diejenigen Personen, die nie eine Reise gebucht haben, die einen Stop in P hatte 1P Im linken Unterbaum müsste aber auch dafür eine Projektion (Buchungs-ID weg) vor die Division. dieser Ausdruck ist nicht zulässig und auch nicht zielführend 0P UPDATE: In dem einen Fall ist ein INSERT richtig. In den anderen Fall (123456789) ist aber schon ein Tupel vorhanden -> UPDATE -2.5P Die Idee mit dem Update ist prinzipiell richtig. Aber funktioniert ja nur, wenn schon ein Tupel da war. Bei dem Tupel für die 213456789 war noch keines da -> hier INSERT -1.5P Nicht beides, UPDATE und INSERT. Jeweils nur eines. -1/2 Das INSERT für Buchung 213456789 fehlt -1.5P Aufgrund der vereinfachenden Voraussetzung gibt es auch nur die 2.5P für das UPDATE-Statement Die Tabellen- und Spaltennamen passen nicht zu dem in Aufgabe 3 entwickelten Schema -1 Die Spalte heisst hier nicht ID, sondern Buchung -1/2 Hier hätte auffallen müssen, dass die Ausflugsbuchungen wegen 1:n weder in der Tabelle "Reisebuchung" noch in "Ausflüge" sein dürfen -1/2 Setzt *alle* Ausflugsbuchungen, die zu dieser Reisebuchung gemacht wurden, hoch -1 Anzahl = Anzahl +1; es muss ja eingerechnet werden, welcher Wert vorher dort stand -1/2 (aufgrund des fehlerhaften Entwurfs für die Ausflugstickets in Aufgabe 3 wäre das sowieso hier problematisch geworden, dabei hätte der Fehler auffallen können) Die Bezeichnung des Ausflugs muss auch verglichen werden - jemand könnte ja für die mitreisende Familie am selben Tag verschiedene Ausflüge buchen. -1/2 (Um sicher zu sein, müsste das Datum auch überprüft werden) Wenn Tickets nicht als separate Tabelle: Ausflug vs Ausflugstickets FF Bei den Fragezeichen rächt sich das redundante Mitführen von Ort/Land: Entweder Ort/Land sind unwichtig, dann sollten die Spalten nicht da sein, oder sie sind wichtig, dann dürfte man kein "?" setzen -1/2 (AnzahlTickets bei 213456789 = 1) RUNDREISE: Das sind nur einzelne Reisen, die in HH starten und enden, aber keine Rundreisen, die aus mehreren Reisen zusammengesetzt werden. Das sind nur jeweils Paare aus zwei direkt aufeinanderfolgenden Reisen. Reise: immer Ort+Land: Start+StartL/Ziel+ZielL Die Spaltennamen passen nicht zum (vorgegebenen!) Schema von "Reise" Die Idee bis Zeile 9 Mitte ist richtig. Die Idee in Zeile 2 mit zwei Reisen Start+Ende zu arbeiten und Anforderungen an die Zwischenreisen zu stellen, ist richtig Mit der zweiten Hälfte von Zeile 9 wird das dann aber kaputtgemacht: es darf keine Reisen zwischen Start und Ende geben ... 3P -- wenn Ansatz mit 2 Reisen und Subquery für Zwischenreise richtig: 3P Die Idee bis Zeile 12 ist richtig. Mit dem Rest bis Zeile 16 wird das dann aber kaputtgemacht: es darf mkeine Reisen zwischen START und Ende geben ... ## 7 Teilnehmer haben es mit WITH RECURSIVE versucht, bzw gemacht: Reise: immer Ort+Land: Start+StartL/Ziel+ZielL -1/2 Spaltennamen: "von"/"bis" für Start/Enddatum -1/2 WHERE im Basisfall: StartL='D' JOIN-Bedingung: und dasselbe Schiff -1/2 WHERE: hier schon Ziel=Hamburg zu fordern würde nur Reisen dranhängen, die direkt wieder nach HH gehen -1/2 Zeile 6: Attribute von r und von rt kombinieren, sonst verliert man den Zusammenhang -1 -> rt.Start/land+"von" und r.Ziel/land+"bis" (=Enddatum) nehmen => dann ist jedes Tupel in "Rundreise" eine Reise ohne Pause, die in HH beginnt. -> wenn man dann einfach nur Ziel=HH/D testet, hat man die Ergebnisse. endlose Rekursion: da ja mit jedem Level das Ankunftsdatum zeitlich später ist, kann der Loop nicht unendlich lange laufen, irgendwann ist die Datenbank (bzw die vorgeplanten Zeiträume) zu Ende. -1/2 Das GROUP BY Schiff: macht dann aber alles kaputt: -1 es nimmt das Startdatum der frühesten solchen Reise, und das Enddatum der spätesten - auch wenn das Schiff dazwischen irgendwo eine Woche Wartungspause oder sowas hat. ###### WITH RECURSIVE Rundreise (Schiffsname , Startdatum , Enddatum , Startort , Endort ) AS ( SELECT Schiffsname , Startdatum , Enddatum , Startort , Endort FROM Reise WHERE Startort = ’Hamburg’ UNION ALL SELECT r.Schiffsname , r.Startdatum , r.Enddatum , r.Startort , r.Endort FROM Reise r JOIN Rundreise rt ON r.Schiffsname = rt.Schiffsname AND r.Startdatum = rt.Enddatum ) SELECT Schiffsname , MIN (Startdatum) AS Abreisedatum , MAX ( Enddatum ) AS Rückkehrdatum FROM Rundreise WHERE Endort = ’ Hamburg ’ GROUP BY Schiffsname ; ###### WHERE im Basisfall: StartL='D' -1/2 WHERE in Zeile 27: Reise.Ziel ist eine Stadt, min(von) ist ein Datum ... und aber auch die (Datums)bedingung passt nicht, und es wird nicht getestet ob es dasselbe Schiff ist. -1 Hauptteil Zeile 30ff: es wird nicht geprüft, ob man am Ende wieder in HH ist, (nächstesZiel müsste HH sein) und max(Rückkehrdatum) würde ja ggf zu lange fahren, wenn man zwischendurch schon mal am Ende einer Teilreise in HH war. 4P weil es ein ausbaufähiges Resultat ist. (allerdings hätte man RECURSIVE hier garnicht gebraucht, war ja in der Vorlesung auch nicht dran) KÜNSTLICHE IDs: a) Auswirkungen auf ER-D (weak/id: 1P): 0P PK im RM (Schiff+vonDatum: 2P) : 2P (bis braucht man nicht) 1.5 P Schiff ist kein Attribut, sondern über eine Beziehung verbunden -> [[Reise]] müsste weak sein -1 Teil a): ER-M+RM ok 3P Auswirkungen auf andere Tabellen (Mitziehen zu Zwischenstop, Buchung usw.) 1P (das "unübersichtlich" kann man diskutieren - bei dem FK Kabine vermisst man "Schiff" ja dann) zusammenges. Schlüssel: mehr Attrs/mehr Speicher, längere Join-Bedingungen 1+1P Performance direkt nicht beeinträchtigt, da Index auf Key künstl ID: kürzer/einfacher je nach Formulierung 1-2P weniger Attrs 1P verständlicher/intuitiver vs unnötige Information 1/2P - trifft nicht immer zu künstl.Schl"ussel: manchmal zusätzliches Join notwendig um Werte-Attrs zuzugreifen 1P nat.Schlüssel: ggf weniger Joins notwendig 1P weniger Attrs, einfachere Join-Bedingungen 1+1P Verdecken von Attributen und verlorene Integritätsbedingungen: Buchung.Schiff für FK->Kabine 1P Ausflugsbuchung.Reise für FK->Ausflug 1P wenn genannt: Verhalten bei Änderungen an den Daten +1P wenn genannt: zusammengesetzte Schlüssel können manchmal zusätzliche Eindeutigkeitsbedingungen zusichern (Schiff,von) - hier aber nicht besonders wertvoll wenn genannt: eindeutige IDs finden/verwalten 1P Der Rest geht an der Frage vorbei und ist zum Teil auch nicht zutreffend "weniger Änderungen" nein, genau das ist umgekehrt. Eine künstliche ID ändert sich nie, bei einer "echten" ID kann es in der Realität passieren, dass man die durch die Fremdschlüssel in der ganzen Datenbank durchziehen muss (Mondial: Landescode oder ein Stadtname ändert sich) nur angefangenes Satzfragment 0P ################