Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
Teil 2-
5. Vorlesung
1
5. Vorlesung
Modul: Programmierung B-PRGGrundlagen der Programmierung II
Professur für Datenbanken und Informationssysteme Dr. Karsten Tolle
Anmeldung zur Klausur
Bis spätestens zum 16.07. anmelden!
… was passiert dann? � Raumzuordnung wird erstellt. Dort prüfen wo man schreibt!
DBIS - SS2010Grundlagen der Programmierung II2
Klausur istFreitag den 23. Juli
Literatur
• Folien/Übungen zu DB1 und DB2 sind online zugänglich
DBIS - SS2010
• Bib. unter H, Treppe hoch, dann lauft ihr in DB-Bücher
Grundlagen der Programmierung II3
Fahrplan
Heute:• ER
• relationales Modell
Nächste Woche:• FDs und NFs
DBIS - SS2010
• FDs und NFs
• SQL
Letzte Vorlesung:• Diverses
• Fragen und Antworten
Grundlagen der Programmierung II4
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
DBIS - SS2010Grundlagen der Programmierung II5
Die Welt … Otto Müller lebt in Frankfurt am Main, in
der Robert-Mayer-Str. 11. Er hat ein Flug nach Kapstadt gebucht.
DBIS - SS2010Grundlagen der Programmierung II6
lebt_in
Person Haus lebt_in
Das Entity -Relationship ModellAus der Sicht des Objekt-Beziehungs-Modells (Entity-Relationship-Model)
besteht die Welt aus Objekten (Entities) und Beziehungen (Relationships) zwischen diesen Objekten.
Objekt (Entity):
DBIS - SS2010
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.
Grundlagen der Programmierung II7
Begriffe im Alltag
Achtung: Die Begriffe
• Entity und Entity-Typ
• Beziehung (Relation) und Beziehungstyp (Relationship-Typ)
DBIS - SS2010Grundlagen der Programmierung II8
(Relationship-Typ)
werden im Alltag oft als Synonyme verwendet.
(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
DBIS - SS2010
Größen, aus einem bestimmten Wertebereich (value set) annehmen.
Beispiel:
Grundlagen der Programmierung II9
Passagier
Name Freigepäck Status
Otto Müller20kgEconomy Class
Wichtig!
Ein Beziehungstyp zwischen zwei Entity-Typen kann eine mathematische Relation aufgefasst werden.
Person Stadt lebt_in S_Name Population
Name Geb_Datum
DBIS - SS2010Grundlagen der Programmierung II10
Person Stadt lebt_in Population Geb_Datum
Instanz:Person = { p1, p2, p3 }Stadt = { c1, c2, c3 }lebt_in = { <p1,c1>, <p2,c3>, <p3,c3> }
Min/Max Kardinalitäten
• min_card(Person, Lebt_in) = 1
• max_card(Person, Lebt_in) = 1
Person Stadt lebt_in (1,1) (0,n)
• •
DBIS - SS2010
• max_card(Person, Lebt_in) = 1
• min_card(Stadt, Lebt_in) = 0
• max_card(Stadt, Lebt_in) = n
Grundlagen der Programmierung II11
• p1
• p2
• p3
• c1
• c2
• c3
• c4
Person, verbindlich
Stadt, optional
Bem.: Es gibt andere Notationen, z.B. wird manchmal nur max_card angegeben.
Es gilt immer: min_card <= max_card!
KardinalitätenInstanz:Person = { p1, p2, p3 }Stadt = { c1, c2, c3 }lebt_in = { <p1,c1>, <p2,c3>, <p3,c3> }
• p1 • c1
• p1
• c1
Instanz:Person = { p1, p2, p3, p4}Stadt = { c1, c2, c3, c4, c5 }lebt_in = { <p1,c1>, <p2,c1>, <p3,c3>, <p1, c4> }
DBIS - SS2010Grundlagen der Programmierung II12
• p1
• p2
• p3
• c1
• c2
• c3
Person
Stadt
• p2
• p3
• p4
• c2
• c3
• c4
• c5
Person Stadt
Person Stadt lebt_in S_Name Population
Name Geb_Datum
(1,1) (1,1) Person Stadt lebt_in
S_Name Population
Name Geb_Datum
(0,n) (0,n)
Klassifizierung der Beziehungstypen
• one-to-one (max_card auf beiden Seiten = 1)
Person Stadt lebt_in (1,1) (0,1)
DBIS - SS2010
• one-to-many (max_card auf einer Seiten = 1, auf der anderen n)
• many-to-many (max_card auf beiden Seiten n)
Grundlagen der Programmierung II13
Person Stadt lebt_in (0,1) (0,n)
Person Stadt lebt_in (0,n) (1,n)
(Beziehungs ) Attribute
Eine Beziehung kann durch Merkmale (Attribute) gekennzeichnet werden.
Beispiel: Rolle
Die Funktion, die ein Objekt in einer Beziehung erfüllt, nennt man seine Rolle.
DBIS - SS2010
Beispiel:
Grundlagen der Programmierung II14
PASSAGIER FLUG bucht
SITZNR.
Gebuchter_Passagier Gebuchter_Flug
Rolle
(Beziehungs ) AttributeInstanz:Passagier = { p1, p2, p3 }Flug = { c1, c2, c3 }bucht = { <p1,c1, „D2“>, <p2,c1, „D3“>}
• p1
• c1
D2
D1D2
DBIS - SS2010Grundlagen der Programmierung II15
PASSAGIER FLUG bucht
SITZNR.
Gebuchter_Passagier Gebuchter_Flug
• p2
• p3
• c2
• c3
• c4
Passagier Flug
D3
Die Uni …
Studenten können sich von Professoren über eine Vorlesung mündlich prüfen lassen.
Student Prof prüft Name Gehalt
Name Geb_Datum
Alt. 1:
DBIS - SS2010Grundlagen der Programmierung II16
Vorlesung
Student Prof prüft Name Gehalt
Name Geb_Datum
Vorlesung Titel SWS
Alt. 2:(N-näre Beziehung)
Zusammengesetzte Attribute
Aggregation von Attributen die etwas gemeinsam haben, z.B.:
StrasseA
DBIS - SS2010Grundlagen der Programmierung II17
Strasse
Person
A d r e s s e
Nummer
Ort
PLZ
Generalisierung
Hierarchien für Entity-Typen (entspricht Klassenhierarchy in OO)
Person
DBIS - SS2010Grundlagen der Programmierung II18
Person
FrauMann
Schlüssel
Ein Schlüssel besteht aus einer Menge von Attributen, deren Werte eine Instanz (Entity) eines Entity-Types eindeutig bestimmt.
DBIS - SS2010Grundlagen der Programmierung II19
Person
Name
Personalausweis-nummer
Name desVaters
Name
Person Geb.Datum
Geb.Ort
einfacher Schlüssel zusammengesetzter Schlüssel
ER Zusammenfassung
• Entitäten und Entity-Typen
• Beziehungen und Beziehungstypen
• Attribute
• für Entitäten(Typen) und Beziehungen(Typen)
DBIS - SS2010
• für Entitäten(Typen) und Beziehungen(Typen)
• einfach oder zusammengesetzt
• ausgezeichnet als Schlüssel
• Kardinalitäten
• Generalisierung
Grundlagen der Programmierung II20
Entity -Typ oder Attribut???
• Entities sind Klassen von Objekten der realen Welt und nehmen keine Werte an.
Möbelstück
Farbehat
Farbe
Möbelstück
DBIS - SS2010
• Entities sind Klassen von Objekten der realen Welt und nehmen keine Werte an.
• Attribute dagegen sind beschreibende Eigenschaften und nehmen Werte an.
Grundlagen der Programmierung II21
Die Entscheidung ist abhängig vom Kontext (Situation/Anwendungsfall).
Farbe bestehtaus
Lack(1,n) (1,n)
Nr. Name
IntensitätMenge
Name Preis
Professor Lehrveranst.
Ausbilder Seminar
hält
hälthält
hält
AB
C
D
E
A-D
B-D
B-E
B-C
A-E
A-C
besser so …
Grundlagen der Programmierung II22
Professor
Lehrveranst.
Ausbilder Seminar
LehrerPersonal
besser so …
A
B
C D E
A-D
B-D
B-EB-C
A-EA-C
besser so …
Ausdruckskraft
Ein Angestellter einer Abteilung soll nicht mehr verdienen, als der entsprechende Abteilungsleiter.
Angesteller Abteilung
arbeitet_in
Gehalt
DBIS - SS2010Grundlagen der Programmierung II23
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.
Business Rules (im weitesten Sinne) können angesehe n werden als:
1. Die semantische Definition eines für Anwendungen relevanten Konzeptes, genauer, die semantische Definition• eines Objektes,
• eines Attributes oder einer
• Relation
des ER-Modells.
DBIS - SS2010
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).
Grundlagen der Programmierung II24
( 1 , n )
( 1 , n ) ( 1 , n )
PLAYER PRESIDENT COACH FAN
PERSON NAME AGE
MANAGES PLAYS _ FOR IS _ PRESIDENT SUPPORTS
TEAM NAME ( 1 , n )
( 1 , n ) ( 1 , n )
( 1 , 1 ) ( 1 , 1 )
( 1 , 1 ) ( 1 , 1 ) ( 1 , 1 ) ( 1 , 1 )
Grundlagen der Programmierung II25
NAME DATE
NUMBER
( 0 , n )
DATE
LOCATION SIZE
TIME
FINAL _ SCORE ( 0 , 1 )
( 1 , n )
( 1 , n )
( 1 , n )
( 1 , n )
( 1 , 1 )
PLAYS _ AGAINST
GAME ATTENDS TAKES
PLACE _ AT STADIUM
PRACTICES
ATTENDAN CE ( 0 , 1 )
BIRTHPLACE _ OF
RESIDENCE _ CITY _ OF
STUDENT PROFESSOR
BELONGS _ TO
CITY
NAME STATE
PERSON LAST _ NAME AGE
SEMESTER
DEPARTMENT
NAME TELEPHONE
SEMESTER
( 1 , n )
( 1 , 1 )
( 0 , n )
( 1 , 1 ) ( 0 , n )
( 1 , 1 )
( 0 , n )
( 0 , n )
( 0 , n )
Grundlagen der Programmierung II26
GRADUATE _ STUDENT
ADVISED _ BY
VISITING _ PROFESSOR
TAUGHT _ BY
MEETS
PLANNED ENROLLED
SEMESTER
GRADE
COURSE TITLE
TIME DAY HOUR
ROOM ROOM _ NO BUILDING
START _ APPOINTMENT TERMINATE _
APPOINTMENT
( 1 , n )
( 1 , n ) ( 1 , n )
( 1 , 1 )
( 1 , 2 )
( 3 , 5 )
( 1 , n )
( 1 , n )
Grundlagen der Programmierung II27
Grundlagen der Programmierung II28
Relationales DatenmodellNach 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.
DBIS - SS2010
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.
Grundlagen der Programmierung II29
Relationales Datenmodell
Tabellen mit Zeilen und Spalten um die Datendarzustellen.
EMPNO FIRSTNME LASTNME PHONENO SALARY
AttributeEmployee
DBIS - SS2010
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
Tupel
Schema (Relationenschema):Employee(EMPNO, FIRSTNME, LASTNME, PHONENO, SALARY)
Formalisierung des Relationenmodells I
Definition:
Ein Relationenschema R ist eine endliche Menge von Attributnamen {A 1, A2 , ..., An}.
DBIS - SS2010
Notation:
R = {A1, A2 , ..., An} oder R(A1, A2 , ..., An)
Attributnamen können auch verkürzt nur als Attributebezeichnet werden.
Grundlagen der Programmierung II31
Formalisierung des Relationenmodells II
Definition:
Zu jedem Attribut A i, 1 ≤≤≤≤ i ≤≤≤≤ n, gibt es eine Menge Di, den Wertebereich (domain) von A i.
DBIS - SS2010
Notation:
dom (A i) ist der Wertebereich von A i.
Beispiel:
Das Attribut GESCHLECHT hat den Wertebereichdom (GESCHLECHT) = {männlich, weiblich} .
Grundlagen der Programmierung II32
Formalisierung des Relationenmodells IIIDefinition :
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 {t 1, ..., tn} von Rnach D, wobei für jede Abbildung t ∈∈∈∈ r, der Wert t(i) aus der
DBIS - SS2010
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 tfür ein Attribut A, t(A) = a , heißt A-Wert von t.
Grundlagen der Programmierung II33
Relationales DatenmodellTabellen mit Zeilen und Spalten um die Daten darzustellen.
EMPNO FIRSTNME LASTNME PHONENO SALARY
001 Jon Lucas 2983 2000Tupel t
AttributeEmployee
DBIS - SS2010
001 Jon Lucas 2983 2000
003 Jon Smith 2980 3588
103 Lucas Jon 4444 3980
999 Jon Smith 3987 1500
Tupel t
t(EMPNO) = 001t(FIRSTNME) = Jon
dom(SALARY) = „Werte, die als mögliche Gehälter in Frage kommen“
Relationales Datenmodell
EMPNO FIRSTNME LASTNME PHONENO SALARY
001 Jon Lucas 2983 2000
003 Jon Smith 2980 3588
103 Lucas Jon 4444 3980
Tupel t
Employee
t , t
DBIS - SS2010
103 Lucas Jon 4444 3980
999 Jon Smith 3987 1500
t(EMPNO, FIRSTNME) = (001, Jon)
t1, t2 ∈∈∈∈ r und t1(FIRSTNME, LASTNME) = t 2(FIRSTNME, LASTNME)
t1, t2
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
DBIS - SS2010
� Einfügen, Löschen, Ändern von Tupeln
• Relationenschemata sind unveränderlich
• Sind den Spalten einer Relation Attributnamenzugeordnet, so ist deren Reihenfolge unwichtig .(In der Definition der Relation auf S. 5 ist die Reihenfolge der Spalten wichtig.)
Grundlagen der Programmierung II36
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
DBIS - SS2010
Teilmenge K von R, so dass für je zwei verschiedeneTupel 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) = t 2(K), t1 ≠≠≠≠ t2 dann dürfte t2 nicht in r(R) eingefügt werden.
Grundlagen der Programmierung II37
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
DBIS - SS2010
… also aus Schlüssel � Oberschlüssel (aber nicht umgekehrt)
Oberschlüssel
Grundlagen der Programmierung II38
Schlüssel
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
=
DBIS - SS2010Grundlagen der Programmierung II39
EMPNO FIRSTNME LASTNME PHONENO SALARY
001 Jon Lucas 2983 2000
003 Jon Smith 2980 3588
103 Lucas Jon 4444 3980
im mathematischen mengentheoretischen Modell
• Schlüssel, die explizit zu einem Relationenschemaangeführt sind, heißen ausgezeichnete Schlüssel(designated keys).
• Eine Relation kann mehrere Schlüssel besitzen. Man spricht dann von Schlüsselkandidaten .
DBIS - SS2010
spricht dann von Schlüsselkandidaten .
• Im Allgemeinen wird ein Schlüssel als Primärschlüsselausgezeichnet.
• Dieser wird im Relationenschema durch Unterstreichen gekennzeichnet.
Grundlagen der Programmierung II40
ER-Abbildung zu RelationenEntitä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.
DBIS - SS2010
Etwaige Schlüssel werden übernommen und üblicherweise an den Anfang des Relationenschemas gestellt.
„Regel“:
Grundlagen der Programmierung II41
Entitätstyp E
Schlüssel Attribut_A Attribut_B
�
E (Schlüssel, Attribut_A, Attribut_B)
Beispiel
Angestellter
Pers.Nr. Name Vorname
�
DBIS - SS2010Grundlagen der Programmierung II42
�
ANGESTELLTER (Pers.Nr., Name, Vorname)
PersNr Name Vorname
001 Jon Lucas
003 Jon Smith
103 Lucas Jon
ANGESTELLTER
many -to-many
Entität_1 Entität_2 Beziehung
Schlüssel1 A_1
Schlüssel2 A_2
(0:n) (0:n)
B
DBIS - SS2010Grundlagen der Programmierung II43
�
ENTITÄT_1 (Schlüssel1, A_1)ENTITÄT_2 (Schlüssel2, A_2)
BEZIEHUNG (Schlüssel1, Schlüssel2, B)
Beispiel
(0:n) (0:n) Person
AusweisNr. Name Vorname
lebt_in
seit
Ort
PLZ Ortsname
DBIS - SS2010
�
PERSON (AusweisNr., Name, Vorname)
ORT (PLZ, Ortsname)
LEBT_IN (AusweisNr., PLZ, seit)
Grundlagen der Programmierung II44
AusweisNr. Name Vorname
Beispiel mit Instanzen
PLZ Ortsname
501 Buli
503 Wali
603 Kali
AusweisNr Name Vorname
001 Jon Lucas
003 Jon Smith
103 Lucas Jon
PERSON Ort
LEBT_IN
DBIS - SS2010Grundlagen der Programmierung II45
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!
LEBT_IN
one-to-many (min_card = 0)
Entität_1 Entität_2 Beziehung
Schlüssel1 A_1
Schlüssel2 A_2
(0:1) (0:n)
B
DBIS - SS2010
�
ENTITÄT_1 (Schlüssel1, A_1)
ENTITÄT_2 (Schlüssel2, A_2)
BEZIEHUNG (Schlüssel1 , Schlüssel2, B)
Grundlagen der Programmierung II46
Beispiel
(0:1) (0:n) Buch
BuchNr. Titel Autor
verliehen an
Datum
Entleiher
Nummer Name
DBIS - SS2010Grundlagen der Programmierung II47
BuchNr. Titel Autor Nummer Name
�
BUCH (BuchNr., Titel, Autor)ENTLEIHER (Nummer, Name)VERLIEHEN_AN (BuchNr., Nummer, Datum)
one-to-many (min_card = 1)
Entität_1 Entität_2 Beziehung
Schlüssel1 A_1
Schlüssel2 A_2
(1:1) (0:n)
B
DBIS - SS2010
�
ENTITÄT_1 (Schlüssel1, A_1, Schlüssel2, B)
ENTITÄT_2 (Schlüssel2, A_2)
Grundlagen der Programmierung II48
Hier sind nur noch zwei Relationen notwendig!
Beispiel
(1:1) (0:n) Person
AusweisNr. Name Vorname
geboren in
Datum
Ort
PLZ Ortsname
DBIS - SS2010Grundlagen der Programmierung II49
�
PERSON (AusweisNr., Name, Vorname, PLZ, Datum)ORT (PLZ, Ortsname)
… aber auch möglich! (geht immer ☺☺☺☺)
Entität_1 Entität_2 Beziehung
Schlüssel1 A_1
Schlüssel2 A_2
(1:1) (0:n)
B
�
ENTITÄT_1(Schlüssel1, A_1)
DBIS - SS2010Grundlagen der Programmierung II50
ENTITÄT_2 (Schlüssel2, A_2)
BEZIEHUNG (Schlüssel1 , Schlüssel2, B)
(1:1) (0:n) Person
AusweisNr. Name Vorname
geboren in
Datum
Ort
PLZ Ortsname
�
PERSON (AusweisNr., Name, Vorname, PLZ, Datum)ORT (PLZ, Ortsname)GEBOREN_IN (AusweisNr., PLZ, Datum)
one-to-oneEine 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.
DBIS - SS2010
Ist nur eine min-Kardinalität = 1, so wendet man die Abbildung der one-to-many Beziehung an.
Grundlagen der Programmierung II51
Entität_1 Entität_2 Beziehung
Schlüssel1 A_1
Schlüssel2 A_2
(1:1) (0:1)
B
�
ENTITÄT_1 (Schlüssel1, A_1, Schlüssel2, B)ENTITÄT_2 (Schlüssel2, A_2)
Beispiel
(1:1) (0:1) Abteilung
AbteilungsNr. Bezeichnung
geleitet von
seit
Mitarbeiter
Pers.Nr. Name
DBIS - SS2010Grundlagen der Programmierung II52
�
ABTEILUNG (AbteilungsNr., Bezeichnung, Pers.Nr., seit)MITARBEITER (Pers.Nr., Name)
one-to-one (beide min -card = 1)
Entität_1 Entität_2 Beziehung
Schlüssel1 A_1
Schlüssel2 A_2
(1:1) (1:1)
B
DBIS - SS2010Grundlagen der Programmierung II53
�
ENTITÄT_1_2 (Schlüssel1, A_1, Schlüssel2, A_2, B)
oderENTITÄT_1_2 (Schlüssel1, A_1, Schlüssel2, A_2, B)
Nur noch eine Relation notwendig!
Beispiel
(1:1) (1:1) Ausweis
AusweisNr. Behörde
gehört
Ablauf- Datum
Person
Name Vorname
DBIS - SS2010Grundlagen der Programmierung II54
AusweisNr. Behörde Name Vorname
�
PERSON (AusweisNr., Behörde, Ablaufdatum, Name, Vorname)
Sonderfälle
(3:5) (0:1) Auto
KFZ-Kennzeichen Hersteller
hat_Räder Rad
Fabr.-Nr. Breite
DBIS - SS2010Grundlagen der Programmierung II55
�
(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)
Abbildung der Generalisierung
Oberklasse
Schlüssel Attribut_A Attribut_B
Subklasse_2 Subklasse_1
DBIS - SS2010Grundlagen der Programmierung II56
Subklasse_2
Attribut_A_2
Subklasse_1
Attribut_A_1 Attribut_B_1
Hier: Drei Möglichkeiten mit unterschiedlichenVor- und Nachteilen!
1. MöglichkeitAlle 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.
DBIS - SS2010
Inkonsistenz und des zusätzlichen Speicherbedarfs.
Grundlagen der Programmierung II57
Oberklasse
Schlüssel Attribut_A Attribut_B
Subklasse_2
Attribut_A_2
Subklasse_1
Attribut_A_1 Attribut_B_1
�
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)
Konto
Kto.-Nr. Kunde Kto.Stand
Sparkonto
Zinssatz
Girokonto
Kreditrahmen
�
KONTO (Kto.Nr., Kunde, Kto.Stand)GIROKONTO (Kto.Nr., Kunde, Kto.Stand, Kreditrahmen)SPARKONTO (Kto.Nr., Kunde, Kto.Stand, Zinssatz)
2. MöglichkeitDie 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.
DBIS - SS2010Grundlagen der Programmierung II58
Oberklasse
Schlüssel Attribut_A Attribut_B
Subklasse_2
Attribut_A_2
Subklasse_1
Attribut_A_1 Attribut_B_1
�
OBERKLASSE (Schlüssel, Attribut_A, Attribut_B)SUBKLASSE_1 (Schlüssel, Attribut_A_1, Attribut_B_1)SUBKLASSE_2 (Schlüssel, Attribut_A_2)
Konto
Kto.-Nr. Kunde Kto.Stand
Sparkonto
Zinssatz
Girokonto
Kreditrahmen
�
KONTO (Kto.Nr., Kunde, Kto.Stand)GIROKONTO (Kto.Nr., Kreditrahmen)SPARKONTO (Kto.Nr., Zinssatz)
3. MöglichkeitMan 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.
DBIS - SS2010Grundlagen der Programmierung II59
Oberklasse
Schlüssel Attribut_A Attribut_B
Subklasse_2
Attribut_A_2
Subklasse_1
Attribut_A_1 Attribut_B_1
�
KLASSE (Schlüssel, Attribut_A, Attribut_B, Attribut_A_1, Attribut_B_1,Attribut_A_2)
Konto
Kto.-Nr. Kunde Kto.Stand
Sparkonto
Zinssatz
Girokonto
Kreditrahmen
�
KONTO (Kto.Nr., Kunde, Kto.Stand, Kreditrahmen, Zinssatz)
Größeres Beispiel
Angestellter
Pk-Nr Name Lohn
Außendienst
Datum
Manager
AT-Klasse
Abteilung
beschäftigt
geleitet_von
Abt-Nr.
seit
verkauft
� (1,1)
(1,1) (1,1)
Grundlagen der Programmierung II60
Police
Summe Nehmer Art Police-Nr.
�
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)
(1,1)
Schlüssel? … Kontext: Deutschland
ADRESSE
PLZ Ort StraßeNr
60308 Frankfurt Kettenhofweg 23
DBIS - SS2010
63069 Offenbach Bahnhofstr. 12
63069 Offenbach Waldweg 34
Grundlagen der Programmierung II61