Objektorientierte und objektrelationale Datenbanken
Werbung
Objektorientierte und objektrelationale Datenbanken Ein Kompass für die Praxis von Andreas Meier, Thomas Wüst 3., überarb. u. aktualis. Aufl. Objektorientierte und objektrelationale Datenbanken – Meier / Wüst schnell und portofrei erhältlich bei beck-shop.de DIE FACHBUCHHANDLUNG Thematische Gliederung: Zeichen- und Zahlendarstellungen dpunkt.verlag 2003 Verlag C.H. Beck im Internet: www.beck.de ISBN 978 3 89864 191 3 Inhaltsverzeichnis: Objektorientierte und objektrelationale Datenbanken – Meier / Wüst 1 1 Der Weg zur Objektorientierung bei Datenbanksystemen Im einführenden Abschnitt 1.1 erläutern wir die unterschiedlichen Benutzergruppen von Datenbanksystemen und gehen kurz auf die Grobarchitektur solcher Systeme ein. Danach geben wir in Abschnitt 1.2 einen informellen Überblick über wesentliche Konzepte der Objektorientierung wie Objekt, Vererbung und Klassenhierarchie. Daran anschließend können wir in Abschnitt 1.3 objektorientierte und objektrelationale Datenbanksysteme definieren, indem wir mit den Regeln des Datenbank-Manifestes deren Eigenschaften beschreiben. In Abschnitt 1.4 diskutieren wir Chancen und Risiken beim Einsatz objektorientierter und objektrelationaler Datenbanksysteme in der Praxis. 1.1 Zum Einsatz von Datenbanksystemen Beim Aufbau und beim Betrieb von Informationssystemen bedient man sich sinnvollerweise so genannter Datenbanksysteme zum Verarbeiten und Verwalten von Datenbeständen. Ein Datenbanksystem (engl. database system) besteht aus zwei wesentlichen Komponenten: Die Datenbank dient zur Aufbewahrung sowohl der Benutzer- wie der Beschreibungsdaten (oft Metadaten genannt), und das Verwaltungssystem verfügt darüber hinaus über eine Sprache zur Definition, Manipulation und Auswertung der Daten. In Abbildung 1–1 ist ein Datenbanksystem mit unterschiedlichen Benutzergruppen schematisch dargestellt. Gelegentliche Benutzer verwenden eine einfache Sprache, mit der sich ohne große Informatikkenntnisse Ad-hoc-Abfragen formulieren und Auswertungen aufbereiten lassen. Sachbearbeiter aus unterschiedlichen Fachabteilungen oder aus dem Verkauf bedienen sich vordefinierter Abfragen oder spezifischer Anwendungsfunktionen, die ihnen die gewünschten Informationen und Zusammenhänge ohne großen Zeitverzug liefern. Die Anwendungsprogrammierer benutzen sowohl die Abfragesprache wie die Die zwei Komponenten eines Datenbanksystems Datenbankbenutzer, -programmierer und -administratoren 2 1 Der Weg zur Objektorientierung bei Datenbanksystemen Abb. 1–1 Sachbearbeiter Grobarchitektur eines Datenbanksystems mit Benutzergruppen Programmierer gelegentlicher Benutzer Administrator Abfrage Abfrageprogramm Anwendungsprogramm Abfragesprache Datenmanipulationssprache Datenbankschema Datendefinitionssprache Schemaverwaltung Anfragebearbeitung Verwaltungssystem mit Mehrbenutzersynchronisation Benutzerdaten Beschreibungsdaten Das Schema einer Datenbank Gewährleistung des Mehrbenutzerbetriebs umfassendere Datenmanipulationssprache, um maßgeschneiderte Anwendungen herstellen zu können. Die Datenbankadministratoren teilen dem Datenbanksystem Schemaänderungen mit Hilfe einer Datendefinitionssprache mit. Dazu müssen die gewünschten Gegebenheiten aus der realen Welt analysiert und in einem Datenbankentwurfsverfahren strukturiert beschrieben werden. Blickt man ins Innere eines Datenbanksystems (vgl. Abbildung 1–1), so erkennt man unterschiedliche Systemkomponenten. Die Schnittstelle zu den Benutzergruppen bilden die Datendefinitionssprache, die Abfragesprache und die Datenmanipulationssprache. Das eigentliche Schema der Datenbank, d.h. die Beschreibung der Daten und der gewünschten Beziehungen, wird ebenfalls in der Datenbank abgelegt. So definiert man mit Hilfe der Datendefinitionssprache pro Anwendungsbereich ein Datenbankschema. Um die Benutzerdaten in der Datenbank ablegen und verändern zu können, verwendet man die Datenmanipulationssprache. Da mehrere Benutzer oft gleichzeitig ein und dieselbe Datenbank bearbeiten, muss ein Datenbanksystem den Mehrbenutzerbetrieb jederzeit garantieren. Die Kontrolle über die unterschiedlichen Wechselwirkungen der einzelnen Benutzeraktionen wird also vom System wahrgenommen. Gelegentliche Benutzer wie auch Fachspezialisten sind darauf angewiesen, Auswertungen und Abfragen an die Datenbasis jederzeit 1.2 Was sind Objekte? vornehmen zu können. Das Datenbanksystem verfügt deshalb neben der Abfragesprache über eine Komponente, die Abfragen in Datenbankaufrufe übersetzt und die notwendigen Optimierungen vornimmt. Datenbanksysteme unterscheiden sich in der Art und Weise, wie die Daten der realen Welt in der Datenbasis durch ein Datenmodell abgebildet werden und wie mächtig die entsprechende Datenbanksprache ist. So gibt es hierarchische oder netzwerkartige Datenbanksysteme, die in der Datenbank Hierarchien oder Netzwerke von Datensätzen zulassen und in der zugehörigen Sprache Such-, Navigations- und Veränderungsoperationen auf der entsprechenden Datenbasis unterstützen. Relationale Datenbanksysteme wiederum kennen zur Verwaltung der Daten ausschließlich Tabellen (Menge homogener Datensätze), und die relationale Datenbanksprache vermag Tabellenteile zu definieren, zu verändern oder auszuwerten (vgl. die Sprache Structured Query Language oder abgekürzt SQL). SQL:2003, der aktuelle Standard (siehe auch Kapitel 3.4.3), berücksichtigt einige Elemente der Objektorientierung. Somit konnten Hersteller relationaler Datenbanksoftware ihre Produkte zu objektrelationalen Datenbanksystemen (ORDBS) erweitern. Diese Systeme bieten objektorientierte Schnittstellen an, obwohl sie ihre Daten nach wie vor in Tabellen ablegen. Schließlich verwalten objektorientierte Datenbanksysteme (OODBS) ihre Daten in Objektform, und die zugehörige Sprache ist objektorientiert. 1.2 3 Die Mächtigkeit eines Datenbanksystems Was sind Objekte? Objekte sind Grundbausteine, aus welchen objektorientierte Anwendungssysteme aufgebaut werden. Jedes Objekt ist eine eigenständige Einheit, die über Daten (Attributwerte des Objekts) und Verhalten (Methoden oder Operationen des Objekts) verfügt. Objekte mit identischer Struktur und gleichem Verhalten werden zu Klassen abstrahiert. In Abbildung 1–2 ist eine einfache Klasse Instrument zusammen mit zwei konkreten Objekten oder Instanzen schematisch dargestellt. Alle Objekte einer bestimmten Klasse haben dieselben Attribute und verhalten sich gleich: Zum Beispiel besitzt jedes Objekt der Klasse Instrument die Attribute artikelNummer, bezeichnung und preis. Zudem sind die Objekte durch die Zugriffsmethoden lesenPreis und ändernPreis abgeschirmt. Die eigentlichen Attributwerte sind dem Anwender unzugänglich, außer er arbeitet mit den vorgeschriebenen Methoden. Daher werden die Objekte oft kreisförmig dargestellt: Im Innern sind die zu schützenden Attributwerte aufgelistet, umgeben von einem Mantel von Metho- Zur Klassenbildung Das Prinzip der Kapselung 4 1 Der Weg zur Objektorientierung bei Datenbanksystemen Abb. 1–2 Klasse als Abstraktion von Objekten Klasse Instrument artikelNummer bezeichnung preis Attribute Menge von Objekten (Instanzen) lesenPreis ändernPreis Methoden lesen Preis lesen Preis 711-214 änFagott dern 14.980 Preis 259-693 Tenorsax ändern 5.035 Preis Die Vererbungseigenschaft den, die die sichtbare Schnittstelle bilden. Diese Kapselung verhindert unzulässige Zustandsänderungen von Objekten und führt zu einer wünschenswerten Entkoppelung von Anwendern dieser Klasse und internen Klassendetails. Ein weiteres Grundprinzip der Objektorientierung bildet die Vererbung bezüglich einer Klassenhierarchie. Sind die Objekte einer Klasse BlasInstrument spezieller als die einer Klasse Instrument, so kann man die Blasinstrumente als Unterklasse von Instrumenten definieren (vgl. Abbildung 1–3). Dies bedeutet, dass die Attributwerte und das Verhalten von Instrument an BlasInstrument vererbt werden; jedes Blasinstrumentenobjekt besitzt damit alle Eigenschaften, die für die Instrumente gelten. Möglicherweise verfügt die Unterklasse BlasInstrument zusätzlich noch über spezifischere Eigenschaften als die zugehörige Oberklasse Instrument. Abb. 1–3 Instrument Klassenhierarchie Vererbungseigenschaften bei Klassenhierarchien SaitenInstrument BlasInstrument HolzBlasInstrument SchlagInstrument BlechBlasInstrument 1.3 Eigenschaften objektorientierter und objektrelationaler Datenbanksysteme Auf unser Beispiel der Klasse Instrument bezogen, lässt sich eine Klassenhierarchie analog zu Abbildung 1–3 bilden: Die Klasse Instrument ist durch die Unterklassen SaitenInstrument, BlasInstrument und SchlagInstrument spezialisiert. Diese Klassen wiederum können weitere Subklassen aufweisen; so gliedert sich die Klasse BlasInstrument in die Unterklassen HolzBlasInstrument und BlechBlasInstrument. Die Klasse der Holzbläser verfügt über alle spezifischen Eigenschaften, die den Holzblasinstrumenten eigen sind, wie beispielsweise tonUmfang, bohrung oder klappen. Objekte dieser Klasse erben Eigenschaften sowohl von der Klasse BlasInstrument wie auch von der Klasse Instrument. Vererbungseigenschaften gelten sowohl für Attribute wie auch für Methoden der Klassen einer Klassenhierarchie. Möchte man beispielsweise den Preis eines Blechblasinstruments verändern, so wird der an die Klasse BlechBlasInstrument gerichtete Auftrag durch die Methode ändernPreis aus der übergeordneten Klasse Instrument erfüllt. Die Vererbungseigenschaft ist eine der wichtigsten Grundprinzipien objektorientierter Softwareentwicklung. Dank dieser Eigenschaft können Attribute und Methoden in Klassenhierarchien wiederverwendet werden. 1.3 Ober- und Unterklassen Wiederverwendung von Attributen und Methoden Eigenschaften objektorientierter und objektrelationaler Datenbanksysteme Objektorientierte Datenbanksysteme sind im Laufe der achtziger Jahre in Forschungslabors entwickelt worden und seit einigen Jahren kommerziell verfügbar. Die Hersteller relationaler Datenbanksysteme konnten sich dieser Entwicklung nicht verschließen und haben ihre Softwareprodukte zu objektrelationalen Datenbanksystemen erweitert. Ein Diskussionspunkt betrifft die exakte Definition objektorientierter und objektrelationaler Datenbanksysteme und die Frage, welche Eigenschaften zwingend von der Datenbanksoftware unterstützt werden müssen. Um diese Streitfrage zu versachlichen, soll im Folgenden das Datenbank-Manifesto1 erläutert werden. Dieses Grundsatzpapier fordert die Erfüllung von acht Regeln der Objektorientierung und von fünf Regeln allgemeiner Datenbankprinzipien. Aus didaktischen Gründen soll mit den fünf Datenbankgrundsätzen (Regel D1 bis D5) gestartet werden, ergänzt durch weitere fünf Regeln zum Relationenmodell (Regel R1 bis R5), bevor die acht Regeln des Objektmodells 1. 5 Atkinson M. et al. (1989): The Object-Oriented Database System Manifesto. Proc. 1st International Conference on Deductive and Object-Oriented Databases, Kyoto 1989, pp. 40-57. Zur Definition von relationalen, objektrelationalen und objektorientierten Datenbanksystemen 6 1 Der Weg zur Objektorientierung bei Datenbanksystemen (Regel O1 bis O8) illustriert werden. Dies erlaubt im Anschluss, sowohl objektorientierte wie objektrelationale Datenbanksysteme zu definieren. Abb. 1–4 Die fünf Datenbankgrundsätze Datenbankgrundsätze D1 Dauerhaftigkeit D2 Große Datenbestände D3 Mehrbenutzerbetrieb D4 Wiederherstellbarkeit D5 Ad-hoc-Abfragemöglichkeiten Jedes Datenbanksystem, ob hierarchisch, netzwerkartig, relational oder objektorientiert, muss Datenbankgrundsätzen genügen. In Abbildung 1–4 sind die wichtigsten fünf zusammengefasst: Regel D1: Dauerhaftigkeit Regel D2: Große Datenbestände Regel D3: Mehrbenutzerbetrieb Regel D4: Wiederherstellbarkeit ■ Unter Dauerhaftigkeit oder Persistenz ist das Bestehenbleiben eines Datenbankzustands über längere Zeitabstände (Tage, Monate, Jahre etc.) zu verstehen. Ein Datenbankzustand muss so lange gewährleistet sein, bis Datenwerte durch die Anwender bewusst verändert werden. Im Gegensatz zu den Programmiersprachen müssen die Datenstrukturen über die Laufzeit eines Programms hinweg erhalten bleiben, indem sie auf Sekundärspeicher abgelegt werden. ■ Die Bearbeitung großer Datenbestände verlangt vom Datenbanksystem, dass spezifische Verwaltungskomponenten für Sekundärspeicher bereitgestellt werden, wie Bufferpools, Indexmechanismen und Datencluster. Dazu müssen geeignete Bufferorganisationen aufgebaut, Ein- und Auslagerungsstrategien für Bufferpools entwickelt sowie Speicher- und Zugriffspfadalgorithmen implementiert werden. ■ Datenbanken werden typischerweise von mehreren Anwendern gleichzeitig bearbeitet. Ein Datenbanksystem muss deshalb den reibungslosen Betrieb konkurrierender Prozesse garantieren. Ein leistungsfähiges Transaktionskonzept ist notwendig, das konsistente Datenbankzustände wiederum in solche überführt. Das bedeutet, dass Anwendertransaktionen entweder vollständig oder gar nicht auf der Datenbank ausgeführt werden, undefinierte Zwischenzustände sind nicht erlaubt. ■ Treten Fehler während des Datenbankbetriebs auf, so muss das Datenbanksystem Wiederanlaufverfahren (recovery) zur Restaurierung von Datenbankzuständen anbieten. Im Fehlerfall müssen unvollständig ausgeführte Transaktionen zuerst zurückgesetzt (rollback) und dann nochmals gestartet (restart) werden. 1.3 Eigenschaften objektorientierter und objektrelationaler Datenbanksysteme ■ Ein Datenbanksystem muss deklarative Sprachkonstrukte zur Verfügung stellen, um die Datenbanken ad hoc oder eingebettet in Programmiersprachen auswerten zu können. Solche Abfragesprachen zeichnen sich durch ihre Mächtigkeit aus, indem sie sämtliche Auswertungseigenschaften des darunter liegenden Datenmodells unterstützen. 7 Regel D5: Ad-hoc-Abfragemöglichkeiten Die Datenbankregeln D1 bis D5 stellen Anforderungen an Datenbanksysteme, die vom eigentlichen Datenmodell unabhängig sind. Zusätzlich zu diesen Regeln müssen weitere definiert werden. In Abbildung 1–5 sind die entsprechenden Regeln des Relationenmodells und diejenigen des Objektmodells aufgeführt. Relationenmodell Objektmodell R1 Tabellen O1 Komplexe Objekte R2 Primärschlüssel O2 Objektidentität R3 Mengenorientierte Operatoren O3 Datenkapselung R4 Relationenorientierte Operatoren O4 Typen und Klassen R5 Viewkonzept O5 Vererbung O6 Polymorphismus O7 Vollständigkeit O8 Erweiterbarkeit Abb. 1–5 Die Regeln des Relationenmodells und des Objektmodells Das Relationenmodell wurde anfangs der siebziger Jahre durch die Arbeiten von Ted Codd formuliert, bevor eigentliche relationale Datenbanksysteme entwickelt wurden. Ein relationales Datenbanksystem (engl. relational database system), abgekürzt RDBS, erfüllt demnach die fünf Regeln D1 bis D5 der Datenbankgrundsätze und die fünf Regeln des Relationenmodells R1 bis R5. Das Relationenmodell fordert gemäß Abbildung 1–5 die folgenden Regeln: Zur Definition eines ■ Daten und Datenbeziehungen werden tabellarisch dargestellt, indem in den Spalten die Merkmale (Attribute) aufgeführt werden. Die Anzahl der Merkmale und die Anzahl der Merkmalsausprägungen (Datensätze resp. Tupel) sind beliebig. (Die Ordnung der Spalten innerhalb der Tabelle und die Ordnung der Tupel innerhalb der Tabelle sind bedeutungslos.) ■ Einzelne Merkmale oder minimale Merkmalskombinationen identifizieren die Tupel innerhalb der Tabelle eindeutig; sie sind Schlüsselkandidaten. Ein Schlüsselkandidat, d.h. eine minimale und eindeutige Merkmalskombination, muss als Primärschlüssel ausgezeichnet werden. Regel R1: relationalen Datenbanksystems Tabellen Regel R2: Primärschlüssel 8 1 Der Weg zur Objektorientierung bei Datenbanksystemen Regel R3: Mengenorientierte Operatoren Regel R4: Relationenorientierte Operatoren Regel R5: Viewkonzept ■ Tabellen können als Mengen von Tupeln durch die Mengenoperatoren Vereinigung, Durchschnitt, Differenz und kartesisches Produkt zu neuen Tabellen kombiniert werden. Für die Vereinigung, den Durchschnitt und die Differenz müssen die Tabellen vereinigungsverträglich sein, d.h. die Anzahl der Merkmale dieser Tabellen ist identisch, und die korrespondierenden Merkmale verweisen auf ein und dieselben Wertebereiche. ■ Einzelne Tabellen lassen sich auch durch die Filteroperatoren Selektion oder Projektion verändern; bei der Selektion werden Tupel mit bestimmten Eigenschaften evaluiert, der Projektionsoperator reduziert die Tabelle auf einzelne Merkmale. Darüber hinaus gibt es weitere relationenorientierte Operatoren wie Verbund (engl. join) und Division, die aus je zwei Tabellen eine neue Tabelle kombinieren. ■ Das Viewkonzept verlangt, dass über einzelne Tabellen beliebige Sichten (engl. views) gelegt werden können. Sichten sind nichtmaterialisierte (Teil-)Tabellen, die eigene Tabellennamen tragen und für Auswertungszwecke verwendet werden können. Nach der Klärung der Eigenschaften des Relationenmodells können nun die Regeln der Objektorientierung angefügt werden: Regel O1: Komplexe Objekte Regel O2: Objektidentität Regel O3: Datenkapselung Regel O4: Typen und Klassen ■ Die Formulierung von komplexen Objekten, deren Attribute wiederum Objekte sein können, wird unterstützt. Die Attribute des Objekts können einfache Datentypen wie Integer, Character oder Boolean sein oder sich aus beliebigen Datentypen wie Set, List, Audio oder Video zusammensetzen. ■ Jedes Objekt trägt unabhängig von den Werten seiner Attribute eine eindeutige Identität. Die Identifikation eines Objekts muss systemweit (oder mindestens datenbankweit) eindeutig und unveränderbar sein. Insbesondere muss sie unabhängig vom Ort der Speicherung bleiben. ■ Datenkapselung verlangt, nach außen Implementierungsdetails zu verbergen. Zudem sind die Attributwerte jedes Objekts durch einen Schutzmantel von Methoden abgeschirmt. Nur durch sie können Datenwerte verändert oder gelöscht werden. ■ Das Datenbanksystem muss Typen und Klassen2 zulassen. Unter Typen sind klassische Datentypen aus Programmiersprachen zu verstehen, die zur Übersetzungszeit einer Typenprüfung unterwor- 2. Im Manifesto werden Typen und Klassen synonym verwendet. Wir setzen hier Typen zur Strukturbeschreibung und Klassen zur Definition von Struktur und Verhalten einer Menge von Objekten ein. 1.3 Eigenschaften objektorientierter und objektrelationaler Datenbanksysteme 9 fen sind. Objekte mit äquivalenter Struktur und gleichem Verhalten werden zu Klassen zusammengefasst. Klassen werden benutzt, um Instanzen zur Laufzeit generieren zu können. Die Menge der vorhandenen Instanzen kann gemäß Regel O4 variieren, im Gegensatz zu einem Wertebereich eines Typs während der Programmlaufzeit. So sind in Abbildung 1–3 zwar alle Objekte Instrumente, doch können die einzelnen Objekte je nach Klassenzugehörigkeit noch weitere Attribute und Methoden aufweisen. ■ Vererbung von Struktur und Verhalten muss durch das Datenbanksystem ermöglicht werden. Eine Subklasse (Unterklasse) in einer Klassenhierarchie kann Eigenschaften (Attribute und Methoden) von übergeordneten Klassen (Oberklassen) erben. Daneben darf die Unterklasse eigene Eigenschaften, seien dies Attribute oder Methoden, hinzufügen. ■ Dieselben Methodennamen können auf Objekte unterschiedlicher Klassen vielgestaltig (polymorph) angewendet werden, obwohl die entsprechenden Methoden je nach Klassenzugehörigkeit abweichende Implementierungen aufweisen. Ist zur Übersetzungszeit die notwendige Implementierung festgelegt, so kann statisch gebunden werden; andernfalls muss zur Laufzeit der auszuführende Code bestimmt werden, was als spätes Binden bezeichnet wird. Regel O5: Vererbung Regel O6: Polymorphismus Dank Regel O6 können Methoden mit ein und demselben Namen in abgeleiteten Subklassen überschrieben werden. Die Methode ändernPreis der Klasse Instrument aus Abbildung 1–3 kann sowohl von der Klasse HolzBlasInstrument als auch von BlechBlasInstrument überschrieben werden, wenn unterschiedliche Preisgestaltungen zur Anwendung gelangen sollen. Dieses Prinzip des Polymorphismus ergänzt deshalb die Vererbungseigenschaften. ■ Vollständigkeit verlangt, dass die zum Datenbanksystem gehörende Datenbanksprache berechnungsvollständig sein muss. Mit anderen Worten kann jede Operation, im Speziellen jede Datenbankoperation, durch die Datenbanksprache selbst ausgedrückt werden. ■ Die Forderung der Erweiterbarkeit bezieht sich auf die Unterstützung neuer, benutzerdefinierter Typen und Klassen. Nach außen hin soll kein Unterschied zwischen benutzerdefinierten und systemdefinierten Klassen mehr bestehen. Mit den Regeln der Datenbankgrundsätze, des Relationenmodells und des Objektmodells lassen sich nun die Definitionen für objektorientierte und objektrelationale Datenbanksysteme herleiten. Regel O7: Vollständigkeit Regel O8: Erweiterbarkeit 10 1 Der Weg zur Objektorientierung bei Datenbanksystemen Zur Definition eines OODBS Zur Definition eines ORDBS Gemäß dem Datenbank-Manifesto versteht man unter einem objektorientierten Datenbanksystem (engl. object-oriented database system), abgekürzt OODBS, ein Softwaresystem, das die fünf Grundsätze (Regel D1 bis D5) der Datenhaltung und -nutzung sowie die acht Regeln der Objektorientierung (Regel O1 bis O8) erfüllt. Ein objektrelationales Datenbanksystem (engl. object-relational database system), abgekürzt ORDBS, ist ein relationales Datenbanksystem, das die Regeln O1 bis O8 der Objektorientierung zusätzlich unterstützt. Die Objekte werden bei einem ORDBS nach wie vor in Tabellen abgelegt, d.h., die Speicherungskomponente bleibt relational. Allerdings müssen für die Verwaltung komplexer Datenstrukturen resp. für Multimedia-Anwendungen erweiterte Datentypen und Speicherungskonzepte zur Verfügung stehen, wie z.B. Binary Large Objects (BLOBs), siehe auch Abschnitt 4.6.3. 1.4 Nutzungspotenziale für die Praxis Weshalb ist es sinnvoll, objektorientierte oder objektrelationale Datenbanksysteme in der Praxis einzusetzen? Könnte man nicht abwarten und vorläufig »nur« objektorientiert programmieren und die Datenhaltung nach wie vor einem herkömmlichen Datenbanksystem überlassen? Diese beiden Fragen sollen im Folgenden anhand Abbildung 1–6 näher diskutiert werden. Abb. 1–6 Komponenten einer objektorientierten Datenbankanwendung grafische Benutzerschnittstelle Mensch-Maschine-Schnittstelle objektorientierte Programmiersprache Entwicklungsumgebung objektorientiertes oder objektrelationales Datenbanksystem Datenhaltung 1.4 Nutzungspotenziale für die Praxis 11 Bei der Entwicklung eines objektorientierten Anwendungssystems können drei wichtige Ebenen unterschieden werden: ■ die Präsentation von Objekten an der Schnittstelle zum Benutzer, ■ die Bearbeitung von Objekten mit Hilfe einer Programmiersprache und ■ die Datenhaltungsebene zur längerfristigen Aufbewahrung der Objekte. Für jede dieser drei Ebenen kann nun die Frage nach der Objektorientierung gesondert diskutiert werden. In einem ersten Fall wird konventionell programmiert, die Daten werden in herkömmlichen Datenhaltungssystemen verwaltet, und lediglich an der Benutzerschnittstelle werden objektorientierte Konzepte verwendet. Dieses Face-Lifting bestehender Anwendungen kann vorübergehend die Benutzer von Informationssystemen zufrieden stellen, bei Änderungswünschen und beim Bedarf nach zusätzlicher Funktionalität treten die darunter liegenden Systemmängel durch längere Entwicklungszeiten und mögliche Leistungseinbußen zu Tage. Eine zweite Option besteht darin, zusätzlich objektorientiert zu programmieren, die Datenhaltung aber nach wie vor mit herkömmlichen Technologien zu bewerkstelligen. Dieses Vorgehen lässt eine Kluft zwischen Programmiersprache und Datenbank bestehen (engl. impedance mismatch), weil die transienten (temporären) Objekte während der Laufzeit von Programmen in dauerhafte Objekte für die Datenhaltung konvertiert werden müssen und umgekehrt. Abgesehen von Laufzeit-Schwierigkeiten verlangt dieses Vorgehen bei der Analyse und beim Entwurf einiges Kopfzerbrechen, müssen doch komplexe Objekte in konsistenter Art auf flache Datenstrukturen abgebildet werden. Schließlich verfolgt eine dritte Option die Objektorientierung am konsequentesten, sowohl beim Gestalten der Benutzerschnittstelle als auch bei der Anwendungsentwicklung und der Datenhaltung. Die Vorteile liegen auf der Hand, der objektorientierte Ansatz kann von der Analyse über den Entwurf und den Bau eines Prototypen zur Verifikation der Anwenderwünsche bis hin zur eigentlichen Entwicklung und Nutzung ausgereifter Informationssysteme durchgehend angewandt werden. Jeder dieser Schritte erfolgt einheitlich nach dem objektorientierten Paradigma. Der konsequent verfolgte Weg der vollen Integration von objektorientierter Benutzerschnittstelle, Entwicklungsumgebung und Datenhaltung bringt in der Praxis zahlreiche Vorteile: Objektorientierte Benutzerschnittstelle Objektorientierte Programmierung Objektorientierte Programmierung und Datenhaltung 12 1 Der Weg zur Objektorientierung bei Datenbanksystemen Durchgängigkeit des objektorientierten Ansatzes Wiederverwendung von Daten und Verhalten Unterstützung komplex strukturierter Datenbestände Keine Kluft zwischen Programmiersprache und Datenbank ■ Sowohl bei der Analyse als auch beim Entwurf und bei der Implementierung wird einheitlich nach dem objektorientierten Paradigma vorgegangen. Es gibt im Normalfall keine Bruchstellen, wenn die darunter liegenden Werkzeuge die Grundeigenschaften der Objektorientierung erfüllen. ■ Während herkömmliche Datenbanksysteme die Wiederverwendbarkeit der Daten gewähren, eröffnen die OODBS und teilweise ORDBS eine neue Dimension, da sie die Wiederverwendbarkeit von Struktur und Verhalten zulassen. Dadurch können Geschäftsprozesse und bereichsübergreifende Anwendungssysteme dank mächtiger Vererbungseigenschaften effizient weiterentwickelt werden. ■ Herkömmliche Datenbanksysteme verlangen formatierte und strukturierte Dateninhalte; Text, Bildmaterial, Grafiken, Ton und Video können nur mühsam, wenn überhaupt, verwaltet werden. Im Gegensatz dazu ermöglichen OODBS und ORDBS die Verwaltung und Verarbeitung sowohl formatierter wie unformatierter Daten. Damit können komplex strukturierte Datenbestände besser bewirtschaftet werden. ■ Die unterschiedlichen Benutzergruppen eines Datenbanksystems verwenden ein und dieselbe Sprache für transiente wie persistente Objekte. Dadurch müssen keine unterschiedlichen Sprachumgebungen gepflegt, geschult und unterstützt werden. Der gelegentliche Benutzer, der Anwendungsprogrammierer und der Datenbankadministrator können die Abfragesprache OQL (Object Query Language) oder objektorientierte Erweiterungen von SQL einsetzen. Auch wenn der Reifegrad objektorientierter und objektrelationaler Datenbanksysteme noch gesteigert werden kann – bei den objektorientierten vor allem im Hinblick auf systemtechnische Aspekte, bei den objektrelationalen bezüglich der Eigenschaften der Objektorientierung – so ist dieser Datenbanktechnologie ein Entwicklungspotenzial in der Praxis sicher (vgl. hierzu auch Kapitel 5 und 6). 1.5 Bibliographische Angaben Es gibt eine große Anzahl von Standardwerken auf dem Gebiet der Datenbanken. Einige davon behandeln neben relationalen Konzepten auch objektorientierte und objektrelationale, inklusive der entsprechenden Datenbanksysteme. Date (2001) und Silberschatz et al. (1997) sind in den USA und im englischen Sprachraum sehr bekannt. Das gut lesbare und anschauli- 1.5 Bibliographische Angaben che Buch von den Schotten Connolly und Begg (1999) wird von Praktikern gerne als Nachschlagewerk benutzt. Als deutsche Lehrbücher im Datenbankbereich sind Heuer und Saake (2000), Kemper und Eickler (2001) sowie Vossen (2000) zu erwähnen. Das Werk von Meier (2003) behandelt Modellierung und Nutzung relationaler Datenbanken und ist ein Leitfaden für die Praxis. Speziell mit objektorientierter Datenbanktechnologie befassen sich die Werke von Bertino und Martino (1993), Hohenstein et al. (1996), Heuer (2002), Hughes (1991), Geppert (2002), Lausen und Vossen (1996) sowie Stonebraker (1998). 13
