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!

Ähnliche Dokumente
Daten Bank. 2. Vorlesung. Dr. Karsten Tolle PRG2 SS 2014

Geoinformation Abbildung auf Tabellen

Garten - Daten Bank. - survival pack -

Theorie zur Übung 8 Datenbanken

Probeklausur mit Musterlösung

Daten Bank. 2. Vorlesung. Dr. Karsten Tolle PRG2 SS 2015

Vorlesung Datenbank-Entwurf Klausur

Klausur Datenbanken II

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Alfons Kemper, Ph.D.

Datenbank und Tabelle mit SQL erstellen

Relationale Datenbanken in der Praxis

Es geht also im die SQL Data Manipulation Language.

Rückblick: Entity-Relationship-Modell

Prüfung Informatik für Ökonomen II. 14. Januar Teil 1: Datenbanktechnik Musterlösungen

Datenbanken Entity-Relationship-Modell und Datenbankentwurf 1. Andreas Heß Hochschule Furtwangen

GROUP BY, HAVING und Sichten

Daten-Definitionssprache (DDL) Bisher: Realwelt -> ERM -> Relationen-Modell -> normalisiertes Relationen-Modell. Jetzt: -> Formulierung in DDL

In diesem Abschnitt wollen wir uns mit der Architektur von Datenbank Managements Systemen beschäftigen.

Aggregatfunktionen in der Relationenalgebra?

Multimedia im Netz Wintersemester 2013/14. Übung 03 (Nebenfach)

OR-Mapping. WS2008/2009 DBIS/Dr. Karsten Tolle

Oracle: Abstrakte Datentypen:

Überblick Felix Naumann. Zugriffsrechte Zugriffsrechte erzeugen Zugriffsrechte prüfen Zugriffsrechte vergeben Zugriffsrechte entziehen

Abbildung 1: Das ERM. Nun zu den Tabellen: Zunächst wird aus jeder Entity eine Tabelle, d.h. wir erhalten:

Datenmodelle und Datenbanken 2

Gruppe A Bitte tragen Sie SOFORT und LESERLICH Namen und Matrikelnr. ein, und legen Sie Ihren Studentenausweis bereit.

Klausur Datenbanksysteme, Lösungen

Relationales Datenbankpraktikum 2016ss

Objektrelationale, erweiterbare Datenbanken

Oracle SQL Tutorium - Wiederholung DB I -

Fakultät für Informatik & Wirtschaftsinformatik DB & IS II - SS Metadaten

Daten Bank. 6. Vorlesung

In diesem Abschnitt wollen wir uns mit einem besonderen Thema widmen. Dem Thema SQL-JOIN.

Datenbanken für Online Untersuchungen

SQL Tutorial. SQL - Tutorial SS 06. Hubert Baumgartner. INSO - Industrial Software

Welche Kunden haben die gleiche Ware bestellt? select distinct a1.name, a2.name from Auftrag a1, Auftrag a2 where a1.ware = a2.ware.

Webbasierte Informationssysteme

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Alfons Kemper, Ph.D.

Grundlagen von Datenbanken SS 2010 Kapitel 8: Datenbank-Einbettung in Programmiersprachen Prof. Dr. Stefan Böttcher Universität Paderborn

Gruppe B Bitte tragen Sie SOFORT und LESERLICH Namen und Matrikelnr. ein, und legen Sie Ihren Studentenausweis bereit.

OO Programmiersprache vs relationales Model. DBIS/Dr. Karsten Tolle

Seminar 2. SQL - DML(Data Manipulation Language) und. DDL(Data Definition Language) Befehle.

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Alfons Kemper, Ph.D.

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann

Einleitung 19. Teil I Einführung in Datenbanksysteme 25. Kapitel 1 Wozu Datenbanksysteme da sind 27

4. Objektrelationales Typsystem Kollektionstypen. Nested Table

SQL für Trolle. mag.e. Dienstag, Qt-Seminar

Visualisierung in Informatik und Naturwissenschaften

Vorlesung Wissensentdeckung in Datenbanken

Datenbankentwurf. Kapitel 3. Datenbankentwurf 76 / 508

