Online-Kurs 'Datenbanken und Datenmodellierung'
Online-Kurs 'Datenbanken und Datenmodellierung'
Online-Kurs 'Datenbanken und Datenmodellierung'
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
Inhaltsverzeichnis<br />
<strong>Online</strong>-<strong>Kurs</strong> <strong>'Datenbanken</strong> <strong>und</strong><br />
<strong>Datenmodellierung'</strong><br />
Das Entity-Relationship-Modell<br />
Print-Version - 15.04.2002<br />
(c) StR S. Winter - Universität Passau<br />
1 Allgemeine Hinweise zum Abschnitt ER-Modell<br />
1.1 Lernziele<br />
1.2 Begriffe<br />
1.3 Vorgehensweise bei der Bearbeitung<br />
1.4 Material<br />
2 Gr<strong>und</strong>lagen des ER-Modells<br />
2.1 Das Entity-Relationship-Modell<br />
2.2 Die Idee des ER-Modells<br />
2.3 Die graphische Darstellung<br />
2.4 Rollennamen<br />
2.5 Der Begriff der Domäne<br />
2.6 Übungen<br />
3 Schlüssel<br />
3.1 Identifizierung von Entities<br />
3.2 Superschlüssel, Schlüsselkandidat, Primärschlüssel<br />
3.3 Übungen<br />
4 Mengenschreibweise von Entity- <strong>und</strong> Relationship-Typen<br />
4.1 Mengenschreibweise für Entity-Typen<br />
4.2 Mengenschreibweise für Relationship - Typen<br />
5 Relationship-Typen als Teilmengen kartesischer Produkte<br />
5.1 Konkatenation von Entities<br />
5.2 Das kartesische Produkt von Entity-Typen<br />
5.3 Relationship-Typ als Teilmenge eines kartesischen Produkts<br />
5.4 Übungen<br />
6 Funktionalität bei zweistelligen Relationship-Typen<br />
6.1 Funktionalität (Kardinalität) bei 2-stelligen Relationship-Typen<br />
6.2 1:1 - Relationship-Typen<br />
6.3 n:1 - Relationship-Typen<br />
6.4 1:n - Relationship-Typen<br />
6.5 n:m - Relationship-Typen<br />
6.6 Die (min, max) - Notation<br />
6.7 Übungen<br />
7 Mehrstellige Relationship-Typen<br />
7.1 Mehrstellige Relationship-Typen<br />
7.2 Funktionalitäten für mehrstellige Relationship-Typen<br />
7.3 Übungen<br />
8 Generalisierung <strong>und</strong> Spezialisierung<br />
8.1 Generalisierung<br />
8.2 Spezialisierung<br />
8.3 Die isa-Beziehung<br />
8.4 Übungen<br />
9 Schwache Entity-Typen<br />
9.1 Existenzabhängigkeit<br />
9.2 Schwache Entity-Typen
9.3 Diskriminator <strong>und</strong> Schlüssel schwacher Entity-Typen<br />
9.4 Darstellung im ER-Modell<br />
9.5 Mehrfache Abhängigkeiten<br />
9.6 Übungen<br />
10 Der Entwurf eines ER-Modells<br />
10.1 Vorschlag für die Vorgehensweise<br />
10.2 Übungen<br />
1 Allgemeine Hinweise zum Abschnitt ER-Modell<br />
Dieser Abschnitt behandelt die Gr<strong>und</strong>lagen des Entity-Relationship-Modell (ER-Modell) sowie den Entwurf eines<br />
ER-Modells.<br />
1.1 Lernziele<br />
Nach dem Studium dieses Abschnittes sollten Sie Folgendes<br />
1. kennen<br />
❍ Gr<strong>und</strong>lagen des ER-Modells<br />
❍ Einordnung des ER-Modells innerhalb des Datenbankentwurfes<br />
❍ Schlüssel<br />
❍ Funktionalität, Kardinalität<br />
❍ Prinzip der Generalisierung <strong>und</strong> Spezialisierung<br />
❍ Schwache bzw. existenzabhängige Entity-Typen<br />
2. durchführen können<br />
❍ Erstellung eines ER-Modells zu einer vorgegebenen 'Miniwelt'<br />
❍ Festlegung eines Primärschlüssels bei den Entity-Typen<br />
1.2 Begriffe<br />
Zudem sollten Sie die Bedeutung folgender Begriffe kennen:<br />
● Entity-Typ , Entity , Relationship-Typ , Relationship , Attribut , Attributwert<br />
● Superschlüssel , Schlüsselkandidat , Primärschlüssel<br />
● Funktionalität<br />
● Generalisierung , Spezialisierung<br />
● Existenzabhängigkeit , schwacher Entity-Typ , Diskriminator<br />
1.3 Vorgehensweise bei der Bearbeitung<br />
Das Material sollte in der vorgegebenen Reihenfolge abgearbeitet werden.<br />
1.4 Material<br />
●<br />
Printversion des Abschnittes " ER-Modell "
2 Gr<strong>und</strong>lagen des ER-Modells<br />
2.1 Das Entity-Relationship-Modell<br />
Das Entity-Relationship-Modell ist ein Datenmodell , das sich gut zur Darstellung des konzeptuellen<br />
Datenbankschemas für relationale Datenbanksysteme eignet.<br />
Dazu steht eine standardisierte graphische Notation in Form des Entity-Relationship-Diagramms (ER-Diagramm) zur<br />
Verfügung.<br />
Sowohl der Vorgang als auch das Resultat der Modellierung wird Entity-Relationship-Entwurf (ER-Entwurf) genannt.<br />
Das Resultat der Modellierung wird auch oft - ebenso wie das zugr<strong>und</strong>eliegende Datenmodell - als<br />
Entity-Relationship-Modell (ER-Modell) des Anwendungsbereichs bezeichnet. Vorteil des ER-Entwurfs ist es, dass er<br />
systematisch in eine Menge von Relationenschemata überführt werden kann, die die Gr<strong>und</strong>lage für die Tabellen einer<br />
relationalen Datenbank bilden.<br />
Bemerkung:<br />
Datenmodelle zur konzeptuellen Modellierung beschreiben nur die Struktur der Daten <strong>und</strong> verfügen im Allgemeinen<br />
nicht über Operatoren zur Datenmanipulation.<br />
2.2 Die Idee des ER-Modells<br />
2.2.1 Entity, Relationship, Attribut <strong>und</strong> Attributwert<br />
Das ER-Modell geht davon aus, dass sich die betrachtete Miniwelt durch Objekte (Entities) <strong>und</strong> Beziehungen<br />
zwischen diesen Objekten (Relationships) beschreiben lässt. Entities <strong>und</strong> Relationships können durch Attribute<br />
näher charakterisiert werden. Dabei handelt es sich um Eigenschaften, die für jedes Entity bzw. jede Relationship durch<br />
entsprechende Werte, die Attributwerte, konkretisiert werden.<br />
Beispiel: In der Miniwelt Schule gibt es beispielsweise die Lehrerin Thatcher, Geburtsjahr 1970, wohnhaft in Berlin.<br />
Diese ist Klassenleiterin der Klasse 11, dessen Klassenzimmer die Raumnummer 202 hat. Lehrerin Thatcher <strong>und</strong> die<br />
Klasse 11 sind Objekte. Eine Beziehung zwischen diesen beiden Objekten besteht darin, dass Frau Thatcher die<br />
Klassenleitung dieser Klasse hat.<br />
2.2.2 Entity-Typ, Relationship-Typ, Attribut<br />
Ein Entity-Typ fasst eine Menge von gleichartigen Entities, d.h. Entities, die durch gleiche Attribute charakterisiert<br />
sind, zusammen. Analog entspricht ein Relationship-Typ einer Menge gleichartiger Relationships.<br />
Beispiel: In der Miniwelt Schule könnte sich das folgendermaßen darstellen:
Bemerkung:<br />
1.<br />
2.<br />
3.<br />
4.<br />
5.<br />
Entity-Typen müssen nicht disjunkt sein, d.h. im Allgemeinen kann ein Entity Element mehrerer Entity-Typen sein.<br />
Relationship-Typen stellen - wie angesprochen - Beziehungen zwischen Entity-Typen her. Die Stelligkeit eines<br />
Relationship-Typen gibt an, zwischen wie vielen Entity-Typen eine Beziehung hergestellt wird. Am häufigsten sind<br />
2-stellige Relationship-Typen.<br />
Ein Entity-Typ kann natürlich an mehreren Relationship-Typen beteiligt sein.<br />
Entity-Typ, Relationship-Typ <strong>und</strong> Attribut entsprechen der Schemaebene, während Entity, Relationship <strong>und</strong><br />
Attributwert Instanzen darstellen.<br />
Konkrete Entities, Relationships <strong>und</strong> Attributwerte spielen in der Regel beim ER-Entwurf keine Rolle, weil die<br />
Modellierung auf Schemaebene stattfindet.<br />
Beispiel:<br />
● Beispiel zu Bemerkung 1:<br />
●<br />
Die Entity-Typen Lehrkraft <strong>und</strong> Erziehungsberechtigter sind nicht disjunkt. Eine Lehrkraft kann<br />
gleichzeitig Erziehungsberechtige(r) sein.<br />
Beispiel zu Bemerkung 3:<br />
Eine Lehrkraft kann einerseits eine Klassenführung, andererseits eine Fachbetreuung ausüben. Die Situation<br />
kann durch<br />
❍ die Entity-Typen Lehrkraft, Klasse <strong>und</strong> Fach <strong>und</strong><br />
❍ die Relationship-Typen hat_Klassenleitung_in (Beziehung zwischen Lehrkraft <strong>und</strong> Klasse) <strong>und</strong><br />
hat_Fachbetreuung_in (Beziehung zwischen Lehrkraft <strong>und</strong> Fach) modelliert werden.<br />
Der Entity-Typ Lehrkraft ist an beiden Beziehungen beteiligt.<br />
2.3 Die graphische Darstellung<br />
Entity-Typen werden durch Rechtecke , Relationship-Typen durch Rauten <strong>und</strong> Attribute durch Ovale dargestellt.<br />
Der zugehörige Name wird jeweils innerhalb der Figur angegeben. Die Rauten der Relationship-Typen werden mit den<br />
beteiligten Entity-Typen durch Kanten verb<strong>und</strong>en. Die Attribute werden den Entity-Typen ebenfalls durch Kanten<br />
zugeordnet.<br />
Beispiel: Die graphische Umsetzung des obigen Beispiels hat damit folgende Form:
Ist ein Entity-Typ an mehreren Relationship-Typen beteiligt, ist dieser Entity-Typ dementsprechend mit mehreren<br />
Relationship-Typen durch Kanten verb<strong>und</strong>en.<br />
Beispiel: Lehrkräfte können sowohl eine Klassenleitung sowie eine Fachbetreuung ausüben. Ein mögliches ER-Modell<br />
zeigt folgendes Bild<br />
Attribute von Relationship-Typen werden wie Attribute von Entity-Typen grafisch dargestellt.<br />
Beispiel: Die Wertigkeit einer Fachbetreuung ist ein Attribut des Relationship-Typen hat_Fachbetreuung_in.
2.4 Rollennamen<br />
Um die durch einen Relationship-Typ verb<strong>und</strong>enen Entity-Typen genauer charakterisieren zu können, können ihnen<br />
Rollennamen zugeordnet werden.<br />
Beispiel: Gegeben sei der Entity-Typ Person. Die Beziehung Elternteil - Kind kann durch folgenden Relationship-Typen<br />
beschrieben werden:<br />
Bemerkung:<br />
Wie das obige Beispiel zeigt, kann ein Entity-Typ mit sich selbst in Beziehung gesetzt werden.<br />
2.5 Der Begriff der Domäne<br />
Entity- bzw. Relationship-Typen werden durch eine geeignete Auswahl von Attributen beschrieben. Die zulässigen<br />
Attributwerte werden je Attribut durch eine vorgegebene Wertemenge, die Domäne, festgelegt.<br />
Beispiel: Den Attributen des Entity-Typs Lehrkraft können beispielsweise folgende Domänen zugr<strong>und</strong>eliegen:<br />
Attribut Domäne<br />
Name STRING<br />
PersNr INTEGER > 0<br />
Wohnort STRING<br />
Geschlecht {'w', 'm'}<br />
Geburtsjahr INTEGER > 1900<br />
Domänen können<br />
● extensional, d.h. durch Aufzählung aller zulässigen Werte, oder<br />
● intensional, d.h. durch Angabe allgemein bekannter Mengen, wie INTEGER für ganze Zahlen, STRING für<br />
Zeichenreihen usw., die durch Bedingungen, wie INTEGER > 0, modifiziert werden können,<br />
definiert sein.
Beispiel: Im obigen Beispiel ist die Domäne des Attributs Geschlecht extensional definiert, alle anderen Domänen<br />
sind intensional definiert.<br />
Bemerkung:<br />
Die Festlegung der Domänen kann bei der Erstellung des ER-Modells erfolgen. Dies ist vor allem dann notwendig, wenn<br />
sich bereits bei der Analyse der Miniwelt spezielle Anforderungen an bestimmte Domänen ergeben. Sehr oft werden die<br />
Domänen aber erst bei der Entwicklung des Relationenmodells festgelegt.<br />
2.6 Übungen<br />
Aufgabe:<br />
Welche Entity- <strong>und</strong> Relationship-Typen sind in der Miniwelt Schule vorstellbar?<br />
Lösungsvorschlag:<br />
●<br />
●<br />
Aufgabe:<br />
Entity-Typen: Lehrkraft, Schueler, Klasse, Fach, Raum, Personal, ...<br />
Relationship-Typen: hat_Fachbetreuung_in, hat_Lehrbefaehigung_in, hat_St<strong>und</strong>enplan, ist_Fachlehrkraft_von,<br />
gehoert_zu_Klasse, ...<br />
Erstellen Sie ein ER-Modell für folgende Situation: Einige Lehrkräfte sind Vorgesetzte der anderen Lehrkräfte.<br />
Lösungsvorschlag:<br />
Es ist also möglich, dass an einem Relationship-Typ nur ein einziger Entity-Typ beteiligt ist.<br />
Gegeben ist folgende Ausgangssituation: In einer Firma gibt es Arbeitnehmer, die Maschinen bedienen. Außerdem gibt<br />
es Arbeitnehmer, die Vorgesetzte sind. (Attribute sollen hier vernachlässigt werden.)<br />
Aufgabe:<br />
Welche Entity- bzw. Relationship-Typen gibt es?<br />
Lösungsvorschlag:<br />
●<br />
●<br />
Aufgabe:<br />
Entity-Typen: Arbeitnehmer, Maschinen<br />
Relationship-Typen: ist_Vorgesetzter_von, bedient<br />
Zeichnen Sie das ER-Modell für die Situation.<br />
Lösungsvorschlag:
3 Schlüssel<br />
3.1 Identifizierung von Entities<br />
Die Wahl der Attribute eines Entity-Typs muss derart erfolgen, dass jedes Entity dieses Entity-Typen eindeutig durch<br />
seine Attributwerte identifizierbar ist. Gegebenenfalls müssen weitere Attribute hinzugenommen oder vorhandene<br />
Attribute stärker differenziert werden. Sehr oft werden zu diesem Zweck "künstliche" Unterscheidungsmerkmale<br />
eingeführt.<br />
Beispiel: Für den Entity-Typ Lehrkraft seien folgende zwei Möglichkeiten vorgegeben:<br />
Im linken Fall kann es bei der Identifizierung der Entities schnell zu Problemen kommen, da an einer Schule durchaus<br />
zwei Lehrkräfte mit identischen Daten bzgl. Name, Wohnort, Geschlecht <strong>und</strong> Geburtsjahr unterrichten können. Durch<br />
Hinzunahme des Attributs PersNr ist aber eine eindeutige Identifizierung möglich. Dabei kann die Identifzierung des<br />
Entities gr<strong>und</strong>sätzlich über die Kombination aller ihrer Attributwerte erfolgen. Der Wert des Attributs PersNr alleine ist<br />
aber offensichtlich auch ausreichend.<br />
3.2 Superschlüssel, Schlüsselkandidat, Primärschlüssel<br />
Obige Überlegung führt zur Unterscheidung von Superschlüssel, Schlüsselkandidat <strong>und</strong> Primärschlüssel von Entity<br />
- Typen.<br />
1. Jede Teilmenge der Attributmenge eines Entitytyps, anhand deren Wertkombination die Entities dieses Typs<br />
identifizierbar sind, heißt Superschlüssel dieses Entity-Typs.<br />
2. Ein minimaler Superschlüssel, d.h. ein Superschlüssel mit einer minimalen Menge von Schlüsselattributen, heißt<br />
Schlüsselkandidat. Minimale Menge bedeutet dabei, dass aus dieser Menge kein Attribut weggelassen<br />
werden kann, ohne die Superschlüsseleigenschaft der Menge zu zerstören.<br />
3. Einer der Schlüsselkandidaten eines Entity-Typs wird beim ER-Entwurf als Primärschlüssel ausgewählt <strong>und</strong><br />
dient dann zur Identifizierung von Entities.<br />
Beispiel: In der Schulverwaltung wird eine Klasse durch die Attribute Name <strong>und</strong> Klassenzimmer festgelegt. Jede<br />
Klasse hat dabei ihr eigenes Klassenzimmer-
Superschlüssel: ● {Name, Klassenzimmer}<br />
●<br />
●<br />
{Name}<br />
Schlüsselkandidaten: ● {Name}<br />
●<br />
{Klassenzimmer}<br />
{Klassenzimmer}<br />
Primärschlüssel: je nach Festlegung<br />
●<br />
●<br />
{Name} oder<br />
{Klassenzimmer}<br />
Bemerkung:<br />
Zu einem Entity-Typen kann es mehrere Schlüsselkandidaten geben. Dabei ist es durchaus möglich, dass diese<br />
Attributmengen verschieden groß sind.<br />
Beispiel: Schüler sind in unserer Schulverwaltung eindeutig durch Angabe des Eintrittsjahres <strong>und</strong> der laufenen Nummer<br />
charakterisiert. Die zweielementige Attributmenge {Eintrittsjahr, Nr} eignet sich daher als Schlüsselkandidat des<br />
Entity-Typen Schueler. Führt man zusätzlich für die Schüler Personalnummern ein, so ist die einelementige Menge<br />
{PersNr} ebenfalls ein Schlüsselkandidat.<br />
Bemerkung:<br />
Die Wahl der Schlüssel, insbesondere der Primärschlüssel, hängt natürlich auch vom betrachteten Zeitraum oder dem<br />
Anwendungsbereich ab. Bei beschränktem Zeitraum bzw. Anwendungsbereich reicht in der Regel oft ein "kleiner"<br />
Primärschlüssel, d.h.ein Primärschlüssel, der in einem erweiterten Zeitraum oder Anwendungsbereich die Kriterien eines<br />
Superschlüssels nicht erfüllen würde.<br />
Beispiel: In dem oben skizzierten Beispiel ist die Wahl des Attributs Name bzw. Klassenzimmer als Primärschlüssel<br />
ausreichend, da davon ausgegangen werden kann, dass innerhalb einer Schule der Klassenname bzw. das<br />
entsprechende Klassenzimmer nur einmal existiert. Würde die Schulverwaltung aber in eine übergeordnete<br />
Schulverwaltung integriert, müsste der Primärschlüssel eventuell neu definiert werden, da dann durchaus zwei Klassen<br />
mit gleichem Namen vorkommen können.<br />
Bemerkung:<br />
● Statt "Superschlüssel" wird manchmal der Begriff "Schlüssel" verwendet. Oft wird auch der Primärschlüssel<br />
einfach als Schlüssel (Key) bezeichnet.<br />
● Die Entscheidung für einen bestimmten Schlüsselkandidaten als Primärschlüssel geschieht während der<br />
Modellierung des Anwendungsbereiches.<br />
● Im Abschnitt über das Relationenmodell wird ebenfalls auf Schlüssel eingegangen.<br />
● Primärschlüssel werden im ER-Modell durch Unterstreichung gekennzeichnet.<br />
3.3 Übungen<br />
Aufgabe:<br />
Welche künstlichen Unterscheidungsmerkmale kennen Sie aus dem täglichen Leben?
Lösungsvorschlag:<br />
●<br />
●<br />
●<br />
●<br />
●<br />
Ausweisnummern<br />
Bestellnummern<br />
Bankleitzahlen<br />
Kontonummern<br />
usw.<br />
Firmenmitarbeiter werden durch den Entity-Typ Angestellte mit den Attributen PersNr, Name <strong>und</strong> Einkommen<br />
dargestellt.<br />
Aufgabe:<br />
Welche Superschlüssel <strong>und</strong> Schlüsselkandidaten gibt es?<br />
Lösungsvorschlag:<br />
●<br />
●<br />
Superschlüssel: {PersNr, Name, Einkommen}, {PersNr, Name}, {PersNr, Einkommen}, {PersNr}<br />
Schlüsselkandidaten: {PersNr}<br />
Betrachten Sie zu dem Entitytyp Professordie folgenden möglichen Attribute:Vorname, Name, Fachgebiet, Status,<br />
Zimmer, Telefon <strong>und</strong> PersNr. Welche Schlüssel sind im Folgenden angegeben?<br />
Aufgabe:<br />
{Name, Telefon}<br />
Lösungsvorschlag:<br />
Superschlüssel, da die Zuordnung Telefon - Professor eindeutig ist.<br />
Aufgabe:<br />
{Zimmer}<br />
Lösungsvorschlag:<br />
Superschlüssel, Schlüsselkandidat, eventuell Primärschlüssel. (Jede Professorin bzw. jeder Professor hat ein eigenes<br />
Büro)<br />
Aufgabe:<br />
{Name, Vorname}<br />
Lösungsvorschlag:<br />
kein Schlüssel, da Professoren mit gleichem Vornamen <strong>und</strong> Namen existieren können.<br />
Aufgabe:<br />
Wie stellt sich für die drei vorgegebenen Attributmengen die Situation bzgl. der Schlüssel dar, wenn nicht nur die
Professorenschaft einer Hochschule, sondern die Professorenschaft eines Landes betrachtet wird?<br />
Lösungsvorschlag:<br />
{Name, Telefon} bleibt ein Superschlüssel, da eine Telefonnummer landesweit nur einmal vergeben wird.<br />
Das Attribut Zimmer ist weder Schlüsselkandidat noch Superschlüssel, da nicht auszuschließen ist, dass es an<br />
verschiedene Hochschulen gleiche Zimmernummern gibt.<br />
{Name, Vorname} ist kein Schlüssel, da es aufgr<strong>und</strong> der erweiterten Anzahl der Professoren sehr wahrscheinlich ist,<br />
dass Hochschullehrer mit identischem Namen <strong>und</strong> Vornamen existieren.<br />
4 Mengenschreibweise von Entity- <strong>und</strong> Relationship-Typen<br />
Die ER-Entwurf ist auf der Schema-Ebene angesiedelt. Zur Angabe der Instanz eines Entity- bzw. Relationship-Typen<br />
nutzt man die Mengenschreibweise.<br />
4.1 Mengenschreibweise für Entity-Typen<br />
Ein Entity-Typ E ist eine Menge von Entities e 1 bis e n , es gilt also E = { e 1 , ..., e n }.<br />
Ein konkretes Entity wird durch die Liste der zugehörigen Attribut - Wert - Paare repräsentiert.<br />
Beispiel: Für der Entitytyp Lehrkraft gilt: Lehrkraft = { l 1 , ..., l 7 } mit<br />
l 1 = ((PersNr: 566), (Name: Schumann), (Geschlecht: w), (Wohnort: Passau), (Geburtsjahr: 1959))<br />
l 2 = ((PersNr: 15), (Name: Neumann), (Geschlecht: m), (Wohnort: Passau), (Geburtsjahr: 1950))<br />
l 3 = ((PersNr: 35), (Name: Rinser), (Geschlecht: w), (Wohnort: Passau), (Geburtsjahr: 1946))<br />
l 4 = ((PersNr: 73), (Name: Zuse), (Geschlecht: m), (Wohnort: München), (Geburtsjahr: 1936))<br />
l 5 = ((PersNr: 245), (Name: Gauß), (Geschlecht: m), (Wohnort: Passau), (Geburtsjahr: 1925))<br />
l 6 = ((PersNr: 356), (Name: Thatcher), (Geschlecht: w), (Wohnort: Berlin), (Geburtsjahr: 1970))<br />
l 7 = ((PersNr: 1344), (Name: Graf), (Geschlecht: w), (Wohnort: Berlin), (Geburtsjahr: 1957))<br />
Für den Entity-Typ Klasse gilt: Klasse = { k 1, k 2 } mit<br />
k 1 = ((Name: 11), (Klassenzimmer: 202))<br />
k 2 = ((Name: 5), (Klassenzimmer: 101))<br />
4.2 Mengenschreibweise für Relationship - Typen<br />
Ebenso können Relationship-Typen durch Mengen dargestellt werden. Die Relationships werden dabei durch Auflistung<br />
der Attribute <strong>und</strong> Attributwerte aller beteiligten Entities beschrieben.<br />
Beispiel: Die Relationship hat_Klassenleitung_in stellt eine Beziehung zwischen den Entity-Typen Lehrkraft<br />
<strong>und</strong> Klasse her.
Bemerkung:<br />
Die Mengenschreibweise von Relationship-Typ ist zum Verständnis der (min, max) - Notation notwendig.<br />
5 Relationship-Typen als Teilmengen kartesischer Produkte<br />
Relationship-Typen sind Mengen von Relationships. Relationships wiederum können als eine kombinierte Liste aller<br />
Attribut-Werte-Paare der beteiligten Entities dargestellt werden. Mathematisch kann damit ein Relationship-Typ als<br />
Teilmenge des kartesischen Produktes der beteiligten Entity-Typen gesehen werden.<br />
5.1 Konkatenation von Entities<br />
Eine Kombination von Entities wird über den Begriff der Konkatenation definiert.<br />
Definition: Konkatenation von Entities<br />
Die Konkatenation e 1 * e 2 zweier Entities e 1 <strong>und</strong> e 2 ist die Liste der Attribut-Wert-Paare, die durch<br />
Hintereinanderschreiben der entsprechenden Listen für e 1 <strong>und</strong> e 2 entsteht.<br />
Beispiel: Für l 2 = ((PersNr: 15), (Name: Neumann), (Geschlecht: m), (Wohnort: Passau), (Geburtsjahr: 1950))<br />
<strong>und</strong> k 2 = ((Name: 5), (Klassenzimmer: 101))<br />
ergibt die Konkatenation<br />
l 2 * k 2 = ((PersNr: 15), (Name: Neumann), (Geschlecht: m), (Wohnort: Passau), (Geburtsjahr: 1950), (Name: 5),<br />
(Klassenzimmer: 101))<br />
Die Konkatenation entspricht der Beziehung Lehrkraft Neumann hat die Klassenleitung der Klasse 5, ist<br />
damit also als Relationship des Relationship-Typen hat_Klassenleitung_in interpretierbar.<br />
Bemerkung:<br />
Analog wird die Konkatenation e 1 * ... * e n mehrerer Entities definiert.<br />
5.2 Das kartesische Produkt von Entity-Typen<br />
Die Menge aller Konkatenationen der Entities zweier Entity-Typen E 1 <strong>und</strong> E 2 wird über das kartesische Produkt E 1 x<br />
E 2 beschrieben.<br />
Definition: Kartesisches Produkt von Entities<br />
Das kartesische Produkt E 1 x E 2 zweier Entity-Typen E 1 <strong>und</strong> E 2 ist definiert als die Menge aller möglichen<br />
Konkatenationen ihrer Elemente: E 1 x E 2 = { e 1 * e 2 | e 1 E 1 <strong>und</strong> e 2 E 2 }<br />
Bemerkung:<br />
Analog wird das kartesische Produkt E 1 x ... x E n mehrerer Entity-Typen definiert.<br />
Beispiel:
Die Menge enthält alle möglichen Kombinationen der Entity-Typen Lehrkraft <strong>und</strong> Klasse. Anders ausgedrückt sind<br />
dies alle (theoretisch) möglichen Relationships des Relationship-Typen hat_Klassenleitung_in.<br />
Das kartesische Produkt der beteiligten Entity-Typen bildet also den Elementevorrat für den jeweiligen<br />
Relationship-Typen.<br />
5.3 Relationship-Typ als Teilmenge eines kartesischen Produkts<br />
Jeder Relationship-Typ R zwischen gegebenen Entity-Typen E 1 , ..., E k kann als eine Teilmenge des kartesischen<br />
Produkts E 1 x ... x E k aufgefasst werden, d.h.<br />
Bei k beteiligten Entity-Typen heißt R k-stellig.<br />
Beispiel:<br />
R E 1 x ... x E k.<br />
Der Relationship-Typ hat_Klassenleitung_in ist 2-stellig.<br />
5.4 Übungen<br />
Aufgabe:<br />
In einer Firma gibt es Angestellte, die Projekte bearbeiten. Angestellte sind Müller mit der PersNr. 3 <strong>und</strong> Meier mit der<br />
PersNr. 7. Müller ist am Projekt 'Datenbanksysteme' beteiligt, Meier ist Mitarbeiter in den Projekten 'Datenbanksysteme'<br />
<strong>und</strong> 'Softwareentwicklung'.<br />
Geben Sie ein geeignetes ER-Diagramm an.<br />
Lösungsvorschlag:<br />
Die Einführung der Projektnummer ermöglicht die eindeutige Indentifizierung der Projekte. Ist die Namensgebung der<br />
Projekte eindeutig, kann auch der Projektname als Primärschlüssel verwendet werden.
Aufgabe:<br />
Geben Sie das kartesische Produkt Angestellter x Projekt an.<br />
Lösungsvorschlag:<br />
Angestellter x Projekt = { ((PersNr: 3), (Name: Müller), (ProNr: 1), (Name: Datenbanksysteme)), ((PersNr: 3),<br />
(Name: Müller), (ProNr: 2), (Name: Softwareentwicklung)),((PersNr: 7), (Name: Meier), (ProNr: 1), (Name:<br />
Datenbanksysteme)), ((PersNr: 7), (Name: Meier), (ProNr: 2), (Name: Softwareentwicklung)) }<br />
Aufgabe:<br />
Geben Sie eine geeignete Teilmenge dieses kartesischen Produkts an, die die in der Aufgabenstellung gegebene<br />
Situation beschreibt.<br />
Lösungsvorschlag:<br />
Die Relationship bearbeitet kann als Teilmenge des kart. Produktes interpretiert werden: bearbeitet = { ((PersNr:<br />
3), (Name: Müller), (ProNr: 1), (Name: Datenbanksysteme)), ((PersNr: 7), (Name: Meier), (ProNr: 1), (Name:<br />
Datenbanksysteme)), ((PersNr: 7), (Name: Meier), (ProNr: 2), (Name: Softwareentwicklung)) }<br />
6 Funktionalität bei zweistelligen Relationship-Typen<br />
6.1 Funktionalität (Kardinalität) bei 2-stelligen Relationship-Typen<br />
Ein wichtiges Charakteristikum von 2-stelligen Relationship-Typen ist ihre Funktionalität oder Kardinalität. Dadurch<br />
wird zum Ausdruck gebracht, mit wie vielen Entities ein gegebenes Entity in Beziehung stehen kann.<br />
Bemerkung:<br />
Die Funktionalität muss beim Datenbankentwurf durch die Analyse der Rahmenbedingungen erkannt werden.<br />
Man unterscheidet die Funktionalitäten 1:1, n:1, 1:n <strong>und</strong> n:m <strong>und</strong> spricht dementsprechend von<br />
● 1:1 - Relationship-Typen oder 1:1 - Beziehungen<br />
● n:1 - Relationship-Typen oder n:1 - Beziehungen<br />
● 1:n - Relationship-Typen oder 1:n - Beziehungen<br />
● n:m - Relationship-Typen oder n:m - Beziehungen<br />
Beim ER-Modell wird die Funktionalität durch entsprechende Angabe von 1, n oder m an den grau unterlegten Stellen<br />
angegeben.<br />
Das ER-Diagramm ist folgendermaßen zu lesen:<br />
Einem Entity aus E 1 können höchstens y Entities aus E 2 zugeordnet werden bzw.<br />
Einem Entity aus E 2 können höchstens x Entities aus E 1 zugeordnet werden.<br />
x bzw. y wird mit '1' oder mit einem Buchstaben, meistens 'n' oder 'm', belegt. Dabei symbolisiert<br />
● '1' höchstens eine Beziehung <strong>und</strong><br />
●<br />
'n' bzw 'm' beliebig viele, d.h. keine, eine oder mehrere Beziehungen.
Bemerkung:<br />
●<br />
●<br />
●<br />
Ausgehend von der Mengenschreibweise für Relationship-Typen kann man die obige Beziehung auch<br />
folgendermaßen interpretieren:<br />
Der Relationship-Typ R enthält maximal y Tupel mit einem Entity des Entity-Typen E 1 bzw. maximal x Tupel mit<br />
einem Entity des Entity-Typen E 2.<br />
Die Lesart dieser Funktionalitätsdarstellung wird in der Literatur unterschiedlich gehandhabt. Man findet oft auch<br />
die umgekehrte Interpretation:<br />
Einem Entity aus E 1 werden höchstens x Entities aus E 2 zugeordnet bzw. einem Entity aus E 2 werden<br />
höchstens y Entities aus E 1 zugeordnet.<br />
Hier ist auf jeweilige Notation der jeweiligen Autors zu achten.<br />
In der Literatur findet sich auch eine graphische Darstellungsmöglichkeit für Funktionalitäten mit Hilfe von Pfeilen.<br />
6.2 1:1 - Relationship-Typen<br />
Ein 2-stelliger Relationship R zwischen den Entity-Typen E 1 <strong>und</strong> E 2 hat die Funktionalität 1:1, falls ein Entity aus E 1<br />
mit höchstens einem Entity aus E 2 über R in Beziehung stehen kann <strong>und</strong> umgekehrt. R heißt dann 1:1 -<br />
Relationship-Typ.<br />
Definition: 1:1-Funktionalität<br />
Seien E 1 , E 2 Entity-Typen <strong>und</strong> R E 1 x E 2 ein Relationship-Typ. Weiterhin seien x <strong>und</strong> x' Entities von E 1 <strong>und</strong> y <strong>und</strong><br />
y' Entities von E 2. R ist ein 1:1 - Relationship-Typ, falls gilt:<br />
<strong>und</strong><br />
( x, y ) R <strong>und</strong> ( x, y' ) R y = y'<br />
( x, y ) R <strong>und</strong> ( x', y ) R x = x' .<br />
Beispiel: Der Relationship-Typ hat_Klassenleitung_in ist ein 1:1-Relationship-Typ, denn jede Klasse hat genau<br />
eine Lehrkraft als Klassenleitung <strong>und</strong> jede Lehrkraft hat höchstens eine Klassenleitung.<br />
Bemerkung:<br />
Als alternative graphische Darstellung der 1:1 Funktionalität findet man auch folgende Pfeildarstellung:<br />
6.3 n:1 - Relationship-Typen<br />
Ein 2-stelliger Relationship R zwischen den Entity-Typen E 1 <strong>und</strong> E 2 hat die Funktionalität 1:n, falls ein Entity aus E 1<br />
mit höchstens einem Entity aus E 2 , aber ein Entity aus E 2 mit beliebig vielen Entities aus E 1 über R in Beziehung
stehen kann. R heißt dann n:1 - Relationship-Typ.<br />
Definition: n:1-Funktionalität<br />
Seien E 1 , E 2 Entity-Typen <strong>und</strong> R E 1 x E 2 ein Relationship-Typ. Weiterhin seien x ein Entity von E 1 <strong>und</strong> y <strong>und</strong> y'<br />
Entities von E 2.R ist ein n:1 - Relationship-Typ, falls gilt:<br />
( x, y ) R <strong>und</strong> ( x, y' ) R y = y'<br />
Beispiel: Der Relationship-Typ gehoert_zu ist ein n:1-Relationship-Typ, d.h. gehoert_zu hat die Funktionalität n:1.<br />
Ein Schüler gehört zu genau einer Klasse, zu einer Klasse gehören aber mehrere Schüler.<br />
Bemerkung:<br />
Als alternative graphische Darstellung der n:1 Funktionalität findet man auch folgende Pfeildarstellung:<br />
6.4 1:n - Relationship-Typen<br />
Ein n:1 - Relationship-Typ R zwischen E 1 <strong>und</strong> E 2 ist ein 1:n - Relationship-Typ zwischen E 2 <strong>und</strong> E 1 . Damit gilt<br />
Analoges zum vorherigen Abschnitt.<br />
6.5 n:m - Relationship-Typen<br />
Ein 2-stelliger Relationship R zwischen den Entity-Typen E 1 <strong>und</strong> E 2 hat die Funktionalität n:m, falls ein Entity aus E 1<br />
mit beliebig vielen Entities aus E 2 über R in Beziehung stehen kann <strong>und</strong> umgekehrt. Es gelten also keine<br />
Einschränkungen. R heißt dann n:m - Relationship-Typ.<br />
Beispiel: Der Relationship-Typ hat_Lehrbefaehigung_in ist ein n : m-Relationship-Typ, d.h.<br />
hat_Lehrbefaehigung_in hat die Funktionalität n:m.
Bemerkung:<br />
Graphisch wird die n:m - Funktionalität wie folgt dargestellt:<br />
6.6 Die (min, max) - Notation<br />
Bei der Verwendung der Funktionalität ist für einen Entity-Typen nur die maximale Anzahl der Beziehungen mit einem<br />
Relationship-Typen relevant. Falls diese Anzahl größer als eins ist, wird sie, ohne genauere Aussagen zu machen, als n<br />
oder m (d.h. beliebig viele) gesetzt.<br />
Die (min, max) - Notation erlaubt die Festlegung präziser Unter- <strong>und</strong> Obergrenzen. Damit kann also - im Gegensatz<br />
zur 1:1, 1:n oder n:m - Notation - auch die minimale Anzahl der Beziehungen festgelegt werden. Dazu wird für jeden an<br />
der Relationship-Typ R beteiligten Entity-Typ E i ein Zahlenpaar (min, max) angegeben.<br />
Damit wird ausgedrückt, dass jedes Entity von E i mindestens min-mal <strong>und</strong> höchstens max-mal in der Beziehung R steht.<br />
Im ER-Modell wird die (min, max) - Notation folgendermaßen verwendet:<br />
Bemerkung:<br />
● Beachten Sie beim ER-Modell die unterschiedliche Platzierung der Funktionalitätsangaben in der x:y-Notation <strong>und</strong><br />
der (min, max) - Notation.<br />
●<br />
●<br />
Oft kann die Obergrenze nicht festgelegt werden. In diesem Fall ersetzt man max durch einen Stern.<br />
Ein Relationship-Typ R kann als Menge von Tupeln aufgefasst werden, die aus den Entities der beteiligten Tupel<br />
aufgebaut werden. Die Markierung (min, max) bei einem Entity-Typen E gibt an, dass es mindestens min <strong>und</strong><br />
höchstens max Tupel mit einem Entity von E gibt.<br />
Beispiel: Ein Fach (Wahl- oder Pflichtfach) hat 0 bis 2 Fachbetreuer. Theoretisch darf eine Lehrkraft beliebig viele<br />
Fachbetreuungen übernehmen. (Natürlich muss der Fachbetreuer immer die entsprechende Lehrbefähigung besitzen.)<br />
Diese Situation kann im ER-Modell mit Hilfe der (min, max)-Notation folgendermaßen dargestellt werden:
(Aus Übersichtlichkeitsgründen wird bei den Entity-Typen jeweils nur ein Attribut verwendet.)<br />
Betrachtet man die Situation aus der Sicht der Mengenschreibweise für Relationship-Typen, so lässt sich die<br />
angegebene (min, max) - Funktionalität folgendermaßen interpretieren:<br />
Der Relationship-Typ hat_Fachbetreuung_in enthält Tupel, deren erste Komponente die Personalnummer der<br />
Lehrkraft <strong>und</strong> deren zweite Komponente den Fachnamen enthält. Wegen (0,2) darf es maximal zwei Tupel mit<br />
gleichem Fachnamen geben, wegen (0,*) aber beliebig viele Tupel mit gleichem Personalnummerwert.<br />
Ohne Verwendung der (min,max)-Notation wäre die Funktionalität weniger aussagekräftig:<br />
6.7 Übungen<br />
Aufgabe:<br />
Geben Sie die Funktionalität folgender Relationship-Typen an:<br />
1. Mitarbeiter gehoert_zu Abteilung<br />
2. Mitarbeiter arbeitet_in Projekt<br />
3. Mitarbeiter ist_Abteilungsleiter_von Abteilung<br />
Lösungsvorschlag:<br />
1.<br />
2.<br />
3.<br />
Aufgabe:<br />
n:1, denn ein Mitarbeiter gehört zu höchstens einer Abteilung, zu einer Abteilung gehören aber mehrere<br />
Mitarbeiter.<br />
n:m, denn Mitarbeiter können in mehreren Projekten gleichzeitig arbeiten, ein Projekt wird in der Regel von mehr<br />
als einem Mitarbeiter durchgeführt.<br />
1:1, denn eine Abteilung hat genau eine Abteilungsleiterin bzw. einen Abteilungsleiter<br />
Eine Schülerin hat viele CDs, die sie auch an Fre<strong>und</strong>e ausleiht. Damit sie immer weiß, wem sie welchen Tonträger<br />
gegeben hat, möchte sie ein Datenbanksystem einsetzen.<br />
Geben Sie möglich Entity- <strong>und</strong> Relationship-Typen an.<br />
Lösungsvorschlag:<br />
●<br />
●<br />
Aufgabe:<br />
Entity-Typ: CD, Fre<strong>und</strong><br />
Relationship-Typ: ausgeliehen_an
Geben Sie die Funktionalität (x:y-Notation) für die in der vorherigen Aufgabe gewählten Relationship-Typen an?<br />
Lösungsvorschlag:<br />
ausgeliehen_an: n:1, denn ein Tonträger kann nur einmal ausgeliehen werden, ein Fre<strong>und</strong> kann aber mehrere CDs<br />
gleichzeitig ausleihen.<br />
Aufgabe:<br />
Zeichnen Sie ein entsprechendes ER-Diagramm! (Attribute können vernachlässigt werden.)<br />
Lösungsvorschlag:<br />
Aufgabe:<br />
Flüsse können in einem Meer münden. Erstellen Sie ein ER-Modell <strong>und</strong> geben Sie die Funktionalität in (x:y) <strong>und</strong> (min,<br />
max)-Notation an.<br />
Lösungsvorschlag:<br />
Es gilt: Ein Fluss mündet maximal in ein Meer. In ein Meer mündet mindestens ein Fluss, in der Regel aber mehrere<br />
Flüsse.<br />
Angabe der Funktionalität<br />
Angabe der (min, max) - Notation<br />
7 Mehrstellige Relationship-Typen<br />
7.1 Mehrstellige Relationship-Typen<br />
Ein Relationship-Typ R ist eine Teilmenge des kartesisches Produkts der beteiligten Entity-Typen. Sind am<br />
Relationship-Typ mehr als zwei Entity-Typen beteiligt, spricht man von mehrstelligen Relationship-Typen. Für einen<br />
n-stelligen Relationship-Typ gilt:<br />
R E 1 x ... x E n<br />
Bemerkung:<br />
Dreistellige Relationship-Typen kommen bei ER-Modellierungen noch häufig vor, höherstellige Beziehungen findet man<br />
dagegen selten.
Beispiel: Im Schulverwaltungsbeispiel gibt es den dreistelligen Relationship-Typ ist_Fachlehrkraft_von. Dadurch<br />
wird eine Beziehung zwischen den Entity-Typen Lehrkraft, Fach <strong>und</strong> Klasse modelliert. Das ER-Modell hat folgende<br />
Gestalt:<br />
Es gilt: ist_Fachlehrkraft_von Lehrkraft x Klasse x Fach.<br />
Unter Beteiligung der Entities<br />
●<br />
●<br />
●<br />
((PersNr: 35), (Name: Rinser), (Geschlecht: w), (Wohnort: Passau), (Geburtsjahr: 1946)) Lehrkraft ,<br />
((Name: 5), (Klassenzimmer: 101)) Klasse <strong>und</strong><br />
((Name: Deutsch), (Pflichtfach: ja)) Fach<br />
gibt es die Relationship<br />
((PersNr: 35), (Name: Rinser), (Geschlecht: w), (Wohnort: Passau), (Geburtsjahr: 1946), (Name: 5),<br />
(Klassenzimmer: 101),(Name: Deutsch), (Pflichtfach: ja)) ist_Fachlehrkraft_von.<br />
Dadurch wird ausgedrückt, dass Frau Rinser die Klasse 5 im Fach Deutsch unterrichtet.<br />
7.2 Funktionalitäten für mehrstellige Relationship-Typen<br />
Die Begriff der Funktionalität kann auch auf mehrstellige Beziehungen R E 1 x ... x E n übertragen <strong>und</strong> erweitert<br />
werden. Bei mehrstelligen Relationship-Typen wird damit zum Ausdruck gebracht, mit wie vielen Entities e i des<br />
Entity-Typen E i das Entity-Tupel (e 1 , ..., e i - 1 , e i + 1 , ..., e n ) mit e 1 E 1 , ...,e n E n in Beziehung steht. Der<br />
Relationship-Typ wird im ER-Modell wieder entsprechend annotiert. Der Wert "1" symbolisiert wieder höchstens eine<br />
Zuordnung <strong>und</strong> ein Buchstabe beliebig viele Zuordnungen.<br />
Für den dreistelligen Relationship-Typen R E 1 x E 2 x E 3<br />
bedeutet dies konkret:<br />
● Einem Tupel (e 1 , e 2 ) mit e 1 aus E 1 <strong>und</strong> e 2 aus E 2 werden höchstens z Entities e 3 aus E 3 zugeordnet.<br />
● Einem Tupel (e 1 , e 3 ) mit e 1 aus E 1 <strong>und</strong> e 3 aus E 3 werden höchstens y Entities e 2 aus E 2 zugeordnet.<br />
● Einem Tupel (e 2 , e 3 ) mit e 2 aus E 3 <strong>und</strong> e 3 aus E 3 werden höchstens x Entities e 1 aus E 1 zugeordnet.<br />
R hat damit die Funktionalität x:y:z<br />
Beispiel: Die Relationship hat_Lehrbefaehigung_in hat die Funktionalität 1:n:m.
Die Funktionalität wird folgendermaßen interpretiert:<br />
●<br />
●<br />
●<br />
Zu einer Klasse <strong>und</strong> einem Fach kann es höchstens eine Lehrkraft geben, d.h. innerhalb einer Klasse dürfen<br />
nicht mehrere Lehrkräfte dasselbe Fach unterrichten.<br />
Zu einer Klasse <strong>und</strong> einer Lehrkraft kann es mehrere Fächer geben, d.h. eine Lehrkraft kann eine Klasse<br />
durchaus mehr als einem Fach unterrichten.<br />
Zu einer Lehrkraft <strong>und</strong> einem Fach kann es mehrere Klassen geben, d.h. eine Lehrkraft darf dasselbe Fach in<br />
unterschiedlichen Klassen unterrichten.<br />
Bemerkung:<br />
Auch bei mehrstelligen Relationship-Typen kann die (min, max) - Notation verwendet werden. Analog zur (min, max) -<br />
Notation bei zweistelligen Relationship-Typen gibt auch hier min die minimale Anzahl <strong>und</strong> min die maximale Anzahl der<br />
Beziehungen eines Entity-Typs an.<br />
7.3 Übungen<br />
Aufgabe:<br />
Interpretieren Sie folgendes ER-Diagramm:<br />
Lösungsvorschlag:<br />
Professoren betreuen Studenten bei Seminarthemen <strong>und</strong> geben ihnen auf die Seminararbeit eine Note. Dabei gilt:<br />
● Zu einem Studenten <strong>und</strong> einem Seminarthema darf es nur eine betreuende Professorin bzw. einen betreuenden<br />
Professor geben. d.h. ein Student darf dasselbe Seminarthema nicht mehrfach bearbeiten.<br />
● Zu einem Thema <strong>und</strong> einem Professor bzw. einer Professorin darf es mehrere Studenten geben, d.h. dasselbe<br />
Seminarthema darf von einer Professorin bzw. einem Professor an mehrere (unterschiedliche) Studenten<br />
ausgegeben werden.<br />
● Zu einem Studenten <strong>und</strong> einem Professor darf es nur ein Seminarthema geben, d.h. Studenten dürfen bei einer<br />
Professorin bzw. einem Professor nur ein Seminarthema ableisten.<br />
Aufgabe:<br />
Interpretieren Sie die Funktionalität des folgenden ER-Diagramms:<br />
Lösungsvorschlag:<br />
In R<br />
●<br />
●<br />
muss jedes Entity aus A in genau einem Tupel vertreten sein;<br />
darf ein Entity aus B höchstens zweimal in einem Tupel vertreten sein;
●<br />
muss jedes Entity aus C mindestens in einem Tupel vorkommen.<br />
8 Generalisierung <strong>und</strong> Spezialisierung<br />
8.1 Generalisierung<br />
Das Prinzip der Generalisierung wird eingesetzt, um eine übersichtlichere <strong>und</strong> natürlichere Strukturierung der<br />
Entity-Typen zu erzielen. Dabei werden gemeinsame Eigenschaften, also Attribute <strong>und</strong> Beziehungen, ähnlicher<br />
Entity-Typen "herausfaktorisiert" <strong>und</strong> einem gemeinsamen Obertyp zugeordnet. Die beteiligten Entity-Typen sind dann<br />
Untertypen des jeweiligen Obertyps. Eigenschaften, die nicht allen Untertypen gemeinsam sind, bleiben beim<br />
entsprechenden Untertyp.<br />
Da jedes Element eines Untertyps auch Element aller Obertypen ist, hat es auch alle Beschreibungsmerkmale der<br />
Obertypen. Es "erbt" damit sämtliche Eigenschaften des Obertypen.<br />
Beispiel: Die Lehrkräfte einer Schule werden durch den Entity-Typ Lehrkraft , die übrigen Angestellten (Sekretärin,<br />
Hausmeister, ...) durch den Entity-Typ Personal repräsentiert.<br />
Als Obertyp ist der Entity-Typ Bedienstete möglich, der die gemeinsamen Attribute aufnimmt.<br />
Die Beziehung von Unter- <strong>und</strong> Obertyp wird durch den speziellen Relationship-Typ isa ausgedrückt. Im ER-Modell wird<br />
diese Beziehung durch eine Raute mit der Beschriftung isa repräsentiert.<br />
Beispiel: Im obigen Beispiel gilt: Lehrkraft isa Bedienstete bzw. Personal isa Bedienstete.
8.2 Spezialisierung<br />
Die Spezialisierung ist die inverse Operation zur Generalisierung<br />
Beispiel: Lehrkraft <strong>und</strong> Personal sind Spezialisierungen von Bedienstete.<br />
8.3 Die isa-Beziehung<br />
Die isa - Beziehung beschreibt sowohl Generalisierung als auch Spezialisierung.<br />
Definition: Generalisierung <strong>und</strong> Spezialisierung<br />
Seien A <strong>und</strong> B Entity-Typen.<br />
A isa B : B ist eine Generalisierung von A oder A ist eine Spezialisierung von B.<br />
Fur die Beziehung A isa B gilt:<br />
● A erbt die Attribute von B. A kann darüberhinaus zusätzliche Attribute besitzen.<br />
● Zu jedem a A gehört genau ein b B, so dass a <strong>und</strong> b das gleiche Entity repräsentieren. Insbesondere hat a<br />
also für die ererbten Attribute dieselben Werte wie das korrespondierende Entity b.<br />
● Kein b B kann zu zwei verschiedenen Elementen von A gehören. Es kann aber b B geben, die zu keinem a<br />
A gehören.<br />
● Die Schlüsselkandidaten von A sind diejenigen von B. Die Schlüsselattributwerte des Entity a A sind diejenigen<br />
des korrespondierenden Entity b B. Folglich hat A den gleichen Primärschlüssel wie B.<br />
8.4 Übungen<br />
Aufgabe:
Wie könnte ein Generalisierung der Entity-Typen PKW (Attribute: Farbe, PS), Motorrad (PS, Farbe), LKW (Farbe,<br />
Nutzlast, PS), Motorboot (PS, Länge) aussehen.<br />
Lösungsvorschlag:<br />
Eine Lösungsmöglichkeit von vielen ist:<br />
Als Primärschlüssel wurde der (künstliche) Schlüssel Fahrzeugnummer eingeführt.<br />
Die Hierarchiestruktur hängt natürlich von den vorgegebenen Daten ab. Müssen beispielsweise Fahrzeuge ohne Motor,<br />
d.h. ohne PS-Angabe, "eingebaut" werden, so ist zu überlegen, ob man das Attribut PS wirklich dem Obertyp Fahrzeug<br />
zuordnet.<br />
9 Schwache Entity-Typen<br />
In den meisten Fällen sind Entities autonom <strong>und</strong> innerhalb ihrer Entitymenge über die Schlüsselattribute eindeutig<br />
identifizierbar.<br />
9.1 Existenzabhängigkeit<br />
Bei der Modellierung einer Miniwelt ergeben sich oft Entity-Typen, die von einem anderen Entity-Typ abhängig sind.<br />
Solche Entity-Typen heißen existenzabhängig.<br />
Definition: Existenzabhängigkeit<br />
Ein Entity-Typ E 1 heißt existenzabhängig von dem Entity-Typ E 2 (über R), falls es einen n:1 - Relationship-Typ R mit R<br />
E 1 x E 2 gibt, so dass e 1 E 1 nur dann existieren kann, wenn es ein e 2 E 2 gibt, so dass (e 1 , e 2 ) R gilt, d.h. e<br />
1 über R mit e 2 in Beziehung steht.<br />
In diesem Fall heißt<br />
● E 2 dominant <strong>und</strong><br />
●<br />
E 1 untergeordnet unter E 2 (durch R)<br />
Die Definition sagt folglich aus, dass das Entity e 1 in E 1 nur vorkommen kann, falls ein entsprechendes e 2 in E 2<br />
existiert.<br />
Beispiel: Mit Hilfe der Schulverwaltung sollen Räume verwaltet werden. Die Schule besteht aus drei Gebäuden.<br />
Gebäude <strong>und</strong> Räume tragen jeweils eine Nummer. Als Entity-Typen bieten sich Raum <strong>und</strong> Gebäude an, die über den<br />
Relationship-Typ liegt_in miteinander in Beziehung stehen. Raum ist ein existenzabhängiger Entity-Typ, da die<br />
Existenz eines Raumes von der Existenz des Gebäudes abhängig ist.<br />
Gebäude ist in diesem Fall dominant, der Entity-Typ Raum dementsprechend untergeordnet unter Gebäude durch
liegt_in.<br />
9.2 Schwache Entity-Typen<br />
Bei existenzabhängigen Entity-Typen kann es vorkommen, dass die Entities nur in Kombination mit dem Schlüssel des<br />
dominanten Entity-Types identifizierbar sind. Man spricht von schwachen Entity-Typen.<br />
Beispiel: Haben die Räume einer Schule mit drei Gebäuden eine eindeutige Raumnummer, so sind diese Räume auch<br />
ohne Angabe des entsprechenden Gebäudes eindeutig identifizierbar. Es wäre aber auch vorstellbar, dass die Räume<br />
eines Gebäudes von eins beginnend durchnummeriert sind. Dann müsste zur eindeutigen Identifizierung eines Raumes<br />
neben der Raumnummer auch das entsprechende Gebäude angegeben werden.<br />
Definition: Schwacher Entity-Typ<br />
Ein existenzabhängiger Entity-Typ E ist ein schwacher Entity-Typ, falls die Menge seiner Attribute keinen<br />
Superschlüssel bildet. Sonst heißt E auch starker Entity-Typ.<br />
Beispiel: Sind die Räume der drei Schulgebäude jeweils von eins beginnend durchnummeriert, so existieren<br />
beispielsweise drei Räume mit der Raumnummer 1. Raum ist in diesem Fall ein schwacher Entity-Typ, da die eindeutige<br />
Identifizierung eines Raumes nur unter zusätzlicher Angabe der Gebäudenummer möglich.<br />
9.3 Diskriminator <strong>und</strong> Schlüssel schwacher Entity-Typen<br />
Ein schwacher Entity-Typ hat keine eigenständigen Schlüsselkandidaten, durch die alle Entities dieses Entity-Typs<br />
eindeutig identifiziert werden könnten. Es gibt aber eine minimale Menge von Attributen, durch die Entities, die einem<br />
übergeordneten Entity zugeordnet sind, innerhalb des schwachen Entity-Typs voneinander unterscheidbar sind. Diese<br />
Attributmenge heißt Diskriminator.<br />
Definition: Diskriminator<br />
Sei der Entity-Typ E 1 dem Entity-Typ E 2 untergeordnet durch R. Ein Diskriminator von E 1 ist eine minimale Menge<br />
von Attributen von E 1 , deren Wertekombination für jedes Entity e 1 E 1 eine Unterscheidung unter den Elementen der<br />
Menge { e 1 E 1 | (e 1 , e 2) R } ermöglicht.<br />
Beispiel: Wir gehen wieder davon aus, dass die Räumzählung innerhalb der drei Schulgebäude bei eins beginnt. Das<br />
Attribut RaumNr ist der Diskriminator für den schwachen Entity-Typ Raum. Es kann zwar innerhalb des Entity-Typs Raum<br />
zwei Entities mit gleicher Raumnummer geben, diese sind aber dann verschiedenen Gebäuden zugeordnet.<br />
Für die Schlüsselkandidaten eines schwachen Entity-Typs gilt:<br />
Sei der Entity-Typ E 1 dem Entity-Typ E 2 untergeordnet. Sei K ein Schlüsselkandidat von E 2 <strong>und</strong> sei D ein Diskriminator<br />
von E 1 . Dann ist K D ein Schlüsselkandidat von E 1 .<br />
Bemerkung:<br />
Der Primärschlüssel eines schwachen Entity-Typs E wird aus dem Primärschlüssel des zugehörigen dominanten<br />
Entity-Typs zusammen mit einem ausgewählten Diskriminator von E gebildet.<br />
Beispiel: Einziger Schlüsselkandidat <strong>und</strong> damit gleichzeitig Primärschlüssel des Entity-Typen Raum ist {GebNr,<br />
RaumNr}<br />
9.4 Darstellung im ER-Modell<br />
Im ER-Modell werden existenzabhängige <strong>und</strong> schwache Entity-Typen durch doppelt umrandete Rechtecke<br />
repräsentiert. Sehr oft wird auch die Beziehung zum dominanten Entity-Typ doppelt umrandet. Der Diskriminator wird<br />
durch eine gestrichelte Unterstreichung gekennzeichnet.<br />
Beispiel: Das ER-Modell für obiges Beispiel hat folgendes Aussehen:
9.5 Mehrfache Abhängigkeiten<br />
Schwache Entity-Typen <strong>und</strong> ihre Unterordnung unter einen dominanten Entity-Typ müssen je nach Anwendungsbereich<br />
möglicherweise über mehrere Beziehungen hinweg iteriert werden. Ein dominanter Entity-Typ kann gleichzeitig wieder<br />
einem anderen Entity-Typen untergeordnet sein. Wichtig ist, dass diese Abhängigkeitskette in einem starken Entity-Typ<br />
endet.<br />
Beispiel: Eine Stadt verwaltet die Gebäude ihrer Schulen zentral.<br />
In diesem Fall gilt:<br />
● Der Entity-Typ Raum ist dem Entity-Typ Gebäude untergeordnet, dieser wiederum dem Entity-Typ Schule.<br />
● Der hier vorliegende Schlüsselkandidat für den Entity-Typ Raum (aus dem Anwendungsbereich der Stadt) ist<br />
{RaumNr, GebNr, SchulNr}. (Aus dem Blickwinkel der Schule ist aber der Schlüsselkandidat {RaumNr, GebNr}<br />
ausreichend!)<br />
9.6 Übungen<br />
Aufgabe:<br />
Finden Sie Beispiele für Beziehungen mit schwachen Entity-Typen.<br />
Lösungsvorschlag:<br />
●<br />
●<br />
Aufgabe:<br />
Schüler - Prüfung<br />
Konto - Überweisung<br />
Modellieren Sie die Situation "Einwohner (AusweisNr, Name, Vorname) sind Staatsbürger eines Landes (Name,<br />
Einwohnerzahl)".<br />
Lösungsvorschlag:
10 Der Entwurf eines ER-Modells<br />
In diesem Abschnitt wird zusammenfassend das Vorgehen beim Entwurf eines ER-Modells beschrieben.<br />
10.1 Vorschlag für die Vorgehensweise<br />
Ausgangspunkt ist die Miniwelt, für die eine Datenbank entwickelt werden soll, <strong>und</strong> eventuell ein Anforderungsprofil.<br />
Folgende Schritte führen zum ER-Modell:<br />
1. Festlegung der Entity- <strong>und</strong> Relationship-Typen<br />
2. Angabe der Attribute, die die Entity- <strong>und</strong> Relationship-Typen eindeutig charakterisieren, bzw. die laut Anforderung<br />
notwendig sind<br />
3. evtl. Einführung einer Generalisierungs-Hierarchie<br />
4. Festlegung der Primärschlüssel der Entity-Typen<br />
5. Angabe der Funktionalitäten<br />
6. evtl. Festlegung der Domänen<br />
Bemerkung:<br />
● Bei großen Projekten werden zuerst ER-Modelle für die einzelnen Views entworfen, die dann in einem zweiten<br />
Schritt in ein Gesamtmodell zusammengefasst werden.<br />
● Die Reihenfolge der Schritte 2 - 6 ist nicht bindend.<br />
● Oft gibt es bei der Erstellung eines ER-Modells mehrere gleichwertige Lösungen.<br />
10.2 Übungen<br />
Aufgabe:<br />
Erstellen Sie auf der Gr<strong>und</strong>lage der vorgegebenen Ausgangssituation ein ER-Modell der Schulverwaltung.<br />
Lösungsvorschlag:<br />
Das folgende ER-Modell stellt einen Lösungsvorschlag dar. Es dient als Gr<strong>und</strong>lage für die weiteren Betrachtungen!