Humboldt-Universität zu Berlin

Transcription

Humboldt-Universität zu Berlin
Institut für Informatik
GIS-Datenbank für webservicebasierten Zugriff auf
standortbezogene Informationen
Diplomarbeit von Ralf Heese
März 2002
1. Gutachter:
Prof. Johann Christoph Freytag, Ph.D.
2. Gutachter:
Dr. Rainer Eckstein
Inhaltsverzeichnis
1 Einleitung
1
2 Erstellen der GIS-Datenbank
2.1 Alternative Einleseverfahren . . . . . . . . . . . .
2.2 Vorverarbeitung der GDF-Dateien . . . . . . . .
2.2.1 Gesamtüberblick . . . . . . . . . . . . . .
2.2.2 Das Parser-Paket . . . . . . . . . . . . . .
2.2.3 Die Ausgabe in die DEL-Dateien . . . . .
2.3 Verwendung des MultiNet Shapefile-Format . . .
2.3.1 Die Shapefile-Spezifikation . . . . . . . . .
2.3.2 Das MultiNet Shapefile-Format . . . . . .
2.3.3 Einlesen der dBASE- und Shape-Dateien
3 Zugriff auf räumliche Daten
3.1 Mehrdimensionale Zugriffsverfahren . . .
3.1.1 Charakterisierung . . . . . . . . .
3.1.2 Anforderungen . . . . . . . . . . .
3.1.3 Anfragebearbeitung . . . . . . . .
3.2 Geometrien im DB2 Spatial Extender . .
3.2.1 Indizierung räumlicher Objekte . .
3.2.2 Anfragebearbeitung . . . . . . . .
3.2.3 Beobachtungen und Eigenschaften
3.2.4 Analyse . . . . . . . . . . . . . . .
3.2.5 Experimentelle Überprüfung . . .
3.2.6 Bewertung . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
7
8
9
11
13
16
16
17
21
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31
32
32
34
35
37
37
39
41
42
47
57
4 Webservices
4.1 Webservice – ein allgemeiner Begriff . . . . . .
4.1.1 Eine Definition . . . . . . . . . . . . . .
4.1.2 Wichtige Standards . . . . . . . . . . .
4.1.3 Vor- und Nachteile von Webservices . .
4.2 Realisierung eines Webservice . . . . . . . . . .
4.2.1 Die verwendete Webservice-Architektur
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
58
59
59
60
73
75
75
i
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ii
INHALTSVERZEICHNIS
4.2.2
4.2.3
4.2.4
Implementierung des Webservice . . . . . . . . . . . .
Klient des Webservice . . . . . . . . . . . . . . . . . .
Auswahl der UDDI . . . . . . . . . . . . . . . . . . . .
5 Zusammenfassung und Auswertung
A Modellierung des Importwerkzeugs
A.1 Konfigurationsdateien . . . . . . . . . . . . . . . . .
A.1.1 Visualisierung einer XML-Dokumentstruktur
A.1.2 Allgemeine Konfiguration . . . . . . . . . . .
A.1.3 Datenbankspezifische Konfiguration . . . . .
78
81
82
84
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
88
88
88
88
90
B Realisierung des Webservice
93
B.1 WSDL-Beschreibung . . . . . . . . . . . . . . . . . . . . . . . 93
B.1.1 Schnittstellendefinition . . . . . . . . . . . . . . . . . . 93
B.1.2 Implementationsabschnitt . . . . . . . . . . . . . . . . 95
Abbildungsverzeichnis
1.1
Datennetz (Ausschnitt) . . . . . . . . . . . . . . . . . . . . .
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
Übersicht über die Pakete der Vorverarbeitungssoftware
Das Parser-Paket . . . . . . . . . . . . . . . . . . . . . .
Zusammenwirken der wichtigsten Klassen . . . . . . . .
Verkehrsnetz Layer (Ausschnitt) . . . . . . . . . . . . .
Points of Interest Layer (Ausschnitt) . . . . . . . . . . .
Import vom MultiNet Shapefile-Format . . . . . . . . .
Aufrufvarianten der INSERT-Anweisung . . . . . . . . . .
Pakete des Importwerkzeugs . . . . . . . . . . . . . . . .
Das Paket teleatlas . . . . . . . . . . . . . . . . . . . . .
Das Paket database . . . . . . . . . . . . . . . . . . . . .
Substitution innerhalb von SQL-Dateien . . . . . . . . .
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
Lokale Teilung einer Region . . . . . . . . . . . . . . . . . . .
Nicht-lokale Teilung einer Region . . . . . . . . . . . . . . . .
Anfragebearbeitung mit räumlichen Operationen . . . . . . .
Mehrdimensionales Zugriffsverfahren des DB2 Spatial Extender
Ausführungsplan für eine Anfrage mit Geometrien . . . . . .
Skizze zur Abschätzung der Indexeinträge . . . . . . . . . . .
Punkteverteilung im Datenraum . . . . . . . . . . . . . . . .
Straßennetz aus der GIS-Datenbank (Ausschnitt) . . . . . . .
Zufällig generierte Geometrien (Ausschnitt) . . . . . . . . . .
Ausdehnungen der Geometrien (Straßennetz) . . . . . . . . .
Ausdehnung der Geometrien (Zufallsgeometrien) . . . . . . .
33
33
36
38
40
45
49
51
51
52
54
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
Webservice Modell . . . . . . . . . . . . . . . . . . .
Schichtenmodell des UDDI (Interop Stack) . . . . .
Bestandteile einer SOAP-Nachricht . . . . . . . . . .
Header einer SOAP-Nachricht . . . . . . . . . . . . .
Body einer SOAP-Nachricht . . . . . . . . . . . . . .
SOAP HTTP-Anforderung . . . . . . . . . . . . . .
SOAP HTTP-Antwort . . . . . . . . . . . . . . . . .
Schnittstellenabschnitt des POI-Service (Ausschnitt)
61
63
64
65
66
67
67
70
iii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
10
12
14
18
20
22
23
24
25
27
29
iv
ABBILDUNGSVERZEICHNIS
4.9
4.10
4.11
4.12
4.13
4.14
Implementationsabschnitt des POI-Service
Schlüssel-Datenstrukturen der UDDI . . .
Verknüpfung von WSDL und UDDI . . .
Überblick über die Systemumgebung . . .
Subsysteme Webservice . . . . . . . . . .
Modellierung des Webservice . . . . . . .
(Ausschnitt)
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
70
71
73
76
77
80
A.1 Aufbau der allgemeinen Konfigurationsdatei . . . . . . . . . .
A.2 Aufbau der Konfigurationsdatei für DB2 UDB . . . . . . . .
89
91
Tabellenverzeichnis
3.1
3.2
3.3
3.4
Schnittpunkte der Geometrien mit dem Gitter . .
Ergebnisse der Experimente zu Punktdaten . . .
Ergebnisse der Experimente (Straßennetz) . . . .
Ergebnisse der Experimente (Zufallsgeometrien) .
.
.
.
.
39
50
53
55
A.1 Kardinalitäten im XML-Modell . . . . . . . . . . . . . . . . .
89
v
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
vi
TABELLENVERZEICHNIS
Kapitel 1
Einleitung
Nach einem langen Spaziergang durch die Innenstadt von Köln steht eine
Touristin vor dem Dom und möchte mit den öffentlichen Verkehrsmitteln
wieder zurück in ihr Hotel. Sie greift zum Mobiltelefon und stellt eine Verbindung zum WAP-Portal ihres Mobilfunkanbieters her. Nach der Auswahl
des Menüpunktes öffentliche Verkehrsmittel öffnet sich eine Eingabemaske,
in dem sie ihr Ziel, den Namen ihres Hotels, eingibt. Kurze Zeit später wird
eine Wegbeschreibung zur nächstgelegenen Bushaltestelle sowie die Fahrverbindung zu ihrem Hotel auf dem Display angezeigt.
Insgesamt realisiert das entworfene Szenario einen standortbezogenen
Dienst (Location Based Service). Unter Ausnutzung der Ortbarkeit eines
eingeschalteten Mobiltelefons lassen sich auf die momentane Position abgestimmte Dienste und Informationen anbieten. Für die Realisierung eines
solchen Szenarios ist ein Zusammenführen verschiedenster Datenquellen erforderlich.
Zunächst wird für die Erstellung der Fahrverbindung ein Ausgangspunkt
und ein Ziel benötigt. Der Ausgangspunkt ist in naher Zukunft mit einer
noch höheren Präzision verfügbar. Mit dem zur Zeit verwendeten Ortungsverfahren, mittels der Informationen einer Funkzelle, ist es dem Mobilfunkbetreiber möglich, die Position eines Mobiltelefon in Städten bis zu einer
Genauigkeit von 100 bis 500 Meter zu ermitteln. Diese Genauigkeit nimmt
jedoch auf ländlichen Gebieten stark ab (bis auf 10 Kilometer), da die Funkmasten weit voneinander entfernt aufgestellt sind. Durch verbesserte Techniken wie dem EOTD-Verfahren (Enhanced Observed Time Difference), bei
dem die Laufzeitunterschiede von Signalen zwischen Mobiltelefon und verschiedenen Funkmasten genutzt werden, erhöht sich die Genauigkeit auf 30
Meter. GPS-taugliche Hardware erlaubt sogar die Bestimmung der Position
bis auf 10 Meter Genauigkeit. Die so gewonnene Positionsangabe lässt sich
nun mit anderen Daten koppeln. [Bag01]
Mittels einer Datenquelle, die die Haltestellen der öffentlichen Verkehrsmittel der Stadt und Routinginformationen kombiniert, wird eine Wegbe1
2
KAPITEL 1. EINLEITUNG
schreibung zur nächstgelegenen Haltestelle berechnet. Nach dem Ermitteln
der Adresse des Hotels kann die Fahrverbindung mittels des aktuellen Busfahrplans bestimmt werden.
Werden ähnlich gelagerte Szenarien betrachtet, so wird die Komplexität
der Integration unterschiedlichster Datenquellen (Abbildung 1.1) offensichtlich. Die Abbildung zeigt ein Mindmap zu der Frage, welche Daten für einen
Kunden unterwegs von Bedeutung sein könnten.
Diskothek
Sportplätze
Kino
Bars
Freizeit
Museen
hist. Bauten
PKW
POIs
Verkehr
LKW
Hilfestellen
Polizei
öffentlich
Nutzer
Giftzentrale
Dienstleister
Vorhersage
Wetter
Services
Einkauf
Reisewetter
Vermietung
Wassersport
Wind
Seegang
Restaurant
Bewertung
Zeiten
Abbildung 1.1: Datennetz (Ausschnitt)
Dabei wurden zunächst die vier umfassenden Kategorien Verkehr, Points
of Interests (POIs), Services und Wetter erkannt. Die Kategorie Verkehr
beinhaltet vor allem Routing- und Fahrplan-Informationen sowohl im privaten als auch im logistischen Bereich. Unter POIs versteht man markante
Punkte auf Landkarten wie zum Beispiel Sehenswürdigkeiten und Freizeitanlagen. Weitere interessante Einrichtungen sind unter der Kategorie Services
zusammengefasst. Bei POIs und Services sind nicht nur die Adressen von
3
Interesse, sondern auch zusätzliche Daten wie Öffnungszeiten, Bewertungen
oder geschichtliche Hintergrundinformationen. Nicht zuletzt liefert die Kategorie Wetter nicht nur den Reisenden Entscheidungshilfen, sondern auch
Wassersportlern.
Das Netz in Abbildung 1.1 lässt sich dabei beliebig in alle Richtungen erweitern. Tatsächlich sind neben der eigentlichen Datenlieferung auch Dienstleistungen wie zum Beispiel das Durchführen einer Zimmerreservierung oder
die Vorbestellung eines Mietwagens mögliche Erweiterungen.
Aufgrund der Menge der Daten können diese üblicherweise nicht lokal
von einem einzigen Service-Anbieter vorgehalten werden, erst recht nicht,
wenn er seine Services international anbietet. Abgesehen davon ist der Aufwand zur Wahrung der Aktualität der Daten immens. Es muss daher ein
einfacher und universeller Weg gefunden werden, die verschiedenen Datenquellen zu kombinieren. Eine Möglichkeit ist die Erstellung von Webservices
durch die Betreiber der Datenquellen.
Ein Webservice ist eine zu einem Paket zusammengefasste Sammlung von
Funktionen, das zur Benutzung durch andere Programme im Netz publiziert
wird [Gla00]. Über Webservices lassen sich somit verschiedene Dienstleistungen zu neuen höherwertigen kombinieren. Die Interaktion zwischen den
Webservices erfolgt mit einem standardisierten und universell einsetzbaren
Protokoll.
Übertragen auf das oben entworfene Szenario könnte die Ermittlung der
Fahrverbindung eine Aggregation verschiedener Webservices (Positionsermittlung, Geokodierung, Routing und Fahrplanauskunft) sein.
Das Ziel der Diplomarbeit ist die Realisierung eines webbasierten Zugriffs
auf eine GIS-Datenbank unter Verwendung von Webservices. Damit lassen
sich die kartografischen Daten aus der Datenbank durch Kombination mit
anderen Webservices aufwerten.
Zur Verwirklichung dieses Zieles sind verschiedene Teilziele zu erreichen.
Zum Aufbau der Datenbasis wird zunächst ein für die zu erwartenden Anfragen optimiertes Datenbankschema entwickelt und anschließend bezüglich eines konkreten Datenbankmanagementsystem (DBMS) umgesetzt. Die Umsetzung in ein konkretes DBMS erfordert auch Überlegungen zum schnellen
Laden der kartografischen Daten in die GIS-Datenbank. Da die Datenbank
vor allem eine Zuordnung von räumlichen Objekten zu deren Koordinaten
vornimmt, sind insbesondere Aspekte der Speicherung und des Zugriffs der
Koordinaten zu berücksichtigen.
Ein weiteres Teilziel besteht im Publizieren der Webservices. Dafür wird
ein Webservice-Verzeichnis aufgesetzt, das das Auffinden und die Auswahl
eines Webservice nach spezifischen Eigenschaften, wie zum Beispiel die Art
der Daten oder der Verfügbarkeit, gestattet.
Erst wenn diese Basis geschaffen ist, kann die eigentliche Realisierung
des Webservice erfolgen. Mit dem Webservice kann dann über das stan-
4
KAPITEL 1. EINLEITUNG
dardisierte Protokoll SOAP kommuniziert und Daten aus der Datenbasis
abgefragt werden. Das Simple Object Access Protocol (SOAP) ist ein einfaches XML-basiertes Protokoll zum Austausch von Informationen in einer
dezentralisierten und verteilten Umgebung [W3C00b].
Erste Erfahrungen für die Entwicklung eines Datenbankschemas für die
Datenbasis wurden bereits in der Studienarbeit [Hee01] gesammelt. Weiterhin wurde dort eine Methode zum Laden der Daten in die Datenbank
vorgestellt. Der neue Fokus der Diplomarbeit bedingt eine Verbesserung der
in der Studienarbeit entwickelten Konzepte.
Das Datenbankschema aus der Studienarbeit erweist sich als ungünstig
für die schnelle Beantwortung von Anfragen an die Datenbasis, da die Daten
vor allem stark vertikal verteilt gespeichert werden, d.h., die Informationen
zu einem Feature sind auf mehrere Tupel verteilt, die dann aufwändig durch
Joins zusammengefügt werden müssen. Deshalb muss das Datenbankschema
geeignet abgeändert werden. Dies betrifft auch die physische Speicherung der
Daten in den Tabellen.
Eng mit der Veränderung des Datenbankschemas verbunden ist eine Adaption des Einlesevorgangs, da die Daten nun anders auf die Tabellen verteilt
werden. In der Studienarbeit wurden die Daten aus im GDF-Standard kodierten Dateien extrahiert und in ein von der Datenbank nutzbares Format
umgesetzt. Durch die Transformation wurden die Daten auf verschiedene
Dateien verteilt, die anschließend direkt in die Tabellen der Datenbank eingelesen werden. Eine Veränderung des Datenbankschemas bedeutet also eine
Neuverteilung der Daten auf Dateien.
Eine veränderte Ausgangssituation schafft seit kurzem auch die Auslieferung der kartografischen Daten in einem anderen Datenformat, dem
MultiNet Shapefile-Datenformat. Dieses basiert auf dem ESRI® ShapefileFormat und kombiniert räumliche Objekte mit zugehörigen Eigenschaften
zu einem leicht verarbeitbaren Datenformat. Durch Nutzung dieses Datenformats könnte der durch das GDF-Format entstehende Mehraufwand, z. B.
Konvertierung der Daten und Zwischenspeicherung, vermieden werden.
Der folgende Abschnitt bietet einen Überblick über die einzelnen Kapitel
der Diplomarbeit. Im Anschluss an diese Einleitung befasst sich das zweite
Kapitel mit dem Importieren von kartografischen Daten in eine Datenbank.
Dabei wird auf die Datenformate GDF und MultiNet Shapefile eingegangen.
Nach der Diskussion alternativer Importverfahren bei Datenbanken wird
zunächst die Remodellierung der Vorverarbeitungssoftware für GDF-Dateien
vorgestellt, die vor allem um eine datenbankunabhängige Ausgabe erweitert
worden ist. Der anschließend Abschnitt beschreibt den Import der Daten
aus dem MultiNet Shapefile-Format, wobei ein anderes Importverfahren als
bei den GDF-Dateien eingesetzt wurde.
5
Das dritte Kapitel beschäftigt sich mit mehrdimensionalen Zugriffsverfahren, die im engen Zusammenhang mit einem performanten Zugriff auf
räumliche Daten zu sehen sind. Neben einer allgemeinen Einführung und
der Charakterisierung der Zugriffsverfahren werden grundlegende Anforderungen zusammengestellt. Für die Speicherung der räumlichen Objekte wird
der DB2 Spatial Extender eingesetzt, der dem Nutzer ein mehrdimensionales Zugriffsverfahren zur Verfügung stellt. Damit dieses Zugriffsverfahren
gewinnbringend eingesetzt werden kann, muss es entsprechend konfiguriert
werden. Daher werden im zweiten Teil des Kapitels nach einer Analyse der
Zugriffsstruktur einige Regeln und Heuristiken zur performanten Konfiguration aufgestellt, die anschließend experimentell überprüft werden.
Nachdem eine kartografische Datenbasis erstellt und ein performanter
Zugriff auf die Daten gewährleistet wurde, beschreibt das vierte Kapitel die
Realisierung eines prototypischen Webservice für den Zugriff auf standortbezogene Informationen. Dazu werden zuerst die grundlegensten Standards
kurz erläutert und danach die konkrete Implementierung eines Webservice
unter Verwendung etablierter Werkzeuge dokumentiert.
Wesentliche Begriffe sowie wichtige Begriffe aus der Studienarbeit werden
im Glossar beginnend auf Seite 102 erläutert. Das erste Auftreten eines im
Glossar beschriebenen Begriffs ist durch das Kreuz gekennzeichnet.
Kapitel 2
Erstellen der GIS-Datenbank
Zum Einrichten einer Datenbasis müssen die kartografische Daten von Tele
Atlas, einem Unternehmen das kartografische Daten sammelt und aufbereitet, in eine Datenbank übertragen werden. Die Daten werden üblicherweise
nach administrativen Gebieten aufgeteilt und in unterschiedlichen Datenformaten auf CDs ausgeliefert.
Zuerst werden die verschiedenen Importverfahren einer Datenbank gegenübergestellt, um abwägen zu können, welches Verfahren sich für die jeweiligen Datenformate am besten eignet. Wichtige Kriterien sind dabei der
Datendurchsatz sowie die Einfachheit von notwendigen Datentransformationen.
Bisher lieferte der Vertreiber die kartografischen Daten hauptsächlich im
GDF-Datenformat aus. Dieses durch den GDF-Standard [GDF95] definierte
Datenformat gestattet auf Basis eines Referenzmodells den Austausch von
räumlichen Daten zwischen unterschiedlichen Firmen und Organisationen
ohne Kompatibilitätsprobleme. Damit die Daten in eine Datenbank übertragen werden können, ist eine entsprechende Vorverarbeitung der GDF-Datei
notwendig. Die Transformation der GDF-Datei in ein für Datenbanken nutzbares Datenformat beschreibt der zweite Abschnitt dieses Kapitels.
Seit kurzem sind die Daten auch im MultiNet Shapefile-Format verfügbar, auf das im anschließenden Abschnitt eingegangen wird. Basierend auf
dem ESRI Shapefile-Format werden räumliche Objekte mit den zugehörigen Informationen so gespeichert, dass ein Zugriff auf die unterschiedlichen
Layer vereinfacht wird. Ein Layer gruppiert die kartografischen Informationen bezüglich ihrer Thematik, z. B. Autobahnen oder Verwaltungsbezirke.
Insofern der Spatial Extender des DBMS das Shapefile-Format unterstützt,
reduziert sich der Aufwand für die Integration bzw. den Import der kartografischen Daten in die Datenbank wesentlich.
Der letzte Abschnitt diese Kapitels beschreibt die verwendeten Konzepte
zum Import des MultiNet Shapefile-Formats sowie die Modellierung und
Implementierung eines einfach zu bedienenden Importwerkzeugs, das ohne
6
2.1. ALTERNATIVE EINLESEVERFAHREN
7
großen Aufwand für verschiedene DBMS konfiguriert werden kann.
2.1
Alternative Einleseverfahren
Im Allgemeinen bieten Datenbankmanagementsysteme verschiedene Methoden zum Laden von Daten in Datenbanktabellen, die sich vor allem im
Datendurchsatz unterscheiden. Grundsätzlich lassen sich zwei verschiedene
Methoden für den Datenimport unterscheiden. Zum einen können INSERTAnweisungen generiert werden und zum anderen schreibt ein Werkzeug die
Daten unmittelbar auf Datenbankseiten (Load). Dieser Abschnitt stellt die
alternativen Methoden vor und begründet die getroffenen Entscheidungen.
Dabei wird vor allem Bezug zur verwendeten DB2 UDB genommen.
Die SQL-Anweisung zum Einfügen jedes einzelnen Datensatzes kann entweder von dem Datenbankwerkzeug IMPORT oder durch eine selbst programmierte Routine erzeugt und ausgeführt werden. Wesentliche Eigenschaften
dieses Verfahrens sind die Kontrolle aller Integritätsbedingungen und die
Unterstützung von Auslösern (Trigger) während des Einfügens. Weiterhin
können sowohl Tabellen als auch Indizes trotz des Imports weiter genutzt
werden und das DBMS sorgt durch das Protokollieren aller Operationen für
Datensicherheit, weshalb keine spezielle Sicherung der Daten erforderlich ist.
Nachteilig ist vor allem der zeitliche Aufwand für den Import großer Datenmengen, der unter anderem auch aufgrund des sequenziellen Aktualisierens
der Indizes entsteht.
Im Gegensatz zu der eben beschriebenen Methode werden die Daten
beim Load formatiert und anschließend direkt auf die Datenbankseiten geschrieben. Zuletzt werden die Indizes in einem einzigen Durchgang aktualisiert. Außerdem werden Multiprozessormaschinen besonders unterstützt.
Daher eignet es sich sehr gut zum Laden großer Datenmengen. Jedoch kann
vor Abschluss des Vorganges die Tabelle nicht zugegriffen werden und es erfolgt auch keine Überprüfung von etwaigen Integritätsbedingungen. Da die
Operationen auf der Datenbank nur minimal durch das DBMS protokolliert
wird, muss bei Bedarf ein Sicherungsabbild der Tabelle erstellt werden.
Für die Auswahl des Datenimportverfahrens im Rahmen der Diplomarbeit ist vor allem die Unterstützung von Geometrien von Bedeutung. Daher
wird für eine weitergehende Charakterisierung der Datenimportverfahren
auf [IBM00b] verwiesen.
Geometrien werden durch den DB2 Spatial Extender in einem proprietären Datenformat verwaltet. Dazu stellt der Spatial Extender gespeicherte
Datenbankprozeduren zur Verfügung, die eine Konvertierung aus einer textuellen oder binären Darstellung (OGC1 , ESRI) vornehmen. Zum Importieren von Geometrien müssen die Daten in einer solchen Darstellung vorliegen.
1
Open GIS Consortium
8
KAPITEL 2. ERSTELLEN DER GIS-DATENBANK
Insbesondere bedeutet dies, dass eine Verwendung der üblichen Importverfahren für Tabellen, die räumliche Objekte enthalten, nur mit wesentlich
erhöhtem Aufwand möglich ist. Die erforderlichen Arbeitsschritte beschreibt
[Hee01]; es wird dort festgestellt, dass sich nur die textuelle Darstellung der
Geometrien nutzen lässt, da bei der binären Repräsentation für jede einzelne Geometrie eine separate Datei angelegt werden muss, was aufgrund der
Anzahl nicht vom Betriebssystem effizient gehandhabt werden kann. Weiterhin müssen die Daten in temporären Tabellen und Dateien zwischengelagert
werden. Ein weiterer Nachteil ist die Beschränkung der Textdarstellung einer Geometrie auf 4000 Zeichen durch die gespeicherte Datenbankprozedur,
da bereits etwas komplexere Polygone diese Grenze überschreiten.
Die im folgenden Abschnitt beschriebene Vorverarbeitung der GDFDateien benutzt das eben vorgestellte Verfahren. Für dieses Format ist dies
sinnvoll, da die GDF-Dateien auf jeden Fall transformiert werden müssen,
damit die darin enthaltenen kartografischen Daten geeignet in die Datenbank importiert werden können.
Im Gegensatz dazu zeichnet sich gerade das MultiNet Shapefile-Format
dadurch aus, dass zu jedem beschriebenen Objekt neben den Eigenschaften
auch die dazugehörige Geometrie in einer Tabelle bzw. Datei erfasst wurde.
Das heißt, die Daten sind bereits derart als Layer aufbereitet, dass keine
weiteren Transformationen erforderlich sind. Eine Konvertierung der Geometrien in eine Textdarstellung bedeutet daher einen zusätzlichen Bedarf an
Speicherplatz und Zeit. Daher ist dieses Verfahren für dieses Datenformat
nicht empfehlenswert.
Wie in dem Abschnitt 2.3 zum MultiNet Shapefile-Format beschrieben
wird, wurde deshalb zum einen die Importfunktionalität des DB2 Spatial
Extenders verwendet und zum anderen eine gespeicherte Prozedur zum Laden von dBASE-Dateien implementiert. Diese beiden Prozeduren beruhen
auf dem Ausführen von entsprechend generierten INSERT-Anweisungen. Obwohl die Methoden langsamer arbeiten, werden Ressourcen in Form von
Speicherplatz gespart sowie die Fehleranfälligkeit reduziert, da keine zusätzlichen Konvertierungen und Zwischenspeicherungen notwendig sind.
2.2
Vorverarbeitung der GDF-Dateien
Aufgrund der Anordnung der Daten und dem gegenseitigen Referenzieren
zwischen den Rekords (Datensätzen) innerhalb einer GDF-Datei eignet sich
das GDF-Datenaustauschformat nur bedingt zum Einlesen in eine Datenbank. Bevor die GDF-Daten aus den Dateien in die Datenbank übertragen
werden können, bedarf es einer Vorverarbeitung. Diese überführt die GDFDatei in das DEL-Format, so dass eine einfachere Weiterverarbeitung mit
datenbankinternen Mitteln möglich ist. In [Hee01] wurden bereits die grundlegenden Pakete (Scanner und Parser) und ihre Funktionsweise vorgestellt.
2.2. VORVERARBEITUNG DER GDF-DATEIEN
9
Im weiteren Verlauf der Arbeit, auch mit anderen DBMS, hat es sich gezeigt, dass die Modellierung der Vorverarbeitungssoftware vor allem im Bereich der Datenausgabe verbessert werden kann. Zwar ist das DEL-Format
datenbankunabhängig, aber die Verwendung von strukturierten Datentypen, wie sie meistens von den Spatial Extendern verwendet werden, erfordert eine datenbankspezifische Ausgabe. Daher ist die Software um weitere
Pakete erweitert und stellenweise remodelliert worden.
Zunächst wird ein Überblick über die Vorverarbeitungssoftware gegeben
und das Zusammenwirken der Pakete dokumentiert. Nach der Beschreibung
des zentralen Parser-Pakets, werden die verwendeten Konzepte zur datenbankunabhängigen Ausgabe in DEL-Daten vertieft.
2.2.1
Gesamtüberblick
In diesem Abschnitt werden nach einem Gesamtüberblick zunächst die einzelnen Pakete der Vorverarbeitungssoftware vorgestellt und auf diejenigen
näher eingegangen, die nicht in späteren Abschnitten gesondert aufgegriffen
werden.
Die Daten aus einer GDF-Datei werden durch die Vorverarbeitung je
nach Rekordtyp in unterschiedliche DEL-Dateien geschrieben. Ein Rekordtyp beschreibt in einer GDF-Datei den Typ eines Datensatzes bzw. die Art
der Information näher, z. B. Koordinatendatensatz. Zum Verteilen der Daten wird die GDF-Datei zeilenweise gelesen und anschließend von einem Parser ausgewertet. Je nach Art der Daten werden diese dann in entsprechende Dateien hinausgeschrieben. Jeder Arbeitsschritt in der Vorverarbeitung
wird von einem Paket übernommen. Eine Überblick über alle Pakete gibt
das Klassendiagramm in Abbildung 2.1, wobei zur besseren Übersicht die
Import-Abhängigkeiten zu den Paketen Logbook und GDFException nicht
visualisiert wurden, da diese von den meisten anderen Paketen zur Fehlerbenachrichtigung herangezogen werden.
Das Paket Scanner kapselt den Zugriff auf die GDF-Datei gegenüber
den Parsern. Damit wird erreicht, dass die Parser keinerlei Informationen
über die physische Speicherung eines Rekords2 oder die Art des Mediums
benötigen. Der Scanner speichert dazu die jeweils aktuelle logische Zeile in
einem lokalen Puffer. Extraktionsmethoden des Scanners, z. B. readInteger(),
erlauben dann das Auslesen der einzelnen Felder aus der logischen Zeile aufgrund der Positionsangaben wie sie im GDF-Standard definiert sind. Nähere
Informationen zur Speicherung eines Rekords in einer GDF-Datei kann in
[GDF95] oder in Kurzform bei [Hee01] nachgelesen werden.
Zur Vereinfachung der Kommunikation zwischen dem Scanner und den
Parsern der Rekordtypen dient das Paket Queues. In diesem Paket wird der
abstrakte Datentyp Schlange (Queue) implementiert, wodurch das Auslesen
2
Die Länge einer Zeile in einer GDF-Datei ist auf 80 Zeichen beschränkt. Längere
Rekords müssen demnach über mehrere Zeilen verteilt werden.
10
Abbildung 2.1: Übersicht über die Pakete der Vorverarbeitungssoftware
11
sich wiederholender Datenfelder bzw. Datenfeldgruppen vereinfacht wird.
Ein weiterer Vorteil ist die Einsparung von sehr vielen Methodenaufrufen.
Die Queues transportieren dabei die aus den Datenfeldern gelesenen Werte
vom Scanner zum Parser.
Wie die Abbildung 2.1 zeigt, bildet das Paket Parser den Mittelpunkt
der Vorverarbeitungssoftware und importiert daher alle anderen. Die Klassen dieses Pakets steuern die Vorverarbeitung und kapseln dabei die Spezifikationen der Rekordtypen aus dem GDF-Standard. Einen Einblick in das
Paket gibt der Abschnitt 2.2.2.
Die Ausgabe in DEL-Dateien versteckt das Paket DelOutput vor den
Parsern. Damit lassen sich bei den Parsern die üblichen Mechanismen zur
Ausgabe von Daten in Dateien verwenden, ohne sich dabei Gedanken über
die Form einer DEL-Datei machen zu müssen. Tiefere Einblicke in die Modellierung des Pakets liefert der Abschnitt 2.2.3.
Für die Repräsentation der Geometrien wurde das Paket Spatial modelliert. Die jeweiligen Klassen speichern die Koordinaten zu den Geometrien
und lassen sich dabei über das Paket DelOutput, wie jeder andere Datentyp
auch, in eine DEL-Datei schreiben; dies ist im Zusammenhang mit der datenbankunabhängigen Ausgabe besonders wichtig. Die Klasse Polygon vereint
zusätzlich zu der Kapselung der Geometrien die Fähigkeiten, doppelte Koordinaten zu eliminieren und Ringe zu erkennen. Dadurch entstehen mehr
gültige Polygone, wie sie für die Visualisierung benötigt werden. Falls erforderlich lässt sich dieses Paket auch durch Funktionalitäten zum Validieren
der Geometrien und zur Fehlerbehebung erweitern.
Die Fehlerverwaltung geschieht mit den Paketen Logbook und GDFException und erhöhen damit die Fehlertoleranz des Programms. Diese beiden
Pakete werden von nahezu allen anderen Paketen benutzt. Das Logbook dient
zur Mitteilung möglicher Fehler an den Nutzer; dazu zählen unter anderem
nicht gesetzte Werte oder Konvertierungsfehler aufgrund einer fehlerhaften
GDF-Datei. Die Fehlernachrichten werden wahlweise auf dem Bildschirm
oder in eine Datei ausgegeben. Die im Paket GDFException definierten Ausnahmen erlauben eine Auswertung der Fehlerursache und eine adäquate Reaktion darauf.
2.2.2
Das Parser-Paket
Zwischen Scanner- und DelOutput-Paket eingebunden, steuern die Klassen
des Parser-Paket die Vorverarbeitung und kapseln die Spezifikationen des
GDF-Standards. Dieser Abschnitt vertieft den Aufbau dieses zentralen Paketes. Das Klassendiagramm in Abbildung 2.2 gibt einen Überblick über die
Beziehungen zwischen den Klassen innerhalb diese Pakets.
Im Vergleich zum ersten Entwurf in der Studienarbeit wurde dieses Paket
erheblich verändert. Das neue Modell ist wesentlich modularer aufgebaut, so
dass sich die Integration von Parsern für hinzugenommene Rekordtypen und
12
Abbildung 2.2: Das Parser-Paket
13
die Wartung des Quellcodes vereinfacht. Zudem sind die Struktur des Pakets
und das Zusammenwirken der Klassen einfacher zu erfassen. Im Zusammenhang mit der Modularisierung wurde auch das Paket Maps extrahiert und
separat modelliert. Es wird zur Auflösung von Referenzen der Koordinaten
von Knoten (nodes), Linien (edges) bzw. Flächen (faces) benötigt. Für
eine genaue Beschreibung der Funktionsweise von den Referenzen wird auf
[GDF95] oder [Hee01] verwiesen.
Wesentlicher Bestandteil für die Handhabung der vielen unterschiedlichen Rekordtypen ist die Klasse RecordParser. Von dieser abstrakten Basisklasse leiten sich die Klassen für das Parsen der einzelnen Rekordtypen ab,
wobei jede Klasse für einen Rekordtyp zuständig ist. In diesem Sinne sind die
Spezifikationen für die Rekordtypen aus dem GDF-Standard in den Kindklassen kodiert. In Abbildung 2.2 sind nur die implementierten Rekordtypen
dargestellt.
Alle vom RecordParser abgeleiteten Klassen müssen die Methode parseRecord() implementieren. Beim Aufruf dieser Methode übernimmt der spezifische Parser die Kontrolle des Scannens und extrahiert die notwendigen
Datenfelder eines Rekords. Die herausgezogenen Daten werden dann in ein
oder mehrere DEL-Dateien geschrieben. Die Kontrolle gibt er erst wieder
ab, wenn ein anderer Rekordtyp auftritt oder das Dateiende erreicht ist.
Dann wird vom Parser die Steuerung je nach Rekordtyp an den nächsten
Rekordparser weitergegeben. Dadurch werden wiederholte Methodenaufrufe
und Ojektinstanziierungen vermieden.
Da zu einer Zeit nur eine Instanz eines RecordParser-Kindes existiert,
wird eine Struktur benötigt, die global wichtige Informationen bezüglich
einer GDF-Datei ständig bereithält. Zu diesen Informationen gehören zum
Beispiel die VolumenID und DatasetID, die in fast jeder DEL-Datei mit ausgegeben werden, sowie die verschiedenen Map-Instanzen. Die Klasse GDFInfo, von der nur eine Instanz existiert, bietet den Kindinstanzen die Möglichkeit Informationen an andere weiterzugeben. Die Klassen Parser und RecordParser erhalten über eine Referenz zu dieser Instanz Zugang zu den
globalen Daten.
2.2.3
Die Ausgabe in die DEL-Dateien
Mit der Einführung eines anderen DBMS ändert sich auch die Kodierung
von Geometrien durch den zum DBMS gehörenden Spatial Extender. Da in
der ersten Version der Vorverarbeitungssoftware das Ausgabeformat für die
DEL-Dateien fest in die Rekordparser hineincodiert war, ergaben sich durch
einen Wechsel aufwändige Adaptionsarbeiten. Damit sich der Aufwand auf
ein Minimum reduziert, wurde die Ausgabe in DEL-Dateien durch das Paket
DelOutput gekapselt.
Dieser Abschnitt konzentriert sich hauptsächlich auf die Ausgabe der
Datenfelder in DEL-Dateien. Insbesondere wird gezeigt, inwieweit eine Ad-
14
aption der Vorverarbeitungssoftware an andere DBMS einfach zu realisieren
ist. Dazu wird der Datenfluss zwischen den Klassen der unterschiedlichen
Pakete eingehender betrachtet.
Global gesehen, bewegen sich die Daten aus der GDF-Datei über den
Scanner zum Parser. Nach dem Parsen werden die extrahierten Informationen der Ausgabe übergeben. Diese Stufen lassen sich im Klassendiagramm in
Abbildung 2.3 wiederfinden. So gesehen, hat sich der Datenfluss im Vergleich
zu der Modellierung in [Hee01] nicht weiter verändert. Jedoch wurden in dem
neu entworfenen Modell die einzelnen Stufen zum Teil nochmals verfeinert
modelliert, so dass diese leichter zu warten und Anpassungen einfacher zu
realisieren sind.
Abbildung 2.3: Zusammenwirken der wichtigsten Klassen
Der Zugriff auf eine GDF-Datei wird durch die Klasse Scanner realisiert,
die auch die Zugriffsmethoden zur Navigation und zum Auslesen von Datenfeldern implementiert (vgl. Abbildung 2.3). Gesteuert wird das Scannen
durch die Klassen Parser und RecordParser, wobei die Klasse Parser als Verteiler dient. Entsprechend dem aktuellen Rekordtyp wird eine Instanz einer
Kindklasse des RecordParsers erzeugt und die Kontrolle mittels der Methode
parseRecord() an diese übergeben. Erst nachdem der Block mit demselben
Rekordtyp abgearbeitet wurde, wird die Kontrolle zurückgegeben.
Wie bereits festgestellt, muss zum Erreichen von Datenbankunabhängig-
15
keit die Ausgabe in die DEL-Dateien von dem Parse-Vorgang entkoppelt
werden. Dazu wurde ein neues Paket geschaffen, dass die Formatierung der
Ausgabe übernimmt. Mit der Basisklasse DelOutput wurde die Ausgabe in
DEL-Dateien für Standarddatentypen realisiert. Da sich für die Standarddatentypen selten Unterschiede ergeben, kann diese Basis im Allgemeinen für
alle DBMS übernommen werden. Besonders kritisch ist die Formatierung
der strukturierten Datentypen oder die Kodierung von Geometrien, weshalb an dieser Stelle ein passendes Entwurfsmuster eingesetzt werden muss
– eine Lösung besteht in der Verwendung einer abstrakten Fabrik (abstract
factory). Ein Entwurfsmuster ist eine Beschreibung zusammenarbeitender
Objekte und Klassen, die maßgeschneidert sind, um ein allgemeines Entwurfsproblem in einem bestimmten Kontext zu lösen.
Das Entwurfsmuster abstrakte Fabrik – genau genommen handelt es sich
um ein Erzeugungsmuster – definiert eine Schnittstelle zum Erzeugen von
Familien verwandter oder voneinander abhängiger Objekte, ohne ihre konkreten Klassen zu benennen. Es kann aus verschiedenen Gründen angewandt
werden: wenn das System unabhängig davon sein soll, wie seine Produkte
erzeugt, zusammengesetzt und repräsentiert werden, oder wenn das System
mit einer aus mehreren Produktfamilien konfiguriert werden soll.[GHJV96]
Im folgenden Abschnitt werden die Strukturbestandteile der Fabrikmethode
anhand des vorliegenden Designs erläutert.
Die Basis des Entwurfsmusters bilden eine abstrakte Fabrik und ein abstraktes Produkt. Die abstrakte Fabrik deklariert eine abstrakte Schnittstelle für Operationen, die Produktobjekte erzeugen. Die Schnittstelle für einen
bestimmten Typ von Produktobjekten wird in dem abstrakten Produkt deklariert. In dem vorliegenden Modell geben die Klassen SpatialDelFactory
und SpatialDel die Schnittstellen vor. Da die Ausgabe der Standarddatentypen im Allgemeinen bereits datenbankunabhängig ist, wurde SpatialDel als
Unterklasse von DelOutput modelliert.
Auf die durch die obigen Schnittstellen definierte Grundlage setzen sowohl die konkrete Fabrik und das konkrete Produkt auf. Eine konkrete Fabrik wie z. B. DB2DelFactory implementiert die Operation zur Erzeugung
konkreter Produktobjekte (createSpatialDel()). Die von der konkreten Fabrik erzeugten konkreten und datenbankspezifischen Ausgabeinstanzen, z. B.
DB2Del, realisieren die Schnittstelle des abstrakten Produktes – also im Detail die Speicherung von Geometrien in DEL-Dateien (vgl. Abbildung 2.3).
Je nach DBMS können also von SpatialDel Klassen abgeleitet werden, die
die abstrakten Methoden datenbankspezifisch implementieren.
Bei der Nutzung dieses Entwurfsmuster beschränkt sich die Applikation
auf die Verwendung der Schnittstellen der abstrakten Fabrik und des abstrakten Produktes. Damit wird die Erzeugung von Produktobjekten auf
die Ableitung der abstrakten Fabrik verlagert. Dadurch reduziert sich die
Anzahl der Quellcodeänderungen erheblich und erlaubt eine einfache Umstellung der Vorverarbeitung auf andere DBMS.
16
2.3
Verwendung des MultiNet Shapefile-Format
Seit kurzem bietet Tele Atlas ihre Daten außer im GDF-Dateiformat auch
im MultiNet Shapefile-Format an. In diesem Datenformat werden wie auch
bei GDF-Dateien räumliche Objekte und die dazugehörigen Informationen zusammen gespeichert. Im Gegensatz zum GDF-Standard definiert die
Shapefile-Spezifikation kein allgemeines Referenzmodell für die kartografischen Daten, sondern beschreibt ausschließlich die Form der Speicherung in
Dateien. Bezogen auf die Terminologie von Datenbanksystemen repräsentiert eine Shape-Datei eine Tabelle mit einer Spalte räumlichen Datentyps.
Durch diese Art der Speicherung lassen sich die kartografischen Daten ohne
spezielle Vorverarbeitung einfach selektieren und zugreifen.
In den folgenden Abschnitt wird zunächst auf die Shapefile-Spezifikation
eingegangen und anschließend die Speicherung der Informationen im Shapefile-Format beschrieben. Dabei liegt der Schwerpunkt auf den zur Realisierung des Webservice notwendigen Daten. Zuletzt wird die Vorgehensweise
und das Werkzeug zum Laden der Daten in die Datenbank erläutert.
2.3.1
Die Shapefile-Spezifikation
Das weit verbreitete Shapefile-Format wurde von ESRI, Inc. für die Speicherung von kartografischen Daten entwickelt. Im folgenden Teil werden die
grundlegenden Bestandteile der Shapefile-Spezifikation [ESR98] vermittelt
und auf die Verknüpfung von räumlichen Objekten mit den zugehörigen
Informationen eingegangen.
Wenn von der Speicherung räumlicher Objekte im Shapefile-Format gesprochen wird, so ist die Kombination von drei korrelierten Dateien gemeint
– einer Shape-Datei (.shp3 ), einer Indexdatei (.shx) und einer dBASE-Datei
(.dbf). Dabei enthält die Shape-Datei die Koordinaten der räumlichen Objekte und die dBASE-Datei zusätzliche Informationen zu einem Objekt wie
zum Beispiel Namen oder Identifikatoren. Die Indexdatei enthält Metadaten
zum präzisen Zugriff auf die Rekords in der Shape-Datei.
Ein Merkmal der Speicherung von räumlichen Objekten im ShapefileFormat ist die Auslagerung der Koordinaten in eine separate Datei. Dies ist
sinnvoll, da für die einzelnen räumlichen Objekte, außer bei Punktobjekten,
der Speicherplatzbedarf stark schwankt. Durch diese Aufteilung können die
zusätzlichen Informationen zu einem räumlichen Objekt in einem üblichen
Datenbankdateiformat wie zum Beispiel dem dBASE-Dateiformat verwaltet
werden.
Zwischen der dBASE-Datei und der Shape-Datei besteht eine 1:1-Beziehung; zu dem i-ten Rekord in der Shape-Datei korrespondiert das i-te Rekord
in der dBASE-Datei und umgekehrt. Den schnellen Zugriff auf die Koordinaten der räumlichen Objekte gestattet die Indexdatei. Der i-te Rekord der
3
In Klammern steht die verwendete Dateiendung.
2.3. VERWENDUNG DES MULTINET SHAPEFILE-FORMAT
17
Indexdatei enthält den Offset und die Länge des i-ten Rekords in der ShapeDatei. Die Vektorkoordinaten werden dabei binär kodiert gespeichert. Da
diese Kodierung keinen weiteren Einfluss auf die Diplomarbeit hat, wird für
detaillierte Angaben auf die technische Beschreibung des Shapefile-Formats
[ESR98] verwiesen.
2.3.2
Das MultiNet Shapefile-Format
Der prototypisch zu entwickelnde Webservice ermittelt zu einem vorgegebenen Standpunkt nahe gelegene Einrichtungen, die für den Nutzer von besonderem Interesse sind (POIs). Dazu ist es erforderlich, zunächst alle interessierenden POIs in der Umgebung des Standortes zu bestimmen und anschließend die Adressinformationen zusammenzutragen oder auch eine Route zu
dem ausgewählten Servicepunkt zu berechnen. Von dem Standpunkt der
Realisierung des Webservice ausgehend, wird nachfolgend das Datenmodell
der GIS-Datenbank vorgestellt.
Das MultiNet Shapefile-Format basiert auf der ESRI Shapefile-Spezifikation und bietet unter anderem kartografische Informationen zum Straßennetz, zu POIs und Landnutzung. Vom allgemeinen Referenzmodell des GDFStandards 3.0 [GDF95] wurde das vom MultiNet Shapefile-Format verwendete physische Datenmodell abgeleitet. Das Referenzmodell beschreibt die
Transformation von Objekten der realen Welt in ihre Datenbankrepräsentation und bildet damit das konzeptionelle Modell. Die wichtigsten Aspekte
dieses Referenzmodells werden an dieser Stelle kurz zusammengefasst, um
anschließend das physische Datenmodell aus dem Blickwinkel des zu realisierenden Webservice zu betrachten.
Ein Objekt der realen Welt, z. B. eine bestimmte Straße, wird als ein
Feature bezeichnet, das einem Oberbegriff (Feature-Klasse) zugeordnet
werden kann. Solche Oberbegriffe sind zum Beispiel Straßen und Fährverbindungen, Verwaltungsgebiete oder Gewässer. Je nach Abstraktion der Darstellung wird ein Feature als Punkt-, Linienzug- oder Gebietsfeature interpretiert. Einem Feature können Eigenschaften zugeordnet werden und es
kann semantisch in Beziehung zu anderen Feature stehen. Beispielsweise
spiegelt sich die Aussage ein Service liegt an einer Straße in einer Beziehung
zwischen den Feature Service und Straße wider.
Die Verwendung des GDF-Standards bietet einen umfangreichen Katalog
an vordefinierten Feature- und Beziehungstypen. Es ist aber auch möglich,
diesen Katalog um eigene Definitionen zu erweitern. Ausführlichere Darstellungen zum allgemeinen Referenzmodell finden sich in [GDF95, Hee01]
und die Regeln zur Erfassung von Objekten der realen Welt können in
[Tel00a, Tel00b] nachgelesen werden.
Das MultiNet Shapefile-Format nutzt die Kategorisierung der Feature im
GDF-Standard zur Gruppierung der kartografischen Daten in Layer; insgesamt werden 13 Layer definiert. Diese umfassen beispielsweise das Verkehrs-
18
netz inklusive Geokodierungs- und Routinginformationen, markante Punkte
(POIs) oder Bebauungs- und Verwaltungsgebiete, um nur die wichtigsten zu
nennen.
Im Kontext der Diplomarbeit werden nur die für die vorgesehene Anwendung wichtigsten Layer mit ihrem physischen Datenmodell detailliert
vorgestellt. Den gesamten Umfang der Layerspezifikationen liest man in den
Tele Atlas Dokumentationen [Tel01a, Tel01b] nach.
Verkehrsnetz Layer
Der Schwerpunkt der Tele Atlas Daten liegt auf der Erfassung von Informationen über das Straßenverkehrsnetz in Europa und den USA. Neben
der Darstellung von Straßenverbindungen ermöglicht dieser Layer Routing
und die Konvertierung von Adressen in Koordinaten (Geokodierung). Unter
anderem wird hier auch die Beschilderung der Straßen erfasst.
In dem Ausschnitt aus dem physischen Datenmodell in Abbildung 2.4
wird der Layer Verkehrsnetz gezeigt, der alle Daten zur Visualisierung des
Straßennetzes speichert. Um die Übersicht zu erhöhen, wurden die Attribute ausgeblendet. Eine genaue Vorstellung über die Erfassung von Straßen
laut GDF-Standard unterstützt das Verstehen der Abbildung. Daher werden
diese Aspekte des allgemeinen Referenzmodells kurz ausgeführt.
Abbildung 2.4: Verkehrsnetz Layer (Ausschnitt) [Tel01b]
19
Die Erfassung der Objekte der realen Welt erfolgt auf unterschiedlichen
Abstraktionsebenen. Auf unterster Ebene (Level 0) bestehen alle Feature
aus einem Netzwerk von Linien und Knoten, wobei jede Linie von Knoten
begrenzt wird. Diese werden auf dem Level 1 zu Straßenelementen (road
elements) und Einmündungen (junctions) zusammengefasst und zur detaillierten Visualisierung verwendet. Auf der nächsthöheren Abstraktionsebene
(Level 2) entstehen Straßen (roads) aus ein oder mehreren Straßenelementen und Kreuzungen (intersections) aus Einmündungen und gegebenenfalls
Straßenelementen. Bei Letzterem können Straßenelemente zum Beispiel bei
der Erfassung von Autobahnausfahrten auftreten. Grundsätzlich wird jede
Straße durch eine Kreuzung an jedem Ende begrenzt.
Das kurze Beispiel der Erfassung einer Autobahn soll den Unterschied
zwischen Level 1 und 2 illustrieren. Auf dem Level 1 wird jede Fahrtrichtung
durch ein eigenes Straßenelement repräsentiert, die jedoch auf dem Level 2
zu einer einzigen Straße verschmelzen. Die zweite Abstraktionsebene findet
vor allem beim groben Routing Verwendung, das keine genauen Abbiegevorgänge einbezieht (z. B. Überlandfahrten auf Autobahnen). Während Level 0 nicht mit dem MultiNet Shapefile-Format ausgeliefert wird, kann auf
Daten der Level 1 und 2 zugegriffen werden.
Abbildung 2.4 zeigt die Verwaltung des Straßennetzes auf den Leveln
1 und 2. Hier lassen sich fast alle oben beschriebenen Elemente wiederfinden. Die Tabelle Straßennetz4 speichert die erste Abstraktionsebene, wobei
die Einmündungen nicht explizit modelliert wurden. Die Kreuzungen und
Straßen auf dem Level 2 werden durch die Tabellen Level 2 Straße und Kreuzung repräsentiert. Die übrigen Tabellen unterstützen die Modellierung von
Kreuzungen.
In der Tabelle Kreuzung sind die Eigenschaften zu Kreuzungen zusammengefasst. Eine Kreuzung kann sich aus ein oder mehreren Einmündungen
und Straßenelementen zusammensetzen. Die Bestandteile einer Kreuzung
werden in der Tabelle Kreuzung Index verwaltet. Handelt es sich bei der
Kreuzung um eine Autobahnausfahrt kann zusätzlich der Mittelpunkt erfasst sein. Die Spalte elemID von der Tabelle Kreuzung Index referenziert
in der Straßennetz-Tabelle die ID eines Straßenelement oder die ID einer
Einmündung5 , je nach Feature-Klasse.
Die zu einer Straße (Level 2) kombinierten Straßenelemente (Level 1)
werden in der Tabelle Level 2 Straße beschrieben. Dabei werden die Bestandteile (Straßenelemente oder Kreuzungen) einer Straße durchnummeriert aufgelistet, wobei das erste und letzte Teil stets Kreuzungen sind. Die
elemID referenziert je nach Feature-Klasse des Teilelements entweder das
Straßennetz oder den Kreuzungsindex.
4
Die zwei Buchstaben hinter dem Namen der Tabelle gibt die Kennung wieder, wie sie
von Tele Atlas verwendet wird.
5
Anmerkung zu Abbildung 2.4: Alle Straßenelemente sind gerichtet und unterscheiden
daher die begrenzenden Einmündung in F JnctID (Start) und T JnctID (Ende).
20
Points of Interest Layer
Für die Selektion der nahe liegenden Servicepunkte bezüglich eines Standortes bietet sich das Layer mit den Points of Interest (POI) an. Dieser Layer
stellt die Informationen zu den unterschiedlichen markanten Gebäuden oder
Serviceeinrichtungen zur Verfügung. Solche Einrichtung sind zum Beispiel
Krankenhäuser, Hotels, Restaurants oder Tankstellen. Im Folgenden werden nun die Zusammenhänge zwischen den POIs und dem Verkehrsnetz
beschrieben.
Abbildung 2.5 zeigt einen Ausschnitt des POI Layers aus dem physischen
Datenmodell. Da die Attribute der Tabellen in diesem Kontext weniger wichtig sind, wurden diese nicht in die Abbildung mit aufgenommen. Neben den
zentralen Tabellen Straßennetz und POI beschreiben die übrigen Tabellen
Zugangsbeziehungen zwischen Straßenelementen und POIs.
Abbildung 2.5: Points of Interest Layer (Ausschnitt) [Tel01b]
Die Tabelle POI enthält die wichtigsten zu einem POI erfassten Eigenschaften und bildet den Ausgangspunkt, wenn nach bestimmten Einrichtungen gesucht wird. Da einige Einrichtungen über mehrere Zugänge von
verschiedenen Straßen aus verfügen, werden diese in einer separaten Tabelle POI Zugang verwaltet. Die Zugänge können zu einer Einmündung eines
Straßenelements im Straßennetz führen. Zusätzlich zu den Zufahrten der
POIs kann die am nächsten gelegene Straße (closest transportation element
ID) erfasst sein. Falls keine Zufahrt zu einem POI definiert ist, ist es stattdessen möglich, die Position des am nächsten gelegenen Straßenelements
zu verwenden. Teilweise sind in der Realität Services in anderen integriert,
z. B. ein Restaurant in einem Hotel, oder lassen sich nur über andere Einrichtungen nutzen. Die Beziehung zwischen zwei POIs (service belongs to
service) wird durch die Tabelle POI Beziehung ausgedrückt. Über die ID
eines POIs aus der POI-Tabelle lassen sich dazugehörige (ID ←→ P OIID)
21
oder untergeordnete POIs (ID ←→ belP OIID) ermitteln.
2.3.3
Einlesen der dBASE- und Shape-Dateien
Das MultiNet Shapefile-Format bildet eine Alternative zum vorher besprochenen GDF-Dateiformat. Die bereits durch den Produzenten durchgeführte
Aufteilung der Daten in Layer reduziert den Aufwand für die Vorverarbeitung der Daten erheblich. Anders als beim GDF-Dateiformat ist es nicht
mehr erforderlich, die gesamten Daten zu parsen und für das Laden in die
Datenbank aufzubereiten. Abgesehen davon, dass die Attribute der Feature
leichter zugänglich sind, entfällt insbesondere die Dereferenzierung von IDs
(vgl. [Hee01]), um die Koordinaten für ein räumliches Objekt zu ermitteln.
Im Zusammenhang mit dem in der Diplomarbeit verwendeten DB2 Spatial
Extender wird der Import der Daten durch die Unterstützung des ShapefileFormats vereinfacht.
Wie bereits beschrieben, werden die kartografischen Daten auf Layer aufgeteilt. Eine Datei im Shapefile-Format speichert jeweils nur die Daten einer
relationalen Tabelle in einer Datei, weshalb zu einem Layer mehrere ShapeDateien gehören. Auf einer höheren Ebene sind die Daten aufgrund geografischer Zusammengehörigkeit in einem Verzeichnis zusammengefasst; das
Kriterium für die Gruppierung sind Verwaltungsgrenzen. Insgesamt umfasst
die komplette Datensammlung für ein Verwaltungsgebiet (ein Verzeichnis)
198 Dateien.
Zur Automatisierung des Datenimports wurde ein Werkzeug modelliert
und implementiert. Das Hauptanliegen bei der Modellierung des Werkzeugs
war einfache Bedienbarkeit und Konfiguration sowie eine Portierung auf andere Betriebssysteme und Datenbanken mit geringem oder gar keinem Einfluss auf die Quellen. Zugleich wurde ein hoher Datendurchsatz angestrebt.
Dieser Abschnitt beschreibt die verwendeten Konzepte und das zugrunde
liegende Modell des Werkzeugs, sowie die speziellen Anpassungen, die aufgrund der Verwendung des DB2 Spatial Extenders erforderlich sind.
Das Use-Case-Diagramm in Abbildung 2.6 gibt einen Überblick über
den Importvorgang. Insgesamt lassen sich beim Import zwei beteiligte Systeme identifizieren, das Importwerkzeug und die GIS-Datenbank. Der Nutzer
bedient sich des Importwerkzeugs, um die Dateien des MultiNet ShapefileFormats in die Datenbank einzulesen. Das Importwerkzeug bereitet den Import in die Datenbank vor und gibt den Auftrag an die Datenbank weiter.
Dabei wird aus Sicht des Importwerkzeugs davon ausgegangen, dass das
System GIS-Datenbank in der Lage ist, dBASE- und Shape-Dateien einzulesen.
Nicht jede Erweiterung eines DBMS um die Verwaltung räumlicher Daten kann Shape-Dateien verarbeiten und nicht jedes DBMS unterstützt
das dBASE-Format. Daher muss in solchen Datenbankmanagementsystemen zunächst die entsprechende Funktionalität zum Beispiel als gespeicherte
22
Abbildung 2.6: Import vom MultiNet Shapefile-Format
Prozedur integriert werden. Der in der Diplomarbeit verwendete DB2 Spatial Extender ergänzt DB2 UDB um die Fähigkeit, Shape-Dateien einlesen
zu können. Jedoch wird das dBASE-Format nicht unterstützt und erforderte die Implementierung eines entsprechenden Importmoduls. Daher wird
zunächst auf diesen Punkt näher eingegangen, um daran anschließend die
Konzepte des Importwerkzeugs zu erklären.
Erweiterung der Importfunktionalität des DBMS
Zum Zwecke der Erweiterung der Importmöglichkeiten von DB2 UDB um
das dBASE-Format wurde eine dementsprechende gespeicherte Prozedur
sp import dbf() implementiert. Diese Prozedur nimmt einen Dateinamen
und den vollständig qualifizierten Namen einer Tabelle als Eingabe, um dann
die Daten aus der Datei in die spezifizierte Tabelle zu laden.
Für das Extrahieren der Daten aus der dBASE-Datei wurde die unter GNU LGPL6 stehende C-Bibliothek Shapefile C Library V1.2 von Frank
Warmerdam [War01] nach vorheriger Modifizierung eingesetzt. Das dBASEImportmodul wurde unter Benutzung des Call Level Interfaces (CLI) implementiert und ist daher einfach auf andere Datenbanken portierbar. Um
den Import der Datei zu beschleunigen, wurde zum einen die Implementierungssprache C ausgewählt und zum anderen erfolgt die Datenübertragung
zur Datenbank in großen Blöcken.
Obwohl die Daten mittels langsamen INSERT-Anweisung an die Datenbanksystem geschickt werden, wird eine Beschleunigung des Imports durch
6
GNU Library General Public License
23
die gleichzeitige Übertragung mehrerer Rekords an die Datenbank erreicht.
Speziell bei den großen Datenmengen verringert sich Anzahl der INSERTAufrufe erheblich (vgl. Abbildung 2.7). Die Anzahl der gleichzeitig übertragenen Rekords ist parametrisierbar und dient gleichzeitig als commit-Punkt.
2x INSERT
Bulk
Gespeicherte
Prozeduren
40.000x INSERT
Einzeln
Daten−
bank
Abbildung 2.7: Aufrufvarianten der INSERT-Anweisung
Automatisierung des Importvorganges
Nachdem die Datenbank sowohl Shape- als auch dBASE-Dateien importieren kann, wird abschließend das Importwerkzeug in den wichtigsten Punkten dokumentiert. Das Importwerkzeug ermöglicht es einem Nutzer, Dateien
des MultiNet Shapefile-Formats automatisiert in die Datenbank zu laden.
Das Resultat ist ein einfach zu bedienendes Werkzeug, das für verschiedene
DBMS und räumliche Datenbankerweiterungen konfiguriert werden kann.
Weiterhin ist es mit wenigen oder gar keinen Änderungen im Quellcode
möglich, beliebige SQL-Anweisungen (z. B. die Erzeugung oder Registrierung von gespeicherten Prozeduren) einzubinden, falls keine Einschränkungen durch das DBMS vorliegen. Das Importwerkzeug wurde prototypisch für
DB2 UDB konfiguriert, wobei zusätzlich eine automatisierte Vorbereitung
einer frischen“ Datenbank für die Nutzung mit dem DB2 Spatial Extender
”
integriert wurde.
Abbildung 2.8 visualisiert die Aufteilung der Klassen auf die verschiedenen Pakete. Auf der obersten Ebene besteht das Importwerkzeug aus den
Paketen teleatlas, database und configurator, wobei das letztere ausschließlich
Basisklassen zur Verarbeitung von XML-Konfigurationsdateien enthält. Der
mit dem Nutzer kommunizierende Teil befindet sich im Paket teleatlas. Die
Klassen in diesem Paket dienen dem Einlesen der allgemeinen Konfiguration, dem Bestimmen der zu importierenden Dateien und dem Beauftragen
des DBMS zum Laden der gefundenen Dateien. Damit übernimmt dieses
Paket die Steuerung des Importvorganges. Das Paket database beinhaltet
die Logik zum Verbindungsaufbau zur Datenbank und zur Ausführung von
SQL-Anweisungen. Zusätzlich definiert es die abstrakte Basisklasse zum Importieren der dBASE- und Shape-Dateien. In diesem Paket sind die Pakete
sql zur Ausführung von SQL-Prozessen und db2 mit den DB2 UDB spezifischen Implementationen der abstrakten Klassen enthalten. Die Modellierung
24
der letzten beiden Pakete wird im Folgenden vorgestellt. Dabei befasst sich
ein Paragraf speziell mit den zusätzlichen Vorbereitungen für Einsatz des
DB2 Spatial Extender.
Abbildung 2.8: Pakete des Importwerkzeugs
Das Importwerkzeug wurde in der Programmiersprache Java geschrieben. Diese Wahl hat vernachlässigbaren Einfluss auf die Performanz des
Datenimports, da dieser separat durch gespeicherte Datenbankprozeduren
realisiert ist. Zugleich lässt sich das Importwerkzeug später ohne viel Aufwand um eine grafische Benutzeroberfläche (GUI) erweitern.
Paket teleatlas Das Klassendiagramm in Abbildung 2.9 zeigt einige Klassen des Pakets teleatlas mit den wesentlichen Memberfunktionen sowie die
Verknüpfung mit der Datenbankfunktionalität über die Klassen DbFileLoader und SQLProcess. Das Paket bildet die Schnittstelle zum Nutzer und
hat die Aufgabe, die Namen aller zu importierenden Dateien zu ermitteln
und für jede den Importauftrag an die Datenbank weiterzuleiten. Des Weiteren wird hier die allgemeine Konfiguration ausgelesen und dem System zur
Verfügung gestellt.
Da der größte Teil der Konfiguration über XML-Dateien abgewickelt
wird, muss der Klasse ImportTeleatlas nur der Pfad zu den Dateien des Mul-
25
Abbildung 2.9: Das Paket teleatlas
tiNet Shapefile-Formats übergeben werden. Nach Initialisierung der Klasse
übernimmt die Methode ImportTeleatlasFiles() die Kontrolle und erzeugt
einen Iterator für die Dateien im spezifizierten Verzeichnis. Der Iterator
TeleatlasFileIterator durchsucht rekursiv das Verzeichnis nach Dateien des
Typs dBASE oder Shape. Bevor je nach Typ der gefundenen Datei die entsprechende Importfunktion der Datenbank aufgerufen wird, werden gegebenenfalls die Tabellen mittels eines SQL-Prozesses in der Datenbank angelegt.
Die Funktionsweise von SQL-Prozessen wird später separat erläutert.
Da der Import selbst datenbankspezifisch ist, wurde bei der Implementierung der Methode ImportTeleatlasFiles() die abstrakte Basisklasse DbFileLoader eingesetzt, die die Methoden importDBFFile() und importSHPFile()
der Anwendung zur Verfügung stellt und damit Datenbankfunktionalität
kapselt. In der allgemeinen Konfiguration des Importwerkzeugs muss angegeben werden, welche konkrete Ableitung von DbFileLoader verwendet
wird. Der Vorteil dieser Vorgehensweise ist, dass ohne Codeänderung eine
Abwandlung des Importverfahrens in die Datenbank möglich ist. Dies umfasst nicht nur das Verwenden eines anderen DBMS, sondern es können für
dasselbe DBMS unterschiedliche Strategien entwickelt und getestet werden.
Für das in der Diplomarbeit verwendete DBMS wurde eine Ableitung von
DbFileLoader implementiert, die für Shape-Dateien die gespeicherte Proze-
26
dur gse import shape() des DB2 Spatial Extender und für dBASE-Dateien
die oben beschriebene Prozedur sp import dbf() nutzt.
Die für alle Datenbanken notwendigen Einstellungen werden über die
Klasse ImportConfigurator zugänglich gemacht. Dabei wird die mittels einer
XML-Datei gespeicherte Konfiguration in unterschiedliche Abschnitte unterteilt, denen jeweils eigene Verwaltungsklassen zugeordnet sind. Die Struktur
der XML-Datei und weiterführende Erklärungen zur allgemeine Konfiguration befinden sich in Anhang A.1.2.
Paket database Alle Kontakte zur Datenbank werden über das Paket database abgewickelt. Dies umfasst den datenbankspezifischen Auf- und Abbau
von Datenbankverbindungen und das Ausführen von SQL-Anweisungen jeglicher Art, insofern keine Einschränkungen aufgrund des DBMS vorliegen.
Zum einen lassen sich einzelne SQL-Anweisungen absetzen und zum anderen ist es möglich, vorher zu SQL-Prozessen zusammengestellte Kommandos
abzuarbeiten. Nach der Beschreibung der Handhabung von Datenbankverbindungen wird näher auf SQL-Prozesse eingegangen.
Eine Übersicht über die wichtigsten Elemente des Pakets database gibt
das Klassendiagramm in Abbildung 2.10. Das Kernstück dieses Pakets ist die
Klasse DbConnector, die die Verbindung zur Datenbank unterhält und unter
anderem für das Ausführen von SQL-Anweisungen zuständig ist. Die datenbankseitigen Parts der allgemeinen Konfiguration werden durch die Klassen
DatabaseConfigurator und SpatialConfigurator sowie durch die Klasse SQLConfigurator des Pakets sql dem System zur Verfügung gestellt. Die bereits
vorgestellte Klasse DbFileLoader ist ebenfalls diesem Paket zugeordnet. Auf
diese Klasse wird nicht weiter eingegangen, sondern sie wurde nur zur Einordnung in den Datenbankkontext mit in die Abbildung aufgenommen. Das
in diesem Paket enthaltene Paket sql enthält die Klassen zur Realisierung
von SQL-Prozessen. Weiterhin befindet sich hier das Paket DB2, das die
datenbankspezifischen Klassen für DB2 UDB zusammenfasst.
Die Konstruktion der URL zum Verbindungsaufbau zu einer Datenbank aus den Angaben Datenbankname, Port, usw. wird von den JDBCTreiberherstellern individuell gestaltet. Damit nun das Importwerkzeug auch
zu verschiedenen DBMS Verbindung herstellen kann, benutzt der DbConnector die abstrakte Basisklasse DbConnection, die eine Methode zum Herstellen der Datenbankverbindung deklariert. Der Name der zu verwendenden
konkreten Implementierung wird in der allgemeinen Konfiguration angegeben (vgl. Abschnitt A.1.2).
Es existiert nur eine Instanz der Klasse DbConnector, die in der jetzigen
Implementation auf genau eine Datenbankverbindung zurückgreift. In einem
anderen Kontext ist es auch vorstellbar, dass ein Pool mit mehreren Verbindungen verwaltet wird. Die Anwendung, in diesem Fall DbFileLoader, erhält
keinen direkten Zugriff auf das Handle der Datenbankverbindung, sondern
27
Abbildung 2.10: Das Paket database
greift über Methoden der Klasse DbConnector darauf zu. Damit wirken sich
Änderungen im Design bei der Verwaltung der Datenbankverbindung nicht
auf die Anwendungen aus.
Die Klassen DatabaseConfigurator und SpatialConfigurator gestatten den
Zugriff auf die Bereiche der Datenbankkonfiguration und der Konfiguration
der räumlichen Erweiterung (vgl. Anhang A.1.3).
Paket sql Eine Eigenschaft des MultiNet Shapefile-Formats ist, dass außer den Spaltennamen und den Datentypen der Spalten keine weiteren Informationen gespeichert sind. So sind keine Primär- oder Fremdschlüssel
definiert. Im Allgemeinen müssen die Spalten des Primärschlüssels explizit als NOT NULL deklariert werden, weshalb eine vollautomatische Generierung der Tabellen nicht möglich ist. Zur Lösung des Problems wurden SQLProzesse implementiert. Diese ermöglichen es dem Benutzer, auf sehr einfachem Weg SQL-Anweisungen aus Dateien an festgelegten Punkten in den
Importvorgang einzubinden. Auch bei der Implementierung eigener Routi-
28
nen vereinfachen diese den Zugriff auf SQL-Dateien. Eine hervorzuhebende
Eigenschaft von SQL-Prozessen ist die Fähigkeit, Zeichenketten in den SQLAnweisungen zur Adaption an verschiedene DBMS substituieren zu können.
Insbesondere wird im Folgenden dieser Mechanismus und dessen Anwendung
im Importwerkzeug vorgestellt.
Die gebräuchlichsten Datentypen lassen sich häufig auf ANSI-Standard
Datentypen zurückführen, die im Allgemeinen von den meisten DBMS auch
akzeptiert werden (z. B. bei der Erzeugung von Tabellen). Im Zusammenhang mit räumlichen Datentypen unterscheiden sich aber sowohl die Benennung als auch die Modellierung der Datentypen. Damit unter anderem nicht
für jedes DBMS spezielle DDL-Anweisungen (Data Definition Language)
geschrieben werden müssen, wurden die SQL-Prozesse um einen Substitutionsmechanismus erweitert.
SQL-Prozesse bauen auf SQL enthaltende Textdateien auf und werden in
der allgemeinen Konfiguration in der Sektion sqlProcesses definiert (vgl.
Anhang A.1.2). Eine SQL-Datei wird durch eine Instanz der Klasse SQLReader repräsentiert, die ein sequenzielles Einlesen der SQL-Anweisungen
erlaubt. Die SQL-Dateien können beliebige SQL-Anweisungen enthalten, sofern keine Einschränkungen durch das DBMS vorliegen, zum Beispiel dürfen
einige Kommandos nur über den Kommandozeileninterpreter abgesetzt werden. Einem SQL-Prozess können auch mehrere SQL-Dateien respektive Instanzen des SQLReaders zugeordnet werden, wobei diese in der Reihenfolge
der Nennung abgearbeitet werden.
Für jede SQL-Datei lassen sich Abbildungen (mapping) von Zeichenketten (token) auf Zeichenketten (value) definieren, das heißt, eine Zeichenkette wird durch eine andere substituiert. Damit lassen sich die Datentypen
für räumliche Spalten in der DDL mit einer allgemeingültigen Bezeichnung
versehen, die erst bei Ausführung der Anweisung durch eine datenbankspezifischen Datentyp ersetzt wird. Zum Beispiel kann als räumlicher Datentyp
in der SQL-Datei DT Point verwendet werden, der erst zur Ausführungszeit
auf die Zeichenkette DB2GSE.ST POINT beim DB2 Spatial Extender oder
MDSYS.SDO GEOMETRY bei Oracle abgebildet wird. Damit erst zur Laufzeit
definierte Werte, z. B. Datenbankname, Schemaname oder Nutzername, in
den SQL-Dateien verwendet werden können, ist die Referenzierung von vorher festgelegten Variablen“ möglich.
”
Ein Beispiel illustriert die Verwendung dieses Mechanismus. Angenommen eine Anwendung definiert eine Variable schemaName, die auf den jeweils aktuellen Schemanamen abgebildet wird. Nun lässt sich eine Zeichenkette %1 in der SQL-Anweisung durch den aktuellen Schemanamen substituieren, indem die Variable schemaName dereferenziert wird. Abbildung 2.11
veranschaulicht die soeben verwendeten Substitutionen bezüglich Datentyp
und Schemaname.
Vorteilhaft an der Vorgehensweise ist die Trennung von SQL und Anwendung. Ohne direkten Eingriff in die Applikation lassen sich die SQL-
SQL−Datei
ausgeführte Anweisung
CREATE TABLE %1.point
(p DT_POINT);
...
CREATE TABLE schema.point
(p DB2GSE.ST_POINT)
...
29
Konfigurationsdatei
...
<mapping token="%1"
valueRef="schemaName" />
<mapping token="DT_POINT"
value="DB2GSE.ST_POINT" />
...
Abbildung 2.11: Substitution innerhalb von SQL-Dateien
Anweisungen verändern, z. B. das Hinzufügen von neuen Tabellen oder NOT
NULL-Deklarationen.
Im Rahmen der Diplomarbeit nicht erforderliche Verbesserungen der
Mechanismen in den SQL-Prozessen wären zum Beispiel eine intelligente
bzw. definierbare Behandlung von Fehlern, die bei der Ausführung der SQLAnweisungen entstehen.
Falls für eine SQL-Datei Substitutionen von Zeichenketten definiert sind,
muss darauf geachtet werden, dass keine Seiteneffekte entstehen. Seiteneffekte können durch unbeabsichtigte Ersetzungen in den SQL-Anweisungen
entstehen, z. B. die ungewollte Veränderung von Tabellen-, Spalten- oder Indexnamen. Derartige Seiteneffekte vermeidet man am sichersten durch die
Verwendung von in SQL unerlaubten Zeichen in den selbst definierten Token.
Bei der Erzeugung der Tabellen werden Substitutionen zum Ersetzen
der räumlichen Datentypen genutzt und. Des Weiteren wird der Name des
Schemas, in das die Daten importiert werden, zur Laufzeit aus dem Dateinamen ermittelt. Weiterhin werden über den Mechanismus auf einfache Art
die gespeicherten Prozeduren in der Datenbank erzeugt bzw. registriert.
Paket db2 Hauptsächlich implementieren die Klassen im Paket db2 die zuvor beschriebenen abstrakten Basisklassen. Daher bedarf es eigentlich keiner
separaten Beschreibung. Jedoch beschränkt sich die Implementierung der
Klasse DB2FileLoader nicht nur auf den Import von dBASE- und ShapeDateien, sondern sie automatisiert auch die Vorbereitung der Datenbank
für die Verwendung des DB2 Spatial Extenders. Die zusätzlich realisierten
Aufgaben sollen im Folgenden kurz zusammengefasst werden.
Bevor bei DB2 UDB eine Datenbank räumliche Daten speichern kann,
müssen die Datentypen, gespeicherten Prozeduren und Funktionen des DB2
Spatial Extenders in der Datenbank erzeugt werden. Weiterhin muss für
30
die zu speichernden räumlichen Daten ein entsprechendes räumliches Bezugssystem erstellt werden. Diese beiden Aufgaben werden durch die Klasse DB2FileLoader, eine Ableitung der abstrakten Basisklasse DbFileLoader,
automatisiert.
Dazu wird vor dem Import einer Shape-Datei geprüft, ob die räumlichen Datentypen bereits existieren. Sollte dies nicht der Fall sein, so werden
als erstes die Datenbankparameter entsprechend der datenbankspezifischen
Konfigurationsdatei gesetzt. Anschließend wird die gespeicherte Prozedur
db2gse.gse enable db() des DB2 Spatial Extenders ausgeführt, die die zur
Verarbeitung räumlicher Daten notwendigen Datenbankobjekte erzeugt.
Des Weiteren wird getestet, ob das in der Konfigurationsdatei angegebene räumliche Bezugssystem bereits registriert wurde. Ein räumliches Bezugssystem dient der Transformation der Originalkoordinaten in eine Datenbankrepräsentation, bestehend aus positiven ganzzahligen Werten. Ohne ein
derartiges Bezugssystem können keine räumlichen Daten importiert werden.
Gegebenenfalls wird das Bezugssystem selbstständig nach den Vorgaben aus
der Konfiguration registriert. Erst nach diesen Prüfungen wird der Import
durchgeführt. Weitere Informationen zu den Datenbankparametern und dem
räumlichen Bezugssystem sind im Anhang A.1.3 zusammengefasst.
Kapitel 3
Zugriff auf räumliche Daten
Im vorherigen Kapitel wurde der Import der kartografischen Daten in eine
Datenbank beschrieben. Für eine performante Beantwortung von Anfragen
an die Datenbasis werden üblicherweise gezielt Indizes für ein oder mehrere
Spalten einer Tabelle erzeugt. Durch das Anlegen von Indizes wird das Optimierungsprogramm des DBMS in die Lage versetzt, performantere Anfragebearbeitungspläne zu entwickeln. Anstatt sequenziell die gesamte Tabelle zu
durchsuchen, können Daten meistens schneller über einen Index zugegriffen
werden, da Indexdateien im Allgemeinen kleiner und in kürzerer Zeit lesbar
sind. Durch Einschränkung des Suchbereiches lassen sich zusätzlich Teile des
Suchraumes ausschließen, wodurch weniger Seiten gelesen werden müssen.
Bei dem angestrebten Webservice werden zu einem gegebenen Standort
nahe gelegene POIs gesucht. Anders formuliert: es werden alle Punkte in
einem vorgegebenen Bereich gesucht; es handelt sich dabei um eine so genannte Bereichsanfrage. Da eine GIS-Datenbank üblicherweise ein größeres
Territorium abdeckt, müssen geeignete Indizes zum Auffinden aller räumlichen Objekte in einem Gebiet erstellt werden, um eine rasche Beantwortung
einer Anfrage an die Datenbank und damit an den Webservice zu ermöglichen.
Eine wesentliche Eigenschaft der in der Anfrage zu verarbeitenden Daten ist die Mehrdimensionalität, wobei jede Dimension gleichberechtigt gegenüber den anderen ist. Weil es für räumliche Objekte keine totale Ordnung
gibt, die die Nachbarschaftsbeziehungen aufrechterhält, können Verfahren
zur Indizierung eindimensionaler Daten nicht ohne Weiteres auf mehrdimensionale Daten angewendet werden. Seit den 60-ern wurden daher Strukturen
entworfen, die gerade den effizienten Zugriff auf mehrdimensionale Daten
gewährleisten.
Da die räumlichen Daten im Design des Webservice von zentraler Bedeutung sind, wird in diesem Kapitel auf mehrdimensionale Zugriffsverfahren
eingegangen. Zunächst erfolgt eine Charakterisierung der unterschiedlichen
Zugriffsverfahren, um anschließend das durch den DB2 Spatial Extender
31
32
KAPITEL 3. ZUGRIFF AUF RÄUMLICHE DATEN
implementierte Zugriffsverfahren zu analysieren und dessen Eigenschaften
zusammenzutragen. Aus der Analyse lassen sich dann Regeln und Heuristiken ableiten, die zu einer performanten Konfiguration führen. Dabei sind die
seitens des Nutzers veränderbaren Parameter von besonderem Interesse. Die
Parameter bestimmen, wie gewinnbringend ein Index für die Beantwortung
einer Anfrage ist.
3.1
Mehrdimensionale Zugriffsverfahren
Mehrdimensionale Daten werden nicht nur in GIS-Datenbanken verwendet,
sondern lassen sich auch in anderen Bereichen wiederfinden, z. B. CADSysteme, Expertensysteme oder Medizin. Bei den großen gespeicherten Datenmengen ist für das Arbeiten mit solchen Systemen ein effizienter Zugriff
auf die Daten besonders wichtig. Zu den effizient auszuführenden Operationen gehört unter anderem das Aufsuchen von Datensätzen über mehrere
gleichberechtigte Schlüssel – man spricht auch vom symmetrischen Aufsuchen. [HR99]
Dieser Abschnitt gibt einen Überblick über mehrdimensionale Zugriffsverfahren, die Suchoperationen in räumlichen Datenbanken unterstützen.
Dabei werden zuerst Kriterien zur Klassifikation und wünschenswerte Eigenschaften der Verfahren zusammengefasst. Anschließend erfolgt eine generelle
Beschreibung der Bearbeitung von Anfragen, bei denen ein räumlicher Index einbezogen wird. Auf Basis der so gewonnenen Kenntnisse lässt sich
das mehrdimensionale Zugriffsverfahren des DB2 Spatial Extender konkreter beschreiben und analysieren.
3.1.1
Charakterisierung
Bei der Charakterisierung mehrdimensionaler Zugriffsverfahren existieren
keine eindeutigen Hierarchien, sondern vielmehr können die Methoden durch
Betrachtung unterschiedlicher Aspekte gruppiert werden. Hybride Verfahren
erlauben bezüglich einer Eigenschaft teilweise keine eindeutige Zuordnung.
Im Folgenden werden einige Merkmale zusammengefasst, nach denen sich
solche Gruppen herausbilden lassen.
Die Verfahren können danach sortiert werden, ob die Struktur bezüglich
des zu speichernden Datensatzes oder des einbettenden Datenraumes aufgebaut wird [NHS84, LLWS97]. Bei den ersteren erfolgt die Unterteilung des
Datenraumes aufgrund der Werte in den Datensätzen, wie beispielsweise
beim k-d-Baum. Der Aufbau der Strukturen solcher Verfahren ist dabei von
der Datenverteilung abhängig. In [SRF87] werden diese Verfahren auch als
adaptiv (adaptive) bezeichnet. Zu der zweiten Kategorie zählen Methoden,
die die Grenzen einer Region unabhängig von den Daten aufgrund festgelegter Teilungsregeln bestimmen (z. B. halbieren einer Region); diese werden
bei [SRF87] starr (fixed) genannt. Derartige Verfahren haben die Vorteile,
3.1. MEHRDIMENSIONALE ZUGRIFFSVERFAHREN
33
dass die Struktur unabhängig von der Einfügereihenfolge und die Form der
entstehenden Regionen besser kontrollierbar ist. Dies ist zum Beispiel beim
Radix-Baum der Fall.
In [Sam94] wird eine Unterscheidung bezüglich der Verwaltungsstruktur
getroffen. Die erste Klasse bilden hierarchische Verfahren, die eine baumartige Struktur zum Gewährleistung des Zugriffs auf die räumlichen Objekte
verwenden (z. B. k-d-Tree, Quadtree). Die übrigen nichthierarchischen Methoden, wie das Grid File oder EXCELL, verwenden ein Verzeichnis (directory) zur Berechnung der zuzugreifenden Regionen.
Eine andere Aufteilung nehmen Seeger und Kriegel in [SK88] vor und
unterscheiden die Methoden aufgrund der Behandlung der räumlichen Objekte. Es bilden sich Kategorien, die entweder Clipping, Überlappung oder
Transformation benutzen. Beim Clipping werden zu große Geometrien aufgeteilt (Grid File), während beim Arbeiten mit Überlappung stets das ganze
Objekt auf Kosten multipler Suchpfade abgespeichert wird (R-Tree). Zu der
letzten Klasse zählen die eindimensionalen Einbettungen des Datenraumes
mittels raumfüllender Kurven (Hilbertkurve, Z-Ordering).
Weitere Kriterien zur Einordnung von mehrdimensionalen Zugriffsverfahren bieten die Betrachtung der Dimensionalität und Lokalität bei einer
Teilung einer Region [SRF87]. Wenn eine Teilung einer Region notwendig ist, können davon eine (k-d-Baum) oder alle Dimensionen gleichzeitig
(Quadtree) betroffen sein. Untersucht man die Lokalität eines Verfahrens
bei einer Teilung, so wird die Aufteilung entweder auf eine Region begrenzt
(lokal) oder sie erfolgt bei allen Regionen in der Teilungsrichtung (nichtlokal). In den Abbildungen 3.1 und 3.2 werden diese beiden Vorgehensweisen
gegenübergestellt.
Abbildung 3.1: Lokale Teilung einer Region
Abbildung 3.2: Nicht-lokale Teilung einer Region
Ein weiteres Charakteristikum zur Gruppierung mehrdimensionaler Zugriffsverfahren leitet sich aus den Eigenschaften der gespeicherten Daten ab.
Die in Datenbanken zu verwaltenden räumlichen Objekte lassen sich unter
anderem danach unterscheiden, ob sie eine räumliche Ausdehnung besitzen
(z. B. Punkte gegenüber Polygonen). Analog dazu unterscheidet man Zugriffsverfahren, die nur Punktobjekte (PAM – point access methods) oder
auch räumlich ausgedehnte Objekte (SAM – spatial access methods) verwalten können. Letztere Zugriffsverfahren entwickelten sich häufig durch
die Modifizierung (Transformation, Overlapping, Clipping oder Multiples
34
Layers [GG98]) von Punktzugriffsverfahren.
3.1.2
Anforderungen
Damit ein mehrdimensionales Zugriffsverfahren sinnvoll in Datenbankmanagementsystemen eingesetzt werden kann, werden verschiedene Anforderungen an diese gestellt. Die hier vorgestellten Anforderungen können später zur
Analyse des im DB2 Spatial Extender verwendeten Verfahrens herangezogen
werden.
In [GG98] wurde ausgehend von den Eigenschaften räumlicher Daten
und deren Anwendungen ein Anforderungsprofil zusammengestellt, wobei
auch datenbankspezifische Aspekte wie Mehrbenutzerzugriff oder Integration der Verfahren in ein DBMS einbezogen wurden. Das Interesse im Kontext
der Diplomarbeit liegt jedoch im Bereich des performanten Zugriffs auf die
Daten, weshalb nachfolgend insbesondere darauf Bezug genommen wird.
Unabhängigkeit von Eingabedaten Es wird von den Verfahren erwartet, dass trotz ungünstiger Verteilung oder Einfügereihenfolge der Daten die Effizienz des Zugriffs beibehalten wird. Die Berücksichtigung
des Aspekt der ungleichmäßigen Verteilung von Daten ist insbesondere
bei GIS-Datenbanken von besonderer Bedeutung, da hier häufig Ballungsgebiete von räumlichen Objekten auftreten (z. B. Stadtzentren
gegenüber ländlichen Gegenden).
Skalierbarkeit Trotz Vergrößerung der Anzahl zu verwaltender räumlicher
Objekte sollte der Zugriff auf die Daten adäquat performant bleiben.
Auch hier lässt sich ein direkter Bezug zu GIS-Datenbanken herstellen, da im Allgemeinen sehr große Datenmengen auftreten können. So
umfassen die von Tele Atlas über die Infrastruktur Deutschlands gesammelten Daten rund 60 Gigabyte und bilden damit sogar nur eine
kleinere Datenbank.
Zeiteffizienz Die Suche in einer räumlichen Datenbank sollte möglichst
schnell sein. Maßstab hierfür bildet der eindimensionale B-Tree. Das
heißt, bei beliebiger Kombination der Suchattribute und ungünstigster
Datenverteilung – also im worst case – sollte die Suche logarithmisch
bleiben.
Speicherplatzeffizienz Ein Index sollte möglichst klein im Verhältnis zu
den zu indizierenden Daten sein, wobei zusätzlich die prozentuale Speicherplatzausnutzung auf den Seiten nach unten beschränkt ist. Dadurch wird gewährleistet, dass möglichst wenige Indexseiten zugegriffen werden müssen.
Unterstützte Operationen Das Zugriffsverfahren sollte alle Operationen
annähernd gleich gut unterstützen. Eine effiziente Suche allein ist nicht
3.1. MEHRDIMENSIONALE ZUGRIFFSVERFAHREN
35
ausreichend, wenn das Einfügen oder Löschen von Daten sehr zeitaufwändig ist. Dieser Punkt ist gerade für den Import der Daten oder
bei der Erzeugung von räumlichen Indizes von Bedeutung.
3.1.3
Anfragebearbeitung
Auf räumlichen Objekten arbeitende Operationen sind sehr kostenintensiv,
weshalb mehrstufige Auswertungsstrategien für räumliche Anfragen genutzt
werden. Nach einer kurzen Beschreibung möglicher Suchszenarien auf räumlichen Datenbanken, wird die übliche Vorgehensweise bei der Bearbeitung
räumlicher Anfragen erläutert.
Auf räumliche Daten arbeitende Operationen können in die drei Klassen
richtungsbezogene, abstandsbezogene und topologische Operationen unterteilt werden [PTS97]. Richtungsbezogene Beziehungen beschreiben die Position im Raum, die zwei räumliche Objekte zueinander haben, zum Beispiel
im Sinne von nördlich oder oberhalb. Die zweite Klasse bilden die abstandsbezogenen Operationen wie zum Beispiel nah und fern, wobei der Abstand
durch die euklidische Metrik berechnet wird. In der letzten Klasse werden
diejenigen Operationen zusammengefasst, in der die direkte Beziehung zwischen zwei räumlichen Objekten betrachtet wird. Dazu zählen Operationen wie Schnitt oder Inklusion, bei denen der Abstandsbegriff keinen weiteren Einfluss hat. Detaillierte Definitionen dieser Operatoren finden sich in
[GG98] und teilweise in [HR99].
In der letzten Klasse von Operationen befindet sich auch die Beziehung
Überlappung“, die die Basis für eine der gebräuchlichsten Anfrageformen,
”
der Bereichsanfrage, bildet. Eine weitere häufig anzutreffende Suchoperation ist die Punktanfrage [HR99]. Diese Operationen bilden Spezialfälle der
schnittbildenden Operationen innerhalb der topologischen Klasse und sind
bei der Realisierung des Webservice von besonderem Interesse.
Eine Punktanfrage liefert die Antwort zu der Frage, welche Objekte einen
gegebenen Punkt im Datenraum enthalten. Beispielsweise könnte im Zusammenhang mit der Diplomarbeit nach dem Namen des Bezirks gesucht werden, in dem man sich gerade aufhält. Dahingegen beantwortet die Bereichsanfrage die Frage, welche Objekte sich in einem gegebenen Anfragefenster
befinden oder es schneiden. Oft wird für das Anfragefenster ein achsenparalleles Rechteck bevorzugt. Genau diese Art der Fragestellung wird in dem
realisierten Webservice verwendet, um alle nahe gelegenden Einrichtungen
zu einem Standort zu finden.
Bei der Bearbeitung von Operationen auf räumlichen Objekten wird
im Allgemeinen ein mehrstufiges Selektionsverfahren angewendet [BKSS94,
GG98, TSS00], da das Durchführen der Berechnungen mit den genauen Koordinaten sehr rechenintensiv ist. Dazu untergliedert man die Abarbeitung
einer Operation in zwei Arbeitsschritte: Filter- und Verfeinerungsschritt.
Das Schema in Abbildung 3.3 visualisiert die notwendigen Arbeitsschritte
36
und die entstehenden Ergebnismengen.
Anfrage
Filter
Test auf Basis
von Approximationen
Kandidaten
Treffer
Test auf Basis der
Objekt−Geometrien
Ausschuss
Spatial
Index
Verfeinerung
Treffer
Anfrageergebnis
Abbildung 3.3: Anfragebearbeitung mit räumlichen Operationen
Im ersten Schritt werden durch einen Geometriefilter räumliche Objekte ausgeschlossen, die aufgrund der Beziehung ihrer Approximationen die
Anfragekriterien nicht erfüllen können. Bei der Approximation eines räumlichen Objekts handelt es sich üblicherweise um das minimal umschreibende
und achsenparallele Rechteck (minimum bounding rectangle (MBR) oder
minimum bounding box (MBB)) und wird aus einem räumlichen Index bezogen.
Zur Erstellung eines Indizes über räumliche Objekte und zum Filtern
werden Approximationen verwendet, da diese zum einen weniger Speicherplatz benötigen und zum anderen die Berechnungen einfacher und damit
schneller durchzuführen sind. Die Verwendung von Approximationen beschleunigt demnach die Selektion der Geometrien bezüglich des Anfragekriteriums. Lassen sich sogar aus den Approximationen sichere Rückschlüsse
auf die eigentliche Geometrie ziehen (z. B. bei Punkten), so können die Geometrien direkt in das Resultat überführt werden. Einzelheiten über Verfahren, Eigenschaften und Anforderungen von Approximationen können in
[BKSS94, Fla97] nachgelesen werden.
In dem anschließenden Arbeitsschritt werden die Treffer aus dem Fil-
3.2. GEOMETRIEN IM DB2 SPATIAL EXTENDER
37
terschritt genauer betrachtet. Dazu werden die detaillierten Informationen
der räumlichen Objekte geladen und das Anfragekriterium exakt überprüft.
Dadurch werden Treffer eliminiert, bei denen nur das MBR aber nicht das
Objekt selbst das Anfragekriterium erfüllt (false hits). Diese Treffer werden
in der restlichen Diplomarbeit als ungültige Treffer bezeichnet.
3.2
Zugriff auf Geometrien mit dem DB2 Spatial
Extender
Der DB2 Spatial Extender ist eine Erweiterung zu DB2 UDB für die Verarbeitung und Verwaltung räumlicher Objekte. Dazu stellt dieser räumliche Datentypen in Form von strukturierten Datentypen, Operationen auf
räumlichen Datentypen in Form von nutzerdefinierten Funktionen und ein
mehrdimensionales Zugriffsverfahren zur Verfügung. Da, wie bereits erläutert, die mehrdimensionalen Zugriffsverfahren besonders wichtig für das effiziente Ausführen von Operationen auf räumlichen Objekten ist, wird diese
im folgenden Abschnitt beschrieben und analysiert. Mit den aus der Analyse gewonnen Erkenntnissen werden anschließend Hinweise zur Konfiguration
des Zugriffsverfahren abgeleitet.
3.2.1
Indizierung räumlicher Objekte
In diesem Abschnitt wird erläutert, wie die räumlichen Objekte mit dem
mehrdimensionalen Zugriffsverfahren des DB2 Spatial Extender organisiert
werden.
Wie bei vielen anderen Zugriffsverfahren auch werden für das Erzeugen
des Indizes Approximationen der räumlichen Objekte verwendet. Die Approximation wird durch die Bestimmung des minimal umschreibenden Rechtecks (MBR) gebildet. Der gesamte Datenraum wird von bis zu drei Gittern
mit quadratischen Zellen unterschiedlicher Größe überdeckt. Die Gitter bilden dabei eine Hierarchie (Schicht) bezüglich der Gittergröße, das heißt, das
erste Gitter besitzt die kleinsten Zellen und das letzte die größten. Abgesehen von der Hierarchie können die Anzahl der Gitter und die jeweiligen
Gittergrößen frei und unabhängig voneinander gewählt werden.
Ein Indexeintrag wird bei der Überschneidung der Approximation einer Geometrie mit dem Zellraster generiert. Dabei besteht der Indexeintrag
aus einem internen Identifikator sowie der minimalen x- und y-Koordinate
der geschnittenen Zelle. Die Schnitte zwischen Gitter und Approximation
können besonders effizient berechnet werden, da es sich um zwei Rechtecke
handelt (Aufwand O(1)) und die Approximation explizit in der Datenbankdarstellung der Geometrie gespeichert wird. Werden mehrere Gitterzellen
von der Approximation geschnitten, dann wird für jede Zelle ein separater
Indexeintrag erzeugt. Bei der Überprüfung auf Schnitte der Approximation
38
mit dem Zellraster wird beim kleinstmöglichen Gitter begonnen. Insofern in
einer Schicht vier oder mehr geschnittene Zellen ermittelt werden, wird für
die Indizierung das nächstgrößere Gitter verwendet. Wurde das größte definierte Gitter erreicht, müssen alle für diese Schicht generierten Indexeinträge
in den Index aufgenommen werden. Abbildung 3.4 visualisiert die Generierung von Indexeinträgen für verschiedene Geometrien.
80.0
70.0
60.0
50.0
B
40.0
30.0
C
20.0
A
10.0
0.0
G1
10.0 20.0
G2
30.0 40.0
50.0
G3
60.0 70.0 80.0
Abbildung 3.4: Mehrdimensionales Zugriffsverfahren des DB2 Spatial Extender [IBM00a]
Die Abbildung zeigt den mit drei Gittern (gestrichelte Linien) überspannten Datenraum, wobei die Gittergrößen bei 10.0 (G1), 30.0 (G2) und
70.0 (G3) liegen. Um die eingezeichneten Geometrien (dick umrandet) sind
zusätzlich die Approximationen (dünngezeichnete Rechtecke) eingetragen
worden. Weiterhin wurden für die Schichten eins und zwei die geschnittenen
Gitterzellen grau unterlegt; damit die Übersicht erhalten bleibt, wurde für
die Schicht drei darauf verzichtet.
Tabelle 3.1 listet die in den Index eingetragenen Tupel auf, die bei der
Indizierung der Geometrien entstehen. Für die einzelnen Geometrien beginnend beim Punkt wird im Folgenden erläutert, wie die Einträge zustande
kommen.
Da ein Punkt keine räumliche Ausdehnung besitzt, und damit die Approximation der Punkt selbst ist, schneidet dieser grundsätzlich nur eine
Gitterzelle auf der niedrigsten Schicht. Im Beispiel liegt der Punkt A in der
Gitterzelle mit den minimalen Koordinaten (20.0, 10.0). Die Approximati-
Gitter
10.0
30.0
70.0
39
Indexeintrag
ID xGrid yGrid
A
20.0 10.0
B
0.0 30.0
B
30.0 30.0
C
0.0
0.0
C
70.0
0.0
Tabelle 3.1: Schnittpunkte der Geometrien mit dem Gitter
on des Polygons B schneidet auf der untersten Schicht (G1) mehr als vier
(genau neun) Gitterzellen. Daher wird auf das nächstgrößere Gitter übergegangen, wo nur noch zwei Zellen des Gitters betroffen sind; daher werden
zwei Einträge in dem Index erzeugt. Zuletzt werden die Einträge für den Linienzug C generiert. Dieser schneidet auf der Schicht eins zwölf und auf der
Schicht zwei sechs Gitterzellen. Das heißt, in beiden Situationen sind mehr
als vier Zellen betroffen und für die Indizierung muss die oberste Schicht
(G3) benutzt werden. Für das größte Gitter sind dann zwei Einträge in den
Index einzufügen.
3.2.2
Anfragebearbeitung
Wie bereits erläutert, dient ein mehrdimensionales Zugriffsverfahren zur Beschleunigung einer räumlichen Operation. Dieser Abschnitt klärt die Frage, wie das eben beschriebene mehrdimensionale Zugriffsverfahren räumliche Operationen bei der Anfragebearbeitung unterstützt. Zur Veranschaulichung werden die einzelnen Schritte anhand eines typischen Zugriffsplans für
eine Bereichsanfrage erläutert. Zum besseren Verständnis wird vorher kurz
darauf eingegangen, wozu und wie ein Zugriffsplan erstellt wird. Bei den
Erläuterungen wird zur Vereinfachung angenommen, dass eine achsenparallele Bereichsanfrage (Fenster) zu beantworten ist. Der Schluss auf die Vorgehensweise für andere Operationen ist offensichtlich, wenn man bedenkt, dass
immer zuerst die Beziehung zwischen den MBRs der Geometrien überprüft
wird.
Der Ausführungsplan (Zugriffsplan) für eine SQL-Anweisung wird vom
SQL-Compiler des DBMS erstellt und legt die Abarbeitung einer Anfrage
fest. Zur Generierung eines Zugriffsplan werden innerhalb des Compilers
verschiedene Phasen durchlaufen. Die wichtigsten sind dabei die syntaktische
und semantische Analyse, die Anfrageoptimierung durch Umschreiben und
die Optimierung durch Erzeugen alternativer Zugriffspläne [IBM00b]. Für
die weiteren Betrachtungen ist nur der Teil der Optimierung von Interesse.
Die Optimierung einer SQL-Anfrage erfolgt demnach in zwei Phasen.
Während das Umschreiben der SQL-Anweisung eher auf syntaktischer Ebene geschieht (z. B. Verschiebung oder Mischen von Operationen), berücksich-
40
tigt die Erzeugung alternativer Zugriffspläne Informationen, die im Zusammenhang mit den Datenbankobjekten stehen (z. B. Statistiken für Tabellen,
Indizes, Spalten und Funktionen). Das Resultat dieses Vorganges ist ein
Ausführungsplan der aufgrund der vorliegenden Informationen wahrscheinlich den geringsten Ausführungsaufwand hat.
DB2 UDB ermöglicht es dem Nutzer, den erzeugten Anfrageplan zu visualisieren und zu analysieren, wobei unter anderem die geschätzten Ausführungszeiten für die einzelnen Operatoren sowie die involvierten Datenbankobjekte abfragbar sind. Ein vereinfachter Ausführungsplan für eine Bereichsanfrage auf eine Tabelle mit räumlichen Index wird in Abbildung 3.5
gezeigt. In der Abbildung sind nur die wichtigsten Operatoren des Zugriffsplans dargestellt; das heißt, alle im Zusammenhang mit dem räumlichen
Bezugssystem stehenden Operationen wurden zur Verringerung der Komplexität weggelassen.
RETURN
II
I/II
NLJOIN
FETCH
Bounding Box
I
SORT
I − Filterung
II − Verfeinerung
EISCAN
Selektiviät
GeoIndex
Geotabelle
Abbildung 3.5: Ausführungsplan für eine Anfrage mit Geometrien
Analog zu der üblichen Form der Anfragebearbeitung unter Verwendung
eines mehrdimensionalen Zugriffsverfahrens benutzt auch der DB2 Spatial
Extender ein zweistufiges Selektionsverfahren (vgl. Abbildung 3.3). Zur Visualisierung wurden zusätzlich in Abbildung 3.5 die Bereiche der Filterung
und der Verfeinerung hervorgehoben.
In dem ersten Schritt erfolgt ein Filtern der Geometrien anhand ihrer Approximationen, wobei die in Frage kommenden Geometrien mit Unterstützung des Index bestimmt werden. Bei dem Indexzugriff werden zu-
41
nächst alle Indexeinträge ermittelt, deren Gitterzelle das gegebene Fenster
schneidet – in der Abbildung dargestellt durch die Operation EISCAN (Extension Index Scan). Da es sich bei dem Index um eine Mehrschichtenstruktur
(vgl. Abschnitt 3.2.4) handelt müssen die Einträge aller definierten Gitter
durchsucht werden.
Anschließend werden im NLJOIN (Nested Loop Join) diejenigen Geometrien herausgefiltert, deren Approximationen aufgrund ihrer Position zum
Fenster ausgeschlossen werden können (ungültige Treffer). An dieser Stelle
müssen bereits die Datenseiten der Geometrien geladen werden (fetch), um
auf die Koordinaten der Approximation zugreifen zu können. Da hierbei entsprechend häufig kostenintensiv auf den Sekundärspeicher zugegriffen muss,
sollte durch den Index eine hohe Selektivität erreicht werden. Das heißt, es
sollten nur die besten Kandidaten durch den Index ausgewählt werden. Das
Ergebnis wird unmittelbar innerhalb des NLJOIN an den Verfeinerungsschritt
weitergegeben.
Die Trennung zwischen Filter- und Verfeinerungsschritt ist in der Abbildung 3.5 nicht explizit erkennbar, da sich diese in der NLJOIN-Operation
überschneiden. Diese Überlagerung erscheint sinnvoll, da die genauen Koordinaten der Geometrien, insofern diese nicht aufgrund ihres Umfangs separat1 verwaltet werden, bereits während des Filterns geladen wurden. Im
Falle eines positiven Resultats beim Test mit der Approximation erfolgt im
Verfeinerungsschritt eine genaue Überprüfung mit den richtigen Koordinaten der Geometrien. Das Ergebnis dieses Arbeitsschritts wird als Resultat
der Bereichsanfrage zurückgegeben.
3.2.3
Beobachtungen und Eigenschaften
Nachdem die Funktionsweise des mehrdimensionalen Zugriffsverfahrens des
DB2 Spatial Extenders erläutert wurde, werden in diesem Abschnitt wesentliche Eigenschaften und Beobachtungen zusammengefasst.
Zunächst lässt sich feststellen, dass es sich bei dem mehrdimensionalen
Zugriffsverfahren des DB2 Spatial Extender um eine Methode mit Aufteilung
des gesamten einbettenden Datenraumes durch disjunkte Regionen (bezogen auf ein Gitter) handelt. Die Verwendung multipler Gitter erzeugt eine
Hierarchie total geordneter Schichten, wobei jede Schicht den Datenraum
auf unterschiedliche Weise (verschiedene Zellgrößen) partitioniert. Da die
Anzahl der Schichten auf drei begrenzt ist, müssen größere räumliche Objekte mittels Clipping indiziert werden. Diese Eigenschaften zusammenfassend
erhält man eine Mehrschichtenstruktur – eine Variante von Verfahren, die
überlappende Regionen zulassen – wie sie in [HR99] definiert ist.
Die Größen der Gitterzellen für die drei Schichten werden zu Beginn
der Erstellung des Index festgelegt und bleiben unverändert, solange der
1
Moderne DBMS speichern LOBs (Large Objects) ab einer bestimmten Größen unabhängig von den anderen Attributen.
42
Index existiert. Daraus lässt sich bereits folgern, dass eine Adaption an
eine sich verändernde Datenverteilung nicht berücksichtigt wird. Um eine
ungleichmäßige Datenverteilung in gewissem Maße abzufangen, muss diese
schon bei der Erstellung des Index durch die Gestaltung der Zellengrößen der
Gitter ausgeglichen werden. Zur Verdeutlichung dieser Tatsache betrachte
man den Filterschritt in der Anfragebearbeitung (vgl. Abschnitt 3.2.2). Wurde eine Gitterzelle vom Fenster geschnitten, müssen alle darin enthaltenen
Geometrien, genauer deren Approximationen, überprüft werden. Bei einer
sehr hohen Dichte von Geometrien in dieser Zelle werden unter Umständen
zahlreiche Test mit negativem Ausgang durchgeführt. Andere Zugriffsverfahren begrenzen die Anzahl der Geometrien pro Zelle, so dass an dieser
Stelle eine feinere Granularität erreicht wird.
Aus der Benutzung eines unveränderlichen Zellrasters und unter der Bedingung gleich bleibender Datenverteilung ergibt sich weiterhin, dass wechselndes Einfügen und Löschen von Datensätzen sowie jede beliebige Einfügereihenfolge keinen Einfluss auf die Struktur und damit auf die Effizienz haben. Die obige Bedingung ist für die Gültigkeit der Aussage notwendig,
da eine ungleichmäßige Datenverteilung zu dem vorher genannten Problem
führen kann. Des Weiteren werden aufgrund der Struktur keine Operationen
wie Split oder Merge benötigt, wie sie bei vielen anderen mehrdimensionalen Zugriffsstrukturen erforderlich sind. Im Zusammenhang mit der Struktur
ist noch erwähnenswert, dass Gitterzellen, die keine Geometrien enthalten,
nicht in dem Indexverzeichnis kodiert und nicht weiter berücksichtigt werden.
Wenn in einer Tabellen nur Punktobjekte verwaltet werden, so ist offensichtlich die Definition eines einzigen Gitters ausreichend – es wird immer
das kleinste Gitter verwendet. Diese Aussage lässt sich eingeschränkt auch
auf räumlich ausgedehnte Geometrien übertragen. Wenn die zu verwaltenden Geometrien annähernd die gleiche maximale Ausdehnung besitzen, so
ist ein einzelnes Gitter ausreichend, da das Clipping nur bedingt auftritt.
3.2.4
Analyse
In den vorherigen Abschnitten wurden zunächst die Funktionsweise sowie
allgemeine bzw. offensichtliche Eigenschaften des räumlichen Zugriffsverfahren des DB2 Spatial Extenders beschrieben. Basierend auf den dort gewonnenen Erkenntnissen werden im folgenden Abschnitt Heuristiken oder Regeln
hergeleitet, die den Anwender oder Administrator bei der Konfiguration des
Zugriffsverfahrens unterstützen. Nachdem das Ziel der Analyse beschrieben
wurde, wird zuerst der Spezialfall betrachtet, bei dem nur Punktdaten vorliegen. Eine gesonderte Behandlung ist angebracht, da hierbei nur ein Gitter
benötigt wird und kein Clipping auftreten kann. Danach werden beliebige
Geometrien behandelt, wobei neben der Zellengröße auch die Anzahl der
Schichten veränderbar ist.
43
Das Hauptziel der Analyse ist die Entwicklung von Heuristiken und Regeln zur performanten Konfiguration des mehrdimensionalen Zugriffsverfahrens vom DB2 Spatial Extender. Da im Allgemeinen der Zugriff auf
den Sekundärspeicher deutlich mehr Zeit benötigt als die von der CPU
durchgeführten Berechnungen, wird die Anzahl der Seitenzugriffe und die
Ausführungszeit als Kriterium für die Performanz herangezogen. Die Konfiguration des mehrdimensionalen Zugriffsverfahrens hat großen Einfluss auf
die Ausführungszeit und die Anzahl der Seitenzugriffe, da diese bestimmt,
wie gut bereits der Filterschritt ungültige Treffer eliminiert.
Betrachtet man eine ausschließlich Punkte enthaltende Tabelle, vereinfacht sich die Konfiguration des mehrdimensionalen Zugriffsverfahrens erheblich. Das folgende Theorem fasst wesentliche Aspekte zusammen.
Theorem 3.1 Für die Konfiguration des mehrdimensionalen Zugriffsverfahrens des DB2 Spatial Extenders zur Verwaltung von Geometrien ohne
räumliche Ausdehnung (Punkte) gelten folgende Aussagen:
(a) Die Definition eines einzelnen Gitters ist ausreichend.
(b) Für Geometrien ohne räumliche Ausdehnung enthält das Indexverzeichnis O(n) Einträge, wobei n die Anzahl der zu verwaltenden Geometrien ist.
(c) Die Auswahl der Gittergröße orientiert sich an dem Datenbereich mit
der höchsten Dichte und bewegt sich in der Größenordnung des durchschnittlichen Abstands eines Punktes zu seinen unmittelbaren Nachbarn.
Beweis:
(a) Die Anzahl der Gitter und die jeweiligen (aufsteigenden) Gittergrößen
können unabhängig von einander gewählt werden. Da bei Geometrien ohne räumliche Ausdehnung kein Clipping auftreten kann, ist die
Aussage offensichtlich richtig.
(b) Nach dem Algorithmus, der in Abschnitt 3.2.1 beschrieben wird, wird
zu jedem räumlichen Objekt mindestens ein Eintrag erzeugt. Da jedoch
kein Clipping auftreten kann, beträgt die Anzahl der Indexeinträge genau n. Insbesondere ist anzumerken, dass Gitterzellen, die keine Geometrien enthalten, nicht im Index reflektiert werden.
(c) Die Regionen in denen eine hohe Datendichte vorliegt, verursachen im
Allgemeinen die meisten ungültigen Treffer, da dort wesentlich mehr
Geometrien einer Zelle zugeordnet werden. Daher muss insbesondere
in diesen Regionen auf die Gitterzellengröße geachtet werden.
44
Zunächst kann aus (b) geschlussfolgert werden, dass die Konfiguration
des mehrdimensionalen Zugriffsverfahrens keinen Einfluss auf die Anzahl der Indexeinträge hat und deswegen nicht weiter berücksichtigt
werden muss.
Da zur Überprüfung der Approximationen während des Filterns die
Koordinaten sowohl von den gültigen (hits) als auch von den ungültigen Treffern (false hits) geladen und überprüft werden müssen, ist die
Anzahl der ungültigen Treffer das ausschlaggebende Kriterium für die
Performanz des Zugriffsverfahrens.
Die Anzahl ungültiger Treffer wird genau dann minimiert, wenn möglichst wenige Punkte einer Zelle zugeordnet werden. Dies ist offensichtlich dann der Fall, wenn die Gittergröße möglichst klein gewählt wird.
Da sich bei der fortwährenden Verfeinerung des Rasters die Anzahl der
einer Gitterzelle zugeordneten Punkte nur unwesentlich verändert und
damit die durch den Index selektierten Treffermengen nahezu identisch
bleiben, erbringt eine Zellengröße unterhalb der Größenordnung des
durchschnittlichen Abstands eines Punktes zu seinen unmittelbaren
Nachbarn, wenn überhaupt, nur einen unwesentlichen Performanzgewinn.
2
Nachdem die Konfiguration des mehrdimensionalen Zugriffsverfahren für
räumlich nicht ausgedehnte Objekte behandelt wurde, befassen sich die folgenden Paragrafen mit räumlich ausgedehnten Geometrien wie Linienzügen
oder Polygonen. Während vorher das Hauptkriterium die Datenverteilung
im einbettenden Raum gewesen war, muss nun insbesondere das Clipping
beachtet werden, da sich hierdurch das Indexverzeichnis vergrößern kann.
Lemma 3.1 (Abschätzung der Indexeinträge) Sei G eine Geometrie
mit dem MBR (xmin , ymin , lx , ly ) beliebig gegeben. Die Gitter seien durch
die jeweilige Seitenlänge einer Zelle zi > 0 mit 1 ≤ i ≤ k ≤ 3 definiert,
wobei k die Anzahl der definierten Gitter bezeichnet. Dann gelten folgende
Abschätzungen für die Indexeinträge bezogen auf das Gitter i (ohne Berücksichtigung der Beschränkung durch den Algorithmus für das Gitter i < k
auf vier Zellen):
&
lx ly
zi2
'
(i)
(ii)
≤ IG ≤
lx
ly
+2 ·
+2
zi
zi
Beweis: Zum Berechnen der Anzahl der Indexeinträge ist es ausreichend,
die Anzahl der von der Fläche des MBR geschnittenen Gitter zu berechnen,
da jedes geschnittene Gitter genau einen Indexeintrag erzeugt.
l
(i) Die Ungleichung gilt offensichtlich, da lzxi bzw. zyi die Anzahl der geschnittenen Gitter entlang der x-Achse bzw. y-Achse bezeichnet. Es
45
werden sozusagen die Längen bezüglich zi normiert. Die Gesamtzahl
der geschnittenen Gitterzellen ergibt sich aus deren Produkt.
(ii) Als erstes wird die Anzahl der geschnittenen Gitter in Richtung der
x-Achse IGx bestimmt und nach oben abgeschätzt. Dazu bezeichnet
x = xmin mod zi den Abstand des MBR zur nächstkleineren Gittergrenze entlang der x-Achse. Zum besseren Verständnis visualisiert Abbildung 3.6 die eingeführten Bezeichnungen. Die gestrichelte Linien repräsentieren dabei das Gitter zi und das durchgezogene Rechteck stellt
die Approximation einer Geometrie dar. Unter Berücksichtigung, dass
der obere und rechte Rand einer Gitterzelle nicht zu derselben gehört,
ergibt sich:
=
IGx
≤
x<zi
≤
 l
