Zurück

Konzeptueller Entwurf am Beispiel

In diesem Abschnitt kannst du die einzelnen Schritte von der Anforderungsanalyse bis zum konzeptuellen Entwurf eines ER-Diagramms in einer interaktiven Simulation durchgehen.

Schritte von der Anforderungsanalyse bis zum konzeptuellen Entwurf

Im Folgenden werden die einzelnen Schritte und die dahinterliegenden Überlegungen, die in der Simulation dargestellt werden, noch einmal genauer beschrieben:

Teil 1: Entitäten, Attribute und Beziehungen

Wann immer wir ein ER-Modell aufstellen wollen, benötigen wir Informationen über den Kontext, den wir modellieren wollen. In unserem Beispiel erhalten wir diese anhand einer kurzen Beschreibung in Textform.

Wir haben gelernt, dass Entitäten beispielsweise Personen oder Objekte modellieren. Im Beschreibungstext werden sie daher in den meisten Fällen als Nomen erkennbar sein.

Allerdings können Nomen auch für Attribute, also die Eigenschaften der Objekte oder Personen, stehen. Wir müssen daher im Text alle möglichen Nomen finden und in jedem Fall entscheiden, ob sie eines von beidem repräsentieren.

Den dritten Hauptbestandteil eines ER-Modells bilden die Beziehungen zwischen den Entitäten. Da sie keine Objekte repräsentieren, müssen wir diese aus dem Kontext schließen. In vielen Fällen sind sie durch Verben maskiert, welche sich in der Nähe der beteiligten Entitätsnomen befinden.

Es ist zudem möglich, dass Beziehungen mit Attributen verfeinert werden müssen, um zwischen gleichartigen Fällen zu unterscheiden. Um beispielsweise modellieren zu können, dass ein Supermarkt mehrere Einkäufe abwickelt, bei denen die Kunden dieselbe Anzahl derselben Sorte Kaltgetränk erwerben, kann die Beziehung „verkauft_Kaltgetränk" um eine Einkaufs-ID erweitert werden, die diese Fälle eindeutig differenziert.

Nachdem nun alle Entitäten und Beziehungen bestimmt sind, müssen wir das Modell nach solchen Entitätsklassen durchsuchen, die nur dann existieren können, wenn sie in Beziehung mit einer anderen Entitätsklasse stehen. Solche Entitäten stehen in einer Identifikationsabhängigkeit und heißen auch schwache Entitäten. Im Diagramm werden sie durch eine doppelte Umrandung dargestellt. Sie sind in jedem Fall mit mindestens einer Beziehung verknüpft, welche ebenfalls doppelt umrahmt ist. Es sind diese Beziehungen, in denen sich das Objekt befinden muss, um zu existieren.

Teil 2: Kardinalitäten

Als Nächstes sollen die Kardinalitäten bestimmt werden. Diese geben an, wie viele Exemplare einer Entität Teil dieser Beziehung sind. Um sie zu bestimmen, reicht es nicht, lediglich den Text zu lesen. Stattdessen muss aus dem Kontext gefolgert werden, wie die Werte zu belegen sind.

Eine gute Methode, diese Analyse durchzuführen, ist das gedankliche Fixieren einer Entität, um die Kardinalitäten der anderen zu bestimmen. Um also beispielsweise für die Beziehung A <R> B die Kardinalitäten zu bestimmen, fixieren wir zuerst die Entität A und überlegen, wie viele Exemplare von B mit genau einem der Sorte A in Beziehung stehen können. Diesen Wert schreiben wir dann B zu. Danach fixieren wir B und entscheiden, wie oft A in Beziehung mit einem Exemplar von B stehen kann.

Im Gegensatz zu UML notieren wir „n-fache“ Kardinalitäten (Entität A kann n-fach mit B in Beziehung stehen) in der für ER-Diagramme gängigen Chen-Notation nicht etwa als 1 ... n, sondern lediglich als *.

Teil 3: Schlüsselattribute

Um die Entitäten in den Datenbanken eindeutig und mit möglichst wenig Aufwand voneinander zu unterscheiden, benötigen sie ein oder mehrere Schlüsselattribute. Dies sind solche Attribute, die zusammen genommen genau eine Entität identifizieren. Da für eine Entität mehrere sogenannte Schlüsselkandidaten (Teilmengen der Attribute, die die Entität eindeutig identifizieren) existieren, ist der Primärschlüssel einer Entität minimal, das heißt, er besteht aus so wenigen Attributen wie nötig. Des Weiteren müssen Primärschlüssel definiert werden, also für alle Entitäten nicht NULL sein.

Für das Beispiel müssen wir uns jetzt also auf die Suche nach solchen Primärschlüsseln für jede Entität begeben. Unter Umständen bemerken wir, dass in der bestehenden Attributmenge kein Schlüsselkandidat existiert. In diesem Fall müssen wir ein weiteres Attribut erzeugen, welches diese Eigenschaft besitzt. Hierfür eignen sich IDs, also Zeichenketten, die je Entitätsklasse eindeutig vergeben werden und daher nicht mehrfach auftreten können.