Objektrelationale Datenbanken

Inhaltsverzeichnis

Darstellungsverzeichnis

Abkürzungsverzeichnis

1 Abgrenzung verschiedener Datenbanksysteme
1.1 Klassifizierung nach Stonebraker
1.2 Kritik an der Klassifizierung nach Stonebraker
1.3 Differenzierung OODBS / ORDBS

2 Nachteile von RDBMS
2.1 Datenmodellierung
2.2 Datenbankentwurf
2.3 Anfragesprache
2.4 Fazit

3 Erweiterungen des relationalen DBS in ORDBS
3.1 Basisdatentypen
3.1.1 BLOB
3.1.2 CLOB
3.2 Benutzerdefinierte Datentypen
3.2.1 Distinct Types
3.2.2 Row Types
3.2.3 Abstract Data Types
3.2.4 Array Types
3.2.5 weitere Collections
3.3 Objekt-Identitäten und Referenzen
3.4 Verhalten von Datenbankobjekten
3.5 Weitere Objektorientierte Konzepte

4 Können ORDBS Probleme der RDBS lösen?
4.1 Datenmodellierung
4.2 Datenbankentwurf
4.3 Anfragesprache
4.4 Fazit

Literatur-/Quellenverzeichnis

Darstellungsverzeichnis

Abbildung 1: DBMS-Klassifikationsmatrix

Abbildung 2: Relative Größe des DBMS-Marktes im Jahr 2005

Abbildung 3: Marktübersicht über wichtige objektorientierte und objektrelationale Systeme

Abbildung 4: Autotypen mit Ausstattungspaketen: geschachtelte Darstellung

Abbildung 5: Autotypen mit Ausstattungspaketen: relationale Darstellung mit Informationsverlust

Abbildung 6: Autotypen mit Ausstattungspaketen: relationale Darstellung mit künstlichen Schlüsseln

Abbildung 7: Beispiel für Row data type

Abbildung 8: Vergleichstabelle Zeilenreferenz mit Primär-/Fremdschlüssel- beziehung

Abbildung 9: Unterschied zwischen der Anordnung komplizierter Operationen in
herkömmlichen Datenbankarchitekturen (links) und dem objektorientierten Fall (rechts)

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Abgrenzung verschiedener Datenbanksysteme

Einleitend zu meiner Studienarbeit über objektrelationale Datenbanken möchte ich das Gebiet entsprechend dem Thema abgrenzen. Hierzu ist eine Einteilung der verschiedenen Datenbankkonzepte notwendig.

Woimmer unter Zuhilfenahme der IT gearbeitet wird, fallen zwangsläufig Daten an. Diese müssen in irgendeiner Weise gespeichert werden, um erneut genutzt werden zu können. Hierbei gibt es jedoch eine Vielzahl von möglichen Anwendungsgebieten, die zu unterschiedlichen Anforderungen an die Datenhaltung führen.

1.1 Klassifizierung nach Stonebraker

In „Objektrelationale Datenbanken - Die nächste große Welle“ führt Michael Stonebraker deshalb zunächst eine sog. DBMS-Klassifikationsmatrix ein. Diese richtet sich zum einen nach der Komplexität der Daten, die die Anwendung benutzt, und zum anderen danach, in wieweit diese eine Abfragemöglichkeit dieser Daten benötigt. Zur Vereinfachung und Veranschaulichung des Modells wird verallgemeinert, daß die Ausprägung der obigen Charakteristika nur die Werte „einfache Daten“ oder „komplexe Daten“ bzw. „benötigt Abfragen“ oder „benötigt keine Abfragen“ seien.^[1]

Dadurch ergibt sich eine 2-mal-2-Matrix mit 4 Quadranten. Abhängig von den Charakteristika paßt jede Anwendung in mindestens eine der 4 Quadranten.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: DBMS-Klassifikationsmatrix

Als eine Anwendung des 1. Quadranten wird ein gewöhnlicher Texteditor wie Notepad oder vi angesehen, da dieser weder mit besonders komplexen Daten arbeitet noch wirk- lich Abfragen benutzt. Die einzige „Abfrage“ ist „hole Datei“, die einzige „Aktualisie- rung“ ist „schreibe Datei“. Somit werden diese Anforderung zur genüge vom Dateisystem befriedigt.

Als Anwendungen des 2. Quadranten sieht Stonebraker die herkömmlichen relationalen Datenbanken, da diese auf einfachen Datentypen beruhen und in einem sehr hohen Ma- ße (SQL-)Abfragen benutzen. Er gibt jedoch gleich zu bedenken, daß der Markt für Anbieter von relationalen Datenbanksystemen ein „überfüllter Tummelplatz“ sei. Be- sonders seit Microsoft den Code von Sybase für dessen MS-SQL-Server erworben hat und nun auf dem Markt neben Größen wie Oracle, DB2, Informix und CA Ingres drängt sei ein Preisverfall abzusehen.^[2] Einen weiteren nicht unerheblichen Einfluß können die Open-Source-Projekte wie mSQL, MySQL oder PostgreSQL einnehmen. Z.B. beim Wachstumsmarkt der Webserver erfreut sich die kostenlose, LAMP abgekürzte Kombination aus Linux, Apache, MySQL und PHP großer Beliebtheit.^[3]

