Überlegungen zum ER-Modell

Um das ER-Modell diskutieren zu können, ist es zunächst einmal essentiell, dieses kurz zu skizzieren und dessen Zweck zu erläutern, um den anschließenden Gedankengängen folgen zu können.
Dabei werde ich versuchen, dieses so einfach wie möglich abzuhandeln und mit Beispielen zu unterlegen, um das Verständnis desselben zu erleichtern.

Erklärung des ER-Modell
Die Bezeichnung ER-Modell leitet sich aus den englischen Begriffen Entity (= Entität) und Relationship (= Beziehung) ab. Es handelt sich hierbei um die graphische Umsetzung des Aufbaus einer Datenbank. Die betrieblichen Abläufe werden dabei, in einem ersten Schritt, von Wirtschaftlern analysiert, da diese mit den Abläufen im Betrieb vertraut sind und danach von Informatikern in eine relationale Datenbank umgesetzt.
Ziel ist es eine Datenbank zu generieren, bei der die Redundanzen (= Mehrfacheinträge inhaltsgleicher Bedeutung) minimiert werden, um bei eventuellen Änderungen (z.B. Änderung einer Wohnadresse) diese Änderung nur 1x in der Datenbank verändert werden muss und danach automatisch auf alle Datenbereiche übertragen wird.
Es könnte sonst vorkommen, dass z.B. beim Schreiben einer Rechnung die Adresse zwar geändert wird , aber bei einer darauf folgenden Mailing-Aktion die alte Adresse wieder in der Adressatenliste aufscheint, weil die Redundanz nicht gegeben war. Dies soll ein ER-Modell vermeiden.
Die nachfolgende Grafik veranschaulicht ein solches Modell anhand eines Buchhandels.



Auf die einzelnen graphischen Elemente des ER-Modell wird nun nachfolgend näher eingegangen.

Entität
Als Entität bezeichnet man hierbei Objekte der Wirklichkeit in Form materieller oder immaterieller (abstrakter) Art. Entitäten könnten beispielsweise folgende Bezeichnungen tragen: Buch, Kunde, Verlag, Angestellter, Auftrag, Projekt, etc. Die Entitäten sind als rechteckige Kästchen gekennzeichnet.

Attribute
Jede Entität ist durch bestimmte Attribute gekennzeichnet, welche Elementarinformationen derselben darstellen. Dies können z.B. bei der Entität „Verlag“ folgende Informationen sein: Ort, PLZ, Straße, Kundennummer, Name, Kurzbezeichnung. Gekennzeichnet werden diese Attribute mit einer ovalen Blase.

Jeder der Entitäten besitzt mindestens einen Primärschlüssel (=Schlüsselattribut). Dies ist eine Eigenschaft, durch welche sich die Entität eindeutig identifizieren lässt. Als Beispiele können hier unter andere folgende Beispiele herangezogen werden (vgl. obige Grafik).

Entität „Kunde“: Kundennummer als Primärschlüssel
Jeder Kunde hat eine eigene Kundennummer, welche nur ein einziges Mal an einen Kunden vergeben wird. Er ist dadurch eindeutig identifiziert.

Die Attribute Ort, PLZ, Straße, Nachname und Vorname eignen sich aus den folgenden Gründen nicht als Primärschlüssel.

Ort: Verschiedene Kunden können im gleichen Ort wohnhaft sein.
Straße: Verschiedene Kunden können in der gleichen Straße wohnhaft sein.
PLZ: Verschiedene Kunden können unter der gleichen PLZ wohnhaft sein.
Vorname: Mehrere Kunden können den gleichen Vornamen besitzen.
Nachname: Mehrere Kunden können den gleichen Nachnamen besitzen.

Verwechslungen könnten daher nicht ausgeschlossen werden.

Entität „Auftrag“: Nr als Primärschlüssel
Jeder Auftrag trägt eine fortlaufende Nummer, welche nur ein einziges Mal vergeben werden kann. Auch hier wird die eindeutige Identität gewahrt.

Die Attribute Kundennummer und Datum erscheinen hierbei als Schlüsselattribute ungeeignet.

Kundennummer: Es können mehrere Aufträge von ein und demselben Kunden in Auftrag gegeben werden.
Datum: Es können mehrere Aufträge zum selben Datum eingehen.

Entität „Buch“: Nr als Primärschlüssel
Jedes Buch bekommt eine fortlaufende Nummer, sobald es in das Sortiment aufgenommen wird. Diese wird, genauso wie bei den beiden vorangegangenen Beispielen, nur ein einziges Mal vergeben, d.h. es kann ausgeschlossen werden, dass zwei verschiedene Bücher die gleiche Buchnummer besitzen. Auch hier wird eine eindeutige Identifikationsmöglichkeit gegeben.

Die Attribute Autor, Titel, Preis, Verlag, Auslaufend und Bestand sind aus den nachfolgend angeführten Begründungen nicht als Primärschlüssel geeignet.

Autor: Es können mehrere Bücher von ein und demselben Autor existieren.
Titel: Es könnte vorkommen, dass zwei oder mehrere Autoren ein Buch mit demselben Titel auf den Markt bringen (vom Copyright-Schutz mal abgesehen).
Preis: Es besteht die Möglichkeit, dass verschieden Bücher einen identischen Preis aufweisen.
Verlag:Es besteht die Möglichkeit, dass ein und dasselbe Buch von mehreren Verlagen bezogen werden kann.
Auslaufend: Die Anzahl der auslaufenden Bücher ist variabel, wodurch die Zuordnung auf ein bestimmtes Buch nicht mehr gegeben ist.
Bestand: Auch der Bestand ist variabel und es kann vorkommen, dass von verschiedenen Büchern die gleiche Anzahl vorhanden ist.

Entität „Verlag“: Kurzbezeichnung als Primärschlüssel
Es wird davon ausgegangen, dass an jeden Verlag eine einzigartige Kurzbezeichnung vergeben wird, welche kein anderer Verlag besitzt.

Kritische Anmerkung: Hier wäre vielleicht die Vergabe einer Nummer, wie bei den anderen Entitäten, eine adäquatere Methode, da es eventuell passieren kann, dass zwei verschiedenen Verlagen, welche eine ähnlich Namensgebung aufweisen, die gleiche Kurzbezeichnung zuerkannt wird, sofern dies (z.B. EDV-mäßig) nicht überprüft wird.

Die Attribute Name, Kundennummer, Straße, PLZ, Ort sind aus folgenden Gründen nicht als Schlüsselattribut geeignet:

Name: Es können mehrere Verlage mit dem gleichen Namen existieren. Dies könnte im Speziellen dann sein, wenn ein Verlag mehrere Niederlassungen besitzt.
Kundennummer: Jeder Verlag besitzt in der Regel mehrer Kunden und daher auch mehrere Kundennummern.
Straße: Es besteht die Möglichkeit, dass zwei oder mehrere Verlage in der gleichen Straße angesiedelt sind.
PLZ: Es besteht die Möglichkeit, dass zwei oder mehrere Verlage unter der gleichen PLZ angesiedelt sind.
Ort: Es besteht die Möglichkeit, dass zwei oder mehrere Verlage im gleichen Ort angesiedelt sind.

Aus den Erläuterungen wird nun klar, dass als Primärschlüssel bzw. Schlüsselattribut nur jene Eigenschaften herangezogen werden können, welche eine Entität eindeutig beschreiben können. Sie sind daher, genauso wie die Attribute, streng mit der Entität verknüpft. Gekennzeichnet werden diese Attribute als eine ovale Blase mit einem Unterstrich, welcher die Eigenschaft als Schlüsselattribut hervorheben soll.

Merksatz: Schlüsselattribute können nur jene Attribute sein, welche eine Entität auf eindeutige Art und Weise beschreiben können.

Beziehungen
Beziehungen dienen dazu, um Entität miteinander zu verknüpfen, d.h. sie stehen in einer bestimmten Beziehung miteinander. In unserem Buchhandelsbeispiel könnten die Beziehungen folgendermaßen formuliert werden:

