Untersuchung und Bewertung zur Interoperabilität von Geodaten in räumlichen Datenbanken

Inhaltsverzeichnis

1 Einführung

2 Datenbanken
2.1 Ansätze zur Datenhaltung
2.1.1 Datei- oder Filesystem
2.1.2 Relationale Datenbank
2.1.3 Objektorientierte Datenbank
2.1.4 Objektrelationale Datenbank
2.2 Ansätze zur räumlichen Datenhaltung
2.2.1 Datei
2.2.2 BLOB
2.2.3 Relationaler Ansatz
2.2.4 Objektorientierter Ansatz
2.2.5 Objektrelationaler Ansatz
2.2.6 Vergleich der Ansätze
2.3 Indizierung
2.3.1 B-Baum
2.3.2 R-Baum
2.3.3 Quadbaum
2.3.4 Vergleich der Indizierungen
2.4 Informixâ Dynamic Server 2000
2.4.1 Allgemeine Einführung
2.4.2 Installation
2.4.3 Administration
2.4.4 Schnittstellen
2.4.5 DataBlade Technologie
2.4.6 Informix Spatial DataBlade Module
2.4.7 Räumliche Datentypen
2.4.8 Räumliche Metadatentabellen
2.4.9 Indizierung
2.5 Microsoft SQL Server 2000
2.5.1 Strategie
2.5.2 Allgemeine Einführung
2.5.3 Editionen
2.5.4 Installation
2.5.5 Administration
2.5.6 Schnittstellen
2.5.7 Datentypen
2.5.8 Indizierung
2.6 Oracle 9i
2.6.1 Installation
2.6.2 Administration
2.6.3 Schnittstellen
2.6.4 Räumliche Datentypen
2.6.5 Räumliche Indizierung
2.7 Vergleich der Datenbanken
2.7.1 Vergleich zwischen Informix, SQL Server und Oracle 9i
2.7.2 Vergleich zwischen SQL Server und Access

3 GI-Systeme
3.1 MapInfo Professional 6.5
3.1.1 Anbindung an Informix
3.1.2 Anbindung an SQL Server
3.1.3 Anbindung an Oracle
3.1.4 Vergleich der Anbindungen von MapInfo
3.2 GeoMedia Professional 4.0
3.2.1 Anbindung an SQL Server
3.2.2 Anbindung an Oracle
3.2.3 Vergleich der Anbindungen von GeoMedia
3.3 ArcView 3.2/ArcSDE 8.1
3.3.1 Anbindung an Informix
3.3.2 Anbindung an SQL Server
3.3.3 Anbindung an Oracle
3.3.4 Vergleich der Anbindungen von ArcView/ArcSDE

4 Vergleich der Anbindung der GI-Systeme an die Datenbanken
4.1 Informixâ Dynamic Server 2000
4.2 Microsoft SQL Server 2000
4.3 Oracle 9i

5 Interoperabilität
5.1 Szenarien
5.2 Interoperabilität über mehrere Datenbanksysteme

6 Bewertung/Fazit

7 Anhang
7.1 Fehlerbeschreibung Anbindung MapInfo an Informix

8 Verzeichnisse
8.1 Abkürzungsverzeichnis
8.2 Abbildungsverzeichnis
8.3 Tabellenverzeichnis
8.4 Quellenverzeichnis
8.4.1 Literatur
8.4.2 Internet

9 CD zur Diplomarbeit

1 Einführung

Geodaten, bei welchen es sich um räumliche Daten handelt, liegen heutzutage in einer Vielzahl von digitalen Vektorformaten vor. Diese können von verschiedenen GI-Systemen gelesen werden. Somit besteht die Möglichkeit, die Daten zu visualisieren, zu analysieren oder auch zu verändern. Die räumlichen Daten werden als einzelnes File auf dem Sekundärspeicher (Festplatte) gespeichert. Mittlerweile hat sich allerdings als nicht zu übersehende Alternative die Speicherung der räumlichen Daten in Datenbanken kommerzieller Anbieter entwickelt. Vorhandene GI-Systeme können nun direkt an die Datenbanken angebunden werden, um räumliche Daten zu lesen und zu schreiben. Wünschenswert wäre es nun, dass GI-Systeme von verschiedenen Anbietern auf ein und denselben räumlichen Datenbestand in der Datenbank zugreifen könnten und diesen gemeinsam visualisieren, analysieren und verändern können. Dieses gemeinsame Bearbeiten der räumlichen Daten steht in direktem Zusammenhang mit dem Begriff der Interoperabilität. Hierzu eine Definition des Begriffes:

„Interoperabilität bezeichnet die Möglichkeit, verschiedenartige Daten in einem einzelnen Arbeitsablauf zu integrieren. Dies setzt voraus, dass Syntax und Semantik der Daten dem Anwender in einheitlicher Form zur Verfügung gestellt werden. Interoperabilität erlaubt den transparenten Zugang zu mehreren raumbezogenen Daten- und Verarbeitungsressourcen innerhalb eines einzigen Arbeitsablaufes, ohne sie in einen Datenbestand zu überführen.“ ([Bil99])

Wäre eine Interoperabilität zwischen vorhandenen GI-Systemen und Datenbanksystemen möglich, so ergeben sich erhebliche Einsparungspotenziale, da räumliche Daten nicht doppelt erfasst werden müssen und auch ein wesentlich beschleunigter Workflow in vielen Bereichen des Handels, der Industrie und der öffentlichen Hand möglich wäre, da räumliche Daten zentral und ohne Informationsverluste bearbeitbar sind. Darüber hinaus kommt es zu einer erheblichen Beschleunigung des Wachstums des Geodatenmarktes. Eine Untersuchung der Ansätze und die Bewertung zur Interoperabilität von Geodaten in räumlichen Datenbanken soll in dieser Diplomarbeit erfolgen.

In Kapitel 2 werden dazu bereits bestehende Ansätze zur Speicherung räumlicher Daten in Datenbanken erläutert und verglichen. Ein Vergleich findet auch mit der bestehenden Speicherung als File auf Sekundärspeichern statt. Daran anschließend werden die durch die Speicherung in Datenbanken möglichen räumlichen Indizierungen erklärt und verglichen. Somit lassen sich Anfragen an den räumlichen Datenbestand beschleunigen. Nach diesen allgemeinen, eher theoretischen Grundlagen, werden die drei Datenbanksysteme Informix Dynamic Server, Microsoft SQL Server und Oracle 9i als Möglichkeit zur Speicherung räumlicher Daten vorgestellt. Dabei wird neben der Installation, der Administration und den Schnittstellen der Datenbank besonders auf vorhandene Ansätze zur Haltung und Indizierung von räumlichen Daten eingegangen. Abschließend folgt ein ausführlicher Vergleich mit den Vor- und Nachteilen der drei Datenbanksysteme.

Kapitel 3 gibt eine Einführung in die drei GI-Systeme MapInfo Professional 6.5, Geomedia Professional 4.0 und ArcView3.2/ArcSDE 8.1. Es wird die Anbindungen der GI-Systeme an die Datenbanken beschrieben und analysiert. Dabei wird primär auf die Unterstützung vorhandener Ansätze zur Speicherung der räumlichen Daten in den Datenbanksystemen und deren räumlichen Indizierungen eingegangen. Bei einigen GI-Systemen erfolgen diesbezüglich auch eigene Implementierungen, die über die vorhandenen Möglichkeiten der Datenbanksysteme hinausgehen. Abschließend zu jedem GI-System erfolgt ein Vergleich zwischen den realisierten Anbindungen an die Datenbanksysteme. Kapitel 4 baut auf die im vorherigen Kapitel erläuterten Anbindungen auf. Hier werden die Anbindungen allerdings nicht von der GI-Systemseite, sondern aus der Datenbanksicht betrachtet. Zu jedem der in Kapitel 2 vorgestellten drei Datenbanksysteme erfolgt ein ausführlicher Vergleich der realisierten Anbindungen, die in Kapitel 3 vorgestellt wurden.

Kapitel 5 beschäftigt sich mit Überlegungen zur Realisierung von Interoperabilität zwischen den in Kapitel 3 beschriebenen Anbindungen. Es werden Szenarien aufgestellt und diskutiert, die es ermöglichen, räumliche Daten durch direkte Anbindung zwischen verschiedenen GI-Systemen, verschiedenen Datenbanken auszutauschen und zu bearbeiten.