m
 x+lx + 1
, falls (x + lx ) mod zi = 0
l zi m
x+l
x

, sonst
zi
x + lx
+1
zi
lx
+2
zi
(3.1)
Analog erhält man mit y = ymin mod zi für die Anzahl der geschnittenen Gitterzellen entlang der y-Achse:
≤
IGy
ly
+2
zi
(3.2)
Die obere Abschätzung der Anzahl der Indexeinträge für eine Geometrie ergibt sich aus dem Produkt der Gleichungen 3.1 und 3.2.
3
lx
2
x
ly
1
z
0
1
2
y
i
3
4
5
6
Abbildung 3.6: Skizze zur Abschätzung der Indexeinträge
2
46
Aus dem vorangegangenen Lemma lässt sich die intuitiv verständliche
Aussage ableiten, dass je größer die Gitterzelle gewählt wird, desto geringer
ist die Anzahl der Indexeinträge.
Ein wesentlicher Faktor bei der Performanz eines mehrdimensionalen
Zugriffsverfahrens ist die Reduzierung der ungültigen Treffer beim Indexzugriff. Da bei beliebiger Vergrößerung der Gitterzellen zugleich die Anzahl der
ungültigen Treffer erhöht wird, ist der dadurch zu erzielende Performanzgewinn beschränkt. Ab einer von der Datenverteilung bestimmten Größe
übersteigt der Aufwand für das Lesen der Datenseiten für die ungültigen
Treffer den Performanzgewinn durch die Vergrößerung der Gitterzellen.
Bei der Untersuchung der Konfiguration des mehrdimensionalen Zugriffsverfahrens zur Verwaltung räumlich ausgedehnter Geometrien waren
keine mathematisch fundierten Bedingungen erkennbar, die eine optimale
Leistung garantieren. Daher wurden nachfolgend einige empirische Anhaltspunkte zusammengestellt, die eine gute Ausgangssituation für eine performante Konfiguration schaffen. Daran anschließend folgen genauere Erklärungen zu den Heuristiken.
Ist die Datenverteilung vernachlässigbar, so lässt sich besonders gut eine
Statistik über die gerundeten maximalen Ausdehnungen der einzelnen Geometrie zur die Bestimmung einer Ausgangskonfiguration verwenden. Aus
einer solchen Statistik ergeben sich Hinweise
zu Häufungspunkten, bei denen viele Geometrien annähernd die gleiche Ausdehnung besitzen. Diese Häufungspunkte könnten von einem
separaten Gitter aufgenommen werden.
zu nicht auftretenden Werten. Diese Stellen können ignoriert werden.
zu längeren Abschnitten, bei denen annähernd gleich viele Geometrien unterschiedlich maximale Ausdehnungen besitzen. Je nach Umfang
des Abschnitts könnten diese Geometrien zu einem Gitter zusammengefasst oder besonders aufgeteilt werden.
zu der maximale Ausdehnung über alle Geometrien. Dieser Wert kann
als Basis für die Zellengröße des größten Gitters genutzt werden.
Auf Basis der soeben vorgestellten Statistik werden nun einige Heuristiken zur Bestimmung einer Ausgangskonfiguration zusammengefasst.
Häufungspunkte Sei bei der Ausdehnung h ein derartiger Häufungspunkt,
dann ist ein separates Gitter mit mindestens der Größe 2h vorzusehen.
Da bei einer Zellengröße identisch h die Approximationen mit hoher
Wahrscheinlichkeit nicht komplett innerhalb einer Gitterzelle liegen,
werden dann sehr häufig zwei oder mehr Zellen geschnitten bzw. Indexeinträge erzeugt. Bei einer Zellengröße von mindestens 2h ist offensichtlich die Anzahl der geschnittenen Zellen geringer.
47
dicht liegende Häufungspunkte Da insgesamt nur drei Gitter zur Verfügung stehen, werden nur die signifikanten Häufungspunkte betrachtet
und es müssen gegebenenfalls dicht liegende zusammen berücksichtigt
werden. Konzentrieren sich sehr viele Häufungspunkte in einem Abschnitt, so lassen sie sich auch in zwei Gruppen aufteilen. Insofern
die Geometrien besonders dicht im Datenraum liegen, ist die zweite
Variante zu bevorzugen, da bei Anfragen weniger ungültige Treffer
entstehen können.
maximale Ausdehnung Falls erforderlich sollte die Seitenlänge einer Zelle des größten Gitter mindestens der maximalen Ausdehnung über
alle Geometrien entsprechen. Die Zellengröße muss in Abhängigkeit
von der Anzahl der Geometrien gewählt werden, die nicht durch ein
kleineres Gitter abgedeckt werden. Dabei ist die Tatsache zu berücksichtigen, dass gerade wenn die Seitenlänge der Gitterzelle
viel kleiner
l x ly
als die Ausdehnung der Geometrie ist, O zi
Indexeinträge (vgl.
Lemma 3.1) entstehen.
Verhältnis zwischen den Zellengrößen Relativ dicht liegende Gittergrößen erweisen sich als ungünstig. Wenn sich auf einer unteren Schicht
mehr als vier Zellen geschnitten werden, bedeutet dies bei ähnlichen
Gittergrößen, dass beim nächstgrößeren Gitter wahrscheinlich auch
mehr als vier Zellen geschnitten werden. Damit ist der Nutzen der
nächsthöheren Schicht eingeschränkt. Daher ist mindestens eine Verdoppelung der Gittergrößen sinnvoll, wobei zusätzlich die Verteilung
in der Statistik berücksichtigt werden sollte.
Variation der Gittergrößen Es hat sich herausgestellt, dass geringfügige
Variationen der Gittergröße annähernd dieselbe Performanz bieten –
die Größenordnung ist also entscheidend.
Art der Geometrie Da sowohl bei Polygonen als auch bei Linienzügen
das MBR als Approximation verwendet wird, können obige Heuristiken auf alle räumlich ausgedehnten Geometrien angewendet werden.
Aus Lemma 3.1 leitet sich ab, dass die von der Approximation aufgespannte Fläche Einfluss auf die Konfiguration des Zugriffsverfahrens hat.
Daher wurde untersucht, ob eine Statistik über die auftretenden Flächengrößen Informationen zu der Konfiguration liefern kann. Da sich eine Flächegröße A = lx ly aufgrund vieler verschiedener Wertepaare ergeben kann, ist
eine derartige Statistik nicht aussagekräftig.
3.2.5
Experimentelle Überprüfung
Nachdem Theorien über die Konfiguration des räumlichen Zugriffsverfahren aufgestellt wurden, wurden einige Experimente zur Überprüfung durch-
48
geführt. Die daraus gewonnen Ergebnisse werden in diesem Abschnitt vorgestellt. Dazu werden zuerst die Vorgehensweise und die Bewertungskriterien
für die Experimente beschrieben. Anschließend erfolgt die Dokumentation
und Auswertung der einzelnen Experimente.
Wie bereits in Abschnitt 3.2.2 festgestellt, ist die teuerste Operation in
dem Zugriffsplan der Zugriff auf die Koordinaten der Geometrien. Damit der
Optimierer den Aufwand korrekt abschätzen kann, muss die Selektivität der
räumlichen Indizes möglichst exakt bestimmbar sein (vgl. Abbildung 3.5).
Die Selektivität gibt dabei an, wie viele Einträge durch den Index ausgewählt
werden. Im Allgemeinen kann der Optimierer aus den Statistiken über den
Index auf die Selektivität schließen. Da es sich bei dem räumlichen Index
um einen nutzerdefinierten handelt und keine Statistiken über die Verteilung
der Geometrien im einbettenden Datenraum existieren, wird standardmäßig
eine vordefinierte Selektivität angenommen. Alternativ kann der Nutzer den
Wert explizit angeben. Da bei den Experimenten die Selektivitäten nur unzureichend bekannt sind, können die vom generierten Zugriffsplan stammenden
Aufwandsabschätzungen nicht als Vergleichskriterium eingesetzt werden.
Deshalb wurden zum Bewerten der unterschiedlichen Konfigurationen
für einen räumlichen Index Vergleichstests durchgeführt. Auf Basis von den
durchgeführten Vergleichstest lassen sich Aussagen über die Anzahl der gelesenen bzw. zugegriffenen Seiten sowie die Dauer der Anfrage treffen. Die
Anzahl der durch das mehrdimensionale Zugriffsverfahren ausgewählten Indexeinträge (gültige und ungültige Treffer) lässt sich nur implizit durch die
Anzahl der Seitenzugriffe ableiten.
Experimente zu Punktdaten
Für die Bewertung der Heuristiken zur Konfiguration eines räumlichen Index
auf einer Tabelle, die ausschließlich Punktdaten enthält, wurden räumliche
Indizes mit verschiedenen Zellgrößen erstellt und anschließend Bereichsanfragen ausgeführt. Dieser Abschnitt beschreibt die Durchführung der Experimente sowie deren Resultate.
Wie bereits festgestellt wurde, ist für den Nutzen des räumlichen Zugriffsverfahren die Auswahl der Gittergröße in Abhängigkeit von der Datenverteilung von entscheidender Bedeutung. Aus diesem Grund ist eine
gleichmäßige Verteilung der Daten weniger aussagekräftig; vielmehr muss
das Verhalten unterschiedlicher Gittergrößen bei ungleichmäßiger Datenverteilung untersucht werden.
Dazu wurde zuerst eine Tabelle mit Punktdaten (insgesamt 50.000 Einträge) mit einer ungleichmäßigen Datenverteilung erstellt. Die Abbildung 3.7
zeigt die Verteilung der Daten – der überwiegende Teil der Punkte konzentriert sich im Zentrum des Datenraumes. Die dargestellte Verteilung stellt
einen Bezug zu der Aussage her, dass bei kartografischen Daten urbane Zentren besonders viele räumliche Objekte beinhalten.
49
Abbildung 3.7: Punkteverteilung im Datenraum
Für die entstandene Tabelle wurden nacheinander räumliche Indizes mit
einem Gitter und verschiedener Zellgröße angelegt und anschließend zwei Arten von Anfragen ausgeführt. Der erste Anfragetyp (Zentrum) beinhaltete
Bereichsanfragen, deren Mittelpunkte im Zentrum des Datenbereichs lagen,
während bei dem zweiten (Rand) die Mittelpunkte der Anfragefenster deutlich außerhalb des Zentrums gewählt wurden. Die Fläche des Anfragefensters
war dabei in allen Fällen identisch 1 E 2 (das verwendete Maß sind Einheiten). Die Anfragen selektierten aus dem Datenbereich rund 7000 Punkte im
Zentrum bzw. 100 Punkte am Rand. Der Abstand eines Punktes zu seinem
nächsten Nachbarn liegt im Zentrum in der Größenordnung von 0.003 E.
Die Tabelle 3.2 fasst die Ergebnisse der Anfragen für ausgewählte Gittergrößen zusammen. Gemessen wurde die für die Beantwortung der Anfrage
benötigte Gesamtzeit sowie die anteilige CPU-Zeit. Wie sich herausstellte,
ist ein nicht zu vernachlässigender Faktor die für Sortiervorgänge benötigte
Zeit (vgl. Abbildung 3.7); daher wurde sie mit in die Tabelle aufgenommen.
Da die Häufigkeit des Zugriff auf den Sekundärspeicher einen Indikator für
die Güte des räumlichen Indizes darstellt, wurden zusätzlich die Anzahl der
gelesenen Daten- und Indexseiten erfasst.
Bei der Auswertung der Ergebnisse ist zu bedenken, dass die Anfragen
mehrmals hintereinander ausgeführt wurden und somit die Daten- und Indexseiten im Hauptspeicher und zum Teil im Puffer des DBMS vorlagen.
Damit lässt sich erklären, warum die CPU-Zeit einen großen Anteil an der
Gesamtzeit hat und teilweise keine Indexseiten gelesen wurden. Diese Vorgehensweise hat sehr geringen Einfluss auf die Anzahl der gelesenen Daten- und
Indexseiten. Vergleichstests mit leerem“ Hauptspeicher und Datenbankpuf”
50
fer bestätigen, dass sich hauptsächlich die benötigte Gesamtzeit aufgrund
der Sekundärspeicherzugriffe verlängert.
Anfragetyp
Zentrum
Rand
Gittergröße (E)
3e0
3e−1
3e−3
3e−5
3e0
3e−1
3e−3
3e−5
Zeit
Ges.
5,558
3,225
3,334
3,285
4,076
0,180
0,160
0,161
(s)
CPU
4,456
3,124
3,255
3,145
2,343
0,130
0,130
0,130
Seitenzugriffe
Daten Index
2664
443
2495
169
2507
178
2468
158
1128
449
76
0
80
0
83
0
Sort
(ms)
1369
183
177
171
2193
2
2
2
Tabelle 3.2: Ergebnisse der Experimente zu Punktdaten
Zunächst lässt sich feststellen, dass für die Bearbeitung des Anfragetyps
Zentrum mehr Zeit und Seitenzugriffe benötigt werden als bei der äquivalenten Anfrage des Typs Rand. Ein anderes Ergebnis war nicht zu erwarten,
da im Zentrum wesentlich mehr Geometrien selektiert und somit mehr Berechnungen durchgeführt werden.
Betrachtet man den Anfragetyp Zentrum, so fällt auf, dass obwohl annähernd gleich viele Datenseiten gelesen wurden, die Ausführungszeit des gröbsten Gitters fast doppelt so hoch wie bei den feineren Gittern ist. Weiterhin
wurden doppelt so viele Indexseiten zugegriffen. Daraus lässt sich für das
grobe Gitter ableiten, dass ein großer Teil der Rechenzeit beim Zugriff auf
den Index (inklusive anschließendem Sortieren) investiert wurde. Aufgrund
der um ein Vielfaches höheren Indexseitenzugriffe und dem hohen Aufwand
für das Sortieren liegt der Schluss nahe, dass wesentlich mehr Punkte durch
eine Gitterzelle selektiert wurden. Da die Anzahl der Tupel im Ergebnis
konstant blieb, mussten offensichtlich viele ungültige Treffer im Filterschritt
eliminiert werden. Die Vermutung wird durch die Tatsache untermauert,
dass bei einer Verzehnfachung der Seitenlänge eines Gitters die hundertfache Anzahl von Punkten in einer Zelle enthalten sind (Gleichverteilung
vorausgesetzt).
Innerhalb des Anfragetyps Rand bemerkt man, dass beim Index mit dem
größten Gitter mehr Zeit und häufigere Seitenzugriffe zur Beantwortung der
Anfrage erforderlich waren. Der immense Sprung ist vermutlich dadurch
begründet, dass die selektierten Gitterzellen derart ungünstig lagen, dass
viele Punkte des Zentrums einbezogen wurden.
Gemeinsam für beide Anfragetypen ergibt sich die Aussage, dass bei
einer Verfeinerung des Gitter, wobei die Seitenlänge einer Zelle nahe bzw.
unterhalb des Abstandes eines Punktes zu seinem nächsten Nachbarn liegt,
keine wesentliche Verbesserung des räumlichen Index erreicht wird. Das lässt
51
sich zum einen damit begründen, dass die bei der Verfeinerung zusätzlich
entstehenden Zellen nur geringfügig die Verteilung der Punkte auf die Zellen
beeinflusst. Zum anderen wirkt sich die Veränderung des Verhältnisses der
Flächen von Gitterzelle und Anfragefenster stärker auf die Performanz des
räumlichen Index aus als bei Anfragen im Zentrum.
Zusammenfassend werden durch die durchgeführten Experimente die
Aussagen des Theorems 3.1 bestätigt, wobei eine Überprüfung der Aussage
für große Datenmengen noch nicht erfolgte.
Experimente zu räumlich ausgedehnten Geometrien
Während bei Punktdaten nur eine einzige Gittergröße berücksichtigt werden
musste und außerdem die Einflussgrößen auf die Konfiguration gut bekannt
waren, ergeben sich bei räumlich ausgedehnten Geometrien zusätzliche Parameter. Abgesehen davon, dass bis zu drei Gitter zu konfigurieren waren, sind
die Formen und Größen sowie die Zusammensetzung der Testdaten sehr variabel. Im folgenden Abschnitt werden zunächst die verwendeten Datensätze
charakterisiert und anschließend ausgewählte Ergebnisse der durchgeführten
Vergleichstests präsentiert.
Bei den Experimenten wurden zwei unterschiedliche Datensätze verwendet. Der erste Datensatz stellt einen Auszug aus der GIS-Datenbank (Straßennetz) dar, während der zweite zufällig generiert wurde. Die Abbildungen
3.8 und 3.9 geben einen Überblick über die Struktur der Daten. Zur Verbesserung der Darstellung werden nur Ausschnitte der verwendeten Daten
gezeigt.
Abbildung 3.8: Straßennetz aus
der GIS-Datenbank (Ausschnitt)
Abbildung 3.9: Zufällig generierte
Geometrien (Ausschnitt)
Insgesamt umfasste das Straßennetz rund 113.000 und der zweite Da-
52
tensatz 50.000 Geometrien. Es wurden zwei in der Struktur verschiedene
Datensätze ausgewählt, um die oben aufgestellten Heuristiken besser überprüfen zu können. Zuerst werden die Experimente mit den Daten des Straßennetzes dokumentiert und anschließend wird auf die Zufallsgeometrien
eingegangen.
Anzahl der Geometrien
Straßennetz Bereits an den obigen Abbildungen erkennt man die sehr unterschiedliche Struktur der Daten. Das Straßennetz besteht aus sich kaum
überlagernden Linienzügen und hat demzufolge eine geringere Datendichte.
Obwohl nachfolgend weniger die Datenverteilung im Vordergrund steht, so
charakterisiert eine annähernd gleichmäßige Verteilung die Daten. Wie sich
aus der Statistik über die maximalen Ausdehnung der Geometrien in Abbildung 3.10 ergibt, existieren viele Geometrien mit einer ähnlichen maximalen
Ausdehnung nahe 1e−3 E.
50000
45000
40000
35000
30000
25000
20000
15000
10000
5000
0
0
0.01
0.02
0.03
0.04
0.05
maximale Ausdehnung (E)
0.06
0.07
Abbildung 3.10: Ausdehnungen der Geometrien (Straßennetz)
Zur Erstellung der Statistik wurden die maximalen Ausdehnungen der
Geometrien auf drei Stellen hinter dem Komma gerundet und anschließend
die Anzahl der Geometrien mit gleicher Ausdehnung bestimmt. Diese Statistik lässt sich sehr einfach und schnell berechnen, da die minimalen und
maximalen Koordinaten einer Geometrie separat im strukturierten Datentyp
gespeichert und direkt zugreifbar sind. Bei einem geringen Umfang der Daten kann ein Tablescan mit anschließender Gruppierung verwendet werden.
Befinden sich besonders viele Datensätze in einer Tabelle, kann der Aufwand
durch Auswahl eines repräsentativen Ausschnitts reduziert werden.
Durch die eben erwähnte Rundung der Ausdehnungen erkennt man den
großen Anteil kleiner Geometrien mit einer maximalen Ausdehnung um die
1e−3 E besonders gut. Da die Geometrien nicht besonders dicht im Datenraum liegen, werden in Übereinstimmung mit den Heuristiken auf Seite 46 alle Geometrien mit einer Ausdehnung kleiner als ca. 1e−2 E gemeinsam betrachtet. Den Heuristiken weiter folgend bilden die Gittergrößen
53
2e−2 E, 4e−2 E und 6e−2 E einen guten Ausgangspunkt für eine performante Konfiguration. Das größte Gitter wurde so gewählt, dass die wenigen
größeren Geometrien mit wenig Clipping verarbeitet werden können.
Auf der Grundlage dieser Werte wurden mehrere Versuche durchgeführt,
wobei ein Teil der Ergebnisse in Tabelle 3.3 zusammengefasst wurde. Gemessen wurde die Anzahl Indexeinträge, die insgesamt benötigte Zeit inklusive
Ausgabe des Ergebnisses sowie die anteilige CPU-Zeit. Die Anzahl der Indexeinträge wurde mit Hilfe der Datenbankstatistiken zu Indizes ermittelt.
Da dort nur die Anzahl der voneinander verschiedenen Werte ausgelesen
werden kann, bilden die Angaben in der Tabelle eine untere Grenze. Weiterhin wurden die Anzahl der zugegriffenen Daten- bzw. Indexseiten festgehalten. Da die für das Sortieren benötigte Zeit Rückschlüsse auf die Anzahl
der durch den Indexzugriff gelieferten Ergebnisse zulässt, wurde dieser Wert
ebenfalls in die Tabelle aufgenommen.
Gittergr. (E)
IndexZeit (s)
Seitenzugr.
1
2
3 eintr.
Ges. CPU Dat
Idx
Anfragefenster 0, 01 × 0, 01 E 2
1e-3 2,5e-2 5e-2 ≥ 212010 0,401 0,361
232
72
1,5e-2
4e-2 6e-2 ≥ 130524 0,141 0,100
0
0
2e-2
4e-2 6e-2 ≥ 126013 0,180 0,130
93
11
8e-2
2e-1 4e-1 ≥ 115915 0,301 0,240
143
49
Anfragefenster 0, 5 × 0, 5 E 2
1e-3 2,5e-2 5e-2 ≥ 212010 2,724 2,574 1034
579
1,5e-2
4e-2 6e-2 ≥ 130524 2,193 2,053 1017
327
2e-2
4e-2 6e-2 ≥ 126013 2,113 2,063 1071
323
8e-2
2e-1 4e-1 ≥ 115915 2,183 2,103 1031
284
Sort
(ms)
29
2
4
22
425
296
290
296
Tabelle 3.3: Ergebnisse der Experimente zu räumlich ausgedehnten Geometrien (Straßennetz)
Zur Durchführung der Vergleichstests wurden Bereichsanfragen mit unterschiedlicher Ausprägung an die Datenbasis gestellt und dabei die Gittergrößen zum Teil erheblich variiert. Der erste Anfragetyp selektierte 128 und
der zweite 1610 Datensätze bei einer Seitenlänge des Fensters von 0.01 E
bzw. 0.5 E. Analog zu den Experimenten mit Punktdaten wurde jede Anfrage mehrmals hintereinander ausgeführt und erst das letzte Messergebnis
gewertet. Da dadurch der überwiegende Teil der Datenbankseiten im Hauptspeicher bereits zwischengespeichert wurden, konnten die Einflüsse des Sekundärspeichers größtenteils eliminiert werden. Die Nullen in der Tabelle
lassen sich damit erklären, dass die benötigten Daten- und Indexseiten bereits im Datenbankpuffer vorhanden waren und nicht mehr geladen werden
mussten.
Zunächst fällt auf, dass die Anzahl der Indexeinträge mit Vergrößerung
54
der Gitterzellen abnimmt, was mit den Folgerungen aus dem Lemma 3.1
auf Seite 44 übereinstimmt. Bei einer Gittergröße nahe dem Wert, den die
meisten Geometrien als maximale Ausdehnung haben (vgl. Abbildung 3.10),
verdoppelt sich die Anzahl der Indexeinträge im Vergleich zu der zweiten
Konfiguration. Im Zusammenhang damit bemerkt man einen Anstieg der
zugegriffenen Indexseiten.
Betrachtet man die benötigten Gesamtzeiten, so liegen die besten Ergebnisse in der Nähe der durch die Heuristiken vorgeschlagenen Konfiguration.
Extremwerte in der Konfiguration führen bei dem kleinen Anfragefenster zu
starken Performanzeinbußen, da in diesen Fällen viele Daten- und Indexseiten zugegriffen werden. Auffällig bei dem großen Anfragefenster (0, 5 E)
ist, dass trotz der sehr groß gewählten Gitter der Performanzverlust gering
ausfällt. Dies könnte damit begründet werden, dass die weniger zugegriffenen Indexseiten Einfluss haben und/oder zufällig eine gute Überdeckung
von Gitterzelle und Anfragefenster auftrat, so dass wenige ungültige Treffen
entstanden. Dies wird aus der annähernd gleichen Sortierzeit beim kleinen
und großen Anfragefenster geschlossen.
Anzahl der Geometrien
Zufällig generierte Geometrien Nachdem die Daten aus der GIS-Datenbank zum testen genutzt wurden, erläutert dieser Teil die Experimente
mit den zufällig erzeugten Daten. Der zufällig generierte Datensatz zeichnet
sich dadurch aus, dass sich viele Geometrien im Zentrum des einbettenden
Datenraumes konzentrieren und sich dadurch zahlreiche Überlagerungen ergeben (vgl. Abbildung 3.9). Aufgrund des Verfahrens bei der Erzeugung der
Geometrien bilden sich viel mehr unterschiedliche Ausdehnungen als beim
Straßennetz. Die Anzahl der Punkte, die Platzierung sowie die Koordinaten
selbst wurden durch einen Zufallsgenerator ermittelt. Die Abbildung 3.11
visualisiert die dabei aufgetretenen maximalen Ausdehnungen.
1800
1600
1400
1200
1000
800
600
400
200
0
0
1
2
3
4
maximale Ausdehnung (E)
5
6
Abbildung 3.11: Ausdehnung der Geometrien (Zufallsgeometrien)
In der Mitte des Graphen erkennt man eine lang gestreckte Zone, in der
55
verschiedene maximale Ausdehnungen annähernd gleich oft angenommen
wurden. Unter Verwendung der aufgestellten Heuristiken (S. 46) wurden die
Gittergrößen 4 E, 6 E und 8 E als Ausgangspunkt für die Experimente benutzt. Die ersten beiden Gittergrößen wurden aus den empirisch festgelegten
Häufungspunkten 2 E und 3 E ermittelt, während der letzte Wert aufgrund
der maximalen Ausdehnung aller Geometrien gewählt wurde. Damit nehmen
die ersten beiden Gitter den größten Teil der Geometrien auf.
Die Anfragen mit einer Kantenlänge von 1 E und 10 E selektierten aus
der Datenbasis mit den 50.000 zufällig generierten Geometrien etwa 450
bzw. 9600 Datensätze. Die Tabelle 3.4 zeigt die Ergebnisse der durchgeführten Vergleichstests. Die gemessenen Größen sind die gleichen wie in dem
vorherigen Experiment.
Gittergr. (E)
1 2
3
2
4
4
8
3
6
8
12
5
8
12
-
2
4
4
8
3
6
8
12
5
8
12
-
IndexZeit (s)
Seitenzugriffe
einträge Ges. CPU Daten Index
Anfragefenster 1 × 1 E 2
≥ 129717 0,741 0,651
483
60
≥ 95421
0,971 0,911
756
81
≥ 95355
1,092 0,951
733
72
≥ 66536
1,462 1,402
1009
177
2
Anfragefenster 10 × 10 E
≥ 129717 5,147 4,997
3385
468
≥ 95421
5,187 5,077
3415
451
≥ 95355
5,157 5,047
3376
400
≥ 66536
4,496 4,426
3324
179
Sort
(ms)
25
67
69
181
385
398
400
188
Tabelle 3.4: Ergebnisse der Experimente zu räumlich ausgedehnten Geometrien
Da die Tabellen für die Vergleichstests mit den Straßennetzdaten ausführlich erläutert wurden, werden hier nur besondere Auffälligkeiten diskutiert. Eine solche Besonderheit stellen die Experimente mit den sehr großen
Gittern 8 E und 12 E dar. Bezogen auf das kleine Anfragefenster werden
zum Teil doppelt so viele Daten- und Indexseiten verarbeitet als bei den
anderen Gitterkonfigurationen. Der große Zeitaufwand beim Sortiervorgang
lässt darauf schließen, dass der Indexzugriff besonders viele (gültige und
ungültige) Treffer zurückgegeben hat. Im Kontrast dazu erbringt dieselbe
Konfiguration bei dem großen Anfragefenster mit Abstand das beste Ergebnis. Dies ist wahrscheinlich darauf zurückzuführen, dass zum einen sehr wenige Gitter geschnitten wurden und zum anderen sehr viele der Geometrien
aus einer Zelle in das Anfrageergebnis übernommen werden konnten. Bemerkenswert bei den großen Gitterzellen sind auch die Messergebnisse bezüglich
der zugegriffenen Indexseiten und der benötigten Sortierzeit. Die bezüglich
der Ergebnisse zu dem großen Anfragefenster sehr kleinen Messwerte sind
56
im Vergleich zu der analogen Anfrage mit kleinem Anfragefenster nahezu
identisch. Eine Ursache dafür liegt vermutlich in der Überlappung der Anfragefenster, so dass dieselben Zellen von dem Anfrage Fenster geschnitten
wurden.
Insgesamt liefern die aufgestellten Heuristiken für räumlich ausgedehnte Geometrien einen guten Anhaltspunkt für eine performante Konfiguration. Eine anschließende Überprüfung von leicht variierenden Konfigurationen
ermöglicht eine Verbesserung der Leistung. Aus den Experimenten lässt sich
schlussfolgern, dass die Position und die Größe des Anfragefensters unmittelbaren Einfluss auf die Performanz haben.
Nicht betrachtete Aspekte
Bei den durchgeführten Experimenten konnten nicht alle Aspekte eingehend
betrachtet werden. Daher wurden in diesem Abschnitt mögliche weitere Einflussgrößen auf die Performanz des mehrdimensionalen Zugriffsverfahrens
zusammengestellt.
Die Experimente werden an Tabellen ohne Nutzlast durchgeführt, das
heißt, außer dem räumlichen Objekt enthielten die Tabellen nur noch eine
Identifikator. Da die Geometrien, sofern diese nicht zu groß sind, zusammen
mit anderen Attributen abgespeichert werden, liegt die Vermutung nahe,
dass die Geometrien bei umfangreicher Nutzlast noch stärker auf verschiedenen Datenbankseiten verstreut werden. Dadurch wird eine möglichst genaue
Selektion im Filterschritt um so wichtiger, um möglichst wenige Datenseiten
lesen zu müssen. In diesem Kontext ergibt sich die Frage, welchen Einfluss
die Größe der Datenbankseiten auf die Performanz der Anfragebearbeitung
hat.
Ein anderer Aspekt, der bisher nicht näher untersucht wurde, ist die Bedeutung des Anfragefensters auf die Performanz des Zugriffsverfahrens. Es
ist anzunehmen, das die Position des Fensters unmittelbaren Einfluss auf
die Performanz der Anfragebearbeitung hat, da zum einen die Anzahl der
geschnittenen Gitterzellen und zum anderen die Anzahl der (ungültigen)
Treffer verändert wird. Wie die Größe des Anfragefensters sich auf die Performanz und die Konfiguration des Zugriffsverfahrens auswirkt, wurde nur
am Rande betrachtet.
Die durchgeführten Experimente wurden ausschließlich mit kleinen Datenmengen vorgenommen, da die Tests mit verschiedenen Konfigurationen
aufgrund des nicht zu vernachlässigen Zeitaufwands zum Aufbau der unterschiedlichen Indizes in dem gegebenen Zeitrahmen der Diplomarbeit nicht
durchführbar waren. Demzufolge lassen sich keine konkreten Aussagen zur
Skalierbarkeit treffen.
Im Rahmen der Diplomarbeit wurden keine Vergleiche zu anderen mehrdimensionalen Zugriffsverfahren durchgeführt. Durch derartige Vergleiche
wäre eine bessere Abschätzung der Leistungsfähigkeit des DB2 Spatial Ex-
57
tenders möglich.
3.2.6
Bewertung
In den vorangegangenen Abschnitten wurden unterschiedliche Aspekte des
mehrdimensionalen Zugriffsverfahrens des DB2 Spatial Extenders betrachtet. Dieser Abschnitt greift die wesentlichen Erkenntnisse zusammenfassend
auf und wertet die durchgeführten Experimente unter Einbeziehung der aufgestellten Thesen aus.
Das mehrdimensionale Zugriffsverfahren des DB2 Spatial Extender ist
eine einfach zu realisierende und unkomplizierte Methode räumliche Daten
zu indizieren. Es werden keine aufwendigen Operationen zum Aufbau eines
Baumes oder Verzeichnisses benötigt, da alle Indexeinträge mathematisch
ermittelt werden können. Weil die Quellen des DB2 Spatial Extender nicht
zugänglich waren, konnte insbesondere der unmittelbare Indexzugriff nur
auf einer hohen Abstraktionsebene beschrieben werden. Die Frage, wie die
Indexeinträge dazu benutzt werden, um die zu den Geometrien gehörenden
internen Identifikatoren zu ermitteln, bleibt unbeantwortet.
Bei der Konfiguration des mehrdimensionalen Zugriffsverfahren sind die
Eigenschaften der zu verwaltenden räumlichen Objekte besonders zu berücksichtigen. Eine grundlegende Veränderung der Eigenschaften der gespeicherten Geometrien durch Einfüge- und Löschoperationen erfordert im Laufe der
Zeit eine Prüfung der Konfiguration und gegebenenfalls eine Neuerstellung
des Index. Wird auf die Datenbasis ausschließlich lesend zugegriffen, wirkt
sich dieses Charakteristikum weniger stark aus. Im Kontrast dazu ist eine
Neuerstellung des Index insbesondere für große Datenmengen nicht praktikabel.
Im weiteren Verlauf der Analyse wurden Methoden zur Ermittlung einer performanten Konfiguration entwickelt und anschließend experimentell
überprüft. Es hat sich gezeigt, dass eine performante Konfiguration für
Punktdaten einfachen Regeln folgt, während für beliebige räumlich ausgedehnte Objekte nur Heuristiken angegeben werden konnten. Die Vergleichstests bestätigten überwiegend die aufgestellten Theorien. Jedoch bedarf es
insbesondere bei räumlich ausgedehnten Geometrien einer Untersuchung unterschiedlicher Konfigurationen, um in Abhängigkeit von den zu erwartenden
Anfragen eine optimale Konfiguration zu erhalten.
Kapitel 4
Webservices
Der Erfolg des Internets basiert auf einigen wesentlichen Faktoren: Einfachheit und Omnipräsenz. Insofern ein Service-Anbieter eine Webseite erstellen
kann, ist dieser in der Lage, an der weltweiten Internet-Gemeinschaft teilzunehmen. Auf der Seite eines Nutzers genügt die Kenntnis über die Eingabe
von Webadressen, um vielfältige Informationen und Dienstleistungen in Anspruch nehmen zu können. Der Grundgedanke der Webservice-Bewegung
ist, die Idee des einfachen Zugangs zu Informationen auch auf Services auszudehnen. Dabei meint der Begriff Services keine monolithischen Angebote,
sondern er umfasst vielmehr Komponenten, die von anderen zum Zusammensetzen größerer Applikationen oder Services genutzt werden können.
[Vas00]
Webservices repräsentieren eine Revolution der Möglichkeiten im Bereich
des e-Business [Col01]. Diese Technologie gestattet die Entwicklung dynamischer e-Business Applikationen auf der Basis wiederverwertbarer Softwaremodule die über das Internet eingebunden werden. Der Nutzen des
Webservice beinhaltet nicht nur den Business-to-Consumer (B2C) Bereich,
sondern erlaubt auch die Interoperabilität von Systemen zwischen verschiedenen Business-Partnern (B2B).
Dieses Kapitel widmet sich dem Design eines Webservice zur Veröffentlichung von Diensten auf der Basis einer GIS-Datenbank. In den ersten Abschnitten werden die grundlegenden Konzepte und Begriffe aus dem Bereich Webservice erläutert, damit deren Zusammenwirken bei der späteren
Realisierung eines Webservice besser nachvollzogen werden kann. Weiterhin
wird die generelle Webservice-Architektur mit ihren Bestandteilen ServiceVerzeichnis, Anbieter und Klient vorgestellt. Zuletzt werden einige Vor- und
Nachteile von Webservices abgewogen.
Im zweiten Teil dieses Kapitels wird auf die konkrete prototypische Realisierung eines Webservice eingegangen. Im Rahmen einer Testumgebung
wird ein Webservice-Verzeichnis aufgesetzt, ein Webservice publiziert und
durch einen Klienten genutzt. Der implementierte Webservice liefert zu ei58
4.1. WEBSERVICE – EIN ALLGEMEINER BEGRIFF
59
nem gegebenen Standort eine Liste mit bedeutsamen Einrichtungen wie zum
Beispiel Tankstellen oder Krankenhäuser. Die relevanten Informationen werden dabei mit Unterstützung einer GIS-Datenbank ermittelt. Insbesondere
wird in diesem Teil auf die verwendeten Werkzeuge sowie die Modellierung
des Webservice eingegangen.
4.1
Webservice – ein allgemeiner Begriff
Es gibt seit geraumer Zeit über das Internet (Web) zugängliche Dienstleistungen (Services). Es lassen sich die verschiedensten Dinge online erledigen,
sei es der Erwerb von Büchern, Blumen bzw. Fahrscheinen für die Deutsche
Bahn, die Beteiligung an Auktionen oder die Erledigung des Wocheneinkaufs. Was unterscheidet die überall Aufregung auslösenden Webservices von
den eben genannten Internet-Dienstleistungen? Was macht einen Webservice
aus und warum ist dieser Gedanke so revolutionär? Diese und andere Fragen
werden in diesem Abschnitt aufgegriffen und soweit wie möglich geklärt.
4.1.1
Eine Definition
Eine die wesentlichen Aspekte zusammenfassende Definition für Webservice
wurde in einem Tutorial von Doug Tidwell1 veröffentlicht [Tid00]:
Web services are a new breed of Web application. They are
”
self-contained, self-describing, modular applications that can be
published, located, and invoked across the Web. Web services
perform functions that can be anything from simple requests
to complicated business processes. A sample Web service might
provide stock quotes or process credit card transactions. Once
a Web service is deployed, other applications (and other Web
services) can discover and invoke the deployed service.“
Verglichen mit anderen Umschreibungen für den Begriff Webservice z. B.
in [Kir01], [Ste01a] oder [Hew01] ergeben sich grundlegende Eigenschaften
für einen Webservice. Ein Webservice ist eine in sich abgeschlossene Softwarekomponente, in [Kir01] wird dabei auch von einer Blackbox gesprochen, um deren Inhalt man sich nicht mehr zu kümmern braucht. In sich
abgeschlossen heißt, dass die entwickelte Komponente eine klar umrissene
Funktionalität zur Verfügung stellt.
Durch die Veröffentlichung einer Servicebeschreibung inklusive Schnittstelle in einem Netzwerk (insbesondere Internet), kann ein Webservice lokalisiert und zum Zusammensetzen lose gekoppelter, höherwertiger Services
genutzt werden. Ein wesentliches Ziel der Veröffentlichung von Webservices
1
Er wird in diesem Tutorial als IBM’s Evangelist für Webservices bezeichnet.
60
KAPITEL 4. WEBSERVICES
ist die Unterstützung der Wiederverwendung von Komponenten. Die Forderung nach geringer Koppelung erlaubt ein einfaches Austauschen von Komponenten und Rekonfiguration, ohne tief in das System eingreifen zu müssen.
Implizit aus der Veröffentlichung der Webservices ergibt sich eine Verteilung
der Anwendung über das Internet.
Die Beschreibung der spezifischen Funktionalität eines Webservice ist
dabei ebenso standardisiert wie das auf Nachrichten basierende Kommunikationsprotokoll zwischen Serviceanbieter und -nutzer. Bei dem Verwenden
von Webservices ist es unerheblich, welche Plattform oder Implementationssprache der Anwender nutzt, solange Möglichkeiten zum Erzeugen und
Konsumieren von Nachrichten existieren.
4.1.2
Wichtige Standards
Ein markanter Unterschied zu den schon existierenden Dienstleistungen im
Internet lässt sich bereits jetzt festhalten: Die Beschreibung der Funktionalität und der Kommunikationsverfahren eines Webservice sowie die Kommunikation selbst sind standardisiert. Die Standards, auf denen Webservices
aufbauen, werden von den Mitarbeitern unterschiedlichen Firmen (IBM, Microsoft, SUN) in Kooperation erarbeitet. Dieser Abschnitt stellt die Zusammenhänge zwischen den wichtigsten Standard vor.
Bisherige Standards für die Kommunikation bei verteiltem Rechnen wie
Corba, Distributed Smalltalk oder Java RMI resultierten in eng gekoppelten Systemen. Diese Ansätze erfordern zu viele Vereinbarungen zwischen
Systemen unterschiedlicher Organisationen, um eine Basis für eine offene,
allgegenwärtige e-Business-Lösung im Internet zu bilden. Zum Beispiel ist
DCOM ein Microsoft-Standard und funktioniert daher am besten auf Windowsplattformen. Das Pendant zu DCOM bildet mit ähnlichen Restriktionen CORBA auf UNIX-Plattformen. Entsteht nun eine Situation, in der
sowohl mit DCOM als auch mit CORBA operiert werden muss, sind aufgrund der grundsätzlichen Unterschiede zwischen den beiden Protokollen
zuerst schwerwiegende Konflikte zu lösen. [Ada01]
Der Trend aber bewegt sich zu lose gekoppelten und dynamisch gebundenen Systemen. Zum Erreichen von lose gekoppelten Systemen wurde das
RPC-Protokoll Simple Object Access Protocol (SOAP) auf der Basis von
XML entwickelt. Diese beiden Standards bilden das Fundament auf dem
Webservices aufbauen.
XML wurde in einer Arbeitsgruppe des World Wide Web Consortiums (W3C) 1996 entwickelt. Damit entstand eine einfach über das Internet verwendbare Sprache, die eine Vielzahl unterschiedlicher Applikationen
unterstützt. Zentrales Ziel ist das Erreichen einer Einfachheit im Umgang
mit der Sprache, indem XML-Dokumente auch für Menschen lesbar und
verständlich sind und so weit wie möglich auf optionale Features verzichtet
wird. [W3C00a]
61
Allein die Möglichkeit, auf einfache Art plattformübergreifend mit anderen Systemen kommunizieren zu können, reicht nicht aus, die oben beschriebenen lose gekoppelten und dynamisch gebundenen Systeme zu realisieren
– es fehlt eine Institution, die Anbieter und Nutzer zusammenbringt. Bis
vor kurzem gab es keine zentrale, standardisierte und einfache Möglichkeit
Informationen darüber zu erlangen, welche Standards unterschiedliche Unternehmen unterstützen. Des Weiteren existierte kein zentraler Anlaufpunkt
zum Herstellen von Kontakten zu allen Anbietern eines bestimmten Service.
Das Lösen der Kommunikationsprobleme erfordert eine Verzeichnisarchitektur, die das Registrieren, Finden und Kontaktieren unternehmensübergreifend standardisiert. Unter diesem Leitgedanken entwickelten führende
Unternehmen in Technologie und e-Business gemeinsam die Universal Description, Discovery and Integration (UDDI) Spezifikation. Diese Spezifikation beschreibt ein plattformunabhängiges Framework zum Auffinden von
Businesspartnern, zum Interagieren von Unternehmen über das Internet und
zum Austauschen von Informationen, realisiert als ein globales Verzeichnis.
[udd00a]
Das Modell für eine Webservice-Architektur stellt Abbildung 4.1 dar.
Die Abbildung zeigt die drei Rollen Verzeichnis (Service Registry), Klient
(Service Requestor) und Anbieter (Service Provider), die im Rahmen von
Webservices entstanden sind, sowie die dazugehörigen Operationen. Weiterhin sind die involvierten Spezifikationen angetragen wie sie in der Diplomarbeit angewendet wurden. Veränderte Randbedingungen können dazu
führen, dass andere Spezifikationen verwendet werden; zum Beispiel ist die
Service-Beschreibung mit WSDL nicht zwingend notwendig.
UDDI
Service
Verzeichnis
Finden
Publizieren
WSDL
WSDL
SOAP
Service
Klient
Binden
Service
Anbieter
Abbildung 4.1: Webservice Modell [Kre01]
Das Service-Verzeichnis dient Anbietern als Plattform zur Veröffentlichung von Webservices. Dazu beschreiben Anbieter die Schnittstellen sowie
die Zugriffspunkte (eine URL) für den Webservice mittels der Webservice
Description Language (WSDL) und registriert (publish) diesen in dem Ver-
62
zeichnis.
Sucht ein Nutzer eine bestimmte Dienstleistung, so bietet das Verzeichnis die Möglichkeit, Webservices aufgrund unterschiedlicher Kriterien aufzufinden (find). Über die WSDL-Beschreibung erfährt der Klient, wie die
Schnittstelle des Webservice aufgebaut ist, welche Kommunikationsprotokolle (z.B. SOAP RPC über HTTP) unterstützt werden und wie der Webservice erreicht werden kann. Nachdem die Wahl des Webservice feststeht, kann
der Nutzer entsprechende Nachrichten an den Anbieter senden (bind). Der
Nachrichtenaustausch zwischen den drei Systemen basiert dabei auf SOAPNachrichten, die auf XML-Dokumente aufbauen.
Der erste Abschnitt ordnet die verschiedenen Standards in einem Schichtenmodell ein, um einen Überblick über die Abhängigkeiten zwischen den
Spezifikationen zu geben. Da schon seit längerer Zeit XML ein weit verbreiteter und bekannter Standard ist, soll auf XML hier nur insofern eingegangen
werden, als es im Kontext zu SOAP behandelt wird. Im dann folgenden
Abschnitt wird das Kommunikationsprotokoll und der RPC-Mechanismus
beschrieben, wie sie im SOAP-Standard festgelegt sind. Zur Beschreibung
der Schnittstelle eines Webservice bietet sich die WSDL-Spezifikation an,
die anschließend vorgestellt wird. Nachdem das unternehmensübergreifende
und globale Verzeichnis UDDI beschrieben wurde, werden Verknüpfungen
zwischen WSDL und den UDDI-Datentypen hergestellt.
Webservice-Architektur
Wie bereits in Abbildung 4.1 aufgezeigt, bestehen die Hauptoperationen
des Webservice-Modells aus Publizieren (publish), Finden (find) und Binden
(bind). Damit die Operationen problemlos genutzt werden können, müssen
diese auf einer gemeinsamen Basis aufbauen. Zur Gewährleistung der Interoperabilität basieren die Schichten der Webservice-Architekturen auf offenen
Standards.
Da die verschiedenen Unternehmen und Organisationen eine individuelle
Vorstellung von Webservices haben, entstanden mit der Zeit unterschiedliche
Schichtenmodelle. In diesem Abschnitt wird das konzeptionelle Schichtenmodell von IBM vorgestellt, da es weitestgehend akzeptiert wurde und sich
auch als Quasi-Industriestandard etabliert hat [Mye02, SHSF01].
Das in [Kre01] veröffentlichte Schichtenmodell wird in Abbildung 4.2
gezeigt. Auf der linken Seite sieht man die Bezeichnungen der einzelnen
Schichten und auf der rechten repräsentativ die zugehörigen Standards und
Werkzeuge. Dabei baut die obere Schicht auf die Fähigkeiten der unteren
Ebene auf.
Eine grundlegende Eigenschaft von Webservices ist die Kommunikation
über ein Netzwerk. Die Basis der Kommunikation im Internet bilden etablierte Protokolle wie HTTP oder TCP/IP.
Auf XML basierende SOAP-Nachrichten können somit über ein Netz-
weitere Layer (Service Flow)
63
WSFL
.
Service Publikation/Suche
UDDI
Service Beschreibung
WSDL
XML−basierte Nachrichten
SOAP, SOAP RPC
Neztwerk
HTTP, SMTP
Abbildung 4.2: Schichtenmodell des UDDI (Interop Stack) [Kre01, udd00b]
werk übertragen werden. SOAP bietet einen einfachen Mechanismus zur
Kommunikation zwischen Webservice-Teilnehmer, indem bei Aufrufen von
entfernten Funktionen deren Parameter und Ergebnisse übertragen werden.
Die nächsthöhere Schicht beschäftigt sich mit der Beschreibung der Kommunikation in einem strukturierten Format. Dazu werden die Schnittstellen
und Kommunikationsaspekte mittels der weit verbreiteten Web Service Description Language (WSDL) beschrieben. Eine WSDL-Beschreibung definiert
also die Rahmenbedingungen für den Aufruf eines Webservice.
Die soeben beschriebenen Schichten sind auf jedem Fall für das Betreiben
oder Nutzen von Webservices notwendig. Unterschiede gibt es hauptsächlich
in den verwendeten Protokollen und Standard. Zum Beispiel lassen sich im
Intranet auch andere Infrastrukturen wie CORBA nutzen.
Damit Webservices von Klienten genutzt werden können, müssen ihnen
die WSDL-Dokumente zugänglich gemacht werden. Das kann zum Beispiel
durch das Zuschicken per E-Mail oder einem einfachen WSDL-Verzeichnis
geschehen. Alternativ kann die Bindung an Webservices entweder zum Entwicklungszeitpunkt oder zur Laufzeit über eine UDDI vollzogen werden.
Simple Object Access Protokoll (SOAP)
Neben SOAP existieren auch RPC-Protokolle wie XML-RPC, WDDX oder
ebXML, aber letztendlich wurde SOAP von den vier möglichen Kandidaten zum Internetstandard. SOAP bietet einen einfachen Mechanismus zum
Austausch von strukturierten und getypten Informationen zwischen dezentralisierten und verteilten Umgebungen mittels XML. Das Protokoll definiert einen Mechanismus, wie anwendungsspezifische Daten kodiert werden.
Dabei bleibt es vollständig unabhängig von Plattform, Objektmodell und
Implementationssprache.
SOAP-RPC ist aber nur ein Teil des SOAP-Standards [W3C00b]; tat-
64
sächlich setzt sich der Standard aus drei Teilen zusammen, die jeweils funktional abgegrenzte Aspekte der Kommunikation beschreiben. Die Rahmenbedindungen eines Nachrichtenaustauschs per SOAP werden durch SOAPEnvelope festgelegt. Damit wird die grundsätzliche Behandlung und Verarbeitung von SOAP-Nachrichten festgelegt – also beantwortet dieser Teil die
Fragen, woraus eine Nachricht aufgebaut ist, wer die Nachricht wie verarbeitet und welche Abschnitte der Nachricht optional sind. Damit anwendungsspezifische Daten zwischen Applikationen ausgetauscht werden können, definiert der Abschnitt SOAP-Encoding-Rules einen Mechanismus zum Serialisieren von Datentypen. Der letzte Teil SOAP RPC umfasst Konventionen
zur Realisierung von RPC-Aufrufen und Antworten. Auf den Inhalt dieser
drei Teile wird im Folgenden kurz eingegangen.
Grundsätzlich werden SOAP-Nachrichten nur in einer Richtung übertragen, von einem Sender zu einem Empfänger. Häufig werden SOAP-Nachrichten zu einem Anfrage-/Antwortverfahren oder einem ähnlichen Mustern
kombiniert. SOAP-Nachrichten werden immer in XML kodiert, wobei die
zum Verstehen einer Nachricht notwendigen Metadaten im SOAP-Envelope
zusammengefasst werden. Diese äußere Hülle bildet das Wurzelelement und
beinhaltet den optionalen Header und den obligatorischen Body (vgl. Abbildung 4.3). Der Header ist ein generischer Mechanismus zum Hinzufügen von
zusätzlicher Funktionalität, wohingegen der Body den Behälter für die Informationen an den finalen Adressaten darstellt. Alle Bestandteile in einem
SOAP-Envelope sind im Namensraum http://schemas.xmlsoap.org/soap/envelope/ definiert. Eine Bindung des SOAP-Envelope-Elements an einen anderen Namensraum wird als Fehler behandelt.
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
>
<SOAP-ENV:Header>

