Objektorientierte Datenbanken

1. Objektorientierte Datenbanken • die nächste Generation der Datenbanktechnologie? • A. Kemper, G. MoerkotteObject-Oriented Database Management: Applications in Engineering and Computer Science, Prentice Hall, 1994 • ca. 12 kommerzielle Produkte • „Nischen-Dasein“ • Konzepte wurden in Relationalen Datenbanken übernommen • Objekt-Relationale Dtaenbanken • seit 1993 erster Standard (ODMG)

2. Nachteile relationaler Modellierung Hülle Begrzg StartEnde x y z Polyeder (4,*) (1,1) Flächen (3,*) (2,2) Kanten (2,2) (3,*) Punkte

3. Nachteile relationaler Modellierung • Segmentierung • Künstliche Schlüsselattribute • Fehlendes Verhalten • Externe Programmierschnittstelle

4. Visualisierung des „Impedance Mismatch“ Anwendung A Anwendung B rotate rotate Transf. TA Transf. TB relationale Datenbasis

5. Vorteile objektorientierter Datenmodellierung Anwendung A Anwendung B someCuboid  rotate(‚X‘,10); w := someCuboid  weight(); scale rotate weight translate ... specWeight volume objektorientierte Datenbasis

6. Vorteile objektorientierter Datenmodellierung • „information hiding“/Objektkapselung • Wiederverwendbarkeit • Operationen direkt in Sprache des Objektmodells realisiert (kein Impedance Mismatch)

7. ODMG-Standardisierung Beteiligte • SunSoft (Organisator: R. Cattell) • Object Design • Ontos • O2Technology • Versant • Objectivity Reviewer • Hewlett-Packard • Poet • Itasca • intellitic • DEC • Servio • Texas Instruments

8. Bestandteile des Standards • Objektmodell • Object Defintion Language (ODL) • Object Query Language (OQL) • C++ Anbindung • Smalltalk Anbindung • Java Anbindung Motivation der Standardisierung • Portabilitäts-Standard • kein Interoperabilitäts-Standard

9. Integration des ODMG-Objektmodells C++ Java Smalltalk Objekt- modell DBMS Anwendung Anwendung Anwendung

10. Einige Objekte aus der Universitätswelt • class Professoren { • attributelongPersNr; • attribute stringName; • attribute stringRang; • … • };

11. 1 : 1-Beziehungen residiert in 1 1 Professoren Räume • class Professoren { • attribute long PersNr; • ... • relationship Räume resisdiertIn; • }; • class Räume { • attribute long RaumNr; • attribute short Größe; • ... • relationship Professoren beherbergt; • };

12. Beispielausprägungen

13. Beispielausprägungen • Nachteile • Verletzung der Symmetrie • Verletzung der 1:1-Einschränkung

14. Bessere Modellierung mit „inverse“ class Professoren { attributelong PersNr; ... relationship Räume residiertIn inverse Räume::beherbergt; }; class Räume { attributelong RaumNr; attributeshort Größe; ... relationship Professoren beherbergt inverse Professoren::residiertIn };

15. 1 : N-Beziehungen lesen 1 N Professoren Vorlesungen • class Professoren { • ... • relationshipset(Vorlesungen) liest inverseVorlesungen::gelesenVon; • }; • class Vorlesungen { • ... • relationshipProfessoren gelesenVon inverse Professoren::liest; • };

16. N : M-Beziehungen hören N M Studenten Vorlesungen • class Studenten { • ... • relationshipset(Vorlesungen) hört inverseVorlesungen::Hörer; • }; • class Vorlesungen { • ... • relationshipset(Studenten) Hörer inverseStudenten::hört; • };

17. Rekursive N : M-Beziehungen voraussetzen N Vorlesungen M • class Vorlesungen { • ... • relationship set(Vorlesungen) Vorgänger inverseVorlesungen::Nachfolger; • relationship set(Vorlesungen) Nachfolger inverseVorlesungen::Vorgänger; • };

