Kapitel 5: Das objektorientierte Modell Teil I Datenmodelle Kapitel 5: Das objektorientierte Modell

Literatur Datenbankeinsatz S.M. Lang, P.C. Lockemann Springer-Verlag, 1995 The Object Data Standard: ODMG 3.0 R.G.G. Cattell, D.K. Barry, D. Bartels Morgan Kaufmann Publishers, 2000

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)

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.

Kapitel 5.1: ODMG

Objekte und Literale Objekt Literal 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“

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

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 Über Beziehungen können beliebig komplexe Objektnetze entstehen. Aggregierung, wenn Beziehung Objekt-Unterobjekt-Beziehung beschreibt. 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

Polymorphe Typen und Mengen Typsystem für Literale Atomare Typen char,string,long,short,float,double,boolean Atomare polymorphe Typen enum ::= <string> Strukturierte Typen date, time, timestamp, interval Strukturierte polymorphe Typen struct ::= [sel:Typ, ..., sel:Typ] set ::= {Typ} bag ::= ∥Typ∥ list ::= <Typ> Typ: Vereinigungsmenge der Literal- und Objekttypen, Typkonstruktoren: [] Tupelkonstruktor, {} Mengenkonstruktor, ∥∥ Multimengenkonstruktor, <> Listenkonstruktor.

Polymorphe Typen und Mengen Typsystem für Objekte Strukturierte Objekttypen Date, Time, Timestamp, Interval Strukturierte 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}

Bewertung Strukturelle Mächtigkeit hoch Obj Set Literal Bag List Strukturelle Mächtigkeit hoch Volle strukturelle Orthogonalität

Polymorphe 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 ::= (Extent2sel) 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.

Polymorphe 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

Typisierung Kategorisierung von Objekten Kategorisierung von Literalen Gemeinsamer Zustandswertebereich (Attribute, Beziehungen). Gemeinsames Verhalten (Operatoren). Kategorisierung von Literalen 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.

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.

Objekttypen (2) Beispiel: Zwei Quader als Objekte (4.0, 1.5, 1.0) (8.0, 6.5, 6.0) (2.0, 0.0, 0.0) (5.0, 2.0, 4.0) 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!

Gleiche Schnittstelle, unterschiedliche Klassen Objekttypen (3) Quader (Würfel) geoName:‘Quader88‘ p1: @ p2: @ p3: @ p4: @ p5: @ p6: @ p7: @ p8: @ Quader geoName:‘Quader77‘ flächen:{ @ @ @ @ @ @ } Fläche … kanten:{ @ @ @ @ } kanten:{ @ @ @ @ } … Kante … p1: @ p2: @ p1: @ p2: @ … Punkt Gleiche Schnittstelle, unterschiedliche Klassen x: 2.0 y: 0.0 z: 0.0 x: 4.0 y: 0.0 z: 0.0 x: 8.0 y: 6.5 z: 6.0 x: 5.0 y: 2.0 z: 4.0 Vielflächner Punktrepräsentation Eckpunkt Eckpunkt

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.

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.

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).

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; class Fläche { attribute set<Kante> kanten; relationship set<Vielflächner> körper inverse Vielflächner::flächen; 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) attribute: hat einen einzigen Typ 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; class Fläche { attribute set<Kante> kanten; relationship set<Vielflächner> körper inverse Vielflächner::flächen; 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(); relationship/inverse: Beziehung, immer definiert als traversal path zwischen zwei Typen. Beide Typen müssen Instanzen haben, die mittels OID referenzierbar sind. 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.

Objektorientierte Datenbasisschemata (4) interface DatabaseFactory { Database new(); }; 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(); };

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; class Fläche { attribute set<Kante> kanten; relationship set<Vielflächner> körper inverse Vielflächner::flächen; Auch Klassen sind noch abstrakte Repräsentationen! abstrakt, da offen bleibt, ob als Literal oder als (interne) Prozedur realisiert.

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?

Lebensende transienter Objekte Dauerhaftigkeit (2) Lebensende transienter Objekte kante5 p1: p2: kante5 p1: p2: Persistent x: 5.0 y: 2.0 z: 4.0 p1a ? Transient x: 8.0 y: 6.5 z: 6.0 p2a ? dangling references

Vererbung (1) Gesetzmäßigkeiten nicht nur zwischen Daten sondern auch zwischen Typen: Typhierarchie. Drei Arten: Interface Class inherits extends Verhaltensvererbung/-generalisierung Vererbung von Zustand und Verhalten Interface Class Interface implements Zustandsimplementierung Verhaltensvererbung Class

Vererbung (2) Gesetzmäßigkeiten nicht nur zwischen Daten sondern auch zwischen Typen: Typhierarchie. Interface Bewirkt Übernahme aller Attributdeklarationen und Operatorsignaturen des Obertyps in den Untertyp. Mehrfachvererbung erlaubt: Typen bilden Typheterarchie. Jede Schnittstelle erbt implizit von Object. inherits Verhaltensvererbung/-generalisierung Interface

Vererbung (3) Gesetzmäßigkeiten nicht nur zwischen Daten sondern auch zwischen Typen: Typhierarchie. Klassen, die von Schnittstellen erben, vervollständigen und implementieren diese. Mehrfachvererbung erlaubt: Typen bilden Typheterarchie. Interface implements Zustandsimplementierung Verhaltensvererbung Class

Vererbung (4) Gesetzmäßigkeiten nicht nur zwischen Daten sondern auch zwischen Typen: Typhierarchie. 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! Class extends Vererbung von Zustand und Verhalten Class

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; class Fläche { attribute set<Kante> kanten; relationship set<Vielflächner> körper inverse Vielflächner::flächen; 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?

Vererbung Interface Interface Interface Interface Interface Class z.B. unterschiedliche Sprachanbindung Class z.B. Ergänzung der Schnittstelle

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.

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.

Polymorphie (3) 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!) interface Object { boolean same_as(in Object einObjekt); Object copy(); void delete(); ... }; interface ObjectFactory { Object new(); }; Keine Aussage über die Semantik von „ Objektgleichheit“! Erst klassenspezifisch festgelegt bei der Implementierung. Standardfall: OID-Gleichheit.

Kurzschreibweise für inherits 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(); ... }; Kurzschreibweise für inherits 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); ... };

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); ... };

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); ... };

