Inhaltsverzeichnis

  Inhaltsverzeichnis  II

  Darstellungsverzeichnis  III

  Abkürzungsverzeichnis.  IV

1  Abgrenzung verschiedener Datenbanksysteme.  1

1.1  Klassifizierung nach Stonebraker  1

1.2  Kritik an der Klassifizierung nach Stonebraker.  3

1.3  Differenzierung OODBS / ORDBS.  4

2  Nachteile von RDBMS.  6

2.1  Datenmodellierung  6

2.2  Datenbankentwurf.  8

2.3  Anfragesprache  9

2.4  Fazit  10

3  Erweiterungen des relationalen DBS in ORDBS  11

3.1  Basisdatentypen  11

3.1.1  BLOB.  12

3.1.2  CLOB.  12

3.2  Benutzerdefinierte Datentypen  12

3.2.1  Distinct Types  12

3.2.2  Row Types  13

3.2.3  Abstract Data Types.  15

3.2.4  Array Types  16

3.2.5  weitere Collections  17

3.3  Objekt-Identitäten und Referenzen.  17

3.4  Verhalten von Datenbankobjekten  18

3.5  Weitere Objektorientierte Konzepte  19

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

4.1  Datenmodellierung  21

4.2  Datenbankentwurf.  21

4.3  Anfragesprache  21

4.4  Fazit  22

  Literatur-/Quellenverzeichnis  23

  Objektrelationale Datenbanken  

  Darstellungsverzeichnis  

  Abbildung 1: DBMS-Klassifikationsmatrix.  1

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

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

  Systeme  4

  Abbildung 4: Autotypen mit Ausstattungspaketen: geschachtelte Darstellung  7

  Abbildung 5: Autotypen mit Ausstattungspaketen: relationale Darstellung mit  

  Informationsverlust  7

  Abbildung 6: Autotypen mit Ausstattungspaketen: relationale Darstellung mit  

  künstlichen Schlüsseln  8

  Abbildung 7: Beispiel für Row data type  14

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

  beziehung  18

  Abbildung 9: Unterschied zwischen der Anordnung komplizierter Operationen in  

  herkömmlichen Datenbankarchitekturen (links) und dem  

  objektorientierten Fall (rechts)  19

  Objektrelationale Datenbanken  

Abkürzungsverzeichnis

ADT abstrakter Datentyp DDL Data Definition Language DML Data Manipulation Language DBMS Datenbank-Managementsystem ER Entity Relationship IT Informationstechnologie ODL Object Definition Language ODMG Object Database Management Group OID Object Identification OML Object Manipulation Language OODBS Objektorientiertes Datenbanksystem OOPL Objektorientierte Programmiersprache OQL Object Query Language ORDBS Objektrelationales Datenbanksystem ORDBMS Objektrelationales Datenbankmanagementsystem RDBS Relationales Datenbanksystem RDBMS Relationales Datenbankmanagementsystem SQL Structured Query Language UML Unified Modeling Language WWW World Wide Web

Objektrelationale Datenbanken

Abgrenzung verschiedener Datenbanksysteme Seite 1

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.

1 3

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 wirklich Abfragen benutzt. Die einzige „Abfrage“ ist „hole Datei“, die einzige „Aktualisie-

¹ Stonebraker, Objektrelationale Objektrelationale Datenbanken

Abgrenzung verschiedener Datenbanksysteme Seite 2

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. Besonders 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. ² 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 Performance nicht gestellt. Als Plattform für Anwendungen dieses Quadranten sieht er Objektorientierte Datenbanken wie Produkte von Object Design, Ontologic, Versant, Servio, 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 abzuspeichern, 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 Geschwindigkeit, in der sich z.B. das World Wide Web fülle. Auch die zunehmende Speicherung von Bild und Ton in digitaler Form führe zu enormem Bedarf an Verwaltung

2 Stonebraker, M., Objektrelationale DB, 1999, S. 6f

3 Wölfer, T., Network Computing, 18.10.2000, S.70 Objektrelationale Datenbanken

Abgrenzung verschiedener Datenbanksysteme Seite 3

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 anwachse. 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 Interesse, z.B. in Versicherungen auch Bilder der Schadensdaten direkt im Datenverarbeitungssystem abzulegen. Insgesamt schätze er den Markt für Datenbankmanagementsysteme im Verhältnis zum heutigen Gesamtmarkt wie folgt dargestellt ein: 4

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ürde, 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 Materie 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. ⁵ Selbst eine standardisierte Abfragesprache

