Beziehungen
Zwischen den einzelnen Entity-Typen können Beziehungen (relationships) bestehen. Auch diese Beziehungen können Attribute besitzen. Als Bsp. betrachten wir die Beziehung „besucht“ zwischen den Typen „Schüler“ und „Kurs“, die „Note“ als Attribut hat.
Allerdings sind die zweiwertigen Beziehungen die weitaus wichtigsten. Bei ihnen unterscheidet man zwischen drei Komplexitäten:
1:1-Beziehungen: jedes Entity vom Typ E1 steht höchstens mit einem Entity vom Typ E2 in Beziehung und umgekehrt. Schulbsp.: Schüler - erhält - Abiturzeugnis. Jeder Schüler erhält (höchstens) ein Abiturzeugnis, und jedes Abiturzeugnis gehört eindeutig zu einem Schüler.
1:n-Beziehungen: jedes Entity vom Typ E2 steht höchstens mit einem Entity vom Typ E1 in Beziehung, es können aber mehrere aus E2 zum selben Entity aus E1 eine Beziehung haben. Schulbsp.: Lehrer - ist Tutor von - Schüler. Jeder Schüler hat nur einen Tutor, aber jeder Lehrer, der Tutor ist, hat mehrere Schüler in seiner Tutorengruppe. n:1-Beziehungen sind natürlich ganz analog definiert.
n:m-Beziehungen: jedes Entity aus E1 kann zu mehreren aus E2 eine Beziehung haben, und jedes Entity aus E2 zu mehreren aus E1. Schulbsp.: Schüler - besucht - Kurs. Jeder Schüler besucht mehrere Kurse, und Kurse werden von mehreren Schülern besucht.
In der grafischen Realisierung des ER-Modells werden die Komplexitäten an die Linien, die die Beziehung darstellen, geschrieben.
Die Entscheidung über die Kardinalität einer Richtung der Beziehung wird über die sogenannte KaMe-Frage getroffen.
KaMe-Frage
Kann eine Entität des Typs A mit mehreren Entitäten des Typs B in Beziehung stehen?
Ja → Kardinalität ist n Nein → Kardinalität ist 1
Die Komplexität lässt sich noch weiter spezifizieren, wenn man bei den Beziehungen nicht nur Höchstgrenzen, sondern auch Mindestgrenzen angibt. Wir betrachten dazu die 1:n-Beziehungen. Hier war verlangt, dass jedes Entity aus E2mit höchsten einem Entity aus E1 in Beziehung steht. Man kann sich natürlich auch fragen, ob jedes Entity mit genau einem Entity aus E1 in Beziehung steht. Im Beispiel bedeutet, dass jeder Schüler einen Tutor haben muss.
Manchmal wird diese Unterscheidung durch die Angabe von Intervallen gekennzeichnet, d.h. statt der 1 wird das Intervall [0,1] bzw. [1] angegeben. Man spricht auch von Kardinalitäten (für 1:1, n:1, usw) und von Optionalitäten Auch bei Attributen wird diese Unterscheidung manchmal durchgeführt. So könnte bei Adressen die Angabe von Straße, PLZ und Ort zwingend vorgeschrieben sein, die Angabe einer Telefonnummer jedoch optional sein. Man kennzeichnet solche optionalen Attribute manchmal mit einem Kreis an die Verbindungslinie zwischen Entity und Attribut.
Mehrfache Beziehungen
Beziehungen werden grafisch durch Rauten dargestellt. Zwischen Entity-Typen kann es mehr als eine Beziehung geben, wie das folgende Bsp. zeigt.
Eine Beziehung kann auch zwischen mehr als Typen bestehen. Wir betrachten die Schulstunde als Entity. Das kann durchaus sinnvoll sein, damit Attribute wie Anfangs- und Endzeit gespeichert werden können, dann ergibt sich der Stundenplan als eine Dreierbeziehung zwischen Stunde, Raum und Kurs.
Ein Entitytyp kann auch mehrfach an einer Beziehung teilnehmen. Man spricht dann von Rekursion.
Optionalität von Beziehungen
Die Komplexität lässt sich noch weiter spezifieren, wenn man bei den Beziehungen nicht nur Höchstgrenzen, sondern auch Mindestgrenzen angibt. Wir betrachten dazu die 1:n-Be-ziehungen. Hier war verlangt, dass jedes Entity aus E2mit höchsten einem Entity aus E1 in Beziehung steht. Man kann sich natürlich auch fragen, ob jedes Entity mit genau einem Entity aus E1 in Beziehung steht. Im Beispiel bedeutet, dass jeder Schüler einen Tutor haben muss.Mit der Optionalität einer Beziehung wird also ausgedrückt, ob eine Entität eine Beziehung eingehen kann oder muss, ob diese Beziehung also optional oder obligatorisch ist. Wie bei der Kardinaliät muss die Frage nach der Optionalität für beide Beziehungstyprichtungen geklärt werden.
MuMi-Frage
Die Entscheidung über die Optionalität einer Richtung der Beziehung wird über die sogenannte MuMi-Frage getroffen.
Muss eine Entität des Typs A mit mindestens einer Entität des Typs B in Beziehung stehen?
Ja → nicht optional, obligatorisch, muss-Beziehung Nein → optional, nicht obligatorisch, kann-Beziehung
Manchmal wird diese Unterscheidung durch die Angabe von Intervallen gekennzeichnet, d.h. statt der 1 wird das Intervall [0,1] bzw. [1] angegeben. Man spricht auch von Kardinalitäten (für 1:1, n:1, usw) und von Optionalitäten Auch bei Attributen wird diese Unterscheidung manchmal durchgeführt. So könnte bei Adressen die Angabe von Straße, PLZ und Ort zwingend vorgeschrieben sein, die Angabe einer Telefonnummer jedoch optional sein. Man kennzeichnet solche optionalen Attribute manchmal mit einem Kreis an die Verbindungslinie zwischen Entity und Attribut.
IS-A Beziehung
Eine besondere Art von „relationships“ sind die sogenannten „IS-A“ Beziehungen (aus dem Englischen, wörtlich übersetzt „ist ein“). Damit wird es möglich, Teilmengen von Entity-Typen zu erfassen. Diese Beziehungen entsprechen der oben angegebenen speziellen Abstraktionsform „Spezialisieren bzw. Generalisieren. Bei bestimmten Entities gibt es sinnvolle Teilmengen, die alle Attribute der übergeordneten Menge erben (diese müssen auch nicht mehr in der grafischen Darstellung angegeben werden.), aber noch zusätzliche Attribute besitzen. Ein Bsp. aus der Schule soll das verdeutlichen.
Auf eine Angabe von Attributen wurde verzichtet. Es lassen sich jedoch ohne Probleme an diesem Bsp. ererbte und neue Attribute erläutern. So wären etwa „Name, Vorname, Adresse „ für alle Schulmitglieder gemeinsam. Bei Lehrer könnten die Zusatzattribute „Titel, Unterrichtsfächer“ auftauchen, bei Angestellter „Besoldungsgruppe“, bei Sekretär/in und Haus-meister lassen Sie bitte mal Ihre antasie spielen.
Ein Sonderfall der Spezialisierung soll in diesem Fall noch erwähnt werden, die Partitionierung. Dabei wird ein Entity-Typ in mehrere disjunkte (elememtfremde) Entity-Typen spezialisiert. Von vollständiger Partitionierung wollen wir sprechen, wenn jede Instanz eindeutig einer Partition zugeordnet werden kann.
Für das Entity-Relationship-Modell wurden verschiedene Erweiterungen vorgeschlagen, so z.B. ein EER-Modell (von „erweitert“). Auf diese Ansätze soll hier nicht näher eingegangen werden.
Abschließend noch ein etwas umfangreicheres Bsp. zum ER-Modell, das sich zum Teil aus den bisher besprochenen zusammensetzt. Es beschreibt einen Ausschnitt aus der Schulverwaltung. Man kann sicher einige Kritikpunkte finden, insbesondere die Auswahl der Attribute. Ich möchte aber nochmals darauf hinweisen, dass dieses Skript Anregungen geben soll und nicht eine Mustermodellierung der Schulverwaltung erstellen möchte. Allerdings erscheint mir diese Bsp. für den Unterricht besonders geeignet, da es aus der Alltagswelt der Schüler entnommen ist. Deshalb erscheint es auch eine reizvolle Aufgabe, ein solches Modell selbst zu erstellen oder das angegebene zu verbessern und zu erweitern. Auch Aspekte des Datenschutzes, auf die ich hier nicht weiter eingehen will, lassen sich daran ausgezeichnet debattieren.