Kapitel 5.2: Objektalgebra

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.

Objektorientierte Algebra Angelehnt an die relationalen Algebra, also , , \, a, s, p, b, B, e, f, g Erweitert um folgende Operatoren: Expansion c: Verallgemeinerung des relationalen Projektionsoperators Gruppierung G: Verallgemeinerung der Gruppierung aus SQL Entschachtelung m: Umkehrung der Gruppierung

Operatoren der Algebra: Übersicht  Typ, {} Mengentyp mit Elementtyp , [a1:1,..., an:n] Tupeltyp, []:  ist Tupeltyp, {}:  ist Mengentyp, 1, 2[]: 1 2 ist Konkatenation Sofern  Objekttyp ist, enthält Typ ausgezeichnetes Attribut mit OID.

Operatoren der Algebra: Übersicht Anwendung einer Transformationsfunktion auf die Elemente des Operanden (z.B. Menge von Werten wie etwa OIDs) zur Erzeugung einer Ergebnismenge, (e) = {(y) | ye} (p als Spezialfall) bzw. einer neuen Komponente in einer Tupelmenge a:(e) = {y[a:(y)] | ye}

Operatoren der Algebra: Übersicht Selektion wie gewohnt, p(e) = {y | ye, p(y)}

Operatoren der Algebra: Übersicht Reduktion ist spezielle Selektion, die alle Tupel ausblendet, die in irgendeiner Komponente den Nullwert  (also beispielsweise die leere Referenz) enthalten: A(e) = aA:y.a(e) wobei AA(), A() Attribute auf der obersten Ebene des zu e gehörenden Tupel- oder Mengentyps 

Operatoren der Algebra: Übersicht Join wie gewohnt, e1bpe2 = {xy | xe1, ye2, p(x,y)} Übrige Verbindungsoperationen entsprechend

Operatoren der Algebra: Übersicht Gruppierung wie gewohnt, jedoch verallgemeinert bzgl. Aggregierungsfunktion angewendet auf die durch Gruppierung entstandene Menge, g;A;(e) = {y.[Ā][g:G] | ye, G=({x.[A] | xe, x.[Ā]=y.[Ā]})} mit Ā = A() \ A. Spezialfälle: Gruppierung nach Einzelattribut: g;a;(e) Keine Aggregierung (Identität): g;A;id(e)

Operatoren der Algebra: Übersicht Entschachtelung (Umkehrung der Gruppierung), g(e) = {y.[g]x | ye, xy.g} -

Kapitel 5.3: Semantik

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.

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!)

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.

Objektgleichheit (2) q88a name: „Quader 88“ p1: p2: p3: p4: p5: p6: 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: 5.0 y: 2.0 z: 4.0 p1b x: 5.0 y: 2.0 z: 4.0 p1a x: 8.0 y: 6.5 z: 6.0 p2b x: 8.0 y: 6.5 z: 6.0 p2a

