Kapitel DB-2: Datenbankentwurf - Informationsmodellierung
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Herbstsemester 2011
CS241 Datenbanken / CS261 Web Data Management
Kapitel DB-2: Datenbankentwurf –
Informationsmodellierung
H. Schuldt
Informationsmodellierung
Ziel der Informationsmodellierung (des konzeptuellen Datenbankentwurfs)
• Die Modellierung von Sachverhalten der realen Welt mit Hilfe weniger
Grundkonzepte mit dem Zweck, eine computergestützte Datenbank aufzubauen
• Dazu sind notwendig:
– eine Modellierungssprache (ein „semantisches“ Datenmodell)
– eine Entwurfsmethodologie
– computergestützte Entwurfswerkzeuge (für grosse Entwürfe)
Rolle der Informationsmodellierung bei der Entwicklung von Informationssystemen:
Informationssysteme werden in mehreren Stufen entwickelt:
1. Analyse der Anwendungswelt (Ermittlung des Informationsbedarfs,
zu automatisierende Abläufe)
2. Informationsmodellierung (sowie Prozessmodellierung)
3. Abbildung des Informationsmodells auf ein (relationales) Datenbankschema
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-2
1
Einordnung des konzeptuellen DB-Entwurfs (I)
Der konzeptuelle Datenbank-Entwurf ist wie folgt (grob) in Aktivitäten der
Informationsmodellierung eingebunden:
Ausschnitt der
realen Welt
(Miniwelt)
Konzeptueller DB-Entwurf:
manuelle/intellektuelle Modellierung
konzeptuelles Schema
halbautomatische Transformation
relationales Netzwerk- objektrelationales
Schema Schema
... Schema
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-3
Abstraktionsebenen des Datenbankentwurfs
Beim Entwurf einer Datenbankanwendung lassen sich drei Abstraktionsebenen
unterscheiden:
• die konzeptuelle Ebene: diese ermöglicht die Strukturierung des
Anwendungsbereichs (Miniwelt). Das Ergebnis des konzeptuellen Entwurfs
(konzeptuelles Schema) ist unabhängig vom verwendeten Datenbanksystem.
Der konzeptuelle DB-Entwurf ist Gegenstand dieses Kapitels.
• die Implementierungsebene: diese Ebene sieht die Modellierung mit Hilfe
der Konzepte des verwendeten Datenbanksystems vor (d.h. verwendet das
Datenmodell eines DBMS – relational, objektorientiert, objektrelational, etc.).
Das relationale Datenmodell wird Kapitel DB-3 eingeführt.
• die physische Ebene: diese Ebene hat zum Ziel, die Performanz der
Datenbankanwendungen zu erhöhen, in dem besondere Speicherstrukturen,
Indexstrukturen, etc. verwendet werden. Voraussetzung sind dabei Annahmen
der zu erwartenden Datenmengen bzw. Zugriffscharakteristiken; zudem sind
vertiefte Kenntnisse von Betriebssystemkonzepten nötig.
Kapitel DB-9 und DB-10 (nur cs241) befassen sich mit dem physischen Entwurf
und dessen Grundlagen.
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-4
2Datenbank-Entwurf: Übersicht
• Generelle Aufgabe:
Finde eine formale Beschreibung (Modell) für einen zu modellierenden Teil der
realen Welt
• Zwischenstufen:
– Beschreibung durch natürliche Sprache (Pflichtenheft):
Beispiel: In der Datenbank sollen alle Studierenden mit den
durch sie belegten Lehrveranstaltungen gespeichert sein
– Beschreibung durch abstrakte grafische Darstellungen:
Studierender belegt Vorlesung
– Beschreibung im relationalen Modell:
create table studierender (...) ;
create table vorlesung (...) ;
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-5
Einordnung des konzeptuellen DB-Entwurfs (II)
Informations- Datenverarbeitungs-
anforderungen anforderungen
Anforderungs-
analyse
Anforderungsspezifikation
(Pflichtenheft, Informations- & Prozessmodell)
Konzeptueller Entwurf
DBMS-
konzeptuelles Schema Eigenschaften
(DBMS-unabhängig)
Implementierungsentwurf
(logischer Entwurf)
Hardware/OS-
Eigenschaften logisches Schema
(DBMS-abhängig)
Physischer Entwurf
Physisches (internes) Schema
(DBMS-abhängig)
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-6
3Grundkonzepte semantischer Datenmodelle (I)
Klassifikation (Synonym: Typisierung)
• Grundlage der Klassifikation ist die Unterscheidung zwischen dem Typ eines
Objekts und einer Menge von Objekten dieses Typs (auch „Extent“ des Typs
genannt). Ein Objekt, also ein Element des Extents, wird auch „Ausprägung“
des Typs genannt.
Generalisierung/Spezialisierung: Beides beinhaltet die Anordnung der Typen in einer
Typhierarchie, besser Typverbund (häufig auch Begriffshierarchie genannt).
– Generalisierung eines Typs:
• Übergang zu einem allgemeineren (Supertyp).
• Allgemeinster Typ ist „Das Ding an sich“
– Spezialisierung eines Typs:
• Übergang von einem allgemeinem zu einem oder mehreren speziellen
Typen (Subtypen)
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-7
Grundkonzepte semantischer Datenmodelle (II)
Ein weiteres Grundkonzept ist das Abstrahieren von Details. Dies stellt eine
wesentliche Fähigkeit menschlicher Kommunikation dar und ist auch für die
Repräsentation von Wissen essentiell.
Man unterscheidet zwei Formen der Abstraktion:
1. Aggregation: Bildung von zusammengesetzten Objekttypen aus Einfacheren.
(vergleichbar mit dem Bilden von struct- bzw. record-Typen in
Programmiersprachen und dem gesamthafte Ansprechen von struct-
oder record-Variablen)
2. Assoziation: Bildung von Mengentypen, also die Zusammenfassung
von Objekten desselben Typs (vergleichbar dem set-Konstruktor in
Programmiersprachen)
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-8
4Das (erweiterte) Entity-Relationship-Modell …
Das Entity-Relationship-Modell (ER-Modell) bzw. das
erweiterte Entity-Relationship-Modell (EER-Modell) ist das am weitesten verbreitete
Modell zur Unterstützung des konzeptuellen Datenbank-Entwurfs.
– Es dient dazu, ein konzeptuelles Schema für einen Ausschnitt der
realen Welt zu erstellen
– Als grafische Darstellung werden E/R-Diagramme eingesetzt
– Gemäss den Anforderungen an den konzeptuellen Entwurf beschreibt das
(E)ER-Modell ein maschinenfernes Datenmodell und erlaubt die Modellierung
auf einem hohen Abstraktionsniveau, ohne dass dabei Überlegungen zur
Effizienz eine Rolle spielen
– Das Modell muss danach über vorgegebene, grundlegende
Transformationsregeln in ein logisches Schema überführt
(und evtl. nachgebessert T Normalisierung) werden
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-9
… Das (erweiterte) Entity-Relationship-Modell
Ausgangspunkt der Modellierung sind Objekte (Entities, Entitäten) der realen Welt
oder unserer Vorstellung (eine Person, ein Buch, ein Bankkonto, etc.).
Die Modellierung umfasst folgende Schritte:
• Schritt 1: Anwendung der Klassifikation
– Welche verschiedenen Typen von Objekten soll es geben? Was sind deren
Attribute?
• Schritt 2: Generalisierung
– Feststellen, ob es Objekttypen gibt, deren Merkmalsfunktionen als
Teilmengen bei anderen Objekttypen vorkommen.
• Schritt 3: Beziehungen zwischen Objekten:
– Feststellen, welche Typen von Beziehungen (“Relationship Types”)
es zwischen den Objekttypen geben soll.
• Schritt 4: Festlegung der Arten der Beziehungstypen
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-10
5Elemente des ER-Modells
• Entitätstypen (Entity Types): Objekttypen
Student
• Attribute: Eigenschaften der Objekttypen Name
• Beziehungstypen (Relationship Types):
belegt
Beziehungen zwischen Entitäten
Entscheidende Aufgabe des Datenbank-Entwurf:
• Das Auffinden geeigneter Entitäten, Attribute und Beziehungen
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-11
Anwendung der Klassifikation
Schritt 1: Anwendung der Klassifikation als erstes Ordnungssprinzip des Entwurfs:
– Welche verschiedenen Typen (Entitätstypen) von Objekten soll es geben?
Durch welche Merkmale (= Attributwerte) sollen sie beschrieben werden
und wie sollen sie daher später in der DB repräsentiert sein?
Ein Entitätstyp E bezeichnet eine Menge von Merkmalsfunktionen (=Attribute)
Eine Entitätsmenge, abgekürzt durch ext(E) bezeichnet eine Menge von Objekten die
vom gleichen Typ sind, d.h. die durch die gleichen Attribute beschrieben werden
(sollen). Manchmal wird die Entitätsmenge auch aktiver Domain von E bezeichnet.
Ein Attribut (Merkmalsfunktion) ist eine Funktion, die einer (realen) Entität einen
Merkmalswert aus einem bestimmten Wertebereich (Domain) zuordnet.
Beispiele:
– Bücher Attribute: ISBN, Titel, Autoren, Verlag, Erscheinungsjahr
– Bankkonten Attribute: Kontonummer, Kontoinhaber, Kontostand, Zinssatz
– Studenten Attribute: Matrikel-Nummer, Name, Adresse, Prüfungen
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-12
6Identifikationsschlüssel
• Ein Identifikationsschlüssel eines Entitätstyps E ist eine Menge K von
(einwertigen) Attributen, für die folgendes gilt: Zu jedem Zeitpunkt
unterscheiden sich zwei verschiedene Objekte e1 und e2 aus E bezüglich K,
und es gibt keine echte Teilmenge von K, die diese Eigenschaft besitzt.
Beispiele:
– Kontonummer bei Bankkonten einer bestimmten Bank,
– IBAN und BIC bei internationalen Bankkonten
– AHV-Nummer bei Angestellten
• Es empfiehlt sich, als Identifikationsschlüssel künstliche Schlüssel zu verwenden,
die sich während der “Lebensdauer” der identifizierten Objekte nie ändern,
z.B. Kontonummern und Angestelltennummern.
• Ein Objekt der realen Welt kann als eigenständiges Objekt oder “nur” als Wert
eines Attributs modelliert werden.
– Beispiel: “Farbe” kann eine Attribut eines Entitätstyps sein (z.B. die Farbe
eines Autos) oder ein eigenständiger Entitätstyp mit Attributen wie
“chemische Zusammensetzung”, “Preis” oder auch “Wellenlänge”
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-13
Wertebereiche und Graphische Darstellung von Entitätstypen
• Die Wertebereiche von Attributen sind prinzipiell nicht auf elementare Datentypen
beschränkt, sondern können tupelwertig sein (z.B. Datum =TT.MM.JJ).
• Ebenfalls sind einfache Mengen als Attributwerte zugelassen
• Allerdings wird beides in der Praxis recht selten angewandt
Department.No ist
Identifikationsschlüssel
Symbole: Beispiele: No
Entity-Type Department Name
Locations
Department.Locations ist ein mehrwertiges Attribut
A1 No
First
...
Entity-Type Employee Name
An last
...
Employee.Name ist ein
strukturiertes Attribut
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-14
7Generalisierung/Spezialisierung
Schritt 2: Generalisierung: Ordnung schaffen bei den Typen durch Anordnen der
Typen in eine „Typhierarchie“: Feststellen, ob es Entitätstypen gibt, deren
Merkmalsfunktionen als Teilmengen bei anderen Entitätstypen vorkommen.
Generalisierung, Spezialisierung, Vererbung:
• Zwei Entitätstypen E und F stehen in einer ISA-Beziehung, man sagt „F is a E“,
wenn
1. die Attributmenge von F eine Obermenge der Attributmenge von E ist und
2. die Objektmenge von F eine Teilmenge der Objektmenge von E ist
(„jedes f ist-ein e“)
• Man bezeichnet F als Spezialisierung von E (F ist Subtyp)
E
und E als Generalisierung von F (E ist Supertyp).
Man sagt auch, dass F die Attribute von E „erbt“.
F
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-15
Generalisierung/Spezialisierung: Beispiel
Die Vererbungsbeziehungen sind Bestandteil des erweiterten ER-Modells
• Beispiel:
– Ein Lehrender kann entweder ein Professor, ein Assistent oder ein externer
Lehrbeauftragter sein
• Charakteristik und Bedeutung:
– Sämtliche Attribute und Beziehungen werden in der Typhierarchie nach
unten vererbt
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-16
8Generalisierung/Spezialisierung
Mit der Generalisierung lassen sich ganze Hierarchien aufbauen, die häufig die
morphologische Gliederung eines Anwendungsfeldes modellieren.
Beispiele:
• Wirbeltiere – Säugetiere – Katzen – Tiger – Säbelzahntiger
• Bankkonten – Sparkonten – Jugendsparkonten
Generalisierungshierarchien müssen nicht notwendigerweise Bäume sein.
Beispiel:
Personen
Angestellte Studenten
Praktikanten
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-17
Zusatzbedingungen bei Spezialisierung/Generalisiserung
Verfeinerungen bei Generalisierung/Spezialisierung
• Seien F1, ..., Fn Spezialisierungen des Entitätstyps E.
• E heisst disjunkt partitioniert, wenn je zwei Objektmengen Oj und Ok der
Typen Fj und Fk disjunkt sind.
• E heisst vollständig-überdeckend partitioniert wenn die Vereinigung der
speziellen Objektmengen die Objektmenge von E ergibt
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-18
9Beziehungstypen
Schritt 3: Ausgangspunkt: Objekte der realen Welt. Diese stehen in vielerlei
Beziehungen zueinander (z.B. manche Personen sind Kunden einer Bank,
manche Personen sind verheiratet). Feststellen, welche Typen von Beziehungen
(„Relationship Types“) es zwischen den Objekttypen geben soll.
Beziehungstyp, Beziehungsmenge, Beziehung
• Ein Beziehungstyp B zwischen Entitätstypen T1, T2, ..., Tn mit n¥2 ist eine Folge
von Paaren
B= ‚ R1:T1, R2:T2, ..., Rn:Tn Ú
mit Ri als Rollennamen zur Bezeichnung der Rolle, die Entitätstyp Ti in der
Beziehung B spielt.
• Eine Beziehungsmenge (relationship set) des Typs B, abgekürzt mit ext(B) ist eine
Teilmenge des kartesischen Produkts der betroffenen Objektmengen
ext(B) Œ ext(T1) ä ... ä ext(Tn)
• Eine einzelne Beziehung b ist ein n-Tupel b = ‚ id(e1), ..., id(en) Ú mit id(ei)
als Identifikationsschlüssel des Objektes ei vom Typ Ti, also ei aus ext(Ti)
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-19
Beziehungstypen: Beispiele
Beispiel 1:
Studierender belegt Vorlesung
Beziehungsmenge: belegt (Wirth, Algorithmen und Datenstrukturen)
belegt (Wirth, Programmieren I)
belegt (Kant, Grundlagen der Philosophie)
belegt (Bernoulli, Mathematik I)
Beispiel 2:
• Beziehungstyp Einkauf:
Einkauf = ‚ Kunde:Person, Kauf:Ware, Verkäufer:Händler Ú
Ausprägungsbeispiele: ‚ Ueli, Milch, Migros Ú
‚ Christoph, Käse, Coop Ú
Beispiel 3:
• Beziehungstyp verheiratet_mit:
verheiratet_mit = ‚ Ehefrau:Person, Ehemann:Person Ú
Ausprägungsbeispiele ‚ Paola, Kurt Ú
‚ Paola, Felix Ú
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-20
10Beziehungsattribute
Beispiel 3 zeigt, dass Verfeinerungen von Beziehungen nötig sind
(weitere Arten von Beziehungen)
Beziehungsattribut: Zusätzlich zur Angabe der beteiligten Entitätstypen können
weitere Merkmalsfunktionen (Attribute) –wie bei Entitätstypen– zur näheren
Beschreibung einer Beziehung herangezogen werden
(z.B. die Vorratsmenge, die von einem Produkt in einem Lager vorhanden ist,
oder die Note, die ein Student in einem Prüfungsfach erreicht hat).
Beispiel 3*:
Beziehungstyp verheiratet_mit*:
verheiratet_mit = ‚ Ehefrau:Person, Ehemann:Person, Hochzeit:Datum, Scheidung:Datum Ú
Ausprägungsbeispiele ‚ Paola, Kurt, 01.01.1955, 31.12.1988 Ú
‚ Paola, Felix, 01.01.1989, Ú
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-21
Graphische Darstellung von Beziehungen
Symbol:
RoleName1 RoleName2
Entity-Type1 Relship-Type Entity-Type2
A1 . . . An
Beispiel
Manager
Employee Manages Department
StartDate
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-22
11Mehrstellige Relationen
• Relationen können auch mehrstellig sein, d.h. mehr als zwei Entitätstypen
verbinden (ternäre Relationen, vierstellige Relationen, etc.)
Dozent
empfiehlt
Buch Vorlesung
Ausprägung: empfiehlt (Schuldt, Kemper&Eickler-Datenbanksysteme, Datenbanken)
empfiehlt (Vetter, Mössenböck-Sprechen Sie Java?, Programmieren I)
empfiehlt (Kant, Kritik der reinen Vernunft, Philosophie I)
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-23
Schlüssel in Beziehungstypen …
• Schlüssel eines Beziehungstyps: Eine Teilmenge K der Vereinigung Ki der
Identifikationsschlüssel K1, ..., Kn der betroffenen Entitätstypen T1, ..., Tn heisst
Schlüssel(-kandidat) des Beziehungstyps B, wenn sich zu jedem Zeitpunkt je zwei
verschiedene Beziehungen b und b‘ von ext(B) bezüglich K unterscheiden
müssen, und es keine echte Teilmenge von K gibt, die diese Eigenschaft hat.
Falls mehrere Schlüsselkandidaten existieren, wird einer zum
Identifikationsschlüssel von B erklärt.
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-24
12… Schlüssel in Beziehungstypen
• Beispiel 1:
Beziehungstyp: Lagerung = ‚ Lagerprod:Produkt, Lagerort:Ort Ú
PNr ist ein Schlüsselkandidat von Lagerung, falls ein Produkt immer nur an einem
Ort gelagert wird. Andernfalls ist {PNr,OrtNr} ein Schlüsselkandidat von Lagerung.
• Beispiel 2: Schlüssel?
Prüfling Prüfer
Studierender Prüfung Professor
Note Prüfungsfach
Mat.-Nr. Name
Vorlesung
Nummer
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-25
Objekttyp oder Beziehungstyp?
• Grundsätzlich gilt, dass jeder Beziehungstyp mit Attributen auch als Entitätstyp
eingeführt werden könnte.
• Beispiel: Kunden (KNr) bestellen Produkte (PNr) zu einem bestimmten Datum in
einer bestimmten Menge. Es sollen fortlaufend die Bestellungen nummeriert
werden (BestNr)
Variante 1:
Kunde Bestellung Produkt
Datum Menge
BestNr
• Nachteile/Fehler?
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-26
13Beziehungstyp wird Objekttyp
• Variante 2: Einführung eines Entitätstyps „Bestellungen“
Regel: Eine komplizierter, durch viele Attribute beschriebener Beziehungstyp sollte
besser in einen Entitätstyp überführt werden; dann werden nur einfache binäre
Beziehungen zwischen den ursprünglichen Entitätstypen und dem neuen
Entitätstyp benötigt
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-27
Kardinalitätsrestriktionen
Schritt 4: Festlegung der Arten der Beziehungstypen, also zusätzliche einfache
Integritätsbedingungen
• Kardinalitätsbedingungen:
Eine Kardinalitätsbedingung (cardinality constraint) für die Teilnahme eines
Entitätstyps E in einem Beziehungstyp B legt fest, wie häufig eine Entität vom Typ
E in B mindestens vorkommen muss (minimale Kardinalität) und/oder wie häufig
sie höchstens vorkommen darf (maximale Kardinalität).
• In einem ER-Diagramm wird die Kante zwischen einem Entitätstyp E und einem
Beziehungstyp B mit (min,max) annotiert, wobei min die minimale und max die
maximale Kardinalität bezeichnen. Wenn die maximale Kardinalität nicht
spezifiziert wird, steht für max das Symbol * („don‘t care“).
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-28
14Beispiel zu Kardinalitätsrestriktionen …
works-for
(1,1) (2,*)
Employee Department
(0,1) (1,1)
manages
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-29
… Beispiel zu Kardinalitätsrestriktionen
Beispielausprägung zu ERM-Diagramm der vorigen Seite:
works-for
Employee Department
manages
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-30
15Gegenüberstellung üblicher Sprechweisen
• In der Praxis sind für die minimale Kardinalität meist nur die Werte 0
(“optional participation”) und 1 (“mandatory participation”) relevant, für die
maximale Kardinalität nur die Werte 1 und * . Die Teilnahme von E1 in R heisst
optional, falls die minimale Kardinalität von E1 in R null ist und obligatorisch sonst.
• Gegenüberstellung:
Art der Beziehung R zwischen Kardinalität von E1 in R Kardinalität von E2 in R
E1 und E2 (Kurzform)
1 : 1 – Beziehung (0,1) oder (1,1) (0,1) oder (1,1)
1 : N – Beziehung (0,*) oder (1,*) (0,1) oder (1,1)
N : 1 – Beziehung (0,1) oder (1,1) (0,*) oder (1,*)
M : N – Beziehung (0,*) oder (1,*) (0, *) oder (1,*)
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-31
1:1-Beziehung (one-to-one-relationship)
Angestellter leitet Abteilung
(0,1) (1,1)
• Charakteristik:
Jedes Objekt aus dem linken Entitätstyp steht in Beziehung zu keinem oder genau
einem Objekt aus dem rechten Entitätstyp und umgekehrt.
• Im Beispiel hat jede Abteilung genau einen Leiter und kein Angestellter leitet
mehrere Abteilungen
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-32
16m:1-Beziehung (many-to-one-relationship)
Angestellter arbeitet_in Abteilung
(1,1) (2,*)
• Charakteristik:
Jedes Objekt auf der "many"-Seite steht in Beziehung zu höchstens einem
Objekt auf der "one"-Seite (im Allgemeinen nicht umgekehrt)
• Jeder Angestellte arbeitet in genau einer Abteilung; in jeder Abteilung arbeiten
beliebig viele Angestellte (aber mindestens zwei)
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-33
m:n-Beziehung (many-to-many-relationship)
Studierender belegt Vorlesung
(1,*) (1,*)
• Charakteristik:
Jedes Objekt auf der linken Seite kann zu mehreren Objekten auf der rechten
Seite in Beziehung stehen (d.h. keine Einschränkung)
Beispiel-Ausprägung:
belegt (Wirth, Algorithmen und Datenstrukturen)
belegt (Wirth, Programmieren I)
belegt (Kant, Grundlagen der Philosophie)
belegt (Bernoulli, Mathematik I)
belegt (Euler, Mathematik I)
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-34
17Umwandlung Beziehungstyp in Objekttyp & binäre Beziehungstypen
• Ein n-ärer Beziehungstyp R zwischen n Entitätstypen E1, ..., En kann immer als
eigenständiger Entitätstyp R und n binären Beziehungstypen zwischen R und Ei
(1 § i § n) dargestellt werden, wobei für R ein neuer künstlicher
Identifikationsschlüssel eingeführt wird.
(0,*) (0,*)
Buyer Trade Commodity
(0,*)
Seller
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-35
Umwandlung Beziehungstyp in Objekttyp & binäre Beziehungstypen
(0,*) (1,1) (1,1) (0,*)
Buyer buys Trade what Commodity
(1,1)
sells
(0,*)
Seller
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-36
18Rekursive Beziehungstypen …
• Ein Beziehungstyp kann auch zwei oder mehr gleiche Entitätstypen verbinden.
• Er heisst dann oft rekursiver Beziehungstyp. Hierzu muss man Rollennamen für
die jeweilige Rolle des Entitätstyps einführen.
• Rekursive Beziehungstypen können ebenfalls Attribute besitzen
Angestellter Bauteil
(0,1) (0,*) (0,*) (0,*)
Untergebener Vorgesetzter Oberteil Unterteil
Dienst-
Stückliste
verhältnis
Anzahl UT
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-37
… Rekursive Beziehungstypen
• Beispiel
welche
(0,*)
Voraus-
Vorlesung
setzung
(0,*)
wofür
Ausprägung:
Voraussetzung (Programmieren I, Algorithmen und Datenstrukturen)
Voraussetzung (Programmieren II, Programmieren I)
Voraussetzung (Programmieren II, Algorithmen und Datenstrukturen)
Voraussetzung (Logik, Grundlagen der Philosophie)
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-38
19Schwacher Entitätstyp (Weak Entity Type)
• Ein Entitätstyp W heisst schwach (weak), wenn er in einer strengen
hierarchischen Beziehung zu einem Entitätstyp S steht, d.h. bei Kardinalität (1,1),
und wenn zur Identifikation der Entitäten von W der Primärschlüssel des
Entitätstyps S herbeigezogen wird (er nicht allein existenzfähig ist).
Gebäude Geb.Nr. Gebäude Geb.Nr.
(1,*)
liegt_in
(1,1)
Raum RaumNr. Raum RaumNr.
Ursprüngliche Notation nach Chen vereinfachte Notation
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-39
Beispiel (die etwas vereinfachte Universität)
• Die Mitglieder einer Universität setzen sich aus Studierenden und Angestellten
zusammen. Angestellte sind entweder Professoren oder Assistierende.
• Die Fakultätsbibliotheken (charakterisiert durch den Namen der Fakultät)
besitzen mehrere Dokumente. Dies können entweder Master-Arbeiten,
Dissertationen oder Lehrbücher sein. Alle Dokumente besitzen eine eindeutige
Signatur, einen Titel und ein Erscheinungsjahr. Dokumente werden natürlich
von Personen verfasst und können von Universitäts-Mitgliedern entliehen
werden (mit einem Ausleih- und Rückgabedatum). Jede Fakultätsbibliothek wird
von genau einem Uni-Mitglied geleitet
• Master-Arbeiten werden von mindestens einem Assistierenden betreut;
es gibt aber auch Assistierende ohne Betreuungsaufgaben.
• Dissertationen werden von Professoren betreut und bewertet. Zu jeder
Dissertation gibt es genau einen Betreuer und zwei bis fünf Professoren,
welche die Arbeit bewerten.
• Lehrbücher werden von Professoren im Rahmen ihrer Vorlesungen empfohlen
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-40
20Beispiel: Modellierung in EERM
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-41
UML
• In den letzten Jahren hat sich UML als Modellierungssprache durchgesetzt,
hauptsächlich wegen der ganzheitlichen Modellierung von Software (durch die
Unterstützung der unterschiedlichen Diagrammtypen)
• Unterschiede zum ERM (EERM):
– Attribute werden direkt im Entity-Kasten notiert
– Es existiert kein eigenes Symbol für Relationships (nur eine Kante zwischen
den Kästchen)
Ausnahme: ternäre/mehrstellige Relationships mit Raute
– Verschiedene Vererbungsbeziehungen
– Notation der Kardinalitäten (an gegenüberliegender Seite)
– (Methoden: Nicht gebraucht bei DB-Modellierung)
Angestellter Abteilung
Personalnr: int arbeitet in Abteilungsnr: int
Name: string 0..* 1 Bezeichn: string
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-42
21UML: Komplette Spezifikation von Attributen
• In der vollständigen Form lautet die Syntax eines Attributs in UML wie folgt
(eckige Klammern bezeichnen dabei optionale Angaben)
[Sichtbarkeit] Name [Multiplizität] [: Typ]
[= Anfangswert] [{Änderbarkeit}] [{Zusicherung}]
Beispiel (Rechteck):
Rechteck
+ Name : String {frozen}
Farbe : {rot, gruen, blau} = gruen
# Eckpunkt [4 .. 4] {ordered} : Punkt
- Kante_x : Integer {changeable} {Kante_x > 0}
- Kante_y : Integer {changeable} {Kante_y > 0}
/ Flaecheninhalt : Integer { Flaecheninhalt =
Kante_x * Kante_y}
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-43
UML: Assoziationen und reflexive Assoziationen
• UML-Notation für
Assoziationen
Reflexive Assoziation
(auch als rekursive Assoziation
bezeichnet)
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-44
22UML: Kardinalitäten von Assoziationen ...
• Die Kardinalität einer Assoziation gibt an, mit wie vielen Objekten des
gegenüberliegenden Entitätstyps ein Objekt assoziiert sein kann. Diese
Angabe ist auf beiden Seiten einer Assoziation möglich.
Hierzu wird dieselbe Notation wie für die Multiplizität von Attributen verwendet
• UML-Notation für Kardinalitäten
Anzahl der Klasse_1-Objekte, Anzahl der Klasse_2-Objekte,
die ein Klasse_2-Objekt kennt die ein Klasse_1-Objekt kennt
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-45
... UML: Kardinalitäten von Assoziationen ...
Arten von Assoziationen:
Beispiele: Zwischen einem beliebigen B-Objekt und einem Objekt der Klasse A
gibt es:
• Genau eine Beziehung (Muss-Beziehung)
• null, eine oder beliebig viele Beziehungen
(Kann-Beziehung)
• Null oder eine Beziehung (Kann-Beziehung)
• Eine oder mehrere Beziehungen
(Muss-Beziehung)
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-46
23... UML: Kardinalitäten von Assoziationen ...
Beispiele (Fortsetzung): Zwischen einem beliebigen B-Objekt und einem Objekt
der Klasse_A gibt es:
• Drei oder mehr als drei Beziehungen
(Muss-Beziehung)
• Null bis fünf Beziehungen
(Kann-Beziehung)
• Genau vier Beziehungen (Muss-Beziehung)
• Eine, drei oder fünf Beziehungen
(Muss-Beziehung)
• Nicht keine, nicht fünf, sechs oder acht Beziehungen
(Muss-Beziehung)
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-47
... UML: Kardinalitäten von Assoziationen
Beispiel
• Ein Kunde kann mehrere Zahlungsverzüge besitzen, aber
jeder Zahlungsverzug gehört zu genau einem Kunden
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-48
24UML: Assoziationsnamen
• Assoziationen können benannt werden; dies ist in jeder Richtung mit einem
unterschiedlichen Bezeichner möglich
• Zusätzlich zum Namen der Assoziation wird dann mittels eines bzw.
angegeben, in welcher Richtung dieser Name angewandt werden muss
Beispiel: benannte Kann-und Muss-Assoziationen
„Ein Kunde kann beliebig viele Aufträge erteilen,
ein Auftrag gehört jedoch zu genau einem Kunden“
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-49
UML: Rollen ...
• Eine Rolle beschreibt, welche Funktion ein Objekt in einer Assoziation übernimmt
• Die Rolle wird an die Assoziation, auf der Seite der jeweiligen Entität geschrieben
Beispiel: Eine Firma besitzt als Arbeitgeber mehrere Mitarbeiter
(Arbeitnehmer). Jeder Mitarbeiter kann einen PKW als Dienstwagen
fahren.
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-50
25... UML: Rollen
• Rollennamen können natürlich auch in einer reflexiven Assoziation angegeben
werden
• Zusätzlich sind immer auch (nicht nur bei reflexiven Assoziationen)
Zusicherungen (assertions) möglich, die an die Assoziation geheftet werden
Beispiel: Sowie Chef als auch Mitarbeiter sind Angestellte; allerdings besitzt
der Chef ein höheres Gehalt als der Mitarbeiter
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-51
Ternäre Assoziationen, n-gliedrige Assoziationen ...
• Neben den (normalen) binären Assoziationen, die zwei Entitätstypen verbinden,
gibt es auch Assoziationen, die drei oder mehrere Entitätstypen verbinden
(ternäre bzw. n-gliedrige Assoziationen).
• Als grafisches Element für n-gliedrige Assoziationen steht eine Raute zur
Verfügung, die mit den beteiligten Entitätstypen durch Linien verbunden ist
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-52
26... Ternäre Assoziationen, n-gliedrige Assoziationen
Beispiel für eine ternäre Assoziation:
Reservierung eines Sitzplatzes in einem Zug. Reservierung besteht
aus einem Fahrgast, einem Zug und einem Platz in diesem Zug. Ein
Platz in einem Zug kann (nacheinander) von mehreren Fahrgästen
reserviert werden, ein Fahrgast hat in einem Zug genau eine
Platzreservierung und ein Fahrgast kann einen Platz in mehreren
Zügen reservieren.
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-53
Beispielmodell (Folien #DB-2-40 und #DB-2-41) in UML
HS 2011 Datenbanken (CS241) / Web Data Management (CS261) – Datenbankentwurf DB-2-54
27Sie können auch lesen
