31.10.2013 Aufrufe

Das Entity- Relationship-Modell - mediendb.hjr-verlag.de ...

Das Entity- Relationship-Modell - mediendb.hjr-verlag.de ...

Das Entity- Relationship-Modell - mediendb.hjr-verlag.de ...

MEHR ANZEIGEN
WENIGER ANZEIGEN

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.

Gunter<br />

Saake<br />

Kai-Uwe<br />

Sattler<br />

Andreas<br />

Heuer<br />

5. Auflage<br />

Datenbanken<br />

Konzepte und Sprachen


3<br />

<strong>Das</strong> <strong>Entity</strong>-<br />

<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong><br />

Datenmo<strong>de</strong>lle dienen in <strong>de</strong>r Informatik <strong>de</strong>r Erfassung und Darstellung <strong>de</strong>r Informationsstruktur<br />

einer Anwendung, nicht <strong>de</strong>r Informationen selbst. Im Datenbankbereich<br />

gibt es verschie<strong>de</strong>ne Einsatzzwecke. Als Entwurfsmo<strong>de</strong>lle für<br />

die frühen Phasen <strong>de</strong>r Entwicklung von Datenbankanwendungen sind sie weitgehend<br />

unabhängig von <strong>de</strong>r späteren Implementierungsplattform und dienen<br />

auch als Mittel zur Kommunikation mit <strong>de</strong>m Anwen<strong>de</strong>r o<strong>de</strong>r Auftraggeber.<br />

Realisierungsmo<strong>de</strong>lle wer<strong>de</strong>n dagegen zur Implementierung <strong>de</strong>s Datenbankentwurfs<br />

in einem konkreten System eingesetzt und beschreiben somit die <strong>Mo<strong>de</strong>ll</strong>ierungsmöglichkeiten<br />

dieses Systems.<br />

In diesem Kapitel wer<strong>de</strong>n wir nach einigen grundlegen<strong>de</strong>n Überlegungen<br />

zur Rolle von Datenbankmo<strong>de</strong>llen zunächst das klassische Entwurfsmo<strong>de</strong>ll für<br />

Datenbanken kennenlernen – das <strong>Entity</strong>-<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong>.<br />

3.1 Datenbankmo<strong>de</strong>lle<br />

Die Konzepte eines Datenbankmo<strong>de</strong>lls (im Weiteren auch als Datenmo<strong>de</strong>ll bezeichnet)<br />

zur Darstellung einer Informationsstruktur umfassen<br />

1. statische Eigenschaften wie a) Objekte und b) Beziehungen, inklusive <strong>de</strong>r<br />

Standarddatentypen, die Daten über die Beziehungen und Objekte darstellen<br />

können,<br />

2. dynamische Eigenschaften wie a) Operationen und b) Beziehungen zwischen<br />

Operationen sowie<br />

51<br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519


3. Integritätsbedingungen an a) Objekte und b) Operationen.<br />

Objekte sind dabei etwa (Daten über) Weine und Weingüter (Erzeuger), aber<br />

auch über Ereignisse wie die Bestellung eines Weines bei einem Händler (1a).<br />

Ein Beispiel für eine Beziehung zwischen diesen Objekten ist die Tatsache, dass<br />

ein Erzeuger einen Wein produziert (1b). Operationen auf Objekten sind das Bestellen<br />

eines Weines o<strong>de</strong>r die Berechnung <strong>de</strong>s Preises unter Einbeziehung von<br />

Steuern (2a). Beziehungen zwischen Operationen können zum Beispiel festlegen,<br />

dass ein Wein erst dann bestellt wer<strong>de</strong>n darf, wenn er produziert wird<br />

(2b). Als Integritätsbedingung können wir festlegen, dass die Bestellnummer<br />

eines Weines ein<strong>de</strong>utig sein muss (Schlüsselbedingung, 3a), dass es zu je<strong>de</strong>m<br />

Wein auch einen Erzeuger geben muss (referentielle Integrität, 3a) o<strong>de</strong>r dass<br />

das Alter eines Weines nur erhöht wer<strong>de</strong>n kann (Übergangsbedingung, 3b).<br />

Datenmo<strong>de</strong>lle sind in vielen Gebieten <strong>de</strong>r Informatik grundlegend. Beispielsweise<br />

gibt es in folgen<strong>de</strong>n Bereichen spezifische Datenmo<strong>de</strong>lle:<br />

• Programmiersprachen: Typsysteme wie in C o<strong>de</strong>r Java,<br />

• Expertensysteme: Wissensrepräsentationsmetho<strong>de</strong>n wie semantische Netze,<br />

logische Formeln o<strong>de</strong>r Framestrukturen,<br />

• Graphiksysteme: Repräsentationsmo<strong>de</strong>lle wie das Begrenzungsmo<strong>de</strong>ll<br />

(Boundary Representation, BRep) o<strong>de</strong>r die Constructive Solid Geometry<br />

(CSG),<br />

• Datenbanksysteme: Datenbankmo<strong>de</strong>lle, mit <strong>de</strong>nen wir uns in diesem Kapitel<br />

beschäftigen.<br />

Tabelle 3.1 stellt die Begriffe Datenbankmo<strong>de</strong>ll, Datenbankschema und Datenbank<br />

<strong>de</strong>r <strong>de</strong>n meisten Lesern vertrauten Begriffswelt imperativer Programmiersprachen<br />

gegenüber. Ein Datenbankmo<strong>de</strong>ll entspricht einem Typsystem<br />

einer Programmiersprache, in <strong>de</strong>m die Strukturierungskonzepte für die manipulierten<br />

Daten festgelegt wer<strong>de</strong>n. Ein Datenbankschema entspricht in dieser<br />

Analogie <strong>de</strong>n Variablen<strong>de</strong>klarationen, während die eigentliche Datenbank <strong>de</strong>n<br />

<strong>de</strong>n Variablen zugewiesenen Daten (<strong>de</strong>n Werten) entspricht.<br />

Klassische Datenbankmo<strong>de</strong>lle sind speziell geeignet für:<br />

• große Informationsmengen mit relativ starrer Struktur und<br />

• die Darstellung statischer Eigenschaften und Integritätsbedingungen (umfasst<br />

somit die Bereiche 1a, 1b und 3a).<br />

Als Operationen sind in <strong>de</strong>n klassischen Datenbankmo<strong>de</strong>llen nur die Standard-<br />

Anfrage- und Än<strong>de</strong>rungsoperationen vorhan<strong>de</strong>n, die objektspezifische Operationen<br />

nicht adäquat mo<strong>de</strong>llieren und unterschei<strong>de</strong>n können.<br />

52 3 <strong>Das</strong> <strong>Entity</strong>-<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong><br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519


Datenbankkonzept<br />

Datenbankmo<strong>de</strong>ll<br />

Typsystem einer<br />

Programmiersprache<br />

Typsystem<br />

Relation, Attribut . . . int, struct ...<br />

Datenbankschema<br />

Variablen<strong>de</strong>klaration<br />

relation WEIN = (...)<br />

Datenbank<br />

WEIN(4961, ’Chardonnay’, ’Weiß’, . . . )<br />

var x: int, y: struct Wein<br />

Werte<br />

42, ’Cabernet Sauvignon’<br />

Tabelle 3.1: Gegenüberstellung von Datenbankkonzepten zu Konzepten imperativer Programmiersprachen<br />

Zu <strong>de</strong>n klassischen Datenbankmo<strong>de</strong>llen zählen abstrakte Datenbankmo<strong>de</strong>lle,<br />

die speziell für <strong>de</strong>n Datenbankentwurf geeignet sind, und konkrete Datenbankmo<strong>de</strong>lle,<br />

die zur Implementierung dieses Entwurfs mit einem konkreten<br />

Datenbanksystem bereitstehen. Tabelle 3.2 zeigt einige Beispiele und<br />

gleichzeitig <strong>de</strong>n Zusammenhang mit Programmiersprachen: Auch hier gibt es<br />

abstrakte Notationen für Algorithmen und konkrete Implementierungen als<br />

Programm in einer konkreten Programmiersprache.<br />

<strong>Mo<strong>de</strong>ll</strong>e Daten Algorithmen<br />

abstrakt <strong>Entity</strong>-<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong> Struktogramme<br />

konkret Hierarchisches <strong>Mo<strong>de</strong>ll</strong> Pascal<br />

Netzwerkmo<strong>de</strong>ll<br />

C, C++<br />

Relationenmo<strong>de</strong>ll Java, C#<br />

Tabelle 3.2: <strong>Mo<strong>de</strong>ll</strong>e für Daten und Algorithmen in verschie<strong>de</strong>nen Abstraktionsstufen<br />

In diesem Kapitel und <strong>de</strong>m folgen<strong>de</strong>n Kapitel 4 wer<strong>de</strong>n wir zunächst zwei<br />

<strong>de</strong>r klassischen Datenbankmo<strong>de</strong>lle vorstellen. In <strong>de</strong>n späteren Kapiteln wer<strong>de</strong>n<br />

dann auch noch einige neuere Datenbankmo<strong>de</strong>lle eingeführt.<br />

Abbildung 3.1 beinhaltet eine historische Einordnung sowie einen Überblick<br />

über die Bezüge zwischen <strong>de</strong>n vorgestellten Datenbankmo<strong>de</strong>llen. Dabei<br />

be<strong>de</strong>uten HM: hierarchisches <strong>Mo<strong>de</strong>ll</strong>, NWM: Netzwerkmo<strong>de</strong>ll, RM: Relationenmo<strong>de</strong>ll,<br />

NF 2 : <strong>Mo<strong>de</strong>ll</strong> <strong>de</strong>r geschachtelten (Non-First-Normal-Form = NF 2 ) Relationen,<br />

eNF 2 : erweitertes NF 2 -<strong>Mo<strong>de</strong>ll</strong>, ER: <strong>Entity</strong>-<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong>, SDM:<br />

semantische Datenmo<strong>de</strong>lle, OODM / C++: objektorientierte Datenmo<strong>de</strong>lle auf<br />

Basis objektorientierter Programmiersprachen wie C++, OEM: objektorientierte<br />

Entwurfsmo<strong>de</strong>lle (etwa UML), ORDM: objektrelationale Datenmo<strong>de</strong>lle.<br />

Die genannten <strong>Mo<strong>de</strong>ll</strong>e lassen sich wie folgt kurz charakterisieren:<br />

3.1 Datenbankmo<strong>de</strong>lle 53<br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519


ab Mitte<br />

1960<br />

implementierungsnah<br />

HM<br />

abstrakt<br />

1970<br />

NWM<br />

SQL<br />

RM<br />

ER<br />

1980<br />

1990<br />

OODM<br />

(C++)<br />

ODMG<br />

ORDM<br />

NF 2<br />

eNF 2<br />

OEM<br />

UML<br />

SDM<br />

2000<br />

SQL:1999<br />

2005<br />

SQL:2003<br />

Abbildung 3.1: Historische Einordnung und Bezüge zwischen einigen <strong>de</strong>r vorgestellten<br />

Datenbankmo<strong>de</strong>lle<br />

• Hierarchisches <strong>Mo<strong>de</strong>ll</strong> (HM)<br />

Die Datenbestän<strong>de</strong> wer<strong>de</strong>n angelehnt an hierarchisch strukturierte Dateiformate<br />

beschrieben. Beginnend in <strong>de</strong>n 70er Jahren ist das hierarchische<br />

<strong>Mo<strong>de</strong>ll</strong> (neben <strong>de</strong>m Netzwerkmo<strong>de</strong>ll) das erfolgreichste <strong>de</strong>r Datenbankmo<strong>de</strong>lle<br />

<strong>de</strong>r ersten Generation.<br />

• Netzwerkmo<strong>de</strong>ll (NWM)<br />

Der Datenbestand besteht aus verketteten Datensätzen (Records), die ein<br />

Netzwerk bil<strong>de</strong>n. Zur Verkettung wer<strong>de</strong>n zweistellige funktionale Beziehungen<br />

genutzt. Der Zugriff auf die einzelnen Datensätze geschieht mittels<br />

Navigation. Alle Programme wer<strong>de</strong>n in einer Programmiersprache (<strong>de</strong>r sogenannten<br />

Wirtssprache) geschrieben, die um spezielle Kommandos wie<br />

find (Suchen und Positionieren), get (Datentransfer zum Anwendungsprogramm)<br />

und store (Datentransfer zur Datenbank) erweitert wird.<br />

• Relationenmo<strong>de</strong>ll (RM)<br />

Im Relationenmo<strong>de</strong>ll wer<strong>de</strong>n die Daten als flache (ungeschachtelte) Tabellen<br />

dargestellt. Tabellen sind Mengen von Tupeln. Beziehungen wer<strong>de</strong>n<br />

ausschließlich über Wertegleichheit ausgedrückt.<br />

54 3 <strong>Das</strong> <strong>Entity</strong>-<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong><br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519


• SQL-Datenmo<strong>de</strong>ll (SQL)<br />

<strong>Das</strong> SQL-Datenmo<strong>de</strong>ll erweitert das theoretische Relationenmo<strong>de</strong>ll um einige<br />

weitere Aspekte: Tabellen als Multimengen und als Mengen wer<strong>de</strong>n<br />

unterschie<strong>de</strong>n; eine Reihe von unterschiedlichen Wertebereichen (unter<br />

an<strong>de</strong>rem lange Fel<strong>de</strong>r, Strings, Datumswerte) und Nullwerte wer<strong>de</strong>n eingeführt;<br />

Gruppierung und Sortierung (im flachen Relationenmo<strong>de</strong>ll nicht<br />

ausdrückbare Operationen) wer<strong>de</strong>n in <strong>de</strong>r Anfragesprache unterstützt.<br />

