Objektorientierte und objektrelationale Datenbanken

Objektorientierte
und
objektrelationale
Datenbanken
Beschreibung
komplex strukturierter Objekte
R. Oßwald
FHTW Berlin
Programmierverfahren
(Paradigmen)
vor 1960:
maschinenorientierte Programmiersprachen
(Maschinencode, Assembler)
1960:
höhere algorithmische Programmiersprachen
(Algol60, Fortran, Cobol, PL/1, Basic, Pascal)
1970:
strukturierte Programmierung
(Zusammenfassung von zusammengehörenden
Befehlsgruppen in strukturellen Einheiten:
Alternativen, Zyklen; Prozeduren, Funktionen)
1990:
objektorientierte Programmierung
(Klassenkonzept)
objektorientierte Programmierung
wesentliche Konzepte bereits 1967 in Simula festgelegt,
aber keine allgemein anerkannte Einführung
• konsequente Weiterführung der damals noch
umstrittenen strukturierten Programmierung
• ohne den Vorteil einer besonders einfachen CompilerImplementierung (vgl. Pascal !!)
¾ Klassen als nutzereigene Datentypen
¾ Objekte als Ausprägungen einer Klasse
¾ Datenkapselung in Klassen bzw. Objekten
¾ Vererbung als Technologie zum Aufbau von Klassenbzw. Objekt-Hierarchien
¾ Polymorphie zur Darstellung von Objekten als
dynamische Ausprägungen einer Klasse
(wird ermöglicht durch das Konzept des späten Bindens
von Routinen)
Datenstrukturierung
Datentyp: ist definiert durch seinen Wertebereich
und die darauf möglichen Operationen
• stellt ein Schema dar, nach dem Variable vereinbart und
erzeugt werden können
• z.B.:
integer
Wertebereich:
Operationen:
(Standardtyp in Pascal)
-32768 ... 32767
+ - * / mod div
• Probleme:
komplexe Datenstrukturen und
Verwendung nicht vorgesehener Operationen
• Forderung:
nutzerdefinierte Datentypen und
dazu gehörende problembezogene Operationen
(einfachstes Beispiel: komplexe Zahlen!)
abstrakter Datentyp (ADT):
ist ein Schema zur Realisierung eines Datentyps,
dessen Datenstruktur sowie
ausführbare Operationen festgelegt werden,
dessen interne Datenstruktur aber verborgen
(gekapselt) wird.
Beispiel: Stapel (stack)
- verwaltet Elemente eines gegebenen Datentyps nach
dem LIFO-Prinzip
-
zugehörige Operationen sind:
•
•
•
•
•
initial (Name)
push (Element)
pop ()
empty ()
top ()
Erzeugen eines Stapels
Einfügen eines neuen/obersten Elements
Entfernen des obersten Elements
Abfragen, ob der Stapel leer ist
Abfragen (Entnehmen) des obersten
Elements
Schnittstelle
Typname,
Beschreibung der Operationen
Implementierung
Algorithmen zur Realisierung der
Operationen
(einschl. Operation zum Erzeugen
von Variablen zum ADT)
Datenkapselung
vollständige Datenkapselung:
Die Daten eines Objekts werden geheim gehalten
(verborgen, gekapselt).
Die Daten sind daher nicht direkt aus der Kapsel
exportierbar, sondern können nur über vordefinierte
Operationen abgefragt werden.
Datenkapseln sind dort vorteilhaft einsetzbar, wo das
Manipulieren einer komplexen Datenstruktur im
Mittelpunkt steht.
Beispiel: Verwaltung eines Datenbestands
Schnittstelle
Beschreibung der Operationen
Implementierung
gekapselte Datenstruktur
(mit Initialisierung)
Algorithmen zur Realisierung der
Operationen
Klassen
logische Beschreibung:
Eine Klasse ist ein Schema zum Beschreiben von
Objekten ähnlichen Verhaltens.
Zu einer Klasse können beliebig viele Objekte
(Instanzen, Ausprägungen) erzeugt werden.
programmtechnische Beschreibung:
Eine Klasse ist ein nutzerdefinierter Datentyp, der
Daten und Operationen zusammenfaßt.
(siehe ADT und Datenkapselung!)
Objekte
Objekte sind die Laufzeitrepräsentationen einer Klasse,
sie sind ihre konkrete Abbildung im Speicher.
Klassen und Objekte
Eine Klasse ist die rein statische Beschreibung der
Gesamtheit aller möglichen Objekte.
Eine Klasse ist das Speichermuster ihrer Objekte.
Vererbung (inheritance)
Klassen können Hierarchien bilden, indem Oberklassen
(Elternklassen) Instanzvariablen und/oder Methoden an
Unterklassen (Kindklassen) vererben.
Die Vererbung entspricht dem Prinzip der Generalisierung:
• Die Oberklasse enthält und vererbt die allgemeinen
Eigenschaften, während in der Unterklasse spezielle
Angaben hinzukommen können.
• Dabei können in der Unterklasse auch ererbte
Eigenschaften modifiziert (überladen) werden
(virtuelle Methoden).
Oberklasse
Vererbung
Klasse
Nachricht
als Schnittstelle
erklärte
Methoden
und
Variable
ererbte Eigenschaften
(Variable und Methoden)
individuelle Eigenschaften
(Instanzvariable und
Methoden)
Vererbung
Nachricht
Dynamisches Binden
auch als spätes Binden bezeichnet
Für eine Nachricht an ein Objekt wird erst zur Laufzeit
im Objekt eine konkrete Methode ausgewählt.
Polymorphie
Gleiche Botschaften können, an verschiedene Objekte
gesendet, unterschiedliche Reaktionen bewirken.
Voraussetzungen:
• Methoden gleichen Namens für unterschiedliche
Aufgaben in unterschiedlichen Objekten
(Definition virtueller Methoden)
• spätes Binden
(vergleiche: "+"-Zeichen bei integer bzw. string)
Multiple Vererbung
auch als Mehrfachvererbung bezeichnet
Mehrfachvererbung bedeutet, daß eine Objektklasse
gleichzeitig die Eigenschaften von mehreren Oberklassen
erben kann.
DBMS-Klassifikationsmatrix
ad hocAbfragen
a/e
a/k
nur
geplante
Abfragen
g/e
g/k
einfache
Daten
komplexe
Daten
Quadrant "g/e":
• Standard-Textverarbeitung
(MS-Word, WorPerfect, StarWriter, vi, ...)
• einzige Abfrage:
hole Datei
• einzige Aktualisierung:
schreibe Datei
• Nutzung des Dateisystems im Betriebssystem
Quadrant "a/e":
• relationale Datenbanken
• Sprache: SQL-2
Quadrant "g/k":
• Anwendungen zum grafischen Layout
(MF: offene Raumplanung, Chip: Leiterbahnen, ...)
• persistente Programmiersprache; OODBMS
Quadrant "a/k":
• geografische und Bild-DB, techn. Dokumentationen
• spezif. Datentypen, nutzerdefinierte Funktionen
• SQL-3, C++, spezifische Anwendungssysteme
vereinfachte
Sicht:
realistische
Sicht:
ad hocAbfragen
RDBMS
ORDBMS
nur
geplante
Abfragen
DateiSystem
OODBMS
einfache
Daten
komplexe
Daten
ad hocAbfragen
RDBMS
ORDBMS
nur
geplante
Abfragen
DateiSystem
OODBMS
einfache
Daten
komplexe
Daten
einige existierende Systeme:
ORDBMS
OODBMS
DB2/6000 C/S
Illustra =>Informix
Omniscience
Gemstone
Itasca
Jasmine
O2
ObjectStore
Objectivity/DB
Ontos
POET
Open ODB => Odapter
ODB II
UniSQL
Versant
RDBMS-Grenzen:
• keine komplex strukturierten Daten
• Probleme beim Verwalten neuartiger Strukturen
(Codefragmente, HTML-Seiten, audio/video-Dateien, ...)
• Nichtübereinstimmung mit Prinzipien der
oo-Programmierung:
Objekte über eine Vielzahl von
Tabellen verteilt; aufwendige (teure) Verbundoperationen!
OODBMS-Nachteile:
• kein Sichtenkonzept
• Sperrverfahren bei Transaktionen noch unzureichend
• genauer Ablauf von Transaktionen nicht immer genau
vorhersehbar (information hiding: "kleine" Berechnung u.U.
mit lawinenartigen Folgen!)
• primitive Zugriffsrechte (oft nur Freund-Feind-Regelung;
nur selten Abstufungen wie mit grant/revoke)
• bei einigen Systemen: Manipulation im ungeschützten
Hauptspeicher (direkte Manipulation möglich: am OODBMS
vorbei!)
• navigierendes Arbeiten wie in Netzwerk-Datenbanken
• keine eingeführten Standards (in Entwicklung bzw. gerade
erst vorgelegt [2000]: ODMG 2.0, ODL, OQL, SQL-3)
OID == Objektidentifikator
1.) identifiziert jedes Objekt systemweit eindeutig,
2.) wird automatisch, zwingend vom System vergeben,
3.) semantisch unabhängig von Objekteigenschaften,
4.) nicht änderbar,
5.) bleibt über gesamte Systemlebensdauer erhalten,
6.) ermöglicht Duplikate
Multimedia = objektorientiert ???
Multimediale Schauspieleragentur:
• zusammengesetzte Objekte:
Film, Agentur
• einfache Objekte:
Beschreibung, Szene, Sprache
• Methoden:
start, stop, play, pause, display
• Ereignisse (Events)
Ende
Object Database Standard:
• z.Z. [2000] noch erhebliche Unterschiede
(unterstützte Programmiersprachen, Schnittstellen, ...)
• Herstellerabhängigkeit; fehlende Portabilität
• wünschenswert: durchgängige oo Technologie
(oo-Betriebssystem, OODBMS, oo Programmiersprachen)
• Herstellergruppe entwickelt gemeinsamen Standard:
"Object [Data] Management Group"
(Gemstone, Itasca, O2, ObjectStore, Objectivity, POET,
UniSQL und Versant)
• Ziel: Object Request Broker (ORB)
(Interface zwischen Hard- und Softwarekomponenten
verschiedener Hersteller: gemeinsame Schnittstellen!)
• zur Common Object Request Broker Architecture
(CORBA) erweitert
(Dienste- und Schnittstellen-Architektur heterogener,
interoperabler Systeme)
• Ergebnisse:
­
­
­
­
­
ODMG 2.0-Dokument
[1999]
ein Objektmodell,
Objekt-Definitionssprachen
(ODL = Object Definition Language,
OIF = Interface Definition Language),
eine Objekt-Anfragesprache OQL,
Anbindungen an oo Programmiersprachen
(C++, Java, Smalltalk)
Einbindung des Modells in eine ORB-Umgebung
• viele Gemeinsamkeiten zwischen OQL und SQL-3
(Dominanz von SQL am Markt zu erwarten: IBM, Oracle!)
Grundzüge des ODMG-Modells:
(1) Zentrale Modellierungskonstrukte sind:
das Objekt (mit Identität) sowie
das Literal (ohne Identität).
–
–
(2) Objekte und Literale können anhand von Typen
kategorisiert werden, wobei alle Elemente eines Typs
gleiche (Zustands-) Struktur und gleiches Verhalten
besitzen.
(3) Der Zustand eines Objekts wird definiert durch Werte
für eine Menge von Eigenschaften.
Diese Eigenschaften können entweder Attribute des
Objekts oder Beziehungen des Objekts zu anderen
Objekten sein.
(4) Das Verhalten von Objekten wird festgelegt durch
eine Menge von Operationen, welche auf einem
Objekt des betreffenden Typs ausgeführt werden
können.
Operationen müssen eine Liste von Input- und
Output-Parametern besitzen, jeder davon mit
spezifischem Typ.
Eine Operation kann ferner ein Ergebnis mit
spezifischem Typ liefern.
­
­
(5) Ein Typ besitzt grundsätzlich eine externe
Spezifikation und eine (oder auch mehrere)
Implementierungen. Die Spezifikation beschreibt die
nach außen sichtbaren Charakteristika:
Operationen, welche auf den Instanzen des Typs
ausgeführt werden können,
Eigenschaften bzw. Attribute, auf deren Werte
zugegriffen werden kann,
Ausnahmen bzw. Fehlermeldungen oder Ereignisse
(events), die von Operationen ausgelöst werden
können.
­
­
­
(6) Eine Interface-Definition spezifiziert das abstrakte
Verhalten eines Objekttyps.
(7) Eine Literal-Definition legt nur die Zustandsbeschreibung fest.
(8) Eine Klassen-Definition ist eine Kombination aus
Verhaltens- und Zustandsbeschreibung.
(9) Supertypen sind Objekttypen, die eine
Generalisierung (IS_A_Beziehung) erlauben.
(10) Ein (wahlweise benannter) Extent (oder Extension) ist
die Menge aller Ausprägungen eines Typs.
(11) Optional können Attribute eines Typs als Mitglieder
eines Schlüssels (Key) ausgezeichnet werden.
weiterführende Literatur:
Ahrens, K.; Fischer, J.:
Objektorientierte Programmierung
Berlin, München: Verlag Technik, 1992 (ISBN 3-341-01062-9)
Eisele, R.:
Neues von SQL: SQL GOES Object-Oriented
Datenbank-Fokus 2/95, 50-54
IT Verlag für innovative Technologien
Geppert, A.:
Objektorientierte Datenbanksysteme - Ein Praktikum
Heidelberg: dpunkt Verlag, 1997 (ISBN 3-920993-62-4)
Grotehen, Th.; Dittrich, K.:
Objektorientierte Datenbanken auf dem Weg ins Establishment
Datenbank-Fokus 4/95, 48-55
IT Verlag für innovative Technologien
Heuer, A.:
Objektorientierte Datenbanken: Konzepte, Modelle, Systeme
Bonn u.a.: Addison-Wesley, 1992
Meier, A.; Wüst, Th.:
Objektorientierte und objektrelationale Datenbanken (Ein Kompaß für die
Praxis)
Heidelberg: dpunkt Verlag, 2000 (ISBN 3-920993)
Stahlknecht, P.; Hasenkamp, U.:
Einführung in die Wirtschaftsinformatik
Berlin u.a.: Springer, 1999
(ISBN 3-540-65764-9)
Stonebraker, M.:
Objektorientierte Datenbanken: die nächste große Welle
München, Wien: Hanser, 1999
(ISBN 3-446-19334-0)
Vossen, G.:
Datenbankmodelle, Datenbanksprachen und Datenbankmanagementsysteme
München, Wien: R.Oldenbourg, 1999
(ISBN 3-486-24544-9)
Standard ANSI/ISO/IEC 9075-1 ... 9075-5, 1999
Information Technology - Database Languages - SGL, Part 1 ... Part 5
http://www.techstreet.com/features/ISO_IEC_9075.html (15.09.2000)