In Kapitel 6 erfolgte eine abschließende Bewertung und ein Fazit zu den bestehenden Möglichkeiten zur Interoperabilität von Geodaten in räumlichen Datenbanken.

2 Datenbanken

Datenbanken haben die Aufgabe, Daten zu speichern, diese effizient zu verwalten und zu benutzen. In diesem Kapitel sollen die im Laufe der Zeit entstandenen verschiedenen Ansätze zur Realisierung einer Datenbank erläutert werden. Darauf aufbauend erfolgte Umsetzungen zur Speicherung von räumlichen Daten. Anschließend folgen die auch für räumliche Daten wichtigen Datenbankobjekte Indizes. Des weiteren werden die drei Datenbankprodukte Informix, SQL Server und Oracle vorgestellt und abschließend erfolgt ein Vergleich derselben.

2.1 Ansätze zur Datenhaltung

Allgemein wird zwischen sechs fundamentalen Ansätzen unterschieden, um Daten zu halten bzw. zu verwalten:

- Datei- oder Filesystem
- Hierarchische Datenbank
- Netzwerkdatenbank
- Relationale Datenbank
- Objektorientierte Datenbank
- Objektrelationale Datenbank

Jeder Ansatz hat seine eigenen Stärken, der ihn somit für bestimmte Datenbankaufgaben zweckmäßig erscheinen lässt. Die aufgeführten Ansätze werden, mit Ausnahme der hierarchischen Datenbank und Netzwerkdatenbank, da diese zur Speicherung von räumlichen Daten nicht von Interesse sind, im folgenden beschrieben.

2.1.1 Datei- oder Filesystem

Datei- oder Filesysteme kamen Anfang der 60er Jahre auf. Die Daten wurden in elementaren Dateien abgelegt und die Verwaltung der Daten übernahm direkt die Anwendung. Somit ergaben sich verschiedene Nachteile. Die Datenorganisation war geräteabhängig und zwangsweise redundant, da nicht alle Daten zentral abgespeichert wurden und somit entstanden leicht inkonsistente Datenbestände. Siehe hierzu auch die Abb. 2-1 auf Seite 7.

2.1.2 Relationale Datenbank

Nach den Dateisystemen kamen die relationalen Datenbanksysteme auf, welche derzeit auf dem Markt der Datenbanken den größten Marktanteil besitzen. Als Beispiele seien Oracle, DB2, Informix, Microsoft SQL Server und Sybase genannt.

Die Daten werden bei relationalen Datenbanken mengenorientiert in Form einer Tabellenstruktur, in der alle Datentypen und Beziehungen definiert werden, in Tabellen (Relationen) gespeichert. Für eine ausführliche Einleitung in Relationen siehe [Hei01]. Kennzeichen dieser Datenbanken ist, dass sie eine Drei-Ebenen-Architektur nach dem ANSI-SPARC Modell besitzen. Dadurch ist eine strikte Trennung von Daten (auf der Festplatte), Datenlogik (Verwaltung übernimmt das Datenbankmanagementsystem (DBMS)) und Anwendungslogik (z. B. GIS-Client) gewährt. Außerdem existiert eine einheitliche Datenbanksprache zur Definition, Abfrage und Manipulation der Daten (z. B. SQL), eine Einbettung dieser Sprache in kommerzielle Programmiersprachen (SQLJ), kontrollierter Mehrbenutzerbetrieb sowie Datensicherheitsmechanismen.

Relationale Datenbanken sind optimiert auf schnelle, kurzlaufende Abfragen und Transaktionen für folgende einfache Datentypen:

- Integer
- Float
- Character, String
- Datum und Uhrzeit, Zeitintervall

Einige relationale Datenbanken besitzen darüber hinaus noch eine beschränkte Unterstützung für komplexe Datentypen. Diese werden in sogenannten „simple large objects“ gespeichert. Dies sind reine Text- bzw. Byte-Typen, bei denen weder eine Indizierung, Suchalgorithmen noch Manipulationen durch das Datenbankmanagementsystem (DBMS) möglich sind. Sie sind ähnlich denen in 2.2.2 aufgeführten BLOB und CLOB.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2-1: Datei- oder Filesystem

2.1.3 Objektorientierte Datenbank

