PRG-2 Musterlösung Blatt 9 SS Dies ist eine Musterlösung. Trotzdem können hier auch Fehler enthalten sein also keine Gewähr auf Korrektheit!

Transkript

1 PRG-2 Musterlösung Blatt 9 SS 2015 Dies ist eine Musterlösung. Trotzdem können hier auch Fehler enthalten sein also keine Gewähr auf Korrektheit!

2 Aufgabe 1 a) hatpraegeherr Praegeherr Amt Praegeherr_Person Praegeherr_Institution Je nachdem, was man aussagen möchte, ist die Kardinalität bei der Münze: also auch ohne Angabe des Prägeherrn möglich aber nur max. einer (1,1) genau ein Prägeherr für jede Münze Bem.: In echt wäre auch denkbar, jedoch gibt dies die Aussage der Aufgabenstellung nicht her. Sollte dies aber jemand mit nachvollziehbarer Begründung angeben, wäre es auch OK.

3 Aufgabe 1 b) : Jede Münze hat eine Vorder- und eine Rückseite, welche jeweils eine Beschriftung und/oder eine Abbildungen haben können. Oft wird eine Person oder eine Gottheit abgebildet. In diesem Fall spricht man auch von einem Portrait. (1,1) hatvorderseite Beschriftung Abbildung Seite (1,1) hatrueckseite Abbildung kann auch über eine Relation gelöst werden. Münze hat immer genau eine Vorder- und Rückseite, daher die (1,1). Nur ein Portrait pro Seite möglich, daher (auch anders denkbar, mit Begründung) Portrait hatportrait Portrait_Person Gottheit

4 Aufgabe 1 b) : Jede Münze hat eine Vorder- und eine Rückseite, welche jeweils eine Beschriftung und/oder eine Abbildungen haben können. Oft wird eine Person oder eine Gottheit abgebildet. In diesem Fall spricht man auch von einem Portrait. Beschriftung Abbildung Seitentype (2,2) hatseite Seite Auch eine Möglichkeit, wobei es von der Aufgabenstellung her eigentlich nicht so optimal ist, da man über BR sicherstellen muss, dass es nur eine Vorder- und eine Rückseite gibt und nicht zwei Vorder- Seiten. Weitere Alternative wäre für Vorderseite und Rückseite eigene Entitätstypen zu erstellen. Portrait hatportrait Portrait_Person Gottheit

5 Aufgabe 1 c) : Der Fundort einer Münze wird durch eine eindeutig identifiziert. Weiterhin hat er eine Geo-Position mit Längen- und Breitengrad. Jeder Fundort gehört zu genau einer Gemeinde, welche durch einen Amtlichen Gemeindeschlüssel ( identifiziert wird. Ebenfalls soll der Zeitpunkt des Auffindens der Münze mit erfasst werden. Zeitpunkt Long Lat hatfundort Fundort (1,1) liegtin AGS Auch die Geo-Position kann über eine Relation Gemeinde modelliert werden. Die Gemeinde könnte auch als Attribut (nur der AGS) an den Fundort gesetzt werden. Ist aber nicht so schön, man will sicher auch den Namen der Gemeinde speichern Wichtig ist den Zeitpunkt an die Relation hatfundort zu setzen! (Wenn als Kardinalität (1,1) gewählt wurde, ist der Zeitpunkt zwar an der Münze denkbar, ich persönlich halte diese aber dort auch in diesem Fall für nicht so schön.)

6 Aufgabe 2 (zu 1-c): Erstellen Sie für Ihre Modellierung der Teilaufgabe 1-c) ein gültiges Mengendiagramm, in welchem Sie vier Münzen und zwei Fundorte eintragen sollen. Beschreiben Sie kurz in eigenen Worten, was Sie darstellen wollen. 4 Münzen M1 M2 M3 T1 T2 T2 2 Fundorte FO1 FO2 M4 Beschreibung: Zeigt 4 Münzen, wobei M1-M3 am Fundort FO1 gefunden wurden. Die Münzen M2 und M3 wurden zusammen entdeckt, M1 zu einem anderen Zeitpunkt. Für M4 kennen wir den Fundort und die Fundzeit nicht, daher dort keine Verbindung.

