Das Entity Realtionship Modell

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