18. Ternäre Beziehungen prüfen Vorlesungen Professoren Studenten • class Prüfungen { • attribute struct Datum • { short Tag;short Monat; short Jahr} Prüfdatum; • attribute float Note; • relationship Professoren Prüfer inverse Professoren::hatGeprüft; • relationship Studenten Prüfling inverse Studenten::wurdeGeprüft; • relationshipVorlesungen Inhalt inverse Vorlesungen::wurdeAbgeprüft; • };

19. Vervollständigtes Universitäts-Schema class Professoren { attribute long PersNr; attribute string Name; attribute string Rang: relationshipRäume residiertIn inverseRäume::beherbergt; relationship set(Vorlesungen) liest inverseVorlesungen::gelesenVon relationship set(Prüfungen) hatGeprüft inverse Prüfungen::Prüfer; }; class Vorlesungen { attribute longVorlNr; attribute stringTitel; attribute short SWS; relationship Professoren gelesenVon inverse Professoren::liest; relationship set(Studenten) Hörer inverseStudenten::hört; relationship set(Vorlesungen) Nachfolger inverse Vorlesungen::Vorgänger; relationship set(Vorlesungen) Vorgänger inverse Vorlesungen::Nachfolger; relationship set(Prüfungen) wurdeAbgeprüft inverse Prüfungen::Inhalt; }; class Studenten { ... relationship set(Prüfungen) wurdeGeprüft inverse Prüfungen::Prüfling; };

20. Modellierung von Beziehungen im Objektmodell Vorlesungen Räume beherbergt resisiertIn Studenten Professoren wurdeGeprüft hatGeprüft hört liest Prüfungen Prüfer Prüfling Inhalt wurdeAbgeprüft Hörer gelesenVon Vorgänger Nachfolger

21. Einige Objekte aus der Universitätswelt

22. Eigenschaften von Objekten • Im objektorientierten Modell hat ein Objekt drei Bestandteile: • Identität • Typ • Wert/Zustand

23. voraussetzen Uni-Schema Nach- folger VorlNr MatrNr Vorgänger N M hören SWS Vorlesungen Name Studenten N M N N Titel Semester M lesen prüfen Note PersNr 1 1 Rang arbeitenFür Name Assistenten Professoren Raum N 1 Fachgebiet PersNr Name

25. Einige Objekte aus der Universitätswelt

26. Objekt-Identität • Das wesentliche Charakteristikum objekt-orientierter Datenmodellierung • Verweise werden über die OID realisiert • Zwei Realisierungsformen • Physische OIDs • Enthalten den Speicherort des Objekts • Im wesentlichen entsprechen diese den Tupel IDentifikatoren (TIDs) • Logische OIDs • Unabhängig vom Speicherort der Objekte • D.h. Objekte können verschoben werden • Indirektion über eine „Mapping“-Struktur • B-Baum • Hash-Tabelle • Direct Mapping

27. Realisierung physischer OIDs

28. Drei Realisierungstechniken für logische OIDs

29. Typeigenschaften: Extensionen und Schlüssel class Studenten (extent AlleStudenten key MatrNr) { attribute longMatrNr; attribute string Name; attribute short Semester; relationship set(Vorlesungen) hört inverse Vorlesungen::Hörer; relationship set(Prüfungen) wurdeGeprüft inverse Prüfungen::Prüfling; };

30. Modellierung des Verhaltens: Operationen Operationen um ... • Objekte zu erzeugen (instanziieren) und zu initialisieren, • die für Klienten interessanten Teile des Zustands der Objekte zu erfragen, • legale und konsistenzerhaltendeOperationen auf diesen Objekten auszuführen und letztendlich • die Objekte wieder zu zerstören.

