Musterlösung zum zweiten Beispiel des Laborübungsteils aus Datenmodellierung

• Beispiel: Schule
• Beispiel: Eventfirma
• Beispiel: Pizzeria

Beispiel: Schule

Das ER Modell

Das Relationenmodell

befugt(Lehrer.SVNr, Fach.Abkürzung)
unterrichtet(Lehrer.SVNr, Fach.Abkürzung, Klasse.Name)
nimmtTeil(Lehrer.SVNr, Konferenz.Datum)
geschwister(Schüler.SVNr, Schüler.SVNr)

Zusatzfragen

• Modellieren Sie den Sachverhalt einmal mit und ein weiteres Mal ohne Nullwerte. Passen Sie ER-Diagramm und Relationenmodell entsprechend an.

  rot: Lösung mit Nullwerten
  grün: Lösung ohne Nullwerte

  Ehemalige(Personal.SVNr, Kündigungsdatum)

• Geschwister haben oft den selben Hauptwohnsitz. Andern Sie Ihre Modellierung nun dahingehend, dass ein mehrfaches Speichern von Adressen an denen mehrere Schüler wohen vermieden wird.

  Anstatt den Hauptwohnsitz direkt bei den Schülern zu speichern (blaue Lösung) wird eine neue Entität HWS erzeugt (orange Lösung). Ein zusätzlicher Schlüssel wird verwendet, um bei einer ünderung des Hauptwohnsitzes von Geschwistern die Adresse in der Datenbank nur einmal ändern zu müssen. Das dazu passende Relationenmodell wird folgendermaßen angepasst:
  HWS(a_id, Adresse)

• Sie wissen, dass genau einer der Schüler Schulsprecher ist. Können Sie diesen Sachverhalt in dem ER-Diagramm modellieren? Wenn ja, wie? Wenn nein, wieso nicht?

  Nein, das ist nicht möglich. Im ER-Diagramm können Aussagen über eine ganz bestimmten Anzahl von Tupeln aus einer Tabelle nicht getroffen werden.

• Ist durch Ihre Modellierung sichergestellt, dass jeder Lehrer nur Fächer unterrichtet, deren Lehrbefugnis er besitzt?

  Nein, das ist nicht sichergestellt.

Beispiel: Eventfirma

Das ER- Modell

Das Relationenmodell

E_Adresse (a_id, Land, PLZ, Ort, Straße, Nummer)
Event (Adresse.a_id, Beginn, Ende, Name, Personen, Zielgruppe)
Zusatz_P (Event.a_id, Event.Beginn, Personen)
Zusatz_Z (Event.a_id, Event.Beginn, Zielgruppe)
v_Musik (Event.a_id, Event.Beginn, Musikanlage.id)
v_Zelt (Event.a_id, Event.Beginn, Zelt.id, Zweck)
v_Bühne (Event.a_id, Event.Beginn, Bühne.id)
verwendet (Event.a_id, Event.Beginn, Objekt.id)

Lager (l_id, Name, Größe, F_Adresse.a_id)
L_Adresse (a_id, Land, PLZ, Ort, Straße, Nummer)

Band (Name, Anzahl, Richtung, Land)
spielt (Band.Name, Event.a_id, Event.Beginn)

Karten (Typ, Event.a_id, Event.Beginn, Preis, Anzahl)

Zusatzfragen

• Lösen Sie in einem ersten Schritt die Aufgabe unter der Verwendung von Nullwerten (ER-Diagramm und Relationenmodell). Eliminieren Sie in einem zweiten Schritt alle Nullwerte und erstellen Sie ein zweites ER-Diagramm und ein Relationenmodell.

  rot: Lösung mit Nullwerten
  grün: Lösung ohne Nullwerte

• Können Sie in Ihrem Modell ausschließen, dass in der Datenbank eine Bühne zu einem bestimmten Zeitpunkt für mehrere Fetivals zugeteilt ist? Begründen Sie Ihre Antwort!

  Nein, das kann nicht ausgeschlossen werden. Zum Beispiel ist es in v_Bühne zulässig, für eine Bühne zwei Events einzutragen, die gleichzeitig beginnen, aber an unterschiedlichen Orten stattfinden.

• Ändern Sie Ihr ER-Diagramm und das Relationenmodell dahingehend, dass von den Bands nicht nur bekannt ist, bei welchen Events sie auftreten, sondern auch, auf welcher Bühne sie dort spielen. Gehen Sie davon aus, dass bei einer Veranstaltung eine Band maximal auf einer Bühne auftritt. Geben Sie diesen Sachverhalt sowohl in (min, max) Notation als auch in (N:M) Notation wieder.

  Die Beziehung

  spielt (Band.Name, Event.a_id, Event.Beginn)

  wird nun durch eine ternäre Beziehung ersetzt:

  spielt (Band.Name, Event.a_id, Event.Beginn, Bühne.id)

  Wichtig ist, dass die ID der Bühne nicht Teil des Schlüssels ist, da eine Band pro Event sowieso nur auf einer Bühne spielt. Um sicherzugehen, dass bei jedem Event mindestens eine Bühne verwendet wird, bzw., weil nicht unbedingt auf jeder Bühne bei einem Event Bands auftreten müssen, bleibt die Beziehung v_Bühne erhalten.
  