Als Anwendungen des 3. Quadranten erwähnt Stonebraker CAD-Programme. Hierbei sei die Umwandlung der Daten, wie z.B. Nachbarschaftsbeziehungen von Punkten ins Dateisystem sehr aufwendig. Anforderungen an Abfragen werden zu Gunsten der Per- formance nicht gestellt. Als Plattform für Anwendungen dieses Quadranten sieht er Ob- jektorientierte Datenbanken wie Produkte von Object Design, Ontologic, Versant, Ser- vio, O2 und Mantisse.

Schließlich bleiben für den 4. Quadranten komplexe Daten, wie z.B. umfangreiche Bilddaten, die u.a. auch durch benutzerdefinierte Funktionen abgefragt werden müssen. Dies sei der Markt für objektrelationale Datenbanksysteme, da diese um entsprechende Datentypen erweitert sind bzw. erweitert werden können, um komplexe Daten abzu- speichern, benutzerdefinierte Funktionen unterstützen und über eine Abfragesprache verfügen.

Stonebraker schätzt das objektrelationale Paradigma als die nächste große Welle ein. Dies untermauert er zum einen auf die steigende Computerisierung neuer Multimedia- Anwendungen. Nach Schätzungen lägen noch 85% der nützlichen Informationen der Welt nicht in elektronischer Form vor. Dem entgegen stehe eine unglaubliche Ge- schwindigkeit, in der sich z.B. das World Wide Web fülle. Auch die zunehmende Spei- cherung von Bild und Ton in digitaler Form führe zu enormem Bedarf an Verwaltung von komplexen Daten. Mit ihrer Menge geht auch ein Bedarf an Abfragen dieser einher, weshalb der Markt an objektrelationalen Systemem in den nächsten 10 Jahren stark an- wachse. Zum anderen verschieben sich kommerzielle Datenverarbeitungsanwendungen nach rechts, was bedeute, daß die Komplexität der verwendeten Daten steige. Z.B. sei dies die Folge der steigenden Leistungsfähigkeit der Datenverarbeitung und dem Inte- resse, z.B. in Versicherungen auch Bilder der Schadensdaten direkt im Datenverarbei- tungssystem abzulegen. Insgesamt schätze er den Markt für Datenbankmanagementsys- teme im Verhältnis zum heutigen Gesamtmarkt wie folgt dargestellt ein:^[4]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Relative Größe des DBMS-Marktes im Jahr 2005

Hiernach würde der Markt für RDBMS ein hundertfaches des heutigen Gesamtmarktes einnehmen, wobei der Markt für ORDBMS dies noch einmal um 50% übersteigen wür- de, während OODBMS gerade mal auf die Größe des heutigen Marktes stoßen würden. Letztendlich verspräche diese „große Welle“ mindestens so bedeutend wie der letzte Paradigmenwechsel zu werden, der von CODASYL zu relationalen Systemen erfolgte.

1.2 Kritik an der Klassifizierung nach Stonebraker

Ich habe dieses Klassifizierungssystem als Einstieg in meine Studienarbeit gewählt, da es im großen und ganzen die kommenden Entwicklungstendenzen aufzeigt und die Ma- terie verdeutlicht. Aufgrund seiner starken Verallgemeinerungen und Beschränkung auf nur zwei Kriterien ist es jedoch wenig aussagekräftig. Schlimmer jedoch wiegt, daß Stonebraker verkennt, daß OODBMS sehr wohl Abfragemöglichkeiten bieten und somit auch für den 4. Quadranten geeignet wären.^[5] Selbst eine standardisierte Abfragesprache steht mit der Object Query Language (OQL) seit Verabschiedung des ODMG-2.0 Standards 1997 zur Verfügung.^[6]

1.3 Differenzierung OODBS / ORDBS

Ein deutlich differenzierteres Modell verwenden die Autoren Meier und Wüst zur Marktübersicht anhand der Datenbankeigenschaften und Eigenschaften der Objektorien- tierung zur Einordnung der verfügbaren kommerziellen Datenbanksysteme. Hinter die- sen Charakteristika verbergen sich jeweils eine Vielzahl von Einzelkriterien. Unter den Prinzipien der Objektorientierung werden die Unterstützung für komplexe Objekte, Ob- jektidentität, Datenkapselung, Typen und Klassen, Vererbung, Polymorphismus, Voll- ständigkeit und Erweiterbarkeit bewertet. Als Datenbankgrundsätze werden Dauerhaf- tigkeit, große Datenbestände, Mehrbenutzerbetrieb, Rekonstruierbarkeit und Ad-hoc- Abfragemöglichkeit bewertet. Zusätzlich fließt noch die Praxistauglichkeit im bezug auf Sprachunabhängigkeit, Datenunabhängigkeit, Beziehungskonzept, Schemaevolution, Versionenkontrolle, Autorisierung, Standardkonformität, Integration und Migration sowie Leistungsdurchsatz ein.^[7] Hiernach ergibt sich folgendes Schaubild:

Eigenschaften der Objektorientierung

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Marktübersicht über wichtige objektorientierte und objektrelationale Systeme

Objektorientierte Datenbanksysteme müssen minimal die acht Regeln der Objektorientierung und die fünf Datenbankgrundsätze erfüllen, damit sie das Prädikat OODBS erhalten. Die neun Forderungen der Praxis können nicht allesamt verlangt werden, da die heutigen Produkte diesbezügliche Schwächen aufweisen.^[8]

Objektrelationale Datenbanken sind Datenbanksysteme, die von relationalen Datenmo- dell ausgehen und objektorientierte Erweiterungen anbieten. Die Datenhaltung erfolgt also primär in Tabellen - eventuell um Tabellenspalten mit erweiterten Datentypen er- gänzt - und die Sprachschnittstelle folgt dem neuesten Sprachstandard SQL-3. Bei ob- jektrelationalen Datenbanksystemen wird dem objektorientierten Paradigma nur teilwei- se entsprochen.^[9]