31. Modellierung des Verhaltens: Operationen II Drei Klassen von Operationen: • Beobachter (engl. observer): • oft auch Funktionen genannt • Objektzustand „erfragen“ • Beobachter-Operationen haben keinerlei objektändernde Seiteneffekte • Mutatoren: • Änderungen am Zustand der Objekte. • Einen Objekttyp mit mindestens einer Mutator-Operation bezeichnet man als mutierbar. • Objekte eines Typs ohne jegliche Mutatoren sind unveränderbar (engl. immutable). • Unveränderbare Typen bezeichnet man oft als Literale oder Wertetypen.

32. Modellierung des Verhaltens: Operationen III • Konstruktoren und Destruktoren: • Erstere werden verwendet, um neue Objekte eines bestimmten Objekttyps zu erzeugen. • Instanziierung • Der Destruktor wird dazu verwendet, ein existierendes Objekt auf Dauer zu zerstören • Konstruktoren werden sozusagen auf einem Objekttyp angewandt, um ein neues Objekt zu erzeugen. • Destruktoren werden dem gegenüber auf existierende Objekte angewandt und können demnach eigentlich auch den Mutatoren zugerechnet werden.

33. Klassen-Definition von Operationen in ODL Man spezifiziert • den Namen der Operation; • die Anzahl und die Typen der Parameter; • den Typ des Rückgabewerts der Operation; • eine eventuell durch die OperationsausführungausgelösteAusnahmebehandlung (engl. exceptionhandling).

34. Klassen-Definition von Operationen in ODL Beispiel-Operationen class Professoren { exception hatNochNichtGeprüft {}; exception schonHöchsteStufe {}; ... float wieHartAlsPrüfer()raises (hatNochNichtGeprüft); voidbefördert() raises (schonHöchsteStufe); }; Aufruf der Operationen im Anwendungsprogramm: in OQL: meinLieblingsProfbefördert(); select p.wieHartAlsPrüfer() from p in AlleProfessoren where p.Name = „Curie“;

35. Vererbung und Subtypisierung Uni-Mitglieder Name is-a MatrNr PersNr Studenten Angestellte is-a Rang Fachgebiet Assistenten Professoren Raum

36. Terminologie Instanzen Objekttypen • Untertyp / Obertyp • Instanz eines Untertyps gehört auch zur Extension des Obertyps • Vererbung der Eigenschaften eines Obertyps an den Untertyp A Typ1 is-a B Typ2 is-a C Typ3

37. Darstellung der Subtypisierung AB A ExtTyp1 • Inklusionspolymorphismus • Subtituierbarkeit • Eine Untertyp-Instanz ist überall dort einsetzbar, wo eine Obertyp-Instanz gefordert ist. ExtTyp2 ExtTyp3 A B C

38. Abstrakte Typhierarchie bei Einfach-Vererbung ANY ... is-a is-a is-a ... OT1 ... is-a is-a is-a is-a is-a is-a ... OT2 ... is-a is-a is-a ... ... Otn-1 is-a is-a is-a ... OTn eindeutiger Pfad: Otn Otn-1  ...  OT2  OT1  ANY

39. Vererbung von Eigenschaften PersNr Name Angestellte GebDatum PersNr Alter() Name Gehalt() is-a GebDatum PersNr Alter() Name Gehalt() Assistenten Professoren GebDatum Rang Alter() resisidertIn Gehalt() hatGeprüft Fachgebiet liest

40. Interface-Definition in ODL class Angestellte (extent AlleAngestellte) { attribute long PersNr; attribute string Name; attribute date GebDatum; short Alter(); long Gehalt(); }; class Assistenten extends Angestellte (extentAlleAssistenten) { attribute string Fachgebiet; }; class Professorenextends Angestellte (extent AlleProfessoren) { attribute stringRang; relationshipRäume residiertIn inverse Räume::beherbergt; relationship set(Vorlesungen) liest inverse Vorlesungen::gelesenVon; relationship set(Prüfungen) hatGeprüft inverse Prüfungen::Prüfer; };

