prev up next

Verfeinerung des relationalen Schemas

Das im Initialentwurf erzeugte relationale Schema läßt sich verfeinern, indem einige der $1:1$-, $1:N$- oder $N:1$-Beziehungen eliminiert werden. Dabei dürfen nur Relationen mit gleichem Schlüssel zusammengefaßt werden.

Nach dieser Regel können von den drei Relationen

Vorlesungen : {[ VorlNr : integer, Titel : string, SWS : integer] }
Professoren : {[ PersNr : integer, Name : string, Rang : string, Raum : integer] }
lesen : {[ PersNr : integer, VorlNr : integer] }

die Relationen Vorlesungen und lesen zusammengefaßt werden. Somit verbleiben im Schema

Vorlesungen : {[ VorlNr : integer, Titel : string, SWS : integer, gelesenVon : integer] }
Professoren : {[ PersNr : integer, Name : string, Rang : string, Raum : integer] }

Das Zusammenlegen von Relationen mit unterschiedlichen Schlüsseln erzeugt eine Redundanz von Teilen der gespeicherten Information. Beispielsweise speichert die (unsinnige) Relation

Professoren' : {[ PersNr, liestVorl, Name, Rang, Raum ] }

zu jeder von einem Professor gehaltenen Vorlesung seinen Namen, seinen Rang und sein Dienstzimmer:

\begin{figure}\begin{center}
\begin{tabular}{\vert r\vert r\vert l\vert r\vert r...
...125 & 4052 & Sokrates & C4 & 226\\
\hline
\end{tabular}\end{center}\end{figure}

Bei $1:1$-Beziehungen gibt es zwei Möglichkeiten, die ursprünglich entworfene Relation mit den beteiligten Entity-Typen zusammenzufassen.


Abbildung 6.2: Beispiel einer 1:1-Beziehung

Abbildung 6.2 zeigt eine mögliche Modellierung für die Unterbringung von Professoren in Räumen als $1:1$-Beziehung. Die hierzu gehörenden Relationen heißen

Professoren : {[ PersNr, Name, Rang ] }
Räume : {[ RaumNr, Größe, Lage ] }
Dienstzimmer : {[ PersNr, RaumNr ] }

Da Professoren und Dienstzimmer denselben Schlüssel haben, kann zusammengefaßt werden zu

Professoren : {[ PersNr, Name, Rang, Raum] }
Räume : {[ RaumNr, Größe, Lage ] }

Da das Attribut RaumNr innerhalb der Relation Dienstzimmer ebenfalls einen Schlüssel bildet, könnten als Alternative auch die Relationen Dienstzimmer und Räume zusammengefaßt werden:

Professoren : {[ PersNr, Name, Rang] }
Räume : {[ RaumNr, Größe, Lage, ProfPersNr ] }

Diese Modellierung hat allerdings den Nachteil, daß viele Tupel einen sogenannten Nullwert für das Attribut ProfPersNr haben, da nur wenige Räume als Dienstzimmer von Professoren genutzt werden.

Die in Abbildung 6.1 gezeigte Generalisierung von Assistenten und Professoren zu Angestellte könnte wie folgt durch drei Relationen dargestellt werden:

Angestellte : {[ PersNr, Name] }
Professoren : {[ PersNr, Rang, Raum] }
Assistenten : {[ PersNr, Fachgebiet] }

Hierdurch wird allerdings die Information zu einem Professor, wie z.B.

[2125, Sokrates, C4, 226]

auf zwei Tupel aufgeteilt:

[2125, Sokrates] und [2125, C4, 226]

Um die vollständige Information zu erhalten, müssen diese beiden Relationen verbunden werden (Join).

Tabelle 6.1 zeigt eine Beispiel-Ausprägung der Universitäts-Datenbasis. Das zugrundeliegende Schema enthält folgende Relationen:

Studenten : {[ MatrNr : integer, Name : string, Semester : integer] }
Vorlesungen : {[ VorlNr : integer, Titel : string, SWS : integer, gelesenVon : integer] }
Professoren : {[ PersNr : integer, Name : string, Rang : string, Raum : integer] }
Assistenten : {[ PersNr : integer, Name : string, Fachgebiet : string, Boss : integer] }
hören : {[ MatrNr : integer, VorlNr : integer] }
voraussetzen : {[ Vorgänger : integer, Nachfolger : integer] }
prüfen : {[ MatrNr : integer, VorlNr : integer, PersNr : integer, Note :decimal] }

Professoren
PersNr Name Rang Raum
2125 Sokrates C4 226
2126 Russel C4 232
2127 Kopernikus C3 310
2133 Popper C3 52
2134 Augustinus C3 309
2136 Curie C4 36
2137 Kant C4 7
Studenten
MatrNr Name Semester
24002 Xenokrates 18
25403 Jonas 12
26120 Fichte 10
26830 Aristoxenos 8
27550 Schopenhauer 6
28106 Carnap 3
29120 Theophrastos 2
29555 Feuerbach 2

Vorlesungen
VorlNr Titel SWS gelesenVon
5001 Grundzüge 4 2137
5041 Ethik 4 2125
5043 Erkenntnistheorie 3 2126
5049 Mäeutik 2 2125
4052 Logik 4 2125
5052 Wissenschaftstheorie 3 2126
5216 Bioethik 2 2126
5259 Der Wiener Kreis 2 2133
5022 Glaube und Wissen 2 2134
4630 Die 3 Kritiken 4 2137
voraussetzen
Vorgänger Nachfolger
5001 5041
5001 5043
5001 5049
5041 5216
5043 5052
5041 5052
5052 5259
hören
MatrNr VorlNr
26120 5001
27550 5001
27550 4052
27550 5041
28106 4052
28106 5216
28106 5259
27550 4630
29120 5041
29120 5049
29555 5022
25403 5022
29555 5001
Assistenten
PersNr Name Fachgebiet Boss
3002 Platon Ideenlehre 2125
3003 Aristoteles Syllogistik 2125
3004 Wittgenstein Sprachtheorie 2126
3005 Rhetikus Planetenbewegung 2127
3006 Newton Keplersche Gesetze 2127
3007 Spinoza Gott und Natur 2134
 
prüfen
MatrNr VorlNr PersNr Note
28106 5001 2126 1
25403 5041 2125 2
27550 4630 2137 2
Beispielausprägung der Universitätsdatenbank


Abbildung 6.3: Schwacher Entity-Typ

Zur Modellierung von schwachen Entity-Typen betrachten wir Abbildung 6.3 , in der mittels der Relation liegt_in der schwache Entitity-Typ Räume dem Entity-Typ Gebäude untergeordnet wurde.

Wegen der $1:N$-Beziehung zwischen Gebäude und Räume kann die Beziehung liegt_in verlagert werden in die Relation Räume:

Räume : {[ GebNr, RaumNr, Größe] }

Eine Beziehung bewohnt zwischen Professoren und Räume benötigt als Fremdschlüssel zum einen die Personalnummer des Professors und zum anderen die Kombination von Gebäude-Nummer und Raum-Nummer:

bewohnt : {[ PersNr, GebNr, RaumNr] }

Da bewohnt eine $1:1$-Beziehung darstellt, kann sie durch einen Fremdschlüssel beim Professor realisiert werden. Ist die beim Gebäude hinterlegte Information eher gering, käme auch, wie im Universitätsschema in Abbildung 6.1 gezeigt, ein Attribut Raum bei den Professoren infrage.


prev up next