Das Entity-Relationship-Modell
Prof. Dr. T. Kudraß
1
Datenmodelle
• Datenmodell
– System von Konzepten zur abstrakten Darstellung eines Ausschnitts
der realen Welt mittels Daten
– Verschiedene Abstraktionsebenen
– Bestehen aus:
 Strukturen (statische Eigenschaften)
 Operatoren (dynamische Eigenschaften)
 Constraints (Korrektheitsbedingungen)
– Werte ohne Struktur sind sinnlos
91
19
5
Beispiel: 301
Prof. Dr. T. Kudraß
302
303
304
91
91
91
18
22
12
Tag
301
302
303
304
Jahr
91
91
91
91
Tmax
19
18
22
12
2
9
-3
Tmin
5
2
9
-3
2
Datenmodelle (Forts.)
Operatoren erlauben Zugriff, Speicherung, Änderung von Werten, z.B.
Insert 305 91 -6 11
Constraints garantieren die syntaktische und semantische Korrektheit
einer Operation (und dadurch die Konsistenz eines Datenbankzustandes)
Beispiel:
Tmax > Tmin macht obige Operation ungültig
Oft sind Konsistenzregeln in den Strukturen inhärent (für den Benutzer
intuitiv), müssen aber für das DBMS explizit dargestellt werden.
Prof. Dr. T. Kudraß
3
Konzeptueller DB-Entwurf
• Konzeptueller Entwurf
– Entity-Relationship-Modell ist traditioneller Ansatz
– Was sind die Entitäten und die Beziehungen im gewählten
Weltausschnitt?
– Welche Information über diese Entitäten und Beziehungen
sollen in der DB gespeichert werden
(Informationsbedarfsanalyse)?
– Was sind die Integritätsbedingungen (oder Business Rules),
die gelten müssen?
– Ein DB-Schema kann graphisch im ER-Modell repräsentiert
werden (ER-Diagramm)
– Ein ER-Diagramm läßt sich in ein relationales Schema
übersetzen (logischer DB-Entwurf)
Prof. Dr. T. Kudraß
4
Logischer Datenbankentwurf (Phasen)
Verständnis des Datenbank-Entwurfs auch nützlich für den
Datenbank-Anwender
• Anforderungs-Analyse
– Welche Daten?
– Welche (häufigen) Operationen?
– Welche Anwendungen?
• Konzeptueller DB-Entwurf
– Spezifikation der gesammelten Anforderungen in einer high-levelDarstellung (z.B. ER-Modell)
• Logischer DB-Entwurf
– Übersetzung des konzeptuellen DB-Entwurfs in ein Schema im
Datenmodell des Ziel-DBMS (zumeist relationales DBMS)
Prof. Dr. T. Kudraß
5
Physischer DB-Entwurfs (Phasen)
Verständnis wichtig für den Programmierer / DatenbankAdministrator
• Schema-Verfeinerung
– Normalisierung des relationalen Schemas soweit erforderlich
(Nutzung Normalformen-Theorie)
• Physischer DB-Entwurf
– Phys. Entwurfsentscheidungen (Index, Clusters) entsprechend LastProfilen und Performance-Anforderungen
• Security-Entwurf
– Definition von Benutzergruppen, Rollen, Zugriffsrechten
Prof. Dr. T. Kudraß
6
Konzept 1: Entity-Menge
• Entity: “A thing that has a real or individual existence in reality or in mind“
(Webster)
• Entity ist von anderen Objekten unterscheidbar, wird beschrieben durch
eine Menge von Attributen (in DB)
• Entity-Menge: Zusammenfassung aller Entities mit gemeinsamen
Eigenschaften
Elemente einer Menge e i E
z.B. Personen, Bücher, Projekte, Kunden, Wein
• Zugehörigkeit über Prädikat entscheidbar
ei i
Ej 3
is Ej(ei)
• DB enthält endlich viele Entity-Mengen
E1 , E2 , E 3
z.B. E1 ... Personen
E2 ... Kunden
E 2  E1
Angestellter
Prof. Dr. T. Kudraß
7
Konzept 2: Relationship-Menge
• Relationship: Beziehung zwischen zwei oder mehreren Entities,
z.B. “John arbeitet in der Vertriebsabteilung“
• Zusammenfassung von gleichartigen Beziehungen
(Relationships) zwischen Entities, die jeweils gleichen EntityMengen angehören, z.B. ist Hörer von zwischen Student und
Vorlesung
• R ... Relationship-Menge = math. Relation zwischen
n Ei

