1 teil i datenmodelle kapitel 5: das objektorientierte modell
Post on 05-Apr-2015
111 Views
Preview:
TRANSCRIPT
1
Teil ITeil I
DatenmodelleDatenmodelle
Kapitel 5: Das objektorientierte Modell
2
Literatur
Datenbankeinsatz
S.M. Lang, P.C. LockemannSpringer-Verlag, 1995
The Object Data Standard: ODMG 3.0
R.G.G. Cattell, D.K. Barry, D. BartelsMorgan Kaufmann Publishers, 2000
3
Objektorientierung und Datenbanken
Programmiersprachen
OO-Kernkonzepte Objekt Klasse bzw. Typ Monomorphie Kapselung („information
hiding“) Vererbung bzw.
Generalisierung
Datenbanksysteme
DB-Kernkonzepte Zustand Zustandsräume Polymorphie Mengenkonstrukt Dauerhaftigkeit
Nahtloses Zusammenführen aller drei Bereiche zu Objektorientierten DBMS (ooDBMS)
4
Standards Es gibt leider kein einheitliches objektorientiertes
Datenmodell! Es gibt aber Standards für objektorientierte Datenmodelle in
Programmiersprachen: Java C++ (ISO-Standard)
Es gibt auch ein Referenzmodell im ooDBMS-Bereich: ODMG 3.0
Wir lehnen uns im folgenden an das Objektmodell der ODMG (Object Data Management Group) an.
5
Kapitel 5.1: ODMG
6
Objekte und Literale Objekt
hat eigene Identität besitzt Objektzustand („Wert“)
Attribute und Objektverhalten
Operationen (Ausnahmen)
Wert kann jederzeit unabhängig von Identität geändert werden Beispiel: Quader
Literal hat keine Identität besitzt ausschließlich nicht änderbaren Wert, der zugleich der
Kennzeichnung dient, Beispiel: „rot“
7
Objektidentität OID:
Repräsentant einer Objektidentität Eindeutig innerhalb der Datenbasis
Objektidentität ist orthogonal zu anderen Objekteigenschaften
Vergleiche: Relational Wertbasierter Ansatz Schlüsselattribut Teil des Wertes eines Tupels
8
Objektbeziehungen Wird als Typ eines Attributs ein Objekttyp vereinbart, so
werden dem Attribut Referenzen auf Objekte (genauer: deren Identifikatoren) als Wert zugewiesen.
Vergleich: Relational: Beziehung wertbasiert durch Fremdschlüssel Objektorientiert: Beziehung durch OID
Fläche f2 punkt1: (0,0,0) punkt2: (2,0,0) punkt3: (2,4,0) punkt4: (0,4,0)
Fläche f2 punkt1: (0,0,0) punkt2: (2,0,0) punkt3: (2,4,0) punkt4: (0,4,0)
Fläche f2 punkt1: (0,0,0) punkt2: (2,0,0) punkt3: (2,4,0) punkt4: (0,4,0)
Fläche f2 punkt1: (0,0,0) punkt2: (2,0,0) punkt3: (2,4,0) punkt4: (0,4,0)
Fläche f2 punkt1: (0,0,0) punkt2: (2,0,0) punkt3: (2,4,0) punkt4: (0,4,0)
Quader q1 farbe: „blau“ flächen: { , , , , , } skaliere(faktor)
Fläche f1 punkt1: (0,0,0) punkt2: (2,0,0) punkt3: (2,4,0) punkt4: (0,4,0)
Über Beziehungen können beliebig komplexe Objektnetze entstehen.
Aggregierung, wenn Beziehung Objekt-Unterobjekt-Beziehung beschreibt.
9Polymorphe Typen und Mengen
Typsystem für Literale
Atomare Typenchar,string,long,short,float,double,boolean
Atomare polymorphe Typen enum ::= <string>Strukturierte Typen date, time, timestamp, intervalStrukturierte polymorphe Typen
struct ::= [sel:Typ, ..., sel:Typ]set ::= {Typ}bag ::= ∥Typ∥list ::= <Typ>
Typ: Vereinigungsmenge der Literal- und Objekttypen,Typkonstruktoren:[] Tupelkonstruktor,{} Mengenkonstruktor,∥∥ Multimengenkonstruktor,<> Listenkonstruktor.
10Polymorphe Typen und Mengen
Typsystem für Objekte
Strukturierte Objekttypen Date, Time, Timestamp, IntervalStrukturierte polymorphe Objekttypen
Obj ::= [sel:Typ, ..., sel:Typ]Set ::= {Typ}Bag ::= ∥Typ∥List ::= <Typ>
Datenbankspezifisch und entscheidend für die Skalierbarkeit: Extent-Konstruktor erlaubt es, sämtliche Objekte eines gegebenen Typs in einer eigenen Extension zu sammeln:
Extension Extent ::= {Objekttyp}
11
Bewertung
Strukturelle Mächtigkeit hoch Volle strukturelle Orthogonalität
Set
Obj
Literal
Bag
List
12Polymorphe Konsistenzbedingungen (1)
Polymorphe Konsistenzbedingungen legen fest, welche Arten von Zustandsbeschränkungen nach einer Konkretisierung eines polymorphen Typsystems zu einem Datenbasisschema zusätzlich aufgeprägt werden können.
Bedingung 1: Schlüsselbedingung.
Mit der auf Skalierbarkeit zugeschnittenen Konstruktion der Extension geht ein key-Konstruktor einher, mit dem sich innerhalb einer Extension eine Schlüsseleigenschaft für strukturierte Objekte durchsetzen läßt.
key ::= (Extent2sel) 2Literaltyp Objekttyp Ziel: Bessere Handhabbarkeit der Eindeutigkeit von
Objekten in Extension dadurch, dass zur Feststellung der Eindeutigkeit die Kenntnis der Werte unter ausgewählten Attributen genügt.
13Polymorphe Konsistenzbedingungen (2)
Bedingung 2: Erlaubt bidirektionale Kopplung zweier Objekttypen, indem man jedem beteiligten Typ ein relationship-Konstrukt hinzu fügt, das über eine inverse-Angabe das relationship-Konstrukt im jeweils anderen Typ benennt.
relationship ::= Objekttyp Objekttyp
14
Typisierung Kategorisierung von Objekten
Gemeinsamer Zustandswertebereich (Attribute, Beziehungen). Gemeinsames Verhalten (Operatoren).
Kategorisierung von Literalen Gemeinsamer Zustandswertebereich (Attribute, Beziehungen). Objekte können als Bestandteil strukturierter Literale auftreten.
Der OID-Verweis ist dann ein Literal (somit unveränderlich). Die Objekteigenschaften bleiben erhalten. Somit können auch
Literale ein Verhalten besitzen.
15
Objekttypen (1) Schnittstelle (interface) als externe Spezifikation zur
Verwendung durch den Benutzer und für Typprüfungen. Objektkapselung: Objekt verbirgt nach außen hin
Objektzustand, Implementierung seiner Operatoren.
Objekt stellt nach außen hin sichtbares Verhaltensrepertoire (zugreifbare Attribute und Operatorsignaturen) zur Verfügung.
Ermöglicht intern verschiedene Repräsentationen des Objektzustandes und Implementierungen von Operatoren.
Klasse (class) als abstrakte Implementierung eines Objektes. Definition des Zustandsraum eines Objektes durch Angabe
sämtlicher Attribute. Enthält somit alle für die Implementierung der Operatoren
erforderlichen Angaben, nicht aber die Implementierung (Methoden) selbst.
16
Objekttypen (2)
Beispiel: Zwei Quader als Objekte
Quader77
(4.0, 1.5, 1.0)
(2.0, 0.0, 0.0) (5.0, 2.0, 4.0)
(8.0, 6.5, 6.0)
Quader88
Gleiche Schnittstelle, falls für die beiden Quader unterschiedliche Repräsentationen existieren, diese aber von außen nicht erkennbar sind.
Klasse macht solche Unterschiede sichtbar!
17
Objekttypen (3)
geoName:‘Quader77‘
flächen:{ @ @ @ @ @ @ }
kanten:{ @ @ @ @ }kanten:{ @ @ @ @ }
p1: @
p2: @
x: 2.0
y: 0.0
z: 0.0
p1: @
p2: @
x: 4.0
y: 0.0
z: 0.0
geoName:‘Quader88‘
p1: @
p2: @
p3: @
p4: @
p5: @
p6: @
p7: @
p8: @
x: 8.0
y: 6.5
z: 6.0
x: 5.0
y: 2.0
z: 4.0
…
…
…
…
Quader
Fläche
Kante
Quader (Würfel)
Eckpunkt EckpunktPunktrepräsentation
Punkt
Vielflächner
Gleiche Schnittstelle, unterschiedliche Klassen
18
Operatoren Monomorphe Operatoren sind nicht Bestandteil eines
Datenmodells. Ihre Signaturen gehören in das Datenbasisschema.
ODMG: Die Implementierung monomorpher Operatoren ist eine Angelegenheit der Anwendung, nicht des Datenbanksystems! Daher keine Führung von Methoden im Schema. Methoden werden in der Zielsprache der gewünschten
ODMG-Sprachanbindung (Java, C++, Smalltalk) implementiert.
Hat dazu den Vorteil der Sprachneutralität des Schemas.
19
Objektorientierte Datenbasisschemata (1)
Object Definition Language (ODL) als DDL Keine Programmier- sondern eine Spezifikationssprache.
„Kompatibel“ zur Interface Definition Language der Object Management Group (OMG IDL).
Es können Schnittstellen und Klassen aufgeführt werden. Es werden nur Operatoren und keine Methoden angegeben.
Nur Instanzen von Klassen können gespeichert werden. Eine Schnittstelle führt daher erst dann zu Objekten, wenn
angegeben wird, durch welche Klasse(n) sie implementiert wird.
20
Objektorientierte Datenbasisschemata (2) Eine Extension für einen Typ ist die explizite Menge aller
Instanzen dieses Typs in einer bestimmten Datenbasis. Sie kann daher nur für eine Klasse vereinbart werden.
Nur eine Extension kann als Menge behandelt werden. Ein Objekttyp muss daher eine Extension besitzen, um einen
Schlüssel zu haben. Die Root-Anweisung ist auch hier implizit: Extensionen
bilden zugleich die Wurzelobjekte. Die automatische Extent-Verwaltung wird vom Entwerfer
der Objektdatenbasis festgelegt (anders als bei einem relationalen DBMS).
21
Objektorientierte Datenbasisschemata (3)
class Punkt( extent punkte ) { attribute float x; attribute float y; attribute float z; void translation(in Punkt p);};
class Kante { attribute Punkt p1; attribute Punkt p2; void translation(in Punkt p);};
class Fläche { attribute set<Kante> kanten; relationship set<Vielflächner> körper inverse Vielflächner::flächen; void translation(in Punkt p);};
class Vielflächner( extent vielflächner; key vName ) { attribute string vName; relationship set<Fläche> flächen inverse Fläche::körper; void translation(in Punkt p);};
class Quader extends Vielflächner( extent quader ) { attribute float volume();};
22
class Vielflächner( extent vielflächner; key vName ) { attribute string vName; relationship set<Fläche> flächen inverse Fläche::körper; void translation(in Punkt p);};
class Quader extends Vielflächner( extent quader ) { attribute float volume();};
Objektorientierte Datenbasisschemata (3)
class Punkt( extent punkte ) { attribute float x; attribute float y; attribute float z; void translation(in Punkt p);};
class Kante { attribute Punkt p1; attribute Punkt p2; void translation(in Punkt p);};
class Fläche { attribute set<Kante> kanten; relationship set<Vielflächner> körper inverse Vielflächner::flächen; void translation(in Punkt p);};
attribute: hat einen einzigen Typ
traversal path: Die referenzielle Integrität wird vom ODBMS garantiert. Falls ein Objekt gelöscht wird, werden alle traversal paths zu diesem Objekt mit gelöscht.
relationship/inverse: Beziehung, immer definiert als traversal path zwischen zwei Typen. Beide Typen müssen Instanzen haben, die mittels OID referenzierbar sind.
23
Objektorientierte Datenbasisschemata (4)
Eine Datenbasis muss erst geöffnet werden, bevor auf sie zugegriffen werden kann.
Mit bind können Objekten Namen gegeben werden: dauerhafte globale
Variablen die dadurch weitere root-
Objekte bezeichnen.
interface Database {void open(in string dbName);void close();void bind(in any einObjekt,
in string name);Object lookup(in string name);Objekt unbind(in string name)Module schema();
};
interface DatabaseFactory {Database new();};
24
Schema und Datenbasis
class Punkt( extent punkte ) { attribute float x; attribute float y; attribute float z; void translation(in Punkt p);};
class Kante { attribute Punkt p1; attribute Punkt p2; attribute float länge; void translation(in Punkt p);};
class Fläche { attribute set<Kante> kanten; relationship set<Vielflächner> körper inverse Vielflächner::flächen; void translation(in Punkt p);};
abstrakt, da offen bleibt, ob als Literal oder als (interne) Prozedur realisiert.
Auch Klassen sind noch abstrakte Repräsentationen!
25
Dauerhaftigkeit (1) Relational: nur persistent ODMG: Zwei Alternativen
transient persistent
Wird zum Zeitpunkt der Erzeugung eines Objektes festgelegt
Problem: Was ist, wenn referenzierendes Objekt länger lebt als das referenzierte?
26
Dauerhaftigkeit (2)
kante5
p1:p2:
x: 8.0y: 6.5z: 6.0
p2a
x: 5.0y: 2.0z: 4.0
p1a
Lebe
nsen
de t
rans
ient
er O
bjek
te
Persistent
Transient?
?
kante5
p1:p2:
dangling references
27
Vererbung (1)Gesetzmäßigkeiten nicht nur zwischen Daten sondern auch zwischen Typen: Typhierarchie.Drei Arten:
Interface
Interface
Verhaltensvererbung/-generalisierung
Class
Class
Vererbung von Zustand und Verhalten
Interface
Class
Zustandsimplementierung Verhaltensvererbung
inherits
implements
extends
28
Vererbung (2)
Gesetzmäßigkeiten nicht nur zwischen Daten sondern auch zwischen Typen: Typhierarchie.
Interface
Interface
Verhaltensvererbung/-generalisierung
inherits Bewirkt Übernahme aller
Attributdeklarationen und Operatorsignaturen des Obertyps in den Untertyp.
Mehrfachvererbung erlaubt: Typen bilden Typheterarchie.
Jede Schnittstelle erbt implizit von Object.
29
Vererbung (3)
Gesetzmäßigkeiten nicht nur zwischen Daten sondern auch zwischen Typen: Typhierarchie.
Interface
Class
Zustandsimplementierung Verhaltensvererbung
implements
Klassen, die von Schnittstellen erben, vervollständigen und implementieren diese.
Mehrfachvererbung erlaubt: Typen bilden Typheterarchie.
30
Vererbung (4)
Gesetzmäßigkeiten nicht nur zwischen Daten sondern auch zwischen Typen: Typhierarchie.
Class
Class
Vererbung von Zustand und Verhalten
extends
Bewirkt Übernahme aller Attributdeklarationen und Operatorsignaturen des Obertyps in den Untertyp.
Nur Einfachvererbung: Typen bilden Typhierarchie. Begründet mit der Gefahr des
Erbens unterschiedlicher Implementierungen bei gleicher Signatur.
Zum Vererben der Implementierungen sagt ODMG nicht aus!
31
Vererbung zwischen Klassen
class Punkt( extent punkte ) { attribute float x; attribute float y; attribute float z; void translation(in Punkt p);};
class Kante { attribute Punkt p1; attribute Punkt p2; void translation(in Punkt p);};
class Fläche { attribute set<Kante> kanten; relationship set<Vielflächner> körper inverse Vielflächner::flächen; void translation(in Punkt p);};
class Vielflächner( extent vielflächner; key vName ) { attribute string vName; relationship set<Fläche> flächen inverse Fläche::körper; void translation(in Punkt p);};
class Quader extends Vielflächner( extent quader ) { attribute float volume();};
Teilmenge?
32
Vererbung
Interface
InterfaceInterface
Class
ClassInterface Class
Interface
z.B. unterschiedliche Sprachanbindungz.B. Ergänzung
der Schnittstelle
33
Polymorphie (1) Polymorphe Operatoren haben in der Datenbankwelt
durchaus ihren Sinn: Verwaltungsaufgaben. Frage: Wie kann man sie in die Objektwelt einbringen? Ansatz: Annäherung durch Vererbung.
34
Polymorphie (2) Inklusionspolymorphie:
Vererbung einer Operation an alle Untertypen eines Typs. Objekt eines Typs besitzt auch den Typ sämtlicher Obertypen.
Positioniere allgemein nutzbare Operationen in Schnittstellen oder Klassen sehr weit oben in der Typhierarchie.
Von ihnen können andere Klassen durch entsprechende Einordnung in die Typhierarchie erben.
Allgemein nützliche Typen können standardmäßig und somit auch als Bestandteil eines Datenbanksystems angeboten werden.
Bedenke aber: Passende Methoden existieren erst nach Anbindung an konkretes Datenbanksystem.
35
Polymorphie (3)
interface Object {boolean same_as(in Object einObjekt);Object copy();void delete();...
};
Objektschnittstelle, die von allen Objekten geerbt wird
same_as: Test auf Objektgleichheit
Objektkonstruktion durch Schnittstelle außerhalb der Typhierarchie (ein noch nicht existentes Objekt kann nicht erben!)
Keine Aussage über die Semantik von „ Objektgleichheit“!
Erst klassenspezifisch festgelegt bei der Implementierung.
Standardfall: OID-Gleichheit.
interface ObjectFactory {Object new();};
36
Polymorphie (4)
interface Collection : Object {unsigned long cardinality();boolean is_empty();boolean contains_element(in Object element);void insert_element(in Object element);void remove_element(in Object element);Object select_element(in string OQL_predicate);Iterator create_iterator();...
};
interface Iterator {boolean at_end();void reset();any get_element();void next_position();void replace_element(in any element);...
};
interface Set : Collection {Set create_union(in Set andereMenge);Set create_intersection(in Set andereMenge);Set create_difference(in Set andereMenge);boolean is_subset_of(in Set andereMenge);...
};
Kurzschreibweise für inherits
37
Polymorphie (5)
interface Collection : Object {unsigned long cardinality();boolean is_empty();boolean contains_element(in Object element);void insert_element(in Object element);void remove_element(in Object element);Object select_element(in string OQL_predicate);Iterator create_iterator();...
};
interface Iterator {boolean at_end();void reset();any get_element();void next_position();void replace_element(in any element);...
};
interface Bag : Collection {unsigned long occurrences_of(in Object element); Bag create_union(in Bag andereMenge);Bag create_intersection(in Bag andereMenge);Bag create_difference(in Bag andereMenge);...
};
38
Fehlerbehandlung Jeder Operator kann mittels einer raise-Klausel eine
benannte Ausnahme an einen Ausnahmebehandler melden, der von der Datenbankanwendung bereitgestellt und bei Eintreten der Ausnahme nach bestimmten Regeln ermittelt wird.
Beispiel:
interface Collection {...void remove_element(in any element)
raises (ElementNichtGefunden);...
};
39
Kapitel 5.2: Objektalgebra
40
Polymorphe Operatoren Relationales Datenmodell:
Muster für Datenmodell mit polymorphen Operationen. Eigenschaften der Dienstschnittstelle unabhängig von jeglicher
Anwendung auf eine Miniwelt. Objektorientierte Datenmodelle:
Muster für Datenmodelle mit monomorphen Operationen. Operatoren berücksichtigen die Eigenheiten der Miniwelt
Die Aufgaben eines DBMS sind generisch definiert. Daher sollte man auch in der Lage sein, allgemeingültige
polymorphe Operatoren für ODBMS zu vereinbaren. Vorschlag für eine Objektalgebra (nicht Teil des ODMG-
Standards!) auf Set.
41
Objektorientierte Algebra Angelehnt an die relationalen Algebra, also, , \, a, , , b, B, e, f, g
Erweitert um folgende Operatoren: Expansion : Verallgemeinerung des relationalen
Projektionsoperators Gruppierung : Verallgemeinerung der Gruppierung aus SQL Entschachtelung : Umkehrung der Gruppierung
42
Operatoren der Algebra: Übersicht
Bezeichnung Signatur Bedingung
Expansion : {} {´}
a: : {} { [a : ´]}
: ´: ´, []
Selektion p : {} {} p: bool
Reduktion A : {} {} A A()
Join e1 b p e2 : {}, {} { } ,[], p: , bool
Outerjoin e , f , g (entsprechend b )
Natürlicher Join e1Bpe2 : {´}, {´´} {´´´} A(´)A(´´) =
Gruppierung g;A; : { ´} { [g : ´´]} A = A(´), : {´} ´´
Entschachtelung g : { [g : {´}]} { ´} ´ []
Typ, {} Mengentyp mit Elementtyp , [a1:1,..., an:n] Tupeltyp, []: ist Tupeltyp, {}: ist Mengentyp,1, 2[]: 1 2 ist KonkatenationSofern Objekttyp ist, enthält Typ ausgezeichnetes Attribut mit OID.
43
Operatoren der Algebra: Übersicht
Bezeichnung Signatur Bedingung
Expansion : {} {´}
a: : {} { [a : ´]}
: ´: ´, []
Selektion p : {} {} p: bool
Reduktion A : {} {} A A()
Join e1 b p e2 : {}, {} { } ,[], p: , bool
Outerjoin e , f , g (entsprechend b )
Natürlicher Join e1Bpe2 : {´}, {´´} {´´´} A(´)A(´´) =
Gruppierung g;A; : { ´} { [g : ´´]} A = A(´), : {´} ´´
Entschachtelung g : { [g : {´}]} { ´} ´ []
Anwendung einer Transformationsfunktion auf die Elemente des Operanden (z.B. Menge von Werten wie etwa OIDs) zur Erzeugung einer Ergebnismenge,
(e) = {(y) | ye} ( als Spezialfall)bzw. einer neuen Komponente in einer Tupelmengea:(e) = {y[a:(y)] | ye}
44
Operatoren der Algebra: Übersicht
Bezeichnung Signatur Bedingung
Expansion : {} {´}a: : {} { [a : ´]}
: ´: ,́ []
Selektion p : {} {} p: bool
Reduktion A : {} {} A A()
Join e1 b p e2 : {}, {} { } ,[], p: , bool
Outerjoin e , f , g (entsprechend b )
Natürlicher Join e1B pe2 : {´}, {´´} {´´´} A(´)A(´´) =
Gruppierung g;A; : { ´} { [g : ´´]} A = A(´), : {´} ´´
Entschachtelung g : { [g : {´}]} { ´} ´ []
Selektion wie gewohnt, p(e) = {y | ye, p(y)}
45
Operatoren der Algebra: Übersicht
Bezeichnung Signatur Bedingung
Expansion : {} {´}a: : {} { [a : ´]}
: ´: ,́ []
Selektion p : {} {} p: bool
Reduktion A : {} {} A A()
Join e1 b p e2 : {}, {} { } ,[], p: , bool
Outerjoin e , f , g (entsprechend b )
Natürlicher Join e1B pe2 : {´}, {´´} {´´´} A(´)A(´´) =
Gruppierung g;A; : { ´} { [g : ´´]} A = A(´), : {´} ´´
Entschachtelung g : { [g : {´}]} { ´} ´ []Reduktion ist spezielle Selektion, die alle Tupel ausblendet, die in irgendeiner Komponente den Nullwert (also beispielsweise die leere Referenz) enthalten:A(e) = aA:y.a(e)
wobei AA(), A() Attribute auf der obersten Ebene des zu e gehörenden Tupel- oder Mengentyps
46
Operatoren der Algebra: Übersicht
Bezeichnung Signatur Bedingung
Expansion : {} {´}a: : {} { [a : ´]}
: ´: ,́ []
Selektion p : {} {} p: bool
Reduktion A : {} {} A A()
Join e1 b p e2 : {}, {} { } ,[], p: , bool
Outerjoin e , f , g (entsprechend b )
Natürlicher Join e1B pe2 : {´}, {´´} {´´´} A(´)A(´´) =
Gruppierung g;A; : { ´} { [g : ´´]} A = A(´), : {´} ´´
Entschachtelung g : { [g : {´}]} { ´} ´ []
Join wie gewohnt, e1bpe2 = {xy | xe1, ye2, p(x,y)}Übrige Verbindungsoperationen entsprechend
47
Operatoren der Algebra: Übersicht
Bezeichnung Signatur Bedingung
Expansion : {} {´}a: : {} { [a : ´]}
: ´: ,́ []
Selektion p : {} {} p: bool
Reduktion A : {} {} A A()
Join e1 b p e2 : {}, {} { } ,[], p: , bool
Outerjoin e , f , g (entsprechend b )
Natürlicher Join e1B pe2 : {´}, {´´} {´´´} A(´)A(´´) =
Gruppierung g;A; : { ´} { [g : ´´]} A = A(´), : {´} ´´
Entschachtelung g : { [g : {´}]} { ´} ´ []
Gruppierung wie gewohnt, jedoch verallgemeinert bzgl. Aggregierungsfunktion angewendet auf die durch Gruppierung entstandene Menge,g;A;(e) = {y.[Ā][g:G] | ye, G=({x.[A] | xe, x.[Ā]=y.[Ā]})}mit Ā = A() \ A.Spezialfälle:Gruppierung nach Einzelattribut: g;a;(e)Keine Aggregierung (Identität): g;A;id(e)
48
Operatoren der Algebra: Übersicht
Bezeichnung Signatur Bedingung
Expansion : {} {´}a: : {} { [a : ´]}
: ´: ,́ []
Selektion p : {} {} p: bool
Reduktion A : {} {} A A()
Join e1 b p e2 : {}, {} { } ,[], p: , bool
Outerjoin e , f , g (entsprechend b )
Natürlicher Join e1B pe2 : {´}, {´´} {´´´} A(´)A(´´) =
Gruppierung g;A; : { ´} { [g : ´´]} A = A(´), : {´} ´´
Entschachtelung g : { [g : {´}]} { ´} ´ []
Entschachtelung (Umkehrung der Gruppierung),g(e) = {y.[g]x | ye, xy.g}-
49
Kapitel 5.3: Semantik
50
Spezielle Themen
ODMG lässt eine Reihe von Aspekten der Semantik noch offen, die dann Gegenstand der spezifischen Anwendungslogik und daher dort zu implementieren sind:
Optionen für die Objektidentität. Objektgleichheit. Vererbung von Methoden und deren Implementierungen.
51
Objektidentität
Unverzichtbar: Jedes Objekt besitzt eine eindeutige Identität. Die Identität eines Objekts ist während seiner Lebensdauer
unveränderlich. Die Identität eines Objekts ist unabhängig vom
Speicherungsort des Objekts und vom Objektzustand.
Wünschenswert: Auch nach dem Löschen eines Objekts aus dem System
wird es kein anderes Objekt geben, das jemals die gleiche Identität wie die des gelöschten Objekts aufweist.(Harte Forderung an ein Datenbanksystem!)
52
Objektgleichheit (1) Wann sind zwei Objekte gleich?
Objekt (OID)-gleichheit: o1 == o2
Wertgleichheit: o1.w = o2 .w
Zustandsgleichheit erster Stufe: o1 =1 o2
Zustandsgleichheit n-ter Stufe: o1 =n o2
Im ODMG-Objektmodell wird eine Entscheidung nicht erzwungen!
Entscheidung ist implementierungsabhängig.
53
Objektgleichheit (2)
q88a
name: „Quader 88“p1:p2:p3:p4:p5:p6:p7:p8:
q88b
name: „Quader 88“p1:p2:p3:p4:p5:p6:p7:p8:
q88d
name: „Quader 88“p1:p2:p3:p4:p5:p6:p7:p8:
q88c
name: „Quader 88“p1:p2:p3:p4:p5:p6:p7:p8:
x: 8.0y: 6.5z: 6.0
p2ax: 5.0y: 2.0z: 4.0
p1a
x: 8.0y: 6.5z: 6.0
p2b x: 5.0y: 2.0z: 4.0
p1b
54
Objektgleichheit (3)
q88a
name: „Quader 88“p1:p2:p3:p4:p5:p6:p7:p8:
q88b
name: „Quader 88“p1:p2:p3:p4:p5:p6:p7:p8:
q88d
name: „Quader 88“p1:p2:p3:p4:p5:p6:p7:p8:
q88c
name: „Quader 88“p1:p2:p3:p4:p5:p6:p7:p8:
x: 8.0y: 6.5z: 6.0
p2ax: 5.0y: 2.0z: 4.0
p1a
x: 8.0y: 6.5z: 6.0
p2b x: 5.0y: 2.0z: 4.0
p1b
Trivialerweise gilt:q88a == q88a
q88a = q88a n: q88a =n q88a
55
Objektgleichheit (4)
q88a
name: „Quader 88“p1:p2:p3:p4:p5:p6:p7:p8:
q88b
name: „Quader 88“p1:p2:p3:p4:p5:p6:p7:p8:
q88d
name: „Quader 88“p1:p2:p3:p4:p5:p6:p7:p8:
q88c
name: „Quader 88“p1:p2:p3:p4:p5:p6:p7:p8:
x: 8.0y: 6.5z: 6.0
p2ax: 5.0y: 2.0z: 4.0
p1a
x: 8.0y: 6.5z: 6.0
p2b x: 5.0y: 2.0z: 4.0
p1b
Es gilt:q88a =1 q88b
Nicht jedoch:q88a == q88b
56
Objektgleichheit (5)
q88a
name: „Quader 88“p1:p2:p3:p4:p5:p6:p7:p8:
q88b
name: „Quader 88“p1:p2:p3:p4:p5:p6:p7:p8:
q88d
name: „Quader 88“p1:p2:p3:p4:p5:p6:p7:p8:
q88c
name: „Quader 88“p1:p2:p3:p4:p5:p6:p7:p8:
x: 8.0y: 6.5z: 6.0
p2ax: 5.0y: 2.0z: 4.0
p1a
x: 8.0y: 6.5z: 6.0
p2b x: 5.0y: 2.0z: 4.0
p1b
Es gilt: p1a =1 p1b...
q88a =2 q88c
Nicht jedoch: q88a == q88cq88a =1 q88c
57
Objektgleichheit (6)
q88a
name: „Quader 88“p1:p2:p3:p4:p5:p6:p7:p8:
q88b
name: „Quader 88“p1:p2:p3:p4:p5:p6:p7:p8:
q88d
name: „Quader 88“p1:p2:p3:p4:p5:p6:p7:p8:
q88c
name: „Quader 88“p1:p2:p3:p4:p5:p6:p7:p8:
x: 8.0y: 6.5z: 6.0
p2ax: 5.0y: 2.0z: 4.0
p1a
x: 8.0y: 6.5z: 6.0
p2b x: 5.0y: 2.0z: 4.0
p1b
Schließlich:q88a =2 q88d
58
Volles Beispiel (1)define type Punkt is
structure[ x, y, z: Float ]; // Tupeltyp mit atomaren Attributeninterface
declare Float x(void); // Leseoperation für Koordinate xdeclare Float y(void); // Leseoperation für Koordinate ydeclare Float z(void); // Leseoperation für Koordinate zdeclare void x:(Float wx); // Schreiboperation für Koordinate xdeclare void y:(Float wy); // Schreiboperation für Koordinate ydeclare void z:(Float wz); // Schreiboperation für Koordinate zdeclare Punkt addition(Punkt p); // Additionsoperation für Punktedeclare void translation(Punkt p); // Translation eines Punktsdeclare Float distanz(Punkt p); // Abstand zu einem zweiten Punktdeclare Float nullDistanz(void); // Abstand zum Nullpunkt
implementationdefine x isreturn x;end define x;define x: isx := wx;return;end define x:;... // Weitere Lese- und Schreiboperationen
59
Volles Beispiel (2)define addition is
Punkt newP := Punkt.create()newP.x:(x + p.x());newP.y:(y + p.y());newP.z:(z + p.z());return newP;
end define addition;define translation is
x := x + p.x();y := y + p.y();z := z + p.z();return;
end define translation;define distanz is
Float dx, dy, dz;dx := x - p.x();dy := y - p.y();dz := z - p.z();return sqrt(dx * dx + dy * dy + dz * dz);
end define distanz;define nullDistanz is
Punkt nullP := Punkt.create();nullP.x:(0.0);nullP.y:(0.0);nullP.z:(0.0);return self.distanz(nullP);end define nullDistanz;
end type Punkt;
60
Volles Beispiel (3)define addition is
Punkt newP := Punkt.create(); newP.x:(x + p.x());newP.y:(y + p.y());newP.z:(z + p.z());return newP;
end define addition;define translation is
x := x + p.x();y := y + p.y();z := z + p.z();return;
end define translation;define distanz is
Float dx, dy, dz;dx := x - p.x();dy := y - p.y();dz := z - p.z();return sqrt(dx * dx + dy * dy + dz * dz);
end define distanz;define nullDistanz is
Punkt nullP := Punkt.create();nullP.x:(0.0);nullP.y:(0.0);nullP.z:(0.0);return self.distanz(nullP);end define nullDistanz;
end type Punkt;
Erzeugen neuer Objekte: Pseudo-Nachricht create(), an den jeweiligen Typ „geschickt“, von dem eine neue Instanz erzeugt werden soll.
In addition() wird eine temporäre Variable benötigt. Sie wird mit dem Objekttyp Punkt deklariert und per Zuweisung “:=„ sofort mit einem neuen Objekt (dieses Typs) initialisiert.Die Attribute a des zu vereinbarenden Objekts
können von diesem gelesen und geschrieben werden, indem man a einfach benennt (Lesen) oder a einen Wert zuweist (Schreiben).
Auf Attribute anderer Objekte kann hingegen wegen des Kapselungsprinzips nicht einfach zugegriffen werden, dies muss ausdrücklich durch die Vereinbarung von Operationen zu ihrem Lesen und Schreiben gestattet werden.
61
Volles Beispiel (4)define type Quader is
structure[ p1, p2, p3, p4, p5, p6, p7, p8: Punkt ];
interfacedeclare Float volumen(void);declare void translation(Punkt p);declare void skalierung(Float factor);declare void rotation(Punkt px, py, pz);
end type Quader;
define type Quaderbaukasten isstructure
{ Quader };
end type Quaderbaukasten;
Anmerkungen: Implementierungen sind weggelassen. Beachte: Punkte nicht unmittelbar zugänglich.
62
Austausch von Informationen (1)
Nachrichtenaustausch:
Nachrichten für den Quader q88a und den Punkte p1a:q88a.skalierung(1.5);v := q88a.volumen();p := p1a.addition(p1b);
Variablenzuweisung:
Seien v1, v2 Variablen, d.h. benannte Referenzen für jeweils ein
Objekt. Dann bewirkt die Zuweisung v1 := v2, dass v1 auf
dasjenige Objekt verweist, das bereits v2 referenziert.
63
Austausch von Informationen (2)Beispiel:
punkt2 := punkt1;punkt3 := punkt2;
Situation vor und nach der Zuweisung:
Bemerkung: p1a ist nach der Zuweisungsfolge ungenutzt.Möglichkeiten: Automatische Entfernung aus dem System, ohne dass sich der
Anwender darum kümmert. Explizite Entfernung aus dem System durch den Anwender.
x: 8.0
y: 6.5
z: 6.0
x: 5.0
y: 2.0
z: 4.0
x: 5.0
y: 2.0
z: 4.0
x: 8.0
y: 6.5
z: 6.0
p2a p1a p2a p1a
Zustand nach der ZuweisungZustand vor der Zuweisung
punkt 1
punkt 2
punkt 3
punkt 1
punkt 2
punkt 3
64
Überladen von Operationen (1)Überladen: Zulassen verschiedener namensgleicher
Operationen innerhalb eines Namensraums.Welche der namensgleichen Operationen jeweils gemeint ist, wird über die Anzahl, die Reihenfolge und die Typen der Parameter herausgefunden.
Beispiele für Namensräume: Namensraum: Menge aller Definitionen im Systemdefine type Punkt is
structure[ x, y, z: Float ];
interfacedeclare void translation(Punkt p);
end type Punkt;
define type Quader isstructure
[ p1, p2, p3, p4, p5, p6, p7, p8: Punkt ];interface
declare void translation(Punkt p);end type Quader;
Zulässig in ODMG
65
Überladen von Operationen(2)
Beispiele für Namensräume: Namensraum: jeweiliger Typdefine type Quader is
structure[ p1, p2, p3, p4, p5, p6, p7, p8: Punkt ];
interface...overload void rotation(Punkt px, py, pz);overload void rotation(Float x1, y1, z1, x2, y2, z2, x3, y3, z3);overload void rotation(Matrix rotmatrix);
end type Quader;
Nicht zulässig in ODMG (auch nicht durch Vererbung!)
66
Schwache Typisierung Variablen und Objektattribute besitzen keinen Typ. Sie können daher zu unterschiedlichen Zeitpunkten Objekte
unterschiedlichen Typs referenzieren. Typkonsistenz (Operator ist auf referenziertes Objekt
anwendbar) ist daher erst zur Laufzeit unmittelbar vor der Auswertung prüfbar!
67
Typhierarchien
Ordnung auf Typen: Wir definieren für die Objekttypen t1,...,tn eine Ordnung t.
ti t tk bedeutet, dass ti Untertyp von tk ist.
Charakteristika dieser Ordnung: Reflexivität: ti t ti.
Transitivität: Wenn ti t tk und tk t tm, so gilt auch ti t
tm.
Antisymmetrie: Wenn ti t tk und tk t ti, so gilt ti = tk.
Keine Linearität: Für Typen ti und tk kann gelten, dass
weder ti t tk noch tk t ti.
Damit ist t eine partielle Ordnung, darstellbar durch einen
azyklischen Graphen.
68
Strenge Typisierung (1) Variablen und Objektattribute besitzen einen Typ. Variablen und Objektattribute können zu unterschiedlichen
Zeitpunkten Objekte unterschiedlichen Typs unter folgenden Einschränkungen referenzieren: Es dürfen nur Objekte eines Untertyps des spezifizierten Typs
referenziert werden (Substituierbarkeitsprinzip) Typkonsistenz kann dadurch bereits zur Übersetzungszeit
geprüft werden. Tatsächlicher Typ wird allerdings auch hier erst zur Laufzeit
bestimmt.
69
Bei langer Lebensdauer häufig unvermeidlich: Bedingt Änderung des Datenbasisschemas. Vorsicht: Implementierung muss meist mit geändert werden!
Strenge Typisierung (2) Spielräume hinsichtlich referenzierter Objekte:
Objekt besitzt stets einen Typ: Dieser bleibt unveränderlich Dieser kann wechseln, sofern das Substituierbarkeitsprinzip
eingehalten wird Objekt kann gleichzeitig mehrere Typen besitzen, sofern diese
in einer Hierarchie angeordnet sind
Mengensichtweise: Mengeninklusion.Änderungen des Typs lassen sich vorweg einplanen oder flexibler auffangen.
70
Strenge Typisierung (3)
ODMG legt strenge Typisierung in Form der Mengeninklusion zugrunde!
Vererbung zwischen Klassen impliziert Teilmengeneigenschaft zwischen deren Extensionen.
Da ein Objekt somit mehrere Typen besitzen kann, ist bei seiner Erzeugung der spezialisierteste Typ anzugeben.
Substituierbarkeitsprinzip dann: Objekt darf an jeder Stelle verwendet werden, an der einer seiner Typen erwartet wird.
71
Volles Beispiel (5)define type GeoKörper is
structure[ bezeichnung, farbe: String; material: Material ];
interfacedeclare Float dichte(void);
implementationdefine dichte is
return material.dichte;end define dichte;
end type GeoKörper;
define type Material isstructure
[ name: String; dichte: Float ];
end type Material;
72
Volles Beispiel (6)define type Zylinder supertype GeoKörper is
structure[ radius: Float; mittelpunkt1, mittelpunkt2: Punkt ];
interfacedeclare Float länge(void);declare Float volumen(void);declare Float masse(void);declare void translation(Punkt p);
implementationdefine länge is
return mittelpunkt1.distanz(mittelpunkt2);end define länge;define volumen is
return radius radius 3.14 self.länge();end define volumen;define masse is
return self.volumen() self.dichte();end define masse;define translation is
mittelpunkt1.translation(p);mittelpunkt2.translation(p);return;
end define translation;
end type Zylinder;
Also: Zylinder t GeoKörper
73
Typhierarchie
Illustration des Beispiels:
Object
Quader
Quaderbaukasten Material
GeoKörper
Zylinder
Punkt
74
Substituierbarkeitsprinzip (1) Statischer Typ einer Referenz: Der Typ, mit dem die
Referenz deklariert wurde, d.h. der Typ, den der Übersetzer für diese Referenz annimmt.
Dynamischer Typ einer Referenz: Der tatsächliche Typ des Objekts, auf das die Referenz zur Laufzeit verweist.
Dieser Typ kann sich während des Programmlaufes ändern, wenn bei Neuzuweisung an eine Variable Objekte unterschiedlicher Untertypen angegeben werden.
75
Übersetzer: Substituierbarkeitsprinzip erfüllt
statischer und dynamischer Typ von zy: Zylinder
Substituierbarkeitsprinzip (2)Beispiel:
GeoKörper geo;Zylinder zy; zy := Zylinder.create();geo := zy;
statischer Typ von geo: GeoKörperdynamischer Typ von geo: Zylinder(nach Ausführung der zweiten Anweisung)
76
Übersetzer: Verstoß gegen Substituierbarkeitsprinzip
Substituierbarkeitsprinzip (3)
Gegenbeispiel:Punkt p;GeoKörper geo;Zylinder zy; p := Punkt.create();geo := GeoKörper.create();zy := geo;zy.translation(p);
Falls vom Übersetzer übersehen:Laufzeitfehler, denn: translation() ist für GeoKörper nicht definiert, sondern wird erst in Zylinder eingeführt.
Der Übersetzer verhindert zulässige Situationen:geo := Zylinder.create();würde keinen Laufzeitfehler verursachen
77
Verfeinerung ererbter EigenschaftenAbstrakte Typdefinition:
define type t' supertype t isstructure ...interface ...
end type t';
Typ t' erbt alle Eigenschaften, also Attribute und Operationen, von seinem Obertyp t.
In manchen Fällen kommt es vor, dass die Semantik der ererbten Eigenschaften nicht genau auf die Eigenschaften des Untertyps passt.
Ererbte Eigenschaften müssen daher im Untertyp modifiziert werden können.
Dies bezeichnet man auch als Verfeinerung ererbter Eigenschaften.
78
Verfeinerung von Operationen (1)
Notation der Operationsdeklarationen:tn+1 t0.op(t1,...,tn)
op ist der Name der Operation. t0 ist der Empfängertyp, d.h. derjenige Typ, innerhalb
dessen Definitionsrahmen die Operation deklariert wird. t1, ..., tn sind die Typen der Operationsparameter, sofern
n>0. tn+1 ist der Typ des Ergebnisses der Operation.
79
Verfeinerung von Operationen (2)Semantik: Dynamisches Binden: Zur Erinnerung: ODMG sagt zum Vererben der
Implementierungen nichts aus! Daher allgemeinste Annahme: Implementierungen dürfen
jederzeit verfeinert werden! Wegen dieser Verfeinerungsmöglichkeit werden
Operationen prinzipiell dynamisch gebunden. Das bedeutet, dass zu einem Operationsaufruf zur Laufzeit
eine Implementierung (unter mehreren, die zur Verfügung stehen) ausgewählt wird.
Ein Aufruf o.op() einer verfeinerten typ-assoziierten Operation op() wird an die Implementierung gebunden, die zu dem direkten Typ des Empfängerobjekts o gehört.
80
Folgt sofort aus dem Substituierbarkeitsprinzip
Verfeinerung von Operationen (3)Syntax: Kontravariante Operationsverfeinerung: Seien
Operation op von Typ t0 an Typ t'0 vererbt, t'0 t t0,
ti und t'i Typen für 1 i n+1,
tn+1 t0.op(t1,...,tn) die Operationsdeklaration.
Dann ist t'n+1 t'0.op(t'1,...,t'n) genau dann eine gültige
Verfeinerung von op, wenn gilt: ti t t'i für 1 i n. Die Argumenttypen der verfeinerten
Operation müssen also stets Obertypen sein. (Reflexivität!) t'n+1 t tn+1. Der neue Ergebnistyp muss auf jeden Fall
Untertyp sein. (Reflexivität!)
Begründung: Typsicherheit.
81
Verfeinerung von Operationen (4)
Beispiel:define type Rohr supertype Zylinder is
structure[ innererRadius: Float ];
interfacerefine Float volumen(void);
implementationdefine volumen is return(super.volumen() -
innererRadius innererRadius 3.14 self.länge());end define volumen;
end type Rohr;
nur Unterschiede aufgeführt
Verfeinerung ohne Änderung von Argument- und Ergebnistyp
gemeint ist die im Obertyp vereinbarte Implementierung
Unproblematisch!
82
Verfeinerung von Operationen (5)define type Zylinder supertype GeoKörper is
structure[ radius: Float, mittelpunkt1, mittelpunkt2: Punkt ];
interfacedeclare Float länge(void);declare Float volumen(void);declare Float masse(void);declare Float translation(Punkt p);declare void verbindung(Zylinder z);
end type Zylinder;
define type Rohr supertype Zylinder isstructure
[ innererRadius: Float ];interface
refine Float volumen(void);refine Float masse(void);refine void verbindung(Rohr r);
end type Rohr; Verstoß!
Idee: Zylinder sollen mit (beliebigen) Zylindern verbunden werden können, Rohre aber nur mit Rohren.
83
Verfeinerung von Operationen (6)
Zylinder zy1, zy2;Rohr ro; zy1 := Zylinder.create();ro := Rohr.create();zy2 := ro;zy2.verbindung(zy1);
Falls vom Übersetzer übersehen: Tatsächlich ist zur Laufzeit Rohr der dynamische Typ von
zy2. Da zy1 aber kein Rohr ist, ergäbe sich bei der
Programmausführung ein Fehler, da die Typdeklaration der Operation verbindung() in Rohr nicht erfüllt ist.
Einschränkung des Überladens in ODMG schließt dort die Verfeinerung aus!
84
Verfeinerung von Attributen (1)Attributverfeinerung: Retypisierung von Attributen, etwa in
der folgenden Form:
define type t isstructure
[ ... a: ta ... ];
end type t; define type t' supertype t is
structure[ ... a: t'a ... ];
end type t';
85
Verfeinerung von Attributen (2)
Einführung von a benutzenden Operationen: Sei t' t t.
Lesen von a: ta t.a() bzw. t'a t'.a();
Setzen von a: void t.a:(ta) bzw. void t'.a:(t'a).
Definition:
Die Verfeinerung eines Attributes ist gleichbedeutend mit der Verfeinerung der beiden Zugriffsfunktionen des Attributes.
Satz:
Aus der Verfeinerungsbedingung folgt:
Es ist nicht möglich, beide Zugriffsfunktionen des gleichen Attributes zu verfeinern.
86
Verfeinerung von Attributen (3)Abstrakte Beweisskizze: Widerspruchsbeweis: Annahme: t'a ist Untertyp von ta (t'a t ta).
In diesem Fall ist void a:(t'a) keine legale Verfeinerung von void a:(ta).Das Argument der verfeinerten Operation müsste dazu nämlich Obertyp sein.
Annahme: t'a ist Obertyp von ta (ta t t'a).In diesem Fall ist t'a t'.a() keine legale Verfeinerung von ta t.a().Der Ergebnistyp der verfeinerten Operation müsste dazu nämlich Untertyp sein.
Somit darf t'a weder echter Untertyp noch echter Obertyp von ta sein.
Mithin ist Attributverfeinerung unter Aufrechterhaltung strenger Typisierung generell nicht möglich.
87
Subtypisierung von Mengentypen (1)
Mengentypen:
Wenn ti ein Typ ist, soll { ti } der Mengentyp zu ti sein in dem
Sinne, dass jedes Objekt dieses Typs eine Menge von Elementen aus ti ist.
Satz:
Bei der Subtypisierung von Mengentypen darf der Elementtyp nicht verändert werden. Oder umgekehrt ausgedrückt: Für zwei Typen t und t' mit t' t t gilt nicht { t' } t { t }.
88
Subtypisierung von Mengentypen (2)Betrachte:
define type set_t isstructure
{ t };interface
declare Boolean istLeer(void);declare void einfügen(t elem);declare t löschen(void);
end type set_t; define type set_t' supertype set_t is
structure{ t' };
interfacedeclare Boolean istLeer(void);declare void einfügen(t' elem);declare t' löschen(void);
end type set_t';
89
Subtypisierung von Mengentypen (3)
Abstrakte Beweisskizze: Widerspruchsbeweis: Annahme t' t t:
Operation einfügen() erfüllt nicht die Verfeinerungsbedingung.
Annahme t' t t:
Operation löschen() erfüllt nicht die Verfeinerungsbedingung.
Insgesamt folgt, dass set_t' weder echter Untertyp noch echter Obertyp von set_t sein darf.
Die gleichen Überlegungen lassen sich auf Listentypen <t> anwenden.
90
Subtypisierung von Mengentypen (4)define type Zylindermenge is
structure{ Zylinder };
interfacevoid einfügen(Zylinder zy);...
end type Zylindermenge;
define type Rohrmenge supertype Zylindermenge isstructure
{ Rohr };
end type Rohrmenge;
Verstoß!
Zylindermenge zm;Rohrmenge rm;Zylinder zy;
...rm := Rohrmenge.create();zm := rm;zy := Zylinder.create();
...zm.einfügen(zy);
Die Zuweisungen gehorchen der Substituierbarkeit und sind korrekt ausführbar. Die einfügen()-Anweisung ist ebenfalls statisch korrekt, denn zm besitzt den statischen Typ Zylindermenge.
Es kommt jedoch zu einem Typisierungsfehler zur Laufzeit, da diese Anweisung einen (allgemeinen) Zylinder in eine Menge von Rohren einfügen würde.
91
Mengeninklusion
Die Mengeninklusion von ODMG ist keineswegs immer wünschenswert!
Beispiel: Ein Zylinder ist zugleich ein geometrischer Körper Ein Rohr soll aber kein Zylinder sein.
92
Mehrfachvererbung (1)Einfachvererbung:
GeoKörper
Zylinder
RohrVollzylinder
HohlwelleVollwelle
Problem: Sowohl Voll- wie Hohlwellen sind Spezialisierungen von Antriebswelle.
93
Mehrfachvererbung (2)
Mehrfachvererbung: Jeder Typ darf mehrere direkte Obertypen besitzen, so
dass sich eine Typheterarchie (nicht mehr nur -hierarchie) ausbilden kann
Ein Typ erbt dabei die Attribute und Operationen aller seiner Obertypen
Die Eigenschaften der Ordnung t auf Typen sollen
allerdings weiterhin gelten, daher keine Zyklen im Vererbungsgraph.
94
Mehrfachvererbung (3)
Beispiel:
GeoKörper
Zylinder
Vollzylinder
HohlwelleVollwelle
Antriebswelle
Rohr
95
Mehrfachvererbung (4)define type Zylinder supertype GeoKörper is
structure[ radius: Float, mittelpunkt1, mittelpunkt2: Punkt ];
interfacedeclare Float länge(void);declare void translation(Punkt p);
end type Zylinder;
define type Rohr supertype Zylinder isstructure
[ innererRadius: Float ];interface
declare Float volumen(void);declare Float masse(void);declare void verbindung(Rohr r);
end type Rohr;
define type Antriebswelle isstructure
[ maxDrehmoment: Float, lagerpunkt1, lagerpunkt2: Punkt ];interface
declare void translation(Punkt p);end type Antriebswelle;
define type Hohlwelle supertype Rohr, Antriebswelle is
interfacedeclare Float durchbiegung(void);
end type Hohlwelle;
96
Mehrfachvererbung (5)Konflikt: Typ t erbt von Heterarchieästen, in denen
unabhängig voneinander ein Attribut oder eine Operation mit dem gleichen Namen definiert ist, z.B. translation().
Auflösungsstrategien: Ausschlussstrategie: Verbot von Attributen oder
Operationen gleichen Namens in Obertypen von t, die untereinander nicht in Ober-/Untertypbeziehung stehen.
Defaultstrategie: Bestimmten vordefinierten Regeln folgend wird bei Konflikten eine der verfügbaren Alternativen gewählt.
Qualifikationsstrategie: Bei Konflikten wird der Bezeichner des Typs vorangestellt, von dem geerbt werden soll.
ODMG: Vermeiden des Konflikts indem Klassen Schnittstellen implementieren und Klassen nicht von Klassen mehrfach erben.
top related