• Überlegen Sie sich, welche Vor- und Nachteile es hat, die Adressen der Events und die der Lager in einer Tabelle gemeinsam zu speichern, zwei separate Tabellen zu erstellen oder die Lageradressen nur als ein Attribut anzugeben. Begründen Sie ihre Lösung.

  Die Adressen gemeinsam zu speichern ist natürlich möglich. Allerdings entsteht durch die Erstellung einer zweiten Tabelle kaum Mehraufwand. Man gestaltet die Datenbank damit aber übersichtlicher, da Adressen von Lagern und die der Events nicht direkt etwas miteinander zu tun haben. Möchte man beispielsweise alle Orte herausfinden, an denen die Firma jemals einen Event veranstaltet hat, so müsste man bei Verwendung einer Tabelle diese zuerst mit der Eventtabelle joinen.

  Die Adresse als Attribut zu speichern ist ebenfalls eine gültige Lösung des Problems. Hier gilt es zu überlegen, was man sich von der Datenbank erwartet. Genügt es bespielsweise, die gesamte Adresse nur in Form eines Strings zu kennen oder will man auf Teile der Adresse zugreifen können.

Beispiel: Pizzeria

Das ER-Modell

Das Relationenmodell

Angestellter (SVNr, Person.id, SVNr, Vorname, Nachname, Adresse, Gehalt)
Liferant (Angestellter.id, Angestellter.SVNr)
Koch (Angestellter.id, Angestellter.SVNr, Qualifikation)
Kellner (Angestellter.id, Angestellter.SVNr)
Person (ID, Vorname, Nachname, Adresse)

Tisch (Nummer, Sitzplätze)
eingeteilt (Tisch.Nummer, Kellner.id, Kellner.SVNr)

Bestellung_T (Tisch.Nummer, Timestamp, bezahlt, Betrag)
bestellt_T (Bestellung_T.Nummer, Bestellung_T.Timestamp, Angebot.Name, Angebot.Größe, Anzahl)
bearbeitet (Kellner.id, Kellner.SVNr, Bestellung_T.Nummer, Bestellung_T.Timestamp)

Kunde (Person.id, id, Vorname, Nachname, Adresse, TelNr)
Stammkunde (Kunde.id, Rabatt)

Bestellung_K (Kunde.id, Timestamp, Preis, ausgeliefert)
bestellt_K (Bestellung_K.id, Bestellung_K.Timestamp, Angebot.Name, Angebot.Größe, Anzahl)
liefert (Lieferant.id, Lieferant.SVNr, Bestellung_K.id, Bestellung_K.Timestamp)

vertritt (Vertreter: Angestellter.id, ZuVertretender: Angestellter.id, Vertreter: Angestellter.SVNr, ZuVertretender: Angestellter.SVNr)

Zusatzfragen

• Erstellen Sie ein ER-Diagramm und ein Relationenmodell ohne Nullwerte.

  Achtung: Beachten Sie hier nur die schwarz bzw. rot geschriebenen Teile der Musterlösung!

• Der Realität entsprechend sollen Angestellte auch Kunden sein können. Ist das in Ihrem Modell möglich? Ändern Sie Ihr Modell dahingehend, dass bei Angestellten, die auch Kunden sind, keine Daten doppelt gespeichert werden.

  Alle blau (bzw. schwarz) geschriebenen Teile gehören zur Lösung dieser Aufgabe. Beachten Sie, dass die Sozialversicherungsnummer der Angestellten nun nicht mehr als Schlüssel verwendet wird und stattdessen eine ID als Schlüssel dient, um Kunde und Angestellter generalisieren zu können.

• Haben Sie die Datenbank für die Pizzeria so modelliert, dass bei einer Bestellung auch mehrere gleiche Pizzen oder Getränke aus dem Angebot bestellt werden können? Wenn nicht, dann passen Sie ihr ER-Diagramm und Relationenmodell entsprechend an.

  Die einfachste Lösung besteht darin, zu jedem "bestellt" die bestellte Anzahl dazuzuspeichern (grüne Lösung). Eine andere Möglichkeit wäre, davon auszugehen, dass jedes bestellte Produkt einen Bestellposten zugewiesen bekommt:

  

• Kann es laut Ihrem Modell passieren, dass beispielsweise ein Koch durch einen Liferanten vertreten wird? Ist es möglich, dieses Problem direkt im ER-Diagramm zu beseitigen und sicherzustellen, dass Angestellte nur durch Angestellte vertreten werden, die der selben Gruppe angehören? Wenn ja, wie? Wenn nein, wieso nicht?

  Im obigen Modell kann es passieren, dass ein Angestellter von einem Angestellten anderen Typs vertreten wird. Man könnte statt einer "vertritt"-Relation für alle Angestellten gemeinsam, für jeden Angestelltentyp eine eigene "vertritt"-Relation erstellen.