Kunde erteilt uns einen Auftrag: Die Beziehung zwischen Kunde und Auftrag ist die „Erteilung“ desselben.

Der Auftrag lautet 1 Stück des Buches „X“: Die Beziehung zwischen Auftrag und Buch ist die Order „über“ 1 Buch X.

Das Buch X wird vom Verlag Y verlegt: Die Beziehung zwischen Buch und Verlag ist dessen „Verlegung“.

Auch Beziehungen können Attribute aufweisen, welche die Beziehung näher erklären sollen. In unserem Beispiel hat die Beziehung „über“ die Attribute Menge und Nr. Ob eine Beziehung Attribute enthält oder nicht, ergibt sich aus dem logistischen Ablauf der Unternehmung.
Die Menge kann sich hierbei z.B. auf die Anzahl eines georderten Buches in der Auftragsposition 1 beziehen und die Nr auf eine gegebenenfalls erwünscht Reihenfolge.

Arten von Beziehungen
Entitäten können auf verschieden Arten miteinander in Beziehung stehen. Die nachfolgenden Erklärungen sollen dies zum besseren Verständnis erläutern.

1:1 Beziehung: Eine Entität 1 steht einer Entität 2 gegenüber (E1:E2 = 1:1)

In diesem Beispiel gibt es keine 1:1 Beziehung, aber man könnte z.B. ein Preisausschreiben anführen. Jeder Teilnehmenden darf nur mit einer Karte am Preisausschreiben mitmachen und jede Karte kann daher auch nur einem Teilnehmenden zugeordnet werden.

1:n Beziehung: Eine Entität 1 steht n Entitäten 2 gegenüber (E1:E2 = 1:n)

Als Beispiel sei hier auf den Buchhandel Bezug genommen:
Ein Kunde (1) kann mehrere Aufträge (n) in Auftrag geben und mehrere Aufträge (n) können von einem Kunden (1) kommen.

n:m Beziehung: Mehrere (n) Entitäten 1 stehen mehreren (m) Entitäten 2 gegenüber (E1:E2 = n:m)

Beispiel Auftrag und Buch:
Mehrere Aufträge (n) können sich auf mehrere Bücher (m) beziehen und mehrere Bücher (m) können auf mehreren Aufträgen (n) aufscheinen.

Gekennzeichnet werden Beziehungen mit Rauten.
Nachfolgende Grafik fasst diese Darstellungsformen noch einmal zusammen.



Kritischer Diskurs zum ER-Modell

Redundanzen
Wie in der Einleitung erwähnt ist es das Ziel Redundanzen zu minimieren. Im vorliegenden Beispiel befinden sich jedoch noch einige Mehrfachnennungen (z.B. PLZ, Ort). Diese könnten gegebenenfalls noch in eine extra Tabelle ausgelagert werden, da die PLZ direkt mit dem Ort verknüpft ist. Auch die Straße kommt doppelt vor. Hier muss aber kritisch darauf hingewiesen werden, dass es Straßennamen gibt, welche in mehreren Gemeinden, Städten und Orten, gleich lauten!!

Normalisierung von Beziehungen
Im gegebenen Beispiel gibt es noch n:m Beziehungen. Ziel ist es aber, ein Datenbank-Modell zu generieren, bei welchem n:m Beziehungen vermieden werden. Hier könnte gegebenenfalls noch etwas geändert werden.

Zusätzliche Attribute
Zusätzliche Attribute bei einigen Entitäten könnten noch mehr Möglichkeiten der Datenabfrage ermöglichen. Dies hängt natürlich immer mit dem Zweck (welche Informationen brauch ich unbedingt). Zusammen. Je mehr Daten natürlich verwaltet werden, desto arbeitsintensiver ist auch die „Wartung“ der Datenbank. Ich möchte dennoch ein paar Beispiele erwähnen:

Entität Buch: z.B. das Gewicht für Transportkosteninformationen
Entität Kunde: z.B. Geburtsdatum für kleine Geburtstagspräsente
Entität Verlag: z.B. die Dauer der der Zusammenarbeit für etwaige Dankeschön-Präsente