Databases Reference
In-Depth Information
Schlüssel müssen hier eindeutig im Bereich der Oberklasse sein.
Die Vorteile dieser Lösung sind folgende: Die Daten, die zu einem Objekt gehö-
ren, sind zusammenhängend in einer Relation gespeichert. Es gibt keine Prob-
leme mit Beziehungen zur Oberklasse, da alle Objekte, auf die sie sich beziehen,
in der Oberklasse enthalten sind.
Es ist allerdings eine Redundanz gegeben, die in der Datenbank sicher verwal-
tet werden muss (z.B. durch Trigger, vgl. Kapitel 7.3.3).
Alle Daten werden in der Oberklasse gespeichert
Hier werden alle Attribute aller Unterklassen in die Oberklasse gezogen - alle
Objekte werden in der Oberklasse gespeichert, wobei jeweils die Attribute, die
nicht zu der entsprechenden Unterklasse gehören, mit einer Nullmarke zu ver-
sehen sind. Diese Lösung ist nur akzeptabel, wenn die Anzahl der eigenständi-
gen Attribute der Unterklassen nicht zu groß ist.
Die Umsetzung von Abbildung 3.23 in ein Relationenschema nach dem Grund-
satz, dass jede Klasse zu einer eigenständigen Relation wird, ergibt das Schema in
Abbildung 3.24.
Kunde
kunden_nr
status
name
straße
plz
ort
letzte_bestellung
letzte_werbeaktion
zahlung
Kunden_key
Kunden_status
Personenname
Straßenname
Postleitzahl
Ortsname
Datum
Datum
Zahlungsart
<pk>
kunden_nr =kunden_nr
kunden_nr = kunden_nr
Kunde mit Kreditkarte
kunden_nr
herausgeber
karten_nr
gültig_bis
Kunde mit Girokonto
kunden_nr
konto_inhaber
blz
konto_nr
Kunden_key
Personenname
Bankleitzahl
Kontonummer
<pk,fk>
Kunden_key
Personenname
Bankleitzahl
Kontonummer
<pk,fk>
Abbildung 3.24: Relationenmodell für Klassen mit Vererbung
Beispiel Fahrzeugwartung
Im Folgenden wird ein weiteres kleines Fallbeispiel eingeführt. Es geht um die
Wartung und Inspektion von Fahrzeugen und Fahrzeugaggregaten in einem Ver-
kehrsbetrieb. Das Modell ist durch folgende Aussagen beschrieben:
Search WWH ::




Custom Search