Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

1 Teil I Datenmodelle Kapitel 5: Das objektorientierte Modell.

Ähnliche Präsentationen


Präsentation zum Thema: "1 Teil I Datenmodelle Kapitel 5: Das objektorientierte Modell."—  Präsentation transkript:

1 1 Teil I Datenmodelle Kapitel 5: Das objektorientierte Modell

2 2 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

3 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 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 5 Kapitel 5.1: ODMG

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

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

10 10 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 ::= 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 11 Bewertung Strukturelle Mächtigkeit hoch Volle strukturelle Orthogonalität Set Obj Literal Bag List

12 12 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 2 sel ) 2 Literaltyp 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.

13 13 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

14 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 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 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 17 Objekttypen (3) } x: 2.0 y: 0.0 z: 0.0 x: 4.0 y: 0.0 z: 0.0 geoName:Quader 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 Punktrepräsentation Punkt Vielflächner Gleiche Schnittstelle, unterschiedliche Klassen

18 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 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 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 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 kanten; relationship set 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ächen inverse Fläche::körper; void translation(in Punkt p); }; class Quader extends Vielflächner ( extent quader ) { attribute float volume(); };

22 22 class Vielflächner ( extent vielflächner; key vName ) { attribute string vName; relationship set 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 kanten; relationship set 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 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 { voidopen(in string dbName); voidclose(); voidbind(in any einObjekt, in string name); Objectlookup(in string name); Objektunbind(in string name) Moduleschema(); }; interface DatabaseFactory { Database new(); };

24 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 kanten; relationship set 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 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 26 Dauerhaftigkeit (2) kante5 p1: p2: x: 8.0 y: 6.5 z: 6.0 p2a x: 5.0 y: 2.0 z: 4.0 p1a Lebensende transienter Objekte Persistent Transient ? ? kante5 p1: p2: dangling references

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

28 28 Vererbung (2) Gesetzmäßigkeiten nicht nur zwischen Daten sondern auch zwischen Typen: Typhierarchie. 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 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 30 Vererbung (4) Gesetzmäßigkeiten nicht nur zwischen Daten sondern auch zwischen Typen: Typhierarchie. 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 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 kanten; relationship set 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ächen inverse Fläche::körper; void translation(in Punkt p); }; class Quader extends Vielflächner ( extent quader ) { attribute float volume(); }; Teilmenge?

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

33 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 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 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!) n Keine Aussage über die Semantik von Objektgleichheit! n Erst klassenspezifisch festgelegt bei der Implementierung. n Standardfall: OID-Gleichheit. interface ObjectFactory { Objectnew(); };

36 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 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 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 39 Kapitel 5.2: Objektalgebra

40 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 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 42 Operatoren der Algebra: Übersicht Typ, { } Mengentyp mit Elementtyp, [a 1 : 1,..., a n : n ] Tupeltyp, []: ist Tupeltyp, {}: ist Mengentyp, 1, 2 []: 1 2 ist Konkatenation Sofern Objekttyp ist, enthält Typ ausgezeichnetes Attribut mit OID.

43 43 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} ( als Spezialfall) bzw. einer neuen Komponente in einer Tupelmenge a: (e) = {y [a: (y)] | y e}

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

45 45 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

46 46 Operatoren der Algebra: Übersicht Join wie gewohnt, e 1 b p e 2 = {x y | x e 1, y e 2, p(x,y)} Übrige Verbindungsoperationen entsprechend

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

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

49 49 Kapitel 5.3: Semantik

50 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 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 52 Objektgleichheit (1) Wann sind zwei Objekte gleich? Objekt (OID)-gleichheit: o 1 == o 2 Wertgleichheit: o 1.w = o 2.w Zustandsgleichheit erster Stufe: o 1 = 1 o 2 Zustandsgleichheit n-ter Stufe: o 1 = n o 2 Im ODMG-Objektmodell wird eine Entscheidung nicht erzwungen! Entscheidung ist implementierungsabhängig.

53 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.0 y: 6.5 z: 6.0 p2a x: 5.0 y: 2.0 z: 4.0 p1a x: 8.0 y: 6.5 z: 6.0 p2b x: 5.0 y: 2.0 z: 4.0 p1b

54 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.0 y: 6.5 z: 6.0 p2a x: 5.0 y: 2.0 z: 4.0 p1a x: 8.0 y: 6.5 z: 6.0 p2b x: 5.0 y: 2.0 z: 4.0 p1b Trivialerweise gilt: q88a == q88a q88a = q88a n: q88a = n q88a

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

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

57 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.0 y: 6.5 z: 6.0 p2a x: 5.0 y: 2.0 z: 4.0 p1a x: 8.0 y: 6.5 z: 6.0 p2b x: 5.0 y: 2.0 z: 4.0 p1b Schließlich: q88a = 2 q88d

