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

Prof. Dr. T. Kudraß 1

Objekt-Datenbanken


Nichtstandard-Anwendungen: Einige Beispiele• Entwurf (CAD)

– Architektur– Maschinenbau– Elektronik (VLSI)– Softwareproduktion– Chemische Strukturen

• Kartographie– Landkarten– Flächenregister

• Bildverarbeitung• Industrielle Produktion

• Auch: Büroautomatisierung usw.


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)


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“


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)


ObjektorientierungUmwelt-ausschnitt

1:N 1:1satzorientiertesDatenmodell

objektorientiertesDatenmodell

Datenbank


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 Datenmodellzusammengesetzte Objekte (strukturiert, komplex), ohne Beschränkung+Möglichkeiten zur Definition typspezifischer Operatoren (und damit neuer Typen) durch Benutzer+OO Aspekte


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


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-ID‘s– während der Objektlebensdauer konstant– üblicherweise systemverwaltet

• Objekt-Referenzen– nicht das gleiche wie referentielle Constraints!– Schlüsselwort: REF<type>– Navigation entlang von Referenzen: Punktnotation


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 Op‘s möglich

interface

impl

O2 O5 O6O3

O4O1

sichtbar

verdeckt

Op1 Op2 Op3 Op4 Op5


Abstrakte Datentypen (auf Attributebene)• Erzeugung problembezogener Datentypen als neue

Basistypen• zugeschnittene Operatoren und Funktionen

– Beispiel: ADT ‘DATE‘, Operator ‘-‘

Normalfall Finanzwelt15. April - 15. März 31 3015. März - 15. Febr. 28 30

SELECT ‘Beschäftigungsdauer‘:Heute() - P.EDATUMFROM PERS P

Weitere Anwendungsbeispiele:Datentypen TEXT, IMAGE, LINE (Funktion Länge u.a.)


Anwendungsbeispiel: Verwaltung räumlicher Objekte• Relationenmodell bietet keine Unterstützung• hohe Komplexität bereits in einfachen Fällen

– Beispiel: Darstellung von Rechtecken in der Ebenea) Relationenmodell

R-ECK (RNR, X1, Y1, X2, Y2: INTEGER)Finde alle Rechtecke, die das Rechteck ((0,0),(1,1)) schneiden!

SELECT RNR FROM R-ECKWHERE (X1 > 0 AND X1 < 1 AND Y1 > 0 AND Y1 < 1)

OR (X1 > 0 AND X1 < 1 AND Y2 > 0 AND Y2 < 1)OR (X2 > 0 AND X2 < 1 AND Y1 > 0 AND Y1 < 1)OR (X2 > 0 AND X2 < 1 AND Y2 > 0 AND Y2 < 1)

(X2,Y2)

(X1,Y1)


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


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


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

ObjekttypMenge spez. Operationen•EINSTELLUNG•VERSETZUNG•GEHALTSERHÖHUNG

SQL-Operationen

Objektorientierung

• Erhöhte Datenunabhängigkeit


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


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

AbhebungEinzahlung

Konto-Nr.InhaberKonto-Stand

Überweisung

Zinssatz

Fälligkeit


Spätes Binden (Late Binding)

Objekt Selektor Parameter

Empfänger zu verarbeitendeMethode

Object1

... Method1

... send ...

Objektx ArgumentxSelektorx

Object2

...

Methodx

<codex2>

Object3

...

Methodx

<codex3>


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


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


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


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!


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

Documents

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