1 Abgrenzung verschiedener Datenbanksysteme
Werbung
Objektrelationale Datenbanken Studienarbeit für die Prüfung zum Diplom-Betriebswirt (BA) im Ausbildungsbereich Wirtschaft Fachrichtung: Wirtschaftsinformatik Kurs: WWI98G1 der von Name: Springmann Geburtsort: Achern Vorname: Michael Ausbildungsstätte: Badischer Gemeinde-Versicherungs-Verband Betreuender Dozent: Abgabedatum: 06.11.2000 Dipl.-Wirt. Ing. (FH) Uwe Faber Note: ......................... Inhaltsverzeichnis Seite 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 ..................................................................................................... 5 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üsselbeziehung ................................................................................................ 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 Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. 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. Abfrage 2 4 keine Abfrage 1 3 einfache Daten komplexe Daten 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 wirklich Abfragen benutzt. Die einzige „Abfrage“ ist „hole Datei“, die einzige 1 Stonebraker, M., Objektrelationale DB, 1999, S. 1ff Objektrelationale Datenbanken Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. Seite 2 „Aktualisierung“ 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.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 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 MultimediaAnwendungen. 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 2 3 Stonebraker, M., Objektrelationale DB, 1999, S. 6f Wölfer, T., Network Computing, 18.10.2000, S.70 Objektrelationale Datenbanken Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. Seite 3 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 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 Abfrage keine Abfrage relationales DBMS objektrelationales DBMS 100 150 Datei-System objektorientiertes DBMS 1 einfache Daten komplexe Daten 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ü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 4 Stonebraker, M., Objektrelationale DB, 1999, S. 20f Objektrelationale Datenbanken Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. Seite 4 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 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, Polymorphismus, Datenkapselung, Vollständigkeit Datenbankgrundsätze werden und Typen und Klassen, Erweiterbarkeit Dauerhaftigkeit, Vererbung, bewertet. große Als Datenbestände, Mehrbenutzerbetrieb, Rekonstruierbarkeit und Ad-hoc-Abfragemöglichkeit bewertet. Zusätzlich fließt noch die Praxistauglichkeit im bezug auf Sprachunabhängigkeit, Datenunabhängigkeit, Autorisierung, Beziehungskonzept, Standardkonformität, Schemaevolution, Integration und Versionenkontrolle, Migration sowie Eigenschaften der Objektorientierung Objectivity/DB ObjectStore Itasca O2 POET GemStone Matisse Versant ONTOS DB Omniscience Informix/Illustra UniSQL/X objektorientierte Datenbanksysteme OSMOS objektrelationale Datenbanksysteme Oracle 8 DB2 Datenbankeigenschaften 5 6 vgl. Heuer, A., OODBs, 1997, S. 423 Heuer, A., OODBs, 1997, S. 431 Objektrelationale Datenbanken Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. Seite 5 Leistungsdurchsatz ein.7 Hiernach ergibt sich folgendes Schaubild: 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 Datenmodell ausgehen und objektorientierte Erweiterungen anbieten. Die Datenhaltung erfolgt also primär in Tabellen – eventuell um Tabellenspalten mit erweiterten Datentypen ergänzt – und die Sprachschnittstelle folgt dem neuesten Sprachstandard SQL-3. Bei objektrelationalen Datenbanksystemen wird dem objektorientierten Paradigma nur teilweise entsprochen.9 7 Meier, A. / Wüst, T., Objektorientierte DB, 1997, S. 144ff Meier, A. / Wüst, T., Objektorientierte DB, 1997, S. 1479 Meier, A / Wüst, T., Objektorientierte DB, 1997, S. 148 9 Meier, A / Wüst, T., Objektorientierte DB, 1997, S. 148 8 Objektrelationale Datenbanken Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. 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 DVAnwendungen 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.12 An folgendem Beispiel wird diese Einschränkung und die Umgehung dieser deutlich: 10 Sauer, H., RDBs, 1998, S. 13 Heuer, A., OODBs, 1997, S. 72 12 vgl. Heuer, A./ Saake, G., Datenbanken, 1994, S. 94f 11 Objektrelationale Datenbanken Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. Austattungspakete Autotyp Opel Astra VW Golf Seite 7 Pakete Paket Ausstattung Radio Kassettenfach Zentralverriegelung Radio Sportlenkrad Schalensitze Sportlenkrad Schalensitze Alu-Felgen Breitreifen Radio Servolenkung 5-Gang-Getriebe Servolenkung Zentralverriegelung Airbag Kopfstützen hinten 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 Opel Astra Opel Astra Opel Astra Opel Astra Opel Astra Opel Astra Opel Astra VW Golf VW Golf VW Golf VW Golf VW Golf VW Golf Ausstattung Radio Kassettenfach Zentralverriegelung Sportlenkrad Schalensitze Alu-Felgen Breitreifen Radio Servolenkung 5-Gang-Getriebe Zentralverriegelung Airbag Kopfstützen hinten 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 Opel Astra Opel Astra Opel Astra VW Golf VW Golf Paket OA-GL OA-GS OA-GT VG-GL VG-CD Objektrelationale Datenbanken Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. Pakete Paket OA-GL OA-GL OA-GL OA-GS OA-GS OA-GS OA-GT OA-GT OA-GT OA-GT VG-GL VG_GL VG-GL VG-CD VG-CD VG-CD VG-CD Seite 8 Ausstattung Radio Kassettenfach Zentralverriegelung Radio Sportlenkrad Schalensitze Sportlenkrad Schalensitze Alu-Felgen Breitreifen Radio Servolenkung 5-Gang-Getriebe Servolenkung Zentralverriegelung Airbag Kopfstützen hinten 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 ObjektKomponentenobjekt-Beziehungen Datenbankmodell nicht (Aggregation) unterschieden werden. können Sie im werden relationalen 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 13 14 darstellt, ist die Modellierung in Heuer, A., OOBDs, 1997, S. 74 vgl. Heuer, A., OODBs, 1997, S. 78 Objektrelationale Datenbanken „höheren“ Normalformen Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. Seite 9 wünschenswert, 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.16 Beim Synthesealgorithmus hingegen werden zwar alle formalen DatenbankschemaEigenschaften erreicht, trotzdem können Attribute unterschiedlicher Objekttypen nicht getrennt werden. Außerdem werden nur funktionale und keine mehrwertigen Abhängigkeiten berücksichtigt.17 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.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 allgemeine Programme, die in einer höheren Programmiersprache geschrieben werden. 15 vgl. Heuer, A. / Saake, G., Datenbanken, 1994, S. 195ff 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 16 Objektrelationale Datenbanken Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. Der Hauptnachteil bei derzeit existierenden Datenbanksystemen Seite 10 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.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, 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.22 Bei weitgehenden Erweiterungen des relationalen Systems um objektorientierte Eigenschaften spricht man von objektrelationalen Datenbanksystemen,23 denen ich mich noch genauer widmen möchte. 20 Heuer, A., OODBs, S. 102ff vgl. Heuer, A., OODBs, S. 1 22 Heuer, A., OODBs, S.413f 23 Heuer, A., OODBs, S.420 21 Objektrelationale Datenbanken Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. 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 Sprache25, 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 vgl. Meier, A. / Wüst, T., Objektorientierte DB, 1997, S. 173 26 vgl. Fortier, P. J., SQL3, 1999, S. 119ff 25 Objektrelationale Datenbanken Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. 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.28 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 28 vgl. Sauer, H., RDBs, 1998, S. 127ff Sauer, H., RDBs, 1998, S. 128 Objektrelationale Datenbanken Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. 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 vermittler_nr ) euro_t, 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 Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. Seite 14 Abbildung 7: Beispiel für Row data type Beispiel:29 CREATE TABLE employees emp_id KEY, last_name first_name NULL, emp_address emp_phone emp_full_time emp_signature emp_picture emp_resume ) ( INTEGER CONSTRAINT employees_emp_id_pk PRIMARY name_t CONSTRAINT employees_last_name NOT NULL, name_t CONSTRAINT employees_first_name NOT ROW ( street CHARACTER city CHARACTER state CHARACTER zip CHARACTER ), CHARCTER (10), BOOLEAN, BLOB (1M), BLOB (10M), CLOB (50K) VARYING (30) VARYING (20) (2), VARYING (9) 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 city CHARACTER state CHARACTER zip CHARACTER ), CREATE TABLE employees emp_id KEY, last_name first_name NULL, emp_address emp_phone emp_full_time emp_signature emp_picture emp_resume ) 29 VARYING (30) VARYING (20) (2), VARYING (9) ( INTEGER CONSTRAINT employees_emp_id_pk PRIMARY name_t CONSTRAINT employees_last_name NOT NULL, name_t CONSTRAINT employees_first_name NOT address_t, CHARCTER (10), BOOLEAN, BLOB (1M), BLOB (10M), CLOB (50K) Fortier, P. J., SQL3, 1999, S. 135f Objektrelationale Datenbanken Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. 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.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 30 vgl. Sauer, H., RDBs, 1998, S. 131 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 31 Objektrelationale Datenbanken Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. Seite 16 beispielsweise 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 angepriesen, 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 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 KEY, last_name first_name emp_address emp_phone emp_full_time emp_signature emp_picture emp_resume ) ( INTEGER CONSTRAINT employees_emp_id_pk PRIMARY name CONSTRAINT employees_last_name NOT NULL, name CONSTRAINT employees_first_name NOT NULL, address_t, CHARCTER (10) ARRAY (5), BOOLEAN, BLOB (1M), BLOB (10M), CLOB (50K) 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.38 In SQL-3 wird zum entschachteln solcher PNF der THE-Operator verwendet.39 Die verwendete Abbildung 34 vgl. Stonebraker, M., Objektrelationale DB, 1999, S. 41 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 35 Objektrelationale Datenbanken Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. Seite 17 der Ausstattungspakete 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:nKardinalitä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-Wert41 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 41 Fortier, P. J., SQL3, 1999, S. 140f vgl. Heuer, A., OODBs, 1997, S. 101 Objektrelationale Datenbanken Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. 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. Art der Beziehung Kardinalitäten Unabhängigkeit von logischen Datenstrukturen Unabhängigkeit von Datenänderungen Referentielle Integrität Zugriffsoptimierung Besondere Eignung Zeilenreferenz Explizit durch Referenzen. Die Referenzen einer Spalte können auf verschiedene Tabellen zeigen. 1:1 und n:1 (1:n und n:m zukünftig durch Collection-Typen) Gering Primär- / Fremdschlüsselbeziehung Beziehung wird dynamisch durch Wertevergleich (JOIN) rekonstruiert. 1:1, 1:n und n:1 Hoch Wenn sich der Schlüsselwert ändert, Wenn sich der Schlüsselwert ändert, bleiben Referenzen gültig. müssen alle Werte, auf die referenziert wird, geändert werden. Typprüfung und Scope-Anweisung Referentielle Integrität kann verhindern ungültige Referenzen. jederzeit vom Datenbanksystem Referenzen auf gelöschte Zeilen sichergestellt werden. werden beim zugriff erkannt. Durch Indizes und durch die in der Durch einen Index Zeilenreferenz enthaltene interne Satzadresse Komplexe Beziehungsgeflechte Einfache Beziehungen (z.B. Stücklisten, geometrische Strukturen, ...) Abbildung 8: Vergleichstabelle Zeilenreferenz mit Primär-/Fremdschlüsselbeziehung42 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 43 Sauer, H., RDBs, 1998, S. 120f vgl. Fortier, P. J., SQL3, S. 275ff Objektrelationale Datenbanken Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. Anwendungsprogramme Sichten ... ... Personen Personen Angestellte Seite 19 Angestellte 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 Vererbung45 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 45 Heuer, A., OODBs, 1997, S. 103 vgl. Sauer, H., RDBs, 1998, S.109ff Objektrelationale Datenbanken Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. 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 Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. 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-aBeziehungen (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-Diagrams46 oder UML47 erstellen. 4.3 Anfragesprache Rekursionen wurden in den SQL-3-Standard mitaufgenommen.48 Durch die Einführung von Methoden in ADTs, SQL Persistent Stored Modules49 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 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 47 Objektrelationale Datenbanken Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. Seite 22 Zudem steht mit dem Call-Level-Interface eine normierte Schnittstelle zu modernen Programmiersprachen zur Verfügung50 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 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 51 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: AddisonWesley-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: dpunktVerl., 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 ......................... ......................................... Datum Unterschrift Objektrelationale Datenbanken