4 Stonebraker, M., Objektrelationale DB, 1999, S. 20f

5 vgl. Heuer, A., OODBs, 1997, S. 423 Objektrelationale Datenbanken

Abgrenzung verschiedener Datenbanksysteme Seite 4

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 Objektorientierung zur Einordnung der verfügbaren kommerziellen Datenbanksysteme. Hinter diesen Charakteristika verbergen sich jeweils eine Vielzahl von Einzelkriterien. Unter den Prinzipien der Objektorientierung werden die Unterstützung für komplexe Objekte, Objektidentität, Datenkapselung, Typen und Klassen, Vererbung, Polymorphismus, Vollständigkeit und Erweiterbarkeit bewertet. Als Datenbankgrundsätze werden Dauerhaftigkeit, 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. ⁷ Hiernach ergibt sich folgendes Schaubild:

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

6 Heuer, A., OODBs, 1997, S. 431

7 Meier, A. / Wüst, T., Objektorientierte DB, 1997, S. 144ff Objektrelationale Datenbanken

Abgrenzung verschiedener Datenbanksysteme Seite 5

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

8 Meier, A. / Wüst, T., Objektorientierte DB, 1997, S. 147 9 Meier, A / Wüst, T., Objektorientierte DB, 1997, S. 148

Objektrelationale Datenbanken

Nachteile von RDBMS Seite 6

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 verstehen 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 Konzepte Attribute, Relationenschema sowie Integritätsbedingungen wie Schlüssel und Fremdschlü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. ¹² An folgendem Beispiel wird diese Einschränkung und die Umgehung dieser deutlich:

10 Sauer, H., RDBs, 1998, S. 13

11 Heuer, A., OODBs, 1997, S. 72

12 vgl. Heuer, A./ Saake, G., Datenbanken, 1994, S. 94f Objektrelationale Datenbanken

Nachteile von RDBMS Seite 7

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:

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:

Nachteile von RDBMS Seite 8

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), Isa-Beziehungen zwischen verschiedenen Objekttypen (Generalisierung) und Objekt-Komponentenobjekt-Beziehungen (Aggregation) können im relationalen Datenbankmodell 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-

13 Heuer, OOBDs,

14 vgl. Heuer, A., OODBs, 1997, S. 78 Objektrelationale Datenbanken

Nachteile von RDBMS Seite 9

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 Dekompositions- und der Synthesealgorithmus, sowie das Sichtintegrationsverfahren. Diese hier zu erläutern würde den Rahmen der Arbeit sprengen. Es bleibt jedoch zu erwähnen, 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. ¹⁶ Beim Synthesealgorithmus hingegen werden zwar alle formalen Datenbankschema-Eigenschaften erreicht, trotzdem können Attribute unterschiedlicher Objekttypen nicht getrennt werden. Außerdem werden nur funktionale und keine mehrwertigen Abhängigkeiten berücksichtigt. ¹⁷ Beim Sichtintegrationsverfahren treten eventuell unentscheidbare Probleme auf, die ihre Ursache in der uneingeschränkten Form der zugehörigen Abhängigkeiten haben. 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. ¹⁹ 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 allgemeine Programme, die in einer höheren Programmiersprache geschrieben werden. Der

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 Objektrelationale Datenbanken

Nachteile von RDBMS Seite 10

Hauptnachteil bei derzeit existierenden Datenbanksystemen und Programmiersprachen ist der sog. impedance mismatch, das Nicht-Zusammenpassen von Programmiersprachen- 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 Verwendung einer Datenbankprogrammiersprache. ²⁰ 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. ²¹ 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, Speicherstrukturen und Zugriffspfade, Transaktionen und Concurrency Control sowie Recovery-Mechanismen ein objektorientiertes Datenbanksystem (OODBS) entwickelt. Oder aber es wurde ein bestehendes (meist relationales) Datenbanksystem strukturell und / oder verhaltensmäßig objektorientiert erweitert. ²² Bei weitgehenden Erweiterungen des relationalen Systems um objektorientierte Eigenschaften spricht man von objektrelationalen Datenbanksystemen, ²³ denen ich mich noch genauer widmen möchte.

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 Objektrelationale Datenbanken

Erweiterungen des relationalen DBS in ORDBS Seite 11

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 genannt werden)

⇒ eine getrennte Klassen- und Typhierarchie (die Klassenhierarchie wird bei objektrelationalen 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 ²⁵ , 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

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 Objektrelationale Datenbanken

Erweiterungen des relationalen DBS in ORDBS Seite 12

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. Hierbei handelt es sich um die Definition eines neuen Namens für einen bereits existierenden Typ. ²⁸ Dies läßt sich einsetzen, um verschiedene Argumente, die intern gleich dargestellt 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.

27 vgl. Sauer, H., RDBs, 1998, S. 127ff

28 Sauer, H., RDBs, 1998, S. 128 Objektrelationale Datenbanken

Erweiterungen des relationalen DBS in ORDBS Seite 13

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

CREATE TABLE provisionen ( provision dm_t, vermittler_nr INTEGER, )

CREATE TABLE gewinn ( gewinn euro_t, vermittler_nr INTEGER, )

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:

SELECT provisionen.vermittler_nr, provisionen.provision, gewinne.gewinn

FROM gewinne, provisionen

WHERE gewinne.vermittler_nr = provisionen.vermittlernummer AND gewinne.gewinn < provisionen.provision

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:

FUNCTION betrag_in_euro(dm dm_t) RETURNS euro_t

BEGIN DECLARE euro euro_t; SET euro = dm / 1,95583; RETURN euro;

END

Die korrekte Abfrage lautet nun:

SELECT provisionen.vermittler_nr, provisionen.provision, gewinne.gewinn

FROM gewinne, provisionen

WHERE gewinne.vermittler_nr = provisionen.vermittlernummer AND gewinne.gewinn < betrag_in_euro(provisionen.provision)

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.

Objektrelationale Datenbanken

Erweiterungen des relationalen DBS in ORDBS Seite 14

Beispiel: 29

CREATE TABLE employees ( emp_id INTEGER CONSTRAINT employees_emp_id_pk PRIMARY KEY, last_name name_t CONSTRAINT employees_last_name NOT NULL, first_name name_t CONSTRAINT employees_first_name NOT NULL, emp_address ROW (

street CHARACTER VARYING (30)

CHARACTER VARYING (20) emp_phone emp_full_time emp_signature emp_picture emp_resume CLOB (50K) )

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:

CREATE ROW TYPE address_t ( street CHARACTER VARYING (30)

city CHARACTER VARYING (20) state zip CHARACTER VARYING (9) ), CREATE TABLE employees ( emp_id INTEGER CONSTRAINT employees_emp_id_pk PRIMARY KEY, last_name name_t CONSTRAINT employees_last_name NOT NULL, first_name name_t CONSTRAINT employees_first_name NOT NULL, emp_address address_t,

emp_phone CHARCTER (10), emp_full_time emp_signature emp_picture emp_resume ) 29 Fortier, P. J., SQL3, 1999, S. 135f Objektrelationale Datenbanken

Erweiterungen des relationalen DBS in ORDBS Seite 15

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 internen 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

CREATE TYPE person_t ( PUBLIC first_name name_t, PUBLIC last_name name_t, PUBLIC date_of_birth DATE )

CREATE TABLE students ( student person_t, course course_t )

SELECT last_name(student) FROM students WHERE ...

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. ³¹ 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. ³³ Sie bieten dadurch die Grundlage für Unterstützung von bei-

30 vgl. Sauer, RDBs,

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 Objektrelationale Datenbanken

Erweiterungen des relationalen DBS in ORDBS Seite 16

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. ³⁴ Die so „erweiterten ADTs“ sind nicht im SQL-3-Standard enthalten und werden von den Datenbankherstellern unter verschiedenen Namen angepriesen, so heißt dieser Datentyp in Oracle 8i „Data Cartrige“ ³⁵ , in IBM DB2 Universal Database „Reltional Extenders“ ³⁶ und in Illustra / Informix Universal Server „Data Blades“ 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:

CREATE TABLE employees ( emp_id INTEGER CONSTRAINT employees_emp_id_pk PRIMARY KEY, last_name name CONSTRAINT employees_last_name NOT NULL,

first_name name CONSTRAINT employees_first_name NOT NULL, emp_address emp_phone emp_full_time emp_signature emp_picture emp_resume ) 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. Darunter werden jene NF²-Relationen zusammengefaßt, die sich immer entschachtelt durch eine äquivalente 1NF-Relation darstellen lassen. ³⁸ In SQL-3 wird zum entschachteln solcher PNF der THE-Operator verwendet. ³⁹ Die verwendete Abbildung der Ausstat-

34 vgl. Stonebraker, Objektrelationale

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 Objektrelationale Datenbanken

Erweiterungen des relationalen DBS in ORDBS Seite 17

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 aufnehmen. 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 aufgenommen.

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 Fremdschlü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 abstrakte Schlüssel ohne offensichtliche Aussagekraft verwendet, wie z.B. eine fortlaufende Bestellnummern.

In ORDBS kann vom System intern ein Surrogat-Wert ⁴¹ 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.

40 Fortier, P. J., SQL3, 1999, S. 140f

41 vgl. Heuer, A., OODBs, 1997, S. 101 Objektrelationale Datenbanken

Erweiterungen des relationalen DBS in ORDBS Seite 18

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 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 Programmlogik großer Anwendung bewältigen und wiederverwendbarer und gekapselt speichern.

42 Sauer, H., RDBs, 1998, S. 120f

43 vgl. Fortier, P. J., SQL3, S. 275ff Objektrelationale Datenbanken

Erweiterungen des relationalen DBS in ORDBS Seite 19

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

3.5 Weitere Objektorientierte Konzepte

ORDBS besitzen eine Typ- und Tabellenhierarchie, die Vererbung ⁴⁵ unterstützt. So lassen sich speziellere Untertypen (sub types) des ADT person_t erzeugen, z.B. Angestellte 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

44 Heuer, A., OODBs, 1997, S. 103

45 vgl. Sauer, H., RDBs, 1998, S.109ff Objektrelationale Datenbanken

Erweiterungen des relationalen DBS in ORDBS Seite 20

ließe sich so zu der bereits erwähnten Funktion betrag_in_euro(dm_t) die entsprechende für französische Franc erzeugen:

CREATE DISTINCT TYPE ffr_t AS DECIMAL (7,2)

FUNCTION betrag_in_euro(ffr ffr_t) RETURNS euro_t

BEGIN DECLARE euro euro_t; SET euro = ffr / 6,55957; RETURN euro;

END

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

Objektrelationale Datenbanken

Können ORDBS Probleme der RDBS lösen? Seite 21

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önnen je nach Anforderung als variables Array, Set, List oder Multi Set modelliert werden.

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 Algorithmen für die höheren Normalformen nicht mehr anwenden. Jedoch lassen sich nun leichter Datenbankmodell anhand beispielsweise eines ER-Diagrams ⁴⁶ oder UML ⁴⁷ erstellen.

4.3 Anfragesprache

Rekursionen wurden in den SQL-3-Standard mitaufgenommen. ⁴⁸ Durch die Einführung von Methoden in ADTs, SQL Persistent Stored Modules ⁴⁹ 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.

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 Objektrelationale Datenbanken

Können ORDBS Probleme der RDBS lösen? Seite 22

Zudem steht mit dem Call-Level-Interface eine normierte Schnittstelle zu modernen Programmiersprachen zur Verfügung ⁵⁰ 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 Datenbankhersteller 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 Objektorientierung 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 objektrelationalen Datenbanken und somit zu SQL-3: Hier wird eine objektorientierte Evolution statt einer objektorientierten Revolution durchgeführt. Zudem liegen Objektdatenbanken bezüglich Stabilität und verfügbaren Administrationswerkzeugen noch hinter relationalen zurück.“ 54

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

⁵³ vgl. Heuer, A., OODBs, 1997, S. 429

54 Sauer, H., RDBs, 1998, S. 104 Objektrelationale Datenbanken

Literatur-/Quellenverzeichnis Seite 23

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 objektrelationalen Datenbank-Systemen, http://e-lib.informatik.unirostock.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 Relational Database: An Overview, An Oracle Technical White Paper, http://technet.oracle.com, 1997

Meier, Andreas / Wüst, Thomas [Objektorientierte DB, 1997]: Objektorientierte Datenbanken - 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]: Objektrelationale 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

Objektrelationale Datenbanken

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

......................... .........................................