41. Darstellung der Extensionen AlleAngestellten AlleAssistenten AlleProfessoren

42. Verfeinerung und spätes Binden {id1, id11, id7} • Die Extension AlleAngestellten mit (nur) drei Objekten AlleAngestellten:

43. Verfeinerung (Spezialisierung) der Operation Gehalt • Angestellteerhalten: 2000 + (Alter() – 21) * 100 • Assistenten bekommen: 2500 + (Alter() – 21) * 125 • Professorenerhalten: 3000 + (Alter() – 21) * 150 selectsum(a.Gehalt()) from a in AlleAngestellten • für das Objekt id1 wird die Professoren-spezifische Gehalts-Berechnung durchgeführt, • für das Objekt id11 die Assistenten-spezifische und • für das Objekt id7 die allgemeinste, also Angestellten-spezifische Realisierung der Operation Gehalt gebunden.

44. Graphik: Mehrfachvererbung Angestellte Studenten • geht so in ODMG nicht • eine Klasse kann nur von einer Klasse erben • sie kann aber auch mehrere Interfaces implementieren – à la Java is-a HiWis Angestellte IF Angestellte Studenten implementiert Schnittstelle HiWis erbt

45. Interface- / Klassendefinition in ODL class HiWis extends Studenten, Angestellte (extent AlleHiWis) { attributeshort Arbeitsstunden; ... }; interface AngestellteIF { short Alter(); long Gehalt(); }; class HiWis extends Studenten : AngestellteIF (extent AlleHiWis) { attributelong PersNr; attributedate Gebdatum; attributeshort Arbeitsstunden; };

46. Die Anfragesprache OQL Einfache Anfragen • finde die Namen der C4-Professoren select p.Name from p in AlleProfessoren where p.Rang = „C4“; • Generiere Namen- und Rang-Tupel der C4-Professoren selectstruct(n: p.Name, r: p.Rang) from p in AlleProfessoren where p.Rang = „C4“; Geschachtelte Anfragen und Partitionierung selectstruct(n: p.Name, a: sum(select v.SWS from v in p.liest)) from p in Alle Professoren whereavg(select v.SWS from v in p.liest) > 2;

47. Pfadausdrücke in OQL-Anfragen select s.Name from s in AlleStudenten, v in s.hört where v.gelesenVon.Name = „Sokrates“; • Visualisierung des Pfadausdruckes hört gelesenVon Name Professoren Studenten Vorlesungen • ein längerer Pfadausdruck • eineVorlesung.gelesenVon.residiertIn.Größe Vorlesungen Professoren Räume float

48. Erzeugung von Objekten Vorlesungen(VorlNr: 5555, Titel: „Ethik II“, SWS: 4, gelesenVon: ( select p from p in AlleProfessoren where p.Name = „Sokrates“ )); Operationsaufruf in OQL-Anfragen select a.Name from a in AlleAngestellte where a.Gehalt() > 100.000;

49. Programmiersprachen-Anbindung Entwurfsentscheidung • Entwurf einer neuen Sprache • eleganteste Methode, • hoher Realisierungsaufwand • Benutzer müssen eine neue Programmiersprache lernen • Erweiterung einer bestehenden Sprache • Benutzer müssen keine neue Sprache lernen • manchmal unnatürlich wirkende Erweiterungen der Basissprache • Datenbankfähigkeit durch Typbibliothek • einfachste Möglichkeit für das Erreichen von Persistenz • mit den höchsten „Reibungsverlusten“ • evtl. Probleme mit der Transparenz der Einbindung und der Typüberprüfung der Programmiersprache • ODMG-Ansatz

50. C++-Einbindung ODLKlassendeklarationen Objektcode Metadaten Objekte ODBMS Laufzeit-Bibliothek Headerdateien Quellcode AnwendungLaufzeit-System Präprozessor C++-Compiler Linker Objektbank