In diesem Artikel gibt es nun endlich das praktische Beispiel zur ER-Modellierung. Auch dieses Mal soll das Bibliotheksbeispiel wieder zur Hilfe genommen werden.
Beschreibung einer Datenbank
Die Datenbank soll alle nachfolgend beschriebenen Vorgänge in einer Bibliothek erfassen. Zu allen Mitarbeitern der Bibliothek soll eine eindeutige Personalnummer, der Name, sowie der aktuelle Wohnort gespeichert werden. Sollte ein Mitarbeiter krank werde, muss ein anderer Mitarbeiter einspringen. Dazu werden Festnetz- sowie Mobilnummer von jedem Mitarbeiter gespeichert. Alle Bücher der Bibliothek sollen ebenfalls in der Datenbank erfasst werden. Die wesentlichen Daten der Bücher sind ISBN, Titel, Autor und Klappentext. Jeder Bibliotheksbenutzer erhält eine eigene Kundennummer. Neben der Kundennummer soll auch der Name gespeichert werden. Bei allen Ausleihen soll das Ausleihdatum, das erwartete Rückgabedatum und das tatsächliche Rückgabedatum protokolliert werden.
Vom Text zum ER-Modell.
Die Datenbank soll alle nachfolgend beschriebenen Vorgänge in einer Bibliothek erfassen.
Der erste Satz der Beschreibung soll uns nur zeigen, in welche Richtung wir denken sollen.
Zu allen Mitarbeitern der Bibliothek soll eine eindeutige Personalnummer, der Name, sowie der aktuelle Wohnort gespeichert werden.
Wir benötigen also eine Entität Mitarbeiter, welche die Attribute Name und Wohnort hat, wobei Wohnort ein zusammengesetztes Attribut ist, da es aus Straße, Hausnummer, PLZ und Wohnort besteht. Zusätzlich hat Mitarbeiter noch das Schlüsselattribut Personalnummer. Es kann als Schlüsselattribut verwendet werden, da in der Beschreibung „eindeutig“ steht.
Sollte ein Mitarbeiter krank werde, muss ein anderer Mitarbeiter einspringen. Dazu werden Festnetz- sowie Mobilnummer von jedem Mitarbeiter gespeichert.
Zu Mitarbeiter fügen wir jetzt noch das Mehrfachattribut Telefonnummer. Es soll ja schließlich mindestens 2 Werte enthalten.
Alle Bücher der Bibliothek sollen ebenfalls in der Datenbank erfasst werden. Die wesentlichen Daten der Bücher sind ISBN, Titel, Autor und Klappentext.
Um diese Sätze zu verwerten fügen, wir eine Entität Buch hinzu, welche die Attribute Titel, Autor, Klappentext und das Schlüsselattribut ISBN hat. Der Text gibt zwar keinen Hinweis, dass ISBN ein Schlüsselattribut sein soll. Unser Allgemeinwissen sollte uns aber sagen, dass jede ISBN eindeutig ist und sinnvolle Schlüsselattribute schaden nie.
Jeder Bibliotheksbenutzer erhält eine eigene Kundennummer. Neben der Kundennummer soll auch der Name gespeichert werden.
Mit diesen Sätzen führen wir eine neue Entität Bibliotheksbenutzer ein, welche das Schlüsselattribut Kundennummer und das normale Attribut Name besitzt.
Bei allen Ausleihen soll das Ausleihdatum, das erwartete Rückgabedatum und das tatsächliche Rückgabedatum protokolliert werden.
Um diese Information zu verwerten, benötigen wir unseren gesunden Menschenverstand, da die gegebenen Informationen nicht sehr ausführlich sind. Es macht Sinn diese Anforderung als Relation zwischen Buch und Bibliotheksnutzer zu notieren. Eine Notation als eigene Entität wäre aber auch möglich. In unserem Fall erhält die Beziehung noch eigene Attribute (Ausleihdatum, Rückgabedatum und tatsächliches Rückgabedatum). Das Rückgabedatum habe ich als abgeleitetes Attribut (lässt sich aus Ausleihdatum + 4 Wochen berechnen) gezeichnet. In der Regel würde aber auch ein einfaches Attribut reichen.
Kardinalitäten
Für die einzige vorhandene Beziehung können wir nun noch Kardinalitäten hinzufügen. Ich verwende die umgekehrte Chen-Notation mit Min-Max-Erweiterung.
Nicht jeder Bibliotheksnutzer muss ein Buch ausgeliehen haben (Manche sind vielleicht nur wegen des Internetzugangs dort).
Maximal ein Nutzer hat gleichzeitig ein Buch ausgeliehen. Ein Nutzer kann mehrere Bücher ausleihen.