Prof. Dr. T. Kudraß1 Objekt-Datenbanken. Prof. Dr. T. Kudraß2 Nichtstandard-Anwendungen: Einige Beispiele Entwurf (CAD) –Architektur –Maschinenbau –Elektronik.

Präsentation zum Thema: "Prof. Dr. T. Kudraß1 Objekt-Datenbanken. Prof. Dr. T. Kudraß2 Nichtstandard-Anwendungen: Einige Beispiele Entwurf (CAD) –Architektur –Maschinenbau –Elektronik."—  Präsentation transkript:

1 Prof. Dr. T. Kudraß1 Objekt-Datenbanken

2 Prof. Dr. T. Kudraß2 Nichtstandard-Anwendungen: Einige Beispiele Entwurf (CAD) –Architektur –Maschinenbau –Elektronik (VLSI) –Softwareproduktion –Chemische Strukturen Kartographie –Landkarten –Flächenregister Bildverarbeitung Industrielle Produktion Auch: Büroautomatisierung usw.

3 Prof. Dr. T. Kudraß3 Neue Anforderungen: Modellierung von Struktur hochstrukturierte Informationen –beliebig zusammengesetzte Objekte –beliebige Beziehungen zwischen Objekten z.B. benutzt, abgeleitet von –Versionen Alternativen, Revisionen, Varianten Konfigurationen –spezielle Attributwertebereiche Vektoren, Matrizen, Geometrie –Beziehungen zwischen Typen von Objekten Generalisierung / Spezialisierung unstrukturierte Informationen –multimediale Informationen (BLOB)

4 Prof. Dr. T. Kudraß4 Neue Anforderungen: Modellierung von Verhalten mächtige Operatoren zum Umgang mit hochstrukturierter Information –passende Operatoren für alle Arten von Zusammensetzungen, Beziehungen –passende Operatoren für alle Attributwertebereiche, Versionen Berücksichtigung typspezifischen Verhaltens –große Vielfalt von Informationstypen –Gemeinsamkeiten ähnlicher Typen Beispiel: Verschiebe Viereck

5 Prof. Dr. T. Kudraß5 Beschränkungen klassischer Datenmodelle einfach strukturierte Datenobjekte –satzorientiert, festes Format geringe semantische Ausdrucksfähigkeit –fehlende Abstraktionskonzepte nur einfache Integritätsbedingungen umständliche Einarbeitung in Programmiersprachen auf kurze Transaktionen zugeschnitten (ACID) keine Unterstützung von –Zeit und Versionen –räumlichen Beziehungen mangelnde Effizienz bei anspruchsvollen Anwendungen (z.B. Verarbeitung von komplexen Joins)

6 Prof. Dr. T. Kudraß6 Objektorientierung Umwelt- ausschnitt 1:N1:1 satzorientiertes Datenmodell objektorientiertes Datenmodell Datenbank

7 Prof. Dr. T. Kudraß7 Satzorientiert vs. Objektorientiert Satzorientiertes Datenmodell einfache Objekte aus atomaren oder zusammengesetzten Typen (beschränkte Zusammensetzung) –keine Definition beliebiger neuer Typen + ausschließlich vordefinierte generische Operatoren –Objekte erzeugen und löschen –Attributwerte modifizieren –Suche nach Attributwerten (Voll) Objektorientiertes Datenmodell zusammengesetzte Objekte (strukturiert, komplex), ohne Beschränkung + Möglichkeiten zur Definition typspezifischer Operatoren (und damit neuer Typen) durch Benutzer + OO Aspekte

8 Prof. Dr. T. Kudraß8 Definition eines objektorientierten DBMS OODBMS muß zwei Kriterien erfüllen –es muß ein DBMS sein –es muß ein objektorientiertes System sein DBMS-Aspekte –Persistenz –Externspeicherverwaltung –Synchronisation (Concurrency Control) –Logging und Recovery –Ad-hoc-Anfragesprache OO-Aspekte –Objektidentität –komplexe Objekte –Kapselung –Typ-/Klassenhierarchie –Vererbung –Überladen (Overloading) und spätes Binden (Late Binding) –Erweiterbarkeit

9 Prof. Dr. T. Kudraß9 Objektidentität Existenz des Objekts ist unabhängig von seinem Wert Objektidentität –nicht durch anwendungsspezifische Werte wie im Relationenmodell –eindeutige Objekt-Identifikatoren (Surrogate) –Objekte können identisch oder gleich sein Objekt-IDs –während der Objektlebensdauer konstant –üblicherweise systemverwaltet Objekt-Referenzen –nicht das gleiche wie referentielle Constraints! –Schlüsselwort: REF –Navigation entlang von Referenzen: Punktnotation