• <strong>Mo<strong>de</strong>ll</strong> <strong>de</strong>r geschachtelten (Non-First-Normal-Form) Relationen (NF 2 )<br />

<strong>Das</strong> NF 2 -<strong>Mo<strong>de</strong>ll</strong> stellt eine Erweiterung <strong>de</strong>s Relationenmo<strong>de</strong>lls um hierarchische<br />

Schachtelung dar: Attribute dürfen in diesem <strong>Mo<strong>de</strong>ll</strong> Relationen<br />

als Werte haben.<br />

• Erweitertes NF 2 -<strong>Mo<strong>de</strong>ll</strong> (eNF 2 )<br />

Die Erweiterung <strong>de</strong>r geschachtelten Relationen <strong>de</strong>s NF 2 -<strong>Mo<strong>de</strong>ll</strong>s um die<br />

Kollektionstypen Liste und Multimenge sowie die orthogonale Schachtelung<br />

aller Typkonstruktoren führt zum eNF 2 -<strong>Mo<strong>de</strong>ll</strong>.<br />

• <strong>Entity</strong>-<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong> (ERM)<br />

<strong>Das</strong> ER-<strong>Mo<strong>de</strong>ll</strong> ist ein abstraktes <strong>Mo<strong>de</strong>ll</strong>, in <strong>de</strong>m Datenbestän<strong>de</strong> durch abstrakte<br />

Datensätze (Entities), beliebige Beziehungen (<strong>Relationship</strong>s) und<br />

Attribute mo<strong>de</strong>lliert wer<strong>de</strong>n.<br />

Dieses <strong>Mo<strong>de</strong>ll</strong> wird hauptsächlich für <strong>de</strong>n Entwurf von Datenbanken eingesetzt.<br />

• Semantische Datenmo<strong>de</strong>lle (SDM)<br />

Semantische Datenmo<strong>de</strong>lle erweitern das ER-<strong>Mo<strong>de</strong>ll</strong> um weitere Abstraktionskonzepte<br />

(Spezialisierung, Generalisierung, komplexe Objekte) bzw.<br />

stellen Neuentwicklungen basierend auf diesen Konzepten dar. Hier wer<strong>de</strong>n<br />

auch erweiterte ER-<strong>Mo<strong>de</strong>ll</strong>e eingeordnet.<br />

Auch diese <strong>Mo<strong>de</strong>ll</strong>e wer<strong>de</strong>n primär als Entwurfsdatenmo<strong>de</strong>lle eingesetzt.<br />

• Objektorientierte Datenmo<strong>de</strong>lle auf Basis objektorientierter Programmiersprachen<br />

wie C++ (OODM)<br />

<strong>Das</strong> Typsystem <strong>de</strong>r Programmiersprache wird direkt als Datenbankmo<strong>de</strong>ll<br />

eingesetzt. Naturgemäß ist die Umsetzung in <strong>de</strong>r Datenbank sehr implementierungsnah;<br />

es existiert keine physische Datenunabhängigkeit.<br />

• Objektorientierte Entwurfsmo<strong>de</strong>lle (OEM)<br />

Objektorientierte <strong>Mo<strong>de</strong>ll</strong>ierungskonzepte (Kapselung, Metho<strong>de</strong>n, Spezialisierung,<br />

Referenzen) wer<strong>de</strong>n mit <strong>de</strong>n Konzepten von ER-<strong>Mo<strong>de</strong>ll</strong>en vereinigt<br />

(<strong>Entity</strong> = Objekt). Im Gegensatz zu <strong>de</strong>n programmiersprachenbasierten<br />

OODM-Ansätzen wird <strong>de</strong>r extensionale Aspekt von Klassen (Klasse als<br />

Kollektion von Objekten) betont.<br />

3.1 Datenbankmo<strong>de</strong>lle 55<br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519


• ODMG-Standard<br />

<strong>Das</strong> Datenbankmo<strong>de</strong>ll <strong>de</strong>s ODMG-Standards ist eine Weiterentwicklung<br />

<strong>de</strong>r programmiersprachenbasierten OODM-Ansätze durch Aufnahme datenbankspezifischer<br />

<strong>Mo<strong>de</strong>ll</strong>ierungskonzepte. Beson<strong>de</strong>rs bei <strong>de</strong>r Anfragesprache<br />

wur<strong>de</strong>n auch Konzepte von SQL übernommen.<br />

• Objektrelationale Datenmo<strong>de</strong>lle (ORDM) und SQL-Standard SQL:2003<br />

Objektrelationale Datenbanken stellen eine evolutionäre Erweiterung von<br />

relationalen Datenbanken um Konzepte <strong>de</strong>r Objektorientierung dar. Mit<br />

<strong>de</strong>n Standards SQL:1999 und SQL:2003 wur<strong>de</strong>n Erweiterungen <strong>de</strong>s relationalen<br />

<strong>Mo<strong>de</strong>ll</strong>s um objektorientierte Konzepte wie abstrakte Datentypen,<br />

Spezialisierungshierarchien für Tabellen sowie Objekti<strong>de</strong>ntifikatoren eingeführt.<br />

3.2 Semantikfestlegung für Datenbankmo<strong>de</strong>lle<br />

Wie legt man die Semantik eines Datenbankmo<strong>de</strong>lls fest? Als Datenbankmo<strong>de</strong>ll<br />

bezeichnen wir eine abstrakte Sprache zur Beschreibung von Datenbankschemata,<br />

und ein <strong>de</strong>rart beschriebenes Datenbankschema beschreibt mögliche<br />

Datenbanken als Instanzen sowie die Möglichkeiten, diese Datenbanken zu än<strong>de</strong>rn.<br />

In letzter Konsequenz legt ein Datenbankmo<strong>de</strong>ll somit die Semantik von<br />

Datenbankschemata fest, die wie<strong>de</strong>rum Abfolgen von Datenbanken charakterisieren,<br />

wie sie von einem Datenbankmanagementsystem verwaltet wer<strong>de</strong>n.<br />

Ein Datenbanksystem kann als lange Zeit laufen<strong>de</strong>r Prozess aufgefasst<br />

wer<strong>de</strong>n, <strong>de</strong>ssen jeweils aktueller Zustand <strong>de</strong>n Inhalt <strong>de</strong>r Datenbank festlegt.<br />

Eine formale Semantikfestlegung kann einen <strong>de</strong>rartigen Systemlauf als lineare<br />

Folge von Zustän<strong>de</strong>n mo<strong>de</strong>llieren, wobei je<strong>de</strong>r Zustand einer Datenbank entspricht,<br />

und die Übergänge die Än<strong>de</strong>rungen <strong>de</strong>r Datenbank mo<strong>de</strong>llieren, etwa<br />

das Einfügen eines Datenelements.<br />

Eine <strong>de</strong>rartige Semantikfestlegung ist uns von imperativen Programmiersprachen<br />

bekannt: Dort wer<strong>de</strong>n die Zustän<strong>de</strong> zum Teil durch die aktuellen Belegungen<br />

<strong>de</strong>r Variablen festgelegt, und ein Zustandsübergang kann diese Belegung<br />

durch <strong>de</strong>n Zuweisungsoperator än<strong>de</strong>rn. Die Semantikfestlegung für Datenbanksysteme<br />

kann somit als Erweiterung <strong>de</strong>rartiger Programmiersprachensemantiken<br />

aufgefasst wer<strong>de</strong>n: Datenbankzustän<strong>de</strong> wer<strong>de</strong>n durch Variablen zu<br />

einem strukturierten Datentyp (in <strong>de</strong>r Regel basierend auf <strong>de</strong>m Mengenkonstruktor)<br />

mo<strong>de</strong>lliert, und <strong>de</strong>r Zuweisungsoperator wird durch elementare Operationen<br />

(etwa Einfügen o<strong>de</strong>r Löschen von Elementen) auf diesen Variablen<br />

ersetzt.<br />

Abbildung 3.2 zeigt eine Zustandsfolge für einen Ausschnitt unserer Weindatenbank.<br />

Es wer<strong>de</strong>n die ersten drei Zustän<strong>de</strong> σ 0 bis σ 2 gezeigt. Beim ersten<br />

56 3 <strong>Das</strong> <strong>Entity</strong>-<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong><br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519


(Zinfan<strong>de</strong>l, Rot,2004, Helena)<br />

(Pinot Noir, Rot, 2001, Creek)<br />

(Zinfan<strong>de</strong>l, Rot,2004, Helena)<br />

(Pinot Noir, Rot, 2001, Creek)<br />

(Creek Shiraz, Rot, 2003, Creek)<br />

σ 0<br />

σ 1<br />

σ 2<br />

(Zinfan<strong>de</strong>l, Rot,2004, Helena)<br />

(Pinot Noir, Rot, 2001, Creek)<br />

Abbildung 3.2: Beispiel für eine Datenbankzustandsfolge<br />

Zustandsübergang bleibt <strong>de</strong>r Inhalt <strong>de</strong>r Datenbank unverän<strong>de</strong>rt, beim Übergang<br />

von σ 1 auf σ 2 wird ein neuer Wein hinzugefügt.<br />

Die konkreten Semantikfestlegungen für Datenbankmo<strong>de</strong>lle sind natürlich<br />

etwas ausgefeilter als diese direkte <strong>Mo<strong>de</strong>ll</strong>ierung. Wir wer<strong>de</strong>n das Prinzip an<br />

einem einfachen Beispiel kurz erläutern und danach jeweils bei <strong>de</strong>n konkreten<br />

Datenbankmo<strong>de</strong>llen ausgereiftere Semantikfestlegungen angeben. Statt Folgen<br />

von Datenbankzustän<strong>de</strong>n wird bei <strong>de</strong>r Semantikfestlegung vereinfachend<br />

jeweils die Menge <strong>de</strong>r möglichen Datenbankzustän<strong>de</strong> festgelegt.<br />

Als Beispiel behan<strong>de</strong>ln wir ein einfaches Datenmo<strong>de</strong>ll, das als Datenbankobjekte<br />

Mengen von Tupeln betrachtet. Dieses <strong>Mo<strong>de</strong>ll</strong> ist eine vereinfachte Version<br />

<strong>de</strong>s relationalen Datenbankmo<strong>de</strong>lls, das später in diesem Buch intensiv<br />

behan<strong>de</strong>lt wer<strong>de</strong>n wird. In unserem Beispiel – wie in Abbildung 3.2 – sollen Daten<br />

über Weine gespeichert wer<strong>de</strong>n. Dazu wollen wir in <strong>de</strong>r Datenbank unter<br />

<strong>de</strong>m Begriff Wein jeweils Einträge <strong>de</strong>r Form (Name, Farbe, Jahrgang, Weingut)<br />

speichern.<br />

Als Basisdatentypen verwen<strong>de</strong>n wir die ganzen Zahlen integer sowie Zeichenketten<br />

string. Die Konstruktoren tuple und set erlauben die Konstruktion<br />

komplexerer Datenstrukturen und stellen die Basisoperationen für diese Datenstrukturen<br />

bereit, etwa insert und <strong>de</strong>lete für Mengen. Die Notation set(z)<br />

be<strong>de</strong>utet, dass <strong>de</strong>r Konstruktor set auf <strong>de</strong>n Datentyp z angewen<strong>de</strong>t wird.<br />

Für je<strong>de</strong>n Datentyp legen wir nun eine Trägermenge als Be<strong>de</strong>utung <strong>de</strong>s<br />

Datentyps fest (und Funktionen auf diesen Trägermengen als Be<strong>de</strong>utung <strong>de</strong>r<br />

Operationen). Wir bezeichnen diese Trägermengen als mögliche Werte und notieren<br />

diese Zuordnung mit <strong>de</strong>m griechischen Buchstaben µ (gesprochen mü).<br />

• µ(integer) = Z<br />

(die ganzen Zahlen Z)<br />

3.2 Semantikfestlegung für Datenbankmo<strong>de</strong>lle 57<br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519


• µ(string) = C ∗<br />

(Folgen von Zeichen aus C = {a,b,...,z,A,B,...,Z,...})<br />

• µ(set(z)) = 2 µ(z)<br />

(die Potenzmenge über <strong>de</strong>n Werten <strong>de</strong>s Parameterdatentyps z, o<strong>de</strong>r an<strong>de</strong>rs<br />

ausgedrückt, die Menge aller Teilmengen von möglichen Werten in µ(z)) 1<br />

• µ(tuple(z 1 ,...,z n )) = µ(z 1 ) × ··· × µ(z n )<br />

(das kartesische Produkt <strong>de</strong>r Parameterwertebereiche)<br />

Die Semantik eines Datenbankschemas ist zustandsbasiert: Eine Zustandsfunktion<br />

ˆσ (ausgesprochen Sigma Dach) ordnet je<strong>de</strong>r „Datenbankvariablen“ in<br />

je<strong>de</strong>m Zustand einen Wert zu. Allgemein entspricht eine Datenbankentwicklung<br />

einer Folge<br />

ˆσ = 〈σ 0 ,σ 1 ,...,σ i ,...〉<br />

<strong>Das</strong> Dach über <strong>de</strong>m Sigma soll die aufgespannte Folge von einzelnen Zustän<strong>de</strong>n<br />

σ i an<strong>de</strong>uten. Im Datenbankbereich gehen wir in <strong>de</strong>r Regel von unendlichen<br />

Folgen aus – die Datenbestän<strong>de</strong> sind beliebig lange persistent. Als Menge <strong>de</strong>r<br />

Datenbankzustän<strong>de</strong> nehmen wir Punkte einer Zeitachse T (in <strong>de</strong>r Regel die<br />

natürlichen Zahlen), so dass wir für eine Datenbankvariable db Folgen<strong>de</strong>s erhalten:<br />

