In diesem Kapitel werden einige weitere Datenmodelle mit Anforderungsbeschreibung, Lösung und Lösungshinweisen vorgestellt. Es handelt sich um einfache didaktisch motivierte und einführende Beispiele, die aber alle wesentlichen Hürden der relationalen Datenmodellierung beinhalten.

17.1 Obst

Der Anwendungsbereich

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, ...), 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" ). Dies können durchaus mehrere sein, z.B. eine Sorte Äpfel, mehrere Sorten Birnen, usw., alles was in der Region wächst.

Beispiele für Lieferbarkeit

LNr

SortBez

Monat

100

Äpfel xyz

August

100

Äpfel xyz

September

100

Birnen xyz

Oktober

101

Birnen xyz

Oktober

...

...

...


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

Textliche Lösung

Anmerkung: "Verfügbarkeit" bezieht sich nicht auf den Lagerbestand, sondern auf die Wachstumsperioden.

Insgesamt ergeben sich damit folgende Relationen:

Landwirte (#LiefNr, Name, Vorname, Typ)

Lieferanten (#LiefNr, ZV, AbrArt, AdrNr)

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

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

KonkreteLief (#(LiefNr, SortNr, LTag), KPreis, Menge) //Konkrete Lieferungen

Lieferbarkeit (#(LiefNr, ObstNr, Monat))

Obstsorten (#SortNr, SortBez, LagFäh, Umsatz)

Grafische Notation des Datenmodells


Abbildung 17.1-1:

Relationales Datenmodell Obst

17.2 Haushaltsgeräte

Der Anwendungsbereich

Ein großer Einzelhändler möchte seinen Lagerbestand und die Verkäufe in einer Datenbank verwalten. Für jedes Haushaltsgerät wird die exakte Bezeichnung (Bez) erfasst, z.B. Staubsauger XYZ. Außerdem der Hersteller (Hersteller), der Listenpreis (LPreis), die Anzahl der Geräte im Lager (AnzLager), das Datum der Herstellung (DatumHerst) und das Datum, wann es ins Lager aufgenommen wurde (LagAufn). Für Staubsauger wird zusätzlich festgehalten, welche Saugkraft sie haben und von welchem Typ sie sind (mit Beutel, ohne, ...). Für Kaffemaschinen, welche Wassermenge sie maximal verarbeiten können (MaxWass) und in welcher Zeit sie einen halben Liter Kaffee kochen (Geschw).

Einzel- oder Typinformation?

Von den Kunden werden Name, Vorname (VName) und Telefonnummer erfasst Tel; durchaus auch mehrere) und natürlich erhält jeder eine Kundennummer (KuNr). Beim Verkauf hochwertiger Geräte mit Garantievereinbarung (teurer als 300 Euro) wird der Käufer (mit aktueller Adresse), das konkrete Gerät (Seriennummer, ...GNr) das Datum, die Versicherungsnummer (VNr) und der tatsächlich erzielte Preis (ErzPreis) festgehalten. Dieser weicht oft vom Listenpreis ab, meist weil Nachlässe gegeben werden.

Ein Kunde kann mehrere Adressen haben (PLZ, Ort, Straße), unter einer Adresse können mehrere Kunden wohnen.

Textliche Notation

Bez(eichnung) als Schlüssel deutet immer auf die Typbezeichnung und damit auf die Typebene

HG-Typen (#Bez, Hersteller, LPreis, AnzLager) //Typ-Ebene Hausgeräte

HG-Einzeln (#GNr, Bez, DatumHerst, LagAufn //Einzel-Ebene Hausgeräte

Staubsauger (#Bez, Saugkraft, Typ) //Typ-Ebene

Kaffeemaschine (#Bez, MaxWass, Geschw) //Typ-Ebene

Kunden (#KuNr, Name, VName)

VerkHG (#(GNr, KuNr, AdrNr), Datum, ErzPreis, VNr) //Verkäufe von Hausgeräten

KuAdr (#(KuNr, AdrNr))

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

Telefon (#(KuNr, Tel))

Anmerkungen

Für die Kunden werden beliebig viele Adressen erfasst und es wird auch datenbanktechnisch berücksichtigt, dass unter einer Adresse mehrere Kunden wohnen können. Es werden auch Kunden erfasst, deren Adresse durch eine Werbeaktion gewonnen wurde, die aber noch nichts gekauft haben.

Das Muster Einzel/Typ ist nicht auf Anhieb erkennbar. Hier hilft das Nachdenken mit Hilfe der Attributzuordnung, z.B. über ein FA-Diagramm.

Grafische Darstellung des Datenmodells


Abbildung 17.2-1:

Relationales Datenmodell zum Anwendungsbereich Haushaltsgeräte

17.3 Angestellte

Der Anwendungsbereich

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

  • 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.
  • Das Vorgesetztenverhältnis. Wer ist wem unter- bzw. überstellt?
  • 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.
  • Die Standorte werden mit einer identifizierenden Information (OrtId), ihrer Bezeichnung (Bez), ihrer Adresse und der Anzahl Mitarbeiter am Standort (AnzMitarb) erfasst.
  • Ein Angestellter kann in mehreren Projekten mitarbeiten und ein Projekt hat typischerweise mehrere Mitarbeiter.
  • 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.
  • 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.
  • 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.
  • Für die von den Angestellten benutzten PCs wird die Inventarnummer, (InvNr), die Bezeichnung (Bez) und der Typ (Typ) erfasst. Ein PC kann mehreren Angestellten zugeordnet sein, ein Angestellter nutzt zu einem Zeitpunkt maximal einen PC. Die Übernahme eines PC durch einen Angestellten wird mit der Art der Übernahme (Art; "Entwickler, Office-Nutzer, Superuser"), dem Beginn (Beginn) und dem Ende (Ende) festgehalten. Natürlich nutzt ein Angestellter im Zeitverlauf mehrere PC, diesbezüglich soll die gesamte Historie festgehalten werden.
  • 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.
  • 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).

Textliche Lösung

Abteilungen (#AbtBez, AbtLeiter, OrtId)

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

Die Beziehung Angestellte-Abteilungen-Funktionen beschreibt die Übernahme von Funktionen in Abteilungen durch Angestellte, mit Angabe des Zeitraums:

  • BeginnF: Beginn der Funktionsübernahme
  • EndeF: Ende der Funktionsübernahme
  • BezFu: Bezeichnung der Funktion

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

Die Beziehung Angestellte - Abteilungen - Zugehörigkeit beschreibt die Zugehörigkeit zu Abteilungen, mit Angabe des Zeitraums:

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

AngAdr (#(PersNr, AdrId))

Angestellte (#PersNr, Name, VName, DatumEinst, GebTag)

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

Methodisch wäre ein Schlüssel mit InvNrPC eingängiger. Da nach den Anforderungen jedem/jeder nur genau ein PC zugeordnet ist, wäre dies auch möglich.

ProjMitarb (#(PersNr, BezProj))

AngPS (#(PersNr, BezPS), ErfPS)

Entwickler (#PersNr, EntwU, HauptPS)

GebService (#PersNr, Funktion, Schicht)

PCEinzeln (#InvNr, BezPC)

PCTyp (#BezPC, Typ)

Projekte (#Bez, TagEinr, Dauer, Budget)

ProjOrte (#(BezProj, OrtId))

PS (#BezPS, BezComp, PreisLiz)

Standorte (#OrtId, Bez, AnzMitarb, AdrId)

TopMan (#PersNr, Bereich, Entgelt)

Vorgesetzte (#(PersNrV, PersNrU))

Die grafische Lösung


Abbildung 17.3-1:

Relationales Datenmodell zum Anwendungsbereich Angestellte

17.4 Kfz-Werkstatt

Der Anwendungsbereich

In der Datenbank soll das Geschehen rund um die Reparaturaufträge erfasst werden. Für die Reparaturaufträge selbst wird erfasst, um welches Kraftfahrzeug es geht, an welchem Tag es in die Werkstatt kam (TagAnnahme), um was für einen Schaden es sich handelte (ArtSchaden), also z.B. Totalschaden, Blechschaden, Motorprobleme, usw. Außerdem, bei welchem Serviceberater (ServBerater) das Auto abgegeben wurde und von welchem Kunden das Auto kommt. Zur einfacheren Handhabung erhält jeder Reparaturauftrag eine fortlaufende Nummer (RepANr). Aus demselben Grund wird jedem angelieferten Kfz ebenfalls eine eindeutige Nummer (KfzNr) gegeben.

Rund um Reparaturaufträge

Für die Kunden wird neben einer Kundennummer (KuNr) der Name (Name), Vorname (VName), eine Telefonnummer (Tel; die unter der der Kunde für Rückfragen zur Reparatur erreichbar ist) und die Adresse (PLZ, Ort, Straße) erfasst. Grundsätzlich soll es möglich sein, dass ein Kunde mehrere Adressen hat und unter einer Adresse mehrere Kunden wohnhaft sein können. Die Erfassung der Kundenadressen ist unabhängig von konkreten Reparaturaufträgen.

Für die Kfz werden der Hersteller (Hersteller; z.B. VW, BMW, AUDI), die Bezeichnung (Bez; z.B. PASSAT, A6, GOLF), die Art des Autos (Autoart; z.B. Cabrio, Limousine, usw.), das Kennzeichen (Kennz) und der Tag der Erstzulassung (TagErstzula) erfasst. Bei Fahrzeugen, die bei unserem Autohaus gekauft wurden, wird zusätzlich der Tag des Verkaufs (TagVerkauf) und die Art der Garantie (ArtGarantie) festgehalten.

Muster Einzel/Typ

Nach durchgeführter Reparatur wird die Rechnung in der üblichen Struktur erstellt, mit Rechnungsnummer (RNr), Datum (Datum), Angabe des Kunden und des reparierten Autos, Angabe derjenigen Adresse des Kunden, an den die aktuelle Rechnung geschickt werden soll, Rechnungspositionen mit Beschreibung der einzelnen Reparatur (BeschrRep; z.B. "Lackschaden am Kotflügel ausgebessert", "Druckluftschlauch wegen Marderschaden ausgewechselt") und Kosten der Reparatur (Preis; bei jeder Position). Auch die Gesamtsumme (SummeGes) der Rechnung wird erfasst.

Textliche Lösung

KFZAutohaus (#KfzNr, TagVerkauf, ArtGarantie)

KFZ-Einzeln (#KfzNr, Kennz, TagErstzula, (Hersteller, Bez))

KFZ-Typ (#(Hersteller, Bez), Autoart)

Oder auch : KFZ-Typ (#TypBez, #(Hersteller, Bez), Autoart) ; d.h. mit dem Attribut TypBez als konstruiertem identifizierenden Attribut und mit den Konsequenzen bzgl. des Fremdschlüssels.

ReKöpfe (#RNr, Datum, KNr, AdrNr, KfzNr, SummeGes)

RePos (#(RNr, PosNr), BeschrRep, Preis)

Kunden (#KuNr, Name, VName, Tel)

RepAufträge (#RepANr, KfzNr, ArtSchaden, TagAnnahme, ServBerater, KuNr)

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

KundeAdr (#(KuNr, AdrNr))

Grafische Lösung


Abbildung 17.4-1:

Relationales Datenmodell Kfz-Werkstatt

17.5 WebShop

In diesem Beispiel erfolgt ansatzweise auch prozessorientierte Datenmodellierung, d.h. eine Datenmodellierung, wie sie entlang eines Geschäftsprozesses nötig ist.

Der Anwendungsbereich

Es geht um Teile des Finanzwesens eines WebShops. Wenn die Warensendung im WebShop fertig ist wird die Rechnung erstellt und der Sendung beigelegt. Damit ist das kaufmännische Konstrukt Rechnung existent. Wie üblich, wird es über Rechnungsköpfe und Rechnungspositionen erfasst. Die Rechnungsköpfe erhalten als identifizierendes Attribut eine Rechnungsnummer (ReNr) und als beschreibende Attribute das Rechnungsdatum (RDatum), die Zahlungsart (ZahlArt; L (per Lastschrift), U (per Überweisung)), die Versandart (VersArt) und der Kunde vermerkt. Da die Rechnung als PDF-Dokument erzeugt wird, ist dessen identifizierende Information (PDFId) hier ebenfalls festgehalten.

Die Kunden werden durch ihre Kundennummer (KuNr) und durch ihre Adressangaben (Name, Vorname (VName), PLZ, Ort, Straße) erfasst. Damit bei einem evtl. Umzug die frühere korrekte Adresse für die Rechnung vorhanden ist, werden bei der Rechnung die "änderungsanfälligen" Adressangaben zum Zeitpunkt der Rechnungsstellung (RechnungsstellungsZeitpunkt) erfasst (durch Name-RZ, PLZ-RZ, Ort-RZ, Straße-RZ). Es versteht sich, dass ein Kunde u.U. mehrere Rechnungen beim WebShop hat, jede Rechnung aber genau einem Kunden zugeordnet ist.

Die Artikel werden durch eine Artikelnummer ArtNr, eine Artikelbezeichnung ArtBez, den Preis und eine Artikelbeschreibung (ArtBeschr) erfasst.

Die einzelnen Rechnungspositionen einer Rechnung erhalten eine Positionsnummer (PosNr), die Artikelnummer (ArtNr) und die Anzahl. Wiederum um die Rechnung auch nach längerer Zeit, wenn sich vielleicht Bezeichnung und Preis verändert haben, abrufen zu können, wird bei der Rechnung der zum RechnungsstellungsZeitpunkt gültige Preis (Preis-RZ) und die da gültige Bezeichnung ArtBez-RZ erfasst.

Für alle Artikel wird auch der gültige Mehrwertsteuersatz (MWStS) Mehrwertsteuer (MWStB) erfasst. Zu beachten ist, dass verschiedene Produkte des WebShops unterschiedliche Mehrwertsteuersätze haben). Da sich auch Mehrwertsteuersätze regelmäßig verändern, wird dieser für den Rechnungsstellungszeitpunkt (RZ) festgehalten.

Für Produkte von Fremdanbietern (Firmen, die über den WebShop auch verkaufen) wird noch die Firmennummer (FiNr) des Fremdanbieters erfasst und seine durchschnittliche Lieferzeit (LiefZeit).

Auch die ausgesandten Mahnungen und Zahlungserinnerungen werden erfasst. Jede wird identifiziert (MahnId) und bezieht sich auf genau eine Rechnung. Es versteht sich, dass es zu einer Rechnung mehrere Mahnungen geben kann. Festgehalten wird, an welchem Tag die Mahnung (Datum) verschickt wurde und von welchem Typ sie war. Verschiedene Mahnungen zur selben Rechnung erhalten jeweils eine neue Id.

Eine Rechnung kann sich in verschiedenen Zuständen befinden. Folgende sind möglich:

Zustände einer Rechnung

ZustandsNr

Bezeichnung

100

neu (nach Erstellung)

200

offen (nach Versand zum Kunden)

300

nicht bezahlt

310

nicht bezahlt (1. Zahlungserinnerung)

320

nicht bezahlt (2. Zahlungserinnerung)

330

nicht bezahlt (1. Mahnung)

340

nicht bezahlt (2. Mahnung)

350

nicht bezahlt (rechtsanwaltliche Mahnung)

400

Widerspruch

500

Gutschrift

600

storniert

700

bezahlt (Rückbuchbar)

710

bezahlt


Diese Zustände sollen für jede Rechnung erfasst werden. Nach der Erstellung hat sie den Zustand (ZustNr) "neu", nach Zusendung zum Kunden den Zustand "offen", nach Bezahlung den Zustand "bezahlt". Zu beachten ist, dass ALLE sich im Zeitverlauf ergebenden Zustände erfasst werden sollen, so dass die gesamte Historie einer Rechnung erfasst wird. Deshalb wird auch bei jedem neuen Zustand das Datum (DatumZ) erfasst, zu dem er eintrat.

Textliche Fassung des Datenmodells:

Mahnungen (#MahnId, ReNr, Datum, Typ)

Zustände (#(ReNr, ZustNr), DatumZ)

Fremdanbieter (#FiNr, LiefZeit)

Artikel (#ArtNr, ArtBez, Preis, ArtBeschr, MWStS, Typ)

ArtikelFA (#ArtNr, FiNr)

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

ReKöpfe (#ReNr, RDatum, ZahlArt, VersArt, PDFId, KuNr, Name-RZ, PLZ-RZ, Ort-RZ, Straße-RZ)

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

RZ: RechnungsstellungsZeitpunkt

Grafische Fassung des Datenmodells :


Abbildung 17.5-1:

Relationales Datenmodell WebShop

ReKöpfe: Rechnungsköpfe

RePos: Rechnungspositionen

ArtikelFA: Artikel von Fremdanbietern

17.6 Zoo

Der Anwendungsbereich

Für einen Zoo soll eine Datenbank rund um die vorhandenen Tiere erstellt werden. Dabei erfolgt eine Konzentration auf größere Tiere (Säugetiere, Reptilien, ...). Allen diesen Tieren wird eine identifizierende Tiernummer (TierNr), ihr Name (Name) und die Gattung, zu der sie gehören (Gattung) zugewiesen. Außerdem wird ihr Geburtstag (GebTag), das Geschlecht und das Gebäude erfasst, in dem sie gehalten werden. Für jede Gattung wird auch festgehalten, wieviele Tiere davon im Zoo vorhanden sind (z.B. 5 Afrikanische Elefanten oder 20 Schimpansen) (Anzahl). Wegen der Bedeutung der Information für die Gebäude und das Außengelände wird bei Elefanten noch zusätzlich das Gewicht und bei Giraffen die Größe erfasst, jeweils mit dem Datum, zu dem der Wert erhoben wurde.

Tiere - als Gattung (Typ) und einzeln:
Gen/Spez

Auch das benötigte Futter für die Tiere wird verwaltet mit der Futterbezeichnung (Bez), dem noch vorhandenen Vorrat (Vorrat) und der Mindestmenge, die immer vorrätig gehalten wird (MiMenge). Ebenso die Entnahmen von Futter mit der Futterbezeichnung (FuttBez), der Menge, dem Tag der Entnahme (Datum) und dem Tier, das gefüttert wird. Es wird nur ein Mal pro Tag Futter für ein Tier entnommen.

Den Tieren sind Pfleger zugeordnet. Von diesen wird in der Datenbank die Personalnummer (PersNr), der Name und Vorname (VName) festgehalten. Es wird auch festgehalten, von wann bis wann ein Pfleger einem Tier zugeordnet ist (Beginn, Ende). Öfters kommt es vor, dass ein Pfleger für einen bestimmten Zeitraum einem Tier zugeordnet ist, dann nicht mehr und später wieder, so dass es mehrere Pflegezeiträume eines Pflegers bei einem Tier geben kann.

Für die einzelnen Gebäude des Zoos wird eine Gebäudenummer (GebNr), die Größe, der Typ (für Säugetiere, für Reptilien, usw.) und die Anzahl der Plätze (AnzPlätze) erfasst. Selbstverständlich wird auch festgehalten, welches Tier aktuell in welchem Gebäude ist.

Für die einzelnen Gebäude des Zoos wird eine Gebäudenummer (GebNr), die Größe, der Typ (für Säugetiere, für Reptilien, usw.) und die Anzahl der Plätze (AnzPlätze) erfasst. Selbstverständlich wird auch festgehalten, welches Tier aktuell in welchem Gebäude ist.

Für jedes Tier gibt es eine Tierakte, die digital geführt wird. Ein Eintrag entsteht bei der Geburt, einer beim Weggang bzw. Sterben des Tieres. Dazwischen entstehen Einträge bei besonderen Anlässen, z.B. wenn das Tier den Zoo wechselt, eine schwere Verletzung / Erkrankung erleben muss oder Nachwuchs bekommt. Jeder Eintrag erhält eine fortlaufende Aktennummer (1, 2, 3, ...) (AktNr). Außerdem wird das Datum der Anlage der Akte (DatAnlage) sowie der Grund für die Anlage (Geburt, Krankheit, Tod, ...) (Ereignis) und eine Beschreibung des Ereignisses (BeschrEr) in die Datenbank eingetragen. Nach dem Tod des Tieres wird die Akte archiviert und aus der Datenbank entfernt.

Komposition

Textliche Fassung des Datenmodells:

Tierakten (#(TierNr, AktNr), DatAnlage, Ereignis, BeschrEr)

Gebäude (#GebNr, Größe, Typ, AnzPlätze)

Pflege (#(PersNr, TierNr, Beginn), Ende)

Pfleger (#PersNr, Name, VName)

Futter (#Bez, Vorrat, MiMenge)

Fütterung (#(TierNr, FuttBez, Datum), Menge)

Tiere-Einzeln (#TierNr, Name, BezGatt, GebTag, Geschlecht, GebNr)

Tiere-Gattung (#BezGatt, Anzahl)

Elefanten (#(TierNr, Datum), Gewicht)

Giraffen (#(TierNr, Datum), Größe)

Grafische Darstellung des Datenmodells

Die folgende Abbildung zeigt die grafische Fassung des Datenmodells.


Abbildung 17.6-1:

Relationales Datenmodell Zoo

Muster Komposition bei Tierakten

Muster Einzel/Typ bei Tiere

Muster Gen/Spez bei Elefanten, Giraffen