Objektorientierte Datenbankmanagementsysteme sind kommerziell seit 1987 verfügbar. Ihr Marktanteil ist im Vergleich zu relationalen Datenbanken verschwindend gering. Entstanden sind diese aus einer Zusammenführung der Konzepte von Datenbanken und objektorientierten Programmiersprachen (z. B. Java, C#, C++).

Eine objektorientierte Datenbank erweitert die klassische relationale Datenbank um komplexe Datentypen, die mit Typkonstruktoren wie set of, tuple of und list of beschrieben werden können. Außerdem bekommt jedes Objekt eine Objektidentität (object identifier). Somit ist es möglich vorhandene Objekte von ihren Werten, die sie besitzen, zu unterscheiden. Letztendlich ist auch eine Vererbung der Attribute der existierenden Objekte möglich. Manche objektorientierte Datenbanken beherrschen auch höhere objektorientierte Konzepte wie z. B. Metaklassen (in Java mit abstrakten Klassen bezeichnet), Methoden, die auf Objekten und ihren Attributen operieren, Vererbung und Überschreiben von Methoden sowie Kapselung.

2.1.4 Objektrelationale Datenbank

Objektrelationale Datenbanken sind der neueste Ansatz zur Haltung von großen Datenbeständen. Sie versuchen die Vorteile von relationalen und objektorientierten Datenbanken zu vereinigen sowie die Nachteile weitestgehend auszuschalten. Daher bieten sie fortgeschrittene Unterstützung für komplexe Datentypen, die in sogenannten „smart large objects“ gespeichert werden. Diese werden auch BLOB (Binary Large Object) bzw. CLOB (Character Large Object) genannt.

Darüber hinaus erlauben sie die Definition von eigenen Datentypen als Kombination aus einfachen Datentypen, bereits definierten Datentypen. Diese eigenen Datentypen werden „User Defined Type“ (UDT) genannt. UDT’s können auch durch Vererbung und Ergänzung bereits bestehender UDT’s erzeugt werden. Außerdem ist es möglich, eigene Funktionen zu entwickeln, die auf diesen UDT’s arbeiten. Diese Funktionen sind mit Methoden aus objektorientierten Programmiersprachen vergleichbar. Es gibt z. B. spezielle UDT’s für die Arbeit mit 2D und 3D-Bildern, Musik, Video, elektronische Dokumente, HTML-Seiten und räumlichen Daten. Auf UDT’s für räumliche Daten wird sowohl in 2.4.7 als auch in 2.6.4 noch genauer eingegangen. Ebenfalls bekommen instanzierte Objekttypen vom DBMS eine systemweite eindeutige Objektidentität zugewiesen. Insgesamt gesehen ermöglichen objektrelationale Datenbanksysteme bessere Speicher- und Manipulationsmöglichkeiten für komplexe Datenstrukturen als relationale Datenbanksysteme.

([Heu00], [Inf99a], [Orf99])

2.2 Ansätze zur räumlichen Datenhaltung

Nachdem die einzelnen Ansätze zur Haltung von Daten erläutert wurden, werden nun darauf aufbauend verschiedene Umsetzungen zur Speicherung von räumlichen Daten beschrieben. Diese Datenbanken werden dann räumliche Datenbanken genannt. Unter räumlichen Daten werden Geometrien verstanden, welche in der Regel in einer Vektorform vorliegen. Oftmals sind mit diesen noch Sachattribute verknüpft, welche gemeinsam gespeichert werden können. Bei sämtlichen nun folgenden Umsetzungen wird davon ausgegangen, dass die Geometrien in Vektorform vorliegen. Dies hat einige Vorteile im Vergleich zu einem Rasterformat, u. a. erweiterte Abfragemöglichkeiten, höhere Datenkompressionen, leichte Überführung in andere Koordinatensysteme.

2.2.1 Datei

Am Anfang wurden räumliche Daten einfach in einem herstellerspezifischen oder neutralen Austauschformat (z. B. EDBS) auf die Festplatte geschrieben. Diese Datenhaltung ist heutzutage noch in allen gängigen GI-Systemen implementiert. Jedes GI-System speichert dabei seine räumlichen Daten in seinem eigenen herstellerspezifischen Dateiformat. Teilweise können die GI-Systeme auch Dateiformate von anderen GI-Systemen lesen und speichern.

2.2.2 BLOB

Der älteste Ansatz zur Speicherung räumlicher Daten in einer Datenbank ist der durch einen BLOB. Beim BLOB werden die räumlichen Daten einfach in einer langen Zeichenkette abgelegt. Um nun die Daten lesen bzw. schreiben zu können, muss der genaue Aufbau der Zeichenkette bekannt sein, der in der Regel herstellerspezifisch ist. Theoretisch lässt sich der BLOB in jedem beliebigen Datenbanksystem realisieren. In der Praxis ist er allerdings meistens in einer relationalen Datenbankumgebung implementiert worden. Hierbei bekommt der BLOB eine Spalte einer Relation zugewiesen, in denen dann die Geometrien abgelegt werden, während andere Spalten für Sachattribute der Geometrien dienen können. Nachfolgend ist die Realisierung in einer relationalen Datenbank dargestellt:

Relation Flurstücke

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2-2: BLOB in einer relationalen Datenbank

Die Relation Flurstücke enthält zwei Attribute. Zum einen das Sachattribut Flurstücksnummer und zum anderen das Attribut Geometrie, welches vom Datentyp BLOB ist. In Abb. 2-2 wird der Aufbau des BLOBs angedeutet. Zu dem Flurstück mit der Nr. 115 gehört z. B. der Punkt 112 mit der X-Koordinate 123.017. Um nun mit einzelnen Koordinatenwerten rechnen zu können, muss die Zeichenkette in Teilketten zerlegt werden. In manchen Datenbanksystemen wird zwischen den Datentypen CLOB (Character Large Object) und BLOB unterschieden. Ein BLOB besteht aus einer Kette von Bytes, während ein CLOB aus einer Kette von Zeichen besteht. In den meisten Sprachen, abgesehen von fernöstlichen Sprachen, wird für ein Zeichen zur Darstellung lediglich ein Byte benutzt. In diesem Fall sind BLOB und CLOB identisch, weshalb in dieser Diplomarbeit BLOBs und Zeichenketten oftmals gleichgesetzt werden. Ebenfalls ist zu beachten, dass BLOB sowohl für den Ansatz an sich als auch den Datentyp stehen kann. Dies ist aus dem jeweiligen Kontext ersichtlich.

2.2.3 Relationaler Ansatz

Nach dem BLOB kam der relationale Ansatz zur Speicherung räumlicher Daten auf. Bei ihm liegt der Gedanke zu Grunde, die Geometrie aus der herstellerspezifischen Zeichenkette des BLOB herauszuholen und explizit zusammen mit Metainformationen der räumlichen Daten in Relationen zu speichern. Wie die Geometrien genau in der Relation abgelegt werden sollen, wurde vom OGC (Open GIS Consortium) in der Simple Feature Specification festgelegt. Weitere Informationen zum OGC und zur Simple Feature Specification finden sich in der Arbeit von [Bla01]. Zur Verdeutlichung der Umsetzung ein Beispiel:

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2-3: relationaler Ansatz

Das Flurstück in Abb. 2-3 mit der Nummer 115 setzt sich aus den Punkten P1-P4 zusammen. Die dazugehörige Relation SDOGEOM sieht nun folgendermaßen aus. Das Attribut SDO_GID gibt die Objektidentifikation an, die Flurstücksnummer. SDO_SEQ ist ein fortlaufender Index für das aktuelle Objekt, hier ein Polygon. In den Attributen SDO_X1, SDO_Y1, SDO_X2 und SDO_Y2 sind die eigentlichen Koordinaten gespeichert. In diesem Beispiel definieren zwei Koordinatenpaare immer eine Linie und in der letzten Zeile wird das Polygon geschlossen.

2.2.4 Objektorientierter Ansatz

Ein rein objektorientierter Ansatz wird auf einer objektorientierten Datenbank realisiert. Dabei ist es leicht möglich, komplexe Objekte und ihre Beziehungen in der Datenbank abzubilden. Jede Geometrie kann durch eine eigene Klasse modelliert werden. Spezielle Geometrien können die Eigenschaften von den grundlegenden Geometrien erben und diese durch eigene spezielle erweitern. Als Beispiel sei hier die grundlegende Geometrie Linienzug genannt. Eine spezielle Geometrie könnte ein Rechteck sein, welches sämtliche Attribute von Linienzug erbt und z. B. durch das Attribut Fläche erweitert. Jedoch gibt es zur Zeit weder einen anerkannten Standard, noch kommerzielle Produkte. Bisher wurden lediglich verschiedene Prototypen realisiert.

2.2.5 Objektrelationaler Ansatz

Der objektrelationale Ansatz ist der neueste der genannten Ansätze. Bei ihm werden die Techniken eines objektrelationalen Datenbanksystems genutzt. Dazu wird ein neuer räumlicher Objekttyp geschaffen. Dieser allgemeine räumliche Objekttyp kann Punkte, Linien, Polygone oder homogene und heterogene Sammlungen dieser drei Grundtypen enthalten. Um dies zu verwirklichen besitzt er mehrere Attribute. In einem der Attribute werden die Koordinaten gespeichert. Die eigentlichen Koordinaten werden also nicht wie im relationalen Ansatz direkt in der Relation gespeichert, sondern in einem benutzerdefinierten räumlichen Objekttyp, der entweder als Attribut einer Relation abgelegt werden kann oder direkt in einer reinen Objekttabelle des räumlichen Objekttyps. Der Aufbau der Geometrien wurde ebenfalls vom OGC in der Simple Feature Specification festgelegt. Für eine ausführliche Beschreibung des objektrelationalen Ansatzes sei auf die Arbeit von [Hei01] verwiesen.

2.2.6 Vergleich der Ansätze

Bei einem Vergleich der Ansätze besitzen die letzten vier Modelle, welche die Daten mit Hilfe eines Datenbankmanagementsystems speichern, mehrere Vorteile gegenüber des ersten Ansatzes, der die Speicherung als File auf der Festplatte vorsieht.

Durch die Datenbank wird eine Redundanzfreiheit ermöglicht, d. h. die Daten liegen jeweils nur einmal vor und sind nicht mehrfach auf verschiedenen GIS-Clients verteilt. Somit ist auch die Datenintegrität leichter zu gewährleisten. Ein weitere Vorteil ist der mögliche Mehrbenutzerbetrieb mit Benutzerkontrollen. Von verschiedenen GIS-Clients kann somit kontrolliert auf ein und denselben Datenbestand zugegriffen werden. Durch die strikte Trennung zwischen Daten (auf der Festplatte), Datenlogik (in der Datenbank selbst) und Anwendungslogik (GIS-Programm) ist eine beliebige Kombination dieser Schichten theoretisch möglich. Wie dies aussehen könnte, wird in Kapitel 5 erläutert. Ebenfalls können in der Datenbank bereits Objekte zur Abfrage von Überlappung, Berührung etc. implementiert werden. Diese Objekte werden je nach Datenbanksystem Methode, Prozedur oder Funktion genannt.

Wird der BLOB bewertet, so ist festzustellen, dass beim BLOB die Geometrie in einem Attribut abgelegt wird und somit gekapselt ist. Allerdings gestaltet es sich sehr umständlich einzelne Punkte auszulesen, was durch die nicht mögliche Indizierung (siehe 2.3) noch verstärkt wird. Somit kommt es zu einer schlechten Performance. Außerdem werden die Daten herstellerspezifisch abgelegt.

Beim relationalen Ansatz überzeugt, dass dieser von allen relationalen Datenbanksystemen implementiert werden kann, was auf Grund der großen Verbreitung dieser Systeme ein Vorteil ist. Außerdem ist eine Performancesteigerung mittels räumlicher Indizierung möglich. Nachteil ist die nur geringe Realisierung von Geometrietypen und die geringe Kapselung der Daten.

Mit dem objektorientierten Ansatz ist es wesentlich einfacher, Geometrien bzw. ihre Beziehungen zueinander abzubilden, als dies mit einem relationalen Ansatz auf Relationen der Fall ist. Allerdings steigt hierbei auch die Komplexität der gespeicherten Daten, was ab einer gewissen Datenmenge zu erheblichen Performanceproblemen führt. Ein weiterer Nachteil ist auch die fehlende Standardisierung beim objektorientierten Ansatz. Eine Möglichkeit der Standardisierung wäre eine Anlehnung an das objektorientierte Modell von GML (Geography Markup Language), eine auf XML basierende Beschreibungssprache für Geodaten. Näheres zu GML siehe [Klü02].

Vorteil des objektrelationalen Ansatzes ist die Kapselung der Geometrie in einem Objekttyp. Somit können in einer Tabelle sowohl räumliche als auch weitere Sachinformationen gespeichert werden. Außerdem wird dieser Ansatz durch räumliche Indizes unterstützt, was eine Performancesteigerung zur Folge hat. Ein gewichtiger Vorteil gegenüber dem relationalen Ansatz ist, dass dieser beliebige Geometrietypen unterstützt und auch räumliche Operationen auf den Objekten durchgeführt werden können. Als Nachteil des Ansatzes erweißt sich, dass die Einfachheit des relationalen Systems beim Aufbau als auch bei Abfragen nicht vorhanden ist.

Zusammenfassend lässt sich feststellen, dass BLOBs in allen gängigen relationalen und objektrelationalen Datenbanksystemen realisiert worden sind, sie dürften aber auf Grund der Vorteile von relationalem bzw. vor allem objektrelationalen Ansatz mit der Zeit ganz verschwinden. Der relationale Ansatz wird mittlerweile von den Datenbanksystemen nicht mehr unterstützt. Zu empfehlen ist es, wenn mit vertretbarem Aufwand möglich, bestehende Realisierungen auf den objektrelationalen Ansatz zu überführen, da dieser von der Unterstützung und auch sowohl im Hinblick auf Performance als auch Interoperabilität am besten geeignet ist. Der objektorientierte Ansatz ist theoretisch ein sinnvoller Ansatz, allerdings ist zur Zeit noch keine vernünftige Marktdurchdringung gegeben, weswegen hiervon noch abzuraten ist. ([Ost02])

2.3 Indizierung

Ein wichtiges Datenbankobjekt in Bezug auf räumliche Daten sind Indizes. Aus diesem Grund ist der Indizierung auch ein eigener Unterabschnitt gewidmet. Wozu werden überhaupt Indizierungen benötigt?

Besonders bei räumlichen Daten liegen große Datenmengen vor. Würde nun in dieser großen Datenmenge ein einzelnes Geometrieobjekt bei einer räumlichen Anfrage gesucht werden, so müsste der gesamte Datenbestand sequentiell vom ersten bis zum letzten Geometrieobjekt durchsucht werden (full table scan), was sehr zeitaufwendig wäre. Um diese Anfrage zu beschleunigen, wird ein Index in gesonderten Tabellen angelegt. Ein Index kann als ein sortiertes Verzeichnis des zugrunde liegenden Datenbestandes betrachtet werden. Ein Index basiert dabei auf einer oder mehreren Spalten einer Tabelle, Sicht. Durch einen Index müssen nur noch relevante Objekte gelesen werden.

Zur Indizierung von räumlichen Daten wird sowohl der R-Baum als auch der Quadbaum benutzt. In den nachfolgenden Abschnitten wird zuerst der B-Baum erklärt, danach der R-Baum, dann der Quadbaum sowie abschließend ein Vergleich der Indizierungen.

2.3.1 B-Baum

B-Bäume sind in den meisten Datenbanksystemen implementiert. In diesem Abschnitt wird der prinzipielle Aufbau eines B-Baumes erklärt und auf eine Variante, den B+-Baum, eingegangen.

Ausgangspunkt bei Baum-Indizes, zu denen auch der später noch vorgestellte R-Baum gehört, ist ein sortierter Suchbaum. Über diesen Suchbaum ist es möglich, nach bestimmten Zeilen der Tabelle über das indizierte Attribut zu suchen. Der Baum besteht dabei aus Knoten und Blättern. Zeiger auf die eigentlichen Datensätze bzw. die Datensätze selbst der indizierten Tabelle sind sowohl in den Knoten als auch in den Blättern enthalten. Ein ausgeglichener oder balancierter Baum bedeutet, dass der Weg von der Wurzel bis zu den Blättern in allen Teilästen gleich lang ist. B-Bäume sind sowohl als Primär- als auch Sekundärindex geeignet. Primärindizes können die interne Speicherstruktur des Sekundärspeichers (Festplatte) ausnutzen und werden meistens über Primärschlüsselattributen definiert. Sekundärindizes dagegen stellen einen weiteren Zugriffspfad auf die Daten dar.

Für das Einfügen und Löschen existieren verschiedene Algorithmen, um den Baum balanciert zu halten. Das Suchen in B-Bäumen erfolgt nach einem einfachen Muster. Gestartet wird in der Wurzel des Baumes. Dort findet ein Vergleich mit dem zu suchenden Datensatz statt. Ist dieser ungleich des Datensatzes, auf den der Zeiger der Wurzel zeigt, so fährt der Algorithmus, je nachdem ob der zu suchende Datensatz kleiner oder größer des vergleichenden Datensatzes ist, im linken oder rechten Teilbaum fort. Bei mehrfach abgehenden Teilbäumen erfolgt ein verschachtelter Vergleich. Ansonsten wurde der Datensatz in der Wurzel bzw. dem aktuellen Knoten bereits gefunden. In dem nun folgenden Knoten findet wieder ein Vergleich statt und gegebenenfalls wird in den entsprechenden Teilbaum verzweigt. Dies geschieht solange, bis ein Blatt erreicht ist. Enthält auch dieses Blatt nicht den Zeiger auf den gesuchten Datensatz, so ist dieser nicht vorhanden. Außerdem ist es möglich, dass eine Wurzel, ein Knoten mehrere Datensätze bzw. mehrere Zeiger auf Knoten, Blätter enthält. Der prinzipielle Aufbau eines B-Baumes wird noch einmal im nachfolgenden Beispiel verdeutlicht:

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2-4: B-Baum

Die braunen Rechtecke stellen die Knoten dar, in denen die Vergleiche erfolgen, dass oberste Rechteck die Wurzel, die schwarzen Pfeile die Zeiger auf die jeweils nächste Ebene und die grünen Rechtecke die Blätter. In dem in Abb. 2-4 aufgeführten Beispiel sind die Attributwerte des indizierten Attributes vom Typ Integer. Wird nun z. B. nach dem Datensatz mit dem Attributwert 11 gesucht, so geschieht dies folgendermaßen. Der Algorithmus vergleicht zuerst den Attributwert 11 mit dem Attributwert 9 der Wurzel und stellt fest, dass dieser größer ist, worauf er in den rechten Teilbaum verzweigt. Dort vergleicht er nun den Attributwert 11 mit dem Attributwert 13 und stellt fest, dass dieser kleiner ist und verzweigt in den linken Teilbaum. Hier angekommen vergleicht er den Attributwert 11 mit dem Attributwert des Knoten und da diese übereinstimmen, wird der Algorithmus beendet. Der Knoten enthält nun den gesuchten Datensatz bzw. einen Zeiger auf diesen.

Beim B+-Baum sind Zeiger auf die eigentlichen Datensätze der Tabelle ausschließlich in den Blättern enthalten. Jedes Suchen nach einem bestimmten Datensatz dauert nun gleich lang und Änderungsoperationen sind effizienter als beim B-Baum. Eingesetzt wird der B+-Baum häufig als Primärindex. B+-Bäume können auch zur Indizierung von BLOBs eingesetzt werden. Als Anwendung kommt Video, Musik in Frage, welche in BLOBs gespeichert ist. Statt Attributen werden nun Positionen oder Offsets im BLOB indiziert.

([Heu99])

2.3.2 R-Baum

Der R-Baum wird am häufigsten benutzt, um räumliche Daten zu indizieren. Vereinfacht gesagt ist der R-Baum sich als eine spezielle Erweiterung des ausgeglichenen B-Baumes für räumliche Daten vorzustellen. Bei ihm sind, wie auch beim B+-Baum Zeiger auf die Datensätze ausschließlich in den Blättern vorhanden. Das Grundkonzept besteht darin, während der Abfrage eine möglichst kleine Ergebnismenge aus den Daten zu erhalten. Dies geschieht durch eine einhüllende Geometrie, die im zweidimensionalen ein Rechteck ist. Sie ist durch eine Anzahl von Koordinaten definiert und kann eine oder mehrere räumliche Objekte enthalten. Im Gegensatz zu dem noch später folgenden Quadbaum wird der Index anhand der Geometrien aufgebaut. Im ersten Schritt wird um die zu indizierenden Geometrien ein minimales Rechteck gelegt, sogenannte MBR (Minimum Bounding Rectangle). Um diese Rechtecke werden im nächsten Schritt bestanpassende Rechtecke (MBR) gelegt, die nun teilweise mehrere MBRs aus dem ersten Schritt einschließen. Im letzten Schritt wird das gesamte zu indizierende Gebiet durch ein Rechteck eingeschlossen. Anhand der MBR kann nun ein R-Baum, ähnlich einem B-Baum generiert werden und in Tabellen abgelegt werden. Im folgenden ist ein Aufbau des R-Baumes samtzugehörigen Geometrien abgebildet.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2-5: Aufbau des R-Baumes und dazugehöriges Gebiet

Wie anhand der Abb. 2-5 zu sehen ist, können Geometrieobjekte auch zu mehreren MBR gehören. Objekt D1 z. B. gehört zu den MBRs R8, R3 und R1. Außerdem überschneiden sich MBRs oftmals.

Der R-Baum Index ist als eine Hierarchie von Seiten aufgebaut. Auf der obersten Stufe steht die Stammseite, die im obigen Beispiel die MBR R1 und R2 enthält. Auf den nächsten Stufen (mittlere Stufe) folgen die Äste, z. B. R6 und R7 und auf der untersten Stufe die Blätter, z. B. R11 und R12. Jedes Blatt besitzt eine gewisse Anzahl von Indexeinträgen. Allerdings enthalten die einzelnen Seiten normalerweise nicht die volle Anzahl an Indexeinträgen. Dies rührt unter anderem daher, dass der R-Baum balanciert ist, d. h. der Weg von der obersten Stufe zu den einzelnen Blättern der untersten Stufe ist stets gleich lang. Jede Seite des Baumes repräsentiert eine physikalische Seite bzw. Block der Festplatte. Der R-Baum wird dabei so angelegt, dass die Anzahl der Festplattenzugriffe zur Ausführung einer Anfrage minimiert wird, da diese enorm viel Zeit kosten im Vergleich der Zugriffe auf den Hauptspeicher (Größenordnungsdifferenz Zugriffslücke 105).

Obwohl Geometrieobjekte zu mehreren MBR gehören können, tauchen sie nur einmal im Index auf, um den Index klein zu halten. Ein Indexeintrag in den Blättern besteht aus einer Kopie des Schlüssels oder der Daten selbst und ein Zeiger auf die indizierte Datenbankreihe. Ein Indexeintrag in der obersten oder einer mittleren Ebene besteht aus der Definition der MBR und einem Zeiger, der zu einer nächst tieferen Stufe zeigt.

Die Anzahl der Stufen, d. h. die Höhe des Baumes, hängt maßgeblich von der Anzahl der indizierten Datensätze ab, die in einem Knoten gespeichert werden können. Die Anzahl wiederum hängt von der Größe des Schlüssel ab. Der Grad der Verzweigung des R-Baumes ist abhängig von der Anzahl der Indexeinträge pro Knoten. Generell ist die hierarchische Struktur des Index vergleichbar mit B-Bäumen.

Die einfachste Art des Suchens innerhalb eines R-Baumes ist die Suche nach Objekten, welche ein vorgegebenes Objekt überschneiden. Als Beispiel kann nach allen Polygonen einer räumlichen Spalte gesucht werden, welche ein vorgegebenes Polygon überschneiden. Die Suche beginnt nun in der obersten Stufe. Dabei wird die MBR des Suchobjektes mit den MBR der Indexeinträge der obersten Stufe verglichen. Alle Zweige, welche nun mit der MBR des Suchobjektes überschneiden, müssen nun geprüft werden. Diese Suche geschieht rekursiv bis zur untersten Stufe. Zweige, deren MBR sich nicht überschneidet, werden nicht weiter untersucht. Hieraus ergeben sich Geschwindigkeitsvorteile gegenüber B-Bäumen. Sobald die Suche ein Blatt erreicht, wird wieder eine Überschneidung der beiden MBR durchgeführt (Box-Test). Ergibt dieser Test eine Überschneidung, so werden die Objekte exakt verglichen und bei positivem Ausgang wird die zugehörige Reihe der Tabelle als Ergebnis zurückgegeben.

Performance wird beim R-Baum erreicht, indem Objekte außerhalb der MBR nicht einem exakten Test unterzogen werden müssen und die MBR möglichst klein gewählt wird. R-Bäume sind dynamisch, d. h. sie werden aktualisiert nach Änderung der zugrunde liegenden Daten im Gegensatz z. B. zu Hash-Verfahren, welche oftmals statisch sind. Auswirkungen auf die Geschwindigkeit des R-Baumes hat außerdem der Überlappungsgrad der MBR und die relative Lage der Objekte zueinander. Je mehr Überlappungen vorhanden sind, um so geringer ist die Selektivität der Daten. Gerade bei Erweiterungen des R-Baumes auf drei und mehr Dimensionen wird die Überlappung so groß, dass es zu erheblichen Performanceproblemen kommt, bei denen in Teilfällen sogar eine sequentielle Suche schneller ist.

([Heu00], [Inf99c], [Ora01b])

2.3.3 Quadbaum

Der Quadbaum Index wird ebenfalls eingesetzt, um räumliche Daten zu indizieren. Es wird dabei das gesamte zu indizierende Gebiet in Rechtecke unterteilt. Der Prozess der Unterteilung wird Tesselation genannt. Im ersten Schritt wird das gesamte Gebiet in vier Kacheln unterteilt (1. Tesselation). Im nächsten Schritt werden die Kacheln, welche eine Geometrie oder Teile davon enthalten, wiederum in vier Kacheln unterteilt (2. Tesselation). Diese Unterteilung wird solange fortgeführt, bis eine vorher definierte Kachelgröße (SDO_LEVEL) bzw. die Gesamtanzahl der Kacheln (SDO_NUMTILES) je Geometrie erreicht wird. Siehe hierzu Abb. 2-6.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2-6: Quadbaum Indizierung bei gleicher Kachelgröße

Die grauen Rechtecke stellen die zu indizierenden Geometrien dar. Die einzelnen Unterteilungen, in diesem Fall kam es zu zwei Tesselationen, werden durch das blaue Gitter visualisiert.

Aus den beiden bereits erwähnten Abbruchkriterien SDO_LEVEL und SDO_NUMTILES ergeben sich zwei Arten von Kacheln, um das Gebiet abzudecken. Zum einen gleichmäßige Kacheln, welche durch das Abbruchkriterium einer bestimmten Kachelgröße (SDO_LEVEL) entstehen, bei dem die Tesselation nach einer bestimmten Kachelungstiefe abbricht. Variabel große Kacheln entstehen durch das Kriterium SDO_NUMTILES, bei einer maximalen Kachelanzahl pro Geometrie abzubrechen.

Nachdem die Unterteilung in Kacheln erfolgt ist, wird in Tabellen abgelegt, welche Kacheln zu den einzelnen Geometrien gehören. Kacheln, welche keinerlei Geometrien enthalten, werden nicht aufgeführt. Sollen nun die Tabelle linear nach den Kacheln sortieren, um sie performant auf dem Sekundärspeicher (Festplatte) zu speichern, ergibt sich ein Problem hinsichtlich der Reihenfolge, da von einem zweidimensionalen Gebiet auf eine eindimensionale Ordnung transformiert werden muss. Dies wird in der Regel durch Haschfunktionen, z. B. Z-Kurven gelöst. Bei Z-Kurven werden die nächsten Nachbarn hintereinander abgelegt. Siehe hierzu Abb. 2-7.

Abb. 2-7: Z-Kurve über einem tessellierten Gebiet

Der Quadbaum Index bietet somit eine Alternative zum R-Baum.

([Ora01b])

2.3.4 Vergleich der Indizierungen

Nachdem nun die Indizierungsarten vorgestellt wurden, soll nun ein Vergleich derselben erfolgen. Der B-Baum bzw. B+-Baum wird ausschließlich zur Indizierung von nicht räumlichen Daten verwendet, weswegen ein Vergleich mit dem R-Baum bzw. Quadbaum nicht sinnvoll erscheint. Würden räumliche Daten trotzdem mittels eines B-Baumes indiziert, so wäre dies nur über dazugehörige Sachattribute möglich, was nicht zu einer Beschleunigung bei räumlichen Abfragen führen würde, da höchstens eine semantische aber keine eindeutige funktionale Beziehung zwischen den räumlichen Daten und dem Sachattribut besteht.

Folgend ein Vergleich von R-Baum und Quadbaum mittels einer Gegenüberstellung. Die in blauer Schrift dargestellten Punkte stellen dabei einen Vorteil dar.

Abbildung in dieser Leseprobe nicht enthalten

Tab. 2-1: Vergleich Quadbaum und R-Baum

Wie fällt nun eine Bewertung zugunsten des einen oder anderen Indizes aus? Anhand Tab. 2-1 lässt sich feststellen, dass die überwiegende Mehrheit der Vorteile auf Seiten des R-Baumes liegt. Allerdings sollte er nicht bedingungslos eingesetzt werden. Bei Daten, an denen oft Änderungen vorgenommen werden, ist der Quadbaumindex vorzuziehen. ([Ora01b])

Um die Performance von R-Baum und Quadbaum in der Realität gegenüber zu stellen, wurde ein Vergleichstest mit mehren räumlichen Abfragen durchgeführt. Dazu wurde ein Datensatz, bestehend aus 7434 Polygonen, welche Flurstücke darstellen und 10789 Polygonen, welche Gebäude darstellen, in eine Oracle Datenbank (siehe 2.6) geladen und mit GeoMedia (siehe 3.2) auf diese zugegriffen. Als Quadbaumindexart wurde Fixed Index gewählt mit einer vom Spatial Index Advisor (2.6.2) geschätzten Kachelungstiefe von sieben.

Räumliche Abfragen waren:

1. Zeige alle Flurstücke an, die ein Gebäude enthalten.
2. Zeige alle Gebäude an, die bis zu einem Umkreis von 1000m eines bestimmten Flurstückes stehen.
3. Zeige alle Gebäude an, die eine Flurstücksgrenze berühren.

Nachfolgend eine Tabelle mit eingetragenen Abfragezeiten. Die Zahlen sind dabei relativ zwischen beiden Indizierungsarten zu sehen und nicht als Absolutwerte.

Abbildung in dieser Leseprobe nicht enthalten

Tab. 2-2: Performance R-Baum und Quadbaum

Anhand der Tabelle ist ersichtlich, dass der R-Baum bei allen Abfragen schneller war, was ein Vorziehen gegenüber dem Quadbaum bestätigt. Dies trifft auch für die Nachbarschaftsanfrage Abfrage 2 zu, was somit mit der bereits in Tab. 2-1 getroffenen Aussage übereinstimmt.

2.4 Informixâ Dynamic Server 2000

Informix, vertrieben mittlerweile durch IBM, ist ein objektrelationales Datenbanksystem. Das komplette Datenbanksystem besteht dabei aus einem Datenbankserver, der Datenbank und ein oder mehreren Clientanwendungen.

2.4.1 Allgemeine Einführung

„Der IBM Informix Dynamic Server wurde für OLTP^[1] -, eCommerce- und Webanwendungen entwickelt. Er bietet eine hervorragende Erweiterbarkeit und unterstützt die DataBlade Technologie (2.4.5). Seinen Kern bildet eine bewährte Transaktions Engine für unternehmenskritische Anwendungen. In der Lage Tausende von gleichzeitigen Benutzern zu verwalten, bietet er ein Maximum an Zuverlässigkeit, Verfügbarkeit und Skalierbarkeit.“[ Informix ]

Der Datenbankserver wird mit Informix Dynamic Server 2000 bezeichnet. In dieser Diplomarbeit lag die Version 9.21 für Windows vor, welche auf Windows 2000, Windows NT 4.0 (SP5) läuft. Clientanwendungen dagegen laufen auf beliebigen Windowsversionen. Ein Datenbankserver ist ein Softwarepaket, welches den Zugang von einem oder mehreren Client zu einer oder mehreren Datenbanken regelt. Mit Informix Dynamic Server 2000 sind folgende objektrelationalen Funktionen möglich: UDT’s, benutzerdefinierte Funktionen, Typ- und Tabellenvererbung.

Um eine hohe Anzahl paralleler Clientanfragen bewältigen zu können, besitzt Informix eine fortgeschrittene Systemarchitektur, welche „dynamic scalable architecture“ (DSA) genannt wird. Die DSA besteht aus den drei Hauptkomponenten:

- Shared memory
- Disk
- Virtual processor

Die „Shared memory“-Komponente ermöglicht es parallel laufenden Prozessen gemeinsam Datenbestände durch gemeinsamen Zugang zu Speicherregionen zu nutzen. Dies hat mehrere Vorteile. Zum einen wird dabei der Speicherplatzverbrauch reduziert, da die Daten redundanzfrei im Hauptspeicher gehalten werden können. Außerdem sind somit weniger Zugriffe auf die Festplatte nötig. Die Positionierung des Schreiblesekopfes der Festplatte verursacht schließlich die größten Performanceprobleme. Zum anderen ist hiermit eine schnelle Kommunikation zwischen parallel laufenden Prozessen möglich. Unterschieden wird zwischen zwei Arten von shared memory. Einem resistenten, welcher aus einem Puffer für Daten von der Festplatte besteht, und einem virtuellen, welcher die Ressourcen der virtual processors verwaltet. Der Begriff virtual processor wird weiter unten in diesem Abschnitt erläutert.

Die Disk-Komponente ermöglicht das Speichern der Daten und Logbücher auf formatierten und unformatierten Festplattenplatz. Beim formatierten Festplattenplatz (cooked disk space) wird die Verwaltung der Festplatte dem zugrunde liegenden Betriebssystem (z. B. Windows 2000) überlassen. Hiermit ist eine Zuweisung zu Dateien etc. wesentlich einfacher für das Datenbankmanagementsystem. Nachteil ist, dass sich das DBMS somit auf das Betriebssystem verlassen muss, dass die Daten auch wirklich gespeichert sind. Beim unformatierten Festplattenplatz (raw disk space) übernimmt das DBMS die Verwaltung der physikalischen Speicherung der Daten auf die Festplatte für das Betriebssystem. Der Nachteil ist hierbei der erhöhte Aufwand für das DBMS. Vorteil ist die durch das DBMS garantierte Abspeicherung der Daten z. B. nach einem Commit. Commit bedeutet das Ende einer Transaktion auf einer Datenbank, sprich das Ende einer Kette von Änderungs-, Anfrageoperationen auf einer Datenbank. Generell ist der unformatierte Festplattenplatz bei großen Datenbanken, an denen viele Clients angebunden sind, und die Gefahr von Inkonsistenzen groß ist, vorzuziehen gegenüber formatierten Festplattenplatz.

Die Virtual Processor-Komponente ist die zentrale Komponente von Informixs DSA. Datenbankprozesse werden nun virtual processor unter Informix genannt, da sie ähnliche Funktionen besitzen, wie die Central Processor Unit (CPU) in einem Computer. Eine CPU lässt verschiedene Betriebssystemprozesse laufen, um verschiedene Anwendungen zu bedienen, ein virtual processor lässt verschiedene parallele Prozesse oder Arbeitseinheiten laufen, um mehrere Clientprogramme zu bedienen.

Informix bittet auch die Parallelisierung von Anfragen (PDQ). Dies führt zu einer enormen Performancesteigerung, da eine Anfrage auf mehreren Prozessoren verteilt wird. Anwendung findet dies vor allem bei Anfragen an ein Data Warehouse, bei denen es gilt, eine große Datenmenge zu untersuchen.

Des weiteren bietet Informix Dynamic Server 2000 gängige Logbuch- und Wiederherstellungsmechanismen (Recovery).

Dynamic Server erlaubt auch die Anfrage an verteilte Datenbanken. Bei verteilten Datenbanken ist z. B. eine Relation auf mehreren Datenbankservern verteilt (horizontale Fragmentierung). In jedem Datenbankserver existiert dabei das gleiche Schema, allerdings sind die Tupel verteilt. Als Beispiel ist sich eine Mitarbeiterrelation der Universität vorzustellen, bei dem die Tupel jedes Instituts auf dem eigenen Institutsdatenbankserver liegen.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2-8: Verteiltes Datenbanksystem

Eine Anfrage an die Datenbank erscheint transparent, d. h. der Client bekommt nicht mit, dass die Daten in mehreren Datenbanken gespeichert sind. An verteilten Transaktionen werden von Informix unterstützt Zwei-Phasen-Commit-Protokoll (2PC) und heterogenes Commit.

Beim 2PC wird eine der beteiligten Datenbanken als Koordinator bestimmt. Dieser fragt alle Teilnehmer, ob sie ein Commit durchführen können. Wenn alle positiv geantwortet haben, sendet der Koordinator an alle Teilnehmer die Anweisung, dass sie Commit ausführen können. Dieser erhält nun abschließend noch eine Bestätigung der Teilnehmer.

Heterogenes Commit ist eine von Informix verwendete Bezeichnung. In diesem Fall ist mindestens eine beteiligte Datenbank keine Informixdatenbank. Auch hier wird 2PC angewendet. Die Nicht-Informixdatenbank, auch Gateway-Teilnehmer genannt, muss nun mit dem Koordinator über ein Informix Enterprise Gateway Produkt kommunizieren. Das Informix Enterprise Gateway Produkt ist ein Programm, welches Distributed Relational Database Architecture (DRDA) unterstützt. DRDA wurde von IBM als eine Menge von Protokollen entwickelt, um Kommunikation zwischen heterogenen Datenbanklandschaften zu ermöglichen.

Die TP/XA-Bibliothek von Informix Dynamic Server dient dazu, dass eine Informixdatenbank als Ressource einer verteilten Umgebung fungiert. Die TP/XA-Bibliothek hält sich hierbei an die XA Interfacespezifikation entwickelt von X/Open. Die Informixdatenbank kann nun von anderen Transaktionsmanagern genutzt werden. Bekannte Transaktionsmanager (TP Monitors) sind CICS von IBM, Tuxedo und Top End von Bea. Der Einsatz eines Transaktionsmanagers ist sinnvoll, wenn die Daten über Datenbanken von verschiedenen Herstellern verteilt sind, um somit datenbankübergreifend Transaktionen zu ermöglichen.

Im Bereich der Sicherheit werden von Informix folgende drei Funktionen unterstützt:

- Sicherheit auf Datenbankebene
- Sicherheit auf Tabellenebene
- Rollenerstellung

Unter der Sicherheit auf Datenbankebene kann sich die Verschlüsselung der Daten mittels gängiger Verschlüsselungsverfahren vorgestellt werden. Bei der Sicherheit auf Tabellenebene werden Sichten, d. h. es ist nur ein bestimmter Ausschnitt der Tabelle sichtbar, Prozeduren, die den Zugriff auf Tabellen überwachen, verwendet. Durch die Rollenerstellung ist es möglich, ähnlich wie bei Betriebssystemen, Benutzern verschiedene Rechte (z. B. Lese-, Schreib-Rechte) durch den Datenbankadministrator zuzuweisen.

Außerdem ist es mit Informix möglich, sämtliche Ereignisse aufzuzeichnen. Somit kann jede Aktion der Benutzer verfolgen werden. Ebenfalls können diese Informationen auch für Statistiken benutzt werden, um somit die Datenbank zu optimieren (z. B. durch Anlegen neuer Indizes).

Unterstützt werden von Informix folgende Datentypen:

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2-9: Unterstützte Datentypen in Informix

Die Datentypen bzw. deren Attribute können teilweise durch Casten (Umwandeln) konvertiert werden.

Dynamic Server unterstützt einfache große Objekte (Text- und Bytetypen) und „Smart large Objects“ (BLOB und CLOB). Diese Daten werden entweder zusammen mit anderen Datenbankdaten oder in speziellen Dateien, „blobspaces“ für Text- und Bytetypen und „sbspaces“ für BLOB und CLOB gespeichert. Sie müssen meist außerhalb der Tabelle gespeichert werden, da die Datenmenge oftmals sehr groß ist. Ein Zeiger, der anstelle der Daten in der Tabelle gespeichert wird, zeigt nun auf den BLOB bzw. CLOB.

Einfache große Objekte besitzen ein theoretisches Kapazitätslimit von 213 Bytes. In der Praxis wird dies durch die Festplattengröße beschränkt. Auf diese Objekte kann nicht direkt zugegriffen werden, sondern sie müssen sequentiell eingelesen werden.

„Smart large Objects“ (BLOB und CLOB) erlauben dagegen, einzelne Segmente zu lesen, danach zu suchen und zu schreiben. Außerdem können Kontrollsperren unabhängig von den Kontrollsperren der Datenbank eingeführt werden. „Smart large Objects“ werden z. B. zur Speicherung von Video- und Musikstücken, Bildern, großen Textdokumenten und räumlichen Objekten benutzt.

Komplexe Datentypen sind eine Zusammensetzung aus existierenden Datentypen. Informix unterscheidet hierbei zwischen Collection-Typ und benannten bzw. unbenannten Reihentypen.

Ein Collection-Typ ist eine Gruppe von Elementen des selben Datentyps, vergleichbar mit einem Array in Programmiersprachen. Somit ist es möglich, in einer einzelnen Tabellenspalte eine Gruppe von Elementen zu speichern.

Ein Reihentyp ist eine Abfolge von Feldern. Jedes Feld besitzt einen Namen und einen Datentyp. Die Felder eines Reihentyps sind allerdings nicht mit den Spalten einer Tabelle vergleichbar, denn es ist weder möglich Voreinstellungen für die Felder vorzunehmen, noch Bedingungen auf ihnen zu definieren, noch können die Felder direkt in Tabellen benutzt werden. Zusätzlich wird noch zwischen benannten und unbenannten Reihentypen unterschieden. Ein benannter Reihentyp ist eine Gruppe von Feldern, die unter einem einzigen Namen definiert sind. Ein Feld gehört somit zu diesem bestimmten Reihentyp. Dieser benannte Reihentyp bzw. dessen Namen ist eindeutig in der gesamten Datenbank. Ein unbenannter Reihentyp wird durch die Struktur seiner Felder bestimmt. Im Gegensatz zum benannten Reihentyp kann dieser nicht als Tabellenschema, zur Definition einer Tabelle benutzt werden. Er wird benutzt, um eine Spalte, ein Feld oder eine Variable zu definieren.

Ein bedeutender Unterschied zwischen komplexen und benutzerdefinierten Datentypen ist die Möglichkeit des Zugangs bzw. der Manipulation individueller Komponenten des komplexen Datentyps mittels SQL-Ausdrücken.

Es können benutzerdefinierte Typen (UDT) erzeugt werden, um den Datenbankserver flexibler zu gestalten hinsichtlich der Abspeicherung und der Manipulation von z. B. räumlichen Daten. Unter Informix können benutzerdefinierte Daten entweder „distinct“ (verschieden) oder „opaque“(eingekapselt) sein.

Benutzerdefinierte Typen, welche eingekapselt sind, speichern einen einzelnen Wert und können vom Datenbankserver nicht in seine Komponenten zerlegt werden. Die Attribute des neuen Datentyps sind dabei nur durch Methoden erreichbar bzw. veränderbar. Somit ist eine Kapselung erreicht worden.

Der „distinct“-Typ besitzt die oben genannten Eigenschaften des „opaque“-Typ. Er wird benutzt, um bereits bestehende „opaque-Typen“ bzw. Grundtypen zu verändern, zu erweitern, nicht aber zu ersetzen. Er unterscheidet sich hierbei durch seinen Namen vom ursprünglichen Typ. Ein umwandeln zwischen dem „distinct“-Typ und dem ursprünglichen „opaque“-Typ ist nur durch explizites Casting möglich.

Benutzerdefinierte Routinen (UDR) sind Routinen, die mittels SQL oder einer anderen UDR aufgerufen werden können. UDR hat Vorteile im Bereich der Performancesteigerung, Optimierung und für Konfigurationsaufgaben. UDR können geschrieben werden, um folgende Aufgaben zu erfüllen:

- Einkapselung von SQL-Ausdrücken
- Erweiterte Funktionen für Grunddatentypen
- Unterstützung neuer Datentypen (UDT)
- Trigger für viele Anwendungen
- Zur Begrenzung von Benutzerrechten
- Manipulation großer Objekte
- Unterstützung interaktiver Multimediapublikationen

UDR werden meist in SPL (2.4.4) geschrieben, jedoch können auch externe in Java oder C geschriebene Routinen aufgerufen werden.

Benutzerdefinierte Aggregatfunktionen (UDA) erweitern die Datenbank durch Aggregationen über UDT’s und UDR’s. Damit ist es möglich, grundlegende Aggregatfunktionen wie z. B. AVG, COUNT, MAX zu überladen. Ebenfalls besteht die Möglichkeit eigene Aggregatfunktionen zu definieren.

An Vererbungsmechanismen gibt es in Informix die Typen- und Tabellenvererbung. Vererbbare Typen in Informix sind allerdings ausschließlich benannte Reihentypen. Durch die Vererbung werden Eigenschaften geerbt, die noch durch spezielle Eigenschaften ergänzt werden können. Tabellen, deren Schema durch benannte Reihentypen definiert ist, können vererbt werden. Weitergegeben wird hierbei auch das Verhalten der Tabelle (Bedingungen, Speicheroptionen, Trigger,...).

([Inf99a])

2.4.2 Installation

Im folgenden wird die Installation von Informix Dynamic Server und zugehörigen Produkten unter Windows 2000 beschrieben. Voraussetzung für die Installation ist unter anderem ein NTFS Dateisystem. ([Inf00b])

Während der Installation wird der Benutzer informix unter Windows 2000 eingerichtet. Standardmäßig wird dann mittels dem Benutzer informix über die Windowsauthentifizierung auf die Datenbank zugegriffen. Generell erlaubt Informix die Anmeldung an die Datenbank nur über Betriebssystembenutzer.

Anzuraten ist eine benutzerdefinierte Installation, bei der im Zweifelsfall die vorgegebenen Defaultwerte übernommen werden können. Bei der Auswahl der zu installierenden Produkte sollte der Informix Dynamic Server, die Clientbibliotheken Informix Connect (2.4.4) und der BladeManager (2.4.5) ausgewählt werden. Das DataBlade Developers Kit kann deaktiviert werden, da es dazu dient, eigene DataBlades (2.4.5) zu entwickeln. Siehe hierzu Abb. 2-10.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2-10: Informix Installation 1

Nun können noch verschieden selbsterklärende Einstellungen getätigt werden, bevor die Produkte kopiert werden. Nachdem der Informix Dynamic Server installiert ist, wird eine Instanz desselben erstellt. Diese Instanz sollte auch gleich initialisiert werden. Ansonsten ist dies auch später über die Konsole möglich (2.4.3). Nachdem das Produkt Informix Dynamic Server installiert wurde, wird Informix Connect installiert. Mit ihr wird auch ein ODBC-Treiber mitinstalliert. Falls auch JDBC-Treiber benötigt werden, so müssen diese später extra installiert werden.

Erscheint während der Installation die Fehlermeldung

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2-11: Informix Fehlermeldung

so kann dies normalerweise vernachlässigt werden. SNMP (Simple Network Message Protocol) dient dazu, Systemadministratoren bei der Verwaltung verteilter Umgebungen zu unterstützen. Die Datenbank ist auch ohne den OnSNMP subagent voll funktionsfähig.

Nachdem auch der BladeManager installiert ist, müssen noch einige Einstellungen am Informix Dynamic Server getätigt werden. Zuerst sollten die wichtigsten Systemvariablen von Informix dauerhaft im System gesetzt werden. Dazu werden sie am besten in die Umgebungsvariablen des Systems eingetragen. Zu finden unter Einstellungen/Systemsteuerung/System/Erweitert/Umgebungsvariablen. Die Werte der Umgebungsvariablen werden am einfachsten der Konsolenausgabe, die erscheint, sobald das neu angelegte Icon im Startmenü mit der Bezeichnung des Instanznamens des Informix Dynamic Servers doppelgeklickt wird, entnommen. Als nächstes sollten noch die Dienste unter Einstellungen/Systemsteuerung/Verwaltung/Dienste angepasst werden, damit die Datenbank beim Hochfahren des Systems ebenfalls automatisch gestartet wird.

Die zentrale Konfigurationsdatei des Informix Dynamic Servers lautet ONCONFIG.’Instanzname’ und ist im Verzeichnis ‚Installationspfad’/etc zu finden. Eine Standardkonfiguration mit dem Namen onconfig.std befindet sich ebenfalls in diesem Verzeichnis. Die Konfigurationsdatei kann mit einem beliebigen Texteditor geöffnet und bearbeitet werden. Für einen Ausschnitt der Datei siehe Abb. 2-12:

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2-12: Konfigurationsdatei ONCONFIG

Der Instanzname der Informix Datenbank lautet in diesem Fall ikgis6. Sobald etwas an dieser Datei geändert wurde, sollte der Dienst der zugehörigen Instanz neu gestartet werden.

Wird mit einem Test oder Demo System gearbeitet, so können die logische Logdateien so eingestellt werden, dass sie zyklisch wieder freigegeben werden. Ansonsten müsste als Alternative ein kontinuierliches Backup eingerichtet werden. Dies ist wichtig, damit der Server, sobald die Logdateien voll sind, nicht in einen Ruhemodus (Quiescentmodus) fährt, bei dem nur noch eingeschränkte Funktionalität möglich ist. Um dies zu vermeiden, wird in der bereits beschriebenen Konfigurationsdatei ONCONFIG der Parameter LTAPEDEV auf NUL (Windows NT) bzw. auf /dev/null (Unix/Linux) gesetzt. Anschließend ist ein Neustart des Dienstes nötig. Abb. 2-13 zeigt die veränderte ONCONFIG.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2-13: Konfigurationsdatei ONCONFIG und Parameter LTAPEDEV

Um die ab Abschnitt 2.4.6 erklärte räumliche Erweiterung Informix Spatial DataBlade nutzen zu können, muss diese, nachdem Informix Dynamic Server 2000 installiert wurde, mit der separat beiliegenden CD noch installiert werden.

Eine ausführliche Dokumentation zu Informix Dynamic Server und zugehörigen Clientprodukten ist auf der CD Informix Answers Online enthalten, die durch einfachen Aufruf des Setupprogramms installiert werden kann.

Um mit dem Dynamic Server erste Schritte auszuprobieren, empfiehlt es sich, das Skript dbaccessdemo von der Konsole aus zu starten, welches eine Datenbank und einige mit Inhalten gefüllte Tabellen anlegt. Bereits während der Installation angelegt wurden die beiden Systemdatenbanken sysmaster und sysutils. Interessante Informationen liefert hierbei die Tabelle sysdatabases der Datenbank sysmaster, in der Name, Erstellungsdatum, Loggingstatus der Datenbanken gespeichert ist.

2.4.3 Administration

Administriert wird der Informix Dynamic Server von verschiedenen Programmen. Als zentrale Konfigurationsdatei kann die bereits unter 2.4.2 erläuterte ONCONFIG gesehen werden. Ein Programm zur Verwaltung der Instanzen von Informix Dynamic Server ist der Server Instance Manager, der über einen Programmgruppeneintrag gestartet werden kann.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2-14: Server Instance Manager

In Abb. 2-14 existiert bereits eine Instanz mit der Bezeichnung ikgis3.

Ein weiteres Administrationsprogramm ist DBAccess. Mit diesem besteht die Möglichkeit SQL-Anweisungen an das Datenbanksystem zu richten. Einige DDL (Data Definition Language) und DML (Data Manipulation Language) Anweisungen sind dabei mittels Menüpunkten ausführbar. DBAccess wird über die Eingabeaufforderung mittels dbaccess aufgerufen und ist ein Konsolenprogramm.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2 - 15 : DBAccess Hauptmenü

Das in Abb. 2-15 gezeigte Hauptmenü von DBAccess bietet eine Reihe von Menüpunkten, die ebenfalls einige Unterpunkte enthalten. Durch den Menüpunkt Query-language erscheint eine Art Texteditor, in dem SQL-Befehle eingeben werden können. Bei Connection wird eine Verbindung zu einem Datenbankserver hergestellt, was allerdings durch die Windowsauthentifizierung und den Benutzer informix in der Regel automatisch geschieht. Unter dem Menüpunkt Database, Table können Datenbanken, Tabellen angelegt, modifiziert, gelöscht werden und unter Session werden Informationen vom Informix Dynamic Server angezeigt. Ein ungewohnte Menüsteuerung von DBAccess sollte beachtet werden. Soll ein Untermenü abgebrochen werden, ohne das etwas bestätigt wird, so geht dies nicht wie sonst üblich mit <Esc>, sondern nur mit der Tastenreihenfolge <Space> und <Enter>.

[...]

^[1] Unter OLTP versteht man die Anbindung von Clients an einen Datenbankserver in einem Firmennetzwerk.