Datenbanken

fbi
h_da
Datenbanken
Kapitel 2: Semantische Datenmodellierung
Schestag
Datenbanken (Bachelor)
Kapitel 2 - 1
fbi
h_da
Semantische Datenmodellierung
Inhalte des Kapitels
• Die Rolle der Datenmodellierung im Lifecycle von Informationssystemen
• Das erweiterte Entity-Relationship Modell (eERM)
• Unterschiedliche Nomenklaturen für ER-Diagramme
Lernziele
• Strategischen Stellenwert der semantischen Datenmodellierung mit Hilfe
von ER-Diagrammen in der Analyse-Phase verstehen
• Analogien und Unterschiede zum OOA-Klassendiagramm kennen
• Sensibilisierung für unterschiedliche Nomenklaturen und die damit
zusammenhängende Änderung der semantischen Aussage
→ Unter Semantik (gr. σημαίνειν sēmainein „bezeichnen“) versteht man die Lehre über die
Bedeutung von Zeichen, also im Speziellen von allen sprachlichen Äußerungen.
Insbesondere in der Analysephase ist es wichtig, bei der Beschreibung der Anforderungen, der
Wahl der Bezeichner etc. vollständige semantische Klarheit zu erreichen!
Schestag
Datenbanken (Bachelor)
Kapitel 2 - 2
Die Rolle der Datenmodellierung …
fbi
h_da
…im Lifecycle von Informationssystemen
•
Vor der Einführung der OOA / OOD, mit UML als standardisierter Beschreibungssprache ab 1997, war die Sicht auf Daten und Prozesse getrennt – auch hinsichtlich
der eingesetzten Methodiken:
Pla
eER-Modell
A na
lyse
ER Diagramme, Chen 1976
Relationenmodell
(für RDBMS, Codd 1970)
SQL (für RDBMS,
Codd 1970)
Des
ign
Imp
lem
Da t
Schestag
ng
nun
u
n
g Pla
ent
en
James Martin, 1982
strukturierte Analyse
de Marco 1979
e
s
y
l
An a
gn
i
s
De
ieru
ng
me
e
l
Imp
ng
u
r
ntie
Pr o
Datenbanken (Bachelor)
strukturierter Entwurf
Constantine, Jackson 1974/75
strukturierte Programmierung
Dijkstra 1970
e
s
s
ze
Kapitel 2 - 3
fbi
h_da
Lifecycle von Informationssystemen
•
Evolutionäre Vorgehensmodelle entsprechen einem zyklischen, iterativen Durchlaufen der einzelnen Phasen Jede Phase liefert Ergebnisse, die als Input für die
darauf folgende Phase Verwendung finden:
Planungsphase
Planungsphase
DerInformationsbedarf
Informationsbedarfder
derzu
zuuntersuchenden
untersuchendenOrganisation
Organisationwird
wirdermittelt
ermitteltund
undeine
eine
Der
Informationsstrategieerarbeitet.
erarbeitet.
Informationsstrategie
Beispiel:CRUD-Matrix
CRUD-Matrix(Create
(Create––Read
Read––Update
Update––Delete)
Delete)
Beispiel:
⇒Ergebnis:
Ergebnis:”Informations-Projekte”
”Informations-Projekte”(=Zusammenfassung
(=Zusammenfassungvon
vonFunktionen,
Funktionen,die
diedie
die
⇒
gleichenInformationsobjekte
Informationsobjekteverwenden)
verwenden)und
und“Funktionsbereiche”
“Funktionsbereiche”sind
sinddefiniert,
definiert,
gleichen
umden
denvorgegebenen
vorgegebenenOrganisationsbereich
Organisationsbereichzu
zustrukturieren.
strukturieren.
um
Schestag
Datenbanken (Bachelor)
Kapitel 2 - 4
fbi
h_da
A
uf
K
un
Planungsphase
de
n
Fu
nk
tio
ne
n
Ausschnitt aus einer
CRUD-Matrix
ve
rw
tr
al
ag
te
n
ab
A
w
uf
ic
tr
ke
ag
ln
a
Li
br
ef
ec
er
hn
an
en
te
B
n
es
ve
te
rw
llu
al
n
B
te
g
es
n
er
te
st
llu
el
le
ng
W
n
ar
ab
en
re
ei
ch
ng
…
ne
an
n
g
üb
er
…
w
a
Lifecycle von Informationssystemen
Entitäten
Kundenaufträge
Kunde
CRUD
Beschaffung
R
R
…
Auftrag
CRUD
R
…
Auftragsposition
CRUD
R
…
CRU
…
CRUD
…
Kundenrechnung
Kundenrechnungsposition
R
R
R
R
…
R
R
R
…
L-Bestellung
CRUD
R
R
…
L-Bestellungsposition
CRUD
R
R
…
Artikel
R
CRUD
Lieferant
L-Rechnung
L-Rechnungsposition
CRU
…
CRUD
…
Wareneingangbuch
…
Schestag
…
…
…
Datenbanken (Bachelor)
…
…
…
…
CRU
…
…
…
Kapitel 2 - 5
fbi
h_da
Lifecycle von Informationssystemen
Analysephase
Analysephase
Die“Informations-Projekte”
“Informations-Projekte”aus
ausder
derPlanung
Planungwerden
werdensowohl
sowohlaus
ausDatenDaten-als
alsauch
auch
Die
ausProzess-Sicht
Prozess-Sichtweiter
weiterdetailliert.
detailliert.Zu
Zujedem
jedemZeitpunkt
Zeitpunktder
derAnalyseAnalyse-und
undauch
auchder
der
aus
darauffolgenden
folgendenDesignphase
Designphasemuss
mussdarauf
daraufgeachtet
geachtetwerden,
werden,dass
dassDatenDaten-und
und
darauf
Prozessmodellzueinander
zueinanderkonsistent
konsistentsind.
sind.
Prozessmodell
⇒Ergebnis:
Ergebnis:Datenmodell
Datenmodell(eER-Diagramm)
(eER-Diagramm)und
undProzessmodell
Prozessmodell(Analysesicht)
(Analysesicht)liegen
liegenvor.
vor.
⇒
Schestag
Datenbanken (Bachelor)
Kapitel 2 - 6
fbi
h_da
Lifecycle von Informationssystemen
Designphase
Designphase
Währendman
mansich
sichininder
derAnalysephase
Analysephaseausschließlich
ausschließlichmit
miteiner
einerlogischen
logischenSicht
Sichtauf
auf
Während
dieDaten
Datenbeschäftigt,
beschäftigt,wird
wirddiese
diesewährend
währendder
derDesignphase
Designphasedurch
durchdie
dieSicht
Sichtauf
aufdie
die
die
Implementierungsplattform(DBMS)
(DBMS)ergänzt:
ergänzt:
Implementierungsplattform
Festlegungder
derDatentypen
Datentypen(DBMS-spezifisch)
(DBMS-spezifisch)
•• Festlegung
Implementierungder
derBeziehungen
Beziehungendurch
durchDefinition
Definitionvon
vonReferenzen
Referenzenetc.
etc.
•• Implementierung
MitHilfe
Hilfevon
vonCASE-Tools
CASE-Tools*)*)können
könnenDatenmodelle
Datenmodelleder
derDesignsicht
Designsichtaus
ausDatenmodellen
Datenmodellen
Mit
derAnalysesicht
Analysesichtgeneriert
generiertwerden
werden(und
(undumgekehrt:
umgekehrt:Round-Trip-Engineering).
Round-Trip-Engineering).
der
⇒Ergebnis:
Ergebnis:Datenmodell
Datenmodell(z.B.
(z.B.Relationenmodell
Relationenmodellbeim
beimEinsatz
Einsatzvon
vonRDBMS)
RDBMS)und
und
⇒
Prozessmodellder
derDesignsicht
Designsichtliegen
liegenvor.
vor.
Prozessmodell
*) CASE = computer aided software engineering
Schestag
Datenbanken (Bachelor)
Kapitel 2 - 7
fbi
h_da
Lifecycle von Informationssystemen
Implementierungsphase
Implementierungsphase
DieGüte
Gütevon
vonAnalyse
Analyseund
undDesign
Designzeigen
zeigensich
sichinineiner
einerrelativ
relativproblemlosen
problemlosen
Die
Implementierung.
Implementierung.
ImFalle
Falleeines
einesRDBMS
RDBMSerfolgt
erfolgtdie
dieImplementierung
Implementierungeines
einesDatenbankschemas
Datenbankschemas
Im
durchdie
diedeklarative
deklarativeSprachkomponente
Sprachkomponentevon
vonSQL
SQL(SQL
(SQLDDL).
DDL).
durch
BeimEinsatz
Einsatzvon
vonCASE-Tools
CASE-Toolsist
istes
esmöglich,
möglich,das
dasSQL-Skript
SQL-Skriptfür
fürein
einspezifisches
spezifisches
Beim
RDBMSdirekt
direktaus
ausden
denInformationen
Informationendes
desRelationenmodells
Relationenmodellszu
zugenerieren.
generieren.
RDBMS
→ Welche Diagrammtypen der UML können Sie im Fall eines
objektorientierten Systems den einzelnen Phasen zuordnen?
Schestag
Datenbanken (Bachelor)
Kapitel 2 - 8
fbi
h_da
Semantische Datenmodellierung
9 Die Rolle der Datenmodellierung im Lifecycle von Informationssystemen
•
Das erweiterte Entity-Relationship Modell (eERM)
•
Unterschiedliche Nomenklaturen für ER-Diagramme
Schestag
Datenbanken (Bachelor)
Kapitel 2 - 9
fbi
h_da
Das Entity-Relationship Modell ERM
Das Entity-Relationship Modell wurde von Chen*) erstmals 1976 vorgestellt.
Oracle
(1979)
CODASYL
System R (1977)
→ DB2
(1983 unter MVS)
IMS/VS seit
1968 (IBM)
1960
Hierarchisches
Datenbankmodell
1970
1976 1980
1990
Netzwerk
Datenbankmodell
(1971, Data Base Task Group)
Relationales
Datenbankmodell
(1970, Edgar F. Codd)
Schestag
1997 2000
2010
UML – Unified Modeling
Language
wird 1997 von der OMG als
Standard akzeptiert
*) Chen P. P-S. The Entity-Relationship Model – Towards a Unified View of Data.
ACM Transactions of Database Systems (March 1976), 1(1):9-36
Datenbanken (Bachelor)
Kapitel 2 - 10
Das Entity-Relationship Modell ERM
fbi
h_da
„A data model, called the entity-relationship model, is proposed. This
model incorporates some of the important semantic information about
the real world. A special diagrammatic technique is introduced as a
tool for database design. An example of database design and description
using the model and the diagrammatic technique is given. Some implications for data integrity, information retrieval, and data manipulation are
discussed.
The entity-relationship model can be used as a basis for unification of
different views of data: the network model, the relational model, and the
entity set model. Semantic ambiguities in these models are analyzed.
Possible ways to derive their views of data from the entity-relationship
model are presented. …“
Anfang des Abstracts zu o.g. Artikel von P.P-S. Chen, 1976
Schestag
Datenbanken (Bachelor)
Kapitel 2 - 11
fbi
h_da
Das Entity-Relationship Modell ERM
Ziele des von Chen 1976 vorgestellten ERM:
• Modellierbarkeit semantischer Informationen aus der realen Welt
• Schaffung einer Grundlage zur Analyse von
– Netzwerkmodell
– Relationenmodell und
– Entity-Set Model.
•
Das ERM von Chen zeichnet sich aus durch seine Unabhängigkeit von
spezifischen Datenbankmodellen.
→ Der Entwurf eines ER-Modells findet in der Analysephase des SW-Lifecycle
statt.
Schestag
Datenbanken (Bachelor)
Kapitel 2 - 12
ERM – Der Entity-Typ (Entity-Type)
•
fbi
h_da
Zur visuellen Beschreibung der Struktur von Objekten der realen Welt und
der Beziehungen dieser Objekte untereinander verwendet man Diagramme,
in denen die entsprechenden Komponenten graphisch dargestellt werden:
– Eine Entität (entity) ist ein Objekt der realen Welt.
– Der Entity-Typ (entity type) ist der Repräsentant aller Objekte
gleichen Typs.
→ Grafische Notation: Rechteck, das den Namen des Entity-Typs enthält:
Produkt
Produkte
) Der Name eines Entity-Typs ist stets ein Substantiv, das im Singular
verwendet wird. Ein Entity-Typ, der die Struktur von Produktobjekten
repräsentieren soll, erhält also den Namen Produkt (und nicht Produkte!).
Schestag
Datenbanken (Bachelor)
Kapitel 2 - 13
ERM – Der Entity-Typ (Entity-Type)
•
fbi
h_da
Hinweis: Der Begriff Entity-Typ entspricht der Schemadeklaration einer
Klasse in der UML und wird bei der Datenmodellierung, auch bei CASETools, häufig dem Begriff Entität (Entity) gleichgesetzt.
Genau genommen entspricht der Begriff der Entität jedoch einer einzelnen
Instanz eines Enitity-Typs, so wie ein Objekt einer einzelnen Instanz einer
Klasse entspricht.
Toolbar und Zeichencanvas zur Modellierung eines konzeptionellen Datenmodells
Power Designer 12.5
Schestag
Datenbanken (Bachelor)
Kapitel 2 - 14
ERM – Der Beziehungstyp (Relationship-Type)
•
•
fbi
h_da
Eine Beziehung (Relationship, Assoziation) beschreibt, ob und wie
Entitäten untereinander assoziiert sind.
Der Beziehungstyp (relationship type) ist der Repräsentant aller
Beziehungen gleichen Typs.
→ Grafische Notation (in CASE-Tools eher selten unterstützt): Raute, die den
Namen des Beziehungstyps oder eine (numerische) Referenz auf den
Bezeichnertext enthält.
Bestellung
Produkt
Schestag
oder
1
1 = Bestellung
Bestellung
Datenbanken (Bachelor)
Kunde
Kapitel 2 - 15
ERM – Der Beziehungstyp (Relationship-Type)
•
•
fbi
h_da
Hinweis: Der Begriff Beziehungstyp entspricht dem Begriff der Beziehung
zwischen Klassen in der UML und wird bei der Datenmodellierung, auch bei
CASE-Tools, häufig dem Begriff Beziehung (Relationship bzw. Association)
gleichgesetzt.
Im allgemeinen Fall wird eine Beziehung in den meisten CASE-Tools
zunächst als Verbindungslinie zwischen zwei Entity-Typen dargestellt.
Produkt
Bestellung
Kunde
Toolbar und Zeichencanvas zur Modellierung eines konzeptionellen Datenmodells
Power Designer 12.5
Schestag
Datenbanken (Bachelor)
Kapitel 2 - 16
ERM – Der Beziehungstyp (Relationship-Type)
•
fbi
h_da
Hinweis: Der Begriff Beziehungstyp entspricht dem Begriff der Beziehung
zwischen Klassen in der UML und wird bei der Datenmodellierung, auch bei
CASE-Tools, häufig dem Begriff Beziehung (Relationship bzw. Association)
gleichgesetzt.
→ Zu den unterschiedlichen Darstellungen der Kardinalitäten vgl. Folie 2 – 21 ff.
Toolbar und Zeichencanvas zur Modellierung eines konzeptionellen Datenmodells
Power Designer 12.5
Schestag
Datenbanken (Bachelor)
Kapitel 2 - 17
fbi
h_da
ERM – Attribute
•
Attribute beschreiben die Eigenschaften von Entity- oder Beziehungstypen.
→ Grafische Notation: Abgerundetes Rechteck oder Oval, das den
Attributnamen enthält.
Produkt
…
•
•
Bestellung
Kunde
Vorname
Bestelldatum
Nachname
…
Attribute, die in dieser Form in ER-Diagrammen dargestellt werden, zeigt
man aus Übersichtlichkeitsgründen oft nur optional mit an.
Welches ist die Analogie im UML-Klassendiagramm (Analysesicht) zu
Beziehungen, die selbst Attribute besitzen?
Schestag
Datenbanken (Bachelor)
Kapitel 2 - 18
fbi
h_da
ERM – Attribute
•
Hinweis: In den meisten CASE-Tools werden die Attribute von EntityTypes in Analogie zur Darstellung der Attribute einer Klasse in der UML als
Attributliste angezeigt:
Toolbar und Zeichencanvas zur Modellierung eines konzeptionellen Datenmodells
Power Designer 12.5
•
Bereits in der Analysesicht können den Attributen generische Datentypen
zugeordnet werden, die jedoch noch nicht spezifisch für das jeweilige
DBMS-Zielsystem sind.
Schestag
Datenbanken (Bachelor)
Kapitel 2 - 19
fbi
h_da
ERM – n-äre Beziehungen
•
•
•
Entsprechend der Anzahl n der an einer Beziehung beteiligten Entity-Typen
spricht man von n-stelligen oder auch n-ären Beziehungen, n ≥ 2.
Im Fall n = 2 nennt man die Beziehung 2-stellig oder auch binäre Beziehung und spezialisiert den Fall, dass die Beziehung rekursiv sein kann.
3-stellige Beziehungen nennt man auch ternäre Beziehungen.
→ Die Raute als Symbol für eine Beziehung ist besonders gut geeignet, n-äre
Beziehungen für n ≥ 3 darzustellen.
Produkt
1
1 = Komponentenbeziehung
Bestellung
Kunde
Lieferung
→ Wie stellen Sie ternäre Beziehungen in der UML dar?
Schestag
Datenbanken (Bachelor)
Kapitel 2 - 20
fbi
h_da
ERM – Kardinalitäten
•
•
•
Mit der Kardinalität*) min:max kennzeichnet man die minimal und maximal
mögliche Anzahl von Instanzen eines Entity-Typ, die mit einer bestimmten
Instanz eines anderen Entity-Typ in Beziehung stehen.
Als Wert für „beliebig viele“ verwendet man Buchstaben wie m und n.
Ursprünglich verwendete Chen in seinen Diagrammen bei der Angabe von
Kardinalitäten nur die Obergrenze!
1 Kunde bestellt mindestens 1, aber beliebig viele Produkte
Produkt
N
oder 1:N
Bestellung
0:M oder
M
Kunde
1 Produkt wird von möglicherweise keinem aber beliebig vielen Kunden bestellt.
*) Die Zuordnung der Kardinalitäten (in der UML auch Multiplizitäten genannt) zu den Entitäten wird
u. U. auch in umgekehrter Reihenfolge vorgenommen und erfordert für n-äre Beziehungen, n ≥ 3
eine klare semantische Definition!
Vgl. hierzu den Abschnitt Unterschiedliche Nomenklaturen zu ER-Diagrammen.
Schestag
Datenbanken (Bachelor)
Kapitel 2 - 21
fbi
h_da
ERM – Kardinalitäten
•
Hinweis: In vielen CASE-Tools zur ER-Modellierung werden die
Kardinalitäten mit der Krähenfuß-Nomenklatur nach James Martin
bezeichnet (engl. crawfood-Darstellung):
Entität
= maximal ein
Entität
kein oder
ein
Entität
= beliebig viele
ein und
nur ein
Entität
= mindestens ein
ein oder
mehrere
kein oder
mehrere
Schestag
= genau ein
Datenbanken (Bachelor)
Kapitel 2 - 22
fbi
h_da
ERM – Kardinalitäten im Power Designer
•
Hinweis: Im Power Designer ist es möglich, für eine Relationship ein
Association-Symbol einzuführen (an Stelle der Raute), dies ist aber nicht
zwingend erforderlich (s. Folien 2-16 und 2-17).
→ Statt dessen kann auch ohne Darstellung eines Assoziationssymbols direkt
die binäre Darstellung zwischen zwei Entity-Typen dargestellt werden. Hierbei werden die Kardinalitäten mit der Krähenfuß-Notation angezeigt …
Im Power Designer wird bei
der 0:1-Notation auf die
Darstellung der 1 verzichtet!
→ … während bei den Beziehungslinien zu einem Association-Symbol die
Kardinalitäten in der min,max-Notation angezeigt werden (s. Folie 2-19).
Schestag
Datenbanken (Bachelor)
Kapitel 2 - 23
ERM – schwache Entitäten
fbi
h_da
•
Entitäten, die nicht alleine, sondern nur in Abhängigkeit von der Existenz
anderer Entitäten existieren können, nennt man schwache Entitäten –
weak entities und spricht auch von abhängigen Beziehungen – dependent
Relationships.
•
Die Entity-Typen schwacher Entitäten werden in der Nomenklatur nach
Chen durch ein Rechteck mit doppelter Linie gezeichnet. Von der Raute auf
den schwachen Entity-Typ deutet ein Pfeil:
Student
1
Student
Nachweis
Nachweis
Bewertung
Bewertung
Im Power Designer ändert sich bei
Abhängigkeit (= Dependency) die grafische
Darstellung der entsprechenden Kardinalität!
Schestag
Datenbanken (Bachelor)
Kapitel 2 - 24
fbi
h_da
ERM – Hörsaalübung
•
Zeichnen Sie zunächst ein UML-Klassendiagramm (Analysesicht), das die
im Folgenden beschriebenen Klassen und ihre Beziehungen zueinander
modelliert:
Entity-Typen––Klassen
Klassen
Entity-Typen
Mitarbeiter
• • Mitarbeiter
Abteilung
• • Abteilung
Projekt
• • Projekt
Beziehungstypen––Beziehungen
Beziehungen
Beziehungstypen
JederMitarbeiter
Mitarbeiterarbeitet
arbeitetiningenau
genaueiner
einerAbteilung,
Abteilung,ininjeder
jederAbteilung
Abteilungarbeiten
arbeitenmehrere
mehrereMitarbeiter.
Mitarbeiter.
• •Jeder
JedeAbteilung
Abteilunghat
hatgenau
genaueinen
einenMitarbeiter,
Mitarbeiter,der
derder
derLeiter
Leiterdieser
dieserAbteilung
Abteilungist.
ist.
• •Jede
JederMitarbeiter
Mitarbeiterarbeitet
arbeitetininkeinem,
keinem,einen
einenoder
odermehreren
mehrerenProjekten
Projektenmit.
mit.
• •Jeder
Füreinen
einenMitarbeiter
Mitarbeiterist
istseine
seineRolle
Rolleininjedem
jedemProjekt
Projektbekannt,
bekannt,an
andem
demererbeteiligt
beteiligtist.
ist.
• •Für
JedesProjekt
Projektist
istgenau
genaueiner
einerAbteilung
Abteilungzugeordnet.
zugeordnet.
• •Jedes
•
Zeichnen Sie nun ein ER-Diagramm, das die o.g.Entity-Typen und deren
Beziehungen untereinander darstellt. Verwenden Sie zur Darstellung der
Beziehungstypen das Rautensymbol.
Schestag
Datenbanken (Bachelor)
Kapitel 2 - 25
Das erweiterte ER Modell – eERM – Vererbung
fbi
h_da
•
Die spezielle Beziehungsstruktur einer Vererbungshierarchie –
Inheritance wurde als Erweiterung der ursprünglichen ERM in Anlehnung
an entsprechende objektorientierte Konzepte ergänzt.
•
Man spricht auch von Generalisierung / Spezialisierung oder von „ist-ein
Beziehung“
•
Ein Wurzel-Entity-Typ stellt jeweils den Supertyp dar, der diejenigen
Attribute und Beziehungen enthält, die alle seine Subtypen (Spezialisierungen) gemeinsam haben.
•
Alle Subtypen werden dann nur noch durch spezifische Attribute oder auch
durch spezifische Beziehungen zu anderen Entity-Typen beschrieben, die
sie von den anderen Subtypen unterscheiden.
) Welche constraints der UML kennen Sie im Zusammenhang mit der
Darstellung von Vererbungshierarchien?
Schestag
Datenbanken (Bachelor)
Kapitel 2 - 26
fbi
h_da
eERM – Vererbung
Geschäftspartner
Händler
Spediteur
Kunde
Veranstalter
• Man unterscheidet zwischen den folgenden Spezialisierungsformen:
→ Totale Spezialisierung: Jede Instanz des Supertyps entspricht mindestens
einem Subtyp. Insbesondere überdeckt die Menge aller Subtypen alle
Instanzen des Supertyps (Darstellung: „Doppelstrich“, s.o.).
→ Partielle Spezialisierung: Nicht jede Ausprägung des
Supertyps wird notwendig spezialisiert
(Darstellung: „einfacher Strich“).
Schestag
Datenbanken (Bachelor)
Kapitel 2 - 27
fbi
h_da
eERM – Vererbung
→ Disjunkte Spezialisierung: Die Teilmengen der Instanzen aller
Spezialisierungen sind disjunkt (Darstellung: D = disjoint im
Dreickessymbol), andernfalls erlaubt man
→ Überlappende Spezialisierung (Darstellung: O = overlapping im
Dreieckssymbol)
D
O
Toolbar und Zeichencanvas zur Modellierung einer
Vererbungshierarchie im konzeptionellen Datenmodell
Power Designer 12.5
Die Unterschiedung zwischen totaler und. partieller
Spezialisierung bzw. zwischen disjunkten und überlappenden Spezialisierungen ist hier möglich durch
Setzen der beiden folgenden Eigenschaften:
mutually exclusive ↔ disjoint
complete
Schestag
Datenbanken (Bachelor)
Kapitel 2 - 28
Primärschlüssel
•
•
•
•
fbi
h_da
Um einzelne Entitäten voneinander unterscheiden und identifizieren zu
können, wird ein so genannter Primärschlüssel (Primary Key) eingeführt:
Ein Attribut oder eine Kombination von Attributen heißt Primärschlüssel
p, wenn gilt:
1. Der Wert von p definiert die Attributwerte aller anderen Attribute der
Entität eindeutig.
2. Man kann (im zusammengesetzten Fall) kein Attribut aus p entfernen,
ohne dass 1. verletzt wird.
Besteht der Schlüssel aus einer Kombination mehrerer Attribute, so
spricht man von einem zusammengesetzten Schlüssel - concatinated
key.
Graphische Notation: Der Primärschlüssel ist einfach (oder doppelt)
unterstrichen in der Attributliste:
…
Buch (ISBN, Titel, …)
Schestag
Buch
Datenbanken (Bachelor)
ISBN
Kapitel 2 - 29
fbi
h_da
Candidate Key
•
•
Gibt es in einem Entity-Typ mehrere Schlüssel, von denen jeder die Rolle
des Primärschlüssels übernehmen kann, so nennt man diese candidate
keys (alternative Primärschlüssel) und wählt einen von ihnen als Primärschlüssel des Entity-Typs aus.
Der Begriff „concatinated” gilt analog für candidate keys.
•
Beispiel: Personalstammdaten in einem Entity-Typ Person
Person
Sozialversicherungsnummer
Personalnummer
Gehalt
candidate key: Sozialversicherungsnummer
Schestag
Datenbanken (Bachelor)
Steuerklasse
primary key: Personalnummer
Kapitel 2 - 30
fbi
h_da
Unterschiedliche Nomenklaturen …
… für ER-Diagramme
•
Erste Schema-Diagramme wurden in den 60er Jahren von Charles
Bachmann1) formalisiert:
– Er benutzte Rechtecke, um so genannte Record-Typen zu kennzeichnen, und Linien bzw. gerichtete Pfeile von einem Record-Typ zu
einem anderen, um eine 1:1- bzw. 1:N-Beziehung unter den Instanzen
des jeweiligen Typs zu kennzeichnen:
Bachmann-Notation
A
B
A
B
Vergleich: Chen-Notation
A
1) Bachmann,
Schestag
1
1
B
A
1
N
B
C.W. Data Structure Diagrams. Databases 1, 2 (1969), pp. 4-10
Datenbanken (Bachelor)
Kapitel 2 - 31
Unterschiedliche Nomenklaturen
fbi
h_da
Bei jeder Schreibweise stellt sich die Frage nach
• Lesrichtung und
• Interpretation der Kardinalitäten (Multiplizitäten):
Chen-Notation (analog UML-Lesrichtung und -Interpretation)
Jede Instanz der Entität A
ist zu 1 Instanz der Entität
B assoziiert bzgl. R.
A
N
1
R
B
Jede Instanz der Entität B
ist zu N Instanzen der Entität
A assoziiert bzgl. R.
B
Jede Instanz der Entität B
ist in maximal n Beziehungen vom Typ R zu Instanzen der Entität A enthalten.
min,max-Notation
Jede Instanz der Entität A
ist in maximal 1 Beziehung
vom Typ R zu Instanzen
der Entität B enthalten.
A
(0,1)
R
(0,n)
→ Während die erste Notation die Anzahl der bzgl. R assoziierten Entitäten
zählt, wird in der zweiten Notation die Anzahl der Beziehungen R gezählt, in
denen eine Entität enthalten ist.
Schestag
Datenbanken (Bachelor)
Kapitel 2 - 32
fbi
h_da
Unterschiedliche Nomenklaturen
→ Im folgenden Szenario einer ternären Beziehung „Produktionsorganisation“
wird die Interpretation der Kardinalitäten zwischen Chen- (bzw. UML-)
Notation und min,max-Notation verglichen:
–
–
–
–
–
–
Schestag
Eine Produktion kann auf mehrere Lokationen verteilt sein, und
ein Mitarbeiter arbeitet an genau einer Lokation,
ein Mitarbeiter arbeitet bei genau einer Produktion mit,
eine Produktion hat viele Mitarbeiter,
an einer Lokation arbeiten viele Mitarbeiter,
an einer Lokation können mehrere Produktionen stattfinden.
Datenbanken (Bachelor)
Kapitel 2 - 33
fbi
h_da
Unterschiedliche Nomenklaturen
→ Chen-Notation in n-ären Beziehungen:
Produktionsorganisation
Mitarbeiter
ein Mitarbeiter
Produktion
?
arbeitet an
eine Produktion
kann verteilt sein auf
Lokation
genau einer
beliebig viele
?=1
oder
?=n
→ Die Kardinalitäten werden nicht mehr durch die binäre Lesart gefunden,
sondern durch die Beantwortung der Frage, zu wie vielen Instanzen des
n-ten Entity-Typ jeweils n-1 Instanzen der anderen Entity-Typen in
Beziehung stehen:
Schestag
Datenbanken (Bachelor)
Kapitel 2 - 34
fbi
h_da
Unterschiedliche Nomenklaturen
→ Chen-Notation: Zu wie vielen Lokationen steht ein Paar (Mitarbeiter,
Produktion) in Beziehung?
–
–
–
–
–
–
Eine Produktion kann auf mehrere Lokationen verteilt sein, und
ein Mitarbeiter arbeitet an genau einer Lokation,
ein Mitarbeiter arbeitet bei genau einer Produktion mit,
eine Produktion hat viele Mitarbeiter,
an einer Lokation arbeiten viele Mitarbeiter,
an einer Lokation können mehrere Produktionen stattfinden.
Mitarbeiter
N
1
Produktionsorganisation
?
⇒
Produktion
?=1
Lokation
Schestag
Datenbanken (Bachelor)
Kapitel 2 - 35
fbi
h_da
Unterschiedliche Nomenklaturen
→ … aber nicht jede semantische Bedeutung einer binären Beziehung kann in
der Kardinalität einer n-ären Beziehung, n ≥ 3 ausgedrückt werden:
–
–
–
–
–
–
Eine Produktion kann auf mehrere Lokationen verteilt sein, und
ein Mitarbeiter arbeitet an genau einer Lokation,
ein Mitarbeiter arbeitet bei genau einer Produktion mit,
eine Produktion hat viele Mitarbeiter,
an einer Lokation arbeiten viele Mitarbeiter,
an einer Lokation findet nur eine Produktion statt.
Mitarbeiter
N
1
Produktionsorganisation
?
⇒
Produktion
?=1
Lokation
Schestag
Datenbanken (Bachelor)
Kapitel 2 - 36
fbi
h_da
Unterschiedliche Nomenklaturen
→ min,max-Notation: In wie vielen Beziehungen zu Paaren (Produktion,
Lokation) ist ein Mitarbeiter enthalten?
–
–
–
–
–
–
Eine Produktion kann auf mehrere Lokationen verteilt sein, und
ein Mitarbeiter arbeitet an genau einer Lokation,
ein Mitarbeiter arbeitet bei genau einer Produktion mit,
eine Produktion hat viele Mitarbeiter,
an einer Lokation arbeiten viele Mitarbeiter,
an einer Lokation können mehrere Produktionen stattfinden.
Mitarbeiter
(1,1)
Produktionsorganisation
(1,n)
Produktion
(1,n)
Lokation
Schestag
Datenbanken (Bachelor)
Kapitel 2 - 37
Unterschiedliche Nomenklaturen
fbi
h_da
CASE-Tools …
• verwenden fast ausschließlich binäre Beziehungen und die Ergänzung
eines eigenen Entity-Typ als Repräsentanten der n-ären Beziehung.
• Als Konvention für die Lesrichtung hat sich die der Chen-Notation bzw. die
der Mulitplizitäten bei Klassendiagrammen in der UML durchgesetzt.
• Meistens verzichtet man auf die Raute als Beziehungssymbol.
→ Beispiel-Szenario der vorgehenden Folie mit Hilfe binärer Beziehungen und
eines zusätzlichen Entity-Typen:
Mitarbeiter
1
*
Produktions- *
organisation
Lokation
Schestag
1
1
Produktion
*
Datenbanken (Bachelor)
Kapitel 2 - 38
fbi
h_da
Zusammenfassung
•
Die ER-Modellierung legte bereits in den 60er Jahren die Grundlagen für
das UML-Klassendiagramm in der Analysesicht (OOA).
•
Neben zahlreichen Analogien zum UML-Klassendiagramm der OOA gibt es
neben Unterschieden in der Nomenklatur
– den Begriff der schwachen Entität, sowie
– den Begriff des Primärschlüssels und der Candidate Keys.
•
Das erweiterte ER-Modell – eERM ermöglicht es, analog zur UML,
Vererbungshierarchien zu beschreiben.
•
Im Gegensatz zur standardisierten UML findet man in Diagrammen zur
Datenmodellierung unterschiedliche Lesrichtungen bzgl. der Kardinalitäten.
Hier stehen im direkten Gegensatz die Lesrichtung von ER-Diagrammen
nach Chen und UML gegenüber der min,max-Notation.
Schestag
Datenbanken (Bachelor)
Kapitel 2 - 39
Datenbanken
9
Einführung
9
Semantische Datenmodellierung
3.
Relationenmodell
4.
SQL - Structured Query Language
5.
Datenbank-Anwendungsentwicklung
6.
Transaktionsmanagement
7.
Interne Datenorganisation
8.
Rückblicke und Ausblicke
Schestag
Datenbanken (Bachelor)
fbi
h_da
Kapitel 2 - 40