ˆσ(db): T → µ(typ(db))<br />

wobei typ(db) <strong>de</strong>n Datentyp <strong>de</strong>r Datenbankvariablen bezeichnet. In unserem<br />

konkreten Beispiel <strong>de</strong>r Weindatenbank haben wir die Funktion<br />

ˆσ(WEINE): T → 2 C∗ ×C ∗ ×ZZ×C ∗<br />

als Semantik unseres einfachen Datenbankschemas. Ein konkreter Zustandswert,<br />

etwa zum Zeitpunkt 42, könnte dann wie folgt lauten:<br />

ˆσ(WEINE)(42) = {(’Zinfan<strong>de</strong>l’,’Rot’,2004,’Helena’),<br />

(’Pinot Noir’,’Rot’,2001,’Creek’)}<br />

Dieses Beispiel sollte die prinzipielle Vorgehensweise an<strong>de</strong>uten, mit <strong>de</strong>r man<br />

die Semantik von Datenbankschemata festlegen kann. Wir folgen <strong>de</strong>n prinzipiellen<br />

Konventionen (µ für mögliche Werte, σ für Zustän<strong>de</strong>) in <strong>de</strong>n weiteren<br />

1 Genau genommen nur die endlichen Teilmengen <strong>de</strong>r Potenzmenge 2 µ(z) : Wir haben an dieser<br />

Stelle eine vereinfachte Darstellung gewählt, um <strong>de</strong>n verwen<strong>de</strong>ten mathematischen Apparat<br />

nicht unnötig aufzublähen.<br />

58 3 <strong>Das</strong> <strong>Entity</strong>-<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong><br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519


Kapiteln, wer<strong>de</strong>n aber die Notationen jeweils an die Konventionen <strong>de</strong>r betrachteten<br />

Datenmo<strong>de</strong>lle anpassen. Des weiteren betrachten wir in <strong>de</strong>r Regel einen<br />

festen Datenbankzustand ˆσ(i), ohne dass <strong>de</strong>m i eine beson<strong>de</strong>re Be<strong>de</strong>utung zuzuordnen<br />

sei, und notieren diesen Zustand abkürzend als σ.<br />

3.3 Grundlagen <strong>de</strong>s <strong>Entity</strong>-<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong>s<br />

Der Begriff <strong>de</strong>s <strong>Entity</strong>-<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong>s (kurz ER-<strong>Mo<strong>de</strong>ll</strong>) geht zurück auf<br />

einen grundlegen<strong>de</strong>n Artikel von P. P. Chen im Jahre 1976 [Che76]. Seit dieser<br />

Zeit hat sich dieses Datenmo<strong>de</strong>ll fest im Bereich <strong>de</strong>r Datenbankmo<strong>de</strong>lle<br />

etabliert und wird – in abgewan<strong>de</strong>lten Formen – heutzutage faktisch als Standardmo<strong>de</strong>ll<br />

für frühe Entwurfsphasen <strong>de</strong>r Datenbankentwicklung eingesetzt.<br />

Zum ER-<strong>Mo<strong>de</strong>ll</strong> gehört eine graphische Notation, mit <strong>de</strong>r<br />

(Datenbank-)Schemata mo<strong>de</strong>lliert wer<strong>de</strong>n können, die – wie im vorigen Abschnitt<br />

erläutert – die Struktur <strong>de</strong>r Datenbank auf einer noch abstrakten,<br />

implementierungsunabhängigen Ebene beschreiben. Ein solches ER-Schema<br />

o<strong>de</strong>r auch ER-Diagramm (ERD) ist aufgrund <strong>de</strong>r wenigen benötigten Konzepte<br />

und <strong>de</strong>r einfachen Notation auch für Nicht-Datenbankspezialisten (d.h. die<br />

Anwen<strong>de</strong>r o<strong>de</strong>r Auftraggeber – die Domänenexperten) verständlich und daher<br />

sehr gut für die frühen Entwurfsphasen und die Kommunikation mit diesen<br />

Nutzern geeignet.<br />

3.3.1 Grundkonzepte <strong>de</strong>s klassischen ER-<strong>Mo<strong>de</strong>ll</strong>s<br />

<strong>Das</strong> <strong>Entity</strong>-<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong> basiert auf <strong>de</strong>n drei Grundkonzepten <strong>Entity</strong> als<br />

zu mo<strong>de</strong>llieren<strong>de</strong> Informationseinheit, <strong>Relationship</strong> zur <strong>Mo<strong>de</strong>ll</strong>ierung von Beziehungen<br />

zwischen <strong>Entity</strong>s und Attribut als Eigenschaft von einem <strong>Entity</strong> o<strong>de</strong>r<br />

einer Beziehung. Neben <strong>de</strong>m englischen Lehnwort <strong>Entity</strong> sind in <strong>de</strong>utschsprachigen<br />

Dokumenten die Begriffe Objekt, Ding o<strong>de</strong>r gar Entität vorgeschlagen.<br />

Wir verzichten auf diese Ein<strong>de</strong>utschungen, da die Begriffe zum Teil in <strong>de</strong>r allgemeinen<br />

Informatik an<strong>de</strong>rs belegt sind (etwa Objekt), zum an<strong>de</strong>ren Teil in <strong>de</strong>r<br />

Umgangssprache (Ding) o<strong>de</strong>r <strong>de</strong>m Fremdwörtergebrauch (Entität) 2 an<strong>de</strong>rs verwen<strong>de</strong>t<br />

wer<strong>de</strong>n. Neben <strong>de</strong>m Begriff <strong>Relationship</strong> sind die Begriffe Beziehung<br />

und Relation mit verbreitet.<br />

2 Gebräuchliche Be<strong>de</strong>utungen <strong>de</strong>s Begriffs Entität sind etwa die folgen<strong>de</strong>n:<br />

• Brockhaus Enzyklopädie, Band 6: Entität [mlat.] die, -/-en, Philosophie: die bestimmte Seinsverfassung<br />

(Wesen) <strong>de</strong>s einzelnen Seien<strong>de</strong>n, auch dieses selbst.<br />

• Du<strong>de</strong>n Fremdwörterbuch: Entität [lat.-mlat.] die, -, -en: 1. <strong>Das</strong>ein im Unterschied zum Wesen<br />

eines Dinges (Philos.). 2. [gegebene] Größe<br />

Trotz dieses sehr spezifischen Fremdwortgebrauchs wird Entität wie<strong>de</strong>rholt als <strong>de</strong>utsches Gegenstück<br />

zu <strong>Entity</strong> vorgeschlagen.<br />

3.3 Grundlagen <strong>de</strong>s <strong>Entity</strong>-<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong>s 59<br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519


Die drei Basisbegriffe <strong>Entity</strong>, <strong>Relationship</strong> und Attribut können wie folgt<br />

charakterisiert wer<strong>de</strong>n:<br />

<strong>Entity</strong> ist ein Objekt <strong>de</strong>r realen o<strong>de</strong>r <strong>de</strong>r Vorstellungswelt, über das Informationen<br />

zu speichern sind, z.B. ein Wein, ein Weingut, ein Produkt, ein<br />

Kun<strong>de</strong> o<strong>de</strong>r auch ein Stu<strong>de</strong>nt o<strong>de</strong>r Professor. Auch Informationen über Ereignisse<br />

wie Bestellungen o<strong>de</strong>r Prüfungen können Objekte im Sinne <strong>de</strong>s<br />

ER-<strong>Mo<strong>de</strong>ll</strong>s sein.<br />

<strong>Relationship</strong> repräsentiert eine Beziehung zwischen <strong>Entity</strong>s, z.B. ein Weingut<br />

produziert einen Wein, ein Kun<strong>de</strong> bestellt ein Produkt o<strong>de</strong>r ein Dozent<br />

hält eine Vorlesung.<br />

Attribut entspricht einer Eigenschaft von <strong>Entity</strong>s o<strong>de</strong>r Beziehungen, z.B. Farbe<br />

und Jahrgang eines Weines, <strong>de</strong>r Name eines Weingutes, die ISBN eines<br />

Buchs, <strong>de</strong>r Titel einer Vorlesung.<br />

<strong>Entity</strong>s sind in einer Datenbank allerdings nicht direkt darstellbar, son<strong>de</strong>rn<br />

nur über ihre Eigenschaften beobachtbar. Dies be<strong>de</strong>utet einfach nur, dass etwa<br />

ein Wein nicht selbst in <strong>de</strong>r Datenbank gespeichert wer<strong>de</strong>n kann – nur Informationen<br />

über seine Eigenschaften (Name, Farbe, Jahrgang usw.) lassen sich<br />

erfassen.<br />

Daher benötigen wir Werte als direkt darstellbare, primitive Datenelemente.<br />

Wertemengen sind beschrieben durch Datentypen, die neben einer Wertemenge<br />

auch die Grundoperationen auf diesen Werten charakterisieren.<br />

Im ER-<strong>Mo<strong>de</strong>ll</strong> gehen wir von einer Reihe vorgegebener Standarddatentypen<br />

aus, etwa die ganzen Zahlen integer, die Zeichenketten string, Datumswerte<br />

date etc. Je<strong>de</strong>r Datentyp stellt einen Wertebereich µ(D) mit Operationen<br />

und Prädikaten dar, zum Beispiel:<br />

µ(int): <strong>de</strong>n Wertebereich Z (die ganzen Zahlen) mit +,−,·,÷,=, < ...<br />

µ(string): <strong>de</strong>n Wertebereich C ∗ (Folgen von Zeichen aus <strong>de</strong>r Menge C) mit +,=<br />

,< ...<br />

Der Wertebereich wird auch Interpretation (Be<strong>de</strong>utung) genannt und beschreibt<br />

die möglichen Werte, die eine <strong>Entity</strong>-Eigenschaft annehmen kann.<br />

<strong>Entity</strong>-Typen<br />

<strong>Entity</strong>s sind die in einer Datenbank zu repräsentieren<strong>de</strong>n Informationseinheiten.<br />

Sie wer<strong>de</strong>n nicht einzeln in ihren Ausprägungen (ein konkreter Wein Zinfan<strong>de</strong>l,<br />

rot, 2004 im Barossa Valley produziert) mo<strong>de</strong>lliert, son<strong>de</strong>rn Objekte mit<br />

gleichen Eigenschaften wer<strong>de</strong>n zu <strong>Entity</strong>-Typen zusammengefasst, beispielsweise<br />

Wein o<strong>de</strong>r Rotwein, allgemein also etwa E 1 ,E 2 ....<br />

60 3 <strong>Das</strong> <strong>Entity</strong>-<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong><br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519


In <strong>de</strong>r graphischen Notation wer<strong>de</strong>n <strong>Entity</strong>-Typen als Rechtecke dargestellt,<br />

wobei <strong>de</strong>r Name <strong>de</strong>s Typs in das Rechteck eingetragen wird (siehe Abbildung<br />

3.3).<br />

Wein<br />

Abbildung 3.3: Graphische Darstellung eines <strong>Entity</strong>-Typs<br />

Die Semantik eines <strong>Entity</strong>-Typs wird, wie in Abschnitt 3.2 dargestellt,<br />

durch die Deklaration <strong>de</strong>r möglichen Exemplare und durch Zustän<strong>de</strong> festgelegt,<br />

die jeweils eine aktuell existieren<strong>de</strong> Menge von Exemplaren beschreiben. Die<br />

Semantik eines <strong>Entity</strong>-Typs E wird somit durch zwei Definitionen bestimmt:<br />

µ(E) Die Menge <strong>de</strong>r möglichen <strong>Entity</strong>s vom Typ E. Die Werte <strong>de</strong>r Menge µ(E)<br />

wer<strong>de</strong>n hier nicht festgelegt; wir gehen von einer hinreichen<strong>de</strong>n Anzahl<br />

möglicher Werte aus, etwa einer Menge isomorph zu <strong>de</strong>n natürlichen Zahlen.<br />

σ(E) Die Menge <strong>de</strong>r aktuellen <strong>Entity</strong>s vom Typ E in einem Zustand σ, d.h., die<br />

aktuelle Ausprägung <strong>de</strong>s <strong>Entity</strong>-Typs (σ, <strong>de</strong>r griechische Buchstabe Sigma,<br />

steht für englisch state (Zustand)).<br />

Aktuelle <strong>Entity</strong>s müssen mögliche Elemente sein, also gilt σ(E) ⊆ µ(E). Ferner<br />

for<strong>de</strong>rn wir, dass in je<strong>de</strong>m Zustand nur eine endliche Menge aktueller<br />

<strong>Entity</strong>s existiert, also σ(E) endlich ist.<br />

Beziehungstypen<br />

Auch Beziehungen zwischen <strong>Entity</strong>s wer<strong>de</strong>n in einem ER-Schema nicht für je<strong>de</strong><br />

Ausprägung mo<strong>de</strong>lliert, son<strong>de</strong>rn zu Beziehungstypen zusammengefasst. Es<br />

wird also nur <strong>de</strong>r Sachverhalt beschrieben, dass ein Wein von einem Erzeuger<br />

produziert wird und nicht, dass <strong>de</strong>r 2004er Zinfan<strong>de</strong>l von <strong>de</strong>r Creek Winery<br />

hergestellt wur<strong>de</strong>. Ein Beziehungstyp muss min<strong>de</strong>stens zwei <strong>Entity</strong>-Typen<br />

miteinan<strong>de</strong>r verbin<strong>de</strong>n, allgemein kann jedoch eine beliebige Anzahl n ≥ 2 von<br />

<strong>Entity</strong>-Typen an einem Beziehungstyp teilhaben. Im ersten Fall spricht man<br />