2 Mengenlehre. Definition: Unter einer Menge M versteht man die Zusammenfassung von unterscheidbaren Objekten (den Elementen) zu einem Ganzen.

ids-system GmbH Tipp #3 Leer-Strings in SQL oder die Frage nach CHAR oder VARCHAR

Datenbanken. Seminararbeit. Einführung in das wissenschaftliche Arbeiten

Bitte beachten: Die Vorschläge sind keine Musterlösung!

Es wird empfohlen folgendes Material anzusehen:

Data Cubes PG Wissensmangement Seminarphase

dbis Praktikum DBS I SQL Teil 2

Musterlösung zur Finalklausur Datenbanksysteme am

Datenbanken Unit 3: Das relationale Modell

Dies ist eine Probeklausur, die keine formalen Schlüsse auf die Form, die Struktur oder den Inhalt der endgültigen Klausur zulässt.

ARBEITSBLATT ZUR SQL-BEFEHLEN

Datenbanken Unit 3: Das relationale Modell

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Alfons Kemper, Ph.D.

Übung 3. Komplexe SQL-Anfragen. Prof. Dr. Andreas Schmietendorf 1. Übung 3

IV. Datenbankmanagement

Introduction to Data and Knowledge Engineering. 6. Übung SQL

Kapitel 6. Datenmalipulation (DML) d. h. insert, update, delete, select im Relationenmodell (in Oracle)

Installationsanleitung All.Relation V

insert, update, delete Definition des Datenbankschemas select, from, where Rechteverwaltung, Transaktionskontrolle

Universität Augsburg, Institut für Informatik WS 2009/2010 Prof. Dr. W. Kießling 06. Nov Dr. A. Huhn, F. Wenzel, M. Endres Lösungsblatt 2

Aufgabe 12.1: JDBC - Datenbankzugriff in Java

Datenbanktechnologie mit praktischen Übungen in MySQL und PHP

Veranstaltung Pr.-Nr.: Datenmodellierung. Veronika Waue WS 07/08. Phasenschema der Datenbankentwicklung (grob) Informationsanalyse

Microsoft Access 2010 SQL nutzen

Übersicht der wichtigsten MySQL-Befehle

Datenbanksysteme 2013

Sonstige Assets. Assets über T-SQL Abfragen anlegen

Datenbanken mit OpenOffice-Base Tabellen und einfache Abfragen

Abfragen aus mehreren Tabellen (mit join)

Systemanalyse. - Folien zur Vorlesung für AI3 im Sommersemester Teil 5 -

Willkommen. Datenbanken und Anbindung

Klausur mit Musterlösung

10. Datenbank Design 1

Universität Augsburg, Institut für Informatik Wintersemester 2008/2009 Prof. Dr. W. Kießling 03. Februar Semesterklausur

Folien php/mysql Kurs der Informatikdienste

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann

Universität Augsburg, Institut für Informatik WS 2006/2007 Dr. W.-T. Balke 27. Nov M. Endres, A. Huhn, T. Preisinger Lösungsblatt 5

Einführung in die Informatik II

Teil 2-5. Vorlesung. Modul: Programmierung B-PRG Grundlagen der Programmierung II

Datenmanagement I SoSe 2006 Aufgabenblatt 4

PRÜFUNG SOFTWARETECHNIK II Musterlösung

Übung PL/SQL Trigger Lösungen

ODBC-Verbindungen in Oracle-Datenbanken nutzen

Abbildung 6-8: Abfolge beim doppelten Abschicken von Formularen

Das Entity-Relationship Modell

MySQL: SELECT-Abfragen über mehrere Tabellen (JOINs)

Datenbanken SQL Einführung Datenbank in MySQL einrichten mit PhpMyAdmin

Einführung in Datenbanksysteme, Datenbanken für die Bioinformatik Sommersemester Übungszettel (Abgabe Fr

7. XML-Datenbanksysteme und SQL/XML

Transkript:

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!

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.

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

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

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 (http://de.wikipedia.org/wiki/amtlicher_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.)

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.

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.

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

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.

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: http://stackoverflow.com/questions/11165944/how-to-change-mysql-tablenames-in-linux-server-to-be-case-insensitive

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