=Paper=
{{Paper
|id=None
|storemode=property
|title=Nutzung von Proxys zur Ergänzung von Datenbankfunktionen
|pdfUrl=https://ceur-ws.org/Vol-581/gvd2010_2_2.pdf
|volume=Vol-581
|dblpUrl=https://dblp.org/rec/conf/gvd/AdamLB10
}}
==Nutzung von Proxys zur Ergänzung von Datenbankfunktionen==
https://ceur-ws.org/Vol-581/gvd2010_2_2.pdf
Nutzung von Proxys zur Ergänzung von
Datenbankfunktionen
Alexander Adam Sebastian Leuoth Wolfgang Benn
Technische Universität Technische Universität Technische Universität
Chemnitz Chemnitz Chemnitz
Straße der Nationen 62 Straße der Nationen 62 Straße der Nationen 62
09107 Chemnitz 09107 Chemnitz 09107 Chemnitz
alad@cs.tu-chemnitz.de lese@cs.tu-chemnitz.de benn@cs.tu-chemnitz.de
ZUSAMMENFASSUNG oder dessen Pendant bei IBM, des DB2 Spatial Extenders
In dieser Arbeit präsentieren wir eine Möglichkeit, Funk- [12]. Beide bauen einen neuen Index – einen R-Baum [9] bei
tionalitäten – in diesem Fall primär Indizes – in eine Da- Oracle, ein Grid bei DB2 [2] – ein.
tenbank einzubringen. Dies geschieht in einer Weise, dass
weder die Datenbank noch eine Anwendung, welche die Da- All das führt dazu, dass heutige relationale Datenbanken für
tenbank nutzt, etwas davon bemerken soll. Auf diese Weise sehr viele Bereiche Lösungen in Form von Indizes bereits
soll die aufwendige Anpassung der Anwendungen an eine zur Verfügung stellen. Allerdings gibt es auch Anwendungs-
zusätzliche Komponente vermieden werden. Zugleich wird gebiete – jene, die nicht genügend Nachfrage bieten können
auch verhindert, dass die Datenbank durch das Einbringen – bei denen diese Standardlösungen nicht anwendbar sind.
neuer Funktionalitäten instabiler wird. Der Anwender steht dann vor der Wahl, eine komplett eigene
Datenbanklösung zu erstellen oder aber eine bestehende Da-
tenbank zu erweitern. Eine Eigenentwicklung kommt dabei
Keywords für die wenigsten in Frage, da diese immens zeit- und damit
Datenbankerweiterung, Indizierung, Proxy kostenintensiv ist. Sie muss darüberhinaus auch selbst wei-
terentwickelt und mit Aktualisierungen versorgt werden, ein
1. EINLEITUNG weiterer sehr kostenintensiver Punkt, der gegen eine solche
Datenbanken sind allgegenwärtig und nicht mehr aus dem Entwicklung spricht.
täglichen Leben wegzudenken. Sie verwalten von vertrauli-
chen Personendaten bis hin zum Zahlungsverkehr von Ban- Bei der zweiten Möglichkeit – der Erweiterung eines Daten-
ken sehr viele Bereiche der Gesellschaft. Daraus ergeben banksystems – wird über vom Datenbankhersteller bereit-
sich einige Anforderungen, denen Datenbanksysteme gerecht gestellte Schnittstellen die Funktionalität einer bestehenden
werden müssen. So kann erwartet werden, dass Zugangs- Datenbank um die geforderten Eigenschaften erweitert. Es
richtlinien eingehalten und die Daten sicher – d. h. vor frem- ist schwierig, diese Erweiterungen dauerhaft in Datenbanken
dem Zugriff und Verlust – verwahrt werden. zu integrieren. Zum einen haben die Datenbankhersteller ein
berechtigtes Interesse daran, nur gut getestete Komponen-
Datenbanken, wie wir sie heute kennen, haben sich dabei ten in ihre Produkte einfließen zu lassen, zum anderen müs-
über viele Jahre hinweg entwickelt. Angefangen von den sen diese weitestgehend allgemein einsetzbar sein.
ersten Systemen, wie z. B. System R [4] und IMS [8], bis
zu den heutigen großen relationalen Datenbanksystemen – In einigen Umgebungen ist es allerdings nicht möglich, Ein-
bspw. Oracle [14] und IBM DB2 [3], um nur einige zu nennen griffe in die Datenbank oder die Anwendungen, die auf sie
– wurden immer wieder neue Funktionalitäten hinzugefügt. Zugriff nehmen, vorzunehmen. Ein Szenario ist hier der Be-
Entwicklungen an Datenbanksystemen finden dabei meist trieb eines Rechenzentrums, welches Datenbankdienstleis-
direkt bei den Datenbankherstellern statt. Diese integrie- tungen zur Verfügung stellt. Hier können weder Eingriffe
ren neue Techniken in ihre Datenbanken, wenn diese ausrei- in die Datenbanken vorgenommen werden, noch ist dies bei
chend getestet, ausgereift und für eine breite Öffentlichkeit den Anwendungen möglich, da diese den Kunden gehören.
nutzbar und nützlich sind. Selbst einige Spezialgebiete wur-
den bereits abgedeckt, so z. B. die Speicherung und schnelle Aus diesem Grund wollen wir einen Weg schaffen, der sich in
Abfrage von räumlichen Daten mittels Oracle Spacial [17] eben diesen Situationen einsetzen lässt und der dann auch
für andere offensteht. Es soll dabei möglichst erreicht wer-
den, dass das Zusatzmodul, ein Proxy, komplett transparent
in die bestehende Infrastruktur integriert werden kann.
Im nächsten Abschnitt werden wir zunächst auf andere Tech-
niken eingehen, die genutzt werden können, neue Funktio-
nalitäten, speziell Indizes, in Datenbanken einzufügen. An-
schließend werden wir unser Konzept aufzeigen und einige
Spezialfälle diskutieren.
2. STAND DER TECHNIK an dieser Stelle auch alle Funktionen, die angepasst werden,
und deren Seiteneffekte beachtet werden.
2.1 ADT
Klassischerweise können neue Funktionalitäten in Daten-
Beide Verfahren – Plugins und ADTs – haben einen gemein-
banksysteme mittels Stored Procedures und eigenen abstrak-
samen Schwachpunkt: sie müssen immer in die Datenbank
ten Datentypen (ADT) implementiert werden. Die meisten
selbst integriert werden. Ein solcher Eingriff, in die u. U. für
Datenbanksysteme bieten diese Möglichkeiten. [11, 15, 18]
ein Unternehmen kritischen Datenbestände ist, schon allein
Diese Erweiterungsmöglichkeiten sind jedoch begrenzt, da
aufgrund von Sicherheitsbedenken, schwierig bis unmöglich
mit ihnen immer die Ablage der Daten in den vorgegebe-
umzusetzen. Bei einer komplett neuen Datenbank, die erst
nen Strukturen der Datenbank einhergeht. Auch lassen sich
ihren Regelbetrieb aufnehmen muss, ist dieser Weg jedoch
so die internen Abläufe nur schwer beeinflussen. Postgres
gangbar.
bietet beispielsweise die Möglichkeit die verfügbaren Indi-
zes mittels Callback-Funktionen auf den ADT anwendbar
zu machen. Eine komplett neue Indexstruktur lässt sich so 2.3 GreenSQL
allerdings nicht einbauen. Außerdem wird bei einer Anfrage Einen anderen Weg geht das GreenSQL-Projekt. Ziel von
nicht die Selektionsbedingung des WHERE-Teiles mit überge- GreenSQL ist es, eine Datenbank vor schädlichen SQL-Be-
ben. Das bedeutet, dass immer der komplette Tabelleninhalt fehlen zu schützen. Dabei nutzt es auch einen Proxyansatz.
zurückgeliefert werden muss und die Datenbank die Bedin- Die GreenSQL kennt dabei die folgenden Betriebsmodi:
gungen des WHERE-Teiles schließlich selbst auswertet.
• Simulationsmodus: Es findet hierbei kein Eingriff in
2.2 Plugins die Kommunikation statt. Es werden ausschließlich alle
Um nun diese Einschränkungen zu umgehen, wurden tiefer- Anfragen untersucht und bei verdächtigen Anfragen
greifende Möglichkeiten geschaffen, auch eigene Indizes in ein Verantwortlicher informiert.
Datenbanksysteme einzubringen. Allgemein wird diese Mög-
lichkeit auch als „Extensible Indexing“ bezeichnet. Oracle • Blockierung von verdächtigen Anfragen: Hier werden
setzt dies im Datacartridge Framework [5], IBM DB2 mit Heuristiken angewandt, um die eingehenden Anfragen
dem DB2 Extender [19] um. Weitere Ausführungen zu u. a. zu beurteilen. Wird eine Anfrage als „verdächtig“ ein-
Informix DataBlades [20] und GiST [10] sind auch in [1] gestuft, so wird noch in einer Positivliste nachgeschaut,
sowie auf allgemeinerem Niveau in [13] zu finden. ob die Anfrage doch zulässig ist. Ist sie zulässig, so wird
sie an den Datenbankserver weitergeleitet, ansonsten
wird direkt ein leeres Ergebnis zurückgeliefert.
Datenbankerweiterung außerhalb der Datenbank
komplett eigene • Lernmodus: Um nicht auf die Heuristiken angewiesen
Datenverwaltung
zu sein, kann GreenSQL in diesem Modus eine Liste
Pluginschnittstelle zugelassener Anfragen erzeugen.
Bereitstellung von
Zugriffsfunktionen
für Erweiterungen datenbankverwalteter • Schutz vor unbekannten Anfragen: Nachdem alle zuge-
lassenen Anfragen „gelernt“ wurden, werden in diesem
Datenbank Server Bereich
Bereitstellung von Modus alle unbekannten Anfragen blockiert.
− Zugriffskontrolle
− ACID
− SQL Schnittstelle Die Anfragen werden dabei mittels Mustererkennung un-
tersucht. Eine Anfrage wird also nicht geparst und anhand
eines Syntaxbaumes untersucht, was genau bewirkt werden
soll. Damit ist der Nutzen auf Anfragen beschränkt, die kei-
Abbildung 1: Mittels eines Datenbankplugins wie
ne komplexe syntaktische Struktur aufweisen. Des weiteren
hier dargestellt lassen sich neue Funktionen in ei-
ist GreenSQL auf MySQL zugeschnitten. Es kennt die Ta-
ne Datenbank integrieren, insbesondere Indizes (vgl.
bellennamen des Systemkataloges, die sich aber bei anderen
[5]).
Datenbanken zu denen von MySQL unterscheiden.
Diese Pluginschnittstellen ermöglichen es, komplett neben 3. UNSER ANSATZ
der Datenbank Indexfunktionalitäten bereitzustellen und die 3.1 Allgemein
Datenbank so auf eine reine Verwaltungskomponente zu re- Da weder die Datenbank noch die Anwendung angepasst
duzieren. Die Datenbank macht weiterhin die Zugriffskon- werden dürfen, muss also eine externe Lösung angestrebt
trolle, SQL-Auswertung, Transaktionen, gibt dann die ei- werden. In Abbildung 2(a) ist nocheinmal das Ausgangsze-
gentliche Ausführung aber an das Plugin ab. Dieses kann nario dargestellt. Im weiteren werden wir uns auf SQL [6] als
z. B. speziell strukturierte Daten sehr effizient außerhalb der Kommunikationssprache hin zur Datenbank beschränken.
Datenbank vorhalten. Diese Einschränkung ist insofern unkritisch, da die meisten
Datenbanksysteme auf diese Art angesprochen werden und
Neben konkreten Pluginschnittstellen, steht bei Opensource- sich der folgende Ansatz auch auf andere Anfragemöglich-
Projekten auch der Weg des direkten Eingriffes in den Da- keiten übertragen lässt.
tenbankkern offen. Da sich interne Strukturen bei solchen
Projekten allerdings häufig ändern, ist hier der Wartung- Der einzig verbleibende Punkt, um noch etwas zu integrie-
aufwand für eine solche Lösung enorm. Des weiteren müssen ren, ist die Kopplung zwischen Anwendung und Datenbank,
SQL Anwendung Datenbank
Anwendung Datenbank
Antwort
(a) Datenbankhersteller−spezifische Kopplungskomponente
SQL SQL
Anwendung Proxy Datenbank Verwaltungskomponente
Antwort Antwort
(b)
SQL−Parser
Indizierungskomponente
Abbildung 2: Integrationsszenario. In Teil (a) ist
dargestellt, wie sich der bisherige Ablauf bei der
Kommunikation von Anwendung und Datenbank
darstellt. Teil (b) zeigt, wie sich der Proxy einfügt
und die Kommunikation auf ihn umgeleitet wird.
Abbildung 3: Interner Aufbau des Proxys. Der
Proxy besteht im Wesentlichen aus einem SQL-
sprich die Kommunikationsstrecke. Abbildung 2(b) zeigt, Parser, dem eigentlichen Index und einer Verwal-
wie ein solcher Eingriff aussehen könnte. Ein Proxy nimmt tungskomponente, die diese Komponenten mitein-
den Datenverkehr von der Anwendung entgegen und wertet ander koppelt. Um die Datenbankanfragen einzule-
diesen aus. Er miemt also die Datenbank. Zur Beantwortung sen, wird noch eine Datenbankhersteller-spezifische
der Anfrage kann der Proxy trotzdem mit der Datenbank Schnittstelle benötigt.
kommunizieren.
Anschließend wird geprüft, ob der Proxy überhaupt etwas
Es gibt mehrere Möglichkeiten, einen Proxy in eine beste-
mit dieser Anfrage anfangen kann. Im Falle eines Index wer-
hende Systemlandschaft zu integrieren:
den also die Tabellen, auf die sich die Anfrage bezieht, mit
den indizierten Tabellen verglichen. Wenn keine indizierte
• Nicht-transparente Integration, indem der Anwendung Tabelle getroffen wurde, so wird die Anfrage unbehandelt
der Proxy als neuer Datenbankserver mitgeteilt wird. an die Datenbank weitergereicht, von dieser beantwortet und
Im Idealfall ist dies nur ein einziger Eintrag in der An- das Ergebnis an die Anwendung zurückgeliefert.
wendung.
Wird die Anfrage bearbeitet, so muss der SQL-Parser diese
• Ersetzen des Datenbankservers durch den Proxy. Hier- zuerst in Unteranfragen zerlegen. Abbildung 4 zeigt eine sol-
bei übernimmt der Proxy die Adresse des Datenbank- che zerlegte Anfrage, die eine Unteranfrage beinhaltet. Bei
servers und der Datenbankserver bekommt eine neue der Beantwortung muss der Baum, der sich aus dieser Struk-
Adresse zugeteilt. tur ergibt, von den Blättern her zur Wurzel hin abgearbei-
tet werden. Es muss also zunächst die Anfrage „SELECT mid
• Transparentes Einklinken des Proxys. Dabei werden FROM abt WHERE nr = 3“ abgearbeitet werden. Die Ergeb-
auf Netzwerkebene die Datenpakete, die für den Da- nisse dieser Teilanfrage werden dann in den darüberliegen-
tenbankserver bestimmt sind, auf den Proxy umge- den Knoten eingebaut. Sobald alle Kindknoten eines Kno-
leitet (Destination Network Address Translation) [7]. tens abgearbeitet wurden, kann der Knoten selbst bearbeitet
Diese Variante ist vom Anpassungsaufwand für die An- werden.
wendung als auch für den Datenbankserver am gerings-
ten (im Idealfall Null). Dabei ist jedoch zu beachten, 0 SELECT * FROM mitarb WHERE mitarb.id IN ( 1 )
dass es sich hierbei um einen Eingriff in eventuell ver-
trauliche Kommunikation handelt.
1 SELECT mid FROM abt WHERE abt.nr = 3
Ziel soll es sein, die letzte Möglichkeit zu realisieren. Bei ei- Abbildung 4: Anfragebaum für eine kleine geschach-
ner Neuinstallation ist ein neues Indizierungsverfahren, egal telte SQL-Anfrage. Anfrage 1 ist in Anfrage 0 ein-
ob Datenbank intern oder extern, verhältnismäßig einfach zu gebettet, ihre Ergebnisse sind für die Beantwortung
integrieren. Die Integration in bestehende Systemlandschaf- von Anfrage 0 entscheidend.
ten aber gestaltet sich schwierig. Eine transparente Lösung
ist hier die einzig anwendbare.
In eine Anfrage, die Daten aus Unteranfragen benötigt, wer-
3.2 Bearbeitung einer Anfrage den die Ergebnisse dieser Unteranfrage zunächst direkt ein-
Egal für welche Integrationsvariante sich entschieden wur- gesetzt. Im vorigen Beispiel würde also bspw. eine Anfra-
de, im Betrieb sind die Aufgaben der Kernkomponenten des ge wie „SELECT * FROM mitarb WHERE id IN (17,23,42)“
Proxys gleich. Diese Kernkomponenten und ihr Zusammen- erzeugt werden.
spiel sind in Abbildung 3 dargestellt. Sendet die Anwendung
eine Anfrage an die Datenbank, wird diese zunächst von der Im Falle eines Index ist es nicht sinnvoll, jeden Zweig im An-
Verwaltungskomponente des Proxys entgegengenommen. fragebaum zu verfolgen. Es müssen nur Blätter ausgewertet
werden, die auch tatsächlich an einem für den Index aus- eine um den Primärschlüssel id erweiterte Anfrage werden:
wertbaren Vaterknoten direkt oder indirekt angeschlossen
sind.
SELECT * FROM mitarb WHERE gehalt > 2000
AND id IN (4, 18)
Bei der Auswertung eines Anfragebaumes ergibt sich das
in Abbildung 5 dargestellte Kommunikationsschema. Es ist
zu erkennen, dass während der Beantwortung einer Anfrage Problematisch an dieser Lösung kann die begrenzte Länge
u. U. mehrere Anfragen an die Datenbank abgeschickt wer- von SQL-Ausdrücken sein, die eine Datenbank verarbeiten
den müssen, während die Anwendung auf die Antwort war- kann. Für den Fall einer Überschreitung dieser Maximallän-
tet. Dieses Wechselspiel von Proxy und Datenbank kann bei ge muss ein anderer Weg gegangen werden. So können die
entsprechend tief geschachtelten Anfragen sehr lange dau- Ergebnisse, die der Index zurückliefert, in der Datenbank in
ern. Es muss noch untersucht werden, bis zu welcher Tiefe eine seperate, temporäre Tabelle eingefügt werden. Die neue
sich die Ausführung der Auflösung tatsächlich lohnt und ab SQL-Anfrage hätte dann die Form:
wann die gesamte Anfrage direkt an die Datenbank weiter-
geleitet werden sollte.
SELECT * FROM mitarb WHERE gehalt > 2000
AND id IN (SELECT * FROM temp_tabelle)
Anwendung Proxy Datenbank
Anfrage
4. AUSBLICK
Das beschriebene Verfahren befindet sich noch in Entwick-
Verarbeitung lung. Von den vorgestellten Komponenten wurde der SQL-
Anfrage
Parser umgesetzt. Ein weiterer Punkt, das Verändern von
Verarbeitung SQL-Anfragen, stellt eine Herausforderung dar, da die Über-
Antwort tragungswege von und zu den Datenbanken herstellerab-
Verarbeitung hängig sind. Erste Tests zeigten Prüfsummen, die sich al-
Anfrage lerdings nur auf die Länge der Anfrage bezogen. Eine Ver-
änderung wurde erfolgreich vorgenommen. Dieser Punkt ist
Verarbeitung
Antwort allerdings ein weites Feld und wir werden uns zunächst auf
eine Schnittstelle festlegen, im speziellen auf das Oracle Call
Verarbeitung
Antwort Interface (OCI) [16].
Auch muss die Leistungsfähigkeit der beschriebenen Verän-
derungsverfahren noch untersucht werden. Anfängliche Tests
Idle Warten Arbeiten mit manueller Erweiterung der Anfragen zeigten bereits Ge-
schwindigkeitssteigerungen.
Abbildung 5: Kommunikationsschema. Die Abbil- Der entwickelte Proxy kann prinzipiell nicht nur einen da-
dung zeigt das Kommunikationsverhalten der ein- tenbankexternen Index ermöglichen. Er erlaubt auch eine
zelnen Teilnehmer. Zu bemerken ist, dass nicht jede Fülle anderer Funktionen. So kann er dazu genutzt wer-
Anfrage der Anwendung auch nur eine Anfrage des den, Antworten auf Anfragen an die Datenbank zwischen-
Proxys bei der Datenbank bedingt, sondern auch zuspeichern, er kann Adapterfunktionen zu anderen SQL-
eine Reihe solcher Anfragen an die Datenbank aus- Dialekten oder zu ganz anderen Anfrageparadigmen sein.
lösen kann. Diese stehen nicht im direkten Fokus der Arbeit, sollen aber
definitiv evaluiert werden.
Ein Index muss nicht die Daten selbst, sondern nur Identifi- 5. LITERATUR
katoren speichern, die einzelne Datensätze eindeutig identi- [1] R. Acker, R. Pieringer, and R. Bayer. Towards Truly
fizieren. Sein Ergebnis sind also idealerweise Primärschlüs- Extensible Database Systems. In K. Andersen,
sel der eigentlichen Tupel in der Datenbank. Werden einer J. Debenham, and R. Wagner, editors, DEXA 2005,
Datenbank die Tupelidentifikatoren (TIDs) der gesuchten pages 596–605. Springer-Verlag Berlin Heidelberg,
Datensätze mitgeteilt, kann diese sie sehr schnell finden. Es 2005.
kann allerdings vorkommen, dass die von einem Index zu- [2] D. W. Adler. DB2 Spatial Extender - Spatial data
rückgelieferten Ergebnisse unscharf, es also zu viele sind. within the RDBMS. In VLDB ’01: Proceedings of the
Deshalb müssen alle WHERE-Bedingungen der originalen An- 27th International Conference on Very Large Data
frage erhalten bleiben. Bases, pages 687–690, San Francisco, CA, USA, 2001.
Morgan Kaufmann Publishers Inc.
Eine Möglichkeit der Datenbank, die Ergebnisse eines Index [3] R. Ahuja. DB2 9 Unveiled: Overview and New
mitzuteilen, ist die Erweiterung der ursprünglichen Anfra- Enhancements. IBM Software Group, July 2006.
ge um seine Ergebnisse. Zum Beispiel kann so aus einem [4] M. M. Astrahan, M. W. Blasgen, D. D. Chamberlin,
einfachen K. P. Eswaran, J. N. Gray, P. P. Griffiths, W. F. King,
R. A. Lorie, P. R. McJones, J. W. Mehl, G. R.
Putzolu, I. L. Traiger, B. W. Wade, and V. Watson.
SELECT * FROM mitarb WHERE gehalt > 2000 System R: relational approach to database
management. ACM Trans. Database Syst.,
1(2):97–137, 1976.
[5] E. Belden, T. Chorma, D. Das, Y. Hu, S. Kotsovolos,
G. Lee, R. Leyderman, S. Mavris, V. Moore, M. Morsi,
C. Murray, D. Raphaely, H. Slattery, S. Sundara, and
A. Yoaz. Oracle Database Data Cartridge Developers
Guide, 11g Release 2 (11.2). Oracle, July 2009.
[6] D. D. Chamberlin and R. F. Boyce. SEQUEL: A
structured English query language. In SIGFIDET ’74:
Proceedings of the 1974 ACM SIGFIDET (now
SIGMOD) workshop on Data description, access and
control, pages 249–264, New York, NY, USA, 1974.
ACM.
[7] K. B. Egevang and P. Francis. RFC 1631 – The IP
Network Address Translator (NAT). Cray
Communications, NTT Software Lab, May 1994.
[8] R. L. Gilliam. The State of IMS. IBM Corporation,
Department DQZA, Route 100 Box 100, Sommers
NY, USA, 06877, Apr. 2005.
[9] A. Guttman. R-trees: a dynamic index structure for
spatial searching. In SIGMOD ’84: Proceedings of the
1984 ACM SIGMOD international conference on
Management of data, pages 47–57, New York, NY,
USA, 1984. ACM.
[10] J. M. Hellerstein, J. F. Naughton, and A. Pfeffer.
Generalized Search Trees for Database Systems. In
VLDB ’95: Proceedings of the 21th International
Conference on Very Large Data Bases, pages 562–573,
San Francisco, CA, USA, 1995. Morgan Kaufmann
Publishers Inc.
[11] IBM. SQL Reference, Volume 1. IBM Corporation,
Nov. 2009.
[12] IBM Deutschland GmbH. DB2 Spatial Extender und
Geodetic Data Management Feature – Benutzer- und
Referenzhandbuch, July 2006.
[13] H.-P. Kriegel, M. Pfeifle, M. Pötke, and T. Seidl. The
Paradigm of Relational Indexing: A Survey. In
Proceedings of the 10th Conference on Database
Systems for Business, Technology, and the Web
(BTW’03), GI-Edition Lecture Notes in Informatics,
pages 285–304, Leipzig, Deutschland, 2003.
[14] K. Loney. Oracle Database 11g The Complete
Reference. McGraw-Hill, Inc., New York, NY, USA,
2009.
[15] D. Lorentz and M. B. Roeser. Oracle Database SQL
Language Reference, 11g Release 2 (11.2). Oracle,
Oct. 2009.
[16] J. Melnick. Oracle Call Interface Programmer’s
Guide, 11g Release 2 (11.2). Oracle, Oct. 2009.
[17] C. Murray. Oracle Spatial Developers Guide, 11g
Release 2 (11.2). Oracle, Dec. 2009.
[18] The PostgresSQL Global Development Group.
PostgreSQL 8.4.3 Documentation, 2009.
[19] K. Stolze and T. Steinbach. DB2 Index Extensions by
example and in detail, IBM Developer works DB2
library. Dec. 2003.
[20] M. Ubell. The Montage extensible DataBlade
architecture. SIGMOD Rec., 23(2):482, 1994.