10 Prof. Dr. T. Kudraß10 interface impl interface impl interface impl Kapselung von Objekten interface impl Instanzen benutzerdefinierter Typen unsichtbar Code der Operatoren bleibt Anwender verborgen Anwender sieht nur Operatorschnittstellen –Objektzugriff ausschließlich mit den definierten Ops möglich interface impl O2O5O6 O3 O4O1 sichtbar verdeckt Op1Op2Op3Op4Op5

11 Prof. Dr. T. Kudraß11 Abstrakte Datentypen (auf Attributebene) Erzeugung problembezogener Datentypen als neue Basistypen zugeschnittene Operatoren und Funktionen –Beispiel: ADT DATE, Operator - NormalfallFinanzwelt 15. April - 15. März 31 30 15. März - 15. Febr. 28 30 SELECT Beschäftigungsdauer:Heute() - P.EDATUM FROM PERS P Weitere Anwendungsbeispiele: Datentypen TEXT, IMAGE, LINE (Funktion Länge u.a.)

12 Prof. Dr. T. Kudraß12 Anwendungsbeispiel: Verwaltung räumlicher Objekte Relationenmodell bietet keine Unterstützung hohe Komplexität bereits in einfachen Fällen –Beispiel: Darstellung von Rechtecken in der Ebene a) Relationenmodell R-ECK (RNR, X1, Y1, X2, Y2: INTEGER) Finde alle Rechtecke, die das Rechteck ((0,0),(1,1)) schneiden! SELECT RNR FROM R-ECK WHERE (X1 > 0 AND X1 0 AND Y1 < 1) OR (X1 > 0 AND X1 0 AND Y2 < 1) OR (X2 > 0 AND X2 0 AND Y1 < 1) OR (X2 > 0 AND X2 0 AND Y2 < 1) (X2,Y2) (X1,Y1)

13 Prof. Dr. T. Kudraß13 Anwendungsbeispiel: Verwaltung räumlicher Objekte b) ADT-Lösung ADT BOX mit Funktionen INTERSECT, CONTAINS, AREA usw. R-ECK (RNR: INTEGER, Beschr: BOX) SELECT RNR FROM R-ECK WHERE INTERSECT (Beschr, (0,0,1,1)) in SQL: CREATE TYPE BOX x1: integer, y1: integer, x2: integer, y2: integer, member function intersect... member function contains... member function area...

14 Prof. Dr. T. Kudraß14 Zusätzliche Typkonstruktoren Erzeugen strukturierter Datentypen aus Basistypen Relationenmodell beschränkt auf Bildung von Tupeln und Relationen Wünschenswert: –ARRAY-Konstruktor (VEKTOR) –TUPLE –LIST –SET –MULTISET / BAG Beliebige Kombination aller Konstruktoren zum Aufbau komplexer Objekte

15 Prof. Dr. T. Kudraß15 ADTs auf Objektebene Jedes Objekt ist gekapselt und besitzt eine objektspezifische Menge von Operationen –Struktur des Objektes ist verborgen –Verhalten des Objekts ausschließlich durch seine Operationen bestimmt –Implementierung der Operationen bleibt verborgen XXX ANGESTELLTER Relation Objekttyp Menge spez. Operationen EINSTELLUNG VERSETZUNG GEHALTSERHÖHUNG SQL-Operationen Objektorientierung Erhöhte Datenunabhängigkeit

16 Prof. Dr. T. Kudraß16 Typen / Klassen Typ –Menge von Werten –Beschreibung von Objekten mit gleicher Struktur / gleichen Operatoren Begriff aus der DBS-Welt Klasse –Menge von Objekten mit spezifischen Eigenschaften –besitzt Methoden, gehört zu einer Klassenhierarchie –im Vergleich zu Typen steht die Erzeugung neuer Instanzen der Klasse im Vordergrund (NEW-Methode) Begriff aus der OOPL-Welt

