PRG2 SS2010 Vorl5prg2/SS2010/...Teil 2-5. Vorlesung 1 Modul: Programmierung B-PRG Grundlagen der Programmierung II Professur für Datenbanken und Informationssysteme Dr. Karsten Tolle

Teil 2-

5. Vorlesung

1

5. Vorlesung

Modul: Programmierung B-PRGGrundlagen der Programmierung II

Professur für Datenbanken und Informationssysteme Dr. Karsten Tolle

[email protected]

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


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


Die Welt … Otto Müller lebt in Frankfurt am Main, in

der Robert-Mayer-Str. 11. Er hat ein Flug nach Kapstadt gebucht.


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.


Begriffe im Alltag

Achtung: Die Begriffe

• Entity und Entity-Typ

• Beziehung (Relation) und Beziehungstyp (Relationship-Typ)


(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:


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


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


• 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> }


• 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)


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:


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


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:


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


Strasse

Person

A d r e s s e

Nummer

Ort

PLZ

Generalisierung

Hierarchien für Entity-Typen (entspricht Klassenhierarchy in OO)

Person


Person

FrauMann

Schlüssel

Ein Schlüssel besteht aus einer Menge von Attributen, deren Werte eine Instanz (Entity) eines Entity-Types eindeutig bestimmt.


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


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.


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 …


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


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).


( 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 )


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 )


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 )



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.


Relationales Datenmodell

Tabellen mit Zeilen und Spalten um die Datendarzustellen.

EMPNO FIRSTNME LASTNME PHONENO SALARY

AttributeEmployee

DBIS - SS2010


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.


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} .


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.


Relationales DatenmodellTabellen mit Zeilen und Spalten um die Daten darzustellen.


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


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.)


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.


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


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

=



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.


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“:


Entitätstyp E

Schlüssel Attribut_A Attribut_B

�

E (Schlüssel, Attribut_A, Attribut_B)

Beispiel

Angestellter

Pers.Nr. Name Vorname

�


�

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


�

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)



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


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)


Schlüssel1 A_1

Schlüssel2 A_2

(0:1) (0:n)

B

DBIS - SS2010

�

ENTITÄT_1 (Schlüssel1, A_1)


BEZIEHUNG (Schlüssel1 , Schlüssel2, B)


Beispiel

(0:1) (0:n) Buch

BuchNr. Titel Autor

verliehen an

Datum

Entleiher

Nummer Name


BuchNr. Titel Autor Nummer Name

�

BUCH (BuchNr., Titel, Autor)ENTLEIHER (Nummer, Name)VERLIEHEN_AN (BuchNr., Nummer, Datum)

one-to-many (min_card = 1)


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)



Hier sind nur noch zwei Relationen notwendig!

Beispiel

(1:1) (0:n) Person


geboren in

Datum

Ort

PLZ Ortsname


�

PERSON (AusweisNr., Name, Vorname, PLZ, Datum)ORT (PLZ, Ortsname)

… aber auch möglich! (geht immer ☺☺☺☺)


Schlüssel1 A_1

Schlüssel2 A_2

(1:1) (0:n)

B

�

ENTITÄT_1(Schlüssel1, A_1)



BEZIEHUNG (Schlüssel1 , Schlüssel2, B)

(1:1) (0:n) Person


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.



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


�

ABTEILUNG (AbteilungsNr., Bezeichnung, Pers.Nr., seit)MITARBEITER (Pers.Nr., Name)

one-to-one (beide min -card = 1)


Schlüssel1 A_1

Schlüssel2 A_2

(1:1) (1:1)

B


�

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


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


�

(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


Subklasse_2 Subklasse_1


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.


Oberklasse


Subklasse_2

Attribut_A_2

Subklasse_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.


Oberklasse


Subklasse_2

Attribut_A_2

Subklasse_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


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.


Oberklasse


Subklasse_2

Attribut_A_2

Subklasse_1


�

KLASSE (Schlüssel, Attribut_A, Attribut_B, Attribut_A_1, Attribut_B_1,Attribut_A_2)

Konto


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)


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


Documents

PRG2 SS2010 Vorl5prg2/SS2010/...Teil 2-5. Vorlesung 1 Modul: Programmierung B-PRG Grundlagen der Programmierung II Professur für Datenbanken und Informationssysteme Dr. Karsten Tolle