Objektgleichheit (3) Trivialerweise gilt: q88a == q88a  q88a = 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: Trivialerweise gilt: q88a == q88a  q88a = q88a  n: q88a =n q88a q88c name: „Quader 88“ p1: p2: p3: p4: p5: p6: p7: p8: x: 5.0 y: 2.0 z: 4.0 p1b x: 5.0 y: 2.0 z: 4.0 p1a x: 8.0 y: 6.5 z: 6.0 p2b x: 8.0 y: 6.5 z: 6.0 p2a

Objektgleichheit (4) Es gilt: q88a =1 q88b Nicht jedoch: q88a == q88b 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: 5.0 y: 2.0 z: 4.0 p1b x: 5.0 y: 2.0 z: 4.0 p1a Es gilt: q88a =1 q88b Nicht jedoch: q88a == q88b x: 8.0 y: 6.5 z: 6.0 p2b x: 8.0 y: 6.5 z: 6.0 p2a

Objektgleichheit (5) Es gilt: p1a =1 p1b ...  q88a =2 q88c Nicht jedoch: q88a == q88c q88a =1 q88c 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: 5.0 y: 2.0 z: 4.0 p1b x: 5.0 y: 2.0 z: 4.0 p1a x: 8.0 y: 6.5 z: 6.0 p2b x: 8.0 y: 6.5 z: 6.0 p2a

Objektgleichheit (6) Schließlich: q88a =2 q88d 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: Schließlich: q88a =2 q88d q88c name: „Quader 88“ p1: p2: p3: p4: p5: p6: p7: p8: x: 5.0 y: 2.0 z: 4.0 p1b x: 5.0 y: 2.0 z: 4.0 p1a x: 8.0 y: 6.5 z: 6.0 p2b x: 8.0 y: 6.5 z: 6.0 p2a

Volles Beispiel (1) define type Punkt is structure [ x, y, z: Float ]; // Tupeltyp mit atomaren Attributen interface declare Float x(void); // Leseoperation für Koordinate x declare Float y(void); // Leseoperation für Koordinate y declare Float z(void); // Leseoperation für Koordinate z declare void x:(Float wx); // Schreiboperation für Koordinate x declare void y:(Float wy); // Schreiboperation für Koordinate y declare void z:(Float wz); // Schreiboperation für Koordinate z declare Punkt addition(Punkt p); // Additionsoperation für Punkte declare void translation(Punkt p); // Translation eines Punkts declare Float distanz(Punkt p); // Abstand zu einem zweiten Punkt declare Float nullDistanz(void); // Abstand zum Nullpunkt implementation define x is return x; end define x; define x: is x := wx; return; end define x:; ... // Weitere Lese- und Schreiboperationen

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;

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.

Volles Beispiel (4) Anmerkungen: Implementierungen sind weggelassen. define type Quader is structure [ p1, p2, p3, p4, p5, p6, p7, p8: Punkt ]; interface declare 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 is structure { Quader }; end type Quaderbaukasten; Anmerkungen: Implementierungen sind weggelassen. Beachte: Punkte nicht unmittelbar zugänglich.

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.

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. punkt 2 punkt 3 punkt 1 punkt 2 punkt 3 punkt 1 p2a p1a p2a p1a x: 8.0 y: 6.5 z: 6.0 x: 5.0 y: 2.0 z: 4.0 x: 8.0 y: 6.5 z: 6.0 x: 5.0 y: 2.0 z: 4.0 Zustand vor der Zuweisung Zustand nach der Zuweisung

Ü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 System define type Punkt is structure [ x, y, z: Float ]; interface declare void translation(Punkt p); end type Punkt; define type Quader is structure [ p1, p2, p3, p4, p5, p6, p7, p8: Punkt ]; interface declare void translation(Punkt p); end type Quader; Zulässig in ODMG

Überladen von Operationen(2) Beispiele für Namensräume: Namensraum: jeweiliger Typ define 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!)

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!

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.

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.

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 Bei langer Lebensdauer häufig unvermeidlich: Bedingt Änderung des Datenbasisschemas. Vorsicht: Implementierung muss meist mit geändert werden! Mengensichtweise: Mengeninklusion. Änderungen des Typs lassen sich vorweg einplanen oder flexibler auffangen.

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.

Volles Beispiel (5) define type GeoKörper is structure [ bezeichnung, farbe: String; material: Material ]; interface declare Float dichte(void); implementation define dichte is return material.dichte; end define dichte; end type GeoKörper;     define type Material is structure [ name: String; dichte: Float ]; end type Material;

