Prof. Dr. T. Kudraß 1
Objekt-Datenbanken
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.
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)
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“
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)
Prof. Dr. T. Kudraß 6
ObjektorientierungUmwelt-ausschnitt
1:N 1:1satzorientiertesDatenmodell
objektorientiertesDatenmodell
Datenbank
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 Datenmodellzusammengesetzte Objekte (strukturiert, komplex), ohne Beschränkung+Möglichkeiten zur Definition typspezifischer Operatoren (und damit neuer Typen) durch Benutzer+OO Aspekte
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
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-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
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 Op‘s möglich
interface
impl
O2 O5 O6O3
O4O1
sichtbar
verdeckt
Op1 Op2 Op3 Op4 Op5
Prof. Dr. T. Kudraß 11
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.)
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 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)
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-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 ...
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
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
ObjekttypMenge spez. Operationen•EINSTELLUNG•VERSETZUNG•GEHALTSERHÖHUNG
SQL-Operationen
Objektorientierung
• Erhöhte Datenunabhängigkeit
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
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
AbhebungEinzahlung
Konto-Nr.InhaberKonto-Stand
Überweisung
Zinssatz
Fälligkeit
Prof. Dr. T. Kudraß 18
Spätes Binden (Late Binding)
Objekt Selektor Parameter
Empfänger zu verarbeitendeMethode
Object1
... Method1
... send ...
Objektx ArgumentxSelektorx
Object2
...
Methodx
<codex2>
Object3
...
Methodx
<codex3>
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)
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
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
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!
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