2 Nachteile von RDBMS

Die Geschichte der Datenbanksysteme läßt sich schon 30 Jahre zurückverfolgen. IMS von IBM, eines der ersten Datenbanksysteme, kam 1968 auf den Markt. Seit dieser Zeit ist das Angebot durch die Entwicklung von hierarchischen Datenbanksystemen, Netzwerk-Datenbanksystemen und invertierten Listen zu den relationalen Datenbankmanagementsystemen (RDBMS). So werden bei Neuentwicklungen von DV-Anwendungen fast ausschließlich relationale Datenbanksysteme eingesetzt.

Allerdings ist trotz dieser Popularität kaum eine andere Entwicklung in der Datenverarbeitung nach so vielen Jahren noch so umstritten wie die relationalen Datenbanken. Diejenigen, die sich zu diesem Phänomen bisher geäußert haben, begründen dies damit, daß die von Codd im Jahre 1970 aufgestellten Theorien »nur« die mathematische Grundlagen darstellten und die meisten Datenbankhersteller die Implementierung dieser Theorien (Datenbanksysteme) bisher nur sehr mangelhaft realisieren konnten.

Laut E.F: Codd ist das Relationenmodell ein Art, die Daten zu sehen. In der Praxis zeigt sich jedoch, daß der Anwender relationaler Datenbanken eine ganze Philosophie verste- hen muß.^[10]

2.1 Datenmodellierung

Beim Entwurf einer Datenbank müssen die in der Realität existierenden Gegebenheiten möglichst exakt abgebildet werden. Hierzu haben wir im Relationenmodell die Konzep- te Attribute, Relationenschema sowie Integritätsbedingungen wie Schlüssel und Fremd- schlüssel.^[11]

Die erste Normalform (1NF) bedingt, daß nur atomare Attributwerte in der Datenbank gespeichert werden können und ihnen stehen in der Regel nur die Standarddatentypen wie integer, string, real oder boolean zur Verfügung.^[12] An folgendem Beispiel wird diese Einschränkung und die Umgehung dieser deutlich:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Autotypen mit Ausstattungspaketen: geschachtelte Darstellung

Würde man versuchen, diese Daten in eine Tabelle ohne irgendwelche Kunstgriffe zu speichern, so käme folgende Tabelle zustande, wobei ein wichtiger Teil der enthaltenen Informationen verloren ginge:

Austattungspakete Autotyp Ausstattung

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Autotypen mit Ausstattungspaketen: relationale Darstellung mit Informationsverlust

Durch einen künstlichen Schlüssel läßt sich dies vermeiden, jedoch ist dazu das Einführen einer neuen Tabelle nötig:

Ausstattungspakete Autotyp Paket

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Autotypen mit Ausstattungspaketen: relationale Darstellung mit künstlichen Schlüsseln

Aus dieser Eigenschaft ergeben sich nun zwei Nachteile in der Datenmodellierung:

1. Attribute, die aus Wertemengen oder aus mehreren Komponenten bestehen, können simuliert, aber nicht direkt im Relationenmodell dargestellt werden.^[13]

2. Beziehungen zwischen verschiedenen Relationen eines Objekttyps (Assoziation), Is- a-Beziehungen zwischen verschiedenen Objekttypen (Generalisierung) und Objekt- Komponentenobjekt-Beziehungen (Aggregation) können im relationalen Daten- bankmodell nicht unterschieden werden. Sie werden jeweils über Fremdschlüssel- Beziehungen dargestellt.^[14]

2.2 Datenbankentwurf

Aus den Nachteilen eines RDBMS bei der Datenmodellierung folgt ein erhöhter Aufwand beim Datenbankentwurf. So muß beispielsweise die verlorengegangene Information, welche Art von Beziehung in einem Fremdschlüssel gespeichert ist, in der Programmlogik nachgereicht werden.

Neben der ersten Normalform (1NF), die zwingende Voraussetzung für die Nutzung eines RDBMS darstellt, ist die Modellierung in „höheren“ Normalformen wünschens- wert, weil hierdurch z.B. bei der dritten Normalform (3NF) Redundanzen vermieden werden.^[15]

Um diese Normalformen zu erreichen, gibt es formale Algorithmen. Diese sind der De- kompositions- und der Synthesealgorithmus, sowie das Sichtintegrationsverfahren. Die- se hier zu erläutern würde den Rahmen der Arbeit sprengen. Es bleibt jedoch zu erwäh- nen, daß das Ergebnis der Dekomposition nicht abhängigkeitstreu, nicht minimal und sehr reihenfolgeabhängig ist. Teilweise werden Attribute völlig getrennter Objekttypen in ein Relationenschema aufgenommen, Informationen eines Objekttyps dagegen auf mehrere Relationenschemata verteilt oder gar nicht berücksichtigt.^[16] Beim Syntheseal- gorithmus hingegen werden zwar alle formalen Datenbankschema-Eigenschaften er- reicht, trotzdem können Attribute unterschiedlicher Objekttypen nicht getrennt werden. Außerdem werden nur funktionale und keine mehrwertigen Abhängigkeiten berücksich- tigt.^[17] Beim Sichtintegrationsverfahren treten eventuell unentscheidbare Probleme auf, die ihre Ursache in der uneingeschränkten Form der zugehörigen Abhängigkeiten ha- ben.^[18]

2.3 Anfragesprache

