2 Relationale Datenbanken – Von der Anforderung zum Datenmodell

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

Erster Schritt des Gesamtwegs:
Anforderungen – Datenmodell (Schema) – Datenbank – Web-Benutzeroberfläche

Die Aufgaben dieses Kapitel beziehen sich auf den ersten Schritt des Gesamtwegs, von der Anforderungsbeschreibung zum Datenmodell.

2.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.

2.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.

2.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 Mitglied:

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.

2.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 2.1-1: Grafische Lösung zum Anwendungsbereich Sportverein – Ausschnitt Mitglieder

2.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.

2.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 formuliert :

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.

2.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.

2.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 2.2-1: Grafische Lösung zum Anwendungsbereich Sportverein – Ausschnitt aktiv/passiv

2.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.

2.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.

2.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:

Verbindungs­relation

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.

2.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 2.3-1: Anwendungsbereich Sportverein – Fragment Mannschaften/Abteilungen

2.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.

2.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!).

2.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 Manschaften 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

2.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 2.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, Kurzbezeichnung der gegnerischen 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)

2.5 Sportverein (insgesamt)

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

2.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!).

2.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 2.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 Mann­schaften

• 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:

Begeg­nungen

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.

2.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 (Attributsausprägungen aktiv, passiv, verstorben).

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

Grafische Fassung

Abbildung 2.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

2.6 Obst

2.6.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.

2.6.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

2.6.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 2.6-1: Relationales Datenmodell Obst

2.7 Angestellte

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

2.7.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).

2.7.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 / Speziali­sierung

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 2.7-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.

2.7.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 2.7-2: Relationales Datenmodell zum Anwendungsbereich Angestellte

2.8 Sprachenverlag

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

2.8.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.

2.8.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.

2.8.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 2.8-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. Daraus folgen weitere Relationen:

Zeitaspekt in Beziehung

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 2.8-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 2.8-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)

2.8.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 2.8-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

2.9 Lehre 1

Aufgabenstellung: Prof. Dr. Josef L. Staud

Lösung: stud. oec. inf. Karolin Staud

2.9.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.

2.9.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

2.9.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 2.9-1: Relationales Datenmodell Lehre 1

2.10 Lehre 2

Aufgabenstellung: Prof. Dr. Josef L. Staud

Lösung: stud. oec. inf. Karolin Staud

2.10.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.

2.10.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, insgesamt 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).

2.10.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 2.10-1: Relationales Datenmodell Lehre 2

2.11 Lehre 3

Dies ist die umfangreichste Aufgabe zum Vorlesungsbetrieb an Hochschulen. Hier wird in den Lösungsschritten, stärker als oben, die schrittweise Entwicklung des Datenmodells anhand von Modellfragmenten dargestellt. Außerdem wird das Muster Generalisierung / Spezialisierung intensiv thematisiert.

2.11.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.

2.11.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 2.11-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 2.11-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.

Die neuen Relationen und ihr Umfeld:

