1.1 Analyse
Die Analyse-Phase hat das Ziel, zu klären, was die zu entwickelnde Datenbank leisten soll. Dazu wird zunächst die Ist-Situation analysiert und anschließend die angestrebte Soll-Situation definiert (Anforderungsdefinition).
Wir konzentrieren uns im Folgenden auf die Frage, welche Daten in der Datenbank gespeichert werden sollen. Dazu betrachten wir zunächst die betroffenen Geschäftsprozesse und klären welche Informationsobjekte (Personen, Sachen, Vorgänge, ...) von Interesse sind und wie diese miteinander in Beziehung stehen. Das Ergebnis halten wir mit Hilfe eines konzeptionellen Datenmodells fest. Dabei nehmen wir die fachliche Sicht der Anwenderseite ein und blenden Fragen der IT-Realisierung noch bewusst aus. Das konzeptionelle Datenmodell wird auch als semantisches Datenmodell bezeichnet.
Beispiel
Die Fahrrad Müller GmbH vermietet Fahrräder. In ihrem Angebot finden sich verschiedene Typen wie zum Beispiel Mountainbikes, Trekkingräder, Rennräder und E-Bikes. Jede Vermietung erfasst das Unternehmen in einer Software, die die Daten mit Hilfe einer relationalen Datenbank verwaltet.
Beispielhaft ist folgender Geschäftsvorfall:
Am 11.08.2015 schließt Max Maier den Mietvertrag für ein Mountainbike und ein Trekkingrad. Es wird vereinbart, dass der Mietzeitraum am nächsten Tag beginnt und drei Tage dauert. Der Angestellte ruft über die Software eine Liste aller Mountainbikes auf und ordnet dem Mietvertrag das Fahrrad mit der Kennung Cross#7 zu. Anschließend ruft er eine Liste aller Trekkingräder auf und ordnet dem Mietvertrag noch das Fahrrad mit der Kennung Mark#2 zu.
Frage 1-1: Informationsobjekte
Welche Informationsobjekte (Personen, Sachen, Vorgänge, ...) spielen in dem Geschäftsvorfall eine Rolle? Welche Daten stehen zu diesen Informationsobjekten zur Verfügung?
Lösung
Lösung
Entity-Relationship-Modell
Die am häufigsten eingesetzte Beschreibungssprache für konzeptionelle Datenmodelle ist das von Peter Chen entwickelte Entity-Relationship-Modell (ER-Modell, ERM). Wir nutzen das ER-Modell in seiner erweiterten Form (modifizierte Chen-Notation).
Beispiel
Der Kunde Max Maier, der von ihm abgeschlossene Mietvertrag und das dem Mietvertrag zugeordnete Fahrrad stellen Objekte dar, über die Informationen gespeichert werden sollen. Im Entity-Relationship-Modell werden Informationsobjekte Entitäten genannt.
Jede Entität gehört zu einem bestimmten Entitätstyp. Aus dem vorliegenden Geschäftsvorfall lassen sich die Entitätstypen Kunde, Mietvertrag und Fahrrad ableiten.
Die Attribute bzw. Eigenschaften eines Entitätstyps legen fest, welche Daten für Entitäten seines Typs erfasst werden. Auf Grundlage des vorliegenden Geschäftsvorfalls weisen wir dem Entitätstyp Kunde die Attribute Vorname und Nachname, dem Entitätstyp Mietvertrag die Attribute Abschlussdatum, Mietbeginn und Mietdauer und dem Entitätstyp Fahrrad die Attribute Kennung und Typ zu.
Können Entitäten verschiedener Typen miteinander in direkter Beziehung stehen, wird dies im Entity-Relationship-Modell durch einen Beziehungstyp deutlich gemacht, der die beteiligten Entitätstypen verbindet.
Im Entity-Relationship-Diagramm wird ein Entitätstyp in einem Rechteck dargestellt. Die Attribute eines Entitätstyps werden jeweils in einer Ellipse dargestellt, die mit ihrem Entitätstyp durch eine Linie verbunden ist. Stehen Entitäten verschiedener Typen miteinander in direkter Beziehung, werden deren Entitätstypen durch eine Linie verbunden. Auf halber Strecke wird eine Raute eingefügt, die die Art der Beziehung kurz beschreibt.
Atomare Attributwerte
Bei der Modellierung des ER-Modells ist darauf zu achten, dass alle Attribute atomare Werte enthalten.
Beispiel
Nehmen wir an, der Entitätstyp Kunde wurde so modelliert, dass er lediglich das Attribut Name besitzt. Das Attribut Name enthält in diesem Fall keinen atomaren, das heißt unteilbaren, Wert, da sich der Name in die beiden Werte Vorname und Nachname aufteilen lässt.
Ein Attributwert ist atomar, wenn er eine Information darstellt, die sich nicht in weitere Einzelinformationen zerlegen lässt.
Vermeidung von Redundanzen
Bei der Modellierung des ER-Modells ist darauf zu achten, dass keine Redundanzen entstehen. Als Redundanz bezeichnet man das mehrfache Vorhandensein ein und derselben Information.
Beispiel
Nehmen wir an, der Kunde ist nicht als eigener Entitätstyp modelliert. Statt dessen sind seine Attribute Vorname und Nachname dem Entitätstyp Mietvertrag zugeordnet. Dies hat zur Folge, dass in der Datenbank Vor- und Nachname eines Kunden bei jedem Mietvertrag gespeichert sind, den der Kunde abgeschlossen hat. Dieselben Informationen, nämlich Vor- und Nachname eines Kunden sind in diesem Fall mehrfach, das heißt redundant, gespeichert. Dies gilt es zu vermeiden.
Als Redundanz bezeichnet man das mehrfache Vorhandensein ein und derselben Information.
Schlüssel
Jede Entität muss eindeutig anhand ihrer Attributwerte identifizierbar sein. Ein Attribut, das dies ermöglicht, wird Schlüsselkandidat genannt. Sind mehrere Attributwerte nötig, um eine Entität eindeutig zu identifizieren, bilden die entsprechenden Attribute einen zusammengesetzten Schlüsselkandidaten.
Von allen möglichen Schlüsselkandidaten wird ein geeigneter Kandidat als Primärschlüssel ausgewählt. Folgende Kriterien sind dabei zu berücksichtigen:
-
Ein einer Entität zugewiesener Primärschlüsselwert ändert sich nicht, solange die Datenbank existiert.
-
Primärschlüsselwerte sind möglichst einfach strukturiert. Geeignet sind zum Beispiel fortlaufende ganze Zahlen.
Schlüsselkandidaten, die im Geschäftsbetrieb verwendet werden, werden natürliche Schlüssel genannt. Ein Beispiel für einen natürlichen Schlüssel ist das Kfz-Kennzeichen, das ein Auto eindeutig identifiziert.
Einen natürlichen Schlüssel als Primärschlüssel zu verwenden, kann sich als problematisch erweisen. Denn es kann nicht ausgeschlossen werden, dass sich im Geschäftsbetrieb diese Schlüssel im Laufe der Zeit ändern beziehungsweise dort erneut vergeben werden. Das Ändern von Primärschlüsselwerten ist jedoch ein kritischer Vorgang, den es zu vermeiden gilt. Eine erneute Vergabe eines Primärschlüsselwertes verstößt gegen die Anforderung, dass ein Primärschlüssel eindeutig sein muss.
Zum Beispiel kann sich das Kfz-Kennzeichen ändern, wenn ein Auto dauerhaft an einen Standort in einem anderen Landkreis verlegt wird. Auf der anderen Seite kann das Kfz-Kennzeichen eines stillgelegten Autos erneut verwendet werden.
Dieses Risiko wird durch die Verwendung künstlicher Primärschlüssel (Surrogatschlüssel) ausgeschlossen. Ein solcher Schlüssel wird künstlich genannt, da dem Entitätstyp ein zusätzliches Attribut hinzugefügt wird, das nicht aus der realen Welt abgeleitet wurde und dort keinerlei Bedeutung besitzt.
Beispiel
Für die Entitätstypen Kunde und Mietvertrag liefert der Geschäftsvorfall keine Schlüsselkandidaten. Wir fügen daher jeweils ein Attribut namens ID hinzu, das als künstlicher Primärschlüssel dient.
Die im Geschäftsvorfall genannte Kennung scheint zwar ein Fahrrad eindeutig zu identifizieren, allerdings wird sie im Geschäftsbetrieb genutzt und besitzt dort eine Bedeutung. Es kann auch nicht ausgeschlossen werden, dass sie sich niemals ändert. Aus diesem Grund fügen wir auch hier einen künstlichen Primärschlüssel namens ID hinzu.
Wir ergänzen unser Entity-Relationship-Diagramm entsprechend und kennzeichnen die Attribute, die als Primärschlüssel dienen, indem wir ihre Attributnamen unterstreichen.
Kardinalität
Die Kardinalität eines Beziehungstyps gibt an, mit wie vielen Entitäten des gegenüberliegenden Typs eine Entität in Beziehung stehen kann und umgekehrt.
| Zeichen | Bedeutung |
|---|---|
| c | keiner oder einer |
| 1 | genau einer |
| n bzw. m1 | einer oder mehrere |
| nc bzw. mc | keiner, einer oder mehrere |
Beispiel
Die Fahrrad Müller GmbH möchte auch die Daten potentieller Kunden erfassen. Dabei handelt es sich um Personen, die bisher noch kein Rad gemietet haben, deren Daten jedoch zum Beispiel aufgrund einer Anfrage dem Unternehmen bekannt sind.
Einen Mietvertrag schließt die Fahrrad Müller GmbH immer mit genau einem Kunden.
Einem Mietvertrag muss mindestens ein Fahrrad zugeordnet werden.
Fragen 1-2: Kardinalität
Beziehungstyp Kunde schließt Mietvertrag
Beziehungstyp Mietvertrag reserviert Fahrrad
Modellierungsfragen
Modellieren verschiedene Personen den gleichen Sachverhalt mit der gleichen Modellierungssprache, führt dies nicht zwangsläufig zu gleichen Modellen. Die Einhaltung der Modellierungsregeln vorausgesetzt, lässt sich in der Regel nicht sagen, dass ein Modell richtig und das andere falsch ist. Man kann jedoch abwägen, welche Modellierung den Sachverhalt genauer abbildet beziehungsweise die spätere Realisierung der Anforderungen erleichtert.
Beispiel
Wir haben den Fahrradtyp als Attribut des Entitätstyps Fahrrad modelliert. Alternativ kann der Fahrradtyp auch als eigener Entitätstyp modelliert werden, der mit dem Entitätstyp Fahrrad in Beziehung steht. In diesem Fall stellen die Fahrradtypen, zum Beispiel Mountainbike, Trekkingrad, Rennrad und E-Bike, jeweils eine Entität des Entitätstyps Fahrradtyp dar.
Sofern es neben der Typenbezeichnung noch weitere Daten gibt, die unmittelbare Eigenschaften des Fahrradtyps darstellen, zum Beispiel eine Abkürzung der Typenbezeichnung, ist ein eigenständiger Entitätstyp Pflicht. Doch auch ein Entitätstyp, der neben einem Schlüssel nur über ein Attribut verfügt, kann eine sinnvolle Modellierung sein:
Vorteile einer Modellierung des Fahrradtyps als eigenständiger Entitätstyp:
- Es ist möglich im System Fahrradtypen anzulegen, von denen bisher noch kein Fahrrad im Bestand ist.
- Die Typenbezeichnung wird nur einmal gespeichert. Es kann somit nicht mehr zu unterschiedlichen Schreibweisen kommen.
- Es lässt sich schnell und einfach feststellen, welche Fahrradtypen einem Fahrrad zugewiesen werden können.
Aufgabe 1-1: Fuhrpark
Die Firma Atlanta GmbH hat einen Fuhrpark von Firmenwägen, die von Mitarbeitern für berufliche Zwecke genutzt werden können. Das Unternehmen möchte die Verwaltung des Fuhrparks, die bislang ausschließlich in Papierform erfolgt, auf eine IT-gestützte Lösung umstellen.
Erstellen Sie aufgrund der folgenden Unterlagen und Anforderungen ein Entity-Relationship-Diagramm.
-
-
Mitarbeiter füllen einen Reservierungsvordruck aus. Ein Verantwortlicher des Fuhrparks ordnet der Reservierung dann ein Fahrzeug zu und vermerkt dessen Kennzeichen auf dem Reservierungsvordruck.
Abb. 1-5: Reservierungsvordruck -
Wird ein neues Fahrzeug angeschafft, erfasst die Fuhrparkverwaltung dessen Daten in folgender Tabelle:
Abb. 1-6: Fahrzeuge im Fuhrpark
-
-
Instandhaltung
Bei Reparaturen beziehungsweise Wartungsarbeiten an Fahrzeugen sollen Datum, Kilometerstand, Kosten sowie eine kurze Beschreibung in der Datenbank festgehalten werden.
-
Kfz-Versicherung
Als zusätzliche Anforderung sollen auch einige Daten der Kfz-Versicherungen der Fahrzeuge in die Datenbank integriert werden.
Verlangt werden jeweils folgende Informationen: die Versicherungsnummer, ob zusätzlich zur Haftpflichtversicherung eine Vollkasko bzw. Teilkasko abgeschlossen wurde, die Höhe des jährlichen Beitrags sowie der Firmenname der jeweiligen Versicherungsgesellschaft, inklusive Postanschrift und Telefonnummer.
Es soll auch möglich sein, die Kontaktdaten einer Versicherungsgesellschaft zu erfassen, mit der bisher noch kein Kfz-Versicherungsvertrag abgeschlossen worden ist.
Es reicht aus, wenn für jeden Firmenwagen jeweils der aktuelle Vertrag gespeichert werden kann. Eine Historie wird nicht verlangt.