auch von binären Beziehungstypen, im allgemeinen Fall entsprechend von n-<br />

stelligen Beziehungstypen.<br />

Zu je<strong>de</strong>m n-stelligen Beziehungstyp R gehören n <strong>Entity</strong>-Typen E 1 ,...,E n .<br />

Auch hier wird die Semantik über die möglichen bzw. aktuellen Ausprägungen<br />

festgelegt. Für je<strong>de</strong>n Beziehungstyp R wer<strong>de</strong>n die möglichen Ausprägungen als<br />

die Elemente <strong>de</strong>s kartesischen Produkts über <strong>de</strong>n möglichen <strong>Entity</strong>s festgelegt:<br />

3.3 Grundlagen <strong>de</strong>s <strong>Entity</strong>-<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong>s 61<br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519


µ(R) = µ(E 1 ) × ··· × µ(E n )<br />

Die Menge <strong>de</strong>r aktuellen Beziehungen σ(R) in einem Zustand ist wie<strong>de</strong>r<br />

eine Teilmenge <strong>de</strong>r möglichen Beziehungen µ(R). Wir verschärfen diese Bedingung<br />

dahingehend, dass aktuelle Beziehungen nur zwischen aktuellen <strong>Entity</strong>s<br />

bestehen, also:<br />

σ(R) ⊆ σ(E 1 ) × ··· × σ(E n )<br />

Beziehungstypen wer<strong>de</strong>n graphisch als Raute dargestellt, in die <strong>de</strong>r Name<br />

<strong>de</strong>s Typs eingetragen wird. Die Verbindungen zu <strong>de</strong>n beteiligten <strong>Entity</strong>-Typen<br />

erfolgt über Linien typischerweise von <strong>de</strong>n Ecken <strong>de</strong>r Raute. Bei <strong>de</strong>r Wahl <strong>de</strong>s<br />

Typnamens ist es oft sinnvoll, die Leserichtung (von links nach rechts, von oben<br />

nach unten) zu berücksichtigen, allerdings sind Beziehungen grundsätzlich bidirektional.<br />

In Abbildung 3.4 ist die Notation von Beziehungstypen an zwei Beispielen<br />

dargestellt. Der binäre Beziehungstyp in Abbildung 3.4 a) ordnet einem Wein<br />

<strong>de</strong>n Erzeuger zu (Erzeuger produziert Wein), <strong>de</strong>r dreistellige (ternäre) Beziehungstyp<br />

in Abbildung 3.4 b) drückt aus, dass ein Kritiker einen Wein zu einem<br />

Gericht empfiehlt. Die Beispiele sollen auch noch einmal ver<strong>de</strong>utlichen,<br />

dass <strong>Entity</strong>-Typen nicht direkt, son<strong>de</strong>rn nur über Beziehungstypen miteinan<strong>de</strong>r<br />

verbun<strong>de</strong>n wer<strong>de</strong>n können.<br />

Erzeuger<br />

produziert<br />

Wein<br />

(a) Binärer Beziehungstyp<br />

Kritiker<br />

empfiehlt<br />

Wein<br />

Gericht<br />

(b) n-stelliger Beziehungstyp<br />

Abbildung 3.4: Graphische Darstellung von Beziehungstypen<br />

Neben <strong>de</strong>r gezeigten graphischen Notation ist auch eine Textnotation<br />

möglich, die für einen Beziehungstyp R die Form R(E 1 ,...,E n ) hat, z.B.<br />

62 3 <strong>Das</strong> <strong>Entity</strong>-<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong><br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519


produziert(Erzeuger, Wein). Man beachte, dass in <strong>de</strong>r Textnotation eine Reihenfolge<br />

<strong>de</strong>r beteiligten <strong>Entity</strong>-Typen festgelegt wird – in <strong>de</strong>r graphischen Notation<br />

wird dieses offen gelassen.<br />

Ist ein <strong>Entity</strong>-Typ mehrfach an einem Beziehungstyp beteiligt (etwa in <strong>de</strong>r<br />

Beziehung grenzt_an(Anbaugebiet, Anbaugebiet)), können Rollennamen vergeben<br />

wer<strong>de</strong>n:<br />

grenzt_an(Gebiet1: Anbaugebiet, Gebiet2: Anbaugbiet)<br />

Während in <strong>de</strong>r Textnotation dieser Rollenname durch die Parameterposition<br />

ersetzt wer<strong>de</strong>n könnte (etwa steht im grenzt_an-Beziehungstyp das nördlichere<br />

o<strong>de</strong>r westlichere Gebiet vorn), ist in <strong>de</strong>r graphischen Notation in diesen<br />

Fällen die Vergabe von Rollennamen zwingend. Die Rollennamen wer<strong>de</strong>n an<br />

die Verbindungslinie zwischen Beziehungstyp-Symbol und <strong>Entity</strong>-Typ-Symbol<br />

geschrieben (Abbildung 3.5).<br />

Gebiet1<br />

Anbaugebiet<br />

grenzt an<br />

Gebiet2<br />

Abbildung 3.5: Beziehungstyp mit Rollennamen<br />

Attribute<br />

Attribute mo<strong>de</strong>llieren Eigenschaften von <strong>Entity</strong>s o<strong>de</strong>r auch Beziehungen. Alle<br />

<strong>Entity</strong>s eines <strong>Entity</strong>-Typs haben dieselben Arten von Eigenschaften. Attribute<br />

wer<strong>de</strong>n somit für <strong>Entity</strong>-Typen <strong>de</strong>klariert.<br />

In <strong>de</strong>r graphischen Notation wird ein Attribut als Oval dargestellt und über<br />

eine Linie <strong>de</strong>m <strong>Entity</strong>-Typ zugeordnet. In Abbildung 3.6 ist dies für <strong>de</strong>n <strong>Entity</strong>-<br />

Typ Wein mit <strong>de</strong>n Attributen Name, Farbe und Jahrgang dargestellt. Optional<br />

kann zum Attribut A noch <strong>de</strong>r Wertebereich D in <strong>de</strong>r Form A : D angegeben<br />

wer<strong>de</strong>n.<br />

Im klassischen ER-<strong>Mo<strong>de</strong>ll</strong> nehmen Attribute „druckbare“ Werte an, also<br />

Werte <strong>de</strong>r Standarddatentypen wie int o<strong>de</strong>r string. Die tatsächliche Menge <strong>de</strong>r<br />

angebotenen Datentypen schwankt je nach zugrun<strong>de</strong>liegen<strong>de</strong>r Literaturquelle<br />

und wird darum von uns offen gelassen.<br />

Die Semantik einer Attribut<strong>de</strong>klaration wird wie folgt festgelegt: Ein Attribut<br />

A eines <strong>Entity</strong>-Typs E stellt im Zustand σ eine Abbildung dar:<br />

3.3 Grundlagen <strong>de</strong>s <strong>Entity</strong>-<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong>s 63<br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519


Name<br />

Farbe<br />

Wein<br />

Jahrgang<br />

Abbildung 3.6: Attributnotation für <strong>Entity</strong>-Typen<br />

σ(A) : σ(E) → µ(D)<br />

Eine Attribut<strong>de</strong>klaration entspricht somit in einem Zustand σ einer Funktion,<br />

die je<strong>de</strong>m aktuellen <strong>Entity</strong> aus σ(E) einen Wert <strong>de</strong>s Datentyps D zuordnet.<br />

Attribute von Beziehungen wer<strong>de</strong>n analog behan<strong>de</strong>lt. Attribut<strong>de</strong>klarationen<br />

wer<strong>de</strong>n beim Beziehungstyp vorgenommen; eine Attribut<strong>de</strong>klaration gilt<br />

auch hier für alle Ausprägungen eines Beziehungstyps. Derartige Attribute<br />

wer<strong>de</strong>n auch als Beziehungsattribute bezeichnet. Die Semantik von Beziehungsattributen<br />

wird analog zu <strong>Entity</strong>-Attributen festgelegt. Ein Attributtyp A<br />

eines Beziehungstyps R stellt im Zustand σ eine Abbildung dar:<br />

σ(A) : σ(R) → µ(D)<br />

Man beachte, dass die Attributfunktion nur für Beziehungsausprägungen <strong>de</strong>finiert<br />

sind, die im aktuellen Zustand enthalten sind.<br />

Die Notation wird im Beispiel in Abbildung 3.7 gezeigt – dieser Beziehungstyp<br />

gibt an, dass ein Wein zu einem bestimmten Anteil aus einer Rebsorte hergestellt<br />

ist. Beispielsweise sind Bor<strong>de</strong>aux-Weine meist sogenannte Cuvees –<br />

eine Kombination (Verschnitt) aus drei bis fünf verschie<strong>de</strong>nen Rebsorten. <strong>Das</strong><br />

Attribut Anteil gibt in unserem Beispiel an, zu wieviel Prozent eine bestimmte<br />

Rebsorte beteiligt ist. Offensichtlich kann dieses Attribut we<strong>de</strong>r <strong>de</strong>m <strong>Entity</strong>-<br />

Typ Wein noch <strong>de</strong>m <strong>Entity</strong>-Typ Rebsorte zugeordnet wer<strong>de</strong>n: im ersten Fall wäre<br />

<strong>de</strong>r Anteil für alle an <strong>de</strong>r Beziehung beteiligten Rebsorten gleich, im zweiten<br />

Fall wäre eine Rebsorte bei allen beteiligten Weinen zu gleichen Anteilen vertreten.<br />

In <strong>de</strong>r Textnotation wer<strong>de</strong>n <strong>Entity</strong>-Typen E mit Attributen A 1 ,...A m und<br />

<strong>de</strong>n jeweiligen Wertebereichen D 1 ,...,D m wie folgt notiert:<br />

E(A 1 : D 1 ,...,A m : D m )<br />

Oft wer<strong>de</strong>n die Wertebereiche (wie auch in <strong>de</strong>r graphischen Notation, vergleiche<br />

Abbildung 3.6) weggelassen, also:<br />

E(A 1 ,...,A m )<br />

64 3 <strong>Das</strong> <strong>Entity</strong>-<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong><br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519


Anteil<br />

Wein<br />

hergestellt<br />

aus<br />

Rebsorte<br />

Abbildung 3.7: Attributnotation für Beziehungstypen<br />

Deklarationen von Beziehungstypen R mit Attributen wer<strong>de</strong>n entsprechend notiert,<br />

in<strong>de</strong>m sie an die Liste <strong>de</strong>r <strong>Entity</strong>-Typen angefügt wer<strong>de</strong>n (hier sind die<br />

Wertebereiche weggelassen):<br />

R(E 1 ,...,E n ;A 1 ,...,A p )<br />

Zur besseren Unterscheidbarkeit können die beteiligten <strong>Entity</strong>-Typen von <strong>de</strong>n<br />

Attributen wie hier durch ein Semikolon anstelle eines Kommas getrennt wer<strong>de</strong>n.<br />

I<strong>de</strong>ntifizierung durch Schlüssel<br />

In <strong>de</strong>r Regel haben wir bei einer Beschreibung im ER-<strong>Mo<strong>de</strong>ll</strong> <strong>de</strong>n Effekt, dass<br />

einige Attribute mit ihren Werten bereits eine ein<strong>de</strong>utige I<strong>de</strong>ntifizierung für<br />

<strong>Entity</strong>s eines <strong>Entity</strong>-Typs bil<strong>de</strong>n – so wird ein Wein etwa durch <strong>de</strong>n Namen,<br />

<strong>de</strong>n Jahrgang und das Weingut ein<strong>de</strong>utig i<strong>de</strong>ntifiziert, ein Buch durch die zugehörige<br />

ISBN und ein Stu<strong>de</strong>nt durch seine Matrikelnummer 3 . Wir bezeichnen<br />

eine <strong>de</strong>rartige I<strong>de</strong>ntifikation durch eine Attributmenge als Schlüssel 4 für <strong>de</strong>n<br />

betreffen<strong>de</strong>n <strong>Entity</strong>-Typ.<br />

Für einen <strong>Entity</strong>-Typ E(A 1 ,...,A m ) sei eine Teilmenge {S 1 ,...,S k } <strong>de</strong>r gesamten<br />

Attribute gegeben, die sogenannten Schlüsselattribute. Es gilt also:<br />

{S 1 ,...,S k } ⊆ {A 1 ,...,A m }<br />

In je<strong>de</strong>m Datenbankzustand i<strong>de</strong>ntifizieren die aktuellen Werte <strong>de</strong>r Schlüsselattribute<br />

ein<strong>de</strong>utig Instanzen <strong>de</strong>s <strong>Entity</strong>-Typs E. Formal kann diese Bedingung<br />

wie folgt geschrieben wer<strong>de</strong>n:<br />

∀e 1 ,e 2 ∈ σ(E) : (σ(S 1 )(e 1 ) = σ(S 1 )(e 2 ) ∧ ... ∧ σ(S k )(e 1 ) = σ(S k )(e 2 )) =⇒ (e 1 = e 2 )<br />

3 Die Festlegung einer i<strong>de</strong>ntifizieren<strong>de</strong>n Schlüsselbedingung ist eine <strong>Mo<strong>de</strong>ll</strong>ierungsentscheidung<br />

für eine konkrete Datenbankanwendung – für je<strong>de</strong> <strong>de</strong>r drei Beispieli<strong>de</strong>ntifizierungen lassen sich<br />

in <strong>de</strong>r Realität Gegenbeispiele fin<strong>de</strong>n.<br />

4 Im Relationenmo<strong>de</strong>ll wird die Definition noch exakter getroffen. Dort wird auch noch die Minimalität<br />

<strong>de</strong>r Attributmenge festgelegt.<br />