R  E1 D E2 ... D En
d.h. R = {r = [e1, e2 ... en ] s e1 i E1 ... en i En }
gewöhnlich n=2 oder n=3
Keine Disjunktheit der Entity-Mengen, die an einer Ri beteiligt sind,
gefordert (d.h. dieselbe Entity-Menge nimmt in verschiedenen Rollen
teil)
z.B. HEIRAT: PERSON (MANN), PERSON (FRAU)
Angestellter
Prof. Dr. T. Kudraß
Arbeitet
Abteilung
8
Konzept 3: Wertemengen
• Information über ei oder ri wird ausgedrückt durch Attribut-WertPaare
• Wertemengen Wi (Domains) bestimmen Zulässigkeit konkreter
Werte für ei und ri
• Definition durch Aufzählung, Prädikate
– Beispiele:
NUMMER = neunstellige natürliche Zahl
QUALITÄT = {1,2,3,4,5}
NACHNAME = Menge der max. 35 langen Zeichenfolgen über
Alphabet
Prof. Dr. T. Kudraß
9
Konzept 4: Attribute
• Attribut A zu einer Entity-Menge E oder Relationship-Menge R
• Mathematische Funktion
A: E  W bzw. W1 D W2 ... D Wk
oder
A: R  W bzw. W1 D W2 ... D Wm
Darstellung als Oval
name
• Einfache vs. Zusammengesetzte Attribute
– KDNR
– NAME
– ANSCHRIFT
stadt
adr