Ein generelles Problem aller Anfragesprachen relationaler DBMS (nicht nur SQL) liegt in deren Grundlage. Codd fordert von einem voll relationalen Datenbanksystem, daß die Anfragesprache relational vollständig ist, also zumindest das leistet, was die Relationenalgebra oder der Kalkül können und diese Vollständig mit rein deskriptiven Mitteln, also ohne Wiederholungsanweisungen (Repeat, While, Loop) oder anderen navigierenden Operationen erreicht wird. Dies führt in der praktischen Verwendung zu folgenden drei Hauptproblemen: Strukturmangel im Ergebnis, keine Unterstützung komplexer Strukturen und Notwendigkeit expliziter Verbundoperationen.^[19] Auch lassen sich ohne Schleifenkonstrukte nur schwer Rekursionen ausführen.

Will man komplexe Operationen in relationalen Datenbanksystemen durchführen, so bleibt einem in vielen Fällen nur die Einbettung der Datenbankoperationen in allgemei- ne Programme, die in einer höheren Programmiersprache geschrieben werden. Der Hauptnachteil bei derzeit existierenden Datenbanksystemen und Programmiersprachen ist der sog. impedance mismatch, das Nicht-Zusammenpassen von Programmierspra- chen- und Datenbankkonzepten. Was nicht zusammenpaßt, sind vor allen Dingen das Typsystem sowie die Paradigmen der Programmiersprache (etwa imperativ) und der Datenbank (etwa kalkülartig). Einschränken läßt sich dieses Problem durch Verwen- dung einer Datenbankprogrammiersprache.^[20] Diese bieten jedoch nicht einen so großen Funktionsumfang, so daß sich nicht alle benötigte Funktionalität hierdurch realisieren läßt.

2.4 Fazit

Die Liste der Nachteile von RDBMS ließe sich noch lange fortsetzen und es liegt im Interesse der Datenbankhersteller, diese zu umgehen. Hierbei gibt es Grundsätzlich zwei Möglichkeiten, nachdem ersichtlich ist, daß die Beschränkung auf das relationale Datenmodell Ursache hierfür ist: Entweder man verwendet ein anderes Datenmodell oder man erweitert das verwendete.

Objektorientierung ist in der Informatik eines der großen Schlagwörter der neunziger Jahre geworden.^[21] Und so verwundert es nicht, daß auch aus diesem Gebiet ein Ausweg aus den Beschränkungen des RDBMS gesucht wurde. Dabei wurde entweder mehr oder weniger ausgehend von einer objektorientierten Programmiersprache (OOPL) wie Smalltalk oder C++ durch Realisierung von Datenbankkonzepte wie Persistenz, Spei- cherstrukturen und Zugriffspfade, Transaktionen und Concurrency Control sowie Reco- very-Mechanismen ein objektorientiertes Datenbanksystem (OODBS) entwickelt. Oder aber es wurde ein bestehendes (meist relationales) Datenbanksystem strukturell und / oder verhaltensmäßig objektorientiert erweitert.^[22] Bei weitgehenden Erweiterungen des relationalen Systems um objektorientierte Eigenschaften spricht man von objektrelatio- nalen Datenbanksystemen,^[23] denen ich mich noch genauer widmen möchte.

3 Erweiterungen des relationalen DBS in ORDBS

Im Strukturteil bieten ORDBS

⇒ Typen, Typkonstruktoren und oft auch abstrakte Datentypen (ADTs),
⇒ Objektidentititäten für komplexe Tupel in Relationen (die häufig auch Klassen ge- nannt werden)
⇒ eine getrennte Klassen- und Typhierarchie (die Klassenhierarchie wird bei objektre- lationalen Systemen häufig Relationenhierarchie oder Tabellenhierarchie genannt) sowie bei den höheren Konzepten
⇒ Methoden,
⇒ Vererbung und eventuell auch Overriding.

Im Operationenteil fällt auf, daß nur relationale Anfragen erlaubt sind. Trotz vieler objektorientierter Konzepte im Datenmodell ist das Grundlegende Konstrukt immer noch die Relation oder Tabelle.^[24]

Als Datenmanipulationssprache (DML) verwenden alle auf dem Markt erhältlichen ORDBS eine an SQL-3 angelehnte Sprache^[25], so daß ich mich im weiteren an diesem Standard „gemeinsamen Nenner“ orientieren werde.

3.1 Basisdatentypen

In SQL-3-Standard (gelegentlich auch als SQL-99 bezeichnet) wurden weitere Basisdatentypen gegenüber SQL-2 (gelegentlich auch als SQL-92 bezeichnet) festgelegt. Zudem wurden die bestehenden Datentypen teilweise verändert. So wurde die interne Repräsentation der BOOLEAN-Werte im Standard festgelegt.^[26]

3.1.1 BLOB

Binary Large Object ist ein Datentyp, der für große Binärdaten, wie z.B. Bilder verwendet werden kann. Diese Objekte werden in der Datenbank abgelegt - also nicht in einer separaten Datei - und besitzen Datenbankfunktionen zur Manipulation, damit diese nicht auf dem Client-System bearbeitet und gecached werden müssen.

3.1.2 CLOB

Character Large Object ist ein Datentyp, der für lange Texte verwendet werden kann. Auch für diese bieten viele Anbieter spezielle Datenbankfunktionen, um das Netzwerk und die Clients zu entlasten.

3.2 Benutzerdefinierte Datentypen

Im Standard wurde ebenfalls festgelegt, welche Möglichkeiten der Benutzer hat, eigene Datentypen anzulegen. Hierdurch wird eine sehr große Anzahl von Anwendungsfällen unterstützt, ohne daß der Datenbankanbieter hierfür jeden erforderlichen Datentyp bei der Programmierung implementieren muß und hält dadurch auch die Anzahl der Typen überschaubar.^[27]

3.2.1 Distinct Types

Die elementarste Form eines benutzerdefinierten Datentyps ist der distinkte Typ. Hier- bei handelt es sich um die Definition eines neuen Namens für einen bereits existieren- den Typ.^[28] Dies läßt sich einsetzen, um verschiedene Argumente, die intern gleich dar- gestellt werden von einer fehlerhaften Benutzung zu schützen, z.B. bei Währungen. Beispiel:

CREATE DISTINCT TYPE euro_t AS DECIMAL (7,2) CREATE DISTINCT TYPE dm_t AS DECIMAL (7,2)

In einer Tabelle seien durch eine Auswertung die Gewinne durch die Vermittler gespeichert, in einer anderen die an sie gezahlte Provisionen.

Nach der Umstellung auf Euro werden die Gewinne in Euro erfaßt, während die gezahlten Provisionen nicht umgerechnet wurden.

Abbildung in dieser Leseprobe nicht enthalten

Will nun jemand auswerten, welcher Vermittler mehr Provision erhalten hat, als das Unternehmen an den durch ihn abgeschlossene Verträge verdient hat, so könnte er fälschlicherweise folgende Abfrage ausführen wollen:

Abbildung in dieser Leseprobe nicht enthalten

Diese Abfrage wird die Datenbank nicht ausführen, da die Datentypen von Gewinn und Provision verschieden sind und somit ein Vergleichsoperator nicht zulässig ist. Durch eine Funktion läßt sich jedoch die korrekte Auswertung ermöglichen:

Abbildung in dieser Leseprobe nicht enthalten

Die korrekte Abfrage lautet nun:

Abbildung in dieser Leseprobe nicht enthalten

3.2.2 Row Types

Über diesen Datentyp lassen sich wie für Tabellen auch für Spalten einer Tabelle eine Reihe von Attributname-Datentyp-Paaren zuweisen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Beispiel für Row data type

Beispiel:^[29]

Abbildung in dieser Leseprobe nicht enthalten

Es lassen sich auch Row types Namen zuweisen, um diese wie andere Datentypen in den Tabellendefinitionen verwenden und wiederverwenden zu können. In diesem Beispiel würde dies wie folgt vorgegeben werden:

Abbildung in dieser Leseprobe nicht enthalten

3.2.3 Abstract Data Types

Abstrakte Datentypen zählen wohl zu den bedeutendsten Erweiterung des Typsystems in ORDBS. Sie erlauben nicht nur das Neubenennen von bestehenden Datentypen (wie die Distinct Types) oder die Kombination aus bestehenden Typen (wie die Row Types), sie erlauben darüber hinaus auch die Definition von Methoden und Kapselung der inter- nen Darstellung der Werte. Der Zugriff auf die Attribute eines so erzeugten Objekts erfolgt ausschließlich über Funktionen. Durch das Schlüsselwort PUBLIC werden die benötigten Zugriffsfunktionen für das entsprechende Attribut automatisch erstellt.^[30]

Abbildung in dieser Leseprobe nicht enthalten

Jedoch wird meist die aus OOPL bekannte Kaskaden-Punkt-Notation verwendet, die auch schon in früheren SQL-Standards zum Zugriff auf Spalten einer Tabelle erwendet wurde.^[31] Der SQL-3-Standard sieht vor, daß zwei Punkte verwendet werden müssen:^[32]

SELECT students.student..last_name FROM students WHERE ...

Die Leistungsfähigkeit von ADT liegt dabei darin, komplexe Objekte und deren Verhalten recht genau im Datenbankmodell ablegen zu können. Es lassen sich nun auch Funktionen zu diesen Typen definieren, z.B. eine Funktion, die das aktuelle Alter in Jahren einer Person als Differenz aus Systemdatum und Geburtsdatum ausgibt. Damit wäre folgende Abfrage möglich:

SELECT student..last_name, student..first_name FROM students

WHERE student..age > 35

Einige Datenbankhersteller erlauben auch, Methoden von ADT in C++, Smalltalk oder Java zu programmieren.^[33] Sie bieten dadurch die Grundlage für Unterstützung von bei- spielsweise Texten, Bildern, Filmen, Ton, geometrische Formen, geographische Daten und Zeitreihen mit eigenen Vergleichs-, Sortierungs und Umwandlungsoperatoren und Verwendung weiterer Zugriffpfade neben B/B*-Bäume auch über R-, KdB-, Quad- Bäume oder Gitterdateien.^[34] Die so „erweiterten ADTs“ sind nicht im SQL-3-Standard enthalten und werden von den Datenbankherstellern unter verschiedenen Namen ange- priesen, so heißt dieser Datentyp in Oracle 8i „Data Cartrige“^[35], in IBM DB2 Universal Database „Reltional Extenders“^[36] und in Illustra / Informix Universal Server „Data Bla- des“^[37]

3.2.4 Array Types

Über diesen Datentyp lassen sich aus Programmiersprachen schon lange genutzte Feldspeicher (Array) als Attribute in der Datenbank speichern. Da ein Array mehrere Argumente eines Datentyps aufnehmen kann, wird hiermit die Einschränkung der ersten Normalform bei RDBS außer Kraft gesetzt. Sollen 1:n-Beziehungen abgebildet werden, wobei für n eine Obergrenze gegeben ist, z.B. sollen mehrere Telefonnummern eines Mitarbeiters hinterlegt werden, so ließe sich dies wie folgt realisieren:

Abbildung in dieser Leseprobe nicht enthalten

Es handelt sich hierbei um eine geschachtelte Relation oder auch NF² relation genannt. NF² steht hierbei für Non First Normal Form (NFNF). Genauer betrachtet handelt es sich um eine sog. PNF-Relation, wobei PNF für Partitioned Normal Form steht. Darun- ter werden jene NF²-Relationen zusammengefaßt, die sich immer entschachtelt durch eine äquivalente 1NF-Relation darstellen lassen.^[38] In SQL-3 wird zum entschachteln solcher PNF der THE-Operator verwendet.^[39] Die verwendete Abbildung der Ausstat- tungspakete in ihrer nicht normalisierten Darstellung (Abbildung 4, Seite 7) ist so eine PNF-Relation.

3.2.5 weitere Collections

Wie Array Types werden auch noch weitere Sammlungen von mehreren Instanzen eines Datentyps (Collections) vorgesehen. Diese sind SET, LIST und MULTISET. Sie alle haben im Gegensatz zu einem Array keine bestimmte Obergrenze für die 1:n- Kardinalität. Sie können Basisdatentypen ebenso wie komplexe Datentypen aufneh- men.^[40]

SET ist hierbei eine ungeordnete Liste ohne Duplikate. LIST ist eine geordnete Liste ohne Duplikate.

MULTISET erlaubt im Gegensatz zu SET und LIST Duplikate.

Eventuell werden SET, LIST und MULTISET erst in den SQL-4-Standard aufgenom- men.

3.3 Objekt-Identitäten und Referenzen

In einem RDBS werden Datensätze durch Schlüssel identifiziert. Dies kann jedoch zu Problemen führen, wenn sich dieser ändert. Denn wird dieser Schlüssel als Fremd- schlüssel in einer anderen Relation benutzt, so muß er auch dort abgeändert werden. Um dies zu vermeiden, werden in RDBS anstelle von „sprechenden Schlüsseln“ häufig abs- trakte Schlüssel ohne offensichtliche Aussagekraft verwendet, wie z.B. eine fortlaufen- de Bestellnummern.

In ORDBS kann vom System intern ein Surrogat-Wert^[41] erzeugt, der einen Datensatz repräsentiert. Dieser wird objekt identity (OID) genannt, ist in der Datenbank immer eindeutig, wird nie geändert, wird bei der Erzeugung eines Objektes generiert und ist solange gültig, wie auch das Objekt in der Datenbank existiert.

Auf ein solches Objekt kann über eine (Zeilen-)Referenz mit REF verwiesen werden. Um nun eine Referenz aufzulösen gibt es umgekehrt den DEREF-Operator.

Durch OID und REF lassen sich somit in Tabellen eine Art Fremdschlüsselbeziehung modellieren.

Abbildung in dieser Leseprobe nicht enthalten

Besondere Eignung Komplexe Beziehungsgeflechte Einfache Beziehungen

(z.B. Stücklisten, geometrische Strukturen, ...)

Abbildung 8: Vergleichstabelle Zeilenreferenz mit Primär-/Fremdschlüsselbeziehung^[42]

3.4 Verhalten von Datenbankobjekten

In ORDBS gibt es die Möglichkeit, Methoden an Objekte zu binden, z.B. indem man bei ADT solche Funktionen definiert. Eine weitere Möglichkeit stellen Trigger dar.

Trigger sind meist kleine Programme, die immer dann aufgerufen werden, wenn ein für sie definiertes Ereignis an einem bestimmten Objekt eintritt, z.B. wenn es aktualisiert wird.^[43]

Durch die Zuweisung von Verhalten an Objekte läßt sich ein großer Teil der Programm- logik großer Anwendung bewältigen und wiederverwendbarer und gekapselt speichern.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: Unterschied zwischen der Anordnung komplizierter Operationen in herkömmlichen Da- tenbankarchitekturen (links) und dem objektorientierten Fall (rechts)^[44]

3.5 Weitere Objektorientierte Konzepte

ORDBS besitzen eine Typ- und Tabellenhierarchie, die Vererbung^[45] unterstützt. So las- sen sich speziellere Untertypen (sub types) des ADT person_t erzeugen, z.B. Angestell- te employee_t, bei denen das Datum des Beginns der Beschäftigung mitgespeichert werden soll.

CREATE TYPE employee_t UNDER person_t ( PUBLIC hire_date DATE )

Ebenso wäre es möglich, eine Untertabellen (sub tables) zu erzeugen, um beispielsweise die leitenden Angestellten von Abteilungen abzuspeichern:

CREATE TABLE employees ( emp_id INTEGER, emp employee_t )

CREATE TABLE dept_managers UNDER employee ( dept REF(department_t) )

Je nach Grad der objektorientierten Implementierung erhält das erbende Objekt nicht nur die Argumente (Struktur), sondern auch sämtliche Methoden (Verhalten). Hier wird dann das Merkmal Overiding interessant: Es erlaubt, geerbte Information mit an den Wünschen angepaßten zu „überschreiben“.

Auf der Seite der Funktionen bietet Polymorphismus die Möglichkeit, unter gleichem Namen angepaßt an den übergebenen Objekttyp Routinen auszuführen. Beispielsweise Objektrelationale Datenbanken ließe sich so zu der bereits erwähnten Funktion betrag_in_euro(dm_t) die entsprechende für französische Franc erzeugen:

Abbildung in dieser Leseprobe nicht enthalten

Wird nun die Funktion betrag_in_euro aufgerufen, entscheidet die Datenbank anhand des übergebenen Objekttyps selbstständig, welche Routine aufgerufen werden muß (und somit welcher Umrechnungskurs Verwendung findet).

4 Können ORDBS Probleme der RDBS lösen?

Abschließend möchte ich darauf eingehen, inwieweit die objektorientierten Ergänzungen des relationalen Modells dessen Nachteile beseitigen.

4.1 Datenmodellierung

Attribute, die nicht nur aus einem Wert bestehen, sondern aus einer Wertemenge kön- nen je nach Anforderung als variables Array, Set, List oder Multi Set modelliert wer- den.

Beziehungen (Assoziationen) zwischen Objekten können durch Referenzen, Is-a- Beziehungen (Generalisierung) durch Typ- und Tabellenhierarchien mittels Vererbung und Objekt-Komponentenobjekt-Beziehungen (Aggregation) mittels abstrakter Datentypen und falls nötig Referenzen und Collections modelliert werden. Somit lassen sich diese verschiedenen Beziehungstypen auch im Modell unterscheiden.

4.2 Datenbankentwurf

Auf die 1NF kann in ORDBS verzichtet werden. Dadurch lassen sich auch die Algo- rithmen für die höheren Normalformen nicht mehr anwenden. Jedoch lassen sich nun leichter Datenbankmodell anhand beispielsweise eines ER-Diagrams^[46] oder UML^[47] er- stellen.

4.3 Anfragesprache

Rekursionen wurden in den SQL-3-Standard mitaufgenommen.^[48] Durch die Einführung von Methoden in ADTs, SQL Persistent Stored Modules^[49] und Triggers wird die Notwendigkeit auf Programmiersprachen außerhalb der Datenbank auszuweichen, deutlich gesenkt. Das Typsystem ähnelt nun dem objektorientierter Programmiersprachen, so daß impedance mismatch reduziert sein sollte.

Zudem steht mit dem Call-Level-Interface eine normierte Schnittstelle zu modernen Programmiersprachen zur Verfügung^[50] und es besteht die Möglichkeit, Methoden auf den Servern in C++ oder Java zu schreiben.^[51]

4.4 Fazit

Die objektorientierten Erweiterungen bieten Lösungen für den Großteil der Probleme relationaler Datenbanksysteme. Und so verwundert es nicht, daß die großen Datenbank- hersteller auch alle derartige Produkte inzwischen auf den Markt gebracht haben.

Durch die Vielzahl von Möglichkeiten und das beibehalten der Relation kann beim erstellen des Datenmodells jedoch die Designentscheidung erschwert werden.^[52]

Im Vergleich mit vollständig objektorientierten Datenbanksystemen können ORDBS von der Ausgereiftheit der zugrundeliegenden Systeme profitieren. So stellen OODBS bei Transaktionen und Anfragen keine echte Konkurrenz für ORDBS dar.^[53]

Und ein wichtiges Argument darf hierbei nicht vergessen werden: Anwendungen und Daten für bestehende RDBMS lassen sich meist nahtlos in ORDBMS überführen, da diese die direkte Nachfolgeversion darstellt. Somit wird meiner Meinung nach die Ob- jektorientierung in kleinen Schritten Einzug in die Datenbankwelt erhalten - in Form von ORDBS. Mit zunehmendem Reifegrad und neuentwickelten Anwendungen werden auch OODBS mehr Verbreitung finden - doch bis dahin eine Speziallösung bleiben.

„Jedoch leiten objektorientierte Datenbanksysteme einen Paradigmenwechsel ein, der im Markt recht schwer zu etablieren ist. Genau darin besteht der Unterschied zu objekt- relationalen Datenbanken und somit zu SQL-3: Hier wird eine objektorientierte Evolu- tion statt einer objektorientierten Revolution durchgeführt. Zudem liegen Objektdaten- banken bezüglich Stabilität und verfügbaren Administrationswerkzeugen noch hinter relationalen zurück.“^[54]

Literatur-/Quellenverzeichnis

Foutier, Paul J. [SQL3, 1999]: SQL-3 - Implementing the Object-Relational Database, Implementing the SQL Foundation Standard, New York: McGraw-Hill, 1999

Heuer, Andreas [OODBs, 1997]: Objektorientierte Datenbanken - Konzepte, Modelle, Standards und Systeme, 2., aktualisierte und erweiterte Aufl., Bonn: Addison- Wesley-Longman, 1997

Heuer, Andreas / Saake, Gunter [Datenbanken, 1997]: Datenbanken - Konzepte und Sprachen, 1. korrigierter Nachdruck, Bonn, Albany, Attenkirchen: Internat. Thomson Publ., 1997

Heuer, Andreas u.a. [E-Mail-Verwaltung, 1999]: Electronic-Mail-Verwaltung auf ob- jektrelationalen Datenbank-Systemen, http://e-lib.informatik.uni-

rostock.de/fulltext/1999/preprints/cs-07-99-1999.ps.gz

Koch, George / Loney, Kevin [Oracle8, 1998]: Oracle8 - Die umfassende Referenz, München, Wien: Hanser, 1998

Kumar, Sanjeev / Nori, Anil [Oracle8 ORDBS Overview, 1997]: Oracle8 Object Re- lational Database: An Overview, An Oracle Technical White Paper,

http://technet.oracle.com, 1997

Meier, Andreas / Wüst, Thomas [Objektorientierte DB, 1997]: Objektorientierte Da- tenbanken - Ein Kompaß für die Praxis, 1. Auflage, Heidelberg: dpunkt-Verl., 1997

Sauer, Hermann [RDBs, 1998]: Relationale Datenbanken - Theorie und Praxis, 4., aktulisierte und erweiterte Auflage, Bonn: Addison-Wesley-Longman, 1998

Stonebraker, Michael / Moore, Dorothy [Objektrelationale DB, 1999]: Objektrelatio- nale Datenbanken - Die nächste Große Welle, München, Wien: Hanser, 1999

Wölfer, Thomas [Der LAMP-Server]: Der LAMP-Server, in: Network Computing, 18. Oktober 2000, S. 70 - 72

Ich versichere hiermit, daß ich meine Studienarbeit mit dem Thema

„Objektrelationale Datenbanken“

selbständig verfaßt und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe.

Ort

Datum Unterschrift

[...]

---

^[1] Stonebraker, M., Objektrelationale DB, 1999, S. 1ff

^[2] Stonebraker, M., Objektrelationale DB, 1999, S. 6f

^[3] Wölfer, T., Network Computing, 18.10.2000, S.70

^[4] Stonebraker, M., Objektrelationale DB, 1999, S. 20f

^[5] vgl. Heuer, A., OODBs, 1997, S. 423

^[6] Heuer, A., OODBs, 1997, S. 431

^[7] Meier, A. / Wüst, T., Objektorientierte DB, 1997, S. 144ff

^[8] Meier, A. / Wüst, T., Objektorientierte DB, 1997, S. 147

^[9] Meier, A / Wüst, T., Objektorientierte DB, 1997, S. 148

^[10] Sauer, H., RDBs, 1998, S. 13

^[11] Heuer, A., OODBs, 1997, S. 72

^[12] vgl. Heuer, A./ Saake, G., Datenbanken, 1994, S. 94f

^[13] Heuer, A., OOBDs, 1997, S. 74

^[14] vgl. Heuer, A., OODBs, 1997, S. 78

^[15] vgl. Heuer, A. / Saake, G., Datenbanken, 1994, S. 195ff

^[16] Heuer, A., OODBs, 1997, S. 89

^[17] Heuer, A., OODBs, 1997, S. 91

^[18] Heuer, A. / Saake, G., Datenbanken, 1994, S. 220

^[19] Heuer, A., OODBs, 1997, S. 93

^[20] Heuer, A., OODBs, S. 102ff

^[21] vgl. Heuer, A., OODBs, S. 1

^[22] Heuer, A., OODBs, S.413f

^[23] Heuer, A., OODBs, S.420

^[24] Heuer, A., OODBs, 1997, S. 422f

^[25] vgl. Meier, A. / Wüst, T., Objektorientierte DB, 1997, S. 173

^[26] vgl. Fortier, P. J., SQL3, 1999, S. 119ff

^[27] vgl. Sauer, H., RDBs, 1998, S. 127ff

^[28] Sauer, H., RDBs, 1998, S. 128

^[29] Fortier, P. J., SQL3, 1999, S. 135f

^[30] vgl. Sauer, H., RDBs, 1998, S. 131

^[31] vgl . Stonebraker, M., Objektrelationale DB, 1999, S.55

^[32] vgl. Fortier, P. J., SQL3, 1999, S. 157; anders hierzu Notation in Illustra mit einfachem Punkt, vgl. Stonebraker, M., Objektrelationale DB, 1999, S. 55

^[33] vgl. Stonebraker, M., Objektrelationale DB, 1999, S.30ff; ebenso Meier, A. / Wüst, T., Objektorientierte DB, 1997, S. 161

^[34] vgl. Stonebraker, M., Objektrelationale DB, 1999, S. 41

^[35] vgl. Kumar, S. / Nori, A., Oracle8 ORDBS Overview, 1997

^[36] vgl. Meier, A. / Wüst, T., Objektrientierte DB, 1997, S. 161

^[37] vgl. Heuer, A., OODBs, 1997, S. 589 u. S. 518ff

^[38] Heuer, A. / Saake, G. , Datenbanken, 1994, S. 111ff

^[39] vgl. Fortier, P. J., SQL3, S. 270; ebenso Koch, G. / Loney, K., Oracle8, 1998

^[40] Fortier, P. J., SQL3, 1999, S. 140f

^[41] vgl. Heuer, A., OODBs, 1997, S. 101

^[42] Sauer, H., RDBs, 1998, S. 120f

^[43] vgl. Fortier, P. J., SQL3, S. 275ff

^[44] Heuer, A., OODBs, 1997, S. 103

^[45] vgl. Sauer, H., RDBs, 1998, S.109ff

^[46] vgl. Heuer, A., OODBs, 1997, S. 134ff

^[47] vgl. Heuer, A., OODBs, 1997, S. 176f und Meier, A. / Wüst, T., Objektorientierte DB, 1997, S. 11

^[48] vgl. Fortier, P. J., SQL3, 1999, S. 345-356

^[49] vgl. Fortier, P.J., SQL3, 1999, S. 301-339

^[50] vgl. Fortier, P. J., SQL3, 1999, S. 79f

^[51] vgl. Sauer, H., RDBs, 1998, S. 138

^[52] vgl. Sauer, H., RDBs, 1998, S. 139

^[53] vgl. Heuer, A., OODBs, 1997, S. 429

^[54] Sauer, H., RDBs, 1998, S. 104