3 Aufgaben zum relationalen Datenbankdesign

Für eine umfassende Einführung in die relationale Modellierung vgl. [Staud 2021]:

Staud, Josef Ludwig: Relationale Datenbanken. Grundlagen, Modellierung, Speicherung, Alternativen (2. Auflage). Hamburg 2021 (tredition)

Auszüge finden sich auf http://www.staud.info/rm1/rm_t_1.htm

3.1 Basisübung 1

Zu Beginn eines jeden Datenbankprojekts müssen aus der Beschreibung des Anwendungsbereichs und den Anforderungen die relevanten Relationen abgeleitet werden. In dieser Aufgabe geht es um diesen Schritt. Mit im Mittelpunkt sind dabei methodenbedingte Zerlegungen der Relationen.

3.1.1 Anforderungsbeschreibung

Im Rahmen des Datenbankdesigns für einen Sportverein wurden für die Mitglieder folgende Anforderungen formuliert:

Die Mitglieder des Vereins werden durch Name, Vorname (VName), Telefon (Tel), Geburtstag (GebTag), Alter, eine Mitgliedsnummer (MiNr) und die Hauptadresse (PLZ, Ort, Straße) festgehalten. Erfasst wird außerdem der Tag des Eintritts (Eintritt) in den Verein. Bei ausgetretenen Mitgliedern ebenfalls der des Austritts (Austritt). Es kommt leider vor, dass ein Mitglied austritt und später wieder eintritt. Auch dies soll in vollem Umfang dokumentiert werden, d.h. vorherige Mitgliedschaften werden nicht gelöscht. Es entsteht so eine Dokumentation aller Ein- und Austritte eines Vereinsmitglieds. Bei verstorbenen Mitgliedern wird der Todestag (Todestag) vermerkt.

Daraus sind die Relationen abzuleiten.

3.1.2 Lösungsschritte

Die erste Relation liegt nahe: Mitglieder mit dem Schlüssel #MiNr. Welche Attribute können ihr zugeordnet werden? Sicherlich der Name und Vorname (VName), denn diese sind eindeutig für jedes Miglied:

Mitglieder (#MiNr, Name, Vorname, …)

Die Telefonnummer nur, falls sie auch eindeutig ist. Auf Nachfrage erfahren wir, dass die Mitglieder durchaus mehrere Telefoniermöglichkeiten haben, z.B. einen Festnetz- und einen Mobilfunkanschluss. Dies würde in Mitglieder zu Mehrfacheinträgen führen. Deshalb wird dafür eine eigene Relation eingeführt:

Telefone (#(MiNr, Tel))

MiNr wird zum Fremdschlüssel.

Den Geburtstag, das Alter und die Hauptadresse können wir wiederum der Relation Mitglieder hinzufügen:

Mitglieder (#MiNr, Name, Vorname, GebTag, Alter, PLZ, Ort, Straße, …)

Das Alter wird später in der Datenbank aus dem Geburtstag und dem Systemdatum regelmäßig berechnet. Solche abgeleiteten Attribute, wie sie in der ER-Modellierung genannt werden, die mittels anderer bestimmt und in die Datenbank eingetragen werden, kommen in Datenbanken durchaus vor.

Abgeleitete Atribute

Gäbe es mehrere Adressen je Mitglied, müsste dafür eine eigene Relation eingerichtet werden. Hier wird aber ausdrücklich auf die Hauptadresse verwiesen. Die Situation, mehrere Adressen im Datenmodell anlegen zu müssen, wird unten in den Aufgaben öfters bewältigt.

Mehrere Adressen

Mit den Attributen Tag des Eintritts (Eintritt) und des Austritts (Austritt) kommt die zeitliche Dimension in Form einer Zeitspanne ins Spiel. Das Attribut Eintritt kann problemlos in Mitglieder aufgenommen werden. Austritt dagegen nicht, da diese Attribut ja erst beschrieben werden kann, wenn der Austritt geschieht und solche semantisch bedingten Leereinträge sind in relationalen Datenbeständen nicht erwünscht. Es bleibt also nur eine eigene Relation mit den Austritten. Insgesamt also:

Zeitliche Dimension

Mitglieder (#MiNr, Name, Vorname, GebTag, Alter, PLZ, Ort, Straße, Eintritt, …)

Austritte (#MiNr, Austritt)

Es soll nicht verschwiegen werden, dass hier sehr oft die pragmatische Lösung gewählt wird, das Ende der Zeitachse zusammen mit dem Eintritt zu platzieren, obwohl damit semantisch bedingte Leereinträge entstehen:

Pragmatik

Mitglieder (#MiNr, Name, Vorname, GebTag, Alter, PLZ, Ort, Straße, Eintritt, Austritt, …)

Nun findet sich aber in den Anforderungen der Wunsch, auch mehrere Ein- und Austritte eines Mitglieds zu erfassen und zu dokumentieren. Dies verändert den obigen Entwurf. Ein- und Austritte müssen wegen der Möglichkeit der Mehrwertigkeit zusammen mit der Mitgliedsnummer in eine eigene Relation Mitgliedschaften und raus aus Mitglieder:

Mitglieder (#MiNr, Name, Vorname, GebTag, Alter, PLZ, Ort, Straße, …)

Mitgliedschaften (#(MiNr, Eintritt), Austritt)

Mitgliedschaften.MiNr wird Fremdschlüssel. Jetzt kann ein Mitglied alle paar Jahre aus- und später wieder einreten. Bei solchen Zerlegungen ist auf die Korrektheit des Schlüssels zu achten. Er muss jedes Tupel eindeutig identifizieren. Dies ist hier oben der Fall.

Am Schluss der Anforderungsbeschreibung werden die verstorbenen Mitglieder erwähnt. Auch sie sollen erfasst werden. Den Todestag in Mitglieder zu erfassen wäre wegen der semantisch bedingten Leereinträge falsch. Bleibt auch hier nur eine eigene Relation zu den verstorbenen Mitgliedern:

Verstorbene Mitglieder

MitglVerstorben (#MiNr, Todestag)

Wir gehen davon aus, dass die Daten zu den verstorbenen Mitgliedern in Mitglieder erhalten bleiben. Falls dem nicht so wäre, müsste MitglTot um die entsprechenden Attribute erweitert werden.

3.1.3 Lösung

Damit liegen mit den jeweiligen Endfassungen folgende Relationen vor.

Textliche Fassung

Mitglieder (#MiNr, Name, Vorname, GebTag, Alter, PLZ, Ort, Straße)

Mitgliedschaften (#(MiNr, Eintritt), Austritt)

MitglVerstorben (#MiNr, Todestag)

Telefone (#(MiNr, Tel))

Grafische Fassung

Abbildung 3.1-1: Grafische Lösung zum Anwendungsbereich Sportverein – Ausschnitt Mitglieder

3.2 Basisübung 2

Auch in dieser Aufgabe geht es um das Erkennen der Relationen. Dabei steht das Erkennen und Bewältigen des Musters Generalisierung/Spezialisierung (vgl. [Staud 2021, Abschnitt 14.1]) im Mittelpunkt.

3.2.1 Anforderungsbeschreibung

Es liegt bereits eine Relation zu den Mitgliedern des Sportvereins vor:

Mitglieder (#MiNr, Name, Vorname, GebTag, Alter, PLZ, Ort, Straße)

Folgende zusätzlichen Anforderungen wurden formulieret :

Für die Mitglieder wird erfasst, ob es sich um ein passives oder ein aktives Mitglied handelt. Für jedes aktive Mitglied wird dann noch festgehalten, welche Sportart es in welcher Leistungsstufe (LStufe) betreibt. Für die passiven Mitglieder wird erfasst, für welche ehrenamtliche Tätigkeit sie zur Verfügung stehen (BezTät). Dies können mehrere sein.

3.2.2 Lösungsschritte

Mal angenommen, es würde nur gefordert, dass erfasst wird, ob das Mitglied aktiv oder passiv ist. Dann würde ein Attribut AktPass mit den Ausprägungen aktiv oder passiv in Mitglieder reichen:

Mitglieder (#MiNr, Name, Vorname, GebTag, Alter, PLZ, Ort, Straße, AktPass)

Kommen allerdings weitere Attribute für die Untergruppen hinzu, so wie hier

• Sportart und Leistungsstufe (LStufe) für die aktiven Mitglieder,
• BezTät für die passiven Mitglieder,

ändert sich die Situation. Oftmals werden dann einfach diese Attribute der Relation hinzugefügt:

Mitglieder (#MiNr, Name, Vorname, GebTag, Alter, PLZ, Ort, Straße, AktPass, Sportart, LStufe, BezTät)

Dies ist falsch, denn damit entstehen semantisch bedingte Leereinträge in der späteren Datenbank. Da ein Mitglied entweder aktiv oder passiv ist, gibt es immer Attribute, die keine Einträge erhalten können. Vgl. dazu das Muster Generalisierung/Spezialisierung in [Staud 2021, Abschnitt 14.1].

Falsch

Die korrekte Lösung besteht darin, zwei neue Relationen anzulegen, eine für die aktiven und eine für die passiven Sportler:

Korrekt

MitglAktiv (#MiNr, Sportart, LStufe)

MitglPassiv (#MiNr, BezTät)

Das ist nun schon fast richtig. Da in der Anforderung gefordert ist, auch mehrere ehrenamtliche Tätigkeiten zu berücksichtigen, muss MitglPassiv noch angepasst werden:

MitglPassiv (#(MiNr, BezTät))

Der zusammengesetzte Schlüssel erfüllt die Anforderung, MiNr wird zum Fremdschlüssel.

3.2.3 Lösung

Damit ergibt sich folgende relationale Lösung für die Generalisierung/Spezialisierung.

Textliche Fassung

Mitglieder (#MiNr, Name, Vorname, GebTag, Alter, PLZ, Ort, Straße, AktPass) //Generalisierung :

MitglAktiv (#MiNr, Sportart, LStufe) //Spezialisierung 1:

MitglPassiv (#(MiNr, BezTät)) //Spezialisierung 2:

Mitglieder.AktPass wird von der Methode nicht verlangt, erleichtert aber die späteren Auswertungen und ist daher aus pragmatischen Gründen sinvoll.

Die relationalen Verknüpfungen erfolgen über die MiNr. Zu den Karadinalitäten und Min-/Max-Angaben vgl. die Abbildung.

Grafische Fassung

Abbildung 3.2-1: Grafische Lösung zum Anwendungsbereich Sportverein – Ausschnitt aktiv/passiv

3.3 Basisübung 3

Auch hier geht es um die Klärung der Relationen in einer Anforderungsbeschreibung und um deren Einbindung in das übrige Datenmodell.

3.3.1 Anforderungsbeschreibung

Es liegt bereits aus den obigen zwei Aufgaben ein Datenmodell vor, das ergänzt werden soll:

Mitglieder (#MiNr, Name, Vorname, GebTag, Alter, PLZ, Ort, Straße, AktPass)

MitglAktiv (#MiNr, Sportart, LStufe)

MitglPassiv (#(MiNr, BezTät))

Mitgliedschaften (#(MiNr, Eintritt), Austritt)

MitglVerstorben (#MiNr, Todestag)

Telefone (#(MiNr, Tel))

Nun soll dieses Datenmodell um (Sport-)Abteilungen und Mannschaften ergänzt werden. Hier die diesbezüglichen Anforderungen:

Der Sportverein ist in Abteilungen (AbtNr, AbtBez) gegliedert (Handball, Fußball, Volleyball, usw.).

Jede Abteilung hat einen Leiter, dessen Mitgliedsnummer hier erfasst werden soll (AbtLeiter). Dieser zählt als aktives Mitglied.

Eine Abteilung kann mehrere Mannschaften haben. Natürlich gehört eine Mannschaft zu genau einer Abteilung.

Von jeder Mannschaft (MaNr, MaBez) werden mit Hilfe der Mitgliedsnummer die Spieler und der Kapitän (KapNr) festgehalten sowie die Liga, in der sie spielt (Bundesliga, usw.).

Jede Mannschaft hat einen (einzigen) Trainer (TrNr). Auch dieser wird festgehalten. Er zählt als aktives Mitglied.

3.3.2 Lösungsschritte

Die sicherlich erste Überlegung nach der Analyse der Anforderungen ist, die Mannschaften als Relation anzulegen und dort die Abteilungszugehörigkeit zu vermerken. Dies wäre aber nicht korrekt, da die Abteilungen nicht nur identifiziert (AbtNr, AbtBez), sondern auch beschrieben werden (AbtLeiter). Deshalb wird für sie eine eigene Relation angelegt:

Abteilungen (#AbtNr, #AbtBez, AbtLeiter)

Da ein Abteilungsleiter aktives Mitglied ist, wird das Attribut Abteilungen.AbtLeiter zum Fremdschlüssel bzgl. der Relation MitglAktiv:

Abteilungen (#AbtNr, #AbtBez, AbtLeiter)

MitglAktiv (#MiNr, Sportart, LStufe)

Anschließend werden in den Anforderungen die Mannschaften angesprochen. Da sie identifiziert (MaNr) und weiter beschrieben werden durch die Mitgliedsnummern des Kapitäns (KapNr), des Trainers (TrNr) und durch die Liga, in der sie spielen, wird auch für sie eine Relation angelegt:

Mannschaften

Mannschaften (#MaNr, MaBez, Liga, KapNr, TrNr, …)

In den Anforderungen wurde auch das Verhältnis Abteilungen/Mannschaften beschrieben. Diese 1 :n-Beziehung kann dadurch modelliert werden, dass die Mannschaften die AbtNr als Fremdschlüssel erhalten :

Mannschaften (#MaNr, #MaBez, Liga, KapNr, TrNr, AbtNr, …)

Mehrere Schlüssel können Relationen durchaus haben. Sie werden dann Primärschlüssel und Sekundärschlüssel genannt. Im obigen Beispiel könnte die MaNr als Verknüpfungsattribut dienen und MaBez als identifizierend beschreibendes.

Mehrere Schlüssel

Obiger Relation fehlt allerdings noch etwas wichtiges. KapNr und TrNr sind einfach nur Nummern, erst durch die Verknüpfung mit den aktiven Mitgliedern (MitglAktiv) sind diesen Nummern die weiteren Informationen zugeordnet. Deshalb werden KapNr und TrNr hier ebenfalls zu Fremdschlüsseln :

Kapitän, Trainer

Mannschaften (#MaNr, MaBez, Liga, KapNr, TrNr, AbtNr)

MitglAktiv (#MiNr, Sportart, LStufe)

Folgende Verknüpfungen liegen bzgl. der Mannschaften damit vor :

• Mannschaften.KapNr mit MitglAktiv.MiNr
• Mannschaften.TrNr mit MitglAktiv.MiNr
• Mannschaften.AbtNr mit Abteilungen.AbtNr

Bleiben noch die Spieler. Natürlich soll festgehalten werden, welche Spieler in welcher Mannschaft spielen. Wir können sicherlich davon ausgehen, dass Spieler datenbanktechnisch aktive Mitglieder sind. Würde ein aktives Mitglied nur in einer Mannschaft spielen, könnten wir die Mannschaft in MitglAktiv vermerken. Auf Nachfrage erfahren wir aber, dass ein aktives Mitglied durchaus in mehreren Mannschaften spielen kann. Das verändert das Modellfragment.

Spieler

Jetzt liegt eine n:m-Beziehung zwischen den beiden Relationen Mannschaften und MitglAktiv vor. Dies erfordert eine Verbindungsrelation, die AM-MA (aktive Mitglieder – Mannschaften) genannt werden soll:

Verbindungsrelation

AM-MA (#(MaNr, MiNr))

Die Kardinalität ist n:m, die Min-/Max-Angaben sind – von den aktiven Mitgliedern zu den Mannschaften 0,n : 0,m.

Wir gehen also davon aus, dass es auch aktive Mitglieder gibt, die nicht in einer Mannschaft sind und dass wir eine Mannschaft erst in der Datenbank aufnehmen, wenn wir zumindest ein Mitglied (z.B. die Kapitänin) angeben können.

3.3.3 Lösung

Insgesamt liegen für dieses Fragment zum Datenmodell Sportverein damit folgende Relationen vor.

Textliche Notation

Abteilungen (#AbtNr, #AbtBez, AbtLeiter)

MitglAktiv (#MiNr, Sportart, LStufe)

Mannschaften (#MaNr, #MaBez, Liga, KapNr, TrNr, AbtNr)

Mehrere Schlüssel

AM-MA (#(MaNr, MiNr))

Grafische Fassung

Abbildung 3.3-1: Anwendungsbereich Sportverein – Fragment Mannschaften/Abteilungen

3.4 Basisübung 4

Zwei Modellierungsaspekte werden hier betrachtet:

• Die Modellierung von Vorgängen, von Ereignissen mit zeitlicher Dimension.
• Wiederum gilt, dass die neuen Anforderungen in ein bestehendes Datenmodell eingearbeitet werden sollen.

3.4.1 Anforderungsbeschreibung

Aus den obigen Aufgaben liegt ein Datenmodell zu einem Sportverein vor, das ergänzt werden soll:

Abteilungen (#AbtNr, #AbtBez, AbtLeiter)

AM-MA (#(MaNr, MiNr))

Mannschaften (#MaNr, #MaBez, Liga, KapNr, TrNr, AbtNr)

MitglAktiv (#MiNr, Sportart, LStufe)

Mitglieder (#MiNr, Name, Vorname, GebTag, Alter, PLZ, Ort, Straße, AktPass)

Mitgliedschaften (#(MiNr, Eintritt), Austritt)

MitglPassiv (#(MiNr, BezTät))

MitglVerstorben (#MiNr, Todestag)

Telefone (#(MiNr, Tel))

Es wurde beschlossen, auch die Begegnungen, an denen Mannschaften des Vereins teilnehmen, in der Datenbank zu erfassen. Hier die Anforderungen:

Begegnungen

Die Begegnungen von Mannschaften des Vereins sollen mit Datum (Tag), Spielbeginn (Beginn), gegnerischer Mannschaft (Gegner) und Ergebnis festgehalten werden. Falls im Rahmen eines Turniers zwei Mannschaften des Vereins gegeneinander spielen, wird nur ein Eintrag vorgenommen und eine der beiden Mannschaften als „gegnerische“ Mannschaft eingetragen. Für diese Datenbank wird angenommen, dass eine Mannschaft mehrere Spiele an einem Tag haben kann (Turnier!).

3.4.2 Lösungsschritte

Die Anforderungen machen deutlich, dass die Begegnungen nicht in einer der schon bestehenden Relationen erfasst werden können. Sie werden identifiziert durch die Attribute (MaNr, Gegner, Tag, Beginn). Ein solcher Schlüssel mit zugehöriger Relation liegt bisher nicht vor, also ist eine weitere Relation nötig, die Begegnungen genannt werden soll:

Begegnungen (#(MaNr, Gegner, Tag, Beginn)).

Beginn ist im Schlüssel für den Fall dabei, dass tatsächlich zwei Mansschaften an einem Tag zwei mal gegeneinander spielen, z.B. bei einem Vereinsturnier.

Es geht nur um Begegnungen des Vereins, nicht z.B. um die einer ganzen Liga zwischen allen Mannschaften. Deshalb ist die in MaNr angesprochene Mannschaft immer die des Vereins.

Dies erlaubt und verlangt die Verknüpfung von Begegnungen mit dem vorliegenden Datenmodell über die Relation Mannschaften. Begegnungen.MaNr wird zum Fremdschlüssel und dient damit der Verknüpfung mit Mannschaften.MaNr.

Begegnungen (#(MaNr, Gegner, Tag, Beginn)).

Mannschaften (#MaNr, #MaBez, Liga, KapNr, TrNr, AbtNr)

Nun fehlt nur noch, das Ergebnis mit in die Begegnungen aufzunehmen :

Begegnungen (#(MaNr, Gegner, Tag, Beginn), Ergebnis).

So weit so gut. Bei der Kontrolle des Ergebnisses sollte man allerdings bemerken, dass der Schlüssel überausgestattet ist. Dies kommt von dem erfassten Zeitpunkt der Begegnung. Zeitpunkte sind alleine schon sehr identifizierend. Liegen sie vor, gilt es nur noch zu bedenken, welches zusätzliche Attribut zum Schlüsselcharakter führt. Hier ist es so, dass eine Mannschaft zu einem Zeitpunkt nur ein Spiel gestalten kann. Also genügt als Schlüssel #(MaNr, Tag, Beginn) und der Gegner wird zum deskriptiven Attribut ohne Schlüsselcharakter :

Zeitachse, Zeitpunkte

Begegnungen (#(MaNr, Tag, Beginn), Gegner, Ergebnis). //final

3.4.3 Lösung

Textliche Fassung

Begegnungen (#(MaNr, Tag, Beginn), Gegner, Ergebnis).

Mannschaften (#MaNr, #MaBez, Liga, KapNr, TrNr, AbtNr)

Die Beziehung Begegnungen zu Mannschaften stellt eine Komposition dar. Wenn eine Mannschaft aus der Datenbank gelöscht wird, müssen (datenbanktechnisch) auch ihre Begegnungen verschwinden, da unvollständige Schlüssel nicht zulässig sind.

Muster Komposition

Grafische Fassung

Abbildung 3.4-1: Anwendungsbereich Sportverein – Fragment Mannschaften/Begegnungen

Alternative

Bei solchen zusammengesetzten Schlüsseln, vor allem, wenn sie noch umfangreicher sind, wird oft ein künstlich generierter Schlüssel gewählt, der das jeweilige Geschehen eindeutig beschreibt. Hier wäre z.B. eine Zeichenkette, bestehend aus Datum, Beginn, Mannschaftsnummer, Kurzbezeichnunge der gegenerischen Mannschaft, denkbar. Also z.B.

Pragmatik

20230505M001BayMü

… für eine Begegnung am 5.5.2023 zwischen unserer Mannschaft M001 und Bayern München.

Für die Relation ergäbe sich dann:

Begegnungen (#BegebungID, MaNr, Tag, Beginn, Gegner, Ergebnis)

3.5 Sportverein (insgesamt)

Einzelne Fragmente dieser Aufgabe dienten oben in den Basisübungen 1 – 4 zur Wiederholung elementarer Modellierungstechniken. Hier nun die integrierte Fassung.

3.5.1 Anforderungsbeschreibung

Ein Sportverein beschließt, seine Aktivitäten (Mitgliederverwaltung, Sportveranstaltungen, usw.) in Zukunft computergestützt abzuwickeln. Dazu soll eine Datenbank aufgebaut werden, für die folgende Festlegungen getroffen werden:

• Die Mitglieder des Vereins werden durch Name, Vorname (VName), Telefon (Tel), Geburtstag (GebTag), eine Mitgliedsnummer (MiNr) und die Hauptadresse (PLZ, Ort, Straße) festgehalten. Erfasst wird außerdem der Tag des Eintritts (Eintritt) in den Verein. Bei ausgetretenen Mitgliedern ebenfalls der des Austritts (Austritt). Es kommt auch vor, dass ein Mitglied austritt und später wieder eintritt. Auch dies soll in vollem Umfang dokumentiert werden, d.h. vorherige Mitgliedschaften werden nicht gelöscht. Es entsteht so eine Dokumentation aller Ein- und Austritte eines Vereinsmitglieds. Bei verstorbenen Mitgliedern wird der Todestag (Todestag) vermerkt.
• Für die Mitglieder wird erfasst, ob sie passiv oder aktiv sind. Für jedes aktive Mitglied wird dann noch festgehalten, welche Sportart es in welcher Leistungsstufe (LStufe) betreibt. Dies können mehrere sein. Für die passiven Mitglieder wird erfasst, für welche ehrenamtliche Tätigkeit sie zur Verfügung stehen (BezTät). Auch dies können mehrere sein.
• Der Sportverein ist in Abteilungen (AbtNr, AbtBez) gegliedert (Handball, Fußball, Volleyball, usw.).
• Jede Abteilung hat einen Leiter (AbtLeiter). Dieser zählt als aktives Mitglied.
• Eine Abteilung kann mehrere Mannschaften haben. Natürlich gehört eine Mannschaft zu genau einer Abteilung.
• Von jeder Mannschaft (MaNr, MaBez) werden mit Hilfe der Mitgliedsnummer die Spieler und der Kapitän (KapNr) festgehalten sowie die Liga, in der sie spielt (Bundesliga, usw.).
• Jede Mannschaft hat einen (einzigen) Trainer (TrNr). Auch dieser wird festgehalten. Er zählt als aktives Mitglied.
• Die Begegnungen von Mannschaften des Vereins sollen mit Datum (Tag), Spielbeginn (Beginn), gegnerischer Mannschaft (Gegner) und Ergebnis festgehalten werden. Falls im Rahmen eines Turniers zwei Mannschaften des Vereins gegeneinander spielen, wird nur ein Eintrag vorgenommen und eine der beiden Mannschaften als "gegnerische" Mannschaft eingetragen. Für diese Datenbank wird angenommen, dass eine Mannschaft mehrere Spiele an einem Tag haben kann (Turnier!).

3.5.2 Lösungsschritte

Wie sehen nun die konkreten Modellierungsschritte aus? Sinnvoll ist es, zuerst die Objekte und Objektklassen und die zugehörigen Relationen zu suchen.

Erste Schritte

Beginnen wir mit den Mitgliedern des Vereins. Diese erkennt man modellierungstechnisch daran, dass es sich erstens um Objekte im allgemeinen Sinn handelt und dass zweitens diese Objekte durch Attribute beschrieben werden. Zweiteres ist von zentraler Bedeutung, denn sonst kann es sich auch um ein Attribut handeln, das andere Objekte beschreibt. Es entsteht also eine Relation Mitglieder. Nehmen wir die in der Anforderung genannten deskriptiven Attribute und den Schlüssel erhalten wir folgende Relation:

Mitglieder

Mitglieder (#MiNr, Name, VName, Tel, GebTag, PLZ, Ort, Straße)

Alle Mitglieder sind irgendwann in den Verein eingetreten. Insofern könnte man das Attribut Eintritt zur Relation mithinzunehmen. Da es aber Mitglieder gibt, die ausgetreten sind und solche, die vielleicht später wieder eintreten, stellen diese Mitglieder eine Spezialisierung dar. Die ganz korrekte Lösung wäre es, zwei Relationen anzulegen:

Eintritt, Austritt, verstorbene Mitglieder

MitglEintritt (#(MiNr, Datum))

MitglAustritt (#(MiNr, Datum))

Der Schlüssel ist zusammengesetzt, da dasselbe Mitglied ja jeweils mehrere Einträge haben kann.

Vertretbar ist aber auch die hier gewählte pragmatische Lösung, die Ein- und Austritte zusammen zu verwalten, auch wenn dabei inhaltlich begründete Leereinträge entstehen, denn das Austrittsdatum wird erst beschrieben, wenn das Mitglied tatsächlich austritt:

Mitgliedschaften (#(MiNr, Eintritt), Austritt)

Auch hier ist der Schlüssel wieder zusammengesetzt aus Mitgliedsnummer und Eintrittsdatum, da nur diese Attributkombination differenziert. In beiden Fällen ist es daher möglich, dass ein Mitglied mehrfach ein- und wieder austritt.

Auch die verstorbenen Mitglieder müssen als Spezialisierung erfasst werden, da diese Eigenschaft und den Todestag die anderen Mitgleider nicht teilen:

Verstorbene Mitglieder

MitglVerstorben (#MiNr, Todestag)

Dies macht nochmals deutlich, dass ein Attribut genügt, zu um einer spezialisierten Relation zu kommen.

Bleibt noch die Modellierung der Eigenschaft, aktives oder passives Vereinsmitglied zu sein. Ginge es nur um diese Eigenschaft, würde einfach ein Attribut "aktiv/passiv" mit diesen zwei Eigenschaften an die Relation Mitglieder angefügt. Nun ist es hier aber so, dass für die aktiven und passiven Mitglieder jeweils unterschiedliche Attribute festgehalten werden sollen. Deshalb müssen diese Teilgruppen der Mitglieder getrennt als Spezialisierungen erfasst werden:

Aktiv / Passiv - Muster Gen/Spez

MitglAktiv (#MiNr, Sportart, LStufe)

MitglPassiv (#(MiNr, BezTät))

Die passiven Mitglieder erhalten einen zusammengesetzten Schlüssel. Damit kann datenbanktechnisch ein Mitglied auch mehrere ehrenamtliche Tätigkeiten übernehmen.

Oftmals wird in die "oberste" Relation ganz pragmatisch noch ein Attribut eingefügt, das angibt, zu welcher Spezialisierung das Objekt gehört. Hier könnte z.B. ein Attribut Status in Mitglieder angeben, ob es sich um ein aktives, passives oder verstorbenes Mitglied handelt. Dies erleichtert die Abfragen und Auswertungen sehr stark, denn dadurch kann ohne Abfragen der Spezialisierungen gleich die entsprechende Auswahl getroffen werden.

Pragmatik

Insgesamt erhalten wir damit für die Mitglieder folgende Relationen:

Mitglieder (#MiNr, Name, VName, Tel, GebTag, PLZ, Ort, Straße, Status)

MitglEinAus (#(MiNr, Eintritt), Austritt)

MitglVerstorben (#MiNr, Todestag)

MitglAktiv (#MiNr, Sportart, LStufe)

MitglPassiv (#(MiNr, BezTät))

Hier die grafische Darstellung dieses Modellfragments:

Abbildung 3.5-1: Mitglieder im Datenmodell Sportverein

Hilfestellung zum Lesen der Wertigkeiten

In der relationalen Verknüpfung zwischen Mitglieder und MitglAktiv kommt eine bestimmte MiNr aus Mitglieder maximal einmal vor, eine bestimmte MiNr aus MitglAktiv genau ein Mal.

In semantischen und objektorientierten Modellen ist es möglich auszudrücken, dass alle Objekte der übergeordneten Einheit (Entitätstyp, Superklasse) an den Spezialisierungen teilhaben. Dies kann in relationalen Modellen nicht ausgedrückt werden. Falls es gewünscht wird, muss es auf andere Weise festgehalten und durch das Anwendungsprogramm sichergestellt werden.

Totale Beteiligung

Betrachten wir nun die Mannschaften. Sie tauchen mit folgenden Beschreibungen auf:

Die Mannschaften

• Jede Abteilung hat mehrere Mannschaften, insofern könnte "Mannschaft" ein Attribut von Abteilung sein.
• Von jeder Mannschaft werden die Bezeichnung (MaBez), die Spieler, der Kapitän, die Liga, der Trainer und ihre Begegnungen festgehalten.

Letzteres macht die Mannschaften zu Klassen und dann zu Relationen, da sie durch weitere Attribute beschrieben werden. Trainer und Kapitän sind aktive Mitglieder und werden somit durch einen Fremdschlüssel erfasst. Die Abteilungszugehörigkeit wird im nächsten Schritt geklärt. Damit ergibt sich folgender erster Entwurf:

Mannschaften (#MaNr, #MaBez, Liga, TrNr, KapNr)

Schlüssel, Sekundärschlüssel und Fremdschlüssel

MaNr: Mannschaftsnummer

MaBez: Mannschaftsbezeichnung

TrNr: Trainernummer

KapNr : Kapitänsnummer

Die Zuordnung der Spieler schieben wir auf, da eine Mannschaft mehrere Spieler hat. Die Begegnungen werden ebenfalls später geklärt, da sie durch weitere Attribute zu einer eigenständigen Existenz kommen.

Jetzt müssen noch die Abteilungen betrachtet werden. Für sie wurde oben festgehalten, dass der Verein in Abteilungen gegliedert ist (Handball und Fußball), dass jede Abteilung eine/n Leiter/in und mehrere Mannschaften hat.

Abteilungen

In Konfrontation mit den schon erstellten Modellfragmenten lässt sich damit festhalten, dass Abteilungen zu einer Relation mit den Attributen AbtBez und AbtLeiter wird. Die Tatsache, welche Mannschaft zu welcher Abteilung gehört, ist eine 1:n-Beziehung (z.B. als 1,1 : 1,n) und wird daher durch den Fremdschlüssel AbtNr in Mannschaften festgehalten.

Abteilungen (#AbtNr, #AbtBez, AbtLeiter)

Mannschaften (#MaNr, MaBez, Liga, TrNr, KapNr, AbtNr)

Eine Mannschaft hat mehrere Spieler, ein Spieler kann in mehreren Mannschaften sein. Damit liegt eine n:m-Beziehung zwischen Aktiven Mitgliedern (AM) und Mannschaften (MA) vor:

Spieler

AM-MA (#(MaNr, MiNr))

Im beschreibenden Text wurde festgelegt, dass alle Begegnungen von Mannschaften des Vereins mit Tagesdatum, Gegner und Ergebnis festgehalten werden sollen. Da die Mannschaften in einer anderen Relation beschrieben sind, werden sie hier durch den Fremdschlüssel MaNr repräsentiert:

Begegnungen

MaNr, Tag, Gegner, Ergebnis

Fehlt noch ein Schlüssel. Dieser könnte realisiert werden, indem bei jeder Begegnung der Beginn des Spiels miterfasst wird. Denn eine Mannschaft kann zwar u.U. an einem Tag mehrere Begegnungen haben, aber nicht mit demselben Startpunkt. Damit werden (MaNr, Tag, Beginn) zu einem Schlüssel und die Relation ergibt sich wie folgt:

Begegnungen (#(MaNr, Tag, Beginn), Gegner, Ergebnis)

Die Beziehung Begegnungen zu Mannschaften stellt eine Komposition dar. Wenn eine Mannschaft aus der Datenbank gelöscht wird, müssen (datenbanktechnisch) auch ihre Begegnungen verschwinden, da unvollständige Schlüssel nicht zulässig sind.

Muster Komposition

Zu beachten ist, dass es nur um die Spiele des betrachteten Vereins geht, nicht um alle Spiele einer Liga, was die Situation verändern würde. Oben wurde schon angemerkt, was geschieht, falls ausnahmsweise im Rahmen eines Turniers zwei Mannschaften des Vereins gegeneinander spielen.

3.5.3 Lösung

Insgesamt ergibt sich damit das folgende Datenmodell.

Textliche Fassung

Mitglieder (#MiNr, Name, VName, Tel, GebTag, PLZ, Ort, Straße, Status)

Mitgliedschaften (#(MiNr, Eintritt), Austritt)

MitglVerstorben (#MiNr, Todestag)

MitglAktiv (#MiNr, Sportart, LStufe)

MitglPassiv (#(MiNr, BezTät))

Begegnungen (#(MaNr, Tag, Beginn), Gegner, Ergebnis)

AM-MA (#(MaNr, MiNr))

Abteilungen (#AbtNr, AbtBez, AbtLeiter)

Mannschaften (#MaNr, MaBez, Liga, TrNr, KapNr, AbtNr)

Anmerkung:

Folgende Abweichungen gegenüber der Modellierung der Fragmente in den Basisübungen liegen vor:

- Attribut Mitglieder.Status. Es erfasst auch die verstorbenen Mitglieder, kann also die Attributsausprägungen aktiv, passiv und verstorben haben.

- Hier wurde nur ein einziger Telefonanschluss modelliert. Dadurch wird Tel ein ganz normales deskriptives Attribut.

Grafische Fassung

Abbildung 3.5-2: Gesamtmodell Sportverein

AbtNr: Abteilungsnummer

AbtLeiter: Abteilungsleiter

MaNr: Mannschaftsnummer

MiNr: Mitgliedsnummer

TrNr: Trainernummer

KapNr: Kapitänsnummer

LStufe: Leistungsstufe

BezTät: Bezeichnung der ehrenamtlichen Tätigkeit

3.6 Rechnungen/Kunden

Nun ein einfaches „Gesamtmodell“, das aber bereits wesentliche Komponenten relationaler Datenmodelle enthält.

3.6.1 Anforderungsbeschreibung

Es geht, stark vereinfacht, um die Verwaltung von Rechnungen von Kunden. Erfasst werden sollen die Rechnungen mit all ihren Positionen und dem Rechnungsdatum (ReDatum). Außerdem die Artikel, die in den Rechnungspositionen auftauchen mit ihrer Anzahl. Für die Artikel werden eine Beschreibung, der Preis und der Standort der Ware im Lager erfasst. Für die Kunden werden Name, Vorname, Postleitzahl (PLZ), Ort, Straße und ein Festnetztelefonanschluss (FestTelefon) sowie ein Mobiltelefon (MobilTelefon) erfasst. Von einem Kunden werden maximal zwei Adressen in die Datenbank genommen.

Vgl. Abschnitt 1.2 zur Typographie

3.6.2 Lösungsschritte

Relationen festlegen

Sofort erkennbar als Relationen ("Identifikation + Beschreibung") sind Rechnungen, Artikel und Kunden.

Für die Rechnungen wird ReNr als Schlüsselattribut gewählt. Das Rechnungsdatum kommt hinzu (ReDatum). Bei den Positionen ergibt sich ein Problem. Wie wir wissen hat eine Rechnung typischerweise mehrere Positionen, auf denen die gekauften Artikel vermerkt sind – je einer pro Position. Also müssen die Positionen getrennt verwaltet werden. Wir teilen daher das Realweltphänomen Rechnung auf in Rechnungsköpfe (RechKöpfe) und Rechnungspositionen (RechPos).

Rechnungen

In die Relation RechKöpfe kommen erstmal die Attribute ReNr und ReDatum:

RechKöpfe

RechKöpfe(#ReNr, ReDatum)

Für die Rechnungspositionen (RechPos) führen wir eine Positionsnummer ein (PosNr). Dieses Ergänzen von Attributen ist zulässig und auch immer wieder notwendig. Auch die Artikelnummer des Artikels (ArtNr), der auf der Position auftaucht (immer nur einer, normalerweise), wird hinzugefügt. Er wird Fremdschlüssel und leistet die Verknüpfung mit der später zu erstellenden Relation zu Artikeln (vgl. unten). Hinzugefügt wird noch die Anzahl der Artikel in der Position.

Erinnerung:

Schlüssel: identifizierendes Attribut bzw. identifizierende Attributskombination

Schlüsselattribut: Attribut eines Schlüssels

Nichtschlüsselattribut: die übrigen Attribute einer Relation

Fremdschlüssel: ein Attribut, das der relationalen Verknüpfung dient. Es ist in „seiner“ Relation nicht Schlüssel, aber in der anderen zu verknüpfenden Relation.

Mehr dazu in [Staud 2021, Abschnitt 8.2]

Bleibt noch der unabdingbare Schlüssel. Die Positionsnummer kann es nicht sein, denn diese wiederholt sich über die Rechnungen hinweg. Nehmen wir allerdings die Rechnungsnummer dazu, entsteht Eindeutigkeit. Die Kombination aus ReNr und PosNr ergibt den zusammengesetzten Schlüssel. Das darin enthaltene Attribut ReNr ist Fremdschlüssel, es leistet die Verknüpfung mit der Relation RechKöpfe:

RechPos (#(ReNr, PosNr), ArtNr, Anzahl)

RechPos

Anmerkungen:

- Auf die Positionsnummer könnte verzichtet werden. Dann wird hier stattdessen die Artikelnummer gewählt.

- Schlüssel sind unabdingbar. Wenn sie in den Anforderungen vergessen werden, sind sie zu ergänzen.

Die Beziehung zwischen Rechungsköpfen und -positionen hat die Kardinalitä 1:n und die Min-/Max-Angaben 1,n : 1,1. Es liegt also Existenzabhängigkeit vor. Mehr dazu unten.

Für die Kunden führen wir als Schlüssel eine Kundennummer ein (KuNr). Wir fügen Name und Vorname hinzu und ebenfalls den Mobilanschluss, denn dieser ist personenspezifisch, d.h. diese Information ist funktional abhängig vom Kunden, nicht von seiner Adresse. Damit ergibt sich:

Kunden

Kunden(#KuNr, Name, Vorname, MobilTelefon)

Normalerweise würden wir hier die Adressattribute ergänzen. Da es aber nach der Anforderungsbeschreibung mehr als eine Adresse je Kunde geben kann, müssen die Adressangaben in einer eigenen Relation verwaltet werden (keine Mehrfacheinträge!). Wir legen wieder einen Schlüssel fest, eine Adressnummer (AdrNr):

Adressen

Adressen (#AdrNr, PLZ, Ort, Straße, FestTelefon)

FestTelefon wurde zu den Adressen genommen, weil ein Festnetztelefon ortsspezifisch ist, d.h., dieses Attribut ist funktional abhängig von den Adressen.

Als letztes sind noch die Artikel zu klären. Für sie werden in der Beschreibung eine Beschreibung, der Preis und der Standort der Ware im Lager (Standort) verlangt. Wir ergänzen noch den oben schon angelegten Schlüssel, Artikelnummer (ArtNr), und erhalten damit:

Artikel

Artikel (#ArtNr, Beschreibung, Preis, Standort)

Insgesamt liegen damit folgende Relationen vor:

Adressen (#AdrNr, PLZ, Ort, Straße, FestTelefon)

Artikel (#ArtNr, Beschreibung, Preis, Standort)

Kunden(#KuNr, Name, Vorname, MobilTelefon)

RechKöpfe(#ReNr, ReDatum …

RechPos (#(ReNr, PosNr), ArtNr, Anzahl)

Restliche Verknüpfungen

Eine wichtige relationale Verknüpfung wurde oben schon eingefügt, die Komposition zwischen Rechnungsköpfen und -positionen. Denn es gilt: Eine Rechnung hat mindestens eine Position und eine Position gehört zu genau einer Rechnung. Es liegt also eine 1 :n-Beziehung zwischen Rechnungsköpfen und Rechnungspositionen vor. Der oben angelegte zusammengesetzte Schlüssel (ReNr, PosNr) drückt diese Existenzabhängigkeit aus, da durch den zusammengesetzten Schlüssel festgelegt wird, dass jede Rechnungsposition auch zu einem Rechnungskopf gehören muss (Komposition).

Komposition

Verknüpfungen sind oft nicht explizit in den Anforderungsbeschreibungen enthalten, sondern müssen aus der Semantik des Anwendungsbereichs oder von der Methodik abgeleitet werden. Hier z.B. für die Verknüpfung von Rechnungen und Kunden. Für diese gilt folgende Semantik: Jede Rechnung gehört zu genau einem Kunden. Ein Kunde kann mehrere Rechnungen haben. Eine solche 1:n-Verknüpfung zwischen Kunden und Rechnungen wird mit den Min-/Max-Angaben 0,n : 1,1 oder 1,n : 1,1 so umgesetzt: Die Kundennummer (KuNr) wird der Relation Rechnungsköpfe als Fremdschlüssel hinzugefügt:

Rechnungen und Kunden

RechKöpfe(#ReNr, KuNr, ReDatum)

Die Verknüpfung zwischen den Artikeln und Rechnungspositionen beruht ebenfalls auf einer 1:n-Verknüpfung: auf einer Rechnungsposition ist genau ein Artikel, ein Artikel kann auf mehreren Positionen auftreten. Die Min-/Max-Angaben (Artikel/Rechnungspositionen) sind entsprechend 0,n : 1,1. Dies wurde bereits oben durch Einfügen der Artikelnummer (ArtNr) in die Relation RechPos realisiert. ArtNr ist dort Fremdschlüssel.

Artikel und Rechnungs-positionen

RechPos (#(ReNr, PosNr), ArtNr, Anzahl)

Bleibt noch die Verbindung von Kunden und Adressen. Hier wird in der Anforderungsbeschreibung ausgeführt, dass jeder Kunde in der Datenbank zwei Adressen haben kann. Z.B. eine Liefer- und eine Rechnungsadresse. Dies wäre eine 1:n-Beziehung. Da wir aber gleich noch berücksichtigen, dass unter einer Adresse mehrere Kunden wohnen können, wird diese Beziehung zu einer n:m-Beziehung und bedarf einer eigenen Relation, einer Verbindungsrelation. Wenn wir festlegen, dass ein Kunde nur angelegt wird, wenn mindestens eine Adresse vorliegt und eine Adresse nur, wenn sie tatsächlich zu einem Kunden gehört, sind die Min-/Max-Angaben (Kunden/Adressen) 1,2 : 1,m.

Kunden und Adressen

Dies führt zu einer Relation Kundenadressen (KuAdr). Sie hat den zusammengesetzten Schlüssel aus Adressnummer und Kundenummer :

KuAdr (#(AdrNr, KuNr))

Restliche Prüfung

Die gefundenen Relationen sind in der jeweils letzten Fassung vollständig. Es müssen keine weiteren Attribute ergänzt werden, wir können die Relationenbeschreibungen schließen.

Sie sind auch alle bereits in der höchsten Normalform: Es gibt einen Schlüssel und weitere Attribute, die nur von diesem vollumfänglich funktional abhängig sind (BCNF). Probleme mit der 4NF und 5NF gibt es augenscheinlich nicht.

3.6.3 Lösung

Damit ergibt sich folgendes Datenmodell, zuerst die textliche Notation:

Textlich

Adressen(#AdrNr, PLZ, Ort, Straße, FestTelefon)

Artikel (#ArtNr, Beschreibung, Preis, Standort)

KuAdr (#(AdrNr, KuNr))

Kunden(#KuNr, Name, Vorname, MobilTelefon)

RechKöpfe(#ReNr, ReDatum, KuNr)

RechPos(#(PosNr, ReNr), ArtNr, Anzahl)

Die Frage, ob wirklich alle Verknüpfungen umgesetzt wurden, beantwortet sehr anschaulich die grafische Ausprägung des Datenmodells.

Grafisch

Abbildung 3.6-1: Relationales Datenmodell Rechnungen/Kunden

3.6.4 FA - Diagramme

Eine Einführung in FA-Diagramme findet sich in [Staud 2021, Kapitel 8] und http://www.staud.info/rm1/rm_t_1.htm#Kapitel9

Oftmals ist die Betrachtung der funktionalen Abhängigkeiten der Relationen von großem Nutzen. Sie zeigen insbesondere auf, ob wirklich die höchste Normalform bei den Relationen erreicht wurde.

Aufgabe

Erstellen Sie für alle Relationen des Datenmodells ein FA-Diagramm.

Lösung

Abbildung 3.6-2: FA-Diagramme der Relationen zum Datenmodell Rechnungen/Kunden.

Die FA-Diagramme zeigen, dass tatsächlich alle Relationen in der höchsten Normalform sind.

3.6.5 Umsetzung mit mySQL

Aufgabe

• Erstellen Sie zu diesem Datenmodell die Datenbank mit SQL-Befehlen.
• Füllen Sie Demo-Daten ein, in denen die Verknüpfungen sichtbar werden.
• Führen Sie dann Auswertungen über die Verknüpfungen aus.

Lösung

Datenbank und Relationen einrichten

Die Datenbank soll ReKu (Rechnungen/Kunden) genannt werden. Umlaute werden umgewandelt. Einige Attributsbezeichnungen wurden gekürzt.

Aufpassen: Reihenfolge beachten. Bei Verknüpfungen zuerst die Relation mit dem Schlüssel, dann die mit dem Fremdschlüssel.

Der folgende Befehl legt die Datenbank an:

create database reku default character set latin1 collate latin1_german1_ci;

Nun die Relationen:

ReKu

create table kunden (KuNr smallint(5), name char(10), vorname char(10), mobil char(12), primary key (KuNr));

Anzeige Struktur mit mySQL

create table artikel (ArtNr smallint(4), beschreibung varchar(10), preis decimal(7,2), standort char(5), primary key (ArtNr));

Artikel

create table adressen (AdrNr smallint(7), plz char(5), ort char(10), strasse char(10), FestTelefon char(15), primary key (adrnr));

Adressen

create table RechKoepfe (ReNr smallint(6), KuNr smallint(5), primary key (ReNr), ReDatum date, foreign key (KuNr) references kunden(KuNr))

RechKoepfe

create table RechPos (ReNr smallint(6), PosNr tinyint(3) unsigned, ArtNr smallint(4), anzahl smallint(2),

primary key (ReNr, PosNr),

foreign key (ArtNr) references artikel(ArtNR),

foreign key (ReNr) references RechKoepfe(ReNr));

RechPos

create table KuAdr (AdrNr smallint(7), KuNr smallint(5),

primary key (adrnr, kunr),

foreign key (kunr) references kunden(kunr),

foreign key (adrnr) references adressen(adrnr));

KuAdr

Demo-Daten einfüllen

[Falls wegen Fehlern Wiederholung nötig ist, vorab: delete from kunden;]

Eingabe Kundendaten

insert into kunden (KuNr, Name, Vorname) values (1007, 'Aberer', 'Anton');

insert into kunden (KuNr, Name, Vorname) values (1008, 'Blauer', 'Guiseppe');

insert into kunden (KuNr, Name, Vorname) values (1009, 'Cäser', 'Filippa');

insert into kunden values (1010, 'Dodolo', 'Rita', '1234567890');

insert into kunden values (1011, 'Steiner', 'Sepp', '2345678901');

select * from kunden;

Eingabe Adressdaten

Insert into adressen (AdrNr, plz, ort) values (1001, '88333', 'Waldhausen');

Insert into adressen (AdrNr, plz, ort, strasse) values (1011, '99333', 'Buchen', 'Am Baum 7');

Insert into adressen values (2011, '11111', 'Karlstadt', 'Hauptstr. 77', '111-2222');

Select * from adressen;

Eingabe in KuAdr

insert into KuAdr values (1001, 1007);

insert into KuAdr values (2011, 1007);

insert into KuAdr values (1001, 1008);

insert into KuAdr values (1011, 1009);

insert into KuAdr values (2011, 1010);

select * from KuAdr;

Auch die Verknüpfung von kunden und adressen über kuadr klappt:

select k.kunr, k.name, k.vorname, k.mobil, a.adrnr, a.plz, a.ort, a.strasse

from kunden k, adressen a, kuadr v

where k.kunr=v.kunr and a.adrnr=v.adrnr;

Eingabe in Artikel

insert into artikel values (100, 'Gamer-PC', 2500.00, 'ST007');

insert into artikel values (101, 'Büro-PC', 1200.00, 'ST018');

insert into artikel values (102, 'Entwickler-PC', 3200.00, 'ST100');

select * from artikel;

insert into rechkoepfe values (23001, 1007, '2023-03-27');

select * from rechkoepfe;

insert into rechpos values (23001, 1, 100, 1);

insert into rechpos values (23001, 1, 101, 2);

3.7 Haushaltsgeräte

Aufgabenstellung: Prof. Dr. Josef L. Staud

Lösung: stud. inform. Karolin Staud

Bei dieser Aufgabe soll nicht nur das relationale Datenmodell erstellt werden, sondern auch die Datenbank selbst mit mySQL. Anschließend soll sie noch mit beispielhaften Daten befüllt werden.

3.7.1 Anforderungsbeschreibung

Es geht um Haushaltsgeräte in einem Einzelhandelsgeschäft (vereinfacht), die in einer Datenbank erfasst werden sollen.

Für jedes Haushaltsgerät wird die Bezeichnung (Bez) erfasst, z.B. Staubsauger XYZ. Außerdem der Hersteller (Hersteller), der Listenpreis (LPreis) und die Anzahl der Geräte im Lager (AnzLager). Jedes einzelne Gerät erhält eine Gerätenummer (GNr) und es wird festgehalten, wann es hergestellt wurde (MonatHerst; Monat Herstellung) und wann es ins Lager kam (LagAufn).

Für Staubsauger wird zusätzlich festgehalten, welche Saugkraft sie haben und von welchem Typ sie sind (mit Beutel, ohne, …). Für Kaffemaschinen, welche Wassermenge sie maximal verarbeiten können (MengeWasser) und in welcher Zeit sie einen halben Liter Kaffee kochen (Geschw).

Von den Kunden werden Name und Vorname (VName) erfasst und sie erhalten eine Kundennummer (KuNr). Jeder Kunde kann beliebig viele Adressen (PLZ, Ort, Straße) besitzen. Die Erfahrung hat gezeigt, dass unter einer Adresse u.U. mehrere Kunden wohnen (Mehrfamilienhaus, Studierendenwohnheim, …), dies soll datenbanktechnisch festgehalten werden.

Kunden haben inzwischen oft mehrere Telefone (Festnetz und mobil). Diese werden alle erfasst. Es kommt vor, dass unter einer Telefonnummer mehrere Kunden zu erreichen sind (z.B. bei einer Familie).

Beim Verkauf eines Gerätes wird festgehalten, an welchen Kunden das Gerät verkauft wurde. Außerdem das Datum und der tatsächlich erzielte Preis (ErzPreis). Dieser weicht oft vom Listenpreis ab, weil z.B. Nachlässe gegeben werden.

3.7.2 Lösungsschritte

Die Haushaltsgeräte (HG) sind gleich als Relation erkennbar. Sie werden durch die Gerätenummer (GNr) identifiziert und durch zahlreiche weitere Attribute beschrieben:

HG (#GNr, Bez, Hersteller, LPreis, AnzLager, MonatHerst, LagAufn, …

Ein wenig Unbehagen erzeugt diese Relation allerdings. Werden hier nicht Informationen mehrfach erfasst? Z.B. der Hersteller und der Listenpreis für alle identischen Geräte? Genauso ist es und etwas Erinnerung an die Theorie führt zu dem Ergebnis, dass hier ein Muster Einzel/Typvorliegt [Anmerkung] . Vgl. oben sowie [Staud 2021, Abschnitt 14.2]. Obige Relation würde also viele Redundanzen aufweisen. Die Lösung besteht darin, zwei Relationen anzulegen, HG-Einzeln und HG-Typen.

Hausgeräte (HG)

Beginnen wir mit HG-Einzeln. Die einzelnen Geräte werden durch die Gerätenummer (GNr) identifiziert und als Einzelgeräte durch den Monat der Herstellung (MonatHerst) und die Lageraufnahme (LagAufn) beschrieben:

Muster Einzel/Typ

HG-Einzeln (#GNr, MonatHerst, LagAufn)

Die Geräte als Typen erhalten Bez als Schlüssel und die Attribute Hersteller, LPreis und AnzLager als beschreibende Attribute:

HG-Typen (#Bez, Hersteller, LPreis, AnzLager)

Bleibt noch die Verknüpfung dieser Einzel- und Gerätetyp-Informationen. Diese erfolgt wie meist durch Schlüssel/Fremdschlüssel. Beim Muster Einzel/Typ ist es immer so, dass bei der Einzelinformation der Schlüssel der zugehörigen Typinformation eingefügt wird:

HG-Einzeln (#GNr, MonatHerst, LagAufn, Bez)

Umgekehrt wäre es nicht möglich, da dies zu Mehrfacheinträgen führen würde. Die Kardinalität ist (von HG-Einzeln ausehend) n:1, die Min-/Max-Angaben sind 1,1 : 0,n:

• Jedes individuelle Hausgerät gehört zu genau einem Gerätetyp
• Zu einem Gerätetyp gehören mehrere Einzelgeräte oder auch keines mehr, nach dem Verkauf des Letzen.

In der Anforderungsbeschreibung werden dann Staubsauger und Kaffeemaschinen angeführt. Sie sind auch Geräte, erhalten aber zusätzliche Attribute: Staubsauger Saugkraft und Typ, Kaffemaschinen MengeWasser und Geschw. Damit liegt eine Generalisierung / Spezialisierung vor. Vgl. oben sowie [Staud 2021, Abschnitt 14.1].

Generalisierung / Spezialisierung

In beiden Fällen sind die Attribute auf Typebene: alle einzelnen Kaffeemaschinen haben das Attribut MengeWasser, usw. Insofern gehören sie zur Relation HG-Typen. Ergänzen wir nun aber einfach die Relation HG-Typen um diese Attribute, gibt es das Problem, dass bestimmte Attribute nicht für alle Objekte Gültigkeit haben. Staubsauger haben z.B. nicht die Attribute von Kaffemaschinen, Kühlgeräte weder die von Staubsaugern noch von Kaffeemaschinen, usw. Es gibt also semantische bedingte Leereinträge, die in Datenbeständen absolut unerwünscht sind (vgl. [Staud 2021, S. 180ff]). Die Ursache liegt in der hier vorliegenden Generalisierung/Spezialisierung (Gen/Spez). Diese verlangt für eine korrekte Modellierung, dass die Spezialisierungen (hier: Staubsauger und Kaffeemaschinen) in eigenen Relationen erfasst und mit der Generalisierung (hier: HG-Typen) verknüpft werden.

Generalisierung / Spezialisierung

Es entstehen also eigene Relationen für Staubsauger und Kaffeemaschinen, mit dem Schlüssel von HG-Typen:

HG

Staubsauger (#Bez, Saugkraft, Typ)

Kaffeemaschinen (#Bez, MengeWasser, Geschw)

Die Schlüssel der Spezialisierungen sind also gleich dem Schlüssel der Generalisierung. Allerdings sind die Schlüsselmengen der Spezialisierungen Teilmengen der Schlüsselmenge der Generalisierung. Es handelt sich um eine Beziehung mit der Kardinalität 1:1 und den Min-/Max-Angaben 0,1 : 1,1 (von der Generalisierung ausgehend).

Auch die Kunden erfüllen die Kriterien für eine Relation. Der Schlüssel ist KuNr, die Attribute sind Name und Vorname.

Kunden

Kunden (#KuNr, Name, Vorname)

Wo kommen die Adressinformationen hin? Gäbe es nur eine Adresse, kämen sie einfach in die Kundendatei. Die Möglichkeit mehrerer Adressen je Kunde führt aber zu einer eigenen Relation Adressen mit den Attributen PLZ, Ort, Straße. Da es ohne Schlüssel nicht geht und in der Anforderung keiner spezifiziert ist, legen wir einen fest: AdrNr (Adressnummer):

Adressen

Adressen (#AdrNr, PLZ, Ort, Straße)

In der Beschreibung wird ausgeführt, dass Kunden mehrere Telefonanschlüsse haben können. Dafür muss dann eine eigene Relation Telefone angelegt werden. Für diese steht beschreibend nur die Telefonnummer zur Verfügung (Tel). Da zu einem Anschluss mehrere Kunden gehören, liegt eine n:m-Beziehung zwischen Kunden und Telefonen vor. Die MinMax-Angaben sind 0,n : 1,m. Wir lassen also auch zu, dass es in unserer Datenbank Kunden ohne angegebene Telefonnummer gibt. Dies alles erfordert einen zusammengesetzten Schlüssel in Telefone und KuNr als Fremdschlüssel :

Telefon­anschlüsse mit 1:n

Telefone (#(Tel, KuNr))

Die bei einer Verbindungsrelation normalerweise folgende dritte Relation (hier zu Telefonanschlüssen) ist mangels beschreibender Attribute für Telefonanschlüsse hier nicht nötig. Wäre aber möglich, z.B. bezüglich Anschlussart, Geschäftstelefon, privater Anschluss, Erreichbarkeit des Anschlusses.

Die Erfassung der Verkäufe gestaltet sich etwas anspruchsvoller. In der Beschreibung ist angedeutet, dass Einzelgeräte erfasst werden sollen, nicht die Bezeichnung der Typ-Ebene. Da wäre modelltechnisch eine Ergänzung der Relation HG-Einzeln durch ein Attribut KuNr als Fremdschlüssel denkbar:

Verkäufe

HG-Einzeln (#GNr, KuNr, Bez, … //falsche Lösung

Dies entspricht einer 1:n-Beziehung zwischen KUNDEN und HG-Einzeln. Überdenkt man die damit ausgedrückte Semantik, wird aber klar, dass dies nicht möglich ist. In HG-Einzeln werden alle Geräte erfasst, die auf Lager genommen werden. In die Verkäufe kommen nur die verkauften Geräte, also eine Teilmenge. Will man entsprechend der relationalen Theorie semantisch bedingte Leereinträge (hier bei KuNr) vermeiden, ist eine Relation Verkäufe mit dem Schlüssel/Fremdschlüssel #GNr und dem Fremdschlüssel KuNr die richtige Lösung:

Verkäufe (#GNr, KuNr, Datum, ErzPreis) //richtige Lösung

Hier ist nun jedem tatsächlich verkauften Gerät ein Kunde zugeordnet mit einer 1:n-Beziehung zwischen Kunden und Geräten.

Die Min-/Max-Angaben sind (von den Kunden ausgehend) 0,n : 0,1. Es kann also Kunden geben, die noch nicht gekauft haben und es gibt natürlich Geräte, die noch nicht verkauft sind. Auch hier gilt wieder, dass dies auch anders festgelegt werden kann.

Die Beziehung zwischen Kunden und Adressen ist noch nicht erfasst. Hier wurde in der Anforderung darauf hingewiesen, dass nicht nur ein Kunde mehrere Adressen haben kann, sondern dass unter einer Adresse auch mehrere Kunden wohnen können. Eine solche Situation erfordert eine n:m-Beziehung, die zu einer Verbindungsrelation KuAdr führt:

Adressen

KuAdr (#(KuNr, AdrNr))

Die Min-/Max-Angaben können wir festlegen. Da es in der Datenbank keine Kunden ohne Adressen und keine Adressen ohne Kunden geben soll (beides wäre auch möglich!), ergeben sich die Min-/Max-Angaben 1,n : 1,m.

Damit ist die Modellierung abgeschlossen. Die Relationen sind in der höchsten Normalform: Die BCNF ist erfüllt und es liegen keine Verstöße gegen die 4NF und 5NF vor. Die auftretenden Muster (Gen/Spez und Einzel/Typ) wurden eingearbeitet. Zeitliche Informationen liegen, bis auf das Verkaufsdatum, nicht vor.

3.7.3 Lösung

Textliche Fassung

HG-Einzeln (#GNr, MonatHerst, LagAufn, Bez)

HG-Typen (#Bez, Hersteller, LPreis, AnzLager)

Staubsauger (#Bez, Saugkraft, Typ)

Kaffeemaschinen (#Bez, MengeWasser, Geschw)

Kunden (#KuNr, Name, Vorname)

Adressen (#KuNr, PLZ, Ort, Straße)

KuAdr (#(KuNr, AdrNr))

Telefone (#(Tel, KuNr))

Verkäufe (#GNr, KuNr, Datum, ErzPreis)

Grafische Fassung

Abbildung 3.7-1: Relationales Datenodell Haushaltsgeräte

3.7.4 Datenbank erstellen

Zuerst muss die Datenbank angelegt werden. Dies geschieht mit folgendem Befehl:

create database HG default character set latin1 collate latin1_german1_ci;

Dann werden die Relationen angelegt. Dabei muss eine Reihenfolge beachtet werden: Eine Relation mit Fremdschlüssel kann nur eingerichtet werden, wenn die Relation mit dem zugehörigen Schlüssel vorhanden ist.

HG-Typen (#Bez, Hersteller, LPreis, AnzLager)

create table hgt (Bez varchar(7), Hersteller varchar(2), LPreis decimal(7,2), AnzLager smallint(3), primary key (bez));

HG-Einzeln (#GNr, MonatHerst, LagAufn, Bez)

create table hge (GNr int(5), MonatHerst date, LagAufn date, bez varchar(7) references hgt (bez), primary key (GNr));

Kaffeemaschinen (#Bez, MengeWasser, Geschw)

create table kaffee (bez varchar(7), wasser decimal(4,1), geschw smallint(3), primary key (bez));

Staubsauger (#Bez, Saugkraft, Typ)

create table staubsauger (bez varchar(7), saug int (4), typ varchar(10), primary key (bez));

Adressen (#KuNr, PLZ, Ort, Straße)

create table adressen (AdrNr int(6), plz varchar(5), ort varchar(10), strasse varchar(10), primary key (adrnr));

Kunden (#KuNr, Name, Vorname)

create table kunden (KNr int(6), name varchar(10), vname varchar(10), primary key (KNr));

KuAdr (#(KuNr, AdrNr))

create table KuAdr (KNr int(6), AdrNr int(6), primary key (KNr, AdrNr), foreign key (KNr) references kunden(knr), foreign key (adrnr) references adressen(adrnr));

Verkäufe (#GNr, KuNr, Datum, ErzPreis)

create table verkaeufe (GNr int(5), KNr int(6) references kunden(knr), Datum date, ErzPreis decimal (6,2), primary key (GNr));

Telefone (#(Tel, KuNr))

create table telefone (Tel varchar(10), KNr int(6), primary key (Tel, KNr), foreign key (KNr) references kunden(knr));

Alternativ, mit Benennung des Fremdschlüssels:

create table telefone2 (Tel varchar(10), KNr int(6), primary key (Tel, KNr), constraint fs_tel_ku foreign key (KNr) references kunden(knr));

3.8 Obst

3.8.1 Anforderungsbeschreibung

Ein Einzelhändler möchte seine Obstlieferanten und Obstlieferungen in einer Datenbank verwalten. Für alle Lieferanten erfasst er die Zuverlässigkeit (ZV; Skala von 1 bis 6) und die Art der Abrechnung (AbrArt; sofort, Monatsende, Saisonende, ...). Bezüglich der Landwirte, die ihm Obst liefern, erfasst er Name, Vorname (VName), Typ (biologisch, konventionell, ...), Postleitzahl (PLZ), Ort, Straße, Telefon (nur eines; Tel), Mailadresse (E-Mail) und welche Obstsorten (z.B. Golden Delicious) (SortBez) sie ihm in den einzelnen Monaten typischerweise liefern können ("Lieferbarkeit"). Natürlich bezieht er dieselbe Obstsorte u.U. von unterschiedlichen Landwirten und von einem Landwirt mehrere Obstsorten, z.B. eine Sorte Äpfel, mehrere Sorten Birnen, usw., alles was in der Region wächst.

Bezüglich der Obstgroßhändler erfasst er Firmenname (FName), Land (Deutschland, Österreich, Schweiz, Niederlande, ...) Postleitzahl (PLZ), Ort (Ort), Straße, Telefon (nur eines) (Tel), Fax (Fax), Mailadresse (E-Mail) und - genau wie bei den Landwirten - welche Obstsorten (SortBez) in welchem Zeitraum typischerweise lieferbar sind (z.B. Erdbeeren von Januar bis März, da aus Übersee). Alle Lieferanten (Landwirte oder Großhändler) erhalten eine Lieferantennummer (LiefNr). Aus pragmatischen Gründen erhält jede Obst­sorte auch eine identifizierende Nummer (Sortennummer, SortNr). Für jede Obstsorte wird auch festgehalten, wie lagerfähig sie ist (LagFäh), d.h. wieviele Wochen man sie gekühlt aufheben kann.

Weiter sollen konkrete Lieferungen (von Landwirten oder Großhändlern) erfasst werden mit Obstsorte, Menge (Menge), Liefertag (LTag), Lieferant (Landwirt oder Großhändler) und Kilopreis (KPreis). Ein Lieferant liefert höchstens einmal pro Tag, da aber u.U. mehrere Obstsorten. Aus statistischen Gründen wird auch festgehalten, wieviel (in kg) von jeder Obstsorte umgesetzt wurde (Umsatz). Diese Berechnung erfolgt in jedem Jahr neu ab Jahresanfang.

3.8.2 Lösungsschritte

Beim Lesen der Anforderungsbeschreibung sollte man erkennen, dass die Beschreibung der Lieferanten zu der Struktur führt, die man Generalisierung / Spezialisierung nennt. Da gibt es zum einen Landwirte, zum anderen Großhändler und beide haben teilweise identische Attribute. Da beide Gruppen identifiziert und beschrieben werden, ist für sie jeweils eine Relation anzulegen. Für die identischen Attribute ist ebenfalls eine eigene Relation anzulegen. Die erste Annäherung ergibt:

Generalisierung / Spezialisierung

• Attribute für alle Lieferanten (Generalisierung): LiefNr, ZV, AbrArt
• Attribute für Landwirte (Spezialisierung 1): Name, VNameTyp, PLZ, Ort, Straße, Tel, E-Mail, SortBez (mehrere)
• Attribute für Großhändler (Spezialisierung 2): FName, Land, PLZ, Ort, Straße, Telefon, Fax, E-Mail

Schauen wir obige drei Relationenkandidaten an, sehen wir, dass die beiden Spezialisierungen noch identische Attribute aufweisen. Dies muss geändert werden, schließlich sollen Generalisierung und Spezialisierungen bis auf verknüpfende Attribute nur verschiedene haben. Wir nehmen also im nächsten Schritt alle weiteren Attribute, die für alle Lieferanten vorliegen, in die entsprechende Relation:

Lieferanten (#LiefNr, ZV, AbrArt, PLZ, Ort, Straße, E-Mail, Tel)

Natürlich kommen wir gleich ins Grübeln, was die Adressen angeht. Da aber nicht verlangt ist, mehrere Adressen pro Lieferant zu erfassen, können wir es so belassen.

Für die Landwirte bleiben dann noch folgende Attribute übrig:

Landwirte (#LiefNr, Name, Vorname, Typ)

Für die Großhändler:

Großhändler (#LiefNr, FName, Land, Fax)

Wie üblich bei einer Generalisierung / Spezialisierung erhalten alle drei Relationen denselben Schlüssel. Für Anmerkungen zur Verknüpfung vgl. unten.

Pragmatik. Die relationale Theorie verlangt es nicht, aber aus pragmatischen Gründen nimmt man bei einer Gen/Spez oftmals ein Attribut in die Generalisierung, das für jeden Eintrag festhält, zu welcher Spezialisierung er gehört. Das macht SQL-Abfragen sehr viel einfacher, z.B. wenn auf die Spezialisierungen zugegriffen werden soll. Wir ergänzen hier also in Lieferanten ein Attribut Typ mit den zwei Ausprägungen Landwirt (LW) und Großhändler (GH).

Lieferanten (#LiefNr, Typ, ZV, AbrArt, PLZ, Ort, Straße, E-Mail, Tel)

Betrachten wir nun die Lieferbarkeit. Hier deutet die Anforderungsbeschreibung an, dass Landwirte und Großhändler gleich behandelt werden. Folgende Tabelle fasst die beschriebene Semantik zusammen.

Lieferbarkeit und Obstsorten

• Ein Lieferant kann mehrere Obstsorten liefern und dies jeweils in verschiedenen Monaten.
• Eine Obstsorte kann von verschiedenen Lieferanten geliefert werden und dies wiederum in verschiedenen Monaten.

Wir haben also eine Dreierbeziehung, die durch einen Schlüssel mit drei Attributen bewältigt wird:

Lieferbarkeit (#(LiefNr, ObstNr, Monat))

Wer da Probleme hat, dem hilft die Überlegung, dass erst durch das Attribut Monat jedes Tupel eindeutig wird. Die Unterstreichungen kennzeichnen Fremdschlüssel und deuten Verknüpfungen an. Dazu unten mehr.

Auch für die Obstsorten liegen identifizierende und beschreibende Attribute vor, so dass eine entsprechende Relation entsteht:

Obstsorten (#ObstNr, SortBez, LagFäh)

Die Beziehungen ergeben sich zum Teil methodisch, zum Teil semantisch. Methodisch sind es die zwischen der Generalisierung Lieferanten und den Spezialisierungen Landwirte und Großhändler. Dies wurde oben schon durch den Schlüssel LiefNr umgesetzt. Die Kardinalität einer Beziehung zwischen Generalisierung und Spezialisierung ist 1:1. Da aber in jeder Spezialisierung nur eine Teilmenge der Generalisierung vorliegt, sind die Min-/Max-Angaben (für Landwirte/Lieferanten bzw. Großhändler/Lieferanten) 1,1 : 0,1.

Beziehungen klären

Eine semantische Basis haben die „konkreten Lieferungen“ (KonkreteLief). Sie verknüpfen Lieferanten und Obstsorten. Wegen der angeführten Wertigkeiten können wir eine Relation mit einem zusammengesetzten Schlüssel anlegen:

KonkreteLief (#(LiefNr, ObstNr))

Es fehlt aber noch der Liefertag (LTag). Da jeder Lieferant höchstens einmal pro Tag liefert, können wir LTag noch zum Schlüssel hinzunehmen:

KonkreteLief (#(LiefNr, ObstNr, LTag))

Wenn wir die beschreibenden Attribute noch hinzufügen erhalten wir die folgende Relation:

KonkreteLief (#(LiefNr, ObstNr, LTag), Menge, KPreis)

Die beiden Fremdschlüssel zeigen die notwendigen relationalen Verknüpfungen zwischen Lieferanten und Obstsorten auf. Die Kardinalität ist n:m, die Min-/Max-Angaben sollen auf 0,n : 0,m festgelegt werden. D.h., wir wollen auch Lieferanten erfassen, von denen noch keine Lieferungen kamen und Obstsorten, die noch nicht geliefert wurden.

Etwas Nachdenken verlangen die abschließenden Ausführungen zu den Jahresmengen. Es ist verlangt, in jedem Jahr für jede Obstsorte den Umsatz im Zeitverlauf hochzurechnen. Dies kann nicht in vollem Umfang durch die Datenmodellierung gelöst, sondern nur vorbereitet werden. Dazu dient die folgende Relation:

Jahresumsätze (#(Jahr, ObstNr), Umsatz)

Eine Verknüpfung kann mit Obstsorten angelegt werden. Die Kardinalität ist (von Obstsorten ausgehend) 1:n, da es nach mehreren Jahren mehrere Jahresumsätze je Obst­sorte gibt. Die Min-/Max-Angaben sind, wenn wir annehmen, dass neue Obstsorten nicht gleich in die Messung geraten, 0,n : 1,1.

Durch Datenbankprogrammierung (Trigger, usw.) muss sichergestellt werden, dass bei jedem Eintrag in KonkreteLief in der Relation Jahresumsätze ein Fortschreiben des entsprechenden Umsatzes erfolgt. Am Jahresende muss die Datenbankprogrammierung sicherstellen, dass neue Tupel für das neue Jahr angelegt werden.

Die Relationen sind in der höchsten Normalform: Die BCNF ist erfüllt und es liegen keine Verstöße gegen die 4NF und 5NF vor. Das auftretende Muster (Gen/Spez) wurde eingearbeitet. Weitere liegen nicht vor. Die automatisierte Bestimmung der Jahresumsätze muss mittels Datenbankprorammierung erfolgen.

Schluss­bemerkung

3.8.3 Lösung

Textliche Fassung

Großhändler (#LiefNr, FName, Land, Fax)

Jahresumsätze (#(Jahr, ObstNr), Umsatz)

KonkreteLief (#(LiefNr, ObstNr, LTag), Menge, KPreis)

Landwirte (#LiefNr, Name, Vorname, Typ)

Lieferanten (#LiefNr, ZV, AbrArt, PLZ, Ort, Straße, E-Mail, Tel)

Lieferbarkeit (#(LiefNr, ObstNr, Monat))

Obstsorten (#ObstNr, SortBez, LagFäh)

Grafische Fassung

Abbildung 3.8-1: Relationales Datenmodell Obst

3.9 Angestellte

Diese Aufgabe gehört mit 18 Relationen und zahlreichen Modellmerkmalen (auch zu Zeitaspekten) zu den ausführlichen.

3.9.1 Anforderungsbeschreibung

In diesem Anwendungsbereich geht es um Angestellte eines Unternehmens, ihre Ausstattung mit PC, ihre Mitarbeit in Abteilungen und Projekten, usw. Ausschnitte aus diesem didaktisch motivierten Datenmodell dienen in den Theoriekapiteln von [Staud 2021] als Beispiele. Folgendes soll festgehalten werden:

(1) Für die Angestellten die Personalnummer (PersNr), der Name (Name), Vorname (VName) und Geburtstag (GebTag). Außerdem werden die Adressen erfasst mit Strasse, PLZ, Ort und einer zweiten Adresszeile (AdrZ2). Jeder Angestellte kann mehrere Adressen haben und unter einer Adresse können mehrere Angestellte wohnen.

(2) Das Vorgesetztenverhältnis. Wer ist wem unter- bzw. überstellt?

(3) Für die Projekte die Bezeichnung (Bez), der Einrichtungstag (TagEinr), die Dauer (Dauer) und das Budget (Budget). Ein Projekt kann auf mehrere Standorte verteilt sein. Dies wird auch erfasst.

(4) Die Standorte werden mit einer identifizierenden Information (OrtId), ihrer Bezeichnung (Bez), ihrer Adresse und der Anzahl Mitarbeiter am Standort (AnzMitarb) erfasst.

(5) Ein Angestellter kann in mehreren Projekten mitarbeiten und ein Projekt hat typischerweise mehrere Mitarbeiter.

(6) Für die Abteilungen wird die Abteilungsbezeichnung (AbtBez), der Abteilungsleiter (AbtLeiter) und der Standort festgehalten. Eine Abteilung ist immer genau an einem Standort, an einem Standort können mehrere Abteilungen sein.

(7) In einer Abteilung sind mehrere Angestellte, ein Angestellter gehört aber zu einem Zeitpunkt genau zu einer Abteilung. Im Zeitverlauf können Angestellte auch die Abteilung wechseln, was mit BeginnZ(ugehörigkeit) und EndeZ ebenfalls erfasst wird.

(8) Festgehalten wird auch, welche Funktion ein Angestellter in einer Abteilung hat. Dies geschieht mit Hilfe der Funktionsbezeichnung (BezFu), dem Beginn (Beginn) und Ende (Ende) der Funktionsübernahme. Es ist durchaus möglich, dass ein Angestellter im Zeitablauf auch unterschiedliche Funktionen in einer Abteilung übernimmt. Zu einem Zeitpunkt aber immer nur eine.

(9) Für die von den Angestellten benutzten PC wird die Inventarnummer, (InvNr), das Kaufdatum (Kauf), die Bezeichnung (Bez) und der Typ (Standard, Entwickler-PC, Server, …) erfasst. Ein PC kann mehreren Angestellten zugeordnet sein, ein Angestellter nutzt zu einem Zeitpunkt maximal einen PC. Bei der Übernahme eines PC durch einen Angestellten wird die Art der Nutzung (Art; "Entwickler, Office-Nutzer, Superuser"), der Beginn (Beginn) und das Ende (Ende) festgehalten. Natürlich nutzt ein Angestellter im Zeitverlauf mehrere PC, diesbezüglich soll die gesamte Historie festgehalten werden.

(10) Für die Programmiersprachen, die von den Angestellten beherrscht werden, wird die Bezeichnung der Sprache (BezPS), die Bezeichnung des Compilers (BezComp) und der Preis (PreisLiz) für eine Lizenz festgehalten. Wegen der Bedeutung der Programmiererfahrung wird außerdem festgehalten, wieviel Jahre Programmierpraxis (ErfPS) jeder Angestellte in seinen Programmiersprachen hat. Es gibt auch Angestellte, die nicht programmieren und keine Programmiersprache beherrschen.

(11) Für die Entwickler unter den Angestellten wird die von ihnen genutzte Entwicklungsumgebung (EntwU) und ihre hauptsächlich genutzte Programmiersprache festgehalten (HauptPS). Für die Mitarbeiter des Gebäudeservices die Funktion (Funktion) und die Schicht (Schicht), in der sie arbeiten. Für das Top-Management der Bereich in dem sie tätig sind (Bereich) und das Entgeltmodell, nach dem sie ihr Gehalt bekommen (Entgelt).

3.9.2 Lösungsschritte

Punkt 1 deutet eine Relation zu Angestellten an. Der Schlüssel und zahlreiche weitere Attribute sind bereits angeführt:

Relationen festlegen

Angestellte (#PersNr, Name, VName, GebTag)

Mit ihnen kommen die Adressen und der Semantikaspekt, dass jeder Angestellte mehrere Adressen haben kann und unter einer Adresse mehrere Angestellte wohnen können. Hier legen wir schon mal die Adressrelation an, der weitergehende Semantikaspekt wird unten betrachtet. Wir ergänzen einen Schlüssel für die Adressen (AdrId).

Adressen (#AdrId, PLZ, Ort, AdrZ2, Strasse)

Der nächste Punkt gibt einen Hinweis auf das zu erfassende Vorgesetztenverhältnis. Dazu unten mehr. Dann die Projekte (3). Sie werden identifiziert und beschrieben, also können wir eine Relation anlegen :

Projekte (#Bez, TagEinr, Dauer, Budget)

Die Projektmitarbeit setzt Angestellte und Projekte in eine Beziehung. Sie wird deshalb unten modelliert.

Auch die Standorte (Punnkt 4) sind identifiziert und beschrieben, wobei die Klärung der Adressangaben unten erfolgt. Damit ergibt sich erstmal:

Standorte (#OrtId, Bez, AnzMitarb)

Die in (6) angesprochenen Abteilungen sind ebenso sofort als Relationen erkennbar. Es werden eine Bezeichnung und weitere beschreibende Attribute genannt. Für den Standort ergänzen wir ein Attribut Ort:

Abteilungen (#AbtBez, AbtLeiter, Ort)

Das Verhältnis Abteilung/Standort klären wir unten. Auch die nächsten beiden Punkte klären Beziehungsfragen und werden deshalb unten betrachtet.

Danach folgt in (9) die Beschreibung der PC. Beim Lesen dieses Punktes sollte man erkennen, dass hier Einzelgeräte erfasst werden. Diese werden wie folgt beschrieben:

PC (#InvNr, Kauf, Typ, Bez)

Die Zuordnung der PC ist wiederum eine Beziehungsfrage und wird unten umgesetzt.

Der vorletzte Punkt deutet an, dass Software in diesem Unternehmen eine große Rolle spielt. Die Programmiersprachen werden identifiziert und beschrieben, finden also in eine Relation:

PS (#BezPS, BezComp, PreisLiz)

Die Sache mit der Programmiererfahrung gehört wiederum in den nächsten Punkt.

Der letzte Punkt deutet eine Generalisierung/Spezialisierung an. Entwickler, Gebäudeservice und Manager haben als Spezialisierungen jeweils eigene Attribute, zusätzlich zu denen der Generalisierung (Angestellte). Damit ergeben sich folgende Relationen :

Generalisierung / Spezialisierung

Entwickler (#PersNr, EntwU, HauptPS)

TopMan (#PersNr, Bereich, Entgelt)

GebService (#PersNr, Funktion, Schicht)

Der Schlüssel ist, wie bei einer Generalisierung / Spezialisierung üblich, derjenige der Generalisierung.

Beziehungen klären

Beginnen wir bei der Präzisierung der Beziehungen wieder mit dem ersten Punkt der Anforderungsbeschreibung. Hier geht es um die Beziehung zwischen Angestellten und Adressen:

Angestellte / Adressen

Adressen (#AdrId, PLZ, Ort, AdrZ2, Strasse)

Angestellte (#PersNr, Name, VName, GebTag)

Die Semantik beschreibt eine n:m-Beziehung. Dies erfordert eine Verbindungsrelation AngAdr mit einem zusammengesetzten Schlüssel:

AngAdr (#(PersNr, AdrNr))

Die Kardinalität ist n:m. Die Min-/Max-Angaben sind 1,n : 1,m, wenn man die Adressangabe zu einer Pflichtangabe macht (d.h., in der Datenbank gibt es keinen Angestellten ohne Adresse und keine Adresse ohne Angestellten). Denkbar wären aber auch 0,n : 0,m und andere Kombinationen (vgl. Abbildung).

Abbildung 3.9-1: N:m-Beziehung mit AngAdr und alternativen Min-/Max-Angaben.

Im zweiten Punkt ist gefordert, dass das Vorgesetztenverhältnis zwischen den Angestellten erfasst wird. Dies ist eine rekursive Beziehung (vgl. auch [Staud 2021, Abschnitt 14.3]), die in der relationalen Modellierung durch eine weitere Relation Vorgesetzte gelöst werden muss:

Vorgesetzte

Vorgesetzte (#(PersNrV, PersNrU))

Angestellte (#PersNr, Name, VName, GebTag)

Damit steht in jedem Tupel von Vorgesetzte an erster Stelle die Personalnummer des Vorgesetzten, an zweiter Stelle die einer untergebenen Person. Beide Attribute sind Fremdschlüssel bzgl. Angestellte.PersNr. Jedes Tupel hält somit ein Vorgesetztenverhältnis fest. In dieser Relation können auch Hierarchien abgebildet werden. Dies ist eine schlichte Lösung des Problems, mehr an Semantik muss in die Anwendungsprogrammierung.

Erinnerung: Angestellte.PersNr bedeutet: Attribut PersNr der Relation Angestellte.

Die nächste zu klärende Beziehung betrifft die zwischen Projekten und Standorten (Punkt 3). Da ein Projekt auf mehrere Standorte verteilt sein kann und da – wie wir auf Nachfrage erfuhren [Anmerkung] – an einem Standort mehrere Projekte angesiedelt sein können, liegt hier eine n:m-Beziehung zwischen Projekten und Standorten vor. Hier die Lösung, ergänzt um die beiden verknüpften Relationen:

Projekte / Standorte

ProjOrte (#(BezProj, OrtId))

Projekte (#Bez, TagEinr, Dauer, Budget)

Standorte (#OrtId, Bez, AnzMitarb)

Die Min-/Max-Angaben ergeben sich zu 1,n : 1,m, wenn wir festlegen, dass jedes Projekt ab Einrichtung mindestens einen Standort haben muss und ein Standort erst in die Datenbank aufgenommen wird, wenn mindestens 1 Projekt dort angesiedelt ist.

Auch die Projektmitarbeit (Punkt (5)) hat die Struktur einer n:m-Beziehung. Ein Angestellter kann in mehreren Projekten mitarbeiten, ein Projekt kann mehrere zugeordnete Angestellte haben. Mit den verknüpften Relationen ergibt sich:

Projekt-mitarbeit

ProjMitarb (#PersNr, BezProj))

Angestellte (#PersNr, Name, VName, GebTag)

Projekte (#Bez, TagEinr, Dauer, Budget)

Was die Min-/Max-Angaben angeht, können wir davon ausgehen, dass sicherlich nicht alle Angestellten in Projekten tätig sind. Außerdem sei es so, dass ein Projekt datenbanktechnisch schon eingerichtet sein kann, bevor ihm Personal zugewiesen wurde. Damit ergeben sich die Min-/Max-Angaben 0,n : 0,m.

Als nächster Beziehungsaspekt werden in Punkt (6) die Abteilungsstandorte angeführt. So wie es gefordert ist, stellt es eine 1:n-Beziehung dar (Standorte/Abteilungen). Da eine Abteilung nicht ohne Standort existieren kann, wird das Attribut OrtId zu einem Fremdschlüssel in Abteilungen. Wir nehmen an, dass es Standorte auch geben kann, ohne dass dort eine Abteilung angesiedelt ist (weil dort z.B. nur Projekte sind). Dies erfordert die Min-/Max-Angaben 1,n : 0,n. Zusammen mit der beteiligten Relation ergibt sich damit:

Abteilungen / Standorte

Abteilungen (#AbtBez, AbtLeiter, OrtId)

Standorte (#OrtId, Bez, AnzMitarb)

Punkt (7) spricht die Abteilungszugehörigkeit an. Nach der Beschreibung ist dies eine 1:n-Beziehung, die durch einen Fremdschlüssel AbtBez in Angestellte modelliert werden könnte. Hier ist aber zusätzlich verlangt, dass die zeitliche Zugehörigkeit ebenfalls erfasst wird mit Anfang (BeginnZ) und Ende (EndeZ) der Zugehörigkeit. Damit ist ein Zeitaspekt zu modellieren: die Zeitabschnitte der Abteilungszugehörigkeit. Da es durchaus vorkommen kann, dass jemand eine Abteilung verlässt und später wieder in sie zurückkommt (vielleicht sogar mehrfach), liegt hier eine n:m-Beziehung mit zeitlicher Dimension zwischen Abteilungen und Angestellten vor.

Abteilungs-zugehörigkeit

Da ein Angestellter zu jedem Zeitpunkt einer Abteilung angehören sollte (extreme Sonderfälle sollen mal nicht betrachtet werden), und da eine Abteilung erst eingerichtet wird, wenn zumindest die Abteilungsleiterin feststeht (so soll es hier sein), sind die Min-/Max-Angaben für die Richtung Angestellte/Abteilungen 1,n : 1,m.

Dafür richten wir eine Relation AngAbtZug (Angestellen/Abteilung/Zugehörigkeit) ein, in die neben PersNr und AbtBez auch BeginnZ und EndeZ rein müssen.

Mit der Aufnahme von Beginn und Ende der Zugehörigkeit, können die unterschiedlichen Phasen erfasst werden. Z.B. kann eine Angestellte vom 1.1.2020 bis zum 20.6.2023 und vom 4.5.2021 bis zur Gegenwart in einer bestimmten Abteilung gewesen sein. Um Eindeutigkeit zu erreichen, muss ein Zeitpunkt in den Schlüssel. Wir nehmen hier BeginnZ.

Die zeitliche Dimension führt im Fall von Zeiträumen dazu, dass gegen die „reine“ relationale Lehre verstoßen werden muss. Denn dabei entsteht ein Attribut (hier: EndeZ), das semantikbedingt leere Einträge hat (bis zum Ende des Zeitraums, hier: der Zugehörigkeit) und dies sollte in relationalen Datenbanken nicht sein. Eine eigene Relation für EndeZ wäre möglich, darauf wird aber aus pragmatischen Gründen i.d.R. verzichtet.

Zeitliche Dimension

Der Schlüssel enthält zum einen PersNr und AbtBez, muss zum anderen um BeginnZ erweitert werden. Insgesamt wird diese Beziehung dann durch folgende Relationen beschrieben:

AngAbtZug (#(PersNr, AbtBez, BeginnZ), EndeZ)

Abteilungen (#AbtBez, AbtLeiter, OrtId)

Angestellte (#PersNr, Name, VName, GebTag)

In Punkt (8) wird gefordert, dass auch die Funktionen, die Angestellte in Abteilungen übernehmen, in der Datenbank erfasst werden. Basis ist wieder die 1:n-Beziehung zwischen Angestellten und Abteilungen. Hier muss sie ergänzt werden um die Attribute der Funktionsbeschreibung: BezFu, BeginnF, EndeF. Da auch hier ein wiederholtes Beenden und Wiederaufnehmen möglich ist und zu einem Zeitpunkt nur eine einzige Funktion übernommen wird, ist die folgende Relation AngAbtFu korrekt.

Zur Wertigkeit liegen keine Angaben vor. Wir nehmen daher an, dass eine Angestellte in einer Abteilung in einem Zeitraum nur jeweils eine Funktion übernimmt und dass eine Abteilung keine, eine oder mehrere Funktionen zu vergeben hat. Damit ergibt sich die Kardinalität n:m und die Min-/Max-Angaben 0,1 : 0,m.

AngAbtFu (#(PersNr, AbtBez, BeginnF), EndeF, BezFu))

Die Funktionsübernahme kann damit vollständig in die Relation AngAbtFu aufgenommen werden. Der Schlüssel muss BeginnF enthalten (möglich wäre auch EndeF), dadurch sind auch mehrere zeitlich verschobene Funktionsübernahmen möglich.

Die Struktur wäre durch leichte semantische Änderungen eine andere, z.B. wenn mehr als eine Funktion in einem Zeitraum übernommen werden könnte.

Punkt (9) klärt die Zuordnung von PC zu Angestellten. In der Beschreibung wird eine 1:n-Beziehung deutlich, was normalerweise einfach zu einem Fremdschlüssel führt. Hier ist aber wieder für diese PC-Nutzung Beginn, Ende und Art der Nutzung zu erfassen und dies so, dass auch mehrere Nutzungsphasen modelliert werden können.

PC und Angestellte

Wir müssen also die einfache Relation

PC-Nutzung (#(PersNr, InvPC))

oder

PC-Nutzung(#InvPC, PersNr)

(wenn eine Person nur einen PC hat) ergänzen. Zum einen machen wir PersNr und Beginn gemeinsam zum Schlüssel. Damit erfasst diese Relation nicht mehr nur Personen, sondern Zeiträume. Hinzu muss auch Ende zur Beschreibung des Zeitraums und Art für die Nutzung sowie InvPC als Fremdschlüssel, damit festgehalten wird, um welchen PC es sich handelt.

Die Min-/Max-Angaben ergeben sich (von PC zu Angestellte) zu 0,n : 0,1, wenn PC auch erfasst werden sollen, bevor sie zugewiesen sind und man die Möglichkeit bestehen lassen will, dass es Angestellte (in der Datenbank) gibt, die noch keinen PC zugewiesen bekommen haben.

Zusammen mit den verknüpften Relationen ergibt sich dann:

AngPC (#(PersNr, Beginn), InvNrPC, Art, Ende)

PC (#InvNr, Kauf, Typ, Bez)

Angestellte (#PersNr, Name, VName, GebTag)

Bei den Programmiersprachen zielt die weitere Beschreibung in Punkt 10 auf die Erfassung der Programmiererfahrung. Es soll also ganz grundsätzlich die Beziehung zwischen Angestellten und Programmiersprachen festgehalten werden („wer kann in Java programmieren?“) und die Anzahl der Erfahrungsjahre.

Durch die Mehrzahl bei Programmiersprachen ist die die Kardinalität n:m. Die Min-/Max-Angaben sind 0,n : 0,m, da ja Angestellte dabei sind, die nicht programmieren und wir auch Programmiersprachen in der Datenbank erfassen wollen, die zwar angeschafft wurden, aber noch nicht eingesetzt werden.

Dies erfordert wieder eine eigene Relation AngPS für diese Beziehung zwischen PS und Angestellte.

AngPS (#(BezPS, PersNr))

PS (#BezPS, BezComp, PreisLiz)

Angestellte (#PersNr, Name, VName, GebTag)

Sehr oft gibt es in Anforderungsbeschreibungen nur indirekte Hinweise auf Beziehungen. Ein Beispiel ist hier die Beziehung zwischen Abteilungen und Abteilungsleitern. Nehmen wir folgendes an:

Vergessene Anforderungen

• Eine Angestellte kann keine, eine oder in Ausnahmefällen auch mal mehr Abteilungen leiten.
• Eine Abteilung wird immer genau von einem Angestellten geleitet und auch erst eingerichtet, wenn ein solcher ernannt ist.

Damit ist die Kardinalität (Angestellte/Abteilungen) 0:n und Abteilung.AbtLeiter wird zum Fremdschlüssel. Die Min-/Max-Angaben sind 0,m : 1,1.

Abteilungen (#AbtBez, AbtLeiter, OrtId)

Restliche Prüfung

Dadurch, dass bei der Bildung der Relationen auf die Einhaltung der Struktur „ein Schlüssel und nur davon abhängige Attribute“ geachtet wurde, war die höchste Normalform gesichert. Das führte auch zu den Lösungen rund um die Muster, z.B. indem Spezialisierungen in eigene Relationen mit dem Schlüssel der Generalisierung kommen. Auch Verstöße gegen die 4NF und 5NF liegen hier nicht vor.

Gegen die Grundlagen der relationalen Theorie verstoßen die Attribute, die erstmal keine Werte aufweisen können („Ende Zeitraum“), weil ihre Werte erst später anfallen. Streng nach der reinen Lehre wären hier eigene Relationen nötig.

3.9.3 Lösung

Insgesamt gehören zum Datenmodell nun folgende Relationen.

Textliche Fassung

Abteilungen (#AbtBez, AbtLeiter, OrtId)

Adressen (#AdrId, PLZ, Ort, AdrZ2, Strasse)

AngAbtFu (#(PersNr, AbtBez, BeginnF), EndeF, BezFu))

AngAbtZug (#(PersNr, AbtBez, BeginnZ), EndeZ)

AngAdr (#(PersNr, AdrNr))

Angestellte (#PersNr, Name, VName, GebTag)

AngPC (#(PersNr, Beginn), InvNrPC, Art, Ende))

AngPS (#(PersNr, BezPS), ErfPS)

Entwickler (#PersNr, EntwU, HauptPS)

GebService (#PersNr, Funktion, Schicht)

PC (#InvNr, Kauf, Typ, Bez)

Projekte (#Bez, TagEinr, Dauer, Budget)

ProjMitarb (#PersNr, BezProj))

ProjOrte (#(BezProj, OrtId))

PS (#BezPS, BezComp, PreisLiz)

Standorte (#OrtId, Bez, AnzMitarb, AdrId)

TopMan (#PersNr, Bereich, Entgelt)

Vorgesetzte (#(PersNrV, PersNrU))

Grafische Fassung

Abbildung 3.9-2: Relationales Datenmodell zum Anwendungsbereich Angestellte

3.10 Sprachenverlag

Diese Aufgabe gehört mit 15 Relationen, zahlreichen Modellmerkmalen und Mustern zu den ausführlichen.

3.10.1 Anforderungsbeschreibung

Es geht um die Produkte eines Verlages, der Wörterbücher (z.B. von Deutsch nach Englisch), digital oder auch gedruckt, herstellt und verkauft und der seit einiger Zeit auch Übersetzungsprogramme anbietet. Seine Produkte sollen in einer Datenbank verwaltet werden. Zu erfassen sind die nachfolgend angeführten Sachverhalte:

(1) Alle Produkte, d.h. alle Wörterbücher und Volltextübersetzer (Programm zur automatischen Übersetzung von Text) mit ihrer Produktnummer (ProdNr) und Bezeichnung (Bez), mit ihrem Listenpreis (LPreis) und den Sprachen, die abgedeckt sind (z.B. deutsch nach englisch und englisch nach deutsch, deutsch nach französisch und französisch nach deutsch).

(2) Für jedes gedruckte Wörterbuch wird auch festgehalten, wieviele Einträge es hat (Einträge), für welche Zielgruppe es gedacht ist (Schüler, Studierende, "Anwender", "Profi-Anwender", Übersetzer) (Zielgruppe), wann es auf den Markt gebracht wurde (ErschDat), wieviele Seiten es hat (AnzSeit).

(3) Für jedes digitale Wörterbuch wird auch festgehalten, wann es auf den Markt gebracht wurde (ErschDat), welche Speichertechnik (SpeichTech) bei ihm verwendet wurde, wieviele Einträge es umfasst (Einträge) und für welche Zielgruppe es gedacht ist (Schüler, Studierende, "Anwender", "Profi-Anwender", Übersetzer) (Zielgruppe).

(4) Die digitalen Produkte des Verlags beruhen jeweils auf einem Übersetzungsprogramm (BezProg). Es kann sein, dass eines mit verschiedenen Programmen angeboten wird (z.B. zielgruppenspezifisch). Natürlich dient ein Programm u.U. mehreren digitalen Produkten. Für diese Programme wird festgehalten, welche Dokumentarten (DokArt) sie auswerten können (Word, PDF, Bildformate, usw.; mehrere) und ob es möglich ist, die Programmleistung in Textprogramme zu integrieren (IBK: Integrierbarkeit).

(5) Für jeden Volltextübersetzer wird auch festgehalten, welche Sprachen abgedeckt sind, wieviele Einträge das Systemlexikon hat (Einträge), für welche Zielgruppe das Produkt gedacht ist und wann es auf den Markt gebracht wurde (ErschDatum). Festgehalten wird außerdem, ob man den Käufern anbietet, es durch Internetzugriffe regelmäßig aktualisieren zu lassen. Falls ja, wie lange dies möglich ist (AktJahre), z.B. 5 Jahre ab Kauf.

(6) Für alle Programme werden außerdem die Softwarehäuser, die an der Erstellung mitgearbeitet haben, mit ihrer Anschrift (nur die der Zentrale) festgehalten. Es wird auch die zentrale E-Mail-Adresse erfasst. Es kommt durchaus vor, dass ein Programm in Kooperation von mehreren Softwarehäusern erstellt wird. Natürlich bietet ein bestimmtes Softwarehaus u.U. mehrere Programme an, z.B. für verschiedene Sprachen. Es wird bzgl. eines jeden Programms der Beginn und das Ende der Zusammenarbeit vermerkt.

(7) Für alle digitalen Produkte werden außerdem die Systemvoraussetzungen festgehalten, abhängig vom eingesetzten Programm. Welche minimale Hardwareanforderung gegeben ist (anhand des Prozessors, Proz), wieviel Arbeitsspeicher sie benötigen (ArbSp), wieviel freier Plattenspeicher (PlattSp) nötig ist (in MB) und welche Betriebssystemversion (BS) genutzt werden kann (Windows Vista, 7, 8; LINUX). Dies sind in der Regel mehrere.

(8) Erfasst werden auch die konkreten Geräte, auf denen die digitalen Produkte lauffähig sind mit ihrer Bezeichnung (Bez) und dem Gerätetyp (Typ; Smartphone, Pad, Tablet, Laptop, usw.). Auf einem Gerät sind natürlich mehrere digitale Produkte lauffähig, dagegen werden die digitalen Produkte am Ende ihrer Entwicklung auf genau ein Gerät zugeschnitten. Besteht das jeweilige Gerät nicht mehr, wird auch das zugehörige digitale Produkt überflüssig.

(9) Die Entwicklung der Programme findet so statt, dass jedes Programm mit unterschiedlichen grafischen Bedienoberflächen (GUI; graphical user interface) kombiniert werden kann. Für die GUIs wird ein Schlüssel (GUIId), der Typ (Fenster, Kacheln, ...) und die Programmiersprache (PS), mit der sie entwickelt wurde, festgehalten. Ein konkretes vom jeweiligen Softwarehaus angebotenes Programm enthält dann genau eine GUI, d.h. die Programme sind nach ihren GUIs differenziert.

3.10.2 Lösungsschritte

Hier nun die schrittweise Umsetzung des Textes in ein relationales Datenmodell. Sie erfolgt, indem die Anforderungen nacheinander Absatz für Absatz bearbeitet werden.

Anforderung Teil 1

Alle Produkte, d.h. alle Wörterbücher und Volltextübersetzer (Programm zur automatischen Übersetzung von Text) mit ihrer Produktnummer (ProdNr) und Bezeichnung (Bez), mit ihrem Listenpreis (LPreis) und den Sprachen, die abgedeckt sind (z.B. deutsch nach englisch und englisch nach deutsch, deutsch nach französisch und französisch nach deutsch).

Dem Text kann entnommen werden, dass es Produkte gibt und dass diese (erstmal) aus Wörterbüchern und Volltextübersetzern bestehen. Nennen wir sie auch Produkte und geben ihnen den Schlüssel ProdNr. Außerdem wird auf die abgedeckten Sprachen hingewiesen. Da dies immer zwei sind, legen wir zwei Attribute Sprache1 und Sprache2 an. Z.B. also mit den Einträgen Italienisch und Deutsch.

Produkte (#ProdNr, Bez, LPreis, Sprache1, Sprache2)

Anforderung Teil 2

Für jedes gedruckte Wörterbuch wird auch festgehalten, wieviele Einträge es hat (Einträge), für welche Zielgruppe es gedacht ist (Schüler, Studierende, "Anwender", "Profi-Anwender", Übersetzer) (Zielgruppe), wann es auf den Markt gebracht wurde (ErschDat), wieviele Seiten es hat (AnzSeit).

Das Wort "auch" macht deutlich, dass es sich um eine Variante handelt, die evtl. zusätzliche Attribute hat. Dies ist hier auch der Fall, so dass eine Spezialisierung für gedruckte Wörterbücher eingerichtet werden muss. Sie wird WBGedr genannt und hat (erstmal) die folgenden Attribute.

WBGedr (#ProdNr, Einträge, Zielgruppe, ErschDat, AnzSeiten)

Anforderung 3

Für jedes digitale Wörterbuch wird auch festgehalten, wann es auf den Markt gebracht wurde (ErschDat), welche Speichertechnik (SpeichTech) bei ihm verwendet wurde, wieviele Einträge es umfasst (Einträge) und für welche Zielgruppe es gedacht ist (Schüler, Studierende, "Anwender", "Profi-Anwender", Übersetzer) (Zielgruppe).

Generalisierung / Spezialisierung

Wieder taucht in der Anforderungsformulierung das Wort "auch" auf. Die neue Produktvariante hat dann auch eine Spezialisierung: Digitale Wörterbücher. Diese Relation wird WBDig genannt:

WBDig (#ProdNr, Einträge, Zielgruppe, ErschDat, SpeichTech)

Da in WBDig zum Teil dieselben Attribute wie in WBGedr vorliegen, kann eine Generalisierung dieser beiden Relationen mit Einträge, ErschDatum und Zielgruppe gebildet werden. Dieses Muster Gen/Spez muss man nun erkennen, z.B. anhand der Semantik ("Ähnlichkeit") oder der identischen Attribute. Die Bereinigung ergibt eine Relation für Wörterbücher und je eine "abgeschlankte" für die digitalen und gedruckten Wörterbücher.

Damit entstehen folgende neue bzw. veränderte Relationen:

WB (#ProdNr, Einträge, Zielgruppe, ErschDat)

WBDig (#ProdNr, SpeichTech)

WBGedr (#ProdNr, AnzSeiten)

WB ist Spezialisierung von Produkte, WBDig und WBGedr sind Spezialisierungen von WB. Von der Generalisierung ausgehend ist die Kardinalität 1:1 und die Min-/Max-Angaben sind 0,1 : 1,1.

Will man eine nicht simple Gen/Spez-Struktur durchdringen, lohnt sich die Anlage einer Tabelle mit den Attributen der beteiligten Relationen, wie es die folgenden Abbildungen zeigen. In der Kopfzeile sind die einzelnen Produkte angesiedelt, darunter zeilenweise die Attribute. Die obersten Zeilen geben die Attribute an, die alle Produkte haben, darunter dann die für die einzelnen Spezialisierungen.

Schon diese Tabelle zeigt die Gen/Spez-Struktur auf. Noch übersichtlicher wird es, wenn man in jeder Spalte die Attribute weg lässt, die in der übergeordneten Generalisierung enthalten sind:

Hier ist jetzt der Spezialisierungszusammenhang klar erkennbar. WBDig „erbt“, wie es in der objektorientierten Programmierung genannt wird, die Attribute von WB und von Produkte.

Anforderung Teil 4

Die digitalen Produkte des Verlags beruhen jeweils auf einem Übersetzungsprogramm (BezProg). Es kann sein, dass eines mit verschiedenen Programmen angeboten wird (z.B. zielgruppenspezifisch). Natürlich dient ein Programm u.U. mehreren digitalen Produkten. Für diese Programme wird festgehalten, welche Dokumentarten (DokArt) sie auswerten können (Word, PDF, Bildformate, usw.; mehrere) und ob es möglich ist, die Programmleistung in Textprogramme zu integrieren (IBK: Integrierbarkeit).

Digitale Produkte

Anforderung 4 beschreibt die digitalen Produkte näher. Der erste Teil legt außerdem auch eine n:m-Beziehung zwischen Produkten und Programmen fest, so dass sich die Relation ProdDig ergibt. Die Programme werden durch die beiden Attribute DokArt und IBK datenbanktechnisch existent, wegen der n:m-Beziehung zwischen Programmen und Dokumentart sogar in zwei Relationen.

Damit kommen folgende Relationen dazu:

Programme (#BezProg, IBK)

ProgDokArt (#(BezProg, DokArt))

ProdDig (#(ProdNr, BezProg))

Die Kardinalitäten und Min-/Max-Angaben sind wie folgt:

• Von Produkte zu ProdDig: 1:n bzw. 0,n : 1,1
• Von Programme zu ProdDig: 1:n bzw. 0,n : 1,1, da wir davon ausgehen, dass es auch (datenbanktechnisch) Programme geben kann, die noch nicht in einem digitalen Produkt verarbeitet sind.
• Von Programme zu ProgDokArt: 1:n bzw. 0,1 : 1,n.

Anforderung Teil 5

Für jeden Volltextübersetzer wird auch festgehalten, welche Sprachen abgedeckt sind, wieviele Einträge das Systemlexikon hat (Einträge), für welche Zielgruppe das Produkt gedacht ist und wann es auf den Markt gebracht wurde (ErschDatum). Festgehalten wird außerdem, ob man den Käufern anbietet, es durch Internetzugriffe regelmäßig aktualisieren zu lassen. Falls ja, wie lange dies möglich ist (AktJahre), z.B. 5 Jahre ab Kauf.

3.10.3 Lösung durch Umbenennung

Die Beschreibung der Produkte geht damit weiter und die Volltextübersetzer (VTÜ) werden als Relation eingeführt. Die hier genannten Attribute der Volltextübersetzer sind aber bis auf eines in WB enthalten. Deshalb ändern wir den Namen von WB in WB+VTÜ (Wörterbücher und Volltextübersetzer). Dies ist eine pragmatische aber angemessene Lösung, denn normalerweise gibt es keine zwei Relationen mit identischem Schlüssel. Für die Volltextübersetzer mit Aktualisierungsmöglichkeit wird eine neue Relation VTÜAkt angelegt:

WB+VTÜ (#ProdNr, Einträge, Zielgruppe, ErschDat)

VTÜAkt (#ProdNr, AktJahre)

Auch die Gen/Spez-Tabelle ändert sich damit (die bei den anderen Produkten vorkommenden Attribute wurden gleich weggelassen):

Um nicht den Überblick zu verlieren und um die Gen/Spez-Struktur ganz deutlich zu machen, hier die an diesem Fragment beteiligten Relationen, textlich und grafisch.

Produkte (#ProdNr, Bez, Lpreis, Sprache1, Sprache2)

VTÜAkt (#ProdNr, AktJahre)

WB+VTÜ (#ProdNr, Einträge, Zielgruppe, ErschDat)

WBDig (#ProdNr, SpeichTech)

WBGedr (#ProdNr, AnzSeiten)

Die Kardinalitäten und Min-/Max-Angaben sind damit jetzt wie folgt:

• Von WB+VTÜ zu WBGedr: 1:1 bzw. 0,1 : 1,1
• Von WB+VTÜ zu WBDig: 1,1 bzw. 0,1 : 1,1
• Von WB+VTÜ zu VTÜAkt: 1,1 bzw. 0,1 : 1,1
• Von Produkte zu WB+VTÜ: 1,1 bzw. 0,1 : 1,1. Wir lassen also datenbanktechnisch Produkte zu, die weder Wörterbücher (WB) noch Volltextübersetzer (VTÜ) sind.

Abbildung 3.10-1: Generalisierung / Spezialisierung rund um Produkte

Anforderung Teil 6

Für alle Programme werden außerdem die Softwarehäuser, die an der Erstellung mitgearbeitet haben, mit ihrer Anschrift (nur die Zentrale) festgehalten. Es wird auch die zentrale E-Mail-Adresse erfasst. Es kommt durchaus vor, dass ein Programm in Kooperation von mehreren Softwarehäusern erstellt wird. Natürlich bietet ein bestimmtes Softwarehaus u.U. mehrere Programme an, z.B. für verschiedene Sprachen. Es wird bzgl. eines jeden Programms der Beginn und das Ende der Zusammenarbeit vermerkt.

Hier werden nun die Softwarehäuser zu Datenbankobjekten. Da für sie gleich auch noch Attribute vorliegen, kann eine Relation angelegt werden. Außerdem auch für die Beziehung zwischen den Softwarehäusern und den Programmen. Diese ist vom Typ n:m und hat eine Zeitkomponente (Zeitabschnitte). Es genügt, den Beginn der Zusammenarbeit in den Schlüssel aufzunehmen, damit können mehrere solche Phasen unterschieden werden.

Zeitaspekt in Beziehung

Daraus folgen weitere Relationen:

SWHäuser (#SWHNr, PLZ, Ort, Straße, eMail)

SWHProg (#(SWHNr, BezProg, Beginn), Ende)

Programme (#BezProg, IBK)

Die Kardinalitäten und Min-/Max-Angaben sind wie folgt:

• Von Programme über SWHProg zu SWHäuser: n:m bzw. 1,n : 1,m

Anforderung Teil 7

Für alle digitalen Produkte werden außerdem die Systemvoraussetzungen festgehalten, abhängig vom eingesetzten Programm. Welche minimale Hardwareanforderung gegeben ist (anhand des Prozessors, Proz), wieviel Arbeitsspeicher sie benötigen (ArbSp), wieviel freier Plattenspeicher (PlattSp) nötig ist (in MB) und welche Betriebssystemversion (BS) genutzt werden kann (Windows 7, 8, 10, 11; LINUX). Dies sind in der Regel mehrere.

Zuerst scheint der Text eine Erweiterung der Beschreibung der digitalen Produkte zu enthalten. Die Formulierung "abhängig vom eingesetzten Programm" zeigt aber, dass Objekte gemeint sind, die durch die Kombination aus Produkt und Programm identifiziert sind. Deshalb wird die Relation ProdDig hier um die drei Attribute Proz, ArbSp und PlattSp ergänzt.

Bleiben noch die Betriebssysteme. Da u.U. mehrere Betriebssysteme für ein digitales Produkt tauglich sind, muss eine Relation erstellt werden, die das Attribut BS mit im Schlüssel hat: ProdDigBS. Dadurch kommt es zu einer eher seltenen Konstellation: einem Fremdschlüssel, der aus zwei Attributen besteht. ProdDig hat den Schlüssel #(ProdNr, BezProg), ProdDigBS den Fremdschlüssel (ProdNr, BezProg).

Zusammen mit Programme liegen dann folgende geänderten und neuen Relationen vor:

ProdDig (#(ProdNr, BezProg), Proz, ArbSp, PlattSp)

ProdDigBS (#((ProdNr, BezProg), BS) //innere Klammer nur wegen derAnschaulichkeit

Programme (#BezProg, IBK)

Die Kardinalitäten und Min-/Max-Angaben sind wie folgt:

• Von ProdDig zu ProdDigBS: 1:n bzw. 1,n : 1,m

Anforderung Teil 8

Erfasst werden auch die konkreten Geräte, auf denen die digitalen Produkte lauffähig sind mit ihrer Bezeichnung (Bez) und dem Gerätetyp (Typ; Smartphone, Pad, Tablett, Laptop, usw.). Auf einem Gerät sind natürlich mehrere digitale Produkte lauffähig, dagegen werden die digitalen Produkte am Ende ihrer Entwicklung auf genau ein Gerät zugeschnitten. Besteht das jeweilige Gerät nicht mehr, wird auch das zugehörige digitale Produkt überflüssig.

Damit ergibt sich eine Relation zu Geräten. Außerdem kann die Gerätebezeichnung als Teilschlüssel in den Schlüssel von ProdDig aufgenommen werden, denn ein Gerät ist auf mehreren digitalen Produkten lauffähig. Dies führt zu neuen bzw. veränderten Relationen:

Geräte (#Bez, Typ)

ProdDig (#(ProdNr, BezProg, BezGerät), Proz, ArbSp, PlattSp)

Ist das wirklich korrekt? Bei näherem Hinsehen entsteht ein leichtes Unbehagen. Wird nicht Proz, ArbSp und PlattSp alleine durch ProdNr und BezProg bestimmt? Was tut dann, diesbezüglich, BezGerät im Schlüssel. Würden die drei beschreibenden Geräte auch durch das jeweilige Gerät mit bestimmt, wäre das in Ordnung. Nach der Beschreibung ist dies aber nicht anzunehmen. Der Bedarf an Hardwarekapazitäten wird wohl geräteunabhängig bestimmt. Um ein solches Unbehagen zu beseitigen, ist ein FA-Diagramm gut geeignet:

Unbehagen

Abbildung 3.10-2: FA-Diagramm der Relation ProdDig_1NF

Das macht die Problematik klar. Die Relation ist nicht mal in 2NF. Deshalb muss normalisiert werden. Es entstehen die folgenden Relationen (als FA-Diagramme).

Abbildung 3.10-3: FA-Diagramm der Relationen ProdProgGer_5NF und ProdDig_5NF

Damit ergibt sich eine veränderte Relation ProdDig (die der "vorletzten" Fassung entspricht) und eine neue Relation zu der Beziehung von Produkten, Programmen und Geräten. Sie hält fest, in welcher konkreten Konstellation die drei Komponenten zusammengefügt werden können:

ProdDig (#(ProdNr, BezProg), Proz, ArbSp, PlattSp)

ProdProgGer (#(ProdNr, BezProg, BezGerät))

Es soll an dieser Stelle nicht verschwiegen werden, dass ProdProgGer in der Praxis ein Kandidat für die Einführung eines Schlüssels wäre, der in seiner Zusammensetzung die jeweils konkrete Konstellation ausdrückt, z.B. PPGId (ProduktProgrammGerätId). Dann würden die drei Attribute a) zu einem Sekundärschlüssel und b) zu beschreibenden Attributen:

Konstruierter Schlüssel.

ProdProgGer-Alternative (#PPGId, (ProdNr, BezProg, BezGerät))

Wir belassen es hier aber bei der obigen Lösung, so dass sich folgende Relationen ergeben:

Geräte (#Bez, Typ)

ProdDig (#(ProdNr, BezProg), Proz, ArbSp, PlattSp)

ProdProgGer (#(ProdNr, BezProg, BezGerät))

Betrachten wir noch die Kardinalitäten und Min-/Max-Angaben:

• Für Produkte – ProdProgGer – Geräte ergibt sich die Kardinalität n:m und die Min-/Max-Angaben 1,n : 1,n, wenn wir festlegen, dass nur Produkte bzw. Geräte datenbankmäßig erfasst werden, die auch zum Einsatz kommen.

Anforderung Teil 9

Die Entwicklung der Programme findet so statt, dass jedes Programm mit unterschiedlichen grafischen Bedienoberflächen (GUI; graphical user interface) kombiniert werden kann. Für die GUIs wird ein Schlüssel (GUIId), der Typ (Fenster, Kacheln, ...) und die Programmiersprache (PS), mit der sie entwickelt wurde, festgehalten. Ein konkretes vom jeweiligen Softwarehaus angebotenes Programm enthält dann genau eine GUI, d.h. die Programme sind nach ihren grafischen Bedienoberflächen differenziert.

Nun wird die Einbindung der grafischen Bedienoberflächen (Graphical User Interface, GUI) in das Datenmodell geklärt. Sie werden durch Identifikation und Beschreibung datenbanktechnisch existent in der Relation GUI. Dem Text kann außerdem entnommen werden, dass ein bestimmtes Programm genau eine ganz bestimmte GUI hat, so dass hier eine 1:n-Beziehung vorliegt. Entsprechend wird der Schlüssel von GUI in Programme als Fremdschlüssel eingefügt:

GUI (#GUIId, Typ, PS)

Programme (#BezProg, IBK, GUIId)

3.10.4 Lösungen

Textliche Fassung

Geräte (#Bez, Typ)

GUI (#GUIId, Typ, PS)

Programme (#BezProg, IBK, GUIId)

ProdDig (#(ProdNr, BezProg), Proz, ArbSp, PlattSp)

ProdDigBS (#((ProdNr, BezProg), BS)

ProdProgGer (#(ProdNr, BezProg, BezGerät))

Produkte (#ProdNr, Bez, LPreis, Sprache1, Sprache2)

ProgDokArt (#(BezProg, DokArt))

SWHäuser (#SWHNr, PLZ, Ort, Straße, eMail)

SWHProg (#(SWHNr, BezProg, Beginn), Ende)

VTÜAkt (#ProdNr, AktJahre)

WB+VTÜ (#ProdNr, Einträge, Zielgruppe, ErschDat)

WBDig (#ProdNr, SpeichTech)

WBGedr (#ProdNr, AnzSeiten)

Grafische Fassung

Abbildung 3.10-4: Relationales Datenmodell Sprachenverlag

Abkürzungen für Attribute:

AktJahr: Zahl der Jahre, in denen das Programm aktualisiert wird

ArbSp: Arbeitsspeicher

BS: Bezeichnung Betriebssystemversion

ErschDatum: Erscheinungsdatum

Geräte.Bez: Bezeichnung des Geräts

Geräte.Typ: Gerätetyp

GUI.Typ: Typ der grafischen Bedienoberfläche

GUIId: Schlüssel für die grafische Bedienoberfläche

LPreis: Listenpreis

PlattSp: Speichergröße der Festplatte

ProdDig.BezProg: Bezeichnung des Übersetzungsprogramms

ProdNr : Produktnummer

Produkte.Bez: Bezeichnung Produkt

Proz: Bezeichnung des Prozessors bei digitalen Produkten

PS: Programmiersprache, mit der die GUI entwickelt wurde

SWHProg.Beginn: Beginn der Zusammenarbeit

SWHProg.Ende: Ende der Zusammenarbeit

WBVTÜ. Einträge: Zahl der Einträge in gedruckten Wörterbüchern und Volltextübersetzern

Zielgruppe: anvisierte Kundengruppe

Abkürzungen für Relationen:

Geräte: Geräte, auf denen das digitale Produkt einsetzbar ist

GUI: grafische Bedienoberfläche

ProdDig: digitale Produkte

ProdDigBS: digitale Produkte in Kombination mit Betriebssystemen

ProdProgGer: Kombination Produkte – Programme – Geräte

Produkte: die vom Sprachenverlag hergestellten Produkte

ProgDokArt: Dokumentarten, die von den Programmen ausgewertet werden können

Programme: die eingesetzten Programme

SWHäuser: Softwarehäuser, die mit dem Sprachenverlag zusammenarbeiten

SWHProg: Kombination Softwarehäuser und Programme

VTÜAkt: Angabe zur Aktualisierung bei Volltextübersetzern

WB+VTÜ: Attribute zu Volltextübersetzern und Wörterbüchern

WBDig: digitale Wörterbücher

WBGedr: Gedruckte Wörterbücher

3.11 Lehre 1

Aufgabenstellung: Prof. Dr. Josef L. Staud

Lösung: stud. inform. Karolin Staud

3.11.1 Anforderungsbeschreibung

Für den Lehrbetrieb einer Hochschule soll eine Datenbank erstellt werden. Dazu wird ein relationales Datenmodell erstellt, für das die folgenden Anforderungen festgelegt wurden. Zu erfassen sind:

(1) Lehrveranstaltungen: Jede Veranstaltung mit einer identifizierenden Nummer (LVNr), Bezeichnung (BezLV), der Zahl der Semesterwochenstunden (SWS) und in welchem Semster sie nach der SPO angeboten werden müssen (SemPlan).

(2) Studierende mit Matrikelnummer (MatrNr), Namen, Vornamen (VName) und einem E-Mail-Postfach (E-Mail).

(3) Der Besuch von Lehrveranstaltungen durch Studierende. Es kommt durchaus vor, dass ein Studierender eine bestimmte Lehrveranstaltung mehrfach besuchen muss.

(4) Dozenten: Jeder Dozent, der Lehrveranstaltungen gibt, mit Namen und Vornamen.

(5) Die Lehrtätigkeit der Dozenten. Festgehalten wird, welcher Dozent eine bestimmte Veranstaltung in welchem Semester gehalten hat. An dieser (kleinen) Hochschule wird jede Veranstaltung pro Semester nur einmal gehalten. Allerdings kommt es vor, dass mehrere Dozenten in einem Semester zusammen eine Lehrveranstaltung durchführen.

3.11.2 Lösungsschritte

Anforderung 1

Unschwer kann die erste Relation erkannt werden: Lehrveranstaltungen (LV). Sie werden identifiziert (LVNr) und beschrieben, sind also datenbanktechnisch relevant:

LV (#LVNr, #BezLV, SWS, SemPlan)

Da die Bezeichnung der Lehrveranstaltung auch eindeutig sein dürfte, wird BezLV zu einem Sekundärschlüssel.

Anforderung 2

Hier werden die Studierenden angesprochen. Da ein Schlüssel vorliegt (MatrNr) und beschreibende Attribute, entsteht eine Relation:

Studierende (#MatrNr, Name, VName, E-Mail)

Anforderung 3

Für den Besuch von Lehrveranstaltungen (LVBesuch) müssen obige Relationen verknüpft werden. Geht man davon aus, dass Vorlesungen semesterweise besucht werden, ist die erste Lösung g wie folgt:

LVBesuch (#(MatrNr, LVNr), Semester)

Durch den Hinweis, dass Lehrveranstaltungen durchaus auch mehrfach besucht werden (müssen), ergibt sich aber eine Änderung. Das Attribut Semester muss in den Schlüssel, sonst wäre der Schlüssel im Fall von Wiederholungsn nicht eindeutig:

LVBesuch (#(MatrNr, LVNr, Semester))

Anforderung 4

Die hier angesprochenen Dozenten können, wenn man einen Schlüssel ergänzt (DozNr), ebenfalls als Relation angelegt werden:

Dozenten (#DozNr, Name, VName)

Anforderung 5

Der abschließende Punkt betrifft die Lehrtätigkeit (Lehre). Gehen wir von der realistischen Annahme aus, dass ein Dozent keine (Freisemester), eine oder (meist) mehrere Lehrveranstaltungen gibt, ergibt sich folgende Lösung:

Lehre ((DozNr, LVNr, Sem), …//Sem = Semester

Wäre verlangt, dass eine bestimmte Lehrveranstaltung pro Semester vom selben Dozenten mehrfach gehalten werden kann, müsste die Relation verändert werden.

Nun ist noch gefordert, dass auch der Fall erfasst wird, dass mehrere Dozenten zusammen eine Lehrveranstaltung durchführen. Dies ist mit obiger Relation möglich. Dann gibt es z.B. folgende Tupel:

1007, DBS1, SS2023

1008, DBS1, SS2023

Die Lösung ist aber nur richtig, weil in der Anforderungsbeschreibung ausgeführt ist, dass in jedem Semester jede Vorlesung nur einmal gehalten wird. Das drücken auch die Min-/Max-Angaben aus:

Min-/Max-Angaben für Dozenten – Lehre – LV: 0,n : 1,1

3.11.3 Lösung

Textliche Fassung

LV (#LVNr, #BezLV, SWS, SemPlan)

Studierende (#MatrNr, Name, VName, E-Mail)

LVBesuch (#(MatrNr, LVNr, Semester))

Dozenten (#DozNr, Name, VName)

Lehre ((DozNr, LVNr, Sem))

Grafische Fassung

Abbildung 3.11-1: Relationales Datenmodell Lehre 1

3.12 Lehre 2

Aufgabenstellung: Prof. Dr. Josef L. Staud

Lösung: stud. inform. Karolin Staud

3.12.1 Anforderungsbeschreibung

Diese Aufgabe baut auf obiger auf. Die zusätzlichen Anforderungen sind mit „ZUSÄTZLICH:“ markiert. Entwerder also die obige Lösung übernehmen und als Ausgangsbasis nehmen oder einfach als Ganzes lösen. Erfasst weden sollen:

(1) Lehrveranstaltungen: Jede Veranstaltung mit einer identifizierenden Nummer (LVNr), Bezeichnung (BezLV), der Zahl der Semesterwochenstunden (SWS) und in welchem Semster sie nach der SPO angeboten werden müssen (SemPlan).

(2) Studierende mit Matrikelnummer (MatrNr), Namen, Vornamen (VName) und einem E-Mail-Postfach (E-Mail). ZUSÄTZLICH: Von jedem Studierenden wird die Hauptadresse, die der Kommunikation mit der Hochschule dient, mit PLZ, Ort, Straße erfasst.

(3) Der Besuch von Lehrveranstaltungen durch Studierende. Es kommt durchaus vor, dass ein Studierender eine bestimmte Lehrveranstaltung mehrfach besuchen muss.

(4) Dozenten: Jeder Dozent, der Lehrveranstaltungen gibt, mit Namen und Vornamen. ZUSÄTZLICH: Für interne Dozenten wird noch festgehalten, in welchem Raum der Hochschule sie ihr Büro haben und wann ihre Sprechstunde ist. Für externe Dozenten wird festgehalten von welcher Organisation sie kommen (einem Unternehmen, einer anderen Hochschule, usw.).

(5) Die Lehrtätigkeit der Dozenten (Lehre). Festgehalten wird, welcher Dozent eine bestimmte Veranstaltung in welchem Semester gehalten hat. An dieser (kleinen) Hochschule wird jede Veranstaltung pro Semester nur einmal gehalten. Allerdings kommt es vor, dass mehrere Dozenten in einem Semester zusammen eine Lehrveranstaltung durchführen.

(6) ZUSÄTZLICH: Jede einzelne Veranstaltungsstunde (VTermine) mit Tag, Beginn, Ende und Raum. Als Schlüssel für die Termine dient eine Konstruktion aus Tag und Anfangszeit, also z.B. 20230602_0830 für eine Lehrveranstaltung, die am 2.6.2023 um 8.30 Uhr begann.

(7) ZUSÄTZLICH: Der Besuch der Veranstaltungstermine durch die Studierenden. An dieser Hochschule ist es üblich, die Anwesenheit zu kontrollieren. Deshalb wird für jeden Veranstaltungstermin einer Lehrveranstaltung festgehalten, welche Studierenden anwesend waren.

3.12.2 Lösungsschritte

Anforderung 1

Unschwer kann die erste Relation erkannt werden: Lehrveranstaltungen (LV). Sie werden identifiziert (LVNr) und beschrieben, sind also datenbanktechnisch relevant:

LV (#LVNr, #BezLV, SWS, SemPlan)

Da die Bezeichnung der Lehrveranstaltung auch eindeutig sein dürfte, wird BezLV zu einem Sekundärschlüssel.

Anforderung 2

Hier werden die Studierenden angesprochen. Da ein Schlüssel vorliegt (MatrNr) und beschreibende Attribute, entsteht eine Relation mit Name, VName und Email. Da von den Studierenden nur eine einzige Adresse erfasst wird, können die Adressinformkationen auch in diese Relation eingefügt werden. Somit entsteht:

Studierende (#MatrNr, Name, VName, E-Mail, PLZ, Ort, Straße)

Anforderung 3

Für den Besuch von Lehrveranstaltungen müssen obige Relationen verknüpft werden. Geht man davon aus, dass Vorlesungen semesterweise besucht werden, ist die Lösung wie folgt:

LVBesuch (#(MatrNr, LVNr), Semester)

Durch den Hinweis, dass Lehrveranstaltungen durchaus auch mehrfach besucht werden (müssen), ergibt sich aber eine Änderung. Das Attribut Semester muss in den Schlüssel, sonst wäre der Schlüssel nicht eindeutig:

LVBesuch (#(MatrNr, LVNr, Semester))

Anforderung 4

Die hier angesprochenen Dozenten können, wenn man einen Schlüssel ergänzt (DozNr), ebenfalls als Relation angelegt werden:

Dozenten (#DozNr, Name, VName) //vorläufig

Nun werden aber für interne und externe Dozenten jeweils spezifische Attribute genannt. Das führt zu Spezialisierungen von Dozenten. Wird Dozenten in DozAllg (Dozenten allgemein) umbenannt und für die Spezialisierungen DozIntern und DozExtern eingeführt, entstehen folgende Relationen:

DozAllg (#DozNr, Name, Vorname, Typ)

DozIntern (#DozNr, EMail, BüroNr, SprStunde)

DozExtern (#DozNr, Org)

Das Attribut DozAllg.Typ wurde aus pragmatischen Gründen hinzugenommen. Es gibt an, ob der Dozent ein interner oder ein externer ist und erleichtert damit die Abfragen.

Anforderung 5

Dieser Punkt betrifft die Lehrtätigkeit (Lehre). Dafür werden Dozenten und Lehrveranstaltungen verknüpft. Gehen wir von der realistischen Annahme aus, dass ein Dozent keine (Freisemester), eine oder (meist) mehrere Lehrveranstaltungen gibt, ist die Lösung wie folgt:

Lehre ((DozNr, LVNr, Sem), …//Sem = Semester

Die Min-/Max-Angaben für Dozenten – Lehre – LV sind 0,n : 1,1.

Anforderung 6 – Termine!

Neben den Lehrveranstaltungen ist auch die Erfassung der einzelnen Termine der Lehrveranstaltung gefordert. Entsprechend den Anforderungen wird für die Termine ein konstruierter Schlüssel TerminNr angelegt. Als beschreibende Attribute kommen Tag, Beginn, Ende und Raum hinzu:

LVTermine (#TerminNr, Tag, Beginn, Ende, Raum, …//vorläufig

Etwas wichtiges fehlt da noch, die Lehrveranstaltung um die es geht. Diese kann mit Hilfe der LVNr hinzugefügt werden. Dies sollte im Schlüssel geschehen, da es mit Sicherheit Lehrveranstaltungen gibt, die zum selben Zeitpunkt stattfinden. Die LVNr ist dann auch Fremdschlüssel. Damit ergibt sich:

LVTermine (#TerminNr, LVNr), Tag, Beginn, Ende, Raum) //final

Der konstruierte Schlüssel könnte aus der LVNr und zeitlichen Angaben bestehen. Also z.B. 1220_20230602_0830 für einen Lehrveranstaltungstermin mit der Nummer 1220, die am 2.6.2023 um 8.30 Uhr beginnt.

Will man keinen konstruierten Schlüssel, könnte man den zeitlichen Aspekt mittels Tag und Beginn erfassen, isgesamt also zum Schlüssel #(LVNr, Tag, Beginn) finden.

Anforderung 7

Hier soll auch noch der Besuch der Termine durch die Studierenden festgehalten werden („Anwesenheitsliste“). Dafür muss eine Relation „Lehrveranstaltungsbesuchtermine“ (LVBesTermine) angelegt werden. Als Attribute werden die TerminNr und die MatrNr. Benötigt. Es handelt sich um eine n:m-Beziehung, so dass folgende Relation entsteht:

LVBesTermine (#(TerminNr, MatrNr))

Als Min-/Max-Angabe soll für „Studierende – LVBesTermine – LVTermine“ 0,n : 3,n angenommen werden mit der Erkenntnis/Semantik: Es gibt Studierende, die gar keinen Termin wahrnehmen, ein Termin findet nur statt, wenn mindestens drei Studierende anwesend sind (zum Beispiel).

3.12.3 Lösung

Textliche Fassung

DozAllg (#DozNr, Name, Vorname, Typ)

DozExtern (#DozNr, Org)

DozIntern (#DozNr, EMail, BüroNr, SprStunde)

Lehre ((DozNr, LVNr, Sem)

LV (#LVNr, #BezLV, SWS, SemPlan)

LVBesTermine (#(TerminNr, MatrNr))

LVBesuch (#(MatrNr, LVNr, Semester))

LVTermine (#TerminNr, LVNr), Tag, Beginn, Ende, Raum)

Studierende (#MatrNr, Name, VName, E-Mail, PLZ, Ort, Straße)

Grafische Fassung

Abbildung 3.12-1: Relationales Datenmodell Lehre 2

3.13 Lehre 3

3.13.1 Anforderungsbeschreibung

Hier wird der Anwendungsbereich Vorlesungsbetrieb einer Hochschule (HS) betrachtet. Folgendes soll erfasst werden:

(1) Für die Lehrveranstaltungen eine Veranstaltungsnummer (LVNr), ihre Bezeichnung (BezLV), der Typ des zugehörigen Studienganges (Master, Bachelor, Diplom) (TypSG), die Bezeichnung des Studienganges (WI, AI, ...), der die Lehrveranstaltung durchführt (BezSG), die Credit Points (cp) und die Anzahl Semesterwochenstunden (SWS). Außerdem, in welchem Studiensemester die Lehrveranstaltung abzuhalten ist (SemPlan). Für jeden konkreten Termin der Lehrveranstaltungen wird festgehalten an welchem Tag er statt fand (Tag), wann er begann (Beginn) und wann er endete (Ende). Also z.B. Mittwochs, 8.00 - 9.30 Uhr. Die Räume werden ebenfalls erfasst, mit einer Typisierung (ArtRaum; DV-Raum, Vorlesungsraum, Labor, ...), der Größe (Groesse), der Ausstattung mit Beamern und Intranet (BeamerJN, IntranetJN) und dem Gebäude, in dem sie sich befinden (GebBez). Dabei geht man davon aus, dass in einem Semester eine Lehrveranstaltung immer in demselben Raum stattfindet. In verschiedenen Semestern kann die Lehrveranstaltung aber natürlich in jeweils anderen Räumen sein.

(2) Die Studierenden werden durch ihre Matrikelnummer (MatrNr), den Namen, Vornamen (VName) und ein E-Mail-Postfach (E-Mail) erfasst. Für sie wird außerdem festgehalten, in welchem Semester sie welche Lehrveranstaltung besucht haben. Es kommt durchaus vor, dass ein Studierender eine bestimmte Lehrveranstaltung mehrfach besuchen muss. Sozusagen in den "Stammdaten" der Studierenden ist außerdem vermerkt, wann das Studium begann (BegStudium), wann es endet(e) (EndeStudium), in welchem Studiengang (SG) sie eingeschrieben sind und in welchem Fachsemester sie sich befinden (FachSem). Für die Studierenden werden beliebig viele Adressen (PLZ, Ort, Strasse) zugelassen. Eine davon muss als die gekennzeichnet sein, zu der die Mitteilungen der Hochschule gesandt werden.

(3) Die Dozenten werden durch eine Dozentennummer (DozNr), den Namen, Vornamen (VName), die Anrede sowie ein E-Mail-Postfach erfasst. Für die Dozenten der Hochschule sollen zusätzlich auch die Nummer ihres Büros (BüroNr), ihre interne Telefonnummer (IntTel), ihre Sprechstunde (SprSt), ihre Fakultät und die Angabe des Gebäudes, in dem sich das Büro befindet (GebBez), angegeben werden. Für diese Gebäude wird noch festgehalten, in welchem Ort sie sich befinden (Ort), welche Straßenadresse sie haben (Straße, z.B. Hauptstr. 8) und welcher DV-Betreuer für das Gebäude zuständig ist (Straße, DVBetr). Es gibt an dieser Hochschule auch externe Dozenten. Für diese wird die Adresse erfasst (nur eine), welchen akademischen Abschluss sie haben (AkAb) und in welcher Organisation (Unternehmen, andere Hochschule, ...) welcher Branche sie arbeiten. Deren Adresse wird, für die Zusendung von Lehraufträgen usw., ebenfalls erfasst.

(4) Zum Lehrbetrieb soll in der Datenbank festgehalten werden, welcher Dozent welche Lehrveranstaltung gehalten hat. Üblicherweise hält ein Dozent mehrere Lehrveranstaltungen in einem Semester und dieselbe Lehrveranstaltung kann in verschiedenen Semestern von unterschiedlichen Dozenten gehalten werden. Kein Dozent hält in einem Semester eine Lehrveranstaltung mehrfach. Auch der Besuch von Lehrveranstaltungen durch Studierende wird mit Angabe des Semesters erfasst. Es soll möglich sein, dass ein Studierender mehrfach für eine Lehrveranstaltung eingeschrieben ist (Wiederholungen).

(5) Alle Prüfungen beziehen sich immer auf genau eine Lehrveranstaltung. Jeder wird eine Prüfungsnummer (PrüfNr) und eine Bezeichnung (Bez) zugewiesen. Bei allen Prüfungen wird der Prüfungstag festgehalten (Datum). Bei Klausuren (KL) und mündlichen Prüfungen (MP) auch die Länge. Bei mündlichen Prüfungen zusätzlich der Prüfer (dies ist immer nur genau einer; PrüfPersNr). Dieser kann interner oder auch externer Dozent sein. Praktische Arbeiten (PA) sind Leistungen wie Erstellung eines Datenmodells, Modellierung eines Prozesses, usw. Laborarbeiten (LA) sind solche, für die ein Labor und die Unterstützung des zuständigen Laborbetreuers benötigt wird. Beide finden in einem bestimmten Zeitraum statt, der ebenfalls in der Datenbank erfasst werden soll (Start, Ende). Bei Laborarbeiten sind zusätzlich die Laborbezeichnung (LabBez; EBUS-Labor, Mikrocomputerlabor, ERP-Labor, ...) und der Laborbetreuer mit Namen und Vornamen zu erfassen (LabBetrN, LabBetrVN).

(6) Der Besuch einer Prüfung bezieht sich immer auf eine Lehrveranstaltung. Festgehalten wird zu jeder Prüfung das Semester, in dem sie stattfindet (Sem), das genaue Datum, um welchen Versuch es sich handelt (1. Versuch, 2. Versuch, ...) und welche Note erzielt wurde.

3.13.2 Lösungsschritte

Anforderung Teil 1

Für die Lehrveranstaltungen eine Veranstaltungsnummer (LVNr), ihre Bezeichnung (BezLV), der Typ des zugehörigen Studienganges (Master, Bachelor, Diplom) (TypSG), die Bezeichnung des Studienganges (WI, AI, ...), der die Lehrveranstaltung durchführt (BezSG), die Credit Points (cp) und die Anzahl Semesterwochenstunden (SWS). Außerdem, in welchem Studiensemester die Lehrveranstaltung abzuhalten ist (SemPlan). Für jeden konkreten Termin der Lehrveranstaltungen wird festgehalten an welchem Tag er war (Tag), wann er begann (Beginn) und wann er endete (Ende). Also z.B. Mittwochs, 8.00 - 9.30 Uhr. Die Räume werden ebenfalls erfasst, mit einer Typisierung (ArtRaum; DV-Raum, Vorlesungsraum, Labor, ...), der Größe (Groesse), der Ausstattung mit Beamern und Intranet (BeamerJN, IntranetJN) und dem Gebäude, in dem sie sich befinden (GebBez). Dabei geht man davon aus, dass in einem Semester eine Lehrveranstaltung immer in demselben Raum stattfindet. In verschiedenen Semestern kann die Lehrveranstaltung aber natürlich in jeweils anderen Räumen sein.

Auf Grund der Beschreibung kann angenommen werden, dass es nicht um fixe Wochenpläne geht, sondern um flexible, also um Einzeltermine. Dass trotzdem die meisten dann in jeder Woche zum selben Zeitpunkt stattfinden, soll nicht stören.

Die Lehrveranstaltungen (LV) selbst sind sofort als Relationen erkennbar, da sie identifiziert und durch zahlreiche Attribute beschrieben werden (mit BezLV, TypSG, BezSG, SemPlan, cp, SWS). Der Schlüssel ist LVNr. Für die Termine der Lehrveranstaltungen ergibt sich ein Schlüssel, wie er oft bei zeitlich fixierten Vorgängen auftritt. Der eigentliche Gegenstand, hier die Veranstaltungstermine, muss mit einem "Zeitstempel" versehen werden. Dabei genügen hier Tag und Beginn, da damit der Schlüssel eindeutig wird (LVTermine mit #(LVNr, Tag, Beginn), Ende).

Auch die Räume sind oben angesprochen. Ihre Modellierung bereitet keine Probleme: (#RaumNr, ArtRaum, Groesse, BeamerJN, IntranetJN, GebBez). Bei den Gebäuden muss geprüft werden, ob sie später noch beschrieben werden. Da dies hier der Fall ist, wurde die Gebäudebezeichnung als Fremdschlüssel aufgenommen.

Die Ausführungen in der Anforderung zu den Räumen für die Lehrveranstaltungen sind etwas unklar und müssen präzisiert werden. Nimmt man die Räume zu den Terminen hinzu entsteht Redundanz, denn es ist ja in einem Semester immer derselbe Raum, in dem die Lehrveranstaltung stattfindet. Deshalb muss eine eigene Relation eingerichtet werden, die an einer einzigen Stelle für eine Lehrveranstaltung und ein ganzes Semester den Raum mittels RaumNr festhält: LVRäume mit (#(LVNr, Sem), RaumNr). Das Attribut RaumNr stellt als Fremdschlüssel die Verknüpfung mit Räume her.

Damit ergeben sich folgende Relationen:

LV (#LVNr, BezLV, TypSG, BezSG, SemPlan, cp, SWS)

LVRäume (#(LVNr, Sem), RaumNr)

LVTermine (#(LVNr, Tag, Beginn), Ende)

Räume (#RaumNr, ArtRaum, Groesse, BeamerJN, IntranetJN, GebBez)

Die Kardinalitäten und Min-/Max-Angaben sind wie folgt (hier mal ausnahmsweise zusätzlich auch mit Einzelangaben zur n:m-Verknüpfung):

• Von LV über LVRäume zu Räume: n:m bzw. 1,n : 0,n. Weil eine Lehrveranstaltung in mehreren Semestern in verschiedenen Räumen abgehalten werden kann und wenn wir annehmen, dass es auch Räume für Lehrveranstaltungen gibt, die noch nicht eingesetzt wurden.
• Von LV zu LVRäume: 1:m bzw. 1,n : 1,1 (Teil von oben).
• Von Räume zu LVRäume: 1:n bzw. 0,n : 1,1 (Teil von oben).
• Von LV zu LVTermine: 1:n bzw. 1,n : 1,1.

Die folgende Abbildung zeigt diesen Modellausschnitt in grafischer Form.

Abbildung 3.13-1: Relationales Datenmodell HS – Ausschnitt Lehrveranstaltungen

Nicht verwirren lassen: Die Beziehung LV – Räume ist hier nicht nur jeweils für ein Semester, sondern über die Semester hinweg erfasst. Deshalb n:m und nicht 1:n.

Anforderung Teil 2

Die Studierenden werden durch ihre Matrikelnummer (MatrNr), den Namen, Vornamen (VName) und ein E-Mail-Postfach (E-Mail) erfasst. Für sie wird außerdem festgehalten, in welchem Semester sie welche Lehrveranstaltung besucht haben. Es kommt durchaus vor, dass ein Studierender eine bestimmte Lehrveranstaltung mehrfach besuchen muss. Sozusagen in den "Stammdaten" der Studierenden ist außerdem vermerkt, wann das Studium begann (BegStudium), wann es endet(e) (EndeStudium), in welchem Studiengang (SG) sie eingeschrieben sind und in welchem Fachsemester sie sich befinden (FachSem). Für die Studierenden werden beliebig viele Adressen (PLZ, Ort, Strasse) zugelassen. Eine davon muss als die gekennzeichnet sein, zu der die Mitteilungen der Hochschule gesandt werden.

Hieraus ergeben sich mehrere Relationen. Die erste zu den Studierenden. Sie werden durch die Matrikelnummer identifiziert und durch die angegebenen weiteren Attribute beschrieben. Die Aufnahme von EndeStudium verstößt ja eigentlich gegen eine derGrundregeln relationaler Datenmodellierung (weil diese Angabe ja erst mal nicht zur Verfügung steht), wird aber aus pragmatischen Gründen akzeptiert: (#MatrNr, Name, VName, E-Mail, BegStudium, EndeStudium, SG, FachSem).

Die zweite erfasst den Besuch von Lehrveranstaltungen. Es ist eine n:m-Verknüpfung, so dass eine Verbindungsrelation entsteht (LVBesuch), allerdings mit einem zusätzlichen Zeitstempel, der Semesterangabe (Sem).

Abschließend werden oben die Adressangaben der Studierenden angesprochen. Der Text lässt auf eine 1:n-Beziehung zwischen Studierenden und Adressen schließen. Da aber unter einer Adresse auch mehrere Studierende wohnen können (Wohnheim, Wohngemeinschaft), gilt auch umgekehrt eine 1:n-Beziehung. Insgesamt ensteht also also eine n:m-Beziehung. Diese führt zur Relation StudAdr. Mit dem Attribut Art kann festgehalten werden, ob es sich um die Adresse für die Mitteilungen an die Studierenden handelt.

Die neuen Relationen:

Studierende (#MatrNr, Name, VName, E-Mail, BegStudium, EndeStudium, SG, FachSem)

LVBesuch (#(MatrNr, LVNr, Sem))

Adressen (#AdrNr, Ort, PLZ, Strasse)

StudAdr (#(MatrNr, AdrNr), Art)

Nehmen wir LV dazu, sind die Kardinalitäten und Min-/Max-Angaben wie folgt:

• Von Studierende über LVBesuch zu LV: n:m bzw. 0,n : 3,n. Wenn man annimmt, dass ein Studierender auch mal keine Lehrveranstaltung besucht und dass eine Lehrveranstaltung nur durchgeführt wird, wenn mindestens drei Studierende anwesend sind.
• Von Studierende über StudAdr zu Adressen: n:m bzw. 1,n : 1,m.

Die folgende Abbildung zeigt diesen Ausschnitt des Datenmodells:

Abbildung 3.13-2: Relationales Datenmodell HS – Auschnitt Studierende und Lehrveranstaltungen

Anforderung Teil 3

Die Dozenten werden durch eine Dozentennummer (DozNr), den Namen, Vornamen (VName), die Anrede sowie ein E-Mail-Postfach erfasst. Für die Dozenten der Hochschule sollen zusätzlich auch die Nummer ihres Büros (BüroNr), ihre interne Telefonnummer (IntTel), ihre Sprechstunde (SprSt), ihre Fakultät und die Angabe des Gebäudes, in dem sich das Büro befindet (BezGeb), angegeben werden. Für diese Gebäude wird noch festgehalten, in welchem Ort sie sich befinden (Ort), welche Straßenadresse sie haben (Straße, z.B. Hauptstr. 8) und welcher DV-Betreuer für das Gebäude zuständig ist (Straße, DVBetr). Es gibt an dieser Hochschule auch externe Dozenten. Für diese wird die Adresse erfasst (nur eine), welchen akademischen Abschluss sie haben (AkAb) und in welcher Organisation (Unternehmen, andere Hochschule, ...) welcher Branche sie arbeiten. Deren Adresse wird, für die Zusendung von Lehraufträgen usw., ebenfalls erfasst.

Dozenten mit Generalisierung / Spezialisierung. Die Lehrkräfte der Hochschule erscheinen hier als externe und interne Dozenten. Da es Attribute für alle Dozenten gibt und spezifische für die beiden Untergruppen liegt eine Generalisierung / Spezialisierung vor. Die gemeinsamen Attribute sind Name, VName, Anrede und E-Mail, sie kommen in die Generalisierung (DozAllgemein).

Den externen Dozenten (DozExt) wird nach Übernahme eines Lehrauftrags eine Dozentennummer (DozNR) zugewiesen. Diese entspricht modelltechnisch der Personalnummer (DozExtern) der internen Dozenten (DozHS). Für die externen Dozenten wird neben dem akademischen Abschluss (AkAb) eine einzige Adresse erfasst, somit genügt für das Festhalten der Adresse ein Fremdschlüssel in der Relation (AdrNr). Für die Organisationszugehörigkeit wird ebenfalls ein Fremdschlüssel (OrgNr) angelegt (zur Organisation vgl. unten). Bei den Dozenten der Hochschule wird angenommen, dass sie nur ein einziges Büro haben. Dessen Gebäude kann als Fremdschlüssel in DozHS erfasst werden.

Alle drei Relationen zu Dozenten erhalten denselben Schlüssel. Dies ist bei einer Generalisierung / Spezialisierung immer der Fall und wirkt auf den ersten Blick befremdlich, da im allgemeinen in der relationalen Modellierung gilt: Es gibt keine Relationen mit demselben Schlüssel. Dies ist eine der Ausnahmen.

Auch die Gebäude können mit einem Schlüssel (#BezGeb), dem Ort und der Straße sowie dem zuständigen DV-Betreuer (DVBetr) erfasst werden.

Bleiben noch die Organisationen. Sie haben eine Bezeichnung und eine Adresse, Außerdem wird ihre Branche festgehalten und ein Schlüssel (OrgNr) vergeben. Damit kann eine Relation Organisationen angelegt werden. Mit dem Fremdschlüssel AdrNr wird diese Relation mit der zu den Adressen verknüpft.