DBIS - Humboldt-Universität zu Berlin

Humboldt-Universität zu Berlin
Institut für Informatik
Datenbankentwurf für kartographische Informationen
mit Unterstützung verschiedener Anwendungsfelder
Studienarbeit von Ralf Heese
Juni 2001
Betreuer: Dr. Rainer Conrad
Inhaltsverzeichnis
1 Einleitung
1
2 Einführung in das GDF-Format
2.1 Allgemeines Referenzmodell . . . .
2.2 Das GDF-Dateiformat . . . . . . .
2.2.1 Logische Struktur . . . . . .
2.2.2 Physische Struktur . . . . .
2.2.3 Verlinken von Datenrekords
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Entwicklung des Datenbankschemas
3.1 Anforderungsanalyse . . . . . . . . . . .
3.2 Konzeptioneller Datenbankentwurf . . .
3.3 Logischer Datenbankentwurf . . . . . . .
3.3.1 Strukturierung der Datenbank . .
3.3.2 Data Definition Language . . . .
3.4 Physischer Datenbankentwurf . . . . . .
3.4.1 Tabellenbereiche und Pufferpools
3.4.2 Räumlicher Index . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 Einlesen einer GDF-Datei in die Datenbank
4.1 Vorbereiten der Datenbank . . . . . . . . . . .
4.2 Konzepte zum Füllen von Datenbanktabellen .
4.3 Verarbeitung einer GDF-Datei . . . . . . . . .
4.3.1 Struktur . . . . . . . . . . . . . . . . .
4.3.2 Funktionsweise des Scanners . . . . . .
4.3.3 Funktionsweise des Parsers . . . . . . .
4.4 Vorgehen beim Einlesen der Koordinaten . . .
4.5 Laden der DEL-Dateien . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
8
10
14
15
.
.
.
.
.
.
.
.
16
16
19
22
23
23
29
29
31
.
.
.
.
.
.
.
.
34
34
37
39
39
40
42
43
47
5 Zusammenfassung und Auswertung
49
5.1 Fortführung der Studienarbeit . . . . . . . . . . . . . . . . . . 50
i
ii
INHALTSVERZEICHNIS
A Das
A.1
A.2
A.3
Entity Relationship Modell
Entity und Entity-Typ . . . . . . .
Attribut und Attributtyp . . . . . .
Beziehung und Beziehungstyp . . .
A.3.1 Grad . . . . . . . . . . . . .
A.3.2 Kardinalität . . . . . . . . .
A.3.3 Totalität . . . . . . . . . . .
A.4 Spezialisierung und Generalisierung
B Data Definition Language
B.1 Einzigartige Datentypen .
B.2 Tabellen . . . . . . . . . .
B.2.1 Metadatentabellen
B.2.2 Datentabellen . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
52
52
52
53
53
53
53
54
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
55
55
55
56
57
Tabellenverzeichnis
2.1 Rekordtypen (Auszug) . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Spezifikation Koordinaten-Rekord . . . . . . . . . . . . . . . . 11
2.3 Struktur des GDF-Dateiformats . . . . . . . . . . . . . . . . . 13
3.1
Definierte eizigartige Datentypen . . . . . . . . . . . . . . . . 26
4.1
Werte für die Systemvariablen . . . . . . . . . . . . . . . . . . 35
A.1 Interpretation der Kardinalitäten . . . . . . . . . . . . . . . . 54
iii
Abbildungsverzeichnis
1.1
Kontext des Systems . . . . . . . . . . . . . . . . . . . . . . .
3
2.1
Allgemeines Referenzmodell (vereinfacht) . . . . . . . . . . . .
9
3.1
3.2
3.3
3.4
3.5
Datenbankschema (Teil 1) . . . . . . . . . . .
Datenbankschema (Teil 2) . . . . . . . . . . .
Aufteilung der Datenbank . . . . . . . . . . .
Datentypen des Spatial Extender (Ausschnitt)
Gitterindex . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
21
22
23
28
32
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
Vorbereitung der Datenbank (vereinfacht) . . . . . .
Datenfluss beim IMPORT-Befehl/LOAD-Hilfsprogramms
Komponenten des Einleseprogramms . . . . . . . . .
Einlesen einer logischen Zeilen . . . . . . . . . . . . .
Auslesen von Datenfeldern aus einer logischen Zeile .
Parsen eines Knotenrekords . . . . . . . . . . . . . .
Polygon in der GDF-Datei . . . . . . . . . . . . . . .
resultierendes Polygon in der Datenbank . . . . . . .
Einlesen der DEL-Dateien . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
36
38
40
41
42
44
47
47
48
A.1
A.2
A.3
A.4
Entity-Typ . . . . . . . . . . . . .
Attributtypen . . . . . . . . . . . .
Beziehungstyp . . . . . . . . . . . .
Spezialisierung und Generalisierung
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
52
53
53
54
iv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Kapitel 1
Einleitung
Ein computergestütztes Geo-Informationssystem (GIS) bezeichnet ein Computersystem zur Erfassung, Verwaltung, Manipulation, Analyse und Visualisierung von kartographischen Daten [Kin01]. Wichtige Komponenten eines
GIS sind Hardware, Software und Daten. Hardware bezeichnet in diesem Zusammenhang den Computer, auf dem das GIS operiert. Die Software umfasst
die Werkzeuge, mit denen kartographische Daten verarbeitet werden. Hierzu
zählen unter anderem Datenbankmanagementsysteme (DBMS), Visualisierungswerkzeuge sowie Werkzeuge zur Analyse und Manipulation. Die wohl
wichtigste Komponente in einem GIS sind die Daten. GIS beschränken sich
nicht nur auf die Koordinaten räumlicher Objekte, sondern integrieren auch
zusätzliche mit den Orten verbundene Daten.[ESR98]
GIS bilden eine Grundlage unter anderem für Planungs- und Verwaltungsaufgaben und ermöglichen die Analyse des Zusammenspiels unterschiedlicher
Arten von Informationen basierend auf deren geographischen Position. Wie
bereits oben angedeutet, gehören zu den Aufgaben eines GIS
• die Konvertierung der Daten von Karten in ein digitales Format.
• die Transformation bzw. Manipulation der Daten. Dies kann zum Beispiel eine kurzzeitige Transformation zur Darstellung eines Kartenausschnitts sein.
• die Speicherung der Daten in Dateien (flat file) oder mit Hilfe eines
Datenbankmanagementsystems in einer Datenbank.
• die Analyse von Daten und die Beantwortung von Anfragen. Hauptziele dabei sind das Finden von passenden Gebieten zu gegebenen Fakten (z. B. zur Planung von Flughäfen) und das Erfragen spezieller Eigenschaften einer geographischen Lokalität (z. B. Verkehrsdichte einer
Straße).
1
2
KAPITEL 1. EINLEITUNG
• die Visualisierung als Karte oder Graph.
DBMS sind auf die Speicherung und Verwaltung großer Datenbestände
optimiert und werden darum immer häufiger als Datenquelle für die unterschiedlichen Werkzeuge eingesetzt. Nicht zuletzt die Entwicklung spezieller
Erweiterungen für die Verarbeitung räumlicher Daten unterstützt diese Tendenz. Da im Allgemeinen die zu verarbeitenden Daten in unterschiedlichen
Datenformaten vorliegen, ermöglicht die Verwendung eines DBMS nicht nur
eine einfache Speicherung und Organisation der Daten, sondern es wird durch
eine Integration dieser verschiedenen Datenquellen in eine Datenbank ein
datenformatunabhängiger Zugriff erreicht. Weiterhin unterscheiden sich die
Datenquellen im Transportmedium; statische1 Daten werden meistens mittels Datenträger wie zum Beispiel CD oder Band transportiert, wohingegen
dynamische Daten einfacher via Internet bezogen werden. Ein Datenbanksystem gestattet als lokaler Zwischenspeicher den Zugriff auf alle Datenquellen
unabhängig vom Transportmedium.
Diese Studienarbeit entstand im Rahmen eines Kooperationsabkommens
zwischen dem Lehrstuhl für Datenbanken und Informationssysteme am Institut für Informatik der Humboldt-Universität zu Berlin und der Firma Vivatech Software Berlin GmbH, die unter anderem Software zur Visualisierung
von kartographischen Daten konzipiert. Das Ziel ist die Entwicklung eines
datenbankgestützten Geo-Informationssystem zur performanten Verwaltung
kartographischer Daten sowie die effiziente Beantwortung von Anfragen. Dabei steht eine Integration unterschiedlicher Datenquellen im Vordergrund.
Der schematische Aufbau eines solchen Systems ist in Abbildung 1.1 veranschaulicht. Die Grundlage dieses System bilden statische (GDF, Höhendaten, Satellitenbilder usw.) und dynamische Daten (Verkehrsdaten, Wetterdaten usw.), die durch Datenbanken bereitgestellt werden. Vorhandene
Applikationen zur Visualisierung wie zum Beispiel 2D- und 3D-Renderer fordern zur Verarbeitung Daten für Kartenausschnitte aus der Datenbank an.
Hierbei ist eine Zusammenführung unterschiedlicher Datenquellen notwendig, um die vom Nutzer gewünschten Informationen als Ganzes präsentieren
zu können.
Die Grundlage dieser datenbankgestützten Lösung bildet der konzeptionelle Entwurf eines Datenbankschemas zur Verwaltung der im GDF-Format
vorliegenden kartographischen Daten. Dabei soll der Entwurf die effiziente
Beantwortung typischer Anfragen gewährleisten. Neben dem eigentlichen Datenbankentwurf steht auch die Entwicklung und Implementierung eines effizi1
Hierbei beziehen sich die Begriffe statisch“ und dynamisch“ auf die Häufigkeit der
”
”
durchgeführten Aktualisierungen.
3
Applikationen
statische
Daten
GDF
Höhen− sonstige
daten
Bilder
integriertes
Datenbankschema
Satelliten− Points of
bilder
Interest
dynamische
Daten
Verkehrs−
daten
Wetter−
daten
Points of
Interest
Abbildung 1.1: Kontext des Systems
enten Tools zum Einlesen einer GDF-Datei in eine Datenbank im Mittelpunkt
der Betrachtungen. Im Anschluss wird das entwickelte Modell bezüglich eines
konkreten Datenbankmanagementsystems physisch umgesetzt, mit kartographischen Daten gefüllt und das bis dahin entstandene System bewertet.
Im folgenden Abschnitt werden die bisherigen Vorgehensweisen für die
Verarbeitung der Daten skizziert. Die Firma Vivatech Software Berlin GmbH
verwendet für die Berechnung von 2D- und 3D-Darstellungen eines Kartenausschnittes unter anderem geographische Daten, die als Dateien im GDF
Format vorliegen. Für die Verarbeitung und den Zugriff der Daten wurden
bisher eigene Routinen in Java implementiert, die zunächst die GDF-Dateien
entsprechend der unterschiedlichen Daten sortiert in den Hauptspeicher einlasen. Die Nachbildung gewisser Funktionalitäten eines Datenbankmanagementsystems — zum Beispiel wurden Joins manuell durchgeführt — erlaubte
eine schnelle Filterung der Daten unter bestimmten Gesichtspunkten.
Durch diese individuelle Lösung ist jedoch eine Integration anderer Datenquellen oder Datenformate nur durch Erweiterung des bestehenden oder
Hinzufügen neuen Quellcodes möglich. Gerade die Integration zusätzlicher
Datenquellen wie zum Beispiel Wetter- oder Verkehrsdaten erhöht die Attraktivität und den Mehrwert einer Visualisierung von Kartenausschnitten.
Weiterhin sind Anfragen an die Datenbasis nur in dem Umfang möglich,
wie sie durch die Implementation der Zugriffsroutinen vorgegeben sind. Die
Verwendung des Hauptspeichers als Medium zum Vorhalten der kartographi-
4
KAPITEL 1. EINLEITUNG
schen Daten beschränkt aufgrund des großen Speicherbedarfs die Nutzbarkeit eines solchen Systems. Letztendlich konnte somit nur auf einem kleinen
Ausschnitt der Daten operiert werden.
Der Inhalt der einzelnen Kapitel dieser Studienarbeit wird im Folgenden kurz erläutert. Kapitel zwei gibt zunächst eine Einführung in das GDFFormat, in dem die zu verarbeitenden Daten vorliegen. Zum Verständnis des
Formats und der inneren Zusammenhänge wichtige Begriffe werden zusammenfassend erklärt und anhand von Beispielen illustriert. Des Weiteren wird
auf den konzeptionellen Aufbau und die physische Speicherung einer GDFDatei eingegangen.
Das dritte Kapitel konzentriert sich vor allem auf den Entwicklungsprozess des Datenbankschemas. Nach der Abgrenzung des Problemraumes wird
das entwickelte Datenbankschema vorgestellt und die Realisierung bezüglich
des Datenbankmanagementsystems DB2 Universal Database Version 7.1 mit
der Erweiterung DB2 Spatial Extender diskutiert. Neuerungen dieses DBMS
sind die strukturierten Datentypen und typisierten Tabellen. Eine Realisierung unter Einbeziehung der Neuerungen wird der üblichen relationalen Vorgehensweise gegenübergestellt.
Im Kapitel vier werden prinzipielle Konzepte zur Übertragung der Daten
aus einer GDF-Datei in eine Datenbank beschrieben. Diese Konzepte befassen sich hauptsächlich mit DB2 UDB V7.1, sind jedoch auch in den meisten
anderen DBMS umsetzbar. Zu diesem Zweck wurden Werkzeuge entworfen
und implementiert, die den Transfer der Daten aus GDF-Dateien in die Datenbank unterstützen. Nachdem die Komponenten und die Funktionsweise
der Werkzeuge erläutert wurde, werden spezielle Probleme der vorliegenden
räumlichen Daten und deren Lösung veranschaulicht.
Kapitel 2
Einführung in das Geographic
Data File Format
Der Geographic Data File Standard [GDF95] wurde 1995 dem European
Committee for Standardization zur Begutachtung vorgelegt. Entwickelt wurde der Standard für Firmen und Organisationen, die effizient Daten eines
Straßenverkehrsnetz sammeln, verwalten und produzieren müssen. Der Standard bietet ein allgemeines Referenzmodell, auf das sich sowohl Produzent
als auch Nutzer bei der Entwicklung ihrer Applikation stützen können. Auf
Grundlage dieses Modells wurde auch ein Datenaustauschformat definiert,
um Kompatibilitätsprobleme zu minimieren. Weiterhin beschreibt der Standard, wie darin gespeicherte Daten dargestellt und Metainformationen (z. B.
Qualität der Daten) definiert werden.
In diesem Kapitel werden alle zum Verständnis notwendigen Aspekte des
GDF-Standards näher betrachtet.
2.1
Allgemeines Referenzmodell
Zum Verständnis des Modells werden zunächst einige Begriffe, die im Zusammenhang mit dem GDF-Standard stehen, definiert und soweit möglich
anhand von Beispielen veranschaulicht. Die folgenden Definitionen basieren
auf denen in [GDF95].
Definition 2.1 (Feature) Ein Feature (feature1 ) ist die Datenbankdarstellung eines Objektes der realen Welt.
1
In Klammern steht immer die Bezeichnung, wie sie im Englischen verwendet wird.
5
6
KAPITEL 2. EINFÜHRUNG IN DAS GDF-FORMAT
Der Begriff Feature ist dabei nicht wie im Deutschen üblich als Eigenschaft
oder Merkmal zu verstehen, sondern vielmehr als eine Sammlung (i.S. von
Tupel) von Eigenschaften eines Objektes der realen Welt.
Ein Feature kann zum Beispiel die (bestimmte) Berliner Straße, das Sony
Center oder der Bezirk Wedding in Berlin sein. Jedes Feature gehört einer
Feature-Klasse an.
Definition 2.2 (Feature-Klasse) Eine Feature-Klasse (feature class) bezeichnet den Oberbegriff von Feature. Jeder Feature-Klasse ist ein eineindeutiger vierstelliger numerischer Code zugeordnet.
Zum Beispiel können die Berliner Straße, die Frankfurter Allee und die
Rudower Chaussee dem allgemeinen Begriff Straße oder die Bezirke Wedding,
Reinickendorf und Mitte dem Begriff Bezirk zugeordnet werden.
Eine weitere Gruppierung stellen die Feature-Themen dar.
Definition 2.3 (Feature-Thema) In einem Feature-Thema (feature theme) werden gleichartige Feature-Klassen zusammengefasst. Jedem FeatureThema wird ein eineindeutiger zweistelliger numerischer Code zugeordnet.
Betrachtet man beispielsweise Straßen, Kreuzungen oder Fährverbindungen, so werden diese zu dem Feature-Thema Straßen und Fährverbindungen (Roads and Ferries) zusammengefasst. Als ein weiteres Beispiel werden
Länder, Bezirke, Gemeinden, usw. dem Feature-Thema Verwaltungsgebiete
(Administrative Areas) zugeordnet.
Mit Hilfe des GDF-Standard kann, wie oben angedeutet, auch die graphische Repräsentation eines Features verwaltet und gespeichert werden.
Definition 2.4 (Feature-Kategorie) Eine Feature-Kategorie (feature category) ist die Darstellungsform eines Features. Jeder Feature-Kategorie wird
ein eineindeutiger einstelliger numerischer Code zugeordnet.
Es gibt insgesamt vier verschiedene Repräsentationsformen: Punkt, Linienzug, Gebiet und komplex (point, line, area und complex). In diese vier
Gruppen lassen sich auch die Feature unterteilen (vgl. S. 9, Abb. 2.1), d.h.
es gibt Punkt-, Linienzug- und Gebiet-Feature, dies sind die so genannten
simplen Feature, und es gibt die komplexen Feature. Komplexe Feature sind
dabei entweder aus simplen Feature oder aus komplexen Feature selbst zusammengesetzt. Eine Kombination von simplen und komplexen Feature zu
einem komplexen Feature ist nicht erlaubt.
Ein Feature besitzt im Allgemeinen noch weitere Eigenschaften.
2.1. ALLGEMEINES REFERENZMODELL
7
Definition 2.5 (Attribut) Ein Attribut (Attribute) ist eine Eigenschaft
eines Features. Jedem Attribut wird ein eineindeutiger zweistelliger alphanumerischer Code zugeordnet.
Eine Eigenschaft kann zum Beispiel die Bezeichnung eines Features in der
realen Welt sein, die Anzahl der Spuren einer Straße oder die Telefonnummer
einer Tankstelle.
Wenn eine Eigenschaft eines Features weitere Features einbezieht, so wird
dies mit Hilfe von semantischen Beziehungen realisiert.
Definition 2.6 (semantische Beziehung) Eine semantische Beziehung
(semantic relationship) ist eine Eigenschaft eines Features in der andere Features involviert sind. Jeder semantischen Beziehung wird ein eineindeutiger
vierstelliger numerischer Code zugeordnet.
Eine solche semantische Beziehung (kurz Beziehung) könnte zum Beispiel
beschreiben, dass sich das Sony Center auf dem Potsdamer Platz befindet,
wobei das Sony Center und der Potsdamer Platz als Features anzusehen sind.
Die folgenden Definitionen beschreiben die Basiselemente für die Repräsentation von Punkt-, Linienzug- und Gebiet-Feature.
Definition 2.7 (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.
Definition 2.8 (Linie) Eine Linie (edge) ist eine Folge von sich nicht
schneidenden Kanten. An jedem Ende einer Linie befindet sich ein Knoten.
Das Wort edge bedeutet eigentlich Kante; dieser Begriff wird in der Informatik überwiegend als geradlinige Verbindung zweier Knoten im Zusammenhang mit Graphen verwendet. Aber im GDF-Standard handelt es sich
eigentlich um mehrere Kanten die zu einer edge zusammengesetzt werden,
d.h., es ist ein Linienzug. Da der Begriff Linienzug bereits für eine FeatureKategorie vergeben wurde, erscheint die Bezeichnung Linie als angemessen.
Definition 2.9 (Fläche) Eine Fläche (face) ist ein (abgeschlossenes) zweidimensionales Element, das durch eine Menge von Linien begrenzt wird. Innerhalb einer Fläche dürfen sich null oder mehr sich nicht schneidende, geschlossene Mengen von Linien befinden.
Diese inneren Flächen werden als Ringe oder Löcher bezeichnet.
8
KAPITEL 2. EINFÜHRUNG IN DAS GDF-FORMAT
Die eigentliche Fläche berechnet sich also aus der Grundfläche abzüglich
ihrer Löcher. Bei der Beschreibung der Fläche werden die Koordinaten der
Grundfläche im Uhrzeigersinn und die Koordinaten der Löcher entgegen dem
Uhrzeigersinn notiert.
Die Zusammenhänge zwischen den oben definierten Begriffen werden in
Abbildung 2.1 veranschaulicht. Um die Übersichtlichkeit zu erhalten, sind in
diesem Bild keine Attribute eingetragen. Hinweise zur Interpretation eines
ER-Schemas finden sich im Anhang A.
Der Entity-Typ Feature steht im Zentrum des allgemeinen Referenzmodells. Dem Feature werden dabei Attribute, Beziehungen, genau eine FeatureKlasse und genau eine Feature-Kategorie zugeordnet.
Der GDF-Standard lässt für die Kardinalität bei der Beziehung zwischen Feature-Klasse und Feature-Kategorie die zwei Möglichkeiten ’1’ und
’N’ zu (vgl. Abb. 2.1). Die Wahl der Variante bleibt dem Produzenten der
GDF-Datei überlassen. Zum einen kann festgelegt werden, dass Feature einer Feature-Klasse genau auf eine Art und Weise dargestellt werden, zum
anderen können Feature einer Feature-Klasse unterschiedliche Darstellungsformen annehmen. Ein Beispiel für die erste Variante ist, dass alle Feature
der Feature-Klasse Service durch einen Punkt dargestellt werden müssen.
Unter Benutzung der zweiten Variante könnte die Darstellung einer Brücke
als Punkt- oder auch als Gebiet-Feature erlaubt sein. Eine Feature-Klasse ist
wiederum genau einem Feature-Thema zugeordnet.
In der Abbildung 2.1 ist zu erkennen, dass ein Punkt-Feature durch genau einen Knoten, Linienzug-Feature durch Linien und Gebiet-Feature durch
Flächen repräsentiert werden. Zur Vereinfachung der Darstellung wurden
einige Beziehungen zwischen Knoten, Linie und Fläche weggelassen. Diese
Beziehungen geben die in den Definitionen 2.8 und 2.9 gemachten Zusammenhänge wieder: an jedem Ende einer Linie befindet sich ein Knoten und
eine Fläche wird von einer Menge von Linien begrenzt.
2.2
Das GDF-Dateiformat
In einer GDF-Datei werden alle für die Repräsentation eines Kartenausschnitts notwendigen Daten wie Koordinaten, Attribute, Qualität gespeichert. Das Format reflektiert das allgemeine Referenzmodell und dient vor
allem dem Austausch der Daten zwischen unterschiedlichen Anwendungen,
z. B. zwischen Produzent und Nutzer.
Bei der Beschreibung der Struktur einer GDF-Datei wird zwischen logischer und physischer Struktur unterschieden. Die logische Struktur beschreibt
den grundsätzlichen Aufbau einer GDF-Datei, d.h. aus welchen Bestandteilen
2.2. DAS GDF-DATEIFORMAT
9
Feature
Thema
1
besteht
aus
M
M
Feature
Klasse
dargest.
durch
gehört
zu
besteht
aus
M
beteiligt
an
M
M
N
semantische
Beziehung
M
M
komplexes
Feature
Feature
Kategorie
1
1
Feature
1/N
M
N
besitzt
besteht
aus
N
N
Attribut
simples
Feature
besteht
aus
Punkt
Feature
M
repräsent
durch
Linienzug
Feature
M
repräsent
durch
Gebiet
Feature
M
repräsent
durch
1
N
N
Knoten
Linie
Fläche
Abbildung 2.1: Allgemeines Referenzmodell (vereinfacht)
10
KAPITEL 2. EINFÜHRUNG IN DAS GDF-FORMAT
eine Datei zusammengesetzt ist. Bei der physischen Struktur handelt es sich
um die Spezifikation, wie die logischen Strukturelemente in einer Datei physisch abgespeichert werden. Dieser Abschnitt dient dem besseren Verständnis
des Programms zum Einlesen einer GDF-Datei in die Datenbank.
2.2.1
Logische Struktur
Im Folgenden soll zunächst nur der grundsätzlich Aufbau einer GDF-Datei
besprochen werden, ohne dabei auf die Belange einer adäquaten Speicherung
auf einem Sekundärspeicher einzugehen.
Eine GDF-Datei besteht aus einer Folge von logischen Rekords2 , die alle
im GDF-Standard vorgesehenen Daten beinhalten können. Ein logischer Rekord wird in Datenfelder aufgeteilt, die durch Position und Länge bestimmt
sind. Das wichtigste Datenfeld bilden die ersten beiden Zeichen, das den Rekordtyp bestimmt und damit erst eine Interpretation der folgenden Zeichen
als Datenfelder ermöglicht.
In Tabelle 2.1 sind die wichtigsten Rekordtypen aufgelistet. Die übrigen
sind für das Verständnis dieser Studienarbeit nicht notwendig und können
gegebenenfalls in [GDF95] nachgeschlagen werden. Die erste Spalte in der
Tabelle gibt hierbei die Kodierung des Rekordtyps an, die darauffolgende
enthält die Bezeichnung des Rekords wie sie im GDF-Standard verwendet
wird und die letzte beschreibt den Zweck in einer GDF-Datei.
Anhand des Beispiels des Koordinaten-Rekords soll die Definition eines
logischen Rekords verdeutlicht werden. In Tabelle 2.2 ist auszugsweise die
Spezifikation des Koordinaten-Rekords dargestellt.
Wie bereits oben beschrieben, kodieren die ersten beiden Zeichen (hier
’23’) den Rekordtyp. Die nächsten zehn Zeichen gehören zur KoordinatenID, das darauf folgende Zeichen bezeichnet den Geometrietypcode usw. Ist
an der Stelle für die Größe ein ’*’ eingetragen, so darf dieses Datenfeld theoretisch3 unbegrenzt lang sein. Daneben in der Spalte Typ ist der zugehörige
Datentyp spezifiziert, z. B. ’N’ für numerisch. Die nächste Spalte entscheidet
darüber, ob das Datenfeld leer (NULL-Wert) gelassen werden darf, wobei
’Obl’ für obligatorisch und ’<S>’ für optional steht. Handelt es sich um ein
ungenutztes optionales Datenfeld, so muss dieses mit Leerzeichen aufgefüllt
werden. Im GDF-Standard ist festgelegt, dass numerische Werte rechtsbündig
und Text linksbündig einzutragen sind.
Eine besondere Bedeutung hat das Datenfeld ’NUM COORD’. Dieses
Feld gibt an, wie oft die darauf folgenden Datenfelder, die mit einem senk2
3
Im Gegensatz zu physischen Rekords, die weiter unten erläutert werden.
In der Realität gibt es natürlich Grenzen, z. B. durch das Speichermedium.
2.2. DAS GDF-DATEIFORMAT
Code
00
01
02
16
17
90
99
23
24
25
29
41
44
50
51
52
53
54
Name
Bedeutung
allgemeine Rekordtypen
Continuation Record
Fortsetzungsrekord
Volume Header Record
Leitet Volume ein
Dataset Header Record
Leitet Dataset ein
Section Header Record
Leitet Section ein
Layer Header Record
Leitet Layer ein
Comment Record
Ermöglicht Kommentare
Volume Termination Record Beendet Volume
Datenrekords
Coordinates Record
für Koordinaten
Edge Record
für eine Linie
New Node Record
für einen Knoten
Face Record
für eine Fläche
Name Record
für einen Namen
Segmented Attribute Record für Attribute
Relationship Record
für eine Beziehung
Point Feature Record
für einen Punkt
Line Feature Record
für einen Linienzug
Area Feature Record
für ein Gebiet
Complex Feature Record
für ein komplexes Feature
Tabelle 2.1: Rekordtypen (Auszug) [GDF95]
Datenfeld
Größe Typ NULL Beschreibung
REC DESCR
2
N
Obl
Rekordtypcode (23)
XYZ ID
10
N
<S>
Koordinaten ID
G TYPE
1
N
<S>
Geometrietypcode
Q PLAN
2
I
<S>
Qualitätscode
DESC ID
5
N
<S>
Quellen ID
NUM COORD
5
N
Obl
Datenfeldzähler
| X COORD
10
I
<S>
X-Koordinate
| Y COORD
10
I
<S>
Y-Koordinate
| Z COORD
10
I
<S>
Z-Koordinate
Tabelle 2.2: Spezifikation Koordinaten-Rekord
11
12
KAPITEL 2. EINFÜHRUNG IN DAS GDF-FORMAT
rechten Strich gekennzeichnet sind, wiederholt werden. Wenn zum Beispiel
im Koordinaten-Rekord im Datenfeld ’NUM COORD’ eine drei steht, so
bedeutet dies, dass drei Koordinatentripel bestehend aus den Datenfelder
’X COORD’, ’Y COORD’ und ’Z COORD’ vorhanden sind.
Das Beispiel 2.1 zeigt eine Instanziierung eines Koordinaten-Rekords mit
der ID ’8000151’ und zwei Koordinatentripeln. Insbesondere sind hier die mit
Leerzeichen ( ) aufgefüllten Z-Koordinaten zu erkennen. Wegen der besseren
Lesbarkeit wurde der Rekord auf zwei Zeilen verteilt, es handelt sich jedoch
um eine einzelne.
Beispiel 2.1 (logischer Rekord)
23
8000151
3 13318186 52520401
13326591 52526318
13318760 52522824
Nachdem nun der Aufbau der einzelnen Rekords erläutert wurde, wird die
Anordnung der Rekords in der GDF-Datei selbst besprochen. Der generelle
Aufbau einer GDF-Datei ist in Tabelle 2.3 veranschaulicht. Dabei bedeuten
die geschweiften Klammern, dass diese Teile Null oder mehr Mal auftreten
dürfen.
Eine GDF-Datei beginnt grundsätzlich mit einem Volume Header, in
dem allgemeine Informationen wie Hersteller, Erstellungsdatum, verwendeter Standard gespeichert werden. Ein Volume bildet die kleinste physisch
speicherbare Einheit, d.h., ein Volume darf nicht auf mehrere Datenträger
verteilt werden. Mehrere zusammengehörige Volumes werden zu einem Album zusammengefasst. Ein Volume wird explizit mit dem Volume Termination-Rekord beendet.
Das Dataset Level bildet die nächste Ebene in der logischen Struktur. Ein
Dataset ist eine große Menge Daten, die ein geographisches Gebiet abdecken
[GDF95]. Ein Volume kann in Abhängigkeit von der Größe der Datasets mehrere enthalten. Ein Dataset Level wird durch Dataset Header-Rekords eingeleitet, die unter anderem einen eindeutigen Identifikator des Datasets aufnehmen. Darauf können die Definitionen für eigene Datenfelder, Rekords, Features und Attribute folgen. Weiterhin sind Qualitäts- und Quellenangaben
sowie geographische Spezifikationen, z. B. Erdmagnetfeld, möglich. Ein Dataset endet mit dem Beginn des nächsten oder mit dem Volume TerminationRekord.
Auf Grundlage der Koordinaten werden aus einem Dataset Untermengen
gebildet, die Section genannt werden, und bilden die nächste Ebene. Eine
Section beginnt mit Section Header-Rekords, die einen eindeutigen Identifikator der Section enthält. Weitere für die Verarbeitung wichtige Informationen
wie Faktoren, Offsets oder Maximal- und Minimal-Koordinatenwerte werden
2.2. DAS GDF-DATEIFORMAT
Volume Level Dataset Level
Volume Header
{
Dataset Header
Definitionen
Qualitätangaben
Quellenangaben
geogr. Infos
13
Section Level
Layer Level
{
Section Header
{
Layer Header
Koordinaten
Knoten
Linien
Flächen
Punkt-Features
Linienzug-Features
Gebiet-Features
komplexe Features
Attribute
}
Beziehungen
Namen
Attribute
}
}
Volume Term.
Tabelle 2.3: Struktur des GDF-Dateiformats (vereinfacht)[GDF95]
14
KAPITEL 2. EINFÜHRUNG IN DAS GDF-FORMAT
durch den Section Header zur Verfügung gestellt. In diesem Level stehen auch
Rekords für die Namen, Beziehungen und Attribute. Das Ende einer Section ist durch den Beginn der nächsten Section (neue Section-ID) bzw. dem
nächsten Dataset oder dem Volume Termination-Rekord gekennzeichnet.
Die unterste Ebene bildet das Layer Level. Ein Layer ist eine auf Grund
inhaltlicher Informationen gebildete Untermenge einer Section. In dem Header eines Layers können vor allem Genauigkeitsangaben für die Koordinaten
gemacht werden. Die Layer-Ebene dient der Aufnahme der eigentlichen Datenrekords, z. B. Koordination, Knoten, usw. Ein Layer endet mit dem Beginn des nächsten. Der letzte Layer ist durch das Auftreten eines Conversion-,
Semantic Relationship-, Section Header-, Dataset oder Volume TerminationRekord markiert. Eine wichtige Restriktion für die Koordinaten bezüglich
eines Layers ist, dass die räumlichen Objekte einen planaren Graphen bilden. D.h., der Schnittpunkt zweier oder mehr Linien ist ein Knoten und
gehört zu dem Layer, dem die Linien angehören.
Innerhalb einer Ebene ist die Reihenfolge der Rekords nicht vorgeschrieben. Das bedeutet, dass nach dem jeweiligen Header-Rekord (Volume, Dataset, Section oder Layer) die unterschiedlichen Rekords in beliebiger Reihenfolge auftreten dürfen. Im GDF-Standard wird jedoch empfohlen die Blöcke
und Rekords in einer definierten Reihenfolge anzuordnen, insbesondere gilt
dieses für die Datenrekords.
2.2.2
Physische Struktur
In diesem Abschnitt wird die physische Speicherung der Datenrekords vorgestellt. Es geht also um die physische Darstellung eines logischen Rekord in
einer GDF-Datei. Die hier vorgestellten Konzepte wirken sich auf das Einlesen einer GDF-Datei aus. Die verwendete Aufteilung von einer logischen
Zeile auf mehrere physische Zeilen und das damit einhergehende Auffüllen
der physischen Zeilen kompliziert das Auslesen von Datenfeldern.
Eine GDF-Datei besteht ausschließlich aus ASCII-Zeichen, wobei die Zeilenlänge genau 80 Zeichen zuzüglich Zeilenumbruch (ein Zeichen bei einer
Unix- und zwei Zeichen bei einer Windowsdatei) beträgt. Eine solche Zeile
bestehend aus 80 Zeichen wird im Folgenden als physische Zeile bezeichnet.
Daraus folgt, dass logische Rekords, die mehr als 80 Zeichen beinhalten,
auf mehrere Zeilen verteilt werden müssen. Zur Kennzeichnung, dass ein logischer Rekord auf der nächsten Zeile fortgesetzt wird, enthält das 80. Zeichen
eine ’1’, sonst eine ’0’. Handelt es sich um eine fortgesetzte Zeile, so beginnt
sie mit zwei Nullen (vgl. Continuation Record in [GDF95]). Der Zeilenumbruch erfolgt immer an einer Stelle, an der zwei Datenfelder des logischen
Rekords aneinander stoßen, so dass ein Datenfeld immer vollständig auf ei-
2.2. DAS GDF-DATEIFORMAT
15
ner physischen Zeile steht. Die restlichen nicht nutzbaren Zeichen werden mit
Leerzeichen aufgefüllt.
Beispiel 2.2 (physischer Rekord)
Dieses Beispiel zeigt die physische Repräsentation von Beispiel 2.1.
23
00
8000151
13318760
3 13318186 52520401
52522824
13326591
52526318
Im Beispiel 2.2 wird das Prinzip des Aufteilens einer zu langen logischen
Zeile deutlich. Da die Z-Koordinate des zweiten Tripels bestehend aus zehn
Leerzeichen nicht mehr auf die Zeile passt, muss eine neue Zeile begonnen
werden. Das bedeutet, das 80. Zeichen der ersten Zeile wird auf ’1’ gesetzt
und es wird ein Continuation Record erzeugt. Die übrigen Werte (die ZKoordinate des zweiten Tripels und das komplette dritte Tripel) werden nun
in die zweite Zeile eingetragen. Würde die logische Zeile nicht in diese zwei
Zeilen hineinpassen, so müsste eine weitere Zeile angefangen werden usw. Das
80. Zeichen der zweiten Zeile ist eine ’0’, um das Ende eines logischen Rekords
anzuzeigen. Es fällt auf, dass jetzt Leerzeichen hinzugekommen sind — die
sechs Leerzeichen am Ende der ersten Zeile und 37 am Ende der zweiten
Zeile. Diese müssen dann beim Auslesen der Daten ignoriert werden.
2.2.3
Verlinken von Datenrekords
Verlinken meint in diesem Zusammenhang die Realisierung der im allgemeinen Referenzmodell (vgl. S. 9, Abb. 2.1) vorgestellten Beziehungen zwischen
den Entities. Diesen Referenzen muss beim späteren Einlesen gefolgt werden,
um einem Feature seine Attribute und Koordinaten zuordnen zu können.
Zu diesem Zweck definiert jede Spezifikation für ein Datenrekord (vgl.
Tab. 2.1 auf Seite 11) ein Datenfeld, das einen zehnstelligen Identifikator
aufnehmen kann. Dieser Identifikator muss für den jeweiligen Rekordtyp eindeutig sein. Zum Beispiel enthält die Spezifikation des Koordinaten-Rekord
(vgl. Tab. 2.2 auf Seite 11) ein Datenfeld ’ID’, das eine für alle KoordinatenRekords eindeutige ID aufnimmt.
Des Weiteren sind in den Rekordspezifikationen Datenfelder eingeführt
worden, die eine solche ID als Referenz4 aufnehmen können. So besitzt zum
Beispiel der Rekordtyp New Node Record ein Datenfeld ’XYZ ID’, dass einen
Koordinaten-Rekord referenziert, d.h., in das Datenfeld ’XYZ ID’ wird die ID
des zugehörigen Koordinaten-Rekords eingetragen. Damit wird die Beziehung
repräsentiert durch zwischen Punkt-Feature und Knoten realisiert.
4
Im Rahmen von einigen Programmiersprachen spricht man dann von Zeigern oder
Pointern.
1
0
Kapitel 3
Entwicklung des
Datenbankschemas
Der Entwicklungsprozess eines Datenbankschemas setzt sich aus mehreren
Teilschritten zusammen [Fre99][Teo94].
Im ersten Arbeitsschritt wird der Problemraum abgegrenzt und beschrieben. Es werden relevante Objekte, ihre Eigenschaften und Beziehungen betrachtet, Transaktionen und Operationen bestimmt, sowie Systemeigenschaften festgelegt. Diese Phase beeinflusst die Qualität der späteren Lösung wesentlich.
Der nächste Arbeitsschritt ist der konzeptionelle Datenbankentwurf, in
dem auf Grundlage der Anforderungen ein Modell in einer Modellbeschreibungssprache (z. B. Entity Relationship Modell, UML) entworfen wird.
Die Abbildung des entworfenen konzeptionellen Schemas in ein konkretes Datenbankmodell bzgl. eines konkreten Datenbankmanagementsystems
(DBMS) kennzeichnet den dritten Arbeitsschritt. Hier wird gegebenenfalls
eine Normalisierung vorgenommen und es können Integritätsbedingungen
eingebracht werden.
Im letzten Arbeitsschritt wird der physische Datenbankentwurf vorgenommen. Hier werden Indizes angelegt und bestimmt, wie und wo die Daten
physisch gespeichert werden.
Dieser Abschnitt beschreibt die Ergebnisse des obigen Entwicklungsprozesses bezogen auf die vorliegende Problemstellung.
3.1
Anforderungsanalyse
Dieser Arbeitsschritt dient der Abgrenzung und Beschreibung des Problemraumes. Hier werden relevante Objekte und ihre Eigenschaften identifiziert
16
3.1. ANFORDERUNGSANALYSE
17
und anschließend Beziehungen zwischen diesen Objekten ermittelt. Größtenteils unterstützt der GDF-Standard die Analysephase, da dort bereits Entities, Attribute und Beziehungen definiert werden. Die Haupttätigkeit in
dieser Phase besteht also im Identifizieren zusätzlich notwendiger Entities,
Attribute und Beziehungen. Eine weitere wichtige Tätigkeit ist das Bestimmen der Transaktionen und Operationen, die auf der Datenbank (besonders
effizient) ausgeführt werden sollen. Andere Aufgaben sind das Festlegen von
Systemeigenschaften wie Performanz, Sicherheit oder die Spezifikation von
Hard- und Software, da diese Erkenntnisse teilweise Einfluss auf das Datenbankmodell haben.
Software und Hardware
In diesem Teil werden nun die Entscheidungen bezüglich Hard- und Software
vorgestellt und begründet. Dabei wird auch auf mögliche Alternativen eingegangen. Inbesondere geht es hier um die Möglichkeiten zur Speicherung und
Verwaltung der räumlichen Objekte.
Als DBMS wird die Software DB2 Universal Database in der Version 7.11
eingesetzt, wobei die Plattform frei wählbar ist. Dieses erweiterbare objektrelationales DBMS erlaubt eine integrierte GIS-Architektur [Fla97].
Eine weitere Überlegung betrifft die Implementierung von Datentypen für
räumliche Objekte und von räumlicher“ Funktionalität, z. B. räumliche In”
dizes, Schnittberechnung von Flächen. Diese räumliche“ Funktionalität ist
”
notwendig, um vor allem die häufig auftretenden Bereichsanfragen in angemessener Zeit beantworten zu können. Als Bereichsanfragen werden Anfragen
der folgenden Art bezeichnet: Gib mir alle räumlichen Objekte, die in dem
durch die Punkte (x1 , y1 ) und (x2 , y2 ) gegebenen Rechteck (Bounding Box)
liegen! Die erste Möglichkeit ist, diese räumliche Funktionalität selbst zu
implementieren bzw. eine vorhandene Implementierung anzupassen. Hierfür
bietet sich zum Beispiel der in [Fla97] beschriebene Ansatz an, der Z-Werte2
für die Indizierung der räumlichen Objekte verwendet. Die räumlichen Datentypen und die dazugehörige Funktionalität wurden als benutzerdefinierte
Datentypen und Funktionen (User Defined Types/User Defined Functions3 )
realisiert. Alternativ lassen sich auch kommerzielle Produkte nutzen wie zum
Beispiel der DB2 Spatial Extender von IBM.
Für eine eigene bzw. die Anpassung einer vorhandenen Implementierung
spricht, dass die Datentypen und Funktionen sehr genau an die Bedürfnisse
adaptiert werden können. Dabei ist die Indizierung mit Hilfe der Z-Ordnung
1
kurz: DB2 UDB V7.1
In [Bar95] wird diese Indizierung auch als Peano-Ordnung oder N-Ordnung bezeichnet.
3
kurz: UDT/UDF
2
18
KAPITEL 3. ENTWICKLUNG DES DATENBANKSCHEMAS
relativ einfach zu realisieren und ist laut [Fla97] für einen schnellen Zugriff
auf räumliche Objekte durchaus geeignet. Dem entgegen steht der zusätzliche
Entwicklungsaufwand; zwar ist durch [Fla97] bereits ein Gerüst gegeben, aber
trotzdem ist eine Portierung von DB2 V5 auf DB2 UDB V7.1 notwendig,
um die neu integrierten objekt-orientierten Konzepte wie z. B. Vererbung
umfassend nutzen zu können.
Die Verwendung eines kommerziellen Produkts bietet zunächst einmal
einen größeren Funktionsumfang, so dass damit auch ein höheres Anfragepotential gegeben ist. Dieser umfasst neben den grundlegenden Operationen wie
z. B. Schnitt und Vereinigung auch weitergehende wie z. B. Transformation
der Koordinaten in andere Koordinatensysteme. Im Allgemeinen ist eine solche Erweiterung fehlerfreier und auch mehr an die entsprechende Datenbank
angepasst, z. B. Optimierung. Des Weiteren erleichtert eine entsprechende
Dokumentation mit Beispielen die Arbeit mit einer solchen Erweiterung. Auf
der anderen Seite kann eine Funktionenflut“ leicht vom eigentlichen Problem
”
ablenken und auch der Installationsaufwand sowie die Einarbeitung in eine
neue Software sind sicherlich nicht zu unterschätzen. Ein für die wirtschaftliche Nutzung wichtiger Punkt sind die dadurch entstehenden Zusatzkosten.
In Absprache mit Vivatech Software Berlin GmbH wurde entschieden, das
kommerzielle Produkt DB2 Spatial Extender von IBM zu benutzen. Somit
steht zunächst der Entwurf des Datenbankschemas und das Einlesen der
GDF-Daten in die Datenbank im Vordergrund.
Diese Entscheidung schränkt gleichzeitig die Auswahl der verwendbaren
Plattformen ein, da es zur Zeit den DB2 Spatial Extender nur für die Plattformen AIX und Windows 2000 gibt.
Zusätzliche Entity-Typen, Attribute und Beziehungen
In diesem Abschnitt wird untersucht, inwieweit das allgemeine Referenzmodell aus dem GDF-Standard zu verändern bzw. zu ergänzen ist, um ein die
Anforderungen erfüllendes Modell zu erhalten. Dazu werden dem allgemeinen
Referenzmodell neue Entity-Typen, Attribute und semantische Beziehungen
hinzugefügt.
Der Entity-Typ Name wurde zu den bereits im GDF-Standard definierten hinzugenommen. Im GDF-Standard werden diese zusammen mit anderen
Eigenschaften eines Features verwaltet, d.h., sie werden mit dem Entity-Typ
Attribut identifiziert. Die Namen unterscheiden sich jedoch von den norma”
len“ Eigenschaften dahingehend, dass hier nicht nur Code-Wert-Paare auftreten, sondern außerdem auch die jeweilige Sprache gespeichert wird (vgl.
Abb. 3.2). Ein weiterer Grund für die Extraktion der Namen ist, dass diese
eine zentrale Rolle in späteren Anwendungen spielen. Nahezu jedes Feature
3.2. KONZEPTIONELLER DATENBANKENTWURF
19
besitzt einen oder mehrere Namen, die als ein wichtiges Erkennungsmerkmal
eines geographischen Objektes auf einer Karte häufig dargestellt werden.
Ein weiterer hinzugefügter Entity-Typ ist Sektion. Die hier verwalteten
Informationen wie Offsets und Faktoren sind für die Interpretation der Koordinaten wesentlich. Dieser Entity-Typ dient später auch der Einschränkung
des Suchraumes — dieses wird in Abschnitt 3.3 näher ausgeführt. Metadaten
über die GDF-Datei wie Erstellungsdatum, Hersteller usw. werden schließlich
in dem Entity-Typ Volume zusammengefasst.
Weitere Entity-Typen für zusätzliche Metainformationen müssen gegebenenfalls noch ergänzt werden.
3.2
Konzeptioneller Datenbankentwurf
Im Folgenden werden die oben zusammengestellten Anforderungen in einem
Entity Relationship4 Schema visualisiert. Das so entstandene Datenschema
dient der Überprüfung auf Richtigkeit und Vollständigkeit. Insbesondere erleichtert so eine kompakte Visualisierung der Anforderungen die Kommunikation mit dem Auftraggeber.
In einem Vektormodell, wie es in diesem Fall vorliegt, sind die Basisobjekte Knoten, Linien(züge) und Flächen. Für die Verwaltung dieser Objekte
existieren bereits unterschiedliche Basisarchitekturen. Zwei davon sind die
Spaghetti- und die topologische Struktur.
Die Spaghetti-Struktur zeichnet sich durch die voneinander unabhängige
Verwaltung der Basisobjekte aus. So werden Knoten als Koordinatenpaar,
Linien und Flächen als Koordinatenpaarliste abgespeichert. Dies bedeutet,
dass unter Umständen Koordinatenpaare mehrfach abgespeichert werden.
Dadurch können bei späteren Aktualisierungen der Daten Inkonsistenzen
entstehen.
Die topologische Struktur wahrt auf Grund der Speicherung der Koordinaten die topologische Integrität der Daten. So wird eine Linie aus Anfangsund Endknoten sowie einer Menge von Zwischenpunkten zusammengesetzt
und eine Fläche wird als eine Menge von Linien betrachtet.
Die Spaghetti-Struktur erlaubt primär einen schnellen Zugriff auf die Daten, während die topologische Struktur vor allem qualitative Aspekte (Genauigkeit, Integrität) berücksichtigt. [Fla97][Con00]
Hauptsächlich sprechen zwei Gründe für die Verwendung der SpaghettiStruktur als Basismodell. Die zu erstellende Datenbank dient primär der
Beantwortung von Anfragen und bedingt dadurch die Forderung nach ei4
kurz: ER
20
KAPITEL 3. ENTWICKLUNG DES DATENBANKSCHEMAS
ner kurzen Antwortzeit. Der zweite Grund leitet sich teilweise aus der Verwendung des DB2 Spatial Extenders ab. Sicherlich ist die Realisierung einer topologischen Struktur auch mit dem DB2 Spatial Extender möglich,
jedoch lässt sich die zur Verfügung gestellte Funktionalität dann nur eingeschränkt oder umständlich nutzen. Die Tatsache, dass bei der Aktualisierung
der Daten in einer Spaghetti-Struktur Inkonsistenzen auftreten können, ist
vernachlässigbar, da die Koordinaten ausschließlich aus den GDF-Dateien
eingelesen werden.
In den Abbildungen 3.1 und 3.2 ist das entwickelte ER-Schema dargestellt. Die erste Abbildung charakterisiert die Zusammenhänge zwischen den
Entity-Typen, die hauptsächlich für die Visualisierung benötigt werden. Die
zweite Abbildung konzentriert sich auf die zu einem Feature gehörenden Eigenschaften.
Das Feature ist der Basistyp für komplexes Feature und simples Feature,
und die Spezialisierungen übernehmen somit den Schlüssel ’ID’. Während ein
komplexes Feature aus simplen oder wiederum aus komplexen Feature zusammengesetzt wird, untergliedert sich das simple Feature weiter in Punkt-,
Linienzug- und Gebiet-Feature. Diese letztendlich stellen über die Beziehungen repräsentiert durch zu den Entity-Typen Knoten, Linie bzw. Fläche die
entsprechenden Koordinaten zur Verfügung. Dabei besitzen die Beziehungen
repräsentiert durch von dem Entity-Typ Linienzug-Feature nach Linie bzw.
von Gebiet-Feature nach Fläche ein Attribut ’Reihenfolge’, das die Menge der
zu einem Linienzug-Feature gehörenden Linien bzw. der zu einem GebietFeature gehörenden Flächen ordnet.
Wie bereits erwähnt, bilden Knoten, Linien und Flächen häufig die Basistypen für Vektormodelle. Die Koordinaten werden dabei für den Knoten
durch ein einzelnes Wertepaar und für Linien und Flächen durch eine Wertepaarliste angegeben.
Im unteren Teil der Abbildung 3.1 sieht man die Beziehung begrenzt links
bzw. begrenzt rechts. Durch diese Beziehungen wird insofern die Topologie
der Karte berücksichtigt, als dadurch einer Linie die an sie angrenzenden
Flächen zugeordnet werden.
Im Mittelpunkt der Abbildung 3.2 steht das Feature mit seinen Eigenschaften. Zum einen ist der Entity-Typ Attribut zu erkennen, mit seinen
Eigenschaften ’ID’, ’Code’ und ’Wert’. Daneben sieht man den Entity-Typ
Namen als eine Spezialisierung mit der zusätzlichen Eigenschaft ’Sprache’.
Weitere wichtige Entity-Typen sind Feature-Klasse und Feature-Kategorie,
die zum einen eine Gruppierung der Feature in Klassen erlauben (vgl. Def.
2.2) und zum anderen die Einordnung in das Repräsentationsschema vornehmen (vgl. Def. 2.4). Die Zusammenhänge zwischen mehreren Feature werden
über die Beziehung beteiligt an zum Entity-Typen semantische Beziehung
3.2. KONZEPTIONELLER DATENBANKENTWURF
[ID]
M
komplexes
Feature
21
Feature
M
besteht
aus
N
N
simples
Feature
besteht
aus
Punkt
Feature
M
Linienzug
Feature
M
Gebiet
Feature
M
repräsent
durch
repräsent
durch
repräsent
durch
1
N
Knoten
N
Linie
[ID]
Fläche
[ID]
Punkt
Koordinate
[ID]
Linien
Koordinaten
Flächen
Koordinaten
M
begrenzt
links
1
M
begrenzt
rechts
1
Linie
Fläche
Abbildung 3.1: Datenbankschema (Teil 1)
22
KAPITEL 3. ENTWICKLUNG DES DATENBANKSCHEMAS
verwirklicht. Das Attribut ’Reihenfolge’ besagt, welche Stelle die Feature
in der semantischen Beziehung besetzen. Betrachtet man zum Beispiel die
Instanz überquert von dem Entity-Typ semantische Beziehung, so ist es wesentlich, ob nun ein Feature A ein Feature B überquert oder umgekehrt.
Code
Code
Text
Feature
Klasse
M
Text
dargest.
durch
1
Feature
gehört
zu
[ID]
M
Reihenfolge
M
beteiligt
an
M
besitzt
Feature
Kategorie
1
besteht
aus
M
N
N
Code
N
semantische
Beziehung
Attribut
Sprache
Wert
[ID]
Code
Name
Abbildung 3.2: Datenbankschema (Teil 2)
Zu Gunsten einer besseren Übersichtlichkeit wurde nicht dargestellt, dass
alle Entity-Typen bis auf Feature-Klasse und Feature-Kategorie in einer Beziehung gehört zu mit dem Entity-Typ Sektion partizipieren.
3.3
Logischer Datenbankentwurf
Nunmehr wird die Abbildung des soeben vorgestellten ER-Modells auf DB2
UDB V7.1 beschrieben. Es werden unterschiedliche Herangehensweisen und
anwendbare Konzepte (z. B. benutzerdefinierte Datentypen und Funktionen)
diskutiert.
3.3. LOGISCHER DATENBANKENTWURF
3.3.1
23
Strukturierung der Datenbank
Die Sprache SQL kennt das Konzept der Schemata, worunter eine benannte
Sammlung von Objekten, z. B. Tabellen und Sichten, verstanden wird. Gewissermaßen bildet ein Schema einen Namensraum und erleichtert somit die
Wahl von Objektnamen, da diese nur noch innerhalb eines Schemas eindeutig
sein müssen.[Cha99]
Das Konzept der Schemata wird hier dazu genutzt, um zum einen Metadaten einer GDF-Datei von übrigen Daten und zum anderen geographische Gebiete zu trennen. Letzteres meint, dass für jede Sektion in den GDFDateien, die jeweils mit einem geographischen Gebiet gleichzusetzen ist, ein
extra Schema angelegt wird. Diese Aufteilung ist in Abbildung 3.3 veranschaulicht, wobei die Rechtecke innerhalb der Datenbank die einzelnen Schemata für ein geographisches Gebiet symbolisieren. Daraus ergibt sich eine
erhebliche Verkleinerung des Suchraumes bei Bereichsanfragen. Zudem garantiert der GDF-Standard eindeutige Identifikatoren für Knoten, Linien,
Flächen usw. nur innerhalb einer Sektion. Bei einer Zusammenfassung von
Tabellen wird demzufolge ein größerer Primärschlüssel benötigt.
Datenbank
Meta−
daten
Berlin Bayern
(norden)
...
Abbildung 3.3: Aufteilung der Datenbank
Neben den Tabellen zur Umsetzung der Codes (z. B. Attribut-Code) in
lesbaren Text beinhalten die Metadaten eine Tabelle Sektion. In dieser Tabelle wird für jedes Schema die zugehörige Bounding Box gespeichert, so dass
eine Zuordnung von einem Anfragebereich zu den Schemata möglich ist.
3.3.2
Data Definition Language
Konzepte in DB2 UDB V7.1
In diesem Teil werden die möglichen Konzepte zum Anlegen von Tabellen in
DB2 untersucht und sich daraus ergebene Probleme aufgezeigt. Das am Ende
genutzte Konzept entscheidet auch darüber inwiefern diese Implementation
auf andere DBMS übertragbar ist.
24
KAPITEL 3. ENTWICKLUNG DES DATENBANKSCHEMAS
Als Data Definition Language (DDL) wird der Bereich des SQL-Standards
bezeichnet, der der Erzeugung von Objekten (Tabellen, Indizes, usw.) in der
Datenbank dient. Die Realisierung des Datenbankentwurfs auf Grundlage
von DB2 UDB V7.1 kann entweder objekt-relational oder rein“ relational
”
geschehen.
Objekt-relational bietet sich an, da in dem Datenbankentwurf die Spezialisierungshierarchie des Entity-Typs Feature von zentraler Bedeutung ist. Die
Definition der Tabellen spiegelt dann diese Hierarchie auch im DBMS wider.
Weiterhin ergeben sich Vorzüge beim Zugriff auf die aus diesen Entity-Typen
generierten Tabellen, da zum Beispiel bei einer Anfrage über alle Feature
nicht die Tabellen für komplexe Feature und simple Feature nacheinander
abgefragt werden müssen, sondern die Tupel aus beiden Tabellen bereits in
einer Tabelle Feature zusammengefasst sind. Auch ließen sich Methoden (benutzerdefinierte Funktionen) als integraler Bestandteil der Datentypen für
den Zugriff auf die einzelnen Tabellen implementieren.
Im Folgenden wird die prinzipielle Verwendung der objekt-relationalen
Konzepte des strukturierten Datentypen (structured type) und der typisierten Tabellen (typed table) skizziert.
Ein strukturierter Datentyp ist ein benutzerdefinierter Datentyp, der ein
oder mehrere Attribute enthält, die wiederum über Namen und Datentypen
verfügen. Ein strukturierter Datentyp wird mit der SQL-Anweisung CREATE
TYPE (vgl. [IBM00b]) erstellt. Zusätzlich können strukturierte Datentypen
von anderen strukturierten Datentypen abgeleitet werden oder um benutzerdefinierte Methoden — Funktionalität — erweitert werden, die sozusagen
das Verhalten dieses Datentyps definieren. Darauf soll aber nicht weiter eingegangen werden.
Die folgenden beiden SQL-Anweisungen erzeugen zwei strukturierte Datentypen mit den Bezeichnungen st feature5 und st komplex feature. Letzterer
basiert auf st feature.
CREATE TYPE st feature
AS (id INTEGER)
NOT FINAL MODE DB2SQL
CREATE TYPE st komplex feature
UNDER feature
MODE DB2SQL
Ein strukturierter Typ kann als Typ für eine Tabelle — sogenannte typisierte Tabellen (typed tables) — dienen, in der jede Tabellenspalte ihren
Namen und Datentyp aus einem der Attribute des strukturierten Typs ableitet. Dazu dient die SQL-Anweisung CREATE TABLE (vgl. [IBM00b]), wo5
st steht für structured type
3.3. LOGISCHER DATENBANKENTWURF
25
bei jedoch nicht die Spaltennamen und -typen angegeben werden, sondern
die Bezeichnung eines strukturierten Datentyps. Es ist möglich eine Hierarchie von Tabellen aufzubauen, wobei in der Wurzeltabelle durch REF IS
oid USER GENERATED eine zusätzliche Spalte für einen Objektidentifikator
erzeugt wird. Dieser Objektidentifikator identifiziert jedes Tupel eindeutig in
einer Hierarchie. Für eine Hierarchie gilt, dass in Kindertabellen eingefügte
Tupel auch in der Vatertabelle sichtbar sind.
Die untenstehenden Anweisungen erzeugen zwei Tabellen basierend auf
den Datentypen st feature und st komplex feature.
CREATE TABLE feature
OF st feature
REF IS oid USER GENERATED
CREATE TABLE komplex feature
OF st komplex feature
UNDER feature INHERIT SELECT PRIVILEGES
Jedoch wird nicht jede derart aufgebaute Hierarchie von DB2 akzeptiert.
Die Ursache dafür liegt in der Verwaltung der typisierten Tabellen durch
DB2; vermutlich werden nur die Attribute als Spalte einer Tabelle umgesetzt,
die nicht geerbt wurden. Besitzt der abgeleitete strukturierte Datentyp keine
zusätzlichen Attribute, so entstehen nicht erlaubte Tabellen ohne Spalten.
Entscheidend für das Aufbauen einer Hierarchie ist also, dass die abgeleiteten
strukturierten Datentypen mindestens ein Attribut mehr besitzen ( echte“
”
Spezialisierung).
Die obigen Tabellendefinitionen werden also von DB2 mit einer Fehlermeldung zurückgewiesen, da st komplex feature kein zusätzliches Attribut definiert6 .
Da es sich also bei der im Datenbankentwurf aufgebauten Hierarchie nicht
um eine echte“ Spezialisierung handelt, ist eine Generierung der Tabel”
len mit Hilfe der objekt-relationalen Erweiterung von DB2 nicht möglich.
Deshalb wird für die Erzeugung der Tabellen hauptsächlich auf die objektrelationale Erweiterung verzichtet. Ein sich daraus ergebender Vorteil besteht
in der besseren Übertragbarkeit der SQL-Anweisungen auf andere DBMS.
Datentypen
Im Folgenden wird beschrieben, warum und wie das Konzept des einigartigen
Datentyps in die Realisierung des Datenbankentwurfs integriert wird. Dazu
werden auch ein paar Hinweise für die einfache Benutzung benutzerdefinierter
6
Die beiden CREATE TYPE-Anweisungen sind aber erlaubt.
26
KAPITEL 3. ENTWICKLUNG DES DATENBANKSCHEMAS
Datentypen gegeben. Des Weiteren werden die Datentypen des DB2 Spatial Extenders vorgestellt und deren Anwendung in dem Datenbankentwurf
verdeutlicht.
Soweit möglich wurden einzigartige Datentypen (distinct types) eingesetzt, die ihrerseits auf Basisdatentypen von DB2 (z. B. INTEGER, VARCHAR)
aufbauen. Einzigartige Datentypen garantieren vor allem Typsicherheit bei
Anfragen [Cha99]. Dies bedeutet, dass zum Beispiel der Vergleich zwischen
dem Code eines Features und dem Code eines Attributs in einer Anfrage
durch die Datenbank mit einem Fehler abgelehnt wird, falls die Codes jeweils
als einzigartige Typen implementiert sind. Es lassen sich auch die auf einen
Datentyp anwendbaren Operationen einschränken oder erweitern. Zusätzlich sind globale Veränderungen des Datentyps einer Spalte, z. B. die ID soll
BIGINT anstatt INTEGER sein, nur an einer zentralen Stelle vorzunehmen.
Die einzigartigen Datentypen können im Allgemeinen überall dort eingesetzt
werden, wo auch Basisdatentypen stehen können.
In Tabelle 3.1 sind die verwendeten einzigartigen Datentypen, deren Basisdatentypen und Einsatz aufgelistet (vgl. Anhang B.1). Jeder logische Rekord in einer GDF-Datei ist durch eine ID gekennzeichnet (vgl. Absatz 2.2.1)
— dieser Wert wird in Spalten vom Type dt id gespeichert. Für die jeweiligen Kodierungen wie in den Definitionen 2.2, 2.4 und 2.6 ist ein separater
Datentyp vorgesehen. Weiterhin existieren einzigartige Datentypen für den
Text von Namen und den Werten von Attributen. Mit Sprachencode sind
die MARC Sprachencodes für europäische Sprachen gemeint, die für die Spezifizierung der Sprache von Namen benutzt wird. Die Übersetzungstabellen
dienen der Umwandlung von Kodierungen in lesbaren Text; der lesbare Text
wird mit dem Datentyp dt description dargestellt.
einzig. Datentyp
dt id
dt featureKlasse
dt featureKategorie
dt relationshipCode
dt
dt
dt
dt
dt
attributeCode
attributeValue
nameValue
languageCode
description
Basistyp
BIGINT
SMALLINT
SMALLINT
SMALLINT
Anwendung
IDs der Datensätze
Kodierung der Feature-Klasse
Kodierung der Feature-Kategorie
Kodierung des Typs der semantischen Beziehung
CHAR(2)
Kodierung des Attributtyp
VARCHAR(100) Attributwert
VARCHAR(100) Feature-Name
CHAR(3)
Sprachencode
VARCHAR(255) Text in den Übertragungstabellen: Code ↔ lesbarer Text
Tabelle 3.1: Definierte eizigartige Datentypen
3.3. LOGISCHER DATENBANKENTWURF
27
Grundsätzlich werden alle einzigartigen Datentypen im zentralen Schema
Meta generiert. Zur Erzeugung eines einzigartigen Datentyps benutzt man die
CREATE DISTINCT TYPE-Anweisung (vgl. [IBM00b]). Die folgende Anweisung
erzeugt zum Beispiel den Datentyp dt id im Schema meta.
CREATE DISTINCT TYPE meta.dt id AS BIGINT WITH COMPARISONS
Gleichzeitig werden durch DB2 selbst Konvertierungsfunktionen von und
nach dem Basisdatentyp sowie Vergleichsoperatoren für den neuen Datentyp
(=, <>, <, <=, >, >=) generiert. Die von DB2 generierten Konvertierungsfunktionen und Vergleichsoperatoren werden in dem Schema abgelegt, in dem
auch der einzigartige Datentyp erzeugt wurde. Damit nun die neuen einzigartigen Datentypen in gewohnter Form genutzt werden können, muss darauf
geachtet werden, dass dieses Schema auch im Suchpfad (CURRENT FUNCTION
PATH) für die Funktionen liegt. Als Default benutzt DB2 die Systempfade
SYSIBM und SYSFUN sowie das Schema des angemeldeten Nutzers. Das
Kommando
SET PATH = CURRENT PATH, meta
fügt entsprechend dem obigen Beispiel das Schema meta dem aktuellen Pfad
hinzu.
Wie bereits in Abschnitt 3.1 beschrieben, wird zur Verwaltung der räumlichen Daten der DB2 Spatial Extender eingesetzt. Dieser erweitert DB2 um
strukturierte Datentypen für die Speicherung von Koordinaten und darauf
arbeitenden Funktionen.
Die Abbildung 3.4 zeigt die Hierarchie der strukturierten Datentypen,
die durch den DB2 Spatial Extender zur Verfügung gestellt werden. Die
grau unterlegten Datentypen sind nicht instanziierbar, d.h. es kann keine
Instanz erzeugt, keine typisierte Tabelle angelegt und, wenn eine Spalte in
einer Tabelle mit diesem Typ angelegt wurde, so können nur NULL-Werte
oder Instanzen von Subtypen eingefügt werden. In der Abbildung sind die Datentypen nicht dargestellt, die mehrere Punkte (ST MultiPoint), Linienzüge
(ST MultiLineString) oder Polygone (ST MultiPolygon) enthalten können.
In dem Datenbankschema wird für Knoten der Datentyp ST Point, für
Linien ST LineString und für Flächen ST Polygon verwendet.
Tabellen
Die SQL-Anweisungen für die Erzeugung von Tabellen können auf unterschiedliche Weise an DB2 übergeben werden. Die einfachste Variante ist
28
KAPITEL 3. ENTWICKLUNG DES DATENBANKSCHEMAS
ST_Geometry
ST_Point
ST_Curve
ST_Surface
ST_LineString
ST_Polygon
Abbildung 3.4: Datentypen des Spatial Extender (Ausschnitt) [IBM00a]
die manuelle Eingabe der Anweisung am Prompt des DB2-Kommandozeileninterpreters, die offensichtlich als nicht geeignet ausscheidet. Als annähernd gleichwertig sind die Möglichkeiten des SQL-Skripts und der gespeicherten Datenbankprozedur (stored procedure) zu betrachten und werden in
den folgenden Absätzen diskutiert.
Gespeicherte Datenbankprozeduren zeichnen sich dadurch aus, dass diese
in der Datenbank verwaltet werden und somit im gewissen Sinn datenbankweit7 abrufbar sind. Daraus ergibt sich jedoch auch ein aufwändigeres Verfahren für Anpassungen und Korrekturen. Gegen diese Variante spricht auch
eine kompliziertere Ausführung der gespeicherten Datenbankprozeduren, insbesondere zu Testzwecken. Gespeicherte Datenbankprozeduren werden mittels CALL aufgerufen, das jedoch nur aus Applikationen heraus aufgerufen
werden kann [IBM00b].
Die abzuarbeitenden SQL-Anweisungen sind bei einem Skript in einer
Textdatei gespeichert, die dem Kommandozeileninterpreter zur Auswertung
übergeben wird. Für diese Variante sprechen insbesondere die einfache Handhabbarkeit und Korrektur bzw. Veränderung des Skripts. Weiterhin ist ein
Wechsel des DBMS einfacher durchführbar. Nachteilig wirkt sich dagegen
die Speicherung der Skripte außerhalb der Datenbank aus, d.h., sie könnten
verlegt“ werden.
”
Letztendlich steht die Skript-Variante im Vordergrund der Betrachtungen. Die benötigten Tabellen werden in Metadatentabellen und reine“ Da”
tentabellen unterschieden. Da die Erzeugung dieser Tabellen unterschiedlich
gehandhabt werden muss, ist eine Differenzierung notwendig.
Metadaten werden stets im Schema meta abgespeichert und somit werden
7
Überall, wo die Datenbank zugreifbar ist, sind auch die gespeicherten Prozeduren
verfügbar.
3.4. PHYSISCHER DATENBANKENTWURF
29
auch die dazugehörigen Tabellen dort angelegt. Das heißt, hierfür können einfache Skripte zur Erzeugung der Tabellen eingesetzt werden. Zum Anlegen
von Tabellen wird die CREATE TABLE-Anweisung (vgl. [IBM00b]) verwendet.
Der Aufbau der Metadatentabellen kann im Anhang B.2.1 nachgelesen werden.
In diesem Beispiel wird die Tabelle languageCode im Schema meta mit
zwei Spalten (languageCode, description) angelegt. Der Schlüssel der Tabelle
ist die Spalte languageCode, der über den Objektnamen languageCode pk
angesprochen werden kann.
CREATE TABLE meta.languageCode (
languageCode meta.dt languageCode NOT NULL,
description meta.dt description NOT NULL,
CONSTRAINT languageCode pk
PRIMARY KEY (languageCode) )
Im vorgestellten Datenbankentwurf werden die geographischen Regionen
in ein jeweils separates Schema gespeichert. Daraus folgt, dass auch in den
Skripten zur Erzeugung der Datentabellen der Schemaname dynamisch eingesetzt werden muss. Dazu wird anstelle des Schemanamen das Token ’ ?’
benutzt, das zur Laufzeit durch einen übergebenen Schemanamen substituiert wird (s. Abschnitt 4.5). Das Token ist gut geeignet, da es bei DB2
für Applikationen vorbehalten ist und in SQL-Anweisungen nicht vorkommt.
Ansonsten unterscheiden sich die CREATE TABLE Anweisungen nicht von den
oben vorgestellten — die Definitionen dieser Tabellen befinden sich im Anhang B.2.2.
3.4
Physischer Datenbankentwurf
Folgender Abschnitt untersucht die physische Speicherung der Tabellen bzw.
der darin enthaltenen Daten. Es werden einige der in DB2 zur Verfügung
gestellten Methoden für die physische Verteilung der Daten diskutiert. Des
Weiteren wird die Indizierung der räumlichen Daten betrachtet.
3.4.1
Tabellenbereiche und Pufferpools
Wie die physische Speicherung von Tabellen in DB2 UDB V7.1 gehandhabt
wird und was dabei zu beachten ist, wird in diesem Abschnitt vorgestellt.
Dieses Wissen erweitert die Möglichkeiten zum Optimieren des Zugriffs auf
die Daten in einer Datenbank.
Die Daten in den Tabellen werden in der Datenbank in sogenannten Tabellenbereichen (table spaces) gespeichert und verwaltet. Bei der Erstellung
30
KAPITEL 3. ENTWICKLUNG DES DATENBANKSCHEMAS
von Tabellen kann unter anderem auch der zu benutzende Tabellenbereich
angegeben werden. Die Tabellenbereiche wiederum werden in Behältern (i.A.
Dateien) abgelegt. Dabei werden drei verschiedene Typen unterschieden:
regular für Benutzerdaten und Datenbankobjekte
temporary für die Speicherung globaler temporärer Tabellen
long für sehr lange Zeichenfolgen oder lange Objekte (LOB)
Ein weiteres Unterscheidungsmerkmal besteht in der Verwaltung der Tabellenbereiche: systemverwaltet (managed by system), datenbankverwaltet
(managed by database). Ersteres bedeutet, dass die Alloziierung von Sekundärspeicher von DB2 selbst organisiert wird — es wird nur so viel Speicher benutzt, wie benötigt wird. Nachteilig ist, dass das Hinzufügen neuer
Behälter, z. B. wenn der Festplattenplatz nicht mehr ausreicht, im Allgemeinen nicht möglich ist.
Wenn Tabellenbereiche datenbankverwaltet eingerichtet wurden, so liegt
die Verantwortung der Speicherverwaltung beim Datenbankadministrator.
Dieser muss dafür sorgen, dass stets genügend Sekundärspeicherplatz in den
Behältern vorhanden ist. Dabei wird der Speicher vorher dem System bereitgestellt — auch wenn eigentlich nicht so viel benötigt wird — und steht
damit anderen Anwendungen nicht mehr zur Verfügung. Dennoch gibt es für
die hier vorgesehene Anwendung klare Vorteile gegenüber systemverwalteten Tabellenbereichen. Es können neue Behälter dem Tabellenbereich hinzugefügt werden, wonach zur Erhöhung der E/A-Effizienz die vorhandenen
Daten gleichmäßig auf alle Behälter verteilt werden. Eine Tabelle kann nach
dem Typ der zu speichernden Daten (Langfeld/LOB, Indizes, reguläre Tabellendaten) auf mehrere Tabellenbereiche verteilt werden. Da der Speicher
vorher alloziiert wird, steht dieser zusammenhängend (nicht fragmentiert)
auf dem Sekundärspeicher zur Verfügung.[IBM00b]
Ein anderes Konzept, das in Datenbanken genutzt wird, ist die Verwendung von Pufferpools (bufferpool). Ein Pufferpool bezeichnet einen Teil des
Hauptspeichers, der dem schnellen Zugriff der von einem Datenträger gelesenen Daten oder dem Zwischenspeichern von geänderten Tabellen- und
Indexdatenseiten dienen. Dabei ist die vom Pufferpool verwendete Seitengröße ausschlaggebend dafür, wie lang eine im Pufferpool gespeicherte Zeile
sein darf, da eine Zeile sich nicht über mehrere Seiten erstrecken kann.
Standardmäßig wird eine Seitengröße von 4 kB verwendet. Es zeigt sich
jedoch, dass diese Größe für komplexere Anfragen, die den DB2 Spatial Extender benutzen, nicht ausreichend ist — solche Anfragen werden mit einer
3.4. PHYSISCHER DATENBANKENTWURF
31
Fehlermeldung abgebrochen. Deshalb ist es ratsam, die Koordinaten enthaltenden Tabellen in einem Tabellenbereich mit größeren Seiten anzulegen. Dabei ist zu beachten, dass zu Tabellenbereichen mit einer bestimmten
Seitengröße mindestens ein Pufferpool mit derselben Seitengröße existieren
muss. Eine Seitengröße von 4 kB erlaubt Tabellen mit maximal 500 Spalten.
Dahingegen sind bei einer Seitengröße von 8 kB, 16 kB und 32 kB maximal 1012 Spalten möglich. Die Seitengröße bestimmt auch den maximalen
Umfang eines Tabellenbereiches.
Pufferpools und Tabellenbereiche mit großen Seiten können auch nachteilige Auswirkungen auf das Gesamtsystem haben. Da auf einer Seite maximal
255 Zeilen gespeichert werden, bleibt bei Tabellen mit kurzen Zeilenlängen
(= Summe der Spaltenlängen) ein erheblicher Teil der Seite ungenutzt. Auch
leidet in bestimmten Anwendungsgebieten (z. B. OLTP) die Performanz, da
zusätzlich zu den gewollten auch nicht benötigte Daten ausgelesen werden
und im Pufferpool zwischengespeichert werden.
Bei der Verwendung von Pufferpools und Tabellenbereichen mit anderen
Seitengrößen als 4 kB muss auch ein entsprechender temporärer Tabellenbereich angelegt werden, da sonst SQL-Anfragen, die das Zwischenspeichern
von Daten erfordern, nicht abgearbeitet werden können.
Die untenstehenden Anweisungen erzeugen zunächst einen Pufferpool mit
einer Seitengröße von 32 kByte und einem Umfang von 250 Seiten. Darauf
aufbauend wird ein Tabellenbereich in dem Behälter C:\DB2\largets.000
angelegt. Nähere Informationen zu den SQL-Anweisungen findet man in
[IBM00b].
CREATE BUFFERPOOL largeBP SIZE 250 PAGESIZE 32K
CREATE TABLESPACE largeTS PAGESIZE 32K
MANAGED BY SYSTEM USING (’C:\DB2\largets.000’)
BUFFERPOOL largeBP
3.4.2
Räumlicher Index
Für den schnellen Zugriff auf räumliche Daten benötigt man einen Index,
der in kurzer Zeit die in einem vorgegebenen Bereich liegenden räumlichen
Objekte identifiziert. Der von DB2 UDB V7.1 verwendete Indizierungsmechanismus (B-Baum) ist für die Indizierung mehrdimensionaler Daten nicht
geeignet, da dieser nur eindimensionale Daten verarbeiten kann. Daher ist
es notwendig, spezielle räumliche Indizierungsverfahren zu verwenden. Der
DB2 Spatial Extender bietet einen dreistufigen auf einem Gitter basierenden
Index (grid index). Dieser Abschnitt erklärt kurz die Funktionsweise und
Erzeugung eines solchen Indizes.
32
KAPITEL 3. ENTWICKLUNG DES DATENBANKSCHEMAS
Die Koordinaten der räumliche Objekte werden nicht selbst in den Index
eingetragen, sondern zunächst wird das kleinste umschreibende Rechteck (envelope, minimum bounding rectangle8 , bounding box9 ) gebildet. Das MBR
ist selbst wieder ein räumliches Objekt, das die maximale Ausdehnung in xbzw. y-Richtung des zugrundeliegenden Objekts repräsentiert. In den meisten Fällen — ao auch beim DB2 Spatial Extender — handelt es sich dabei
um ein Rechteck.
Für Überschneidungen des so gebildeten MBR und des Gitters werden
nun Einträge im Index vorgenommen. Der Eintrag besteht aus der minimalen x- und y-Koordinate der geschnittenen Gitterzelle. Die Abbildung 3.5
demonstriert die Vorgehensweise. Das Polygon schneidet demnach die Gitterzellen mit den Koordinaten (10, 10), (20, 10), (10, 20), (20, 20), (10, 30)
und (20, 30).
50.0
40.0
30.0
20.0
10.0
0.0
10.0
20.0
30.0
40.0
50.0
Abbildung 3.5: Gitterindex mit einem Level von 10.0
Die Dreistufigkeit ergibt sich dadurch, dass sich insgesamt (maximal) drei
unterschiedliche (ansteigende) Gittergrößen definieren lassen. Dabei wird die
Indizierung mit der niedrigsten Gittergröße begonnen. Wenn das räumliche
Objekt mehr als vier Gitterzellen auf diesem Level überschneidet, so wird
das nächsthöhere Level zur Indizierung probiert, usw. Ist das höchste Level
8
9
kurz: MBR
kurz: BB
3.4. PHYSISCHER DATENBANKENTWURF
33
erreicht, so werden alle Schnitte in den Index eingetragen, unabhängig von
der Anzahl.
Die jeweiligen Gittergrößen werden beim Erzeugen des Indizes durch die
Anweisung CREATE INDEX mit angegeben. Die folgende Anweisung erzeugt
einen räumlichen Index für die Spalte ’Koordinate’ mit Gittergrößen 10, 100
und 1000.
CREATE INDEX point idx ON Point (Koordinate)
EXTEND USING db2gse.spatial index (10e0, 100e0, 1000e0)
Die Auswahl der in Frage kommenden Tupel mittels eines räumlicher Indizes geschieht bei fast allen Funktionen des DB2 Spatial Extenders in drei
Phasen. Zuerst werden alle Einträge im Index ermittelt, die eine größergleiche linke obere Koordinate und eine kleinergleiche rechte untere Koordinate
als die Anfragebox haben. Anschließend wird geprüft, ob das MBR der ermittelten Objekte die Anfragebox schneidet. Zuletzt erfolgt dann der Vergleich
mit den tatsächlichen Koordinaten der Objekte. Da der letzte Vergleich sehr
aufwändig ist, ist eine signifikante Reduzierung der möglichen Kandidaten
besonders wichtig. [IBM00a]
Um eine hohe Selektion durch den Index zu erreichen, müssen die Gittergrößen und die Anzahl der Level (Stufen) passend gewählt werden. Leider
gibt es keine Regeln, wie diese bestimmt werden, vielmehr kommt es dabei
auf Erfahrung und Kenntnis über die Beschaffenheit der zu indizierenden
räumlichen Objekte an. Insgesamt gesehen, bildet allein das Probieren unterschiedlicher Gittergrößen ein Mittel zur Verbesserung der Performanz.
Kapitel 4
Einlesen einer GDF-Datei in
die Datenbank
Dieses Kapitel befasst sich mit der Übertragung der Daten aus einer GDFDatei in die Datenbank. Die Datenbank muss für den Einsatz des DB2 Spatial
Extenders vorbereitet werden, um darin auf die räumlichen Datentypen und
Funktionalitäten zurückgreifen zu können. Erst jetzt ist das Anlegen aller
benötigten Tabellen möglich. Da die Datenbank im Allgemeinen keinen Filter für GDF-Dateien mitliefern, muss dieser selbst implementiert werden.
Für den Transfer der Daten in eine Datenbank sind unterschiedliche Ansätze
denkbar, die im zweiten Abschnitt erläutert werden. Die eigentliche Realisierung des Programms zur Verarbeitung der GDF-Dateien wird anschließend
vorgestellt. Dabei erfordert insbesondere die Übertragung der Koordinaten
in die Datenbank eine gesonderte Betrachtung, da diese dem DB2 Spatial Extender übergeben werden. An dieser Stelle werden einige Kodierungsformate
für räumliche Objekte vorgestellt, die zum Transfer verwendet werden.
4.1
Vorbereiten der Datenbank
Dieser Abschnitt fasst die vorbereitenden Maßnahmen für die Nutzung des
DB2 Spatial Extenders unter DB2 UDB V7.1 zusammen. Um nun die kartographischen Daten in die Datenbank einzulesen, werden zunächst die Metadatentabellen angelegt und anschließend bereits mit Daten gefüllt. Wie
hierbei vorgegangen wird, ist am Ende des Abschnitts beschrieben.
Bevor in einer Datenbank der DB2 Spatial Extender (vgl. Abschnitt 3.1)
verwendet werden kann, muss das System dafür konfiguriert werden — einige
Systemvariable müssen gesetzt werden. Anschließend muss der DB2 Spatial
Extender für die Datenbank registriert werden, um dessen Ressourcen nutzen
34
4.1. VORBEREITEN DER DATENBANK
35
zu können.
Innerhalb DB2 werden global auf das gesamte DBMS und lokal bezüglich
einer Datenbank wirkende Systemvariablen unterschieden. Für die Veränderung einer global wirkenden Systemvariablen stellt DB2 das Kommando
UPDATE DATABASE MANAGER CONFIGURATION1 bereit. Analog dazu existiert
das Kommando UPDATE DATABASE CONFIGURATION2 zur Anpassung der lokal wirkenden Systemvariablen.
Die Tabelle 4.1 enthält für die Systemvariablen die entsprechenden (minimalen) Werte. Die Variable UDF MEM SZ wirkt sich auf die Größe des Speichers aus, den sich benutzerdefinierte Funktionen und der Datenbankprozess
zur Datenübertragung teilen. Die für eine Applikation verfügbare Heapgröße
wird als Anzahl von 4 kB Seiten durch APPLHEAPSZ festgelegt. Die Größe der
für die Wiederherstellung von Daten (data recovery) verwendeter Transaktionslogdateien bestimmt LOGFILSIZ (4 kB Seiten). Die Anzahl der primären
Logdatei speichert die Variable LOGPRIMARY.
Systemvariable Wert Wirkung
UDF MEM SZ
2048
global
APPLHEAPSZ
512
lokal
LOGFILSIZ
2000
lokal
LOGPRIMARY
5
lokal
Tabelle 4.1: Werte für die Systemvariablen
Erst nachdem diese Systemvariablen gesetzt worden sind, kann der DB2
Spatial Extender für eine Datenbank aktiviert (enable) werden. Hierdurch
werden Ressourcen in die Datenbank transferiert, die erst den Einsatz der
räumlichen Datentypen und Funktionen gestatten. Alle Ressourcen werden
in dem Schema db2gse eingerichtet und sind durch Anpassung der Variablen
CURRENT FUNCTION PATH oder durch explizite Namensqualifizierung (z. B.
db2gse.st asText()) anschließend nutzbar.
Der DB2 Spatial Extender stellt hierfür eine gespeicherte Datenbankprozedur namens gse enable db() bereit. Wie bereits weiter oben erwähnt,
werden gespeicherte Datenbankprozeduren nur mittels CALL aus Applikationen heraus aufgerufen. Um diese Funktion dennoch aus einem Skript heraus aufrufen zu können, entstand ein Programm, das nichts weiter als diese
gespeicherte Datenbankprozedur aufruft. Als Parameter erwartet das Programm einen Datenbankalias, einen Benutzernamen und ein Passwort; diese
Informationen werden für den Aufbau einer Datenbankverbindung benötigt.
1
2
kurz: UPDATE DBM CFG
kurz: UPDATE DB CFG
36 KAPITEL 4. EINLESEN EINER GDF-DATEI IN DIE DATENBANK
Im weiteren Verlauf der Datenbankvorbereitung werden benötigte Pufferpools und Tabellenbereiche angelegt, gespeicherte Datenbankprozeduren,
einzigartige Datentypen sowie die Metadatentabellen erzeugt.
Die SQL-Anweisungen für die Erzeugung der einzigartigen Datentypen
und der Metadatentabellen stehen jeweils in einem SQL-Skript, die nacheinander3 ausgeführt werden (vgl. hierzu Anhänge B.1 und B.2.1).
Ein großer Teil der Metadaten sind unabhängig von der jeweiligen GDFDatei, da sie bereits im GDF-Standard festgelegt sind. Vor allem betrifft dies
die Übersetzungstabellen, die Kodierungen in lesbaren Text transformieren.
Diese Daten wurden extrahiert und in einer Trennzeichen separierten (delimited) ASCII-Datei (DEL-Datei) abgespeichert. Diese Dateien können nun
mit dem LOAD-Befehl von DB2 in die entsprechenden Tabellen eingelesen
werden.
Alle diese Vorgänge werden in einem Shell-Skript zusammengefasst, das
mit Hilfe der Abbildung 4.1 nachvollzogen werden kann. Der Übersichtlichkeithalber wurd das Skript etwas vereinfacht.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Programm prepareDB (DB-Alias, Nutzer, Passwort)
: returns Fehlercode
begin
# Phase 1
Erzeuge Datenbank DB-Alias;
Konfiguriere Systemumgebung lt. Tab. 4.1;
Erzeuge die Pufferpools;
Starte Datenbankmanager neu;
# Phase 2
Erzeuge die Tabellenbereiche;
Registriere DB2 Spatial Extender Resourcen;
# Phase 3
SQL-Skript: Erzeugung einzigartiger Datentypen;
SQL-Skript: Erzeugung Metadatentabellen;
Metadaten per LOAD einlesen;
end
Abbildung 4.1: Vorbereitung der Datenbank (vereinfacht)
Das Shell-Skript ist dazu in drei Phasen unterteilt, so dass die Startphase
3
Die einzigartigen Datentypen müssen zuerst erzeugt werden, da die Metadatentabellen
sowie die anderen Datentabellen davon abhängig sind.
4.2. KONZEPTE ZUM FÜLLEN VON DATENBANKTABELLEN
37
mittels Parameter bestimmt werden kann. In der ersten Phase wird eine Datenbank erzeugt und die Systemumgebung konfiguriert. Jetzt muss auch die
Erzeugung des Pufferpool erfolgen, damit diese in der nächsten Phase verwendet werden können. Danach wird der Datenbankmanager gestoppt und
wieder gestartet, damit die Änderungen wirksam werden. Die zweite Phase
befasst sich mit dem Erstellen der Tabellenbereiche. Weiterhin werden die
Ressourcen des DB2 Spatial Extenders mit dem Programm enableDB registriert. Danach wird die aufgebaute Datenbankverbindung getrennt, damit in
Phase drei die Tabellenbereiche verwendet werden können. Die letzte Phase
legt die einzigartigen Datentypen und die Metadatentabellen an, wobei die
Tabellen anschließend gefüllt werden. Bei auftretenden Fehlern während der
Ausführung reagiert das Skript mit einem Rückkehrcode ungleich Null.
4.2
Konzepte zum Füllen von Datenbanktabellen
Es sind unterschiedliche Wege denkbar, Daten in eine Datenbank einzuspielen, die sich jedoch in der Performanz zum Teil wesentlich unterscheiden.
Denkbare Alternativen sind:
• Übertragung der Daten aus einer Applikation heraus über eine direkte
Verbindung zur Datenbank
• Benutzen des IMPORT-Befehls, wobei die Daten aus Dateien im DELFormat ausgelesen werden
• Einlesen mittels der LOAD-Hilfsroutine, ebenfalls unter Verwendung von
Dateien im DEL-Format
In diesem Abschnitt werden diese drei Möglichkeiten miteinander verglichen,
wobei das Hauptaugenmerk auf der Geschwindigkeit liegt. Ein schnelles Einlesen ist erforderlich, da es sich hierbei um eine große Menge an Daten handelt, die in die Datenbank übertragen werden müssen. Offensichtlich ist es
entscheidend, ob hierfür Tage, Stunden oder Minuten benötigt werden.
Grundsätzlich lassen sich die Methoden zur Datenübertragung anhand
zweier Merkmale differenzieren. Zum einen ist kennzeichnend, ob die Daten
direkt aus einer Applikation heraus an die Datenbank eingegeben werden
oder indirekt über den Umweg einer DEL-Datei. Zum anderen ist wesentlich,
inwiefern während der Datenübertragung eine Integritätsprüfung stattfindet.
Die einfachste Methode ist die direkte Datenübertragung zu der Datenbank aus einer Applikation heraus mittels embedded SQL oder Call Level Interface (CLI) Programmierung. Hierbei wird in der Applikation eine
38 KAPITEL 4. EINLESEN EINER GDF-DATEI IN DIE DATENBANK
Verbindung zur Datenbank aufgebaut und darüber die Daten per INSERTAnweisungen in die jeweilige Tabelle eingefügt. Bei dieser Operation wird eine
vollständige Integritätsprüfung vorgenommen; das umfasst die Überprüfung
von eindeutigen Schlüsseln (unique key) wie z. B. dem Primärschlüsselwerten,
Fremdschlüsselbeziehungen (referential integrity) und sonstiger Bedingungen
(check constraint). In Folge dieser Überprüfungen ist diese Vorgehensweise
besonders langsam. Zusätzlich belastet die Bewegung der Daten im Hauptspeicher von der Applikation zum Datenbankprozess die Performanz.
Analog dazu funktioniert das Importieren von Daten aus DEL-Dateien
mittels des IMPORT-Befehls aus DB2. Anstatt die Daten direkt in die Datenbank zu schreiben, wird ein Umweg über DEL-Dateien begangen. Dieses Prinzip benutzt ebenfalls die INSERT-Anweisung, wodurch auch alle Integritätsbedingungen geprüft werden. Deshalb ist diese Vorgehensweise genauso performant wie die erste, benötigt aber wegen des Erzeugens der DEL-Dateien
einen Zwischenschritt. Das Prinzip ist in Abbildung 4.2 nachvollziehbar. Beim
Einlesen der GDF-Dateien muss jedoch keine Datenbankverbindung bestehen.
Programm
DEL−
Dateien
LOAD / IMPORT
GDF−
Datei
Daten−
bank
Abbildung 4.2: Datenfluss bei der Verwendung des IMPORT-Befehls oder des
LOAD-Hilfsprogramms
Die letzte Möglichkeit ist die Verwendung des LOAD-Hilfsprogramms.
Dabei liegen die Daten ebenfalls in DEL-Dateien vor, das Prinzip der Dateneingabe ist jedoch vollkommen anders. Die aus der DEL-Datei eingelesenen
Daten werden direkt auf Datenbankseiten abgebildet und anschließend in die
Datenbank geschrieben. Im Anschluss daran erfolgt eine Überprüfung der eindeutigen Schlüssel, wobei gegebenenfalls Uneindeutigkeiten durch Löschung
von Tupeln beseitigt werden. Weitere Überprüfungen finden nicht statt —
diese und davon abhängige Tabellen werden nur markiert (check pending
state). Der große Vorteil dieser Methode ist der enorme Performanzgewinn;
das LOAD-Hilfsprogramm ist um ein vielfaches (ca. Faktor 10) schneller.
4.3. VERARBEITUNG EINER GDF-DATEI
39
Dieser Vorgang benötigt aber exklusive Zugriffsrechte zu den Tabellenbereichen, in denen sich die Tabellen befinden, d.h., diese sind dann für andere
Nutzer in der Zeit nicht zugänglich.
Der große Geschwindigkeitsvorteil begründet die Entscheidung, zum Einlesen der Daten letztere Variante, das LOAD-Hilfsprogramm, zu verwenden.
Daraus folgt, dass das Programm zum Einlesen der GDF-Dateien DELDateien generiert, die in einer zweiten Phase per LOAD in die Datenbank
eingelesen werden. Den prinzipiellen Datenfluss sieht man in Abbildung 4.2.
4.3
Verarbeitung einer GDF-Datei
Der folgende Abschnitt stellt das Programm vor, mit der eine GDF-Datei
in für das LOAD-Hilfsprogramm verwendbare ASCII-Dateien transformiert
wird. Das Programm wurde in der Sprache C++ unter Verwendung der Standard Template Library (STL) geschrieben. Es besteht insgesamt aus zwei
Komponenten; die erste übernimmt dabei das Lesen der GDF-Datei und die
zweite extrahiert die Datenfelder aus den logischen Zeilen. Diese Unterteilung wird als nächstes beschrieben. Danach wird die Funktionsweise jeder
einzelnen Komponente eingehender erläutert.
4.3.1
Struktur
Das Werkzeug mit dem die GDF-Dateien verarbeitet werden, ist ein Programm, das zunächst die physische Zeilen (vgl. Abschnitt 2.2.2) in logische
umsetzt und anschließend daraus die benötigten Datenfelder ausliest. Die extrahierten Daten können dann in ein für das LOAD-Hilfsprogramm geeignetes
Format abgespeichert werden. In diesem Abschnitt werden die Komponenten
des Programms vorgestellt.
Das Programm besteht im Ganzen aus zwei Komponenten — einem Scanner und einem Parser. Der Scanner übernimmt dabei das Einlesen der GDFDatei und kombiniert physische Zeilen zu einer logischen (vgl. Abschnitt 2.2).
Der Parser extrahiert anhand der Rekorddefinitionen im GDF-Standard die
benötigten Daten aus der logischen Zeile und schreibt diese in die entsprechende Datei. Die Abbildung 4.3 ist eine Verfeinerung von Abbildung 4.2 und
zeigt schematisch diese Aufteilung.
Diese Trennung ist sinnvoll, da eine physische Zeile zusätzliche Zeichen
enthält, die die Interpretation behindern. Solche Zeichen sind zum Beispiel
Leerzeichen, die zum Auffüllen einer physischen Zeile benutzt werden, damit
ein einzelnes Datenfeld nicht auf zwei Zeilen verteilt wird (vgl. Abschnitt
2.2.2). Weitere nur in der physischen Zeile vorkommende Zeichen sind die
40 KAPITEL 4. EINLESEN EINER GDF-DATEI IN DIE DATENBANK
Programm
Scanner
log. Zeile
Parser
phys. Zeile
GDF−
Datei
DEL−
Dateien
Abbildung 4.3: Komponenten des Einleseprogramms
Nullen oder Einsen an der 80. Position (Fortsetzungmarke) und die zwei
Nullen, mit denen die Fortsetzung einer geteilten logischen Zeile eingeleitet
wird. Zum Parser hin sind diese Zeichen nicht sichtbar. Der Parser greift
zum Lesen von Datenfeldern über Methoden des Scanners auf die eingelesene
Zeile zu. Somit konzentriert sich das Wissen über die in einer logischen Zeile
gespeicherten Daten im Parser.
4.3.2
Funktionsweise des Scanners
In diesem Abschnitt geht es um die Scanner-Komponente des Programms
zum Verarbeiten von GDF-Dateien. Diese Komponente arbeitet direkt auf
den GDF-Dateien und unterhalb der Parser-Komponente. Zusammengefasst
bildet diese Komponente die Schnittstelle zu den logischen Zeilen einer GDFDatei.
Der Scanner besitzt zum einen eine Methode zum Lesen der nächsten
logischen Zeile und zum anderen Methoden zum Auslesen bestimmter Bereiche einer logischen Zeile. Der Begriff logische Zeile ist hier eigentlich nicht
ganz korrekt, da sich nach dem Auslesen dieser noch immer Füll- und Steuerzeichen4 darin befinden. Da diese jedoch nur innerhalb des Scanners eine
Rolle spielen und nach außen nicht sichtbar werden, ist der Begriff dennoch
anwendbar.
Der Ablauf der in Abbildung 4.4 dargestellten Methode getNextLine soll
nun erläutert werden. Nachdem die GDF-Datei geöffnet wurde, werden zum
Einlesen einer logischen Zeile solange physische Zeilen zusammengefügt, bis
die 80. Position einer physischen Zeile das Zeichen ’0’ enthält. Das Lesen
4
Im Folgenden werden diese Zeichen nur noch als Füllzeichen bezeichnet.
4.3. VERARBEITUNG EINER GDF-DATEI
41
einer physischen Zeile erfolgt ohne die Zeilenendezeichen. Die logische Zeile
wird solange in einem lokalen Puffer gehalten, bis die nächste logische Zeile
angefordert wird. Konnte aus der GDF-Datei eine logische Zeile extrahiert
werden, liefert diese Methode den Wert wahr (true) ansonsten falsch (false).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Methode getNextLine (void)
: returns boolean
begin
t = ∅; /* temporärer Puffer für physischen Zeile */
p = ∅; /* lokaler Puffer für die logische Zeile */
t = Lese nächste Zeile aus der Datei;
if (Dateiende) then
return (false);
end;
Hänge t an p an;
while (t[79] <> ’0’ and not Dateiende)
t = Lese nächste Zeile aus der Datei;
Hänge t an p an;
end;
return (true);
end
Abbildung 4.4: Einlesen einer logischen Zeilen
Aufgrund der Füllzeichen in der so gewonnenen logischen Zeile ist ein
einfaches Übertragen der Rekordspezifikationen auf die logische Zeile nicht
möglich, d.h., einzelne Datenfelder können nicht direkt aufgrund ihrer Position und Länge in der logischen Zeile ausgelesen werden. Deshalb wurden spezielle Methoden implementiert, die die zu überlesenden Zeichen zählen und
zu der Positionsangabe beim nächste Auslesen von Datenfeldern hinzuaddieren. Um eine korrekte Zählung zu gewährleisten, müssen alle Datenfelder
durchgängig von vorne nach hinten ausgelesen werden. Eine Vorausberechnung, wie viele Zeichen in der i-ten physischen Zeile einer logischen Zeile
hinzugefügt wurden, ist im Allgemeinen nicht möglich, da in den Rekordspezifikation häufig sich wiederholende Datenfelder auftreten (vgl. Abschnitt
2.2.1) und die Anzahl der Wiederholungen nicht deterministisch ist.
Gerade die Häufigkeit dieser sich wiederholender Datenfelder begründet
die Implementation von Methoden, die mehrere Datenfelder nach einem Aufruf an den Parser zurückgeben können. Anhand der Methode readNumber soll
das Prinzip näher erläutert werden.
Die Methode in Abbildung 4.5 nimmt als Parameter die Anzahl der zu
42 KAPITEL 4. EINLESEN EINER GDF-DATEI IN DIE DATENBANK
lesenden Zahlen, die Position bezüglich der logischen Zeile5 , an der die erste
Zahl zu lesen ist, die Anzahl der Zeichen (Länge) einer Zahl und ein Feld
Ergebnis der Länge Anzahl, das die gelesenen Zahlen aufnimmt.
1
2
3
4
5
6
7
8
9
10
11
12
13
Methode readNumber (Anzahl, Position, Länge, Ergebnis[])
: returns Anzahl gelesener Zahlen
begin
Addiere zur Position #Füllzeichen;
for i = 0 to Anzahl - 1 do
if (nächstes Datenfeld passt nicht auf physische Zeile) then
Berechne die Anzahl der Füllzeichen neu;
Addiere zur Position #hinzugekommener Füllzeichen;
end;
Ergebnis[i] = Zahl an Position mit Länge Zeichen;
end;
return (i);
end
Abbildung 4.5: Auslesen von Datenfeldern aus einer logischen Zeile
Im GDF-Standard ist vorgesehen, dass Datenfelder nicht benutzt zu werden brauchen und somit Null-Werte enthalten. Hierfür sind Methoden vorgesehen, die zusätzlich zum Ergebnis-Feld ein Indikatorfeld entsprechend des
Vorhandenseins eines Wertes füllen.
4.3.3
Funktionsweise des Parsers
Oberhalb des Scanners arbeitet die Parser-Komponente. Diese enthält implizit sämtliche Rekordspezifikationen. Auf Grundlage des vorliegenden Rekordtyps der vom Scanner gelesenen logischen Zeile extrahiert diese Komponente
die Datenfelder und schreibt die Daten in DEL-Dateien. In diesem Teil wird
die Funktionsweise dieser Komponente näher vorgestellt.
Ein zentraler Bestandteil dieser Komponente ist eine Schleife (Hauptschleife), die bis zum Erreichen des Dateiendes nacheinander alle logischen
Zeilen vom Scanner lesen lässt und anschließend je nach Rekordtyp in Unterroutinen verzweigt. In diesen werden dann die Datenfelder ausgelesen und
in DEL-Dateien hinausgeschrieben.
Für jeden Rekordtyp wurde also eine spezielle Methode implementiert,
die analog zur Rekordspezifikation die Datenfelder aus der logischen Zeile
5
ohne Füllzeichen, usw.
4.4. VORGEHEN BEIM EINLESEN DER KOORDINATEN
43
ausliest. Wie bereits früher beschrieben, wird für den Zugriff auf die logische
Zeile ausschließlich Methoden des Scanners verwendet. Damit sich die Anzahl
der Methodenaufrufe reduziert, wird nach der Bearbeitung einer logischen
Zeile zunächst geprüft, ob der Rekordtyp der nächsten derselbe ist. Falls
dem so ist, kann auf die Rückkehr in die Hauptschleife verzichtet werden.
Die Tatsache, dass die Koordinaten eines Knotens, einer Linie oder Fläche
nicht zusammen in einem Rekord abgespeichert werden, erfordert ein Zwischenspeichern der Koordinatendaten, d.h., die von den Knoten- (KNOTREC), Linien- (NEDGEREC6 ) oder Flächenrekords (FACEREC) wird auf
ein Koordinatenrekord (XYZREC) mittels eines Identifikators verwiesen (vgl.
Abschnitt 2.2.3). Nur durch die Auflösung dieser Referenz erreicht man die
eigentlichen Koordinaten, die in dem vorliegenden Datenbankentwurf zusammen mit dem jeweiligen räumlichen Objekt abgespeichert werden. Dieses
Vorgehen ist auch wegen der Reihenfolge des Auftretens der Rekords in einer
GDF-Datei notwendig — die Koordinatenrekords stehen vor den anderen Datenrekords. Für das Zwischenspeichern werden Maps aus der STL benutzt.
Eine Map implementiert einen B-Baum, der Schlüssel-Wert-Paare abspeichern kann. Dies gewährleistet einen schnellen Zugriff auf die Daten.
Anhand eines Beispiels soll die Funktionsweise verdeutlicht werden —
das Auslesen aller anderen Rekordtypen erfolgt analog. Die Abbildung 4.6
skizziert die Verarbeitung eines Knotenrekords. Zunächst werden mit Hilfe
von Methoden des Scanners (z. B. readNumber()) aus der logischen Zeile die
Knoten- und die Koordinaten-ID ausgelesen. Die Koordinaten-ID referenziert
einen Rekord in dem sich die tatsächlichen Koordinaten befinden. Danach
erfolgt das Auflösen dieser Referenz über eine Methode (find()), die durch
die STL bereitgestellt wird. Anschließend wird ein Wertepaar in eine andere
Map eingefügt, die für spätere Referenzauflösungen in einem anderen Kontext
benötigt wird. Hiernach können die so extrahierten Datenfelder in eine DELDatei geschrieben werden. Zuletzt wird der Scanner aufgefordert, die nächste
logische Zeile in seinen lokalen Puffer zu laden und es wird überprüft, ob die
neue Zeile den selben Rekordtyp besitzt. Sollte dies der Fall sein, so kann in
dieser Routine verblieben werden.
4.4
Vorgehen beim Einlesen der Koordinaten
Da die Koordinaten mittels des DB2 Spatial Extenders verwaltet werden,
werden natürlich auch die bereitgestellten Datentypen genutzt. Dieser Abschnitt diskutiert die Möglichkeiten für die Konvertierung der aus der GDFDatei extrahierten Koordinaten in das Format des DB2 Spatial Extender
6
Das ’N’ am Anfang steht auch im GDF-Standard.
44 KAPITEL 4. EINLESEN EINER GDF-DATEI IN DIE DATENBANK
1
2
3
4
5
6
7
8
9
10
11
Methode parseNode (void)
: returns void
begin
do
Lese Knoten-ID;
Lese Koordinaten-ID;
Finde Koordinaten-ID in Koordinaten-Map;
Füge (Knoten-ID, Koordinaten-ID) in Knoten-Map ein;
Schreibe in Knoten-Datendatei (Knoten-ID, Koordinaten);
while (scanner.getNextLine() and Rekordtyp = KNOTREC);
end
Abbildung 4.6: Parsen eines Knotenrekords
und auch dem damit verbundenen Transfer in die Datenbank. Dazu müssen
die Koordinaten zuerst kodiert und dem DB2 Spatial Extender übermittelt
werden.
Zunächst soll erläutert werden, wie die Koordinatendaten zu strukturieren sind, damit diese in die Datenbank übertragen werden können. Der DB2
Spatial Extender stellt hierfür unterschiedliche Funktionen zur Verfügung,
die jedoch ähnlich funktionieren. Prinzipiell werden die Koordinaten in einem bestimmten Datenformat kodiert und anschließend einer gespeicherten
Datenbankprozedur übergeben. Die damit in ein internes Datenformat transformierten Daten werden in der Datenbank abgelegt.
DB2 Spatial Extender unterstützt drei Datenformate. Dabei handelt es
sich bei dem ersten um eine ASCII- und bei den anderen um eine Binärdarstellung.
• OGC 7 well-known text representation
• OGC well-known binary8 representation
• ESRI shape representation
Die Textrepräsentation eines räumlichen Objekts lässt sich verhältnismäßig einfach erzeugen; es werden nach dem Objekttyp nur noch die Koordinaten angegeben (vgl. Beispiel 4.1). Jedoch können Objekte mit besonders
vielen Koordinaten nicht in diesem Datenformat in die Datenbank übertragen werden, da die Länge der Zeichenkette durch die gespeicherte Datenbankprozedur auf 4000 Zeichen — der entsprechende Eingabeparameter ist
7
8
Abkürzung für Open GIS Consortium
kurz: WKB
4.4. VORGEHEN BEIM EINLESEN DER KOORDINATEN
45
als VARCHAR(4000) definiert — beschränkt ist. Im Allgemeinen sind in einer
GDF-Datei jedoch Polygone enthalten, die eine längere Zeichenkette erfordern. In solchen Fällen muss auf jeden Fall die binäre Kodierung verwendet
werden.
Beispiel 4.1 (Textrepräsentation eines Linienzuges)
Ein Linienzug, der durch die Punkte (10.05, 10.28), (20.59, 31.98) und
(21.98, 29.80) definiert ist, wird wie folgt als Text kodiert:
linestring ( 10.05 10.28, 20.59 31.98, 21.98 29.80 )
Eine binäre Repräsentation serialisiert ein räumliches Objekt auf ByteEbene. Es ist mit der binären Kodierung von Zeichen in einem Computer
vergleichbar. Hiermit können auch Objekte bestehend aus besonders vielen
Koordinaten übertragen werden; die Grenze liegt bei einer Größe von 1 MB.
Detaillierte Beschreibungen der ASCII- und Binärkodierungen für räumliche Objekte können in [IBM00a] nachgelesen werden.
Die Verwendung des DB2 Spatial Extenders bedeutet gleichzeitig, dass die
Koordinaten nicht einfach mittels des LOAD-Befehls geladen werden können,
da es sich bei den bereitgestellten Datentypen um strukturierte Datentypen
handelt. Es musste also ein alternativer Weg gefunden werden.
Eine Möglichkeit, die Koordinaten räumlicher Objekte in die Datenbank
zu übertragen, ist der direkte Weg über eine Datenbankverbindung mit Hilfe einer INSERT-Anweisung. Weiter oben ist bereits beschrieben, dass diese
Methode recht langsam arbeitet und deshalb nur in besonderen Situationen
(z. B. eine geringe Anzahl räumlicher Objekte) anwendbar ist.
Da die vom DB2 Spatial Extender Importfunktion auf dem gleichen Prinzip wie der IMPORT-Befehl beruht, ist hierdurch keine Verbesserung zu erzielen.
Der bisher erfolgversprechendste Weg verläuft nach folgendem Schema.
Zuerst wird aus den Koordinaten der GDF-Datei die Textrepräsentation erzeugt und diese in eine DEL-Datei geschrieben. Diese Tabelle kann durch
die LOAD-Hilfsroutine in die Datenbank eingelesen werden. Dabei wird die
Textrepräsentation auf den Basisdatentyp VARCHAR(4000) abgebildet. Eine anschließende INSERT ... SELECT-Anweisung mit integriertem Aufruf
der DB2 Spatial Extender Konvertierungsroutine arbeitet um ein vielfaches
schneller. Es liegt die Vermutung nahe, dass auf Grund geringerer Datenbewegungen im Speicher Zeit gewonnen wird.
Wie bereits weiter oben aufgezeigt, besitzen manche Polygone so viele Ecken, dass sie nicht in der Textrepräsentation kodiert werden können.
Es wird also die binäre Kodierung verwendet. Da ein Binärstring nicht wie
46 KAPITEL 4. EINLESEN EINER GDF-DATEI IN DIE DATENBANK
ein String in einer DEL-Datei behandelt werden kann9 , muss jeder derartige
Binärstring in einer extra Datei abgelegt werden. Diese können dann wiederum mittels der LOAD-Hilfsroutine als LOB eingelesen werden. Das Erzeugen
der Binärdateien ist auch der Grund dafür, weshalb man nicht grundsätzlich
binär kodieren kann. Durch die sehr große Anzahl an Dateien ist eine schnelle
Verarbeitung nicht mehr möglich.
Befinden sich zum Beispiel die Textrepräsentationen von räumlichen Objekten in der Tabelle rawNode mit den Spalten ID (BIGINT) und Coordinate (VARCHAR(4000)), und das Ziel ist die Tabelle node mit den Spalten
ID (BIGINT) und Coordinate (db2gse.st point), so transformiert folgende SQL-Anweisung10 die Koordinaten in das entsprechende Format. Analog
kann auch mit LOBs verfahren werden.
INSERT INTO node
SELECT id, st pointFromText(coord, coordref()..srid(0))
FROM rawNode
Trotzdem treten insbesondere beim Einlesen von Flächen (Polygonen)
Probleme auf, die durch die Daten selbst verursacht werden. Zum Teil sind
die Daten wahrscheinlich fehlerhaft (sich selbst schneidene oder nicht geschlossene Polygone) oder der Begriff Polygon wird in der GDF-Datei anders
ausgelegt als im DB2 Spatial Extender. Bei Nichtbeachtung dieser Probleme
gehen sogar bei der Transformation Information verloren.
Sehr häufig treten in einer GDF-Datei Polygone auf, die nach innen gehende Kanten haben, wie in Abbildung 4.7 dargestellt. Diese hineinragenden
Kanten werden jedoch vom DB2 Spatial Extender ersatzlos entfernt wie im
Abbildung 4.8 veranschaulicht. Offensichtlich gehen dadurch Informationen
verloren. Eine zufriedenstellende Lösung für dieses Problem wurde noch nicht
gefunden. Ein Ansatz, um trotzdem auf diese weggeworfenen Koordinaten
zugreifen zu können, könnte zum Beispiel das separate und somit zusätzliche Speichern der Punkte der hineinreichenden Kanten oder des gesamten
Polygons sein.
Diese hineinragenden Kanten erschweren außerdem das Erkennen von
Ringen (vgl. Def. 2.9) in einem Polygon. Das Erkennen von Ringen ist notwendig, um die entsprechende Kodierung erzeugen zu können. Da Polygone
sich nicht selbst schneiden dürfen, zeichnet sich ein Ring dadurch aus, dass
der Anfangs- und Endpunkt derselbe ist. Trifft nun der Algorithmus gleich
zu Anfang auf eine hineinragende Kante, so ist der dritte Punkt gleich dem
ersten und somit wird fälschlicherweise ein Ring identifiziert. Ein Objekt mit
drei Punkten, wobei der erste gleich dem letzten ist, ist kein Polygon.
9
10
Es gibt kein Zeichen, mit dem man einen Binärstring klammern kann
Dabei wird angenommen, dass sich das Schema db2gse im Funktionenpfad befindet.
4.5. LADEN DER DEL-DATEIEN
47
Abbildung 4.7: Polygon in der GDFDatei
Abbildung 4.8: resultierendes Polygon in der Datenbank
Die oben geschilderten fehlerhaften Daten verursachen zudem einen Abbruch und damit ein Zurücksetzen der INSERT ... SELECT-Anweisung, da
die Konvertierungsroutine einen Fehler zurückliefert. Wenn man nicht vorher
sicherstellen kann, dass die Polygone fehlerfrei sind, bleibt in dieser Situation
nichts anderes übrig, als tupelweise die Daten in die Datenbank einzulesen.
Somit bietet sich bei einem Fehler die Möglichkeit, das Polygon näher zu
untersuchen und gegebenenfalls zu berichtigen. Dieses Prinzip kann sowohl
als Applikation oder gespeicherte Datenbankprozedur implementiert werden.
4.5
Laden der DEL-Dateien
Nach der Generierung der DEL-Dateien müssen diese nun in die Datenbank
hineingeladen werden. Wie in Abschnitt 3.3.2 schon aufgezeigt, müssen außerdem die Datentabellen in einem entsprechenden Schema angelegt werden.
Dieser Vorgang wird im folgenden Abschnitt näher beschrieben.
Das Laden der DEL-Dateien wird von einem Shell-Skript gesteuert. Dieses Skript arbeitet in zwei Phasen. In der ersten werden die Daten- und
temporäre Tabellen in einem neuen Schema angelegt, das den Namen der
gerade einzulesenden Sektion erhält. Dazu wird das Token ’ ?’ in den SQLSkripten mittels sed (Stream Editor) durch den Namen der Sektion substituiert und anschließend von DB2 ausgeführt. In der darauffolgenden Phase
werden die DEL-Dateien nacheinander mit Hilfe der LOAD-Hilfsroutine in
die Datenbank geladen. Die Koordinaten werden, wie in Abschnitt 4.4 vorgestellt, zunächst in einer temporären Tabellen abgelegt und dann in das
DB2 Spatial Extender Format überführt. Als letztes werden die temporären
Dateien wieder gelöscht.
Der Ablauf des Skriptes sieht also folgendermaßen aus:
Das Shell-Skript nimmt als Parameter den neuen Schemanamen, einen
Datenbankalias sowie eine NutzerID mit seinem Passwort. Alle Anweisungen
für die Erzeugung und das Laden der Dateien sind bereits in jeweils einem
SQL-Skript zusammengefasst. Es muss lediglich das Token ’ ?’ substituiert
48 KAPITEL 4. EINLESEN EINER GDF-DATEI IN DIE DATENBANK
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Programm loadData (Schema, DB-Alias, Nutzer, Passwort)
: returns Fehlercode
begin
# Phase 1
CONNECT TO DB-Alias USER Nutzer USING Passwort;
Erzeuge Datenbanktabellen in Schema;
Erzeuge temporäre Tabellen in Schema;
# Phase 2
Lade Daten alle Daten bis auf Koordinaten;
Lade Koordinaten in temporäre Tabellen;
Konvertiere Koordinaten;
Lösche temporäre Tabellen;
DISCONNECT;
end
Abbildung 4.9: Einlesen der DEL-Dateien
werden; in diesen Zeilen erfolgt demzufolge auch ein Aufruf von sed.
Kapitel 5
Zusammenfassung und
Auswertung
Insgesamt soll ein datenbankgestütztes Geo-Informationssystem zur performanten Verwaltung kartographischer Daten entwickelt werden, wobei durch
Integration verschiedener Datenquellen der Mehrwert einer Visualisierung
erhöht wird. Im Vordergrund steht hierbei auch die effiziente Beantwortung
von Bereichsanfragen, um eine rasche Visualisierung unterschiedlicher Kartenausschnitte zu gewährleisten. Am Anfang konnten die Anforderungen an
die Datenbank und das System nur allgemein formuliert werden. Im weiteren Verlauf konkretisierten sich unter anderem auch durch die Evaluation
früherer Versionen die Vorstellungen und Erwartungen.
Die Grundlage eines derartigen Systems bildet ein Datenbankschema für
die Verarbeitung und Speicherung von GDF-Daten. In dieser Studienarbeit
wurde ein solches Datenbankschema konzipiert und für das Datenbankmanagementsystem DB2 UDB V7.1 realisiert. Eine Verfeinerung und Ergänzung
des allgemeinen Referenzmodell des GDF-Standards bildet hierfür die Basis.
Der Datenbankentwurf beschreibt zunächst nur die wesentlichen Aspekte der
in GDF-Dateien gespeicherten Informationen. Zum Beispiel sind benutzerdefinierte Feature noch nicht vollständig integriert.
Besondere Anforderungen an das DBMS stellte die Speicherung und Indizierung räumlicher Objekte, da zweidimensionale Datenbestände nicht hinreichend mit den üblichen B-Bäumen indiziert werden können. Eine mögliche
Lösung hierfür ist die Verwendung des DB2 Spatial Extenders, der das DBMS
um räumliche Datentypen und Funktionalität erweitert. Der DB2 Spatial Extender benutzt zur Indizierung der räumlichen Objekte einen mehrstufigen
Gitterindex. Hierbei werden über das betrachtete Gebiet Gitternetze unterschiedlicher Größe gelegt und Schnittpunkte mit den minimalen umschreibenden Rechtecken von räumlichen Objekten in einem Index eingetragen.
49
50
KAPITEL 5. ZUSAMMENFASSUNG UND AUSWERTUNG
Da die Daten im GDF-Format vorliegen, war zuerst eine Einarbeitung
in den konzeptionellen Aufbau und die physische Speicherung einer GDFDatei notwendig. Dabei erwiesen sich zusätzlich eingefügte Leerzeichen bei
der physischen Speicherung der Datenrekords beim Einlesen als hinderlich.
Für den Transfer der Daten aus den GDF-Dateien in die Datenbank
wurden in diesem Kontext entsprechende Werkzeuge implementiert. Das
Hauptaugenmerk liegt hierbei auf dem schnellen Extrahieren und Einlesen
der Daten aus den GDF-Dateien. Aus diesem Grund werden mittels eines
Programms entsprechend den Tabellen im Datenbankschema DEL-Dateien
erzeugt. Anschließend lädt das LOAD-Hilfsprogramms von DB2 die DELDateien in die Tabellen. Diese Methode des Datentransfers erwies sich im
Zusammenhang mit DB2 als besonders zeitsparend. Ein weiterer sich daraus
ergebender Vorteil ist die Unabhängigkeit des Werkzeugs vom DBMS, da im
Allgemeinen jedes DBMS über Möglichkeiten zum Einlesen von DEL-Dateien
verfügt. Als schwierig erwies sich hierbei die Übergabe der Koordinaten an
den DB2 Spatial Extender. Das konnte bisher nur unbefriedigend durch einen
Umweg über das Zwischenspeichern einer textuellen bzw. binären Kodierung
der räumlichen Objekte in temporären Tabellen und darauf folgender Konvertierung gelöst werden.
5.1
Fortführung der Studienarbeit
Im Rahmen einer Studienarbeit ist es nicht möglich, alle Aspekte eines datenbankgestützten Geo-Informationssystems mit Integration unterschiedlicher
Datenquellen zu untersuchen oder zu realisieren. In diesem Kapitel wird zusammengefasst, wie die in der Studienarbeit gelegte Basis erweitert und somit
zu einem umfassenden GIS ausgebaut werden kann. Weiterhin werden in der
Studienarbeit herauskristallisierte Probleme aufgegriffen.
Ein wichtiger Punkt stellt die Realisierung der in der Studienarbeit entwickelten Konzepte in zumindest einem anderen DBMS dar, um dadurch
eine objektivere Bewertung des System auf Basis von DB2 UDB V7.1 vornehmen zu können. Unsystematische, parallel durchgeführte Tests unter dem
DBMS Oracle zeigen, dass DB2 UDB V7.1 mit der Erweiterung DB2 Spatial
Extender für den Einsatz in der Entwicklungsumgebung der Firma Vivatech
Software Berlin GmbH nicht unbedingt die beste Lösung darstellt.
Erste Untersuchungen zeigen, dass DB2 UDB V7.1 nur ein unzureichendes Interface zu Java implementiert. Hauptsächlich werden die Koordinatenlisten aus dem DB2 Spatial Extender mittels der LOB Datentypen übertragen, die jedoch im Allgemeinen eher für Sprachen der dritten Generation
— also für Sprachen die C-ähnliche Strukturen implementieren — geeignet
5.1. FORTFÜHRUNG DER STUDIENARBEIT
51
sind [IBM00a]. Ein weiteres in diesem Zusammenhang auftretendes Problem
ist, dass für das Auslesen der Koordinatenlisten aus den LOBs mittels Java
zunächst ein Konvertierung von der Little Endian zu der Big Endian Repräsentation vorgenommen werden muss. Zusammengefasst wird hier ein effizienterer Mechanismus zur Datenübertragung benötigt. Zum Beispiel wäre
zu entscheiden, ob eine eigene Implementation der räumlichen Erweiterung in
DB2 UDB V7.1, die derartige Konvertierungsprobleme umgeht, Sinn macht
oder ob auf ein anderes DBMS ausgewichen werden sollte.
Ein anderer Ansatzpunkt für eine Weiterentwicklung im Bereich der hier
vorgestellten Werkzeuge zum Einlesen der GDF-Dateien bildet die Korrektur fehlerhafter Koordinaten von räumlichen Objekte. Wie in Kapitel 4.4 beschrieben, treten insbesondere bei Einlesen der Flächen (Polygone) Probleme
mit den Daten auf. In diesem Kontext ist es überlegenswert, Methoden zu
schaffen, die bereits während des Parsens einer GDF-Datei die räumlichen
Objekte auf Validität prüfen und gegebenenfalls Anpassungen vornehmen.
Des Weiteren ist noch nicht klar, ob ausschließlich die korrigierten Objekte in der Datenbank gespeichert werden oder auch noch zusätzliche Informationen, aus denen sich die Daten des ursprünglich fehlerhaften Objektes
wiederherstellen lassen.
Bisher außer Acht gelassen wurde die geeignete Erstellung von (materialisierten) Views oder Indizes. Diese Konzepte ermöglichen dann die Vermeidung von Joinoperationen und dadurch einen schnelleren sowie einfacheren
Zugriff auf die Daten. Sinnvoll ist auch eine weitere Untersuchung des Integrationsaspekts, indem von GDF verschiedene Datenquellen in die Basis
eingeflochten werden und entsprechende Anfragen an das System gestellt
werden. Erst hiernach ist eine vollständige Evaluation des Gesamtsystems
möglich.
Anhang A
Das Entity Relationship Modell
In diesem Anschnitt wird die in der Studienarbeit verwendete Entity Relationship1 Notation näher erläutert. Die in [Fre99] vorgestellte Notation bildet
dabei die Grundlage.
A.1
Entity und Entity-Typ
Ein Entity ist ein gerade betrachteter Gegenstand aus der realen Welt. In der
Modellierung werden Entities mit gleichen Eigenschaften zu Entity-Typen
zusammengefasst. Wie in Abbildung A.1 gezeigt, wird ein Entity-Typ durch
ein Rechteck dargestellt.
Entity
Abbildung A.1: Entity-Typ
A.2
Attribut und Attributtyp
Attribute sind Eigenschaften eines Entity und gleichartige Attribute werden in Attributtypen zusammengefasst. Dargestellt werden diese durch eine
Ellipse (s. Abbildung A.2). Kann ein Attribut mehrere Werte gleichzeitig annehmen (mehrwertig oder auch multi valued), so wird dies durch doppelte
Umrandung gekennzeichnet.
Wenn ein Attribut der Schlüssel eines Entity ist, so wird der Name des
Attributs in eckige Klammer gesetzt.
1
kurz: ER
52
A.3. BEZIEHUNG UND BEZIEHUNGSTYP
Attribut
53
Attribut
[Attribut]
Abbildung A.2: Attributtypen (atomar/mehrwertig/Schlüsselattribut)
A.3
Beziehung und Beziehungstyp
Besteht zwischen zwei Entities eine semantische Verbindung, so kann dies
als Beziehung veranschaulicht werden. Beziehungen derselben Art werden in
Beziehungstypen zusammengefasst. Die graphische Notation ist eine Raute
(s. Abbildung A.3).
Entity A
Beziehung
M
Entity B
N
Abbildung A.3: Beziehungstyp
A.3.1
Grad
Der Grad eines Beziehungstyps gibt an, wie viele Entity-Typen in diesem
partizipieren (binär, tertiär, usw.).
A.3.2
Kardinalität
Die Kardinalität bestimmt die Anzahl der Beziehungsinstanzen, in der ein
Entity teilnehmen kann. Tabelle A.1 zeigt wie die Kardinalitäten in einem
Diagramm interpretiert werden. Ein Beispiel für die Darstellung von Kardinalitäten bietet Abbildung A.3.
A.3.3
Totalität
Die Totalität drückt aus, ob ein Entity an einer Beziehung teilnehmen muss.
Als graphische Darstellung wird ein Querbalken auf der Verbindungslinie
zwischen Entity-Typ und Beziehungstyp benutzt. Dies ist in Abbildung A.3
beim Entity-Typ A zu erkennen. Ist auf der Seite eines Entity-Typs ein
solcher Querbalken eingetragen, so bedeutet dies, dass jede Instanz dieses
Entity-Typs an der entsprechenden Beziehung teilnehmen muss (totale Beteiligung). Ansonsten braucht die Instanz eines Entity nicht an der Beziehung
teilnehmen (partielle Beteiligung).
54
ANHANG A. DAS ENTITY RELATIONSHIP MODELL
A
1
B
1
1
M
N
M
Interpretation
Ein Entity des Typs A steht mit genau einem Entity des Typs
B und ein Entity des Typs B steht mit genau einem Entity
des Typs A in Beziehung.
Ein Entity des Typs A kann mit mehreren Entities des Typs
B in Beziehung stehen, aber ein Entity des Typs B steht mit
genau einem Entity des Typs A in Beziehung.
Ein Entity des Typs A kann mit mehreren Entities des Typs
B und ein Entity des Typs B kann mit mehreren Entities des
Typs A in Beziehung stehen.
Tabelle A.1: Interpretation der Kardinalitäten
Das Beispiel wird so interpretiert, dass jede Instanz des Entity-Typs A
an der Beziehung mit einer Instanz des Entity-Typ B teilnehmen muss. Auf
der anderen Seite kann (muss aber nicht) jede Instanz des Entity-Typs B an
der Beziehung teilzunehmen.
A.4
Spezialisierung und Generalisierung
Ausgehend von mehreren Entity-Typen mit gemeinsamen Attributen kann
ein neuer Entity-Typ erzeugt werden, der nur die gemeinsamen Attribute
besitzt. Diesen Vorgang nennt man Generalisierung. Den umgekehrten Vorgang, also die Bildung neuer Entity-Typen aus einem bereits vorhandenen,
wird als Spezialisierung bezeichnet. Die Generalisierung und Spezialisierung
werden durch ein Dreieck symbolisiert (s. Abbildung A.4).
Insbesondere übernehmen die spezialisierten Entity-Typen alle Attribute
und Schlüssel des Basisentity-Typs. Besitzt die Spezialisierung einen anderen
Schlüssel als die Basis, so wird dieser beim spezialisierten Entity-Typ mit
angegeben.
Entity
Entity
Abbildung A.4: Spezialisierung und Generalisierung
Anhang B
Data Definition Language
B.1
Einzigartige Datentypen
Die untenstehende Tabelle enthält die definierten einzigartigen Datentypen,
deren Basistyp und deren Einsatz. Diese Datentypen sind alle im Schema meta definiert. Um die Operatoren der neuen Datentypen wie bei den Standarddatentypen benutzen zu können, muss sich das Schema meta im Suchpfad für
Funktionen befinden. Dazu ist das Kommando SET PATH = CURRENT PATH,
meta auszuführen.
einzig. Datentyp
dt id
dt featureKlasse
dt featureKategorie
dt relationshipCode
dt
dt
dt
dt
dt
dt
attributeCode
attributeValue
nameValue
languageCode
externalCode
description
B.2
Basistyp
BIGINT
SMALLINT
SMALLINT
SMALLINT
Anwendung
IDs der Datensätze
Kodierung der Feature-Klasse
Kodierung der Feature-Kategorie
Kodierung des Typs der semantischen Beziehung
CHAR(2)
Kodierung des Attributtyp
VARCHAR(100) Attributwert
VARCHAR(100) Feature-Name
CHAR(3)
Sprachencode
VARCHAR(10)
externe Kodierung
VARCHAR(255) Text in den Übertragungstabellen: Code ↔ lesbarer Text
Tabellen
In diesem Abschnitt sind alle Tabellen aufgeführt. Im ersten Teil sieht man
die Tabellen für das Schema meta und im zweiten die für die kartographischen Daten. Dabei sind tabellarisch die Spaltennamen mit ihren Datenty55
56
ANHANG B. DATA DEFINITION LANGUAGE
pen, Zulässigkeit von NULL-Werten sowie eine Kurzbeschreibung dargestellt.
Der Schlüssel einer Tabellen ist hervorgehoben.
B.2.1
Metadatentabellen
Section In dieser Tabelle werden alle Informationen bezüglich einer Sektion
einer GDF-Datei abgelegt. Mit Hilfe dieser Tabelle sind auch die von einer
Bereichsanfrage betroffenen Schemata bestimmbar.
Spaltenname
ID
schema
GeoArea
XY Factor
Datentyp
dt id
VARCHAR(128)
dt description
INTEGER
null
nein
nein
ja
ja
Z Factor
X Offset
Y Offset
Z Offset
max
min
box
INTEGER
INTEGER
INTEGER
INTEGER
st point
st point
st polygon
ja
ja
ja
ja
nein
nein
nein
Kurzbeschreibung
eindeutige ID
zugehöriges Schema
Name des Gebietes
Multiplikator x- und y-Koordinaten
Multiplikator z-Koordinate
Verschiebung x-Koordinate
Verschiebung y-Koordinate
Verschiebung z-Koordinate
rechte obere Ecke der BB
linke untere Ecke der BB
Bounding Box
FeatureKategorie Die Tabelle ermöglicht die Umsetzung der Kodierung
einer Feature-Kategorie in lesbaren Text und umgekehrt.
Spaltenname
featureKategorie
Datentyp
dt featureKategorie
null
nein
externalCode
description
dt externalCode
dt description
ja
nein
Kurzbeschreibung
Kodierung für Feature-Kategorien lt. GDF-Standard
externe Kodierung
Feature-Kategorie als Text
FeatureKlasse Die Tabelle ermöglicht die Umsetzung der Kodierung einer
Feature-Klasse in lesbaren Text und umgekehrt.
Spaltenname
featureKlasse
Datentyp
dt featureKlasse
null
nein
externalCode
description
dt externalCode
dt description
ja
nein
Kurzbeschreibung
Kodierung
für
FeatureKlassen lt. GDF-Standard
externe Kodierung
Feature-Klasse als Text
B.2. TABELLEN
57
RelationshipCode Die Tabelle ermöglicht die Umsetzung der Kodierung
einer semantischen Beziehung in lesbaren Text und umgekehrt.
Spaltenname
relationshipCode
Datentyp
null
dt relationshipCode nein
externalCode
description
dt externalCode
dt description
ja
nein
Kurzbeschreibung
Kodierung für semant. Beziehungen lt. GDF-Standard
externe Kodierung
semant. Beziehung als Text
RelationshipParts Diese Tabelle gibt Auskunft über die teilnehmenden
Features und an welcher Stelle sie auftreten.
Spaltenname
relationshipCode
Datentyp
null
dt relationshipCode nein
position
featureKlasse
SMALLINT
dt featureKlasse
nein
nein
Kurzbeschreibung
Kodierung für semant. Beziehungen lt. GDF-Standard
Stelle in der Beziehung
teilnehmende Feature-Klasse
AttributeCode Die Tabelle ermöglicht die Umsetzung der Kodierung eines Attributes in lesbaren Text und umgekehrt.
Spaltenname
attributeCode
Datentyp
dt attributeCode
null
nein
externalCode
description
dt externalCode
dt description
ja
nein
Kurzbeschreibung
Kodierung für Attribute lt.
GDF-Standard
externe Kodierung
Attribut als Text
LanguageCode Die Tabelle ermöglicht die Umsetzung der Kodierung einer Sprache in lesbaren Text und umgekehrt.
Spaltenname
languageCode
Datentyp
dt languageCode
null
nein
externalCode
description
dt externalCode
dt description
ja
nein
B.2.2
Kurzbeschreibung
Kodierung für Sprachen nach
MARC Sprachcodes
externe Kodierung
Sprache als Text
Datentabellen
ComplexFeature Die Tabelle enthält die Basisinformationen zu einem
komplexen Feature.
Spaltenname
ID
FeatureKlasse
Datentyp
dt id
dt featureKlasse
null
nein
nein
Kurzbeschreibung
Identifikator
Feature-Klasse
58
ANHANG B. DATA DEFINITION LANGUAGE
SimpleFeature Die Tabelle enthält die Basisinformationen zu einem simplen Feature. Hier sind Punkt-, Linienzug, und Gebiets-Feature zusammengefasst.
Spaltenname
ID
FeatureKategorie
FeatureKlasse
Datentyp
dt id
dt featureKategorie
dt featureKlasse
null
nein
nein
nein
Kurzbeschreibung
Identifikator
Feature-Kategorie
Feature-Klasse
Node Die Tabelle enthält die Koordinaten für die Knoten.
Spaltenname
ID
Coordinate
Datentyp
dt id
st point
null
nein
nein
Kurzbeschreibung
Identifikator
Koordinate
Edge Die Tabelle enthält die Koordinaten für die Linien.
Spaltenname
ID
LeftFaceID
Datentyp
dt id
dt id
RightFaceID
dt id
Coordinate
st lineString
null
nein
ja
ja
nein
Kurzbeschreibung
Identifikator
Identifikator von linksseitiger
Fläche
Identifikator von rechtsseitiger
Fläche
Koordinateliste
Edge Die Tabelle enthält die Koordinaten für die Flächen.
Spaltenname
ID
Coordinate
Datentyp
dt id
st polygon
null
nein
nein
Kurzbeschreibung
Identifikator
Koordinateliste
FeatureName Die Tabelle enthält die Namen-Attribute für die Feature.
Spaltenname
ID
AttributeCode
LanguageCode
Text
Datentyp
dt id
dt attributeCode
dt languageCode
dt nameValue
null
nein
nein
nein
ja
Kurzbeschreibung
Identifikator
kodierter Name des Attributs
Sprachenkodierung
Attributwert
B.2. TABELLEN
59
NameOfComplex Diese Tabelle stellt die Verbindung zwischen komplexen Feature und Namenattributen her.
Spaltenname
ComplexID
Datentyp
dt id
null
nein
NameID
dt id
nein
Kurzbeschreibung
Identifikator eines komplexen
Feature
Identifikator eines NamenAttributs
NameOfComplex Diese Tabelle stellt die Verbindung zwischen simplen
Feature und Namenattributen her.
Spaltenname
Datentyp
FeatureKategorie dt featureKategorie
SimpleID
dt id
null
nein
nein
NameID
nein
dt id
Kurzbeschreibung
Feature-Kategorie
Identifikator eines simplen
Feature
Identifikator eines NamenAttributs
FeatureAttribute Die Tabelle enthält die Attribute für die Feature.
Spaltenname
ID
AttributeCode
Value
Datentyp
dt id
dt attributeCode
dt attributeValue
null
nein
nein
ja
Kurzbeschreibung
Identifikator
kodierter Name des Attributs
Attributwert
AttributeOfComplex Diese Tabelle stellt die Verbindung zwischen komplexen Feature und Attributen her.
Spaltenname
ComplexID
Datentyp
dt id
null
nein
AttributeID
dt id
nein
Kurzbeschreibung
Identifikator eines komplexen
Feature
Identifikator eines Attributs
AttributeOfSimple Diese Tabelle stellt die Verbindung zwischen simplen
Feature und Attributen her.
Spaltenname
Datentyp
FeatureKategorie dt featureKategorie
SimpleID
dt id
null
nein
nein
AttributeID
nein
dt id
Kurzbeschreibung
Feature-Kategorie
Identifikator eines simplen
Feature
Identifikator eines Attributs
60
ANHANG B. DATA DEFINITION LANGUAGE
semanticRelation Die Tabelle enthält die Basisdaten für die semantischen
Beziehungen.
Spaltenname
Datentyp
null
semanRelationID dt id
nein
relationshipCode dt relationshipCode nein
Kurzbeschreibung
Identifikator
kodierter Name der semantischen Beziehung
RelationOfFeature Diese Tabelle ordnet einem Feature die semantischen
Beziehungen zu, an denen es beteiligt ist. Das Datenfeld Position dient der
Bestimmung der Stelle in der semantischen Beziehung.
Spaltenname
FeatureKategorie
FeatureID
semanRelationID
Datentyp
dt featureKategorie
dt id
dt id
null
nein
nein
nein
Position
SMALLINT
nein
Kurzbeschreibung
Feature-Kategorie
Identifikator eines Feature
Identifikator der zugehörigen
semantischen Beziehung
Stelle in der Beziehung
ComplexOfSimple Durch diese Tabelle werden die simplen Feature einem
daraus bestehenden komplexen Feature zugeordnet.
Spaltenname
ComplexID
Datentyp
dt id
null
nein
FeatureKategorie dt featureKategorie
SimpleID
dt id
nein
nein
Position
nein
SMALLINT
Kurzbeschreibung
Identifikator eines komplexen
Feature
Feature-Kategorie
Identifikator eines simplen
Feature
fortlaufende Nummer des simplen Feature
ComplexOfComplex Durch diese Tabelle werden die komplexen Feature
einem daraus bestehenden komplexen Feature zugeordnet.
Spaltenname
SuperComplexID
Datentyp
dt id
null
nein
SubComplexID
dt id
nein
Position
SMALLINT
nein
Kurzbeschreibung
Identifikator des entstehenden
komplexen Feature
Identifikator der untergeordneten komplexen Feature
fortlaufende Nummer des
komplexen Feature
B.2. TABELLEN
61
SimpleOfNode Diese Tabelle ordnet einem simplen Feature deren KnotenKoordinaten zu. Implizit wird die Feature-Kategorie Punkt angenommen.
Spaltenname
SimpleID
Datentyp
dt id
null
nein
nodeID
dt id
nein
Kurzbeschreibung
Identifikator eines simplen
Feature
Identifikator des zugehörigen
Knotens
SimpleOfEdge Diese Tabelle ordnet einem simplen Feature deren LinienKoordinatenlisten zu. Implizit wird die Feature-Kategorie Linie angenommen. Das Datenfeld Position dient der Erhaltung der Reihenfolge.
Spaltenname
SimpleID
Datentyp
dt id
null
nein
edgeID
dt id
nein
Direction
SMALLINT
nein
Position
SMALLINT
nein
Kurzbeschreibung
Identifikator eines simplen
Feature
Identifikator der zugehörigen
Linie
Richtung wie die Linie zu
durchlaufen ist — entweder 0
(von vorn) oder 1 (von hinten)
fortlaufende Nummer der Linie
SimpleOfFace Diese Tabelle ordnet einem simplen Feature deren FlchenKoordinatenlisten zu. Implizit wird die Feature-Kategorie Polygon angenommen. Das Datenfeld Position dient der Erhaltung der Reihenfolge.
Spaltenname
SimpleID
Datentyp
dt id
null
nein
faceID
dt id
nein
Position
SMALLINT
nein
Kurzbeschreibung
Identifikator eines simplen
Feature
Identifikator der zugehörigen
Fläche
fortlaufende Nummer der
Fläche
Literaturverzeichnis
[Bar95]
Norbert Bartelme. Geoinformatik. Springer-Verlag Berlin Heiderberg, 1995.
[Cha99]
Don Chamberlin. DB2 Universal Database; Der unentbehrliche
Begleiter. Addison Wesley Longman GmbH, 1999.
[Con00]
Rainer Conrad. Vortragsfolien: GIS und Anwendungen. Institut
für Informatik, Humbold-Universität zu Berlin, 2000.
[ESR98]
ESRI,
http://www.esri.com/library/gis/abtgis/compgis.html.
Components of a GIS, Juli 1998.
[Fla97]
Miroslaw A. Flasza. Diplomarbeit: Implementation von GeoFunktionalität in einem erweiterbaren relationalen DBMS. Institut
für Informatik, Humbold-Universität zu Berlin, August 1997.
[Fre99]
Johann Christoph Freytag. Vorlesungsskript: Grundlagen von Datenbanken. Institut für Informatik, Humbold-Universität zu Berlin, 1998/99.
[GDF95] European Committee for Standardisation. Geographic Data Files,
first draft edition, October 1995.
[IBM00a] IBM. IBM DB2 Spatial Extender User’s Guide and Reference
Version 7, 2000.
[IBM00b] IBM. IBM DB2 Universal Database Online-Informationen Version 7.1, 2000. siehe auch: http://www-4.ibm.com/software/data/db2/library/publications/.
[Kin01]
Kingston Centre for GIS, Kingston University, http://www.kingston.ac.uk/geog/gis/intro.htm. Introduction to GIS and Geospatial
Data, 2001.
62
LITERATURVERZEICHNIS
[Teo94]
63
Toby J. Teorey. Data Modeling & Design; The Fundamental Principles. Morgan Kaufmann Publishers, Inc., second edition, 1994.
Erklärung
Hiermit erkläre ich, dass ich die vorliegende Arbeit selbständig und ohne
unerlaubte Hilfe verfasst habe.
Berlin, den 10. Juni 2001
Ralf Heese