Hier beginnt Teil V: Beispiele relationaler Datenmodelle

mit den Kapiteln

16 Modellierungsbeispiele mit Lösungsweg

17 Weitere Modellierungsbeispiele

Mit den folgenden Beispielen soll auch der Entstehungsprozess eines Datenmodells gezeigt werden - seine Entwicklung "Schritt um Schritt". Dabei werden unterschiedliche Vorgehensweisen vorgestellt. Wie immer in diesem Text bezeichnet folgende Formatierungen ein Attribut, eine Relation und einen Anwendungsbereich.

16.1 Rechnungsstellung

Mit diesem Beispiel wird die Erstellung eines relationalen Datenmodells für den Zweck der Rechnungsstellung gezeigt. Ausgangspunkt ist dabei die in der folgenden Abbildung angegebene Rechnung , also ein Geschäftsobjekt (business object), was in der Datenmodellierung durchaus oft der Fall ist. Es gelten - neben der üblichen kaufmännischen Semantik von Rechnungen - die folgenden Bedingungen und semantischen Festlegungen:

Rechnungen

• 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.
• TOUR bezeichnet das Auslieferungsteam (Tour).
• KVDAT gibt den Tag an, an dem die Kundschaft im Möbelhaus war und die Ware bestellt hat (Kvdat).
• 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)

Diese Aufgabe wird mit unterschiedlichen Komplexitätsgraden in drei Stufen gelöst:

• Aufgabe Stufe 1 - Grundstruktur: Für jeden Kunden wird nur eine Anschrift, die Rechnungsanschrift, erfasst. Es wird keine zeitliche Dimension berücksichtigt, d.h. alte Rechnungen müssen nicht aus der Datenbank heraus reproduzierbar sein.
• Aufgabe Stufe 2 - Beliebige Rechnungs- und Lieferadresse: Für jeden Kunden werden beliebig viele Adressen erfasst. Bei jedem Kauf kann ein Kunde eine beliebige seiner Adressen als Lieferadresse bzw. als Rechnungsadresse angeben.
• Aufgabe Stufe 3 - Zeitachse: Einfügen einer zeitlichen Dimension. Die Rechnungen sollen über die Zeit gerettet werden, d.h. es soll möglich sein, beliebige Rechnungen der Vergangenheit aus der Datenbank heraus zu reproduzieren. Also z.B. eine Rechnung vom 20. November 2012 mit den damaligen Preisen, der damaligen Mehrwertsteuer, usw.

Rechnungsstellung Stufe 1

Für die Stufe 1 sammeln wir zuerst die Attribute ein und bestimmen die Determinanten und funktionalen Abhängigkeiten (ein bei Geschäftsobjekten sinnvolles Vorgehen):

Von den Attributen ausgehend modellieren

• 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
• ZV: Zahlungsvereinbarung
• LiPreis: Listenpreis. Der Preis für die gesamte Position wird berechnet aus Anzahl und Preis.

Für die meisten Artikel liegt noch eine Beschreibung vor (Beschr), die aber nicht auf der Rechnung ausgegeben wird. Der Mehrwertsteuersatz wird im Programm hinterlegt, der Mehrwertsteuerbetrag (MWStB) wird dann daraus und aus der Rechnungssumme berechnet.

Was kann man nun, auch unter Berücksichtigung der ja immer vorliegenden Objekt-/Beziehungsstruktur von den Attributen ableiten? Problemlos zu erkennen sind die Kunden: als Objekte, Objektklasse und als Relation. Identifiziert werden sie durch die KuNr. Diese ist hier also erstmals Determinante. Voll funktional abhängig von dieser sind die folgenden Attribute:

Objekte und Beziehungen finden

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

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

Jeder Kunde kann mehrere Telefonanschlüsse haben. Dies wird durch die folgende Relation erfasst:

KuTel (#(KuNr, Tel))

Beide Relationen sind bereits in 5NF. Ähnlich einfach ist das Erkennen der Rechnung als Modellelement. Bei genauerem Hinsehen erkennt man aber, dass es eine Unterscheidung geben muss zwischen Rechnungskopf (identifiziert durch die Rechnungsnummer (ReNr)) und den Rechnungspositionen, denn es gibt pro Rechnung mehrere Positionen. Folgende funktionalen Abhängigkeiten bestehen von der Determinante ReNr:

Rechnungskopf vs. Rechnungspositionen

• 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 => ZV: Die Zahlungsvereinbarung ist je Rechnung eindeutig. Trotz Nachfragen konnte auch keine weitere Semantik (z.B. Abhängigkeit vom gekauften Produkt) festgestellt werden.

Ergänzt man noch das Datum der Lieferung (DatumLief) und den Mehrwertsteuerbetrag (MWStB) ergibt sich folgende Relation zu den Rechnungsköpfen:

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

Auch diese ist in 5NF. Die letzten leicht erkennbaren Objekte sind die Artikel. Auch sie werden identifiziert (ArtNr), haben eine Bezeichnung (ArtBez) und werden beschrieben. Allerdings liegt nicht zu jedem Artikel eine Beschreibung vor. ArtNr ist also Determinante mit folgenden funktional abhängigen Attributen:

Artikel in zwei Relationen

• ArtNr => ArtBez
• 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 folgenden Relationen:

Artikel (#ArtNr, ArtBez, LiPreis, Standort)

Für die Artikel mit Beschreibung wird eine eigene Relation angelegt, da es sich um eine Teilmenge aller Artikel handelt und damit insgesamt um eine Generalisierung/Spezialisierung (Gen/Spez):

Muster Gen/Spez

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. Ihre Verarbeitung macht bei ungeübten Modellierern regelmäßig Schwierigkeiten. Hier muss erkannt werden, dass das zu modellierende Realweltphänomen das kaufmännische Konstrukt der Rechnungspositionen ist. Wird dies erkannt, ist der Rest einfach. Rechnungspositionen werden durch eine Attributskombination identifiziert: (ReNr, PosNr). Folgende funktionalen Abhängigkeiten bestehen:

Rechnungspositionen - kaufmännische Semantik

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

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)

In dem Lösungsweg hier sind nun sechs Relationen entstanden, die wesentliche Merkmale der Rechnung beschreiben. Zu prüfen sind aber noch die Schlüssel und Fremdschlüssel, d.h. die relationalen Verknüpfungen:

Relationale Verknüpfungen

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

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

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

• Zwischen Artikel und Rechnungspositionen (RePos): Hier liegt wiederum 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.

Hier noch die textlichen Notationen - im Zusammenhang:

ArtBeschr (#ArtNr, Beschr)

Lösung Stufe 1

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)

Rechnungsstellung Stufe 2

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. Eine Folge dieser Festlegung ist, dass die alte Relation Kunden verkürzt wird, da die Adressattribute in die Relation Adressen gehen. Übrig bleiben KuNr, Name, VName, so dass daraus die neue Kundenrelation entsteht:

Adressen

Kunden (#KuNr, Name, Vorname)

Adressen werden zu einer eigenen Relation. Ergänzt wird ein Schlüssel Adressnummer (AdrNr), denn einen Schlüssel braucht jede Relation:

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

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

KuAdr (#(KuNr, AdrNr))

Beide Attribute wurden gleich als Fremdschlüssel gekennzeichnet. Damit ist im Datenmodell die Beziehung zwischen Kunden und Adressen festgehalten. 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:

KuAdrRe (#(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. 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. Da es aber oftmals sinnvoll ist, die Adressen von Kunden auch ohne die Rechnungen ansprechen zu können, z.B. bei Marketingmaßnahmen oder ganz allgemein im Customer Relationship Management (CRM), soll sie drin bleiben. Damit ergibt sich das grafische Datenmodell der folgenden Abbildung.

Die Wertigkeiten bei der dreistelligen Beziehung KuAdrRe ergeben sich wie folgt, wie immer bei mehrstelligen Beziehungen von der Verbindungsrelation aus gesehen: 1,1 : 1:1 : 1,1 (An einer Beziehung nimmt genau eine Kundennummer, eine Adressnummer und eine Rechnungsnummer teil).

Wertigkeiten

Hier das Gesamtmodell nach Stufe 2 in textlicher Notation:

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

Lösung Stufe 2

ArtBeschr (#ArtNr, ArtBeschr)

Artikel (#ArtNr, ArtBez, Standort, LiPreis)

KuAdr (#(KuNr, AdrNr))

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

Kunden (#KuNr, Anrede, Name, Vorname)

KuTel (#(KuNr, Tel))

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

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

Rechnungsstellung Stufe 3

In der folgenden dritten Stufe soll nun die zeitliche Dimension hinzugefügt werden und zwar mit dem Ziel, die Rechnungen der vergangenen Jahre aus der Datenbank heraus reproduzierbar zu halten, auch wenn sich die Stammdaten verändern. Bei einer Rechnungsstellung entstehen ja Daten zum kaufmännischen Vorgang, die auch nicht mehr verändert werden. Z.B. Rechnungsnummer, Rechnungsdatum, Artikelbeschreibung, Positionssummen, Gesamtsumme. Andere Daten werden mit Hilfe der durch das Datenmodell vorgegebenen Struktur im Moment der Rechnungsstellung aus den Datenbeständen geholt: zum Kunden, zu den Artikeln. Genau diese Daten können sich aber nach dem Zeitpunkt der Rechnungsstellung sehr schnell ändern:

Vgl. zur zeitlichen Dimension auch
Kapitel 15

• Der Kunde zieht um, seine Telefonnummer ändert sich, er ändert seinen Namen.
• Die Artikelpreise ändern sich, Artikel verschwinden aus dem Sortiment, ihre Bezeichnung oder auch Beschreibung ändert sich.

Und so weiter. Um sich dagegen abzusichern können die "vergänglichen" Attribute bzw. deren Ausprägungen zum Zeitpunkt der Rechnungsstellung (RZ; Rechnungsstellungszeitpunkt) festgehalten werden. Dazu werden diese Attribute an geeigneter Stelle im Datenmodell angelegt und dann in der Datenbank gespeichert.

Folgende Attribute müssen bezüglich der Kunden über die Zeit "gerettet" werden: Name, Vorname, PLZ, Ort, Straße. Dies geschieht, indem sie mit dem Zusatz "RZ" zusätzlich aufgenommen werden. Doch in welcher Relation soll man sie unterbringen? Hier hilft die Überlegung, von welcher Determinante diese Attribute funktional abhängig sind. Natürlich von der Rechnungsnummer, also gehören sie in die Relation Rechnungsköpfe. Da sich der Mehrwertsteuersatz ja auch regelmäßig ändert und auf der Rechnung ausgewiesen ist, muss auch er "konserviert" werden. Auch er ist von der Rechnungsnummer funktional abhängig. Somit ergibt sich:

Zu "rettende" Kundendaten

ReKöpfe (#ReNr, ReDatum, KVDAT, Tour, Verkäufer, DatumLief, ZV, MWStB, Name-RZ, VName-RZ, PLZ-RZ, Ort-RZ, Straße-RZ, Tel-RZ, MWStS-RZ)

Folgende "vergänglichen" Attribute bezüglich der Artikel sollten, da sie auf der Rechnung erscheinen, verdoppelt werden: Artikelnummer, Artikelbezeichnung, Listenpreis. Wieder hängen wir das Kürzel RZ an. Der Platz für diese Attributdoppelung ist, auch hier hilft wieder die Überlegung zu den funktionalen Abhängigkeiten und zur Determinante, die Relation Rechnungspositionen:

Zu "rettende" Artikeldaten

RePos (#(ReNr, PosNr), ArtNr, Anzahl, ArtNr-RZ, ArtBez-RZ, LiPreis-RZ)

Fassen wir das Vorgehen zusammen. Folgende Schritte sind zu leisten:

• Klären, welche Attribute wegen der notwendigen Reproduzierbarkeit dupliziert werden müssen.
• Feststellen, wo diese Attribute platziert werden können durch Klärung der Frage, wovon sie funktional abhängig sind.

Hier nun das gesamte Datenmodell der Stufe 3 in textlicher Notation:

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

ArtBeschr (#ArtNr, ArtBeschr)

Artikel (#ArtikelNr, ArtBez, Standort, LiPreis)

KuAdr (#(KuNr, AdrNr))

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

Kunden (#KuNr, Anrede, Name, Vorname)

KuTel (#(KuNr, Tel))

ReKöpfe (#ReNr, ReDatum, KVDAT, Tour, Verkäufer, DatumLief, ZV, MWStB, Name-RZ, VName-RZ, PLZ-RZ, Ort-RZ, Straße-RZ, Tel-RZ)

RePos (#(ReNr, PosNr), ArtNr, Anzahl, ArtNr-RZ, ArtBez-RZ, LiPreis-RZ)

RZ : Zeitpunkt der Rechnungsstellung

Das grafische relationale Datenmodell bleibt gleich, da die duplizierten Attribute weder Schlüssel noch Fremdschlüssel sind. Mit dieser Methode des Einbindens der zeitlichen Dimension sind die "geretteten" Daten in die operative Datenbank integriert.

16.2 Sportverein

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:

Anwendungsbereich: Sportverein

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

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 o.g. deskriptiven Attribute und den Schlüssel erhalten wir folgende Relation:

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:

Pragmatische Lösung wegen zeitlicher Dimension.
Muster GenSpez

MitglEinAus (#(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
Klärung der Spezialisierung

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:

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

Die Mannschaften

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

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

Abteilungen

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.

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)

Spieler

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

AMSp (#(MaNr, MiNr))

Begegnungen

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:

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.

Insgesamt ergibt sich damit das folgende Datenmodell.

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

Textliche Notation

MitglEinAus (#(MiNr, Eintritt), Austritt)

MitglVerstorben (#MiNr, Todestag)

MitglAktiv (#MiNr, Sportart, LStufe)

MitglPassiv (#(MiNr, BezTät))

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

AMSp (#(MaNr, MiNr))

Abteilungen (#AbtNr, AbtBez, AbtLeiter)

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

Grafische Notation des Datenmodells:

AbtNr: Abteilungsnummer

AbtLeiter: Abteilungsleiter

MaNr: Mannschaftsnummer

MiNr: Mitgliedsnummer

TrNr: Trainernummer

KapNr: Kapitänsnummer

LStufe: Leistungsstufe

BezTät: Bezeichnung der ehrenamtlichen Tätigkeit

Zur konkreten Bedeutung von Kardinalitäten und Wertigkeiten siehe Kapitel 5.

16.3 PC-Beschaffung

Anforderungen an die Datenbank

In einem Unternehmen soll der Vorgang der PC-Beschaffung durch eine Datenbank festgehalten werden. Folgende Festlegungen ergaben sich in den Interviews, die im Vorfeld mit den Betroffenen geführt wurden:

• Jeder PC erhält eine Inventarnummer (InvPC), ebenso die Bildschirme (InvBS). Jedem PC ist genau ein Bildschirm zugeordnet.
• Für jeden PC wird folgendes festgehalten: der Prozessortyp (Proz), die Größe des Arbeitsspeichers (ArbSp), ob ein optisches Laufwerk (DVD, CD-ROM, usw.) vorhanden ist und welche Bezeichnung und Geschwindigkeit (BezLW bzw. Geschw) es hat. Es können durchaus mehrere optische Laufwerk eines Typs in einen PC eingebaut sein (z.B. zu Archivierungszwecken), so dass auch die Anzahl festgehalten wird. Natürlich gibt es einen Laufwerkstyp durchaus in verschiedenen Rechnern.
• Für alle PCs wird festgehalten, ob Programmiersprachen (PS) installiert sind und falls ja, welche. Für die PCs der Entwickler wird die hauptsächlich verwendete Entwicklungsumgebung (EntwUmg) festgehalten.
• In diesem Unternehmen wird vor der Übergabe des PC an den Nutzer durch die IT geprüft, ob das Gehäuse, die jeweilige Hauptplatine und die Grafikkarte für die Anforderungen des Nutzers geeignet sind. Falls nicht, werden sie ausgetauscht. Deshalb werden diese drei Komponenten in der Datenbank ausgewiesen. Alle mit ihrer Bezeichnung (BezGH, BezHP, BezGK), die Gehäuse noch mit Größenangaben (Größe), die Hauptplatinen mit der Anzahl der Prozessoren (AnzProz) und die Grafikkarten mit ihrer maximalen Auflösung (Auflösung). Natürlich kommt es vor, dass diese Komponenten in mehreren PC eingebaut werden.
• Für jede Festplatte wird die Bezeichnung (BezPl), die Speicherkapazität (Größe) sowie die Zugriffsgeschwindigkeit (Zugriff) erfasst. Jede Festplatte erhält von der IT-Abteilung eine eindeutige Seriennummer (SerNrF), angelehnt an die des Festplattenherstellers und wird ausführlich getestet. Das Ergebnis, ein Qualitätskoeffizient (Qual), wird auch festgehalten. Es kommt durchaus vor, dass ein PC mehrere Festplatten hat, aber nicht umgekehrt.
• Außerdem werden jeweils mit Hilfe einer Kurzbezeichnung (KBezSK) die im PC enthaltenen sonstigen Komponenten (W-LAN-Komponente, Kamera, usw.) festgehalten. Natürlich kommt eine bestimmte Komponente in mehreren PCs vor. Außerdem hat ein PC typischerweise mehrere solcher "sonstigen Komponenten".
• Für jeden ins Unternehmen gegebenen PC wird weiterhin festgehalten, wer ihn nutzt, erfasst über die Personalnummer (PersNr), Name, Vorname (VName) sowie Telefonnummer (Tel) und wann er dort eingerichtet wurde (DatEinr). Ein bestimmter PC wird immer von genau einem Angestellten genutzt, ein Angestellter kann bis zu zwei PC zugeordnet bekommen.
• Für Bildschirme wird neben der Bezeichnung (BezBS) noch festgehalten, von welcher Art (Art) sie sind, welchen Durchmesser sie haben (Zoll) und wann sie übergeben wurden (DatÜb).

Mit diesem Beispiel soll auch nochmals auf das Muster Einzel/Typ hingewiesen werden. Vgl. dazu Abschnitt 14.2.

Einzelgerät vs. Typ

Lösungsweg

Zur Erstellung des Datenmodells werden - Schritt um Schritt - nochmals die Anforderungen betrachtet, jeweils etwas eingerückt.

Jeder PC erhält eine Inventarnummer (InvPC), ebenso die Bildschirme (InvBS). Jedem PC ist genau ein Bildschirm zugeordnet.

Anforderung Teil 1

Für jeden PC wird folgendes festgehalten: der Prozessortyp (Proz), die Größe des Arbeitsspeichers (ArbSp), ob ein optisches Laufwerk (DVD, CD-ROM, usw.) vorhanden ist und welche Bezeichnung und Geschwindigkeit (BezLW bzw. Geschw) es hat. Es können durchaus mehrere optische Laufwerk eines Typs in einen PC eingebaut sein (z.B. zu Archivierungszwecken), so dass auch die Anzahl festgehalten wird. Natürlich gibt es einen Laufwerkstyp durchaus in verschiedenen Rechnern.

Für alle PCs wird festgehalten, ob Programmiersprachen (PS) installiert sind und falls ja, welche. Für die PCs der Entwickler wird die hauptsächlich verwendete Entwicklungsumgebung (EntwUmg) vermerkt.

Da PCs nicht nur identifiziert, sondern auch beschrieben werden, stellen sie eine Relation dar. Mit den Attributen, die im Text genannt werden und die "keine Probleme" machen ergibt sich der nachfolgende Erstentwurf.

Relation PC

Die Bildschirme tauchen hier nur mit einem identifizierenden Attribut auf. Ein Blick weiter nach unten in der Beschreibung zeigt, dass sie weiter beschrieben werden. Also können wir auch dafür eine Relation anlegen. Außerdem ist angegeben, dass jedem PC ein Bildschirm zugeordnet ist, so dass wir auch gleich in PC einen Fremdschlüssel einfügen können.

PC (#InvPC, InvBS, Proz, ArbSp, ...)

BS-Einzeln (#InvBS, ...)

Die optischen Laufwerke werden selbst existent, weil sie identifiziert und beschrieben werden. Zu beachten ist, dass sie auf Typebene erfasst sind, was auch im Schlüssel ("Bezeichnung") zu erkennen ist. Mit der Festlegung, dass ein PC auch mehrere optische Laufwerke enthalten kann, ergibt sich damit [Anmerkung] :

Optische Laufwerke,
auf Typebene

OptLw (#BezLW, Geschw)

OptLwPC (#(BezLW, InvPC), Anzahl)

Man beachte die eingeschränkte Aussagekraft einer solchen Modellierung. Festgehalten wird nicht, welche konkreten Laufwerke in den PC eingebaut sind, sondern nur, wieviele verschiedene Laufwerkstypen. Schon bei der Angabe eines einzigen Typs können dies beliebig viele konkrete Laufwerke sein.

Die Installation der Programmiersprachen wird durch eine eigene Relation festgehalten. Der Schlüssel ergibt sich daraus, dass auf einem PC mehrere Programmiersprachen und eine Programmiersprache auf mehreren PCs installiert ist.

PS-Install (#(InvPC, ProgSpr))

Die Hinweise auf die PCs der Entwickler führen zu einer Spezialisierung. Es entsteht eine eigene Relation mit dem zusätzlichen Attribut.

Muster Gen/Spez

EntwPC (#InvPC, EntwUmg)

Bei den Bildschirmen klärt sich die Modellierungssituation im letzten Teil der Anforderungsliste:

Bildschirme

Für Bildschirme wird neben der Bezeichnung (BezBS) noch festgehalten, von welcher Art (Art) sie sind, welchen Durchmesser sie haben (Zoll) und wann sie übergeben wurden (DatÜb).

Anforderung Teil 2

Damit ergibt sich, dass zu Beginn zu Recht die Einzelinformation zu Bildschirmen angelegt wurde (lag ja auch nahe, angesichts des Schlüssels InvBS). Insgesamt ergeben die Attribute aber auch noch eine Relation mit Typinformation zu den Bildschirmen:

Muster Einzel/Typ

BS-Einzeln (#InvBS, BezBS, DatÜb)

BS-Typen (#BezBS, Art, Zoll)

Der Fremdschlüssel ist nötig, damit die Einzelinformationen mit den Typinformationen verknüpft werden können. Der nächste Abschnitt der Spezifikation legt fest, welche Komponenten auf welche Weise erfasst werden.

Komponentenpräzisierung

In diesem Unternehmen wird vor der Übergabe des PC an den Nutzer durch die IT geprüft, ob das Gehäuse, die jeweilige Hauptplatine und die Grafikkarte für die Anforderungen des Nutzers geeignet sind. Falls nicht, werden sie ausgetauscht. Deshalb werden diese drei Komponenten in der Datenbank ausgewiesen. Alle mit ihrer Bezeichnung (BezGH, BezHP, BezGK), die Gehäuse noch mit Größenangaben (Größe), die Hauptplatinen mit der Anzahl der Prozessoren (AnzProz) und die Grafikkarten mit ihrer maximalen Auflösung (Auflösung). Natürlich kommt es vor, dass diese Komponenten in mehreren PC eingebaut werden.

Anforderung Teil 3 -.

Da alle drei Komponenten mit ihren Bezeichnungen erfasst werden, liegt Typinformation vor. Es handelt sich um eine 1:n-Beziehung zwischen den Komponenten und den PCs, woraus sich die Schlüssel ergeben.

1:n-Beziehung und Muster Einzel/Typ

Gehäuse (#(BezGH, InvPC), Größe)

Grafikkarten (#(BezGK, InvPC), Auflösung)

Hauptplatinen (#(BezHP, InvPC), AnzProz)

Auch die Festplatten werden so beschrieben, dass sie eigene Relationen bilden und dass Einzel- und Typinformation vorhanden ist.

Festplatten

Für jede Festplatte wird die Bezeichnung (BezPl), die Speicherkapazität (Größe) sowie die Zugriffsgeschwindigkeit (Zugriff) erfasst. Jede Festplatte erhält von der IT-Abteilung eine eindeutige Seriennummer (SerNrF), angelehnt an die des Festplattenherstellers und wird ausführlich getestet. Das Ergebnis, ein Qualitätskoeffizient (Qual), wird auch festgehalten. Es kommt durchaus vor, dass ein PC mehrere Festplatten hat, aber nicht umgekehrt.

Anforderung Teil 4

Es ergeben sich die entsprechenden Relationen. Hier soll zusätzlich der Frage nachgegangen werden, wie in einem solchen Fall - wenn also Einzel- und Typinformation vorliegt - die Verknüpfung mit dem restlichen Modell (hier PC) vorgenommen wird. Grundsätzlich ist beides möglich, allerdings ist die Verknüpfung mit Typinformation ungenau. Dabei würde nur erfasst, welcher Plattentyp in einem PC installiert ist. Wird dagegen mit Hilfe der Einzelinformation verknüpft, kann genau festgehalten werden, welche und wieviele Festplatten im PC sind. Deshalb wird hier dieseVorgehensweise gewählt. Da eine einzelne Festplatte nur in einem einzigen PC sein kann, handelt es sich um eine 1:n-Beziehung, die durch den Fremdschlüssel InvPC in FP-Einzeln ausgedrückt wird.

Relationale Verknüpfung mit Typ- oder Einzelinformation

FP-Einzeln (#SerNrF, Qual, BezPL, InvPC)

FP-Typen (#BezPl, Größe, Zugriff)

Der folgende Ausschnitt aus der Spezifikation klärt das Umfeld der im Unternehmen eingesetzten PCs.

Außerdem werden jeweils mit Hilfe einer Kurzbezeichnung (KBezSK) die im PC enthaltenen sonstigen Komponenten (W-LAN-Komponente, Kamera, usw.) festgehalten. Natürlich kommt eine bestimmte Komponente in mehreren PCs vor. Außerdem hat ein PC typischerweise mehrere solcher "sonstigen Komponenten".

Anforderung Teil 5

Auch hier wird wieder auf Typebene modelliert, so dass sich die folgende Relation ergibt.

Sonstige Komponenten

SK (#(KBezSK, InvPC)) //SK : Sonstige Komponenten

Abschließend wird in der Spezifikation beschrieben, wie die Nutzung und Einrichtung datenbankmäßig modelliert wird.

Für jeden ins Unternehmen gegebenen PC wird weiterhin festgehalten, wer ihn nutzt, erfasst über die Personalnummer (PersNr), Name, Vorname (VName) sowie Telefonnummer (Tel) und wann er dort eingerichtet wurde (DatEinr). Ein bestimmter PC wird immer von genau einem Angestellten genutzt, ein Angestellter kann bis zu zwei PC zugeordnet bekommen.

Anforderung Teil 6 - Nutzung

Die Nutzer werden über die Personalnummer erfasst und durch einige weitere Attribute beschrieben.

Nutzer (#PersNr, Name, VName, Tel)

Bleibt die Einrichtung des PCs. Angesichts der Festlegung der Min-/Max-Angaben wird das Attribut PersNr zu einem Bestandteil von PC. Auch das Datum der Einrichtung kann in diese Relation eingefügt werden, die sich damit wie folgt ergibt:

PC (#InvPC, InvBS, Proz, ArbSp, PersNr, DatEinr)

Damit sind die Relationen des Datenmodells zusammengestellt. Auch die relationalen Verknüpfungen sind schon angelegt.

Das gesamte relationale Datenmodell

Zuerst die textliche Notation:

BS-Einzeln (#InvBS, BezBS, DatÜb)

BS-Typen (#BezBS, Art, Zoll)

EntwPC (#InvPC, EntwUmg)

FP-Einzeln (#SerNrF, Qual, BezPL, InvPC)

FP-Typen (#BezPl, Größe, Zugriff)

Gehäuse (#(BezGH, InvPC), Größe)

Grafikkarten (#(BezGK, InvPC), Auflösung)

Hauptplatinen (#(BezHP, InvPC), AnzProz)

Nutzer (#PersNr, Name, VName, Tel)

OptLw (#BezLW, Geschw) //Typebene

OptLwPC (#(BezLW, InvPC), Anzahl) //Typebene

PC (#InvPC, InvBS, Proz, ArbSp, PersNr, DatEinr)

PSInstall (#(InvPC, ProgSpr))

SK (#(KBezSK, InvPC)) //Sonstige Komponenten

Die folgende Abbildung zeigt die grafische Fassung des Datenmodells.

HP: Hauptplatine, Motherboard

EntwPC: Entwickler-PC

16.4 Fachliteratur

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 Beitrag 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 teilweise unterschiedlich beschrieben werden. Zum Beispiel in einer Literaturliste, wie sie bei einer akademischen Abschlussarbeit meist anfällt:

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

Beispiele für eine Monographie (Mono)

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

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

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

Beispiel für einen Sammelband (SB)

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.

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

Beispiele für einen Beitrag in einem Sammelband (SBB)

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.

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

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

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.

Grundstruktur

Bevor wir in die eigentliche Modellierung einsteigen, hier einige Ausführungen zur Erfassung von Fachliteratur und zu den einzelnen Arten, die es hier gibt. 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. Jedes Werk hat eine Person bzw. Organisation (Forschungseinrichtungen, Behörden, ... oder mehrere (schon bald Programme!), die es verfasst haben. Diese Autoren werden ebenfalls erfasst und durch eine Autorennummer identifiziert (AutorNr). Da es zwei Gruppen von Autoren mit teilweise abweichenden Attributen gibt, müssen dafür zwei verschiedene Relationen angelegt werden, Organisationen als Autoren (Aut-Org) und Personen als Autoren (AutPers). Es entsteht also eine Gen/Spez-Hierachie.

Werke – Autoren - Autorenschaft

In die Generalisierung kommt der Name (bei Personen) bzw. die Unternehmensbezeichnung. Dieses Attribut wird hier Id1 genannt. In den beiden Spezialisierungen folgen dann die übrigen beschreibenden Attribute. BezInst (Bezeichnung Institution) sollen die Attribute zur weiteren Bezeichnung der Organisation genannt werden.

Generalisierung / Spezialisierung (GenSpez)

Werke und Autoren sind durch die Autorenschaft verbunden: Hier wird festgehalten, wer welches Werk verfasst hat. Da es sich um eine n:m-Verknüpfung handelt, ergibt sich eine Verbindungsrelation. Das folgende Modellfragment gibt diesen "Kern" des Datenmodells an.

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

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:

Autoren (#AutorNr, Id1)

AutPers (#AutorNr, VName, Anrede)

AutOrg(#AutorNr, BezOrg2, BezOrg3)

Werke (#WerkNr, ...)

Autorenschaft (#(AutorNr, WerkNr), Rang)

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

Muster Komposition. 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 [Anmerkung] .

Komposition zwischen SBB und SB, als 1:n-Beziehung

Zeile K ...

zeigt, dass die Zeitschriftenaufsätze ebenfalls eine spezifisches 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)

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.

Wertigkeiten

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)

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.

"Wieviele Werke liegen zu jedem Fachgebiet vor"

AnzFG (#Fachgebiet, Anzahl)

Das gesamte Datenmodell

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

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.

Grafische Notation

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

16.5 Hochschule – Vorlesungsbetrieb

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

• Für die Lehrveranstaltungen eine Veranstaltungsnummer (LVNr), ihre Bezeichnung (BezV), 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.
• 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.
• 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, ...) sie arbeiten. Deren Adresse wird, für die Zusendung von Lehraufträgen usw., ebenfalls erfasst.
• 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).
• 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).
• 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 Lösungsweg

Für die Lösung werden obige Anforderungen abschnittsweise angeführt, durch Einrückung hervorgehoben und ausgewertet.

Für die Lehrveranstaltungen eine Veranstaltungsnummer (LVNr), ihre Bezeichnung (BezV), 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.

Anforderung Teil 1

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 selbst sind sofort erkennbar, da sie identifiziert und durch zahlreiche Attribute beschrieben werden (LV). 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).

Lehrveranstaltungen und ihre Termine

Auch die Räume sind oben angesprochen. Ihre Modellierung bereitet keine Probleme. Bei den Gebäude muss geprüft werden, ob sie später noch beschrieben werden. Da dies der Fall ist, wird die Gebäudebezeichnung hier als Fremdschlüssel aufgenommen.

Räume

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 festhält.

Damit ergeben sich folgende Relationen:

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

LVRaum (#(LVNr, Sem), Raum)

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

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

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

Anforderung Teil 2

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 der Grundregeln relationaler Datenmodellierung (weil diese Angabe ja erst mal nicht zur Verfügung steht), wird aber aus pragmatischen Gründen akzeptiert.

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

Damit ergibt sich zwischen Studierenden und Adressen eine 1:n-Beziehung. Da unter einer Adresse auch mehrere Studierende wohnen können, gilt auch umgekehrt eine 1:n-Beziehung, insgesamt ensteht also also eine n:m-Beziehung. Diese führt zur Relation Stud-Adr. Mit dem Attribut Art kann festgehalten werden, ob es sich um die Adresse für die Mitteilungen an die Studierenden handelt.

Damit ergeben sich folgende 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)

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, ...) sie arbeiten. Deren Adresse wird, für die Zusendung von Lehraufträgen usw., ebenfalls erfasst.

Anforderung Teil 3

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 Gen/Spez-Hierarchie vor. Die gemeinsamen Attribute sind Name, VName, Anrede und E-Mail, sie kommen in die Generalisierung (DOZ-ALLgemein). Von den externen Dozenten [Anmerkung] (DozExtern) wird nur eine einzige Adresse erfasst, somit genügt für das Festhalten der Adresse ein Fremdschlüssel in der Relation. 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. Bleiben noch die Organisationen. Sie haben eine Bezeichnung und eine Adresse, außerdem vergeben wir für sie noch einen Schlüssel. Damit kann die untenstehende Relation Organisationen angelegt werden. Mit dem Fremdschlüssel AdrNr wird diese Relation mit der zu den Adressen verknüpft.

Gen/Spez mit DozAllg, DozExt und DozHS

Damit ergeben sich folgende zusätzlichen Relationen:

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)

Organisationen (#OrgNr, Bez, AdrNr)

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.

Anforderung Teil 4

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

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

Anforderung Teil 5

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.

Noch eine Gen/Spez

Damit sind die Spezialisierungen klar. PrüfAllg ist die "oberste" Generalisierung und enthält die Attribute, die alle Relationen aufweisen. 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üfKLMP. PrüfLA erhält die Attribute zur Laborbetreuung, PrüfMP die zur prüfenden Person.

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, ArtPrüf, LVNr)

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)

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.

Anforderung Teil 6

Der letzte Teil der Anforderungen klärt die Erfassung des Prüfungsbesuchs. Dies ist wieder eine n:m-Beziehung. 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)

Das gesamte Datenmodell – 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))

LVRaum (#(LVNr, Sem), Raum)

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

Organisationen (#OrgNr, Bez, AdrNr)

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)

Das gesamte Datenmodell – graphische Fassung

16.6 Sprachenverlag

Auch in diesem Beispiel sind wieder viele "Muster" vertreten, besonders ausgeprägt aber das Muster Generalisierung / Spezialisierung (Gen/Spez).

Anwendungsbereich

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.

Wörterbücher und Übersetzungs­programme

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). Es ist grundsätzlich möglich, dass ein Wörterbuch auch nur eine Richtung abdeckt. Deshalb wird jede "Richtung" separat erfasst.

Anforderungungs­beschreibung

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

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

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

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.

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.

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.

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.

Die Entwicklung der Programme findet (natürlich) so statt, dass jedes Programm mit unterschiedlichen grafischen Bedienoberflächen (GUI) 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.

Lösungsschritte

Hier wird nun wieder die schrittweise Umsetzung des Textes in ein relationales Datenmodell dargestellt.

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). Es ist grundsätzlich möglich, dass ein Wörterbuch auch nur eine Richtung abdeckt. Deshalb wird jede "Richtung" separat erfasst.

Anforderung 1

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 und zwar als mehrwertige Attribute an dieser Relation. Damit entstehen die folgenden ersten zwei Relationen:

ProdSpr (#(ProdNr, Sprache))

Produkte (#ProdNr, Bez, LPreis, ...)

Wenn also z.B. ein Produkt "Englisch - Deutsch" und "Deutsch - Englisch" abdeckt hat es mit seiner Produktnummer (z.B. 1000) zwei Einträge:

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

Anforderung 2

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)

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

Anforderung 3

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.

Muster Gen/Spez

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.

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.

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

Anforderung 4

Anforderung 4 beschreibt die digitalen Produkte näher. Der erste Teil legt außerdem auch eine n:m-Beziehung zwischen wischen 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))

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.

Anforderung 5

Die Beschreibung der Produkte geht weiter. Die hier genannten Attribute der Volltextübersetzer sind 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 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:

Lösung durch Umbenennung

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, lohnt sich hier das Erstellen einer Abbildung.

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.

Anforderung 6

Hier werden nun die Softwarehäuser zu Datenbankobjekten. Da für sie gleich auch noch Attribute angegeben werden, 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. Es genügt die Aufnahme des Beginns der Zusammenarbeit in den Schlüssel, damit können mehrere solche Phasen unterschieden werden.

Zeitaspekt in Beziehung

Daraus folgen weitere Relationen:

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

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

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; LINUX). Dies sind in der Regel mehrere.

Anforderung 7

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 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: ProdDig-BS. Dadurch kommt es zu einer eher seltenen Konstellation: einem Fremdschlüssel, der aus zwei Attributen besteht: (#(ProdNr, BezProg)). Der entsprechende Schlüssel ist der von ProdDig.

Zwischen den digitalen Produkten und Betriebssystemen liegt eine n-m-Beziehung vor, weshalb eine eigene Relation dafür notwendig ist.

Daraus ergeben sich folgende geänderte und neue Relationen:

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

ProdDig-BS (#((ProdNr, BezProg), BS)

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.

Anforderung Teil 8

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)

Unbehagen

Ist das wirklich korrekt? Bei näherem Hinsehen beschleicht den Betrachter 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:

Das macht die Problematik klar. Die Relation ist nicht mal in 2NF. Deshalb muss normalisiert werden.

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 neu und ProdProgGer

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 die jeweils konkrete Konstellation ausdrückt (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))

Die folgende Abbildung zeigt das zugehörige FA-Diagramm.

ALTERNATIVE

Die Entwicklung der Programme findet (natürlich) so statt, dass jedes Programm mit unterschiedlichen grafischen Bedienoberflächen (GUI) 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.

Anforderung Teil 9

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

GUI (#GUIId, Typ, PS)

Programme (#BezProg, IBK, GUIId)

Das gesamte relationale Modell

Damit ergibt sich das folgende Gesamtdatenmodell, zuerst in textlicher Notation:

Geräte (#Bez, Typ)

GUI (#GUIId, Typ, PS)

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

ProdDig-BS (#((ProdNr, BezProg), BS)

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

ProdSpr (#(ProdNr, Sprache))

Produkte (#ProdNr, Bez, LPreis, Einträge, Zielgruppe, ErschDat, Typ)

Prog-DokArt (#(BezProg, DokArt))

Programme (#BezProg, IBK, GUIId)

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)

Die grafische Notation:

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

Sprachen: abgedeckte Sprachen

SWHProg.Beginn: Beginn der Zusammenarbeit

SWHProg.Ende: Ende der Zusammenarbeit

WB+VTÜ. 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

ProdDig-BS: digitale Produkte in Kombination mit Betriebssystemen

ProdProgGer: Kombination Produkte – Programme – Geräte

ProdSpr: Kombinatione Produkte und Sprachen

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