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
Häufig gestellte Fragen
Was ist das Thema dieses Dokuments?
Dieses Dokument behandelt objektrelationale Datenbanken (ORDBMS) und deren Erweiterungen gegenüber relationalen Datenbanksystemen (RDBMS). Es werden die Nachteile von RDBMS beleuchtet und wie ORDBMS diese Probleme lösen können.
Wie werden Datenbanksysteme in diesem Dokument klassifiziert?
Das Dokument stellt eine Klassifizierung nach Stonebraker vor, die auf der Komplexität der Daten und dem Bedarf an Abfragemöglichkeiten basiert. Es wird auch ein differenzierteres Modell zur Marktübersicht anhand von Datenbankeigenschaften und Objektorientierungseigenschaften vorgestellt.
Welche Nachteile von RDBMS werden diskutiert?
Die diskutierten Nachteile von RDBMS umfassen Einschränkungen bei der Datenmodellierung (z.B. atomare Attributwerte, fehlende Unterscheidung zwischen Beziehungsarten), erhöhten Aufwand beim Datenbankentwurf, und Probleme mit Anfragesprachen (z.B. Strukturmangel im Ergebnis, keine Unterstützung komplexer Strukturen).
Welche Erweiterungen des relationalen DBS in ORDBS werden behandelt?
Das Dokument behandelt Basisdatentypen wie BLOB und CLOB, benutzerdefinierte Datentypen (Distinct Types, Row Types, Abstract Data Types, Array Types, weitere Collections), Objekt-Identitäten und Referenzen, das Verhalten von Datenbankobjekten (Methoden, Trigger) sowie weitere objektorientierte Konzepte (Typ- und Tabellenhierarchien, Vererbung, Polymorphismus).
Wie können ORDBS die Probleme von RDBMS lösen?
ORDBS können die Datenmodellierung verbessern, indem sie komplexe Attribute, Beziehungen und die Unterscheidung verschiedener Beziehungstypen ermöglichen. Sie können auch den Datenbankentwurf vereinfachen, indem sie auf die 1NF verzichten. Die Anfragesprachen werden durch Rekursionen, Methoden in ADTs, SQL Persistent Stored Modules und Triggers erweitert, wodurch die Notwendigkeit, auf externe Programmiersprachen auszuweichen, verringert wird.
Was sind Abstract Data Types (ADTs)?
Abstrakte Datentypen (ADTs) sind eine bedeutende Erweiterung des Typsystems in ORDBMS. Sie erlauben das Neubenennen von bestehenden Datentypen, die Kombination aus bestehenden Typen, sowie die Definition von Methoden und die Kapselung der internen Darstellung der Werte.
Was sind Objekt-Identitäten (OID) und Referenzen (REF) in ORDBMS?
In ORDBMS kann vom System intern ein Surrogat-Wert (OID) erzeugt werden, der einen Datensatz repräsentiert. Auf ein solches Objekt kann über eine (Zeilen-)Referenz mit REF verwiesen werden. OID und REF ermöglichen eine Art Fremdschlüsselbeziehung in Tabellen.
Was sind Trigger und Methoden in ORDBMS?
Trigger sind kleine Programme, die immer dann aufgerufen werden, wenn ein definiertes Ereignis an einem bestimmten Objekt eintritt. Methoden sind an Objekte gebundene Funktionen. Durch die Zuweisung von Verhalten an Objekte läßt sich ein großer Teil der Programmlogik großer Anwendungen wiederverwendbarer und gekapselt speichern.
Was bedeuten NF² und PNF im Kontext von Array Types?
NF² (Non First Normal Form) ist eine geschachtelte Relation, die durch Array Types ermöglicht wird. PNF (Partitioned Normal Form) ist eine Art von NF²-Relation, die sich immer entschachtelt durch eine äquivalente 1NF-Relation darstellen lässt.
- Quote paper
- Michael Springmann (Author), 2001, Objektrelationale Datenbanken, Munich, GRIN Verlag, https://www.grin.com/document/105500