7 Aufgabe 1 d) : Von einigen Münzen wissen die Archäologen, dass diese von einem Münzmeister in einer bestimmten Münzstätte während einer bestimmten Periode (von bis in Jahren) hergestellt wurden. Muenzmeister bis von produziert Muenzstaette Auch mit binären Relationen Denkbar, man muss dann prüfen, ob alle Informationen modelliert wurden. Da eine Münze nur einmal produziert werden kann, ist dort. Man beachte, dass dies nur mit der Min/Max-Schreibweise dargestellt werden kann. UML könnte dies nicht.

8 Aufgabe 3) : Muenzmeister Zeitpunkt Long Lat produziert hatfund ort Fundort bis von (1,1) Muenzstaette (1,1) (1,1) AGS liegtin Beschriftung hatrueck seite Abbildung hatvorder seite hatpraege herr Amt Praegeherr Gemeinde Seite Praegeherr_Person Praegeherr_Institution Gottheit hatportrait Portrait bis von Person Name Es sollte verstanden werden, dass bei Generalisierung nur die Oberklasse einen PK braucht. Praegeherr_Person hätte bei dieser Konstellation eine Mehrfachvererbung (Objekte hätten entsprechend zwei s). Man könnte diesen Objekttyp auch streichen. Will man aber zwischen Personen und Personen welche Prägeherren waren unterscheiden, wäre diese Modellierung gut/ok. wie das dann im Rel. Modell umgesetzt wird ist ja vorerst nicht gefragt

9 Busines Rules - Beispiele 1. Die Geo-Position des Fundortes muss innerhalb der Grenzen der Gemeinde liegen. 2. Die Objekttypen (Klassen) von Prägeherr_Institution und Prägeherr_Person müssen disjunkt sein. (Gleiches könnte man auch über Gottheit und Person sagen, wenn man dies will? Odysseus ein Gott? Halbgott?) 3. Der Prägeherr, wenn es eine Person war, muss während der Produktionszeit gelebt haben. Wichtig hierbei: 1. Formulierung wie auf den Folien: muss oder darf nicht oder so. 2. Die Regel darf nicht mit den Mitteln des ER-Diagramms wie in der VL vorgestellt darstellbar sein.

10 Aufgabe 5 Geben Sie für die SQL-Statements unten an, ob diese gültig sind oder eine Fehlermeldung geworfen wird. Falls sie gültig sind, beschreiben Sie in eigenen Worten, was das SQL-Statement macht oder anfragt; und geben Sie das Ergebnis von gültigen Anfragen an. Falls Sie eine Fehlermeldung erhalten/erwarten, erläutern Sie warum: a) INSERT INTO bestand (`id_laden`, `id_saft`, `VK`) VALUES (1, 'O-Saft', 1.25); Geht nicht, da O-Saft kein INT ist. b) SELECT * FROM bestand WHERE _Saft like '%saft%'; Geht, auch wenn hier nicht mit INT verglichen wird, jedoch ist das Ergebnis leer (leere Tabelle mit gleichem Schema wie Tabelle bestand). c) SELECT id_laden FROM bestand WHERE bestand.vk = max(bestand.vk); Geht nicht, Aggregation in der WHERE-Klausel nicht erlaubt. d) SELECT * FROM bestand b, laden l WHERE b.bestand < 100; Geht, macht aber kaum Sinn, da auf dem Kreuzprodukt gearbeitet wird (Joinbedingung fehlt). e) SELECT * FROM bestand b, laden l, saft s WHERE s.id=b.id_saft AND b.id_laden=l.id AND id_saft=2; Geht, hier ist auch die Joinbedingung gegeben, es werden also die richtigen Einträge miteinander verbunden. Übersetzung der Anfrage: Gib mir alle Informationen (aus allen drei Tabellen) über Saft mit der 2, wo/sofern dieser im Bestand eingetragen ist. Achtung, bei Linux kann es auch eine Fehlermeldung geben, da saft nicht gefunden wird. Details unter:

11 Ergebnisse d und e Ergebnis d) Ergebnis e) (wenn keine Fehlermeldung)