3.3 Grundlagen <strong>de</strong>s <strong>Entity</strong>-<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong>s 65<br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519


Sowohl in <strong>de</strong>r textuellen als auch in <strong>de</strong>r graphischen Notation markieren wir<br />

Schlüsselattribute durch Unterstreichungen, also textuell durch:<br />

E(...,S 1 ,...,S i ,...)<br />

Die graphische Variante <strong>de</strong>r Schlüssel<strong>de</strong>finition ist in Abbildung 3.8 dargestellt.<br />

In vielen Anwendungen haben wir verschie<strong>de</strong>ne mögliche Schlüssel, etwa<br />

können Weine wie im obigen Beispiel durch Namen, Jahrgang und Weingut,<br />

aber auch durch eine intern vergebene Weini<strong>de</strong>ntifikationsnummer i<strong>de</strong>ntifiziert<br />

wer<strong>de</strong>n. Wir sprechen in diesem Zusammenhang von mehreren Schlüsselkandidaten<br />

o<strong>de</strong>r kurz Schlüsseln. Wir wählen einen <strong>de</strong>r Schlüsselkandidaten aus<br />

und bezeichen ihn als Primärschlüssel. Dieser hat die oben eingeführte einfache<br />

graphische Repräsentation. Falls mehrere Schlüssel graphisch dargestellt<br />

wer<strong>de</strong>n sollen, verbin<strong>de</strong>t man die Kanten zu ihren Attributen jeweils mit einem<br />

Querbalken (siehe [Heu97]).<br />

Die vier Konzepte Werte, <strong>Entity</strong>s, Beziehungen und Attribute ermöglichen die<br />

Beschreibung beliebig strukturierter Weltausschnitte. Wir wer<strong>de</strong>n in <strong>de</strong>n folgen<strong>de</strong>n<br />

Abschnitten allerdings sehen, dass diese Konzepte für eine ausdrucksstarke<br />

und realitätsnahe <strong>Mo<strong>de</strong>ll</strong>ierung weiter verfeinert wer<strong>de</strong>n müssen.<br />

3.3.2 Ein einfaches Beispiel für ein ER-Schema<br />

Bevor wir die erweiterten ER-<strong>Mo<strong>de</strong>ll</strong>ierungskonzepte behan<strong>de</strong>ln, wollen wir zunächst<br />

die bisher eingeführten Konstrukte in einem zusammenhängen<strong>de</strong>n Beispiel<br />

betrachten, das wir später in geeigneter Weise noch verfeinern wer<strong>de</strong>n.<br />

Als Anwendungsdomäne dient wie<strong>de</strong>r unser Weinkeller.<br />

<strong>Das</strong> komplette Schema ist in Abbildung 3.8 dargestellt. Zentraler <strong>Entity</strong>-<br />

Typ ist Wein mit <strong>de</strong>n Attributen Name, Farbe, Jahrgang und Restsüße. Ein Wein<br />

wird aus einer o<strong>de</strong>r mehreren Rebsorte(n) hergestellt (Beziehungstyp), wobei<br />

<strong>de</strong>r Anteil <strong>de</strong>r Rebsorte als Attribut <strong>de</strong>s Beziehungstyps repräsentiert wird (siehe<br />

vorigen Abschnitt). Rebsorte ist ebenfalls ein <strong>Entity</strong>-Typ und wird mit <strong>de</strong>n<br />

Attributen Name und Farbe mo<strong>de</strong>lliert. Weiterhin wird ein Wein von einem Erzeuger<br />

produziert – auch dies wird über einen Beziehungstyp dargestellt. Der<br />

<strong>Entity</strong>-Typ Erzeuger besitzt die Attribute Weingut und eine zunächst nicht weiter<br />

strukturierte Adresse. Als Erweiterung zu unserem bisherigen Beispiel wird<br />

auch das Anbaugebiet als <strong>Entity</strong>-Typ mit <strong>de</strong>n Attributen Name, Region und Land<br />

mo<strong>de</strong>lliert: beispielsweise ist <strong>de</strong>r Ort Saint-Emilion in <strong>de</strong>r Region Bor<strong>de</strong>aux in<br />

Frankreich eine Instanz dieses Typs (d.h. ein konkretes <strong>Entity</strong>). Die Zuordnung<br />

zwischen Erzeuger und Anbaugebiet – also <strong>de</strong>r Sachverhalt, dass ein bestimmtes<br />

Weingut in einem Anbaugebiet angesie<strong>de</strong>lt ist – wird durch <strong>de</strong>n Beziehungstyp<br />

sitzt in erfasst. Schließlich ist <strong>de</strong>n Erzeugern noch eine Lizenz zugeordnet,<br />

die ihnen erlaubt, eine bestimmte Menge Wein zu produzieren.<br />

66 3 <strong>Das</strong> <strong>Entity</strong>-<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong><br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519


Farbe<br />

Name<br />

Land<br />

Bezeichnung<br />

Gericht<br />

[0,*]<br />

Beilage<br />

Name<br />

Rebsorte<br />

[0,*]<br />

hergestellt<br />

aus<br />

Anteil<br />

Farbe<br />

Name<br />

Anbaugebiet<br />

sitzt in<br />

Region<br />

[1,7]<br />

empfiehlt<br />

[0,*]<br />

Wein<br />

produziert<br />

von<br />

Erzeuger<br />

[0,*]<br />

Restsüße<br />

Jahrgang<br />

Weingut<br />

Adresse<br />

Kritiker<br />

besitzt<br />

Name<br />

LizenzNr<br />

Organisation<br />

Menge<br />

Lizenz<br />

Abbildung 3.8: Beispiel für ein ER-Schema<br />

Im linken Teil <strong>de</strong>s Diagramms sind die Empfehlungen mo<strong>de</strong>lliert. Wir nehmen<br />

hierbei vereinfachend an, dass ein Kritiker einen bestimmten Wein zu einem<br />

Gericht empfiehlt, also beispielsweise, dass ein weißer Chardonnay aus Kalifornien<br />

gut zu Lamm passt. Kritiker und Gericht sind daher als <strong>Entity</strong>-Typen<br />

repräsentiert, die über <strong>de</strong>n Beziehungstyp mit <strong>de</strong>m <strong>Entity</strong>-Typ Wein verbun<strong>de</strong>n<br />

sind.<br />

Die Notation <strong>de</strong>r Pfeilspitzen sowie die zusätzlichen Informationen an <strong>de</strong>n<br />

Verbindungslinien wer<strong>de</strong>n wir in <strong>de</strong>n folgen<strong>de</strong>n Abschnitten noch erläutern.<br />

3.3.3 Semantik eines ER-Schemas<br />

Nach<strong>de</strong>m die einzelnen Konzepte erläutert wur<strong>de</strong>n, können wir nun die Semantik<br />

eines kompletten Schemas im ER-<strong>Mo<strong>de</strong>ll</strong> betrachten. Wie in Abschnitt<br />

3.3 Grundlagen <strong>de</strong>s <strong>Entity</strong>-<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong>s 67<br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519


3.2 beschrieben, beschränken wir uns auf die Festlegung <strong>de</strong>r Menge aller möglichen<br />

ER-Zustän<strong>de</strong> σ für ein gegebenes ER-Schema.<br />

Je<strong>de</strong>r Zustand σ eines ER-Schemas ist eine Zuordnung<br />

E ↦→ σ(E) ⊆ µ(E)<br />

R(E 1 ,...,E n ;...) ↦→ σ(R) ⊆ σ(E 1 ) × ... × σ(E n )<br />

E(...,A i : D,...) ↦→ σ(A i ) : σ(E) → µ(D),...<br />

R(...;...,A i : D,...) ↦→ σ(A i ) : σ(R) → µ(D),...<br />

bei gegebener fester Interpretation µ <strong>de</strong>r Datentypen durch Wertebereiche<br />

und <strong>de</strong>r <strong>Entity</strong>-Typen durch vorgegebene Mengen möglicher <strong>Entity</strong>s.<br />

Nach diesen allgemeinen Festlegungen wen<strong>de</strong>n wir uns speziellen Aspekten<br />

und zusätzlichen Notationen zu.<br />

3.4 Eigenschaften von Beziehungen<br />

Wie das Beispiel in Abbildung 3.8 zeigt, können sich Beziehungstypen hinsichtlich<br />

ihrer Eigenschaften unterschei<strong>de</strong>n. So sind an <strong>de</strong>r empfiehlt-Beziehung drei<br />

<strong>Entity</strong>-Typen beteiligt, während alle an<strong>de</strong>ren Beziehungstypen in diesem Schema<br />

binär sind.<br />

Allgemein lassen sich Beziehungen durch zwei wesentliche Eigenschaften<br />

beschreiben:<br />

• die Stelligkeit gibt an, wie viele <strong>Entity</strong>-Typen mit einem Beziehungstyp<br />

verbun<strong>de</strong>n sind, während<br />

• die Funktionalität bzw. Kardinalität beschreibt, wieviele Instanzen eines<br />

<strong>Entity</strong>-Typs jeweils in die Beziehung eingehen.<br />

Im Folgen<strong>de</strong>n wer<strong>de</strong>n wir diese Eigenschaften genauer vorstellen.<br />

3.4.1 Stelligkeit<br />

Die Stelligkeit o<strong>de</strong>r <strong>de</strong>r Grad eines Beziehungstyps beschreibt die Anzahl <strong>de</strong>r<br />

am Beziehungstyp beteiligten <strong>Entity</strong>-Typen, also in <strong>de</strong>r graphischen Notation<br />

die Anzahl <strong>de</strong>r Verbinungslinien. Die zweifellos häufigste Variante sind dabei<br />

binäre (zweistellige) Beziehungstypen. Einige Vorschläge für spezielle ER-<br />

<strong>Mo<strong>de</strong>ll</strong>e und zugehörige Werkzeugsysteme boten daher nur zweistellige Beziehungstypen<br />

als Einschränkung <strong>de</strong>r allgemeineren n-stelligen Beziehungen an.<br />

So stellt sich die Frage, ob mehrstellige Beziehungen eventuell durch mehrere<br />

zweistellige Beziehungen ersetzt wer<strong>de</strong>n können.<br />

68 3 <strong>Das</strong> <strong>Entity</strong>-<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong><br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519


Gericht<br />

Gericht<br />

G-W<br />

empfiehlt<br />

Wein<br />

G-K<br />

Wein<br />

Kritiker<br />

Kritiker<br />

K-W<br />

(a) Ternärer Beziehungstyp<br />

(b) Drei binäre Beziehungstypen<br />

Abbildung 3.9: Ternäre vs. binäre Beziehungen im ER-<strong>Mo<strong>de</strong>ll</strong><br />

Hierzu betrachten wir in Abbildung 3.9 ein Beispiel aus unserer Weindomäne:<br />

nämlich <strong>de</strong>n Beziehungstyp mit <strong>de</strong>n Empfehlungen von Weinen zu bestimmten<br />

Speisen durch Weinkritiker, links wie im vorigen Abschnitt als dreistellige<br />

(ternäre) Beziehung, rechts in Form von drei zweistelligen Beziehungen<br />

jeweils zwischen zwei <strong>Entity</strong>-Typen dargestellt.<br />

Zur Beantwortung unserer Frage betrachten wir in Abbildung 3.10 die Instanzen:<br />

die Ovale symbolisieren die <strong>Entity</strong>-Mengen, die Linien repräsentieren<br />

Beziehungen zwischen einigen ausgewählten <strong>Entity</strong>s. Die unterschiedlichen Linienarten<br />

in Abbildung 3.10 (b) sollen dabei nur die Zuordnung zu <strong>de</strong>n Beziehungen<br />

in Abbildung 3.10 (a) erleichtern – tatsächlich ist die Zusammengehörigkeit<br />

etwa von g 1 − w 1 und g 1 − k 1 nicht mehr gegeben!<br />

Wenn wir nun versuchen, aus <strong>de</strong>n drei binären Beziehungen in Abbildung<br />

3.11 (a) (zur Erinnerung: die unterschiedlichen Linienarten wer<strong>de</strong>n ignoriert)<br />

die ursprünglichen Beziehungen zu rekonstruieren, ergibt sich das Bild<br />

in Abbildung 3.11 (b).<br />

Die Beziehungen (1) bis (3) entsprechen offensichtlich <strong>de</strong>n Beziehungen aus<br />

Abbildung 3.10 (a). Allerdings kann auch die (neue) Beziehung (4) g 1 − w 1 − k 2<br />

abgeleitet wer<strong>de</strong>n!<br />

Wir können also feststellen, dass ein wichtiger Aspekt <strong>de</strong>r ursprünglichen<br />

Beziehungsausprägung nicht mehr rekonstruiert wer<strong>de</strong>n kann: Die Information,<br />

dass unser Kritiker k 2 <strong>de</strong>n Wein w 1 nur für das Gericht g 2 empfohlen hat,<br />

nicht aber für g 1 , ist nun verlorengegangen! Allgemein be<strong>de</strong>utet dies, dass mehrere<br />

mögliche Ausprägungen für empfiehlt auf dieselben binären Beziehungen<br />

abgebil<strong>de</strong>t wer<strong>de</strong>n. Ein weiterer, nicht beabsichtigter Nebeneffekt ist, dass<br />

wir jetzt Informationen ausdrücken können, die mit <strong>de</strong>m ursprünglichen Beziehungstyp<br />

nicht ausdrückbar waren. So können wir beispielsweise eine Be-<br />

3.4 Eigenschaften von Beziehungen 69<br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519


g 1<br />

g 2<br />

w 1<br />

w 2<br />

g 1<br />

g 2<br />

w 1<br />

w 2<br />

Gericht<br />

Wein<br />

Gericht<br />

Wein<br />

