1 Teil I Datenmodelle Kapitel 5: Das objektorientierte Modell

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)





Quader q1 farbe: „blau“ flächen: { , , , , , } skaliere(faktor)


Ü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


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







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


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 Kante { attribute Punkt p1; attribute Punkt p2; attribute float länge; 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)


Interface

Class

Zustandsimplementierung Verhaltensvererbung

implements

Klassen, die von Schnittstellen erben, vervollständigen und implementieren diese.

Mehrfachvererbung erlaubt: Typen bilden Typheterarchie.

30

Vererbung (4)


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






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



Expansion : {} {´}

a: : {} { [a : ´]}

: ´: ´, []



Join e1 b p e2 : {}, {} { } ,[], p: , bool


Natürlicher Join e1Bpe2 : {´}, {´´} {´´´} A(´)A(´´) =



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



Expansion : {} {´}a: : {} { [a : ´]}

: ´: ,́ []



Join e1 b p e2 : {}, {} { } ,[], p: , bool


Natürlicher Join e1B pe2 : {´}, {´´} {´´´} A(´)A(´´) =



Selektion wie gewohnt, p(e) = {y | ye, p(y)}

45



Expansion : {} {´}a: : {} { [a : ´]}

: ´: ,́ []



Join e1 b p e2 : {}, {} { } ,[], p: , bool




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



Expansion : {} {´}a: : {} { [a : ´]}

: ´: ,́ []



Join e1 b p e2 : {}, {} { } ,[], p: , bool





Join wie gewohnt, e1bpe2 = {xy | xe1, ye2, p(x,y)}Übrige Verbindungsoperationen entsprechend

47



Expansion : {} {´}a: : {} { [a : ´]}

: ´: ,́ []



Join e1 b p e2 : {}, {} { } ,[], p: , bool





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



Expansion : {} {´}a: : {} { [a : ´]}

: ´: ,́ []



Join e1 b p e2 : {}, {} { } ,[], p: , bool





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


q88d


q88c


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


q88a


q88b


q88d


q88c


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


q88a


q88b


q88d


q88c


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


q88a


q88b


q88d


q88c


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


q88a


q88b


q88d


q88c


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


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


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.

Documents

1 Teil I Datenmodelle Kapitel 5: Das objektorientierte Modell