Aufgabe 4.1: Lösung: Sei B ein Beziehungstyp über den drei

1
Aufgabe 4.1:
Lösung:
Sei B ein Beziehungstyp über den drei Entitätstypen E1 , E2 und E3 . Sei ohne
Beschränkung der Allgemeinheit die Beziehungskomplexität zu E1 der Form
(0, 1). Wir zeigen, dass B durch die zwei zweistelligen Beziehungstypen B1 und
B2 repräsentiert werden kann, wobei B1 über E1 und E2 , bzw., B2 über E1 und
E3 .
Sei b eine beliebige Beziehungsmenge zu B, die die betrachtete Beziehungskomplexität erfüllt. Sei µ1 eine beliebige Entität vom Typ E1 , die in b vorkommt. Da
die Beziehungskomplexität zu E1 die Form (0, 1) besitzt, existiert genau eine
Beziehung in b, in der µ1 auftritt.
Wir konstruieren zu b eine Beziehungsmenge b1 vom Typ B1 und eine Beziehungsmenge b2 vom Typ B2 , indem wir zu jeder Beziehung (µ01 , µ02 , µ03 ) ∈ b eine
Beziehung (µ01 , µ02 ) in b1 und (µ01 , µ03 ) in b2 einfügen. µ01 , µ02 , bzw. µ03 sind hierbei
Entitäten vom Typ E1 , E2 , bzw. E3 . Für b1 und b2 gilt, dass sie die Beziehungskomplexitäten zu E1 der Form (0, 1) erfüllen.
Da in den Beziehungsmengen b1 und b2 eine Entität µ01 vom Typ E1 jeweils genau einmal auftritt, erhalten wir gerade wieder die Beziehungsmenge b, wenn
wir die Beziehungen zu µ01 in b1 und b2 wieder zu einer einzigen Beziehung
über E1 , E2 und E3 zusammensetzen.
Besitzt B Attribute, dann wird E1 um diese Attribute erweitert.
Das folgende Beispiel demonstriert diesen Zusammenhang.
2
(0,1)
Organisation
OName
Projekt
PrName
(0,*)
Unterstützung
Land
LCode
(0,*)
Land
LCode
(0,*)
LO
(0,1)
Organisation
OName
(0,1)
OP
(0,*)
Projekt
PrName
3
Aufgabe 4.2:
Lösung:
Sei B ein Beziehungstyp über den drei Entitätstypen E1 , E2 und E3 . Wir nehmen vereinfachend an, dass die Schlüssel der Entitätstypen jeweils aus einem
einzigen Attribut bestehen. Wir führen dann einen neuen Entitätstyp E ein und
zeigen, dass B durch drei zweistellige Beziehungstypen B1 , B2 und B3 repräsentiert werden kann, wobei B1 über E und E1 , B2 über E und E2 und B3 über E und
E3 definiert ist.
Sei A, bzw. B, bzw. C der Schlüssel von Ei , i ∈ {1, 2, 3}. E hat dann gerade die
Attribute {A, B, C}; alle diese drei Attribute zusammen bilden den Schlüssel
zu E. Sei b eine beliebige Beziehungsmenge zu B. Sei e diejenige Entitätsmenge
zu E, die wir erhalten, wenn wir zu jeder Beziehung ν in b gerade eine solche
Entität in e einfügen, deren Attributwerte sich aus den Werten der Schlüssel der
an ν beteiligten Entitäten ergeben.
Die Beziehungsmengen bi , 1 ≤ i ≤ 3 enthalten gerade diejenigen Beziehungen zwischen den Entitäten der Entitätsmengen zu Ei und E, so dass die Werte
des Schlüssels von Ei und der Wert des Schlüssels von Ei in E gleich sind. Die
Beziehungskomplexitäten zu E bzgl. B1 , B2 und B3 sind jeweils der Form (1, 1).
Besitzt B Attribute, dann werden diese dem Entitätstyp E zugeordnet.
Das folgende Beispiel demonstriert diesen Zusammenhang.
4
(0,*)
Organisation
OName
Projekt
PrName
(0,*)
Unterstützung
Land
LCode
(0,*)
Organisation
OName
(0,*)
OU
(1,1)
Land
LCode
(0,*)
LU
(1,1)
Unter- (1,1)
stützung
OName
PU
(0,*)
Projekt
PrName
5
Aufgabe 4.3:
Lösung:
Seien B1 und B2 zwei binäre Beziehungstypen jeweils über den Entitätstypen E1
und E2 . Für die Beziehungskomplexitäten gelte:
1)
2)
3)
4)
E1
E2
E1
E2
in B1 : (2, 2),
in B1 : (1, 1),
in B2 : (1, 1),
in B2 : (2, 2).
Seien e1 und e2 zwei Entitätsmengen und b1 und b2 zwei Beziehungsmengen,
die die obigen Beziehungskomplexitäten erfüllen. Sei n1 die Anzahl Entitäten
in e1 und n2 die Anzahl Entitäten in e2 .
Wir können dann n1 = 2n2 und n2 = 2n1 folgern. Daraus ergibt sich dann n1 =
n2 = 0, was zu zeigen war.
6
Aufgabe 4.4:
(a)
Lösung:
Seien u1 und u2 Entitätsmengen zu U1 und U2 . Wir ersetzen die Untertypen U1
und U2 durch neue Untertypen U10 und U20 und führen einen neuen Untertyp
U30 so ein, dass für jede Instanz des resultierenden ER-Schemas gilt:
u01 = u1 \ u2 ,
u02 = u2 \ u1 ,
u03 = u1 ∩ u2 .
(b)
Lösung:
Seien u1 und u2 Entitätsmengen zu U1 und U2 und sei o die Entitätsmenge des
Obertypen O. Wir führen einen neuen Untertyp U3 so ein, dass für jede Instanz
des resultierenden ER-Schemas gilt:
u3 = o \ (u1 ∪ u2 ).
7
(c)
Lösung:
Es ist sinnvoll disjunkte von nicht disjunkten Generalisierungen zu unterscheiden. Ist dies angebracht, so ersetzen wir das bisherige graphische Element
¡@
¡@
¡ISA@ in einem ER-Diagramm durch ¡ D @.
Es ist des Weiteren sinnvoll, den Fall einer totalen Generalisierung von einer
nicht totalen zu unterscheiden. Ist dies angebracht, so ersetzen wir das bisherige
¡@
¡@
graphische Element ¡ISA@ in einem ER-Diagramm durch ¡ T @.
Haben wir eine disjunkte und totale Generalisierung, so ersetzen wir das bis¡@
¡@
herige graphische Element ¡ISA@ in einem ER-Diagramm durch ¡DT@.
Das folgende ER-Diagramm gibt ein Beispiel für die Verwendung dieser unterschiedlichen Formen einer Generalisierung.
kanalisiert
GName
Belastung
stehend
Gewässer
DT
T
schiffbar
fließend
D
nicht
schiffbar
See
Fläche
Meer
Fläche
Fluss
Tiefe
Länge
8
Aufgabe 4.5:
Lösung: Die Variante in Abbildung 4.13 wählt die Darstellung:
Gewässer(GName, Belastung, PrName, Dauer)
See(GName, Fläche)
Fluss(GName, Länge)
(4.1)
Alternativ können wir wählen:
See(GName, Belastung, PrName, Dauer, Fläche)
Fluss(GName, Belastung, PrName, Dauer, Länge)
(4.2)
oder auch:
Gewässer(GName, GTyp, Belastung, PrName,
Dauer, Fläche, Länge)
(4.3)
In Variante 4.1 müssen die kompletten Angaben zu Seen und Flüssen mittels einem natürlichen Verbund zwischen den Tabellen See, bzw. Fluss und
Gewässer berechnet werden. Die Untertypen ergeben sich somit als Sicht über
dem Schema. In Variante 4.2 sind die Untertypen jeweils vollständig in einer Tabelle repräsentiert. Jetzt ergibt sich der Obertyp als Sicht auf das Schema; seine
Tabelle ergibt sich als Vereinigung der Tabellen der Untertypen, wobei zunächst
auf die Spalten des Obertyps projiziert wird. Welche dieser beiden Varianten
vorzuziehen ist hängt davon ab, ob Anfragen zu den Untertypen oder zu den
Obertypen unterstützt werden sollen.
In Variante 4.3 sind alle Zusammenhänge in einer einzigen Tabelle gespeichert.
Obertyp und Untertypen ergeben sich als entsprechende Projektion dieser Tabelle. Die Tabelle enthält Nullwerte, da für Seen und Flüsse unterschiedliche
Spalten anwendbar sind. Um Seen von Flüssen unterscheiden zu können, nehmen wir eine Spalte GTyp in die Tabelle auf. Betreffen die meisten Anfragen die
gemeinsamen Spalten von Seen, Flüssen und sonstigen Gewässern, dann kann
diese Unterstützung die mit Nullwerten im Prinzip verbundenen Nachteile aufwiegen.
9
Aufgabe 4.6:
Lösung:
Stehen die Datentypen ROW und MULTISET zur Verfügung, dann ist die Abbildung mengenwertiger und strukturierter Attribute in ein relationales Datenbankschema unproblematisch. Zu Abbildung (4.9) erhalten wir die CREATEAnweisung:
CREATE TABLE Land (
LCode
LName
HStadt
Fläche
Organisation
CHAR(4),
VARCHAR(50),
VARCHAR(50),
NUMBER,
ROW(
OName CHAR(50),
Beginn CHAR(20) )
MULTISET,
PRIMARY KEY (LCode) )
Betrachten wir jetzt das ER-Diagramm
LName
HStadt
Fläche
LCode
OName
Land
Organisation
Beginn
und nehmen wir an, dass der Datentyp ROW nicht zur Verfügung steht. Wir
kodieren die Struktur des Attributes Organisation in den Namen seiner (untergeordneten) Attribute und erhalten die folgenden CREATE-Anweisung:
CREATE TABLE Land (
...
Organisation.OName CHAR(50),
Organisation.Beginn CHAR(20) ),
PRIMARY KEY (LCode) )
10
Betrachten wir jetzt das ER-Diagramm
LName
HStadt
Fläche
LCode
Land
Organisation
OName
und nehmen wir an, dass der Datentyp MULTISET nicht zur Verfügung steht.
Zur Darstellung brauchen wir zwei Tabellen:
CREATE TABLE Land (
LCode
LName
HStadt
Fläche
PRIMARY KEY (LCode)
CHAR(4),
VARCHAR(50),
VARCHAR(50),
NUMBER,
)
CREATE TABLE LandOrganisation (
LCode
CHAR(4),
OName CHAR(50),
PRIMARY KEY (LCode, OName),
FOREIGN KEY (LCode) REFERENCES Land (LCode) )
11
Aufgabe 4.7:
Lösung:
create table Land(
LCode
varchar(3) primary key,
LName
varchar(100),
HStadt
varchar(100),
Fläche
numeric
);
create table Provinz(
PName
varchar(100),
LCode
varchar(3),
Fläche
numeric,
primary key (PName, LCode),
foreign key (LCode) references Land(LCode)
on delete cascade on update cascade
);
create table Stadt(
SName
varchar(100),
PName
varchar(100),
LCode
varchar(3),
Einwohner
numeric,
LGrad
numeric,
BGrad
numeric,
primary key (SName, PName, LCode),
foreign key (PName, LCode) references Provinz(PName, LCode)
on delete cascade on update cascade
);
create table Organisation(
OName
varchar(100) primary key
);
create table Projekt(
PrName
varchar(100),
Budget
numeric,
primary key (PrName)
);
create table Gewässer(
GName
varchar(100) primary key,
Belastung
numeric,
PrName
varchar(100) foreign key references Projekt(PrName)
on delete set null on update cascade,
Dauer
numeric
);
12
create table See(
GName
varchar(100) primary key,
Fläche
numeric,
foreign key (GName) references Gewässer(GName)
on delete cascade on update cascade
);
create table Fluss(
GName
varchar(100) primary key,
Länge
numeric,
foreign key (GName) references Gewässer(GName)
on delete cascade on update cascade
);
create table LO(
LCode
varchar(3) foreign key references Land(LCode)
on delete cascade on update cascade,
OName
varchar(100) foreign key references Organisation(OName)
on delete cascade on update cascade,
primary key (LCode, OName)
);
create table LOP(
LCode
varchar(3),
OName
varchar(100),
PrName
varchar(100) foreign key Projekt(PrName),
primary key (LCode, OName, PrName),
foreign key (LCode, OName) references LO (LCode, OName)
on delete cascade on update cascade
);
13
Aufgabe 4.8:
Lösung: Wir skizzieren eine systematische Vorgehensweise, die in so weit
detailliert ist, dass sie eine Transformation des UML-Diagramms in Abbildung 4.14 erlaubt.
1) Umwandeln von Klassen.
Einer Klasse - auch Assoziationsklasse - K wird zunächst ein Relationsschema mit gleichem Namen zugeordnet. Die Attribute der Klasse werden zu
Attributen des Schemas. Um für jedes solche Schema einen Primärschlüssel
zu erhalten, führen wir jeweils ein spezielles Attribut K# für eine eindeutige
Identifizierung der Tupel in den entsprechenden Relationen ein. Ein solcher
künstlicher Primärschlüssel kann später unter Umständen gestrichen, oder
durch einen aus den eigentlichen Attributen gebildeten Primärschlüssel ersetzt werden.
2) Umwandeln einer Assoziation A B. Wir beschränken uns auf vereinfachte
Multiplizitäten.
a) A 1 ∗ B. Der Primärschlüssel des Schemas zu A wird als Fremdschlüssel in das Schema zu B übernommen.
b) A 1 1 B. Wir betrachten die Alternativen:
(i) Der Primärschlüssel des Schemas zu A (B) wird als Fremdschlüssel in das Schema zu B(A)übernommen.
(ii) Die Schemata zu A und B werden zu einem Schema AB zusammengefasst; Primärschlüssel von AB ist entweder der Primärschlüssel von A oder B.
c) A ∗ ∗ B. Es wird ein neues Schema AB gebildet, dessen Attribute die
Primärschlüssel von A und B sind.
3) Umwandeln einer Assoziationsklasse C; die zugehörige Assoziation sei A B.
Liegt für die Assoziation der Fall 2a vor, dann werden die Attribute der Assoziationsklasse C in das Schema von B übernommen und das Schema zu
C wird entfernt. Wurde in Schritt 2 das Attribute C# zur Umwandlung von
Assoziationen in Schemata verwendet, dann wird in allen diesen Schemata
C# durch B# ersetzt.
Im Falle von 2(b)i werden die Attribute der Assoziationsklasse C entweder
nach A oder B übernommen und das Schema zu C wird entfernt. Wurde
in Schritt 2 das Attribute C# zur Umwandlung von Assoziationen in Schemata verwendet, dann wird in allen diesen Schemata C# durch B#, bzw. A#
ersetzt.
Im Falle von 2(b)ii und 2c werden die Attribute jeweils nach AB übernommen, das bisherige Schema zu C entfernt und das Schema AB zu C umbenannt. Wurde in Schritt 2 das Attribute C# zur Umwandlung von Assoziationen in Schemata verwendet, dann wird in allen diesen Schemata C#
14
durch A#, B# ersetzt.
4) Umwandeln einer Komposition A•
¦ B. Der Primärschlüssel des Schemas zu
A wird als Fremdschlüssel in das Schema zu B übernommen.
5) Umwandeln einer Generalisierung A ¢ B. Wir betrachten die Alternativen
(vergl. Aufgabe 4.5):
a) Der Primärschlüssel der Oberklasse A ersetzt den Primärschlüssel der
Unterklasse B.
b) Die Attribute der Oberklasse A werden in die Unterklasse B übernommen; das Schema zu A kann entfernt werden.
c) Die Attribute der Unterklasse B werden in die Oberklasse A übernommen. Das Schema zu A wird um ein Attribut erweitert, so dass die Zugehörigkeit eines Tupels zu B in einer Relation zu A gekennzeichnet
werden kann. Das Schema zu B kann entfernt werden.
Wir erhalten zunächst die folgenden Schemata:
Land(Land#, LCode, LName, HStadt, Fläche),
Provinz(Provinz#, Land#, PName, Fläche),
Stadt(Stadt#, Provinz#, Land#, SName, Einwohner, LGrad, BGrad);
Organisation(Organisation#, OName),
Projekt(Projekt#, PrName, Budget),
Gewässer(Gewässer#, Projekt#, GName, Belastung, Dauer),
See(Gewässer#, Fläche),
Fluss(Gewässer#, Länge),
LO(Land#, Organisation#, Art),
LOP(Land#, Organisation#, Projekt#, Betrag)
Die künstlichen Primärschlüssel werden durch die entsprechenden identifizierenden Attribute ersetzt. Des Weiteren, um die Teil-Ganzes-Eigenschaft einer
Komposition auszudrücken, bzw. Multiplizitäten der Form 0..1 oder 0..∗, können geeignete referentielle Aktionen vorgesehen werden. Es ergeben sich dann
Schemata der in der Lösung zu Aufgabe 4.7 skizzierten Form.