strasse
• Einwertige (single-valued) vs. Mehrwertige (multi-valued) Attribute
– FARBE
– KINDER
name
• Nullwerte: Attributwert nicht möglich bzw. unbekannt A(e) ={}, z.B.
private Tel.-Nr.
• Wertemengen Wi nicht notwendig verschieden
• Relationship-Mengen können auch Attribute besitzen, z.B. DATUM einer
HEIRAT
Prof. Dr. T. Kudraß
10
Konzept 5: Schlüssel
• Information über ein Entity ausschließlich über Attribut-Werte
• Identifikation eines Entities durch Attribut (oder Kombination von
Attributen)
• { A1, A2 ... Am } = A sei Menge der Attribute zur EntityMenge E
R = {r = [e1, e2 ... en ] s e1 i E1 ... en i
K  A ist Schlüsselkandidat von E
ei,  ek  K(ei)  K(ek), (Eindeutigkeitseigenschaft)
K sollte minimal sein
En }
• Mehrere Schlüsselkandidaten möglich
z.B. Personalausweis-Nr. oder Sozialversicherungs Nr. für Angestellte
Attributname
unterstrichen
1
Auswahl eines
Primärschlüssels
pnr
Prof. Dr. T. Kudraß
11
Beziehungsarten
• 1:1-Beziehung
Jedes Element von A steht mit genau einem Element von B in
Beziehung.
Beispiele:
Konto - Kontonummer (zu jedem Konto eine Nr.)
Person - Name (eine Person hat einen eindeutigen Namen)
• 1:n-Beziehung
Jedes Element von A steht mit mehreren Elementen (n) von B in
Beziehung. Die Anzahl n kann auch 0 sein.
Beispiele:
Lieferant - Produkt (ein Lieferant liefert n Produkte)
Angestellter - Wohnsitz (ein Angestellter hat mehrere Wohnsitze)
• m:n-Beziehung
Mehrere Elemente von (m) A stehen mit mehreren Elementen (n)
von B in Beziehung. Die Beziehungen müssen nicht total sein,
d.h. m oder n kann 0 sein.
Beispiele:
Angestellter - Projekt (ein Angestellter in mehreren Projekten; an
einem Projekt sind mehrere Angestellte beteiligt)
Prof. Dr. T. Kudraß
12
Beispiele (1)
seit
name
aname
gehalt
pnr
Manager
leitet
1
seit
gehalt
budget
arbeitet
n
1
seit
name
gehalt
m
Abteilung
pname
dauer
pnr
arbeitet
Angestellter
Prof. Dr. T. Kudraß
aname
anr
Angestellter
pnr
Abteilung
1
name
pnr
budget
anr
n
Projekt
13
Beispiele (2)
Ehefrau
Person
1
1
verheiratet
n
rapportiert
n
zusammengesetzt
Ehemann
vorgesetzt
Angestellter
1
untergeordnet
oberes Teil
Teil
m
unteres Teil
Zwischen den gleichen Entity-Mengen können jeweils unterschiedliche Relationship-Mengen definiert werden.
arbeitet
m
n
Angestellter
Projekt
1
Prof. Dr. T. Kudraß
leitet
n
14
Kardinalität von Beziehungen
leitet / wird_geleitet
Abteilung
Manager
1:1
arbeitet mit / für
Manager
Mitarbeiter
1:n
arbeitet an / bearbeitet von
Projekt
Mitarbeiter
Prof. Dr. T. Kudraß
m:n
15
Integritätsbedingungen in Relationships
• Verfeinerung der Semantik einer Beziehung
Sei R  E1 D E2 ... D En
card(R, Ei) = (min,max) bedeutet, daß jedes Element aus Ei in wenigstens min
und höchstens max Ausprägungen von R enthalten sein muß (mit 0  min 
max, max  1)
• Graphische Darstellung
E1
(min1,max1)
R
(min2,max2)
E2
Verfeinerung der Semantik einer Beziehung
e1 nimmt an (min1,max1) Beziehungen von Typ R teil
e2 nimmt an (min2,max2) Beziehungen von Typ R teil
Beispiel
Angestellter
(0,1)
(1,1)
Prof. Dr. T. Kudraß
(1,*)
leitet
arbeitet_in
Abteilung
(1,*)
16
Komplexität binärer Relationships
Kompl.
Bemerkung
Beispiel
(1,1)(1,1)
Strenge 1:1-Beziehung, umkehrbar eindeutige
Funktion
Ehe zwischen Ehemännern und Ehefrauen
(1,1)(0,1)
(0,1)(1,1)
Partielle 1:1
Ehe zwischen Ehemännern und Frauen
(0,1)(0,1)
Allgemeine 1:1
Ehe zwischen Männern und Frauen
(1,1)(1,*)
(1,*)(1,1)
Strenge hierarchische Beziehung
Angestellte in einer Abteilung
(1,1)(0,*)
(0,*)(1,1)
Funktionale Abhängigkeit ohne
Existenzbedingung
Beziehung zwischen Männern (potentiellen Vätern) und Kindern
(0,1)(1,*)
(0,1)(0,*)
(1,*)(0,1)
(0,*)(0,1)
Allgemeine hierarch. Beziehung (1:n)
(k,l)(r,s)
Âllgemeine m:n-Beziehung (l,s 1)
Prof. Dr. T. Kudraß
Angestellte arbeiten für Projekte
17
Schwache Entities
• Schwaches Entity (weak entity) kann eindeutig identifiziert
werden nur über den Primärschlüssel einer anderen (Owner)
Entity.
• Owner Entity und Weak Entity müssen in einer 1:n-Beziehung
stehen (ein Owner, mehrere Weak Entities)
name
pnr
Angestellter
Kinder
hat
(0,*)
alter
name
gehalt
(1,1)
Jedes Entity aus Kinder muß an der Beziehung teilnehmen (total
Participation Constraint)
Prof. Dr. T. Kudraß
18
ISA-Beziehung
• Vererbung von Attributen (vgl. OO Sprachen)
• A “is a“ B heißt: Jedes A Entity ist zugleich auch ein B Entity
• Überdeckung: Kann Joe zugleich ein Fest-Angestellter und ein
Contractor sein (erlaubt / nicht erlaubt)?
– disjunkt (d) vs. nicht-disjunkt (n)
• Vollständigkeit: Kann jeder Angestellte in Intern oder Extern klassifiziert
werden (ja/nein)
– total (t) vs. partiell (p)
• Nutzen von ISA:
– Hinzufügen von Attributen spezifisch für einen Subtyp
– Identifizieren von Entities, die an Beziehungen teilnehmen (Generalisierung)
name
pnr
gehalt
Angestellter
stundensatz
stundenzahl
ISA
Interner
Prof. Dr. T. Kudraß
vertrags_nr
Extern
19
Konzeptueller Entwurf im ER-Modell
• Entwurfsentscheidungen
– Sollte ein Konzept als Entity oder Attribut modelliert werden?
– Sollte ein Konzept als Entity oder Relationship modelliert werden?
– Bestimme die Beziehungen: Binär oder ternär?
• Constraints im ER-Modell
– Möglichst viel Datensemantik sollte erfaßt werden
– Einige Constraints können mit den Mitteln des ER nicht ausgedrückt
werden (z.B. Wertabhängigkeiten zwischen Attributen)
Prof. Dr. T. Kudraß
20
Entity vs. Attribut
• Sollte Adresse ein Attribut von Angestellter sein oder ein Entity (in
Beziehung zu Angestellter)
• Abhängig von der Benutzung der Adress-Information und der
Semantik der Daten
– Wenn mehrere Adressen pro Angestellter vorhanden, dann sollte
Adresse ein eigenständiges Entity sein (wenn mengenwertige
Attribute ausgeschlossen sind)
– Wenn die Struktur der Adresse wichtig ist, d.h. Zugriff auf
Bestandteile der Adresse (wie Stadt), dann muß Adresse als
separates Entity modelliert werden (mit atomaren Attributwerten)
stadt
plz
strasse
Adresse
(0,*)
(1,*)
Angestellter
Prof. Dr. T. Kudraß
21
Entity vs. Attribut (Forts.)
von
name
pnr
bis
gehalt
Angestellter
id
name
budget
Abteilung
Arbeitet_in
• So ist es nicht möglich, die Mitarbeit eines Angestellten über
mehrere Zeiträume zu modellieren (ähnlich wie mehrere
Adressen eines Mitarbeiters)  Ersetzen der zeitbezogenen
Attribute (von,bis) durch das neue Entity Dauer
Es entsteht eine ternäre Beziehung
von
Dauer
name
pnr
Angestellter
Prof. Dr. T. Kudraß
bis
gehalt
id
Arbeitet_in
name
budget
Abteilung
22
Ternäre Beziehungen
• Dreistellige (oder höherwertigere) Beziehungen involvieren drei
(oder mehr) Entity-Typen und sind somit noch komplexer als
binäre Beziehungen.
• Ternäre Beziehungen können nicht automatisch in binäre
Beziehungen aufgebrochen werden
name
Professor
titel
isb
n
Buch
empfiehlt
Vorlesung

name
Professor
titel
Vorlesung
Prof. Dr. T. Kudraß
P-V
P-B
V-B
isbn
Buch
23
Konzeptueller Entwurf (Zusammenfassung)
• Konzeptueller Entwurf folgt der Anforderungsanalyse
• Ergebnis: eine “high-level“ Beschreibung der zu speichernden
Daten
• ER-Modell populär für konzeptuellen Entwurf
• Basis-Konstrukte: Entities, Relationships, Attribute (von Entities und
Relationships)
• Zusätzliche Konstrukte: Weak Entities, ISA-Beziehungen
• Constraints (Integritätsbedingungen) im ER:
– Kardinalitätsrestriktionen (1:1, 1:n, m:n)
– Komplexität von Beziehungen in min,max-Notation (Participation
Constraints)
– Überdeckungs-/Vollständigkeits-Constraints in ISA-Hierarchien
– Bestimmen von Constraints wichtig für guten DB-Entwurf
– Einige Constraints (z.B. funktionale Abhängigkeiten) lassen sich im ERModell nicht ausdrücken
• Entwurf ist subjektiv
– Entity vs. Attribut, Entity vs. Relationship, Binär oder Ternär, mit oder
ohne ISA,
Prof. Dr. T. Kudraß
24

Document