View
2
Download
0
Category
Preview:
Citation preview
Entwurf einer raum-zeitlichen Datenbank
Diplomarbeit zum Erlangen des akademischen Grades
Diplomingenieur (FH)
in der Studienrichtung Geoinformatik
vorgelegt von: Martin Kelle
Erstprüfer: Prof. Dr.-Ing. T. Hillmann
Zweitprüfer: Prof. Dr.-Ing. E. Heil
Tag der Einreichung: 10.01.2012
urn:nbn:de:gbv:519-thesis2011-0539-4
Erklärung der Selbstständigkeit
Ich erkläre hiermit an Eides Statt, dass ich die vorliegende Arbeit selbstständig
und ohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe; die
aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche
kenntlich gemacht.
Die Arbeit wurde bisher in gleicher oder ähnlicher Form keiner anderen Prüfungs-
behörde vorgelegt und auch noch nicht veröffentlicht.
Neubrandenburg, den 10.01.2012
Unterschrift
II
Kurzfassung
Diese Diplomarbeit beschreibt einen möglichen Entwurf einer raum-zeitlichen Datenbank,
zusätzlich die Umsetzung, auf Basis einer objektorientierten Datenbank db4o und außer-
dem die Visualisierung des Datenmodells durch Java3D.
Einleitend werden in Kapitel 2 die allgemeinen Grundlagen über die Eigenschaften von
Geodaten wiedergegeben, sowie die Grundlagen von temporalen Daten, hierbei werden die
einzelnen Komponenten zur Klassifikation der Zeit diskutiert. Zusätzlich wird ein Überblick
über temporale Operationen und der Funktionsweise des Allen-Kalkül gegeben. Kapitel 3
beschreibt die Grundlagen von Geodatenbankensysteme und zieht einen Vergleich zwi-
schen den Systemen. Des Weiteren gibt es einen Überblick über 3D-Geodatenbanken und
spatio-temporale Datenbanken, sowie Informationen über die der Arbeit zugrundeliegen-
den Datenbank db4o. Das Kapitel 4 gewährt einen Einblick in die praktische Umsetzung
des Entwurfes und zeigt Möglichkeiten der Anbindung an Fremdsystem. Hintergründe über
die Visualisierung dieser Arbeit mit Java3D gibt Kapitel 5 wieder. Kapitel 6 beinhaltet ein
abschließendes Fazit und einen Ausblick.
III
Abstract
This thesis describes a possible draft of a spatio-temporal database; it also includes the im-
plementation based on a db4o object-oriented database and furthermore the visualization
of the data model by Java3D.
Introductorily the 2nd chapter should give an overview about the general principles of
the properties of geodatas as well as the basics of temporal data. In connection to this
the single components of the classification of time will be discussed. In addition to this
it will be given an overview about the temporal operations and the functionality of the
Allen interval algebra. Chapter 3 describes the fundamentals of spatial database systems
and draws a comparison between the systems. The chapter also gives an overview about
3D spatial databases and spatio-temperal ones as well as information’s about the db4o
database on which this thesis is based. The chapter 4 gives an insight into the practical
implementation of the draft and shows the possible options of connecting with external
systems. A background of the visualization of this work with the help of Java3D will be
given in the 5th chapter. Chapter 6 includes a final conclusion and a forecast.
IV
Inhaltsverzeichnis
Inhaltsverzeichnis
1 Einleitung 1
2 Grundlagen 3
2.1 Geodaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Eigenschaften von Geodaten . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1.1 Geometrische Eigenschaften . . . . . . . . . . . . . . . . . . 3
2.1.1.2 Topologische Eigenschaften . . . . . . . . . . . . . . . . . . 4
2.1.1.3 Thematische Eigenschaften . . . . . . . . . . . . . . . . . . 5
2.1.1.4 Temporale Eigenschaften . . . . . . . . . . . . . . . . . . . 5
2.2 Temporale Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1 Die Zeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2 Klassifikation der Zeit . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2.1 Temporale Struktur . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2.2 Temporale Ordnung . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2.3 Temporale Historie . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.2.4 Temporale Repräsentation . . . . . . . . . . . . . . . . . . 10
2.2.3 Temporale Datenmodelle . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.3.1 Temporales Modell - ISO 19108 . . . . . . . . . . . . . . . . 11
2.2.3.2 weitere temporale Datenmodelle . . . . . . . . . . . . . . . 12
2.2.4 Temporale Operationen und Funktionen . . . . . . . . . . . . . . . . 13
2.2.4.1 Allen-Kalkül . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3 Geodatenbanken 16
3.1 Datenbanksysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.1 Relationale Datenbanksysteme . . . . . . . . . . . . . . . . . . . . . 16
3.1.2 Objektrelationale Datenbanksysteme . . . . . . . . . . . . . . . . . . 17
3.1.3 Objektorientierte Datenbanksysteme . . . . . . . . . . . . . . . . . . 18
3.1.4 Vergleich zwischen relationalen und objektorientierten Datenbanken 19
V
Inhaltsverzeichnis
3.2 Spatio-temporale Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.1 Temporale GIS-Modelle . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3 3D-Geodatenbanken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.1 Existierende 3D-GIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.2 Geometrische und topologische Datenmodelle . . . . . . . . . . . . . 27
3.3.2.1 Geometrische Datenmodelle . . . . . . . . . . . . . . . . . . 27
3.3.2.2 Topologische Datenmodelle . . . . . . . . . . . . . . . . . . 28
3.4 Auswahl der Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.1 db4o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4.1.1 Öffnen, Schließen, Speichern, Löschen . . . . . . . . . . . . 35
3.4.1.2 Anfragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.1.3 Aktualisierung und Aktivierung . . . . . . . . . . . . . . . 36
4 Realisierung 38
4.1 verwendete Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2 Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.1 Klasse PunktHistorie . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.2 Klasse Punkt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.3 Klasse Linie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2.4 Klasse Auslesen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.5 Klasse AllenKalkuel . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2.6 Klasse NearestNeighbor . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2.7 Paket topologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.2.8 Paket tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3 Anbindung an Fremdsysteme . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5 Visualisierung 54
5.1 Java 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.1.1 Package visual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.1.1.1 Klasse App . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.1.1.2 Klasse MouseTransformGroup . . . . . . . . . . . . . . . . . 56
5.1.1.3 Klasse Java3DContainer . . . . . . . . . . . . . . . . . . . 56
5.1.1.4 Klasse RadioButton . . . . . . . . . . . . . . . . . . . . . . 57
5.1.1.5 Klasse DatumCheck . . . . . . . . . . . . . . . . . . . . . . . 59
5.1.1.6 Klasse Point4D . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.1.1.7 Klasse Line4D . . . . . . . . . . . . . . . . . . . . . . . . . 60
VI
Inhaltsverzeichnis
5.1.2 Bilder des Java Anwendungsfenster . . . . . . . . . . . . . . . . . . . 61
6 Fazit und Ausblick 66
Abbildungsverzeichnis viii
Tabellenverzeichnis ix
Literaturverzeichnis xiii
VII
1 Einleitung
Raum und Zeit sind allgegenwärtig. Seit der Relativitätstheorie von Albert Einstein ist die
Verschneidung von Raum und Zeit in einer einheitlichen vierdimensionalen Struktur be-
stätigt, die sich im Raum-Zeit-Kontinuum, oder auch Raumzeit genannt, wieder spiegelt.
Auf Grund dieser Tatsache lassen sich Raum und Zeit nicht getrennt voneinander betrach-
ten, vielmehr ist es wichtig die Betrachtungsweise der Abhängigkeit von Raumbezug und
Zeitbezug in der Realweltmodellierung zu berücksichtigen - ungefähr genauso wichtig, wie
die Komplexität dynamischer Phänomene der Realwelt zu erfassen, zu modellieren, zu ver-
walten und schlussendlich zu visualisieren.
Heutige relationale bzw. objektrelationale Geodatenbanksysteme stellen hierzu nur unzu-
reichende Mittel zu Verfügung um die Dynamik von Geoobjekten abzubilden. Datenbank-
prototypen aus dem universitären Bereich versuchen es, sich dieser gewaltigen Aufgabe
anzunehmen, aber diese Prototypen sind dann leider oft zu speziell und auf eine bestimm-
te Problemstellung zugeschnitten, woraus schlussendlich folgt, dass diese Datenbanken in
der Regel nicht universell einsetzbar sind.
Begründet auf dieser Tatsache, werden in dieser Arbeit Wege, wie raum-zeitliche Phä-
nomene in einer objektorientierten Datenbank verwaltet und visualisiert werden können
vorgestellt, außerdem wird eine prototypische Beispielimplementierung praktisch umge-
setzt.
Kapitel 2 beschäftigt sich einleitend mit den allgemeinen Grundlagen über die Eigenschaf-
ten von Geodaten, sowie die Grundlagen von temporalen Daten, hierbei werden die ein-
zelnen Komponenten zur Klassifikation der Zeit diskutiert. Zusätzlich wird ein Überblick
über temporale Datenmodelle, sowie über temporale Operationen und der Funktionsweise
des Allen-Kalkül gegeben.
Kapitel 3 beschäftigt sich mit den Grundlagen von Datenbankensysteme und stellt die ver-
schiedenen Datenbankensysteme vor. Es wird in diesem Kapitel ein Vergleich zwischen den
vorhandenen Systemen gezogen und deren Vor- und Nachteile gegenübergestellt. Weiter-
hin werden aktuelle Ansätze von 3D-Geodatenbanken und spatio-temporale Datenbanken
1
aufgeführt. Abschließend werden Einblicke zur Funktionsweise der objektorientierten Da-
tenbank db4o gewährt, sowie die Vorzüge dieser Datenbank aufgezeigt.
Kapitel 4 beschreibt die Umsetzung der raum-zeitlichen Datenbank. Es werden Einblicke
in die verschieden Pakete und Klassen dieser Arbeit gewährt, sowie die Funktionsweisen
der einzelnen Methoden vorgestellt und erklärt. Darüber hinaus werden Möglichkeiten der
Anbindung an Fremdsysteme aufgezeigt und in Grundzügen beschrieben.
Kapitel 5 stellt die visuelle Umsetzung dieser Arbeit vor. Die Abbildungen des Anwen-
dungsprogrammes veranschaulichen bildlich das, was in der Arbeit realisiert worden ist.
Die verschiedenen Klassen und Methoden für die Umsetzung des Anwendungsprogrammes
werden erläutert, ferner ist ein kurzer Exkurs zu Java3D enthalten.
Unter Kapitel 6 sind der Ausblick und eine Handlungsempfehlung zu finden. Wie wird
sich die Situation von raum-zeitlichen Datenbankmodellen mit großer Wahrscheinlichkeit
entwickeln und welche Umsetzungen sind erforderlich, um das bisher realisierte Wissen auf
diesem Gebiet noch weiter auszubauen.
2
2 Grundlagen
2.1 Geodaten
2.1.1 Eigenschaften von Geodaten
Bei der Entwicklung von Datenbankmodellen zur Speicherung und Verwaltung von Geo-
daten müssen gewisse Eigenschaften berücksichtigt werden. Diese Eigenschaften von Geo-
daten, die modelliert werden sollen, lassen sich in vier Kategorien einteilen:
• Geometrische Eigenschaften geben die Ausdehnung und Lage im Raum an.
• Topologische Eigenschaften definieren die relative Beziehungen/Abhängigkeiten zwi-
schen räumlichen Objekten.
• Thematische Eigenschaften entsprechen Sachattributen und geben Typ und Klasse
des Objektes an.
• Temporale Eigenschaften beschreiben den Transaktionszeitpunkt oder die Gültig-
keitszeit der vorangegangenen Eigenschaften.
Eine detaillierte Beschreibung der einzelnen Eigenschaften von Geodaten wird in den nach-
folgenden Kapiteln vorgenommen.
2.1.1.1 Geometrische Eigenschaften
Die geometrischen Eigenschaften repräsentieren die Lage (z.B. ein Punkt) bzw. die Lage
und die Ausdehnung (z.B. ein Stadtgebiet) eines Objektes. Realisiert wird die Repräsentati-
on über Koordinaten in einem Koordinatensystem. Es gibt hierbei jeweils zwei grundlegend
unterschiedliche Modellformen im 2D Raum und im 3D Raum. Im 2D Raum spricht man
vom Rastermodell und dem Vektormdell, im 3D Raum hingegen spricht man vom Draht-
modell (Vektor) und vom Volumenmodell (Raster). Vektormodelle bauen auf Punkten und
der lokal kürzesten Verbindung zwischen zwei Punkten (Linie) auf. Dadurch können kom-
plexe Einheiten (z.B. Linenzüge, Polygone und Multipolygone) gebildet werden, die zur
3
2.1. Geodaten
Beschreibung von Linien und Flächen dienen. Das Vektormodell eignet sich bestens zur
Modellierung von Geoobjekten in Geodatenbanksystemen. Rastermodelle hingegen zerle-
gen den Datenraum in gleichförmige Teilflächen, so genannte Rasterzellen. Sie finden ihren
Haupteinsatz eher im raumbasierten Datenmodell, zum Beispiel als Rasterbild von Luft-
aufnahmen oder Satellitenbildern. Objektbasierte Rastermodelle sind eher unüblich.
2.1.1.2 Topologische Eigenschaften
Für die Topologie von Objekten gibt es zwei Möglichkeiten der Modellierung, zum einen
die explizite und zum andern die implizite Modellierung. Die implizite Modellierung findet
die häufigste Verwendung in Geodatenbanksystemen, außerdem wird bei dieser Art die
topologische Eigenschaft aus der Geometrie abgeleitet. So kann zum Beispiel mit Hilfe der
Koordinaten herausgefunden werden, welche Flächen eine Überlappung aufweisen. Diese
Vorgehensweise ist zwar sehr rechenaufwändig, aber auch sehr effektiv, vorausgesetzt die
Geometriedaten sind weder fehlerhaft noch ungenau. Die explizite Modellierung setzt vor-
definierte Beziehungen voraus, durch die mit Hilfe einer n-zu-m Beziehung alle aneinander
stoßenden Flächen definiert werden können. Dadurch begründet müssen bei einer Anpas-
sung der Geometrie auch die topologischen Beziehungen zueinander angepasst werden. Dies
kann ein Grund dafür sein, warum diese Art der Modellierung so wenig Anklang findet.
Topologische Datenmodelle bestehen aus topologischen Primitiven. Topologische Primitive
sind Topologieobjekte, die einzelne, nicht teilbare Elemente eines topologischen Komplexes
darstellen [ISO03].
Es wird zwischen den folgenden Primitiven im dreidimensionalen Raum unterschieden.
• Knoten (engl. Node) sind 0-dimensionale Topologieobjekte - ein Knoten ist die Stelle,
an der eine Kante anfängt, bzw. endet.
• Kanten (engl. Edges) sind 1-dimensionale Topologieobjekte - eine Kante ist die Ver-
bindung zweier Knoten.
• Maschen (engl. Faces) sind 2-dimensionale Topologieobjekte - eine Masche ist eine
Fläche, die durch mehrere Kanten definiert wird.
• Topologischer Körper (engl. Topological Solid) sind 3-dimensionale Topologieobjekte
- ein topologischer Körper wird durch mehrere Maschen definiert.
Jeder topologischen Primitiven kann je ein geometrisches Äquivalent zugeordnet werden.
Siehe Tabelle 2.1.
4
2.2. Temporale Daten
geometrische Primitive topologische Primitive
Punkt Knoten
Linie Kante
Fläche Masche
Körper topologischer Körper
Tabelle 2.1: Raumbezugsprimitive nach dem Spatial Schema (ISO 19107)
2.1.1.3 Thematische Eigenschaften
Thematische Eigenschaften können in qualitative Eigenschaften (Klassifikation) und quan-
titative Eigenschaften (gemessene Werte) unterteilt werden, die Zuordnung der Eigenschaf-
ten kann entweder raum- oder objektorientiert erfolgen. Die objektorientierte Zuordnung,
ist die typische Art der Modellierung in einer Geodatenbank. Bei objektbasierten Daten-
modellen ist das Geoobjekt der Ausgangspunkt der Betrachtung. Dieses Objekt weist eine
Geometrie auf, die dem thematischen Attribut zugeordnet werden kann. Bei raumorien-
tierten Datenmodellen ist der Datenraum der Ausgangspunkt, in dem die Attributwerte
jedem vorkommendem Punkt zugeordnet werden.
2.1.1.4 Temporale Eigenschaften
Die temporalen Eigenschaften von Geoobjekten beschreiben den Zeitpunkt oder den Zeit-
raum, für den die übrigen Eigenschaften gelten. Durch die Speicherung der Eigenschaf-
ten zu verschieden Zeitpunkten, können Zeiträume zwischen den Zeitpunkten abgeleitet
und die Dynamik eines Objektes beschrieben werden. Aufgrund der hohen Komplexität
in Kombination mit anderen Eigenschaften, sind spatio-temporale Datenbankmodelle in
Geoinformationssystemen und in Geodatenbanksystemen häufig noch Grundlage wissen-
schaftlicher Arbeiten. Auf die temporalen Eigenschaften und die temporale Datenhaltung
wird im folgenden Kapitel näher eingegangen.
2.2 Temporale Daten
Um die temporalen Eigenschaften eines Objektes abzubilden sind grundlegende Kenntnis-
se über die Zeit nötig. Raum und Zeit bestimmen unser Alltag, wobei Jeder sich unter
dem Raum etwas vorstellen kann, den meisten Menschen fehlt aber oft die Vorstellungs-
kraft über die tiefgründigere Bedeutung der Zeit. Im Nachfolgenden wird eine Übersicht
5
2.2. Temporale Daten
über die Grundlagen der Zeit gegeben, außerdem werden einige Zeitmodelle etwas detail-
lierter vorgestellt. Zudem wird auf temporale Operationen und Funktionen eingegangen,
speziell auf das Allen-Kalkül (Kapitel 2.2.4.1), das Vergleichsoperatoren für Zeitspannen
bereitstellt.
2.2.1 Die Zeit
Eine einheitliche Definition für den Begriff Zeit ist nicht gegeben, da die Zeit, je nach
Bedarf auf verschiedene Weisen betrachtet werden kann und somit zahlreiche verschiedene
Definitionen für sie existieren. Die Zeit unter der Betrachtungsweise dieser Arbeit kann wie
folgt definiert werden:
Wissenschaftlich betrachtet kann die Zeit Teil eines Messsystems sein, das dazu benutzt
wird, die Abfolge von Ereignissen abzubilden, sowie die Dauer von einzelnen Ereignissen
und die Intervalle zwischen den jeweiligen Ereignissen zu vergleichen. Außerdem kann mit
der Zeit die Veränderung der Bewegung von Objekten gemessen werden1.
In der Newtonschen Beschreibung der Zeit, gilt diese als absolut und unabhängig von der
Bewegung des Betrachters. Durch die Realtivitätstheorie von Einstein wurde die Annahme
der „absoluten Zeit“ von Newton widerlegt, denn nachweislich ist sie doch abhängig von
der Bewegung des Betrachters im Raum. Ein Trennung von Raum und Zeit ist somit nicht
mehr eindeutig möglich, denn Beide stehen in einer bewiesenen Abhängigkeit zueinander.
Basierend auf diesem wissenschaftlichen Beweis liegt der Schwerpunkt dieser Arbeit in der
Betrachtung eines raum-zeitlichen Datenbankmodells und nicht in der Betrachtung von
Datenbankmodellen, die sich entweder nur auf den Raum oder die Zeit konzentrieren.
2.2.2 Klassifikation der Zeit
Eine Klassifizierung der Zeit in Geoinformationssystemen nimmt Frank [Fra98] vor. Seiner
Auffassung nach können Zeitmodelle unter Berücksichtigung der temporalen Primitiven,
der Unterscheidung zwischen linearer und periodischer Zeit, dem Gegensatz zwischen ordi-
naler und kontinuierlicher Zeit und dem gewählten Betrachtungspunkt klassifiziert werden
(vgl. [Rap00]). Zur Erstellung eines zeitabhängigen Datenmodells muss die Zeit klassifi-
ziert werden. Die Klassifizierung der Zeit erfolgt in zwei Teilen - der Darstellung der Zeit
und ihrer Dimension, beide sollen dazu an dieser Stelle, zum besseren Verständnis, genau-
er erklärt werden. Zur Darstellung der Zeit zählen die temporale Ordnung, die temporale
1www.iep.utm.edu/time/ (Stand November 2011)
6
2.2. Temporale Daten
Struktur, sowie die temporale Repräsentation. Die Dimension der Zeit wird an Hand der
temporalen Historie im Folgenden erklärt.
2.2.2.1 Temporale Struktur
Die temporale Struktur ergibt mit den temporalen Primitiven, den temporalen Domänen,
der temporalen Auflösung und der temporalen Determiniertheit die Grundstruktur eines
temporalen Modells.
Temporale Primitive
Die Grundlage der zeitlichen Aspekte in der Geoinformation bauen auf die Primitive Zeit-
punkt und Zeitspanne auf. Sie dienen der Repräsentation der temporalen Eigenschaften
eines Geoobjektes.
Eine Möglichkeit der Angabe eines Zeitpunktes, wäre zum Beispiel der Zeitpunkt einer
Punktmessung. Durch die Angabe eines Anfangs- und Endzeitpunktes, kann ein Lebens-
zeitraum (Zeitspanne) eines Punktes repräsentiert werden. Der Lebenszeitraum eines Punk-
tes kann außerdem auch als Zeitdauer angegeben werden, für den Fall, dass keine Informa-
tionen über einen Zeitpunkt bekannt sind.
Ist die Angabe des Zeitpunktes bzw. der Zeitpanne nicht möglich, sondern nur die Angabe
der Zeitdauer, so müssen diese Primitive um die Primitive Zeitdauer erweitert werden.
• Zeitpunkt (engl. instant) t ist ein eindeutiges und wieder auffindbares Ereignis
• Zeitspanne (engl. period) ist definiert durch einen Anfangszeitpunkt ta und einen
Endzeitpunkt te
• Zeitdauer (engl. interval) entspricht der Länge einer Zeitspanne, ohne Angabe eines
Zeitpunktes
Temporale Domänen
Bei temporalen Domänen besteht die Möglichkeit der ordinalen bzw. der metrischen Ska-
lierung, wobei bei den metrischen Achsen jeder einzelne Wert berechenbar ist und somit
diskret oder kontinuierlich verwirklicht werden kann. Die ordinale Skalierung, dass heißt
eine Skalierung, die nicht absolut datierbar ist, findet sich häufig in der Archäologie wieder.
In der Praxis geht man auf Grund der Verwaltung der Skalierung, den Weg der Reduzierung
der Ereignisse zu diskreten Daten. In dieser Arbeit, wird wie bei den meisten temporalen
Datenbanken von einer diskreten Zeitdomäne ausgegangen.
Temporale Auflösung
Die temporale Auflösung gibt an, wie häufig ein zu betrachtendes Objekt über einen Zeit-
7
2.2. Temporale Daten
raum aufgenommen wurde, bzw. wird. Die Anzahl der Historien eines Punktes über eine
Zeitspanne sind repräsentativ für die temporale Auflösung. Unterliegt ein Punkt einer häu-
figen Änderung, zum Beispiel ein bewegtes Fahrzeug, so sollte die Auflösung höher gewählt
werden, als zum Beispiel die für einen Baum.
Temporale Determiniertheit
Die temporalen Determiniertheit gibt Auskunft darüber, ob zu den temporalen Primitiven
alle relevanten Zeitinformationen vorhanden sind, es kann hier auch von der Genauigkeit
der Zeitinformation gesprochen werden. Ein Punkt ist determiniert, wenn alle Zeitinfor-
mationen zu ihm vorliegen. Eine Einteilung der Detreminiertheit in „sicher“ und „unsicher“
wäre außerdem möglich.
2.2.2.2 Temporale Ordnung
Die temporale Ordnung beschreibt die Möglichkeit zeitlicher Ordnung über temporale
Strukturen. Sie lässt sich in vier verschiedene Ordnungstypen aufteilen.
• Lineare Ordnung: Sie besagt, dass sich die Primitiven in ihren Grenzen nicht über-
lappen dürfen, da die Zeit linear verläuft. Das bedeutet im konkreten Fall, dass ein
Zeitpunkt für eine Punktmessung vor dem Zeitpunkt einer weiteren Punktmessung
liegen muss bzw. umgekehrt, um den Grundsätzen der linearen Ordnung nicht zu
wiedersprechen.
• Sublineare Ordnung: Hier können sich die Primitiven überlappen, wenn es sich
eventuell um nicht determinierte Zeitinformationen handelt. Beispiele für die subli-
neare Ordnung werden an Abbildung 2.1 veranschaulicht. Die sublineare Ordnung
ermöglicht die Verwaltung nicht-determinierter zeitlicher Zusammenhänge und es
kann zum Beispiel eine Punktänderung zwischen zwei Messungen, über zwei nicht-
determinierte Intervalle abgebildet werden. Da der konkrete Zeitpunkt der Punktän-
derung nicht bekannt ist, muss die Zeitspanne zwischen den Messungen angenommen
werden.
• Verzweigende Ordnung: Bei ihr ist es im Gegensatz zu den beiden vorangegange-
nen Ordnungen möglich, dass die Zeit nach einer linearen Betrachtung verzweigt
wird. Repräsentativ für die verzweigende Ordnung, sind zum Beispiel Planungen für
Bauvorhaben.
• Zyklisch, quasizyklische Ordnung: Hierbei stellt sich die Zeit als Zyklus dar, wobei
es möglich ist, dass sich Thematiken wiederholen.
8
2.2. Temporale Daten
Abb. 2.1: Beispiele für die Verwendung einer sub-linearen Ordnung (Quelle: [Zip01])
2.2.2.3 Temporale Historie
Sie beschreibt den Zusammenhang der temporalen Daten (die Semantik) und stellt somit
die zum Beispiel angenommen Zustände eines Objektes dar. Die temporale Historie kann
je nach Anwendungsgebiet in vier unterschiedliche Zeitangaben gegliedert werden.
• Gültigkeitszeit (engl. valid time): Sie repräsentiert den Zeitraum, wann ein model-
liertes Objekt in der realen Welt wahr ist. Der Zeitraum einer Gültigkeitszeit muss
dabei aber nicht begrenzt sein, da das Ende auch in der Zukunft liegen kann. Der
Anfangs- und Endzeitpunkt eines Punktes, sind ein Beispiel für eine Gültigkeitszeit.
• Aufzeichnungszeit (engl. transaction time): Sie repräsentiert den Zeitpunkt, wann
ein Datenelement in den Datenbestand aufgenommen wurde. Die implizite Transak-
tionszeit wird durch die Systemzeit festgelegt, sie kann nicht in die Zukunft reichen
und ist durch die Gegenwart begrenzt. Die Aufzeichnungszeit eines Punktes kann
sich ändern, wenn dieser in einen anderen Datenbestand übernommen wird.
• Erhebungszeit (engl. measure time): Sie gibt Auskunft über den Zeitpunkt, wann
ein Objekt in der realen Welt betrachtet (aufgenommen) wurde. Der Zeitpunkt ei-
nes Messwertes von einem Punkt ist repräsentativ für die Erhebungszeit. Die Er-
hebungszeit kann gleich der Gültigkeitszeit sein, vorausgesetzt die Messung erfolgt
zum Zeitpunkt der Änderung.
• Fortführungszeit (engl. update time): Sie gibt an, wann ein Objekt fortgeführt bzw.
verändert wird.
Zusätzlich zu den Zeitpunkten ist es nach Ansicht von Hosse [Hos05] sinnvoll die Zeiträume
in die Historie mit einzubeziehen. Hierzu zählen die Planungsperiode (engl. planned period),
die aktuelle Periode (engl. current period) und die historische Periode (engl. historical
period), wobei die Perioden bis auf die aktuelle Periode optional sind. Die aktuelle Periode
9
2.2. Temporale Daten
findet auf jeden Fall statt, auch wenn sie bei einer Momentaufnahme zu einem Zeitpunkt
zusammen schrumpft.
2.2.2.4 Temporale Repräsentation
Die temporale Repräsentation beschreibt die Methodik zur physischen und logischen Dar-
stellung der Zeit, es wird unterschieden, ob ein Wert als Maß eines Zeitsystems oder als
Chrononenzahl bezüglich der Basisuhr gespeichert wird. Ein Wechsel zwischen den Dar-
stellungen ist möglich, vorausgesetzt geeignete Überführungsfunktionen stehen zur Verfü-
gung. So ist es möglich, dass ein Zeitpunkt einer Messung nach der ISO-NORM 86012 zum
Beispiel mit dem Wert 19990312091525.00 oder dem Datum 12.03.1999 und der Uhrzeit
09:15:25 gespeichert wird, wobei beide Möglichkeiten die gleichen Informationen zu einem
Zeitpunkt abbilden. Der Vorteil der physischen gegenüber der logischen Repräsentation ist
die Kalenderunabhängigkeit.
2.2.3 Temporale Datenmodelle
Grundlegend sind drei verschiedene Zeitmodelle zu unterscheiden - das stetige, das
lineare und das diskrete Modell. Ein Zeitmodell, das die vier vorangegangen Aspekte der
Zeit berücksichtig wird von Zipf und Krüger in [Zip01] vorgestellt, die Abbildung 2.2
veranschaulicht dieses Modell. Im Weiteren sollen zusätzliche temporale Datenmodelle und
deren Datenbanksprachen beschrieben werden, die sich für ein Konzept einer temporalen
Datenbank eignen. Auf die sich in den Modellen relevanten zu unterscheidenden tempo-
ralen Datentypen, die zur Speicherung der temporalen Eigenschaften notwendigen sind,
wird jeweils kurz eingegangen. Einen Überblick über weitere temporale Datenbanksysteme
(wie z.B. TOM) und deren Datenbanksprachen gewähren Steiner [Ste98], Kaiser [Kai98]
und Zaniolo et al. [Zan97].
2ist ein internationaler Standard, der numerische Datumsformate und Zeitangaben beschreibt
10
2.2. Temporale Daten
Abb. 2.2: Primitive für ein temporales Modell (Quelle: [Zip01])
2.2.3.1 Temporales Modell - ISO 19108
Das Temporale Schema von Geoinformationen aus der ISO-Reihe wird für die Spezifikation
temporaler Charakteristiken von räumlichen Objekten benötigt. Temporale Eigenschaften
von räumlichen Daten beziehen sich auf Klassen (Objekttypen), mit ihren Attributen, Be-
ziehungen, Aktivitäten und Metadaten, oder sie beziehen sich allgemein auf alle Elemente,
die Werte der temporalen Domäne aufweisen. Grundlegend verwendet die Norm die bei-
den Zeitprimitiven Zeitpunkt und Zeitspanne. Ein Vergleich von zwei Zeitpunkten auf einer
Zeitachse ist ebenso möglich, wie der Vergleich von zwei Zeitspannen, unter zu Hilfenahme
der Vergeleichsoperatoren von Allen (siehe Kapitel 2.2.4). Bei den Zeitpunkten wird sich
die Bedingung zu Nutze gemacht, dass ein Anfangspunkt gleich einem Endpunkt sein kann
(Zeitpunkt) und somit zwei Zeitpunkte wie zwei Zeitspannen verglichen werden können.
Dadurch wird auch ein Vergleich von einem Zeitpunkt und Zeitspanne möglich. Neben den
temporalen Attributen, beinhaltet das Schema auch zeitliche Bezugssysteme. Die zeitlichen
Bezugssysteme dieser Norm sind der Kalender und die Uhrzeit, die Zeitkoordinaten und
die Zeitordnung, wobei bei den Zeitkoordinaten die temporalen Angaben relativ zu einem
Zeitpunkt sind und die Zeitordnung eine geordnete Folge von Zeitpunkten repräsentiert.
Eine Berücksichtigung der zeitlichen Dimension eines Objektes kann durch die Speiche-
11
2.2. Temporale Daten
rung von temporalen Informationen in den Metadaten des Objektes, als Zeitattribute, als
Zeitrealtion in Form einer temporalen Beziehung oder als Zeitfunktion in Form einer At-
tributewertänderung erfolgen. Die Norm ist eine Erweiterung der ISO Norm 05 1992, die
die grundlegende Norm zur Beschreibung der Zeit darstellt. [Kre04]
2.2.3.2 weitere temporale Datenmodelle
Gültigkeitszeitmodell
Das Gültigkeitszeitmodell ist ein Modell mit zwei Zeitattributen, die ein Intervall definie-
ren. Die Angabe der Zeitpunkte erfolgte in einem frühzeitigen Modell von Jones [Jon79],
durch die Zeitattribute „start“ und „stop“. (vgl. [Sch01]). Heutige Modelle bauen auf der
gleichen Struktur auf, deren Datentypen der Zeitattribute aber meistens vom Typ DATE
sind. Datenbanken mit Unterstützung der Gültigkeitszeit werden als Historische Daten-
banken bezeichnet.
Transaktionszeitmodell
Das Transaktionszeitmodell beruht auf der Zeitstempelung der Daten, hierbei wird je-
dem Vorgang in einer Datenbank ein aktueller Zeitstempel zugeordnet. In diesem Modell
wird die Vergabe der Zeitstempel durch die Systemzeit realisiert, wobei eine Variable wie
zum Beispiel „now“ Aufschluss darüber gibt, ob ein Datensatz aktuell ist. (vgl. [Sch01])
Datenbanken mit Unterstützung der Transaktionszeit werden als Rollback Datenbanken
bezeichnet.
Bitemporales Modell
In einem Bitemporales Modell ist es möglich die beiden Zeitinformationen der vorange-
gangenen Modelle zu vereinen. Das Modell ermöglicht die Speicherung der Gültigkeitszeit,
sowie auch die Speicherung der Transaktionszeit. Es können hierbei Rückschlüsse auf die
Historie eines Objektes zu einem bestimmten Zeitraum gezogen werden.
Bitemporal Conceptual Data Model (BCDM)
Das BCDM ist ein bitemporales Modell, das als Grundlage für die Sprache TSQL2 dient.
Die Zeitstempelung in diesem Modell ist implizit und die Zeitdimension ist bitemporal,
wobei die Zeitattribute in der Regel nicht beeinflussbar sind. Das Modell setzt voraus, dass
die Zeit linear, diskret und begrenzt ist.
Die Sprache TSQL2 ermöglicht es Informationen über temporale Beziehungen zu gewinnen,
mit Hilfe der Anwendung von temporalen Beziehungsoperatoren. TSQL2 ist eine tempo-
12
2.2. Temporale Daten
rale Erweiterung von SQL92 und sieht neben den vorhanden Datentypen, den Datentyp
PERIOD vor. Der Datentyp PERIOD ist repräsentativ für die Zeitprimitive Zeitspanne .
Interval Extended Relational Model (IXRM)
Das IXRM ist ein Gültigkeitszeitmodell und Basis der Sprache IXSQL, bei dem die Zeit-
stempelung explizit erfolgt und dessen Datentyp zur Zeitstempelung das INTERVALL ist.
Dieser Datentyp ermöglicht auch die Überprüfung zweier Zeitintervalle auf Überlappung.
Neben diesem Datentyp stellt IXSQL auch eigene Funktionen bereit, eine der wichtigsten
Funktion wäre UNFOLD, die das „herunterbrechen“ der Relation auf einzelne Zeitpunkte
ermöglicht. IXSQL ist ebenso wie TSQL2 abwärtskompatibel zu SQL92 und ermöglicht es
somit auch nicht-zeitbezogene Daten zu verarbeiten. (vgl. [Kai98])
Time DB (ATSQL2)
ATSQL2 ist eine Datenbanksprache, genauso wie TSQL2 und IXSQL, sie ist aber nicht
direkt für ein spezielles Datenbanksystem entworfen worden. Für die temporale Daten-
banksprache ATSQL2 existiert mit TimeDB3 ein bitemporales relationales Datenbanksys-
tem. TimeDB ist für die Anbindung an kommerzielle Datenbanksysteme ausgelegt, eine
Unterstützung zum Beispiel von Oracle, Sybase und Couldscape ist gewährleistet. Die Da-
tenbanksprache ATSQL2 ist eine Erweiterung von SQL92 und ihre Anfragen werden intern
in SQL92 Anfragen umgewandelt. Bei der Abfrage von den unterstützten Gültigkeitszei-
tintervallen mit ATSQL2 zum Beispiel, geschieht eine Umwandlung des Intervalles auf
die Zeitstempelattribute BEGIN und END für SQL92. (vgl. [Kai98]) Einen ausführlichen
Überblick über ATSQL2 und TimeDB gewährt Steiner in seiner Arbeit [Ste98].
2.2.4 Temporale Operationen und Funktionen
Über die Zeit lassen sich drei Arten von Veränderungen von Geoobjekten realisieren (Dy-
namik von Geoobjekten), die der Geometrie, die der Thematik und die der Topologie. Die
hierzu benötigten temporalen Abfragen beruhen auf dem selbigen Prinzip der räumlichen
Abfragen, wobei die Operationen unterschieden werden können [Hos05].
• Build-in-Funktionen ermöglichen Verknüpfungs- oder Vergleichsoperationen und lie-
fern stets einen temporalen Typ.
• Arithmetische Operatoren bieten die Möglichkeit der Anwendung von Grundrechen-
arten mit den Datentypen.
3www.timeconsult.com/TimeConsult.html
13
2.2. Temporale Daten
• Vergleichsoperatoren dienen zur Überprüfung der Selektionsbedingungen. Vergleichs-
operatoren für Zeitspannen sind im folgenden Kapitel über das Allen-Kalkül zu fin-
den.
• Aggregatfunktionen bieten die Möglichkeit SQL-Funktionen wie MAX, MIN oder
SUM auf temporale Datentypen anzuwenden.
2.2.4.1 Allen-Kalkül
Die Beziehungen zweier Zeitspannen scheint im alltäglichen Leben trivial zu sein. Durch
eine genauere Betrachtung von zwei Zeitspannen zueinander ergeben sich mehrere mögliche
Zusammenhänge.
Eine Möglichkeit zur Darstellung zeitlicher Zusammenhänge, ist das Allen-Kalkül von Ja-
mes F. Allen [All83]. Das Allen-Kalkül ist eine Zeitlogik, die Zusammenhänge zwischen
Zeitintervallen definiert und die Möglichkeit bietet die Konsistenz vorhandener Zeitinfor-
mationen zu überprüfen. Allen vergleicht hierzu zwei Zeitintervalle und fasst sie zu dreizehn
zeitlichen Beziehungen (Relationen) zusammen. In der Zeitlogik von Allen gibt es sieben
verschiedene Basisrelationen, von denen sechs eine inverse Relation besitzen. Die somit
entstandenen dreizehn Basisrelationen werden in Tabelle 2.2 zusammengefasst.
Bei der Idee von Allen gilt generell, dass der Startzeitpunkt sX vor dem Endzeitpunkt
eX liegt (sX < eX). Somit existiert kein Zeitintervall dessen Startzeitpunkt gleich dem
Endzeitpunkt (sX = eX) ist (Zeitpunkte). Zeitpunkte werden zwar verwendet um Zeitin-
tervalle, sowie deren Relationen zu definieren, in der eigentlichen Zeitlogik finden sie aber
keine weitere Beachtung. Desweiteren können Relationen zusammengestellt werden, auf
deren Möglichkeit an dieser Stelle kurz eingegangen werden soll. Die von Allen so genann-
te „Komposition von Relationen“ ist in einer Kompositionstabelle (siehe [All83], S. 836)
zusammengefasst und beschreibt die Verkettung von zwei Relationen zwischen drei Inter-
vallen. Zwei gegebene Relationen ra und rb geben die Möglichkeit, auf eine dritte Relation
rc zu schließen Xra Y ∧ Y rb Z → Xrc Z . Ist zum Beispiel die Relation X > Y undY > Z gegeben, so ist die dritte Relation rc gleich X > Z .
Es ist zu beachten, dass ein Rückschluss auf die dritte Relation nicht immer eindeutig
möglich ist.
14
2.2. Temporale Daten
Symbol Bild Bezeichnung Beschreibung Punkt-Ordnung
X ≺ Y XY
X findet vor Y statt before sX < eX < sY < eY
X � Y XY
X findet nach Y statt after sY < eY < sX < eX
X m YX
YX trifft auf Y meets sX < eX = sY < eY
X mi YX
YY trifft auf X met-by sY < eY = sX < eX
X o YX
YX überschneidet sich mit Y overlaps sX < sY < eX < eY
X oi YX
YY überschneidet sich mit X overlapped-by sY < sX < eY < eX
X s YX
YX fängt mit Y auf starts sY = sX < eX < eY
X si YX
YY fängt mit X auf started-by sX = sY < eY < eX
X d YXY
X findet während Y statt during sY < sX < eX < eY
X di YX
YY findet während X statt contains sX < sY < eY < eX
X f YX
YX hört mit Y auf finishes sY < sX < eX = eY
X fi YX
YY hört mit X auf finished-by sX < sY < eY = eX
X ≡ Y XY
X ist gleich Y. equals sX = sY < eY = eX
Tabelle 2.2: Basisrelationen des Allen-Kalküls
15
3 Geodatenbanken
3.1 Datenbanksysteme
Datenbanksysteme bieten die Möglichkeit endliche Mengen atomarer Daten zu organi-
sieren, zu verwalten und zu Datensätzen zusammenzufassen, sowie die Darstellung von
Beziehungen und Abhängigkeiten zwischen Daten und Datensätzen abzubilden.
Bei Datenbanksystemen, die auf relationalen bzw. objektorientierten Strukturen basieren,
gibt es grundlegende und besonders für Geoinformationsysteme (GIS) relevante Unter-
schiede. Bei der Wahl des Datenbankmodells, sollte der Anwendungszweck des Informati-
onssystems berücksichtigt werden. Unter kommerziellen Aspekten, wie zum Beispiel dem
Austausch von Datenbeständen, Wiederverwendbarkeit von Softwareteilen oder der Ver-
wendung von „de Facto-“Standardsystemen, haben sich Datenbankmodelle mit relationaler
Struktur durchgesetzt. Nennenswert wären hier Systeme wie ORACLE oder Informix.
Die Realweltmodellierung in GIS wird auf Tabellenstrukturen relationaler Datenbanksys-
teme abgebildet, obwohl zunehmend auch auf objektorientierte Grundkonzepte zurückge-
griffen wird. Es findet somit ein Verzicht auf die objektorientierten Speicherstrukturen
statt. Da sowohl relationale, als auch objektorientierte Ansätze ihre Vor- und Nachteile
im Bereich GIS haben, sollen diese in den folgenden Abschnitten, in Hinblick auf eine
Verwendung als raum-zeitliche Systeme, näher beurteilt werden.
3.1.1 Relationale Datenbanksysteme
In den weit verbreiteten relationalen Geodatenbanksystemen werden sämtlich Daten, egal
ob geometrisch oder thematisch, in Tabellen abgebildet. Die Möglichkeiten sind im Ge-
gensatz zu selbstständigen Datenbanksystemen zwar sehr beschränkt, jedoch sind allge-
meine Konzepte der relationalen Datenbanksysteme umgesetzt [DL02]. Da Geodaten sehr
oft große Einheiten darstellen, die in der Datenbank atomisiert sind, werden sogenannte
BLOBs eingeführt die vom Datenbankmanagmentsystem nicht näher untergliedert werden
können [Bar05]. In weiten Teilen der Informatik treten wenig Probleme mit dem relatio-
16
3.1. Datenbanksysteme
nalen Modell auf - ein Grund dafür ist seine Einfachheit und Robustheit. Die Eignung
relationaler Modelle als temporale Datenbank ist grundsätzlich möglich, da temporale Da-
tentypen unterstützt werden und geeignete Datenbanksprachen zur Verfügung stehen (siehe
Kapitel 2.2.3).
Ein standardisiertes Vorgehen für die Realisierung temporaler Datenbanken gibt es nicht,
da auf Grund der jeweiligen Problemstellung die Anforderungen an eine solche Datenbank
sehr spezifisch ist. Die Realisierung von Punkten und Linien im dreidimensionalen Raum,
mit zusätzlichen temporalen Informationen, ist in solchen Systemen problemlos umsetz-
bar. Werden die geometrischen bzw. topologischen Modelle hingegen komplexer und die
Funktionen, wie zum Beispiel die Verschneidungen müssen bereitgestellt werden, wird ein
solches System ebenfalls sehr komplex. Die Steigerung der Komplexität in den Abfragen
und der Realisierung eines solchen Modells sollte berücksichtigt werden. Dennoch bauen
viele temporale Datenbanken auf dem relationalen Modellen auf, deren Aufgabe meist aber
nicht die Verwaltung dreidimensionaler Modelle ist.
So kann abschließend gesagt werden, dass die Umsetzung vierdimensionaler Datenmodelle
in relationale Modelle möglich ist, jedoch als nicht empfehlenswert angesehen wird.
3.1.2 Objektrelationale Datenbanksysteme
Objektrelationale Datenbanksysteme erlauben die Aufnahme von Objekten. Das relatio-
nale Konzept wird somit lediglich erweitert um einen deklarativen Datenzugriff und ein
Sichtkonzept, das das objektorientierte Konzept umsetzt. Es wird genau genommen ver-
sucht die Vorteile der objektorientierten- und relationalen Datenbanken zu vereinen.
Die Anforderung aus der Objektorientierung können die objektrelationalen Datenbanksys-
teme aber nicht gänzlich umsetzen, dafür bleiben sie aber hundertprozentig kompatibel
zum relationalen SQL. Um die Konzepte der objektrelationalen Datenbanken umzuset-
zen, haben viele Anbieter spezielle Aufsätze entwickelt, bekannte Beispiele wären PostGIS,
ArcSDE und Oracle Spatial. Da objektrelationale Modell die Aufnahme von Objekten er-
möglichen, ist es möglich abstrakte temporale Datentypen zu integrieren.
Das Problem ist, das diese Datentypen weiterhin auf eine Tabellenstruktur abgebildet wer-
den müssen. Der Aufwand der Programmierung und der Implementierung, in Hinblick auf
eine Speicherung temporaler Strukturen von Geoobjekten ist somit sehr hoch. Eine einfa-
che Abbildung der Dynamik von Geoobjekten (z. B. die zeitlichen Variabilität) ist dadurch
durchaus möglich.
17
3.1. Datenbanksysteme
3.1.3 Objektorientierte Datenbanksysteme
Objektorientierte Datenbanksysteme unterscheiden sich zu den vorangegangenen relationa-
len bzw. objektrelationalen Datenbanksystemen, in dem sie gänzlich auf Tabellen verzich-
ten und die eigentlichen Objekte speichern, sie übertragen die Deklarationseigenschaften
der Programmiersprache in die Datenbank.
Ein großer Vorteil gegenüber relationalen Systemen ist, dass sie die Modellierung kom-
plexer Objekte und Datentypen erlauben, relationale Systeme besitzen hingegen nur eine
begrenzte Anzahl von Datentypen. Zusätzlich findet keine Trennung der Daten und Me-
thoden statt, somit enthalten sie nicht nur die Datenstruktur, sondern sie haben auch eine
Kenntnis über ihr Verhalten. Die Systeme bieten somit die Möglichkeit der realistischen
Modellierung der realen Welt und der Nutzung der vollen Objektfähigkeit. Die Prinzipi-
en der Objektorientierung werden umgesetzt, hier an dieser Stelle sollten Objektidentität,
Kapselung und Vererbung genannt werden. Der Objektidentifikator der Objekte ist ein-
deutig und unveränderlich, wodurch die zugehörigen Eigenschaften unverwechselbar sind.
Ein weiterer Vorteil ist die Typisierung des Verhaltens und der Struktur mehrdimensionaler
Objekte, die je nach Problemstellung neu deklariert werden können, ganz im Gegensatz zu
relationalen Datenbanken, in denen sie vordefiniert sind. Objektorientierte Datenbanken
zeichnen sich dadurch aus, dass sie das durch Klassen- und Objektstrukturen aufgebaute
Modell in seiner ganzen Komplexität direkt im sekundären Speicher eines Systems ablegen
und angefragte Objekte mittels Zeigerarithmetik oder Objektidentitäten sehr performant
zur Bearbeitung in den Arbeitsspeicher laden können [Thi03].
Aufgrund der Marktherrschaft der relationalen Systeme und der Überlegung, dass diese
Systeme für die meisten Problemstellungen ausreichend sind, ist es verständlich das objek-
torientierte Geodatenbanksysteme derzeit nur als Prototypen verfügbar sind. Ein weiterer
Punkt ist der betriebswirtschaftliche Hintergrund, denn die Umsetzung heutiger objek-
trelationaler Systeme in völlig eigenständige objektorientierter Systeme und deren Anbin-
dung an die vorhanden Systeme würden einen erheblichen Kostenfaktor darstellen. Die
aufgeführten Vorteile der objektorientierten Datenbanken, zum Beispiel die Möglichkeit
der Implementierung eigener Datentypen und der Verzicht auf die Tabellenstruktur, lassen
den Anschein zu, dass sie gerade dazu geeignet sind sie als raum-zeitliche Datenbanken zu
verwenden. Eine Umsetzung einer raum-zeitlichen Datenbank spricht somit für eine Rea-
lisierung in einer objektorientierten Datenbank.
Das Problem, das nach dem Entwurf eines solchen Modells entsteht, ist die Anbindung an
vorhandene Geoinfomationssysteme, da diese lediglich relationale bzw. objektrelationale
Datenbanken unterstützen.
18
3.1. Datenbanksysteme
3.1.4 Vergleich zwischen relationalen und objektorientierten
Datenbanken
Obwohl objektorientierte Datenbanksysteme noch immer ein Nischendasein fristen, haben
sowohl relationale- als auch objektorientierte Datenbanksysteme ihre Daseinsberechtigung.
Die Wahl des Datenbankmodells für die jeweilige Anwendung sollte an Hand der Komple-
xität des Datenmodells, der Datenmenge und möglicher Anfragen getroffen werden.
Die beiden Datenbanksysteme unterscheiden sich konzeptionell grundlegend, daher sollen
sie im Nachfolgendem miteinander verglichen werden. Der erheblichste Unterschied der
beiden Modellierungsansätze wird in Abbildung 3.1 deutlich.
Der objektorientierte Ansatz speichert das Objekt 1:1 wobei hingegen der relationale An-
satz das Objekt als Daten in tabellarischer Form abbildet. Durch die Speicherung des
Objektes wird die Trennung der Struktur und des Verhalten des jeweiligen Objektes auf-
gehoben.
Abb. 3.1: Vergleich OODB vs. RDB (Quelle: http://wikis.gm.fh-koeln.de/wiki_db/)
Wie bereits in Kapitel 3.1.3 erwähnt sind im objektorientierten Ansatz keine künstlichen
Schlüsselattribute notwendig, da der Objektidentifikator des Objektes eindeutig ist.
Zusammenhängende Strukturen müssen in relationalen Systemen auf viele Tabellen
verteilt werden, so dass fundierte Kenntnisse der Entitäten vVoraussetzung sind, die im
objektorientierten Ansatz in einer Einheit zusammengeführt werden.
Die Abbildung von 1:1 oder 1:n Beziehungen kann ein relationales Modell sehr gut
abbilden, n:m Beziehung hingegen sind sehr komplex und schwer zu verwalten, außerdem
muss die Beziehung muss aufgeschlüsselt werden. In objektorientierten Modellen sind n:m
Beziehungen hingegen möglich.
Die bereits erwähnte Möglichkeit der Implementierung abstrakter temporaler Datentypen
in objektorientierten Datenbanksystemen, spricht für eine gute Abbildung von Realwelt-
objekten. Ein noch größer Vorteil der Generierung abstrakter temporaler Datentypen, ist
19
3.1. Datenbanksysteme
das Bereitstellen von benutzerdefinierten Operationen für die Datentypen in Methoden.
Relationale Modelle hingegen ermöglichen nur die Speicherung von Zeitinformationen in
den begrenzt vorliegenden Datentypen, die nicht die Möglichkeit bieten die Veränderungen
eines Geoobjektes real abzubilden.
Viele weitere Vorteile des objektorientierten Ansatzes könnten an dieser Stelle genannt
werden, wobei der relationale Ansatz natürlich auch seine Vorteile hat.
Die nicht vorhandene Unterstützung objektorientierter Datenbanken, ist der größte
Nachteil für diese. In der Tabelle 3.1 werden weitere Vor- und Nachteile der beiden
Modellierungsansätze veranschaulicht.
Objektorientiert Relational
Vorteile • schneller und direkter Zugriff auf Ob-
jekte
• Implementierung abstrakter Datenty-
pen
• Versionisierung von Objekten
• direkter Zugriff mit Programmierspra-
chen
• keine Trennung der Daten und Metho-
den
• Abbildung von n:m Beziehungen
• typsicher
• Realwelt-konforme Modellierung
• Durchführung mehrerer Transaktionen
gleichzeitig
• Strukturierung der Daten in Tabellen
ist übersichtlich und einfach nachvoll-
ziehbar
• strenger mathematischer Formalismus
bei der Definition
• keine speziellen Kenntnisse über Pro-
grammiersprachen bzw. der Systemar-
chitektur nötig
Nachteile • platzaufwendigere Speicherung
• oft keine Anfragesprachen
• keine Entwicklung großer Datenbank-
hersteller
• fundierte Kenntnisse über Program-
miersprache und Datenbankarchitektur
nötig
• erhöhter Aufwand bei Erweiterungen
und Modifizierungen
• begrenzte Zahl vorhandener Datenty-
pen und begrenzte Möglichkeiten zur
Modellierung komplexer Objekte
• Trennung der Daten und Methoden
• umständliche Aufteilung eines Objek-
tes über mehrere Relationen
• künstliche Schlüsselattribute
• keine Modellierung von objekt- bzw.
typspezifischen Operationen
• Unverträglichkeit der Daten („Impe-
dance Mismatch“)
Tabelle 3.1: Vor- und Nachteile objektorientierter und relationaler Datenbanken
20
3.2. Spatio-temporale Datenbanken
Es lässt sich feststellen, das beide Modellierungsansätze ihre Daseinsberechtigung gegen-
über der jeweiligen Problemstellung haben. Der Vorteil der objektorientierten Datenban-
ken, im Umgang mit komplexen Datenmodellen, steigert ihre Bedeutung hinsichtlich kom-
plexer Strukturen und bietet sich zur Verwaltung von Geodaten geradezu an. Beispiele für
Implementierungen von objektorientierter Datenbanken sind db4o oder ZODB.
3.2 Spatio-temporale Datenbanken
Bei spatio-temporale Datenbanken kommt zu den räumlichen Informationen, die in Kapitel
2.1.1.4 vorgestellte temporale Eigenschaft von Geodaten hinzu. Um diese Eigenschaft in
einer Datenbank abzubilden, müssen temporale Datenbankmodelle geschaffen werden.
In der Geowissenschaft treten zwei verschiedene Formen der Zeitabhängigkeit auf - zum
einen explizite zeitabhängige 3D-Modelle in denen die Zeit ein unabhängiger Parameter ne-
ben den drei räumlichen Dimensionen ist und zum anderen Modelle in denen der jeweilige
Bearbeitungszustand des Modells mittels einer Update Funktion gespeichert wird [Bär07].
Spatio-temporale Datenbanken müssen in der Lage sein, temporale Abfragen und tempo-
rale Operationen zu realisieren, sowie spatio-temporale Prozesse abzubilden um sie später
zu visualisieren. Dabei werden je nach Anwendungsgebiet unterschiedlichste Anforderung
an eine solche Datenbank gestellt, beginnend von der Geologie, die Prozesse über Jahrmil-
lionen abbilden will, bis hin zur Meteorologie, die nahezu Echtzeitanwendungen benötigt.
3.2.1 Temporale GIS-Modelle
Bei der Datenmodellierung von temporalen Daten in Geoinformationsystemen kann grund-
legend zwischen vier Modellformen unterschieden werden (siehe Tabelle 3.2) (vgl. [Hos05]).
Snapshot-Modell
Das Snapshot-Modell ist die einfachste Form der temporalen Datenmodelle, hier wird die
Zeit als Attribut durch einen Zeitstempel realisiert. Bei jeder Änderung in der Topolo-
gie oder der Geometrie wird der gesamte Ausschnitt gespeichert und mit einem neuen
Zeitstempel versehen.
Update-Modell
Das Update-Modell speichert nur die jeweiligen und tatsächlichen Änderungen, durch hin-
zufügen, löschen oder verändern des Objektes. Die Verwaltung findet in Listenform statt.
Der Zustand zu einem Zeitpunkt setzt sich aus einem Grunddatenbestand (eines Zeitschnit-
tes) und der Addition der jeweiligen Objekte zusammen.
21
3.3. 3D-Geodatenbanken
Space-Time-Composite-Modell
Das Space-Time-Composite-Modell beruht auf dem Update Modell, bei dem die Ände-
rungen zwischen zwei Zeitpunkten gespeichert werden. Hierbei besitzt jedes Objekt seine
eigene Historie, wobei eine sukzessive Verschneidung der einzelnen Updates erfolgt.
4D-Modell
Das 4D-Modell ist der einzige Modellansatz der in vollem Umfang die raum-zeit Topologie
unterstützen kann.Die Primitiven Knoten, Kante und Masche gewährleisten hierbei die
räumliche Topologie. Die komplexen Sachdatenmodelle werden mit Hilfe von bidirektionale
Beziehungen in Verbindung gebracht. Durch das hinzufügen der Zeit zur Raumdimension
ist es möglich das jeder Punkt P (xi, yi, zi, ti ) ein mögliches Ereignis in der Raumzeit
widerspiegelt.
Modell Beschreibung
Snapshot-Modell
(Vektor/Raster)
Auch das Time Cube Modell speichert die Zeit als Information
zu einem geografischen Layer.
Update-Modell
(Vektor/Raster)
Für jedes Feature/Objekt wird ein eigener Zeitwert verwaltet.
Basierend auf einem Ausgangszustand erfolgt die Fortschrei-
bung der Änderungen in separaten Layern/Datenbanken (z.
B. geeignet für das Versionsmanagement in Katasteranwen-
dungen).
Space-Time-Composite
(Vektor)
Ähnlich dem Update-Modell, jedoch werden hier alle Versio-
nen mit Änderungen im selben Layer/Datenbank gespeichert.
4D-Modell Jedes Feature/Objekt besitzt metrische und topologische In-
formationen zur Zeit- und Raumkomponente. Durch die To-
pologiebildung zwischen Punkten P (xi, yi, zi, ti ) entstehen
„echte“ 4D-Objekte (Polytope).
Kombinationen der
vier Modelle
Da alle Modelle unterschiedliche Vor- und Nachteile aufwei-
sen, existieren in der Praxis häufig Kombinationen aus den
einzelnen Modellen.
Tabelle 3.2: Grundlegende Modelle für temporale GIS (Quelle: [Hos05], vgl. [Sch99], [Ott01])
3.3 3D-Geodatenbanken
Der „Hype“ der letzten Jahre auf dem Sektor der dreidimensionalen Visualisierung hat
wohl endgültig dazu geführt, das Nischendasein von 3D-Geoinformationssystemen abzu-
22
3.3. 3D-Geodatenbanken
lösen. 3D ist in aller Munde und betrifft unmittelbar unseren täglichen Alltag, sei es in
Navigationsgeräten, Spielkonsolen oder Fernsehgeräten.
Was letztendlich Auslöser dieses „3D-Hype’s“ war ist schwer zu sagen, eine Möglichkeit
wäre die Einführung von Google Earth und Google SketchUP und dem daraus resultieren-
dem Interesse an 3D-Stadtmodellen. 3D hält aber auch Einzug auf anderen Gebieten - zu
nennen wären hier Klimamodelle, die Funknetzplanung, der Entwurf von Bauteilen oder
das Laserscanning. Somit ist die dreidimensionale Datenerhebung, deren Datenspeicherung
sich in einer Datenbank anbieten würde, in vielen verschiedenen Bereichen anzutreffen.
Der Bedarf zum Einsatz von 3D-Geodatenbanken ist von verschiedenen Faktoren abhängig,
einige davon führt Brinkhoff [Bri05] auf:
• Müssen Anfragen bearbeitet werden, bei denen neben der räumlichen Lage auch
Höhenangaben in Anfragebedingungen vorkommen?
• Treten an einer zweidimensionalen Position mehrere oder gar genauso viele Höhen-
werte auf, wie dies bei den beiden ersten Dimensionen der Fall ist?
• Werden in den Anfragebedingungen dreidimensionale Funktionen benötigt?
Es wird deutlich, dass der Einsatz eines 3D-Geodatenbanksystems erst durch das Ein-
beziehen einer dritten Dimension in die Anfrage nötig wird. Ein gutes Beispiel für eine
3D-Geodatenbank ist das Stadtmodell von Berlin, das auf Grund der weiten Verbreitung
von relationalen Datenbankmanagementsystemen und der direkt möglichen Anbindung an
kommerzielle GIS-Systeme, auf Oracle Spatial 10g setzt [Plü].
3D-Datenbanksysteme sind sonst fast ausschließlich als Prototypen im unversitären Bereich
zu finden. Die Eignung einiger dieser Prototypen, als raum-zeitliche Datenbank werden hier
kurz aufgeführt. Ein Beispiel hierfür ist der Prototyp GeoStore und GeoToolKit der Univer-
sität Bonn. Dieser Prototyp eines objekt-orientierten 3D/4D Geodatenbanksystems, wurde
für die geologische 3D-Modellierung des Untergrundes entwickelt.
Die Abbildung wird durch die Erweiterung des Datenbanksystems ObjectStore um spe-
zielle räumliche 3D Geometrieobjekte erreicht. Das Datenmodell basiert auf dem Modell
simplizialer Komplexe. Eine Beschreibung in Hinblick auf zeitabhängige Objektgeometrien
ist in [Bal04] und [Sie04] zu finden.
Ein weiterer Vertreter dieser Prototypen ist das Datenbanksystem GOODAC der Univer-
sität Münster, das ebenfalls auf Basis von ObjectStore arbeitet und eine prototypische Im-
plementierung des Object-Oriented Geographic Data Model (OOGDM) ist. Es unterstützt
23
3.3. 3D-Geodatenbanken
Objekte im Raster- und Vektormodell, sowie im Zweidimensionalen und Dreidimensiona-
len. Eine temporale Erweiterung des Oriented-Geographic Data Model, ermöglicht jedem
einzelnen Attribute Zeitstempel oder Zeitintervalle zuzuordnen.
BAGIS der TU Clausthal, setzt wie die bereits aufgeführten Prototypen auf ObjectStore.
Die Modellierung und Visualisierung geschieht auf Grundlage des 3D CAD-Systems Micro-
station. Das grundlegende Datenmodell ist CORE (Clausthal Object-Relational Database
Modell), darauf aufbauend existiert ein Geodatenmodell GeoCore zur Modellierung von
Geoobjekten.
Ein weiteres Datenbanksystem, DB3D, setzt bei dem Datenmodell auf simpliziale Kom-
plexe und ist für Internet-basierten Zugriff ausgelegt. Ideen und Erfahrungen aus der Ent-
wicklung von GeoToolKit sind in DB3D eingeflossen. [Bär07]
Bei DB3D und GeoStore, bzw. GeoToolKit, können lediglich Flächen oder Körper ver-
schnitten werden, die Visualisierung erfolgt in Schnitten, die für geologische Zwecke sehr
interessant sind. Positiv anzumerken ist, dass OOGDM und BAGIS zwei Datenmodelle be-
reitstellen und es somit ermöglichen ein Vektormodell abzubilden. Weiterhin positiv ist die
temporale Erweiterung von OOGDM, die aber nicht ausreichend ist, reelle raum-zeitliche
Veränderungen abzubilden.
Die vorangegangen Beispiele zeigen, wie der Stand der Entwicklung von 3D-Geodatenbank
ist. Keine der Datenbanken bietet einen vollständigen Funktionsumfang, für topologischer
und geometrischer Modelle. In Bezug auf die Abbildung raum-zeitlicher Veränderungen,
ist die temporale Erweiterung von OOGDM hervorzuheben, die für die Abbildung der
Dynamik von Geoobjekten aber unzureichend ist.
3.3.1 Existierende 3D-GIS
Auf Grund der Tatsache, dass sich diese Arbeit mit dem Entwurf einer raum-zeitlichen Da-
tenbank beschäftigt, sollen zunächst die am Markt vorhanden 3D-Geoinformationssysteme
auf eine mögliche Verwendbarkeit mit temporaler Daten analysiert werden. Schulze [Sch08]
untersucht in seiner Arbeit den Stand der Implementierung von 3D-GIS Produkten, hierbei
werden verschiedene Ansprüche, die an ein 3D-GIS gestellt werden, zwischen den Produk-
ten verglichen. Eine Untersuchung der temporalen Eigenschaften dieser Produkte erfolgte
nicht, daher sollen im folgenden die temporalen Möglichkeiten einiger Produkte vorgestellt
werden.
24
3.3. 3D-Geodatenbanken
GRASS GIS
Grundlegende ist GRASS GIS nicht in der Lage mit temporalen Datentypen umzugehen
oder zeitliche Abfragen auszuführen. Die Idee temporale Daten in GRASS GIS zu ver-
walten, bzw. zu analysieren, ist aber wohl ein Wunsch der GRASS GIS Anwender. Aus
diesem Grund ist die Entwicklergemeinde von GRASS GIS dabei für die Version 7 eine
temporale Erweiterung für diese GIS-Software zu schaffen 12. Auf der Seite GRASS-Wiki3
können die aktuellen Entwicklungsideen eingesehen werden. Die Entwicklung sieht vor, drei
neue Datentypen in GRASS GIS einzuführen, zusätzlich sollen Anfangs- und Endzeitpunkt
eines Objektes, sowie Zeitstempel für die Transaktionszeit (letzte Änderung) realisiert wer-
den. Möglichkeiten der temporalen Datenbankanbindung von PostgreSQL und SQLite, die
beide temporale Datentypen und temporale Abfragen unterstützen, werden angesprochen,
genauso wie die Möglichkeiten der Verwendung von Datenbanken die keine temporalen Da-
tentypen unterstützen. In solchen Datenbanken, soll der Zeitstempel als DOUBLE Wert
gespeichert werden.
Die angesprochene temporale Erweiterung für GRASS GIS soll neben der Möglichkeit der
Analyse temporaler Daten, auch eine Visualisierung dieser beinhalten. Eine Umsetzung
dieser Idee soll für Raster, Vektor und Voxel Datentypen möglich sein. Es sollen absolute
wie auch relative Zeitangaben möglich sein. Neben der Anfangs- und Endzeit, sowie dem re-
lativen Zeitstempel soll die Zeitzone als INTEGER Wert gespeichert werden. Eine Angabe
der Granularität, sowie auch die Angabe der temporalen Auflösung soll für jeden Datensatz
realisiert werden. Grundlegend setzen sich die Entwickler zum Ziel zusätzliche Funktionen
zu schaffen, wie zum Beispiel dem Auslesen einer temporal interpolierten Karte, oder der
Nächsten Nachbar Suche.
ESRI
Die Produktfamilie aus dem Hause ERSI, hat ihren Funktionsumfang seit der Version 10
auf dem Gebiet 3D und temporale Daten erweitert. So stellt die Firma einfache Editor-
werkzeuge für die 3D-Features in der 3D-Ansicht bereit, hier können 3D-Linien digitalisiert,
Attribute geändert, Teile von Multipatchelementen gefangen und Punkt-Features platziert
werden. Außerdem sind einfache Operationen über 3D Elemente möglich, wie zum Beispiel
die Überschneidungen, die Verschneidungen und das Vereinigen von Multipatchelementen,
sowie die Abfragen, welche Features innerhalb eines Multipatches liegen. Nicht möglich
1http://grass.osgeo.org/wiki/Temporal_extension_for_GRASS_GIS_7 (Stand November
2011)2http://grass.osgeo.org/wiki/Time_series_development (Stand November 2011)3http://grass.osgeo.org/wiki/Main_Page
25
3.3. 3D-Geodatenbanken
hingegen sind interaktive Aktualisierungen der Geometrie, bzw. die Bearbeitung der To-
pologie, der Annotation oder die Teilung von Multipatches durch eine 2D-Linie.
Aber auch in Hinsicht auf temporale Daten hat sich einiges bewegt. Beinhaltet die Datenta-
belle eines Layers Zeitstempel zu einem Objekt, so ist es möglich diese zur Visualisierung
zu nutzen. Hierfür hat die Frima ERSI unter den Layereigenschaften einen Reiter Zeit
hinzugefügt. Ist dieser aktiviert, können die Zeitinformationen genutzt werden, wobei die
Möglichkeit besteht, einen aktuellen Zeitstempel des Objektes bzw. einen Intervall auszu-
werten. Zusätzlich können die Intevallschritte, sowei eine Zeitzone angegeben werden. Die
Visualisierung kann dann durch einen Schieberegler oder durch eine Animation realisiert
werden, eine weitere Möglichkeit stellt der Tracking Analyst bereit. In ArcGIS kann die
Zeit wie bereits erwähnt als Zeitpunkt und Zeitspanne verwendet werden, aber auch als At-
tribut oder Transaktionszeit. Diese temporalen Funktionalitäten werden in einem Großteil
der Datensätze bereitgestellt. Für die Bearbeitung von Zeitstempeln wird ein Werkzeug
Names GPTool zur Verfügung gestellt.
LandXplorer und Autodesk AutoCAD MAP 3D
Das Produkt LandXplorer ist vollwertiges Editorwerkzeug für 3D-Karten, es ermöglicht die
Bearbeitung von 3D Stadtmodellen, die in GML im- und exportiert werden können. Eine
zeitabhängige Visualisierung von Geodaten ist mit diesen Produkt ebenfalls möglich. Die
Unterstützung des Datenformates GML spricht dafür, dass LandXplorer temporale Daten
analysieren und auswerten kann, da in GML die Historie eines Geoobjektes möglich ist,
detaillierte Informationen diesbezüglich lagen dem Autor zum Zeitpunkt der Erstellung
dieser Arbeit nicht vor.
AutoCAD MAP 3D, eine AutoCAD mit GIS-Funktionalitäten der Firma Autodesk, bie-
ten einen breiten Funktionsumfang. Auf die Datenbankanbindung dieses Produktes, sowie
die Verarbeitung und die Visualisierung von 3D/4D-Daten geht Bradke [Bra09] in seiner
Arbeit ein. In der Version 2010 von AutoCAD Map 3D war eine Visualisierung temporaler
Informationen nicht möglich, die Auswertung der Versionsvergleichsmatrix4 der Produk-
tänderung bis zum heutigen Zeitpunkt lässt darauf schliessen, dass AutoCAD MAP 3D
in der aktuellen Version diese Funktionalität weiterhin nicht bereitstellt. Durch die Mög-
lichkeit der Datenbankanbindung von SQLite in der aktuellen Version, die temporale Da-
tentypen und temporale Abfragen unterstützt, sollte dieses Produkt weiterhin beobachtet
werden.
4http://images.autodesk.com/emea_dach_main_germany/files/autocad_map_
3d_comparison_matrix_a4_us.pdf (Stand November 2011)
26
3.3. 3D-Geodatenbanken
Schlussfolgerung der vorgestellten Produkte
Die aufgeführten Produkte der Firma ESRI, sowie das Produkt GRASS GIS bestätigen,
dass das Interesse an der Datenhaltung und Repräsentation temporaler Struktur von hoher
Bedeutung ist. Die Visualisierung der Ölkatastrophe im Golf von Mexiko im Jahre 2010,
mit der Hilfe von Produkten der Firma ERSI, zeigt die Möglichkeiten, die in einem Produkt
stecken, das temporale Informationen auswerten kann.
Ein Anbindung an die der Arbeit zugrunde liegenden Datenbank (siehe Kapitel 3.4.1), ist
mit keinem der Produkte direkt möglich. Die Möglichkeiten die für eine Zugriff auf diese
Datenbank zur Verfügung stehen, werden in Kaptitel 4.3 weiterführend erklärt.
3.3.2 Geometrische und topologische Datenmodelle
Im dreidimensionalen Raum wird das geometrische Modell des zweidimensionalen Raums
durch eine dritte Dimension (Volumenkörper) erweitert. Im 3D-Bereich gibt es im Gegen-
satz zum 2D-Bereich kein einheitliches geometrisches Modell. Begründet durch die verschie-
denen Anwendungsgebiete ist die Möglichkeit der Verwendung eines einheitlichen Modells
nicht gegeben und auch nicht unbedingt sinnvoll [Bär07].
Auf Grund der vielfältigen Literatur und Diskussionen auf diesem Gebiet, soll im Folgenden
nur eine Übersicht über die verschiedenen Modell gegeben werden.
3.3.2.1 Geometrische Datenmodelle
Die Repräsentationsmöglichkeiten dreidimensionaler Informationen lassen sich grundsätz-
lich in drei verschiedene Ansätze unterteilen.
• Vektorbasierte Modelle
Bei den vektorbasierten Modellen können zwei Formen unterschieden werden - die
Randrepräsentation und das Drahtmodell. Das Drahtmodell beschreibt das Objekt
lediglich durch dessen Kanten, bei der Randrepräsentation hingegen wird ein Objekt
durch seine Begrenzungselemente (z.B. Polygon, Kanten und Eckpunkte) beschrie-
ben
• Zerlegungsmodelle
Die Zerlegungsmodelle können wiederum in zwei verschiedene Formen unterteilt wer-
den. Bei der irreguläre Zellzerlegung wird das Objekt aus unterschiedlich getrennten
Primitiven (z.B. Pyramiden, Würfel oder Quader), die zueinander benachbart sind,
näherungsweise abgebildet. Beim Enumerationsverfahren, einem Spezialfall der Zell-
27
3.3. 3D-Geodatenbanken
zerlegung erfolgt die Repräsentation des Objektes durch identische Primitive - hier
findet meist der Würfel als Primitive Verwendung.
• Analytische Modelle
Die analytischen Modelle können durch die Hinzunahme von Pramametern und
Funktionen zu einer Freiformfläche das zu repräsentierende Objekt beschreiben. Va-
rianten der analytischen Repräsentation sind die Funktions-Randrepräsentation, die
Sweep-Repräsentaion und die Parametrische Repräsentation.
Die verschiedenen Modellformen werden in Abbildung 3.2 veranschaulicht.
Abb. 3.2: Verschiedene Modellierungsformen für 3D-Körper (Quelle: [Bri05])
Mischformen der verschiedenen Varianten sind zusätzlich möglich, ein Vertreter der Misch-
formen ist das CSG-Modell (Construtive Solid Geometry). Die vorgestellten Modelle wer-
den von Breuning [Bre05] ausgiebig zur Nutzung in einem 3D-Geoinfrmationssystem dis-
kutiert.
3.3.2.2 Topologische Datenmodelle
Die topologische Modellierung bietet im Vergleich zur geometrischen Modellierung eine
Steigerung der Performance bei topologischen Anfragen, sowie die Wahrung der Integrität
bei der Fortführung. Im topologischen Datenmodell wird ein Punkt nur einmal gespeichert,
wohingegen im geometrischen Modell eine mehrfach Speicherung möglich ist.
Einige Vertreter bzw. Ansätze der topologischen Modellierung sollen nachfolgend vorge-
stellt werden.
3D-FDS nach Molenaar (3D Formal Data Structure)(1992)
Molenaar hat mit dem 3D-FDS eine Erweiterung des Single Vector Value Map (svvm)
um die dritte Dimension entworfen, eine Übersicht des Modells ist in Abbildung 3.3
zusehen. Die Grundlage diese Modells ist eine Randrepräsentaion (siehe Kapitel 3.3.2.1),
erweitert um die Primitiven 0D, 1D und 2D, genutzt zur Darstellung von Punkt-, Linien-
28
3.3. 3D-Geodatenbanken
und Flächenobjekten. Die Grundelemente der Topologie bilden Node (Knoten), Arc
(Kante), Edge (Halbkante) und Face (Facette). Die Einführung des Körpers und der
Halbkanten ermöglichen die Modellierung der dritten Dimension, wobei die Halbkanten die
Aufgabe haben die Orientierung der Flächen umzusetzen, sowie die Grenzen der Fläche
zu repräsentieren. Eine Kante in diesem Modell muss eine gerade Linie sein und eine
Fläche muss planar ist. Die Beziehungen Knoten/Fläche, Kante/Fläche, Knoten/Körper
und Linie/Körper werden explizit gespeichert. Es ist zu sehen, dass Molenaar kein
dreidimensionales topologisches Grundelemet in das Modell integriert hat und auch auf
die Aufnahme gekrümmter Flächen verzichtete. (vgl. [Coo05b], [Zla04])
Abb. 3.3: Konzeptionelles Datenmodell 3D-FDS nach MOLENAAR (1992) [Mol92] (Quelle:
[Coo05b])
3D-GIS-Datenmodell nach Flick
Das Datenmodell nach Flick ist eine Erweiterung des 3D-FDS Modells. Grundlage des
Modells bilden vier Grundobjekte (siehe Abbildung 3.4), mit denen es möglich ist die
Geometrie, die topologischen Beziehungen und die Repräsentation zu verwalten. Hierbei
ist die 0-Zellen ein Punkt, die 1-Zellen eine Linie, die 2-Zellen eine Fläche und die 3-Zellen
ein Körper. Die topologischen Beziehungen der Zellen werden hierbei explizit bidirektional
gespeichert. Bei dem Modell nach Flick wird das Konzept des svvm verworfen, bei ihm er-
folgt die Zuordnung zwischen geometrischen bzw. topologischen Primitiven mit Hilfe einer
Assoziation. Es handelt sich hierbei um ein sehr flexibles Modell, da beim Viewkonzept,
unabhängig von den geometrischen Daten, verschiedene Visualisierungsdaten zugeordnet
werden können. (vgl. [Coo05b])
29
3.3. 3D-Geodatenbanken
Abb. 3.4: 3D-GIS-Datenmodell nach Flick [Fli99] (Quelle: [Coo05b])
ISO 19107 Spatial Schema
Das Spatial Schema der ISO 19107 (siehe Abbildung 3.5) ist ein internationaler Standard
und beinhaltet ein konzeptionelles Datenmodell um Features zu beschreiben und zu
verändern. Es unterstützt hauptsächlich Vektordaten innerhalb von bis zu 3 Dimen-
sionen, die durch die Normung den Datenaustausch zwischen verschieden Systemen
garantieren. Die Primitiven Punkt, Linie, Fläche und Körper bilden die geometrischen
Grundformen des Schemas. Die topologischen Grundformen dieses Modells bilden die
Primitiven Knoten, Kante, Masche und Raumelement. Zusätzlich zu den topologischen
und geometrischen Grundformen stellt das Schema multiple Grundformen (Aggregate)
bereit, die die Zusammenfassung von Primitiven in losen Aggregaten erlaubt. Neben den
multiplen Grundformen existieren noch zusammengesetzte Grundformen (Komplexe), die-
se Grundformen definieren die Zusammenfassung von Primitiven (z.B. zu einer komplexen
Geometrie). Weiterhin definiert das Modell für den Zugriff, den Austausch, die Anfrage,
die Verarbeitung und die Verwaltung von Geoobjekten räumliche Standardoperationen.
(vgl. [Kud07])
Abb. 3.5: ISO19107 Konzeptionelles Schema (Quelle: [Kou09])
30
3.3. 3D-Geodatenbanken
3D Topological Model nach de la Losa (1999)
Bei dem Modell nach de la Losa und Cervelle (siehe Abbildung 3.6) handelt es sich um
ein objektorientiertes Datenmodell. Die topologischen Primitiven sind dabei Node, Arc,
Face und Volume. Das Modell beinhaltet weiterhin ungerichtete und gerichtet Kanten,
sowie orientierte und nicht-orientierte Flächen. Ein Normalvektor jeder Fläche, kann dabei
durch die Richtung der Kanten ermittelt werden. Es erfolgt eine explizite Speicherung
von Löchern und Hohlräumen in diesem Modell. Die geometrische Realisierung erfolgt
über eine triangulierte Randflächenrepräsentation, genauer gesagt durch 0-, 1- und
2-Simplexe.(vgl. [DLL99], [Zla04], [Coo05b])
Abb. 3.6: 3D-GIS Datenmodell nach DE LA LOSA und CERVELLE (1999) (Quelle: [Coo05b])
Urban Data Model nach Coors (2002)
Das Urban Data Model (siehe Abbildung 3.7) ist eine Vereinfachung des 3D-FDS.
In diesem Modell reduzieren sich die zu speichernden Objekte erheblich, da auf die
Speicherung der Kanten verzichtet wird und somit Linien und Flächen nur noch über
Eckpunkte repräsentiert werden. Eine Oberfläche wird durch ebene, konvexe Flächen
repräsentiert, Außerdem wird die Orientierung einer Fläche implizit gespeichert.
Eine Fläche die mehr als drei Knoten besitzt, wird in Dreiecke umgewandelt, so dass jede
Fläche maximal drei Knoten beinhaltet. In diesem Modell existiert keine Primitive Kante,
diese kann aber implizit durch zwei einander folgenden Punkten definiert werden. Eine
Linie des Urban Data Model besteht aus mindestens zwei Knoten. Zusätzlich kann eine
31
3.3. 3D-Geodatenbanken
Fläche nicht mehr als zwei Körper begrenzen. (vgl. [Coo05b])
Abb. 3.7: Urban Data Model nach Coors (2002) (Quelle: [Coo05b])
Simplified Spatial Schema nach Zlatanova (2000)
Das Simplified Spatial Schema (siehe Abbildung 3.8) wurde für Web-Anwendungen
mit vielen Visualisierungsabfragen entwickelt. Das Schema beinhaltet wie das 3D-FDS
vier Features, es wurde aber auf die zwei topologischen Primitiven Knoten und Fläche
reduziert, ähnlich dem vorangegangene Urban Data Model. Die explizite Speicherung der
Beziehung Kante/Fläche wurde entfernt, da sie nach Zlatanova im Dreidimensionalen
verloren geht (z.B. kann eine Kante ein Teil von mehr als zwei Flächen sein). Eine
Voraussetzung des Schema ist, dass Flächen planar sein müssen und das durch sich
schneidende Primitiven neue Primitiven entstehen. Eine explizite Speicherung erfolgt
nur bei den Beziehungen Knoten in Fläche und Fläche in Körper. (vgl. [Zla02]) Eine
detaillierte Beschreibung dieses Modells nimmt Zlatanova und Tempfli in [Zla00] vor.
Abb. 3.8: Simplified Spatial Schema nach ZLATANOVA (2000) (Quelle: [Zla02])
Weitere Modelle werden von ZLATANOVA, RAHMAN und WENZHONG in [Zla02] und
[Zla04] vorgestellt.
32
3.4. Auswahl der Datenbank
Schlussfolgerung der vorgestellten Modelle
Wie die aufgeführten Modelle zeigen, existieren viele verschiedene Wege ein temporales
Modell zu implementieren. Oosterom et al. ([Oos02], S. 8) und Bradke ([Bra09], S. 30)
vergleichen die topologischen Strukturen der meisten vorgestellten Modelle und stellen die
Ereignisse vor. Bradke hebt hierbei das Urban Data Model nach Coors hervor und verweist
auf den Vorteil des geringen Datenvolumens bei der Speicherung dieses Modells hin. Als
Grund dafür gibt er den Verzicht auf zwei Primitive im Vergleich zum 3D-FDS an. Dieser
Rückschluss lässt sich auch bei jüngeren Modellen beobachten, es werden immer weniger
Beziehungen explizit gespeichert und vielmehr implizit aus den geometrischen Primitiven
abgeleitet. Diese Vorgehensweise reduziert wie bereits erwähnt das Datenvolumen erheb-
lich, erfordert bei der impliziten Ableitung aber einen größeren Aufwand. In Hinblick auf
die Veränderung eines Objektes, zum Beispiel bei der Löschung einer Kante einer Fläche
und der damit verbunden eventuellen Auflösung eines Körpers, bringt die implizite Ablei-
tung einen Vorteil, da keine explizit gespeicherten Beziehungen entfernt werden müssen.
3.4 Auswahl der Datenbank
Bei der Auswahl der Datenbank, die dieser Arbeit zugrunde liegt, wurde sich für db4o
von Versant Corporation entschieden. Die Vorteile von db4o als NoSQL-Datenbank über-
zeugten genauso, wie die Möglichkeiten eine objektorientierte Datenbank als Geodatenbank
aufzuzeigen. db4o ist eins der führenden Objektdatenbank-Projekte, das versucht bekannte
Probleme im Bereich Software Engineering und GIS zu lösen.
Die Vorteile von db4o:
• db4o ist optimiert für komplexere Objektstrukturen
• keine spezielle Abfragesprache muss erlernt werden, wie z.B. SQL
• keine Schemainformationen notwendig, die Klasse selbst ist das Schema
• durch Kapselung können gefahrlos Funktionen angeboten werden
• die Abfragen sind typsicher da die Elemente der Programmiersprache verwendet
werden
• bei der Umgestaltung (Refactoring) des Programms können die Abfragen berück-
sichtigt werden
33
3.4. Auswahl der Datenbank
• es besteht die Möglichkeit, dass man von verschiedenen Clients aus in verschiedenen
Sprachen(z.B. C# und Java) auf eine gemeinsame Datenbank zugreifen kann
• db4o kann bis zu 55 mal schneller als Hibernate oder MySQL sein5
• Tiefensteuerung mittels ActionDepth
• fehlerhafte Abfragen werden frühzeitig erkannt
• guter Support für Java und C#
Die Performance der Datenbank spielte eine weitere wichtige Rolle bei der Entscheidungs-
findung. Aktuelle Datenbank-Benchmarks der Initiative PolePosition6 belegen den Vorteil
von db4o.
db4o ist eine Open-Source-Datenbank, die ebenso wie MySQL als duale Lizenz angeboten
wird und die private Nutzung unterliegt der GNU General Public License. Die Datenbank
unterstützt zwei verschiedene Modi, einen eingebetteten Modus und einen Client-Server-
Modus.
Die Auswahl einer objektorientierten Datenbank, ist sehr schwer, da es kaum eine Ge-
genüberstellung von objektorientierten Datenbanken gibt. Eine Auswahl der Datenbank
ist dahingehend schon sehr schwer, da in der Regel nur ein oder zwei Programmierspra-
chen unterstützt werden. Nachteile zu anderen objektorientierten Datenbanken, sind daher
schwer auszumachen. Der Nachteil anderer Datenbanken können zum Beispiel fehlende Ab-
fragesprachen sein, von denen db4o drei zur Verfügung stellt. Aufgrund der wachsenden
Unterstützung von Java im Bereich der Geoinformation (z.B. Java-API der Firma ESRI
oder GeoTools), wurde sich zusätzlich für die Datenbank db4o entschieden, da sie Java
unterstützt.
3.4.1 db4o
Die ausgewählte objektorientierte Datenbank dieser Arbeit db4o, ist unter .NET und Java
erhältlich. Die Installation von db4o ist relativ einfach, im Gegensatz zu anderen Daten-
banksystemen, da sie lediglich aus einer .jar-Datei besteht. Zur Nutzung von db4o ist es
lediglich nötig die Datei in den CLASSPATH für javac und java aufzunehmen.
5http://wikis.gm.fh-koeln.de/wiki_db/Datenbanken/Db4o (Stand November 2011)6www.polepos.org (Stand November 2011)
34
3.4. Auswahl der Datenbank
3.4.1.1 Öffnen, Schließen, Speichern, Löschen
Eine Datenbank unter db4o ist eine einzige Datei und der Name kann unter Berücksichti-
gung der Dateiendung .db4o beliebig gewählt werden.
Für den Import genügt die Anweisung
import com.db4o.*;
oder
import com.db4o.query.*;.
Ein Öffnen bzw. Erzeugen der Datenbank erfolgt über den Aufruf
com.db4o.ObjectContainer db = com.db4o.Db4oEmbedded.openFile (Db4oEmbedded
.newConfiguration (), “datenbank.db4o“);.
Ein Schließen der Datenbank ist über den Aufruf
db.close();
möglich.
Ein Speichern bzw. Löschen von Objekten in der Datenbank wird realisiert über die Aufrufe
db.store(object); (zum Speichern)
db.delete(object); (zum Löschen)
, wobei object, dass zu speichernde bzw. zu löschende Objekt darstellt.
Der ObjectContainer stellt die Datenbank im eingebetteten Modus dar und verwaltet
die Referenzen der Objekt. Die relativ kleine Anzahl der bereitgestellten Methoden, kann
durch ein casten zu com.db4o.ext.ExtObjectContainer erhöht werden.
3.4.1.2 Anfragen
Die db4o-Datenbank stellt drei verschiedene Abfragesprachen, für die Anfragen an die Da-
tenbank bereit. Zu den drei Abfragesprachen zählen Query By Example, Native Anfragen
und SODA. An Hand der Klasse Punkt (Kapitel 4.2.2), soll jeweils kurz ein Beispiel für
die drei Anfragen beschrieben werden.
• Query By Example ermöglicht eine Suche Anhand von Beispielen, hierbei wird der
Anfrage ein erzeugtes Beispielobjekt übergeben. Die Anfrage gibt die Objekte zurück,
die dem Beispielobjekt entsprechen. Ein Beispiel für die Anfrage eines Punktes mit
der Punktnummer „1“ ist:
35
3.4. Auswahl der Datenbank
Punkt be i sp i e lPunkt = new Punkt ( "1" , null ) ;
L i s t r e s u l t = db . querybyExample ( be i sp i e lPunkt ) ;
• Native Anfragen bieten den Vorteil, dass sie in der jeweiligen Programmiersprache
formuliert werden können und somit typsicher und refactorierbar sind. Die Abfrage
eines Punktes könnte wie folgt aussehen.
List r e s u l t = db . query (
new Pred i cate ()
{
public boolean match (Punkt punkt )
{
return punkt . getnummer ( ) . equa l s ( "1" ) ;
}
} ) ;
• SODA (Simple Object Database Access) ist die low-level Anfrage-API. Diese Query
by API ist die Mächtigste der drei von db4o bereitgestellten Abfragesprachen und
bildet die db4o interne Abfragesprache, auf der wiederum alle Abfragen abgebildet
werden. Durch SODA lassen sich sehr komplexe Abfragekriterien ausdrücken, aller-
dings ist sie durch die Verwendung von Zeichenketten in den Abfragen zum Kom-
pilationszeitpunkt nicht typsicher. Aufgrund der Gestaltungsmöglichkeit komplexer
Abfragen mit SODA, hat diese Abfrageart in dieser Arbeit einen hohen Stellenwert.
Ein Beispiel für SODA ist:
Query query = db . query ( ) ;
query . c on s t r a i n (Punkt . class ) ;
query . descend ( "Punktnummer" ) . c on s t r a i n ( "1" ) ;
L i s t r e s u l t = query . execute ( ) ;
Da eine Abfrage wie zum Beispiel über die Historie eines Punktes zu einem gegebenen
Zeitpunkt, mit den vorhanden Abfragesprachen nicht möglich ist, müssen Möglichkeiten
geschaffen werden, um diese Informationen zu erhalten. Die Umsetzung, diese relevanten
Informationen doch zu erhalten, wird in Kapitel 4 näher beschrieben.
3.4.1.3 Aktualisierung und Aktivierung
Werden strukturierte Objekte in der Datenbank aktualisiert, gilt die Regel, dass Verweise
auf andere Objekte mit dem eigentlichen Objekt gespeichert werden, vorausgesetzt, dass
36
3.4. Auswahl der Datenbank
sie noch nicht in der Datenbank existieren. Die Aktualisierungstiefe von db4o ist allerdings
standardmäßig eins. Eine Abhilfe schaffen hierbei die folgenden Zeilen:
EmbeddedConfiguration con f i g = Db4oEmbedded . newConfigurat ion ( ) ;
c on f i g . common ( ) . ob j e c tC l a s s (Punkt . class ) . cascadeOnUpdate ( true ) ;
ObjectContainer db = Db4oEmbedded . openFi l e ( con f ig , datenbank . db4o ) ;
Da ohne diese Angabe die Datenbank nur einen Teil der Aktualisierung speichert und keine
Fehlermeldung ausgibt, sollte dieses Verhalten besonders berücksichtigt werden. Die Be-
achtung der Tiefe sollte auch beim Löschen eines Objektes in der Datenbank berücksichtigt
werden.
Ähnlich der der Tiefe beim Aktualisieren bzw. Löschen, verhält sich db4o bei der Akti-
vierung (Laden). Die standardmäßige Tiefe der Aktualisierung ist fünf, wobei das fünfte
Objekt nur Defaultwerte enthält. Um diese Eigenheiten von db4o zu berücksichtigen und
gegebenenfalls zu umgehen, stellt db4o drei
Recommended