58 58 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

59 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 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 61 Volles Beispiel (4) 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.

62 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 v 1, v 2 Variablen, d.h. benannte Referenzen für jeweils ein Objekt. Dann bewirkt die Zuweisung v 1 := v 2, dass v 1 auf dasjenige Objekt verweist, das bereits v 2 referenziert.

63 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 p2ap1ap2ap1a Zustand nach der ZuweisungZustand vor der Zuweisung punkt 1 punkt 2 punkt 3 punkt 1 punkt 2 punkt 3

64 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 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

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

66 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 67 Typhierarchien Ordnung auf Typen: Wir definieren für die Objekttypen t 1,...,t n eine Ordnung t. t i t t k bedeutet, dass t i Untertyp von t k ist. Charakteristika dieser Ordnung: Reflexivität: t i t t i. Transitivität: Wenn t i t t k und t k t t m, so gilt auch t i t t m. Antisymmetrie: Wenn t i t t k und t k t t i, so gilt t i = t k. Keine Linearität: Für Typen t i und t k kann gelten, dass weder t i t t k noch t k t t i. Damit ist t eine partielle Ordnung, darstellbar durch einen azyklischen Graphen.

68 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 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 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 71 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;

72 72 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

73 73 Typhierarchie Illustration des Beispiels: Object QuaderQuaderbaukastenMaterialGeoKörperZylinderPunkt

74 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 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örper dynamischer Typ von geo: Zylinder (nach Ausführung der zweiten Anweisung)

76 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 77 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.

78 78 Verfeinerung von Operationen (1) Notation der Operationsdeklarationen: t n+1 t 0.op(t 1,...,t n ) op ist der Name der Operation. t 0 ist der Empfängertyp, d.h. derjenige Typ, innerhalb dessen Definitionsrahmen die Operation deklariert wird. t 1,..., t n sind die Typen der Operationsparameter, sofern n>0. t n+1 ist der Typ des Ergebnisses der Operation.

79 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 80 Folgt sofort aus dem Substituierbarkeitsprinzip Verfeinerung von Operationen (3) Syntax: Kontravariante Operationsverfeinerung: Seien Operation op von Typ t 0 an Typ t' 0 vererbt, t' 0 t t 0, t i und t' i Typen für 1 i n+1, t n+1 t 0.op(t 1,...,t n ) die Operationsdeklaration. Dann ist t' n+1 t' 0.op(t' 1,...,t' n ) genau dann eine gültige Verfeinerung von op, wenn gilt: t i 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 t n+1. Der neue Ergebnistyp muss auf jeden Fall Untertyp sein. (Reflexivität!) Begründung: Typsicherheit.

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

82 82 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; Verstoß! Idee: Zylinder sollen mit (beliebigen) Zylindern verbunden werden können, Rohre aber nur mit Rohren.

83 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 84 Verfeinerung von Attributen (1) Attributverfeinerung: Retypisierung von Attributen, etwa in der folgenden Form: define type t is structure [... a: t a... ]; end type t; define type t' supertype t is structure [... a: t' a... ]; end type t';

85 85 Verfeinerung von Attributen (2) Einführung von a benutzenden Operationen: Sei t' t t. Lesen von a: t a t.a() bzw. t' a t'.a(); Setzen von a: void t.a:(t a ) 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 86 Verfeinerung von Attributen (3) Abstrakte Beweisskizze: Widerspruchsbeweis: Annahme: t' a ist Untertyp von t a (t' a t t a ). In diesem Fall ist void a:(t' a ) keine legale Verfeinerung von void a:(t a ). Das Argument der verfeinerten Operation müsste dazu nämlich Obertyp sein. Annahme: t' a ist Obertyp von t a (t a t t' a ). In diesem Fall ist t' a t'.a() keine legale Verfeinerung von t a 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 t a sein. Mithin ist Attributverfeinerung unter Aufrechterhaltung strenger Typisierung generell nicht möglich.

87 87 Subtypisierung von Mengentypen (1) Mengentypen: Wenn t i ein Typ ist, soll { t i } der Mengentyp zu t i sein in dem Sinne, dass jedes Objekt dieses Typs eine Menge von Elementen aus t i 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 88 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';

89 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 anwenden.

90 90 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ß! 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 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 92 Mehrfachvererbung (1) Einfachvererbung: GeoKörperZylinderRohrVollzylinderHohlwelleVollwelle Problem: Sowohl Voll- wie Hohlwellen sind Spezialisierungen von Antriebswelle.

93 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 94 Mehrfachvererbung (3) Beispiel: GeoKörperZylinderVollzylinderHohlwelleVollwelleAntriebswelleRohr

95 95 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;

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


Herunterladen ppt "1 Teil I Datenmodelle Kapitel 5: Das objektorientierte Modell."

Ähnliche Präsentationen


Google-Anzeigen