Lösung zu Aufgabe 3.1

a)

Ein ergänztes Diagramm finden Sie hier.

Da wir die (min,max)-Notation in den Vorlesungen nicht besprachen, habe ich hier die UML-Notation verwendet, vgl. Skript Seite 58 f.

 

Näheres zur Bedeutung der Kardinalitäten bei mehrwertigen (also nicht-binären) Beziehungen finden Sie im Buch in Abschnitt 2.7.2. Die Modellierung der Kardinalitäten (im Buch Funktionalitäten genannt) von verbindet entspricht der Beziehung betreuen in Abb. 2.5: Für jeden Zug ist bei Bekanntsein des VonBahnhofs der NachBahnhof eindeutig bestimmt und umgekehrt. Das wird durch die 1-Kardinalitäten ausgedrückt. Die Kombination eines VonBahnhofs mit einem NachBahnhof kann aber für mehr als einen Zug vorkommen, weshalb für die Züge Mehrfachkardinalität zu verwenden ist. Da die Kardinalitäten Eigenschaften der Beziehungen sind und wir keine Verbindungen betrachten wollen, die von keinem Zug bedient wird, muß der Zug angegeben werden. Die Kardinalität auf Zug-Seite ist daher 1..* und nicht etwa 0..*.

 

b)

Aus dem Umsetzen der Entitätstypen ergeben sich:

Züge:                 {[ZugNr, Länge]}

Bahnhöfe:          {[Name, #Gleise]}

Städte:               {[Name, Bundesland]}

Schwache Entitätstypen und Generalisierung (vgl. Skript S. 96) haben wir hier nicht, so daß dafür keine besondere Berücksichtigung erforderlich ist.

 

Das Umsetzen der Beziehungstypen liefert (Fremdschlüssel sind kursiv und fett dargestellt):

liegen_in:          {[Bahnhof, Städtename, Bundesland]}

starten:              {[ZugNr , Bahnhof]}

enden:               {[ZugNr , Bahnhof]}

                           sowie

verbinden:         {[ZugNr, VonBahnhof, NachBahnhof, Ankunft, Abfahrt]}

                           oder

verbinden:         {[ZugNr, VonBahnhof, NachBahnhof, Ankunft, Abfahrt]}

 

Bitte machen Sie sich klar, weshalb die Primärschlüssel (infolge der Kardinalitäten) so zu wählen sind! Beachten Sie weiterhin, daß die Beziehung verbindet aus Sicht der Bahnhöfe rekursiv ist und deshalb entsprechende Attributnamen für die Fremdschlüssel erforderlich sind, vgl. Skript S. 86.

 

Der Vollständigkeit halber und mit Bezug zum zweiten Absatz von Aufgabe 3.2:

Die dreiwertige (= ternäre) Beziehung verbinden bereitet hier ein Problem: Wir haben zwei Schlüsselkandidaten, nämlich [ZugNr, VonBahnhof] und [ZugNr, NachBahnhof], und es ist eine – durch die Kardinalitäten und die dahinterstehenden FDs zum Ausdruck gebrachte – Integritätsbedingung, daß diese Attributkombinationen auch identifizierend sind, es also – für beide Schlüsselkandidaten – keine zwei Entitäten mit derselben Attributkombination geben darf.

 

Da wir im Relationenmodell jedoch nur einen Primärschlüssel und sonst weiter keine Eindeutigkeitsangaben vermerken können, lassen sich diese Integritätsbedingungen im Relationenmodell auch nicht zum Ausdruck bringen.

 

In der Datenbank, die man aus dem Relationenmodell erstellt, wird das Problem so gelöst – wie im Relationenmodell – einer der Schlüsselkandidaten als Primärschlüssel verwendet wird. Das Einhalten der Eindeutigkeitsbedingung der übrigen Schlüsselkandidaten werden dann mit UNIQUE-Constraints (in der Vorlesung nicht behandelt, vgl. Syntaxbeschreibung und Glossar) oder UNIQUE-Indizes sichergestellt. In Access können Sie einen solchen Index – wie besprochen – in der Tabellenentwurfsansicht über das Dialogfenster Indizes einstellen (Symbolleiste: Blitzsymbol).

 

Ergänzend sei erwähnt, daß man das Modell auch ganz anders gestalten kann, vgl. meine Lösungsvorschläge zu Aufgabe 2.6; doch das ist für diese Aufgabe ohne Belang, bei der das Modell ja vorgegeben war.

[Sowohl meine Lösungen zu Aufgabe 2.6 als auch der dieser Aufgabe zugrunde liegende Vorschlag aus dem Buch haben weitere Nachteile, auf die man bei tieferem Nachdenken stößt, denn es gibt – wenn man die übliche Lebenserfahrung zugrunde legt – zusätzliche (semantische) Integritätsbedingungen; doch das ist erst recht nicht Bestandteil der Aufgabe gewesen und wird deshalb hier nicht besprochen.]

 

c)

Bei der Betrachtung der Primärschlüssel fallen folgende Übereinstimmungen auf:

  1. Der Bahnhofsname ist Schlüsselkandidat (und Primärschlüssel) sowohl der Bahnhöfe als auch der Beziehungsrelation liegen_in.
  2. Die Zugnummer ist Schlüsselkandidat (und Primärschlüssel) von Züge, starten und enden.

Wir fassen deshalb folgendermaßen zusammen (die verschobenen Attribute sind gelb hinterlegt):

 

Züge:                 {[ZugNr, StartBahnhof, ZielBahnhof, Länge]}

Bahnhöfe:          {[Name, Stadt, Bundesland, #Gleise]}

Städte:               {[Name, Bundesland]}

                           sowie

Verbindungen:  {[ZugNr, VonBahnhof, NachBahnhof, Ankunft, Abfahrt]}

                           bzw.

Verbindungen:  {[ZugNr, VonBahnhof, NachBahnhof, Ankunft, Abfahrt]}

 

Außerdem habe ich dabei folgende Veränderungen vorgenommen: