Entity-Relationship Modellierung: Eine Einführung

In diesem Tutorium machen wir uns mit der Entity-Relationship (ER) Modellierung vertraut. Mittels dieser Modelle können wir Verhältnisse der realen Welt wiederspiegeln. Im dritten Tutorium wandeln wir dann dieses Modell in eine relationale Datenbank um, damit wir die zuvor im Modell dargestellten Sachverhältnisse organisiert abspeichern können.

Einführung

Das Grundgerüst des Entity-Relationship Modell sind Entity-Typen und Relationship-Typen.

Entity-Typen

Entity-Typen sind Klassen von gewissen Instanzen, z.B. Studierenden oder auch Produkten und werden durch ein Rechteck gekennzeichnet. In dem Rechteck eines Entity-Typen steht dann der Name dieses Entity-Typen und was diese Klasse ausmacht, wird dann durch Attribute gekennzeichnet. Die Attribute werden durch die Nadelnotation am Entity-Typen vermerkt. Konkret gibt es vier Arten von Attributen:

1. Atomare Attribute: Attribute, welche mittels eines einzelnen Werts gespeichert werden können.

2. Komplexe Attribute: Attribute, die aus mehreren Bestandteilen bestehen (Adresse(Straße, Hausnummer, PLZ, Stadt, Land)).

3. Mengenwertige Attribute: Attribute, die aus mehreren Werten bestehen ({Noten}).

4. Abgeleitete Attribute: Attribute, welche nicht physisch gespeichert werden müssen, da Sie aus anderen Attributen hergeleitet werden können.

Darüber hinaus gibt es auch Schlüsselattribute. Ist der Stecknadelkopf ausgefüllt, so handelt es sich um das Schlüsselattribut oder eines der Schlüsselattribute, die gemeinsam den Schlüssel bilden, wobei ein Schlüssel die Instanz eindeutig identifiziert. Ist der Stecknadelkopf eines Attributs hingegen nicht ausgefüllt, so handelt es sich um ein Nicht-Schlüsselattribut.

Im Folgenden haben wir ein Beispiel eines Entity-Typen Studierende, wobei die Instanzen der Studierenden eindeutig durch ihre Matrikelnummer identifiziert werden. Zusätzlich haben Studierende das komplexe Attribut Name, welches aus den atomaren Attributen Vorname und Nachname besteht. Des Weiteren besuchen Studierende potenziell viele Vorlesungen, weshalb dies ein mengenwertiges Attribut ist, welches zusätzlich auch komplex ist und aus einer VLID und einem VlTitel besteht. Außerdem haben Studierende auch noch das Attribut Semester, welches angibt, in welchem Semester diese sich befinden. Zuletzt haben Studierende noch die Attribute Geburtsdatum und Alter, wobei Alter ein hergeleitetes Attribut ist.

Relationship-Typen

Relationship-Typen bilden Beziehungen ab, welche zwischen den unterschiedlichen Entitäts-Typen gelten. So kann ein Studierender z.B. eine Vorlesung besuchen oder eine Kundin ein Produkt kaufen. Bei allen Relationship-Typen muss die Kardinalität zwischen den Beteiligten Entitäts-Typen angegeben werden. Die Kardinalität definiert auf einem abstrakten Niveau, in welchen Verhältnissen die Entitäts-Typen zueinander stehen. Folgende Ausprägungen sind dabei möglich:

1. Eins-zu-Eins (1 : 1): Für jede Instanz aus dem einen Entitäts-Typen gibt es maximal eine andere Instanz aus dem anderen beteiligten Entitäts-Typen, mit dem die Instanz in Verbindung steht. Beispiel: Eine Fakultät hat maximal einen Dekan, eine Person kann Dekan maximal einer Fakultät sein.

2. Eins-zu-Viele (1 : n): Für jede Instanz aus dem einen Entitäts-Typen gibt es potenziell viele andere Instanzen aus dem anderen Beteiligten Entitäts-Typen, mit denen die Instanz in Verbindung stehen kann, aber diese stehen maximal in Verbindung zu dieser einen Instanz. Beispiel: Ein Dozent kann Modulverantwortlicher vieler Module sein, aber ein Modul kann nur einen Modulverantwortlichen haben.

