Entwurf und Implementierung eines - dbs.uni

Entwurf und Implementierung eines Datenmodells
für Bodendaten zur datenbankgestützten Integration
von Methoden der physischen Geographie
Diplomarbeit im Studiengang Mathematik
mit der Studienrichtung Informatik
- Universität Hannover -
Vorgelegt von: Jens Helge Pfau
Prüfer: Prof. Dr. Udo Lipeck, Prof. Dr. Thomas Mosimann
Betreuer: Dipl.-Math. Carsten Kleiner, Dipl.-Geogr. Markus Neteler
15. Februar 2000
Zusammenfassung
Geografische Informationssysteme werden für die Speicherung, Verknüpfung
und grafische Darstellung räumlicher Daten eingesetzt. Sie sind dabei optimiert für Berechnungen auf geometrischen Daten. Datenbanksysteme hingegen sind für die konsistente Verwaltung und flexible Verknüpfung beliebiger
Daten konzipiert. Das Spatial Cartridge des objekt-relationalen Datenbanksystems Oracle8i implementiert Methoden Geografischer Informationssysteme für ein Datenbanksystem. Im Rahmen dieser Arbeit wird untersucht,
inwieweit damit geografische Methoden, insbesondere Berechnungen auf geometrischen Objekten implementiert werden können. Für diese Untersuchung
wird zunächst ein Datenmodell für Bodendaten entwickelt und und anschließend eine Methode implementiert, die aus unterschiedlich komplexen Teilmethoden zusammengesetzt ist. Dabei werden sowohl einfache Verknüpfungen
von Daten, als auch komplexe Berechnungen auf geometrischen Objekten
durchgeführt.
Inhaltsverzeichnis
1 Einleitung
1
2 Geografische Informationssysteme
5
2.1 Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2 Informationsebenen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.3 GIS-Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.3.1
Rasterdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3.2
Vektordaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3.3
Punktdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3.4
Rasterdatenformat vs. Vektordatenformat . . . . . . . . . . . . .
8
2.4 GIS-Operationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3 Datenbanksysteme
15
3.1 Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.2 Datenbankentwurf
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.2.1
Architekturprinzipien . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.2.2
Phasen des Datenbankentwurfs . . . . . . . . . . . . . . . . . . .
18
3.3 Unified Modelling Language (UML) . . . . . . . . . . . . . . . . . . . . .
19
3.3.1
Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.3.2
Generalisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.3.3
Assoziationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.4 Relationenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.4.1
Modellierungskonzepte . . . . . . . . . . . . . . . . . . . . . . . .
i
22
ii
INHALTSVERZEICHNIS
3.4.2
Modellinhärente Integritätsbedingungen . . . . . . . . . . . . . .
23
3.4.3
Transformation von UML ins Relationenschema . . . . . . . . . .
24
3.5 Oracle 8i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.5.1
Objektrelationale Datenbanksysteme . . . . . . . . . . . . . . . .
25
3.5.2
Komplexe Datentypen in Oracle8i . . . . . . . . . . . . . . . . . .
25
3.5.3
Oracle8i Spatial . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.5.3.1
Speicherung räumlicher Daten . . . . . . . . . . . . . . .
27
3.5.3.2
Anfragemodell . . . . . . . . . . . . . . . . . . . . . . .
32
3.5.3.3
Indexe auf räumlichen Daten . . . . . . . . . . . . . . .
33
3.5.3.4
Operationen auf räumlichen Daten . . . . . . . . . . . .
35
4 Datenbankentwurf
39
4.1 Anforderungsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
4.1.1
Informationsebene Boden
. . . . . . . . . . . . . . . . . . . . . .
41
4.1.2
Informationsebene Nutzung (Vegetation) . . . . . . . . . . . . . .
42
4.1.3
Informationsebene Klima . . . . . . . . . . . . . . . . . . . . . . .
43
4.1.4
Informationsebene Relief . . . . . . . . . . . . . . . . . . . . . . .
43
4.1.5
Methoden und Operationen . . . . . . . . . . . . . . . . . . . . .
44
4.2 Externe Datenbankschemata (UML) . . . . . . . . . . . . . . . . . . . .
46
4.2.1
Externes Schema der Informationsebene Boden . . . . . . . . . .
46
4.2.2
Externes Schema der Informationsebene Nutzung . . . . . . . . .
46
4.2.3
Externes Schema der Informationsebene Klima . . . . . . . . . . .
48
4.2.4
Externes Schema der Informationsebene Relief . . . . . . . . . . .
48
4.3 Konzeptionelles Schema . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.4 Logisches Modell (Relationenmodell) . . . . . . . . . . . . . . . . . . . .
51
4.4.1
Informationsebene Boden
. . . . . . . . . . . . . . . . . . . . . .
51
4.4.2
Informationsebene Nutzung . . . . . . . . . . . . . . . . . . . . .
52
4.4.3
Informationsebene Klima . . . . . . . . . . . . . . . . . . . . . . .
52
4.4.4
Informationsebene Relief . . . . . . . . . . . . . . . . . . . . . . .
53
4.5 Physischer Entwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
INHALTSVERZEICHNIS
iii
4.5.1
Typdefinitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
4.5.2
Relationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
4.5.3
Indexe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
5 Datenimport
57
5.1 Vorbereitungen zum Datenimport . . . . . . . . . . . . . . . . . . . . . .
57
5.2 Import der Sachdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
5.3 Import der geometrischen Daten . . . . . . . . . . . . . . . . . . . . . . .
59
5.4 Datenbereinigung der Geometriedaten
63
. . . . . . . . . . . . . . . . . . .
6 Methoden
67
6.1 Ableitungen innerhalb einer Klasse . . . . . . . . . . . . . . . . . . . . .
6.1.1
68
Methoden der Klasse BodenHorizont . . . . . . . . . . . . . . . .
68
6.1.1.1
Lagerungsdichte
. . . . . . . . . . . . . . . . . . . . . .
68
6.1.1.2
Effektive Durchwurzelungstiefe eines Horizonts . . . . .
71
6.1.1.3
Nutzbare Feldkapazität eines Horizonts . . . . . . . . . .
72
Methoden der Klasse KlimaDatum . . . . . . . . . . . . . . . . .
72
6.1.2.1
Sättigungsdampfdruck . . . . . . . . . . . . . . . . . . .
73
6.1.2.2
Aktueller Dampfdruck . . . . . . . . . . . . . . . . . . .
73
6.1.2.3
Potenzielle Verdunstung nach Haude . . . . . . . . . . .
74
6.2 Ableitungen innerhalb einer Informationsebene . . . . . . . . . . . . . . .
74
6.1.2
6.2.1
Effektive Durchwurzelungstiefe eines Bodenprofils . . . . . . . . .
75
6.2.2
Nutzbare Feldkapazität des effektiven Wurzelraumes
. . . . . . .
79
6.2.3
Ableitung der mittleren kapillaren Aufstiegsrate . . . . . . . . . .
80
6.3 Verschneidung von Informationsebenen . . . . . . . . . . . . . . . . . . .
83
6.3.1
Vorbereitungen zur Kartenerzeugung . . . . . . . . . . . . . . . .
83
6.3.2
Verschneidung von Vektordaten mit Vektordaten . . . . . . . . .
86
6.3.3
Verschneidung von Raster- und Vektordaten . . . . . . . . . . . .
89
6.3.3.1
Rastergenerierung . . . . . . . . . . . . . . . . . . . . .
89
6.3.3.2
Wertzuweisung an Rasterpunkte
92
. . . . . . . . . . . . .
iv
INHALTSVERZEICHNIS
6.3.4
Verschneidung von Rasterdaten mit Rasterdaten . . . . . . . . . .
94
6.4 Probleme bei der Verschneidung . . . . . . . . . . . . . . . . . . . . . . .
97
6.5 Ableitungen für verschnittene Geometrien . . . . . . . . . . . . . . . . . 100
6.5.1
Dauer des kapillaren Aufstiegs . . . . . . . . . . . . . . . . . . . . 101
6.5.2
Mittlerer kapillarer Aufstieg . . . . . . . . . . . . . . . . . . . . . 104
6.5.3
Pflanzenverfügbares Bodenwasser . . . . . . . . . . . . . . . . . . 105
6.5.4
Sickerwasserrate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7 Erfahrungen und Ausblick
111
A Definition der Relationen
113
A.1 Neues Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
A.2 Schemata für alte Dateiformate . . . . . . . . . . . . . . . . . . . . . . . 117
B Tipps und Tricks
121
C Visualisierung
123
C.1 Rasterkarten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
C.2 Vektorkarten
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
D Hilfsprogramme Datenimport
125
D.1 Konvertierung der Sachdaten
. . . . . . . . . . . . . . . . . . . . . . . . 125
D.2 Konvertierung der Polygone . . . . . . . . . . . . . . . . . . . . . . . . . 126
E Beispielanfragen
127
Kapitel 1
Einleitung
Im Bereich der Informatik bilden Datenbanksysteme ein zentrales Thema. Ihre Kernaufgabe ist die effiziente Speicherung und Verwaltung großer Datenbestände. Abhängig
von der Struktur der Daten und der Komplexität der Anfragen an ein Datenbanksystem wird zwischen Datenbanksystemen für Standardanwendungen beziehungsweise Nichtstandardanwendungen unterschieden. Standardanwendungen zeichnen sich
dadurch aus, dass große Datenmengen primitiver (eindimensionaler) Datentypen mit
simplen Algorithmen und einfachen Integritätsbedingungen verwaltet werden. Sie treten
beispielsweise im Banken- und Versicherungswesen auf. Die Verwaltung erfolgt mithilfe
relationaler Datenbankmanagementsysteme (RDBMS), die seit etwa Mitte der
1970er Jahre entwickelt wurden. Nichtstandardanwendungen sind durch komplex strukturierte Objekte sowie aufwendigen Berechnungen und Anfragen auf diesen Objekten,
wie sie typischerweise im naturwissenschaftlich-technischen Bereich vorkommen, charakterisiert. Da relationale Datenbankmanagementsysteme nur bedingt für die Verwaltung
komplexer Daten und Anfragen geeignet sind, wurden seit etwa 1980 zwei weitere Arten
von Datenbankmanagementsystemen entwickelt, objektorientierte (OODBMS) und
insbesondere objekt-relationale Datenbankmanagementsysteme (ORDBMS),
wie zum Beispiel Oracle8i, das im Rahmen dieser Arbeit verwendet wird. Objektrelationale Datenbankmanagementsysteme erweitern die am weitesten entwickelten relationalen Datenbankmanagementsysteme um objektorientierte Ansätze. Hierzu sollten nach
Stonebraker[22] die Erweiterung um benutzerdefinierte Basistypen, die Unterstützung
komplexer Objekte und die Konzepte der Vererbung zählen. Verschiedene objektrelationale Datenbankmanagementsysteme unterstützen einige dieser geforderten Erweiterungen, momentan ist allerdings kein Anbieter auf dem Markt, der alle Forderungen
erfüllt.
Ein Beispiel für eine Nichtstandardanwendung ist der Bereich der geografischen Datenverarbeitung. In diesem Wissenschaftszweig werden Geografische Informationssysteme (GIS) eingesetzt, die räumliche Daten speichern, miteinander verknüpfen
und grafisch darstellen. Die Verwaltung der Daten kann dabei sowohl GIS-intern als
auch extern in einer angekoppelten Datenbank erfolgen. Geografische Informationssy-
1
2
KAPITEL 1. EINLEITUNG
steme werden in den unterschiedlichsten Bereichen eingesetzt. Anwendung finden sie
in der Verkehrs- und Bauplanung ebenso wie in der Geografie bei der Untersuchung
ökologischer Prozesse und Prozesszustände.
Im Rahmen mehrerer am Geographischen Institut der Universität Hannover durchgeführten DFG-Forschungsprojekte wurden Simulationsmodelle entwickelt, um Stoffverlagerungen in Landschaften vorherzusagen [7]. Unter Stoffverlagerungen sind in diesem Zusammenhang sowohl der Transport von Partikeln im Boden als auch Bodenerosion zu verstehen. Kenntnisse über diese Transportprozesse werden beispielsweise
benötigt, um durch Pflanzendünge- und schutzmittel verursachte stoffliche Belastungen
von Gewässern abzuschätzen, die durch Fließgewässer an Erosionssysteme angeschlossen sind. Üblicherweise sind die entwickelten Simulationsmodelle an ein Geografisches
Informationssystem gekoppelt.
Die Eingangsdaten der Simulationsmodelle sind vielfältig. Ihre Aufnahme, Verwaltung
und Speicherung erfolgt in sogenannten Informationsebenen. Eine Informationsebene enthält thematisch zusammenhängende Informationen über einen bestimmten Ausschnitt der realen Welt, beispielsweise den Boden, das Klima oder die Vegetation. Für
die Ableitung von Daten aus Eingangsdaten müssen gegebenenfalls mehrere Informationsebenen miteinander verknüpft werden. Zum Beispiel ist die Bodenfeuchte, die in der
Praxis nicht an allen Orten zu messen ist, für die Bodenerosion von zentraler Bedeutung und durch geeignete Verfahren quasiflächenhaft abzuschätzen. Diese Abschätzung
verknüpft die Informationsebenen Boden, Klima, Vegetation und Relief. Ein bei diesen Verknüpfungen auftretendes Problem ist, dass die Daten in unterschiedlichen Datenformaten vorliegen, die bei Berechnungen gegebenenfalls unter Informationsverlust
ineinander konvertiert werden müssen.
Geografische Informationssysteme sind primär entwickelt worden, um geometrische Operationen durchzuführen und Karten zu erzeugen. Datenbanksysteme hingegen sind für
die Speicherung und Verwaltung der an geometrische Informationen gebundenen Sachdaten den Geografischen Informationssystemen vorzuziehen.
Im Rahmen dieser Arbeit wird zunächst ein semantisches Datenmodell für Bodendaten entwickelt, das anschließend implementiert wird. Dieses Datenmodell enthält neben
den Sachdaten der verschiedenen Informationsebenen auch geometrische Informationen,
damit GIS-extern mehrere Informationsebenen an beliebigen Punkten miteinander verknüpft werden können. Desweiteren werden beispielhaft Methoden implementiert, die
aus Eingangsdaten mehrerer Informationsebenen neue Daten ableiten. Grundlage für die
Verknüpfungen der Eingangsdaten bilden die vom Niedersächsischen Landesamt für Bodenforschung herausgegebenen Auswertungsmethoden im Bodenschutz [17] und die von
der Ad-hoc-Arbeitsgruppe Boden der Geologischen Landesämter und der Bundesanstalt
für Geowissenschaften und Rohstoffe der Bundesrepublik Deutschland unter Leitung von
Werner Pälchen erarbeitete Bodenkundliche Kartieranleitung [1].
Die für die Methoden benötigten Eingangsdaten sind vom Geographischen Institut der
Universität Hannover, Abteilung Physische Geografie und Landschaftsökologie, bereit-
3
gestellt worden. Sie basieren auf Messungen in einem ca. 20 km südlich von Hildesheim gelegenen Untersuchungsgebiet (Groß-Ilde), das eine räumliche Ausdehnung von
ca. 3km × 3km km hat.
Aus diesen inhaltlichen Zielvorgaben ergibt sich für diese Arbeit der folgende Aufbau:
Kapitel 2 gibt eine Einführung in Geografische Informationssysteme, insbesondere werden die in Geografischen Informationssystemen üblichen Datenformate und Operationen
erläutert.
Kapitel 3 gibt einen Überblick über den Entwurf von Datenbanksystemen. Es werden die
Architekturprinzipien sowie die Phasen des Datenbankentwurfs vorgestellt und die in den
folgenden Kapiteln benötigten Konzepte des verwendeten semantischen Datenmodells
(UML) vorgestellt. Zusätzlich wird eine Einführung in das Relationenmodell gegeben,
das Grundlage des implementierten Datenmodells von Oracle8i ist. Oracle8i wird als
Datenbanksystem im Rahmen dieser Arbeit verwendet. Daher schließt Kapitel 3 mit
einem Überblick über die objekt-relationalen Konzepte dieses Datenbanksystems, die
über das Relationenmodell hinausgehen und stellt das Spatial Cartridge vor, das zur
Verwaltung räumlicher Daten entwickelt wurde.
Kapitel 4 befasst sich mit dem konkreten Entwurf eines Datenmodells für Bodendaten.
Es wird eine Anforderungsanalyse durchgeführt und externe Schemata entwickelt, die in
ein konzeptionelles Schema integriert werden. Das konzeptionelle Schema wird schließlich
in ein logisches Modell transformiert und implementiert.
Kapitel 5 beschreibt die zum Datenimport der zur Verfügung gestellten Daten notwendigen Schritte sowie die erforderliche Datenbereinigung.
In Kapitel 6 wird beispielhaft die Methode zur Ableitung der Sickerwasserrate implementiert. Diese Methode ist in mehrere Schritte zu unterteilen, die in den einzelnen Unterabschnitten erläutert werden. Hierzu zählen sowohl einfache Ableitungen neuer Daten
aus Ausgangsdaten als auch komplexe geometrische Berechnungen, die durch Methoden
des Spatial Cartridge ausgeführt werden. In diesem Zusammenhang werden räumliche
Indexe untersucht, die für eine effiziente Bearbeitung der räumlichen Anfragen an das
Datenbanksystem eingesetzt werden.
Kapitel 7 schließt die Arbeit mit einem Überblick über die gemachten Erfahrungen und
einen kurzen Ausblick auf zukünftige Entwicklungen ab.
4
KAPITEL 1. EINLEITUNG
Kapitel 2
Geografische Informationssysteme
2.1
Allgemeines
Geografische Informationssysteme (GIS) dienen der effizienten Speicherung, Verwaltung und Visualisierung räumlicher Daten (Objekte) der realen Welt. Sie sind gegenwärtig selbstverständliche Werkzeuge bei der Bearbeitung raumbezogener Fragestellungen in Forschung und Praxis. Generell können Geografische Informationssysteme
überall dort eingesetzt werden, wo Karten zur Planung, Dokumentation und Entscheidungsfindung genutzt werden, die Daten mit einem gemeinsamen Raumbezug miteinander verknüpfen. Als Beispiel sei hier lediglich die Analyse landschaftshaushaltlicher Prozesse, die Daten sowohl horizontal, als auch vertikal miteinander verknüpft, angeführt.
Im Gegensatz zu Standard-Datenbanksystemen werden in Geografischen Informationssystemen auch räumliche Informationen bereitgehalten. Jedes Objekt, das mit einem
GIS verwaltet wird, hat räumliche und Sachinformationen. Die räumlichen Informationen bestimmen die geographische Lage sowie die Ausdehnung, die Sachinformationen die
Eigenschaften des Objektes. Die Verwaltung der räumlichen Daten erfolgt im GIS. Die
Sachdaten können ebenfalls im GIS oder alternativ durch ein an das GIS gekoppeltes
Datenbanksystem verwaltet werden.
Dieses Kapitel gibt einen Überblick über die heutzutage in Geografischen Informationssystemen verwendeten Datenstrukturen und die gängigen Methoden und Operationen
zur räumlichen Datenanalyse. Betrachtet werden insbesondere der Speicherbedarf und
die Genauigkeit der unterschiedlichen Datenformate sowie der Aufwand verschiedener
Methoden unter Berücksichtigung der zugrunde liegenden Datenstruktur.
Zunächst folgt aber ein Abschnitt, in dem erläutert wird, wie Daten bereits bei der
Aufnahme grob in sogenannte Informationsebenen unterteilt werden.
5
6
2.2
KAPITEL 2. GEOGRAFISCHE INFORMATIONSSYSTEME
Informationsebenen
Zur Arbeit mit einem GIS werden Daten benötigt, die im Wesentlichen durch örtliche
Feldarbeiten (z.B. Vermessungen, geologische Stichproben) sowie Luftbilder und Satellitenaufnahmen gewonnen werden. Die Aufnahme der Daten erfolgt üblicherweise für
einen Ausschnitt der realen Welt, durch Bodenproben werden beispielsweise Bodeninformationen erhalten, durch Klimamessungen Informationen über das Klima. Die Daten
werden thematisch zusammengehörig als Daten einer Informationsebene bezeichnet,
die mehrere, möglichst alle, diesen Bereich betreffenden Informationen enthält.
Ein Layer ist ein thematischer Ausschnitt einer Informationsebene oder eine Kombination mehrere Attribute. In diesem Sinn ist auch eine Informationsebene ein Layer, da sie
mehrere Attribute kombiniert. Layer werden betrachtet, wenn einzelne Informationen
(verschiedener Informationsebenen) miteinander kombiniert werden sollen. Beispielsweise könnte die Temperaturverteilung (Informationsebene Klima) in Abhängigkeit von der
Vegetation (Informationsebene Nutzung) interessieren. Hierzu werden die entsprechenden Layer zueinander in Beziehung gesetzt, um Aussagen darüber zu machen, ob und
wie die Vegetation die Temperatur beeinflusst.
2.3
GIS-Daten
Es gibt eine Vielzahl geografischer Objekte und Phänomene, die durch ein GIS verwaltet werden. Diese Objekte variieren stark hinsichtlich Ausdehnung, Form, struktureller
Komplexität und ihrer Verteilung im Raum. Ein GIS muss daher sowohl kontinuierliche
Erscheinungen, die flächenhaft und quasi unbegrenzt im Raum auftreten (z.B. Temperatur der untersten Luftschicht), als auch diskrete Erscheinungen, d.h. abgrenzbare
Flächen (z.B. See), linienhafte Phänomene (z.B. Straße) sowie punkthafte Informationen
(z.B. geologische Bohrdaten) verwalten können. Für diese unterschiedlichen Anforderungen wurden mehrere Datenformate für Geografische Informationssysteme entwickelt,
um zum einen den Speicherplatzbedarf und zum anderen den Verlust an Information bei
der digitalen Codierung der Realdaten, zu minimieren. Die vier wichtigsten Datenformate, die von jedem GIS unterstützt werden sollten, sind Rasterdaten, Vektordaten,
Punktdaten und Sachdaten. Es ist anzumerken, dass einige Geografische Informationssysteme Punktdaten den Vektordaten unterordnen. Rasterdaten, Vektordaten und
Punktdaten sind geografische Daten, die die Lage, Form und Ausdehnung räumlicher
Objekte beschreiben, Sachdaten halten objektbezogene nichträumliche Informationen
vor. Ein GIS sollte neben diesen unterschiedlichen Datenstrukturen selbst, auch Methoden bereitstellen, die die unterschiedlichen räumlichen Datenformate mit minimalem
Informationsverlust ineinander konvertieren. In den folgenden Unterabschnitten werden
die unterschiedlichen räumlichen Formate, sowie ihre Vor- und Nachteile diskutiert.
2.3. GIS-DATEN
2.3.1
7
Rasterdaten
Rasterdaten werden eingesetzt, um kontinuierlich im Raum verteilte und flächenhafte Daten aufzunehmen. Dabei wird eine Fläche bzw. ein Raum äquidistant in Zellen
eingeteilt, sodass eine Matrixstruktur quadratischer bzw. würfelförmiger Rasterzellen
entsteht. Jedes solche Matrixelement wird bezüglich des betrachteten Sachdatums (Attribut) beziehungsweise einer Kombination von Sachdaten als homogen angesehen und
erhält einen Wert zugewiesen (Abbildung 2.1). Die entstandene Matrix wird abgespeiy
5
1
1
1
2
2
2
2
2
2
3
3
3
4
1
1
1
1
3
2
2
1
1
3
3
1
3
2
2
1
1
3
2
1
3
3
3
3
1
2
2
2
1
3
3
1
1
2
1
1
1
1
1
2
3
3
3
3
1
1
2
2
1
2
2
1
2
3
4
5
6
7
8
9
10
11
12
x
Abbildung 2.1: Rasterdaten
chert. Der Zugriff auf die einzelnen Rasterzellen der Matrix erfolgt über die Angabe von
Zeile und Spalte oder über die geografischen Koordinaten (in Abbildung 2.1 als x bzw.
y bezeichnet). Die Genauigkeit der Beschreibung räumlicher Objekte ist dabei abhängig
von der Auflösung des Rasters.
2.3.2
Vektordaten
Vektordaten werden eingesetzt, um linienhafte Elemente und homogene Flächen zu speichern. Linienhafte Elemente werden als Polygonzüge, homogene Flächen als geschlossene
Polygonzüge abgelegt (siehe Abbildung 2.2). Die Polygonzüge werden aus Punkten mit
Verbindungslinien zusammengesetzt, die mehrere Koordinaten besitzen. Innerhalb der
durch einen Polygonzug umschriebenen Fläche werden die Sachdaten als homogen angesehen.
2.3.3
Punktdaten
Punktdaten werden eingesetzt, um Stichproben an unregelmäßig im Raum verteilten
Standorten aufzunehmen. In manchen Geografischen Informationssystemen stellen Punktdaten ein eigenes Format dar, in anderen sind sie dem Vektorformat untergeordnet.
8
KAPITEL 2. GEOGRAFISCHE INFORMATIONSSYSTEME
y
4
3
2
1
1
2
4
3
4
3
1
2
x
Abbildung 2.2: Vektordaten
Punktdaten dienen der Darstellung und Verortung von Messpunkten aller Art. Üblicherweise werden die Punktdaten als Grundlage für eine flächenhafte Extrapolation von
Messwerten benutzt. Ein typisches Beispiel für diese Zuordnung ist die Verknüpfung von
an einem Standort gemessenen Daten (Punktdaten) mit einem zugeordneten (geschlossenen) Polygon. Die an dem Standort aufgenommenen Daten werden für alle durch das
Polygon umschlossenen Punkte als Referenzwerte angesehen. Grund für diese Extrapolation ist, dass in der Praxis nicht an jedem beliebigen Punkt Werte gemessen werden
können. Fachpersonal bestimmt daher Flächen, die bezüglich der aufgenommenen Daten gleiche oder zumindest sehr ähnliche die Daten beeinflussende Faktoren aufweisen
und ordnen diesen Flächen die für den Referenzstandpunkt erhaltenen Werte oder eine
Referenz auf diesen Standort zu.
2.3.4
Rasterdatenformat vs. Vektordatenformat
Das Rasterdatenformat und das Vektordatenformat sind für die Aufnahme flächenhafter
Phänomene die dominierenden Formate. Sie unterscheiden sich allerdings stark hinsichtlich des Speicheraufwands und der Genauigkeit der Beschreibung. Abhängig von der
realen Größe der Objekte im Verhältnis zu dem der Datenaufnahme zugrunde liegenden
Maßstab und den auf die Daten anzuwendenden Operationen, ist daher häufig eines
der beiden Datenformate vorzuziehen. Die Abbildungen 2.3 und 2.4 verdeutlichen diese
Problematik.
Gegeben ist ein Untersuchungsgebiet mit zwei flächenhaften Objekten (Ackerschlag,
Wald) und einem linienhaften Objekt (Abflussgraben). Wird dieses Untersuchungsgebiet wie in Abbildung 2.3 durch ein Raster überlagert, so fallen zwei Dinge auf:
1. Die flächenhaften Objekte Ackerschlag und Wald belegen viele Rasterzellen und
benötigen daher viel Speicherplatz.
2.3. GIS-DATEN
9
a b c d e f g h i j k l m n o
1
2
3
4
5
6
7
8
Ackerschlag
Abflussgraben
Wald
Rasterlinie
Abbildung 2.3: Abflussgraben zwischen Ackerschlag und Wald im Rasterdatenformat
2. In den Rasterzellen k1 − k8 treten zwei Attributwerte (Abflussgraben und Wald)
auf, jeder Rasterzelle kann aber nur ein Attributwert zugewiesen werden.
Das erste Problem ist, falls keine hoch aufgelösten Raster verwendet werden, durch
stark gestiegene und stark steigende Rechner- und Speicherkapazitäten vermutlich vernachlässigbar. Für das zweite Problem werden allerdings Entscheidungsregeln benötigt,
die den betreffenden Rasterzellen eindeutig einen Wert zuweisen. Hier kann nun auf
verschiedene Arten argumentiert werden:
1. Da der Abflussgraben in den betrachteten Rasterzellen weniger Raum als der Wald
einnimmt, wird diesen Zellen das Attribut Wald zugewiesen. Der Abflussgraben
bleibt unberücksichtigt.
2. Der Abflussgraben ist von großer bodenkundlicher Bedeutung und muss berücksichtigt werden. Den Zellen wird das Attribut Abflussgraben zugewiesen.
Je nach betrachtetem Problembereich ist eine der Alternativen vorzuziehen. Beispielsweise ist der Abflussgraben für Erosionsprozesse und damit für den Abfluss von Dünge- und
Pflanzenschutzmitteln in Gewässer von entscheidender Bedeutung. Die erste Alternative
vermindert daher beträchtlich den Informationsgehalt und auf diesen Daten berechnete
Simulationen wären mit einer großen Unsicherheit behaftet. Ordnet ein GIS allerdings
jeder Rasterzelle immer den Wert zu, der den meisten Raum der Rasterzelle einnimmt,
so schafft eine Verfeinerung des Rasters im vorliegenden Fall Abhilfe. Dadurch würde
allerdings, je nach Verfeinerung, ein Vielfaches an Datenmaterial zu speichern und zu
verwalten sein, ohne Erhöhung des Informationsgehalts für die flächenhaften Objekte
Ackerschlag und Wald bzw. mit nur minimal mehr Information für den Wald. Dies ist
aber, wie bereits erwähnt, eventuell vernachlässigbar. An dieser Stelle sei darauf hingewiesen, dass das eben beschriebene Problem der Speicherung linienhafter Daten im
Rasterformat ebenfalls bei der Beschreibung gekrümmter (linienhafter) Elemente auf-
10
KAPITEL 2. GEOGRAFISCHE INFORMATIONSSYSTEME
tritt.
Die Behandlung dieser Problematik ist in den verschiedenen verfügbaren Geografischen
Informationssystemen nicht einheitlich. Es existiert sowohl der oben beschriebene Ansatz, also die Zuordnung des räumlich größten Attributs an die Rasterzelle, als auch
Ansätze, die unterschiedlichen möglichen Attributen verschiedene Prioritäten zuordnen
und diese Prioritäten mit in den Entscheidungsprozess einbeziehen, ähnlich der zweiten
Alternative.
Für kleine und linienhafte Objekte ist allerdings eine angemessenere Datenstruktur zur
Speicherung entwickelt worden, das Vektorformat. Abbildung 2.4 veranschaulicht die
Speicherung der Objekte aus Abbildung 2.3 im Vektorformat.
Ackerschlag
Abflussgraben
Wald
Vektorlinie
Abbildung 2.4: Abflussgraben zwischen Ackerschlag und Wald im Vektorformat
Im Vektorformat werden lediglich die Stützstellen der Polygone (in geordneter Reihenfolge) abgespeichert. Für die Objekte Ackerschlag und Wald sind daher nur vier Werte
nötig, für den Abflussgraben reichen zwei Werte (Anfangs- und Endpunkt des Abflussgrabens) zur räumlichen Beschreibung aus.
Nicht geeignet sind Vektordaten allerdings zur Erfassung von quasi-kontinuierlichen
Flächendaten (z.B. Niederschlagsverteilung, Bilddaten, Höhenprofilen), die aus sehr vielen kleinen Objekten bestehen, also insgesamt eine stark heterogene Struktur aufweisen
und daher eine Vielzahl von Polygonen zur Beschreibung benötigen, die jeweils nur kleine
Flächen umfassen.
Neben der Speicherung der raumbezogenen Daten ist als weiterer Aspekt die Menge und
Komplexität der Methoden und Operationen auf den Daten für die Auswahl des
Datenformates von Bedeutung. Die Grundoperationen eines GIS werden im folgenden
Abschnitt erläutert.
2.4. GIS-OPERATIONEN
2.4
11
GIS-Operationen
Zur Analyse der aufgenommenen Daten sollte ein Geografisches Informationssystem eine
Grundmenge an Operationen unterstützen.
1. Konvertierungen und Generierung neuer Daten
Daten, die in einer Datenstruktur vorliegen, sollten mit möglichst geringem Informationsverlust in eine andere Datenstruktur konvertiert werden können. Zusätzlich sollte die Möglichkeit bestehen, abgeleitete Daten in einer anderen als der
Eingangsdatenstruktur zu speichern.
Beispiel:
Informationen über die Beschaffenheit des Geländes eines Beobachtungsgebietes
(Geländemodell) werden üblicherweise im Rasterdatenformat aufgenommen. Aufgenommener Wert ist die Höhe, aus der die Hangneigung und die Ausrichtung
(Exposition) des Geländes für die den Rasterpunkten zugeordneten Flächen berechnet werden. Sind nun für die Kartenerzeugung oder Berechnung abgeleiteter
Werte die Höhenlinien des Untersuchungsgebietes von Interesse, so bietet sich in
natürlicher Weise das Vektorformat für die weitere Bearbeitung an, da dieses Format linienhafte Elemente, beispielsweise Höhenlinien, wie oben erläutert deutlich
effizienter unterstützt als das Rasterformat.
2. Räumliche/Geometrische Selektion
Eine häufige Anfrageart an ein Geografisches Informationssystem sind Punkt- und
Bereichsanfragen, wie in den Abbildungen 2.5 und 2.6 dargestellt. Gesucht sind alle
x
Abbildung 2.5: point-query
Abbildung 2.6: window-query
Objekte, die einen gegebenen Punkt bzw. ein gegebenes Polygon geometrisch beinhalten oder schneiden. Ein Sonderfall der Bereichsanfragen sind Fenster-Anfragen
(Window-Queries). In diesem Fall ist der Anfragebereich kein beliebiges Polygon,
sondern ein achsenparalleles Rechteck wie es beispielsweise mit der Maus auf Karten aufgezogen werden kann.
3. Nachbarschaftsanfragen
Gesucht sind benachbarte Objekte eines ausgezeichneten Objektes (Abbildung
2.7) oder eine Menge von Objekten, die innerhalb einer bestimmten Umgebung
um ein Objekt liegen (Abbildung 2.8). Eine Beispiel für eine Nachbarschaftsanfra-
12
KAPITEL 2. GEOGRAFISCHE INFORMATIONSSYSTEME
Abbildung 2.7: Nachbarobjekte
Abbildung 2.8: Objekte innerhalb
einer bestimmten Entfernung
ge wäre: Welche Gebäude liegen an einer bestimmten Straße ?“ Diese Anfragen
”
sind insbesondere bei dynamischen Simulationsprozessen von Bedeutung, da sich
die Objekte gegenseitig beeinflussen und es daher von Interesse ist, in welcher
räumlichen Beziehung bestimmte Objekte stehen.
4. Flächenverschneidungen
Durch die Verschneidung (overlay) zweier Informationsebenen entsteht ein neuer
Layer, der beide Informationsebenen zusammenfasst und die Auflösung des Layers
verfeinert (siehe Abbildung 2.9).
1
b
2
3
Informationsebene
Boden
1a
a
4
Verschneidung
d
c
4a
1b
4d
2b
3d
2c
3c
Informationsebene
Nutzung
Abbildung 2.9: Verschneidung zweier Informationsebenen
Abhängig von der Wahl des Datenformates der räumlichen Daten erfordern Nachbarschaftsanfragen und Flächenverschneidungen einen unterschiedlich hohen Aufwand und
es stellt sich heraus, dass der Rasteransatz für Flächenverschneidungen dem Vektoransatz überlegen ist, während bei Nachbarschaftsanfragen das Vektorformat Vorteile bietet.
Die Flächenverschneidung im Vektorformat erfordert die Berechnung von Schnittpunkten verschiedener Polygone, um daraus neue Polygone abzuleiten. Hierbei entsteht ein
weiteres Problem und zwar, dass aufgrund kaum zu vermeidender Digitalisierungsfehler
eine Vielzahl kleinster Flächen entstehen können, die nach der Verschneidung manuell
korrigiert werden müssen. Für die Flächenverschneidung im Rasterformat ist es ausreichend, jeweils Rasterzellen an der gleichen Stelle miteinander zu verknüpfen. Für diese
Operation im Rasterformat muss allerdings gewährleistet sein, dass die zu verschneidenden Raster denselben Ursprung, dieselbe Orientierung und denselben Maßstab, also
2.4. GIS-OPERATIONEN
13
insbesondere dieselbe Rasterzellengröße, besitzen. Bei genauer Betrachtung der Flächenverschneidung fällt auf, dass im Vektorformat neue geometrische Objekte gebildet werden, denen die Sachdaten der urspränglichen Informationsebenen angeheftet werden.
Es findet demnach eine Berechnung auf den geometrischen Daten statt. Die Flächenverschneidung im Rasterformat ordnet lediglich bereits vorhandenen Rasterzellen neue
Werte zu. Hier werden also keine Berechnungen, sondern ausschließlich Vergleiche und
Zuweisungen durchgeführt. Dies erklärt die wesentlich schnellere Berabeitung der Verschneidungsoperationen im Rasterformat.
Nachbarschaftsanfragen hingegen sind für im Vektorformat vorliegende Daten effizienter
zu bearbeiten. Es muss im Vektorformat lediglich berechnet werden, welche Objekte an
der Grenze zu einem Objekt oder in einer bestimmten Entfernung liegen. Die geometrischen Informationen über die Ausdehnung der Objekte können dann aufgrund der
Zuordnung von Objektdaten und Geometriedaten leicht erhalten werden. Im Rasterformat müssen die einzelnen Rasterzellen untersucht werden und die Überprüfung stattfinden, ob ein Punkt noch zu einem Objekt gehört. Die Ausmaße von Objekten sind im
Rasterformat also nur schwierig zu bestimmen.
Zusammenfassend ist festzuhalten, dass sowohl das Raster- als auch das Vektorformat
Vor- und Nachteile bieten, sodass die Entscheidung für ein Format abhängig von den zu
erwartenden Anfragen getroffen werden sollte, soweit es nicht bereits durch die Art der
Datenaufnahme festgelegt ist.
Weitere Informationen zu Geografischen Informationssystemen finden sich zum Beispiel
in [4] und [16] oder auch im Internet [24].
14
KAPITEL 2. GEOGRAFISCHE INFORMATIONSSYSTEME
Kapitel 3
Datenbanksysteme
Gegenstand dieses Kapitels sind Datenbanksysteme (DBS) unter besonderer Betrachtung des in dieser Arbeit verwendeten Datenbanksystems Oracle8i. Zunächst wird
erläutert aus welchen Komponenten ein DBS zusammengesetzt ist und welche Phasen
beim praktischen Entwurf einer Datenbank existieren. Es schließt sich ein Überblick über
die Modellierungssprache UML sowie das Relationenmodell an, in dem die grundlegenden Konzepte dieser Datenmodelle dargestellt werden. Abschließend werden die
später verwendeten objektrelationalen Konzepte von Oracle8i erläutert, und es wird
ein Überblick über das Spatial Cartridge gegeben, in dem die in ihm definierten Objekttypen und Methoden vorgestellt werden.
3.1
Allgemeines
Ein Datenbanksystem (DBS) besteht aus zwei Teilen:
• Datenbestand
• Datenbankmanagementsystem
Der Datenbestand ist die Menge der durch das Datenbankmanagementsystem
(DBMS) verwalteten Daten. Das DBMS selbst ist eine Sammlung von Programmen,
die für die Verwaltung des Datenbestandes notwendig sind. Zugriffe auf die Daten erfolgen durch das DBMS, das als zwischen Benutzer und Daten geschaltete Schicht die
Konsistenz der Daten gewährleistet. Für die Benutzer stellt es eine Datenbanksprache zur Verfügung. Die Datenbanksprache gliedert sich in einen Teil zur Datendefinition
(Data Definition Language DDL) und einen Teil zur Datenmanipulation (Data Manipulation Language DML), beispielsweise für Anfragen und Änderungen des Datenbestandes. Durch das DBMS und die zentrale Verwaltung der Daten werden folgende Punkte
gewährleistet:
15
16
KAPITEL 3. DATENBANKSYSTEME
• alle Daten werden in einem integrierten Bestand nach Möglichkeit jeweils nur einmal und dauerhaft gespeichert, wodurch weitgehend Redundanzfreiheit gewährleistet ist
• Daten bleiben über die jeweilige Lebensdauer des auf sie zugreifenden Programms
hinaus erhalten
• Daten sind konsistent
• gleichzeitiger Transaktionen mehrerer Benutzer werden synchronisiert
Hervorzuheben ist, dass durch ein DBS verschiedene Daten in einem Bestand integriert
werden und so die Möglichkeit besteht, sehr flexibel mithilfe der DML Anfragen an das
DBS zu stellen, das diese Daten beliebig miteinander verknüpfen kann.
Die Struktur der zu verwaltenden Daten wird dem DBMS durch die DDL übergeben.
Der Inhalt dieser Datenbeschreibung wird auch als Datenbank-Schema bzw. als MetaDaten bezeichnet. Äquivalente Ausdrücke für die gespeicherten Daten sind DB-Zustand,
Inhalt oder auch Ausprägung der Datenbank.
Ein Datenbankschema ist aus mehreren Bestandteilen zusammengesetzt. Das theoretische Minmum bilden
• Strukturbeschreibungen
• Integritätsbedingungen und
• Zugriffsrechte.
Die Strukturbeschreibungen beschreiben die Struktur der zu verwaltenden Daten,
beispielsweise welche Objekte durch das DBMS zu verwalten sind und welche Attribute
die Objekte besitzen. Die Notation erfolgt häufig durch Datenmodelle. Ein Datenmodell ist eine Sammlung von Konzepten zur Datenbeschreibung und -strukturierung. Integritätsbedingungen sichern die Konsistenz der Daten. Ein Beispiel einer Integritätsbedingung für ein Reservierungssystem einer Fluggesellschaft wäre, dass kein Sitzplatz
eines Fluges mehr als einmal reserviert werden darf. Schließlich schränkt die Vergabe
von Zugriffsrechten die Anfragemöglichkeiten der einzelnen Benutzer ein. Dies dient
insbesondere dem Datenschutz.
In der Praxis kommen zu diesen drei Bestandteilen üblicherweise noch weitere hinzu.
Dazu gehören Trigger, die für die Einhaltung komplexer Integritätsbedingungen eingesetzt werden, Sichten (Views), um Benutzern nur einen (für sie relevanten) Ausschnitt
der Datenbank zu zeigen sowie Zugriffe darauf zu ermöglichen und prozedurale Erweiterungen der DML, die selbst mengenorientiert arbeitet.
3.2. DATENBANKENTWURF
3.2
17
Datenbankentwurf
Beim Entwurf einer Datenbank ist zwischen der Architektur und dem physischen Entwurf eines Datenbanksystems zu unterscheiden.
3.2.1
Architekturprinzipien
Nach einem Vorschlag von ANSI/SPARC (American National Standard Institute /
System Planning and Requirement Comittee) aus dem Jahr 1978 gliedert sich die Architektur eines Datenbanksystems in drei Ebenen:
• interne Ebene
• konzeptionelle Ebene
• externe Ebene
Die interne Ebene beschreibt die physische Organisation der Daten. Es wird eine
vollständige Beschreibung der Speicherung der Daten und der Zugriffspfade gegeben.
Insbesondere werden hier auch Indexe auf den Daten angegeben. Die konzeptionelle
Ebene beschreibt eine Gesamtsicht auf die zu verwaltenden Daten. Das konzeptionelle Schema enthält keine Details über Speicherstrukturen, sondern beschreibt Objekte,
Datentypen, Beziehungen, benutzerdefinierte Operationen und zusätzliche Bedingungen
(Integritätsbedingungen) der Datenbank. Zur Beschreibung der konzeptionellen Ebene werden semantische Datenmodelle (zum Beispiel (E)ER-Modell [8] oder UML [20])
verwendet. Die externe Ebene beinhaltet verschiedene Sichten der Benutzer auf die
Daten. Jede externe Sicht beschreibt einen Teil der Datenbank, der für einen bestimmten
Benutzer oder eine Benutzergruppe relevant ist. Auch für diese Beschreibungen werden
semantische Datenmodelle eingesetzt. Die Trennung in verschiedene Architekturebenen
hat zum Ziel, einen gewissen Grad an Datenunabhängigkeit zu gewährleisten. Die
zwei Arten von Datenunabhängigkeit sind:
• physische Datenunabhängigkeit: Möglichkeit innerhalb der internen Ebene
Veränderungen vorzunehmen, ohne dass das konzeptionelle (oder das externe)
Schema verändert werden muss.
Beispiel: Einführung zusätzlicher Zugriffsstrukturen (Indexe), die den Zugriff auf
die Daten beschleunigen sollen. Allerdings sind nur im Idealfall gar keine Änderungen der anderen Ebenen notwendig.
• logische Datenunabhängigkeit: Möglichkeit am konzeptionellen Schema Änderungen vorzunehmen, ohne dass das externe Schema oder Anwendungsprogramme
verändert werden müssen.
Beispiel: Erweiterung des Schemas. Alle Sichten und Anwendungsprogramme auf
ursprünglichen Daten bleiben unverändert erhalten.
18
KAPITEL 3. DATENBANKSYSTEME
3.2.2
Phasen des Datenbankentwurfs
Es wird zwischen vier Phasen des Entwurfs einer Datenbank unterschieden:
1. Anforderungsanalyse:
In dieser Phase werden die Anforderungen an die zu entwerfende Datenbank gesammelt und analysiert. Hierbei werden sowohl die zu verwaltenden Objekte, als
auch Methoden, die auf und zwischen den Objekten realisiert werden sollen, mit
einbezogen.
2. Konzeptioneller Entwurf:
Das konzeptionelle Schema beschreibt mithilfe eines semantischen Datenmodells
Objekte, Beziehungen und Integritätsbedingungen, die sich aus der Anforderungsanalyse ergeben. In diesem Schema werden keine Implementierungsdetails angegeben.
3. Logischer Entwurf:
Nach dem Entwurf des konzeptionellen Schemas wird dieses Modell in das Datenmodell des Datenbanksystems transformiert, das für die Anwendung zum Einsatz
kommen soll. Das Ergebnis dieser Transformation ist das logische Schema. Ein
weit verbreitetes und in dieser Arbeit verwendetes Datenmodell ist das RelationenModell.
4. Physischer Entwurf: In diesem Entwurf werden die internen Speicherstrukturen,
Zugriffspfade auf die Daten und Details über die Organisation der Dateien der
Datenbank festgelegt.
Grundlage einer Datenbank ist ein Datenbankschema in einem semantischen Datenmodell. Als semantische Datenmodelle existieren unter anderem das für die Datenbankentwicklung klassische (Extended-)Entity-Relationship-Modell ((E)ER-Modell)
und die für objektorientierte Analyse- und Entwurfsmethoden entwickelte Unified Modelling Language (UML). Die UML-Notation ist auch in anderen Bereichen der Informatik, wie beispielsweise der Softwareentwicklung, weit verbreitet und es stehen für
die Modellierung mithilfe von UML ausgereifte Entwicklungswerkzeuge (z.B. Rational
Rose) zur Verfügung. Sie ist allerdings sehr viel umfassender als das EER-Modell, da
sie den gesamten Softwareentwicklungsprozess beschreibt. Unter anderem werden für
die objektorientierte Entwicklung Klassendiagramme als Konzept zur Verfügung gestellt, die aber nur einen Ausschnitt des gesamten Spektrums von UML bilden. Für die
Modellierung der Datenbankschemas werden Klassendiagramme in der UML-Notation
verwendet. Da UML in dieser Arbeit als semantisches Datenmodell eingesetzt wird, bilden die Konzepte von UML den Gegenstand des nächsten Abschnitts.
3.3. UNIFIED MODELLING LANGUAGE (UML)
3.3
19
Unified Modelling Language (UML)
Entscheidend für die Ausdrucksfähigkeit eines semantischen Datenmodells sind die vom
Datenmodell zur Verfügung gestellten Konzepte. UML bietet an Modellierungskonzepten
unter anderem Klassen mit entsprechenden Attributen und Methoden, Generalisierungen sowie (qualifizierte) Assoziationen an. Die für den Entwurf der Datenbank
benötigten Modellierungskonzepte von UML werden in den folgenden Unterabschnitten
kurz erläutert. Eine vollständige(re) Auflistung und Beschreibung von UML findet sich
zum Beispiel in [9].
3.3.1
Klassen
Zunächst sollen die Begriffe Klasse, Objekt und Instanz erläutert werden. Ein Objekt der realen Welt besitzt bestimmte Eigenschaften (Attribute). Gleich strukturierte
Objekte sind durch dieselbe Menge an Attributen bestimmt, wobei sich die Ausprägung
der Attribute unterscheiden kann. Beispiel: Jeder Rechner (Klasse) hat einen Prozessor
(Attribut), zwei verschiedene Rechner (Objekt, Instanz) können aber mit unterschiedlichen Prozessoren (Ausprägung) ausgestattet sein. Für gleich strukturierte Objekte wird
eine Klasse eingeführt, deren Attribute denen der Objekte entsprechen. Ein Objekt ist
dann eine Instanz der Klasse, d.h. es besitzt die Attribute der Klasse mit bestimmten
Attributausprägungen. Objekt und Instanz werden im weiteren Text häufig synonym
verwendet.
Klassen werden in UML durch Rechtecke gekennzeichnet und mit ihrem Klassennamen
benannt (Abbildung 3.1). Zusätzlich zum Klassennamen können Klassen noch Attribu-
Klassenname
attribut:Typ=initialer Wert
Klassenname
operation(argumentliste):rückgabetyp
Abbildung 3.1: Klassen in UML
te und Methoden angeheftet werden. Während der Klassenname ein Objekt bezeichnet
(z.B. Standort oder Boden), beschreiben die Attribute Eigenschaften dieser Objekte
(z.B. die Koordinaten eines Standortes oder den Typ eines Bodens). Die einer Klasse
zugeordneten Methoden und Operationen können die Attribute der Klasse setzen, modifizieren, auslesen oder miteinander verknüpfen. Ein Beispiel für eine Methode wäre die
Umwandlung von Koordinaten eines Standortes von einem Koordinatensystem in ein
anderes.
Eine Klasse kann abstrakt deklariert werden. Ist dies der Fall, so wird die Klasse im
physischen Entwurf nicht implementiert, sondern dient lediglich als Schnittstelle zwi-
20
KAPITEL 3. DATENBANKSYSTEME
schen verschiedenen Klassen. Notiert wird eine abstrakte Klasse durch Kursivschrift des
Klassennamens.
3.3.2
Generalisierung
Generalisierung wird eingesetzt, falls verschiedene Klassen Gemeinsamkeiten, aber auch
Unterschiede besitzen. Abbildung 3.2 zeigt ein Beispiel. In dem Beispiel sind drei Klassen
Person
Name
Adresse
Geburtsdatum
Alter()
Angestellter
Student
Einstellungsdatum
MatrikelNr
Gehalt
Semester
Fachbereich
Studiengang
Jahresgehalt()
Abbildung 3.2: Generalisierung in UML
dargestellt, wie sie in einem Datenbankschema der Personalabteilung einer Universität
vorkommen könnten. Instanzen der Klassen Angestellter und Student besitzen beide einen
Namen, eine Adresse und einen Geburtstag. Daher wird eine Klasse Person eingeführt,
der genau die gemeinsamen Attribute dieser beiden Klassen zugeordnet werden. Es findet
eine Generalisierung statt. Die Klassen Angestellter und Student sind Unterklassen der
Oberklasse Person.
Neben diesen gemeinsamen Attributen sind in den jeweiligen Unterklassen noch weitere Attribute angegeben, beispielsweise wird für jeden Angestellten sein Gehalt und
das Einstellungsdatum mit abgespeichert. Diese beiden Attribute sind aber lediglich
für Instanzen der Klasse Angestellter und nicht für Instanzen der Klasse Student von
Bedeutung. Daher werden sie nicht in die Oberklasse Person mit aufgenommen.
Wird nun eine Instanz einer Unterklasse gebildet, so besitzt diese Instanz alle Attribute der Unterklasse und erbt zusätzlich die Attribute der Oberklasse. Eine Instanz von
Student hat demnach die sechs Attribute Name, Adresse, Geburtsdatum, MatrikelNr,
Semester und Studiengang.
3.3. UNIFIED MODELLING LANGUAGE (UML)
21
Ebenso wie Attribute können auch Methoden in Oberklassen definiert werden, die sich
auf die Unterklassen, in denen zusätzliche Methoden angegeben werden können, vererben. Vorstellbar wäre hier eine Methode zur Berechnung des Alters einer Person für
Instanzen von Person zu definieren, während die Berechnung des Jahresgehalts eine Methode der Klasse Angestellter ist. Das Alter von Personen kann dann für Instanzen beider
Unterklassen berechnet werden, während das Jahresgehalt nur für Angestellte ermittelt
wird.
3.3.3
Assoziationen
Assoziationen repräsentieren Beziehungen zwischen Instanzen von Klassen und können
mit einem Namen benannt werden (Abbildung 3.3). An einer Assoziation sind mindeName der Assoziation
Klasse A
Klasse B
Abbildung 3.3: Assoziation in UML
stens zwei Klassen beteiligt. Den an einer Assoziation beteiligten Klassen werden Kardinalitäten zugeordnet. Diese bestimmen die Anzahl der an einer Assoziation beteiligten
Instanzen. Die Notation für Kardinalitäten in UML zeigt Abbildung 3.4, ein Beispiel ist
in Abbildung 3.5 dargestellt. Die Angaben der Kardinalitäten im Beispiel legen fest,
1
*
0..1
m..n
Klasse
genau ein
Klasse
viele (Null oder mehr)
Klasse
optional (Null oder Eins)
Klasse
numerische Angabe
Abbildung 3.4: Kardinalitäten in UML
dass jeder Student an genau einer Universität studiert, an einer Universität aber mehrere Studenten eingeschrieben sind. Weiterhin hört ein Student eine beliebige Anzahl an
Vorlesungen und eine Vorlesung wird von mehreren Studenten besucht. Als weiteres Konzept von UML ist in dem Beispiel eine Assoziationsklasse Studienzeit dargestellt. Eine
Assoziationsklasse ist an eine Assoziation geheftet und durch die Angabe der an der
Assoziation beteiligten Klassen eindeutig bestimmt. Im Beispiel besteht zwischen den
Klassen Student und Universität die Beziehung studiert an, an die die Assoziationsklasse
Studienzeit geheftet ist, die die Dauer der Zeit des Studiums an einer Universität dieser
Beziehung hinzufügt. Die Assoziationsklasse besitzt die beiden Attribute Beginn und
Ende, die Anfang und Ende der Zeit des Studierenden an einer Universität bezeichnen.
22
KAPITEL 3. DATENBANKSYSTEME
Studienzeit
Beginn
Ende
1
Universität
*
studiert an
n
m
Student
Vorlesung
Abbildung 3.5: Beispiel für Kardinalitäten
Assoziationsklassen können ebenso wie andere Klassen Methoden besitzen. Im Beispiel
wäre eine Methode zur Berechnung des Zeitintervalls denkbar. Zu bemerken ist, dass eine Instanz einer Assoziationsklasse durch die Angabe der an der Assoziation beteiligten
Instanzen von Klassen eindeutig festgelegt ist.
3.4
Relationenmodell
Nachdem ein Datenbankschema in einem semantischen Datenmodell entwickelt worden
ist, ist die nächste Phase des Datenbankentwurfs die Transformation in ein implementiertes Datenmodell. Die wichtigsten verfügbaren implementierten Datenmodelle sind
das hierarchische Modell, das Netzwerkmodell, das Relationenmodell, sowie
eine Erweiterung des Relationenmodells, das objektrelationale Modell. Das hierarchische und das Netzwerkmodell sind satzorientierte Datenmodelle, die Datensätze über
Referenzen miteinander verknüpfen. Sie haben heute fast nur noch historische Bedeutung. Grundlage vieler moderner DBMS ist das Relationenmodell. Es wurde in den
1970er Jahren entwickelt und verarbeitet Daten mengenorientiert. Es ist im Vergleich
zu den satzorientierten Datenmodellen sehr einfach strukturiert und besteht im Wesentlichen aus flachen Tabellen (Relationen), in denen Zeilen einzelnen Datenobjekten
entsprechen.
3.4.1
Modellierungskonzepte
An Modellierungskonzepten stellt das Relationenmodell Objekte und Attribute zur
Verfügung, Assoziationen sind durch Verknüpfungen von Relationen, auch Relationenschema genannt, bzw. Tupeln rekonstruierbar. Eine Relation ist mathematisch wie
folgt definiert:
Gegeben seien n nicht notwendigerweise unterschiedliche Wertebereiche D1 , D2 , . . . , Dn ,
die nur atomare Werte (Zahlen, Zeichenketten, ...) enthalten. Dann ist eine Relation R
3.4. RELATIONENMODELL
23
definiert als Teilmenge des kartesischen Produkts der n Wertebereiche:
R ⊆ D 1 × D2 × . . . Dn
Ein Element der Menge R heißtTupel.
Im Datenbankbereich werden den einzelnen Komponenten der Tupel Namen gegeben
und als Attribute bezeichnet.
Das folgende einfache Beispiel verdeutlicht diese Vorgehensweise anhand einer Relation
Student. Ein Student ist vereinfacht als eine Teilmenge des folgenden Kreuzproduktes
festgelegt:
Student ⊆ number(10) × char(20) × char(8) × number(2)
Hierbei repräsentiert number(10) die Matrikelnummer, char(20) den Namen, char(8)
das Fach und number(2) die Semesteranzahl des Studenten. Diese vier Werte sind die
Attribute der Relation Student.
Im Relationenschema würde diese Relation daher wie in Abbildung 3.6 notiert werden.
Student
(Matrikelnummer:number(10),Name:char(20),Fach:char(8),
Semesteranzahl:number(2))
Abbildung 3.6: Relation Student
Ein relationales Datenbankschema ist eine Sammlung mehrerer Relationen bzw.
Relationenschemata mit verschiedenen Namen, wobei sich auch die Attribute je Relation
unterscheiden müssen.
Genaugenommen ist zwischen dem Schema einer Relation, das durch die Wertebereiche
gegeben ist und der aktuellen Ausprägung zu differenzieren. Im obigen Beispiel wäre als
Tupel auch (0,’abc’,’xyz’,99) korrekt, allerdings wird es kein Tupel mit dieser Ausprägung
in der Datenbank geben.
3.4.2
Modellinhärente Integritätsbedingungen
Zu einem vollständigen Relationenschema gehören neben der Deklaration von Relationenund Attributnamen, sowie der Wertebereiche der Attribute noch die im folgenden beschriebenen modellinhärenten Integritätsbedingungen:
• Zu jedem Relationenschema muss ein Primärschlüssel definiert sein. Im obigen
Beispiel ist dies Matrikelnummer. Dies wird durch die Unterstreichung des Attributes ausgedrückt. Durch einen Primärschlüssel können Tupel in Relationen eindeutig
identifiziert werden, d.h. es gibt in einer Relation keine zwei Tupel, deren Attributausprägungen mit Ausnahme des Primärschlüsselattributs übereinstimmen.
24
KAPITEL 3. DATENBANKSYSTEME
• Für die Modellierung von Beziehungen werden Fremdschlüssel eingesetzt. Für
Fremdschlüssel muss die folgende Bedingung erfüllt sein: B 0 sei Schlüssel einer
Relation R2 . Dann ist B Fremdschlüssel der Relation R1 bzgl. der Relation R2 ,
falls für jedes Tupel t1 aus R1 ein Tupel t2 aus R2 existiert, sodass die Werte von
B und B 0 übereinstimmen. Formal: ∀(t1 : R1 )∃(t2 : R2 )(t1 .B = t2 .B 0 ).
• Attribute dürfen bis auf Primarschlüsselattribute optional sein, also Nullwerte
annehmen.
3.4.3
Transformation von UML ins Relationenschema
UML bietet mehr Modellierungskonzepte als das Relationenmodell an, Grundlage eines
in UML erstellten konzeptionellen Schemas bilden aber Klassen mit ihren Attributen,
sowie Assoziationen zwischen Klassen. Daher wird zunächst die Transformation dieser
Basiskomponenten betrachtet.
• Klassen: Eine Klasse in UML entspricht einer Relation im Relationenmodell. Der
Name der Klasse wird ebenso wie die Attribute üblicherweise übernommen, kann
aber auch geändert werden. Für jede Relation wird ein (eventuell extra eingeführter) Primärschlüssel ausgezeichnet, der der Objektidentität von Instanzen der Klassen in UML entspricht. Abstrakt deklarierte Klassen werden nicht transformiert,
da sie nur bei Generalisierungen eingesetzt werden und die Attribute dann den
Attributen der Unterklasse hinzugefügt werden.
• Assoziationen: Für jede Assoziation wird eine Relation erstellt. Attribute dieser
Relationen sind die an die Assoziation gehefteten Attribute, die Attribute eventuell vorhandener Assoziationsklassen, ein gegebenenfalls wieder einzuführender
Primärschlüssel, sowie Fremdschlüssel für die an der Assoziation beteiligten Klassen bzw. deren vorher entworfene Relationen.
Die weiteren in Abschnitt 3.3 erläuterten Modellierungskonzepte von UML werden wie
folgt transformiert. Für abstrakte Oberklassen, die bei Generalisierungen eingeführt werden, werden keine Relationen erzeugt. Die Attribute der abstrakten Oberklassen werden in die Attributliste der Unterklassen mit aufgenommen. Ist eine Oberklasse nicht
abstrakt deklariert, so wird diese Klasse wie oben beschrieben in eine Relation transformiert und in den Unterklassen ein Fremdschlüsselattribut eingeführt, dass auf ein Tupel
in der Relation der Oberklasse verweist.
3.5
Oracle 8i
In dieser Arbeit wird das objektrelationale Datenbanksystem Oracle8i verwendet. Die
verwendeten objektrelationalen Konzepte bilden den Gegenstand dieses Abschnitts.
3.5. ORACLE 8I
3.5.1
25
Objektrelationale Datenbanksysteme
Wie bereits an der Transformation eines in UML entwickelten konzeptionellen Schemas
in das Relationenmodell zu sehen ist, ist das Relationenmodell zu restriktiv, um objektorientierte Modellierungen direkt zu übersetzen. Aus diesem Grunde und der immer
größer werdenden Verbreitung objektorientierter (OO) Techniken bei der Softwareentwicklung, wurde auch im Datenbankbereich mit der Entwicklung sogenannter Objektorientierter Datenbanksysteme (OODBS) begonnen. Diese bieten die Funktionalität herkömmlicher DBS, besitzen aber ein an objektorientierte Programmiersprachen
angelehntes Datenmodell. Im Jahr 1989 wurde ein Kriterienkatalog entwickelt, der die
Mindestanforderungen an OODBS festlegt und als sogenanntes OODB-Manifesto [2]
bekannt geworden ist.
Alternativ zur vollständigen Neuentwicklung OODBS wurde ein zweiter Weg beschritten, der die Relationalen Datenbanksysteme (RDBS) um objektorientierte Konzepte erweitert. Das Ergebnis dieser Erweiterung sind Objektrelationale Datenbanksysteme (ORDBS). Diese sollten auch die Punkte des Kriterienkatalogs erfüllen, allerdings sind keine DBS auf dem Markt, die dies vollständig leisten.
3.5.2
Komplexe Datentypen in Oracle8i
Im Wesentlichen wird in dieser Arbeit das objektrelationale Konzept der komplexen
Datentypen verwendet, das im Hinblick auf Oracle8i nun dargestellt wird.
In Oracle8i können sogenannte benutzerdefinierte (user-defined) Objekttypen erzeugt
werden. Ein Objekttyp besteht dabei aus einem Namen, einer Attributmenge und Methoden. Attributbereiche dürfen dabei selbst wieder objektwertig sein.
Beispiel:
CREATE TYPE Typ_Person AS OBJECT (
Name
VARCHAR2(20),
Geburtsdatum DATE,
Anschrift
TYP_ADRESSE,
MEMBER FUNCTION age RETURN NUMBER,
PRAGMA RESTRICT_REFERENCES (age,WNDS)
);
------
Name
Geburtstag
Adresse (Objekttyp)
Methode
Restriktionen für Methode
Das Beispiel definiert einen neuen Objekttyp Person. Attribute dieses Objekttyps sind
Name, Geburtsdatum und Anschrift, wobei der Wertebereich von Anschrift selbst wieder objektwertig ist. Schließlich wurde für diesen Objekttyp noch eine Methode age()
definiert. Die Implementierung dieser Methode erfolgt getrennt von der Objekttypdefinition. Die letzte Zeile informiert Oracle8i über Seiteneffekte der Methode und schränkt
Zugriffsrechte auf Tabellen gegebenenfalls ein.
Ein definierter Objekttyp kann im Folgenden auch zur Deklaration von Tabellen verwendet werden.
26
KAPITEL 3. DATENBANKSYSTEME
Beispiel:
CREATE TABLE Mitarbeiter OF Typ_Person;
Eine so deklarierte Tabelle kann als klassische Tabelle mit normalen Attributen (Objekttyp aufgelöst) oder als Tabelle mit einem (unbenannten) Attribut, auf das durch
den Operator value zugegriffen werden kann, interpretiert werden.
Zusätzlich können bei der Deklaration von Tabellen mithilfe eines Objekttyps auch Bedingungen, beispielsweise die Auszeichnung eines Primärschlüssels mit angegeben werden. Im obigen Beispiel würde unter der vereinfachenden Annahme, dass eine Person
durch ihren Namen eindeutig zu identifizieren sei, Name wie folgt als Primärschlüssel
einer neuen Tabelle festgelegt:
CREATE TABLE Mitarbeiter OF Typ_Person (
Name PRIMARY KEY);
Nach der Deklaration von Methoden für Objekttypen wird die Implementierung der Methoden mithilfe der Sprache PL/SQL separat vorgenommen. Die Implementierung folgt
dabei folgendem Schema (am Beispiel der Methode age für den Objekttyp Typ Person):
CREATE TYPE Typ_Person AS
MEMBER FUNCTION age return NUMBER IS
-- Variablendeklarationen
BEGIN
-- Methodenrumpf
END;
END;
Definierte Methoden können in SQL-Statements wie Attribute genutzt werden, wobei
hinter dem Methodennamen lediglich noch mögliche Parameterwerte geklammert übergeben werden:
SELECT P.Name, P.age()
FROM
Mitarbeiter;
Neben Objekttypen unterstützt Oracle8i auch zwei Arten von Kollektionstypen, Arrays und geschachtelte Tabellen (nested tables). Arrays sind allerdings für Anfragen nicht praktikabel, da sie nur als Einheit gelesen und geschrieben werden können
und innerhalb eines SQL-Statements kein Zugriff auf einzelne Arrayelemente möglich
ist. Geschachtelte Tabellen werden eingesetzt, falls ein Attribut mehrere Tupel aufnehmen soll. Ein Beispiel wäre die Speicherung mehrerer Adressen (verschiedene Wohnsitze)
einer Person. Dies kann wie folgt implementiert werden. Zunächst wird ein Objekttyp
Typ Adresse für Adressen erzeugt. Anschließend wird ein Typ Typ Adressen Tabelle definiert, der die Definition einer Tabelle ist und als Attribut den Objekkttyp Typ Adresse
besitzt.
CREATE TYPE Typ_Adresse AS OBJECT (
Stadt
VARCHAR2(10),
Strasse
VARCHAR2(20),
Hausnummer NUMBER
3.5. ORACLE 8I
27
);
CREATE TYPE Typ_Adressen_Tabelle
AS TABLE OF Typ_Adresse;
Als geschachtelte Tabelle wird dieser Typ dann wie folgt genutzt:
CREATE TABLE Person (
Name
VARCHAR2(10),
Adressen Typ_Adressen_Tabelle )
NESTED TABLE Adressen
STORE AS Wohnsitze;
Die Werte der geschachtelten Tabelle werden in der nach store as angegebenen Tabelle abgelegt. Intern speichert Oracle8i die Werte der Tupel aller geschachtelten Tabellen dieser Tabelle darin. Der Zugriff auf die geschachtelte Tabelle erfolgt mithilfe des
Schlüsselwortes the.
INSERT INTO THE (
SELECT Adressen
FROM
Person
WHERE Name = ’xyz’
)
VALUES (’abcde’,’fghij’,0);
Eventuell kann bei diesem insert-Statement ein Fehler auftreten, der vermieden wird,
indem die Tabelle zunächst durch einen leeren Konstruktor initialisiert wird.
INSERT INTO Person
VALUES( ’xyz’,Typ_Adressen_Tabelle() );
Der nächste Abschnitt beschreibt das Spatial Cartridge von Oracle8i.
3.5.3
Oracle8i Spatial
Für die Speicherung, Verwaltung und Analyse räumlicher Daten bietet Oracle8i eine
Sammlung integrierter Funktionen und Prozeduren an, die unter dem Namen Oracle8i
Spatial, kurz Spatial, zusammengefasst sind. Die in Spatial verwendeten Datentypen
und Formate entsprechen der vom Open-GIS-Consortium erarbeiteten Norm (siehe
auch [18]). In diesem Abschnitt wird erläutert, wie räumliche Daten mittels Spatial in
einer Datenbank abgelegt werden, wie Anfragen zu formulieren sind und welche Arten
der Indexierung in Spatial existieren, um die Anfragen effizient zu bearbeiten.
3.5.3.1
Speicherung räumlicher Daten
Für die Speicherung von Objekten mit einer räumlichen Komponente im objektrelationalen Schema von Oracle8i wird eine beliebige vom Benutzer anzulegende Tabelle benötigt,
die eine Spalte vom Objekttyp MDSYS.SDO GEOMETRY besitzt. In dieser Tabelle wird für jede geometrische Instanz eine eigene Zeile angelegt. Bevor der Objekttyp
28
KAPITEL 3. DATENBANKSYSTEME
MDSYS.SDO GEOMETRY genauer betrachtet wird, soll kurz erläutert werden, welches
Datenmodell Spatial verwendet.
Das Spatial zugrunde liegende Datenmodell ist hierarchisch aufgebaut und besteht aus
Elementen, Geometrien und Layern. Räumliche Daten werden als Layer abgespeichert, die aus Geometrien zusammengesetzt sind, die wiederum aus Elementen bestehen.
Elemente sind die Basiseinheiten eines geometrischen Objektes. In Spatial sind dies
Punkte, Linienzüge und Polygone. Geometrien repräsentieren ein räumliches Merkmal, das aus primitiven Elementen zusammengesetzt ist. Eine Geometrie kann aus nur
einem Element bestehen, das eine Instanz eines primitiven Typs ist. Ebenso kann eine
Geometrie aber auch aus einer homogenen bzw. heterogenen Menge primitiver Datentypen zusammengesetzt sein. Ein Layer ist eine heterogene Sammlung von Geometrien,
die alle dieselbe Attributmenge besitzen.
Der Objekttyp SDO GEOMETRY ist in Spatial wie folgt definiert:
CREATE TYPE sdo_geometry AS OBJECT (
SDO_GTYPE
NUMBER,
SDO_SRID
NUMBER,
SDO_POINT
SDO_POINT_TYPE,
SDO_ELEM_INFO MDSYS.SDO_ELEM_INFO_ARRAY,
SDO_ORDINATES MDSYS.SDO_ORDINATE_ARRAY );
Das erste Attribut SDO GTYPE ist ein numerischer Wert, der den Typ der Geometrie
angibt. Möglichen Attributwerte und ihre Bedeutung sind der Tabelle aus Abbildung 3.7
zu entnehmen. Der Geometrietyp Collection kann in Oracle 8i5 außer aus den primitiven
Wert
0
1
2
3
Geometry Type
UNKNOWN GEOMETRY
POINT
LINESTRING
POLYGON
4
Collection
5
6
7
MULTIPOINT
MULTILINESTRING
MULTIPOLYGON
Beschreibung
wird ignoriert
Geometrie enthält einen Punkt
Geometrie enthält einen Streckenzug
Geometrie enthält ein Polygon mit oder
ohne Loch
Geometrie ist heterogene Sammlung von
Elementen
Geometrie hat mehrere Punkte
Geometrie hat mehrere Streckenzüge
Geometrie hat mehrere disjunkte Polygone
Abbildung 3.7: Werte für SDO GTYPE
elementaren Datentypen noch aus folgenden Datentypen zusammengesetzt sein:
• 2-D Arc-Line-Strings (durch Kreisbögen zusammengesetzte Streckenzüge)
• 2-D Arc-Polygons (durch Kreisbögen zusammengesetzte Polygone)
• 2-D Circles (Kreise)
3.5. ORACLE 8I
29
• 2-D Optimized Rectangles (Rechtecke)
Das Attribut SDO SRID ist für zukünftige Zwecke reserviert. Es soll als Fremdschlüssel
für eine Referenztabelle zur Definition von Geometrien dienen.
Das Attribut SDO POINT ist ein Objekttyp mit drei numerischen Attributen X, Y
und Z. Sind die beiden folgenden Attribute SDO ELEM INFO und SDO ORDINATES
beide null und ist dieser Wert ungleich null gesetzt, so werden die Werte von X und Y als
Koordinaten einer Punktgeometrie aufgefasst. Dies ist die optimale Art der Speicherung
von Punktdaten. Ist eines der beiden folgenden Attribute nicht null, so wird dieser Wert
von Spatial ignoriert.
Das Attribut SDO ELEM INFO ist eine Array von Zahlen, dessen Größe variiert. Die in
diesem Array angegebenen Werte bestimmen die Interpretation der Werte des Attributs
SDO ORDINATES. Die Größe des Arrays in ein Vielfaches von 3, da für jede Geometrie,
die abgespeichert wird, drei Zahlen in diesem Attribut angegeben werden müssen. Diese
drei Zahlen sind:
1. SDO STARTING OFFSET bestimmt den Offset des ersten Punktes eines Elementes in SDO ORDINATES relativ zum Anfang des Arrays SDO ORDINATES.
Der erste Punkt im Array hat den Offset 1.
2. SDO ETYPE bestimmt den Typ des Elementes. Ist durch SDO GTYPE bereits
festgelegt, um was für Elemente es sich handelt, so wird hier redundante Information abgespeichert. Diese Situation tritt ein, falls es sich um eine homogene Menge
an geometrischen Elementen handelt. Ist allerdings in SDO GTYPE angegeben,
dass eine heterogene Menge an geometrischen Elementen vorliegt, so spezifiziert
dieser Wert den genauen Typ der einzelnen Elemente. Erlaubt sind Werte von 0
bis 5. Der Wert 0 wird bisher nicht unterstützt, die Werte 1, 2 und 3 stehen für
einfache Elemente. Die Werte 4 und 5 repräsentieren zusammengesetzte Elemente.
Für diese hat das Attribut SDO ETYPE mindestens einmal drei Werte als header
und anschließend n-mal drei Elemente für die einfachen Elemente. n ist dabei die
Anzahl der einfachen Elemente, aus denen das Element zusammengesetzt ist. Ein
Beispiel findet sich in Abbildung 3.8.
3. SDO INTERPRETATION ist ein von SDO ETYPE abhängiger Wert. Ist in
SDO ETYPE angegeben, dass es sich um ein zusammengesetztes Element handelt
(Wert 4 oder 5), so gibt dieser Wert die Anzahl der Untertypen an, aus denen
das Element besteht. Hat SDO ETYPE einen der Werte 1, 2 oder 3, so bestimmt
SDO INTERPRETATION, wie die Werte in SDO ORDINATE zu diesem Element
zu interpretieren sind. Beispielsweise wird für ein durch SDO ETYPE als Polygon
definiertes Objekt durch SDO INTERPRETATION bestimmt, ob die einzelnen
Punkte in SDO ORDINATES durch Geraden oder Kreisbögen miteinander verbunden werden. Möglich ist auch, dass das Polygon nur ein Rechteck beschreibt
oder einen Kreis, sodass zwei bzw. drei Punkte zur Beschreibung des geometrischen
Objektes ausreichen.
30
KAPITEL 3. DATENBANKSYSTEME
Eine vollständige Beschreibung der Kombinationsmöglichkeiten und Werte der Attribute SDO ETYPE und SDO INTERPRETATION findet sich in der OnlineDokumentation zu Oracle8i Spatial [23].
Das letzte Attribut SDO ORDINATES ist ein Array variabler Länge von Zahlen, die
die Koordinaten der Ränder der einzelnen Elemente bestimmen, aus denen das Geometrieobjekt besteht. Die Werte in diesem Array sind immer nach Dimensionen geordnet.
Soll zum Beispiel ein Polygon abgespeichert werden, dessen Rand aus 2-dimensionalen
Punkten besteht, so hat das Array die Form (x1 , y1 , x2 , y2 , x3 , y3 , . . .). Sind die Punkte
3-dimensional, so ergibt sich ein Array mit folgender Struktur: (x1 , y1 , z1 , x2 , y2 , z2 , . . .).
Bisher unterstützt Spatial allerdings nur zweidimensionale geometrische Objekte. Die
Koordinaten der Elemente werden in diesem Array direkt nacheinander ohne bestimmte
Trenn- oder Steuerungszeichen aufgelistet. Die letzte Koordinate eines Elements steht
daher direkt vor der ersten Koordinate des nächsten Elements.
Abbildung 3.8 zeigt ein Beispiel für das Anlegen eines geometrischen Objektes vom Objekttyp SDO GEOMETRY. Der Wert SDO GTYPE = 3 definiert das Objekt als ein
y
(2,6)
6
5
(1,5)
(6,5)
4
3
2
(5,6)
(3,4)
(4,4)
(3,3)
(4,3)
(1,2)
SDO_GEOMETRY column = (
SDO_GTYPE = 3
SDO_SRID = NULL
SDO_POINT = NULL
SDO_ELEM_INFO = (1,3,1, 19,3,1)
SDO_ORDINATES = (1,2 , 2,1 , 5,1 , 6,2 , 6,5 ,
5,6 , 2,6 , 1,5 , 1,2 ,
3,3 , 4,3 , 4,4 , 3,4 , 3,3 ) )
(6,2)
1
(2,1)
(5,1)
x
1
2
3
4
5
6
Abbildung 3.8: Polygon mit Loch (Inselpolygon)
Polygon, eventuell mit Loch. SDO SRID bekommt grundsätzlich den Werte null zugewiesen, da es von Spatial noch nicht verwendet wird. SDO POINT ist ebenfalls auf
null gesetzt. Der Grund dafür ist, dass es sich nicht um eine Punkt-Geometrie handelt.
Dies ist auch daraus zu ersehen, dass die nächsten beiden Arrays nicht null gesetzt sind.
SDO ELEM INFO ist ein Array mit sechs Einträgen, die Gesamtgeometrie besteht folglich aus zwei Elementen. Der erste Wert 1 in diesem Array gibt an, an welcher Position
(Offset vom Anfang) des Arrays SDO ORDINATES, die erste Geometrie beginnt. Sie
beginnt demnach mit dem ersten Eintrag in SDO ORDINATES. Die 3 an der zweiten
Position gibt den Typ des betreffenden geometrischen Objektes an, in diesem Fall ein
Polygon. Der dritte Wert 1 besagt, dass die Punkte des Polygons durch gerade Linien
miteinander verbunden werden. Diese drei Arrayelemente definieren die Struktur des
ersten geometrischen Objektes. Hätte das Array SDO ELEM INFO keine weiteren Einträge, so würden alle in SDO ORDINATES vorkommenden Werte zu einem Polygon
3.5. ORACLE 8I
31
zusammengesetzt. Da SDO ELEM INFO aber noch weitere Einträge besitzt, setzt sich
die Gesamtgeometrie noch aus weiteren Elementen zusammen.
Der vierte Eintrag (19) gibt den Offset vom Beginn des Arrays SDO ORDINATES für
das zweite Element an, aus dem das Gesamtgeometrie besteht. Das bedeutet, dass nur
die ersten 18 Einträge der ersten Geometrie zugeordnet sind. Es ist hierbei zu beachten,
dass für ein geschlossenes Polygon der erste und letzte Wert in SDO ORDINATES übereinstimmen müssen. Daher sind 18 Koordinaten zur Beschreibung des ersten Objektes
notwendig, obwohl es nur aus acht Punkten und demnach 16 Koordinaten besteht. Die
weiteren Werte von SDO ELEM INFO sind für die zweite Geometrie ebenso wie für die
erste zu interpretieren, da es sich auch bei dem zweiten Element um ein Polygon handelt,
das aus geraden Linien zusammengesetzt ist. Die Information, dass das Gesamtobjekt
ein Polygon mit Loch ist, ist implizit in der Definition vorhanden, da das zweite Objekt
vollständig im ersten enthalten ist.
Es wäre auch möglich, das zweite Objekt als Rechteck zu definieren, das bereits durch
zwei Punkte eindeutig beschrieben ist. Das zweite Tripel in SDO ELEM INFO müsste
dazu in (1,3,1,19,3,3) abgeändert werden. Die letzte 3 im Array gibt dann an, dass es
sich beim zweiten Objekt um ein Rechteck handelt. Entsprechend würden in dem Array
SDO ORDINATES zwei Punkte, also vier Koordinaten, zur Beschreibung der zweiten
Geometrie ausreichen.
Das erzeugte Objekt kann nun in der Spalte einer Tabelle abgelegt werden, die vom
Typ MDSYS.SDO GEOMETRY ist. Die Definition einer Tabelle mit einem räumlichen
Attribut folgt der üblichen Syntax:
CREATE TABLE expanse (
id
integer,
shape MDSYS.SDO_GEOMETRY
);
Ist eine solche Tabelle angelegt worden, so muss in einer weiteren, vom Benutzer anzulegenden Relation, ein Eintrag für diese Tabelle und ihr räumliches Attribut vorgenommen
werden, um Anfragen an und Operationen auf den geometrischen Daten durchführen zu
können. Diese Relation enthält Metadaten über Tabellen mit Attributen vom Typ MDSYS.SDO GEOMETRY und wird mit SDO GEOM METADATA bezeichnet. Dieser
Name ist fest vorgegeben. Die Relation muss aber vom Benutzer selbst angelegt und
verwaltet werden. Der Aufbau dieser Relation ist wie folgt:
CREATE TABLE SDO_GEOM_METADATA (
TABLE_NAME VARCHAR2(30),
COLUMN_NAME VARCHAR2(30),
DIMINFO
MDSYS.SDO_DIM_ARRAY );
Für jede Relation mit räumlichen Daten muss in dieser Relation ein Tupel angelegt
werden. TABLE NAME gibt dabei den Namen der Relation und COULMN NAME
den Namen der Spalte vom Typ MDSYS.SDO GEOMETRY an. DIMINFO ist ein Array
variabler Länge des Objekttyps SDO DIM ARRAY, wobei die Länge des Arrays der
Dimension der räumlichen Daten entspricht. SDO DIM ARRAY ist definiert als
32
KAPITEL 3. DATENBANKSYSTEME
CREATE TYPE SDO_DIM_ARRAY as VARRAY(4) of SDO_DIM_ELEMENT;
und SDO DIM ELEMENT wiederum ist definiert als:
CREATE TYPE SDO_DIM_ELEMENT as OBJECT (
SDO_DIMNAME
VARCHAR2(64),
SDO_LB
NUMBER NOT NULL,
SDO_UB
NUMBER NOT NULL,
SDO_TOLERANCE NUMBER NOT NULL );
SDO DIMNAME gibt hierbei den Namen und SDO LB bzw. SDO UB die untere bzw.
obere Grenze bezüglich der Dimension an. SDO TOLERANCE bestimmt, um welchen
Wert sich Koordinaten maximal unterscheiden dürfen, damit sie von Spatial noch als
gleich angesehen werden. Die Reihenfolge der Dimensionen im DIMINFO-Array muss
mit der Reihenfolge der Koordinaten in SDO ORDINATES übereinstimmen, da Spatial
dies voraussetzt. Das heißt, falls die Koordinaten als (x1 , y1 , . . . , xn , yn ) in SDO ORDINATES angegeben sind, muss auch in dem DIMINFO-Array zunächst die Informationen
über die x-Dimension und danach die Information über die y-Dimension angegeben sein.
Es sind hier auch mehr Dimensionen möglich, die Methoden von Spatial unterstützen
allerdings nur zweidimensionale Daten.
3.5.3.2
Anfragemodell
Spatial benutzt ein Zwei-Ebenen-Anfrage-Modell (two-tier query model), um
räumliche Anfragen zu bearbeiten (siehe Abb. 3.9). Das bedeutet, dass räumliche Anfragen in zwei Operationen aufgeteilt werden, deren Ergebnis das exakte Resultat liefert.
Die zwei Operationen werden als Primärfilter bzw. Sekundärfilter bezeichnet. Es ist
aber nicht zwingend notwendig, beide Filter in Anfragen zu benutzen. Dies dient in
erster Linie der Effizienzsteigerung.
Aufgabe des Primärfilters ist es, aus der Gesamtmenge der geometrischen Daten in
möglichst kurzer Zeit eine Teilmenge (Kandidatenmenge) herauszufiltern, die als Eingabe an den Sekundärfilter übergeben wird. Diese indexbasierte Primärfilter-Operation
benutzt als Eingabe approximierte Geometrieinformationen, um den Rechenaufwand zu
verringern. Das Ergebnis der Operation des Primärfilters ist eine Obermenge des exakten
Resultats.
Der Sekundärfilter führt anschließend exakte, meistens teure Operationen auf der vom
Primärfilter übergebenen Kandidatenmenge aus und liefert die exakte Ergebnismenge
der Anfrage.
Ein wesentlicher Faktor für die Bearbeitungszeit räumlicher Anfragen ist die Selektivität des Primärfilters, da die Zeit, die Primärfilter-Operationen im Vergleich zu den
Sekundärfilter-Operationen benötigten, praktisch vernachlässigbar ist. Daher ist eine hohe Selektivität des Primärfilters wünschenswert. Bestimmt wird sie durch Indexe auf
den geometrischen Daten.
3.5. ORACLE 8I
Menge
geometrischer
Daten
33
Primärfilter
Menge
an
Kandidaten
Sekundärfilter
exakte
Ergebnismenge
Enthält mindestens
die Menge des exakten
Ergebnisses
Abbildung 3.9: two-tier query model
3.5.3.3
Indexe auf räumlichen Daten
Zur Verringerung von Antwortzeiten bei Anfragen an eine Datenbank werden Indexe
eingeführt. Indexe werden auf einem Attribut (oder einer Attributkombination) einer
Relation definiert. Die Auswahl dieses Attributes bzw. dieser Attribute ist abhängig von
den erwarteten Anfragen. Typische Anfragen, für deren Bearbeitung räumliche Indexe
benötigt werden, sind:
• Bereichsanfragen (window-query): Welche Objekte liegen in einem bestimmten
Bereich (window-query) oder überdecken einen gegebenen Punkt ?
• Räumlicher Verbund (spatial join): In welcher räumlichen Beziehung stehen
Objekte zueinander ?
Die Einträge eines räumlichen Index sind abhängig von den Koordinaten der räumlichen
Objekte (Geometrien). Sie sind allerdings nicht mehrdimensional, sondern angeordnete
Integer-Werte. Dies bedeutet, dass den Integer-wertigen Indexeinträgen Teilflächen des
gesamten Raumes (Kacheln) zugeordnet werden. Das Prinzip der Indexerstellung für
räumliche Daten wird nun erläutert.
Bei der Erstellung eines Indexes mit Spatial wird der Koordinatenraum, der alle Geometrien enthält, in kleinere Teilflächen (Kacheln) zerlegt, die den Raum partitionieren.
Dieser Zerlegungsprozess wird als tessellation bezeichnet. In einem ersten Schritt wird
der gesamte Koordinatenraum entlang der Seitenhalbierenden in vier gleich große Kacheln zerlegt. Spatial bietet nun zwei mögliche Vorgehensweisen an:
• Fixed Indexing: alle Kacheln haben gleiche Größe und Form
• Hybrid Indexing: Größe und Form der Kacheln variieren
Beim fixed indexing wird der erste Schritt mit den entstandenen kleineren Kacheln wiederholt, bis ein Abbruchkriterium erfüllt ist. Das Ergebnis ist eine Zerlegung des Koordi-
34
KAPITEL 3. DATENBANKSYSTEME
natenraumes in Kacheln, die alle dieselbe Größe und Form haben (siehe Abb. 3.10 oben).
Für jede Kachel wird abgespeichert mit welchen Geometrien sie interagiert. Beim hy-
2
0
22
23
32
33
20
21
30
31
02
03
12
13
00
01
10
11
3
1
Abbildung 3.10: Zerlegung einer Fläche und Zuordnung des z-Codes
brid indexing werden zwei Zerlegungen des Koordinatenraumes vorgenommen. Einerseits
wird der Prozess des fixed indexing durchgeführt, zusätzlich wird aber noch eine zweite
Zerlegung vorgenommen, die immer nur die Kacheln weiter teilt, die mit dem Rand einer
Geometrie interagieren, wie in Abbildung 3.11 dargestellt. Auch dies wird wiederholt, bis
ein Abbruchkriterium erfüllt ist. Der Vorteil der Erzeugung zweier Indexe ist, dass der
durch das fixed indexing erstellte Index schnelle Ergebnisse für den Primärfilter liefert,
während der hybride Index die Geometrien relativ genau approximiert und dadurch den
Rechenaufwand für die nachfolgenden Methoden verringert. Mögliche Abbruchkriterien
des tessellation-Prozesses sind beispielsweise die Größe der Kacheln oder eine maximale
Anzahl von Kacheln, die für die Überdeckung einer Geometrie verwendet werden. Die
1. Teilung
2. Teilung
3. Teilung
4. Teilung
Abbildung 3.11: Variable Kachelgröße bei hybrider Indexierung
numerische Codierung der entstandenen Flächen zur Zuweisung an Indexwerte erfolgt
3.5. ORACLE 8I
35
durch den z-Code. Die unteren Grafiken in Abbildung 3.10 veranschaulichen einen sequenziellen Durchlauf durch die erzeugten Kacheln mithilfe einer raumfüllenden Kurve.
Mehr zu diesem Thema findet sich zum Beispiel in [19].
3.5.3.4
Operationen auf räumlichen Daten
In diesem Unterabschnitt werden kurz die von Spatial zur Verfügung gestellten Operatoren und Funktionen vorgestellt. Diese lassen sich grob unterteilen in geometrische
Funktionen, räumliche Operatoren und Hilfsmethoden zur Indexerstellung.
• Geometrische Funktionen des objektrelationalen Modells
Die geometrischen Funktionen bilden den Kern der von Spatial für die Verwaltung
geometrischer Daten zur Verfügung gestellten Methoden. Im Einzelnen sind dies:
– SDO GEOM.SDO AREA(geometry, dim array):
Berechnet die Fläche eines zweidimensionalen Polygons. Dabei bestimmt geometry das zu untersuchende Objekt vom Typ MDSYS.SDO GEOMETRY und
dim array das zugehörige Array mit den Dimensionsinformationen. Dies wird
üblicherweise aus der Tabelle SDO GEOM METADATA ausgelesen.
– SDO GEOM.SDO LENGTH(geometry, dim array):
Berechnet die Länge bzw. den Umfang einer Geometrie. Die Parameter entsprechen denen der Methode SDO GEOM.SDO AREA().
– SDO GEOM.RELATE(geometry1, dim array1, mask, geometry2,
dim array2):
Untersucht zwei Geometrien, um ihre räumliche Beziehung zueinander zu bestimmen. Die Parameter geometry1, geometry2, dim array1 und dim array2
geben die zu untersuchenden Geometrien und Dimensionsinformationen an.
Mithilfe des Parameters mask können dieser Methode verschiedene Parameter übergeben werden, die angeben, welche Beziehung getestet werden soll.
Die möglichen Parameter sind ANYINTERACT, CONTAINS, COVEREDBY, COVERS, DISJOINT, EQUAL, INSIDE, OVERLAPBDYDISJOINT,
OVERLAPBDYINTERSECT und TOUCH. Die genaue Bedeutung dieser
Parameter kann der Dokumentation zu Spatial [23] entnommen werden.
– SDO GEOM.SDO BUFFER(geometry, dim array, distance):
Generiert ein Polygon mit dem in distance übergebenen Abstand um das
Objekt geometry und liefert es als Rückgabewert.
– SDO GEOM.SDO POLY DIFFERENCE(geometry1, dim array1,
geometry2, dim array2):
Berechnet die Differenz (A\B) zweier als geometry1 und geometry2 übergebener Polygone und liefert das Ergebnis dieser Differenzbildung zurück.
36
KAPITEL 3. DATENBANKSYSTEME
– SDO GEOM.SDO POLY INTERSECTION(geometry1,dim array1,
geometry2, dim array2):
Berechnet den Durchschnitt zweier Polygone und gibt diesen zurück.
– SDO GEOM.SDO POLY UNION(geometry1, dim array1, geometry2, dim array2):
Berechnet die Vereinigung zweier Polygone und gibt diese zurück.
– SDO GEOM.SDO POLY XOR(geometry1, dim array1, geometry2,
dim array2):
Berechnet die symmetrische Differenz zweier Polygone und gibt diese zurück.
– SDO GEOM.VALIDATE GEOMETRY (geometry, dim array):
Überprüft die Gültigkeit der in geometry übergebenen Geometrien durch Vergleich mit der Typdefinition. Rückgabewert ist entweder true, falls die Geometrie ihrer Definition entspricht, false, falls die Geometrie fehlerbehaftet ist,
Spatial den Fehler aber nicht bestimmen kann oder eine Fehlernummer, falls
Spatial den Fehlertyp erkennt.
– SDO GEOM.VALIDATE LAYER(table name, column name,
pkey column, result table name):
Überprüft aller Geometrien einer in table name übergebenen Tabelle, die in
column name eine Spalte vom Typ MDSYS.SDO GEOMETRY besitzt und
schreibt das Ergebnis dieser Überprüfung in eine als result table name angegebene Tabelle. pkey column ist Primärschlüssel von table name und muss
mit übergeben werden.
– SDO GEOM.WITHIN DISTANCE(geometry1, dim array1, distance, geometry2, dim array2):
Überprüft, ob zwei Geometrien innerhalb eines bestimmten Abstandes voneinander liegen und liefert im positiven Fall true zurück. Ist der Abstand der
Geometrien größer als angegeben ist der Rückgabewert false.
• Räumliche Operatoren
Räumliche Operatoren unterscheiden sich von den räumlichen Funktionen und
Methoden durch die Art ihrer Rückgabewerte. Sie liefern im Gegensatz zu den differenzierten Werte der Methoden lediglich true oder false zurück. Sie werden daher
in den where-Klauseln eines select-Statements als Filter eingesetzt, um die Anzahl
aufwendigeren und teuren Methodenaufrufe zu reduzieren. In Spatial existieren
drei räumliche Operatoren:
– SDO FILTER(geometry1, geometry2, params):
Dieser Operator wird eingesetzt, um eine Kandidatenmenge an räumlichen
Objekten für weitere Untersuchungen zu identifizieren. Basierend auf dem
räumlichen Index überprüft dieser Operator, ob Objekte mit den gleichen, bei
der Indexierung erzeugten Kacheln, interagieren. Ist dies der Fall, so wird true
zurückgeliefert, andernfalls false. Dieser Operator ist lediglich als Primärfilter
3.5. ORACLE 8I
37
einsetzbar.
– SDO RELATE(geometry1, geometry2, params):
Mit diesem Operator wird getestet, ob die in geometry1 und geometry2
übergebenen Objekte in einer bestimmten räumlichen Beziehung zueinander stehen. Die zu untersuchende Beziehung wird in params angegeben. Beziehungen, die überprüft werden können entsprechen denen der Methode
SDO GEOM.SDO RELATE(). Dieser Operator liefert true zurück, falls die
angegebene Beziehung zwischen den Objekten besteht, andernfalls false. Er
ist sowohl Primär-, als auch Sekundärfilter, bestimmt also im Gegensatz zu
SDO FILTER() kein approximiertes, sondern das exakte Ergebnis.
– SDO WITHIN DISTANCE(T.column, aGeom, params):
Dieser Operator überprüft, ob der Abstand zweier Objekte kleiner als ein vorgegebener Wert ist. T.column ist dabei ein räumliches Attribut einer Tabelle,
also vom Typ MDSYS.SDO GEOMETRY. Auf dieser Spalte muss ein räumlicher Index angelegt sein. In aGeom wird eine beliebige Geometrie übergeben,
die aus einer Tabelle gelesen oder temporär erzeugt werden kann (zum Beispiel Anfragefenster). Ist der Abstand kleiner als der vorgegebene Wert, so
ist der Rückgabewert true, andernfalls false.
• Indexerstellung im objektrelationalen Modell
Für die Indexerstellung und Indexverwaltung bietet Spatial die üblichen SQLKommandos an. Der Typ eines räumlichen Index ist MDSYS.SPATIAL INDEX.
Das Anlegen eines räumlichen Index wird durch die folgende Anweisung realisiert:
CREATE INDEX indexname ON Tabellenname(Spaltenname)
INDEXTYPE IS MDSYS.SPATIAL_INDEX
[PARAMETER];
Die zu übergebenden Parameter bestimmen die Größe der bei der Indexierung erzeugten Kacheln und die Art der Indexierung. Entscheidend hierfür sind die Werte
der Parameter SDO LEVEL für die Anzahl der Teilungen beim fixed indexing und
SDO NUMTILES für die Anzahl der Kacheln pro Geometrie bei der hybriden Indexierung. Die möglichen Kombinationen dieser beider Parameter sind in Abbildung
3.12 angegeben.
SDO LEVEL
nicht angegeben
>= 1
>= 1
nicht angegeben
SDO NUMTILES
nicht angegeben
nicht angegeben
>= 1
>= 1
Art der Indexierung
Fehler
fixed indexing
hybrid indexing
nicht unterstützt
Abbildung 3.12: Wertekombinationen von SDO LEVEL und SDO NUMTILES
Gelöscht wird ein räumlicher Index, wie andere Indexe auch, durch das Kommando
drop index [force].
38
KAPITEL 3. DATENBANKSYSTEME
Für die Bestimmung der Werte von SDO LEVEL bzw. SDO NUMTILES bietet Spatial einige Hilfsmethoden an, die in der Online-Dokumentation genauer beschrieben sind. Es soll lediglich eine Methode Erwähnung finden, da sie direkt für die
Indexerstellung verwendet kann:
SDO TUNE.ESTIMATE TILING LEVEL(table name, column name,
maxtiles, type of estimate):
Diese Methode schätzt einen Wert für SDO LEVEL, der bei der Erstellung eines
räumlichen Index auf der Spalte column name der Tabelle table name benutzt
werden kann. Der Parameter maxtiles gibt die maximale Anzahl an Kacheln an,
die bei der Indexerzeugung gebildet werden dürfen, type of estimate bestimmt ein
der Schätzung zugrunde liegendes Modell. Der durch diese Methode ermittelte
Wert ist allerdings nur ein Schätzwert und sollte in der Praxis als Ausgangspunkt
dienen, um einen endgültigen Wert für SDO LEVEL zu bestimmen. Der optimale
Wert kann (leicht) von diesem Wert abweichen. In der verwendeten Version von
Oracle8i liefert diese Methode allerdings nur null zurück.
Kapitel 4
Datenbankentwurf
In diesem Kapitel werden die einzelnen Phasen des Entwurfs einer Datenbank für bodenkundliche Daten erläutert. Es ist unterteilt in mehrere Abschnitte, die jeweils die
einzelnen Phasen behandeln. Zunächst werden in der Anforderungsanalyse die Menge
der zu verwaltenden Datenbestände und Methoden bestimmt. Der zweite Teil befasst
sich mit den externen Schemata, die sich aus der Anforderungsanalyse ergeben und im
dritten Abschnitt zu einem konzeptionellen Schema integriert werden. Es schließt sich
ein Abschnitt über das logische Modell an. Hierin wird das konzeptionelle Schema in das
Relationenmodell überführt, wobei auch objektrelationale Aspekte berücksichtigt werden, die von Oracle8i bereitgestellt werden. Der letzte Abschnitt befasst sich mit dem
physischen Entwurf der Datenbank. In ihm werden Veränderungen der Implementierung
gegenüber dem Relationenmodell sowie der Einsatz von Indexen erläutert.
4.1
Anforderungsanalyse
Die im Folgenden durchgeführte Anforderungsanalyse basiert auf drei verschiedenen Informationsquellen:
1. Informationsgespräche mit Geografen der Universität Hannover (R. Duttmann,
M. Neteler)
2. Literatur: insbesondere der Habilitationsschrift von R. Duttmann [7], in der partikuläre Stoffverlagerungen in Landschaften untersucht werden, der Dokumentation
zur Methodenbank des Niedersächsischen Bodeninformationssystems (NIBIS) [17]
und der Bodenkundlichen Kartieranleitung der Ad-hoc-Arbeitsgruppe Boden [1].
3. existierende Dateiformate und Datensätze: Vom Geographischen Institut der
Universität Hannover, Abt. Physische Geographie und Landschaftsökologie wurden Daten zur Verfügung gestellt, die im Gebiet Groß-Ilde aufgenommen wurden.
Diese Daten umfassen bodenkundliche Messungen, Angaben über die Nutzung
39
40
KAPITEL 4. DATENBANKENTWURF
des Bodens, Klimainformationen und Informationen über das Relief des Untersuchungsgebietes (digitales Geländemodell). Die meisten dieser Daten liegen im
ASCII-Format vor, es gab aber auch Datensätze (Klima) im Excel-Format. Die
Daten wurden mithilfe verschiedener Konverter und Oracle-Tools (insbesondere
SQL-Loader-Utility für Polygone) in eine Oracle-Datenbank geladen.
Grundlage für die Analyse von Transportprozessen im Boden ist die Aufnahme von
Daten im betrachteten Beobachtungsgebiet. Die aufgenommenen Daten sind in thematisch zusammengehörige Einheiten, sogenannte Informationsebenen, untergliedert. Im
vorliegenden Fall sind Eingangsdaten für vier Informationsebenen vorhanden, die im folgenden Text erläutert werden:
• Boden/Bodenwasser
• Vegetation/Nutzung
• Klima
• Relief
Die Messung von Daten der ersten drei Informationsebenen erfolgt an verschiedenen
Standorten des Beobachtungsgebietes. Bei der Aufnahme von Messdaten werden einem
Standort seine x- und y-Koordinaten, in der Geografie als Rechts- und Hochwert bezeichnet, im Gauß-Krüger-System zugeordnet. Das Gauß-Krüger-System wird in der Geografie benutzt, um Verzerrungen bei der Projektion der kugelförmigen (3-dimensionalen)
Erdoberfläche auf eine (2-dimensionale) Karte möglichst zu minimieren. Das von Gauß
entwickelte Verfahren ist eine konforme Abbildung mit einem längentreuen Hauptmeridian. Eine genaue Beschreibung des Verfahrens findet sich zum Beispiel in Bill [4] (S.202
ff.). Messstandorte sind prinzipiell beliebig im Beobachtungsgebiet verteilt und variieren üblicherweise für die unterschiedlichen Informationsebenen hinsichtlich ihrer Rechtsund Hochwerte.
Da es nicht möglich ist, an allen Punkten des Untersuchungsgebietes Messungen vorzunehmen, wird durch Fachpersonal anhand vorliegender Geländeeigenschaften (beispielsweise Abwassergraben, Straßen, Hügel) zu jedem Standort eine Fläche bestimmt, für die
näherungsweise dieselben Werte wie am Messstandort bezüglich der aufgenommenen
Daten angenommen werden. Das heißt, Standorten sind Flächen mit ähnlichen Ausstattungsmerkmalen zugeordnet. Diese Flächen werden als quasihomogen bezeichent. Die
am Messstandort aufgenommenen Daten gelten als repräsentativ für die ausgezeichnete
Fläche. Die den einzelnen Standorten zugeordneten Flächen überdecken das gesamte Beobachtungsgebiet für jede Informationsebene und sind innerhalb einer Informationsebene
paarweise disjunkt. Sie bilden folglich eine Partition des Gebietes.
Im Gegensatz zu diesen diskreten Standorten zugeordneten Werten liegen die Daten der
Informationsebene Relief in einem Rasterformat vor. Das Beobachtungsgebiet ist für
diese Daten in gleichgroße Rasterzellen aufgeteilt, denen jeweils Werte zugewiesen sind.
4.1. ANFORDERUNGSANALYSE
4.1.1
41
Informationsebene Boden
Der Boden ist allgemein aus mehreren Bodenhorizonten1 zusammengesetzt (siehe
Abbildung 4.1). Zur Beschreibung des Bodens an einem Messstandort werden daher
Gültigkeitsbereich
allgemeine
Bodendaten
Otief
Horizont A
Utief
Otief
Horizont B
Utief
Otief
Horizont C
Utief
Abbildung 4.1: Schichtaufbau des Bodens
sowohl Informationen über den Boden, als auch über die einzelnen Bodenhorizonte
benötigt. Diese Informationen werden durch einen senkrechten Anstich des Bodens bis
in ca. zwei Meter Tiefe erhalten. Das so aufgenommene Bodenprofil enthält Informationen über die einzelnen Bodenhorizonte, die Horizontabfolge und allgemeine nicht
horizontbezogene Eigenschaften des Bodens. Die Daten eines Bodenprofils können folglich in allgemeine Bodendaten und horizontbezogene Bodendaten unterteilt werden. Die allgemeine Bodendaten gelten uneingeschränkt für den Standort, an dem sie
aufgenommen wurden, die horizontbezogenen Daten nur innerhalb eines bestimmten
Horizonts.
Obwohl allgemeine und horizontbezogene Bodendaten korrelieren, ist es nicht möglich,
die horizontbezogenen Bodendaten eindeutig aus den allgemeinen Bodendaten abzuleiten. Allerdings können Angaben über die Horizonte gemacht werden. Beispielsweise
ist durch Kenntnis des Bodentyps (ein allgemeines Bodenattribut) die Horizontabfolge
festgelegt, da ein Bodentyp dadurch charakterisiert ist. Genauere Angaben über die Attribute der einzelnen Horizonte oder ihre genaue Lage im Boden sind aber nicht möglich.
Es können lediglich grobe Angaben über die Horizontabfolge und ihre ungefähre Lage
gemacht werden.
Allgemeine Bodendaten wiederum können teilweise aus den horizontbezogenen Bodendaten abgeleitet werden. Theoretisch wäre es sogar möglich, alle allgemeinen Bodendaten aus der Kenntnis der Horizonte zu bestimmen, da der Boden aus den Horizonten
zusammengesetzt ist. In der Praxis werden allerdings einige der allgemeinen Bodeneigen1
In der Terminologie des Niedersächsischen Landesamtes für Bodenkunde werden Horizonte als
Schichten bezeichnet. Im folgenden Text sind diese beiden Begriffe daher als gleichwertig anzusehen.
42
KAPITEL 4. DATENBANKENTWURF
schaften bereits vor Ort, also bei der Aufnahme des Bodenprofils, durch Fachpersonal
bestimmt und nicht mehr durch die Eigenschaften der Horizonte verifiziert.
Bei Messungen an verschiedenen Standorten können Bodenprofile aufgenommen werden, die nur geringe, für den jeweils betrachteten Problembereich nicht relevante, Unterschiede aufweisen. Diesen quasi gleichen Standorten werden dieselben Bodenprofile
zugeordnet.
Auf horizontbezogene Bodendaten werden Methoden angewendet, die die horizontbezogenen Bodendaten miteinander in Beziehung setzen und aus den aufgenommenen und
ermittelten Primärinformationen implizit darin enthaltene Sekundärinformationen ableiten. Hierzu zählt beispielsweise die Ableitung der Lagerungsdichte aus der Rohdichte
und dem Tongehalt. Für allgemeine Bodendaten existieren bisher keine solche Methoden.
Das Bodenprofil wiederum besitzt Attribute, die aus den allgemeinen und horizontbezogenen Bodendaten, aus denen das Bodenprofil zusammensetzt ist, mithilfe verschiedener
Methoden abgeleitet werden. Diese Methoden benötigen als Eingangsdaten sowohl die
allgemeinen und die horizontbezogenen Bodendaten, als auch Informationen über die
Lage der Horizonte im Boden.
Für die Informationsebene Boden wurden als Eingangsdaten im Untersuchungsgebiet
Groß-Ilde aufgenommene Daten zur Verfügung gestellt. Diese Daten sind im Einzelnen:
• allgemeine Bodendaten
• horizontbezogene Bodendaten
• Informationen über die Lage der Messstandorte in Gauß-Krüger-Koordinaten
• den Messstandorten zugeordnete quasihomogene Flächen in Form von Polygonen,
die den Rand dieser Flächen beschreiben
4.1.2
Informationsebene Nutzung (Vegetation)
Der Boden des betrachteten Gebietes wird auf vielfältige Weise genutzt. Informationen über die Nutzung sind in dieser Informationsebene abgelegt. Ebenso wie bei den
Bodendaten wird auch hier repräsentativ ein Standort ausgewählt, diesem Standort Informationen über die Nutzung angeheftet und eine Fläche zugeordnet, deren Nutzung
der des Standortes entspricht.
Für die Informationsebene Nutzung existieren bisher keine Methoden, die Attribute
dieser Informationsebene zueinander in Beziehung setzen.
An Eingangsdaten wurden zur Verfügung gestellt:
• Nutzungsdaten der Jahre 1994, 1995 und 1996
• Informationen über die Lage der Messstandorte im Gauß-Krüger-System
4.1. ANFORDERUNGSANALYSE
43
• den Messstandorten zugeordnete quasi-homogene Flächen in Form von Polygonen,
die den Rand dieser Flächen beschreiben
4.1.3
Informationsebene Klima
Klimadaten werden kontinuierlich an Klimastationen aufgenommen. Aufgrund der geringen räumlichen Ausdehnung des Untersuchungsgebietes wird das Klima im vorliegenden
Fall als homogen angesehen. Es liegen also nur Daten für einen Messstandort vor. Prinzipiell sind aber für Klimamessungen Standorte mit zugeordneten Flächen vorzusehen.
Innerhalb der Informationsebene Klima sind Methoden vorzusehen, die den Sättigungsdampfdruck (EWT14), den aktuellen Dampfdruck (et14) und die potenzielle Verdunstung nach Haude (ETPhaude) aus den gemessenen Daten ableiten. Zusätzlich werden
aggregierte Klimawerte benötigt, genauer der Jahresniederschlag, der Niederschlag der
Hauptvegetationsperiode (01.April bis 30.September) und der Niederschlag des Winterhalbjahres (01.Oktober bis 31.März des folgenden Jahres). Für diese Aggregationen ist
eine Funktion vorzusehen.
Zur Verfügung gestellte Eingangsdaten der Informationsebene Klima sind:
• täglich gemessene Klimawerte der Jahre 1995 und 1996 (Temperatur, relative
Feuchte und Niederschlag)
4.1.4
Informationsebene Relief
Das Relief beschreibt das Höhenprofil des untersuchten Gebietes. Diese Daten liegen
als Rasterdatei vor, das bedeutet, dass in dem Untersuchungsgebiet an verschiedenen,
äquidistant verteilten Messpunkten, Werte aufgenommen wurden. Neben den Höhenangaben an Rasterzellen liegen in den zur Verfügung gestellten Eingangsdaten zusätzlich
Werte für die Hangneigung und die Hangexposition vor, die aber bereits aus den Höhenangaben abgeleitet sind. Die Hangneigung gibt die Neigung des Normalenvektors der
Ebene an, ist also ein Maß für die Steigung der Fläche. Die Hangexposition bestimmt
die Ausrichtung der Projektion des Normalenvektors auf die Ebene von Ost aus gesehen, also die Ausrichtung der Fläche. Die einer Rasterzelle zugeordneten Daten sind
als Eingangsdaten für einen Punkt angegeben. Sie gelten für eine von diesem Punkt in
Richtung Nord-West ausgerichtete Fläche. In Abbildung 4.2 sind zum Beispiel die Werte
der gekennzeichneten Fläche durch den Rasterpunkt (3,2) gegeben.
Die Größe dieser zugeordneten Fläche ist abhängig von der Auflösung des Rasters (im
vorliegenden Fall 25m × 25m).
Da die für das Relief relevanten, abgeleiteten Daten bereits vorhanden sind, sind keine
weiteren Methoden implementiert.
44
KAPITEL 4. DATENBANKENTWURF
4
3
2
1
1
2
3
4
Abbildung 4.2: Rasterzellen
Eingangsdaten der Informationsebene Relief sind:
• Höhe (Rastergröße 25m × 25m)
• Hangneigung (Rastergröße 25m × 25m)
• Hangexposition (Rastergröße 25m × 25m)
4.1.5
Methoden und Operationen
Für die Analyse von Transportprozessen im Boden ist es notwendig, die Eingangsdaten miteinander zu verknüpfen. Die Verknüpfungen erfolgen sowohl innerhalb einzelner Klassen und Informationsebenen als auch zwischen mehreren Informationsebenen.
Bei Verknüpfungen innerhalb einer Klasse bzw. einer Informationsebene sind lediglich
die an einem Standort gemessenen und zu der jeweiligen Informationsebene gehörigen
Messdaten zueinander in Beziehung zu setzen. Die Geometrie ist für diese Verknüpfungen irrelevant, da nur Sachdaten eines Objektes betrachtet werden. Im Gegensatz hierzu
stehen die Verknüpfungen von Eingangsdaten mehrerer Informationsebenen. Diese erfordern eine Betrachtung der Geometrien, da die einem Standort in einer Informationsebene
zugeordnete Fläche im allgemeinen nicht einer homogenen Fläche einer anderen Informationsebene entspricht. Es müssen folglich Schnittmengen von Flächen berechnet werden,
in denen die Attribute beider Geometrien konstant sind.
Beispielhaft wird in dieser Arbeit die Methode zur Ableitung der Sickerwasserrate implementiert. Die für diese Ableitung notwendigen Schritte sollen an dieser Stelle nur kurz
skizziert werden. Eine ausführliche Diskussion der Methode findet in Kapitel 6 statt.
Die Methode zur Ableitung der Sickerwasserrate benötigt als Eingangsdaten aufgenommene Werte der Informationsebenen Boden, Nutzung, Klima und Relief. Sie ist schematisch in Abbildung 4.3 dargestellt.
Im ersten Schritt werden innerhalb der einzelnen Informationsebenen Werte abgeleitet,
die allein aus den Eingangsdaten der jeweiligen Informationsebene, unter Verwendung
statischer Hilfstabellen, bestimmt werden können. Im vorliegenden Fall sind dies Werte
innerhalb der Informationsebenen Boden und Klima. Anschließend werden die geometrischen Informationen der Informationsebenen Boden und Nutzung verschnitten, um im
4.1. ANFORDERUNGSANALYSE
45
dritten Schritt Werte abzuleiten, die Informationen dieser beiden Informationsebenen
als Eingangsdaten benötigen. Für die Verschneidung der Informationsebenen sind zwei
Vorgehensweisen denkbar.
1. Verschneidung der geometrischen Informationen im Vektorformat und Zuweisung
von Attributen an die neu berechneten Flächen
2. Umwandlung der geometrischen Daten im Vektorformat ins Rasterformat und Zuweisung der Attribute an die einzelnen Rasterpunkte
1.Schritt
Ableitung von Werten
innerhalb der
Informationsebenen
2.Schritt
3.Schritt
Verschneidung der
Informationsebenen
Boden und Nutzung
Ableitung von Werten
mit Eingangsdaten der
Informationsebenen
Boden und Nutzung
4.Schritt
Verschneidung aller
Informationsebenen
5.Schritt
Ableitung der
Sickerwasserrate
Informationsebene
Boden
Informationsebene
BodenNutzung
Informationsebene
( Verschnitt der Informationsebenen Boden und Nutzung )
Nutzung
Informationsebene
Klima
Verschnitt aller
vorhandenen
Informationsebenen
Informationsebene
Relief
Abbildung 4.3: Schematische Darstellung der Methode zur Ableitung der Sickerwasserrate
Nachdem die Informationsebenen verschnitten und die entsprechenden Werte abgeleitet
sind, wird der Verschnitt der Informationsebenen Boden und Nutzung mit den Informationsebenen Klima und Relief verschnitten, da die weiteren abzuleitenden Werte (im
vorliegenden Fall lediglich die Sickerwasserrate) Informationen aller vorhandenen Informationsebenen benötigen. Die räumlichen Informationen der Informationsebene Relief
liegen im Rasterformat vor, daher findet hier eine Verschneidung von Vektor- und Rasterdaten statt, deren Ergebnis das Rasterformat hat. Es ist auch möglich zunächst alle
im Vektorformat vorliegenden Geometrieinformationen ins Rasterformat zu konvertieren, anschließend sämtliche Verschnitte im Rasterformat durchzuführen und dann die
Berechnungen für die einzelnen Rasterpunkte vorzunehmen. Im Rahmen dieser Arbeit
werden beide Vorgehensweisen in Kapitel 6 näher betrachtet.
46
KAPITEL 4. DATENBANKENTWURF
Im fünften und letzten Schritt schließlich wird die Sickerwasserrate für die einzelnen
Rasterpunkte berechnet.
4.2
Externe Datenbankschemata (UML)
Im Folgenden werden die externen Schemata (Sichten der einzelnen Informationsebenen) der zu entwerfenden Datenbank vorgestellt und erläutert. Grundlage der externen
Schemata ist die Anforderungsanalyse.
4.2.1
Externes Schema der Informationsebene Boden
Das externe Schema der Informationsebene Boden (Abbildung 4.4) ist aus fünf Klassen zusammengesetzt. Die Attribute der Klasse BodenStandort bestimmen die Lage des
Messstandortes in Gauß-Krüger-Koordinaten (Rechts- und Hochwert), sowie die diesem
Messstandort zugeordnete quasi-homogene Fläche (Geometrie). An jedem Messstandort
wird genau ein Bodenprofil aufgenommen. Es können aber dieselben Bodenprofile an
verschiedenen Standorten existieren. Daher liegt zwischen den Klassen BodenProfil und
BodenStandort eine 1 : n-Beziehung (funktionale Beziehung) vor.
Eine Instanz der Klasse BodenProfil ist definiert durch eine Instanz der Klasse Boden
und eine oder mehrere Instanzen der Klasse BodenHorizont. Die der Klasse BodenProfil zugeordneten Attribute werden alle aus Objekten dieser beiden Klassen mithilfe der
angegebenen Methoden abgeleitet. Verschiedene Bodenprofile können die gleichen allgemeinen Bodendaten besitzen, also auf dieselbe Instanz der Klasse Boden verweisen. Dann
unterscheiden sich allerdings entweder die dem Bodenprofil zugeordneten Horizonte oder
die Lage der Horizonte im Boden. Die Information über die Lage der Horizonte ist der
Beziehung zwischen den Klassen BodenProfil und BodenHorizont als Assoziationsklasse
Lage angeheftet. Diese Klasse besitzt die beiden Attribute Otief und Utief, die die obere
und untere Tiefe des Horizonts im Boden angeben.
Zu einem Bodenprofil gehören (ein oder) mehrere Horizonte, andererseits kann der gleiche Horizont auch in verschiedenen Bodenprofilen vorkommen. Daher ist die Beziehung
zwischen den Klassen BodenProfil und BodenHorizont eine n : m-Beziehung. Weiterhin
ist jedem Bodenprofil eine Instanz der Klasse Boden zugeordnet. Eine Instanz der Klasse Boden kann aber ebenfalls in verschiedenen Bodenprofilen auftreten. Die Beziehung
zwischen den Klassen Boden und BodenProfil ist demnach funktional (1 : n-Beziehung).
4.2.2
Externes Schema der Informationsebene Nutzung
Das externe Schema der Informationsebene Nutzung (Abbildung 4.5) ist aus zwei Klassen
zusammengesetzt. Die Klasse NutzungStandort beschreibt, wie die Klasse BodenStandort
4.2. EXTERNE DATENBANKSCHEMATA (UML)
Abbildung 4.4: Externes Schema der Informationsebene Boden
Abbildung 4.5: Externes Schema der Informationsebene Nutzung
47
48
KAPITEL 4. DATENBANKENTWURF
der Informationsebene Boden, die Lage des Messstandortes und die zugeordnete Fläche.
Die Klasse Nutzung besitzt die zwei Attribute NutzNr und Jahr. Hier fließt also eine zeitliche Komponente ein. Eine Instanz der Klasse Nutzung beschreibt demnach die Nutzung
in einem bestimmten Jahr. An verschiedenen Messstandorten kann dieselbe Nutzung vorliegen, andererseits werden bei Messungen in verschiedenen Jahren jedem Messstandort
unterschiedliche Instanzen der Klasse Nutzung zugeordnet, da sich zumindest die Jahreszahl ändert. Zwischen den beiden Klassen besteht folglich eine n : m-Beziehung.
4.2.3
Externes Schema der Informationsebene Klima
Das externe Schema der Informationsebene Klima (Abbildung 4.6) ist ebenfalls aus zwei
Klassen zusammengesetzt. Die Klasse KlimaStandort enthält die Lage des Messstand-
Abbildung 4.6: Externes Schema der Informationsebene Klima
ortes und das Attribut Geometrie beschreibt die zugeordnete Fläche2 . Die Klimadaten
selbst sind Attribute der Klasse KlimaWerte. Datum gibt den Tag der Messung an, Temperatur, Niederschlag und RFeuchte (relative Feuchte), die aufgenommen Werte. Da an
einem Messstandort an mehreren Tagen verschiedene Werte aufgenommen werden und
an unterschiedlichen Standorten (zumindest theoretisch) dieselben Messdaten ermittelt
werden können, besteht zwischen den beiden Klassen KlimaStandort und KlimaWerte eine
n : m-Beziehung.
4.2.4
Externes Schema der Informationsebene Relief
Das externe Schema der Informationsebene Relief (Abbildung 4.7) besteht lediglich aus
der Klasse ReliefPunkt. Die Klasse ReliefPunkt besitzt fünf Attribute. Die Attribute
2
Aufgrund der Größe des Untersuchungsgebietes sind keine klimatischen Unterscheidungen an verschiedenen Messpunkten (es gibt nur einen !) notwendig. Es wäre hier also auch möglich, nur die
Klimadaten ohne geometrische Information zu speichern. Im Hinblick auf Erweiterbarkeit wird der
geometrische Aspekt allerdings berücksichtigt.
4.3. KONZEPTIONELLES SCHEMA
49
Abbildung 4.7: Externes Schema der Informationsebene Relief
Rechts- und Hochwert geben die Lage des Punktes in Gauß-Krüger-Koordinaten an,
an dem die Werte der folgenden drei Attribute ermittelt wurden. Diese drei Attribute
sind Hoehe, Hangneigung und Exposition.
4.3
Konzeptionelles Schema
Durch Integration der externen Schemata ergibt sich das konzeptionelle Schema des
Datenbankentwurfs (Abbildung 4.8).
Das konzeptionelle Schema hat gegenüber den externen Schemata die zwei zusätzlichen
abstrakten Klassen Punkt und Standort. Beide Klassen sind abstrakt definiert, da sie nicht
implementiert werden. Sie dienen in diesem Modell lediglich als Oberklassen anderer
Klassen.
Die Klasse Punkt besitzt die Attribute Rechts- und Hochwert, die die Lage eines Punktes in Gauß-Krüger-Koordinaten angeben. Eine Unterklasse von Punkt ist Reliefpunkt.
Diese Klasse enthält zusätzlich die an einem Punkt aufgenommen bzw. abgeleiteten Reliefwerte Hoehe, Hangneigung und Exposition. Die zweite Unterklasse von Punkt ist die
Klasse Standort, die selbst wiederum als Oberklasse der drei Klassen NutzungStandort,
BodenStandort und KlimaStandort eingeführt wurde. Obwohl diese drei Klassen dieselbe
Attributmenge besitzen, werden sie im konzeptionellen Modell nicht zusammengefasst,
da Messungen am selben Standort für mehrere Informationsebenen durchgeführt werden
können, diesen Messungen aber wiederum unterschiedliche Standortobjekte zugewiesen
werden. Der Grund für unterschiedliche Standortobjekte liegt darin, dass sich die Geometrien der bezüglich verschiedener Informationsebenen homogenen Flächen im Allgemeinen unterscheiden. Eine Instanz der Klasse Standort hat zusätzlich zu den von der
Klasse Punkt ererbten Attributen Rechts- und Hochwert noch das Attribut Geometrie,
dass die einem Standort zugeordnete Fläche beschreibt.
50
KAPITEL 4. DATENBANKENTWURF
Abbildung 4.8: Konzeptionelles Schema
4.4. LOGISCHES MODELL (RELATIONENMODELL)
4.4
51
Logisches Modell (Relationenmodell)
In diesem Abschnitt wird die Transformation des konzeptionellen Schemas in das Relationenmodell beschrieben. Aus Gründen der Übersichtlichkeit wird diese Transformation
getrennt für die einzelnen Informationsebenen betrachtet. Im logischen Schema werden
die Datentypen der Attribute festgelegt, die Attribute der abstrakten Oberklassen an
die Unterklassen geheftet, gegebenenfalls künstliche Schlüssel eingeführt sowie Umbenennungen und Vereinfachungen vorgenommen.
4.4.1
Informationsebene Boden
Aus dem konzeptionellen Schema ergeben sich für die Informationsebene Boden die in
Abbildung 4.9 angegebenen Relationenschemata. Der Relation BodenStandort wurde ein
BodenStandort
BodenProfil
BodenHorizont
Horizont
ProfilHorizont
(SNr:INTEGER, Rechtswert:FLOAT, Hochwert:FLOAT,
Geometrie:MDSYS.SDO GEOMETRY, BPNR→BodenProfil)
(BPNr:INTEGER, BNr→Boden, We:FLOAT, nFKWe:FLOAT,
KRmm:FLOAT, KRStufe:INTEGER, nFKWeStufe:INTEGER)
(BNr:INTEGER, Bodentyp:VARCHAR2(10), Grundwasserstand:
VARCHAR2(10),Grundwasserstufe:FLOAT, Staunaessestufe:INTEGER)
(HNr:INTEGER, Horizontbezeichnung:VARCHAR2(10), Bodenart:
VARCHAR2(5), Rohdichte:FLOAT, Grobboden:FLOAT, Humusgehalt:
FLOAT, Carbonatgehalt:FLOAT, Tongehalt:FLOAT, pHWert:FLOAT,
LD:FLOAT, LDStufe:INTEGER, nFK:FLOAT, We:FLOAT)
(BPNr→BodenProfil, HNR→Horizont, Otief:FLOAT, Utief:FLOAT)
Abbildung 4.9: Relationen der Informationsebene Boden
künstliches Schlüsselattribut SNr zugeordnet, anhand dessen Standorte eindeutig identifiziert werden können. Weiterhin ist jeder Instanz der Klasse BodenStandort genau eine
Instanz der Klasse BodenProfil zugeordnet. Diese funktionale Abhängigkeit ist durch die
Fremdschlüsselbedingung BPNr→BodenProfil ausgedrückt. Hierbei ist BPNr ein ebenfalls künstlich eingeführtes Schlüsselattribut für die Klasse BodenProfil. Jeder Instanz der
Klasse BodenProfil ist eine Instanz der Klasse Boden zugeordnet. Auch diese funktionale
Abhängigkeit ist durch eine Fremdschlüsselbedingung im Modell angegeben und zwar
in der Referenzierung der Relation Boden für das Attribut BNr. Das Schlüsselattribut
der Relation BodenProfil, BPNr, wird in der Relation ProfilHorizont als Fremdschlüssel
benötigt, um Instanzen der Klasse BodenHorizont einer Instanz der Klasse BodenProfil
zuzuordnen. Diese Relation benötigt als weiteres Fremdschlüsselattribut den künstlich
eingeführten Schlüssel BSNr der Relation BodenSchicht.
52
4.4.2
KAPITEL 4. DATENBANKENTWURF
Informationsebene Nutzung
Für die Informationsebene Nutzung ergeben sich die in Abbildung 4.10 angegebenen Relationenschemata. Der Relation NutzungStandort wurde das Schlüsselattribut SNr hinzuNutzungStandort
Nutzung
Anbau
(SNr:INTEGER, Rechtswert:FLOAT, Hochwert:FLOAT,
Geometrie:MDSYS.SDO GEOMETRY)
(NNr:INTEGER, NutzNr:INTEGER, Jahr:DATE)
(SNr→NutzungStandort,NNr→Nutzung)
Abbildung 4.10: Relationen der Informationsebene Nutzung
gefügt, durch das der Standort eindeutig identifiziert werden kann. Die Relation Nutzung
enthält Informationen über die Nutzungsart, gebunden an eine zeitliche Komponente.
Diese wird in dem Attribut Jahr abgespeichert. Künstliches Schlüsselattribut dieser Relation ist NNr. Anbau schließlich realisiert die Beziehung zwischen NutzungStandort und
Nutzung. Der Schlüssel dieser Relation setzt sich aus den beiden Fremdschlüsseln SNr
der Relation NutzungStandort und NNr der Relation Nutzung zusammen.
4.4.3
Informationsebene Klima
Das konzeptionelle Schema der Informationsebene Klima zeigt zwei Klassen, KlimaStandort und KlimaWerte. Diese stehen in einer n : m-Beziehung zueinander, wobei jedem
KlimaStandort-Objekt mehrere Instanzen der Klasse KlimaWerte zugeordnet sind. Da
aber Klimadaten an stationären Messstationen periodisch aufgenommen werden, erscheint es an dieser Stelle sinnvoll, alle aufgenommenen Klimawerte bezüglich einer
Messstation in einer eigenen Relation abzulegen und eventuell dadurch entstehende Redundanzen zu tolerieren. Andernfalls wäre aufgrund der Objektidentität eines gemessenen
Datensatzes der Aufwand für das Einfügen von Klimawerten in die Datenbank unverhältnismässig hoch, da für jeden Datensatz überprüft werden müßte, ob bereits ein solches
Tupel in der Datenbank existiert.
Durch das Anlegen einer eigenen Relation für die Messwerte werden einem Klimastandort nicht mehr n gemessene Datensätze zugeordnet, sondern lediglich eine Tabelle, in
der die Klimadaten für diesen Standort abgelegt sind.
Um die Klimadaten zu speichern bietet Oracle8i das in Abschnitt 3.5.2 beschriebene
Konzept der nested tables an, sodass ein neuer Objekttyp Typ KlimaDatenTabelle eingeführt wird, in dem die entsprechenden Tupel abgelegt werden. Die Implementierung
dieses Objekttyps wird in Abschnitt 4.5.1 erläutert.
Schließlich sollten Klimadaten nicht an einen Standort gebunden sein, damit mit denselben Klimadaten auch an anderen Standorten Werte abgeleitet werden können, falls für
diesen anderen Standort keine, nur wenige oder für einen anderen Zeitraum gemessene
Klimadaten vorliegen, der neue Standort aber zumindest ähnliche das Klima beeinflussende Faktoren aufweist. Dies könnte im Prinzip auch durch eine Vergrößerung der einem
4.5. PHYSISCHER ENTWURF
53
Klimastandort zugeordneten quasihomogenen Fläche erreicht werden, an dem die Daten
aufgenommen wurden. Da die Veränderung von Flächen aber aufwendiger ist und eventuell noch Klimadaten für den neuen Standort aufgenommen werden, wird zusätzlich
eine Klasse Klima im Relationenmodell eingeführt, die Klimastandorte und Messdaten
miteinander verbindet.
Aus diesen Üuberlegung ergeben sich für die Informationsebene Klima die in Abbildung
4.11 angegebenen Relationenschemata.
KlimaStandort
Klima
(SNr:INTEGER, KNr→Klima, Rechtswert:FLOAT, Hochwert:FLOAT,
Geometrie:MDSYS.SDO GEOMETRY)
(KNr:INTEGER, Klimadaten:Typ KlimaDatenTabelle)
Abbildung 4.11: Relationen der Informationsebene Klima
Die Interpretation dieser Relationen ist, dass einer Instanz der Klasse Klimastandort eine
Instanz der Klasse Klima zugeordnet ist, deren Werte in einem objektwertigen Attribut
vom Objekttyp Typ KlimaDatenTabelle abgelegt sind.
4.4.4
Informationsebene Relief
Für die Informationsebene Relief ergibt sich aus dem konzeptionellen Modell die in Abbildung 4.12 angegebene Klasse. Die Name der Relation ist in Relief25 geändert, da es
Relief25
(RPNr:INTEGER,Ort:MDSYS.SDO GEOMETRY,
Hoehe:FLOAT,Hangneigung:FLOAT,Exposition:FLOAT)
Abbildung 4.12: Relation der Informationsebene Relief
sich bei den Eingangsdaten um eine Relief mit einem Rasterpunktabstand von 25 Metern
handelt. Später wird noch ein anderes Relief mit einem Rasterpunktabstand von 10 Metern (Relief10) erzeugt. RPNr ist ein künstlich eingeführtes Schlüsselattribut, über das
einzelne Rasterpunkte und an diesen Punkten aufgenommene Werte abgefragt werden
können. Ort fasst die beiden Attribute Rechts- und Hochwert in dem von Spatial bereitgestellten Objekttyp MDSYS.SDO GEOMETRY zusammen. Die anderen drei Attribute
entsprechen den aufgenommen Messwerten bzw. aus den aufgenommenen Messwerten
abgeleiteten Werten.
4.5
Physischer Entwurf
Auf der Basis des logischen Modells wird der physische Entwurf der Datenbank realisiert. Beim physischen Entwurf werden neue Objekttypen definiert, Relationen unter
Beachtung von Integritätsbedingungen angelegt sowie Indexstrukturen erzeugt.
54
4.5.1
KAPITEL 4. DATENBANKENTWURF
Typdefinitionen
Im logischen Modell der zu entwickelnden Datenbank werden zwei Objekttypen verwendet, MDSYS.SDO GEOMETRY und Typ KlimaDatenTabelle. Dies beiden Objekttypen
unterscheiden sich strukturell derart, dass MDSYS.SDO GEOMETRY ein objektwertiges Attribut, das in Abschnitt 3.5.3 erläutert wird, ist und Typ KlimaDatenTabelle eine
geschachtelte Tabelle, deren Definition nun folgt.
Bei Klimamessungen werden vier Werte bestimmt. Dies sind das Datum, die Temperatur, die relative Feuchte RFeuchte, sowie der Niederschlag. Ableitungen innerhalb
der Informationsebene Klima bestimmen aus diesen Messwerten für jeden Messtag den
Sättigungsdampfdruck (EWT14), den aktuellen Dampfdruck (ET14) und die potenzielle Verdunstung nach Haude (ETPhaude). Insgesamt ist ein Tupel für die Klimawerte
eines Tages demnach aus sieben Attributen zusammengesetzt. Hierfür wird zunächst ein
Objekttyp Typ KlimaDatum definiert:
CREATE TYPE Typ_KlimaDatum AS OBJECT (
Datum
DATE,
Temperatur
FLOAT,
RFeuchte
FLOAT,
Niederschlag FLOAT,
EWT14
FLOAT,
ET14
FLOAT,
ETPhaude
FLOAT
);
Die Definition des Typs Typ KlimaDatenTabelle erfolgt anschließend als Tabelle mit Zeilen vom Typ Typ KlimaDatum.
CREATE TYPE Typ_KlimaDatenTabelle AS TABLE OF
Typ_KlimaDatum;
Dieser Typ ist tabellenwertig und kann als Attribut einer anderen Tabelle benutzt werden. Eine solche Konstruktion wird zur Erzeugung der Tabelle Klima verwendet, die ein
Attribut Typ KlimaDaten besitzt, das tabellenwertig ist und als geschachtelte Tabelle
abgespeichert wird. Die Definition der Tabelle Klima lautet:
CREATE TABLE Klima (
KNr
INTEGER,
KlimaDaten Typ_KlimaDatenTabelle
CONSTRAINT PK_Klima PRIMARY KEY (KNr))
NESTED TABLE Klimadaten
STORE AS KlimadatenMenge;
KNr ist dabei der Schlüssel der Relation und in Klimadaten werden die Messwerte
abgelegt. Wie bereits in 3.5.3 beschrieben, werden sämtliche Tupel aller Tabellen vom
Typ Typ KlimaDatenTabelle, die in dieser Relation angegeben sind intern in einer einzigen
Tabelle KlimadatenMenge abgelegt, deren Name nach store as angegeben ist.
4.5. PHYSISCHER ENTWURF
4.5.2
55
Relationen
Die implementierten Relationen entsprechen mit einer Ausnahme denen des logischen
Modells. Ihre SQL-Definitionen finden sich in Anhang A.1. Die Ausnahme besteht in der
Speicherung des Attributes Geometrie in den Relationen BodenStandort, NutzungStandort und KlimaStandort. Dieses Attribut wurde aus der Relation entfernt und separat in
einer jeweils eigenen Relation (BodenFlaeche, NutzungFlaeche und KlimaFlaeche) abgespeichert. Diese Relation besitzt außer der Geometrie als zweites Attribut die Nummer
des Standortes, zu dem die Geometrie gehört. Diese Nummer ist Fremdschlüssel der
Relation.
Der Grund für die Trennung von Sachdaten und Geometriedaten liegt darin, dass die
Menge der geometrischen Informationen um ein Vielfaches höher ist als die Menge an
Sachdaten. Dies kann bei Anfragen, die sich ausschließlich auf Sachdaten beziehen, zu
einer längeren Anfragebearbeitungszeit führen, da nicht direkt auf benötigte Daten zugegriffen werden kann, weil diese nicht im Cache oder Hauptspeicher, sondern auf der
Festplatte vorhanden sind und der Zugriff darauf mehr Zeit in Anspruch nimmt. Dieses
Phänomen wird in der Datenbanktheorie auch als Seitenfehler bezeichnet.
Das folgende Beispiel soll dieses Problem noch einmal verdeutlichen: Angenommen in
einen schnellen Speicher können 1000 Zahlen aufgenommen werden und ein Tupel besteht
durchschnittlich aus einer Zahl für das Schlüsselattribut und 600 Zahlen für die Koordinaten. Um nun auf drei Schlüsselattribute zuzugreifen, muss durchschnittlich einmal der
Inhalt des Speichers neu geladen (und der alte Inhalt wieder auf Festplatte geschrieben)
werden, da die nicht benötigten Koordinaten wertvollen Speicherplatz belegen. Sind nur
die Schlüsselwerte im Speicher, wäre ein Austausch des Speicherinhalts erst nach 1000
Zugriffen notwendig.
Daher wird die Trennung der Geometriedaten für Polygone von den Sachdaten wie im
nachfolgenden Beispiel durchgeführt.
Beispiel: Die Relation
BodenStandort(SNr:integer, Rechtswert:float, Hochwert:float,
Geometrie:MDSYS.SDO GEOMETRY,BPNR→BodenProfil)
wird aufgespalten in die zwei Relationen
BodenStandort(SNr:integer, Rechtswert:float, Hochwert:float, BPNR→BodenProfil) und
BodenFlaeche(SNr→BodenStandort,Geometrie:MDSYS.SDO GEOMETRY)
Die Änderung der Relationen NutzungStandort bzw. KlimaStandort erfolgt analog.
4.5.3
Indexe
Neben den vom Oracle-Datenbanksystem automatisch auf Primärschlüsseln von Tabellen angelegten Indexen wurden Indexe auf den (räumlichen) Geometriedaten erzeugt.
56
KAPITEL 4. DATENBANKENTWURF
Das Anlegen eines räumlichen Index erfordert zunächst die Eintragung der Dimensionsinformationen der zu indexierenden Attribute in die Relation SDO GEOM METADATA.
Hierzu müssen allerdings die maximalen Abmessungen der geometrischen Attribute (der
Gesamtheit einer Relation) bekannt sein. Daher kann dieser Eintrag erst erfolgen, wenn
diese Daten ermittelt sind. Werden Daten automatisiert in die Datenbank eingefügt, so
schließt sich die Indexerzeugung daher an den Datenimport der Geometriedaten an.
In der vorliegenden Arbeit wird in Abschnitt 5.3 auf das Anlegen eines räumlichen Index
eingegangen und in Kapitel 6 werden verschiedene Parameterwerte für SDO LEVEL bzw.
SDO PARAMETER und ihre Auswirkungen auf geometrische Operationen untersucht.
Kapitel 5
Datenimport
In diesem Kapitel wird erläutert, wie die vom Geographischen Institut der Universität
Hannover, Abteilung Physische Geographie und Landschaftsökologie, zur Verfügung gestellten Daten in die im vorigen Kapitel entworfene Datenbank importiert und bereinigt werden. Voraussetzung für den beschriebenen Datenimport ist, dass die Daten im
ASCII-Format vorliegen, was für die Realdaten auch bis auf die Klimadaten zutrifft. Die
Klimadaten liegen als Excel-Datei vor, können aber leicht ins ASCII-Format konvertiert
werden. Die folgenden Abschnitte befassen sich mit den Vorbereitungen zum Datenimport, dem Import der Sachdaten, dem Import der Geometriedaten unter besonderer
Betrachtung des von Oracle bereitgestellten SQL-Loader-Utility und der anschließenden
Erzeugung von Indexstrukturen auf den Daten. Schließlich wird die Datenbereinigung
auf den geometrischen Daten erläutert.
5.1
Vorbereitungen zum Datenimport
In diesem ersten Schritt werden zunächst die benötigten Relationen in der Datenbank
angelegt. Dies erfolgt durch die zwei SQL-Skripte:
./Programme/Schema/create_tables.sql
./Programme/Schema/create_tables_orig.sql
Durch das Skript create tables.sql werden die in Kapitel 4 entworfenen Relationen angelegt. Das Skript create tables orig.sql erzeugt Relationen, deren Struktur der Struktur der
Dateien der Originaldaten entspricht. Dadurch können die Originaldaten direkt mittels
verschiedener SQL-Kommandos in die Datenbank importiert und anschließend durch
SQL-Prozeduren oder Kommandos in die neuen Relationen eingefügt werden. Das Erzeugen der alten Schemata ist notwendig, da das neue Schema vom alten abweicht und
so für den Import der Daten in das neue Schema teilweise aufwendige Verknüpfungen
der Daten durchgeführt werden müssen.
57
58
KAPITEL 5. DATENIMPORT
Für die Originaldateien mit Sachdaten werden durch Hilfsprogramme (convert.java bzw.
konvertiere Klima9596.java für die Klimadaten, die in einer geschachtelten Tabelle gespeichert werden) SQL-Kommandos erzeugt, die, als Skript ausgeführt, die Daten in die
Datenbank importieren. Diese Hilfsprogramme und eine Benutzungsanleitung sind in
Anhang D.1 genauer beschrieben. Die Originaldaten enthalten sehr vereinzelt fehlerhafte Daten, beispielsweise Steuerzeichen o.ä., die aufgrund der geringen Anzahl manuell
korrigiert wurden. Schließlich gab es Dateien mit Kopfzeilen, die Attributnamen angaben. Diese Kopfzeilen wurden ebenfalls manuell modifiziert bzw. entfernt..
Die geometrischen Daten müssen, um sie mit dem SQL-Loader-Utility zu laden, in ein
neues Format konvertiert werden. Diese Konvertierung wird in D.2 beschrieben.
Nachdem alle benötigten Relationen und die für den Import der Originaldaten zu erzeugenden SQL-Skripte und Dateien angelegt sind, können die Daten in die Datenbank
eingelesen werden.
5.2
Import der Sachdaten
Der Import der Sachdaten wird in mehreren Schritten durchgeführt. Zunächst werden
die Werte in die Originalrelationen geladen und dann mittels verschiedener SQL-Skripte
und Prozeduren in die neuen Relationen eingefügt. Für diesen Teil existiert das SQLSkript:
./Programme/Datenimport/init.sql
Dieses Skript ruft andere Skripte auf, die zunächst die Originalsachdaten mittels vorher
erzeugter insert into ... values ...-Kommandos in die Originalrelationen laden. Anschließend werden diese Daten in die neuen Relationen übertragen. Da das neue Schema
die Daten anders als das alte Schema strukturiert, ist diese Übertragung nicht trivial, sondern erfordert zumindest für die Bodendaten eine aufwendige Verknüpfung der
Originalrelationen. Im ursprünglichen Schema sind beispielsweise die Messstandorte der
Informationsebene Boden Attribute der Bodendaten, sodass bei gleichen Bodendaten
mehrere Tupel erzeugt werden, die sich nur bezüglich des Standortes unterscheiden. Solche Redundanzen sollten möglichst vermieden werden und das entwickelte Datenmodell
unterstützt diese Strategie, indem es eine Klasse Boden und eine Klasse BodenStandort
besitzt, sodass die Bodenattribute nur einmal in der Datenbank abgelegt werden. Diese
Initialisierung der Bodendaten wird mithilfe der Datei
./Programme/Datenimport/initBodenprofil.sql
durchgeführt, die automatisch von init.sql aufgerufen wird. Die weiteren neuen Relationen haben lediglich andere Attributbezeichnungen oder werden, wie beispielsweise bei
den Daten der Informationsebene Nutzung, in mehrere Relationen aufgespalten, um wie
bei den Bodendaten Redundanzen zu vermeiden.
5.3. IMPORT DER GEOMETRISCHEN DATEN
59
Schließlich werden noch null-Werte, die in den Originaldaten beispielsweise als 999.99
o.ä. gespeichert sind, zu null korrigiert.
5.3
Import der geometrischen Daten
Nachdem die Sachdaten in das neue Schema übertragen sind, werden die geometrischen
Daten geladen. Dazu wird das SQL-Loader-Utility von Oracle8i benutzt. Dieses benötigt
zum Datenimport eine Kontrolldatei, in der angegeben ist, wie die einzulesenden Daten
zu speichern sind. An dieser Stelle sei darauf hingewiesen, dass alle Koordinatenwerte mit
100 multipliziert wurden, um Nachkommastellen zu vermeiden, da die Koordinatenwerte
bei der Ausgabe aus der Oracle-Datenbank standardmäßig gerundet werden.
Ein relativ einfaches Beispiel für die Anwendung des SQL-Loader ist das Einlesen der
Höhendaten des Reliefs. Die Originaldatei hat folgende Struktur, wobei die Attributnamen nicht in der Datei mit aufgeführt sind:
Rechtswert
x1
x2
x3
Hochwert
y1
y2
y3
Hoehe
h1
h2
h3
Die Relation, die diese Werte aufnehmen soll heißt dgm25 (Digitales Geländemodell,
Punktabstand 25m) und wurde angelegt durch:
CREATE TABLE
PNr
Rechtswert
Hochwert
Hoehe
CONSTRAINT
dgm25 (
INTEGER,
INTEGER,
INTEGER,
FLOAT,
PK_dgm25 PRIMARY KEY (PNr));
Für das erste Attribut PNr, das Primärschlüssel ist, wird demnach ein Wert beim Einlesen benötigt, der in der Eingabe nicht vorhanden ist. Abhilfe schafft hier die Definition
eines Zählers, der durch das SQL-Kommando create sequence ... erzeugt werden kann.
Die restlichen Werte werden direkt aus der Eingabedatei übertragen. Der Aufbau der
Kontrolldatei ist sich daher wie in Abbildung 5.1 angegeben.
Zeile 1 definiert, dass Daten geladen werden sollen. Zeile 2 enthält den Dateinamen der
Eingabedatei, in diesem Fall dgm25.dat. Die Endung .dat wird automatisch angefügt, falls
keine Endung angegeben ist. In Zeile 3 steht der Name der Relation, in die die Werte
geladen werden sollen, Zeile 4 gibt Trennzeichen der einzelnen Werte in der Eingabedatei an. In Zeile 5 wird die Spalte benannt, in die der nachfolgende Wert eingetragen
werden soll. Dies ist der Primärschlüssel PNr, für den eine Sequenz von Zahlen erzeugt
wird. Die Werte in Klammern geben den Startwert der Sequenz und einen Wert für die
Inkrementierung (in dieser Reihenfolge) an. Die Zeilen 7,8 und 9 enthalten die Namen
der Attribute der Relation, in die die Werte eingelesen werden, sowie den Datentyp
60
KAPITEL 5. DATENIMPORT
Listing :
1
2
3
4
5
6
7
8
9
load dgm25.ctl
LOAD DATA
INFILE dgm25
INTO TABLE dgm25
FIELDS TERMINATED BY ’ ’
(PNr SEQUENCE (1,1),
Rechtswert INTEGER EXTERNAL,
Hochwert
INTEGER EXTERNAL,
Hoehe
FLOAT EXTERNAL
)
Abbildung 5.1: Kontrolldatei zum Laden des Höhenprofils
dieser Werte. Das Schlüsselwort external weist den SQL-Loader an, die Werte aus der
Eingabedatei zu lesen (im Unterschied zu PNr).
Die Eingabedateien für die Hangneigung und die Exposition sind strukturell ebenso
aufgebaut wie die Eingabedatei für das Höhenprofil. Daher sind diese Kontrolldateien
für den Datenimport wie die Kontrolldatei in Abbildung 5.1 aufgebaut.
Neben den Reliefdaten werden auch die Polygone der Standorten zugeordneten quasihomogenen Flächen mithilfe des SQL-Loader-Utility importiert. Zunächst müssen allerdings die Originaldateien wie in Anhang D.2 konvertiert werden. Die Eingabedatei für
den SQL-Loader hat dann folgende Struktur, wobei zu berücksichtigen ist, dass in der
Eingabedatei nur Polygone (keine Inselpolygone) abgelegt sind:
1,3,,,1,3,1;3.57002075E8,5.7665E8,3.57002175E8,5.766495E8,...:
2,3,,,1,3,1;3.57002075E8,5.7665E8,3.57037125E8,5.7665E8,...:
3,3,,,1,3,1;3.57037125E8,5.7665E8,3.57047325E8,5.7665E8,...:
Die Struktur der Zeilen dieser Datei entspricht der Struktur von Objekten vom Typ
MDSYS.SDO GEOMETRY. Die erste Zahl ist die Nummer des Polygons, die zweite Zahl,
in diesem Fall immer eine 3 steht für den Typ des Objektes (SDO GTYPE), hier also
Polygon. Es folgen zwei null-Werte für SDO SRID und SDO POINT. SDO SRID ist per
Definition immer null, da es in dieser Version von Oracle noch nicht unterstützt wird,
und SDO POINT ist auf null gesetzt, da keine Punktdaten geladen werden. Die nächsten
drei Werte gehören zusammen und bilden ein Tripel für SDO ELEM INFO. (1, 3, 1)
bedeutet in diesem Fall, dass das erste geometrische Objekt den Offset 1 vom Anfang
des nachfolgenden SDO ORDINATES-Array hat und vom Typ einfaches Polygon mit
durch gerade Linien verbundenen Punkten ist. Es folgen die Koordinaten der einzelnen
Punkte.
Der Aufruf des SQL-Loader zum Laden dieser Daten erfolgt anschließend mithilfe der in
Abbildung 5.2 angegebenen Kontrolldatei (Beispiel für das Laden der Bodenpolygone).
In dieser Datei entsprechen die ersten vier Zeilen denen der Kontrolldatei zum Laden des
Höhenprofils, mit Ausnahme der Bezeichnungen und des Trennzeichens. Zeile 5 definiert
SNr als externen Integer-Wert. Dies ist in der Eingabedatei die Nummer des jeweiligen
Polygons. In der Zeile 6 ist angegeben, dass das Attribut Geometrie objektwertig ist. Die
in Klammern eingeschlossen Attribute der Zeilen 7-13 bestimmen die Attribute dieses
5.3. IMPORT DER GEOMETRISCHEN DATEN
Listing :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
61
load boden polygone.ctl
LOAD DATA
INFILE ilde.pol.ora
INTO TABLE BodenFlaeche
FIELDS TERMINATED BY ’,’
( SNr INTEGER EXTERNAL,
Geometrie COLUMN OBJECT (
SDO_GTYPE INTEGER EXTERNAL,
SDO_SRID INTEGER EXTERNAL,
isnull FILLER CHAR,
SDO_ELEM_INFO VARRAY terminated by ’;’
(SDO_ORDINATES char(38)),
SDO_ORDINATES VARRAY terminated by ’:’
(SDO_ORDINATES char(38)))
)
Abbildung 5.2: Kontrolldatei zum Laden der Bodenpolygone
Objektes. Zeile 7 gibt an, dass SDO GTYPE ein externer Integer-Wert ist. Dies ist die 3
aus der Eingabedatei, also ist die Definition für ein Objekt vom Typ Polygon. SDO SRID
ist immer null, wie in der Eingabedatei angegeben. In Zeile 9 wird einfach ein null-Wert
eingefügt. Dies ist richtig, da keine Punkte geladen werden und an dieser Stelle im
Objekttyp MDSYS.SDO GEOMETRY der Wert für SDO POINT angegeben wird, falls
einer existiert. Zeile 10 besagt, dass nun so viele Werte aus der Eingabedatei gelesen
werden, bis ein Semikolon erreicht wird. Dies sind die Werte für SDO ELEM INFO,
das ein Array von n mal drei Werten ist. In Zeile 12 wird ebenso für die Koordinaten
verfahren, mit dem Unterschied, dass hier bis zu einem Doppelpunkt gelesen wird.
Um alle Geometriedaten zu laden werden die fünf folgenden Kontrolldateien und entsprechenden Eingabedateien benötigt, die sich im Verzeichnis ./Programme/Datenimport
finden:
• Höhenprofil: load dgm25.ctl dgm25.dat
• Hangneigung: load slope25.ctl slope25.dat
• Exposition: load aspect25.ctl aspect25.dat
• Bodenpolygone: load boden polygone ilde.pol.ora
• Nutzungspolygone: load nutzung polygone il nutz.pol.ora
Nachdem die Geometriedaten geladen sind werden für jede Relation mit räumlichen Informationen Einträge in die Relation SDO GEOM METADATA vorgenommen und räumliche Indexe angelegt. Dies kann erst nach dem Laden der Daten durchgeführt werden,
da nur anhand der Daten die Dimensionswerte ermittelt werden können, die in die Relation SDO GEOM METADATA eingetragen werden. Die Methode zur Erzeugung eines
räumlichen Index greift auf diese Tabelle zurück. Ein räumlicher Index kann also auch
erst jetzt erzeugt werden.
Für das Einfügen der Information in die Relation SDO GEOM METADATA und das
Anlegen der Indexe existiert ebenfalls ein Skript:
62
KAPITEL 5. DATENIMPORT
./Programme/Datenimport/init2.sql
In Abbildung 5.3 ist in den ersten drei Zeilen angegeben, wie die Informationen für die
Bodendaten in diese Relation eingetragen werden und anschließend, in den Zeilen fünf
und sechs, ein räumlicher Index auf den Daten erzeugt wird.
Listing :
init2.sql (Ausschnitt)
1 INSERT INTO SDO_GEOM_METADATA VALUES (’BodenFlaeche’,’Geometrie’,
2
MDSYS.SDO_DIM_ARRAY(MDSYS.SDO_DIM_ELEMENT(’X’,357000000,357300000,1),
3
MDSYS.SDO_DIM_ELEMENT(’Y’,576350000,576650000,1)));
4
5 CREATE INDEX IBodenFlaeche ON BodenFlaeche(Geometrie) INDEXTYPE IS
6
MDSYS.SPATIAL_INDEX PARAMETERS(’SDO_LEVEL=6, SDO_NUMTILES=12’);
Abbildung 5.3: Einfügen geometrischer Informationen in SDO GEOM METADATA und
Anlegen eines räumlichen Index
Die in Zeile 1 übergebenen Parameter definieren den Tabellennamen und den Namen
der Spalte, die ein räumliches Attribut ist. In der Zeile zwei wird ein Objekt vom
Typ MDSYS.SDO DIM ARRAY erzeugt, dass selbst zwei weitere objektwertige Attribute besitzt, die jeweils die minimalen und maximalen Werte der Koordinaten einer
Dimension angeben. Die vier Parameter bei der Erzeugung der Objekte vom Typ MDSYS.SDO DIM ELEMENT() sind der Name der Dimension, der minimale und der maximale Wert der Dimension und ein Toleranzwert.
In der Definition des Index wird durch INDEXTYPE IS MDSYS.SPATIAL INDEX angegeben, dass ein räumlicher Index angelegt werden soll. Die beiden Parameter bestimmen die Anzahl der Teilungen für das fixe (SDO LEVEL=6) und das hybride Indexieren
(SDO NUMTILES=12). Indexe und die Auswirkungen verschiedener Werte für die bei
der Indexierung anzugebenden Werte werden noch genauer in Kapitel 6 untersucht.
Nachdem die Metadaten der Tabellen mit geometrischen Informationen in die Relation
SDO GEOM METADATA eingetragen und die Indexe erzeugt sind, wird die Geometrie
der Daten auf ihre Gültigkeit überprüft, d.h. es wird überprüft, ob die Definition des
Geometrietyps mit den Realdaten übereinstimmt. Für die Boden- und die Nutzungspolygone kann dieser Test mithilfe der Datei
./Programme/Datenbereinigung/ueberpruefe_Layer.sql
durchgeführt werden. Für die Bodendaten erfolgt die Überprüfung der Geometrien wie
in Abbildung 5.4 dargestellt.
Die Methode gibt die Nummern der Polygone aus, die die in ihrer Definition definierten Eigenschaften nicht erfüllen. Der Fehler der Geometrie kann auch mit ausgegeben
werden, indem MDSYS.SDO GEOM.VALIDATE GEOMETRY(...) zusätzlich mit in den
select-Teil geschrieben wird. Mithilfe dieser Methode wurde festgestellt, dass bei den
gegebenen Polygonen Fehler auftreten. Die von Oracle ausgegebene Fehlermeldung ist,
dass sich Polygone selbst schneiden, wodurch die Begriffe Inneres und Äusseres nicht
mehr eindeutig zu definieren sind. Dies ist bei den Realdaten allerdings nicht der Fall.
5.4. DATENBEREINIGUNG DER GEOMETRIEDATEN
Listing :
63
ueberpruefe Layer.sql (Ausschnitt)
1 SELECT a.SNr AS BodenFlaeche
2 FROM
BodenFlaeche a,
3
SDO_GEOM_METADATA b
4 WHERE b.table_name=’BodenFlaeche’ and
5
b.column_name=’Geometrie’ and
6
MDSYS.SDO_GEOM.VALIDATE_GEOMETRY(
7
a.Geometrie,b.diminfo)!=’TRUE’;
Abbildung 5.4: Überprüfung der Geometrien der Bodenpolygone
Der Grund für die Fehlermeldung von Oracle sind numerische Ungenauigkeiten, die
durch eine Reduzierung des Toleranzwertes in der Relation SDO GEOM METADATA
weitgehend beseitigt werden können. Allerdings ist diese Fehlermeldung für ein Polygon der Informationsebene Boden dadurch nicht zu beheben. Es wird weiterhin vom
Oracle-Datenbanksystem als fehlerbehaftet angesehen.
5.4
Datenbereinigung der Geometriedaten
Die Topologie der Polygone der Informationsebenen Boden und Nutzung ist bisher in
der Datenbank nur implizit vorhanden. Die Polygone wurden sämtlich als einfache Polygone importiert, ihre Lage zueinander nicht berücksichtigt. Da aber neben einfachen
Polygonen auch Polygone mit Loch (Inselpolygone) vorhanden sind, die von Spatial unterstützt werden, müssen diese nun aus den vorhandenen Daten neu bestimmt werden.
Ein Inselpolygon ist in den Daten durch zwei einfache Polygone dargestellt, das äußere
und das innere Polygon. Solche Paare, in denen ein Polygon inklusive seinem Rand, topologisch im Innern eines anderen Polygons liegt, werden anschließend weiter bearbeitet,
indem das innere Polygon aus dem äußeren Polygon ausgeschnitten wird.
Spatial bietet für diese Differenzbildung von Polygonen die in Abschnitt 3.5.3.4 vorgestellte Methode MDSYS.SDO GEOM.SDO POLY INTERSECTION() an. Die Bestimmung
von Polygonpaaren, bei denen eines im topolgischen Innern eines anderen enthalten ist,
wird mithilfe des Operators SDO RELATE() unter Verwendung des Parameters contains
realisiert.
Abbildung 5.5 zeigt die gesamte Methode zur Berechnung der Inselpolygone am Beispiel
der Bodenpolygone. Für die Polygone der Informationsebene Nutzung. existiert eine
entsprechende Prozedur.
Da nun alle Daten in der Datenbank gespeichert sind, können Anfragen an die Datenbank
gestellt werden, die geometrische und Sachinformationen miteinander verknüpfen. Einige
Beispielanfragen sind in Anhang E angegeben. Teilweise benötigen sie allerdings auch
weitere Relationen, die erst später angelegt werden.
Zum Abschluß dieses Kapitels sind in den Abbildungen 5.6 bis 5.8 die Informationsebenen Boden, Nutzung und Relief veranschaulicht.
64
KAPITEL 5. DATENIMPORT
Die Abbildungen 5.6 und 5.7 stellen die bereinigten Daten der Informationsebenen Boden
bzw. Nutzung im Vektorformat dar. Abbildung 5.6 zeigt die quasihomogenen Flächen
der verschiedenen vorkommenden Bodenprofile im Untersuchungsgebiet, wobei gleiche
Farben für das gleiche Profil stehen. Im linken unteren Bereich sind in dieser Abbildung
mehrere Inseln auszumachen.
Listing :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
erzeuge Inselpolygone Boden.sql
CREATE OR REPLACE PROCEDURE set_InselnBoden
IS
-- In cur werden alle Paare (aSNr,bSNr) geladen fuer die gilt:
-- Flaeche(b) ist vollstaendig enthalten in Flaeche(a)
CURSOR cur IS
SELECT a.SNr AS aSNr, b.SNr as bSNr
FROM
BodenFlaeche a, BodenFlaeche b
WHERE a.SNr!=b.SNr AND
-- Vergleich der Standortnummern
MDSYS.SDO_RELATE(a.Geometrie,b.Geometrie,
’mask=CONTAINS querytype=JOIN’)=’TRUE’;
runner cur%ROWTYPE;
BEGIN
OPEN CUR;
LOOP
FETCH cur INTO runner;
EXIT WHEN cur%NOTFOUND;
-- Innerhalb der UPDATE-Anweisung werden die neuen Polygone berechnet,
-- d.h. Inseln werden aus aeusseren Polygonen geschnitten
UPDATE BodenFlaeche BF
SET BF.Geometrie =
(
SELECT MDSYS.SDO_GEOM.SDO_POLY_DIFFERENCE(a.Geometrie,b.diminfo,
c.Geometrie,b.diminfo)
FROM
BodenFlaeche a,
BodenFlaeche c,
SDO_GEOM_METADATA b
WHERE
b.table_name=’BodenFlaeche’ AND
a.SNr=runner.aSNr and c.SNr=runner.bSNr
)
WHERE BF.SNr=runner.aSNr;
END LOOP;
CLOSE cur;
END;
Abbildung 5.5: Berechnung von Inselpolygonen
In Abbildung 5.7 sind ebenfalls gleiche Farben gleichbedeutend mit gleicher Nutzung.
Die Nutzungsdaten beziehen sich dabei auf das Jahr 1996.
5.4. DATENBEREINIGUNG DER GEOMETRIEDATEN
Abbildung 5.6: Bodenklassen im Untersuchungsgebiet
Abbildung 5.7: Nutzung des Jahres 1996 im Untersuchungsgebiet
65
66
KAPITEL 5. DATENIMPORT
Abbildung 5.8: Höhenprofil
Abbildung 5.8 schließlich zeigt das Höhenprofil eines Gebietes, das als Rasterdatei mit
einem Rasterpunktabstand von 25 Metern aufgenommen wurde. Die Grenzen entsprechen allerdings nicht den Grenzen des Untersuchungsgebietes, das in etwa das zweite
und dritte Viertel in beiden Richtungen ausmacht. Hellere Farben entsprechen hierbei
größeren Höhenwerten.
Die Informationsebene Klima ist nicht dargestellt, da die Klimadaten für das gesamte
Untersuchungsgebiet als homogen angesehen werden.
Die zur Darstellung dieser Bilder verwendeten Programme sind in Anhang C beschrieben.
Sie werden auch für die weiteren in dieser Arbeit berechneten Bilder benutzt.
Kapitel 6
Methoden
In diesem Kapitel wird erläutert, wie Methoden der vom Niedersächsischen Landesamt
für Bodenforschung herausgegebenen Auswertungsmethoden im Bodenschutz [17] mit
der entwickelten Datenbank implementiert werden, um aus aufgenommenen Messwerten
(Primärinformationen) mehrerer Informationsebenen neue Daten (Sekundärinformationen) zu ermitteln und diese in Kartenform darzustellen.
Der prinzipielle Aufbau der Methoden zur Ableitung neuer Daten entspricht folgender
Struktur:
1. Ableitung neuer Daten innerhalb der Klassen
2. Ableitung neuer Daten innerhalb der Informationsebenen
3. Verschneidung von Informationsebenen
4. Ableitung neuer Daten für verschnittene Geometrien
Abhängig von der Anzahl der Informationsebenen, die als Eingangsdaten benötigt werden und der Verschneidungsreihenfolge, können dabei der dritte oder der dritte und vierte Schritt gemeinsam mehrmals nacheinander ausgeführt werden. Die Schritte 1,2 und
4 verknüpfen ausschließlich Sachdaten miteinander, in Schritt 3 werden Berechnungen
auf geometrischen Daten ausgeführt. Es ist nicht zwingend erforderlich die Reihenfolge der Schritte einzuhalten, die Berechnung der Verschneidungen kann auch vor den
Ableitungen der Sachdaten erfolgen. Dabei ist lediglich zu beachten, dass an die neuen
Geometrien Informationen zum Zugriff auf die Sachdaten geheftet werden. Die Ableitung der Sachdaten und die Verschneidung der geometrischen Daten kann also getrennt
voneinander betrachtet werden.
Der Aufbau dieses Kapitels lehnt sich an die vier oben genannten Schritte an. Zunächst
werden Ableitungen innerhalb von Klassen bzw. Informationsebenen betrachtet. Es folgen Untersuchungen über Verschneidungoperationen, wobei insbesondere auf räumliche
Indexe eingegangen wird. Schließlich werden die Methoden zur Ableitung von Daten
67
68
KAPITEL 6. METHODEN
vorgestellt, die Eingangsdaten mehrerer Informationsebenen benötigen. Diese entsprechen aber grundsätzlich den Methoden zur Ableitung innerhalb einer Informationsebene
(Schritt 2), da durch die Verschneidungen praktisch neue, mehrere Informationsebenen
zusammenfassende, Informationsebenen entstehen.
Als Beispiel wird in diesem Kapitel die Methode zur Ableitung der Sickerwasserrate
implementiert, die bereits in Abschnitt 4.1.5 kurz skizziert wurde.
6.1
Ableitungen innerhalb einer Klasse
Bei Ableitungen innerhalb einer Klasse werden aus vorhandenen Klassenattributen abgeleitete Werte berechnet, die ebenfalls ein Attribut der entsprechenden Klasse sind. Es
handelt sich bei den nun vorgestellten Methoden folglich um obkjektbezogene Ableitungen von Werten. Diese Ableitungen benötigen als weitere Eingangsdaten statische
Hilfstabellen, die aus dem NIBIS-Handbuch [17] bzw. der Bodenamtlichen Kartieranleitung [1] entnommen sind. Bei widersprüchlichen Aussagen dieser beiden Quellen wurde
nach der Bodenkundlichen Kartieranleitung verfahren. Auf die benötigten Hilfstabellen
wird jeweils in den Beschreibungen der Methoden eingegangen, die diese benötigen.
Bei der Methode zur Ableitung der Sickerwasserrate werden innerhalb der Klassen BodenHorizont und KlimaDatum abgeleitete Werte bestimmt. Die folgenden Unterabschnitte
erläutern die Implementierungen der einzelnen Methoden, zunächst für die Klasse BodenHorizont, anschließend für die der Klasse KlimaDatum.
6.1.1
Methoden der Klasse BodenHorizont
Innerhalb der Klasse BodenHorizont werden die drei Werte Lagerungsdichte (Ld), effektive Durchwurzelungstiefe (We) und nutzbare Feldkapazität (nFK) aus den aufgenommenen Daten bestimmt. Der Datenfluss innerhalb dieser Klasse ist in Abbildung
6.1 dargestellt. Hierbei ist zu berücksichtigen, dass im Untersuchungsgebiet nur Mineralböden vorliegen. Daher beschränken sich die Ableitungen auf diese Bodentypen. Für
andere Bodentypen sind weitere statische Hilfstabellen in die Datenbank zu importieren
und eventuell geringe Änderungen an den Methoden vorzunehmen (Ergänzungen von
Prozeduren, Umbenennungen von Tabellennamen o.ä.).
6.1.1.1
Lagerungsdichte
Zur Berechnung der Lagerungsdichte eines Bodenhorizonts werden als Eingangsdaten
die Rohdichte und der Tongehalt des jeweiligen Horizonts benötigt. Sind diese bekannt,
so kann die Lagerungsdichte LD nach folgender Formel berechnet werden.
LD = Rohdichte + 0.009 ∗ T ongehalt
6.1. ABLEITUNGEN INNERHALB EINER KLASSE
69
Klasse Bodenhorizont
Eingangsdaten
abgeleitete Werte
*
Bodenart
nutzbare Feldkapazität
Rohdichte
*
Lagerungsdichte
*
Tongehalt
effektive Durchwurzelungstiefe
des Horizonts
Horizontbezeichnung
: geht ein in die Berechnung von
* : unter Verwendung statischer Hilfsrelationen
Abbildung 6.1: Schematische Darstellung des Datenflusses innerhalb der Klasse BodenHorizont
Die Maßeinheit für die Lagerungsdichte ist Gramm pro Kubikzentimeter. Die Zuweisung
des Wertes für die Lagerungsdichtestufe LDStufe erfolgt mithilfe der (statischen) Hilfstabelle aus Abbildung 6.2. Diese ist aus dem Methodenhandbuch [17] bzw. der Bodenkundlichen Kartieranleitung [1], auf der das Methodenhandbuch basiert, übernommen und
wie in Abbildung 6.3 implementiert worden. Statische Hilfstabellen werden in mehreren
[g/cm3 ]
< 1.4
1.4− < 1.6
1.6 − 1.8
> 1.8 − 2.0
> 2.0
Bezeichnung
sehr gering
gering
mittel
hoch
sehr hoch
Kurzzeichen
Ld1
Ld2
Ld3
Ld4
Ld5
Abbildung 6.2: Einstufung der effektiven Lagerungsdichten (Ld) (entnommen aus [1])
Prozeduren für die Einteilung von ermittelten Werten in Stufen oder die Ermittlung neuer Werte anhand verschiedener Eingangsdaten benötigt. Hilfstabellen zur Einteilung von
LdStufe
1
2
3
4
5
LdMin
0
1.4
1.6
1.8
2
LdMax
1.4
1.6
1.8
2.0
100
Abbildung 6.3: Einstufung der effektiven Lagerungsdichten (Ld)
Werten in Stufen haben prinzipiell immer den in Abbildung 6.3 angegebenen Aufbau. Sie
werden daher im weiteren Text nur noch erwähnt, aber nicht mehr genau beschrieben.
Die Definition dieser Tabellen kann dem elektronischen Anhang entnommen werden.
70
KAPITEL 6. METHODEN
Ist ein für die Berechnung der Lagerungsdichte notwendiges Eingangsdatum nicht bekannt, so kann für bestimmte Horizonte anhand des Attributs Horizontbezeichnung unter
Verwendung der Hilfsrelation HT LdStufe der Wert für die Lagerungsdichtestufe LDStufe
abgeschätzt werden. Bei den vorhandenen Daten sind allerdings nicht allen Horizonten
Werte für LDStufe zuzuordnen, von insgesamt 82 in der Relation BodenHorizont vorhandenen Horizonten erhalten 78 einen Wert für LDStufe zugewiesen.
Die Prozedur zur Ableitung der Lagerungsdichte bzw. Lagerungsdichtestufe ist in Abbildung 6.4 dargestellt. Im ersten Teil wird die Lagerungsdichte für Horizonte berechnet,
Listing :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
-- Prozedur zur Berechnung der Lagerungsdichte
-- und zur Speicherung der Lagerungsdichtestufe
calculate ld.sql
CREATE OR REPLACE PROCEDURE calculate_ld IS
BEGIN
-- Rohdichte und Tongehalt bekannt
UPDATE BodenHorizont
SET
Ld = Rohdichte + 0.009*Tongehalt
WHERE
Rohdichte IS NOT NULL AND
Tongehalt IS NOT NULL;
-- Rohdichte oder Tongehalt nicht bekannt
UPDATE BodenHorizont H
SET
H.LDStufe = (
SELECT HT.LDStufe
FROM
HT_LDStufe HT
WHERE INSTR(H.Horizontbezeichnung,HT.Horizont)>0 AND
NOT EXISTS (
SELECT HT2.LDStufe
FROM
HT_LDStufe HT2
WHERE INSTR(H.Horizontbezeichnung,HT2.Horizont)>
INSTR(H.Horizontbezeichnung,HT.Horizont)))
WHERE
H.Rohdichte IS NULL OR H.Tongehalt IS NULL;
-- Lagerungsdichtestufen fuer die Horizonte abspeichern
-- fuer die eine Lagerungsdichte berechnet werden konnte
UPDATE BodenHorizont H
SET
H.LdStufe = (
SELECT T.LDStufe
FROM
T_LDStufe T
WHERE H.Ld>=T.ldmin AND
H.Ld<T.ldmax AND
H.Ld is not null)
WHERE
H.LD IS NOT NULL;
END;
Abbildung 6.4: Prozedur zur Ableitung der Lagerungsdichte(stufe)
deren Rohdichte und Tongehalt bekannt sind und mittels einer update-Anweisung den
Horizonten zugeordnet. Für Horizonte, bei denen mindestens eines dieser beiden Eingangsdaten nicht bekannt ist, wird anhand der Horizontbezeichnung aus der Hilfstabelle
HT LdStufe ein geschätzter Wert ermittelt. Allerdings existieren Horizonte, deren Bezeichnung aus Namen mehrerer Horizonte kombiniert ist. Dies ist der Fall, wenn Horizonte ineinander geschoben sind. Während sich die Bezeichnungen einfacher Horizonte
aus einem Hauptsymbol und einem Zusatzsymbol (z.B. Ah, wobei A das Hauptsymbol für einen A-Horizont ist und h das Zusatzsymbol für eine genauere Beschreibung
6.1. ABLEITUNGEN INNERHALB EINER KLASSE
71
des Horizonts) zusammensetzen, lauten Horizontbezeichnungen für ineinander geschobene Horizonte beispielsweise IIBv-T+cCv. Für solche Horizontbezeichnungen ist für die
Schätzung der Lagerungsdichtestufe die am weitesten rechts stehende Symbolkombination (der Leithorizont), im Beispiel Cv, entscheidend, die durch den Aufruf von instr()
und not exists erhalten wird.
Der dritte Teil schließlich weist den Horizonten, für die eine Lagerungsdichtestufe berechnet werden konnte, mithilfe der Hilfstabelle T LdStufe, die zugehörige Lagerungsdichtestufe zu.
6.1.1.2
Effektive Durchwurzelungstiefe eines Horizonts
Als nächstes wird die Methode zur Berechnung der effektiven Durchwurzelungstiefe eines Bodenhorizontes genauer betrachtet. Die effektive Durchwurzelungstiefe ist ein Maß
dafür, wie tief Wurzeln in den Boden eindringen können, um Wasser und Nährstoffe
aufzunehmen. Sie wird in Dezimetern angegeben. An dieser Stelle wird die effektive
Durchwurzelungstiefe eines einzelnen Horizontes berechnet. Dies ist die Grundlage für
die Methode zur Berechnung der effektiven Durchwurzelungstiefe eines Bodenprofils, die
in Abschnitt 6.2.1 erläutert wird.
Als Eingangsdaten für diese Methode werden die Bodenart und die Lagerungsdichtestufe LDStufe des Horizonts, sowie eine statische Hilfstabelle HT We benötigt, aus der die
effektive Durchwurzelungstiefe We bei Kenntnis von Bodenart und effektiver Lagerungsdichtestufe LDStufe ermittelt werden kann. Die in Abbildung 6.5 angegebene Prozedur
zeigt die Implementierung dieser Methode.
Listing :
1
2
3
4
5
6
7
8
9
10
11
calculate WeSchicht.sql
CREATE OR REPLACE PROCEDURE calculate_WeSchicht
IS
BEGIN
UPDATE BodenHorizont H
SET
H.We = (
SELECT T.We
FROM
HT_We T
WHERE T.Untergruppe=H.Bodenart AND
T.Ld=H.LdStufe
);
END;
Abbildung 6.5: Prozedur zur Ableitung der effektiven Durchwurzelungstiefe
Die Methode ermittelt zu den Tupeln der Relation BodenHorizont die entsprechenden
effektiven Durchwurzelungstiefen aus einer Hilfstabelle. Die äußere update-Anweisung
weist diesen Wert den Tupeln der Relation BodenHorizont zu.
72
KAPITEL 6. METHODEN
6.1.1.3
Nutzbare Feldkapazität eines Horizonts
Als Feldkapazität wird die Wassermenge bezeichnet, die ein Boden gegen die Schwerkraft
zurückhalten kann. Da in dem Wasser Stoffe gelöst sein können, ist sie ebenfalls ein Maß
für das Vermögen des Bodens die Verlagerung derartiger Stoffe in den Untergrund zu
verhindern (insbesondere auch Schadstoffe). Die nutzbare Feldkapazität nFK gibt an,
welcher Teil der Feldkapazität für die Vegetation nutzbar ist. Die Angabe erfolgt in
Millimeter pro Dezimeter bzw. Volumenprozent.
Ebenso wie die Methode zur Ableitung der effektiven Durchwurzelungstiefe eines Horizonts benötigt diese Methode als Eingangsdaten die Bodenart und die Lagerungsdichtestufe, soweit nur mineralische Böden betrachtet werden. Andere Böden benötigen weitere
Hilfstabellen. Anhand dieser Werte wird die nutzbare Feldkapazität aus der Hilfsrelation
Listing :
1
2
3
4
5
6
7
8
9
10
11
12
13
calculate nFK.sql
-- Diese Prozedur bezieht sich bisher nur auf Tabelle 1,
-- also auf Feinboeden mit Humusgehalten <15%
-- andere existieren im Untersuchungsgebiet nicht
CREATE OR REPLACE PROCEDURE calculate_nFK
IS
BEGIN
UPDATE BodenHorizont H
SET
H.nFK = (
SELECT T.nFK
FROM
HT_nFK T
WHERE H.Bodenart=T.Untergruppe AND
H.LdStufe=T.Ld);
END;
Abbildung 6.6: Prozedur zur Ableitung der nutzbaren Feldkapazität
HT nFK ermittelt und in einer update-Anweisung den entsprechenden Tupeln zugeordnet. Die Methode ist in Abbildung 6.6 angegeben.
6.1.2
Methoden der Klasse KlimaDatum
Innerhalb der Klasse KlimaDatum, die zur Definition der geschachtelten Tabelle innerhalb
der Informationsebene Klima zur Aufnahme der Messdaten erzeugt wurde, werden drei
Werte abgeleitet: der Sättigungsdampfdruck (EW T14 ), der aktuelle Dampfdruck (ET14 )
und die potenzielle Verdunstung nach Haude (ET Phaude ).
Das in Abbildung 6.7 dargestellte Datenflussdiagramm zeigt, dass der Sättigungsdampfdruck (EWT14) aus der Temperatur und der aktuelle Dampdruck (ET14) aus dem
Sättigungsdamfdruck und der relativen Feuchte abgeleitet wird. In die Berechnung der
potenziellen Verdunstung nach dem Verfahren von Haude gehen diese beiden Werte, die
daher zunächst abzuleiten sind, sowie der Monat ein.
6.1. ABLEITUNGEN INNERHALB EINER KLASSE
73
Klasse KlimaDatum
Eingangsdaten
abgeleitete Werte
Temperatur
EWT14
relative Feuchte
ET14
Monat
ETPhaude
: geht ein in die Berechnung von
Abbildung 6.7: Schematische Darstellung des Datenflusses innerhalb der Klasse KlimaDatum
6.1.2.1
Sättigungsdampfdruck
Der Sättigungsampfdruck is abhängig von der Temperatur. Nach DIN 19685 (1996)
berechnet er sich nach folgenden Formeln, wobei der Parameter t die Temperatur angibt:
17.84362∗t
−5o C bis 0o C EW T14 = 6.1078 ∗ 2.71828 245.425+t
17.08085∗t
0o C bis 50o C EW T14 = 6.1078 ∗ 2.71828 234.175+t
Der Wert für den Sättigungsdampfdruck ist im mbar angegeben. Die entsprechenden
Berechnungen werden durch die Prozedur aus Abbildung 6.8 durchgeführt. Diese ProListing :
1
2
3
4
5
6
7
8
9
10
11
calculate ewt14.sql
CREATE OR REPLACE PROCEDURE calculate_ewt14
IS
BEGIN
UPDATE TABLE (SELECT klimadaten FROM Klima K)
SET ewt14 = 6.1078*power(2.71828,(17.84362*Temperatur)/(245.425+Temperatur))
WHERE Temperatur>=-5 AND Temperatur<=0;
UPDATE TABLE (SELECT klimadaten FROM Klima K)
SET ewt14 = 6.1078*power(2.71828,(17.08085*Temperatur)/(234.175+Temperatur))
WHERE Temperatur>0 AND Temperatur<=50;
END;
Abbildung 6.8: Prozedur zur Ableitung des Sättigungsdampfdrucks
zedur (ebenso die beiden folgenden) setzt Werte in einer Relation (KlimaDaten), die in
einer anderen (Klima) geschachtelt ist.
6.1.2.2
Aktueller Dampfdruck
Der aktuelle Dampfdruck wird ebenfalls mithilfe einer einfachen Formel nach der oben
angegebenen DIN-Norm berechnet:
ET14 = EW T14 ∗
RF euchte
100
74
KAPITEL 6. METHODEN
Die dafür verwendete Prozedur zeigt Abbildung 6.9.
Listing :
1
2
3
4
5
6
CREATE OR REPLACE PROCEDURE calculate_et14
IS
BEGIN
UPDATE TABLE (SELECT klimadaten FROM Klima K)
SET et14 = ewt14*RFeuchte/100;
END;
calculate et14.sql
Abbildung 6.9: Prozedur zur Ableitung des aktuellen Dampfdrucks
6.1.2.3
Potenzielle Verdunstung nach Haude
Die Berechnungsvorschrift für die potenzielle Verdunstung nach Haude ist ebenfalls
durch die DIN-Norm 19685 festgelegt:
ET PHaude = f (m) ∗ (EW T14 − ET14 )
Dabei ist f(m) ein vom Monat, in dem der Tag liegt, für den die potenzielle Verdunstung berechnet werden soll, abhängiger Faktor (siehe Tabelle 6.10). EW T14 bzw. ET14
sind die vorher berechneten Werte für den Sättigungsdampfdruck bzw. den aktuellen
Dampfdruck.
April-Mai
0.29
Juni
0.28
Juli
0.26
August
0.25
September
0.23
Oktober-März
0.22
Abbildung 6.10: Monatsvariabler Faktor zur Berechnung von ET PHaude
Das Ergebnis der Anwendung der Prozedur aus Abb. 6.11 liegt in mm pro Tag vor.
Die Methode verändert in der Tabelle Klima jeweils die Tupel eines oder mehrerer Monate
nach der angegebenen Formel mit dem entsprechenden Monatsfaktor.
Die Monatsangabe der einzelnen Tupel der geschachtelten Tabelle KlimaDaten wird in
der where-Klausel zunächst aus der Datumsangabe isoliert. Diese Monatsangabe wird
anschließend in eine Zahl umgewandelt und zur Selektion der Tupel einzelner Monate
benutzt, die in der jeweiligen update-Anweisung modifiziert werden.
Der nächste Abschnitt beschäftigt sich mit der Ableitung von Werten innerhalb der
einzelnen Informationsebenen. Die dort vorgestellten Methoden setzen voraus, dass die
Werte innerhalb einzelner Klassen bereits abgeleitet sind.
6.2
Ableitungen innerhalb einer Informationsebene
Methoden zur Ableitung von Werten innerhalb einer Informationsebene existieren bisher
ausschließlich für die Informationsebene Boden, da nur hier Instanzen mehrerer Klassen
6.2. ABLEITUNGEN INNERHALB EINER INFORMATIONSEBENE
Listing :
75
calculate etphaude.sql (Ausschnitt)
1 CREATE OR REPLACE PROCEDURE calculate_etphaude
2 IS
3 BEGIN
4
-- April und Mai
5
UPDATE table (SELECT klimadaten from Klima K)
6
SET
etphaude = 0.29*(ewt14-et14)
7
WHERE TO_NUMBER(TO_CHAR(datum,’MM’)) BETWEEN 4 AND 5;
8
-- Juni
9
UPDATE table (SELECT klimadaten from Klima K)
10
SET
etphaude = 0.28*(ewt14-et14)
11
WHERE TO_NUMBER(TO_CHAR(datum,’MM’))=6;
-- Juli bis September einzeln wie Juni
24
-- Oktober bis Maerz
25
UPDATE table (SELECT klimadaten from Klima K)
26
SET
etphaude = 0.22*(ewt14-et14)
27
WHERE TO_NUMBER(TO_CHAR(datum,’MM’)) BETWEEN 10 AND 12 OR
28
TO_NUMBER(TO_CHAR(datum,’MM’)) BETWEEN 1 AND 3;
29 END;
Abbildung 6.11: Prozedur zur Ableitung der potenziellen Verdunstung nach Haude (Ausschnitt)
an einen Standort gebunden sind. Diese Art von Methoden sind standortbezogen,
das heißt sie berechnen Werte für einen Standort. Dass diese Werte anschließend für
die gesamte dem Standort zugeordnete Fläche gelten ist dabei irrelevant, da die dem
Standort zugeordneten Daten für diese Fläche repräsentativ sind.
Aus dem Modell der Informationsebene Boden ist ersichtlich, dass einer Instanz der
Klasse BodenProfil eine Instanz der Klasse Boden und eine oder mehrere Instanzen der
Klasse BodenSchicht zugeordnet sind. Die Attribute der Klasse BodenProfil werden aus
Attributen dieser beiden Klassen abgeleitet. Es werden also mehrere Klassen einer Informationsebene miteinander verknüpft. Im Einzelnen sind in der Informationsebene
Boden für ein Bodenprofil die effektive Durchwurzelungstiefe We (im Gegensatz zur
Methode für einen Bodenhorizont werden hier alle Horizonte des Bodenprofils betrachtet), die nutzbare Feldkapazität des effektiven Wurzelraumes nFKWe und die mittlere
kapillare Aufstiegsrate KRmm zu bestimmen. Hinzu kommen noch Einteilungen der
Ergebniswerte in Stufen.
Abbildung 6.12 zeigt den Datenfluss für diese Methoden.
Die nachfolgenden Abschnitte erläutern die innerhalb der Informationsebene Boden implementierten und durchzuführenden Methoden.
6.2.1
Effektive Durchwurzelungstiefe eines Bodenprofils
Die effektive Durchwurzelungstiefe eines Bodenprofils gibt an, wie tief Wurzeln theoretisch in den Boden wachsen können (siehe Abbildung 6.13). Die tatsächliche Tiefe der
Durchwurzelung eines Bodens ist noch von anderen Faktoren abhängig, beispielsweise
76
KAPITEL 6. METHODEN
Informationsebene Boden
abgeleitete Werte
Eingangsdaten
BodenHorizont
BodenProfil
*
ProfilHorizonte
effektive Durchwurzelungstiefe des Bodenprofils
Boden
*
*
mittlere kapillare Aufstiegsrate in mm KRmm
nutzbare Feldkapazität desn
effektiven Wurzelraumes des
Bodenprofils nFKWe
: geht ein in die Berechnung von
* : unter Verwendung statischer Hilfsrelationen
Abbildung 6.12: Schematische Darstellung des Datenflusses innerhalb der Informationsebene Boden
von der Nutzungsart des Bodens, da verschiedene Pflanzen ihre Wurzeln unterschiedlich
tief im Boden verankern.
Horizont A
effektive
Durchwurzelungstiefe des
Bodenprofils
Horizont B1
Horizont B2
effektive Durchwurzelungstiefe des Horizontes B2
Horizont C
Abbildung 6.13: effektive Durchwurzelungstiefe
Um die effektive Durchwurzelungstiefe eines Bodenprofils zu bestimmen, werden die effektiven Durchwurzelungstiefen der einzelnen Bodenhorizonte von oben nach unten betrachtet. Ist die effektive Durchwurzelungstiefe eines Bodenhorizontes größer oder gleich
seiner Mächtigkeit, so wird die Horizontmächtigkeit zur effektiven Durchwurzelungstiefe
des Bodenprofils addiert. In Abbildung 6.13 gilt dies für die Horizonte A und B1. Ist
die effektive Durchwurzelungstiefe eines Horizonts kleiner als die Horizontmächtigkeit,
so wird die effektive Durchwurzelungstiefe des Horizontes zur effektiven Durchwurzelungstiefe des Bodenprofils addiert (Horizont B2) und die darunter liegenden Horizonte
werden nicht mehr betrachtet (Horizont C). Anschaulich ist dies beispielsweise der Fall,
wenn im Boden ein Horizont aus Steinen auftritt, durch den die Wurzeln nicht wachsen
können. Die in Abbildung 6.14 angegebene Prozedur berechnet die effektive Durchwurzelungstiefe eines Bodenprofils.
6.2. ABLEITUNGEN INNERHALB EINER INFORMATIONSEBENE
77
Zunächst wird ein Cursor definiert. Die Attribute sind die Nummer des Bodenprofils,
die Nummern der zugehörigen Instanzen der Klasse BodenHorizont, die effektiven Durchwurzelungstiefen der Horizonte, sowie die obere und untere Tiefe der Horizonte im Boden. Diese Attribute werden durch einen Verbund über drei Tabellen und anschließende
Projektion ermittelt. Das Ergebnis der Anfrage wird nach Profilnummer und oberer Horizonttiefe geordnet. Bei der Auswertung des Anfrageergebnisses werden in einer Schleife
die einzelnen Tupel betrachtet und die in der Beschreibung der Methode angegebenen
Überprüfungen bezüglich Horizontmächtigkeit und effektiver Durchwurzelungstiefe des
jeweiligen Horizontes durchgeführt. Die in dieser Prozedur verwendeten Variablen sind
APNr für die Nummer des letzten betrachteten Profils und edt zur Zwischenspeicherung
der effektiven Durchwurzelungstiefe, damit nur ein schreibender Zugriff pro Bodenprofil
auf die Datenbank notwendig ist.
In Zeile 27 wird überprüft, ob ein neues Profil betrachtet wird. Ist dies der Fall, so wird
der aktuelle Wert von edt dem letzten Bodenprofil (Nummer in APNr) zugewiesen. stop
wird auf 0 gesetzt. Diese Variable wird verwendet, um gegebenenfalls Horizonte nicht zu
beachten. Ist stop gleich 0, so wird in Zeile 35 die Schichtmächtigkeit des aktuellen Cursortupels mit seiner effektiven Durchwurzelungstiefe verglichen. Ist sie größer, so wird
edt der Wert der effektiven Durchwurzelungstiefe des Horizonts zuzüglich der oberen
Horizonttiefe zugeordnet. stop wird auf 1 gesetzt und dadurch die nächsten Tupel des
Cursors nicht mehr untersucht. Beim nächsten Profilwechsel wir der Wert von edt dem
richtigen Profil zugewiesen (Nummer in APNr). Ist in Zeile 35 die Schichtmächtigkeit
kleiner als die effektive Durchwurzelungstiefe, so wird edt auf die untere Schichttiefe gesetzt und in Zeile 23 das nächste Tupel geholt. Die Speicherung in edt ist notwendig, da
das Schreiben des Wertes in der Datenbank erst beim nächsten Horizontwechsel erfolgt.
Nachdem die loop-Schleife beendet ist, ist in edt noch die effektive Durchwurzelungstiefe des letzten betrachteten Bodenprofils vorhanden, die noch nicht geschrieben wurde.
APNr enthält die Nummer des letzten Bodenprofils. Die Zeilen 45 bis 47 weisen dem
entsprechenden Datensatz diesen Wert zu.
In den Zeilen 53 bis 61 werden die Werte der effektiven Durchwurzelungstiefe gegebenenfalls korrigiert, da die effektive Durchwurzelungstiefe einen Wert haben muss, der
mindestens 10cm oberhalb des Grundwasserstandes liegt. Hierfür wird ein Verbund der
Relationen BodenProfil, Boden und T Grundwasserstufen (Hilfsrelation) gebildet und anschließend die entsprechenden Tupel korrigiert.
78
KAPITEL 6. METHODEN
Listing :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
calculate We.sql
CREATE OR REPLACE PROCEDURE calculate_We
IS
-- Anfrage ergibt Bodenprofilnummern, Horizontnummern des
-- Bodenprofils mit oberer und unterer Horizonttiefe sowie
-- die effektive Durchwurzelungstiefe der Horizonte
-- sortiert nach Bodenprofilnummer und oberer Tiefe dr Horizonte
CURSOR cur IS
SELECT a.BPNr,b.Otief,b.utief,c.HNr,c.We
FROM BodenProfil a, ProfilHorizont b, BodenHorizont c
WHERE a.BPNr=b.BPNr AND
b.HNr=c.HNr
ORDER BY a.BPNr,Otief;
runner cur%ROWTYPE;
APNr INTEGER;
stop INTEGER;
edt FLOAT;
BEGIN
APNr:=0; -- Alte Profilnummer
STOP:=0; -- =0:weiter summieren, =1:tiefere Horizonte nicht beachten
OPEN cur;
LOOP
FETCH cur INTO runner;
EXIT WHEN cur%NOTFOUND;
-- Werte fuer We werden gespeichert, wenn ein Profilwechsel
-- stattfindet. Wert fuer letztes Profil nach der LOOP-Schleife.
IF(APNr!=runner.BPNr) THEN -- Profilnummer geaendert ?
UPDATE BodenProfil
-- ja -> Wert fuer edt
SET
We=edt
-- letztem Profil zuweisen
WHERE BPNr=APNr;
STOP:=0;
APNr:=runner.BPNr;
-- APNr auf aktuelles Profil setzen
END IF;
IF(STOP=0) THEN
-- *0.1 wegen Angaben in cm bzw. dm
IF((runner.Utief-runner.Otief)*0.1>=runner.We) THEN
edt:=runner.Otief+runner.We*10;
STOP:=1;
ELSE
edt:=runner.Utief;
END IF;
END IF;
END LOOP;
-- Letzten Wert schreiben
UPDATE BodenProfil
SET
We=edt
WHERE BPNr=APNr;
CLOSE cur;
COMMIT;
-- Korrektur: We min 10 cm ueber Grundwasser
UPDATE BodenProfil BP
SET BP.We = ( SELECT (TG.min-1)*10
FROM
T_Grundwasserstufen TG, Boden B
WHERE B.Grundwasserstufe = TG.gws AND
B.BNr = BP.BNr)
WHERE BP.We > ( SELECT (TG.min-1)*10
FROM
T_Grundwasserstufen TG, Boden B
WHERE B.Grundwasserstufe = TG.gws AND
B.BNr = BP.BNr);
END;
Abbildung 6.14: Prozedur zur Ableitung der effektiven Durchwurzelungstiefe eines Bodenprofils
6.2. ABLEITUNGEN INNERHALB EINER INFORMATIONSEBENE
79
Abbildung 6.15 zeigt qualitativ die effektive Durchwurzelungstiefe des Untersuchungsgebietes. Hellere Farben entsprechen höherer effektiver Durchwurzelungstiefe, schwarzen
Flächen ist der Zahlenwert 0 zugeordnet.
Abbildung 6.15: effektive Durchwurzelungstiefe des Untersuchungsgebietes
6.2.2
Nutzbare Feldkapazität des effektiven Wurzelraumes
In Abschnitt 6.1.1.3 wurde bereits erläutert, dass die nutzbare Feldkapazität ein Maß
für das Vermögen des Bodens ist, Wasser gegen die Schwerkraft und, damit verbunden, im Wasser gelöste (Schad)Stoffe, zurückzuhalten und dieses für die Vegetation zu
nutzen. In 6.1.1.3 wurde die nutzbare Feldkapazität aber lediglich für Bodenhorizonte
angegeben. Zur Berechnung der nutzbaren Feldkapazität des effektiven Wurzelraums eines Bodenprofils werden die nutzbaren Feldkapazitäten der einzelnen Bodenhorizonte
von der Oberfläche bis zum Horizont, in dem die effektive Durchwurzelungstiefe endet,
aufaddiert.
Die Prozedur hierzu ist in Abbildung 6.16 dargestellt. Innerhalb einer äußeren updateAnweisung werden die nutzbaren Feldkapazitäten aufsummiert und anschließend dem
entsprechenden Tupel der Relation Bodenprofil zugeordnet.
80
KAPITEL 6. METHODEN
Listing :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
calculate nFKWe.sql
CREATE OR REPLACE PROCEDURE calculate_nFKWe
IS
BEGIN
UPDATE BodenProfil BP
SET nFKWe = (
-- nutzbare Feldkapazitaeten B.nFK der einzelnen
-- BodenHorizonte B werden bis zur effektiven
-- Durchwurzelungstiefe We des Bodenprofils BP
-- aufsummiert. Faktor 0.1 wg. unterschiedlicher
-- Einheiten (cm bzw. dm)
SELECT SUM(B.nfk*(PH.Utief-PH.otief)*0.1)
FROM
BodenHorizont B, ProfilHorizont PH
WHERE BP.bpnr=PH.bpnr AND
B.hnr=PH.hnr AND
PH.otief*0.1<BP.We
GROUP BY BP.bpnr);
END;
Abbildung 6.16: Prozedur zur Ableitung der nutzbaren Feldkapazität des effektiven Wurzelraums
Abbildung 6.19 zeigt qualitativ die nutzbare Feldkapazität des effektiven Wurzelraumes des Untersuchungsgebietes. Dabei entsprechen hellere Farben höheren nutzbaren
Feldkapazitäten des effektiven Wurzelraums.
6.2.3
Ableitung der mittleren kapillaren Aufstiegsrate
Der kapillare Aufstieg ist ein Maß für die Versorgung der Vegetation mit Grundwasser
während Trockenzeiten. Sie wird in Millimeter pro Tag angegeben. In die Ableitung der
Listing :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
-- Berechnet die Grenzflurabstand.
-- Grenzflurabstand = Abstand zwischen Untergrenze
-- der effektiven Ducrhwurzelungstiefe und dem
-- Grundwasser. Falls Grenzflurabstand < 2 wird er
-- fuer weitere Berechnungen auf 2 gesetzt
CREATE OR REPLACE PROCEDURE calculate_za
IS
BEGIN
UPDATE BodenProfil BP
SET
BP.za = (
SELECT ROUND(HT.min-BP.We*0.1)
FROM
Boden B,
T_Grundwasserstufen HT
WHERE BP.BNr=B.BNr
AND
B.Grundwasserstufe = HT.gws;
calculate za.sql
UPDATE BodenProfil BP
SET
BP.za = 2
WHERE BP.za < 2;
END;
Abbildung 6.17: Prozedur zur Ableitung des Grenzflurabstands
kapillaren Aufstiegsrate gehen die Bodenart des Bodens, die Lagerungsdichte des Bo-
6.2. ABLEITUNGEN INNERHALB EINER INFORMATIONSEBENE
81
denhorizonts in dem die effektive Durchwurzelungstiefe endet, sowie der Abstand zwischen dem Grundwasser und der effektiven Durchwurzelungstiefe ein. Dieser Abstand,
Grenzflurabstand genannt, wird zunächst mit der Prozedur aus Abbildung 6.17 berechnet. Hierzu wird aus der Relation Boden, die zu dem betrachteten Bodenprofil gehört
die Grundwasserstufe ermittelt und anschließend aus einer Hilfstabelle die obere Grenze
dieser Grundwasserstufe ausgelesen (Zeilen 19 und 11). Hiervon wird die effektive Durchwurzelungstiefe des Bodenprofils subtrahiert und das Ergebnis in za gespeichert. Ist der
ermittelte Grenzflurabstand kleiner als zwei (Dezimeter), so wird er per Definition auf
zwei gesetzt. Dies ist für die Ableitung der mittleren kapillaren Aufstiegsrate notwendig.
Listing :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
calculate KR.sql
CREATE OR REPLACE PROCEDURE calculate_KR
IS
BEGIN
UPDATE BodenProfil BP
SET
BP.KRmm = (
SELECT HT.KRmm
FROM
BodenHorizont H,ProfilHorizont PH, HT_KRmm HT
WHERE
PH.BPNr
= BP.BPNr AND -- und Bodenschichten bestimmen
PH.HNr
= H.HNr
AND -- Horizont an unterer Grenze der
PH.Otief
< BP.We
AND -- effektiven Durchwurzelungstiefe
PH.Utief
>= BP.We
AND -- bestimmen
H.LDStufe = HT.LDStufe AND -- LDStufe, Bodenart des HoriH.Bodenart = HT.Bodenart AND -- zonts fuer Hilfstabelle
HT.za
= BP.za);
-- abstand gws,we
UPDATE BodenProfil BP
SET
BP.KRStufe = (
SELECT TKR.KRStufe
FROM
T_KRStufe TKR
WHERE
BP.KRmm > TKR.min AND
BP.KRmm <= TKR.max);
END;
Abbildung 6.18: Prozedur zur Ableitung der mittleren kapillaren Aufstiegsrate
Abbildung 6.18 zeigt ihre Ableitung. Es werden mithilfe der Relationen BodenProfil und
ProfilHorizont der Horizont, in dem die effektive Durchwurzelungstiefe endet sowie seine
Lagerungsdichte bestimmt. Unter weiterer Verwendung des Grenzflurabstands und der
Bodenart des Profils wird aus einer Hilfsrelation (HT KRmm) die kapillare Aufstiegsrate
in Millimetern pro Tag ausgelesen. Die äußere update-Anweisung ordnet die Werte den
jeweiligen Tupeln zu.
Abbildung 6.20 zeigt qualitativ die mittlere kapillare Aufstiegsrate des Untersuchungsgebietes. Auch hier entsprechen hellere Farben einem höheren Wert. Weißen Flächen
konnte allerdings kein Wert zugewiesen werden, da Eingangsdaten nicht vorhanden waren.
82
KAPITEL 6. METHODEN
Abbildung 6.19: Nutzbare Feldkapazität des Untersuchungsgebietes
Abbildung 6.20: KRmm des Untersuchungsgebietes
6.3. VERSCHNEIDUNG VON INFORMATIONSEBENEN
6.3
83
Verschneidung von Informationsebenen
Neben den bisher vorgestellten Methoden, die Daten innerhalb einer Informationsebene
bzw. einer Klasse miteinander verknüpfen und an ein Objekt oder einen Standort mit
zugeordneter quasi-homogener Fläche gebunden sind, existieren weitere Methoden, die
Daten mehrerer Informationsebenen zueinander in Beziehung setzen. Für diese Methoden müssen die geometrischen Informationen beachtet und neue Geometrien berechnet
werden. Diese Berechnung neuer Geometrien wird als Verschneidung bezeichnet und
bildet den Gegenstand der folgenden Unterabschnitte.
6.3.1
Vorbereitungen zur Kartenerzeugung
In der Geografie werden Informationen über Eigenschaften eines Untersuchungsgebietes
häufig in Form von Karten repräsentiert. Die Kartenerstellung fällt in den Bereich der
Kartographie. Diese ermöglicht Aussagen über alle Objekte, die einen räumlichen
”
Bezug aufweisen und sich durch mindestens ein weiteres Merkmal (Attribut) unterscheiden lassen“ 1 . Unter Objekten werden hierbei im weitesten Sinne konkrete Gegenstände
(Gebäude, Flüsse, Flächen) verstanden, denen (abstrakte) Sachverhalte als Eigenschaften zugeordnet sind. Weiterhin benötigen Objekte einen räumlichen Bezug, um ihre Eigenschaften in Karten darzustellen. Der räumliche Bezug ist gewöhnlich entweder durch
Vektoren gegeben, die die Lage eines Objektes beschreiben, oder durch Rasterpunkte,
denen ein Objekt (oder ein Merkmal eines Objektes) zugeordnet ist (Vgl. Kapitel 2).
Die Methode zur Ableitung der Sickerwasserrate verknüpft Informationen vier gegebener
Informationsebenen. Die räumliche Lage der Objekte ist für die Informationsebenen
Boden, Nutzung und Klima durch Polygone (Vektordaten), für die Informationsebene
Relief durch Rasterdaten gegeben.
Es gibt demnach drei mögliche Kombinationen von Verschneidungen:
• Verschneidung von Vektordaten mit Vektordaten (Ergebnis im Vektorformat)
• Verschneidung von Rasterdaten mit Vektordaten (Ergebnis im Rasterformat)
• Verschneidung von Rasterdaten mit Rasterdaten (Ergebnis im Rasterformat)
Diese verschiedenen Arten von Verschneidungen werden in den folgenden Unterabschnitten erläutert.
Zunächst müssen jedoch Relationen für die Aufnahme der Verschneidungsergebnisse
angelegt werden. Bei der Verschneidung zweier Informationsebenen werden Tripel von
Informationen erhalten, die das Ergebnis der Verschneidung repräsentieren. Ein Tripel
besteht aus einem geometrischen Objekt und zwei Sachinformationen. Die Sachinformationen verknüpfen das neue geometrische Objekt mit den Sachdaten der verschnitten
1
G.Hake, D.Grünreich, Kartographie [12] S.7
84
KAPITEL 6. METHODEN
Informationsebenen und sind gewöhnlich Verweise auf Schlüsselattribute von Objekten.
Eine Relation, die das Ergebnis einer Verschneidung zweier Informationsebenen aufnimmt, hat daher die in Abbildung 6.21 angegebene Struktur.
Geometrie
1
2
3
4
5
6
7
8
Sachdatum Informationsebene 1 Sachdatum Informationsebene 2
Objekt 1
Objekt4
Objekt 1
Objekt7
Objekt 2
Objekt5
Objekt 3
Objekt4
Objekt 4
Objekt2
Objekt 4
Objekt3
Objekt 5
Objekt1
Objekt 5
Objekt6
Abbildung 6.21: Ergebnistabelle für Verschneidungen
Die erste Zeile der Tabelle besagt, dass die neu berechnete Geometrie 1 die Eigenschaften
von Objekt 1 der einen und die Eigenschaften von Objekt 2 der anderen verschnittenen
Informationsebene besitzt. Um nun weitere Sachdaten auf den neu erzeugten Geometrien
zu berechnen, deren Ableitungsprozedur Eingangsdaten der beiden verschnittenen Informationsebenen benötigt, werden einfach über die Schlüsselattribute die entsprechenden
Sachinformationen der Objekte referenziert und die neuen Werte daraus abgeleitet. Dies
eignet sich allerdings nur für Einmalberechnungen, deren Ergebnisse anschließend wieder
verworfen werden. Um die Ergebnisse von Berechnungen auf Daten verschnittener Informationsebenen dauerhaft in der Datenbank zu speichern, bedarf es weiterer Attribute
in der Tabelle, die das Ergebnis der Verschneidung repräsentiert. Diese hinzuzufügenden
Attribute nehmen anschließend die Werte abgeleiteter Informationen auf.
In der vorliegenden Arbeit werden mehrere Relationen für die Aufnahme von Ergebnissen
von Verschneidungsoperationen angelegt. Zusätzlich zu einem geometrischen Attribut
besitzen sie weitere Attribute, um auf den verschnittenen Geometrien neue Sachdaten
abzuleiten. Beispielhaft wird eine Relation angelegt, die das Ergebnis der Verschneidung
der Informationsebenen Boden und Nutzung im Vektorformat aufnimmt und innerhalb
dieser neu erzeugten verschnittenen Informationsebene abzuleitende Werte speichert.
Die Definition dieser Relation ist in Abbildung 6.22 dargestellt.
FNr ist das Schlüsselattribut der Relation, Geometrie dient der Speicherung der neuen Geometrien, die durch den Verschneidungsprozess berechnet werden. SNrBoden und
SNrNutzung sind Fremdschlüsselattribute, die Objekte der Relationen BodenStandort
und NutzungStandort referenzieren, die für die in Geometrie abgelegte Geometrie gültig
sind. Mithilfe der durch diese Fremdschlüssel referenzierten Objekte werden die Werte
der weiteren Attribute Dauer des kapillaren Aufstiegs (TA), mittlere kapillare Aufstiegsrate (KA) und pfanzenverfügbares Bodenwasser (WPFL) abgeleitet. Die Prozeduren zur
Berechnung dieser drei Attribute benötigen als Eingangsdaten Informationen der Informationsebene Nutzung und der Informationsebene Boden. Die Ableitungsprozeduren für
6.3. VERSCHNEIDUNG VON INFORMATIONSEBENEN
85
CREATE TABLE
FNr
Geometrie
SNrBoden
SNrNutzung
TA
KA
WPFL
CONSTRAINT
CONSTRAINT
VBN (
-- Verschnitt Boden Nutzung
INTEGER,
MDSYS.SDO_GEOMETRY,
INTEGER,
INTEGER,
FLOAT,
FLOAT,
FLOAT,
PK_VBN PRIMARY KEY (FNr),
FK_VBN_SNrBoden
FOREIGN KEY (SNrBoden)
REFERENCES BodenStandort(SNr),
CONSTRAINT FK_VBN_SNrNutzung FOREIGN KEY (SNrNutzung)
REFERENCES NutzungStandort(SNr) );
Abbildung 6.22: Definition einer Relation zur Aufnahme des Verschneidungsergebnisses
der Informationsebenen Boden und Nutzung
diese Sachattribute werden in Abschnitt 6.5 vorgestellt.
Für Verschnitte mit weiteren Informationsebenen müssen Relationen für alle beteiligten
Informationsebenen Fremdschlüsselattribute für die Sachdaten für die an der Verschneidung beteiligten Geometrien besitzen, sowie Attribute für abzuleitende Daten. Strukturell entsprechen sie aber der angegebenen Relation.
Alternativ können auch die Fremdschlüsselattribute entfernt und durch die Attribute des
durch den Fremdschlüssel referenzierten Objektes ersetzt werden. Dies führt aber zu einer redundanten Datenspeicherung, insbesondere für Relationen, die die Ergebnisse von
Verschneidungen im Rasterformat aufnehmen und die Attribute für jeden Rasterpunkt
abspeichern müssen. Die redundante Speicherung kann allerdings trotzdem angebracht
sein, beispielsweise wenn dadurch bei Anfragen die Verbundbildung mehrerer sehr umfangreicher Relationen vermieden werden kann.
Die für Verschneidungen im Rasterformat anzulegenden Ergebnisrelationen haben prinzipiell dieselbe Struktur wie die Ergebnisrelationen im Vektorformat, da sie ebenfalls ein
geometrisches Objekt, in diesem Fall einen Punkt, und Sachdaten speichern. Beipielhaft
ist in Abbildung 6.23 die Definition der Ergebnisrelation für die Verschneidung der vier
an der Ableitung der Methode zur Berechnung der Sickerwasserrate beteiligten Informationsebenen für das Rasterformat dargestellt. Der Name RasterAll10 deutet an, dass
dieses Raster für einen Rasterpunktabstand von 10 Metern verwendet wird.
Die Relation RasterAll10 besitzt als Schlüsselattribut PNr. Dieses Attribut dient auch der
Referenzierung der Koordinaten des Punktes in der Relation Raster10 (siehe Abschnitt
6.3.3) und ist daher ebenfalls als Fremdschlüssel definiert. Die Attribute SNrBoden, SNrNutzung, SNrKlima und PNrRelief werden eingesetzt, um auf Objekte der Relationen
BodenStandort, NutzungStandort, KlimaStandort und Relief10 zu verweisen. Relief10 ist
eine Relation, die das Relief für einen Rasterpunktabstand von 10 Metern enthält. Sie
wird in Abschnitt 6.3.4 näher betrachtet. Die weiteren Attribute sind die in dieser neuen Informationsebene abzuleitenden Werte. Zusätzlich zur vorigen Tabellendefinition ist
86
KAPITEL 6. METHODEN
CREATE TABLE RasterAll10 (
PNr
INTEGER,
SNrBoden
INTEGER,
SNrNutzung INTEGER,
SNrKlima
INTEGER,
PNrRelief INTEGER,
TA
FLOAT,
-- Dauer des kapillaren Aufstiegs
KA
FLOAT,
-- mittlere kapillare Aufstiegsdauer
WPFL
FLOAT,
-- pflanzenverfuegbares Bodenwasser
GWN
FLOAT,
-- Sickerwasserrate
CONSTRAINT PK_RasterAll10 PRIMARY KEY (PNr),
CONSTRAINT FK_RA10_Raster FOREIGN KEY (PNr)
REFERENCES Raster10(PNr),
CONSTRAINT FK_RA10_Boden
FOREIGN KEY (SNrBoden)
REFERENCES BodenStandort(SNr),
CONSTRAINT FK_RA10_Nutzung FOREIGN KEY (SNrNutzung)
REFERENCES NutzungStandort(SNr),
CONSTRAINT FK_RA10_Klima
FOREIGN KEY (SNrKlima)
REFERENCES KlimaStandort(SNr),
CONSTRAINT FK_RA10_Relief FOREIGN KEY (PNrRelief)
REFERENCES Relief10(PNr) );
Abbildung 6.23: Definition einer Relation zur Aufnahme von Verschneidungsergebnissen
mehrerer Informationsebenen im Rasterformat
hier lediglich das Attribut GWN hinzugefügt, das die Sickerwasserrate aufnimmt.
Die nun folgenden Abschnitte untersuchen die Verschneidungen verschiedener Datenformate unter Einsatz des Spatial Cartridge von Oracle8i.
6.3.2
Verschneidung von Vektordaten mit Vektordaten
Die geometrischen Informationen der Informationsebenen Boden und Nutzung liegen als
Polygone vor. Für die Verschneidung der Polygone bietet das Spatial Cartridge von
Oracle8i die Methode MDSYS.SDO GEOM.SDO POLY INTERSECTION an. Angewendet auf zwei Polygone berechnet diese Methode ein Polygon, das den Rand des Durchschnitts der von den ursprünglichen Polygonen umschlossenen Flächen beschreibt. Diese
Methode kann aber ebenso zwei Mengen von Polygonen miteinander verschneiden. Die
Verschneidungsberechnung erfolgt dann mithilfe einer geschachtelten Schleife. Abbildung
6.24 zeigt die Methode zur Verschneidung der Informationsebenen Boden und Nutzung.
Die Zeilen 1 bis 5 der Methode definieren eine Sequenz, deren Werte als Primärschlüssel
der verschnittenen Geometrien eingesetzt werden. In Zeile 9 wird ein Cursor definiert,
der zur Abarbeitung des Ergebnisses der Anfrage der Zeilen 10 bis 17 benutzt wird. Die
Anfrage selbst ist aus zwei geometrischen Operationen zusammengesetzt. In Zeile 12 werden mittels der Methode MDSYS.SDO GEOM.SDO POLY INTERSECTION() die Durchschnitte von Polygonpaaren berechnet, die durch den Operator MDSYS.SDO FILTER()
6.3. VERSCHNEIDUNG VON INFORMATIONSEBENEN
87
aus der Gesamtmenge der Polygonpaare vorselektiert werden.
Der Operator SDO FILTER() realisiert einen Primärfilter auf den Polygonen. Er wird
eingesetzt, da jedes Polygon der Informationsebene Boden mit den meisten Polygonen
der Informationsebene Nutzung einen leeren Durchschnitt hat und umgekehrt. Um die
Anzahl der relativ teuren Verschneidungsberechnungen, die durch die Methode MDSYS.SDO GEOM.SDO POLY INTERSECTION() realisiert sind, zu reduzieren wird daher
dieser Primärfilter eingesetzt, der aus der Gesamtmenge der Polygonpaare eine Kandidatenmenge von Polygonpaaren liefert, die sich eventuell schneiden und die Polygone,
die sich definitiv nicht schneiden, aussortiert.
Listing :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
DROP SEQUENCE VBNnummer;
calc VBN.sql
CREATE SEQUENCE VBNnummer
START WITH 1
INCREMENT BY 1;
CREATE OR REPLACE PROCEDURE calc_VBN
IS
CURSOR cur IS
SELECT B.SNr AS SNrBoden,
N.SNr AS SNrNutzung,
MDSYS.SDO_GEOM.SDO_POLY_INTERSECTION(B.Geometrie,D.diminfo,
N.Geometrie,D.diminfo) AS Geometrie
FROM
BodenFlaeche B,
NutzungFlaeche N,
SDO_GEOM_METADATA D
WHERE D.table_name=’BodenFlaeche’ and -- beide dieselben Dimensionen
MDSYS.SDO_FILTER(B.Geometrie,N.Geometrie,
’querytype=join’)=’TRUE’;
18
19
runner cur%ROWTYPE;
20
21 BEGIN
22
OPEN cur;
23
LOOP
24
FETCH cur INTO runner;
25
EXIT WHEN cur%NOTFOUND;
26
27
IF(runner.Geometrie IS NOT NULL) THEN
28
INSERT INTO VBN(FNr,SNrBoden,SNrNutzung,Geometrie)
29
VALUES (VBNnummer.NEXTVAL,runner.SNrBoden,
runner.SNrNutzung,runner.Geometrie);
30
END IF;
31
END LOOP;
32
CLOSE cur;
33 END;
34 /
Abbildung 6.24: Verschneidung von Polygonen
Die Funktionsweise des Primärfilters ist dabei wie folgt: Bei der Indexierung werden
Werte für die Parameter SDO LEVEL und SDO NUMTILES angegeben. Diese bestimmen
die Anzahl der Teilungen für das fixe und das hybride Indexieren. Zu jeder Kachel werden
die Geometrien abgespeichert, die mit der Kachel interagieren. Haben zwei Polygone
keine gemeinsame Kachel, so schneiden sie sich nicht und können aussortiert werden.
88
KAPITEL 6. METHODEN
Statt des Primärfilters MDSYS.SDO FILTER() könnte auch ein weiterer Operator, MDSYS.SDO RELATE(), verwendet werden. Dieser implementiert sowohl einen Primär-, als
auch einen Sekundärfilter, d.h. durch den Einsatz von SDO RELATE() könnten genau die
Polygonpaare ausgewählt werden, die sich tatsächlich schneiden. Diese Methode führt
aber bereits Berechnungen auf den Objekten aus, die anschließend von der Methode
MDSYS.SDO GEOM.SDO POLY INTERSECTION() noch einmal durchgeführt werden.
Die Verschneidung würde daher wesentlich mehr Zeit benötigen.
Das Ergebnis dieser Verschneidungsmethode für die Informationsebenen Boden und Nutzung zeigt Abbildung 6.25. Hierbei wurden 78 Bodenpolygone mit 413 Nutzungspolygonen verschnitten. Insgesamt wurden dabei 1035 neue Polygone erzeugt.
Abbildung 6.25: Verschnitt von Boden und Nutzung im Vektorformat
Zur besseren Anschauung sind in den Abbildungen 6.26. 6.27 und 6.28 nur die Polygone der Informationsebenen Boden und Nutzung, sowie die berechneten Polygone des
Verschnitts dargestellt.
Abbildung
flächen
6.26:
Boden- Abbildung 6.27: Nutzungs- Abbildung 6.28: Verschneiflächen
dungsresultat
6.3. VERSCHNEIDUNG VON INFORMATIONSEBENEN
89
Den einzelnen Flächen der verschnittenen Geometrie werden die Standortschlüssel der
ursprünglichen Informationsebenen angeheftet, um anschließend die für Berechnungen
notwendigen Werte zu referenzieren. Das Schema zur Berechnung der Attributwerte
dieser verschnittenen Geometrie entspricht prinzipiell dem der Methoden zur Ableitung
neuer Attributwerte innerhalb einer Informationsebene. Dies ist auch daraus ersichtlich,
dass durch die Verschneidung eine neue, zwei Informationsebenen zusammenfassende,
Informationsebene erzeugt wurde.
6.3.3
Verschneidung von Raster- und Vektordaten
Die Verschneidung von Raster- und Vektordaten entspricht einem Punkt-in-PolygonTest für jeden einzelnen Rasterpunkt. Hierbei wird den Rasterpunkten zusätzlich zu den
bereits vorhandenen Attributen eine Referenz auf das Objekt zugeordnet, das durch das
Polygon, in dem der Rasterpunkt liegt, bestimmt ist. Alternativ kann jedem Rasterpunkt auch die Menge der Attribute des bestimmten Objektes hinzugefügt werden. Das
Ergebnis dieser Verschneidung liegt demnach im Rasterformat vor. Theoretisch ist es
auch denkbar, die Rasterdaten ins Vektorformat zu transformieren und die Verschneidung im Vektorformat durchzuführen. Dies führt aber in den meisten Fällen zu einer
Vielzahl kleinster Flächen, da das Rasterdatenformat üblicherweise bei der Erfassung
kontinuierlicher Phänomene verwendet wird. Außerdem müssten zu dieser Transformation quasihomogene Flächen bezüglich der Attributwerte von Rasterpunkten bestimmt
werden, was auf die Problematik der Nachbarschaftsbeziehungen führt (siehe Kapitel 3).
In den folgenden Unterabschnitten wird erläutert, wie Vektordaten ins Rasterformat
konvertiert werden. Dies entspricht der Verschneidung einer Rasterkarte ohne weitere
Attribute mit einer Vektorkarte. Da einer Rasterkarte aber beliebig weitere Attribute
hinzugefügt werden können, wird dadurch auch der allgemeine Fall der Verschneidung
einer Informationsebene, deren Werte im Rasterformat aufgenommen sind, mit einer
Informationsebene, deren Werte im Vektorformat vorliegen, behandelt. Der einzige Unterschied ist, dass zusätzlich zunächst eine Raster erzeugt werden muss, dessen Rasterpunkten anschließend Werte der Vektorkarte zugewiesen werden.
Die Konvertierung von im Vektorformat vorliegenden Daten ins Rasterformat erfolgt in
zwei Schritten. Zunächst muss ein Raster erzeugt werden und anschließend wird eine
Verschneidung der Punktgeometrien des Rasters mit den Polygonen der Vektorkarte
durchgeführt.
6.3.3.1
Rastergenerierung
In diesem Abschnitt wird beispielhaft die Konvertierung der Polygone der Informationsebene Boden in ein Raster durchgeführt. Innerhalb der Informationsebene Boden
existieren bei den vorhandenen Daten 78 Polygone. Das zu erzeugende Raster soll eine
90
KAPITEL 6. METHODEN
Auflösung von 300×300 Punkten, also 90000 Punkte, besitzen. Dies entspricht einem
realen Rasterpunktabstand von 10 Metern.
Ein Raster besteht aus einer Menge an Punkten. Die Punkte können in Spatial als Objekte vom Typ MDSYS.SDO GEOMETRY abgespeichert werden. Im Rahmen dieser Arbeit
wurden mehrere Relationen für Rasterdaten mit einer Auflösung von 300×300 Punkten
angelegt. Um nicht für jede Relation die Punktkoordinaten abzuspeichern, wurde eine
Relation Raster10 erzeugt, die die Koordinaten der Rasterpunkte und zum Zugriff auf
einzelne Punkte ein Primärschlüsselattribut PNr besitzt. Diese Tabelle wird wie folgt
angelegt:
CREATE TABLE Raster10 (
PNr
INTEGER,
Rasterpunkt MDSYS.SDO_GEOMETRY,
CONSTRAINT PK_Raster10 PRIMARY KEY (PNr) );
Nachdem eine Relation für ein Raster angelegt ist, werden in diese Relation die Rasterpunkte eingetragen. Abbildung 6.29 zeigt, wie dieses Einfügen implementiert ist. Als
Beispiel dient die Relation Raster10.
Listing :
create Rasterpunkte.sql
1 DECLARE
2 x
FLOAT; y
FLOAT;
3 xmin FLOAT; ymin FLOAT;
4 xmax FLOAT; ymax FLOAT;
5 dx
FLOAT; dy
FLOAT;
6
7 BEGIN
8
xmin:=357000000; xmax:=357300000; -- minimale und maximale Koordinaten
9
ymin:=576350000; ymax:=576650000; -- des Untersuchungsgebietes
10
dx:=1000;
dy:=1000;
-- Rasterpunktabstand = 10m
11
x:=xmin+dx/2;
y:=ymin+dy/2;
-- Rasterpunkte nicht an Rand
12
13
WHILE (x<xmax AND y<ymax)
14
LOOP
15
INSERT INTO Raster10 VALUES
16
( Pnumber.NEXTVAL, MDSYS.SDO_GEOMETRY(1,NULL,
17
MDSYS.SDO_POINT_TYPE(x,y,NULL),
18
NULL,NULL) );
19
x:=x+dx;
20
IF(x>=xmax AND y<ymax) THEN
21
x:=xmin+dx/2; y:=y+dy;
22
END IF;
23
END LOOP;
24 END;
Abbildung 6.29: Einfügen von Rasterpunkten in die Relation Raster10
In den Zeilen 1 bis 5 werden Variablen deklariert, deren Initialisierung in den Zeilen
8 bis 11 folgt. Sie geben die Ausdehnungen sowie den Punktabstand des Rasters an.
In der Schleife der Zeilen 13 bis 23 werden anschließend die Koordinaten der einzelnen
Rasterpunkte und der Wert ihres Primärschlüsselattributs PNr in die Relation Raster10
eingefügt. Pnumber ist als sequence definiert, so dass die Werte von PNr eindeutig sind.
Innerhalb der insert into-Anweisung wird für jeden Rasterpunkt ein Objekt vom Typ
MDSYS.SDO GEOMETRY erzeugt. Bei der Zuweisung von Werten an dieses Objekt
6.3. VERSCHNEIDUNG VON INFORMATIONSEBENEN
91
wird in Zeile 16 durch die 1 der Typ des Objektes (POINT) festgelegt. Der nachfolgende null-Wert wird SDO SRID (von Spatial bisher noch nicht unterstützt) zugewiesen. Es folgt die Erzeugung eines Objektes vom Typ MDSYS.SDO POINT mit seinen
durch x und y gegebenen Koordinatenwerten. Der dritte Wert null ist für eine mögliche z-Komponente reserviert. Die beiden letzten Attribute innerhalb der Typdefinition
(MDSYS.SDO ELEM INFO bzw. MDSYS.SDO ORDINATES) sind auf null gesetzt, da die
Geometrie lediglich aus einem Punkt besteht. Es sei hier noch einmal darauf hingewiesen, dass durch die Zuweisung eines Wertes ungleich null an eines der beiden letzten
Attribute der Wert für MDSYS.SDO POINT von Spatial ignoriert würde.
Nach der Erzeugung einer Relation für das Raster und dem Einfügen der Rasterpunkte in
diese Relation werden Informationen über die Ausdehnungen des Rasters in die Relation
SDO GEOM METADATA eingetragen. Dies ist notwendig, damit von Spatial Indexe auf
den räumlichen Daten und Berechnungen auf diesen Attributen durchgeführt werden
können. Sind die minimalen und maximalen Ausdehnungen wie im vorliegenden Fall
bekannt, so kann dies durch ein einfaches SQL-Kommando ausgeführt werden.
INSERT INTO SDO_GEOM_METADATA VALUES (’Raster10’,’Rasterpunkt’,
MDSYS.SDO_DIM_ARRAY( MDSYS.SDO_DIM_ELEMENT(’X’,357000000,357300000,0),
MDSYS.SDO_DIM_ELEMENT(’Y’,576350000,576650000,0)));
Die übergebenen Parameter Raster10 bzw. Rasterpunkt bezeichnen die Relation mit einem räumlichen Attribut und das räumliche Attribut der Relation selbst. Der dritte
Parameter ist ein Objekt vom Typ MDSYS.SDO DIM ARRAY, das aus zwei weiteren
Objekten vom Typ MDSYS.SDO DIM ELEMENT zusammengesetzt ist. Diese Elemente
enthalten die Bezeichnungen für die Dimensionen (X-Dimension bzw. Y-Dimension), den
minimalen und maximalen Wert der Geometrien bezüglich dieser Dimension und einen
Wert für die Toleranz. Für jede vorhandene Dimension ist hier ein Element vom Typ
MDSYS.SDO DIM ELEMENT einzufügen.
Für Punktdaten können die Ausdehnungen leicht aus den Geometriedaten selbst bestimmt werden, sodass das Einfügen in die Relation SDO GEOM METADATA auch automatisiert erfolgen könnte. Um beispielsweise den maximalen x-Wert aller in Raster10
enthaltenen Punkte zu bestimmen, genügt die folgende Anfrage:
SELECT MAX(R10.Rasterpunkt.SDO_POINT.x) FROM Raster10 R10;
Die Benutzung eines Aliasnamens für die Relation Raster10 ist wie bei allen Anfragen
an komplexe Objekttypen notwendig.
Für geometrische Objekte deren Koordinaten in SDO ORDINATES abgespeichert sind,
ist die Bestimmung der Ausdehnungen allerdings nicht so einfach, da SDO ORDINATES
vom Typ VARRAY ist. Obwohl dieser Typ ein Array variabler Länge repräsentiert, wird
der Zugriff auf einzelne Arrayelemente mittels SQL nicht unterstützt. Die Werte einzelner
Arrayelemente können lediglich mithilfe prozeduraler Erweiterungen der Sprache SQL
bestimmt werden.
Der letzte Schritt bei der Rastergenerierung ist das Anlegen eines räumlichen Index auf
der Spalte vom Typ MDSYS.SDO GEOMETRY:
92
KAPITEL 6. METHODEN
CREATE INDEX IRASTER ON Raster10(Rasterpunkt) INDEXTYPE IS
MDSYS.SPATIAL_INDEX PARAMETERS(’SDO_LEVEL=6, LAYER_GTYPE=POINT’);
Hierbei wird für SDO LEVEL der Wert 6 übergeben, dies entspricht 26 ∗ 26 = 4096
Kacheln. Jeder Kachel sind demnach 90000/4096, also durchschnittlich etwa 22 Rasterpunkte zugeordnet.
Bei der Wahl der Indexparameter für einen Index vom Typ MDSYS.SPATIAL INDEX
ist darauf zu achten, dass diese für Geometrien, auf denen Berechnungen (beispielsweise Verschneidungen) durchgeführt werden sollen, dieselben Werte haben, um eine
optimale Performance zu gewährleisten. Unterscheiden sich die Werte, so wird während
der Ausführung von Berechnungen auf diesen Daten intern eine neue Indexierung für
die zweite in der Parameterliste der einzelnen Methoden angegebene Geometrie durchgeführt, was die Bearbeitungszeit für die entsprechende Anfrage verlängert. Dies ist zumindest in der Dokumentation von Oracle angegeben. Es wurde allerdings festgestellt,
dass bei räumlichen Anfragen auf geometrische Daten, die mit einem unterschiedlichen
Wert für SDO LEVEL indexiert sind, die Anfragebearbeitung mit der Fehlermeldung
ORA-13227: SDO LEVEL values for the two index tables do not match
abbricht. Ist nur auf einer der Relationen ein räumlicher Index definiert, so tritt die
Fehlermeldung nicht auf.
6.3.3.2
Wertzuweisung an Rasterpunkte
Die Relation Raster10 besitzt die zwei Attribute PNr und Rasterpunkt. Um einzelnen
Rasterpunkten Werte zuzuweisen wird nun eine neue Relation RasterBoden10, wie in
Abbildung 6.30 angegeben, definiert. Die Tupel dieser Relation ordnen Rasterpunkten
Standortnummern (SNrBoden) der Relation BodenStandort zu. Die in SNrBoden zu
speichernde Nummer ist die Standortnummer des Messstandortes, der repräsentativ für
die quasi-homogene Fläche ist, in der der Rasterpunkt liegt.
CREATE TABLE RasterBoden10 (
PNr
INTEGER,
SNrBoden INTEGER,
CONSTRAINT PK_RasterBoden10 PRIMARY KEY (PNr),
CONSTRAINT FK_RasterBoden10_PNr FOREIGN KEY (PNr)
REFERENCES Raster10(PNr),
CONSTRAINT FK_RasterBoden10_SNr FOREIGN KEY (SNrBoden)
REFERENCES BodenStandort(SNr) );
Abbildung 6.30: Definition der Relation RasterBoden10
In der Relation RasterBoden10 ist PNr Fremdschlüssel auf die vorher erzeugte Relation
Raster10, die die Lageinformationen der einzelnen Rasterpunkte bereithält. Die räumlichen Informationen der Relation RasterBoden10, sind also nur indirekt über die Relation
Raster10 zu erhalten.
6.3. VERSCHNEIDUNG VON INFORMATIONSEBENEN
93
Nachdem diese Relation angelegt ist, wird sie initialisiert, indem durch
INSERT INTO RasterBoden10 (
SELECT PNr,null
FROM Raster10);
einfach die Nummern der in Raster10 vorhandenen Punkte übernommen werden. Dies ist
notwendig, um in der folgenden Zuweisung von Standortnummern der Informationsebene
Boden an die einzelnen Tupel der Relation RasterBoden10 ausschließlich update- und
keine insert-Kommandos zu verwenden. Würde in der in Abbildung 6.31 angegebenen
Prozedur insert verwendet, so wäre eine Verletzung der Primärschlüsselbedingung die
Folge, da aufgrund von Berechnungsungenauigkeiten einzelnen Rasterpunkten mehrere
Standorte zugewiesen werden.
Die Zuweisung der Standortnummern der Informationsebene Boden an die einzelnen
Rasterpunkte erfolgt dann wie in der in Abbildung 6.31 angegebenen Prozedur.
Listing :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
CREATE OR
IS
CURSOR
IS
SELECT
FROM
WHERE
calc RasterBoden10.sql (Ausschnitt)
REPLACE PROCEDURE calc_RasterBoden10
cur
a.PNr AS PNr, b.SNr AS SNr
Raster10 a , BodenFlaeche b
MDSYS.SDO_RELATE(a.Rasterpunkt,b.Geometrie,
’mask=ANYINTERACT querytype=JOIN’)=’TRUE’;
runner cur%ROWTYPE;
BEGIN
OPEN cur;
LOOP
FETCH cur INTO runner;
EXIT WHEN cur%NOTFOUND;
UPDATE RasterBoden10
SET
SNrBoden = runner.SNr
WHERE PNr = runner.PNr;
-- update von RasterBoden10
-- unter Verwendung
-- der PNr aus Raster10
END LOOP;
CLOSE cur;
END;
Abbildung 6.31: Zuordnung von Standortnummern der Bodenstandorte an Rasterpunkte
In dieser Prozedur wird in Zeile 3 ein Cursor für die Abarbeitung der Anfrage der Zeilen 5
bis 8 angelegt, die den wesentlichen Teil dieser Prozedur ausmacht. Die select-Anweisung
bildet einen Verbund der Relationen Raster10 und BodenFlaeche. Dieser Verbund wird
über alle Tupel der beiden Relationen gebildet. Dies ist durch den Parameter join, der
dem Operator MDSYS.SDO RELATE() übergeben wurde, bestimmt. Dieser Operator liefert true zurück, falls zwei Elemente, hier also ein Rasterpunkt und eine Fläche irgendwie
(anyinteract) miteinander interagieren. Alternativen sind hier contains bzw. inside als Parameterwerte. Dann würde true zurückgeliefert werden, falls der Rasterpunkt innerhalb
einer durch ein bestimmtes Polygon beschriebenen Geometrie (und nicht auf dem Rand)
94
KAPITEL 6. METHODEN
liegt. Punkte auf der Grenzlinie zweier Polygone werden zwei Werte zugewiesen. Daher
wird auch eine update-Anweisung in Zeile 18 verwendet und kein insert. Der letzte einem
Punkt zugewiesene Wert für SNrBoden wird also dauerhaft gespeichert.
Aufgrund von Ungenauigkeiten in der Berechnung kann der Effekt, dass einzelnen Rasterpunkten mehrere Standortnummern zugeordnet werden, auch nicht durch das Setzen
des Toleranzwertes für beide Geometrien in der Relation SDO GEOM METADATA auf 0
sowie eine Änderung des Parameters anyinteract in inside, beseitigt werden. Es werden
immer noch einzelnen Punkten mehrere Standortwerte zugeordnet.
Abbildung 6.32: Informationsebene Boden Abbildung 6.33: Informationsebene Boden
im Rasterformat
im Vektorformat
Am Ende dieser Prozedur sollten den Rasterpunkten Bodenstandorte zugeordnet sein,
über die die Attribute des Bodens ermittelt werden können. Dies ist allerdings nicht
für alle Rasterpunkte der Fall. Abhängig von der Wahl der Indexparameter und dem
Toleranzwert werden für die Informationsebene Boden zwischen 65000 und 85000 Rasterpunkten (von 90000) Standorte zugeordnet. Eine Diskussion dieses Fehlers und über
mögliche Fehlerursachen findet in Kapitel 6.4 statt. Vorerst werden die erzeugten Relationen mittels verschiedener Maßnahmen (siehe Anhang B) soweit möglich vervollständigt
und korrigiert. Das Ergebnis dieses Prozesses ist für die Informationsebene Boden in
Abbildung 6.32 zu sehen. Daneben zum Vergleich in Abbildung 6.33 die Bodenklassen
im Vektorformat. Die Abbildungen 6.34 und 6.35 zeigen die Nutzung des Jahres 1996,
ebenfalls einmal im Raster- und einmal im Vektorformat.
6.3.4
Verschneidung von Rasterdaten mit Rasterdaten
Verschneidungen im Rasterformat sind grundsätzlich von Datenbanksystemen sehr viel
effizienter durchzuführen als Verschneidungen im Vektorformat. Die einzige Bedingung
6.3. VERSCHNEIDUNG VON INFORMATIONSEBENEN
95
Abbildung 6.34: Nutzung 1996 im Raster- Abbildung 6.35: Nutzung 1996 im Vektorformat
format
an die Rasterdaten ist, dass sie die gleiche Auflösung, denselben Ursprung und dieselbe
Orientierung besitzen. Die Verschneidung entspricht dann einer Vereinigung der Attributlisten der beiden zu verschneidenden Geometrien bzw. Objekte an den einzelnen
Rasterpunkten.
Beispiel:
Ist einem Rasterpunkt in einer Informationsebene die Attributliste A1 und in einer anderen Informationsebene die Attributliste A2 zugeordnet, so besitzt er nach der Verschneidung die Attributliste A1 ∪ A2 .
Für die Verschneidung der Informationsebenen Boden und Nutzung sind diese Voraussetzungen nach der Umwandlung der Geometriedaten vom Vektorformat ins Rasterformat
bei einer Auflösung von 300×300 Punkten gegeben.
Die Relationen, die die Informationen für die Informationsebene Boden im Rasterformat bereithält, ist in Abschnitt 6.3.3.2 definiert. Für die Informationsebene Nutzung
existiert eine entsprechende Relation RasterNutzung10. Die Ergebnisrelation für die Aufnahme des Verschneidungsergebnisses hat dann den folgenden Aufbau:
PNr
1
2
3
SNrBoden
24
17
42
SNrNutzung
7
14
9
Hierbei ist PNr die Nummer des Rasterpunktes und SNrBoden bzw. SNrNutzung die
Nummer des zugehörigen Messstandortes der Informationsebene Boden bzw. Nutzung.
Jedem Rasterpunkt sind also ein Bodenstandort und ein Nutzungsstandort zugeordnet.
In der vorliegenden Arbeit wurde diese Verschneidung gleich für alle vorhandenen Infor-
96
KAPITEL 6. METHODEN
mationsebenen (nachdem die Vektordaten der Informationsebenen Boden, Nutzung und
Klima ins Rasterformat umgewandelt worden sind) durchgeführt. Die Ergebnisrelation
ist dann wie folgt aufgebaut (vgl. auch Abb. 6.23):
PNr
1
2
3
SNrBoden
24
17
42
SNrNutzung
7
14
9
SNrKlima
1
1
1
PNrRelief
1
2
3
TA
KA
WPFL
GWN
Jedem Punkt der Relation, dessen Koordinaten über die Punktnummer aus der Relation Raster10 bestimmt werden können, ist ein Bodenstandort, ein Nutzungsstandort,
ein Klimastandort (Wert konstant 1, da nur ein Klimastandort vorliegt), sowie ein Reliefpunkt zugeordnet. Über diese Zuordnungen werden später bei den Methoden, die
Werte mehrerer Informationsebenen als Eingangsdaten benötigen, die entsprechenden
Werte referenziert. Die Attribute TA, KA, WPFL und GWN sind für die Aufnahme
der abzuleitenden Werte vorgesehen. Hierbei ist zu bemerken, dass die Werte für die
Dauer des kapillaren Aufstiegs TA, für den mittleren kapillaren Aufstieg KA und für
das pflanzenverfügbare Bodenwasser GWN aus den Daten der Informationsebene Boden
und der Informationsebene Nutzung abgeleitet werden können. Die anderen Informationsebenen fließen in die Ableitung dieser Werte nicht mit ein. Es wäre an dieser Stelle
daher auch möglich, die Informationsebenen Boden und Nutzung zu verschneiden, wie
dies beispielsweise für das Vektorformat in Abschnitt 6.3.2 gezeigt wurde, um in dieser Relation zusammenfassend nur noch ein Attribut zur Referenzierung dieser beiden
Informationsebenen zu benötigen. Ebenfalls könnten dann die Attribute der drei aus
diesen beiden Informationsebenen abgeleiteten Werte aus dieser Relation entfernt werden, da sie bereits in einer anderen Relation gespeichert werden, die von dieser Relation
aus referenziert werden kann. Dies würde bei Anfragen allerdings Referenzierungen von
Werten aus mehreren Tabellen benötigen, was die Performance negativ beeinflusst. Aus
diesem Grund und um Anfragen an das Datenbanksystem übersichtlicher zu gestalten,
wird daher darauf verzichtet.
Die vier im Rasterformat vorhandenen Informationsebenen und die Relation RasterAll10
referenzieren alle die Relation Raster10, um die Koordinaten ihrer Rasterpunkte zu bestimmen. Dies wurde so implementiert, damit die nun folgende Verschneidung möglichst
effizient durchgeführt werden kann. Die Verschneidungoperation betrachtet nur noch die
Punktnummern, da gleiche Punktnummern in allen Informationsebenen den gleichen
Koordinaten zugeordnet sind. Das Einfügen der Werte für die einzelnen Informationsebenen in die Relation RasterAll10 ist demnach durch einfache update-Anweisungen zu
vollziehen (Abbildung 6.36). Die Werte für die anderen Informationsebenen werden entsprechend zugewiesen.
Sehr viel aufwendiger als die Verschneidung von Daten im Rasterformat ist die Transformation bzw. Skalierung einer Rasterkarte in eine andere. In Rahmen dieser Arbeit
bestand das Problem das Relief, das als Rasterkarte mit einem Rasterpunktabstand von
25 Metern (Relief25) gegeben war in eine Rasterkarte mit Abstand 10 Meter (Relief10)
6.4. PROBLEME BEI DER VERSCHNEIDUNG
Listing :
1 UPDATE RasterAll10 RA
2 SET
RA.SNrBoden = ( SELECT RB.SNrBoden
3
FROM
RasterBoden10 RB
4
WHERE RB.PNr=RA.PNr);
97
update RasterAll10.sql
Abbildung 6.36: Einfügen von Rasterdaten der Informationsebene Boden
zu verfeinern, da dadurch die oben beschriebene Verschneidung einfach zu realisieren ist.
Die Rasterpunkte des Reliefs bestimmen den Wert für eine Fläche, die nach Nordosten
ausgerichtet ist. Innerhalb dieser dem Relief25 zugeordneten Fläche liegen mehrere Rasterpunkte von Relief10. Die Methode, die den Reliefpunkten von Relief10 die Werte des
zugeordneten Punktes aus Relief25 anheftet, arbeitet nach folgendem Prinzip: Zunächst
wird ein geometrisches Objekt (ein Rechteck) erzeugt, dass die Fläche beschreibt, für
die der gerade betrachtete Punkt aus Relief25 Referenzpunkt ist. Anschließend wird mittels eines Punkt-in-Polygon-Tests für die Punkte aus Relief10 der Referenzpunkt aus
Relief25 bestimmt und die diesem Punkt angehefteten Werte dem Punkt aus Relief10
zugeordnet.
6.4
Probleme bei der Verschneidung
Im vorigen Abschnitt wurde die prinzipielle Vorgehensweise bei der Verschneidung geometrischer Daten erläutert und kurz darauf hingewiesen, dass es bei der Verschneidung
von Raster- und Vektordaten Probleme gibt. Diese sollen nun näher erläutert werden.
Bei der Verschneidung von Raster- und Vektordaten wird nicht zu jedem Rasterpunkt
eine Fläche gefunden, in der er liegt. Abhängig von den Parameterwerten SDO LEVEL
und SDO NUMTILES, die bei der Indexerzeugung angegeben werden und dem Wert für
TOLERANCE, festgelegt beim Einfügen der Dimensionsinformationen in die Relation
SDO GEOM METADATA, schwankt die Anzahl der Rasterpunkte, denen eine Fläche und
damit ein Referenzstandort zugeordnet werden kann, beträchtlich. Es wurde festgestellt,
dass der Toleranzwert dabei den geringsten Einfluss ausübt.
Um dieses Phänomen genauer zu untersuchen wurden einige Verschneidungen zwischen
den Bodenpolygonen und einem Raster mit einer Auflösung von 300×300 Punkten, also
90000 Punkte insgesamt, durchgeführt. Zur Verschneidung wurde der Operator MDSYS.SDO RELATE() wie in Abschnitt 6.3.3 angegeben verwendet. Die Tabelle in Abbildung 6.37 gibt eine Übersicht über die Anzahl der Rasterpunkte, denen in Abhängigkeit von der Wahl der Parameterwerte SDO LEVEL und SDO NUMTILES, ein Wert für
eine Bodenfläche und damit für einen Bodenstandort zugewiesen werden konnte. Ist
für SDO NUMTILES kein Wert angegebenen (-), so ist der Index fixed und nicht hybrid. Das Raster ist dabei jeweils mit dem Parameter SDO LEVEL entsprechend dem
SDO LEVEL des Index auf der Relation BodenFlaeche indexiert. Zusätzlich wurde als
Parameter LAYER GTYPE=POINT angegeben, da es sich bei dem Raster ausschließlich
98
KAPITEL 6. METHODEN
um Punktgeometrien handelt. Die Werte für Zeit geben die Dauer der Verschneidungsberechnungen an. Dies sind aber nicht die reinen CPU-Zeiten für die Berechnungen,
sondern die Realzeiten, die insgesamt für die Berechnungen benötigt wurden. Sie ist
jeweils angegeben, um die Bearbeitungszeit für verschiedenen Indexierungen grob vergleichen zu können.
SDO LEVEL
4
4
4
4
6
6
6
6
8
8
8
8
SDO NUMTILES
6
9
12
6
9
12
6
9
12
Punkte
82057
78016
72296
67355
73345
75222
75145
74734
67075
70107
70107
69736
61
51
43
40
32
32
33
32
26
26
27
28
Zeit
Minuten
Minuten
Minuten
Minuten
Minuten
Minuten
Minuten
Minuten
Minuten
Minuten
Minuten
Minuten
Abbildung 6.37: Initialisierte Rasterpunkte in Abhängigkeit von SDO LEVEL und
SDO NUMTILES (TOLERANCE=1)
In der Tabelle fällt auf, dass das beste Ergebnis für den fixen Index bei einem Wert für
SDO LEVEL von 4 erreicht wird. Bei fixer Indexierung nimmt die Anzahl der zuzuordnenden Punkte mit steigendem Wert für SDO LEVEL ab. Ebenso verhält es sich, wenn
SDO LEVEL konstant auf 4 bleibt und der Wert für SDO NUMTILES erhöht wird. Die
Beobachtung führt zu der Vermutung, dass bei einer gegebenen Anzahl von Kacheln
eine Erhöhung der Kachelungszahl zu einer Verminderung an zuzuordnenden Punkten
führt. Die Abbildungen 6.38 bis 6.46, in denen die Ergebnisse der Verschneidung dargestellt sind, liefern die Begründung für diese Vermutung. Sie lautet, dass in großen
Kacheln viele Punkte sind und das Ausscheiden einiger Punkte bei der Indexierung die
Kachel nicht ausselektiert, da immer noch Punkte vorhanden sind und diese Kachel daher genau untersucht wird, während in kleinen Kacheln weniger Punkte vorhanden sind
und die Kachel dadurch eher ausselektiert wird, falls Punkte falsch zugeordnet werden.
Dies würde auch bedeuten, dass die genaue Berechnung innerhalb der Kacheln korrekt
arbeitet. Abbildung 6.38 bestätigt dies, da hier trotz großer Kacheln die Ränder der Geometrien recht genau approximiert sind. Die Vermutung wird allerdings widerlegt durch
die Betrachtung der Werte für einen SDO LEVEL von 6 bzw 8. Hier werden trotz einer
Verfeinerung der Kachelung zwischenzeitlich mehr Punkte gefunden.
Die Bilder zeigen weiterhin, warum der Toleranzwert eine recht geringe Bedeutung für
das vorhandene Problem hat. Der Toleranzwert führt prinzipiell nur zu einer internen
Vergrößerung der Kacheln und da ganze Kacheln nicht gefunden werden, ist die Höhe
des Toleranzwertes nur von Bedeutung, falls der Toleranzwert die Kacheln entscheidend
vergrößert.
6.4. PROBLEME BEI DER VERSCHNEIDUNG
99
Abbildung
SDO LEVEL=4
6.38: Abbildung
SDO LEVEL=6
6.39: Abbildung
SDO LEVEL=8
6.40:
Abbildung
SDO LEVEL=4,
SDO NUMTILES=6
6.41: Abbildung
SDO LEVEL=6,
SDO NUMTILES=6
6.42: Abbildung
SDO LEVEL=8,
SDO NUMTILES=6
6.43:
Abbildung
6.44: Abbildung
6.45: Abbildung
6.46:
SDO LEVEL=4,
SDO LEVEL=6,
SDO LEVEL=8,
SDO NUMTILES=12
SDO NUMTILES=12
SDO NUMTILES=12
100
KAPITEL 6. METHODEN
Schließlich ist an den Bildern zu sehen, dass Kacheln vorrangig an den Grenzen zwischen
Polygonen ausgeschnitten sind. Oracle selbst räumt Fehler bei der Implementierung der
Methode SDO GEOM.RELATE() ein. Insbesondere treten angeblich Probleme bei Linien
auf, die den gleichen Anfangs- und Endpunkt besitzen und fast parallel verlaufen. Dies
ist an den Grenzflächen der Polygone natürlich der Fall.
Neben der Problematik, dass ganzen Kacheln keine Werte zuzuordnen sind, sind in
den Abbildungen noch zwei weitere Datenfehler auszumachen. Einerseits sind dünne
horizontale Linien zu sehen, denen kein Wert zugewiesen ist und andererseits dünne
horizontale Linien, die anscheinend aus Nachbarobjekten in andere Objekte hineinlaufen.
Die Abbildungen 6.47 und 6.48 zeigen die Nutzungsdaten nach der Konvertierung vom
Vektorformat ins Rasterformat, wobei nur fixed-indexing verwendet wurde. Obwohl die
Nutzungsflächen relativ homogen im Untersuchungsgebiet vorhanden sind, nimmt die
Zuordnung von Sachdaten an Rasterpunkte anscheinend stetig von unten nach oben ab.
Abbildung 6.47: SDO LEVEL=4
Abbildung 6.48: SDO LEVEL=8
In Anhang B werden Möglichkeiten aufgezeigt die Datenfehler der Karten zu korrigieren.
6.5
Ableitungen für verschnittene Geometrien
Werte, deren Ableitung die Eingangsdaten mehrerer Informationsebenen benötigt, sind
innerhalb der Methode zur Ableitung der Sickerwasserrate, die Dauer des kapillaren
Aufstiegs TA, der mittlere kapillare Aufstieg KA, das pflanzenverfügbare Bodenwasser
WPFL und natürlich die Sickerwasserrate GWN selbst. Die ersten drei Werte sind aus
den Daten der Informationsebenen Boden und Nutzung abzuleiten. Da die Verschneidung
dieser beiden Informationsebenen sowohl im Vektorformat (Relation VBN), als auch im
6.5. ABLEITUNGEN FÜR VERSCHNITTENE GEOMETRIEN
101
Verschnitt der Informationsebenen Boden, Nutzung, Klima und Relief
Eingangsdaten
abgeleitete Werte
Informationsebene Boden
Informationsebene Nutzung
*
TA
KA
WPFL
*
Informationsebene Klima
GWN
Informationsebene Relief
: geht ein in die Berechnung von
* : unter Verwendung statischer Hilfsrelationen
Abbildung 6.49: Schematische Darstellung des Datenflusses zur Ableitung der Sickerwasserrate
Rasterformat (Relation RasterAll10) durchgeführt wurde, werden diese Werte für beide Datenformate berechnet. Für die Ableitung der Sickerwasserrate müssen zusätzlich
die Klima- und Reliefinformationen vorhanden sein. Daher kann das Ergebnis der Berechnung dieses Wertes visuell nur im Rasterformat dargestellt werden. Die folgenden
Unterabschnitte beschreiben die Implementierung der verschiedenen Methoden. Der Datenfluss zur Ableitung dieser Werte ist in Abbildung 6.49 dargestellt.
6.5.1
Dauer des kapillaren Aufstiegs
Die Dauer des kapillaren Aufstiegs ist abhängig von der nutzbaren Feldkapazität des effektiven Wurzelraums nFKWe, der mittleren kapillaren Aufstiegsrate KRmm, sowie der
Nutzung des Bodens NutzNr. Sie wird immer für ein bestimmtes Jahr berechnet (hier
beispielhaft für das Jahr 1996) und in Tagen angegeben. NutzNr ist dabei eine Nummer,
die nach einem von R. Duttmann eingeführten Schlüssel verschiedene Nutzungsarten
Bereich für KRmm
< 1, 5
1.5.. < 2.5
2.5.. < 3.5
3.5..4.5
≥ 4.5
KRmm
≤ 1.0
2.0
3.0
4.0
≥ 5.0
Formel
0.14 ∗ nF KW e + 14.3
0.13 ∗ nF KW e + 23.4
0.10 ∗ nF KW e + 35.0
0.07 ∗ nF KW e + 44.4
60
Abbildung 6.50: Mittlere Dauer des kapillaren Aufstiegs (ta) bei Getreide in Abhängigkeit von KRmm und nFKWe
codiert. Die mittlere und rechte Spalte der Tabelle in Abbildung 6.50 zeigen, wie die
Dauer des kapillaren Aufstiegs bei Anbau von Getreide berechnet wird. Die Tabellen für
102
KAPITEL 6. METHODEN
Mais, Zucker und Intensivweide sind entsprechend aufgebaut. Nach weiteren Nutzungsarten wird nicht unterschieden. Die linke Spalte wurde nach Absprache mit M. Neteler
eingeführt, damit das Problem, dass Werte für KRmm in dieser Tabelle nicht eindeutig
Zeilen zuzuordnen sind (fünf Zeilen für sechs Bereiche !), behoben wird.
Abbildung 6.51: Dauer des kapillaren Aufstiegs
Die Methode zur Berechnung der Dauer des kapillaren Aufstiegs ist für die Relation
RasterAll10 in Abbildung 6.52 dargestellt.
In der select-Anweisung werden die Rasterpunktnummer PNr, die Nutzungsnummer
NutzNr, die nutzbare Feldkapazität des effektiven Wurzelraums nFKWe, sowie die mittlere kapillare Aufstiegsrate in Millimetern KRmm aus der Datenbank gelesen. Mithilfe
des Cursors werden anschließend innerhalb der Schleife für die Ergebnistupel der Anfrage die Werte für die Dauer des kapillaren Aufstiegs berechnet und durch die updateAnweisung den Rasterpunkten zugewiesen. Statt der if..then..else-Konstruktion könnte
auch eine zusätzliche Hilfsrelation verwendet werden, die Nutzungsnummern mit Faktoren und Summanden für verschiedene Werte von KRmm und nFKWe verknüpft. Da
6.5. ABLEITUNGEN FÜR VERSCHNITTENE GEOMETRIEN
103
aber erstens die Bereichsangaben für KRmm nicht eindeutig sind zweitens der Nutzungsschlüssel keine allgemeine Norm ist, wurde bisher darauf verzichtet und die etwas
umständliche Konstruktion beibehalten.
Die Prozedur zur Berechnung der Dauer des kapillaren Aufstiegs für die Relation VBN
hat denselben Aufbau wie die angegebene Prozedur. Sie unterscheidet sich lediglich
dadurch, dass für RasterAll10 VBN und für die Punktnummer des Rasterpunktes die
Nummer der betrachteten Fläche eingesetzt wird. Abbildung 6.51 zeigt qualitativ die
Listing :
calculate ta10.sql (Ausschnitt)
1 CREATE OR REPLACE PROCEDURE calculate_ta10
2 IS
3
CURSOR cur IS
4
SELECT ra10.pnr, BP.krmm AS krmm, BP.nfkwe AS nfkwe,
5
TA_NK.Bezeichnung as nart
6
FROM
RasterAll10 ra10, BodenProfil BP, Nutzung N,
7
BodenStandort BS, NutzungStandort NS,
8
Anbau A, TA_NutzungKlassen TA_NK
9
WHERE ra10.SNrBoden=BS.SNr AND
10
ra10.SNrNutzung=NS.SNr AND
11
BP.BPNr=BS.BPNr
AND
12
A.SNr=NS.SNr
AND
13
N.NNr=A.NNr
AND
14
N.Jahr=1996
AND
15
N.NutzNr>=TA_NK.min
AND
16
N.NutzNr<=TA_NK.max;
17
18
runner cur%ROWTYPE;
19
dauer FLOAT;
20
21 BEGIN
22
OPEN cur;
23
LOOP
24
FETCH cur INTO runner;
25
EXIT WHEN cur%NOTFOUND;
26
27
IF(runner.nart=’AG’) THEN
-- Getreide
28
IF (runner.krmm<1.5) THEN
29
dauer:=0.14*runner.nfkwe+14.3;
30
ELSIF (runner.krmm<2.5) THEN
... -- weitere Unterscheidungen fuer krmm
36
ELSE dauer:=60.0;
37
END IF;
38
ELSIF(runner.nart=’MA’ OR runner.nart=’ZS’) THEN -- Mais,
39
IF (runner.krmm<1.5) THEN
-- Zueckerrueben
... -- andere Nutzungsarten
59
END IF;
60
END IF;
61
62
UPDATE RasterAll10
63
SET ta=dauer
64
WHERE pnr=runner.pnr;
65
66
END LOOP;
67
CLOSE cur;
68 END;
Abbildung 6.52: Prozedur zur Ableitung der Dauer des kapillaren Aufstiegs (Ausschnitt)
berechneten Werte für das Untersuchungsgebiet. Hellere Farben entsprechen einer länge-
104
KAPITEL 6. METHODEN
ren kapillaren Aufstiegsdauer. Die Farbe Weiß bedeutet, das kein Wert berechnet werden
kann, da benötigte Eingangsdaten nicht vorhanden sind. Zur besseren Orientierung sind
die Polygonränder schwarz nachgezeichnet.
6.5.2
Mittlerer kapillarer Aufstieg
Der mittlere kapillare Aufstieg KA ist definiert als das Produkt der kapillaren Aufstiegsrate KRmm und der Dauer des kapillaren Aufstiegs TA (KA = KRmm ∗ T A). Die
Einheit ist Millimeter.
Da die Implementierung dieser Methode sehr kurz ist, ist sie zum Vergleich sowohl für
die Raster-, als auch für die Vektordaten in 6.53 bzw. 6.54 dargestellt. In der Prozedur
Listing :
1
2
3
4
5
6
7
8
9
calculate KA10.sql
CREATE OR REPLACE PROCEDURE calculate_ka10
IS
BEGIN
UPDATE RasterAll10 a
SET a.KA = ( SELECT a.TA*b.KRmm
FROM BodenProfil b, BodenStandort c
WHERE a.SNrBoden=c.SNr AND
b.BPNr = c.BPNr);
END;
Abbildung 6.53: Prozedur zur Ableitung des mittleren kapillaren Aufstiegs (Raster)
Listing :
1
2
3
4
5
6
7
8
9
calculate ka.sql
CREATE OR REPLACE PROCEDURE calculate_ka
IS
BEGIN
UPDATE VBN a
SET a.KA = ( SELECT a.TA*b.KRmm
FROM BodenProfil b, BodenStandort c
WHERE a.SNrBoden=c.SNr AND
b.BPNr = c.BPNr);
END;
Abbildung 6.54: Prozedur zur Ableitung des mittleren kapillaren Aufstiegs (Vektor)
wird über die Nummer des dem Rasterpunkt bzw. der Fläche zugeordneten Bodenstandorts das zugehörige Bodenprofil ermittelt. Der Wert für KRmm wird aus der Relation
BodenProfil ausgelesen und mit dem Wert für die Dauer des kapillaren Aufstiegs eines
bestimmten Jahres (hier 1996) multipliziert. Der berechnete Wert wird dem Punkt- bzw.
dem Flächenobjekt zugewiesen. Die Abbildungen 6.55 und 6.56 zeigen die Werteverteilung des kapillaren Aufstiegs. Auch hier sind hellere Farben gleichbedeutend mit höheren
Werten. Weißen Flächen konnte kein Wert zugewiesen werden.
6.5. ABLEITUNGEN FÜR VERSCHNITTENE GEOMETRIEN
105
Abbildung 6.55: Mittlerer kapillarer Auf- Abbildung 6.56: Mittlerer kapillarer Aufstieg im Rasterformat
stieg im Vektorformat
6.5.3
Pflanzenverfügbares Bodenwasser
Der Wert für das pflanzenverfügbare Bodenwasser ist ein Maß für die Wassermenge,
die Pflanzen in Trockenjahren dem Boden entziehen können. In diesen Wert fließt die
effektive Durchwurzelungstiefe durch nFKWe ein und auch die Art der Pflanzen, da
verschiedene Pflanzen unterschiedlich tiefe Wurzeln haben und dies die Menge des Wassers, das sie erreichen können, beeinflusst. Das pflanzenverfügbare Bodenwasser WPFL
berechnet sich einfach als Summe aus der nutzbaren Feldkapazität des effektiven Wurzelraums und dem mittleren kapillaren Aufstieg KA. Die Methode ist strukturell ebenso
aufgebaut wie die Methode zur Ableitung des mittleren kapillaren Aufstiegs und in Abbildung 6.57 dargestellt.
Listing :
1
2
3
4
5
6
7
8
9
10
11
calculate wpfl.sql
CREATE OR REPLACE PROCEDURE calculate_wpfl
IS
BEGIN
UPDATE VBN a
SET
a.WPFL = (
SELECT a.KA+b.nFKWe
FROM
BodenProfil b, BodenStandort c
WHERE a.SNrBoden=c.SNr AND
b.BPNr = c.BPNr );
END;
/
Abbildung 6.57: Prozedur zur Ableitung des pflanzenverfügbaren Bodenwassers)
Ein qualitativer Überblick über das pflanzenverfügbare Bodenwasser im Untersuchungsgebiet (Jahr 1996) Groß-Ilde zeigt Abbildung 6.58. Die Polygone einzelner Flächenele-
106
KAPITEL 6. METHODEN
mente sind wieder schwarz eingezeichnet, helle Farben stehen für hohe Werte und weißen
Flächen konnte kein Wert zugeordnet werden.
Abbildung 6.58: Menge des pflanzenverfügbaren Bodenwassers (1996)
6.5.4
Sickerwasserrate
Als Sickerwasser wird das Wasser bezeichnet, dass sich unter Einwirkung der Schwerkraft
abwärts bewegt.
Die Ableitung der Sickerwasserrate benötigt Eingangsdaten der Informationsebenen Boden, Nutzung, Klima und Relief. Sie wird für ein bestimmtes Jahr berechnet. Um sie
abzuleiten werden zunächst die vier Informationsebenen verschnitten, sodass in einer
Relation Informationen über alle benötigten Eingangsdaten vorhanden sind. Die Relation, die alle diese Eingangsdaten bereithält, ist RasterAll10, die ausführlich in Abschnitt
6.3.1 diskutiert wurde.
6.5. ABLEITUNGEN FÜR VERSCHNITTENE GEOMETRIEN
107
Sind alle diese Werte vorhanden, so berechnet sich die Sickerwasserrate in mehreren
Schritten. Zunächst wird unter Verwendung der Informationen über das pflanzenverfügbare Bodenwasser, die Niederschlagsmenge des Winterhalbjahres sowie der potenziellen
Verdunstung ein Wert nach einer Formel berechnet, die abhängig von der Nutzung ist.
Dieser Wert erhält anschließend Zu- oder Abschläge in Abhängigkeit von der Hangneigung und der Exposition. Für besondere Nutzungen sind wiederum verschiedene Zuund Abschläge auf den berechneten Wert erforderlich.
Die Implementierung der Prozedur wird nun in mehreren Teilen vorgestellt. Zunächst
wird eine Anfrage an die Datenbank gestellt, deren Ergebnis mithilfe eines Cursors abgearbeitet wird. Diese Anfrage ist in Abbildung 6.59 dargestellt. Vor der Implementierung
der Methode wurde allerdings die Relation RasterAll10 um drei Attributwerte erweitert.
Es wurde die Attributliste der Relation Relief10 zur Relation RasterAll10 hinzugefügt.
Dies führt zwar, wie in Abschnitt 6.3.1 erläutert, zu redundanter Datenspeicherung, hilft
aber, die Antwortzeiten zu verkürzen, da keine Verbundbildung zwischen den beiden umfangreichen Relationen Relief10 und RasterAll10 durchzuführen ist.
Listing :
Cursordefinition Sickerwasserrate
1 CURSOR cur IS
2
SELECT ra10.PNr,
3
NKGWN.Bezeichnung AS nart,
4
ra10.wpfl,
5
SK.KNr,
6
ra10.Exposition,
7
ra10.Hangneigung
8
FROM
RasterAll10 ra10,
9
Anbau A,
10
Nutzung N,
11
T_NutzungKlassenGWN NKGWN,
12
StandortKlima SK
13
WHERE ra10.SnrNutzung = A.SNr AND
14
A.NNr = N.NNr
AND
15
N.Jahr=1996
AND
16
N.NutzNr<=NKGWN.max
AND
17
N.NutzNr>=NKGWN.min
AND
18
SK.SNr=ra10.SNrKlima;
Abbildung 6.59: Cursordefinition Sickerwasserrate
Beim Durchlaufen der einzelnen Cursortupel werden nun zunächst aggregierte Klimawerte berechnet (Abb. 6.60).
Im Einzelnen sind diese Werte der Jahresniederschlag N, der Niederschlag der Hauptvegetationsperiode Nv und der Niederschlag des Winterhalbjahres Nwi. Diese Werte werden für das Jahr 1996 bzw. für das Winterhalbjahr 1995/96 berechnet. Schließlich wird
noch die summierte potenzielle Verdunstung nach Haude für die Hauptvegetationsperiode etphaude bestimmt.
Diese Berechnungen werden allerdings nur ausgeführt, wenn sich der Klimastandort
ändert. Zur Speicherung der Nummer des alten Klimastandorts wird die Variable AKNr
verwendet. Um die Anzahl dieser aggregierenden Berechnungen zu minimieren wäre eine
108
KAPITEL 6. METHODEN
Listing :
1
2
3
4
5
6
7
Aggregierung Klimawerte
IF(AKNr!=runner.KNr) THEN
SELECT calculate_Niederschlag(runner.KNr,to_date(’01-Jan-1996’),
to_date(’31-DEC-1996’)) INTO N
FROM DUAL;
SELECT calculate_Niederschlag(runner.KNr,to_date(’01-OCT-1995’),
to_date(’31-MAR-1996’)) INTO NWi FROM DUAL;
SELECT calculate_Niederschlag(runner.KNr,to_date(’01-APR-1996’),
to_date(’30-SEP-1996’)) INTO Nv FROM DUAL;
SELECT get_sum_etphaude(runner.knr,to_date(’01-APR-1996’),
to_date(’30-SEP-1996’)) INTO etphaude FROM DUAL;
AKNr:=runner.KNr;
END IF;
Abbildung 6.60: Aggregierung Klimawerte)
Gruppierung der Cursortupel nach Klimastandorten durchzuführen. Da bei den vorliegenden Daten allerdings nur ein Klimastandort existiert, ist dies hier nicht notwendig.
Sind die aggregierten Klimawerte vorhanden, so können die Werte der Sickerwasserrate
für die einzelnen Rasterpunkte bestimmt werden. Unter Verwendung der Hilfsrelation
T NutzungKlassenGWN wurde in der für den Cursor verwendeten Anfrage einer der vier
folgenden Nutzungsbereiche für einen Rasterpunkt bestimmt: Ackerland, Grünland, Nadelwald, Laubwald (oder null). Für diese vier Bereiche sind unterschiedliche Berechnungsvorschriften zur Ableitung der Sickerwasserrate angegeben. Die Implementierung dieser
Berechnungsvorschriften ist in Abbildung 6.61 angegeben. Auch hier wäre es wie bei der
Methode zur Ableitung der Dauer des kapillaren Aufstiegs in 6.5.1 möglich, durch definierte Nutzungsklasssen die in den einzelnen Formeln angegebenen Faktoren und Summanden in einer Hilfsrelation zu speichern und dadurch die if..then..else-Konstruktion
zu vermeiden.
Listing :
1
2
3
4
5
6
7
8
9
Berechnung der Sickerwasserrate
IF(runner.nart=’A’) THEN
-- Ackerland
Sickerwasserrate:=0.92*Nwi+0.62*Nv-153*Log(10,runner.wpfl)
-0.12*etphaude+109;
ELSIF (runner.nart=’G’) THEN
-- Gruenland
Sickerwasserrate:=0.90*Nwi+0.52*Nv-286*Log(10,runner.wpfl)
-0.1*etphaude+330;
ELSIF (runner.nart=’FN’) THEN -- Nadelwald
Sickerwasserrate:=0.71*Nwi+0.67*Nv-166*Log(10,runner.wpfl)
-0.19*etphaude+127;
ELSIF (runner.nart=’FL’) THEN -- Laubwald
Sickerwasserrate:=0.953*N+0.02**etphaude-430.1;
END IF;
Abbildung 6.61: Berechnung Sickerwasserrate)
Anschließend werden für diesen berechneten Wert in Abhängigkeit von der Hangneigung
und der Exposition verschiedene Zu- und Abschläge vorgenommen. Aufgrund fehlender
Informationen konnte dies hier nicht durchgeführt werden, sodass lediglich der Hauptwert der Sickerwasserrate berechnet wurde und in Abbildung 6.62 qualitativ dargestellt
ist. Wie bei den anderen Bildern auch ist die Helligkeit das Maß für den berechneten
Wert und für weiße Flächen konnten keine Werte berechnet werden.
6.5. ABLEITUNGEN FÜR VERSCHNITTENE GEOMETRIEN
109
Abbildung 6.62: Sickerwasserrate im Untersuchungsgebiet (ohne Zu- und Abschläge)
Die prinzipielle Struktur der Methoden dieses Abschnitts soll hier noch einmal zusammengefasst werden. Zunächst sind die Geometrien der Informationsebenen zu verschneiden, die Eingangsdaten für eine Methode bereithalten. Den einzelnen neu berechneten
geometrischen Objekten (Rasterpunkte oder durch Polygone beschriebene Flächen) werden bei dieser Verschneidung Referenzen auf die einzelnen Sachobjekte (bzw. die Attribute der Sachobjekte selbst) der eingehenden Informationsebenen zugewiesen. Dadurch
entsteht eine neue Informationsebene, die die Informationen der beiden ursprünglichen
Informationsebenen vereinigt und die, falls die geometrischen Informationen im Vektorformat abgespeichert sind, eine verfeinerte Geometrie besitzt. Die Ableitung der neuen
Sachdaten, für die Attribute in der Relation vorzusehen sind, die die neue Informationsebene repräsentiert, entspricht dann der Ableitung von Daten innerhalb einer Informationsebene, mit dem Unterschied, dass die Sachdaten, falls sie nicht direkt in der
neuen Informationsebene gespeichert sind, über Fremdschlüssel in den Relationen der
eingehenden Informationsebenen referenziert werden.
110
KAPITEL 6. METHODEN
Kapitel 7
Erfahrungen und Ausblick
Dieses Kapitel gibt einen Überblick über die Erfahrungen, die im Rahmen dieser Arbeit
mit geografischen Methoden und dem Spatial Cartridge von Oracle gemacht wurden,
sowie Anregungen für zukünftige Arbeiten auf diesem Gebiet.
In Bezug auf den geografischen Teil dieser Arbeit fällt auf, dass die als Grundlage verwendeten Quellen, die Bodenkundliche Kartieranleitung [1] sowie das Methodenhandbuch [17], nur begrenzt für die direkte Implementierung der Methoden verwendet werden können. An vielen Stellen sind EDV-gerechte Anpassungen durchzuführen. Hier sei
nur an die Hilfsrelation zur Ableitung der Dauer des kapillaren Aufstiegs in Abschnitt
6.5.1 erinnert. Auch an anderen Stellen, die nicht alle ausfürlich beschrieben wurden,
sind Modifikationen erforderlich gewesen. Ein Beispiel ist die Bestimmung der kapillaren
Aufstiegsrate, für die bei bestimmten Kombinationen von Eingangswerten, als Ergebnis
in Tabellen des Methodenhandbuchs der Wert > 5.0 oder auch < 0.1 angegeben ist.
Für eine Implementierung der im Methodenhandbuch angegebenen Methoden wäre es
daher wünschenswert, diese Art von Werten zu beseitigen und durch eindeutige Zahlenwerte zu ersetzen. Zusätzlich sollten zahlenwertige Kodierungsschlüssel für bestimmte geografische Daten entwickelt werden, mit denen beispielsweise Bezeichnungen von
Bodenhorizonten (IIBv-T+cCvTu2) oder auch Nutzungsdaten besser verwaltet werden
können. Der von R.Duttmann entwickelte Schlüssel für die Kodierung der Nutzung ist
sicherlich ein richtiger Schritt hin zu einer effizienten computergestützten Verwaltung
geografischer Daten. Ein weiterer anzumerkender Punkt ist, dass sich die Bodenkundliche Kartieranleitung und das Methodenhandbuch an einigen Stellen unterscheiden. Dies
führte insofern zu Problemen, da ursprünglich die Methoden des Methodenhandbuchs
implementiert werden sollten, für die Datenaufnahme aber die Bodenkundliche Kartieranleitung maßgeblich war und in dieser teilweise andere Einteilungen von Werten in
Stufen angegeben oder Methoden nicht definiert waren.
Positiv ist an dem Methodenhandbuch zu bemerken, dass durch den modularen Aufbau
der Methoden die Reihenfolge der Implementierungen zur Ableitung einzelner Werte gut
strukturiert und daher verständlich ist.
111
112
KAPITEL 7. ERFAHRUNGEN UND AUSBLICK
Zum Spatial Cartridge von Oracle sind mehrere Bemerkungen zu machen. An erster
Stelle steht hier natürlich die Problematik der räumlichen Indexe, die die Verschneidungsoperationen massiv beeinträchtigt haben. Weiterhin ist der Anfrageoptimierer von
Oracle8i nicht auf räumliche Anfragen hin erweitert worden. Dies fiel bei der Betrachtung von Ausführungsplänen für räumliche Anfragen auf. Schließlich nimmt auch die
Bearbeitung räumlicher Anfragen zu viel Zeit in Anspruch. Abgesehen davon arbeiten
einige andere Methoden des Spatial Cartridge nicht wie in der Dokumentation angegeben oder haben andere Namen. Diese Probleme sind teilweise sicherlich darauf zurückzuführen, dass Oracle8i bzw. das Spatial Cartridge erst kurze Zeit verfügbar ist und
werden mit nachfolgenden Versionen (hoffentlich) behoben sein, sodass die Bemerkungen aus Abschnitt 6.4 dann nicht mehr aktuell sind. Neben diesen datenbank-technischen
Anmerkungen sind noch einige Stichworte zur Verwaltung der Daten selbst und weiteren
mögliche Forschungsaufgaben zu geben.
Eine denkbare Weiterentwicklung der vorliegenden Datenbank wären Methoden, die
nach Verschneidungsprozessen Flächen mit gleichen Attributausprägungen zu einer neuen Geometrie zusammenfassen. Dies ist bisher nicht implementiert. Das Spatial Cartridge von Oracle bietet hierfür den Objekttyp MULTIPOLYGON an, der dieses leisten
könnte. Ebenso wäre es denkbar Methoden zu entwickeln, die Daten im Rasterformat
analysieren, um Objekte und ihre räumlichen Grenzen im Rasterformat zu identifizieren.
Dadurch wäre es möglich die Zuordnung Sachdaten-Geometrie umzukehren und nicht
mehr den Rasterpunkten die Sachdaten, sondern den Sachdaten eine Menge von Rasterpunkten zuzuordnen, ähnlich der Zuordnung von Polygonen an Standorte. Für eine
Menge von Rasterpunkten bietet Spatial ebenfalls einen Objekttyp an und zwar MULTIPOINT.
Eine andere Zielrichtung ist die Erweiterung der von Spatial angebotenen Methoden zur
Unterstützung dreidimensionaler Berechnungen.
Unabhängig davon wäre es für die zu implementierenden Methoden wünschenswert,
Relationennamen übergeben zu können (Stichwort: dynamisches SQL), da sich die Methoden zur Ableitung von Werten für die unterschiedlichen Formate strukturell nicht
unterscheiden. Schließlich sollte auch die Berücksichtigung temporaler Komponenten
(viele Werte werden für eine bestimmtes Jahr betrachtet) im Hinblick auf dynamische
Simulationen untersucht werden.
Zum Abschluss dieses kurzen Ausblicks sei noch darauf hingewiesen, dass es natürlich
auch ein Ziel zukünftiger Arbeiten sein sollte, die Menge der in der Datenbank implementierten Methoden zu vervollständigen und Simulationsmodelle an sie zu koppeln.
Anhang A
Definition der Relationen
A.1
Neues Schema
-- *****************************
-- ** Informationsebene Boden **
-- *****************************
CREATE TABLE Boden (
BNr
INTEGER,
Bodentyp
VARCHAR2(10) DEFAULT
Grundwasserstand VARCHAR2(10) DEFAULT
Grundwasserstufe FLOAT
DEFAULT
Staunaessestufe INTEGER
DEFAULT
CONSTRAINT PK_Boden PRIMARY KEY(BNr)
);
NULL,
NULL,
NULL,
NULL,
CREATE TABLE BodenProfil (
BPNr
INTEGER,
BNr
INTEGER,
We
FLOAT
DEFAULT NULL,
nFKWe
FLOAT
DEFAULT NULL,
KRmm
FLOAT
DEFAULT NULL,
KRStufe
INTEGER
DEFAULT NULL,
nFKWeStufe INTEGER
DEFAULT NULL,
CONSTRAINT PK_BodenProfil PRIMARY KEY (BPNr),
CONSTRAINT FK_BodenProfil FOREIGN KEY (BNr) REFERENCES Boden(BNr)
);
CREATE TABLE
SNr
Rechtswert
Hochwert
BPNr
CONSTRAINT
BodenStandort (
INTEGER,
FLOAT
NOT NULL,
FLOAT
NOT NULL,
INTEGER NOT NULL,
PK_BodenStandort PRIMARY KEY(SNr),
113
114
ANHANG A. DEFINITION DER RELATIONEN
CONSTRAINT FK_BodenStandort FOREIGN KEY (BPNr) REFERENCES BodenProfil(BPNr)
);
CREATE TABLE BodenHorizont (
HNr
INTEGER,
Horizontbezeichnung VARCHAR2(10) DEFAULT NULL,
Bodenart
VARCHAR2(5)
DEFAULT NULL,
Rohdichte
FLOAT
DEFAULT NULL,
Grobboden
FLOAT
DEFAULT NULL,
Humusgehalt
FLOAT
DEFAULT NULL,
Carbonatgehalt
FLOAT
DEFAULT NULL,
Tongehalt
FLOAT
DEFAULT NULL,
pHWert
FLOAT
DEFAULT NULL,
LD
FLOAT
DEFAULT NULL,
LDStufe
INTEGER
DEFAULT NULL,
nFK
FLOAT
DEFAULT NULL,
We
FLOAT
DEFAULT NULL,
CONSTRAINT PK_BodenHorizont PRIMARY KEY(HNr)
);
CREATE TABLE ProfilHorizont (
BPNr INTEGER,
HNr
INTEGER,
Otief FLOAT NOT NULL,
Utief FLOAT NOT NULL,
-- CONSTRAINT PK_ProfilHorizont PRIMARY KEY(BPNr,HNr),
CONSTRAINT FK_ProfilHorizont_BPNr FOREIGN KEY (BPNr) REFERENCES BodenProfil(BPNr),
CONSTRAINT FK_ProfilSchichten_HNr FOREIGN KEY (HNr)
REFERENCES BodenHorizont(HNr)
);
CREATE TABLE BodenFlaeche (
SNr
INTEGER,
Geometrie
MDSYS.SDO_GEOMETRY,
CONSTRAINT PK_BodenFlaeche PRIMARY KEY (SNr),
CONSTRAINT FK_BodenFlaeche FOREIGN KEY (SNr) REFERENCES BodenStandort(SNr)
);
-- *******************************
-- ** Informationsebene Nutzung **
-- *******************************
CREATE TABLE
SNr
Rechtswert
Hochwert
CONSTRAINT
);
NutzungStandort (
INTEGER,
FLOAT,
FLOAT,
PK_NutzungStandort PRIMARY KEY (SNr)
CREATE TABLE Nutzung(
NNr
INTEGER,
NutzNr INTEGER DEFAULT NULL,
A.1. NEUES SCHEMA
Jahr
INTEGER DEFAULT NULL,
CONSTRAINT PK_Nutzung PRIMARY KEY (NNr)
);
CREATE TABLE Anbau (
SNr INTEGER,
NNr INTEGER,
CONSTRAINT PK_Anbau
PRIMARY KEY (SNr,NNr),
CONSTRAINT FK_AnbauSNr FOREIGN KEY (SNr) REFERENCES NutzungStandort(SNr),
CONSTRAINT FK_AnbauNNr FOREIGN KEY (NNr) REFERENCES Nutzung(NNr)
);
CREATE TABLE
SNr
Geometrie
CONSTRAINT
CONSTRAINT
);
NutzungFlaeche (
INTEGER,
MDSYS.SDO_GEOMETRY,
PK_NutzungFlaeche PRIMARY KEY (SNr),
FK_NutzungFlaeche FOREIGN KEY (SNr) REFERENCES NutzungStandort(SNr)
-- *****************************
-- ** Informationsebene Klima **
-- *****************************
CREATE TABLE
SNr
Rechtswert
Hochwert
CONSTRAINT
);
KlimaStandort (
INTEGER,
FLOAT
NOT NULL,
FLOAT
NOT NULL,
PK_KlimaStandort PRIMARY KEY(SNr)
CREATE TABLE
SNr
Geometrie
CONSTRAINT
CONSTRAINT
);
KlimaFlaeche (
INTEGER,
MDSYS.SDO_GEOMETRY,
PK_KlimaFlaeche PRIMARY KEY (SNr),
FK_Klima_Flaeche FOREIGN KEY (SNr) REFERENCES KlimaStandort(SNr)
CREATE TYPE Typ_KlimaDatum as OBJECT (
Datum
DATE,
Temperatur
FLOAT,
RFeuchte
FLOAT,
Niederschlag
FLOAT,
ewt14
FLOAT,
et14
FLOAT,
ETPhaude
FLOAT
);
/
CREATE TYPE Typ_KlimaDatenTabelle
AS TABLE of Typ_KlimaDatum;
/
115
116
ANHANG A. DEFINITION DER RELATIONEN
CREATE TABLE Klima (
KNr
INTEGER,
KlimaDaten
Typ_KlimaDatenTabelle,
CONSTRAINT PK_Klima PRIMARY KEY (KNr))
NESTED TABLE KlimaDaten
STORE AS KlimaDatenMenge;
CREATE TABLE StandortKlima (
SNr INTEGER,
KNr INTEGER,
CONSTRAINT PK_StandortKlima
PRIMARY KEY (SNr,KNr),
CONSTRAINT FK_StandortKlimaSNr FOREIGN KEY (SNr) REFERENCES KlimaStandort(SNr),
CONSTRAINT FK_StandortKlimaKNr FOREIGN KEY (KNr) REFERENCES Klima(KNr)
);
-- ******************************
-- ** Informationsebene Relief **
-- ******************************
CREATE TABLE Relief25 (
PNr
INTEGER,
x
INTEGER,
y
INTEGER,
Rasterpunkt
MDSYS.SDO_GEOMETRY,
Hoehe
FLOAT,
Hangneigung
FLOAT,
Exposition
FLOAT,
CONSTRAINT PK_Relief25 PRIMARY KEY (PNr)
);
-- *******************************
-- ** Tabelle SDO_GEOM_METADATA **
-- *******************************
CREATE TABLE
TABLE_NAME
COLUMN_NAME
DIMINFO
);
SDO_GEOM_METADATA (
VARCHAR2(30),
VARCHAR2(30),
MDSYS.SDO_DIM_ARRAY
A.2. SCHEMATA FÜR ALTE DATEIFORMATE
A.2
Schemata für alte Dateiformate
-- ****************************
-- *** Originaldatenformate ***
-- ****************************
-- *******************************
-- *** Informationsebene Boden ***
-- *******************************
CREATE TABLE
SNr
Rechtswert
Hochwert
CONSTRAINT
);
Boden_standorte_orig (
INTEGER,
FLOAT,
FLOAT,
PK_Boden_standorte_orig PRIMARY KEY (SNr)
CREATE TABLE
RECNO
AREA
PERIMETER
ILDE#
ILDE_ID
STONR
BOTYP
KULTUR
MGW
GWS
SNAS
FEUCH
GRUN
);
Boden_allg_orig (
INTEGER,
FLOAT,
FLOAT,
INTEGER,
INTEGER,
INTEGER,
VARCHAR2(10),
VARCHAR2(9),
VARCHAR2(10),
FLOAT,
INTEGER,
FLOAT,
VARCHAR2(3)
CREATE TABLE Boden_schicht_orig (
NR
INTEGER,
STONR
INTEGER,
STOID
INTEGER,
OTIEF
INTEGER,
UTIEF
INTEGER,
HORIZ
VARCHAR2(10),
HNBOD
VARCHAR2(5),
LGDI
FLOAT,
STEINE
FLOAT,
ORGSUB
FLOAT,
KALK
FLOAT,
WURZELN
VARCHAR2(2),
GWTIEFE
FLOAT,
FSAND
FLOAT,
MSAND
FLOAT,
GSAND
FLOAT,
FSCHLUFF FLOAT,
MSCHLUFF FLOAT,
117
118
GSCHLUFF
TON
PHWERT
KFWERT
NGESAMT
KAKPOT
SWERT
VWERT
PHOSCAL
SKELETT
LDSV
);
ANHANG A. DEFINITION DER RELATIONEN
FLOAT,
FLOAT,
FLOAT,
FLOAT,
FLOAT,
FLOAT,
FLOAT,
FLOAT,
FLOAT,
VARCHAR2(5),
VARCHAR2(3)
-- *********************************
-- *** Informationsebene Nutzung ***
-- *********************************
CREATE TABLE
RECNO
AREA
PERIMETER
IL_NUTZ#
IL_NUTZ_ID
PARZNR
RFN94
RFN95
RFN96
;
nutzung_orig (
INTEGER,
FLOAT,
FLOAT,
INTEGER,
INTEGER,
INTEGER,
INTEGER,
INTEGER,
INTEGER)
CREATE TABLE
SNr
Rechtswert
Hochwert
);
nutzung_standort_orig (
INTEGER,
FLOAT,
FLOAT
-- ********************************
-- *** Informationsebene Relief ***
-- ********************************
CREATE TABLE
PNr
Rechtswert
Hochwert
Hoehe
);
dgm25 (
INTEGER,
FLOAT,
FLOAT,
FLOAT
CREATE TABLE slope25 (
PNr
INTEGER,
Rechtswert FLOAT,
Hochwert
FLOAT,
Hangneigung FLOAT
);
A.2. SCHEMATA FÜR ALTE DATEIFORMATE
CREATE TABLE
PNR
Rechtswert
Hochwert
Exposition
);
aspect25 (
INTEGER,
FLOAT,
FLOAT,
FLOAT
-- *******************************
-- *** Informationsebene Klima ***
-- *******************************
-- wird direkt in neue Relationen
-- importiert
119
120
ANHANG A. DEFINITION DER RELATIONEN
Anhang B
Tipps und Tricks
In diesem Abschnitt wird beschrieben wie Vektorkarten praktisch in die Rasterdarstellung transformiert werden. Da die Methode SDO RELATE() nur unzureichende Ergebnisse liefert mussten einige Nachbearbeitungen erfolgen.
Eine Möglichkeit, die Rasterdaten zu vervollständigen besteht darin, mehrere Rasterkarten, die mit unterschiedlichen Werten für SDO LEVEL und SDO NUMTILES erzeugt
wurden, übereinanderzulegen. Dies entspricht einer Verschneidung mehrerer Rasterkarten und ist relativ schnell durchzuführen, da die Nummern der Rasterpunkte alle dieselben Koordinaten referenzieren (sie beziehen sich alle auf Raster10). Bei diesem Verfahren
wird zunächst eine Karte benutzt, die mit einer anderen verschnitten wird. Dabei werden
in der Ursprungskarte nur den Punkten neue Werte zugewiesen, die vorher null-Werte
bezüglich des betrachteten Attributs hatten. Dieses Verfahren wird anschließend mit anderen Karten iteriert. Die Punktanzahl bei Bodenkarten kann dadurch auf etwa 85000
erhöht werden.
Anschließend wird eine SQL-Prozedur angewendet, die für Punkte, denen null-Werte
zugewiesen sind, die benachbarten Punkte betrachtet und den am häufigsten vorkommenden Wert diesem Punkt zuordnet. Diese Methode findet sich in
./Programme/Rasterkarten/interpoliere_fehlende_Punkte.sql
Sie bezieht sich allerdings lediglich auf die Relation BodenRaster10, für das Nutzungsraster liegt aber im selben Verzeichnis eine entsprechende Datei.
Mehrfache Anwendung dieser Prozedur bewirkt, dass allen Rasterpunkten Werte zugewiesen werden.
Dieses Verfahren bewirkt aber noch nicht die Beseitigung der schmalen horizontalen
Streifen mit falschen Werten. Um diese Werte zu korrigieren existiert folgende Prozedur:
./Programme/Rasterkarten/korrigiere_falsche_PunkteBoden.sql
Diese Prozedur betrachtet zu jedem Punkt seinen oberen und unteren Nachbarn und
121
122
ANHANG B. TIPPS UND TRICKS
falls diese beiden Punkte den gleichen, vom betrachteten Rasterpunkt abweichenden,
Wert besitzen, wird der Wert des Rasterpunktes ebenfalls auf den Wert der Nachbarn
korrigiert.
Eine andere Möglichkeit, die in der vorliegenden Arbeit zur Erzeugung der Rasterkarten
verwendet wurde, arbeitet wie folgt:
Zunächst wird eine Rasterkarte mittels des Operators MDSYS.SDO FILTER() erzeugt.
Dieser Operator ist lediglich ein Primärfilter und liefert daher für ganze Kacheln Werte.
Die Größe der Kacheln ist abhängig von SDO LEVEL. Im vorliegenden Fall wurde ein
Wert von 9 verwendet. Dies entspricht 512×512 Kacheln, pro Kachel demnach durchschnittlich weniger als ein Rasterpunkt. Trotzdem werden nur 85910 Rasterpunkten
Werte für die Bodenstandorte zugeordnet. Nach dem Betrachten der durch die Relation
RasterBoden10 gegebenen Karte wird eine andere Karte ausgewählt, die für die Flächen,
für die noch keine Werte vorhanden sind, Werte besitzt und wie oben beschrieben mit
der bisher erzeugten Karte verschnitten.
Auf die jetzt vorhandene Relation RasterBoden10 wird gegebenenfalls noch die Methode
zur Interpolierung der fehlenden Punkte angewendet.
Das Ergebnis ist für die weiteren Berechnungen benutzt worden. Zur Erzeugung der
Relation RasterNutzung10 wird analog vorgegangen.
Anhang C
Visualisierung
Die in dieser Arbeit dargestellten Abbildungen des Untersuchungsgebietes Groß-Ilde
wurden mithilfe zweier Visualisierungstools erzeugt, deren Benutzung hier kurz erläutert
werden soll.
C.1
Rasterkarten
Zur Darstellung der Rasterkarten wurde das Programm
./Programme/Rasterkarten/jhpplot.java
verwendet. Der Aufruf dieses Programms erfolgt mit drei Parametern:
java jhpplot Eingabedatei Fenstergroesse_x Fenstergroesse_y
Die Parameter Fenstergroesse x bzw. Fenstergroesse y bestimmen die Größe des Ausgabefensters. Die Punkte werden entsprechend skaliert. Die Eingabedatei muss folgendes
Format besitzen, dass auch zum Export der in der Datenbank berechneten Werte in ein
GIS eignet:
x-Koordinate
x1
x2
x3
...
y-Koordinate
y1
y2
y3
...
Attributwert
v1
v2
v3
...
Zur Ausgabe einer solchen Datei aus der Datenbank wird die Datei
./Programme/Rasterkarten/ausgabe.sql
verwendet. Das Visualisierungsprogramm liest zunächst alle Punkte ein und berechnet
anschließend aus den Koordinaten die maximalen und minimalen Ausdehnungen des
darzustellenden Gebietes. Dies wird für die Skalierung der Punkte benötigt. Zusätzlich
123
124
ANHANG C. VISUALISIERUNG
werden noch die Attributwerte betrachtet, die auf einen Bereich von 0 bis 255 skaliert
werden, um die Anzahl der zur Verfügung stehenden Farben ausnutzen zu können.
C.2
Vektorkarten
Zur Darstellung der Vektorkarten wurde das Programm
./Programme/Vektorkarten/plotPolygone.java
verwendet. Beim Aufruf dieses Programms ist lediglich der Name einer Eingabedatei zu
übergeben, die folgenden Aufbau hat:
Attributwert1
sdo_elem_info1
x11,y11,x12,y12,x13,y13 ...
Attributwert2
sdo_elem_info2
x21,y21,x22,y22,x23,y23 ...
...
Attributwert ist dabei für die Farbwahl in der Darstellung ausschlaggebend. Der Wert
sdo elem info wird aus der Datenbank übernommen und dient der Interpretation des
Polygons (Polygon, Polygon mit Loch, Multipolygon), um die Darstellung korrekt zu
gestalten. Es folgen die Koordinaten, die ebenfalls unbereinigt aus der Datenbank gelesen werden. Um beispielsweise ein Inselpolygon darzustellen werden die zwei in der
Koordinatenliste vorhandenen einfachen Polygone vom Programm zunächst extrahiert
und intern als zwei einzelne Polygone weiterverarbeitet. Auch dieses Programm berechnet die Ausmaße der darzustellenden Karte, um die Polygone an die richtigen Stellen zu
zeichnen.
Die Eingabedatei für dieses Programm wird in zwei Schritten erhalten. Zunächst werden
die Attributwerte und die benötigten Polygoninformationen aus der Datenbank ausgelesen. Dies geschieht mit
./Programme/Vektorkarten/ausgabe.sql
In diesem SQL-Skript müssen ebenfalls Anpassungen für die jeweils auszugebenden Werte gemacht werden. Das Ergebnis ist eine Ausgabedatei mit begrenzter Zeilenlänge. Daher müssen die Zeilen wieder zusammengesetzt werden. Dies wird durch das Programm
./Programme/Vektorkarten/converter.java
realisiert. Dieses Programm entfernt alle Leerzeichen bei den Koordinatenwerten. Die
benötigten Zeilenumbrüche zur Interpretation der Daten bleiben aber erhalten.
Anhang D
Hilfsprogramme Datenimport
D.1
Konvertierung der Sachdaten
Das Programm convert.java erzeugt aus einer Eingabedatei im ASCII-Format SQLKommandos, um die Werte der ASCII-Datei in eine Relation einzulesen. Aufruf des
Programms:
java convert InputFile NameRelation #Attribute
NameAttr[1] TypWert[1] NameAttr[2] TypWert[2] ...
Die einzelnen Übergabeparameter haben folgende Bedeutung:
• InputFile: Name der Eingabedatei
• NameRelation: Name der Relation, in die die Werte eingefügt werden sollen
• #Attribute: Anzahl der Attribute der Relation NameRelation
• NameAttr[i]: Name des i-ten Attributs der Relation NameRelation
• TypWert[i]: Wertebereich des Attributs NameAttr[i]
Anmerkung: Für TypWert[i] wird nur zwischen s für Zeichenkette und nicht s als numerischer Wert unterschieden.
Das folgende Beispiel zeigt die Benutzung dieses Programmes für eine einfache Datei,
die jeweils zwei Zahlen und ein Zeichen pro Zeile enthält.
Beispiel:
Eingabedatei: testdatei.txt
1 2 a
3 4 b
5 6 c
125
126
ANHANG D. HILFSPROGRAMME DATENIMPORT
java convert testdatei.txt Relation 3 Attribut1 i Attribut2 i Attribut3 s
Ausgabe:
insert into Relation(Attribut1,Attribut2,Attribut3) values (1,2,´a´);
insert into Relation(Attribut1,Attribut2,Attribut3) values (3,4,´b´);
insert into Relation(Attribut1,Attribut2,Attribut3) values (5,6,´c´);
Diese Ausgabe kann in eine Datei umgelenkt werden, die dann als SQL-Skript für den
Datenimport zur Verfügung steht.
D.2
Konvertierung der Polygone
Das Programm convert pol ora.java erzeugt aus einer Datei mit Polygondaten eine
Datei, die vom SQL-Loader mit der in Kapitel 5.3 angegebenen Kontrolldatei eingelesen
werden kann.
Aufruf des Programms:
java convert_pol_ora Eingabedatei > Ausgabedatei
Beispiel:
Eingabedatei: testdatei.txt
1
x1
x2
x3
y1
y2
y3
END
2 x4
x5
x6
END
y4
y5
y6
java convert pol ora testdatei.txt
Ausgabe:
1,3,,,1,3,1;x2,y2,x3,y3:
2,3,,,1,3,1;x5,y5,x6,y6:
Diese Ausgabe kann in eine Datei umgelenkt werden, die dann als SQL-Skript für den
Datenimport zur Verfügung steht.
Anm.: Die Eingabedateien sind teilweise fehlerbehaftet. Die zwei auftretenden Fehler
sind, dass Polygone die Nummer -99999 haben und dass Punkte doppelt direkt nacheinander in einem Polygon vorkommen. Doppelte Punkte werden von Spatial ignoriert, die
Polygone mit falschen Nummern werden vom Konverter entfernt.
Anhang E
Beispielanfragen
Was ist die minimale und maximale Dauer des kapillaren Aufstiegs im Untersuchungsgebiet ?
SELECT MIN(ta),MAX(ta) FROM vbn;
Welches ist die minimale x-Koordinate in Raster10 ?
SELECT
MIN(a.Rasterpunkt.SDO_POINT.x) FROM Raster10 a;
Wieviele Flächen wurden 1996 wie genutzt und wie groß ist die Summe der Flaechen ?
SELECT n.nutznr,
COUNT(*),
SUM(mdsys.sdo_geom.sdo_area(nf.Geometrie,b.diminfo))/10000 AS Flaeche
FROM
NutzungStandort ns,
Anbau a,
Nutzung n,
NutzungFlaeche nf,
sdo_geom_metadata b
WHERE ns.snr=a.snr AND nf.snr=ns.snr AND a.nnr=n.nnr AND n.jahr=1996 AND
b.table_name=’NutzungFlaeche’ AND
b.column_name=’Geometrie’
GROUP BY n.nutznr
ORDER BY Flaeche;
Welche Polygone beschreiben im Jahr 1996 Flächen, in denen Ackerbau betrieben wurde?
SELECT a.snr
FROM
NutzungFlaeche a, Anbau b, Nutzung c
WHERE a.SNr=b.SNr AND b.NNr = c.NNr AND
c.Jahr = 1996 AND c.NutzNr between 8000 AND 8999;
127
128
ANHANG E. BEISPIELANFRAGEN
Literaturverzeichnis
[1] Adhoc-Arbeitsgruppe Boden; Bodenkundliche Kartieranleitung (4.Auflage); E.
Schweizerbart’sche Verlagsbuchhandlung, Hannover; 1996 (Nachdruck)
[2] Atkinson M., Bancilhon F., DeWitt D., Dittrich K., Maier D., Zdonik S.: The
Object-Oriented Database System Manifesto, In: Kim W., Nicolas J.-M., Nishio
S. (Hrsg): Deductive and Object-Oriented Databases, Proc. of the 1st Int. Conf.,
DOOD’89, Kyoto, Japan, December 1989, S. 223-240; North-Holland, Amsterdam;
1990.
[3] Balzert H.; Lehrbuch der Software-Technik; Spektrum Akademischer Verlag,
Heidelberg-Berlin-Oxford, ISBN 3-8274-0042-2; 1996
[4] Bill R.; Grundlagen der Geo-Informationssysteme, Band 2, Analysen, Anwendungen
und neue Entwicklungen; Herbert Wichmann Verlag, Hüthig GmbH, Heidelberg,
ISBN 3-87907-228-0; 1996
[5] Cornell G.; Java bis ins Detail; Heise, Hannover, ISBN 3-88229-087-0; 1996
[6] Dehnhardt W.; Anwendungsprogrammierung mit JDBC; Hanser, München-Wien,
ISBN 3-446-21265-5; 1999
[7] Duttmann R.; Partikuläre Stoffverlagerungen in Landschaften; Geographisches Institut der Universität Hannover, Abt. Physische Geographie und Landschaftsökologie; Universität Hannover; 1999
[8] Elmasri R., Navathe S.B.; Fundamentals of Database Systems; Addison-Wesley,
ISBN 0-201-54263-3; 2000
[9] Fowler M.; Kendall S.; UML konzentriert; Addison-Wesley-Longman, Bonn 1998
[10] Göpfert W.; Raumbezogene Informationssysteme; Herbert Wichmann Verlag
GmbH, Karlsruhe; 1987
[11] Goudie A.; Physische Geographie Spektrum Akademischer Verlag GmbH,
Heidelberg-Oxford-Berlin; 1995
[12] Hake G., Grünreich D.; Kartographie (7.Auflage); Walter de Gruyter, Berlin - New
York; 1994
129
130
LITERATURVERZEICHNIS
[13] Kemper A., Eickler A.; Datenbanksysteme; Oldenbourg Verlag, München; 1997
[14] Leser H. (Herausgeber); Handbuch des Geographieunterrichts, Band 11, UMWELT:
Geoökosysteme und Umweltschutz; Aulis Verlag Deubner & Co KG, Köln; 1997
[15] Lipeck U.; Skript zur Vorlesung Datenbanksysteme WS 95/96; Institut für Informatik, Universität Hannover 1996
[16] Neteler M.; Das GRASS-Handbuch; Geographisches Institut der Universität Hannover, Abt. Physische Geographie und Landschaftsökologie; Universität Hannover;
2000
[17] Müller Udo; Auswertungsmethoden im Bodenschutz - Dokumentation zur Methodenbank des Niedersächsischen Bodeninformationssystems; Niedersächsisches Landesamt für Bodenforschung; Hannover; 1997
[18] OpenGIS Consortium, Inc; OpenGIS Simple Features Specification for SQL; 1999
[19] Orenstein J.A., Merret T.H.; A Class of Data Structures for Associative Searching;
In: Proceedings of the 4th ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems; 1984
[20] Rumbaugh J., Jacobson I., Booch G.; Unified Modelling Language – Reference
Manual; Addison-Wesley 1999
[21] Rumbaugh J., Jacobson I., Booch G.; Unified Software Development Process;
Addison-Wesley 1999
[22] Stonebraker M.; Object-relational DBMSs - The next great wave; Morgan Kaufmann, San Francisco; 1996
[23] Online Dokumentation zu Spatial
[24] www.gis-tutor.de
Erklärung
Hiermit erkläre ich, dass ich die vorliegende Arbeit und die zugehörige Implementierung
selbständig verfasst und dabei nur die angegebenen Quellen und Hilfsmittel verwendet
habe.
Hannover, den 15. Februar 2000
131