Universität Augsburg, Institut für Informatik WS 2009/2010 Prof. Dr. W. Kießling 06. Nov. 2009 Dr. A. Huhn, F. Wenzel, M. Endres Lösungsblatt 2 Aufgabe 1: ER-Modellierung 1. Siehe Unterstreichungen in Abbildung 1 2. Siehe Kardinalitäten in Abbildung 1 Datenbanksysteme I Abbildung 1: ER-Modell von Zugverbindungen 3. Beschreibung: Jeder Bahnhof liegt in einer Stadt. Eine Stadt kann aber wiederum mehrere Bahnhöfe haben. Jeder Zug hat einen ausgewiesenen Start- und Zielbahnhof, d.h. fährt auf einer festen Strecke. Auf dieser Strecke können mehrere Zwischenstationen auftreten, dies wird über die dreistellige Relation verbindet realisiert. Die Ankunfts- und Abfahrtszeiten stellen Attribute der Relation dar. 4. Optionalitäten lassen sich durch eine genauere Notation der Kardinalitäten einer Beziehung ausdrücken. Anstatt 1:N kann man z.b. genauer auch 1:1... N schreiben. Eine optionale Beziehung wird dann z.b. durch 1:0... N ausgedrückt, d.h. es kann auch Kardinalität 0 vorkommen. Nach ER-Notation der Vorlesung gibt es auch ein eigenes Symbol für optionale Relationships (siehe S. 22). In Abbildung 1 kann z.b. die Beziehung liegt in auf Seite der Entität Bahnhöfe optional sein, da zwar ein Bahnhof immer zu einer Stadt gehört, eine Stadt aber nicht zwingend einen Bahnhof haben muss. Zusätzlich sieht das Skript auch optionale Attribute vor. Ein Beispiel wäre hier das Attribut Länge der Entität Züge. 1
Aufgabe 2: Relationales DB-Schema 1. Relationenschema: Städte: (Name : String, Region : String) Bahnhöfe : (Name : String, #Bahnsteige: Integer) Züge : ( ZugNr : String, Länge : Float) liegt in : (BName : String, SName : String, Region : String) Start : (ZugNr : String, BName : String) Ziel : (ZugNr : String, BName : String) verbindet : ( VonBahnhof : String, NachBahnhof : String, ZugNr : String, Abfahrt : Date, Ankunft : Date) 2. Verfeinerung: Es werden Relationen für binäre Beziehungstypen mit Relationen für Entitytypen zusammengefasst, falls diese gleiche Schlüssel besitzen und es sich dabei um 1:N, N:1 oder 1:1 Beziehungen handelt. Damit ergibt sich folgendes Schema: Städte: (Name : String, Region : String) Bahnhöfe : (Name : String, #Bahnsteige: Integer, SName : String, Region : String) Züge : ( ZugNr : String, Länge : Float, StartBahnhof : String, ZielBahnhof : String) verbindet : ( VonBahnhof : String, NachBahnhof : String, ZugNr : String, Abfahrt : Date, Ankunft : Date) 2
Aufgabe 3: Modellierung von Entities 1. Als Beispiel werden die Entitäten Person mit Spezialisierungen Angestellter und Student, Sekretärin und Professor als Spezialisierung von Angestellter und schließlich Vorlesung als eigenständige Entität verwendet. Eine mögliche Modellierung dieser Konstellation findet sich in Abbildung 2. Dabei wird eine andere Notation als in der Vorlesung verwendet, ein ISA-Relationship wird z.b. durch Doppelstriche veranschaulicht. Vorname Nachname Anschrift Person Geburtsdatum Matrikelnummer Hauptfach Personalnummer Angestellter Student Nebenfach Zimmernummer Akademischer Status Gehaltsgruppe N ist registriert für M Nummer Sekretärin 1 1...N arbeitet für Professor 1 N lehrt Vorlesung Titel Raum Forschungsgruppe Lehrstuhl Abbildung 2: Erste Modellierung der Entities 2. Als Schlüssel kommen alle Attributkombinationen einer Entität in Frage, die eine Instanz (Tupel) eindeutig identifizieren. Schlüsselkandidaten sind dann wiederum diejenigen Schlüssel, für die keine Untermenge ein Schlüssel ist. In Abbildung 2 wurde als Primärschlüssel der Schlüsselkandidat {Anschrift, Vorname, Nachname, Geburtsdatum} für die Entität Person benutzt. Dies ist in der Tat ein Schlüsselkandidat, da keine Untermenge des Schlüssels ein gültiger Schlüssel ist. {Nachname, Anschrift, Geburtsdatum} ist z.b. kein gültiger Schlüssel, Zwillinge die im selben Haus leben wären somit nicht unterscheidbar. {Vorname, Nachname} reicht auch nicht als Schlüssel, siehe Universitätsmitarbeiter mit gleichen Vor- und Nachnamen. Die Spezialisierungen Angestellter und Student können den Primärschlüssel von Person übernehmen, aber auch andere Primärschlüssel definieren. Dies macht in diesem Fall Sinn, da beide Schlüsselkandidaten vorweisen, die nur aus einem Attribut bestehen (Personalnummer bzw. Matrikelnummer). Um Primärschlüssel mit vielen Attributen wie in Abbildung 2 zu vermeiden wird oft ein neues Attribut id eingeführt, das Tupel eindeutig identifiziert. Dementsprechend würde man die Primärschlüssel wohl auch eher wie in Abbildung 3 gezeigt wählen und auch für die Spezialisierungen Angestellter und Student auf den Schlüssel id als Primärschlüssel zurückgreifen. 3
3. Das Diagramm in Abbildung 3 verwendet jeden Relationship-Typ mindestens einmal: ISA: Angestellter und Student als Spezialisierung von Person 1:1 : Relationship zwischen Sekretärin und Professor könnte streng genommen als 1:1 Relationship modelliert werden 1:N : Eine Vorlesung wird genau von einem Professor gehalten N:M : Ein Student hört mehrere Vorlesungen, eine Vorlesung wird von mehreren Studenten besucht. optionales Relationship: z.b. Professoren im Forschungssemester, Studenten im Urlaubssemester, unattraktive Vorlesungen 4. In ER-Diagrammen sind Mehrfachvererbungen möglich. So könnte eine Konstellation z.b. so aussehen, dass Student sowohl von Person als auch von Angestellter erbt (z.b. ein HIWI). Mehrfachvererbung ist jedoch in J2SE nicht möglich. Vorname Nachname Anschrift Person Geburtsdatum id Matrikelnummer Hauptfach Personalnummer Angestellter Student Nebenfach Zimmernummer Akademischer Status Gehaltsgruppe N ist registriert für M Nummer Sekretärin 1 1...N arbeitet für Professor 1 N lehrt Vorlesung Titel Raum Forschungsgruppe Lehrstuhl Abbildung 3: (verbesserte) alternative Modellierung 4
Aufgabe 4: Das Relationenmodell 1. Bei einer Relation in der ersten Normalform müssen alle Attribute atomar sein, d.h. die Werte der Attribute dürfen nur aus elementaren Datentypen (z.b. VARCHAR oder DATE) bestehen. Die Relation Vorlesungsbetrieb(Student, Vorlesungen) lässt sich jedoch in zwei getrennte Entitäten aufspalten, die durch ein N:M Relationship in Beziehung zueinander stehen. Ein entsprechendes ER-Diagramm ist in Abbildung 4 dargestellt. Die dazugehörigen Relationen zeigt Abbildung 5. Abbildung 4: Entities 2. Wird dieses Diagramm in ein die entsprechenden Relationen-Schemata umgewandelt, so wird das N:M Relationship als eigenständige Tabelle modelliert, die als Fremdschlüssel den Primärschlüssel der Student-Relation und Vorlesung-Relation enthält. Abbildung 5 zeigt das umgewandelte ER-Diagramm in Relationenform. Abbildung 5: Relationen-Schema 3. Gültige Schemata müssen drei strukturelle Integritätsregeln (unabhängig von möglichen Anwendungen) erfüllen: Jede Relation braucht einen Primärschlüssel (siehe Skript S. 31) Referentielle Integrität: Existiert in Relation 4 ein Fremdschlüsselwert, so muss dieser auch in der korrespondierenden Relation als Wer vorhanden sein. (siehe Skript S. 32) Kein Attributwert des Primärschlüssels einer Relation darf Null sein (siehe Skript S. 33). Somit darf Vorlesung kein Tupel ohne id haben, Student keines ohne Matrikel-Nr. 5
Aufgabe 5: Ternäres Relationship Um das vorliegende Diagramm in ein relationales Schema zu überführen muss zuerst dessen Bedeutung klar werden. Das vorliegende Relationship beschreibt die ternäre Beziehung zwischen Studenten, Professoren und Seminarthemen. In Stichpunkten lässt sich diese wie folgt formulieren: Studenten dürfen bei einem Professor nur ein Seminarthema bearbeiten Studenten dürfen dasselbe Thema nur bei einem Professor bearbeiten Professoren können dasselbe Thema an unterschiedliche Studenten vergeben Die Umwandlung eines ternären Relationships lässt sich generalisieren: Aus dem Relationship wird eine eigene Entität E. Besitzt das Relationship Attribute, so werden diese der neuen Entität E zugeordnet. Alle bestehenden Entitäten werden mit E nun nur noch durch binäre Relationships verbunden. E enthält entsprechend die Primary Keys der verbundenen Entitäten als Fremdschlüssel. Die ursprünglichen Kardinalitäten des ternären Relationships werden nun über den Primärschlüssel von E modelliert. Im vorliegenden Fall werden also die Entitäten Professoren, Studenten und Seminarthemen beibehalten und eine neue Entität betreuen eingeführt, die das ternäre Relationship darstellt. Zur Umsetzung ins relationale Modell muss ein Schlüssel für die Relation betreuen bestimmt werden. Hierzu betrachten wir die geltenden Funktionen: Studenten Seminarthemen Professoren (1) Studenten Professoren Seminarthemen (2) Aus den linken Seiten dieser Funktionen ergeben sich potentielle Schlüssel. Diese sind minimal. 1. Möglichkeit: Eine gültige Ausprägung ist: betreuen (PersonalNr : Integer, MatrNr : Integer, Titel : String, Note : Dezimal) PersonalNr MatrNr Titel Note 2125 24002 Präferenzen und Datenbanken 1,0 2125 24002 Suchmaschinen und Datenbanken 2,0 Im dargestellten Beispiel bearbeitet ein Student beim gleichen Professor zwei unterschiedliche Themen. Dies ist ein Widerspruch zur Bedingung (2). 2. Möglichkeit: Eine gültige Ausprägung ist: betreuen (PersonalNr : Integer, MatrNr : Integer, Titel : String, Note : Dezimal) PersonalNr MatrNr Titel Note 2125 24002 Präferenzen und Datenbanken 1,0 2126 24002 Präferenzen und Datenbanken 2,0 Es wird nicht ausgeschlossen, dass ein Student dasselbe Thema bei unterschiedlichen Professoren bearbeitet, was jedoch ein Widerspruch zur Bedingung (1) ist. 3. Möglichkeit: Die Kombination der drei Attribute (PersonalNr, MatrNr, Titel) als Schlüssel zu verwenden löst diese Problematik nicht. Denn dann sind keine der zwei vorgestellten Konsistenzbedingungen mehr erfüllt, wie man sich leicht an einem Beispiel veranschaulichen kann. In SQL löst man diese Problematik wie folgt: Der Primärschlüssel der Relation betreuen wird z.b. {PersonalNr, MatrNr}. Zusätzlich definiert man {Titel, MatrNr} als unique, also als eindeutig. 6