</SOAP-ENV:Header>
<SOAP-ENV:Body>

</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Abbildung 4.3: Bestandteile einer SOAP-Nachricht
Im Vergleich zu XML-Dokumenten sind in einer SOAP-Nachricht die Angabe von Dokumenttypdeklarationen (document type declaration) und Verarbeitungsanweisungen (processing instruction) verboten (vgl. [W3C00a]).
Da zum Serialisieren der Daten in SOAP-Nachrichten keine DefaultRegeln definiert sind, wird diese Information in einem globalen Attribut en-
65
codingStyle referenziert. Der Wert dieses Attributs ist eine Liste geordneter2
URIs, die die Regeln zum Deserialisieren einer SOAP-Nachricht identifizieren. In einer Nachricht darf jedes Element ein solches Attribut beinhalten,
wobei die Reichweite dieses Attributs den Inhalt des Elements und aller seiner Kinder, die keinen encodingStyle definieren, umfasst. Somit lassen sich
bestimmte Abschnitte unterschiedlich kodieren, z. B. der Header anders als
der Body.
Der optionale Header bietet einen flexiblen Mechanismus zur Erweiterung einer Nachricht um bestimmte Funktionalität, ohne dass die Kommunikationspartner davon vorher Kenntnis haben müssen. Beispiele für derartige
dezentralisierte und modulare Erweiterungen für Nachrichten sind Authentifizierung, Transaktionsmanagement oder Bezahlungsmodi. Ein Beispiel für
die Übertragung einer Transaktionsnummer zeigt Abbildung 4.4.
<SOAP-ENV:Header>
<t:Transaction xmlns:t="some-URI" SOAP-ENV:mustUnderstand="1">
...
</t:Transaction>
</SOAP-ENV:Header>
Abbildung 4.4: Header einer SOAP-Nachricht
Der Header bietet zwei Attribute zur Steuerung der Bearbeitung einer
SOAP-Nachricht: actor und mustUnderstand. Der Empfänger eines speziellen Headerabschnitts kann durch das Attribut actor bestimmt werden. Dieser Abschnitt wird von dem Empfänger herausgelöst und anschließend die
Nachricht verarbeitet bzw. weitergeleitet. Dieses Attribut ist sinnvoll, da
eine Nachricht auch über mehrere Zwischenstationen zu dem endgültigen
Adressaten geführt werden kann.
Damit Headerabschnitte von einem Empfänger nicht aufgrund mangelnder Implementierung ignoriert und dadurch Fehler verursacht werden, wurde der Header um ein mustUnderstand-Attribut ergänzt. Ist dieses Attribute
auf den Wert 1“ gesetzt, so muss entweder der markierte Headerabschnitt
”
verarbeitet oder ein Fehler generiert werden. Da hierdurch das unbemerkte Ignorieren von Headerabschnitten verhindert wird, erlaubt SOAP eine
Entwicklung robuster Systeme.
Der Body-Abschnitt (vgl. Abbildung 4.5) ist obligatorisch und dient der
Übermittlung von Daten zu dem endgültigen Adressaten. Bei der Nutzung
von SOAP RPC dient dieser Abschnitt zur Übertragung von RPC-Aufrufen
oder Fehlermeldungen.
Der Abschnitt SOAP-Encoding-Rules definiert eine Möglichkeit zum Serialisieren von Datentypen, die im Allgemeinen in Programmiersprachen und
2
Reihenfolge: spezifisch → weniger spezifisch
66
<SOAP-ENV:Body>
<ns1:getPois xmlns:ns1="urn:poiservice">
<X xsi:type="xsd:double">8.65</X>
<Y xsi:type="xsd:double">49.87</Y>
...
</ns1:getPois>
</SOAP-ENV:Body>
Abbildung 4.5: Body einer SOAP-Nachricht
Datenbanken vorhanden sind. Dabei ist ein Typ entweder skalar (scalar) oder
zusammengesetzt aus anderen Typen (compound). Die Elemente und Attribute für SOAP-Encoding sind im Namensraum http://schemas.xmlsoap.org/
soap/encoding/ definiert. Die in SOAP verwendete Kodierung basiert auf
den Spezifikationen XML Schema Part 1: Structures [W3C01b] und XML
Schema Part 2: Datatypes [W3C01c], die um weitere Regeln erweitert wurden. Die Spezifikation ist derart umfangreich, dass eine Beschreibung der
Regeln in diesem Rahmen nicht möglich ist; dazu kann man in [W3C00b]
weiteres nachlesen.
Remote Procedure Call (RPC) ist ein Kommunikationsprotokoll zum
Aufrufen von Methoden über ein Netzwerk. Das Ziel von SOAP RPC ist
die Definition eines RPC-Protokolls unter Ausnutzung der Flexibilität und
Erweiterbarkeit von XML. Obwohl SOAP RPC nicht auf die Übertragung
über HTTP beschränkt ist, aber diese Art der Übertragung in der prototypischen Realisierung eines Webservice genutzt wurde, befassen sich die
folgenden Ausführungen insbesondere damit. Die Einfachheit und die Omnipräsenz von HTTP erlaubt den Austausch von strukturierten und getypten Information in einer dezentralisierten und verteilten Umgebung. Bei der
Verwendung von HTTP lassen sich RPC-Aufrufe auf HTTP-Anforderungen
bzw. RPC-Antworten auf HTTP-Antworten einfach abbilden.
SOAP benutzt HTTP POST zum Senden der Informationen. Der HTTPHeader wird um ein zusätzliches Feld SOAPAction erweitert, um eine Absicht in eine HTTP-Anforderung zu integrieren. Wie in Abbildung 4.6 verdeutlicht, enthält dieses Feld eine URI, die von Servern und Firewalls zum
Filtern der HTTP-Anforderungen verwendet werden kann.
Die Einbeziehung der Absicht einer SOAP-Nachricht ist gerade deswegen
sinnvoll, weil die Nachrichten ansonsten von einer Firewall nicht überprüft
werden könnten. Aus der Verwendung von HTTP leitet sich aber auch ein
Vorteil von SOAP-Nachrichten ab: Das Senden und Empfangen von SOAPNachrichten und damit das Nutzen von Webservices ist auch bei Verwendung einer Firewall möglich. Wenn nun eine SOAP-Nachricht in ein HTTP
POST integriert wird, so muss dabei der Typ des Inhalts (content type) auf
text/xml“ gesetzt sein.
”
67
POST /soap/servlet/rpcrouter HTTP/1.0
Host: localhost
Content-Type: text/xml; charset=utf-8
Content-Length: 605
SOAPAction: ""
<?xml version=’1.0’ encoding=’UTF-8’?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" ...>
<SOAP-ENV:Body>
<ns1:getPois xmlns:ns1="urn:poiservice" ...>
...
</ns1:getPois>
</SOAP-ENV:Body>
Abbildung 4.6: SOAP HTTP-Anforderung
Wie Abbildung 4.7 vermuten lässt, erfolgt die Rückmeldung auf eine
HTTP-Anforderung mittels der bei HTTP üblichen Statusinformationen.
Sollte bei der Bearbeitung der SOAP-Nachricht ein Fehler aufgetreten sein,
so wird dies durch den Fehlercode 500 ( internal server error“) signali”
siert. Im Beispiel bescheinigt der Statuscode 200, dass die Anfrage inklusive
SOAP-Nachricht empfangen, verstanden und akzeptiert wurde.
HTTP/1.0 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: 1800
<?xml version=’1.0’ encoding=’UTF-8’?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" ...>
<SOAP-ENV:Body>
<ns1:getPoisResponse xmlns:ns1="urn:poiservice" ...>
...
</ns1:getPoisResponse>
</SOAP-ENV:Body>
Abbildung 4.7: SOAP HTTP-Antwort
Zur Durchführung eines RPC-Aufrufs sind verschiedene Informationen
notwendig, die im Body einer SOAP-Nachricht transportiert werden. Der
Aufruf selbst wird als eine einzelne Struktur (einem zusammengesetzten
Datentyp) mit dem Namen der zu rufenden Methode modelliert. Innerhalb
der Struktur gibt es zu jedem Parameter der Methode ein gleichnamiges
68
Element, wobei die Signatur der Methode den Ausschlag für die Reihenfolge der Parameter gibt. Die Antwort auf eine Anfrage wird in ähnlicher
Weise als Struktur kodiert. Hierbei ist der Name der Struktur irrelevant,
es wird jedoch im Standard empfohlen an den Methodennamen Response
anzuhängen. Zusatzinformationen, die im Allgemeinen nicht direkt an die
gerufene Methode übergeben werden (z. B. Transaktionsnummern), können
als Subelement im SOAP-Header übertragen werden.
Web Service Description Language (WSDL)
Mittels der Web Service Description Language (WSDL) spezifiziert der Anbieter das grundsätzliche Format für die an den veröffentlichten Webservice
gerichteten Anfragen (z.B. Ein- und Ausgabeparameter). Dabei können unterschiedliche Kommunikationsprotokolle und Kodierungen verwendet werden. Auf Grundlage einer XML-Grammatik beschreibt WSDL, welche Leistungen ein Webservice erbringt, wo er zu finden ist und wie er genutzt
werden kann. [Vas00, Sho01] Obwohl bei WSDL neben SOAP auch HTTP
und MIME als Übertragungsprotokoll spezifiziert werden können, gibt dieser
Abschnitt nur einen Überblick über die SOAP-Bindung.
Eine Webservice-Beschreibung ist das Schlüsselelement zur Konstruktion
von lose gekoppelten Webservice-Architekturen, da hierdurch der Umfang
des gemeinsam notwendigen Wissens zwischen Anbieter und Nutzer für die
Nutzung eines Webservice reduziert wird. Die Kombination von WebserviceBeschreibung und SOAP-Kommunikation kapselt zum Beispiel das Wissen
um die zugrunde liegende Plattform oder die verwendete Programmiersprache. [Kre01]
Ein Webservice wird als eine Sammlung von Kommunikationsendpunkten, den so genannten Ports, in einem WSDL-Dokument definiert. Ein solches Dokument lässt sich dabei in zwei Abschnitte unterteilen. Am Anfang befindet sich die Schnittstelle, gefolgt von der Implementation. Der
Schnittstellenabschnitt beschreibt die SOAP-Nachrichten in einer plattformund programmiersprachenunabhängigen Weise. Dies unterstützt die Definition von Webservices, die von unterschiedlichen Service-Anbietern implementiert werden können. Zum Vergleich lassen sich die Interface Definition Language (IDL) oder die Java Interfaces heranziehen. Im zweiten Teil
des WSDL-Dokuments, dem Implementationsabschnitt, befinden sich anbieterspezifische Details wie das Serialisieren von Datentypen (vgl. S. 64).
[W3C01a, Tap01]
Im Allgemeinen werden die oben genannten Teile in unterschiedlichen
Dateien verwaltet. Die Trennung von Interface und Implementation unterstützt den Gedanken, dass eine Schnittstelle eines Unternehmens durch
unterschiedliche Anbieter implementiert werden kann. Damit wird Kompatibilität zwischen unterschiedlichen Anbietern gewährleistet. Folglich muss
der Designer einer Schnittstelle nicht unbedingt auch eine Implementierung
69
anbieten.
Die Schnittstellendefinition besteht aus Informationen zu den verwendeten maschinen- und sprachenunabhängigen Datentypen (types-Element),
den Ein- und Ausgabeparametern der Operationen (message-Elemente) und
der Signatur der Operation unter Einbeziehung der vorher definierten Parameter (portType-Element).
Die für die vorher definierten Operationen vorgesehenen Kommunikationsprotokolle (z. B. SOAP RPC über HTTP) werden in einem bindingElement spezifiziert. Dabei sind für eine Operation auch verschiedene Übertragungsprotokolle möglich. Der Implementationsteil der Service-Beschreibung enthält für jede implementierte Bindung (unterstütztes Protokoll) eine
URL, unter der der Service aufrufbar ist.
Die Abbildungen 4.8 und 4.9 zeigen Teile der WSDL-Definition des in der
Diplomarbeit realisierten Webservice getPois() und illustrieren die Verwendung von WSDL zur Definition eines Webservice. Zur besseren Darstellung
wurden dabei die Namespace-Attribute und andere weniger wichtige Elemente weggelassen.
Die Schnittstelle wird in Abbildung 4.8 präsentiert. Da es sich bei dem
Rückgabewert, einem Array von POIs, um einen komplexen Datentyp handelt, wird dieser explizit innerhalb des types-Element definiert. Die daran
anschließenden message-Elemente beinhalten die Parameterlisten für den
Aufruf des Webservice bzw. den Datentyp für den Rückgabewert. Diese Elemente werden in der anschließenden Portdefinition referenziert. Zuletzt wird
in diesem Beispiel eine Bindung für SOAP RPC über HTTP definiert.
Eine WSDL-Darstellung der Implementation von der obigen Schnittstelle veranschaulicht Abbildung 4.9. Durch den Import (import) wird die
Schnittstellendefinition eingebunden. Der Import ist nicht nur auf das Einbinden von Schnittstellendefinition beschränkt, sondern kann zum Beispiel
auch zum Gliedern der Schnittstellendefinition selbst verwendet werden. Für
eine in der Schnittstellendefinition festgelegte SOAP-Bindung wird der Zugangspunkt, eine URL, in einem port-Element angegeben.
Universal Description, Discovery and Integration (UDDI)
Die Universal Description, Discovery and Integration (UDDI) Spezifikation
standardisiert das Publizieren und Finden von Informationen über Webservices. Damit dient die UDDI vor allem der Lösung der Frage, welche Businesspartner welche Services anbieten. Im April 2001 waren es 176 Unternehmen, von anfänglich 36, die vertraglich die Unterstützung der zukünftigen Entwicklung der UDDI-Spezifikation erklärt haben [Ste01b]. Damit ist
die UDDI nicht nur eine Insellösung eines einzelnen Unternehmens, sondern ermöglicht eine unternehmensübergreifende Erfassung und Verwendung von Webservices. Verantwortlich für die Weiterentwicklung der UDDISpezifikation sind die Unternehmen Ariba Inc., IBM und Microsoft Corpo-
70
<?xml version="1.0" encoding="UTF-8"?>
<definitions name="PoiService"
targetNamespace="http://www.dbis.com/poiservice-interface" ... >
<types>
<xsd:schema targetNamespace="http://..." ... >
<xsd:complexType name="ShapePoint"> ... </xsd:complexType> ...
</xsd:schema>
</types>
<message name="IngetPoisRequest">
<part name="x" type="xsd:double"/> ...
</message>
<message name="OutgetPoisResponse">
<part name="pois" type="types:ArrayOfPoi"/>
</message>
<portType name="PoiService">
<operation name="getPois">
<input message="tns:IngetPoisRequest"/>
<output message="tns:OutgetPoisResponse"/>
</operation>
</portType>
<binding name="PoiServiceBinding" type="tns:PoiService">
<soap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="getPois"> ... </operation>
</binding>
</definitions>
Abbildung 4.8: Schnittstellenabschnitt des POI-Service (Ausschnitt)
targetNamespace="http://www.dbis.com/poiservice" ...>
<import location="http://.../PoiService-interface.wsdl"
namespace="http://www.dbis.com/poiservice-interface">
</import>
<service name="PoiService">
<documentation> ... </documentation>
<port binding="interface:PoiServiceBinding"
name="PoiServicePort">
<soap:address location="http://..."/>
</port>
</service>
</definitions>
Abbildung 4.9: Implementationsabschnitt des POI-Service (Ausschnitt)
71
ration. In diesem Abschnitt werden die Strukturen vorgestellt, aus denen
sich ein UDDI-Verzeichnis zusammensetzt.
Das Prinzip der UDDI bietet drei Aspekte, die bei den bisherigen Ansätzen nicht realisiert sind. Zum Ersten liefert die UDDI den Unternehmen
einen standardisierten, transparenten Mechanismus zur Beschreibung ihrer
Dienstleistungen und Geschäftsprozesse auf Basis einer global offenen Architektur. Als Zweites ist die einfache dynamische Entdeckung und Einbeziehung von Webservices zu nennen. Nicht zuletzt bildet die UDDI einen
zentralen Zugangspunkt zu Webservices. [Ste01b] [udd00a]
Konzeptionell besteht die UDDI aus drei Komponenten: den white, yellow und green pages. White pages beinhalten die Kontaktinformationen zu
Unternehmen wie zum Beispiel Adressen. Yellow pages enthalten Kategorisierungen basierend auf standardisierte Taxonomien und schließlich bieten
green pages technische Informationen über die veröffentlichten Webservices,
z. B. die URL zum Zugriff auf einen Webservice.
Abbildung 4.2 auf Seite 63 zeigt die UDDI als eine weitere Schicht
bei der Realisierung vielseitig nutzbarer Webservices. Aufbauend auf dem
WSDL-Standard definiert die UDDI-Spezifikation ein einfaches Framework
zur Beschreibung von beliebigen Webservices. Im Detail besteht die Spezifikation aus einer XML-Schemadefinition für SOAP-Nachrichten und einer
UDDI Schnittstellenbeschreibung. Das UDDI XML-Schema differenziert dabei vier unterschiedliche Typen von Informationen: Geschäfts-, Service- und
Verbindungsinformationen sowie Informationen über die Spezifikationen des
Webservice.
Die hierarchischen Zusammenhänge zwischen den unterschiedlichen Informationstypen sind in Abbildung 4.10 skizziert, wobei der einzelne Typ
durch den dazugehörenden XML-Elementnamen identifiziert werden kann.
<businessEntity>
<businessService>
<tModel>
<bindingTemplate>
Abbildung 4.10: Schlüssel-Datenstrukturen der UDDI [udd00b]
Die äußere Hülle businessEntity beinhaltet die Geschäftsinformationen (white pages), wozu der Firmennamen, die Kontaktadresse, eine Beschreibung sowie die Kategorisierung des Unternehmens gehören. Diese Daten dienen dem Auffinden eines bestimmten Serviceanbieters, falls bereits
Teilinformationen, z. B. der Firmenname, bekannt sind. Hier wird auch die
72
Suche über die Taxonomien der yellow pages unterstützt und erlaubt somit
dem Suchende die Einschränkung des Suchraumes aufgrund von bestimmten
Eigenschaften, z. B. geografischer Bereich oder Industriezweig.
Die technischen und geschäftlichen Informationen über die Webservices,
den Daten in den green pages, werden in Unterstrukturen von dem Element businessEntity zusammengefasst. Dabei werden zusammengehörende Webservices in businessService-Elementen gruppiert. Webservices können zusammengehörig sein, wenn sie in demselben Geschäftsprozess vorkommen oder in dieselbe Kategorie sortiert werden können.
Die zur Kommunikation zwischen Applikationen und Webservices notwendigen technischen Details werden durch bindingTemplate-Elemente zur
Verfügung gestellt. Dazu zählt vor allem die Adresse eines Webservice, um
überhaupt eine Verbindung aufbauen zu können.
Nicht immer ist die Adresse zum Verbindungsaufbau ausreichend, um
einen Webservice aufrufen zu können. Gibt es zum Beispiel einen Webservice, der Fahrkarten reserviert, so werden auch Informationen zum Ablauf des Vorganges, zu Sicherheitsaspekten oder Form der Rückmeldung
benötigt. Damit eine Verträglichkeit (Kompatibilität) mit dem Webservice
vorher abgeklärt werden kann, referenziert jedes bindingTemplate-Element
Informationen über die Spezifikation des Webservice. Eine solche Referenz
ist der Schlüssel zu Metadaten, bestehend aus dem Namen der veröffentlichenden Organisation und einer URL zu der eigentlichen Spezifikation des
Webservice. Diese Metadaten werden als tModel bezeichnet. Der Leitgedanke
des tModels ist, dass verschiedene Unternehmen Webservices veröffentlichen
können, die zu derselben Spezifikation kompatibel sind (dasselbe tModel).
Aufgrund dieser Eindeutigkeitseigenschaft wird die Referenz zu einem tModel auch mit einem Fingerabdruck (fingerprint) verglichen.
Nicht zuletzt sind auch die Methoden zum Zugriff auf eine UDDI standardisiert. Dabei werden die Anfrage- und die Veröffentlichungsschnittstelle
(Inquiry API and Publishers’ API) unterschieden. Die erstere dient dem
Suchen und Durchblättern von Information aus der UDDI, wohingegen die
andere Schnittstelle das Speichern und Löschen von Informationen entsprechend der oben genannten vier Typen ermöglicht.
Verknüpfung von UDDI und WSDL
Nachdem nun sowohl UDDI als auch WSDL kurz beschrieben worden sind,
wird in diesem Abschnitt die Verknüpfung von WSDL-Dokumenten und einem UDDI-Verzeichnis hergestellt. Das Verständnis für diese Zusammenhänge ist wichtig, damit zum Beispiel entsprechend einer Schnittstelle ein Service implementiert oder ein Service mit einer bestimmten Schnittstelle gefunden werden kann.
Die Zusammenhänge werden in Abbildung 4.11 visualisiert. Auf der linken Seite sieht man schematisch die Struktur eines WSDL-Dokuments und
73
auf der rechten die Informationen in einem UDDI-Verzeichnis.
Service Implementation
<import>
<service>
UDDI
BusinessEntity
BusinessService
<port>
BindingTemplate
<port>
BindingTemplate
Service Schnittstelle
<types>
<message>
<portType>
<binding>
tModel
.
Abbildung 4.11: Verknüpfung von WSDL und UDDI [BCEG01]
Die technische Spezifikation in einem tModel basiert auf dem Schnittstellenteil eines WSDL-Dokuments. Aus den in den vorherigen Abschnitten
dargelegten Informationen ergibt sich, dass auf demselben tModel aufgesetzte Webservices, dieselben Ein- und Ausgabeparameter, dieselbe Kodierung
der Datentypen und bestimmte Übertragungsprotokolle verwenden. Dies garantiert die Austauschbarkeit von Webservices.
Unternehmen, die eine Schnittstelle eines Webservice implementieren,
publizieren in der UDDI neben den Informationen zum Unternehmen den
Implementationsabschnitt des WSDL-Dokuments. Wie bereits weiter oben
beschrieben, kann aus diesem der Schnittstellenteil referenziert werden. Die
von einem Unternehmen verfügbaren Webservices werden mittels BusinessService-Einträgen in der UDDI registriert; jeder Eintrag entspricht demnach
einer Implementation einer Schnittstelle. Die unterstützen Kommunikationsprotokolle sind in der UDDI in bindingTemplates abgelegt. Diese basieren
auf den Port-Definitionen in einem WSDL-Dokument.
4.1.3
Vor- und Nachteile von Webservices
Bisher wurden hauptsächlich die Aspekte der Realisierung von Webservices
und der Aufbau einer Webservice-Architektur betrachtet. Dieser Abschnitt
wägt nun die Anwendbarkeit von Webservices ab, indem wesentliche Vorund Nachteile zusammengefasst werden.
Webservices bieten neue Möglichkeiten beim Aufbau von verteilten Systemen. Die Verwendung bisheriger Architekturen (z. B. CORBA) resultiert
oft in eng gekoppelten Systemen, die im Allgemeinen nur mit erhöhtem
Aufwand in einem heterogenen Umfeld arbeiten. Obwohl diese Protokolle in
einem wohldefinierten Umfeld (z. B. Kommunikation zwischen zwei Servern)
74
Vorteile bieten, ist gerade die Kommunikation zwischen Klient und Server
über das Internet problematisch, da insbesondere dort die Heterogenität am
größten ist.
Durch Entkoppelung der Systeme ermöglichen Webservices Interoperabilität unabhängig von Plattform oder Programmiersprache. Jeder Webservice
kapselt einen gewissen Umfang an Funktionalität, die allein durch Kenntnis der Schnittstelle zugreifbar wird. Das heißt, der Umfang des gemeinsamen Wissens zwischen Service und Klient wird eingeschränkt auf die Beschreibung des Webservice (z. B. WSDL) und dem Verfahren zum Nachrichtenaustausch. Die Kapselung der Funktionalität gestattet einen Austausch
der Implementation zu jedem beliebigen Zeitpunkt, ohne Eingriffe in den
Klienten-Systemen vornehmen zu müssen.
Die angestrebte Wiederverwendung von Softwarekomponenten mittels
Webservices lässt sich auch auf Altsysteme ausdehnen. Da die eigentliche
Realisierung eines Webservice an Bedeutung verliert, lassen sich vorhandene
Altsysteme weiter nutzen, indem entsprechende SOAP-Wrapper erstellt und
anschließend als Webservices beschrieben und veröffentlicht werden.
Webservice-Verzeichnisse ermöglichen das Auffinden von Webservice-Beschreibungen dynamisch zur Laufzeit, wodurch sich selbstkonfigurierende
und robuste Systeme geschaffen werden können. Robust werden die Systeme zum einen durch die Vorgehensweise (Wiederholen bei Fehler) des Klients
beim Aufruf eines Webservice (vgl. Abschnitt 4.2.3) und zum anderen kann
ein nicht gefundener Webservice durch einen anderen, der dieselbe Schnittstelle implementiert, ersetzt werden.
Die Nutzung weit verbreiteter Übertragungsprotokolle ermöglicht jedem
einen einfachen Zugang zu Webservices von überall, insofern SOAP-Nachrichten gesendet und empfangen werden können. Betrachtet man insbesondere die Realisierung von SOAP über HTTP, so ist der Zugriff auf Dienstleistungen über das Internet auch bei dem Vorhandensein einer Firewall
möglich. [IBM00c]
Die Kommunikationsgrundlage für Webservices bildet SOAP und damit
auch XML, wodurch die Nachrichten einfach zu handhaben und universell einsetzbar sind. Im Vergleich zu binär serialisierten Daten sind SOAPNachrichten etwa zehn mal umfangreicher, wobei die Datenmenge ohne
Änderung des Protokolls nicht reduziert werden kann. In [GSC+ 00] werden
verschiedene RMI3 -Mechanismen miteinander vergleichen. Es wurde festgestellt, dass eine Datenübertragung mittels SOAP zum Beispiel um Faktor
zehn gegenüber Java RMI langsamer ist. Gerade das (De-)Serialisieren von
bzw. nach XML nimmt im Vergleich zum Senden signifikant mehr Zeit in
Anspruch.
Ein ähnliches Ergebnis bei einem Performanzvergleich zwischen SOAP
und CORBA lieferte [Ada01]; die textuelle Darstellung der zu übertragenen
3
Remote Method Invocation
4.2. REALISIERUNG EINES WEBSERVICE
75
Daten reduziert den Datendurchsatz erheblich.
Trotz der Schwächen bei der Performanz, lässt sich zusammenfassend
feststellen, dass eine Vereinfachung der Kommunikation innerhalb des (stark
heterogenen) Internets ein wesentlicher Vorteil von SOAP darstellt, den andere Mechanismen bisher nicht bieten können.
4.2
Realisierung eines Webservice
In den vorangegangenen Kapiteln und Abschnitten wurden die Grundlagen
für die prototypische Implementierung eines Webservice zum Zugriff auf
standortbezogene Informationen gelegt.
In Kapitel 2 wurde die Erstellung einer GIS-Datenbank auf Basis von
Tele Atlas Daten beschrieben. Darin sind nicht nur kartografische Informationen zum Verkehrsnetz enthalten, sondern es werden auch Daten über
Gebäude und Einrichtungen von besonderer Bedeutung (POIs) bereitgestellt. Kapitel 3 beschreibt, wie ein Datenbankmanagementsystem performant auf die räumlichen Daten in einer GIS-Datenbank zugreifen und damit
eine kurze Antwortzeit auf Anfragen an die Datenbasis gewährleisten kann.
Weitere für die Realisierung eines Webservice wichtige Konzepte wurden in
den vorherigen Abschnitten vorgestellt und die grundsätzlichen Bestandteile
und Operationen einer Webservice-Architektur beschrieben.
Auf der Basis von kartografischen Daten aus einer GIS-Datenbank wurde
ein Webservice implementiert, der zu einem gegebenen Standort umliegende Points of Interest ermittelt und zugehörige Informationen zurückgibt.
Die Anfrage ist dabei nicht auf bestimmte Gebäude oder Dienstleistungen
beschränkt. Weiterhin ist die Größe der zu berücksichtigenden Umgebung
um den gewählten Standort variabel. Zusätzlich wurde ein Klient für den
Webservice verwirklicht, der mittels einer UDDI den Webservice lokalisiert,
um ihn anschließend aufzurufen.
Der folgende Abschnitt gibt zunächst einen Überblick über das Gesamtsystem sowie die verwendete Software, bevor detailliert auf die einzelnen
Aspekte der Realisierung eingegangen wird. Dazu gehört das Aufsetzen einer UDDI, die Implementierung des Webservice und eines Klienten sowie
besondere Aspekte der Kommunikation.
4.2.1
Die verwendete Webservice-Architektur
Für einzelne Aspekte der Entwicklung einer Webservice-Architektur können
vorhandene Softwarelösungen genutzt werden. Dieser Abschnitt vermittelt,
welche Teile der entwickelten Webservice-Architektur von Werkzeugen unterstützt und welche implementiert wurden.
In einer Webservice-Architektur sind drei verschiedene Rollen (ServiceVerzeichnis, -anbieter und -klient) zu realisieren. Die Abbildung 4.12 präsentiert nochmals das Modell aus Abbildung 4.1 auf Seite 61, wobei diesmal der
76
Schwerpunkt auf den Softwarekomponenten liegt. Dabei wurde bei der Darstellung zwischen bereits vorhandenen und noch zu realisierende Software
unterschieden. Durch Überlappung wurden die Abhängigkeiten der Komponenten visualisiert, die überlappte Komponente ist ein Teil oder bildet die
Grundlage der darüber liegenden.
Wasp UDDI
Service
Verzeichnis
DB2−Anpassung
Finden
Publizieren
WSTK
Service
Klient
Administration
Wasp UDDI
Client API
Binden
Apache Soap
(De−)Serialisierung
komplexer Datentypen
Service
Anbieter
WSDL WSTK
implementierte Teile
vorhandene Werkzeuge
Abbildung 4.12: Überblick über die Systemumgebung
Zentrales Element ist das UDDI-Verzeichnis, das die Informationen zu
allen publizierten Webservices bereithält. Die Basisoperationen einer UDDI
sind das Veröffentlichen einer Webservice-Beschreibung (Publizieren) und
das Finden eines Webservice nach verschiedenen Kriterien. Das Publizieren
eines Webservice wird durch einen Anbieter durchgeführt. Dieser ist auch für
das Bereitstellen der Dienstleistung verantwortlich. Die letzte Komponente
ist ein Klient, der über die UDDI eine bestimmte Funktionalität in Form
eines Webservice finden kann. Anschließend können die Informationen zum
Aufruf des Webservice genutzt werden.
Da der Aufwand für die Realisierung einer UDDI den Rahmen dieser Diplomarbeit überschreiten würde, wurde auf die existierende Software WASP
UDDI 3.0 von der Firma Systinet zurückgegriffen. Zusammen mit dieser
Software wird ein Klient-Paket zum Zugriff auf die UDDI ausgeliefert, das
in einem Werkzeug zur Administration (Publizieren/Löschen) des Webservice verwendet wurde. Das Paket kapselt die Konstruktion und das Parsen
der SOAP-Nachrichten für den Zugriff auf die UDDI.
Eine weitere Werkzeugsammlung zum Umgang mit Webservices bildet
das Web Service Tool Kit (WSTK) von IBM. Es unterstützt den Entwickler
teilweise bei der Beschreibung des Webservice mittels WSDL-Dokumenten.
Insofern komplexe (zusammengesetzte) Datentypen verwendet werden, be-
77
darf es erheblicher Nachbearbeitung der erzeugten Dokumente. Zusätzlich
beinhaltet das Paket komfortable Schnittstellen zum Ausführen von Operationen auf der UDDI; dies beinhaltet auch ein einfaches Publizieren von
Webservices auf Grundlage der WSDL-Beschreibung. Für das Publizieren
konnte jedoch mit dem WSTK keine Verbindung zur WASP UDDI (mit angemessenem Aufwand für die Fehlersuche) hergestellt werden, weshalb das
es an diesem Punkt nicht eingesetzt werden konnte und diese Funktionalität
separat implementiert wurde.
Die Kommunikation zwischen Klient und Webservice basiert auf dem
Austausch von SOAP-Nachrichten. Dazu müssen die gesendeten und empfangenen Daten serialisiert bzw. deserialisiert werden. Hierfür wurde die
Softwarelösung Apache Soap in der Version 2.2 verwendet. Dieses Paket
kapselt auf der einen Seite den Aufruf des Webservice und auf der anderen Seite die Rückgabe des Resultats. Das beinhaltet die Konstruktion und
Auswertung der SOAP-Nachrichten sowie das (De-)Serialisieren einfacher
Datentypen. Da in der Diplomarbeit komplexe Datentypen verwendet werden, wurden für das (De-)Serialisieren entsprechende Operationen in Apache
Soap integriert.
Zusätzlich zum obigen Modell schlüsselt das Use-Case-Diagramm in Abbildung 4.13 die Subsysteme Webservice und Klient weiter auf. Dargestellt
werden die implementierten Operationen der einzelnen Rollen sowie die Auslagerung von Funktionalität des Webservice in das Datenbankmanagementsystem.
Abbildung 4.13: Subsysteme Webservice
Auf der Seite des Webservice-Klienten hat der Nutzer die Möglichkeit, in
78
dem UDDI-Verzeichnis nach einem Service zu suchen und anschließend einen
gefundenen Webservice aufzurufen. Die Anfrage wird von dem Webservice
bearbeitet, indem die Daten von der GIS-Datenbank abgefragt und schließlich dem Nutzer zurückgesendet werden. Bevor ein Webservice verwendet
werden kann, muss dieser zunächst von einem Anbieter publiziert werden.
4.2.2
Implementierung des Webservice
Ein Subsystem in einer Webservice-Architektur ist der Anbieter von Dienstleistungen. In der Diplomarbeit wird ein Webservice verwirklicht, der zu
einem gegebenen Standort umliegende bedeutsame Einrichtungen liefert,
wobei die Informationen über die POIs aus einer GIS-Datenbank bezogen werden. Dazu sind verschiedene Aspekte des Subsystems zu betrachten. Zunächst wird eine Schnittstelle für den Klienten entworfen, das heißt
konkret, es wird eine WSDL-Schnittstelle definiert. Anschließend wird der
Zugriff auf die kartografischen Daten modelliert, wozu zum einen die Ausführung von SQL-Anweisungen und zum anderen das Serialisieren des Ergebnisses gehört.
In diesem Abschnitt wird zunächst die entworfene Schnittstelle beschrieben, um anschließend den Zugriff auf die Daten vorzustellen. Das Serialisieren der Daten wird im Kontext der Kommunikation zwischen Anbieter und
Klient in einem separaten Abschnitt dokumentiert.
Schnittstelle
Die Schnittstellendefinition liefert einem Klienten grundlegende Informationen über den Zugriff auf einen Webservice. Neben der Definition der Ein- und
Ausgabeparameter werden außerdem spezifische Datentypen vereinbart und
auch die nutzbaren Übertragungsprotokolle festgelegt. Nicht zuletzt müssen
auch die Namen der Operationen bestimmt werden. Die Schnittstelle wird
in Form eines WSDL-Dokuments dem Klienten zur Verfügung gestellt. Im
Folgenden werden die genannten Aspekte der Schnittstelle betrachtet.
Grundlegende Eingabeparameter für die Bestimmung in der Umgebung
befindlicher POIs sind eine eindeutige Beschreibung des Standortes sowie ein
Maß für die zu berücksichtigende Umgebung. Der Standort könnte zum Beispiel durch eine vollständige Adresse oder einer koordinatenbasierte Positionsangabe gegeben sein. Da sich aus einer Adressenangabe mittels Geokodierung die geografische Position ermitteln lässt, kann davon abstrahiert und
Koordinaten als Eingabe gewählt werden. Weil viele unterschiedliche Koordinatensysteme zur Bestimmung eines Punktes auf der Welt existieren,
benötigt man im Allgemeinen zusätzliche Angaben, die eine Umrechnung in
das Koordinatensystem der GIS-Datenbank erlauben. Dieser Gedanke wurde nicht weiter verfolgt, weil dies bei der Konstruktion eines Webservice nur
eine untergeordnete Rolle spielt und die Berechnungen datenbankseitig au-
79
tomatisierbar sind. Daher wird im Folgenden davon ausgegangen, dass alle
Koordinatenangaben bezüglich des von Tele Atlas verwendeten Koordinatensystems WGS84 gemacht werden. Zusammengefasst sind die Basisparameter ein durch seine Koordinaten gegebener Punkt und eine Entfernungsangabe bezüglich WGS84.
Weiterhin wurden zusätzliche Parameter implementiert, die zum einen
eine Auswahl der gewünschten Feature-Klasse (z. B. nur Tankstellen) und
zum anderen die Anzahl der zurückgegebenen Tupel limitiert. Beide zuletzt
genannte Parameter erlauben eine zum Teil drastische Reduktion des Umfangs der zu übertragenden Antwortnachricht.
Die Antwortnachricht besteht aus einer Liste von POIs. Ein POI wird
dabei durch einen spezifischen Datentyp dargestellt, der neben einem eindeutigen Identifikator und den Koordinaten auch Informationen zum POI selbst
enthält (z. B. Name und Art des POI). Im Sinne von XML-Schema resultiert
dies in einem komplexen Datentyp, der separat in der WSDL-Schnittstelle
definiert werden muss.
Des Weiteren werden in der Schnittstelle die unterstützten Kommunikationsprotokolle festgelegt. Der realisierte Webservice arbeitet auf Basis des
weit verbreiteten und gut unterstützten SOAP RPC Protokolls über HTTP.
Die vollständige WSDL-Definition der Schnittstelle befindet sich in Anhang B.1.1.
Implementierung der Schnittstelle
Die Definition der Schnittstelle ist nur der erste Schritt bei der Realisierung
eines Webservice. Der Kern eines Webservice steckt in den Implementierungen einer Schnittstelle; wie bereits im Abschnitt über WSDL erwähnt, kann
es mehrere Implementierungen geben. An dieser Stelle wird die Modellierung einer möglichen Realisierung beschrieben. Die Aufgabe des Webservice
ist die Umsetzung der Eingabeparameter in SQL-Anweisungen und das anschließende Zusammenstellen der Ergebnismenge. Aus Abbildung 4.13 auf
Seite 77 ist ersichtlich, dass der Webservice auf eine GIS-Datenbank zugreift.
Zur Entkoppelung von SQL-Anweisungen und Anwendung wurden Teile der
Logik in gespeicherte Datenbankprozeduren ausgelagert.
Abbildung 4.14 bietet einen Überblick über die Klassen, die an der Realisierung des Webservice beteiligt sind. Die eingangs erwähnten Teilaufgaben
lassen sich im Klassendiagramm wiederfinden. Die Schnittstelle wird von der
Klasse PoiService zur Verfügung gestellt; die Klasse leitet auch die Datenbankabfragen ein. Die Ergebnisse der Datenbankabfrage wird von der Klasse
ResultSetCollector zur Weiterverarbeitung gesammelt. Die gefundenen Datensätze werden zum Schluss in Poi-Objekten abgelegt und an den Klienten
zurückgegeben.
Beginnend bei den gespeicherten Datenbankprozeduren werden im Folgenden die einzelnen Klassen erläutert und deren Zusammenwirken darge-
80
legt.
Abbildung 4.14: Modellierung des Webservice
Da die kartografischen Daten auf mehrere Schemata verteilt werden,
müssen zunächst die Schemata ermittelt werden, die von dem Umkreis um
den gegebenen Standort geschnitten werden. Anschließend können gezielt die
Tabellen einzelner Schemata abgefragt werden. Die Suche nach den geschnittenen Gebieten übernimmt die gespeicherte Prozedur sp intersected Areas()
und liefert eine Ergebnismenge bestehend aus Schemanamen. Das Ergebnis
wird zusammen mit den Eingabeparametern in Aufrufe der gespeicherten
Prozedur sp get Pois() umgesetzt. Somit erhält man eine Ergebnismenge
mit denjenigen POIs, die den gegebenen Eingabeparametern genügen.
Bisher noch nicht dokumentiert wurden die Vorgänge, die nach dem Aufruf des Webservice zum Herstellen einer Datenbankverbindung und zum
Ausführen der gespeicherten Prozeduren führen. Zum Herstellen einer Datenbankverbindung wird auf das Paket database des Importwerkzeugs (vgl.
Abschnitt 2.3.3) zurückgegriffen. Dadurch wird nicht nur vorhandener Co-
81
de wiederverwendet, sondern es gestattet auch eine einfache Adaption des
Webservice an verschiedene DBMS.
Es wurde festgestellt, dass zunächst die Schemanamen der betroffenen
Gebiete ermittelt werden müssen. Diese Aufgabe wird von einer Methode
der Basisklasse QueryDispatcher übernommen, die ihrerseits die gespeicherte
Prozedur sp intersected Areas() aufruft. Je nach Aufteilung der kartografischen Daten werden mehrere Schemata ermittelt. Damit die Schemata nicht
sequenziell abgearbeitet werden müssen, wurde der Webservice so modelliert, dass mehrere Anfragen (quasi) parallel abgesetzt und verarbeitet werden können. Die Grundlage für dieses Design bildet die Klasse DbQuestioner
als Ableitung von Thread. Mittels der Klasse QueryDispatcher kann für jede Anfrage bezüglich eines Schemas ein eigener Thread erzeugt werden. Die
Ergebnisse werden zentral durch die Klasse ResultSetCollector gesammelt
und zur Weiterverarbeitung bereitgehalten.
Sobald Ergebnisse vorliegen, werden diese durch Methoden von PoiService zu einer Liste von Poi-Objekten zusammengestellt. Nachdem alle Anfragen abgearbeitet wurden, wird diese Liste an den Klienten weitergegeben.
4.2.3
Klient des Webservice
Ein weiterer Bestandteil einer Webservice-Architektur ist ein Klient, der mit
Hilfe der UDDI konkrete Webservices findet und diese dann aufruft oder in
seinen Arbeitsprozess einbindet. Ein Klient kann dabei sowohl interaktiv
als auch autonom agieren. Der folgende Abschnitt beschreibt die typische
Vorgehensweise zur Einbeziehung von Webservices, wie sie in [udd00b] empfohlen wird. Abschließend werden noch einige Bemerkungen zum realisierten
Webservice-Klienten gemacht.
Die unten beschriebene Vorgehensweise hat zum Ziel, die Anzahl der
Anfragen an eine UDDI zu reduzieren, damit die UDDI-Knoten zu entlasten. Das grundlegende Prinzip hierbei ist das lokale Vorhalten der Verbindungsbeschreibung (bindingTemplate), so dass nicht für jeden Aufruf des
Webservice die UDDI kontaktiert werden muss.
Der Programmierer informiert sich im Allgemeinen zur Entwicklungszeit
mit Hilfe der UDDI über die Anbieter der gewünschten Dienstleistung und
speichert die zum gewählten Webservice gehörenden Verbindungsinformationen. Auf Grundlage dieser Informationen kann die Schnittstellendefinition
bezogen und ein entsprechender Klient programmiert werden. Zur Laufzeit
wird auf Basis der gespeicherten Informationen der Webservice beim Anbieter aufgerufen.
Tritt ein Fehler beim Aufruf des Webservice auf, so werden als erstes die
Verbindungsinformationen überprüft, indem diese von dem UDDI-Verzeichnis erneut heruntergeladen werden. Unterscheiden sich die neuen Informationen von den bisherigen, so wird der lokale Cache korrigiert und ein neuer
Aufruf des Webservice mit den neuen Daten ausgeführt. Lassen sich die neu-
82
en Verbindungsinformationen nicht zugreifen oder schlägt der zweite Aufruf
ebenfalls fehl, so ist der Aufruf des Webservices erfolglos.
Das soeben beschriebene Verfahren wird als Wiederholung bei Fehler (retry on failure) bezeichnet. Vorteilhaft an dem Prinzip ist, dass der Anbieter
bei Veränderungen der Verbindungsinformationen nur den UDDI-Eintrag zu
korrigieren braucht. Zugleich erspart das lokale Caching zusätzliche Verbindungsherstellungen zur UDDI.
Im Rahmen der Diplomarbeit wurde ein einfacher Klient verwirklicht,
der einen Webservice lokalisieren und aufrufen kann. Die Eingaben des Klienten leiten sich aus der Schnittstelle des Webservice ab, das heißt konkret,
es werden dem Programm zumindest ein Standort in Form eines Koordinatenpaares sowie der Radius der zu berücksichtigen Umgebung übergeben; zusätzlich sind Angaben zur Feature-Klasse oder eine Begrenzung der
zurückgegebenen Einträge möglich. Als Ergebnis werden die vom Webservice
gelieferten Daten textuell dargestellt.
4.2.4
Auswahl der UDDI
Die UDDI ermöglicht einem Klienten unter einer Auswahl publizierter Implementierungen die gezielte Suche nach Webservices. Auf der anderen Seite
erlaubt sie einem Anbieter die Bereitstellung von Dienstleistungen, so dass
diese auf einfache Weise weltweit gefunden und eingebunden werden können.
Daraus ergibt sich eine zentrale Stellung in einer Webservice-Architektur.
Steven Graham unterscheidet in [Gra01] sechs unterschiedliche Formen
von UDDI-Verzeichnissen, wobei diese grob in öffentliche und private unterteilt werden können. Der wichtigste UDDI-Knoten ist der Zusammenschluss
globaler UDDI unterschiedlicher Unternehmen (UDDI operator cloud). Wird
bei einem dieser UDDI-Verzeichnisse ein Webservice publiziert, so wird der
Eintrag innerhalb einer festgelegten Frist auf allen zur Gruppe gehörenden
UDDI repliziert. Die privaten Formen der UDDI sind aufgrund ihres Anwendungsgebietes gegliedert (z. B. Partnerkatalog UDDI oder unternehmensinterne UDDI). In der Diplomarbeit wurde eine private UDDI zum Testen des
Webservice-Klienten und -anbieters aufgesetzt (Test Bed UDDI).
Da zum einen die Implementation einer UDDI im Rahmen der Diplomarbeit zu aufwändig ist und zum anderen bereits qualitativ gute Realisierungen existieren, wurde auf eine vorhandene Softwarelösung zurückgegriffen. In diesem Abschnitt werden die Kriterien für die Auswahl der UDDIImplementation dargelegt.
Aufgrund der Festlegung der Datenstrukturen und Schnittstellen in den
Spezifikationen [udd01b] bzw. [udd01a] unterscheiden sich die Implementationen nur im Umfang der Realisierung der Spezifikationen, in der verwendeten Software sowie in der Qualität der Realisierung. Genau diese Eigenschaften bildeten die Entscheidungsgrundlage für die Auswahl einer UDDI.
Ein wichtiges Kriterium war eine (nahezu) vollständige Implementierung
83
der UDDI-Spezifikationen, damit sämtliche Aspekte der Realisierung und
Verwendung eines Webservice betrachtet werden können.
Im Allgemeinen werden die Informationen innerhalb einer UDDI in einer Datenbank abgelegt. Da für die Verwaltung der GIS-Datenbank das Datenbankmanagementsystem DB2 UDB verwendet wird, wurde die Auswahl
auf diejenigen UDDI-Implementationen beschränkt, die bereits das genannte DBMS unterstützten oder durch geringfügige Änderungen eine Adaption
erlaubten.
Letztendlich wurde WASP UDDI 3.0 von der Firma Systinet ausgewählt,
die auf Tomcat 3.2 von der Apache Software Foundation als Web Application
Server aufsetzt. Diese Lösung unterstützt DB2 UDB zwar nicht unmittelbar, ließ sich aber mit wenig Aufwand anpassen. Die Änderungen umfassen
die Implementation einer Klasse zum Verbindungsaufbau zur Datenbank,
sowie die Anpassung der DDL-Kommandos zum Erzeugen der notwendigen
Datenbanktabellen.
Alternativ dazu bietet sich die WebSphere UDDI Registry von IBM an,
die standardmäßig für DB2 UDB konfiguriert ist. Ein Grund für die getroffene Wahl ist, dass die UDDI von IBM auf das kommerzielle Produkt
WebSphere 4.0 aufsetzt und damit nicht frei zugänglich ist. Weiterhin wird
das Produkt nur für Windows-Plattformen angeboten.
Kapitel 5
Zusammenfassung und
Auswertung
In dieser Diplomarbeit wurde prototypisch ein Webservice realisiert, der
standortbezogene Informationen aus einer GIS-Datenbank ausliest. Dazu
wurden zunächst die kartografischen Daten, die in den Datenformaten GDF
bzw. MultiNet Shapefile vom Hersteller Tele Atlas vorlagen, in eine Datenbank importiert. Anschließend wurde untersucht wie ein performanter
Zugriff auf die räumlichen Daten realisiert werden kann. Da die an die Datenbasis gestellten Anfragen auf die Selektion bezüglich eines durch Koordinaten gegebenen Standortes beruhen, war die Konfiguration des mehrdimensionalen Zugriffsverfahrens von besonderem Interesse. Auf Basis der
so verfügbaren GIS-Datenbank wurde zuletzt ein Webservice realisiert, der
zu einem gegebenen Standort Informationen über nahe gelegene Einrichtungen (Points of Interest) zurückliefert. Nach der Zusammenfassung und
Auswertung der in den einzelnen Kapitel gesammelten Erkenntnisse wird
auf mögliche weiterführende Themengebiete eingegangen.
Wie gerade beschrieben, musste vor der Realisierung des Webservice
zunächst eine Datenbasis mit kartografischen Information (GIS-Datenbank)
aufgebaut werden. Das GDF-Dateiformat wurde bereits in [Hee01] vorgestellt. Es wurde dort festgestellt, dass zum Import der Daten in eine Datenbank eine Vorverarbeitung notwendig ist, die die kartografischen Daten in
Layer aufgliedert und die Koordinaten der räumliche Objekte für den Importvorgang kodiert. Da der Fokus der Diplomarbeit auf einem möglichst datenbankunabhängigen Importwerkzeug lag, wurde eine Remodellierung des
Werkzeugs zur Vorverarbeitung vorgenommen. Weil die DBMS die räumlichen Datentypen unterschiedlich repräsentieren und sich die Importverfahren grundlegend unterscheiden, wurde die Modularisierung des Werkzeugs
zur Vorverarbeitung verbessert. Das Ergebnis war ein Werkzeug, dass sich
mit geringem Aufwand an verschiedene DBMS anpassen lässt.
Zum Anfang der Diplomarbeit stellte Tele Atlas ein neues Datenfor84
85
mat zur Verfügung, das die kartografischen Informationen bereits in Layer
gruppierte. Dieses MultiNet Shapefile-Format beruht auf der ESRI Shapefile
Spezifikation und gestattet einen einfachen Zugriff sowohl auf die Geometrien als auch auf deren Eigenschaften. Während beim GDF-Dateiformat die
Koordinaten fehleranfällig durch mehrfaches Dereferenzieren von Identifikatoren zusammengestellt werden mussten, können diese bei einem Shapefile
direkt zugegriffen werden. Da das Shapefile-Format einfach zu verarbeiten
ist und das verwendete DBMS respektive der DB2 Spatial Extender das
Shapefile-Format bereits unterstützt, wurde für die weitere Arbeit dieses
Datenformat zugrunde gelegt.
Dazu wurde zunächst ein einfach zu bedienendes Werkzeug entwickelt,
das die Daten in die Datenbank überträgt. Das entstandene Werkzeug kann
zudem mit wenigen Änderungen für andere DBMS konfiguriert werden. Im
Shapefile-Format gespeicherte Daten sind auf drei Dateien aufgeteilt, wobei eine Datei die Attribute des räumlichen Objekts speichert und die zwei
anderen den Zugriff auf die Koordinaten realisieren. Da die Datei mit den
Attributen im dBASE-Format vorliegt, wurde dieses Format von Tele Atlas auch dazu verwendet, Datensätze ohne zugehörige räumliche Objekte
zu kodieren. Die Schwierigkeit bestand darin, dass DB2 UDB das dBASEFormat nicht unterstützt. Daher wurde zusätzlich zu dem Importwerkzeug
eine gespeicherte Prozedur realisiert, die das Einlesen von dBASE-Dateien
übernimmt.
Nach dem die Daten als GIS-Datenbank zur Verfügung standen, musste ein performanter Zugriff auf die räumlichen Daten gewährleistet werden. Räumliche Daten können nicht ohne zusätzliche Algorithmen mit den
üblichen Methoden einer Datenbank indiziert werden, da entsprechend der
Dimensionalität zwei bzw. drei gleichberechtigte Schlüssel vorliegen. Daher
setzt man schon seit geraumer Zeit mehrdimensionale Zugriffsverfahren ein,
die eine gleichberechtigte Suche nach mehreren Schlüsseln gestatten. Der
DB2 Spatial Extender, als räumliche Erweiterung von DB2 UDB, implementiert neben den räumlichen Datentypen und Funktionen auch ein mehrdimensionales Zugriffsverfahren.
Damit ein performanter Zugriff auf die räumlichen Daten erfolgen kann,
muss zunächst das mehrdimensionale Zugriffsverfahren geeignet konfiguriert
werden. Dazu wurden zuerst allgemeine Eigenschaften und Anforderungen
von mehrdimensionalen Zugriffsverfahren zusammengestellt, um anschließend das Zugriffsverfahren des DB2 Spatial Extender zu analysieren. Das
Ziel der Analyse war die Entwicklung von Regeln und Heuristiken, die eine performante Konfiguration garantieren. In diesem Zusammenhang hat es
sich gezeigt, dass die Konfiguration zur Verwaltung von Punktdaten mit
einfachen Regeln zu beschreiben war, während bei räumlich ausgedehnten Geometrien nur Heuristiken aufgestellt werden konnten. Die durch die
Anwendung der Heuristiken entstandene Konfiguration muss anschließend
durch Vergleichstests überprüft und gegebenenfalls variiert werden. Im An-
86
KAPITEL 5. ZUSAMMENFASSUNG UND AUSWERTUNG
schluss daran wurden die aufgestellten Theorien experimentell überprüft,
wobei diese bestätigt wurden. Aus den Experimenten ergaben sich zusätzliche Einflussfaktoren, die jedoch im Rahmen der Diplomarbeit nicht weiter
untersucht wurden.
Mit der Realisierung eines performanten Zugriffs auf die Datenbasis
konnte prototypisch ein Webservice implementiert werden, der zu einem
gegebenen Standort alle in einem Umkreis befindlichen POIs zurückliefert.
Zum Verständnis der Mechanismen einer Webservice-Architektur erfolgte eine Einarbeitung in die verwendeten Standards, die dann zusammenfassend
in der Diplomarbeit dargestellt wurden. Anschließend wurden die Komponenten Klient und Anbieter der Webservice-Architektur modelliert und implementiert. Zusätzlich wurde ein Webservice-Verzeichnis (UDDI) mit einbezogen, wobei auf existierende Software zurückgegriffen wurde. Die Verwendung einer UDDI impliziert die Funktionen Publikation und Suche eines
Webservice, die auf Klienten- und Anbieterseite integriert wurden.
Aufgrund des begrenzten Zeitrahmen war es nicht möglich, andere notwendige Aspekte der Modellierung einer GIS-Datenbank abzuhandeln. In
der Diplomarbeit wurde vor allem der grundlegende Schritt des Imports der
kartografischen Daten in eine Datenbank realisiert sowie die Konfigurationsmöglichkeiten des DB2 Spatial Extenders untersucht.
Eine umfassende Modellierung einer GIS-Datenbank beinhaltet unter anderem auch die physische Speicherung der Daten auf dem Sekundärspeicher.
Dazu gehört zum Beispiel die Partitionierung von Tabellen und das Verteilen
der Datenbankobjekte auf verschiedene Festplatten und Rechner. Obwohl
die Verteilung der Datenbankobjekte zunächst auf Grundlage des Datenbankschemas entschieden wird, müssen später auch DBMS-spezifische Konzepte, beispielsweise unterschiedliche Partitionierungsmechanismen, berücksichtigt werden.
Hat man sich nicht schon von vorn herein auf ein konkretes DBMS festgelegt, so ist neben den kommerziellen Aspekten auch eine Untersuchung auf
die Eignung des DBMS für das vorgesehene Einsatzgebiet sinnvoll. Gerade
bei der Verarbeitung räumlicher Daten bildeten sich unterschiedliche Konzepte zur Verwaltung der Daten heraus, da es bisher keinen einheitlichen
Standard zur Behandlung räumlicher Daten gibt. Weniger kritisch ist dabei
der Einsatz von unterschiedlichen mehrdimensionalen Zugriffsverfahren, solange diese den in der Diplomarbeit vorgestellten Anforderungen genügen.
Konkrete Probleme treten vor allem bei der unzureichenden Standardisierung geeigneter Datenaustauschformate auf. Zwar ist das Shapefile-Format
sehr weit verbreitet und bildet damit einen Quasi-Standard, dennoch ist
der Import dieses Formates nicht überall vorgesehen (z. B. Oracle). Daraus ergeben sich zwangsläufig zum Teil aufwendige Vorverarbeitungsschritte, die abgesehen von dem zu investierenden Aufwand die Fehleranfälligkeit
erhöhen. Weiterhin unterscheiden sich die DBMS bei dem Umfang der räum-
87
lichen Funktionen, obwohl grundlegende Operationen wie der Schnitt oder
die Vereinigung von Geometrien bei allen DBMS zur Verfügung stehen.
Im Zusammenhang mit mehrdimensionalen Zugriffsverfahren wurde in
der Diplomarbeit nur das des DB2 Spatial Extender untersucht. Ein Vergleich zu anderen Zugriffsverfahren, insbesondere zu denen anderer DBMS,
würde eine bessere Beurteilung der einzelnen Verfahren erlauben. Beispielsweise wird bei Oracle sowohl der R-Tree als auch der Quad-Tree implementiert.
Aus der Sicht der Beantwortung von Anfragen lassen sich ebenfalls verschiedene Aspekte aufgreifen und vertiefen. Die GIS-Datenbank könnte um
Funktionalität erweitert werden, die eine umfassende Kategorisierung und
Hierarchisierung der kartografischen Daten vornimmt. Damit könnte zum
einen eine Priorisierung der Datenübertragung aufgrund von Wichtigkeit
oder Bedeutung eines räumlichen Objekts und zum anderen eine Auswahl
der Datensätze in Abhängigkeit des verwendeten Kartenmaßstabs erfolgen.
Es ist zum Beispiel für eine Überblickskarte von Deutschland nicht sinnvoll,
kleine Städte und Gemeinden sowie Nebenstraßen darzustellen.
Zusammenfassend wurden grundlegende Konzepte zum Aufbau eines
Webservice, der auf eine GIS-Datenbank zugreift, in einer prototypischen
Implementierung veranschaulicht. Insbesondere wurden wichtige Standards
im Zusammenhang dargestellt und angewendet. Im Bereich der GIS-Datenbank wurden Heuristiken und Regeln für das mehrdimensionale Zugriffsverfahren des DB2 Spatial Extender erstellt, die über die Anmerkungen in der
Dokumentation von IBM [IBM00a] hinausgehen.
Anhang A
Modellierung des
Importwerkzeugs
Das Importwerkzeug dient zum Laden des MultiNet Shapefile-Formats in
eine Datenbank und wird im Abschnitt 2.3.3 beschrieben. Dieser Anhang
bietet zusätzliche Informationen zu der Modellierung des Werkzeugs. In den
ersten Abschnitten werden die Konfigurationsdateien dokumentiert.
A.1
Konfigurationsdateien
Dieser Abschnitt geht auf die vom Importwerkzeug verwendeten Konfigurationsdateien ein, die grundsätzlich auf XML basieren. Dabei werden datenbankunabhängige und -spezifische Dateien unterschieden. Während die erste
generelle Einstellungen speichert, kann die letzte für die spezielle Konfiguration eines konkreten DBMS bzw. dessen Spatial Extender genutzt werden. Auf Erklärungen zum Lesen der Diagramme folgt zunächst der Aufbau der allgemeinen Konfiguration für datenbankunabhängige Einstellungen. Der anschließende Abschnitt beschreibt die Struktur der speziell auf
DB2 UDB und DB2 Spatial Extender zugeschnittenen Konfigurationsdatei.
A.1.1
Visualisierung einer XML-Dokumentstruktur
Jedes Rechteck in dem Modell repräsentiert ein XML-Element mit seinem
Namen und zugehörigen Attributen. Die Pfeile geben die Kindbeziehung
wieder, wobei die Kardinalitäten angetragen sind (vgl. Tabelle A.1).
A.1.2
Allgemeine Konfiguration
Die allgemeine Konfiguration umfasst alle datenbankunabhängigen Parameter für Datenbank und Spatial Extender sowie die Definition von SQLProzessen. Abbildung A.1 zeigt die Struktur der XML-Datei sowie die Namen der Klassen, über die auf den jeweiligen Teil zugegriffen werden kann.
88
A.1. KONFIGURATIONSDATEIEN
Zeichen
1
?
∗
+
89
Anzahl Elemente
genau ein (required)
Null oder eins
Null oder mehr
eins oder mehr
Tabelle A.1: Kardinalitäten im XML-Modell
Der Name der Konfigurationsdatei kann beim Start des Importwerkzeugs
optional als Parameter angegeben werden.
Abbildung A.1: Aufbau der allgemeinen Konfigurationsdatei
Die Kinder des Dokumentelements config unterteilen die Konfiguration
in die Abschnitte database mit der Datenbankkonfiguration, spatial mit
Einstellungen zum Spatial Extender der Datenbank und sqlProcesses mit
den Definitionen der SQL-Prozesse. Die Verwaltungsklassen der einzelnen
Parts sind in den Kommentaren angegeben.
Die Datenbankkonfiguration umfasst sämtliche Informationen, die zum
Verbindungsaufbau zur Datenbank notwendig sind. Das Attribut dbdriver
enthält den Namen Klasse, die eine Datenbankverbindung liefert. Diese Klas-
90
ANHANG A. MODELLIERUNG DES IMPORTWERKZEUGS
se muss eine Ableitung von DbConnection sein. Das Element dbFileLoader
spezifiziert in dem Attribut name diejenige Klasse (eine Ableitung von dbFileLoader), die den Import der Shape- und dBASE-Dateien übernimmt.
Zuletzt ist hier auch die Anzahl der Updates angegeben, nachdem ein Commit ausgeführt wird.
Der in spatial wurzelnde Bereich beschreibt die allgemeine Konfigurationen des Spatial Extenders der Datenbank. Momentan wird hier nur der
Name der Spalte (spatialColumn) mit den Geometrien festgelegt.
Die Definition von beliebig vielen SQL-Prozessen erfolgt innerhalb des
Elements sqlProcesses. Jedem SQL-Prozess (sqlProcess) können ein oder
mehr SQL-Dateien (sqlFile) zugeordnet werden, die bei Ausführung nacheinander abgearbeitet werden. Dabei kann für jede Datei die Substitution
von Zeichenketten (mapping) spezifiziert werden, um zum Beispiel den aktuellen Schemanamen in SQL-Anweisungen einzufügen oder ein Kommando
datenbankspezifisch abzuwandeln. Das Mapping wird in den Attributen von
mapping angegeben, wobei im Attribut token die zu ersetzende Zeichenkette
steht. Der neue Text kann entweder direkt im Attribut value oder indirekt in
valueRef gesetzt werden. Dabei bedeutet letzteres, dass in einer systeminternen und zur Laufzeit erstellten Tabelle die Substitution mit dem Schlüssel
valueRef abgelegt wird. Dies ermöglicht eine dynamische Substitution bestimmter Werte zur Laufzeit, z. B. der Datenbankname oder Datenbanknutzer.
A.1.3
Datenbankspezifische Konfiguration
Die datenbankspezifische Konfiguration erlaubt es dem Programmierer, Parameter für konkrete Datenbankmanagementsysteme zentral zuzugreifen.
Dies umfasst zum Beispiel Datenbankeinstellungen oder zusätzliche Angaben für den Spatial Extender. Der Name der Konfigurationsdatei kann mittels einer Option beim Start des Werkzeugs angegeben werden. Anhand
der DB2-Konfigurationsdatei soll die Anwendung der Konfigurationsdatei
verdeutlicht werden. Anschließend folgen Erklärungen zu den räumlichen
Bezugssystemen, die vom DB2 Spatial Extender verwendet werden.
Die Struktur der Konfigurationsdatei für DB2 wird in Abbildung A.2
gezeigt. Das Dokumentelement config besitzt die Kindelemente databaseParameter und spatialReference. Das zuerst genannte Element beschreibt
notwendige Einstellungen, damit der DB2 Spatial Extender ohne Fehler auf
DB2 UDB läuft. Das andere Kindelement speichert die Informationen zur
Speicherung der Koordinaten in der Datenbank. Die Attribute der Elemente
werden im Folgenden erläutert.
Der erste Abschnitt der datenbankspezifischen Konfiguration definiert
die notwendigen Datenbankeinstellungen, damit das Zusammenwirken von
DB2 UDB und DB2 Spatial Extender reibungslos abläuft. Innerhalb DB2
werden global auf das gesamte DBMS (dbm) und lokal bezüglich einer Da-
A.1. KONFIGURATIONSDATEIEN
91
Abbildung A.2: Aufbau der Konfigurationsdatei für DB2 UDB
tenbank (db) wirkende Systemvariablen unterschieden (vgl. Abbildung A.2).
Beide Arten von Variablen können in der Konfigurationsdatei gesetzt werden. Bedarf es der Installation des DB2 Spatial Extenders in einer Datenbank1 , so werden die Einstellungen aus der XML-Datei ausgelesen und für
die Datenbank gesetzt. Dabei gibt name den Parameternamen und value
den einzutragenden Wert an.
Alle Koordinaten der zu verwaltenden Geometrien werden datenbankintern als positive ganzzahlige Werte gespeichert, weshalb es im Allgemeinen
einer Transformation der zu verwaltenden Geometrien bedarf. Die Attribute und die Kindelemente von spatialReference beschreiben gerade diese
Transformation. Mit den Attributen srID und srName wird ein räumliches
Bezugssystem (spatial reference) identifiziert. Mit dem Attribut scID wird
das Koordinatensystem referenziert, das dem räumlichen Bezugssystem zugrunde liegt, z. B. WGS84. Dies ermöglicht später Umrechnungen zwischen
verschiedenen Koordinatensystemen.
1
Es ist nicht die Installation im Betriebssystem gemeint.
92
ANHANG A. MODELLIERUNG DES IMPORTWERKZEUGS
Die eigentlichen Transformationsregeln zum Berechnen der Datenbankrepräsentation von Koordinaten werden in den Elementen shift und scale
definiert. Der erste von der Datenbank durchgeführte Schritt ist die Beseitigung des negativen Vorzeichens durch Translation um die in falsex, falsey
und falsez gesetzten Werten entlang der jeweiligen Achsen. Dabei werden
die dort definierten Werte von der jeweiligen Koordinate subtrahiert. Im
zweiten Schritt erfolgt eine Skalierung mit den Multiplikatoren xyunits bzw.
zunits, so dass keine Nachkommastellen mehr auftreten. Bei Zugreifen auf
die Daten wird die Transformation wieder umgekehrt.
Ein konkretes Beispiel veranschaulicht diese Transformation. Ein Koordinatenpaar (x, y) = (−6.01, 48.1) wird durch Translation um falsex = −7
in x-Richtung und Skalierung mit xyunits = 100 der xy-Koordinaten in die
Datenbankrepräsentation (xDB , yDB ) = (99, 4810) transformiert.
Die Attribute falsem bzw. munits bestimmen die Transformation von
Koordinaten, die zusätzlich ein Maß beinhalten. Weiterführende Erklärungen gibt es in der Dokumentation des DB2 Spatial Extender [IBM00a].
Anhang B
Realisierung des Webservice
B.1
WSDL-Beschreibung
In diesem Abschnitt ist das vollständige WSDL-Dokument des in der Diplomarbeit realisierten Webservice. Der Webservice liefert zu einem gegebenen Punkt alle POIs in einem parametrisierbaren Umkreis. Zur Erklärung
der einzelnen Abschnitte der WSDL-Dokumente wird auf Abschnitt 4.1.2
Seite 68 sowie den Spezifikation [W3C01a] verwiesen.
B.1.1
Schnittstellendefinition
Nachfolgend findet sich die Schnittstellendefinition für den PoiService.
targetNamespace="http://www.dbis.com/poiservice-interface"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://www.dbis.com/poiservice-interface"
xmlns:types="http://www.dbis.com/poiservice-interface/types/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<documentation>
Definition komplexer Datentypen fuer PoiService.
</documentation>
<types>
<xsd:schema
targetNamespace="http://www.dbis.com/poiservice-interface/types/"
xmlns="http://www.w3.org/2001/XMLSchema/">
<annotation>
<documentation>
Definition komplexer Datentypen fuer PoiService.
</documentation>
</annotation>
<xsd:complexType name="ShapePoint">
<xsd:sequence minOccurs="1" maxOccurs="1" >
93
94
ANHANG B. REALISIERUNG DES WEBSERVICE
<xsd:element name="x" type="xsd:double"
minOccurs="1" maxOccurs="1" />
<xsd:element name="y" type="xsd:double"
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="Poi">
<xsd:sequence>
<xsd:element name="id" type="xsd:long"
<xsd:element name="name" type="xsd:string"
<xsd:element name="featureType" type="xsd:int"
<xsd:element name="geometry" type="types:ShapePoint"
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ArrayOfPoi">
<xsd:sequence>
<xsd:element name="item" type="types:Poi"
minOccurs="1" maxOccurs="unbounded" />
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
</types>
<message name="IngetPoisRequest">
<part name="x" type="xsd:double"/>
<part name="y" type="xsd:double"/>
<part name="buffer" type="xsd:double"/>
<part name="featureType" type="xsd:int"/>
<part name="limit" type="xsd:int"/>
</message>
<message name="OutgetPoisResponse">
<part name="pois" type="types:ArrayOfPoi"/>
</message>
<portType name="PoiService">
<input message="tns:IngetPoisRequest"/>
<output message="tns:OutgetPoisResponse"/>
</operation>
</portType>
<binding name="PoiServiceBinding" type="tns:PoiService">
<soap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
<soap:operation soapAction="urn:poiservice"/>
<input>
B.1. WSDL-BESCHREIBUNG
95
<soap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn:poiservice" use="encoded"/>
</input>
<output>
<soap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn:poiservice" use="encoded"/>
</output>
</operation>
</binding>
</definitions>
B.1.2
Implementationsabschnitt
Das hier gezeigte WSDL-Dokument beschreibt eine Implementation der obigen Schnittstelle.
targetNamespace="http://www.dbis.com/poiservice"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:interface="http://www.dbis.com/poiservice-interface"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<import location="http://localhost:8080/wsdl/wsdl/PoiService-interface.wsdl"
namespace="http://www.dbis.com/poiservice-interface">
</import>
<service name="PoiService">
<documentation>Service zum Bestimmen umliegender POIs</documentation>
<port binding="interface:PoiServiceBinding"
name="PoiServicePort">
<soap:address location="http://localhost:8080/soap/servlet/rpcrouter"/>
</port>
</service>
</definitions>
Literaturverzeichnis
[Ada01]
Colin J. Adam. Whitepaper: XML as a basis for remote procedure
calls. Webservices.org, 2001. http://www.webservices.org.
[Bag01]
Jo Bager. Das Handy kennt den Weg. c’t 22/01, S 168, Verlag
Heinz Heise GmbH & Co KG, 2001.
[BCEG01] Peter Brittenham, Francisco Curbera, David Ehnebuske, and Steve Graham.
Understanding WSDL in
a UDDI Registry.
IBM, August 2001.
http://www106.ibm.com/developerworks/webservices/library/ws-wsdl/.
[BKSS94] Thomas Brinkhoff, Hans-Peter Kriegel, Ralf Schneider, and
Bernhard Seeger. Multi-step processing of spatial joins. In Proceedings of the 1994 ACM SIGMOD International Conference
on Management of Data, Minneapolis, Minnesota, May 24-27,
1994, pages 197–208. ACM Press, 1994.
[BRJ99a]
Grady Booch, James Rumbaugh, and Ivar Jacobsen. The Unified
Modeling Language Reference Manual. Addison Wesley Longman, Inc., 1999.
[BRJ99b] Grady Booch, James Rumbaugh, and Ivar Jacobsen. The Unified
Modeling Language User Guide. Addison Wesley Longman, Inc.,
1999.
[Col01]
Mark Colan. Dynamic e-business: Using Web services to transform business - White Paper. IBM, June 2001. http://www3.ibm.com/software/ebusiness/docs/Dynamic.pdf.
[ESR98]
ESRI. ESRI Shapefile Technical Description - White Paper, July
1998. http://www.esri.com/software/opengis/openpdf.html.
[Fla97]
Miroslaw A. Flasza. Implementation von Geo-Funktionalität in
einem erweiterbaren relationalen DBMS. Institut für Informatik,
Humbold-Universität zu Berlin, August 1997.
[GDF95]
European Committee for Standardisation. Geographic Data Files, first draft edition, October 1995.
96
LITERATURVERZEICHNIS
[GG98]
97
Volker Gaede and Oliver Günther. Multidimensional access methods. ACM Computing Surveys, 30(2):170–231, 1998.
[GHJV96] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Entwurfsmuster; Elemente wiederverwendbarer objektorientierter Software. Addison-Wesley (Deutschland) GmbH, 1996.
1. Auflage.
[Gla00]
Graham Glass. The Web services (r)evolution. IBM, November 2000. http://www-4.ibm.com/software/developer/library/wspeer1.html.
[Gra01]
Steve Graham. The role of private UDDI nodes in Web services, Part 1: Six species of UDDI. IBM, May 2001. http://www106.ibm.com/developerworks/library/ws-rpu1.html.
[GSC+ 00] Madhusudhan Govindaraju, Aleksander Slominski, Venkatesh Choppella, Randall Bramley, and Dennis Gannon.
Requirements for and Evaluation of RMI Protocols for Scientific Computing.
Department of Computer Science Indiana University Bloomington, IN, 2000.
http://www.sc2000.org/techpapr/papers/pap.pap261.pdf.
[Gut84]
Antonin Guttman. R-trees: A dynamic index structure for spatial searching. In SIGMOD’84, Proceedings of Annual Meeting,
Boston, Massachusetts, June 18-21, 1984, pages 47–57. ACM
Press, 1984.
[Hee01]
Ralf Heese. Datenbankentwurf für kartographische Informationen mit Unterstützung verschiedener Anwendungsfelder. Institut
für Informatik, Humbold-Universität zu Berlin, Juni 2001.
[Hew01]
Hewlard-Packard.
hp Web services platform - White Paper, 2001.
http://www.e-speak.hp.com/downloads/PDF/11-1701 webservices bus level wp.pdf.
[HR99]
Theo Härder and Erhard Rahm. Datenbanksysteme. SpringerVerlag Berlin Heidelberg, 1999.
[IBM00a] IBM. IBM DB2 Spatial Extender User’s Guide and Reference
Version 7, 2000.
[IBM00b] IBM.
IBM
DB2
Universal
Database
OnlineInformationen
Version
7.1,
2000.
http://www4.ibm.com/software/data/db2/library/publications.
[IBM00c]
IBM.
Web Services architecture overview, September 2000.
http://www-106.ibm.com/developerworks/web/library/w-ovr.
98
[Kin01]
Kingston Centre for GIS, Kingston University.
troduction
to
GIS
and
Geospatial
Data,
http://www.kingston.ac.uk/geog/gis/intro.htm.
[Kir01]
Mary Kirtland.
- White Paper.
ary
2001.
A
Platform
Microsoft
In2001.
for Web Services
Corporation,
Janu-
http://msdn.microsoft.com/library/enus/dnwebsrv/html/websvcs platform.asp.
[Kre01]
Heather Kreger.
ture (WSCA 1.0).
Web Services Conceptual ArchitecIBM, May 2001.
http://www4.ibm.com/software/solutions/webservices/pdf/WSCA.pdf.
[LLWS97] Jong-Hak Lee, Young-Koo Lee, Kyu-Young Whang, and Il-Yeol
Song. A region splitting strategy for physical database design of
multidimensional file organizations. In VLDB’97, Proceedings of
23rd International Conference on Very Large Data Bases, August 25-29, 1997, Athens, Greece, pages 416–425. Morgan Kaufmann, 1997.
[Mye02]
Judith M. Myerson. Web Services Architectures, January 2002.
http://www.webservicesarchitect.com/content/articles/myerson01.asp.
[NHS84]
Jürg Nievergelt, Hans Hinterberger, and Kenneth C. Sevcik.
The grid file: An adaptable, symmetric multikey file structure.
TODS, 9(1):38–71, 1984.
[PSTW93] Bernd-Uwe Pagel, Hans-Werner Six, Heinrich Toben, and Peter Widmayer. Towards an analysis of range query performance
in spatial data structures. In Proceedings of the Twelfth ACM
SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems, May 25-28, 1993, Washington, DC, pages 214–
221. ACM Press, 1993.
[PTS97]
D. Papadias, Y. Theodoridis, and E. Stefanakis. Multidimensional range query processing with spatial relations, 1997.
http://citeseer.nj.nec.com/papadias97multidimensional.html.
[Sam94]
Hanan Samet. The Design and Analysis of Spatial Data Structures. Addison-Wesley Publishing Company, Inc., 1994.
[See02]
Scott Seely. SOAP. Prentice-Hall PTR, 2002.
[Sho01]
Yasser
Shohoud.
Introduction
to
http://www.devxpert.com/tutors/wsdl/wsdl.asp.
WSDL,
2001.
[SHSF01] Tanja Sollazzo, Siegfried Handschuh, Steffen Staab, and
Martin Frank.
Semantic Web Service Architecture, 2001.
http://www.aifb.uni-karlsruhe.de/WBS/sha/papers/swobis flairs.pdf.
99
[SK88]
Bernhard Seeger and Hans-Peter Kriegel. Techniques for design and implementation of efficient spatial access methods. In
Fourteenth International Conference on Very Large Data Bases,
August 29 - September 1, 1988, Los Angeles, California, USA,
Proceedings, pages 360–371. Morgan Kaufmann, 1988.
[SRF87]
Timos K. Sellis, Nick Roussopoulos, and Christos Faloutsos. The
r+-tree: A dynamic index for multi-dimensional objects. In
VLDB’87, Proceedings of 13th International Conference on Very Large Data Bases, September 1-4, 1987, Brighton, England,
pages 507–518. Morgan Kaufmann, 1987.
[Ste01a]
The
Stencil
Services
-
[Ste01b]
The Stencil Group.
Why UDDI Will Succeed, Quietly: Two Factors Push Web Services Forward, April 2001.
http://www.stencilgroup.com/ideas scope 200104uddi.html.
[SW88]
Hans-Werner Six and Peter Widmayer. Spatial searching in geometric databases. In Proceedings of the Fourth International
Conference on Data Engineering, February 1-5, 1988, Los Angeles, California, USA, pages 496–503. IEEE Computer Society,
1988.
[Tap01]
Carlos
C.
Tapang.
Web Services Description
Language (WSDL) Explained.
Microsoft
Corporation,
July
2001.
msdn.microsoft.com/library/enus/dnwebsrv/html/wsdlexplained.asp.
[Tel00a]
Tele Atlas NV. Data Specification Volume 1, January 2000. Dokumentation zu den kartographischen Daten.
[Tel00b]
Tele Atlas NV. Data Specification Volume 2, January 2000. Dokumentation zu den kartographischen Daten.
[Tel01a]
Tele Atlas NV. MultiNet Shapefile 4.0 Format Specifications,
2001. Dokumentation zu den kartographischen Daten.
[Tel01b]
Tele Atlas NV. MultiNet Shapefile 4.0 User Guide, 2001. Dokumentation zu den kartographischen Daten.
[Tid00]
Doug Tidwell. Web services - The Web’s next revolution. IBM,
2000.
http://www6.software.ibm.com/developerworks/education/
wsbasics/.
Group.
White
Defining
June
Web
Paper,
2001.
http://www.stencilgroup.com/ideas scope 200106wsdefined.html.
100
[TS96]
Yannis Theodoridis and Timos K. Sellis. A model for the prediction of r-tree performance. In Proceedings of the Fifteenth ACM
SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems, June 3-5, 1996, Montreal, Canada, pages 161–171.
ACM Press, 1996.
[TSS00]
Yannis Theodoridis, Emmanuel Stefanakis, and Timos K. Sellis.
Efficient cost models for spatial queries using r-trees. Knowledge
and Data Engineering, 12(1):19–32, 2000.
[udd00a]
uddi.org.
UDDI Executive White Paper, September 2000.
http://www.uddi.org/whitepapers.html.
[udd00b]
uddi.org.
UDDI Technical White Paper, September 2000.
http://www.uddi.org/whitepapers.html.
[udd01a]
uddi.org.
on,
UDDI
UDDI
Version
2.0
API
SpecificatiOpen
Draft
Specification,
June
2001.
http://www.uddi.org/pubs/ProgrammersAPI-V2.00-Open20010608.pdf.
[udd01b]
uddi.org.
UDDI Version
ference UDDI Open Draft
2.0 Data Structure ReSpecification, June 2001.
http://www.uddi.org/pubs/DataStructure-V2.00-Open-20010608.pdf.
[Vas00]
Venu
Vasudevan.
mer - White Paper.
A
Web
Services
XML.com, April
http://www.xml.com/pub/a/2001/04/04/webservices/.
Pri2000.
[W3C00a] W3C.
Extensible Markup
W3C Recommendation, second
Language (XML) 1.0;
edition, October 2000.
http://www.w3.org/TR/2000/REC-xml-20001006.
[W3C00b] W3C. Simple Object Access Protocol (SOAP) 1.1; W3C Note,
May 2000. http://www.w3.org/TR/2000/NOTE-SOAP-20000508 .
[W3C01a] W3C. Web Services Description Language (WSDL) 1.1; W3C
Note, March 2001.
http://www.w3.org/TR/2001/NOTE-wsdl20010315.
[W3C01b] W3C. XML Schema Part 1: Structures; W3C Recommendation, May 2001. http://www.w3.org/TR/2001/REC-xmlschema-120010502/.
[W3C01c] W3C. XML Schema Part 2: Datatypes; W3C Recommendation, May 2001. http://www.w3.org/TR/2001/REC-xmlschema-220010502/ .
[War01]
101
Frank Warmerdam. Shapefile C Library V1.2, December 2001.
pobox.com/ warmerdam.
Glossar
Allgemeines Referenzmodell Das allgemeine Referenzmodell aus dem
GDF-Standard beschreibt die Transformation von Objekten der realen
Welt in ihre Datenbankrepräsentation.
Beziehung
∼semantische In der Terminologie des GDF-Standards beschreibt
eine semantische Beziehung (Relationship) die Korrelation zwischen zwei oder mehr Feature.
Clipping Unter Clipping versteht man die Aufteilung eines räumlichen Objekts. Dieses Verfahren wird häufig bei der Indizierung größerer räumlicher Objekte mittels mehrdimensionaler Zugriffsverfahren angewendet.
Data Definition Language Als Data Definition Language (DDL) wird
der Bereich des SQL-Standards bezeichnet, der der Erzeugung von
Objekten (Tabellen, Indizes, usw.) in der Datenbank dient.
Data Manipulation Language Die Data Manipulation Language (DML)
ist Teil des SQL-Standards und dient der Anfrage und Manipulation
von Datenbankinhalten.
Datenfeld Ein Datenfeld ist ein Bestandteil eines Rekords, der ein einzelnes
Datum umfasst, z. B. das Datenfeld Rekordtyp in einem Rekord.
Datenfeldgruppe Eine Datenfeldgruppe umfasst mehrere Datenfelder, die
zusammen gehören, z. B. {Sprache, Name}.
dBASE Im dBASE-Dateiformat könne die Daten einer relationalen Datenbanktabelle inklusive Datentypen und Spaltenbezeichnungen gespeichert werden.
DBMS Ein Datenbankmanagementsystem (DBMS) bezeichnet die Software zum Zugriff auf die Datenbank (Daten).
102
GLOSSAR
103
DEL-Dateiformat (delimited) Das DEL-Dateiformat speichert Datenfelder in einer ASCII-Datei, wobei diese durch ein Trennzeichen separiert
sind.
Entwurfsmuster Ein Entwurfsmuster ist eine Beschreibung zusammenarbeitender Objekte und Klassen, die maßgeschneidert sind, um ein
allgemeines Entwurfsproblem in einem bestimmten Kontext zu lösen.
[GHJV96]
Feature Ein Feature ist die Datenbankdarstellung eines Objektes der realen
Welt (z. B. Frankfurter Allee, Berlin).
Feature-Klasse Eine Feature-Klasse bezeichnet einen Oberbegriff für eine
Gruppe von Feature mit ähnlichen Eigenschaften (z. B. Straße, Stadt).
Fläche Eine Fläche (face) ist ein (abgeschlossenes) zwei- dimensionales Element, das durch eine Menge von Linien begrenzt wird. Innerhalb einer
Fläche dürfen sich Null oder mehr sich nicht schneidende, geschlossene
Mengen von Linien befinden. Diese inneren Flächen werden als Ringe
oder Löcher bezeichnet.
GDF-Standard Der GDF-Standard bietet ein Referenz- und ein Datenaustauschformat zum Speichern und Austauschen von geografischen
Daten codiert in einer ASCII-Datei.
Geokodierung Unter Geokodierung (geocoding) versteht man die Ermittlung der Koordinaten aus einer gegebenen postalischen Adresse.
gespeicherte Prozedur Mit einer gespeicherte Prozedur kann der Nutzer
eines DBMS einen Algorithmus kapseln und mittels CALL aufrufen.
GIS Ein Geo-Informationssystem (GIS) bezeichnet ein Computersystem
zur Erfassung, Verwaltung, Manipulation, Analyse und Visualisierung
von kartografischen Daten [Kin01].
Iterator Ein Iterator definiert eine Sicht auf eine Menge, bei der jedes Element genau einmal berücksichtigt wird. Übliche Methoden sind hasNext() zum Abfragen, ob noch weitere Elemente existieren, und next()
zum Liefern des nächsten Elements.
Knoten Ein Knoten (node) ist ein null-dimensionales Element, das der
Schnittpunkt von zwei oder mehr Linien, der Endpunkt einer Linie
oder ein einzelner isolierter Punkt ist.
Layer Ein Layer gruppiert die kartografischen Daten bezüglich ihrer Thematik, z. B. Autobahnen, Landstraßen, usw.
104
GLOSSAR
Level Mit Level werden die unterschiedlichen Abstraktionsebenen bei der
geometrischen Repräsentation von Feature bezeichnet. Es gibt die Level 0 bis 2, wobei Level 2 die höchste Abstraktion beinhaltet.
Linie Eine Linie (edge) ist eine Folge von sich nicht schneidenden Kanten.
An jedem Ende einer Linie befindet sich ein Knoten.
LOB Unter einem großem Objekt (Large Objekt – LOB) versteht man spezielle Datenbankdatentypen, die zur Aufnahme von besonders großen
Datenmengen (Video, o.ä.) geeignet sind.
Loch siehe Fläche
Map In dieser Arbeit bezieht sich der Begriff Map auf die Standard Template Library (STL). Eine Map verwaltet Schlüssel-Wert-Paare in einem
B-Baum.
nutzerdefinierte Funktion Eine nutzerdefinierte Funktion (UDF) erweitert ein DBMS um vom Nutzer definierte Operationen. Diese Operationen werden innerhalb einer SQL-Anweisung (insbesondere SELECT)
aufgerufen.
Paket Der Begriff Paket wird im Sinne des UML-Standards (package) verwendet und bezeichnet eine logische Gruppierung von Elementen
Point of Interest (POI) Darunter versteht man markante oder wichtige Punkte auf Landkarten wie zum Beispiel Sehenswürdigkeiten und
Freizeitanlagen.
Referenzmodell, allgemeines siehe allgemeines Referenzmodell
Rekord Ein Rekord ist ein Element einer GDF-Datei zur Speicherung eines
Datensatzes.
∼logischer Ein logischer Rekord ist die Aneinanderreihung von Datenfeldern. Ein logischer Rekord kann sich über mehrere physische
erstrecken.
∼physischer Ein physischer Rekord bezeichnet die Aufteilung eines
logischen Rekord zu Zeilen mit maximal 80 Zeichen.
Rekordtyp Je nach Art der Information besitzt der Rekord eine unterschiedliche Struktur. Gleichartige Rekords werden zu einem Rekordtyp
zusammengefasst, z. B. Koordinatenrekords, Punkt-Feature-Rekords.
Relationship siehe Beziehung
Ring siehe Fläche
GLOSSAR
105
RPC Remote Procedure Call bezeichnet ein Kommunikationsprotokoll, das
zum Aufruf von Operationen vor allem über ein Netzwerk verwendet
werden kann.
Shapefile Im Shapefile-Format können Geometrien mit dazugehörigen Eigenschaften kombiniert gespeichert werden. Dabei werden die Geometrien in Shape-Dateien (.shp, .shx) abgelegt und die Eigenschaften in
dBASE-Dateien (.dbf).
SOAP Das Simple Object Access Protocol bietet einen einfachen Mechanismus zum Austausch von strukturierten und getypten Informationen
zwischen dezentralisierten und verteilten Umgebung mittels XML.
Spatial Extender Ein Spatial Extender ist eine Erweiterung eines DBMS
zur Verwaltung, Abfragen und Indizierung von räumlichen Objekten.
stored procedure siehe gespeicherte Prozedur
Strukturierter Datentyp Ein strukturierter Datentyp (structured datatype) ist ein benutzerdefinierter Datentyp, der ein oder mehrere Attribute enthält, die wiederum über Namen und Datentypen verfügen.
Thread Auf einem Betriebssystem in Ausführung befindliche Programminstanzen heißen Prozesse. Threads sind leichtgewichtige Unterprozesse, die die CPU in besonderer Weise bei der Umschaltung zwischen
(Unter-)Prozessen unterstützen.
UDDI Die Universal Description, Discovery and Integration (UDDI) Spezifikation standardisiert das Publizieren und Finden von Informationen
über Webservices.
UDF Abkürzung für user defined function. siehe nutzerdefinierte Funktion
UDT Abkürzung für user defined type. siehe strukturierter Datentyp
ungültiger Treffer Im Zusammenhang mit mehrdimensionalen Zugriffsverfahren versteht man diesem Begriff die Geometrien, die zwar beim
Indexzugriff zurückgeliefert werden, aber nach genauer Überprüfung
der Koordinaten das Anfragefenster doch nicht schneiden.
WSDL Die Webservice Description Language ist eine XML-basierte Sprache zur Definition von Webservices und zur Beschreibung des Zugriffs
auf diese.
XML Die Extensible Markup Language ist eine baumstruktur-orientierte
Sprache zur Repräsentation von semistrukturierten Daten, die dabei
leicht zu erzeugen und zu parsen ist.
106
GLOSSAR
Erklärung
Hiermit erkläre ich, dass ich die vorliegende Arbeit selbständig und ohne
unerlaubte Hilfe verfasst habe.
Berlin, den 28. März 2002
Ralf Heese

Humboldt-Universität zu Berlin

Transcription

Similar documents

Anfragebearbeitung 3

COMPUTERNETZE

Connecta Bestellformular