Also: Zylinder £t GeoKörper Volles Beispiel (6) define type Zylinder supertype GeoKörper is structure [ radius: Float; mittelpunkt1, mittelpunkt2: Punkt ]; interface declare Float länge(void); declare Float volumen(void); declare Float masse(void); declare void translation(Punkt p); implementation define 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

Typhierarchie Illustration des Beispiels: Object Quader Punkt GeoKörper Quaderbaukasten Material Zylinder

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.

Substituierbarkeitsprinzip (2) Beispiel: GeoKörper geo; Zylinder zy;     zy := Zylinder.create(); geo := zy; Übersetzer: Substituierbarkeitsprinzip erfüllt statischer Typ von geo: GeoKörper dynamischer Typ von geo: Zylinder (nach Ausführung der zweiten Anweisung) statischer und dynamischer Typ von zy: Zylinder

Substituierbarkeitsprinzip (3) Gegenbeispiel: Punkt p; GeoKörper geo; Zylinder zy;     p := Punkt.create(); geo := GeoKörper.create(); zy := geo; zy.translation(p); Der Übersetzer verhindert zulässige Situationen: geo := Zylinder.create(); würde keinen Laufzeitfehler verursachen Übersetzer: Verstoß gegen Substituierbarkeitsprinzip Falls vom Übersetzer übersehen: Laufzeitfehler, denn: translation() ist für GeoKörper nicht definiert, sondern wird erst in Zylinder eingeführt.

Verfeinerung ererbter Eigenschaften Abstrakte Typdefinition: define type t' supertype t is structure ... 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.

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.

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.

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. Folgt sofort aus dem Substituierbarkeitsprinzip

Verfeinerung von Operationen (4) Beispiel: define type Rohr supertype Zylinder is structure [ innererRadius: Float ]; interface refine Float volumen(void); implementation define 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!

Verfeinerung von Operationen (5) define type Zylinder supertype GeoKörper is structure [ radius: Float, mittelpunkt1, mittelpunkt2: Punkt ]; interface declare 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 is structure [ innererRadius: Float ]; interface refine Float volumen(void); refine Float masse(void); refine void verbindung(Rohr r); end type Rohr; Idee: Zylinder sollen mit (beliebigen) Zylindern verbunden werden können, Rohre aber nur mit Rohren. Verstoß!

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!

Verfeinerung von Attributen (1) Attributverfeinerung: Retypisierung von Attributen, etwa in der folgenden Form: define type t is structure [ ... a: ta ... ]; end type t;     define type t' supertype t is structure [ ... a: t'a ... ]; end type t';

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.

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.

Subtypisierung von Mengentypen (1) 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 }.

Subtypisierung von Mengentypen (2) Betrachte: define type set_t is structure { 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' }; interface declare Boolean istLeer(void); declare void einfügen(t' elem); declare t' löschen(void); end type set_t';

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.

Subtypisierung von Mengentypen (4) define type Zylindermenge is structure { Zylinder }; interface void einfügen(Zylinder zy); ... end type Zylindermenge;     define type Rohrmenge supertype Zylindermenge is structure { Rohr }; end type Rohrmenge; Verstoß! 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. Zylindermenge zm; Rohrmenge rm; Zylinder zy; ... rm := Rohrmenge.create(); zm := rm; zy := Zylinder.create(); ... zm.einfügen(zy);

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.

Mehrfachvererbung (1) Einfachvererbung: GeoKörper Zylinder Vollzylinder Rohr Vollwelle Hohlwelle Problem: Sowohl Voll- wie Hohlwellen sind Spezialisierungen von Antriebswelle.

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.

Mehrfachvererbung (3) Beispiel: GeoKörper Antriebswelle Zylinder Vollzylinder Rohr Vollwelle Hohlwelle

Mehrfachvererbung (4) define type Zylinder supertype GeoKörper is structure [ radius: Float, mittelpunkt1, mittelpunkt2: Punkt ]; interface declare Float länge(void); declare void translation(Punkt p); end type Zylinder; define type Rohr supertype Zylinder is structure [ innererRadius: Float ]; interface declare Float volumen(void); declare Float masse(void); declare void verbindung(Rohr r); end type Rohr;     define type Antriebswelle is structure [ maxDrehmoment: Float, lagerpunkt1, lagerpunkt2: Punkt ]; interface declare void translation(Punkt p); end type Antriebswelle;     define type Hohlwelle supertype Rohr, Antriebswelle is interface declare Float durchbiegung(void); end type Hohlwelle;    

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.