17 Prof. Dr. T. Kudraß17 Typ-/Klassenhierarchie und Vererbung Anordnung von Objekttypen in Generalisierungs-/Spezialisierungs- hierarchie (IS-A-Beziehung) disjunkte/überlappende bzw. partielle/vollständige Spezialisierung Vererbung von –Attributen –Integritätsbedingungen –Default-Werten –Methoden / Funktionen Arten der Vererbung –einfach (Hierarchie) –mehrfach (Typverband) –selektiv Vorteile des Vererbungsprinzips –Code-Wiederverwendung –Modellierungsdisziplin (schrittweise Verfeinerung) KONTO SPAR- BUCH GIRO- KONTO FEST- ZINS SB Abhebung Einzahlung Konto-Nr. Inhaber Konto-Stand Überweisung Zinssatz Fälligkeit

18 Prof. Dr. T. Kudraß18 Spätes Binden (Late Binding) ObjektSelektorParameter Empfänger zu verarbeitende Methode Object 1... Method 1... send... Objekt x Argument x Selektor x Object 2... Method x Object 3... Method x

19 Prof. Dr. T. Kudraß19 Überladen (Overloading) und spätes Binden Methoden können für Subklassen redefiniert werden Name der Methode bleibt gleich, Wirkung der Methode ist objektabhängig (Overloading) –Beispiel: DISPLAY-Funktion für geometrische Objekte kann für jeden Objekttyp neu definiert werden Variante: generische Funktionen –Beispiel: allgemeine COUNT-Funktion für Mengenobjekte (unabhängig vom Komponententyp) –Überladen impliziert (meistens) Binden zur Laufzeit (late binding)

20 Prof. Dr. T. Kudraß20 Operationale Vollständigkeit nicht alle Berechnungen in herkömmlichen DB-Anfragesprachen möglich –DML ist Teilsprache Einbettung in allgemeine Programmiersprache Verwendung zweier Sprachen führt zu Problemen (Impedance Mismatch) –unterschiedliche Typ-Systeme nur begrenzte Typ-Prüfungen möglich Menge von Objekten mit spezifischen Eigenschaften –deklarative DML vs. prozedurale Programmiersprache –mengen- vs. satzorientierte Verarbeitung (Cursor-Konzept) umständliche, fehleranfällige Programmierung Ziel: –einheitliche DB-Programmiersprache –mit persistenten Datenstrukturen

21 Prof. Dr. T. Kudraß21 Schnittstelle eines OODBS OO Sprach-Schnittstelle –strikte Kapselung erlaubt nur Methodenaufrufe –beschränkte Ausdrucksmächtigkeit vor allem beim Retrieval –beträchtliche Erweiterung für OODBS erforderlich –Einführung eines objektorientierten Datenmodells (OODM) OO Datenmodell als Schnittstelle eines OODBS –Datendefinition durch DDL –Datenmanipulation durch DML (deklarativ / prozedural) –Integritäts- und Zugriffskontrolle Eigenschaften der Sprachschnittstellen –deklarative DML nur für ad-hoc-Anfragen (verletzt Kapselung) –prozedurale DML ist eine allgemeine Programmiersprache (z.B. C++) mit einer Query-Sprache als Teilmenge, um programmierte Anfragen auszuführen

22 Prof. Dr. T. Kudraß22 Fazit Man kann ALLES in einem relationalen DBMS (+ einer konventionellen Programmiersprache) ausdrücken: ABER: In vielen Fällen gibt es bessere Wege zum Ziele BESSERE EFFIZIENZ –Entwurfs-, Entwicklungs- und Wartungseffizienz –Ausführungseffizienz durch verbesserte Datenmodellierung (umfassender, präziser) durch verbesserte Verhaltensmodellierung (Programm- entwicklung angepaßt) DAHER: objektorientierte Datenbanktechnologie!

23 Prof. Dr. T. Kudraß23 Trends Weiterentwicklung relationaler zu objektrelationalen DBMS (vgl. auch SQL:1999) –BLOB Datentypen –benutzerdefinierte Datentypen und Datenbankroutinen –typisierte Tabellen –gegenwärtig noch große Heterogenität der DBMS –Pakete für benutzerdefinierte Erweiterung (z.B. Informix Data Blades) Gateway-Ansatz zur Integration von Persistenz in objekt- orientierten Anwendungen –Middleware-Lösung zur Nutzung nicht-objektorientierter Datenquellen –Intelligentes Cache-Management und Entwicklungswerkzeuge (z.B. Transformation Objektmodell relationales Datenmodell) –Kommerzielle Tools: Persistence, Toplink, Roguewave Objektorientierte Datenbanksysteme –Produkte: ObjectStore (jetzt: eXcelon), Versant, Poet