k 1 k 2<br />

Kritiker<br />

(a) Ternäre Beziehung<br />

k 1 k 2<br />

Kritiker<br />

(b) Binäre Beziehungen<br />

Abbildung 3.10: Beispiel für Beziehungsinstanzen zu Abbildung 3.9<br />

g 1<br />

g 2<br />

w 1<br />

w 2<br />

(1) g 1 − w 1 − k 1<br />

(2) g 1 − w 2 − k 2<br />

Gericht<br />

Wein<br />

(3) g 2 − w 1 − k 2<br />

(4) g 1 − w 1 − k 2<br />

k 1 k 2<br />

Kritiker<br />

(a) Binäre Beziehungen<br />

(b) Rekonstruierbare Beziehungen<br />

Abbildung 3.11: Rekonstruktion <strong>de</strong>r Beziehungsinstanzen<br />

ziehungsinstanz g 2 −w 2 einfügen, d.h. eine Empfehlung ohne Angabe eines Kritikers.<br />

Diese kurzen Beispiele zeigen, dass die direkte Umsetzung n-stelliger Beziehungstypen<br />

in zweistellige zu unerwünschten Effekten führen kann. Dies<br />

heißt aber nicht, dass wir prinzipiell eine geringere Ausdrucksfähigkeit haben,<br />

falls wir nur zweistellige Beziehungen erlauben – in unserem Beispiel könnten<br />

wir die dreistellige Beziehung zum Beispiel durch einen künstlichen neuen<br />

<strong>Entity</strong>-Typ Empfehlung und drei zweistellige Beziehungen ersetzen (Abbildung<br />

3.12).<br />

70 3 <strong>Das</strong> <strong>Entity</strong>-<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong><br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519


Gericht<br />

G-E<br />

Empfehlung<br />

W-E<br />

Wein<br />

K-E<br />

Kritiker<br />

Abbildung 3.12: Dreistellige Beziehung durch künstlichen <strong>Entity</strong>-Typ<br />

<strong>Das</strong> Prinzip dieser Umsetzung entspricht <strong>de</strong>r Transformation vom ER-<br />

<strong>Mo<strong>de</strong>ll</strong> in das Netzwerkmo<strong>de</strong>ll, in <strong>de</strong>m ebenfalls nur zweistellige Beziehungen<br />

erlaubt sind. Diese Transformation wird in Abschnitt 16.3 näher erläutert.<br />

Auch im Relationenmo<strong>de</strong>ll können solche Zusammenhänge dargestellt<br />

wer<strong>de</strong>n: Verbundabhängigkeiten und die Transformationseigenschaft Verbundtreue<br />

wer<strong>de</strong>n diese Aufgabe übernehmen (siehe Abschnitt 6.3.2).<br />

3.4.2 Kardinalitäten und funktionale Beziehungen<br />

Neben <strong>de</strong>r Anzahl <strong>de</strong>r in eine Beziehung eingehen<strong>de</strong>n <strong>Entity</strong>-Typen ist die<br />

Anzahl <strong>de</strong>r beteiligten Instanzen <strong>de</strong>s jeweiligen <strong>Entity</strong>-Typs ein weiteres<br />

wichtiges Merkmal von Beziehungstypen. So kann beispielsweise für die<br />

hergestellt aus-Beziehung aus Abbildung 3.7 festgelegt wer<strong>de</strong>n, dass ein Wein<br />

aus min<strong>de</strong>stens einer Rebsorte hergestellt sein muss (an<strong>de</strong>renfalls ist es kein<br />

Wein), an<strong>de</strong>rerseits aber nicht mehr als sieben Rebsorten enthalten darf (sonst<br />

ist er maximal noch als Glühwein geeignet). Derartige Festlegungen bezeichnet<br />

man als Kardinalität einer Beziehung. Eine Kardinalitätsangabe stellt im Prinzip<br />

eine Integritätsbedingung dar, d.h. damit wird beschrieben, unter welchen<br />

Bedingungen die Daten konsistent zur realen Welt sind.<br />

Allgemein lassen sich drei Formen von Kardinalitäten unterschei<strong>de</strong>n, wobei<br />

m und n für eine beliebige Anzahl > 1 stehen:<br />

• 1:1-Beziehungen,<br />

• 1:n- bzw. n:1-Beziehungen sowie<br />

• m:n-Beziehungen.<br />

Im Folgen<strong>de</strong>n stellen wir diese Beziehungstypen genauer vor, wobei wir zunächst<br />

von einem binären Beziehungstyp R ausgehen, <strong>de</strong>r die <strong>Entity</strong>-Typen E 1<br />

und E 2 miteinan<strong>de</strong>r verbin<strong>de</strong>t.<br />

3.4 Eigenschaften von Beziehungen 71<br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519


Bei einer 1:1-Beziehung ist je<strong>de</strong>m <strong>Entity</strong> e 1 vom <strong>Entity</strong>-Typ E 1 maximal ein<br />

<strong>Entity</strong> e 2 vom Typ E 2 zugeordnet und umgekehrt. Abbildung 3.13 ver<strong>de</strong>utlicht<br />

dies für die <strong>Entity</strong>-Mengen von E 1 und E 2 .<br />

E 1 E 2<br />

Abbildung 3.13: 1:1-Beziehung<br />

Ein Beispiel für eine <strong>de</strong>rartige Beziehung ist „Mann ist verheiratet mit<br />

Frau“. Unter Annahme monogamer Beziehungen ist tatsächlich je<strong>de</strong>r Mann mit<br />

maximal einer Frau verheiratet und umgekehrt – allerdings kann es durchaus<br />

Männer o<strong>de</strong>r Frauen geben, die nicht verheiratet sind. In unserem Weinszenario<br />

ist die Beziehung „Erzeuger besitzt Lizenz“ ein Beispiel einer 1:1-Beziehung.<br />

Bei einer 1:n-Beziehung sind je<strong>de</strong>m <strong>Entity</strong> e 1 vom Typ E 1 beliebig viele <strong>Entity</strong>s<br />

vom Typ E 2 zugeordnet; gleichzeitig gibt es jedoch zu je<strong>de</strong>m <strong>Entity</strong> e 2 <strong>de</strong>s<br />

Typs E 2 maximal ein <strong>Entity</strong> e 1 aus E 1 (Abbildung 3.14).<br />

E 1 E 2<br />

Abbildung 3.14: 1:n-Beziehung<br />

Beispiele für <strong>de</strong>rartige Beziehungen sind etwa „eine Mutter hat Kin<strong>de</strong>r“<br />

(eine Mutter kann mehrere Kin<strong>de</strong>r haben, aber je<strong>de</strong>s Kind hat – in diesem Fall<br />

genau – eine biologische Mutter) o<strong>de</strong>r aus unserer Anwendungsdomäne die Beziehungen<br />

produziert und sitzt_in.<br />

72 3 <strong>Das</strong> <strong>Entity</strong>-<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong><br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519


Die hierzu inverse n:1-Beziehung, bei <strong>de</strong>r je<strong>de</strong>m <strong>Entity</strong> e 1 vom Typ E 1 maximal<br />

ein <strong>Entity</strong> <strong>de</strong>s Typs E 2 zugeordnet wird, bezeichnet man auch als funktionale<br />

Beziehung. Ein solcher Beziehungstyp beschreibt eine Funktion:<br />

R : E 1 → E 2<br />

In <strong>de</strong>r Praxis kommen funktionale Beziehungen recht häufig vor. Gera<strong>de</strong> in<br />

implementierungsnäheren Datenmo<strong>de</strong>llen wie <strong>de</strong>m Netzwerkmo<strong>de</strong>ll spielen sie<br />

eine wichtige Rolle, da sie direkt zum navigieren<strong>de</strong>n Zugriff genutzt wer<strong>de</strong>n<br />

können.<br />

Da im ER-<strong>Mo<strong>de</strong>ll</strong> Beziehungen bidirektional sind, kann je<strong>de</strong> 1:n-Beziehung<br />

auch als n:1- und damit als funktionale Beziehung angesehen wer<strong>de</strong>n. So ist <strong>de</strong>r<br />

produziert_von-Beziehungstyp offensichtlich funktional, da je<strong>de</strong>m Wein maximal<br />

ein Erzeuger zugeordnet wird.<br />

Die allgemeinste Form sind m:n-Beziehungen, die (zunächst noch) keinerlei<br />

Restriktionen beinhalten. Hier können je<strong>de</strong>m <strong>Entity</strong> <strong>de</strong>r Menge E 1 mehrere<br />

Entites aus E 2 zugeordnet sein – genauso kann ein <strong>Entity</strong> aus E 2 mit mehreren<br />

E 1 -<strong>Entity</strong>s in Beziehung stehen (Abbildung 3.15).<br />

E 1 E 2<br />

Abbildung 3.15: m:n-Beziehung<br />

Ein Beispiel für m:n-Beziehung ist unsere hergestellt_aus-Beziehung: ein<br />

Wein kann aus mehrere Rebsorten hergestellt wer<strong>de</strong>n und genauso kann eine<br />

Rebsorte in verschie<strong>de</strong>nen Weinen enthalten sein.<br />

In <strong>de</strong>r graphischen Notation <strong>de</strong>s ER-<strong>Mo<strong>de</strong>ll</strong>s wer<strong>de</strong>n Kardinalitäten als<br />

zusätzliche Informationen an <strong>de</strong>n Verbindungslinien zwischen Beziehungstyp<br />

und <strong>Entity</strong>-Typen notiert. Für <strong>de</strong>n speziellen Fall <strong>de</strong>r funktionalen Beziehung<br />

wird die Funktion<br />

R : E 1 → E 2<br />

durch eine Pfeilspitze im Bildbereich E 2 <strong>de</strong>r Funktion dargestellt. Der Beziehungstyp<br />

produziert_von zwischen Weine und Erzeuger wird <strong>de</strong>mnach wie in<br />

Abbildung 3.16 notiert.<br />

3.4 Eigenschaften von Beziehungen 73<br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519


Wein<br />

produziert<br />

von<br />

Erzeuger<br />

Abbildung 3.16: Funktionale Beziehung im ER-<strong>Mo<strong>de</strong>ll</strong><br />

Die 1:1-Beziehung stellt einen Spezialfall <strong>de</strong>r funktionalen Beziehung dar<br />

und kann <strong>de</strong>shalb, wie in Abbildung 3.17 dargestellt, mit zwei Pfeilspitzen notiert<br />

wer<strong>de</strong>n.<br />

Erzeuger besitzt Lizenz<br />

Abbildung 3.17: Graphische Notation einer 1:1-Beziehung im ER-<strong>Mo<strong>de</strong>ll</strong><br />

Für <strong>de</strong>n allgemeinen Fall <strong>de</strong>r Kardinalitätsangabe wird häufig die<br />

[min i ,max i ]-Notation verwen<strong>de</strong>t, bei <strong>de</strong>r zu je<strong>de</strong>m an <strong>de</strong>r Beziehung R beteilgten<br />

<strong>Entity</strong>-Typ E i <strong>de</strong>r minimale (min i ) und <strong>de</strong>r maximale (max i ) Wert <strong>de</strong>r<br />

möglichen Teilnahmen <strong>de</strong>r Instanzen von E i vorgegeben wird:<br />

min i ≤ |{r | r ∈ R ∧ r.E i = e i }| ≤ max i<br />

Die Kardinalitätsangaben wer<strong>de</strong>n an <strong>de</strong>r Verbindungslinie zum jeweiligen<br />

<strong>Entity</strong>-Typ notiert und sind somit auch für beliebige n-stellige Beziehungstypen<br />

verwendbar (Abbildung 3.18).<br />

E 1<br />

[min 1 ,max 1 ] [min n ,max n ]<br />

R<br />

E n<br />

[min 2 ,max 2 ]<br />

E 2<br />

Abbildung 3.18: Kardinalitätsangabe mit [min i ,max i ]-Notation<br />

74 3 <strong>Das</strong> <strong>Entity</strong>-<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong><br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519


Textuell können wir Kardinalitätsangaben wie folgt notieren:<br />

R(E 1 ,...,E i [min i ,max i ],...,E n )<br />

◭Beispiel 3-1◮ Betrachten wir zur Ver<strong>de</strong>utlichung die Beziehung<br />

hergestellt_aus mit <strong>de</strong>n folgen<strong>de</strong>n Kardinalitätsangaben:<br />

hergestellt_aus(Wein[1,3], Rebsorte[0,2])<br />

Nach unserer obigen Erklärung be<strong>de</strong>utet dies, dass ein Wein aus min<strong>de</strong>stens<br />

einer und maximal drei Rebsorten hergestellt sein muss (also zwischen einund<br />

dreimal in einer hergestellt_aus-Beziehung auftreten muss) bzw. dass je<strong>de</strong><br />

Rebsorte in maximal zwei Weinen verwen<strong>de</strong>t wer<strong>de</strong>n darf. Für die <strong>Entity</strong>-<br />

Mengen:<br />

wür<strong>de</strong> die Beziehungsmenge<br />

Weine = {w 1 ,w 2 } und Rebsorte = {r 1 ,r 2 ,r 3 ,r 4 }<br />

hergestellt_aus 1 = {(w 1 ,r 1 ),(w 1 ,r 2 ),(w 1 ,r 3 ),(w 2 ,r 4 )}<br />

diese For<strong>de</strong>rung erfüllen: Der Wein w 1 besteht aus <strong>de</strong>n Rebsorten r 1 ,...,r 3 , <strong>de</strong>r<br />

Wein w 2 aus r 4 . Dagegen erfüllt die Beziehungsmenge<br />

hergestellt_aus 2 = {(w 1 ,r 1 ),(w 1 ,r 2 ),(w 1 ,r 3 ),(w 1 ,r 4 )}<br />