3. Viele-zu-Viele (n : m): Für alle Instanzen aller Beteiligten Entitäts-Typen kann es potenziell viele andere Instanzen in den anderen Beteiligten Entitäts-Typen geben, mit welchen die Instanz in Verbindung steht. Beispiel: Eine Vorlesung kann viele Studierende haben, welche diese besuchen, aber jede Studierende Person kann auch viele Vorlesungen besuchen.

Wichtig ist hierbei zu verstehen, dass n, m oder andere Variablen lediglich das Verhältnis beschreiben und nie einen konkreten Wert annehmen, da wir über Klassen bzw. Entity-Typen sprechen. In unserem Beispiel dient es also nur dazu zu verbildlichen, dass Vorlesungen von vielen Studierenden besucht werden können und dass Studierende viele Vorlesungen besuchen können.

Die Kardinalität kann nicht angeben, ob sich jede Entity eines Entitytypen an einem Relationshiptypen beteiligen muss. Dies kann über die Totalität definiert werden, dargestellt durch einen schwarzen Punkt. Im folgenden Beispiel fordert der Totalitätspunkt, dass jedes modul von mindestens einem:einer Professor:in verwantwortet wird:

Wäre der Totalitätspunkt im obigen Beispiel nicht vorhanden, so könnte ein(e) Professor(in) Modulverantwortliche(r) von einem oder mehreren Modulen sein und ein Modul könnte einen oder keinen Verantwortlichen Professor oder Professorin haben.

Des Weiteren können Relationship-Typen, genauso wie die Entitäts-Typen, auch Attribute haben. Im Gegensatz zu Entity-Typen müssen Relationship-Typen aber keine Attribute haben.

Da Relationship-Typen Beziehungen zwischen Entitäts-Typen abbilden, dürfen diese nie direkt miteinander verbunden sein und auch Entity-Typen dürfen ebenfalls nie miteinander verbunden sein. Des Weiteren müssen Relationship-Typen auch nicht mit genau zwei Entitäts-Typen verbunden sein, wie wir es bisher gesehen haben, da Beziehungen nicht immer zwischen genau zwei Klassen stattfinden.Relationship-Typen können somit auch drei oder mehr Entity-Typen verbinden.

Rekursive Relationship-Typen

Relationship-Typenkönnen auch einen und den gleichen Entitäts-Typen mit sich selbst verbinden. Dies ist z.B. hilfreich, wenn wir für Module weitere Module als Voraussetzung abbilden möchten. Diese Relationship-Typen werden auch konkret als rekursive Relationship-Typen bezeichnet.

Zur Kennzeichung der Beziehung müssen bei rekursiven Relationship-Typen sogenannte Rollen angegeben werden. In unserem Beispiel stellen sie dar, dass Module Vorgänger- oder Nachfolgemodule für andere Module sein können.

Schwache Entity-Typen

Entities von Schwache Entity-Typen zeichnen sich darin aus, dass sie nur in Zusammenhang eines „normalen“ Entitytypen eindeutig identifiziert werden können. Falls bspw. unsere Datenbank nur Studierende aus einer einzigen Universität abbilden können soll, genügt es, für Studierende die MatrikelNummer als Identifikationsmerkmal zu nutzen. Sobald jedoch Studierende mehrerer Universitäten abgebildet werden sollen, könnte eine und die gleiche Matrikelnummer mehrfach vergeben sein. In diesem Fall muss die Studierende als schwacher Entitytyp modelliert werden, welcher nur im kontext einer Universität eindeutig ist.

Gekennzeichnet werden dabei schwache Entitäts-Typen mit einer doppelt umrahmten Box. Die Nadel seines schwachen Schlüssels, ist im Gegensatz zu einem normalen Schlüssel, nicht ausgefüllt, dafür aber durch eine gestrichelte Linie unterstrichen. Per doppelter Umrahmung werden webenfalls die Relationship-Typen gekennzeichnet, die dem schwachen Entitytypen seinen Kontext geben. Die ist nötig, da ein Entitäts-Typ an mehreren Beziehungen (Relationship-Typen) beteiligt sein kann, aber nicht alle Schlüssel dieser Entitäts-Typen notwendig seien müssen, um die Instanzen des schwachen Entitäts-Typen zu identifizieren.