Entwurf einer raum-zeitlichen Datenbank - hs-nb.de · 2019. 10. 28. · tenbank db4o gewährt, sowie die Vorzüge dieser Datenbank aufgezeigt. Kapitel 4 beschreibt die Umsetzung der

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


ü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


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


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


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


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


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


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


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


• 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


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.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.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


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


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


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


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


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


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


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


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


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


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


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


• 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.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


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


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

Documents

Entwurf einer raum-zeitlichen Datenbank - hs-nb.de · 2019. 10. 28. · tenbank db4o gewährt, sowie die Vorzüge dieser Datenbank aufgezeigt. Kapitel 4 beschreibt die Umsetzung der