diese For<strong>de</strong>rung nicht, da hierbei <strong>de</strong>r Wein w 1 viermal auftritt und w 2 nicht<br />

beteiligt ist.<br />

✷<br />

Eine spezielle Wertangabe für max i ist die Angabe eines ∗-Symbols, das einer<br />

unbegrenzten Anzahl entspricht. Für min i wer<strong>de</strong>n häufig 0 o<strong>de</strong>r 1 verwen<strong>de</strong>t,<br />

wobei<br />

• min i = 1 eine zwingen<strong>de</strong> Beziehung bezeichnet, d.h. je<strong>de</strong>s <strong>Entity</strong> <strong>de</strong>s betreffen<strong>de</strong>n<br />

Typs E i muss min<strong>de</strong>stens einmal an <strong>de</strong>r Beziehung teilnehmen,<br />

und<br />

• min i = 0 eine optionale Beziehung beschreibt, also ein <strong>Entity</strong> nicht unbedingt<br />

an <strong>de</strong>r Beziehung teilnehmen muss.<br />

In Abbildung 3.19 sind die verschie<strong>de</strong>nen Beziehungsarten und die korrespondieren<strong>de</strong>n<br />

Notationen dargestellt.<br />

Betrachten wir noch einige weitere Beispiele für Kardinalitätsangaben.<br />

◭Beispiel 3-2◮ Die 1:1-Beziehung besitzt zwischen Erzeuger und Lizenz ist<br />

zumin<strong>de</strong>st einseitig optional, wenn wir annehmen, dass es freie Lizenzen gibt<br />

und damit nicht je<strong>de</strong> Lizenz an <strong>de</strong>r Beziehung beteiligt ist (also min = 0). An<strong>de</strong>rerseits<br />

muss je<strong>de</strong>r Erzeuger genau eine Lizenz besitzen und somit an <strong>de</strong>r<br />

Beziehung teilnehmen:<br />

3.4 Eigenschaften von Beziehungen 75<br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519


Art<br />

Notation<br />

1:1-Beziehung<br />

[0,1] [0,1]<br />

E 1<br />

R<br />

E 2<br />

R(E 1 [0,1],E 2 [0,1])<br />

1:n-Beziehung<br />

[0,*] [0,1]<br />

E 1<br />

R<br />

E 2<br />

R(E 1 [0,∗],E 2 [0,1])<br />

m:n-Beziehung<br />

[0,*] [0,*]<br />

E 1<br />

R<br />

E 2<br />

R(E 1 [0,∗],E 2 [0,∗])<br />

Abbildung 3.19: [min i ,max i ]-Notation für verschie<strong>de</strong>ne Beziehungsarten<br />

besitzt(Erzeuger[1,1], Lizenz[0,1])<br />

✷<br />

◭Beispiel 3-3◮ Die funktionale Beziehung aus Abbildung 3.16 ist in<br />

[min,max]-Notation wie folgt zu notieren:<br />

produziert_von(Wein[1,1], Erzeuger[0,*])<br />

Dies be<strong>de</strong>utet, dass je<strong>de</strong>r Wein von genau einem Erzeuger hergestellt sein muss<br />

(es gibt keinen Wein ohne Erzeuger). Man spricht hier auch von einer totalen<br />

funktionalen Beziehung im Gegensatz zu partiellen Beziehungen bei <strong>de</strong>r Angabe<br />

[0,1]. Gleichzeitig kann ein Erzeuger beliebig viele Weine produzieren, wobei<br />

es auch Erzeuger ohne Wein geben kann.<br />

Wür<strong>de</strong>n wir eine Beschränkung auf maximal drei verschie<strong>de</strong>ne Weine pro<br />

Erzeuger festlegen, so ist folgen<strong>de</strong> Notation notwendig:<br />

produziert_von(Wein[1,1], Erzeuger[0,3])<br />

✷<br />

76 3 <strong>Das</strong> <strong>Entity</strong>-<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong><br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519


◭Beispiel 3-4◮ Die m:n-Beziehung hergestellt_aus zwischen Wein und<br />

Rebsorte kann mit <strong>de</strong>r auf Seite 71 formulierten Einschränkung auf sieben<br />

Rebsorten pro Wein in folgen<strong>de</strong>r Weise verfeinert wer<strong>de</strong>n:<br />

hergestellt_aus(Wein[1,7], Rebsorte[0,*])<br />

Gleichzeitig wird damit auch ausgedrückt, dass je<strong>de</strong>r Wein min<strong>de</strong>stens eine<br />

Rebsorte enthalten muss, an<strong>de</strong>rerseits aber nicht je<strong>de</strong> Rebsorte zur Herstellung<br />

<strong>de</strong>r Weine verwen<strong>de</strong>t wer<strong>de</strong>n muss.<br />

✷<br />

Alternative Notationen<br />

Während die Notation <strong>de</strong>r ER-Grundkonzepte <strong>Entity</strong>- und Beziehungstyp sowie<br />

Attribut in <strong>de</strong>r Literatur weitgehend i<strong>de</strong>ntisch ist, gibt es für die Kardinalitätsangabe<br />

verschie<strong>de</strong>ne Varianten. So wur<strong>de</strong> in <strong>de</strong>r Originalarbeit von Chen<br />

für (binäre) 1:n-Beziehungen eine einfachere Notation verwen<strong>de</strong>t, die <strong>de</strong>r Leserichtung<br />

entspricht. In Abbildung 3.20 (b) ist dies <strong>de</strong>r [min,max]-Notation<br />

gegenübergestellt: einem <strong>Entity</strong> vom Typ E 1 sind N <strong>Entity</strong>s vom Typ E 2 zugeordnet,<br />

daher wird das N an die E 2 -Seite geschrieben.<br />

[0,*] [0,1]<br />

E 1<br />

R<br />

E 2<br />

(a) [min,max]-Notation<br />

1 N<br />

E 1<br />

R<br />

E 2<br />

(b) Chen-Notation<br />

R<br />

E 1 E 2<br />

(c) Krähenfußnotation<br />

Abbildung 3.20: Alternative Notationen für Kardinalitäten<br />

Eine weitere Alternative ist die sogenannte Krähenfußnotation, die auch<br />

von einigen kommerziellen Entwurfswerkzeugen unterstützt wird. Hierbei<br />

3.4 Eigenschaften von Beziehungen 77<br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519


wird die n-Seite (in unserer [min-max]-Notation die [0,1]-Seite!) mit einem Krähenfuß<br />

versehen (Abbildung 3.20 (c)).<br />

3.5 Weitere Konzepte im <strong>Entity</strong>-<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong><br />

Bereits in <strong>de</strong>n ersten Vorschlägen für das ER-<strong>Mo<strong>de</strong>ll</strong> wur<strong>de</strong>n neben <strong>de</strong>n vier<br />

Basiskonzepten Werte, <strong>Entity</strong>s, Beziehungen und Attribute eine Reihe weiterer<br />

<strong>Mo<strong>de</strong>ll</strong>ierungskonzepte vorgeschlagen. Wir betrachten im Folgen<strong>de</strong>n insbeson<strong>de</strong>re<br />

abhängige <strong>Entity</strong>s, Spezialisierungen mittels <strong>de</strong>r IST-Beziehung und<br />

Optionalität von Attributen und Beziehungen.<br />

3.5.1 Abhängige <strong>Entity</strong>-Typen<br />

Neben Attributen können auch funktionale Beziehungen als Schlüssel dienen<br />

– die Definitionen übertragen sich direkt von Attributen auf funktionale Beziehungstypen,<br />

da die Semantik bei<strong>de</strong>r Konzepte durch Funktionen festgelegt<br />

wird. Der Wertebereich einer funktionalen Beziehung ist allerdings die Menge<br />

<strong>de</strong>r aktuellen Instanzen eines <strong>Entity</strong>-Typs – die I<strong>de</strong>ntifizierung durch eine<br />

funktionale Beziehung setzt also die tatsächliche aktuelle Existenz <strong>de</strong>s i<strong>de</strong>ntifizieren<strong>de</strong>n<br />

<strong>Entity</strong>s voraus!<br />

Aus diesem Grun<strong>de</strong> bezeichnen wir einen <strong>Entity</strong>-Typ, an <strong>de</strong>ssen Schlüssel<br />

eine funktionale Beziehung beteiligt ist, auch als abhängigen <strong>Entity</strong>-Typ (engl.<br />

Weak <strong>Entity</strong>). Instanzen eines <strong>de</strong>rartig abhängigen <strong>Entity</strong>-Typs können somit<br />

nur existieren in Abhängigkeit von an<strong>de</strong>ren <strong>Entity</strong>s. Als Beispiel betrachten<br />

wir einen <strong>Entity</strong>-Typ WeinJahrgang zur Darstellung konkreter Jahrgänge eines<br />

Weines, die sich aufgrund äußerer Einflüsse im Charakter unterschei<strong>de</strong>n<br />

können. Die Instanzen dieses <strong>Entity</strong>-Typs wer<strong>de</strong>n durch das Jahr und <strong>de</strong>n (abstrakten)<br />

Weineintrag, zu <strong>de</strong>m <strong>de</strong>r Jahrgang gehört, i<strong>de</strong>ntifziert. <strong>Das</strong> Beispiel<br />

ist in Abbildung 3.21 dargestellt. In <strong>de</strong>r dortigen Notation wer<strong>de</strong>n abhängige<br />

<strong>Entity</strong>-Typen durch funktionale Beziehungen als Schlüssel markiert.<br />

Abbildung 3.22 zeigt eine mögliche Ausprägung für das Beispielschema in<br />

Abbildung 3.21: <strong>Das</strong> Attribut Jahr und <strong>de</strong>r Wert <strong>de</strong>r funktionalen Beziehung<br />

gehört-zu sind zusammen Schlüssel für Wein-Jahrgänge. Weine können ohne<br />

Jahrgänge existieren, aber nicht umgekehrt.<br />

Viele Vorschläge für eine graphische Darstellung von ER-Schemata sehen<br />

eine explizite graphische Notation für abhängige <strong>Entity</strong>-Typen vor. Abbildung<br />

3.23 zeigt das Beispiel aus Abbildung 3.21 in <strong>de</strong>r von Elmasri und Navathe<br />

in [EN02] vorgeschlagenen Darstellung, in <strong>de</strong>r das <strong>Entity</strong>-Symbol und<br />

das <strong>Relationship</strong>-Symbol durch doppelte Linien, und die funktionale Beziehung<br />

durch die Angaben 1 und N gekennzeichnet sind. <strong>Das</strong> zusätzlich i<strong>de</strong>ntifizieren-<br />

78 3 <strong>Das</strong> <strong>Entity</strong>-<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong><br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519


WeinJahrgang<br />

gehört-zu<br />

Wein<br />

Jahr<br />

Name<br />

Restsüße<br />

Farbe<br />

Abbildung 3.21: Abhängige <strong>Entity</strong>s im ER-<strong>Mo<strong>de</strong>ll</strong>: Funktionale Beziehung als Schlüssel<br />

gehört-zu<br />

Jahr: 2004<br />

Restsüße: 1,2<br />

Name: Pinot Noir<br />

Farbe: Rot<br />

gehört-zu<br />

Jahr: 2003<br />

Restsüße: 1,4<br />

Name: Zinfan<strong>de</strong>l<br />

Farbe: Rot<br />

gehört-zu<br />

Jahr: 1999<br />

Restsüße: 6,7<br />

Name: Riesling Reserve<br />

Farbe: Weiß<br />

Abbildung 3.22: Mögliche Ausprägung für abhängige <strong>Entity</strong>s<br />

<strong>de</strong> Attribut Jahr wird dort als partieller Schlüssel bezeichnet und gestrichelt<br />

markiert.<br />

3.5.2 Die IST-Beziehung<br />

Eine weitere, in vielen Anwendungen auftauchen<strong>de</strong> Beziehung zwischen <strong>Entity</strong>s<br />

ist die Spezialisierungs-/Generalisierungsbeziehung, auch als IST-Beziehung<br />

bekannt (engl. is-a relationship). Zur Erläuterung betrachten wir das folgen<strong>de</strong><br />

Beispiel. In unsere Datenbank wollen wir zusätzlich Schaumweine aufnehmen,<br />

die sich von normalen Weinen durch <strong>de</strong>n Gehalt an Kohlendioxid unterschei<strong>de</strong>n,<br />

das durch spezielle Herstellungsverfahren eingebracht wird. Der<br />

Zusammenhang ist in Abbildung 3.24 (a) dargestellt:<br />

• Je<strong>de</strong>r Schaumwein (w 1 ,w 2 ,w 4 ) ist offensichtlich ein Wein (bzw. einer Instanz<br />

vom <strong>Entity</strong>-Typ Wein zugeordnet).<br />

• Aber nicht je<strong>de</strong>r Wein ist zugleich ein Schaumwein (wie z.B. w 3 ,w 5 ,w 6 ).<br />

3.5 Weitere Konzepte im <strong>Entity</strong>-<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong> 79<br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519


WeinJahrgang<br />

N<br />

gehört-zu<br />

1<br />

Wein<br />

Jahr<br />

Name<br />

Restsüße<br />

Farbe<br />

Abbildung 3.23: Abhängige <strong>Entity</strong>s im ER-<strong>Mo<strong>de</strong>ll</strong>: Alternative graphische Notation<br />

Name<br />

w 1<br />

w 2<br />

Wein<br />

Farbe<br />

w 1<br />

w 2<br />

w 4<br />

w 3<br />

w 4<br />

Schaumweine<br />

w 5<br />

w 6<br />

Weine<br />

