Teil 2 -

Teil 2
5. Vorlesung
Modul: Programmierung B-PRG
Grundlagen der Programmierung II
Professur für Datenbanken und Informationssysteme
Dr. Karsten Tolle
[email protected]
1
Anmeldung zur Klausur
Bis spätestens zum 16.07. anmelden!
… was passiert dann? Raumzuordnung wird
erstellt. Dort prüfen wo man schreibt!
Klausur ist
Freitag den
23. Juli
2
Grundlagen der Programmierung II
DBIS - SS2010
Literatur
• Folien/Übungen zu DB1 und DB2 sind online zugänglich
• Bib. unter H, Treppe hoch, dann lauft ihr in DB-Bücher
3
Grundlagen der Programmierung II
DBIS - SS2010
Fahrplan
Heute:
• ER
• relationales Modell
Nächste Woche:
• FDs und NFs
• SQL
Letzte Vorlesung:
• Diverses
• Fragen und Antworten
4
Grundlagen der Programmierung II
DBIS - SS2010
Entity-Relationship Modell (E-R Model)
• P. Chen (ACM Artikel von 1976: The Entity
Relationship Model – Toward A Unified View of
Data)
• Einfache graphische Darstellung der Welt
5
Grundlagen der Programmierung II
DBIS - SS2010
Die Welt …
Otto Müller lebt in Frankfurt am Main, in
der Robert-Mayer-Str. 11. Er hat ein
Flug nach Kapstadt gebucht.
Person
lebt_in
Haus
lebt_in
6
Grundlagen der Programmierung II
DBIS - SS2010
Das Entity-Relationship Modell
Aus der Sicht des Objekt-Beziehungs-Modells (Entity-Relationship-Model)
besteht die Welt aus Objekten (Entities) und Beziehungen
(Relationships) zwischen diesen Objekten.
Objekt (Entity):
Modell eines Dings, das in der Umwelt erkannt und eindeutig identifiziert
werden kann.
Modellierungskonzept der Klassifikation:
Objekte werden zu Objekttypen (Entity-Typs), und Beziehungen zu
Beziehungstypen (Relationship-Typs) zusammengefasst.
7
Grundlagen der Programmierung II
DBIS - SS2010
Begriffe im Alltag
Achtung: Die Begriffe
• Entity und Entity-Typ
• Beziehung (Relation) und Beziehungstyp
(Relationship-Typ)
werden im Alltag oft als Synonyme verwendet.
8
Grundlagen der Programmierung II
DBIS - SS2010
(Objekt) Attribute
Ein Objekttyp ist durch einen bestimmten Satz
von Merkmalen (Attributen) gekennzeichnet.
Jedes Merkmal kann Werte (values), das sind in
der Umwelt beobachtbare oder messbare
Größen, aus einem bestimmten Wertebereich
(value set) annehmen.
Beispiel:
Passagier
Name
Freigepäck
Status
Otto Müller
20kg
Economy Class
9
Grundlagen der Programmierung II
DBIS - SS2010
Wichtig!
Ein Beziehungstyp zwischen zwei Entity-Typen
kann eine mathematische Relation aufgefasst
werden.
Name
Geb_Datum
Instanz:
Person
Stadt
lebt_in
10
Person
lebt_in
Stadt
S_Name
Population
= { p1, p2, p3 }
= { c1, c2, c3 }
= { <p1,c1>, <p2,c3>, <p3,c3> }
Grundlagen der Programmierung II
DBIS - SS2010
Min/Max Kardinalitäten
(1,1)
Person
(0,n)
lebt_in
Stadt
• min_card(Person, Lebt_in) = 1
• max_card(Person, Lebt_in) = 1
• min_card(Stadt, Lebt_in) = 0
• max_card(Stadt, Lebt_in) = n
• p1
• c1
• p2
• c2
• p3
• c3
Es gilt immer: min_card <= max_card!
• c4
Person,
verbindlich
Stadt,
optional
Bem.: Es gibt andere Notationen, z.B. wird manchmal nur max_card angegeben.
11
Grundlagen der Programmierung II
DBIS - SS2010
Kardinalitäten
Instanz:
Person
Stadt
lebt_in
= { p1, p2, p3 }
= { c1, c2, c3 }
= { <p1,c1>, <p2,c3>, <p3,c3> }
• p1
• c1
• p2
• c2
• p3
Instanz:
Person
Stadt
lebt_in
• c3
= { p1, p2, p3, p4}
= { c1, c2, c3, c4, c5 }
= { <p1,c1>, <p2,c1>, <p3,c3>, <p1, c4> }
• p1
• c1
• p2
• c2
• p3
• c3
• p4
• c4
• c5
Person
Name
Geb_Datum
Person
12
Stadt
(1,1)
lebt_in
(1,1)
Stadt
Person
S_Name
Population
Name
Geb_Datum
Grundlagen der Programmierung II
Person
Stadt
(0,n)
lebt_in
(0,n)
Stadt
S_Name
Population
DBIS - SS2010
Klassifizierung der Beziehungstypen
• one-to-one (max_card auf beiden Seiten = 1)
(1,1)
Person
(0,1)
lebt_in
Stadt
• one-to-many (max_card auf einer Seiten = 1, auf der anderen n)
(0,1)
Person
(0,n)
lebt_in
Stadt
• many-to-many (max_card auf beiden Seiten n)
(0,n)
Person
13
(1,n)
lebt_in
Grundlagen der Programmierung II
Stadt
DBIS - SS2010
(Beziehungs) Attribute
Eine Beziehung kann durch Merkmale (Attribute)
gekennzeichnet werden.
Die Funktion, die ein Objekt in einer
Beziehung erfüllt, nennt man seine Rolle.
Beispiel:
Rolle
Gebuchter_Passagier
PASSAGIER
Gebuchter_Flug
bucht
FLUG
SITZNR.
14
Grundlagen der Programmierung II
DBIS - SS2010
(Beziehungs) Attribute
Instanz:
Passagier = { p1, p2, p3 }
Flug
= { c1, c2, c3 }
bucht
= { <p1,c1, „D2“>, <p2,c1, „D3“>}
D2
D1
• p1
D2
• c1
• p2
D3
• c2
• p3
• c3
• c4
Gebuchter_Passagier
PASSAGIER
Gebuchter_Flug
bucht
FLUG
Passagier
Flug
SITZNR.
15
Grundlagen der Programmierung II
DBIS - SS2010
Die Uni …
Studenten können sich von Professoren über eine
Vorlesung mündlich prüfen lassen.
Alt. 1:
Name
Geb_Datum
Student
prüft
Prof
Name
Gehalt
Vorlesung
Alt. 2:
(N-näre Beziehung)
16
Name
Geb_Datum
Student
Titel
SWS
prüft
Prof
Name
Gehalt
Vorlesung
Grundlagen der Programmierung II
DBIS - SS2010
Zusammengesetzte Attribute
Aggregation von Attributen die etwas gemeinsam
haben, z.B.:
Person
17
A
d
r
e
s
s
e
Strasse
Nummer
Ort
PLZ
Grundlagen der Programmierung II
DBIS - SS2010
Generalisierung
Hierarchien für Entity-Typen (entspricht
Klassenhierarchy in OO)
Person
Mann
18
Frau
Grundlagen der Programmierung II
DBIS - SS2010
Schlüssel
Ein Schlüssel besteht aus einer Menge von
Attributen, deren Werte eine Instanz (Entity)
eines Entity-Types eindeutig bestimmt.
Name
Person
Personalausweisnummer
Person
Geb.Ort
Name
Name des
Vaters
einfacher Schlüssel
19
Geb.Datum
zusammengesetzter Schlüssel
Grundlagen der Programmierung II
DBIS - SS2010
ER Zusammenfassung
• Entitäten und Entity-Typen
• Beziehungen und Beziehungstypen
• Attribute
• für Entitäten(Typen) und Beziehungen(Typen)
• einfach oder zusammengesetzt
• ausgezeichnet als Schlüssel
• Kardinalitäten
• Generalisierung
20
Grundlagen der Programmierung II
DBIS - SS2010
Entity-Typ oder Attribut???
Möbelstück
Farbe
Möbelstück
hat
Farbe
•
Entities sind Klassen von Objekten der realen Welt und nehmen keine Werte an.
•
Attribute dagegen sind beschreibende Eigenschaften und nehmen Werte an.
Die Entscheidung ist abhängig vom Kontext (Situation/Anwendungsfall).
Farbe
Nr.
21
(1,n)
Name
Intensität
besteht
aus
Menge
(1,n)
Lack
Name
Grundlagen der Programmierung II
Preis
DBIS - SS2010
B
Professor
hält
A
B-D
Lehrveranst.
A-C
A-D
B-E
hält
hält
B-C
D
Ausbilder
hält
Seminar
C
besser so …
besser so …
A-C
Personal
Lehrer
Lehrveranst.
Ausbilder
Grundlagen der Programmierung II
A-E
D
E
B-D
Seminar
B-C
22
A
A-D
C
Professor
A-E
E
B
B-E
Ausdruckskraft
Ein Angestellter einer Abteilung soll nicht mehr
verdienen, als der entsprechende Abteilungsleiter.
Gehalt
arbeitet_
in
Angesteller
Abteilung
leitet
Benötigt zusätzliche Beschreibung,
sogenannte Business Rules.
Ein Angestellter darf nicht mehr Gehalt bekommen als der Abteilungsleiter,
zu dessen Abteilung der Angestellte gehört.
Ein Abteilungsleiter muss zu der Abteilung gehören, die er leitet.
23
Grundlagen der Programmierung II
DBIS - SS2010
Business Rules (im weitesten Sinne) können angesehen werden als:
1. Die semantische Definition eines für Anwendungen relevanten Konzeptes,
genauer, die semantische Definition
•
eines Objektes,
•
eines Attributes
•
Relation
oder einer
des ER-Modells.
Für diesen Fall werden natürlich sprachliche Sätze verwendet, da es
unmöglich ist hierfür eine präzise Syntax zu definieren.
2. Integritätsbedingungen für die Daten einer Anwendung (als zusätzliche
Beschreibung der im ER-Modell enthaltenen Bedingungen oder
zusätzliche Bedingungen).
3. Abgeleitete Bedingungen bzw. Folgerungen aus anderen Bedingungen
(z.B. Brutto ist Summe aus Netto plus Steuer).
24
Grundlagen der Programmierung II
DBIS - SS2010
NAME
PERSON
AGE
(1 , n )
FAN
COACH
(1 ,1 )
PLAYER
(1 ,1)
SUPPORTS
( 1, n )
PRESIDENT
(1 ,1 )
(1 ,1 )
MANAGES
PLAYS _ FOR
(1 ,1 )
(1 , n)
IS_ PRESIDENT
(1 ,1 )
TEAM
NAME
(1 ,n )
( 1 ,n )
( 1 ,n )
DATE
PRACTICES
PLAYS _
AG AINST
( 1 ,n)
(1 ,n)
( 1 ,1 )
ATTENDS
NUMBER
GAME
TAKES
PLACE _ AT
DATE
FINAL_SCORE (0, 1)
ATTENDAN CE (0,1)
TIME
25
LOCATION
( 0 ,n )
Grundlagen der Programmierung II
STADIUM
SIZE
NAME
NAME
STATE
( 0, n)
( 1 ,1 )
BIRT HPLACE
_OF
CITY
PERSON
LAST_NAME
AGE
NAME
( 0, n)
TELEPHONE
( 1 ,n )
RESIDENCE_
CITY_OF
DEPARTMENT
BELONGS_T O
( 1 ,1)
( 1 ,1)
STUDENT
( 0 ,n)
PROFESSOR
( 0, n)
(0 ,n )
SEMESTER
SEMEST ER
ENROLLED
PLANNED
GRADUATE_
STUDENT
( 1, 1)
ADVISED_
BY
GRADE
START_APPOINTMENT
T ERMINATE_
APPOINTMENT
( 1 ,n)
(1 ,n )
( 1 ,n)
COURSE
TAUGHT_
BY
(1, 2 )
VISITING_
PROFESSOR
TITLE
( 3, 5)
MEET S
(1, n )
ROOM
(1, n)
26
DAY
TIME
Grundlagen
der Programmierung II
HOUR
ROOM_NO
BUILDING
27
Grundlagen der Programmierung II
28
Grundlagen der Programmierung II
Relationales Datenmodell
Nach Edgar F. Codd definiert sich ein Datenbankmodell aus drei
Eigenschaften:
•
Einer generischen Datenstruktur, die die Struktur einer Datenbank
beschreibt.
•
Einer Menge von generischen Operatoren, die man bei beliebigen
Schemata auf die Datenstrukturen anwenden kann, um Daten einzutragen,
zu ändern, abzufragen oder abzuleiten.
•
Einer Menge von Integritätsbedingungen, mit denen man die zulässigen
Datenbankinhalte über die Grundstrukturen hinaus weiter einschränken
kann.
Dem Relationalen Datenmodell (E.F. Codd, 1970) liegt die
mengentheoretische Relation zugrunde.
29
Grundlagen der Programmierung II
DBIS - SS2010
Relationales Datenmodell
Tabellen mit Zeilen und Spalten um die Daten
darzustellen.
Attribute
Employee
Tupel
EMPNO
FIRSTNME
LASTNME
PHONENO
SALARY
001
Jon
Lucas
2983
2000
003
Jon
Smith
2980
3588
103
Lucas
Jon
4444
3980
999
Jon
Smith
3987
1500
Schema (Relationenschema):
Employee(EMPNO, FIRSTNME, LASTNME, PHONENO, SALARY)
DBIS - SS2010
Formalisierung des Relationenmodells I
Definition:
Ein Relationenschema R ist eine endliche Menge von
Attributnamen {A1, A2 , ..., An}.
Notation:
R = {A1, A2 , ..., An} oder
R(A1, A2 , ..., An)
Attributnamen können auch verkürzt nur als Attribute
bezeichnet werden.
31
Grundlagen der Programmierung II
DBIS - SS2010
Formalisierung des Relationenmodells II
Definition:
Zu jedem Attribut Ai, 1 ≤ i ≤ n, gibt es eine
Menge Di, den Wertebereich (domain) von Ai.
Notation:
dom(Ai) ist der Wertebereich von Ai.
Beispiel:
Das Attribut GESCHLECHT hat den Wertebereich
dom(GESCHLECHT) = {männlich, weiblich}.
32
Grundlagen der Programmierung II
DBIS - SS2010
Formalisierung des Relationenmodells III
Definition:
Sei D = D1 × D2 × D3 × ... × Dn das kartesische Produkt der
Domänen D1, D2, D3, ..., Dn.
Eine Relation r auf einem Relationenschema R, bezeichnet mit
r(R), ist eine endliche Menge von Abbildungen {t1, ..., tn} von R
nach D, wobei für jede Abbildung t ∈ r, der Wert t(i) aus der
Domäne Di, 1 ≤ i ≤ n, stammt.
Diese Abbildungen werden Tupel genannt. Der Wert eines Tupels t
für ein Attribut A, t(A) = a, heißt A-Wert von t.
33
Grundlagen der Programmierung II
DBIS - SS2010
Relationales Datenmodell
Tabellen mit Zeilen und Spalten um die Daten darzustellen.
Attribute
Employee
Tupel t
EMPNO
FIRSTNME
LASTNME
PHONENO
SALARY
001
Jon
Lucas
2983
2000
003
Jon
Smith
2980
3588
103
Lucas
Jon
4444
3980
999
Jon
Smith
3987
1500
t(EMPNO) = 001
t(FIRSTNME) = Jon
dom(SALARY) = „Werte,
die als mögliche Gehälter
in Frage kommen“
DBIS - SS2010
Relationales Datenmodell
Employee
Tupel t
t 1, t 2
EMPNO
FIRSTNME
LASTNME
PHONENO
SALARY
001
Jon
Lucas
2983
2000
003
Jon
Smith
2980
3588
103
Lucas
Jon
4444
3980
999
Jon
Smith
3987
1500
t(EMPNO, FIRSTNME) = (001, Jon)
t1, t2 ∈ r und
t1(FIRSTNME, LASTNME) = t2(FIRSTNME, LASTNME)
DBIS - SS2010
Bemerkungen
• Relationen sind Abstraktionen von Teilen der realen
Welt.
• Relationen sind veränderlich, sie ändern ihren
Zustand in der Zeit
Einfügen, Löschen, Ändern von Tupeln
• Relationenschemata sind unveränderlich
• Sind den Spalten einer Relation Attributnamen
zugeordnet, so ist deren Reihenfolge unwichtig.
(In der Definition der Relation auf S. 5 ist die
Reihenfolge der Spalten wichtig.)
36
Grundlagen der Programmierung II
DBIS - SS2010
Schlüssel
Ein Schlüssel identifiziert eine Entität. Er besteht aus
einer Menge von Attributen, deren Werte alle Instanzen
einer Entität eindeutig bestimmen. (aus ER!)
Ein Schlüssel (key) einer Relation r(R) ist eine minimale
Teilmenge K von R, so dass für je zwei verschiedene
Tupel t1, t2 ∈ r gilt:
• t1(K) ≠ t2(K)
und
• keine echte Teilmenge K' von K hat diese Eigenschaft.
Ein Schlüssel kann als Integritätsbedingung angesehen
werden. Falls K Schlüssel von r(R), t1 ∈ r, t1(K) = t2(K),
t1 ≠ t2 dann dürfte t2 nicht in r(R) eingefügt werden.
37
Grundlagen der Programmierung II
DBIS - SS2010
Oberschlüssel
K ist ein Oberschlüssel (super key) der Relation,
falls K einen Schlüssel enthält.
… also aus Schlüssel Oberschlüssel (aber nicht umgekehrt)
Oberschlüssel
Schlüssel
38
Grundlagen der Programmierung II
DBIS - SS2010
Beachte!!!
=
EMPNO
FIRSTNME
LASTNME
PHONENO
SALARY
001
Jon
Lucas
2983
2000
003
Jon
Smith
2980
3588
103
Lucas
Jon
4444
3980
001
Jon
Lucas
2983
2000
im mathematischen
mengentheoretischen Modell
39
EMPNO
FIRSTNME
LASTNME
PHONENO
SALARY
001
Jon
Lucas
2983
2000
003
Jon
Smith
2980
3588
103
Lucas
Jon
4444
3980
Grundlagen der Programmierung II
DBIS - SS2010
• Schlüssel, die explizit zu einem Relationenschema
angeführt sind, heißen ausgezeichnete Schlüssel
(designated keys).
• Eine Relation kann mehrere Schlüssel besitzen. Man
spricht dann von Schlüsselkandidaten.
• Im Allgemeinen wird ein Schlüssel als Primärschlüssel
ausgezeichnet.
• Dieser wird im Relationenschema durch
Unterstreichen gekennzeichnet.
40
Grundlagen der Programmierung II
DBIS - SS2010
ER-Abbildung zu Relationen
Entitätstypen
Ein Entitätstyp wird zu einer Relation (Tabelle), dessen
Relationenschema aus allen Attributen des Entitätstyp besteht.
Jedes Tupel der Tabelle entspricht dann genau einer Entität des
Entitätstyps.
Etwaige Schlüssel werden übernommen und üblicherweise an den
Anfang des Relationenschemas gestellt.
„Regel“:
Schlüssel
Attribut_A
Attribut_B
Entitätstyp E
E (Schlüssel, Attribut_A, Attribut_B)
41
Grundlagen der Programmierung II
DBIS - SS2010
Beispiel
Angestellter
Pers.Nr. Name Vorname
ANGESTELLTER (Pers.Nr., Name, Vorname)
ANGESTELLTER
42
PersNr
Name
Vorname
001
Jon
Lucas
003
Jon
Smith
103
Lucas
Jon
Grundlagen der Programmierung II
DBIS - SS2010
many-to-many
B
Schlüssel1
A_1
Entität_1
Schlüssel2
A_2
(0:n)
Beziehung
(0:n)
Entität_2
ENTITÄT_1 (Schlüssel1, A_1)
ENTITÄT_2 (Schlüssel2, A_2)
BEZIEHUNG (Schlüssel1, Schlüssel2, B)
43
Grundlagen der Programmierung II
DBIS - SS2010
Beispiel
seit
Person
AusweisNr.
(0:n)
lebt_in
(0:n)
Ort
PLZ
Name Vorname
Ortsname
44
PERSON
(AusweisNr., Name, Vorname)
ORT
(PLZ, Ortsname)
LEBT_IN
(AusweisNr., PLZ, seit)
Grundlagen der Programmierung II
DBIS - SS2010
Beispiel mit Instanzen
PERSON
Ort
AusweisNr
Name
Vorname
PLZ
Ortsname
001
Jon
Lucas
501
Buli
003
Jon
Smith
503
Wali
103
Lucas
Jon
603
Kali
LEBT_IN
AusweisNr
PLZ
seit
001
501
23.12.2000
003
501
17.08.2004
001
503
01.01.1999
Jon Lucas (001) lebt_in Buli (501), seit dem 23.12.2000!
45
Grundlagen der Programmierung II
DBIS - SS2010
one-to-many (min_card = 0)
B
Schlüssel1
A_1
Entität_1
Schlüssel2
A_2
(0:1)
Beziehung
(0:n)
Entität_2
ENTITÄT_1 (Schlüssel1, A_1)
ENTITÄT_2 (Schlüssel2, A_2)
BEZIEHUNG (Schlüssel1, Schlüssel2, B)
46
Grundlagen der Programmierung II
DBIS - SS2010
Beispiel
Datum
(0:1)
Buch
BuchNr. Titel
verliehen
an
(0:n)
Entleiher
Nummer
Autor
Name
BUCH
ENTLEIHER
VERLIEHEN_AN
47
(BuchNr., Titel, Autor)
(Nummer, Name)
(BuchNr., Nummer, Datum)
Grundlagen der Programmierung II
DBIS - SS2010
one-to-many (min_card = 1)
B
Schlüssel1
A_1
Entität_1
Schlüssel2
A_2
(1:1)
Beziehung
(0:n)
Entität_2
ENTITÄT_1 (Schlüssel1, A_1, Schlüssel2, B)
ENTITÄT_2 (Schlüssel2, A_2)
Hier sind nur noch zwei Relationen notwendig!
48
Grundlagen der Programmierung II
DBIS - SS2010
Beispiel
Datum
Person
AusweisNr.
(1:1)
geboren
in
(0:n)
Ort
PLZ
Name Vorname
Ortsname
PERSON (AusweisNr., Name, Vorname, PLZ, Datum)
ORT (PLZ, Ortsname)
49
Grundlagen der Programmierung II
DBIS - SS2010
… aber auch möglich! (geht immer☺☺)
B
Schlüssel1
A_1
Entität_1
Schlüssel2
A_2
(1:1)
Beziehung
(0:n)
Entität_2
ENTITÄT_1(Schlüssel1, A_1)
ENTITÄT_2 (Schlüssel2, A_2)
Datum
BEZIEHUNG (Schlüssel1, Schlüssel2, B)
Person
AusweisNr.
(1:1)
geboren
in
(0:n)
Ort
PLZ
Name Vorname
Ortsname
PERSON (AusweisNr., Name, Vorname, PLZ, Datum)
ORT (PLZ, Ortsname)
GEBOREN_IN (AusweisNr., PLZ, Datum)
50
Grundlagen der Programmierung II
DBIS - SS2010
one-to-one
Eine one-to-one Beziehung kann wie eine one-to-many Beziehung in
beide Richtungen betrachtet werden.
Sind beide min-Kardinalitäten = 0, so muss das allgemeine Verfahren
angewendet werden.
Ist nur eine min-Kardinalität = 1, so wendet man die Abbildung der
one-to-many Beziehung an.
B
Schlüssel1
A_1
Schlüssel2
A_2
Entität_1
ENTITÄT_1
ENTITÄT_2
51
(1:1)
Beziehung
(0:1)
Entität_2
(Schlüssel1, A_1, Schlüssel2, B)
(Schlüssel2, A_2)
Grundlagen der Programmierung II
DBIS - SS2010
Beispiel
seit
Abteilung
AbteilungsNr.
(1:1)
geleitet
von
(0:1)
Bezeichnung
Mitarbeiter
Pers.Nr.
Name
ABTEILUNG
(AbteilungsNr., Bezeichnung, Pers.Nr., seit)
MITARBEITER (Pers.Nr., Name)
52
Grundlagen der Programmierung II
DBIS - SS2010
one-to-one (beide min-card = 1)
B
Schlüssel1
A_1
Entität_1
Schlüssel2
A_2
(1:1)
Beziehung
(1:1)
Entität_2
ENTITÄT_1_2 (Schlüssel1, A_1, Schlüssel2, A_2, B)
oder
ENTITÄT_1_2 (Schlüssel1, A_1, Schlüssel2, A_2, B)
Nur noch eine Relation notwendig!
53
Grundlagen der Programmierung II
DBIS - SS2010
Beispiel
AblaufDatum
(1:1)
Ausweis
gehört
(1:1)
AusweisNr. Behörde
Person
Name
Vorname
PERSON (AusweisNr., Behörde, Ablaufdatum, Name, Vorname)
54
Grundlagen der Programmierung II
DBIS - SS2010
Sonderfälle
(3:5)
Auto
KFZ-Kennzeichen
hat_Räder
(0:1)
Hersteller
Rad
Fabr.-Nr.
Breite
(Hier sind RAD1 – RAD3 verbindlich, also NOT NULL, während
RAD4 und RAD5 durchaus Nullwerte beinhalten dürfen.)
AUTO (KFZ-Kennzeichen, Hersteller, RAD1, ... RAD5)
RAD (Fabr.-Nr., Breite)
55
Grundlagen der Programmierung II
DBIS - SS2010
Abbildung der Generalisierung
Schlüssel
Attribut_A
Attribut_B
Oberklasse
Subklasse_1
Subklasse_2
Attribut_A_1
Attribut_B_1
Attribut_A_2
Hier: Drei Möglichkeiten mit unterschiedlichen
Vor- und Nachteilen!
56
Grundlagen der Programmierung II
DBIS - SS2010
1. Möglichkeit
Alle Entitätstypen zu eigenständigen Relationen, die alle für sie
relevanten Informationen beinhalten. Die Subklassen enthalten
neben ihren neuen Attributen noch alle Attribute ihrer Oberklasse.
Der Vorteil der Performance überwiegt nur in wenigen Fällen
gegenüber der entstehenden Redundanz, deren Gefahren der
Inkonsistenz und des zusätzlichen Speicherbedarfs.
Schlüssel
Attribut_A
Attribut_B
Kto.-Nr.
Kunde
Kto.Stand
Oberklasse
Subklasse_1
Attribut_A_1
Attribut_B_1
Konto
Subklasse_2
Girokonto
Attribut_A_2
Kreditrahmen
OBERKLASSE (Schlüssel, Attribut_A, Attribut_B)
SUBKLASSE_1 (Schlüssel, Attribut_A, Attribut_B,
Attribut_A_1, Attribut_B_1)
SUBKLASSE_2 (Schlüssel, Attribut_A, Attribut_B,
Attribut_A_2)
57
Sparkonto
Zinssatz
KONTO (Kto.Nr., Kunde, Kto.Stand)
GIROKONTO (Kto.Nr., Kunde, Kto.Stand, Kreditrahmen)
SPARKONTO (Kto.Nr., Kunde, Kto.Stand, Zinssatz)
Grundlagen der Programmierung II
DBIS - SS2010
2. Möglichkeit
Die Entitätsmengen, die die Subklassen bilden, beinhalten in ihrer
entstehenden Relation neben ihren eigenen Attributen nur noch
den Schlüssel der Oberklassen-Entitätsmenge. Damit lassen sich
alle Daten einer Subklassen-Entität durch einen natürlichen
Verbund (natural join) gewinnen.
Schlüssel
Attribut_A
Attribut_B
Kto.-Nr.
Kunde
Kto.Stand
Oberklasse
Subklasse_1
Attribut_A_1
Attribut_B_1
Konto
Subklasse_2
Girokonto
Attribut_A_2
Kreditrahmen
OBERKLASSE (Schlüssel, Attribut_A, Attribut_B)
SUBKLASSE_1 (Schlüssel, Attribut_A_1, Attribut_B_1)
SUBKLASSE_2 (Schlüssel, Attribut_A_2)
58
Sparkonto
Zinssatz
KONTO (Kto.Nr., Kunde, Kto.Stand)
GIROKONTO (Kto.Nr., Kreditrahmen)
SPARKONTO (Kto.Nr., Zinssatz)
Grundlagen der Programmierung II
DBIS - SS2010
3. Möglichkeit
Man erstellt eine Relation, die als Schema die Vereinigung der
Attribute aller Subklassen und der Oberklasse hat.
Die Attribute, die eine bestimmte Entität nicht hat, werden durch
Nullwerte ersetzt.
Schlüssel
Attribut_A
Attribut_B
Kto.-Nr.
Kunde
Kto.Stand
Oberklasse
Subklasse_1
Attribut_A_1
Attribut_B_1
Konto
Subklasse_2
Girokonto
Attribut_A_2
Kreditrahmen
KLASSE (Schlüssel, Attribut_A, Attribut_B,
Attribut_A_1, Attribut_B_1,
Attribut_A_2)
59
Sparkonto
Zinssatz
KONTO (Kto.Nr., Kunde, Kto.Stand,
Kreditrahmen, Zinssatz)
Grundlagen der Programmierung II
DBIS - SS2010
Größeres Beispiel
Pk-Nr
Name
Lohn
Abt-Nr.
Angestellter
beschäftigt
Abteilung
(1,1)
geleitet_von
(1,1)
seit
Manager
Außendienst
AT-Klasse
Datum
ANGESTELLTER (PK-NR, NAME, LOHN)
AUSSENDIENST (PK-NR)
ABT_MANAGER (ABT-NR, SEIT, PK-NR, AT-KLASSE)
BESCHÄFTIGT (ABT-NR, PK-NR)
POLICE (POLICE-NR, ART, NEHMER, SUMME,
DATUM, PK-NR)
60
Grundlagen der Programmierung II
verkauft
(1,1)
Police
Summe
Nehmer
Art
Police-Nr.
Schlüssel? … Kontext: Deutschland
ADRESSE
61
PLZ
Ort
StraßeNr
60308
Frankfurt
Kettenhofweg 23
63069
Offenbach
Bahnhofstr. 12
63069
Offenbach
Waldweg 34
Grundlagen der Programmierung II
DBIS - SS2010