DozAllg (#DozNr, Name, VName, Anrede, E-Mail)

DozExt (#DozNr, AkAb, OrgNr, AdrNr)

DozHS (#DozNr, Fakultät, BüroNr, BezGeb, IntTel, SprSt, E-Mail)

Gebäude (#BezGeb, Ort, Straße, DVBetr)

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

Organisationen (#OrgNr, Bez, AdrNr, Branche)

Adressen (#AdrNr, Ort, PLZ, Strasse)

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

• Von DozAllg zu DozExt: 1:1 bzw. 0,1 : 1,1. Genauso für DozAllg zu DozHS.
• Von Gebäude zu DozHS: 1:n, bzw. 0,n : 1,1.
• Von Organisationen zu DozExt: 1:n bzw. 1,n : 0,1. Wenn man festlegt, dass eine Organisation nur erfasst wird, wenn sie mindestens einen Dozenten „schickt“ und nicht jeder externe Dozent von einer Organiation kommt („Privatier“).
• Von Adressen zu Organisationen: 1:1 bzw. 0,1 : 1,1 1:1 bzw. 0,1 : 1,1.
• Von Gebäude zu Räume: 1:n bzw. 1,n : 1,1

Hier die grafische Fassung dieses Modellausschnitts:

Abbildung 2.11-3: Relationales Datenmodell HS – Auschnitt Dozenten

Anforderung Teil 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).

Der Lehrbetrieb wird einfach durch eine Verbindungsrelation mit Angabe des Semesters erfasst. Mit dieser Lösung kann ein Dozent mehrere Lehrveranstaltungen pro Semester halten (was ja meist der Fall ist) und dieselbe Lehrveranstaltung kann in einem Semester von mehreren Dozenten gehalten werden, was allerdings normalerweise nicht der Fall ist. Genau gleich ist die Lösung für den Besuch von Lehrveranstaltungen. Durch das Schlüsselattribut Semester sind auch Wiederholungen erfassbar.

Damit ergeben sich folgende neuen Relationen mit "Zeitstempel":

Lehrbetrieb (#(DozNr, VeranstNr, Sem))

LVBesuch (#(MatrNr, LVNr, Sem))

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

• Von LV über Lehrbetrieb zu DozAllg: n:m bzw. 1,n : 0,n. Da ein neuer Dozent auch erfasst werden soll, bevor er oder sie die erste Lehrveranstaltung hält.
• Von LV über LVBesuch zu Studierende: n:m, bzw. 3,n : 0,n. Da eine Lehrveranstaltung mindestens drei Teilnehmer braucht und Studierende zu Beginn des Studiums noch keine LV besucht haben.

Für die grafische Gestaltung vgl. das Gesamtmodell.

Anforderung Teil 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).

. Auch bei den Prüfungen zeichnet sich eine Generalisierung / Spezialisierung ab. Alle erhalten eine Prüfungsnummer (PrüfNr), eine Bezeichnung (Bez), ein Prüfungsdatum (Datum) und den Verweis auf die Lehrveranstaltung , auf die sie sich beziehen. Da sich jede Prüfung auf genau eine Lehrveranstaltung bezieht, ist diese Lösung mit einem Fremdschlüssel korrekt. Für die Klärung der Gen/Spez-Hierarchie wird eine Tabelle erstellt, genau nach den oben formulierten Anforderungen.

Mehrstufige Gen/Spez zu Prüfungen

Damit sind die Spezialisierungen klar. PrüfAllg ist die "oberste" Generalisierung und enthält die Attribute, die alle Relationen aufweisen. Dazu gehört auch ein Fremdschlüssel für die zugehörige Lehrveranstaltung (LVNr). Die ersten Spezialisierungen sind PrüfPALA für die gemeinsamen Attribute von PA und LA (Start und Ende) sowie PrüfKLMP für das gemeinsame Attribut von KL und MP (Länge). Es folgen die Spezialisierungen PrüfLA von PrüfPALA und PrüfMP von PrüfKL+MP. PrüfLA erhält die Attribute zur Laborbetreuung (LabBez, LabBetrN, LabBetrVN), PrüfMP die zur prüfenden Person (PrüfPersNr), die auch Fremdschlüssel ist.

Die Relationen PrüfPALA und PrüfKLMP sind "nach oben" Spezialisierungen und "nach unten" Generalisierungen. Die Abbildung mit dem Datenmodell unten verdeutlicht dieses Strukturmerkmal. In dieser Abbildung sind die relationalen Verknüpfungen entlang dieser Spezialisierungshierachie eingezeichnet. Natürlich können aber in relationalen Datenbanken mit SQL alle Relationen einer Gen/Spez über ihre (gleichen) Schlüssel verknüpft werden.

Die neuen Relationen:

PrüfAllg (#PrüfNr, Bez, Datum, Versuch, ArtPrüf, LVNr)

PrüfPALA (#PrüfNr, Start, Ende)

PrüfKLMP (#PrüfNr, Länge)

PrüfLA (#PrüfNr, LabBez, LabBetrN, LabBetrVN)

PrüfMP (#PrüfNr, PrüfPersNr)

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

• Von PrüfAllg zu PrüfPALA: 1,1 bzw 0,1 : 1,1. Genauso sind die übrigen Gen/Spez-Wertigkeiten .
• Von DozAllg zu PrüfMP: 1:n bzw. 0,n : 1,1. Da es sicher Dozenten gibt, die nicht an einer mündlichen Prüfung teilgenommen haben und da jede mündliche Prüfung genau einen Prüfer hat.

Anforderung Teil 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.

Der letzte Teil der Anforderungen klärt die Erfassung des Prüfungsbesuchs. Dies ist wieder eine n:m-Beziehung (zwischen Studierenden und Prüfungen). Als Schlüssel dient neben der Matrikel- und Prüfungsnummer auch die Semesterangabe. Die anderen drei beschreibenden Attribute werden als Nichtschlüsselattribute eingefügt.

Damit ergibt sich folgende Relation:

PrüfBesuch (#(MatrNr, PrüfNr, Sem), Datum, Versuch, Note)

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

• Von Studierende über PrüfBesuch zu PrüfAllg: n:m bzw. 0,n : 1,m. Da ein Studierender zu Beginn des Studiums noch keine Prüfung besucht hat und da man davon ausgehen kann, dass eine Prüfung nur stattfindet, wenn mindestens ein Prüfling kommt.

Damit sind die einzelnen Anforderungen modelliert und können nun zusammengefügt werden.

2.11.3 Lösung

Textliche Fassung

Adressen (#AdrNr, Ort, PLZ, Strasse)

DozAllg (#DozNr, Name, VName, Anrede, E-Mail)

DozExt (#DozNr, AkAb, OrgNr, AdrNr)

DozHS (#DozNr, Fakultät, BüroNr, BezGeb, IntTel, SprSt, E-Mail)

Gebäude (#BezGeb, Ort, Straße, DVBetr)

Lehrbetrieb (#(DozNr, VeranstNr, Sem))

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

LVBesuch (#(MatrNr, LVNr, Sem))

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

LVTermine (#(LVNr, Tag, Beginn), Ende) //für jeden Termin

Organisationen (#OrgNr, Bez, AdrNr, Branche)

PrüfAllg (#PrüfNr, Bez, ArtPrüf, LVNr)

PrüfBesuch (#(MatrNr, PrüfNr, Sem), Datum, Versuch, Note)

PrüfKLMP (#PrüfNr, Länge)

PrüfLA (#PrüfNr, LabBez, LabBetrN, LabBetrVN)

PrüfMP (#PrüfNr, PrüfPersNr)

PrüfPALA (#PrüfNr, Start, Ende)

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

StudAdr (#(MatrNr, AdrNr), Art)

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

Grafische Fassung

Abbildung 2.11-4: Relationales Datenmodell Vorlesungsbetrieb

2.12 Fachliteratur

Angesichts von 20 Relationen und zahlreichen methodischen und semantischen Strukturmerkmalen gehört diese Aufgabe zu den umfangreichen und komplexen.

2.12.1 Anforderungsbeschreibung

Im Anwendungsbereich Fachliteratur sollen alle wichtigen Typen von Fachliteratur erfasst werden. Zweck der Datenbank ist es, die Literatur zu erfassen, die Suche nach Fachliteratur zu ermöglichen und von Zeit zu Zeit eine Literaturliste wie die nachfolgende zu erstellen (z.B. für eine Bachelor- oder Masterarbeit).

Die wichtigsten Arten von Fachliteratur sind:

• Monographien (Mono). Dies sind Bücher, die ein zusammenhängendes Werk darstellen und die von einem Autor oder mehreren verfasst sind.
• Sammelbände (SB). Auch diese sind Bücher. Allerdings hat hier jedes Kapitel einen eigenen Autor oder mehrere. Die Autoren des Sammelbandes insgesamt werden Herausgeber genannt.
• Die Beiträge in einem Sammelband (SBB). Dies sind die einzelnen Kapitel in Sammelbänden. Da diese ja spezielle Themen betreffen und eigene Autoren haben, werden sie als eigenständige Werke in der Datenbank erfasst. Zum Beispiel, um sie bei einer inhaltlichen Suche zu finden.
• Artikel in Fachzeitschriften (Zeitschriftenartikel, ZSA). Dies sind Werke, die in einer Zeitschrift erschienen sind.
• Internetquellen (IQU). Dies sind Werke von Internetseiten, z.B. Forschungsberichte, Firmenmitteilungen, usw.

Ergänzend werden Zeitschriften (ZS) erfasst, als Trägermedium der Zeitschriftenartikel (ZSA).

Diese Unterscheidung von Literaturarten ist wichtig, weil sie unterschiedlich beschrieben werden. Zum Beispiel in einer Literaturliste, wie sie bei einer akademischen Abschlussarbeit meist anfällt:

Biblio­graphische Angaben

Beispiele für Monographien (Mono)

Scheer, August-Wilhelm: Wirtschaftsinformatik. Referenzmodell für industrielle Geschäftsprozesse (5. Auflage), Berlin et al. 1994 (Springer-Verlag)

Österle, H.; Brenner, W.; Hilbers, K. et al.: Unternehmensführung und Informationssystem, Stuttgart 1992 (XYZ-Verlag)

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

Also: Name; Vorname; Titel; Ort (des Verlags); Erscheinungsjahr; Verlag, bei dem das Buch erschienen ist. Die Gestaltung mit Punkten, Strichpunkten, Kommata und die Einordnung der Verlagsangabe ist nur eine Empfehlung. Bei KI-Programmen als Autoren steht Name für die Bezeichnung der Software.

Beispiel für Sammelbände (SB)

Reussner, Ralf; Hasselbring, Wilhelm (Hrsg.), Handbuch der Software-Architektur (2. Auflage). Heidelberg 2009 (dpunkt)

Becker, Jörg; Kugeler, Martin; Rosemann, Michael (Hrsg.): Prozessmanagement. Ein Leitfaden zur Prozessorientierten Organisationsgestaltung (5. Auflage). Berlin u.a. 2005 (Springer)

Also: Namen und Vornamen; Hinweis auf die Herausgeberschaft; Titel; Untertitel, falls vorhanden; Hinweis auf Auflage, falls nicht die erste; Verlagsort(e); Erscheinungsjahr; Angabe Verlag, falls möglich.

Beispiele für Beiträge in einem Sammelband (SBB)

Hansmann, Holger; Laske, Michael; Luxem, Redmer: Einführung der Prozesse - Prozess-Roll-out. In: [Becker, Kugeler, Rosemann (Hrsg.) 2005], S. 269 - 298.

Baier, Achim; Becker, Steffen; Jung, Martin u.a.: Modellgetriebene Software-Entwicklung . In: [Reussner, Hasselbring (Hrsg.) 2009], S. 93 - 122

Also: Namen und Vornamen, bei mehr als drei Autoren der Zusatz "u.a." (und andere) oder "et al"; Titel; das Wort "In", das verdeutlicht, dass jetzt das übergeordnete Werk (der SB) folgt; bibliographische Angaben des Sammelbandes, in dem der SBB enthalten ist; Seitenangaben: erste und letzte Seite des SBB.

Falls in einer Literaturliste ein Beitrag aus einem Sammelband angeführt wird, muss auch der Sammelband enthalten sein.

Beispiele für einen Artikel in einer Zeitschrift (ZSA)

Wirth, N.: Gedanken zur Software-Explosion. In: Informatik Spektrum, Februar 1994, S. 5 - 10.

Czarski, Carsten: Richtig gefragt. Konstrukte für komplexe Datenbank-Queries. In: iX, Januar 2013, S. 154 - 157.

Schulz, Hajo: Objektorientiert programmieren mit Smalltalk. In: c’t kompakt Programmieren, Heft 03/2012, S. 146 - 152

Also: Namen und Vornamen; Titel, evtl. Untertitel; Bezeichnung der Zeitschrift, Angaben zum konkreten Heft der Zeitschrift; erste und letzte Seite des Artikels.

2.12.2 Lösungsschritte

Grundstruktur: Werke, Autoren, Autorenschaft

Bevor wir in die eigentliche Modellierung einsteigen, hier einige Ausführungen zur Modellierung dieses Anwendungsbereichs. Zu jeder Fachliteratur, egal ob sie als Buch, Zeitschriftenaufsatz oder sonstwie erscheint, gehört ein Text, dieser wird Werk genannt. Er soll hier durch eine WerkNr identifiziert werden:

Im Mittelpunkt: das Werk …

Werke (#WerkNr, ...)

Ein Werk stammt meist von einer oder mehreren natürlichen Personen. Oftmals werden auch Organisationen (Forschungseinrichtungen, Behörden, ...) als Autoren genannt. Inzwischen kann auch ein KI-Programm Texte erstellen und sollte dann als Autor genannt werden. Diese Autoren werden ebenfalls erfasst und durch eine Autorennummer identifiziert (AutorNr). Da es drei Gruppen von Autoren mit teilweise abweichenden Attributen gibt, müssen dafür drei verschiedene Relationen angelegt werden, Organisationen als Autoren (AutOrg), Personen als Autoren (AutPers) und KI-Programme als Autoren:

… und seine Autoren

AutPers (#AutorNr, Name, VName, …)

In dieser ersten Fassung der Relation wurden, abgeleitet aus den obigen Beispielen, die Attribute Name und Vorname (VName) eingefügt.

AutOrg(#AutorNr, BezOrg, BezOrg2, …)

Hier wurde die Bezeichnung der Organisation (BezOrg) und die zweite Zeile der Organiationsbezeichnung (BezOrg2) angelegt.

AutKI(#AutorNr, BezKI, Besitzer, …)

Für die KI-Programme werden in der ersten Fassung ihre Bezeichnung (BezKI), z.B. Chatxyz, und der Besitzer (z.B. Google) erfasst.

Hier bietet sich eine Generalisierung / Spezialisierung an. Die Generalisierung wird Autoren genannt. Sie erhält neben der AutorNr ein Attribut Typ mit den Ausprägungen Mensch, Organisation und KI sowie ein Attribut Id1 für Name (bei Menschen), BezOrg (bei Organisationen) bzw. BezKI (bei KI-Programmen):

Generalisierung / Spezialisierung

Autoren (#AutorNr, Id1, Typ, …)

Diese Generalisierung hat zwar erst mal wenig Attribute, erleichtert aber Abfrage und Verknüpfung. Vielleicht kommen ja noch Attribute dazu.

Hier gilt ganz grundsätzlich:

Autoren­schaft

Ein Autor kann mehrere Werke veröffentlichen, ein Werk kann mehrere Autoren haben.

Werke und Autoren sind durch die Autorenschaft verbunden: Diese hält fest, wer welches Werk verfasst hat. Da es sich um eine n:m-Verknüpfung handelt, ergibt sich eine Verbindungsrelation.

Nehmen wir noch dazu, dass bei Werken mit mehreren Autoren die Reihenfolge der Autorennennungen wichtig ist, ergibt sich für die Relation Autorenschaft ein beschreibendes Attribut Rang (an welcher Stelle der Autorenliste kommt er oder sie). Insgesamt liegen dann in textlicher Form folgende Relationenfragmente vor:

AutKI(#AutorNr, BezKI, Besitzer, …)

Autoren (#AutorNr, Id1, Typ, …)

Autorenschaft (#(AutorNr, WerkNr), Rang)

AutOrg(#AutorNr, BezOrg, BezOrg2, …)

AutPers (#AutorNr, Name, VName, …)

Werke (#WerkNr, ...)

Das folgende Modellfragment gibt diesen "Kern" des Datenmodells an.

Abbildung 2.12-1: Autorenschaft im Anwendungsbereich Fachliteratur

Modellierung der Literaturtypen

Die obige Liste von Werken machte den weitergehenden Aufbau der verschiedenen Literaturarten deutlich. In der folgenden Tabelle sind diese Informationen zusammengefasst. Es handelt sich hier um eine Generalisierung / Spezialisierung (vgl. Abschnitt 2.4.2 sowie [Staud 2021, Abschnitt 14.1]).

Typen bewältigen durch Gen/Spez.

Zeile A ...

sagt, dass alle Werke Autoren haben, die entweder Personen oder Organisationen sind. Dies wurde schon angelegt.

Zeile B ...

gibt den Hinweis auf ein Attribut, das alle verschiedenen Werke haben, den Titel. Außerdem auf eine Spezialisierung von Werke, nämlich Werke mit Untertiteln:

Werke (#WerkNr, Titel, …)

WerkeUT (#WerkNr, UT)

Zeilen C bis G ...

zeigen, dass MONographien (Mono) und SammelBände (SB) die 5 Attribute ISBN, Auflage, Jahr, Ort und BezVerlag gemeinsam haben, womit eine weitere Spezialisierung von Werke entsteht. In die Spezialisierung kommen aber nur drei Attribute, da die Verlagsangaben mehrfach vorkommen können, wenn ein einzelnes Werk von mehreren Verlagen herausgegeben wird. Dazu unten mehr.

Mono+SB (#WerkNr, ISBN, Auflage, Jahr)

Zeilen F und G: vgl. unten

Zeilen H und I ...

geben Attribute an, die nur SBB und ZSA besitzen. Für sie entsteht also eine Spezialisierung:

SBB+ZSA (#WerkNr, Von, Bis)

Zeile J ...

zeigt, dass Sammelbandbeiträge (SBB) eine weitere spezifische Information haben, die Angabe, von welchem Sammelband sie stammen (Quelle). Sie besteht aus zwei Attributen: Werknummer des Sammelbandes (WerkNrSB) und die KapitelNr im Sammelband. Somit entsteht die folgende Relation:

SBB (#WerkNr, WerkNrSB, KapitelNr)

Komposition zwischen SBB und SB als 1:n-Beziehung

Damit liegt eine Komposition zwischen Sammelbandbeiträgen und Sammelbänden vor. Falls ein Sammelband aus dem Buchbestand und damit aus der Datenbank entfernt wird, müssen auch die Sammelbandbeiträge dieses Sammelbands entfernt werden. Die Gestaltung des Schlüssels ergibt sich daraus, dass jeder SBB eine eindeutige Werknummer erhält und auch nur in genau einem SB enthalten ist. So sollte es zumindest sein. Es kommt aber natürlich vor, dass ein Autor sein Werk in mehreren Sammelbänden unterbringt.

Muster Komposition

Zeile K ...

zeigt, dass die Zeitschriftenaufsätze ebenfalls eine spezifische Information haben, die Quellenangabe. Sie besteht (im einfachsten Fall) aus zwei Attributen, Zeitschriftenbezeichnung (ZSBez) und Heftnummer (HeftNr):

ZSA (#WerkNr, ZSBez, HeftNr)

Zeilen L, M und N ...

führen zu weiteren Spezialisierungen von Werke, zu Internetquellen (IQU) und zu Sammelbänden (SB). Für die Internetquellen wird die URL und der Tag des Abrufs (AbrTag) angegeben, für die Sammelbände die Anzahl der Kapitel, die sie enthalten (AnzKap):

IQU (#WerkNr, URL, AbrTag)

SB (#WerkNr, AnzKap)

Insgesamt ergibt sich damit folgendes Datenmodell:

IQU (#WerkNr, URL, AbrTag)

ZSA (#WerkNr, ZSBez, HeftNr)

AutOrg(#AutorNr, BezOrg2, BezOrg3)

Autoren (#AutorNr, Id1)

Autorenschaft (#(AutorNr, WerkNr), Rang)

AutPers (#AutorNr, VName, Anrede)

Mono+SB (#WerkNr, ISBN, Auflage, Jahr)

SB (#WerkNr, AnzKap)

SBB (#WerkNr, WerkNrSB, KapitelNr)

SBB+ZSA (#WerkNr, Von, Bis)

Werke (#WerkNr, Titel)

WerkeUT (#WerkNr, UT)

Wertigkeiten

Die folgende Abbildung mit dem Ausschnitt zur Gen/Spez der Werke und zur Komposition zwischen SBB und SB verdeutlicht dieses Strukturmerkmal. Die Beziehungswertigkeiten zeigen zum einen die zwischen jeder Spezialisierung und ihrer Generalisierung (Kardinalität 1:1, Min-/Max-Angaben 0,1 : 1,1), zum anderen die bei einer Komposition, hier zwischen SB und SBB. Die Null bei der Wertigkeit bedeutet, dass es auch Sammelbände gibt, von denen keine Sammelbandbeiträge erfasst sind. Der Fremdschlüssel Fach in Werke wird unten erläutert.

Abbildung 2.12-2: Gen/Spez zu Literaturarten und Muster Komposition im Anwendungsbereich Fachliteratur

Noch mehr Anforderungen

Erfasst werden soll außerdem, welches Werk von welchem Verlag verfasst wurde. Es kommt auch vor, dass mehrere Verlage zusammen ein Buch publizieren. Bei den Verlagen wird der Ansprechpartner (AnsprV), die allgemeine Telefonnummer (Tel) und die des Ansprechpartners (TelAP) erfasst, für die Adressen der Verlage und die Adressen der Autoren PLZ, Ort und Straße. Von einem Verlag wird nur die Hauptadresse erfasst, von einem Autor mehrere. Es gibt auch Adressen, unter denen mehrere Autoren wohnen. Daraus ergeben sich die folgenden Relationen. Die Veröffentlichungstätigkeit wird als n:m-Verbindung zwischen Verlagen und Werken angesetzt. Die Adressen der Verlage werden durch einen Fremdschlüssel in Verlage integriert. Für die Adressen der Autoren gibt es eine Verbindungsrelation.

Verlage und Publikationen

Neue und veränderte Relationen

Verlage (#VerlNr, #BezVerlag,Tel, AnsprV, TelAP, AdrNr)

Publikationen (#(VerlNr, WerkNr))

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

AutOrg(#AutorNr, BezInst2, BezInst3, AdrNr)

AutPersAdr (#(AutorNr, AdrNr))

Für die Literatursuche sollen die Werke auch inhaltlich erschlossen werden. Dazu werden für jedes Werk ein Schlagwort (BezSchl) oder mehrere erhoben, z.B. Softwareentwicklung, Datenbankdesign, HTML 5, NoSQL. Jedes Schlagwort wird kurz beschrieben (Beschr), um die exakte Bedeutung zu klären. Dies führt zu folgenden neuen Relationen.

Inhaltliche Erschließung

WSchl (#(WerkNr, BezSchl))

Schlagw (#BezSchl, Beschr)

"Wieviele Werke liegen zu jedem Fachgebiet vor"

Ebenfalls erfasst werden soll ein Fachgebiet pro Werk. D.h. jedes Werk erhält eine Fachgebietszuordnung (Medizin, Technik, Informatik, ...). Diese werden regelmäßig ausgezählt, die Ergebnisse werden auch in der Datenbank verwaltet.

AnzFG (#Fachgebiet, Anzahl)

2.12.3 Lösung

Textliche Fassung

Insgesamt ergeben sich damit folgende Relationen:

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

AnzFG (#Fachgebiet, Anzahl) //Anzahl Werke in den Fachgebieten

Autoren (#AutorNr, Id1, Typ) //Name bzw. Organisationsbezeichnung

Autorenschaft (#(AutorNr, WerkNr), Rang)

AutOrg(#AutorNr, BezInst2, BezInst3, AdrNr) //Organisationen als Autoren

AutPers (#AutorNr, VName, Anrede) //Personen als Autoren

AutPersAdr (#(AutorNr, AdrNr)) //n:m, Autorenadressen

IQU (#WerkNr, URL, AbrTag) //Internetquellen

Mono+SB (#WerkNr, ISBN, Auflage, Jahr) //Monographien und Sammelbände

Publikationen (#(VerlNr, WerkNr)) //Verlage und Veröffentlichungen

SB (#WerkNr, AnzKap) //Sammelbände

SBB (#WerkNr, WerkNrSB, KapitelNr) //Beiträge in Sammelbänden

SBB+ZSA (#WerkNr, Von, Bis) //Seitenzahlen

Schlagw (#BezSchl, Beschr) //Schlagworte

Verlage (#VerlNr, #BezVerlag,Tel, AnsprV, TelAP, AdrNr) //Verlage

Werke (#WerkNr, Titel, Fach) //Textliche Werke (Fachliteratur)

WerkeUT (#WerkNr, UT) //Werke mit Untertiteln

WSchl (#(WerkNr, BezSchl)) //Verschlagwortung

ZSA (#WerkNr, ZSBez, HeftNr) //Zeitschriftenaufsätze

Grafische Fassung

Die folgende Abbildung zeigt die grafische Dar­stellung des Datenmodells. Einige beispielhafte Wertigkeiten wurden auch eingefügt. Ein Beispiel für die Wertigkeiten einer n:m-Verknüpfung ist bei Autorenschaft angegeben. Die Min-/Max-Angaben signalisieren, dass nur Autoren aufgenommen werden, die auch mindestens 1 Werk in der Datenbank aufweisen und dass Werke nicht ohne zugehörigen Autor erfasst werden.

Abbildung 2.12-3: Relationales Datenmodell zum Anwendungsbereich Fachliteratur

Abkürzungen in den Datenmodellen zur Fachliteratur:

ZS: Zeitschriften

ZSA: Zeitschriftenartikel

SB: Sammelbände

SBB: Beiträg in einem Kapitel eines Sammelbandes

Mono: Monographien

IQU: Internetquellen

2.13 Rechnungsstellung Stufe 1

2.13.1 Anforderungsbeschreibung

Mit dieser Aufgabe soll ein relationales Datenmodells für den Zweck der Rechnungsstellung erstellt werden. Ausgangspunkt ist dabei die in der folgenden Abbildung angegebene anonymisierte Rechnung, also ein Geschäftsobjekt (business object), was in der Datenmodellierung durchaus oft der Fall ist.

Rechnungen

Um die Rechnung aus dem Datenbestand reproduzieren zu können, soll folgendes festgehalten werden:

• Die Kunden werden mit Namen (Name), Vornamen (VName) und Anrede erfasst. Außerdem wird ein identifizierendes Attribut (KuNr) angelegt.
• Ein Kunde wird zuerst mit nur einer Adresse erfasst. Später dann mit beliebig vielen.
• Ein Kunde kann mehrere Telefonanschlüsse haben.
• In der Datenbank wird auch festgehalten, wer die Kundschaft bedient hat (Verkäufer). Dies wird auf der Rechnung ausgegeben.
• Die Information TOUR. Sie bezeichnet das Auslieferungsteam (Tour).
• Die Information KVDAT. Sie gibt den Tag an, an dem die Kundschaft im Möbelhaus war und die Ware bestellt hat (Kvdat).
• Das Datum der Lieferung (DatumLief).
• Der Betrag der Mehrwertsteuer (MWStBetrag).
• Es gilt: Eine Rechnung bezieht sich auf genau einen Auftrag
• Die angegebene Telefonnummer ist die der Rechnungsanschrift

Die Abkürzungen bei Position 1 bedeuten:

889999: Artikelnummer (ArtNr)

B/00/EG: Standort der Ware im Lager (Standort)

COUCHTISCH 1906 EICHE NATUR - MIT LIFT 125x71 cm: Artikelbezeichnung (ArtBez)

Ansonsten gilt die übliche kaufmännischen Semantik von Rechnungen.

Abbildung 2.13-1: Geschäftsobjekt Rechnung (Typ Möbelhaus)

2.13.2 Lösungsschritte

Relationale Datenmodellierung kann auch so gelöst werden, dass zuerst die Attribute mit ihren Determinanten und funktionalen Abhängigkeiten bestimmt werden:

• Name: des Kunden
• VNname
• PLZ: der Rechnungsanschrift
• Ort
• Straße
• Tel: Telefonnummer
• KuNr: Kundennummer. Diese ergänzen wir gleich, da die Erfassung der Kunden ohne eine Kundennummer nicht sinnvoll ist.
• ReNr: Rechnungsnummer
• ReDatum: Rechnungsdatum
• Verkäufer: die Angabe des Verkäufers erfolgt auf der Rechnung
• KVDAT: Hierbei handelt es sich um das Kaufvertragsdatum.
• Tour: Bezeichnung des Teams, das mit seinem Fahrzeug die Möbel ausliefert. Eine tiefere Semantik liegt nicht vor.
• PosNr: Rechnungspositionsnummer
• ArtNr: wird bei den Rechnungspositionen angegeben.
• Anzahl der Artikel pro Position
• Standort: Standort der Ware im Lager. Wird bei den Rechnungspositionen angegeben.
• ArtBez: Artikelbezeichnung
• DatumLief: Datum der Lieferung
• MWStB: Betrag der Mehrwertsteuer
• ZV: Zahlungsvereinbarung
• LiPreis: Listenpreis. Der Preis für die gesamte Position wird berechnet aus Anzahl und Preis.

Für einige Artikel liegt noch eine Beschreibung vor (Beschr), die aber nicht auf der Rechnung ausgegeben wird. In der Datenbank soll sie trotzdem erfasst werden.

Datenbankdesigner haben es nicht gerne, Informationen im Anwendungsprogramm zu hinterlegen oder in separaten (neben der Datenbank befindlichen) Tabellen und dies obwohl der neueste Datenbank-Ansatz (NoSQL) sehr viel Semantik im Programm umsetzt. Und doch kann es manchmal sinnvoll sein. Hier soll dies beispielhaft mit dem Mehrwertsteuersatz geschehen. Er wird im Programm hinterlegt, der Mehrwertsteuerbetrag (MWStB) wird dann daraus und aus der Rechnungssumme berechnet.

Informationen im Programm

Universalrelation

Das folgende muss man nicht machen, es hilft aber in komplexen Situationen gerade zu Beginn der Modellierung. Wir betrachten alle Attribute und bestimmen alle funktionalen Abhängigkeiten, z.B. durch FA-Diagramme.

Nach einigen langen Besprechungen ergab sich über die gesamte Universalrelation das folgende FA-Diagramm.

Abbildung 2.13-2: FA-Diagramm zur Universalrelation Rechnungen

Grundlage der Betrachtung der funktionalen Abhängigkeiten im FA-Diagramm ist die Kenntnis der Semantik des Anwendungsbereichs. Neben den funktionalen Abhängigkeiten sind auch gleich die Determinaten zu bestimmen. Hier sind dies, wie die Abbildung anschaulich zeigt, KuNr, (ReNr, PosNr), ReNr, ArtNr. Dies sind Kandidaten für die Schlüssel der zu findenden Relationen.

Welche Relationen können wir daraus ableiten? Sie sind in obiger Abbildung leicht zu erkennen. Alle Determinanten mit ihren funktional abhängigen Attributen werden normalerweise zu Relationen. Die Determinanten werden dann zu Schlüsseln.

Problemlos zu erkennen sind die Kunden: Identifiziert werden sie durch die KuNr. Voll funktional abhängig von dieser sind die folgenden Attribute:

Kunden

• KuNr => Name
• KuNr => VName
• KuNr => PLZ
• KuNr => Ort
• KuNr => Straße

Für die Adressangaben gilt dies nur, weil wir uns in Stufe 1 mit der Rechnungsanschrift begnügen. Damit ergibt sich die erste Relation:

Abbildung 2.13-3: FA-Diagramm von Kunden

Kunden (#KuNr, Name, VName, PLZ, Ort, Straße)

Die Telefonanschlüsse wurden oben weggelassen, da ja jeder Kunde mehrere haben kann. Dies ist dann keine funktionale Abhängigkeit. Hier können wir sie wieder dazutun, in einer eigenen Relation:

KuTel(#(KuNr, Tel))

KuNr ist Fremdschlüssel und dient der Verknüpfung mit Kunden.

Oben fällt der Attributsblock auf, der von ReNr funktional abhängig ist. Dies sind Attribute, mit denen die Rechnung beschrieben wird. In Abgrenzung zu den Rechnungspositionen soll er Rechnungsköpfe (ReKöpfe) genannt werden.

Rechnungs­köpfe

Die kaufmännische Semantik und die relationale Theorie sagen uns, dass es eine Unterscheidung geben muss zwischen Rechnungskopf (identifiziert durch die Rechnungsnummer (ReNr)) und den Rechnungspositionen, denn es gibt pro Rechnung mehrere Positionen. Letztere werden durch (ReNr, PosNr) identifiziert.

Folgende funktionalen Abhängigkeiten bestehen von der Determinante ReNr, die – spätestens nach der Normalisierung – zum Schlüssel wird.

• ReNr => ReDatum: Es gibt genau ein Rechnungsdatum pro Rechnung bzw. von der Rechnungsnummer kann auf das Rechnungsdatum geschlossen werden.
• ReNr => Verkäufer: Da immer nur einer für einen Kaufvertrag zuständig ist und nur einer auf der Rechnung erscheint.
• ReNr => Tour: Es gibt ein Auslieferungsteam je Rechnung.
• ReNr => KVDAT: Es gibt hier genau ein Kaufvertragsdatum je Rechnung.
• ReNr => MWStB: Es gibt nur einen Mehrwertsteuerbetrag je Rechnung.
• ReNr => DatumLief: Für jede Rechnung gibt es genau ein Lieferdatum.
• ReNr => ZV: Die Zahlungsvereinbarung ist je Rechnung eindeutig. Trotz Nachfragen konnte auch keine weitere Semantik (z.B. Abhängigkeit vom gekauften Produkt) festgestellt werden.

Damit ergibt sich folgende Relation zu den Rechnungsköpfen:

Abbildung 2.13-4: FA-Diagramm von Rechnungsköpfen (ReKöpfe)

ReKöpfe (#ReNr, ReDatum, KVDAT, Tour, Verkäufer, DatumLief, ZV, MWStB)

Auch diese ist in 5NF.

Die letzten leicht erkennbaren Objekte sind die Artikel. Sie werden identifiziert (ArtNr), haben eine Bezeichnung (ArtBez) und werden beschrieben. ArtNr wird also von der Determinante zum Schlüssel mit folgenden funktional abhängigen Attributen:

Artikel

• ArtNr => ArtBez
• ArtNr => ArtBeschr
• ArtNr => LiPreis: Da es sich um den Einzelpreis der Artikel handelt.
• ArtNr => Standort: Standort der Ware im Lager. Für einen Artikel immer derselbe.

Dies führt zu folgender Relation:

Abbildung 2.13-5: FA-Diagramm von Artikel

Artikel (#ArtNr, ArtBez, ArtBeschr, LiPreis, Standort)

Beim Überprüfen der Semantik überkommen uns Zweifel. Die Artikelbeschreibung liegt derzeit nur für 10% der Artikel vor. Soll das Attribut dann hier bleiben? In der späteren Datenbank wird dann für jeden Artikel der Speicherplatz für die Beschreibung verbraucht, auch wenn keine vorliegt. Da unser Datenbankmanagementsystem an dieser Stelle keine dynamische Speicherverwaltung anbietet, beschließen wir, die Artikelbeschreibung in eine eigene Relation auszulagern.

Pragmatik

Damit erhalten wir eine Generalisierung / Spezialisierung. In der relationalen Modellierung wird dafür für die Spezialisierung eine eigene Relation angelegt mit dem entsprechenden Attribut und mit dem Schlüssel der Generalisierung:

Muster Generali­sierung / Speziali­sierung

ArtBeschr(#ArtNr, ArtBeschr) //Artikelbeschreibung

Auch hier gibt es keinen Verstoß gegen die 5NF.

Bleiben noch die übrigen Attribute. Sie bewegen sich alle um die Rechnungspositionen herum. Rechnungspositionen werden durch eine Attributskombination identifiziert: (ReNr, PosNr). Folgende funktionalen Abhängigkeiten bestehen:

• (ReNr, PosNr) => ArtNr: Da es pro Rechnungsposition nur einen Artikel gibt.
• (ReNr, PosNr) => Anzahl: Anzahl der Artikel je Position.

Damit ergibt sich folgende Relation zu Rechnungspositionen, ebenfalls in 5NF:

Abbildung 2.13-6: FA-Diagramm zu Rechnungspositionen (RePos)

RePos (#(ReNr, PosNr), ArtNr, Anzahl).

Oftmals wird in Übungen obige Relation über den Zusammenhang von Rechnung und Artikeln erkannt. Da es typischerweise pro Rechnung mehrere Artikel gibt und die Artikel auch auf mehreren Rechnungen auftauchen (ein bestimmtes Sofa, das hundert mal verkauft wurde) wird dabei dann zuerst eine Verbindungsrelation mit dem Schlüssel (ReNr, ArtNr) eingerichtet. Dann wird die PosNr zu einem beschreibenden Attribut der Relation. Insgesamt also:

Alternativer Weg

RePos (#(ReNr, ArtNr), PosNr, Anzahl) //Alternative

Relationale Verknüpfungen

In dem Lösungsweg sind nun sechs Relationen entstanden, die wesentliche Merkmale der Rechnung beschreiben. Zu prüfen sind aber noch die die relationalen Verknüpfungen und damit die Schlüssel/Fremdschlüssel – Beziehungen.

• Zwischen Kunden und ReKöpfe: Hier liegt sicherlich eine Beziehung vor. Ein Kunde hat u.U. viele Rechnungen mit dem Unternehmen, aber eine Rechnung bezieht sich immer nur auf einen Kunden. Diese 1:n - Beziehung kann verankert werden, indem in ReKöpfe die Kundennummer als Fremdschlüssel festgehalten wird.

ReKöpfe (#ReNr, ReDatum, KVDAT, Tour, Verkäufer, DatumLief, ZV, MWStB, KuNr)

Damit ist auch festgelegt, dass es keinen Rechnungskopf ohne Kundennummer gibt (denn ein Fremdschlüssel darf nie leer bleiben). Wenn wir annehmen, dass in der Datenbank nur Kunden erfasst sind, die schon gekauft haben, gelten die Min-/Max-Angaben von Kunden zu ReKöpfe 1,n : 1,1.

• Zwischen Kunden und Artikel: Hier gibt es auf der Ebene der Relationen keine direkte Beziehung. Die Beziehung manifestiert sich durch die Rechnung und ihre Positionen. Wenn man sie trotzdem einrichtet, um z.B. im Rahmen des Kundenbeziehungsmanagements (Customer Relationship Management; CRM) schnellen Zugriff auf die vom Kunden schon getätigten Käufe zu haben, ist das möglich. Dafür müsste eine Verbindungsrelation eingerichtet werden.
• Zwischen Kunden und RePos (Rechnungspositionen): Auch hier gibt es auf der Ebene der Relationen keine Beziehung. Die Verknüpfung erfolgt über die Rechnung.
• Zwischen ReKöpfe und Artikel: Dieser Zusammenhang wird über die RePos hergestellt.
• Zwischen ReKöpfe und RePos: Diese Beziehung ist natürlich fundamental. Es ist eine 1:n - Beziehung, denn eine Rechnung kann mehrere Positionen haben, eine Rechnungsposition gehört aber immer zu einer bestimmten Rechnung. Damit handelt es sich bei diesem Muster um eine Komposition. Diese Beziehung wurde aber schon bei der Festlegung des Schlüssels von RePos festgelegt. Es muss lediglich noch die ReNr als Fremdschlüssel gekennzeichnet werden:

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

Komposition bedeutet ja Existenzabhängigkeit, die hier ganz klar zu erkennen ist. Da ein zusammengesetzter Schlüssel, wie hier (ReNr, PosNr), immer vollständig sein muss, kann es keine Rechnungsposition ohne zugehörigen Rechnungskopf geben. Und: Wird ein Rechnungskopf gelöscht, müssen auch die verbundenen Rechnungspositionen gelöscht werden. Die Min-/Max-Angaben sind 1,1 : 1,n, von RePos ausgehend.

• Zwischen Artikel und Rechnungspositionen (RePos): Auch hier liegt eine 1:n - Beziehung vor. Ein Artikel kommt hoffentlich auf vielen Rechnungspositionen vor und eine Rechnungsposition erfasst genau einen Artikel. Die Min-/Max-Angabe von 1,1 auf der Seite der Rechnungspositionen ist hier besonders sinnvoll, denn es hat keinen Sinn, Rechnungspositionen ohne Artikel zu erfassen. Damit kann die Verknüpfung durch Übernahme der ArtNr in die Relation RePos eingerichtet werden. Da dies oben schon geschehen ist (falls nicht, würde das Defizit spätestens hier erkannt), muss lediglich noch die Kennzeichnung von ArtNr als Fremdschlüssel erfolgen:

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

Die funktionalen Abhängigkeiten sind in allen Relationen bereits geklärt, da ja die Attribute so zu Relationen gruppiert wurden, dass jeweils ein Schlüssel und die von ihm voll funktional abhängigen Attribute zusammen kamen. Da keine überlappenden Schlüssel auftreten, ist die BCNF auch gesichert. Da darüber hinaus die in der vierten und fünften Normalform angesprochenen Probleme nicht auftreten, befinden sich alle Relationen in 5NF.

Idealstruktur - redundanzfrei

Die folgende Abbildung zeigt die grafische Darstellung des Datenmodells.

Abbildung 2.13-7: Relationales Datenmodell Rechnungsstellung Stufe 1

Hier noch die textlichen Notationen - im Zusammenhang:

2.13.3 Lösung Stufe 1

ArtBeschr(#ArtNr, Beschr)

Artikel (#ArtNr, ArtBez, Standort, LiPreis)

Kunden (#KuNr, Anrede, Name, VName, PLZ, Ort, Straße)

KuTel(#(KuNr, Tel))

ReKöpfe (#ReNr, ReDatum, KVDAT, Tour, Verkäufer, DatumLief, ZV, MWStB, KuNr)

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

2.14 Rechnungsstellung Stufe 2

2.14.1 Anforderungsbeschreibung

Hier soll das Überarbeiten eines Datenmodells thematisiert werden. Dies ist eine Standardaufgabe, denn ein Anwendungsbereich verändert sich ständig und wenn dies geschieht, muss das Datenmodell und dann die Datenbank angepasst werden.

Überarbeiten

Das folgende Datenmodell aus obiger Aufgabe ist der Ausgangspunkt. Wie zu Beginn von Aufgabe 3.11 erläutert, beschreibt es einen Anwendungsbereich zur Rechnungsstellung:

ArtBeschr(#ArtNr, Beschr)

Artikel (#ArtNr, ArtBez, Standort, LiPreis)

Kunden (#KuNr, Anrede, Name, VName, PLZ, Ort, Straße)

KuTel(#(KuNr, Tel))

ReKöpfe (#ReNr, ReDatum, KVDAT, Tour, Verkäufer, DatumLief, ZV, MWStB, KuNr)

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

In Stufe 2 wird nun zwischen Liefer- und Rechnungsadresse unterschieden und es soll gelten: Ein Kunde kann beliebig viele Adressen haben, jede kann bei einer Rechnung Liefer- oder Rechnungsadresse sein.

Liefer- und Rechnungs­adresse

2.14.2 Lösungsschritte

Da es nun mehrere Adressen je Kunde geben kann ist eine Folge dieser neuen Anforderungen, dass die alte Relation Kunden verkürzt wird, da die Adressattribute in eine eigene Relation Adressen gehen. Übrig bleiben KuNr, Name, VName, so dass daraus die neue Kundenrelation entsteht:

Kunden (#KuNr, Name, Vorname)

Die neue Relation Adressen erhält zusätzlich einen Schlüssel Adressnummer (AdrNr), denn einen Schlüssel braucht jede Relation:

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

Nun fehlt noch die Verknüpfung zwischen den Kunden und Adressen. Deren Wertigkeit ist n:m, denn ein Kunde kann ja mehrere Adressen haen und unter einer Adresse wohnen u.U. mehrere Kunden (Mehrfamilienhäuser). Es wird also eine Verbindungsrelation Kunden/Adressen benötigt. Sie wird KuAdr genannt:

KuAdr (#(KuNr, AdrNr))

Beide Attribute wurden gleich als Fremdschlüssel gekennzeichnet. Damit ist im Datenmodell die Beziehung zwischen Kunden und Adressen festgehalten. Die Min-/Max-Angaben sind 1,n : 1,m, da nur Kunden mit Adressen und nur Adresen mit Kunden erfasst werden wollen.

Bleibt noch zu klären, wie festgehalten wird, welche bei einer bestimmten Lieferung die Liefer- und welche die Rechnungsadresse ist. Bisher war diesbezüglich ja einfach die KNr als Fremdschlüssel in ReKöpfe hinterlegt.

Eine sinnvolle Lösung ist, für jede Lieferung die drei Relationen Kunden, Adressen und Rechnungsköpfe zu verknüpfen und bei jeder Verknüpfung festzuhalten, ob es sich um die Liefer- oder die Rechnungsadresse handelt (hier mit dem Attribut Typ). Dann kann es pro Lieferung eine oder zwei solche Verknüpfungen geben, je nachdem, wieviele Adressen der Kunde angegeben hat. Die Relation hat damit drei Fremdschlüssel:

Lieferungen (#(KuNr, AdrNr, ReNr), Typ)

Das Attribut Typ hat die Ausprägungen L(ieferadresse) und R(echnungsadresse). R gibt es immer, L nur, falls es eine extra Lieferanschrift gibt. Ansonsten ist die Rechnungsanschrift gleich der Lieferanschrift. Diese Semantik muss über die Datenbankprogrammierung sichergestellt werden. Die folgende Tabelle zeigt zur Verdeutlichung einige Beispielsdaten:

Zur Veranschaulichung wurde in den Daten auch der Fall mit eingefügt, dass unter einer Adresse mehrere Kunden wohnen (Rechnungsnummern 2002 und 2020).

Die Relation KuAdr wird jetzt eigentlich nicht mehr benötigt. Die Beziehung zwischen Kunden und Adressen könnte auch aus Lieferungen gewonnen werden. Da es aber oftmals sinnvoll ist, die Adressen von Kunden auch ohne die Rechnungen/Lieferungen ansprechen zu können, z.B. bei Marketingmaßnahmen oder ganz allgemein im Customer Relationship Management (CRM), soll sie drin bleiben.

Pragmatik

Die Wertigkeiten bei der dreistelligen Beziehung Lieferungen ergeben sich – von Lieferungen ausgehend – zu Kunden, Adressen und ReKöpfe wie folgt: Kardinalität 1,1, Min-/Max-Angabe 1,1 : 0,n (falls ein Kunde vor seiner ersten Lieferung erfasst werden kann).

2.14.3 Lösung