(a) Beispiel einer IST-Beziehung<br />

IST<br />

Herstellung<br />

Schaumwein<br />

(b) Notation im ER-<strong>Mo<strong>de</strong>ll</strong><br />

Abbildung 3.24: IST-Beziehung im ER-<strong>Mo<strong>de</strong>ll</strong><br />

Abbildung 3.24(b) zeigt eine mögliche graphische Notation im ER-<strong>Mo<strong>de</strong>ll</strong>.<br />

Der <strong>Entity</strong>-Typ Wein bleibt wie bisher, <strong>de</strong>r <strong>Entity</strong>-Typ Schaumwein ist über eine<br />

funktionale IST-Beziehung zugeordnet und Instanzen dieses Typs wer<strong>de</strong>n auch<br />

über diese Beziehung i<strong>de</strong>ntifiziert. Es han<strong>de</strong>lt sich somit um einen Spezialfall<br />

eines abhängigen <strong>Entity</strong>-Typs!<br />

Weiterhin treffen die Attribute von Wein auch auf Schaumwein zu, auch wenn<br />

sie dort nicht explizit notiert sind. Wir sprechen hier von vererbten Attributen.<br />

Der <strong>Entity</strong>-Typ Schaumwein hat ein zusätzliches Attribut Herstellung, welches<br />

das Verfahren zum Einbringen <strong>de</strong>s Kohlendioxid kennzeichnet (z.B. Asti-<br />

Metho<strong>de</strong>, Champagner-Metho<strong>de</strong>). Insgesamt besitzt Schaumwein also folgen<strong>de</strong><br />

Attribute:<br />

80 3 <strong>Das</strong> <strong>Entity</strong>-<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong><br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519


Schaumwein(Name, Farbe, Herstellung)<br />

} {{ }<br />

von Wein<br />

Darüber hinaus ist zu beachten, dass nicht nur die Attribut<strong>de</strong>klarationen vererbt<br />

wer<strong>de</strong>n, son<strong>de</strong>rn auch jeweils die aktuellen Werte für eine Instanz in einem<br />

Zustand.<br />

In <strong>de</strong>r Textnotation schreiben wir E 1 IST E 2 als Deklaration einer Spezialisierungsbeziehung.<br />

Semantisch entspricht eine IST-Beziehung einer injektiven<br />

funktionalen Beziehung. In diesem Spezialfall können wir die Funktion σ(R) als<br />

Einbettung einer Menge in einer Obermenge auffassen und legen die Semantik<br />

wie folgt fest:<br />

σ(E 1 ) ⊆ σ(E 2 )<br />

Die Funktion σ(R) ist hier also die I<strong>de</strong>ntitätsfunktion. Um die spezielle Rolle<br />

<strong>de</strong>r IST-Beziehung graphisch hervorzuheben, wird in <strong>de</strong>r graphischen Notation<br />

oft anstelle <strong>de</strong>r Beziehungstyp-Raute ein fetter Funktionspfeil benutzt (wie in<br />

Abbildung 3.25).<br />

Herstellung<br />

Name<br />

Farbe<br />

Schaumwein<br />

Wein<br />

Abbildung 3.25: Alternative Notation für IST-Beziehung im ER-<strong>Mo<strong>de</strong>ll</strong><br />

3.5.3 Optionalität von Attributen<br />

Analog zur Optionalität von Beziehungen (Abschnitt 3.4.2), die ausdrückt, dass<br />

<strong>Entity</strong>s eines Typs nicht zwingend an einer Beziehung teilnehmen müssen,<br />

können auch Attribute optional sein. Dies ist <strong>de</strong>r Fall, wenn das Attribut nicht<br />

für alle <strong>Entity</strong>s einen <strong>de</strong>finierten Wert annehmen muss. Nicht-optionale Attribute<br />

wer<strong>de</strong>n entsprechend als total bezeichnet. Auch für die Optionalität (bzw.<br />

Totalität) sind mehrere graphische Notationen verbreitet. Wir folgen <strong>de</strong>r Notation<br />

von Hohenstein [Hoh93], in <strong>de</strong>r Optionalität durch kleine Kreise an <strong>de</strong>r<br />

Verbindungslinie zwischen Attributsymbol und <strong>Entity</strong>-Typ-Symbol markiert<br />

wird. Totalität wird nicht geson<strong>de</strong>rt gekennzeichnet. Ein Beispiel zeigt Abbildung<br />

3.26. Hier wird mo<strong>de</strong>lliert, dass bei kleineren Län<strong>de</strong>rn die Anbaugebiete<br />

nicht in Regionen unterteilt sind, das Attribut Region somit optional ist.<br />

3.5 Weitere Konzepte im <strong>Entity</strong>-<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong> 81<br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519


Weingut<br />

Adresse<br />

Name<br />

Land<br />

Region<br />

Erzeuger<br />

sitzt in<br />

Anbaugebiet<br />

Abbildung 3.26: Optionale Attribute im ER-<strong>Mo<strong>de</strong>ll</strong><br />

Semantisch be<strong>de</strong>utet die Optionalitätsangabe, dass die Funktion σ(A) eine<br />

partielle Funktion ist, somit nicht für alle <strong>Entity</strong>s aus σ(E) einen <strong>de</strong>finierten<br />

Wert annehmen muss.<br />

Analog kann die vorgestellte graphische Notation auch für Optionalität bei<br />

Beziehungstypen eingesetzt wer<strong>de</strong>n. Um Totalität explizit graphisch zu markieren,<br />

könnte etwa ein ausgefüllter Kreis verwen<strong>de</strong>t wer<strong>de</strong>n.<br />

3.6 Zusammenfassung<br />

In diesem Kapitel haben wir mit <strong>de</strong>m ER-<strong>Mo<strong>de</strong>ll</strong> ein Entwurfsmo<strong>de</strong>ll für Datenbanken<br />

kennengelernt, das trotz seines Alters immer noch eine wichtige Rolle<br />

spielt und auch durch eine Vielzahl (kommerzieller) Werkzeuge unterstützt<br />

wird. In Tabelle 3.3 sind noch einmal die wichtigsten Konzepte mit ihrer Be<strong>de</strong>utung<br />

dargestellt.<br />

Wie wir in späteren Kapiteln noch sehen wer<strong>de</strong>n, orientieren sich auch<br />

neuere Entwicklungen aus <strong>de</strong>m Bereich objektorientierter Entwurfsmo<strong>de</strong>lle am<br />

ER-<strong>Mo<strong>de</strong>ll</strong>, sodass wir diese Konzepte – wenn auch unter einem an<strong>de</strong>ren Namen<br />

– wie<strong>de</strong>rfin<strong>de</strong>n wer<strong>de</strong>n.<br />

3.7 Vertiefen<strong>de</strong> Literatur<br />

<strong>Das</strong> <strong>Entity</strong>-<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong> wur<strong>de</strong> in einem grundlegen<strong>de</strong>n Artikel von P.P.<br />

Chen im Jahre 1976 [Che76] beschrieben. Seit<strong>de</strong>m wur<strong>de</strong> es sehr oft in Lehrbüchern<br />

und Übersichtsartikeln behan<strong>de</strong>lt. Zu empfehlen ist insbeson<strong>de</strong>re die<br />

Einführung im Buch von Elmasri und Navathe [EN02]. Dort wird auch auf eine<br />

Reihe von Erweiterungen und Varianten <strong>de</strong>s ER-<strong>Mo<strong>de</strong>ll</strong>s verwiesen und weiterführen<strong>de</strong><br />

Literatur angegeben.<br />

82 3 <strong>Das</strong> <strong>Entity</strong>-<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong><br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519


Begriff<br />

<strong>Entity</strong><br />

<strong>Entity</strong>-Typ<br />

Beziehungstyp<br />

Attribut<br />

Schlüssel<br />

Kardinalitäten<br />

Stelligkeit<br />

funktionale Beziehung<br />

abhängige <strong>Entity</strong>s<br />

IST-Beziehung<br />

Optionalität<br />

Informale Be<strong>de</strong>utung<br />

zu repräsentieren<strong>de</strong><br />

Informationseinheit<br />

Gruppierung von <strong>Entity</strong>s mit<br />

gleichen Eigenschaften<br />

Gruppierung von Beziehungen<br />

zwischen <strong>Entity</strong>s<br />

datenwertige Eigenschaft eines<br />

<strong>Entity</strong>s o<strong>de</strong>r einer Beziehung<br />

i<strong>de</strong>ntifizieren<strong>de</strong> Eigenschaft von<br />

<strong>Entity</strong>s<br />

Einschränkung von Beziehungstypen<br />

bezüglich <strong>de</strong>r mehrfachen Teilnahme<br />

von <strong>Entity</strong>s an <strong>de</strong>r Beziehung<br />

Anzahl <strong>de</strong>r an einem Beziehungstyp<br />

beteiligten <strong>Entity</strong>-Typen<br />

Beziehungstyp mit<br />

Funktionseigenschaft<br />

<strong>Entity</strong>s, die nur abhängig von<br />

an<strong>de</strong>ren <strong>Entity</strong>s existieren können<br />

Spezialisierung von <strong>Entity</strong>-Typen<br />

Attribute o<strong>de</strong>r funktionale<br />

Beziehungen als partielle Funktionen<br />

Tabelle 3.3: Wichtige Begriffe <strong>de</strong>s ER-<strong>Mo<strong>de</strong>ll</strong>s<br />

3.8 Übungsaufgaben<br />

Übung 3-1 <strong>Mo<strong>de</strong>ll</strong>ieren Sie folgen<strong>de</strong>n Sachverhalt in einem ER-Schema. Geben<br />

Sie dabei speziell die Kardinalitäten <strong>de</strong>r Beziehungstypen in [min,max]-<br />

Notation an:<br />

Ein Würfel ist durch 6 Flächen beschrieben, die wie<strong>de</strong>rum jeweils<br />

durch 4 Kanten begrenzt sind. Je<strong>de</strong> Kante wird durch 2 Punkte repräsentiert,<br />

wobei je<strong>de</strong>r Punkt aus x-, y- und z-Koordinate besteht.<br />

Zwei aneinan<strong>de</strong>r grenzen<strong>de</strong> Flächen haben eine Kante gemeinsam,<br />

zwei zusammenstoßen<strong>de</strong> Kanten teilen sich einen Punkt.<br />

Übung 3-2 <strong>Mo<strong>de</strong>ll</strong>ieren Sie die Informationsstruktur <strong>de</strong>r folgen<strong>de</strong>n Anwendung<br />

im ER-<strong>Mo<strong>de</strong>ll</strong>.<br />

✷<br />

3.8 Übungsaufgaben 83<br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519


Es han<strong>de</strong>lt sich um eine Datenbank über Bankkonten und zugehörige<br />

Banktransaktionen. <strong>Mo<strong>de</strong>ll</strong>iert wer<strong>de</strong>n sollen verschie<strong>de</strong>ne Arten<br />

von Konten (Sparkonto, Girokonto usw.), die Informationen über<br />

die Kun<strong>de</strong>n und die Buchungen enthalten. Kun<strong>de</strong>n können mehrere<br />

Konten besitzen, aber nur ein Girokonto, und bei Sparkonten können<br />

mehrere Besitzer eingetragen sein. Scheckkarten wer<strong>de</strong>n nur<br />

für Girokonten ausgegeben, und nur bei diesen sind Abbuchungen<br />

über Geldautomaten möglich. Neben Auszahlungen und Einzahlungen<br />

sind insbeson<strong>de</strong>re Buchungen von einem Konto auf ein an<strong>de</strong>res<br />

möglich. Auszahlungen, Einzahlungen, Buchungen sowie Kontoeröffnung<br />

wer<strong>de</strong>n mit Datum protokolliert.<br />

Welche Beschreibungsaspekte können im ER-<strong>Mo<strong>de</strong>ll</strong> nicht o<strong>de</strong>r nur schlecht<br />

umgesetzt wer<strong>de</strong>n?<br />

✷<br />

Übung 3-3 Geben Sie aus einem Ihnen bekannten Szenario (Universität, Bibliothek<br />

usw.) je ein Beispiel für eine<br />

1. m:n-Beziehung,<br />

2. 1:n-Beziehung,<br />

3. 1:1-Beziehung,<br />

4. mehrstellige Beziehung. ✷<br />

Übung 3-4 Bei <strong>de</strong>r ER-<strong>Mo<strong>de</strong>ll</strong>ierung bestehen trotz <strong>de</strong>r Beschränkung auf wenige<br />

Konzepte einige Freiheiten. So gibt es oft folgen<strong>de</strong> Alternativen:<br />

1. <strong>Entity</strong>-Typ vs. Attribut,<br />

2. abhängiger <strong>Entity</strong>-Typ vs. selbständiger <strong>Entity</strong>-Typ,<br />

3. mehrstelliger Beziehungstyp vs. zusätzlicher <strong>Entity</strong>-Typ und binäre Beziehungen,<br />

4. Attribut vs. IST-Beziehung.<br />

Geben Sie für je<strong>de</strong> dieser Möglichkeiten zum ER-Schema aus Abbildung 3.8<br />

ein Beispiel an und diskutieren Sie Vor- und Nachteile.<br />

✷<br />

84 3 <strong>Das</strong> <strong>Entity</strong>-<strong>Relationship</strong>-<strong>Mo<strong>de</strong>ll</strong><br />

© <strong>de</strong>s Titels »Datenbanken – Konzepte und Sprachen« (ISBN 978-3-8266-9519-3) 2013<br />

by Verlagsgruppe Hüthig Jehle Rehm GmbH, Hei<strong>de</strong>lberg.<br />

Nähere Informationen unter: http://www.mitp.<strong>de</strong>/9519

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!