Institut für Kartographie und Geoinformation

Rheinische Friedrich-Wilhelms-Universität Bonn
Landwirtschaftliche Fakultät
Institut für Kartographie und Geoinformation
Diplomarbeit
Implementierung eines 3D-Stadtmodells
in eine objekt-relationale Datenbank
am Beispiel von Oracle Spatial
vorgelegt im Juli 2003 von
Markus Reuter
Betreuer:
Prof. Dr. Lutz Plümer
Dr. Gerhard Gröger
Erklärung
Hiermit erkläre ich, dass ich diese Diplomarbeit selbständig angefertigt und keine
anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie Zitate kenntlich
gemacht habe.
Bonn, Juli 2003
(Markus Reuter)
- leer -
- leer-
Danksagung
Für die fachliche Hilfe bedanke ich mich bei Gerd, Thomas, Thorsten und Björn. Besonderer
Dank gilt Herrn Prof. Dr. Lutz Plümer, der mir diese Arbeit ermöglicht hat und mich intensiv
unterstützte. Ich danke meinen Eltern, die mir dieses Studium ermöglichten und meinem Patenonkel Dr. Hansludwig Hagen, der mir in wissenschaftlicher Hinsicht immer ein Vorbild
gewesen ist. Meiner Freundin Jutta möchte ich für die letzten 9 Jahre mit ihr danken.
Inhaltsverzeichnis
1 Einleitung
8
2 3D-Repräsentation und Datenbankaspekte
10
2.1 Boundary Representation (B-Rep) ......................................................................... 10
2.2 Contructive Solid Geometry (CSG) ....................................................................... 11
2.3 Umsetzung von 3D-Stadtmodellen ........................................................................ 12
2.3.1 3D VECTOR MAPS ................................................................................... 14
2.3.2 SOMAS .......................................................................................................16
2.4 Virtual Reality Modeling Language (VRML) ....................................................... 17
2.5 Datenbanken...........................................................................................................19
2.5.1 Relationales Schema ................................................................................... 20
2.5.2 Objekt-relationales Schema.........................................................................21
2.5.3 Nested tables ...............................................................................................24
2.5.4 Structured Query Language (SQL) .............................................................25
2.5.5 Java-Schnittstelle.........................................................................................29
3 Implementierung des Datenmodells
32
3.1 Modell „Regengeld“............................................................................................... 32
3.1.1 Primitive ......................................................................................................33
3.1.2 Rekursive Aggregation................................................................................35
3.1.3 Integritätsbedingungen ................................................................................39
3.2 Objekt-Relationale Umsetzung .............................................................................. 40
3.2.1 Geometrisch-topologisches Modell............................................................. 40
3.2.2 Rekursive Aggregation................................................................................42
3.2.3 Erstellung des Datenmodells mit SQL ........................................................ 45
4 Eignung von Oracle Spatial
49
4.1 Konzept ..................................................................................................................49
4.1.1 Räumliche Datentypen ................................................................................ 49
4.1.2 Räumlicher Index ........................................................................................53
4.1.3 Räumliche Operatoren................................................................................. 55
INHALTSVERZEICHNIS
7
4.1.4 Räumliche Funktionen ................................................................................ 58
4.2 3D-Fähigkeiten.......................................................................................................59
4.3 Geometriebeispiel...................................................................................................62
4.4 Polyeder-Representation ........................................................................................ 63
4.5 Oracle Spatial Java Library .................................................................................... 65
4.6 Beurteilung .............................................................................................................67
5 Datenaustausch
71
5.1 Import .....................................................................................................................71
5.1.1 Daten der T-Mobile Deutschland GmbH .................................................... 71
5.1.2 VRML .........................................................................................................73
5.1.3 Probleme und Verbesserungen.................................................................... 74
5.2 Erstellung von Spatial-Objekten ............................................................................ 75
5.3 Export .....................................................................................................................79
5.3.1 Geometrisch-topologisches Modell............................................................. 79
5.3.2 Spatial-Layer ...............................................................................................81
6 Analyse
82
6.1 Speicherplatzbedarf................................................................................................ 83
6.2 Import .....................................................................................................................84
6.3 Export .....................................................................................................................84
6.3.1 Topologie-Query .........................................................................................85
6.3.1 Spatial-Query ..............................................................................................90
6.4 Beurteilung .............................................................................................................91
7 Schluss & Ausblick
94
Anhang
97
Literaturverzeichnis
108
Kapitel 1
Einleitung
Dreidimensionale Stadtmodelle gewinnen in vielen Gebieten zunehmend an Bedeutung. Dazu
gehören neben der einfachen Visualisierung vor allem die Stadt- und Raumplanung, Vermessung, mobile Telekommunikation und das Facility Management. Im Umweltbereich ermöglichen 3D-Stadtmodelle die Simulation von Lärm- und Abgasausbreitungen oder Klimaveränderungen. Die Verwaltung, interoperable Nutzung und Visualisierung der dabei zu berücksichtigenden großen Datenmengen erfordert leistungsfähige Systeme und Standards. Kommerzielle Geoinformationssysteme (GIS) stellen dies zur Zeit nicht zur Verfügung. Professionelle Datenbanksysteme, wie z.B. Oracle, verfügen aber mittlerweile über räumliche Erweiterungen und sind bestens geeignet für die Verwaltung von großen Datenmengen.
Momentan existieren für 3D-Stadtmodelle noch keine geeigneten Standards. In der Geodateninitiative (GDI) NRW gibt es aber Diskussionen und Entwürfe, die an bestehende Standards
der ISO TC2111 und des Open GIS Consortiums2 für die allgemeine Repräsentation von 3DObjekten angelehnt sind.
Insbesondere setzt sich hier die Special Interest Group 3D (SIG 3D) innerhalb der GDI NRW
mit genau diesen Fragen der Modellierung, Speicherung, Erstellung, Nutzung, Visualisierung
und Vermarktung von 3D-Stadt- und Regionalmodellen auseinander. Ihr Ziel ist die Entwicklung von offenen Standards für die Modellierung und Visualisierung von 3D-Geobasisdaten
sowie die Spezifikation der entsprechenden Basisdienste für den Zugriff auf die raumbezogenen Objekte. Dass Städte und Unternehmen eine solche nachhaltige Lösung benötigen, um
Investitionen zu sichern und zu amortisieren, zeigt sich an einer langen Liste von derzeit über
70 Teilnehmern in der SIG 3D, die aus Wirtschaft, Wissenschaft und den öffentlichen Verwaltungen kommen.
Am Institut für Geoinformation und Kartographie der Universität Bonn wurde in einem Kooperationsprojekt mit dem Institut für Photogrammetrie für die Stadt Wuppertal ein 3DStadtmodell entwickelt („Regengeld“), welches sich an den Entwürfen der GDI NRW orientiert und dort auch breite Unterstützung findet. Der Kern dieses Datenmodells wird durch die
geometrisch-topologische Modellierung von 0-, 1-, 2-, und 3-dimensionalen Primitiven gebildet. Diese bauen aufeinander auf und realisieren ein Knoten-, Kanten-, Flächen- und Volumenmodell. Dabei werden Volumen durch ihre Randflächen (Boundary Representation, siehe
[Fol95]) beschrieben. Flächen lassen sich durch ihre Kanten beschreiben, die einen Anfangsund Endknoten besitzen. Koordinaten werden hier immer nur Knotenobjekten
1
: http://www.isotc211.org
: http://www.opengis.org
3
: http://www.gdi-nrw.org
2
8
EINLEITUNG
9
zugeordnet. Das Modell wird in Kapitel 3 genauer beschrieben, es ist Ausgangspunkt für diese Arbeit.
3D-Stadtmodelle werden ständig aktualisiert, was einerseits bedeutet, dass mehrere Benutzer
auf das gleiche Modell zugreifen müssen und andererseits die Daten sich permanent ändern.
Die Menge dieser Daten wird permanent wachsen und relativ bald sind dann Größenordnungen von mehreren Millionen Objekten erreicht und spätestens hier wird der Einsatz von skalierbaren und ausfallsicheren Systemen unabdingbar. Um diesen Umständen gerecht zu werden, ist es nötig, auf eine leistungsstarke Datenbank wie die der Firma Oracle zurückzugreifen. Neben der Tatsache, dass sich die Oracle-Datenbank bereits im GIS-Sektor etablieren
konnte, ist vor allem die räumliche Erweiterung „Spatial“ von Interesse, über die bisher aber
noch kaum Untersuchungen bezüglich ihrer 3D-Fähigkeiten existieren.
Ziel dieser Arbeit ist also die Entwicklung einer Datenbank, welche 3D-Objekte im Sinne des
oben genannten geometrisch-topologischen Modells speichern kann und zusätzlich raumbezogene Anfragen mit Hilfe von Oracle Spatial bearbeitet. Für den Datenaustausch und die
Visualisierung bietet sich die Beschreibungssprache VRML [Klo98] an. Sie dient der Darstellung von 3D-Welten speziell im Internet und beherrscht ebenfalls die Randflächendarstellung
von 3D-Objekten. Zur Evaluation dieser Datenbank stehen reale Daten der T-Mobile
Deutschland GmbH zur Verfügung. Besonderes Augenmerk soll der Abbildung von rekursiven Entwurfsmustern gelten. Ebenso soll die Frage geklärt werden, in wie weit sich Oracle
Spatial für räumliche Anfragen nutzen lässt und wie groß deren Effizienz ist.
Die Arbeit gliedert sich wie folgt:
Zu Anfang werden die wichtigsten Grundlagen vermittelt, die zum Verständnis dieses Themas beitragen. Danach wird die Entwicklung des objekt-relationalen Datenbankschemas zur
Repräsentation von 3D-Objekten beschrieben. Kapitel vier befasst sich mit der räumlichen
Erweiterung Spatial und untersucht deren 3D-Fähigkeiten. Kapitel fünf widmet sich den
Werkzeugen für den Datenaustausch, deren Implementierung einen großen Teil der Zeit für
diese Arbeit ausgemacht haben. Im sechsten Kapitel wird die Effizienz der Datenbank untersucht, an die sich eine kritische Beurteilung zusammen mit einem Ausblick anschließt, in dem
Verbesserungsmöglichkeiten und Vorschläge für weitere Untersuchungen aufgezeigt werden.
10
KAPITEL 2 – 3D-REPRÄSENTATION UND DATENBANKASPEKTE
Kapitel 2
3D-Repräsentation und Datenbankaspekte
Die hier vorgestellten Technologien und Konzepte dienen als Grundlage für die anschließenden Kapitel. Dazu gehören Darstellungsformen von 3D-Objekten, die Umsetzung von 3DStadtmodellen, aber auch das Datenformat VRML, mit dem 3D-Welten beispielsweise im
Internet repräsentiert werden können. Unter der Überschrift „Datenbanken“ befindet sich ein
kurzer Abriss über die Unterschiede zwischen relationalen und objekt-relationalen Datenbank-Schemata sowie eine kurze Einweisung in die Sprache SQL, die der Datenbankabfrage
dient. Der letzte Teil bezieht sich auf die Schnittstelle zwischen Java und der Datenbank.
Die Abschnitte 2.1 und 2.2 enthalten die beiden gängigsten Repräsentationsmöglichkeiten von
3D-Objekten. Der Schwerpunkt soll hier auf der Boundary Representation liegen, an welches
alle in dieser Arbeit vorgestellten Datenmodelle angelehnt sind.
2.1 Boundary Representation (B-Rep)
(a)
(b)
(c)
Abbildung 2.1: B-Rep: (a) geschlossenes Objekt (Körper); (b) einhüllende Flächen; (c)
Punkte und Kanten [Män88]
Das als Boundary-Representation (B-Rep) bezeichnete Darstellungsmodell kommt aus der
Computergrafik und definiert räumliche Objekte mit Hilfe der sie begrenzenden Flächenelemente. Ein Körper besteht demnach aus mehreren Flächen, die jeweils zueinander benachbart
sind und somit das Objekt lückenlos umschließen. Diese Flächen wiederum setzen sich aus
mehreren Kanten zusammen, welche durch jeweils zwei Knoten festgelegt sind. Ein
2.1. BOUNDARY REPRESENTATION (B-REP)
11
Knoten kann Anfangs- oder Endpunkt beliebig vieler Kanten sein. Seine 3D-Koordinaten
werden jedoch nur einmal gespeichert, wodurch Redundanzen vermieden werden.
Diese Art der Objekt-Modellierung ist nicht nur im GIS-Sektor mittlerweile weit verbreitet,
sie findet auch Anwendung in der Virtual Reality Modeling Language (VRML) und ist QuasiStandard bei 3D-Computerspielen.
Vorteile der Boundary Representation:
Objekte sind eindeutig, zwei verschiedene B-Rep’s können nicht das gleiche Objekt
darstellen
Die Topologie des Objektes wird erfasst
Realistische Darstellung durch Verwendung von gekrümmten Flächen (Splines)
Den Flächen des Objekts können direkt Texturen zugeordnet werden
Innenliegende, nicht sichtbare Flächen werden eliminiert, wodurch Sichtbarkeitsprobleme vermieden werden
Nachteile:
Änderungen eines Objektes und speziell das Zusammenführen (Aggregation) mehrerer
Objekte ist sehr aufwändig
Die Vielzahl von Flächen erfordert hohen Rechen- und Speicheraufwand
2.2 Constructive Solid Geometry (CSG)
Die CSG-Darstellung, welche eher aus dem Bereich Maschinenbau und CAD kommt, ist eine
Alternative zur Boundary-Representation, spielt aber in dieser Arbeit eine untergeordnete
Rolle. Hier werden einfache 3D-Primitive wie Quader, Pyramiden, Zylinder, etc. durch Addition, Subtraktion, Vereinigung oder Durchschnittsbildung zu komplexen Objekten zusammengesetzt. Gekrümmte Formen wie Kugel, Zylinder oder Kegel sind in diesem Modell ebenfalls darstellbar. Zur Beschreibung eines komplexen Objekts bedarf es also nur mehrerer
Grundkörper und deren Transformationsparameter. Die Aggregation erweist sich als besonders einfach: Komplexe, zusammengesetzte Objekte werden als neue Primitive definiert, was
zu einem minimalen Satz von Formparametern für Objekte eines Typs führt. Dieser Vorgang
wird „Primitive Instancing“ [Fra02] genannt.
Abbildung 2.2: CSG: Zusammensetzung eines komplexen Objekt aus Grundkörpern
12
KAPITEL 2 – 3D-REPRÄSENTATION UND DATENBANKASPEKTE
Vorteile der Contructive Solid Geometry:
Simple Konstruktion
Geringe Anzahl von zu speichernden Informationen
Nachteile der Contructive Solid Geometry:
Topologie nicht optimal (Schnittkanten bei der Verschmelzung von Objekten)
Eingeschränkter Formenschatz
Objekte werden nicht explizit repräsentiert
Texturen können keinen Flächen zugeordnet werden
Zur Visualisierung müssen erst die Oberflächen ermittelt werden
Abbildung 2.3: Zwei verschiedene CSG-Bäume zeigen das gleiche Gebäude aus
Abbildung 2.2 ( ∪ = Vereinigungsmenge)
2.3 Umsetzung von 3D-Stadtmodellen
3D-Stadtmodelle besitzen sehr viele Einsatzgebiete. Aber nicht jedes Modell ist für alle Anwendungen geeignet.
Einige Beispiele:
Zur Visualisierung eines neuen Bauvorhabens erstellt man ein 3D-Modell der Umgebung einschließlich des geplanten Neubaus. Entscheidungsträger können sich dann anhand einer virtuellen Tour durch das 3D-Modell vorab ein Bild davon machen, wie der geplante Eingriff später aussehen wird, ohne in der Realität auch nur ein Stein zu bewegen.
Ein Mobilfunkunternehmen möchte die Standorte seiner Sendemasten genau bestimmen. Da
sich die Funksignale in alle Richtungen ausbreiten, muss er wissen, wie hoch die Gebäude in
der Umgebung der Sendemasten sind, um Absorptionen und Reflexionen der Signale genau
bestimmen zu können.
2.3. UMSETZUNG VON 3D-STADTMODELLEN
13
Für die richtige Bemessung von Regenwasserabfluss muss der Stadt oder der Kommune ein
3D-Modell zur Verfügung stehen, welches Gebäude in einem höheren Detaillierungsgrad,
also insbesondere auch mit Dachformen und –überständen, beinhaltet.
Diese drei genannten Anwendungen besitzen vollkommen unterschiedliche Genauigkeitsanforderungen. Im Fall der virtuellen Tour durch die Stadt müssen hochauflösende Texturen
vorhanden sein, die Genauigkeit der Objekte sollte im Dezimeterbereich liegen, was also terrestrische Meßmethoden voraussetzt. Bei einem solchen Modell sind nur wenige Arbeitsschritte automatisiert.
Für den Mobilfunkanbieter zählt nicht die Visualisierung, er muss in dem Modell rechnen
können. Seine Daten umfassen Millionen Häuser und Dutzende Städte. Genauigkeitsanforderungen im Meterbereich ermöglichen die Modellierung der Gebäude mittels photogrammetrischer Auswerteverfahren. Der Grad der Automatisierung ist hier sehr groß. Die Stadt oder
Kommune erhält ihre Daten auf ähnliche Weise, allerdings ist die Datengewinnung hier etwas
aufwändiger. Die Häuser werden ebenfalls unter Zuhilfenahme photogrammetrischer Auswerteverfahren abgeleitet. Die hier erforderlichen höheren Genauigkeiten können aber durchaus
noch eingehalten werden. Das Besondere ist hier jedoch der Verschnitt der photogrammetrisch ermittelten Häuser mit den Daten der Automatisierten Liegenschaftskarte (ALK). Aus
der Differenz zwischen dem Grundriss des Hauses aus den ALK-Daten und dem Umriss des
photogrammetrisch abgeleiteten Hauses können Dachüberstände ermittelt werden.
2.3.1 3D vector maps
Alle Ansätze, 3D-Stadtmodelle zu entwickeln und diese in Datenbankschemata umzusetzen,
basieren auf dem Ansatz der Boundary Representation. Sie alle haben ein Modell gemein, in
dem Objekte durch Punkte, Kanten und Flächen dargestellt werden. Der erste Ansatz von Molenaar [Mol92], [Rik94] liegt bereits über ein Jahrzehnt zurück. Er führt neben NODE, ARC
und FACE ein „Zwischen-Element“ ein, um m:n Relationen zu vermeiden. Im zweidimensionalen kann eine Kante nur Teil von maximal zwei Flächen sein, im dreidimensionalen kann
eine Fläche aber um eine Kante rotieren, so dass m Kanten in n Flächen vorkommen können.
Das Zwischen-Element EDGE ist geometrisch gesehen wieder ein ARC, allerdings kommt eine
EDGE immer nur in einem FACE vor und besitzt lediglich einen Verweis auf einen existierenden ARC und zusätzlich die Umlaufrichtung, welche der ARC im FACE besitzt (Abbildung
2.4).
Durch dieses Festlegen der Umlaufrichtung kann mit der „3-Fingerregel der rechten Hand“
die Ober- und Unterseite einer Fläche bestimmt werden. Das Zwischen-Element erfordert
Restriktionen, wie z.B. dass Flächen sich nicht schneiden dürfen oder dass sich Flächen nur
an Ihren Rändern berühren dürfen. Diese Restriktionen gelten aber prinzipiell in allen Flächenbegrenzungs-Modellen und stellen somit keinen Nachteil dar.
14
KAPITEL 2 – 3D-REPRÄSENTATION UND DATENBANKASPEKTE
Abbildung 2.4: Richtung von EDGE und ARC [Mol92]
POINTOBJ
-PID
-PCLASS
-NID
LINEOBJ
SURFACE
-LID
-LCLASS
-BID
-BCLASS
NODEONF
BODYOBJ
-BID
-BCLASS
ARCPOFL
-NID
-NISONF
-ARCID
-APARTOFL
ARCONF
-ARCID
-AISONF
NODEINB
ARCINB
-NID
-NISINB
NODE
-NID
-XC
-YC
-ZC
-ARCID
-AISNINB
ARC
EDGE
-ARCID
-ARCBEG
-ARCEND
-FID
-ENOSEQ
-ARCID
-FORBACK
FACE
-FID
-FPARTOFS
-BIDLEFT
-BIDRIGHT
-TEXTUREREF
Abbildung 2.5: Formal data structure (FDS) for 3D vector maps [Mol92]
In Abbildung 2.5 wird deutlich, dass ein FACE zu zwei verschiedenen BODIES gehören
kann, in der Abbildung dargestellt durch die Beziehung BIDLEFT und BIDRIGHT. Wenn
ein FACE nur zu einem BODY gehört, haben BIDLEFT und BIDRIGHT den gleichen Wert.
Damit eine Fläche auch einzeln im Raum sein kann, ohne zu einem Körper zu gehören, wird
2.3. UMSETZUNG VON 3D-STADTMODELLEN
15
der Raum der Vollständigkeit halber ebenfalls als BODY betrachtet. In diesem Fall wäre FACE
dann auch nicht „part of“ einer SURFACE, die ja die Oberfläche eines Körpers im Sinne der
Boundary Representation darstellt. Im Gegensatz zur Boundary Representation werden Flächen, die im Innern eines Körpers liegen, in diesem Modell nicht ausgeschlossen. Die Darstellung ist somit nicht mehr eindeutig.
Für dieses Modell stellt Molenaar zwölf Konventionen auf, die im Prinzip auf alle anderen
3D-Modelle übertragbar sind, wie auch auf das Modell, welches in Kapitel 3 vorgestellt wird.
1. Jedes elementare Objekt sollte zu einer eigenen Klasse gehören. Das Klassensystem
sollte vollständig und ausschließlich sein.
2. Ein elementares Objekt einer Klasse sollte von nur einem Geometrie-Typ sein.
3. Bei der Analyse eines 3D-Modells als Graph sollten alle geometriebeschreibenden
Punkte als Knoten des Graphs behandelt werden.
4. Kanten werden geometrisch als gerade Linien dargestellt.
5. Jedes Knotenpaar kann nur durch eine Kante mit einander verbunden werden. Sie dürfen zusätzlich aber über eine Kette von Kanten mit einander verbunden sein.
6. Zwei Kanten dürfen sich nicht schneiden. Falls das doch der Fall sein sollte, müssen
sie durch vier Kanten, die sich in einem neuen Punkt schneiden, ersetzt werden.
7. Flächen sollen planar sein (In einer Ebene liegen).
8. Flächen können topologisch nur durch ihre Kanten zu einander in Beziehung gesetzt
werden.
9. Kanten einer Fläche müssen eine eindeutige Orientierung besitzen, um links, rechts,
oben und unten auf einer Fläche bestimmen zu können.
10. Eine Kante kann eine Fläche nur über einen Knoten berühren oder durchstoßen.
11.
-
Ein Knoten repräsentiert höchstens ein Punkt-Objekt
Eine Kante repräsentiert höchstens ein Linien-Objekt
Eine Fläche besitzt höchstens einen Körper auf der Oberseite
Eine Fläche besitzt höchstens einen Körper auf der Unterseite
12.
-
-
Ein Punkt-Objekt wird von einem Knoten repräsentiert
Ein Linien-Objekt wird durch eine Kette von Bögen dargestellt und besitzt einen Anfangs-Knoten, einen End-Knoten, keine Schleifen und keine Äste
Ein Oberflächen-Element darf höchstens einen äußeren Kantenring besitzen
und mehrere Innenringe, die jedoch nicht in einander verschachtelt sein dürfen
16
KAPITEL 2 – 3D-REPRÄSENTATION UND DATENBANKASPEKTE
2.3.2 SOMAS
An der ETH Zürich wird derzeit ein 3D Vektor-GIS Prototyp namens SOMAS (Solid Object
Management System) [Pfu02] entwickelt. Der Schwerpunkt dieses Projekts liegt in der Entwicklung eines geeigneten geometrischen und thematischen Datenmodells mit dem 3D und
4D Analysefunktionen zusammen mit einem optimalen Datenmanagement (Speicherung und
Zugriff) zur Verfügung stehen.
Abbildung 2.6: Relationales Datenmodell von SOMAS [Pfu02b]
Die Daten werden bei SOMAS ebenfalls in einer relationalen Datenbank (Oracle 8i) gespeichert, über ein Interface können 3D-Daten angezeigt und abgefragt werden. Die Modellierung
(Abbildung 2.6) ist im Gegensatz zu Molenaar etwas allgemeiner und speziell auf die Repräsentation von 3D-Stadtmodellen ausgerichtet. Vier Klassen, Point_Entity, Line_Entity, Polygon_Entity und Solid_Entity stellen die vier Grundelemente
dar. Direkt abgeleitet aus diesen Klassen werden die Objekte Vertex, Edge, Face und
Solid. An dieser Stelle sei nur kurz erwähnt, dass trotz der Verwendung der Begriffe Klassen und Objekte, die Daten lediglich in relationalen Tabellen abgelegt sind. Für jede dieser
Klassen von Grundelementen existiert eine Tabelle, in der alle Elemente seines Typs gespeichert sind. Die Attribute sind somit Spaltenelemente. M:n Beziehungen zwischen den Grundelementen werden mit weiteren Tabellen realisiert, in deren Spalten die ID’s von zwei in Beziehung zu einander stehenden Objekten gespeichert werden (Siehe hierzu Abschnitt 2.5 Da-
2.3. UMSETZUNG VON 3D-STADTMODELLEN
17
tenbanken). Die Tabelle Loop stellt den Zusammenhang zwischen Edge und Face her. Ein
Loop besteht aus n Edge’s und ein Face hat genau einen Loop als Außenring sowie 0 bis
n Loop’s als Innenringe.
Dem Benutzer stehen dann 3D-Algorithmen zur Verfügung, die auf die Koordinaten aus der
Tabelle Vertex zugreifen können.
2.4 Virtual Reality Modeling Language (VRML)
Die Beschreibungssprache für virtuelle 3D Welten VRML existiert seit Dezember 1995 in der
Version 1.0 und seit März 1998 in der Version 2.0. Basierend auf XML-Technologie wird in
naher Zukunft Extensible 3D (X3D) der abwärtskompatible Nachfolger von VRML sein.
VRML ist eine Szenen beschreibende Sprache (SDL) und besitzt einen objektorientierten Ansatz, um die Konstellation von 3D-Objekten in einer Szene zu beschreiben. Dabei können 3DObjekte wie bei der CSG-Darstellung aus Primitiven bestehen, genauso ist aber auch die Darstellung der Objekte durch die Boundary Representation möglich. Eine VRML-Datei besteht
aus einer Liste von Knoten, nicht zu verwechseln mit den Knoten der 3D-Modellierung. Diese
Knoten lassen sich in drei grundlegende Kategorien unterteilen: Gruppenknoten, Kindknoten
und Objektknoten (Abbildung 2.7). Wie der Name bereits sagt, fassen Gruppenknoten andere
Knoten zusammen, wobei letztere wiederum aus beiden Kategorien stammen können. Durch
die Kombination verschiedener Knoten in einer Datei entsteht eine hierarchische Struktur, die
als sogenannter Scene Graph bezeichnet wird. Eine VRML-Datei enthält somit genau einen
Scene Graph.
Abbildung 2.7: Hierarchische Objektstruktur in VRML-Dokumenten [Klo98]
Das Zusammenspiel dieser vielen Knoten gestaltet sich derart, dass auf der höchsten Ebene
die Gruppenknoten stehen, die alle untergeordneten (Kind)-Knoten manipulieren. Innerhalb
der einzelnen Kindknoten befinden sich spezifische Objektknoten (sie dienen der Erzeugung
und Gestaltung der geometrischen Objekte), die ausschließlich in der definierten Umgebung
18
KAPITEL 2 – 3D-REPRÄSENTATION UND DATENBANKASPEKTE
vorkommen und wiederum von dieser beeinflusst werden. Veränderungen im Gruppenknoten
pflanzen sich somit bis zu den Objektknoten fort.
Das Beispiel in Abbildung 2.8 zeigt einen Gruppenknoten mit zwei Kindknoten. Der erste
Kindknoten ist ein Text, während der zweite eine Fläche darstellt, deren Geometrie durch
einen Koordinatensatz und einem dazugehörigen Index repräsentiert wird. Die Reihenfolge
der Koordinatentrippel ist nicht von Bedeutung, die Reihenfolge der Indizes aber sehr wohl.
DEF Objekt1 Group {
children [
Transform {
translation 733.79 996.27 122.8
rotation 0 0 0 0
children [
Shape {
geometry Text {
S
string ["Objekt 1"]
}
}
]
}
DEF Flaeche1 Shape {
appearance Appearance {
material Material {diffuseColor 0.5 1 0.5}
}
geometry IndexedFaceSet {
solid FALSE
convex TRUE
coord Coordinate { point [
733.79 996.27 122.8, 743.93 972.67 122.7, 743.93
972.67 133.1,
733.79 996.27 133.1
]
}
coordIndex[0, 1, 2, 3, -1
]
}
}
]
}
Abbildung 2.8: Beispiel für VRML-Szenegraph mit Gruppen- und Kindknoten. Aus
der Datenbank per VRML-Export generiert.
2.4. VIRTUAL REALITY MODELING LANGUAGE
19
Erläuterung des Beispiels:
Typen werden groß, Eigenschaften und Attribute klein geschrieben.
Mit DEF gibt man den Knoten Namen.
Transform ist ein spezieller Gruppenknoten, so dass sich die translation und
rotation nur auf den darunter liegenden Kindknoten (mit dem Text) auswirkt.
Shape ist ein Kindknoten, seine geometrie ist vom Typ Text und dieser enthält
den String „Objekt1“
Der Kindknoten Fläche1 vom Typ Shape besitzt zwei Eigenschaften,
appearance und geometry.
appearance besitzt u.a. die Eigenschaft material, die wiederum das Attribut
diffusecolor besitzt.
Die Eigenschaft geometry des Kindknoten ist vom Typ Indexfaceset. Dieser
Typ entspricht einem planaren Polygon auf das man direkt Texturen aufbringen kann.
Die Eigenschaften solid und convex sind für die Visualisierung notwendig,
Coordinate und CoordIndex beschreiben das Polygon.
Zu CoordIndex:
Die Reihenfolge der Koordinaten in Coordinate ist unbedeutend. Das Polygon muss jedoch aus einem geschlossen Linienzug bestehen und seine Knotenpunkte rechts herum laufen,
um die beiden Seiten einer Fläche eindeutig zuordnen zu können (vgl. Abschnitt 2.3.1). Um
dies zu erreichen, werden in der Zeile mit den Koordinatenindizes CoordIndex die Punkte
in der rechts umher laufenden Reihenfolge eingetragen. Dabei ist 0 das Koordinatentrippel an
der Stelle 0 in der Koordinatenzeile, 1, 2 und 3 analog die Punkte an den Stellen 1, 2 und 3.
Mit –1 wird das Ende des Polygons markiert und automatisch geschlossen. Andere Programme benötigen hier nochmals die erste Koordinate.
2.5 Datenbanken
Eine Datenbank ist nur eine Sammlung von Daten. Ein Datenbankmanagementsystem
(DBMS) wird auch gerne als Datenbank bezeichnet, ist aber in Wirklichkeit ein Programmsystem, dass eine Datenbank für mehrere Nutzer zur gleichzeitigen Benutzung so zur Verfügung stellt, dass kein Nutzer den Datenbestand schädigen kann [Ull88] .
DBMS können nach ihrem typischen Datenmodell unterschieden werden:
Hierarchische Datenbanken
Relationale Datenbanken
Objektorientierte Datenbanken
Graphische Datenbanken
Das von in dieser Arbeit verwendete DBMS Oracle (9.2i) ist eine Relationale Datenbank, die
darüber hinaus über Funktionen einer objektorientierten Datenbank verfügt. Oracle nennt sein
DBMS daher objekt-relational.
20
KAPITEL 2 – 3D-REPRÄSENTATION UND DATENBANKASPEKTE
2.5.1 Relationales Schema
In einem relationalen Datenbankschema - der Großteil der heute eingesetzten DBMS sind
immer noch ausschließlich relationale Datenbanken - werden die Informationen in Tabellen
abgelegt. Die Spalten einer Tabelle werden durch einen Datentyp festgelegt und in jeder Zeile
steht ein neuer Eintrag. Sinnvoller Weise wählt man als erste Spalte einen unified identifier
(UID), genannt Primärschlüssel um alle Spalten eindeutig von einander unterscheiden zu
können.
Bei dem Beispiel aus Abbildung 2.6 sieht die Tabellen etwa so aus:
Tabelle Vertex:
Vertex_ID
X_Coord
1
10,002
2
12,000
3
3,459
…
Y_Coord
9,765
13,004
4,110
Tabelle Edge:
Edge_ID
First_Vertex
201
1
202
2
203
3
…
Last_Vertex
2
3
7
Tabelle Vertex_Edge:
Vertex_Edge_ID
Vertex_ID
1001
4
1002
5
1003
6
…
Z_Coord
0,000
5,553
10,421
Edge_ID
203
203
203
Prev_VE_ID
NULL
1001
1002
Next_VE_ID
1002
1003
1004
Der Primärschlüssel (PK) dient zur eindeutigen Identifizierung einer Zeile der gleichen Tabelle. Demnach ist es nicht erlaubt, den gleichen Wert in einer Tabelle mehrfach zu verwenden.
Allerdings ist es möglich, diesen bei mehreren unterschiedlichen Tabellen einzusetzen. Die
unterschiedlichen Werte für den PK sollen das Beispiel übersichtlicher halten.
Die PK’s der Tabelle Vertex erscheinen in der Tabelle Edge als Fremdschlüssel (FK). Man
speichert in der Tabelle Edge also nicht nochmals die Koordinaten der betreffenden Punkte
sondern zeigt nur auf die Tabelle, wo die Informationen liegen. Diese Vermeidung von Redundanzen ermöglicht zum einen eine effizientere Datenspeicherung, aber vor allem müssen
bei der Änderung der Koordinaten nur die Werte in einer einzigen Tabelle geändert werden.
2.5. DATENBANKEN
21
Die Tabelle Edge weist eine 1:n-Beziehung auf. Mehrere Edges, mit unterschiedlichen
Edge_ID’s könnten die gleichen Fremdschlüssel in den Spalten First_Vertex und
Last_Vertex besitzen. Ein Vertex könnte also in mehreren Edges vorkommen. Damit eine
Edge aber aus mehreren, beliebig vielen Vertices bestehen kann, braucht man die Tabelle
Vertex_Edge. Hier wird die m:n-Beziehung realisiert. Durch die entsprechenden Einträge
in der Tabelle Vertex_edge besitzt die Edge 203 die Vertices 3, 4, 5, 6, 7. Die Reihenfolge
der Vertices 4, 5 und 6 ergeben sich aus den Spalten Prev_VE_ID und Next_VE_ID, 3
und 7 sind Anfangs- und Endpunkt, definiert in der Tabelle Edge. Der Wert NULL, der in der
Tabelle Vertex_Edge auftaucht, bedeutet nur, dass an dieser Stelle keine Information steht.
Dieses System konsequent weitergeführt ergibt letztendlich das komplette relationale Datenbank-Schema.
2.5.2 Objekt-relationales Schema
Oracle nennt sein DBMS wie in 2.3 bereits erwähnt objekt-relational. Zu den Funktionen einer relationalen Tabelle kommen also noch objektorientierte Funktionen hinzu.
Objektorientierung ist seit Anfang der 90er Jahre zu einem großen Schlagwort in der Informatik geworden.
„I have a cat named Trash. In the current political climate, it would seem that if I were trying
to sell him ( at least to a computer scientist), I would not stress that he is gentle to humans and
is self sufficient, living mostly on field mice. Rather, I would argue that he is object-oriented.”
R. King, 1989, [Kin89]
Bei der Objektorientierung sind drei Stichworte auch für die Welt der Datenbanken von großer Bedeutung: Abstraktion, Generalisierung und Aggregation.
Hinter der Abstraktion verbirgt sich die Trennung zwischen Konzept und Umsetzung. In der
Realität ist diese Unterscheidung sehr bedeutsam. Wer weiß, wie man einen Lichtschalter
betätigt, ist auch in der Lage andere Schalter zu betätigen. Wer einen Führerschein hat, kann
ein Auto fahren, ohne dessen kompliziertes Innenleben im Detail verstanden zu haben. Diese
Unterscheidung findet sich in den Begriffen Objekt und Klasse wieder. Ein Objekt ist tatsächlich existierend, die Klasse dagegen beschreibt dieses oder mehrere Objekte. Genauer gesagt,
die Klasse beschreibt, wie das Objekt zu bedienen ist, welche Eigenschaften das Objekt besitzt und wie das Objekt hergestellt wird.
Bei der Generalisierung und Spezialisierung wird durch Vererbung eine „is-a“-Beziehung
ausgedrückt. Eine Klasse wird dabei nicht völlig neu definiert, sondern aus einer Superklasse
22
KAPITEL 2 – 3D-REPRÄSENTATION UND DATENBANKASPEKTE
(Vaterklasse) abgeleitet. Die abgeleitete Klasse wird auch Subklasse genannt. Ein Beispiel
dafür soll Abbildung 2.9 geben.
Abbildung 2.9: Beispiel einer Vererbung, „is-a“-Beziehung [OGCa]
Unter Aggregation versteht man den allgemeinen Fall des einfachen Aufnehmens anderer
Objekte, man spricht hier von einer „part-of“-Beziehung. Diese Beziehung ist jedoch nicht
wie „is-a“ essentiell für die Existenz des aufnehmenden Objektes. Die explizite Anwendung
der (rekursiven) Aggregation wird in den Abschnitten 3.1.2 und 3.2.2 noch genauer erläutert.
Oracle stellt drei Brücken [McC02] zur Verfügung, um das Beste aus beiden Welten nutzen
zu können:
Eine Objektansicht. Eine Objektansicht bildet relationale Tabellen auf eine Objekttabelle ab.
Ähnlich wie relationale Ansichten enthält eine Objektansicht selbst keine eigenen Daten, sondern stellt nur eine bestimmte Methode dar, die zu Grunde liegenden Tabellen zu betrachten.
Mit Hilfe der Objektansicht können vorhandene relationale Tabellen auf eine objektorientierte
Art und Weise angezeigt werden.
Eine Objekttabelle. Eine Objekttabelle ist eine Tabelle, deren Zeilen durch einen Objekttyp
und nicht durch explizite Spalten definiert werden. Die Elemente innerhalb des Objekttyps
definieren, welche Daten in der Objekttabelle gespeichert werden.
Zusätzlich kann eine Objekttabelle Objektmethoden enthalten, mit denen die Daten manipuliert werden können und die mit der Tabellendefinition gespeichert werden. Anders ausgedrückt: In Objekttabellen sind sowohl Daten als auch Anwendungsprozeduren in einem Ob-
2.5. DATENBANKEN
23
jekt zusammengefasst. Objekttabellen können auch über Primärschlüssel und Indizes (schnelle Zugriffspfade) verfügen.
Eine Objekttabelle, die Objektspalten und relationale Spalten verbindet. Eine relationale
Tabelle mit einer oder mehreren Spalten, deren Datentyp durch einen Objekttyp definiert
wird. Eine Objektspalte ist eine Spalte mit einem Objekttyp-Attribut als Datentyp.
Bei dem in dieser Arbeit entwickelten Datenbank-Schema werden ausschließlich Objekttabellen verwendet.
Die Attribute eines Objektes können folgendermaßen definiert werden:
Eine normale Spalte. Jeder Datentyp kann hier eingesetzt werden. Standard-Datentypen sind
u.a.: Number (=Integer), Varchar (=String), Date, Blob (= Binary Large Object) oder Float.
Eine Liste. In Bezug auf Objekte wird eine Liste als Array bezeichnet. Die Größe dieses Array wird festgelegt und kann nicht nachträglich geändert werden.
Eine eingebettete Tabelle. Diese Art von Attribut wird nested table genannt und es handelt
sich dabei um eine Datentabelle innerhalb eines Objektes, deren Größe variabel ist. Mit nested
tables können m:n-Relationen hergestellt werden. Mehr dazu in Abschnitt 2.5.3.
Ein anderes Objekt. Das Objekt, das vorher (zumindest namentlich, nicht inhaltlich) definiert sein muss, wird wie eine weitere Spalte behandelt. Anders als eine normale Spalte hat es
aber seine eigene Liste mit Attributen, die als normalen Spalten, Array, eingebetteten Tabellen oder weiteren Objekten bestehen kann. Der Vorteil besteht z.B. darin, dass dieses Objekt
in vielen anderen Objekten wiederverwendet werden kann.
Objektreferenz
Die Objektreferenz oder REF ist ein spezieller Datentyp, der für Objekttabellen geschaffen
wurde. Sie funktioniert wie ein Fremdschlüssel, sie definiert die Beziehung zwischen zwei
Objekten. Im Gegensatz zur Fremdschlüsselspalte einer relationalen Tabelle wird hier kein
unified identifier (UID) vom Nutzer eingegeben, sondern von der Datenbank festgelegt. Bei
einer Abfrage hat das den Vorteil, keine UID’s zu verwenden, sondern mittels des Befehls
deref die Beziehung zwischen zwei Objekten wieder herzustellen. (Siehe hierzu auch Abschnitt 2.5.4)
Im Application Developer’s Guide – Object-Relational Features [Oraa] findet man eine detailierte Beschreibung der objekt-relationalen Fähigkeiten von Oracle. Darüber hinaus befindet
sich dort in Abschnitt 9 ein Beispiel für die Entwicklung einer objekt-relationalen Datenbank.
24
KAPITEL 2 – 3D-REPRÄSENTATION UND DATENBANKASPEKTE
2.5.3 Nested Tables
Im relationalen Schema wurden m:n-Beziehungen durch eine zusätzliche Tabelle realisiert.
Im objekt-relationalen Schema passiert prinzipiell nichts anderes, allerdings hat der Benutzer
hier keinen direkten Zugriff auf diese Tabelle. Der Inhalt einer solchen nested table wird in
ein Objekt eingebettet. Bei der Anzeige eines Objekts werden dem Nutzer nur die Zeilen aufgelistet, die auch zu diesem Objekt gehören. Für die Zeile A werden also die Elemente A11,
A12 und A13 aufgelistet (Abbildung 2.10). Dieses Verfahren vereinfacht die Handhabung
und setzt den Gedanken der Objektorientierung konsequent fort. Eine von der Datenbank generierte 16 byte lange NESTED_TABLE_ID setzt die übergeordnete Zeile aus einem Objekt
mit den Zeilen des korrespondierenden nested tables in Verbindung.
Abbildung 2.10: Schematische Darstellung eines nested tables [Oraa]
Besitzt die nested table einen Primärschlüssel, wird die Tabelle als index-organisierte Tabelle
(IOT) behandelt. Die Datenbank sortiert die Zeilen nach ihren übergeordneten Zeilen, um die
Effizienz von Zugriffen zu steigern. Wenn man darüber hinaus bei der Erstellung des nested
tables den Befehl COMPRESS angibt, wird der Schlüssel zur übergeordneten Tabelle nur
einmal gespeichert (Siehe Abbildung 2.11). Die SQL-Statemens, die einen nested table erstellen, werden in Abschnitt 3.2.3 nochmals aufgegriffen.
Zum Zeitpunkt dieser Arbeit sind nested tables noch nicht durch die Abfrage-Sprache SQL
(Abschnitt 2.5.4) standardisiert. Dies soll sich für die kommende Version von SQL ändern
und es ist davon auszugehen, dass die Spezifikationen sehr nahe an der Umsetzung durch
2.5. DATENBANKEN
25
Oracle sein werden. Spätestens dann ist das Datenmodell 1:1 auf andere objekt-relationale
DBMS umsetzbar.
Abbildung 2.11: nested table, komprimiert [Oraa]
2.5.4 Structured Query Language (SQL)
Um Datenmanipulationen bei relationalen Datenbanken durchzuführen, wird zumeist SQL
(Structured Query Language = Strukturierte Abfrage Sprache) verwendet. SQL ist eine
nichtprozedurale, relationenalgebraische Sprache. Im Gegensatz zu einer prozeduralen Sprache muss SQL nicht mitgeteilt werden, wie ein Problem zu lösen ist, sondern es muss nur
beschrieben werden, welches Problem zu lösen ist.
Die Grundform einer SQL-Abfrage besteht aus fünf Klauseln [McC02]:
SELECT
Hier gibt man die Liste der Spalten an, die man sehen möchte. Es ist auch möglich Spalten mehrerer Tabellen auszuwählen.
FROM
Hier gibt man die Namen der Tabellen an.
WHERE
(Optional) Bedingungen wie Vergleiche, Begrenzungen, Beziehungen zwischen Tabellen usw. können hier angegeben werden. Mehrere WHEREKlauseln werden mit einem AND verbunden. Ohne die WHERE-Klausel werden immer alle Zeilen gewählt.
GROUP BY (Optional) Wenn Daten zusammengefasst werden sollen, kann man das mit
dieser Klausel tun.
ORDER BY (Optional) Für die Ausgabe werden die Daten hier anhand der Reihenfolge, wie
die Spalten hier angegeben werden, sortiert.
26
KAPITEL 2 – 3D-REPRÄSENTATION UND DATENBANKASPEKTE
Einige Beispielabfragen:
SELECT * FROM Knoten_objtab WHERE ID_Knoten <5;
ID_KNOTEN
---------1
2
3
4
X
---------3445743,93
3445733,79
3445718,64
3445720,76
Y
Z
---------- ---------5539972,67
122,7
5539996,27
122,8
5539989,87
122,8
5539985,06
122,8
SELECT * FROM Knoten_objtab k WHERE ID_Knoten <5 AND z >122.7
ORDER BY y;
ID_KNOTEN
---------4
3
2
X
---------3445720,76
3445718,64
3445733,79
Y
Z
---------- ---------5539985,06
122,8
5539989,87
122,8
5539996,27
122,8
Mit der Objektreferenz aus Abschnitt 2.5.2 kann man nun ganz einfach die Anfangsknoten
von mehreren Kanten ausgeben, ohne dabei in der WHERE-Klausel Bedingungen über die
Zugehörigkeit von Knoten zu Kanten anzugeben, wie es in der relationalen Form der Fall wäre:
SELECT
ID_Kante,
deref(Anfang_ref).id_knoten,
deref(Anfang_ref).x,
deref(Anfang_ref).y,
deref(Anfang_ref).z
FROM Kante_objtab
WHERE ID_Kante <5;
ID_KANTE ID_KNOTEN
X
Y
Z
-------- --------- ----------- ----------- -----1
2 3445733,79 5539996,27 122,8
2
1 3445743,93 5539972,67 122,7
3
11 3445743,93 5539972,67 133,1
4
3 3445718,64 5539989,87 122,8
2.5. DATENBANKEN
27
In der relationalen Form gäbe es jetzt analog zu Abbildung 2.6 zusätzlich eine Tabelle Kante_Knoten, aus der die m:n-Beziehungen ermittelt werden müssten. Die SQL-Abfrage sähe in
etwa so aus:
SELECT
KA.ID_Kante,
KO.x,
KO.y,
KO.z
FROM Kante_objtab KA, Kante_objtab KO, Kante_Knoten KK
WHERE
KA.ID_Kante <5 AND
KK.ID_Kante = KA.ID_Kante;
In den Abbildungen 2.12 und 2.13 finden sich zwei SQL-Abfragen, die alle Koordinaten eines
Gebäudes wiedergeben. In der Abfrage aus Abbildung 2.12 werden für jede Zeile in volumen_objtab sechs in einander verschachtelte Objekt-Referenzen aufgerufen. Mit Hilfe
eines „Joins“ (Abbildung 2.13, vorletzte Zeile), wie er auch in der obigen Abfrage in der
WHERE-Klausel zu finden ist, konnte die gleiche Abfrage wie in Abbildung 2.13 erheblich
beschleunigt werden.
SELECT
v.id_volumen,
m.masche_ref.aussen_ref.id_ring,
h.kante_ref.anfang_ref.id_knoten,
h.kante_ref.anfang_ref.x,
h.kante_ref.anfang_ref.y,
h.kante_ref.anfang_ref.z,
h.kante_ref.ende_ref.id_knoten,
h.kante_ref.ende_ref.x,
h.kante_ref.ende_ref.y,
h.kante_ref.ende_ref.z,
h.sortvar
FROM
volumen_objtab v,
TABLE (v.maschenliste_ntab) m,
TABLE(m.masche_ref.aussen_ref.kantenliste_ntab) h
WHERE
id_volumen = 1
ORDER BY m.masche_ref.aussen_ref.id_ring, h.sortvar;
Abbildung 2.12: SQL-Abfrage eines Gebäudes ohne JOIN
28
KAPITEL 2 – 3D-REPRÄSENTATION UND DATENBANKASPEKTE
SELECT
v.id_volumen,
m.masche_ref.aussen_ref.id_ring,
l.kante_ref.anfang_ref.id_knoten,
l.kante_ref.anfang_ref.x,
l.kante_ref.anfang_ref.y,
l.kante_ref.anfang_ref.z,
l.kante_ref.ende_ref.id_knoten,
l.kante_ref.ende_ref.x,
l.kante_ref.ende_ref.y,
l.kante_ref.ende_ref.z,
l.sortvar
FROM
ring_objtab r,
volumen_objtab v,
table(r.kantenliste_ntab) l,
table(v.maschenliste_ntab) m
WHERE
v.id_volumen = 1 and
m.masche_ref.aussen_ref.id_ring = r.id_ring
ORDER BY r.id_ring, l.sortvar;
Abbildung 2.13: SQL-Abfrage eines Gebäudes mit JOIN
Wie bereits in Abschnitt 2.5.3 erwähnt, werden nested tables in anderen Tabellen gespeichert
als die Objekte. Bei der SQL-Abfrage in Abbildung 2.13 wird dies über den Befehl TABLE
realisiert, der die eingebettete Tabelle aus dem jeweiligen Objekt darstellt.
Vor der Datenabfrage muss man natürlich Tabellen erstellen und diese auch mit Daten füllen.
Mit dem Befehl
CREATE OR REPLACE TYPE Knoten_objtyp;
wird ein Objekt erstellt. Es ist möglich, nur den Tabellennamen ohne seine Spalten zu definieren. Das ist ggf. nötig, um Vererbungen oder Referenzierungen durchzuführen.
CREATE OR REPLACE TYPE Knoten_objtyp AS OBJECT
(ID_Knoten
NUMBER,
x
NUMBER,
y
NUMBER,
z
NUMBER) NOT FINAL;
2.5. DATENBANKEN
29
Erst hier wird festgelegt, dass es sich bei der angelegten Tabelle um eine Objekt-Tabelle handelt. Mit dem Befehl NOT FINAL legt man fest, dass dem Objekt später Attribute oder Methoden hinzugefügt, entfernt oder geändert werden können.
CREATE TABLE Knoten_objtab OF Knoten_objtyp
(PRIMARY KEY (ID_Knoten))
OBJECT IDENTIFIER IS PRIMARY KEY;
Nachdem das Objekt erstellt wurde kann die Tabelle erzeugt werden. Erst hier wird ein Attribut als Primärschlüssel deklariert.
2.5.5 Java-Schnittstelle
Die Java Database Connection (JDBC) ist eine standardisierte Schnittstelle zwischen Java und
einer Datenbank, basierend auf der Abfrage-Sprache SQL. Mit Hilfe von JDBC werden also
SQL-Kommandos zwischen Java und der Datenbank ausgetauscht.
Für die Installation empfiehlt sich die Lektüre des Oracle JDBC Developers Guide and Reference [Orab].
Die Verbindung zwischen Java und der Oracle-Datenbank ist mit zwei verschiedenen Treibern möglich, dem JDBC-Thin-Treiber und dem JDBC-OCI-Treiber.
Der Thin-Treiber wurde komplett in Java programmiert und ist somit plattformunabhängig,
auf der Client-Seite bedarf es keinerlei Oracle-Software. Ein Java-Applet in einem Browser
oder ein eigenständiges Java-Programm kann mit diesem Treiber über das TCP/IP-Protokoll
eine direkte Verbindung zur Datenbank aufbauen.
Der OCI-Treiber wurde für einen Oracle Client-Server Betrieb entwickelt, er setzt also auf
der Client-Seite eine Oracle-Client Installation voraus, wodurch der Treiber auf die von Oracle unterstützten Plattformen begrenzt ist. Dieser Treiber wurde in einer Kombination aus Java
und C geschrieben und setzt die JDBC-Aufrufe in sein eigenes OCI-Interface um. Die Kommunikation zum Oracle Datenbank-Server erfolgt dann über den Oracle Net Adapter, der
wiederum TCP/IP und IPX/SPX unterstützt.
Wie in Abbildung 2.14 zu sehen ist, bietet der OCI-Treiber mehr Funktionen und mehr Performance, die Arbeit mit ihm bedeutet jedoch deutlich mehr Aufwand als mit dem ThinTreiber. Letztendlich war das der Ausschlag dafür, den Thin-Treiber zu wählen.
30
KAPITEL 2 – 3D-REPRÄSENTATION UND DATENBANKASPEKTE
Abbildung 2.14: Vergleich der Oracle JDBC-Treiber [Orab]
Zum Aufbau einer Verbindung verwendet man in Java einen Connection String
String connect_string =
jdbc:oracle:thin:USER/PASSW@IPADRESS:1521:DBNAME";
Die IP-Adresse des Oracle-Servers kann als IP-Adresse oder DNS-Name eingetragen werden,
die Zahl 1521 ist der von der Oracle-Installation gewählte Standard-Port des JDBC-listeners.
Der Name der Datenbank muss unter DBNAME eingetragen werden.
In den folgenden Befehlen wird der JDBC-Treiber geladen, eine Verbindung aufgebaut und
ein SQL-Statement kreiert.
DriverManager.registerDriver (new oracle.jdbc.OracleDriver());
conn = DriverManager.getConnection (connect_string);
stmt = conn.createStatement ();
Dieses Statement nimmt dann den SQL-Befehl im Klartext auf, und sendet ihn an die Datenbank:
ResultSet rset = NULL;
rset = stmt.executeQuery ("SELECT 'Hello JDBC: ' || SYSDATE
FROM DUAL");
Die Antwort der Datenbank, das Resultset wird dann mit diesem Befehl ausgewertet:
while (rset.next ())
System.out.print(rset.getString (1) + "\n");
ResultSet und Verbindung müssen zum Schluss noch ordnungsgemäß geschlossen werden:
rset.close();
conn.close();
2.5. DATENBANKEN
31
Auf diese Weise können Befehle wie SELECT, Update oder Insert an die Datenbank
übermittelt werden. Um eine Tabelle mit vielen Daten zu füllen, müssten tausende InsertBefehle übertragen werden, die jeweils eine neue Zeile hinzufügen. Mit einem Prepared Statement (pstmt) kann diese Aufgabe wesentlich schneller gelöst werden:
for (i=0; i<max; i++)
{
DB.pstmt.setInt(1, Knoten_ID);
DB.pstmt.setDouble(2, x[i]);
DB.pstmt.setDouble(3, y[i]);
DB.pstmt.setDouble(4, z[i]);
DB.pstmt.addBatch();
}
Nachdem die For-Schleife beendet wurde, kann der Batch-Stapel mit einem Befehl an die
Datenbank übergeben werden:
DB.pstmt.executeBatch();
Die Technologien und Konzepte aus diesem Kapitel sollen die Grundlage für die Beschreibung der Entwicklung eines objekt-relationalen Datenmodells sein, welches im folgenden
vorgestellt wird.
Kapitel 3
Implementierung des Datenmodells
In Abschnitt 2.1 wurden bereits zwei Datenmodelle vorgestellt, die „3D Vector Maps“ von
Molenaar und SOMAS von Pfund. Dieses Kapitel wird in Abschnitt 3.1 das Modell „Regengeld“ (Abbildung 3.5) vorstellen und in Abschnitt 3.2 die Umsetzung dieses Modells in ein
objekt-relationales Datenmodell beschreiben. Abschnitt 3.3 erläutert die SQL-Anweisungen,
mit denen das objekt-relationale Modell erstellt wurde.
3.1 Modell „Regengeld“
Am Institut für Geoinformation und Kartographie der Universität Bonn wurde in einem Kooperationsprojekt mit dem Institut für Photogrammetrie für die Stadt Wuppertal ein geometrisch-topologisches 3D-Stadtmodell entwickelt [Bru02]. Das Datenmodell sollte den folgenden Anforderungen entsprechen:
Multifunktionale Nutzung
Neben der Visualisierung soll das Datenmodell insbesondere für raumbezogene und / oder
thematische Anfragen und Auswertungen geeignet sein. Es soll sich als Basismodell für die
Anbindung von Fachanwendungen eignen.
Berücksichtigung von ISO-Standards
Zur Gewährleistung von Interoperabilität werden die räumlichen Objekte entsprechend existierender ISO-Standards (ISO 19107: Spatial Schema) modelliert. Zwei wesentliche Entwurfsentscheidungen wurden dadurch impliziert:
1) Die Objektgeometrien werden durch eine geometrisch-topologische Modellierung repräsentiert.
2) Der ISO-Standard sieht zur Repräsentation von 3D-Volumenmodellen ausschließlich die
Randflächendarstellung (B-Rep) vor.
32
3.1. MODELL „REGENGELD“
33
Hierarchische Gliederung
In Anlehnung an die Modellierung von ALKIS soll das Modell hierarchisch in Ebenen gegliedert sein: In der unteren Ebene befindet sich das geometrisch-topologische Basismodell,
darüber die Aggregationsebene und oben die anwendungsbezogen Modellierung. Verbindungen zu ALKIS-Objekten sollen realisiert werden können.
Der Kern des Datenmodells wird durch die geometrisch-topologische Modellierung von 0-,
1-, 2- und 3-dimensionalen Primitiven gebildet. Sie bauen auf einander auf und realisieren ein
Knoten-, Kanten-, Flächen- und Volumenmodell.
3.1.1 Primitive
Knoten- und Kantenobjekte:
Nur die Knotenobjekte besitzen Koordinaten. Kantenobjekte sind Geraden, sie definieren sich
durch ihren Anfangs- und Endknoten und legen so ihre Geometrie implizit fest.
Flächenobjekte
Flächen werden durch die Angabe der Kanten des Umringpolygons beschrieben. Da Flächen
auch Löcher haben können, ist es nicht ausreichend, nur einen äußeren Flächenumring vorzusehen. Flächen werden deshalb durch Maschen repräsentiert, die genau einen äußeren Umring
und keinen, einen oder mehrere innere (Loch-)Umringe besitzen. Ein Umring ist dabei eine in
einer beliebigen Umlaufrichtung geordnete Menge von mindestens drei Kanten. Da nur ebene
Flächen repräsentiert werden sollen, gilt für alle Knoten des äußeren und der inneren Umringe
die Bedingung, dass sie in einer Ebene liegen müssen, also koplanar sind.
Volumengeometrie
Volumenkoerper
0..2
Orientierung
4..*
begrenzt_von
Flaechengeometrie
Masche
1..0
0..*
innerer
1
1
äußerer
Ring
0..2
3..*
{ordered}
besteht_aus
Liniengeometrie
Kante
Knoten
0..*
1
−x:Koordinate
Endknoten −y:Koordinate
0..*
1 −z:Koordinate
Startknoten
Abbildung 3.1: UML-Diagramm der geometrisch-topologische Modellierung eines
Volumenkörpers [Bru02]
Zur UML-Notation
Das UML-Diagramm stellt Klassen mit ihren Attributen dar, sowie die Assoziationen zwischen diesen Klassen [RJB99]. Die Assoziation benennt die Beziehungen zwischen den Klassen und gibt Multiplizitäten an. So kann die Klasse Knoten in 0 bis beliebig vielen
34
KAPITEL 3 – IMPLEMENTIERUNG DES DATENMODELLS
Klassen Kanten vorkommen, sowohl als Endknoten, als auch als Startknoten. Eine Kante besitzt aber immer genau einen Endknoten und einen Anfangsknoten. Analog dazu sind auch alle
anderen UML-Diagramme zu lesen, die sich auf das Modell Regengeld beziehen.
Modellierung
Das in Abbildung 3.1 dargestellte UML-Diagramm zeigt die Modellierung eines Volumenkörpers. Höherdimensionale Objekte setzen sich aus Primitiven der darunter liegenden Dimensionen zusammen, die aber auch Bestandteil mehrerer Objekte sein können. So besitzen
beispielsweise zwei benachbarte Flächen eine gemeinsame Kante, die nur einmal existiert,
aber von beiden Umringen aus referenziert wird. Dieses Vorgehen hat den Vorteil, dass die
redundante Speicherung von (Teil-) Geometrien vermieden wird. Gleichzeitig ist damit sichergestellt, dass sich berührende bzw. aneinandergrenzende Objekte einerseits nicht überlappen und andererseits keine dazwischenliegenden Klaffungen aufweisen.
Volumenobjekte
Die Randflächen eines Volumens müssen aus mindestens vier Flächen bestehen. Jede Fläche
wird durch eine orientierte Masche repräsentiert. Die Orientierung gibt dabei an, welche Seite
der Masche nach innen bzw. nach außen zeigt. Zur Festlegung einer eindeutigen Orientierung
wird angenommen, dass wenn man senkrecht auf eine Masche schaut und die Kanten des äußeren Rings in linker Umlaufrichtung sortiert sind, der Normalenvektor zum Betrachter zeigt.
Sollen Fenster in Wänden explizit repräsentiert werden, so können die Fenster zunächst als
Löcher in der Wandfläche dargestellt werden. Dazu werden zu der Wandmasche gemäß der
Fensterumrandungen innere Ringe hinzugefügt. Damit die Fläche insgesamt geschlossen
bleibt, wird jedes Fenster durch eine eigene Masche repräsentiert, deren äußerer Ring identisch mit dem entsprechenden inneren Ring der Wandfläche ist.
Materialeigenschaften
0..1
oben
Flaechengeometrie
Masche
0..1
unten
Phototextur
−Bitmap:Binaer
−Tranformationsmatrix:Matrix
einfarbiges Material
−RGB_Wert:(int , int , int )
Abbildung 3.2: Materialmodellierung für Flächen. Eine Masche kann auf der Oberund Unterseite als Material eine Textur oder ein einfarbiges Material
aufweisen. [Bru02]
3.1. MODELL „REGENGELD“
35
Material
Um die Erscheinungsform von Flächen angeben zu können, kann grundsätzlich jeder Flächenseite eine eigene Materialeigenschaft zugewiesen werden. Vorder- und Rückseite einer
Masche können somit unterschiedliche Eigenschaften erhalten. Die Klasse Materialeigenschaften ist eine abstrakte Klasse und wird zunächst in die zwei Unterklassen einfarbiges Material und Phototextur spezialisiert. Die hier verwendete UML-Notation (Pfeil) bedeutet in
diesem Fall eine Generalisierung der Klasse Phototextur zur Klasse Materialeigenschaften.
Das Material ist entweder ein einfarbiges Material oder eine Phototextur. Diese ist als Rastergrafik (Bitmap) zusätzlich zu den Transformationsparametern anzugeben. Die Transformationsmatrix beschreibt die Rotation, Skalierung und Translation der Bitmap bzgl. der Koordinaten des Startknotens der ersten Kante des äußeren Umrings der Masche.
3.1.2 Rekursive Aggregation
Unmittelbar über dem Basismodell befindet sich die Aggregationsebene. Hier werden die
Schemata definiert, die beschreiben, wie Primitive eines Typs zu komplexen Objekten des
gleichen Typs aggregiert werden. Ein Gebäude könnte demnach in mehrere, einzeln repräsentierte Gebäudeteile wie z.B. in Haus und Garage, und das Haus wiederum in Haupttrakt und
Nebentrakt zerlegt und in dieser Struktur als Aggregat gespeichert werden. Einfache Gebäudemodelle besitzen zumeist keine Zerlegung in Gebäudeteile, so dass in den meisten Fällen
keine Aggregation stattfindet.
Es gibt Aggregate für Kanten, Flächen und Volumenkörper. Da diese zur Definition der Objektgeometrie verwendet werden, heißen die Klassen entsprechend Liniengeometrie, Flächengeometrie und Volumengeometrie. Punktgeometrien bestehen jeweils nur aus einem einzigen
Knoten. Eine aus mehreren Knoten zusammengesetzte Punktgeometrie ist nicht vorgesehen.
Objektgeometrie
Volumengeometrie
−Typ:string
Volumenkoerper
Volumenaggregat
Abbildung 3.3: Aggregation von Volumenkörpern zu (komplexen) Volumengeometrien [Bru02]
36
KAPITEL 3 – IMPLEMENTIERUNG DES DATENMODELLS
Das Aggregationsschema ist für alle drei Geometrieklassen identisch. Es besteht jeweils aus
einer Oberklasse, die sich zum einen in das zugrundeliegende Primitiv und zum anderen in
eine Aggregatsklasse spezialisiert, die wiederum eine Aggregationsbeziehung zu ihrer Oberklasse besitzt. Diese Aggregation wird in der UML-Notation durch eine Raute dargestellt, sie
stellt eine spezielle Assoziation dar, deren beteiligte Klassen zueinander in Beziehung stehen,
wie ein Ganzes zu seinen Teilen.
Diese Modellierung realisiert eine rekursive Aggregationshierarchie, die sich durch einen
Baum darstellen lässt, dessen Knoten Aggregatobjekte sind und an dessen Blättern die Primitive hängen. Rekursiv bedeutet zunächst einmal nur, dass die Werte einer Funktion derart zusammenhängen, dass sie sich aus einem gegebenen Anfangswert nacheinander durch jeweils
die gleiche Formel berechnen lassen. Der Baum, der eine Aggregationshierarchie darstellt,
kann also beliebig viele Ebenen besitzen. In einem 3D-Stadtmodell wird z.B. die Garage mit
dem Haus aggregiert, danach dieses Aggregat zusammen mit weiteren zu einem Stadtviertel,
mehrere Viertel zu einer Stadt usw.
Bei der Bildung von Volumenaggregaten ist allerdings darauf zu achten, dass sich die Einzelteile zwar berühren, aber nicht durchdringen dürfen. An den Stellen, an denen sich die Komponenten berühren, müssen diese gemeinsame Flächen, Kanten oder Knoten verwenden. Das
heißt, dass wenn z.B. eine Garage ohne Spalt an die Seitenwand eines Gebäudes gebaut wurde, und Haus und Garage durch einen eigenen Volumenkörper repräsentiert werden sollen,
die Berührungsfläche explizit modelliert sein muss. Die Masche, die die Berührungsfläche
repräsentiert, müsste Bestandteil beider Volumenkörper sein. An diesem Beispiel lässt sich im
übrigen auch verdeutlichen, warum bei Volumenkörpern die Orientierung der Maschen explizit angegeben werden muss, und es nicht reicht z.B. zu fordern, dass die Flächennormale immer nach außen zeigen muss. Da dieselbe Fläche Bestandteil der Volumenkörper des Hauses
und der Garage ist, kann sie nur bzgl. eines der Objekte nach außen zeigen.
Der Aufbau einer Flächengeometrie und einer Liniengeometrie geschieht analog dazu, wobei
allerdings darauf zu achten ist, dass sich Linienaggregate (an Knoten) zwar berühren, aber
nicht überlappen dürfen. Um dies zu gewährleisten, darf jede Kante nur einmal innerhalb derselben Liniengeometrie vorkommen.
3.1. MODELL „REGENGELD“
37
DGM
Flaechengeometrie
-Typ:String
Orientierung
Flaechenaggregat
1..*
Geometrie
TIN
1..*
Masche
Dreieck
1
0..1
0..*
Bruchkante
0..2
Kante
3
begrenzt_von
Abbildung 3.4: Spezielles Flächenaggregat TIN [Bru02]
Als ein spezielles Flächenaggregat wurde das TIN ((triangulated irregular network), eine
unregelmäßige Dreiecksvermaschung explizit modelliert. Es leitet sich aus der Klasse DGM
(Digitales Geländemodell) ab und gibt die Geländeoberfläche wieder. Ein TIN ist ein spezielles Flächenaggregat, das sich ausschließlich aus Dreiecken zusammensetzt. Ein Dreieck ist
eine spezielle Masche. Die Klasse Dreieck wird somit als Unterklasse von Masche modelliert.
Zusätzlich können zu einem TIN eine Menge von Bruchkanten angegeben werden, die bei der
Generierung der Dreiecksvermaschung als Zwangskanten eingehen.
Wie man in Abbildung 3.5 erkennt, besteht das Objekt Gebäude aus Volumen-, Flächen und
Liniengeometrien. Damit ist es möglich, beispielsweise ein Haus durch einen geschlossenen
Volumenkörper zu repräsentieren und die Dachüberstände als einzelne Dachteilflächen ohne
volumetrische Ausdehnung an die Traufkanten anzubringen. Genauso kann man eine Antenne
als Linienobjekt auf das Dach setzen.
0..2
Geometrie
1..*
-R G B _ W e rt:(in t , in t , in t )
einfarbiges Material
Geometrie
1..*
Geometrie
1..*
0..*
-Tranformationsmatrix:Matrix
-Bitmap:Binaer
Phototextur
unten
0..1
oben
0..1
äußerer
1
0..*
innerer
1
1..0
Ring
Flaechenaggregat
4..*
Masche
-Typ:String
Orientierung
Geometrie
Flaechengeometrie
Gebaeude
Ueberirdisches Bauwerk
begrenzt_von
Orientierung
Volumenaggregat
Materialeigenschaften
Volumenkoerper
-Typ:string
Volumengeometrie
Objektgeometrie
Ausgestaltung
0..*
1..*
Dreieck
0..2
1
1..*
Geometrie
3..*
0..2
3
0..*
0..*
Linienaggregat
begrenzt_von
Kante
0..*
Bruchkante
{ordered}
besteht_aus
0..1
TIN
Geometrie
-Typ:String
Liniengeometrie
DGM
Startknoten
1
Endknoten
1
-x:Koordinate
-y:Koordinate
-z:Koordinate
Knoten
1
0..*
-Typ:String
Punktgeometrie
38
KAPITEL 3 – IMPLEMENTIERUNG DES DATENMODELLS
Abbildung 3.4: Gesamtmodell Projekt „Regengeld“ Version vom 13.11.2002 [Bru02]
3.1. MODELL „REGENGELD“
39
3.1.3 Integritätsbedingungen
In Abschnitt 2.1.3 wurden 12 Konventionen aufgestellt, welche die Integrität der Daten sicherstellen sollen. Bezogen auf dieses Modell sind in [Bru02] folgende Integritätsbedingungen aufgestellt worden, die sich mit denen aus 2.1.3 logischerweise stark überschneiden.
•
Es darf keine verschiedenen Knoten mit identischen Koordinaten geben. Wenn zwei
Punkte dieselbe Koordinate besitzen, müssen sie durch den selben Knoten repräsentiert werden.
•
Start- und Endknoten von Kanten müssen unterschiedlich sein. In Verbindung mit der
vorherigen Bedingung wird damit sichergestellt, dass Kanten immer eine Länge > 0
besitzen.
•
Kanten stellen eine gerade Strecke dar, d.h. die Verbindung von Start- und Endknoten
erfolgt auf dem kürzesten Weg.
•
Es darf keine verschiedenen Kanten mit den selben Start- und Endknoten geben.
•
Kanten berühren sich nur in Start- und Endknoten, d.h. es darf keinen Schnitt oder gar
eine Überlappung zweier Kanten geben, die nicht in einem Start- oder Endknoten
liegt.
•
Ein Ring muss ein einfacher Zyklus aus Kanten sein, d.h. nur der erste und der letzte
Knoten des Zyklus dürfen (und müssen) sich berühren.
•
Wenn sich mehrere Ringe berühren, müssen die sich berührenden Elemente (Knoten
oder Kanten) Bestandteil jeweils aller beteiligten Ringe sein.
•
Innerhalb einer Masche dürfen sich der äußere und die inneren Ringe nicht überlappen
und sich höchstens in einem Punkt berühren. Es darf dabei aber nicht der Fall eintreten, dass durch eine Verkettung sich berührender innerer Ringe, die an zwei Knoten
auch den äußeren Ring berührt, die Maschenfläche partitioniert wird.
•
Der äußere und die inneren Ringe einer Masche müssen koplanar sein.
•
Koplanare Maschen dürfen sich nicht überlappen.
•
Volumenkörper dürfen sich nicht durchdringen. Wenn sich Volumenkörper berühren,
müssen die sich berührenden Elemente (Knoten, Kanten oder Maschen) Bestandteil
jeweils aller beteiligten Volumenkörper sein.
40
KAPITEL 3 – IMPLEMENTIERUNG DES DATENMODELLS
Integritätsbedingungen auf der Anwendungsebene
Generell dürfen sich räumliche 3D-Objekte nicht durchdringen. Dies gilt sowohl für Objekte
der selben Klasse als auch bzgl. der Objekte unterschiedlicher Klassen. Das bedeutet, dass
sich einerseits verschiedene Gebäude nicht durchdringen dürfen und andererseits auch kein
Ausgestaltungselement ein Gebäude durchdringen darf.
Bedingt durch die getrennte Bestimmung eines DGMs und der 3D-Objekte kann es passieren,
dass ein Haus von einer Masche des DGMs durchdrungen wird. Um solche Probleme zu vermeiden, muss die Verbindung von 3D-Objekten und DGMs durch gemeinsame Kanten und
Maschen explizit gemacht werden. Dazu ist der Schnitt der Wandflächen mit dem DGM zu
ermitteln. Die Schnittfläche zerteilt das Gebäude in einen oberirdischen und einen unterirdischen Teil. Die Wandflächen teilen sich dementsprechend in eine Masche, die über der Erde
liegt und eine zweite Masche, die unter der Erde liegt. Die Schnittkanten sind dem DGM als
Zwangskanten hinzuzufügen, so dass die Schnittfläche einerseits die oberirdischen und unterirdischen Gebäudeteile begrenzt und sie andererseits Teil des DGMs bleibt.
3.2 Objekt-relationale Umsetzung
Bei der Umsetzung bestand die Aufgabe darin, das zuvor dargestellte Datenmodell in Oracle
in objekt-relationaler Form abzubilden. Eine 1:1 Umsetzung ist deshalb als problematisch
anzusehen, da in der Datenbank nicht ohne weiteres m:n-Beziehungen dargestellt werden
können und vor allem das Problem der rekursiven Aggregation gelöst werden muss. Dieses
Kapitel beschreibt die Umsetzung und Kapitel 3.3 erläutert die SQL-Anweisungen, mit denen
das objekt-relationale Modell erstellt wurde.
3.2.1 Geometrisch-topologisches Modell
MaschenListe ntabtyp
RingListe ntabtyp
KantenListe ntabtyp
Maschenliste_ntab
-SortVar:NUMBER
Innen_ntab
Kantenliste_ntab
Masche_ref
Volumen objtyp
-ID_Volumen:NUMBER
Ring_ref
Masche objtyp
-ID_Masche:NUMBER
-Orientierung:VARRAY
Ring objtyp
-ID_Ring:NUMBER
Kante_ref
Kante objtyp
-ID_Kante:NUMBER
Knoten objtyp
Ende_ref
Aussen_ref
+sortkante:void
Anfang_ref
-ID_Knoten:NUMBER
-x:NUMBER
-y:NUMBER
-z:NUMBER
Abbildung 3.5: UML-Diagramm der objekt-relationalen Umsetzung für die
geometrisch-topologische Modellierung eines Volumenkörpers
3.2 OBJEKT-RELATIONALE UMSETZUNG
41
Zur Notation
Die hier verwendete Notation weicht zur UML-Notation zu Abbildung 3.1 etwas ab, da hier
ein objekt-relationales Modell beschrieben wird. Auf Multiplizitäten muss hier verzichtet
werden, weil die Datenbank nicht in der Lage ist, solche semantischen Bedingungen zu überwachen, vielmehr müssen die Daten bereits den Integritätsbedingungen aus Abschnitt 3.1.3
genügen.
Jedes abgebildete Objekt entspricht einem Objekttypen in der objekt-relationalen Datenbank,
seine Attribute stehen für die Spalten der Tabelle, in der die Daten eines Objekttypen gehalten
werden (Siehe auch „Objekttabelle“ in Abschnitt 2.5.2). Die Assoziationen zwischen den Objekttypen sind ebenfalls Spaltenelemente der Tabellen, bzw. spezielle Attribute der Objekttypen, nämlich Objektreferenzen. Die Ausnahme bilden dabei Assoziationen vom Typ _ntab,
die einer Referenz auf eine eingebettete Tabelle entsprechen.
Modellierung
Die in Abbildung 3.5 dargestellten Einheiten sind zum einen (in der oberen Reihe) nested
tables, zu erkennen an der Endung ntabtyp und zum anderen Objekttypen. In Abschnitt
3.2.3 wird man erkennen, dass die Objekttypen keine Daten enthalten sondern nur die Tabellen definieren, welche dann die Daten aufnehmen. Am Beispiel zwischen Knoten und Kante erkennt man sehr gut die Bedeutung der Objekt-Referenzen. Der Objekttyp Kante besitzt
eine UID (ID_Kante) und zwei Referenzen auf ihren Anfangs- und Endknoten.
Ein Ring soll aus m Kanten bestehen, die wiederum in n Ringen auftauchen dürfen. Hierfür
wird die nested table KantenListe benötigt. Für jeden Ring existiert eine Liste von Objekt-Referenzen auf Kanten und zusätzlich eine Sortiervariable, welche jeder Kante die Position im Ring zuordnet.
Eine Masche besitzt per Definition (Abschnitt 3.1.1) einen Außenring und 0-n Innenringe.
Der Außenring besteht wie bei der Kante aus einer einfachen Objekt-Referenz, während die
Innenringe durch eine Liste von Objekt-Referenzen dargestellt werden. Zusätzlich zu Ihrer ID
besitzt die Masche eine Orientierung bestehend aus drei Zeilen, die als Listenelement (VARRAY) in das Objekt integriert ist (Abschnitt 2.5.2) und die Richtung des Normalenvektors
festlegen.
Das Volumen besitzt analog dazu ebenfalls eine nested table, in der alle Maschen aufgelistet
werden, aus denen sich ein Volumenkörper zusammensetzt.
An dieser Stelle sei darauf hingewiesen, dass die Vergabe von ID’s für objekt-relationale
Schemata nicht notwendig sind. Wenn man aber JOINS (Abschnitt 2.5.4) verwendet, benötigt
man ID’s. Somit gehen sie zusätzlich in dieses Modell ein.
42
KAPITEL 3 – IMPLEMENTIERUNG DES DATENMODELLS
3.2.2 Rekursive Aggregation
a)
G2
G1
G3
G6
G2
G1
G1
G2
LinienGeom_ref
Kante_ref
Kante objtyp
G6
G3
LinienAggregat ntabtyp
G4
G3
G7
G5
c)
LinienGeometrie objtyp
-ID_Linie:NUMBER
- is_aggr: NUMBER
LinienAggregat_ntab
G5
b)
G4
-ID_Kante:NUMBER
G4
Abbildung 3.6: Rekursive Aggregation und Umsetzung in objekt-relationales Modell
Abbildung 3.6 verdeutlicht noch einmal die Baumstruktur einer rekursiven Aggregation. Da
die nested table LinienAggregat wieder auf eine neue LinienGeometrie zeigt, sind
unendlich tiefe Aggregationsebenen möglich. In Beispiel c) zeigt die nested table der LinienGeometrie G7 auf die Geometrien G5 und G6. Diese verweisen wiederum auf die Geometrien
G1 und G2, sowie G3 und G4, welche mit der Objekt-Referenz auf die vier abgebildeten Kanten zeigen. Legen wir das Beispiel aus Abbildung 2.10 zu Grunde, würde die eingebettete
Tabelle etwa so aussehen:
Nested Tabel ID Value
G5
G1
G5
G2
G6
G3
G6
G4
G7
G5
G7
G6
Im Vergleich zu Abbildung 3.3 ist diese Umsetzung zwar etwas anders, das Resultat ist jedoch das gleiche, es können unendlich viele Aggregationsstufen mit diesem Modell ermöglicht werden.
Da eine LinienGeometrie entweder eine Liste mit Aggregaten besitzt oder direkt eine
Kante referenziert, hilft die Variable is_aggr dabei, dieses herauszufinden. Eine andere
3.2 OBJEKT-RELATIONALE UMSETZUNG
43
Möglichkeit bestünde darin, herauszufinden, ob die Referenz auf eine Kante NULL ist, oder
nicht.
Abbildung 3.7 zeigt das komplette Modell. Auf die Einflechtung eines TIN’s und eines
DGM’s wurde verzichtet, eine spätere Erweiterung ist aber durchaus möglich. Auf die Unterteilungen in Gebäude oder oberirdisches Bauwerk wurde ebenso verzichtet, da solche Attribute in einer darüber liegenden Ebene gespeichert werden sollten. Egal, ob Brücke, Haus, Straße
oder Gebäude, dies sind alles Attribute, die dem Objekt später vererbt werden können.
Das an oberster Stelle angeordnete Objekt kann wie im Modell „Regengeld“ Volumen-,
Flächen- und Liniengeometrien besitzen. Zusätzlich sitzt in diesem Objekttyp die SpatialTabelle, in der die Koordinaten einer Geometrie gespeichert sind, egal ob es aus Volumen,
Flächen und / oder Linien besteht. Leider stößt man an dieser Stelle an die Grenzen von Oracle, denn wie man an der Endung Objekt_reltab erkennen kann, handelt es sich hier
nicht um einen Objekttypen, sondern um eine einfache relationale Tabelle. Verantwortlich
dafür ist der Spatial-Datentyp mdsys.sdo_geometry. (Sie dazu Abschnitt 4.6). Die Attribute Volumen_ref, Flaeche_ref und Linie_ref sind daher keine ObjektReferenzen, sondern einfache Fremdschlüssel, somit also vom Datentyp NUMBER(ähnlich
integer).
Der SQL-Befehl, mit dem diese rekursive Aggregation abgefragt werden kann, wird in Abschnitt 5.2 genauer erläutert.
Abbildung 3.7: Objekt-relationales Datenmodell
-ID_Masche:NUMBER
-Orientierung:VARRAY
FlaechenAggregat_ntab
-Rot:NUMBER
-Gruen:NUMBER
-Blau:NUMBER
RGB
Aussen_ref
Innen_ntab
Objekt reltab
-ID_Ring:NUMBER
Ring objtyp
Ring_ref
Kantenliste_ntab
Kante objtyp
-ID_Kante:NUMBER
Kante_ref
-SortVar:NUMBER
Kante_ref
-ID_Linie:NUMBER
-is_aggr:NUMBER
LinienGeom_ref
LinienAggregat_ntab
Anfang_ref
Ende_ref
PunktGeometrie objtyp
Knoten objtyp
Knoten_ref
-ID_Punkt:NUMBER
-ID_Knoten:NUMBER
-x:NUMBER
-y:NUMBER
-z:NUMBER
LinienAggregat ntabtyp
LinienGeometrie objtyp
Linie_ref
KantenListe ntabtyp
Flaeche_ref
-ID_Objekt:NUMBER
-world:mdsys.sdo_geometry
RingListe ntabtyp
FlaechenAggregat ntabtyp
FlaechenGeom_ref
Masche_ref
-ID_Volumen:NUMBER
Masche_ref
MaschenListe ntabtyp
-ID_Flaeche:NUMBER
-is_aggr:NUMBER
Masche objtyp
Maschenliste_ntab
VolumenAggregat ntabtyp
Oben
FlaechenGeometrie objtyp
Unten
Material
Volumen objtyp
Volumen_ref
VolumenAggregat_ntab
VolumenGeom_ref
-ID_VolumenGeom:NUMBER
-is_aggr:NUMBER
VolumenGeometrie objtyp
-Bitmap:BLOB
-Transformation:VARRAY
Textur
Volumen_ref
44
KAPITEL 3 – IMPLEMENTIERUNG DES DATENMODELLS
3.2 OBJEKT-RELATIONALE UMSETZUNG
45
3.2.3 Erstellung des Datenmodells mit SQL
Das Datenmodell kann bei Oracle mit der Enterprise Manager Konsole oder mit SQLBefehlen erstellt werden. Letztere sind in jedem Fall vorzuziehen, da sich damit ObjektReferenzen und eingebettete Tabellen wesentlich flexibler erstellen lassen. Im folgenden finden sich nur die Beispiele für die Implementierung von Punkt- und Liniengeometrie, sowie
den darunter liegenden Typen. Die vollständige Liste der SQL-Befehle befindet sich im Anhang.
Um Objekt-Referenzen zu erstellen, müssen die zu referenzierenden Objekttypen zumindest
namentlich existieren. Daher werden die Typen für Knoten, Kante und Liniengeometrie als
erstes erstellt.
CREATE OR REPLACE TYPE Knoten_objtyp
/
CREATE OR REPLACE TYPE LinienGeometrie_objtyp
/
CREATE OR REPLACE TYPE Kante_objtyp
/
Das LinienAggregat wird nicht referenziert, sondern ist der Objekttyp für eine eingebettete
Tabelle, die direkt im Anschluß definiert wird.
CREATE OR REPLACE TYPE LinienAggregat_objtyp AS OBJECT
(
LinienGeom_ref REF LinienGeometrie_objtyp
) NOT FINAL
/
Mit AS OBJECT legt man fest, dass es sich hierbei um einen Objekttypen handelt. Der Befehl REF weist dem Attribut LinienGeom_ref den Datentyp „Zeiger auf LinienGeometrie_objtyp“ zu, obwohl dieser noch nicht weiter spezifiziert ist. Der Befehl NOT
FINAL ermöglicht es, den Objekttyp später noch zu verändern. Grundsätzlich ist es aber
jederzeit möglich, den Status FINAL oder NOT FINAL zu ändern.
CREATE OR REPLACE TYPE LinienAggregat_ntabtyp AS TABLE OF
LinienAggregat_objtyp
/
Für den späteren Einsatz der eingebetteten Tabelle (nested table) wird hier bereits deren Datentyp als Tabelle in LinienAggregat_objtyp erstellt.
46
KAPITEL 3 – IMPLEMENTIERUNG DES DATENMODELLS
Da jetzt alle Objekttypen definiert sind, werden ihnen im folgenden die Attribute zugewiesen.
CREATE OR REPLACE TYPE PunktGeometrie_objtyp AS OBJECT
(
ID_Punkt
NUMBER,
Knoten_ref
REF Knoten_objtyp
) NOT FINAL
/
CREATE OR REPLACE TYPE Knoten_objtyp AS OBJECT
(
ID_Knoten
NUMBER,
x
NUMBER,
y
NUMBER,
z
NUMBER
) NOT FINAL
/
CREATE OR REPLACE TYPE Kante_objtyp AS OBJECT
(
ID_Kante
NUMBER,
Anfang_ref
REF Knoten_objtyp,
Ende_ref
REF Knoten_objtyp
) NOT FINAL
/
CREATE OR REPLACE TYPE LinienGeometrie_objtyp AS OBJECT
(
ID_Linie
NUMBER,
Kante_ref
REF Kante_objtyp,
LinienAggregat_ntab
LinienAggregat_ntabtyp,
is_aggr
NUMBER
) NOT FINAL
/
Der zuvor definierte Datentyp LinienAggregat_ntabtyp läßt zwar vom Namen her auf eine
eingebette Tabelle schließen, der Datenbank ist das aber noch nicht bekannt. Darüber hinaus
wurden bis jetzt lediglich Objekttypen erstellt, in denen noch keine Daten abgelegt werden
können. Es folgt nun die Erstellung der Tabellen aus den jeweiligen Objekttypen. Zur Erinnerung, es können beliebig viele Tabellen aus einem Objekttyp erstellt werden.
3.2 OBJEKT-RELATIONALE UMSETZUNG
47
CREATE TABLE LinienGeometrie_objtab OF LinienGeometrie_objtyp
(
PRIMARY KEY (ID_Linie),
FOREIGN KEY (Kante_ref) REFERENCES Kante_objtab
ON DELETE CASCADE
)
OBJECT IDENTIFIER IS PRIMARY KEY
NESTED TABLE LinienAggregat_ntab STORE AS LinienAggregat_stortab
/
Bei der Erstellung der Tabelle wird ein Primärschlüssel angegeben, was nicht unbedingt nötig
wäre, aber zwei Vorteile mit sich bringt: Zum einen kann der Benutzer mit Hilfe des Primärschlüssels leichter auf die Daten in der Tabelle zugreifen (z.B. nur ID’s < 20 anzeigen) und
zum anderen speichert die Datenbank einen selbst generierten object-identifier in
einer versteckten Spalte, welcher eine Länge von 16 byte besitzt. Für den Fall, dass man einen
Primärschlüssel angibt und diesen als object-identifier benutzt, kann man Speicherplatz sparen, sofern die selbst generierten ID’s nicht ebenso lang sind [Oraa].
Wie in Abschnitt 2.5.2 erwähnt, werden Objekt-Referenzen als Fremdschlüssel behandelt
(z.B. Attribut Kante_ref). Der Befehl ON DELETE CASCADE ist dafür verantwortlich,
dass beim Löschen einer Kante, die darauf referenzierende LinienGeometrie ebenfalls gelöscht wird, um sogenannte „dangling references“ zu vermeiden, die in solch einem Fall „ins
Leere“ zeigen würden.
Erst bei der Erstellung der Tabelle LinienGeometrie_objtab wird der Datenbank mitgeteilt, dass sie die (bereits erstellte) Tabelle LinienAggregat_ntab als nested table
einbetten soll. Da mehrere Tabellen die gleiche eingebettete Tabelle verwenden können, der
Inhalt der eingebetteten Tabellen aber in einer „externen“ Tabelle (Siehe Abschnitt 2.5.3)
zusammengefasst wird, muss hier der Name dieser „externen“ Tabelle mit dem Befehl STORE AS angegeben werden.
ALTER TABLE LinienAggregat_stortab
ADD (SCOPE FOR (LinienGeom_ref) IS LinienGeometrie_objtab)
/
Da für die Objekt-Referenzen in den eingebetteten Tabellen keine Primärschlüssel verwendet
werden, kann alternativ dazu ein „scoped REF“ verwendet werden, der ebenfalls Speicherplatz spart und für bessere Performance sorgt [Oraa].
Analog zu LinienGeometrie_objtab verhält es sich auch mit den Tabellen Knoten_objtab, Kante_objtab und PunktGeometrie_objtab:
48
KAPITEL 3 – IMPLEMENTIERUNG DES DATENMODELLS
CREATE TABLE Knoten_objtab OF Knoten_objtyp
(
PRIMARY KEY (ID_Knoten)
)
OBJECT IDENTIFIER IS PRIMARY KEY
/
CREATE TABLE PunktGeometrie_objtab OF PunktGeometrie_objtyp
(
PRIMARY KEY (ID_Punkt),
FOREIGN KEY (Knoten_ref) REFERENCES Knoten_objtab
ON DELETE CASCADE
)
OBJECT IDENTIFIER IS PRIMARY KEY
/
CREATE TABLE Kante_objtab OF Kante_objtyp
(
PRIMARY KEY (ID_Kante),
FOREIGN KEY (Anfang_ref) REFERENCES Knoten_objtab
ON DELETE CASCADE,
FOREIGN KEY (Ende_ref) REFERENCES Knoten_objtab
ON DELETE CASCADE
)
OBJECT IDENTIFIER IS PRIMARY KEY
/
Alle SQL-Befehle zur Erstellung des vollständigen Datenmodells befinden sich im Anhang.
Darauf aufbauend werden im folgenden Kapitel die 3D-Fähigkeiten von Oracle Spatial untersucht. Im Anschluss daran werden die verschiedenen Werkzeuge beschrieben, die den Datenaustausch und die Datenaufbereitung mit dem hier vorgestellten Datenmodell realisieren.
Kapitel 4
Eignung von Oracle Spatial
Bislang existieren nur wenige Untersuchungsergebnisse zu den 3D-Fähigkeiten von Oracle
Spatial wie z.B. in [Sto03]. Die von Oracle herausgegebene Dokumentation [Orac] behandelt
das Thema 3D nur ganz am Rande, dort werden vor allem die Fähigkeiten in 2D hervorgehoben. Dieses Kapitel soll Aufschluss über die 3D-Fähigkeiten von Oracle Spatial geben und
gleichzeitig erläutern, wie diese Fähigkeiten in dieser Arbeit genutzt werden können. Zum
besseren Verständnis wird das Konzept von Spatial zunächst in 2D beschrieben. Die 3DFähigkeiten werden darauf aufbauend in Abschnitt 4.2 erläutert.
4.1 Konzept
Oracle Spatial (kurz: Spatial) stellt ein SQL-Schema und zugehörige Funktionen zur Verfügung, mit deren Hilfe das Speichern, Bearbeiten, Aktualisieren und Abfragen von räumlichen
Informationen möglich wird. Dazu gehören:
•
•
•
Ein Schema (MDSYS), dass die Speicherung, Syntax und Semantik der verschiedenen
geometrischen Datentypen beschreibt.
Operatoren und Funktionen, die bestimmte Regionen abfragen können, räumliche Daten mit einander verknüpfen und andere Analyse-Operatoren.
Ein Mechanismus zur räumlichen Indizierung von Daten.
4.1.1 Räumliche Datentypen
Abbildung 4.1 zeigt die von Spatial unterstützten Geometrien. Da deren Koordinaten in drei
Dimensionen gespeichert werden können, ist es auch möglich die o.g. Geometrietypen beliebig im Raum anzuordnen. Außer der Tatsache, dass Polygone, die nicht in einer Ebene liegen,
auch von Spatial akzeptiert werden, entsprechen die Geometrien den Simple Features Spezifikationen [OGCa] des Open Gis Consortium.
49
50
KAPITEL 4 – EIGNUNG VON ORACLE SPATIAL
Point
Line String
Compound Linestring
Self-crossing
line string
Compound Polygon
Polygon
Circle
Polygon with hole
Rectangle
Abbildung 4.1: Auswahl der unterstützten Geometrietypen von Oracle Spatial [Orac]
Demnach müssen (im Gegensatz zu VRML) Polygone immer geschlossen werden, d.h., als
Endpunkt eines Polygons müssen immer die Koordinaten des Anfangspunktes nochmals abgespeichert werden. Die Reihenfolge dieser Punkte ist bei Polygonen bzw. Außen-Polygonen
gegen den Uhrzeigersinn, bei Innen-Polygonen ist die Umlaufrichtung aber mit dem Uhrzeigersinn. Innere Polygone müssen immer im Anschluss an deren äußeres Polygon gespeichert
werden und dürfen dieses auch nur in einem einzigen Punkt berühren (Siehe Abbildung 4.2).
Abbildung 4.2: Von Spatial erlaubte Polygone, angelehnt an die Spezifikationen des
Open Gis Consortium [OGCa]
Umlaufrichtung äußerer Polygone gegen und innerer mit dem Uhrzeigersinn; Innere dürfen äußere Polygone in einem Punkt berühren.
Zu den besonderen Fähigkeiten von Spatial gehört der Umgang mit Koordinatensystemen.
Nicht georeferenzierte Koordinaten werden in kartesischen Koordinaten gespeichert, für alle
Koordinaten mit räumlichem Bezug stehen geodätische, projezierte und lokale Koordinatensysteme zur Verfügung [Orac]. Spatial bietet sogar die Möglichkeit, zwischen Koordinatensystem mit insgesamt 975 verschiedenen Datumsangaben zu transformieren.
4.1. KONZEPT
51
Das zuvor angesprochene Spatial Datenmodell (MDSYS) besitzt eine hierarchische Struktur,
wie Abbildung 4.3 zeigt. Beachtet man diese Struktur, kann ein Element aus einem Punkt,
einer Linie, einem Polygon, einem gemischten Linientyp oder aus einem gemischten Polygon
bestehen. Ein oder mehrere (auch unterschiedliche) Elemente bilden eine Geometrie. Der
Layer, der beliebig viele Geometrien enthalten kann, entspricht einer Spalte in einer Tabelle.
Der Datentyp dieser Spalte heißt MDSYS.SDO_GEOMETRY und kann auch in mehreren
Spalten vorkommen. So ist es z.B. möglich, in einer Tabelle „Gebäude“ einen Layer für
Wohnhäuser, einen Layer für Fabrikhallen usw. zu erstellen, falls es für die Anwendung sinnvoll ist. Ebenso können damit verschiedene Level of Details realisiert werden.
Spatial Layer
Geometries
Elements
Point
Linestring
Polygon
Compound
Linestring
Compound
Polygon
Abbildung 4.3: Hierarchische Struktur des Spatial Datenmodells. Ein Layer kann
beliebig viele Geometrie beinhalten, die wiederum beliebig viele
Elemente enthalten können.
SDO_GEOMETRY wird von Spatial derart definiert:
CREATE TYPE sdo_geometry AS OBJECT (
SDO_GTYPE NUMBER,
SDO_SRID NUMBER,
SDO_POINT SDO_POINT_TYPE,
SDO_ELEM_INFO MDSYS.SDO_ELEM_INFO_ARRAY,
SDO_ORDINATES MDSYS.SDO_ORDINATE_ARRAY);
Das Attribut SDO_GTYPE beschreibt als vierstellige Zahl den Geometrietyp. Dabei steht die
erste Ziffer für die Dimension (2, 3 oder 4), die zweite und dritte Ziffer sind reserviert und die
letzte Ziffer steht für den genauen Geometrietypen. Dazu gehören:
52
0
1
2
3
4
5
6
7
KAPITEL 4 – EIGNUNG VON ORACLE SPATIAL
unbekannte Geometrie
Punkt
Linie
Polygon
collection, entspricht einer Sammlung von Punkt, Linie und Polygon
multipoint, entspricht einer Sammlung von Punkten
multilinestring, entspricht einer Sammlung von Linien
multipolygon, entspricht einer Sammlung von Polygonen
Ein Polygon im 3D hat also das Attribut 3003.
Das Attribut SDO_SDRID steht für eines der zahlreichen Koordinatensysteme, wobei mit
dem Wert NULL das Kartesische Koordinatensystem angenommen wird.
SDO_POINT kann nur dann nicht NULL sein, wenn SDO_GTYPE NULL ist.
SDO_GEOMETRY ist also entweder eine Geometrie, oder ein Punkt.
SDO_ELEM_INFO enthält die Geometrietypen, deren Position in SDO_ORDINATES und die
Interpretation der Elemente einer Geometrie. Mögliche Werte wären:
Wert
0
1
2
3
1003
2003
4
5
1005
2005
Element
unbekanntes Element
Punkt
Linienelement
Polygon
(äußeres)
(inneres)
zusammengesetzte Linien
zusammengesetztes Polygon
(äußeres)
(inneres)
Interpretation
Anzahl der Punkte
1 = gerade Linien, 2 = Kreisbögen
1 = gerade Linien, 2 = Kreisbögen
3 = Rechteck, 4 = Kreis
Anzahl der Subelemente
Anzahl der Subelemente
SDO_ELEM_INFO könnte beispielsweise den Wert (1, 1003, 3, 5, 1003, 3) besitzen, mit
folgendender Bedeutung: (1, 1003, 3) entspricht einem äußeren Polygon (1003) mit der Interpretation 3 = Rechteck, dessen erster Koordinatenwert an der Stelle 1 in SDO_ORDINATES
steht. Die zweite Geometrie beginnt an fünfter Stelle und ist ebenfalls ein Rechteck.
SDO_ORDINATES hat dann z.B. die Werte (10,10, 20,20, 40,40, 50,50) der Art (x1,y1,
x2,y2, x3,y3, x4,y4), denn ein Rechteck ist bereits durch zwei Punkte (vgl. Abbildung 4.1)
definiert.
4.1. KONZEPT
53
Sekundär
Filter
Primär
Filter
Reduzierte
Datenmenge
Layer Daten
Spatial
Index
Exaktes
Ergebnis
Spatial
Funktionen
Abbildung 4.4: Spatial’s „two-tier“-Modell. Mit Hilfe eines Primärfilters wird die
Datenmenge reduziert, um sie erst danach genau zu untersuchen. Diese
Methode spart Rechenaufwand.
Zur Abfrage eines Layers benutzt Spatial ein sog. „two-tier“-Modell, bei dem die Abfrage in
zwei Teile aufgespalten wird (Abbildung 4.4). Die Daten eines Layers werden zunächst mit
einem Primär-Filter selektiert, der einen rämlichen Index verwendet. Die durch diese Filterung reduzierte Datenmenge wird dann mit einem zweiten Filter genau untersucht. Dies ist
notwendig, weil die dazu verwendeten räumlichen Funktionen erheblich mehr Rechenaufwand benötigen als es die Durchsuchung des räumlichen Index erfordert. Die Arbeitsweise
der einzelnen Filter wird in Abschnitt 4.3 noch genauer erläutert.
4.1.2 Räumlicher Index
Um Objekte schneller aufzufinden, kann man die Objekte eines Layers indizieren. Bei der
Indizierung wird die häufig sehr komplexe Geometrie eines Objektes durch eine ganz Einfache approximiert. Im zweidimensionalen spricht man hier von einem Minimum Bounding
Rectangel (MBR), also das kleinste achsparallele Rechteck, welches die Geometrie umschließt. Diese Informationen werden in einem Suchbaum, genauer gesagt in einem R-Baum
[Gut84] sortiert abgelegt.
Abbildung 4.5: Minimum Bounding Rectangle; Kleinstes Rechteck um eine
Geometrie
54
KAPITEL 4 – EIGNUNG VON ORACLE SPATIAL
Nach der Bestimmung der MBR’s für alle Geometrien werden diese Informationen so gruppiert, dass nahe bei einander liegende Objekte auch in der Struktur des Suchbaums in Nachbarschaft zu einander abgebildet werden. Nimmt man das Beispiel aus Abbildung 4.6, so
werden dort die nahe bei einander liegenden Geometrien in a gruppiert. Das gleiche geschieht
mit b, c und d. Diese liegen in der untersten Ebene des Suchbaums und beinhalten das MBR
der gruppierten Geometrien und zusätzlich die Zeiger auf diese Geometrien. Diese Elemente
werden Blätter genannt.
Basierend auf ihrer Nachbarschaft werden als nächstes a, b, c und d in einem weiteren MBR
gruppiert. Die MBR’s a und b werden in R und c und d werden in S zusammengefasst.
Das Element in der höchsten Ebene des Suchbaums, auch Wurzel genannt, besitzt das MBR
um R und S und wie zuvor Zeiger auf die Elemente R und S.
Abbildung 4.6: Indizierung von Geometrien mit Hilfe von MBR’s in einem
R-Baum [Orac]
Die Struktur eines R-Baums ist darauf ausgelegt, auf nahe bei einander liegende Elemente
zuzugreifen. Der Zugriff erfolgt immer von der Wurzel aus, die Knoten des R-Baums besitzen
keine Zeiger auf darüber liegende Elemente. In Spatial beträgt die voreingestellte maximale
Verzweigung eines R-Baum’s 35 Elemente. Auf diese Weise können schon sehr viele Elemente indiziert werden, ohne dass der Baum zu tief wird.
Abbildung 4.7: Nicht exaktes Ergebnis: Das Suchfenster (gestrichelt) überlappt beide
MBR’s, aber berührt tatsächlich nur eine der beiden Geometrien.
4.1. KONZEPT
55
Da ein MBR nur eine Approximation einer komplexen Geometrie darstellt, ist auch das Ergebnis einer Suche im R-Baum nur eine Approximation.
In Abbildung 4.7 wird ersichtlich, dass das Suchergebnis mit MBR’s zwar 100% der gesuchten Objekte wiedergibt, darüber hinaus aber noch weitere Objekte mit in das Suchergebnis
einfließen, die dort eigentlich nicht auftauchen dürften. Aufgrund dessen ist es nötig, das in
Abbildung 4.4 gezeigte „two-tier“-Modell von Spatial anzuwenden. Mit Hilfe der MBR’s
kann also die Suche in einer großen Datenmenge stark reduziert werden, indem nur innerhalb
einer „Area of Interest“ gesucht werden muss.
4.1.3 Räumliche Operatoren
Bezogen auf das „two-tier“-Modell aus Abbildung 4.4 wenden alle räumlichen Operatoren
voreingestellt zuerst den primären, indexbasierten Filter an, um danach das Ergebnis einer
exakten Untersuchung zu unterziehen. Eine Ausnahme bildet hier der Operator
SDO_FILTER, der ausschließlich den ersten Schritt durchführt.
SDO_FILTER
Er benutzt einen räumlichen Index um zwei Geometrien zu finden, die potentiell mit einander
interagieren. In der Regel entspricht die erste Geometrie einem Suchfenster und man möchte
wissen, welche anderen Geometrien sich innerhalb dieses Fensters befinden (vgl. Abbildung
4.7). Prinzipiell ist aber auch möglich, zwei vorhandene Geometrien zu wählen und abzufragen, ob diese mit einander interagieren, wobei SDO_Filter diese Frage immer nur auf Basis der MBR’s der jeweiligen Geometrien beantwortet. Gemäß Abbildung 4.4 („two-tier“Modell) führt SDO_FILTER also nur den ersten Teil aus und liefert lediglich eine reduzierte,
nicht exakte Datenmenge. Da dieser Operator nur die Antwort TRUE oder FALSE liefert,
kann er nur in der WHERE-Klausel der SQL-Abfrage verwendet werden.
Syntax:
SDO_FILTER
( <geometry1>,
<geometry2>,
‘QUERYTYPE =<querytype>’
) = ‘TRUE’
Die erste Geometrie muss einen Index besitzen, man setzt hier die Spalte des zu durchsuchenden Layers ein. Die zweite Geometrie kann aus einer anderen Tabelle sein oder temporär erzeugt werden. Für den Fall, dass diese Geometrie keinen Index besitzt, wird der Inhalt des
Suchfensters für diese Anfrage kurzzeitig indiziert. Als querytype kann WINDOW oder
JOIN eingesetzt werden, Oracle empfiehlt aber in fast allen Fällen WINDOW zu benutzen, da
56
KAPITEL 4 – EIGNUNG VON ORACLE SPATIAL
JOIN (als räumliches Kreuzprodukt zu verstehen) immer auch als WINDOW Abfrage umgeschrieben werden kann.
SDO_RELATE
Dieser Operator führt im ersten Schritt die gleiche Prozedur wie SDO_FILTER aus, überprüft
aber im zweiten Schritt beide Geometrien entsprechend dem 9-Schnittmodell von Egenhofer
[Ege90] (Siehe Abbildung 4.8).
Abbildung 4.8: Oracles Umsetzung des 9-Schnittmodells von Egenhofer [Orac]
Mit dem 9-Schnittmodell können im zweidimensionalen alle topologischen Beziehungen zwischen zwei Objekten ausgedrückt werden. So ist es möglich, durch eine Abfrage alle Objekte
ausgeben zu lassen, die innerhalb (inside) eines Suchfensters liegen. Genauso können aber
auch alle Objekte ausgegeben werden, die gleich (equal) sind, um doppelt vorhandene Daten aufzudecken. Durch die Abfrage der Beziehung touch können z.B. benachbarte Flächen
gefunden werden. Um zu testen, ob zwei Objekte disjunkt (disjoint) sind, muss die Frage
ANYINTERACT = FALSE lauten.
Die Masken TOUCH, OVERLAPBDYDISJOINT, OVERLAPBDYINTERSECT,
EQUAL, INSIDE, COVEREDBY, CONTAINS, COVERS und ANYINTERACT können mit AND oder OR verknüpft werden. Der Rückgabewert des Operators lautet bei
ANYINTERACT = TRUE, bei allen anderen Masken jedoch so wie die Maske selbst, z.B.:
CONTAINS = CONTAINS.
Syntax:
SDO_RELATE
( <geometry1>,
<geometry2>,
‘MASK=<mask>
QUERYTYPE =<querytype>’
) = ‘TRUE’
4.1. KONZEPT
57
Die Operatoren SDO_WITHIN_DISTANCE und SDO_NN wurden in dieser Arbeit zwar
nicht verwendet, sind aber wichtiger Bestandteil von Spatial.
SDO_WITHIN_DISTANCE
Dieser Operator identifiziert mittels des räumlichen Index die Geometrien, welche innerhalb
einer spezifizierten Distanz zu einer gegebenen Geometrie liegen. QUERYTYPE und UNIT
sind optionale Parameter. Wählt man QUERYTYPE = Filter, wird nur der primäre Filter
unter Verwendung der MBR’s durchgeführt. Lässt man das Feld QUERYTYPE weg, wird die
exakte Distanz ermittelt. Bei Verwendung von UNIT kann man verschiedene von Spatial unterstützte Einheiten benutzen, lässt man das Feld weg, so wird die Einheit verwendet, die dem
verwendeten Koordinatensystem zugrunde liegt.
Syntax:
SDO_WITHIN_DISTANCE
( <geometry1>,
<geometry2>,
‘DISTANCE=<n>,
QUERYTYPE = <querytype>
UNIT = unit’
) = ‘TRUE’
SDO_NN
Er sucht mit Hilfe des räumlichen Index den nächsten Nachbarn einer Geometrie.
Mit dem optionalen Parameter SDO_NUM_RES gibt man an, wie viele nächste Nachbarn
angezeigt werden sollen.
58
KAPITEL 4 – EIGNUNG VON ORACLE SPATIAL
4.1.4 Räumliche Funktionen
Der Unterschied zwischen den Operatoren und den Funktionen besteht darin, dass die Operatoren zunächst den primären und danach den sekundären Filter auf die räumlichen Daten anwenden, wobei der erste Filter sich immer auf den räumlichen Index stützt. Die Funktionen
lassen den primären Filter aus, benötigen also keinen räumlichen Index und ermitteln auf diese Weise ein exaktes Ergebnis. Vergleicht man den Operator SDO_RELATE mit der Funktion SDO_GEOM.RELATE, muss die Funktion bei der Performance immer schlechter abschneiden als der Operator, weil der Operator ja nur die Objekte überprüft, die der Primärfilter ausgegeben hat.
Die folgende Tabelle soll einige ausgewählte räumliche Funktionen [Orac] auflisten, die Spatial bereitstellt. Auf eine tiefergehende Beschreibung wird hier jedoch verzichtet.
Räumliche Funktionen
und deren Aufgabe:
RELATE
Untersucht die räumliche Beziehung zweier
Geometrien (nach Egenhofer)
SDO_BUFFER
Legt ein Polygon in bestimmtem Abstand um
eine Geometrie
SDO_CENTROID
Bestimmt den Schwerpunkt einer Geometrie
SDO_CONVEXHULL
Gibt die Hülle einer Geometrie in Form eines
Polygons wieder
SDO_DIFFERENCE
Gibt das Objekt wieder, dass bei einer MINUSVerknüpfung zweier Objekte entsteht
SDO_DISTANCE
Errechnet die Entfernung zwischen den beiden
am nächsten liegenden Punkten zweier Objekte
SDO_INTERSECTION
Gibt das Objekt wieder, dass bei einer UNDVerknüpfung zweier Objekte entsteht
SDO_LENGTH
Berechnet die Durchmesser oder den Umfang
einer Geometrie
SDO_MBR
Gibt die Koordinaten des MBR einer Geometrie
aus
SDO_UNION
Gibt das Objekt wieder, dass bei einer ODERVerknüpfung zweier Objekte entsteht
SDO_WITHIN_DISTANCE
Ermittelt, ob zwei Objekte innerhalb eines
bestimmten Abstandes zu einander liegen
4.2. 3D-FÄHIGKEITEN
59
4.2 3D-Fähigkeiten
Jede der in Abschnitt 4.1 beschriebenen geometrischen Elemente wird durch Koordinaten
repräsentiert, welche alle in drei Dimensionen gespeichert werden können. Für das hier vorgestellte Modell sind vor allem gerade Linien und Flächen interessant. Die Koordinaten von
Linien und Flächen können in x, y und z abgespeichert werden, somit ist es auch möglich,
diese Geometrien frei im Raum anzuordnen.
Mit dem R-Baum können auch Geometrien im 3D und sogar im 4D indiziert werden. Im 3D
spricht man dann aber nicht mehr von einem Minimum Bounding Rectangle, sondern von
einem Minimum Bounding Volume (MBV).
z
y
x
Abbildung 4.9: Im 3D wird aus einem MBR ein MBV, ein Minimum Bounding
Volume ist das kleinste achs-parallele Volumen um eine Geometrie.
Der Operator SDO_FILTER aus Abschnitt 4.3, der nur auf die Interaktion zwischen den Indizes (MBR’s) von Geometrien achtet, führt im Gegensatz zu den anderen Operatoren nur die
primäre Filterung durch. Weil der R-Baum sich auch für 3D-Geometrien indizieren lässt,
vermag SDO_FILTER den primären Filter auch auf 3D-Objekte, bzw. Minimum Bounding
Volumes anzuwenden. Alle anderen Operatoren, die zusätzlich den sekundären Filter anwenden, versagen ihren Dienst bei 3D-Geometrien vollständig.
Man stelle sich den Fall vor, dass zwei Geometrien sich nur in der z-Koordinate unterscheiden
würden, also über einander stehen. 2D-Operatoren wären nicht in der Lage, diese beiden Geometrien von einander zu unterscheiden. Genau das ist derzeit der Stand aktueller geographischer Informationssysteme. In diesem Fall ist der Operator SDO_FILTER jedoch in der Lage,
sofern die MBV’s der beiden Geometrien nicht mit einander interagieren, diese Geometrien
von einander zu unterscheiden, wie Abbildung 4.10 deutlich macht.
60
KAPITEL 4 – EIGNUNG VON ORACLE SPATIAL
a)
b)
Abbildung 4.10: a) Geometrien können aus 2D-Sicht nicht von einander unterschieden
werden, wenn sie genau übereinander stehen. b) Sofern die MBV’s
der beiden Geometrien nicht mit einander interagieren, kann sie
SDO_FILTER aber unterscheiden.
Ebenso wie im 2D ergibt die Suche mit SDO_FILTER mehr Ergebnisse, als es tatsächlich
richtig wäre. An dieser Stelle empfiehlt Oracle eigene Funktionen zu entwickeln, welche die
bereits reduzierte Ergebnismenge hinsichtlich der dritten Dimension genau untersuchen. Es
bieten sich dazu räumliche Funktionen an, die in Java programmiert sogar auf dem Datenbank-Server als Prozeduren ausgeführt werden könnten. Im Hinblick auf ein echtes 3D-GIS
sind solche Eigenentwicklungen unabdingbar, sofern Oracle diese nicht in einer der kommenden Versionen von Spatial zur Verfügung stellt (s.a. Kapitel 7).
Da die Entwicklung solcher Funktionen den Rahmen dieser Arbeit deutlich gesprengt hätte,
wurde hier ein anderer Weg beschritten.
Zwar versagen die räumlichen Operatoren bei 3D-Geometrien ihren Dienst, die räumlichen
Funktionen lassen aber lediglich die z-Koordinate außer Acht, bzw. setzen diese gleich
NULL. Somit ist es also prinzipiell möglich, alle 2D-Abfragen auf 3D-Objekte zu beziehen,
was bei 3D-Stadtmodellen bereits einige Standard-Anwendungen ermöglichen würde. Darüber hinaus kann mittels eines verschachtelten SQL-Befehls das Suchgebiet unter Berücksichtigung der dritten Dimension mit dem Operator SDO_FILTER erheblich eingeschränkt werden.
Folgender SQL-Befehl beinhaltet in der FROM-Klausel eine weitere SELECT-Anweisung,
die den primären Filter ausführt. Auf diese Weise wird das Suchergebnis reduziert und es
4.2. 3D-FÄHIGKEITEN
61
kann dann in der ursprünglichen WHERE-Klausel mit Hilfe der 2D-Funktion ein (bezogen
auf 2D) exaktes Ergebnis geliefert werden.
SELECT s.id_objekt
FROM (
SELECT r.id_objekt, r.world
FROM objekt_reltab r
WHERE MDSYS.SDO_FILTER(
r.world, MDSYS.SDO_GEOMETRY(
3003, NULL, NULL,
MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,3),
MDSYS.SDO_ORDINATE_ARRAY(3446733.79, 5549996.27, 142.8,
3445133.79, 5539196.27, 104.8)
),'querytype=window'
) = 'TRUE'
) S, volumengeometrie_objtab v
WHERE MDSYS.SDO_GEOM.RELATE(
S.world, 'ANYINTERACT', MDSYS.SDO_GEOMETRY(
3003, NULL, NULL,
MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,3),
MDSYS.SDO_ORDINATE_ARRAY(3446733.79, 5549996.27, NULL,
3445133.79, 5539196.27, NULL)
),0.5
) = 'TRUE' AND
v.id_volumengeom = S.id_objekt;
Das Objekt MDSYS.SDO_GEOMETRY wurde bereits in Kapitel 4.1 erläutert. Der Wert
3003 legt ein Polygon im 3D fest, weshalb das in MDSYS.SDO_ELEM_INFO_ARRAY definierte Rechteck im 3D eine Box ist, die durch die x-, y- und z-Koordinaten in
MDSYS.SDO_ORDINATE_ARRAY aufgespannt wird.
Statt der Maske ANYINTERACT kommen für 2D-Untersuchungen alle Masken aus Abbildung 4.8 in Betracht. Die Maske INSIDE würde beispielsweise nur die Geometrien auswählen, die sich vollständig innerhalb des Suchfensters befinden.
Neben der Funktion RELATE sind noch die Funktionen SDO_BUFFER, SDO_DISTANCE
und SDO_LENGTH für diese Nutzung interessant. So könnte mit SDO_Buffer eine Anfrage
vom Typ „Im Umkreis von x Metern um das Objekt y“ gestellt werden. SDO_DISTANCE
kann die kürzeste Horizontalstrecke zwischen zwei Objekten berechnen und SDO_LENGTH
gibt Auskunft über den Durchmesser oder den Umfang unter Vernachlässigung der zKoordinate.
62
KAPITEL 4 – EIGNUNG VON ORACLE SPATIAL
4.3 Geometriebeispiel
Das Gebäude aus Abbildung 4.11 soll in der Tabelle objekt_reltab als SpatialGeometrie abgelegt werden.
Abbildung 4.11: Konstruiertes Gebäude mit Dachüberstand als Beispiel für das
Einfügen einer komplexen Geometrie in einen Spatial-Layer
Der SQL-Befehl dazu sieht wie folgt aus:
insert into objekt_reltab values (1000, NULL,
mdsys.sdo_geometry(3003, NULL, NULL,
mdsys.sdo_elem_info_array(
1, 1003, 1,
16, 1003, 1,
31, 1003, 1,
46, 1003, 1,
61, 1003, 1,
76, 1003, 1,
91, 1003, 1,
103, 1003, 1,
115, 1003, 1,
130, 1003, 1),
mdsys.sdo_ordinate_array(
50,50,50, 50,50,53, 50,58,53, 50,58,50,
50,50,50, 56,50,50, 56,50,53, 50,50,53,
56,50,50, 56,50,53, 56,58,53, 56,58,50,
56,58,50, 56,58,53, 50,58,53, 50,58,50,
50,58,53, 50,50,53, 53,50,56, 53,58,56,
53,50,56, 56,50,53, 56,58,53, 53,58,56,
50,58,53, 56,58,53, 53,58,56, 50,58,53,
50,50,53, 56,50,53, 53,50,56, 50,50,53,
50,50,50, 50,58,50, 56,58,50, 56,50,50,
50,58,53, 50,50,53, 49,50,52, 49,58,52,
NULL, NULL,
50,50,50,
50,50,50,
56,50,50,
56,58,50,
50,58,53,
53,50,56,
50,50,50,
50,58,53)));
4.3. GEOMETRIEBEISPIEL
63
Das Gebäude besteht aus insgesamt zehn Flächen. Dazu gehören die vier rechteckigen Seitenflächen, die beiden rechteckigen Dachflächen, die beiden dreieckigen Giebelflächen, die
Grundfläche des Hauses und der viereckige Dachüberstand, der an die Dachfläche im gleichen Neigungswinkel angesetzt wurde. Jede einzelne Fläche wird in diesem Beispiel in einer
neuen Zeile aufgeführt. Man erkennt auch die Konvention, dass zum Schließen eines Polygons der Endpunkt /Anfangspunkt ein zweites mal gespeichert werden muss.
Beim Einfügen dieses Gebäudes in die Tabelle objekt_reltab wurde dem Attribut
ID_Objekt der Wert 1000 zugeordnet und alle anderen Attribute gleich NULL gesetzt, da
dieses Gebäude nur manuell in die Datenbank eingefügt wurde.
Auf diese Weise sind alle Objekte in die Tabelle objekt_reltab eingefügt und indiziert
worden.
4.4 Polyeder-Repräsentation
Statt mehrere Flächen als Multipolygon zu speichern und damit auch redundante Koordinaten
in Kauf zu nehmen, wurde in [Are03] die Polyeder-Repräsentation in Spatial entwickelt. Ein
Polyeder (engl. Polyhedron) ist das 3D-Äquivalent zu einem 2D-Polygon. Es setzt sich aus
mehreren (mindestens vier) planaren Flächen zusammen und umschließt so ein Volumen.
Diese Darstellungsform ist in der Lage, sowohl die Geometrie, als auch die Topologie von
3D-Objekten direkt im Spatial-Layer zu speichern.
-geometry_type
Node
Face
Polyhedron
1
-starting_offset
4..* -element_type
-interpretation_code
3..* 3..*
ordered
Vertex
-x_coordinate
-y_coordiante
-z_coordinate
Abbildung 4.12: UML-Diagramm der Polyeder-Repräsentation [Are03]
Der folgende SQL-Befehl legt in einem Spatial-Layer namens geometry einen Polyeder in
Form eines Würfels ab. Die Datenstruktur aus Abbildung 4.12 wird dabei innerhalb des Attributs MDSYS.SDO_ORDINATE_ARRAY realisiert.
64
KAPITEL 4 – EIGNUNG VON ORACLE SPATIAL
INSERT INTO polyhedron_table (id, geometry)
VALUES (
1, --id
mdsys.sdo_geometry(3002, -- geometry type: 3D line
NULL, NULL,
mdsys.sdo_elem_info_array(
1,2,1,
25,0,1006,
29,0,1006,
33,0,1006,
37,0,1006,
41,0,1006,
45,0,1006),
-- starting offset, e_type,int_code
-- first triplet is line,
-- then the faces
mdsys.sdo_ordinate_array(
1,1,0, 1,3,0, 3,3,0, 3,1,0,
1,1,2, 1,3,2, 3,3,2, 3,1,2,
-- vertices
1,2,3,4, 8,7,6,5, 1,4,8,5,
-- bottom, top, front face (nodes)
2,6,7,3, 1,5,6,2, 4,3,7,8
-- back, left, right face (nodes)
)
)
);
Im Attribut MDSYS.SDO_ELEM_INFO_ARRAY ist als erstes eine 3D-Linie gespeichert,
deren Koordinaten die gleichen wie die des Polyeders sind. Des weiteren werden in diesem
Attribut Geometrien vom Typ 0, für Spatial also unbekannte Geometrien (vgl. Abschnitt
4.1.1) mit der Interpretation 1006 abgelegt. Diese Interpretation ist von Oracle nicht definiert
und wurde zur Beschreibung einer Fläche als innere (2006) oder äußere (1006) Fläche eines
Polyeders eingeführt.
Im Attribut MDSYS.SDO_ORDINATES werden alle Koordinaten des Polyeders aus Sicht
von Spatial als Punkte der 3D-Linie abgelegt. Die darauf folgenden Knoten stellen zusammen
genommen jeweils eine Fläche dar. Bei welcher Ziffer eine neue Fläche anfängt, wird in
MDSYS.SDO_ELEM_INFO_ARRAY definiert. So bedeutet dort z.B. die Zeile (25, 0, 1006),
dass an der Koordinatenstelle 25 eine unbekannte Geometrie mit der Interpretation 1006 beginnt. Sie besitzt die Werte 1, 2, 3, 4, die von Spatial nicht interpretiert werden. Die zweite
Fläche ist definiert durch die Zeile (29, 0, 1006) und besitzt demnach die Werte 8, 7, 6 und 5.
Diese Werte stehen natürlich für die Position der Koordinatentrippel, so dass also die zweite
4.4. POLYEDER-REPRÄSENTATION
65
Fläche beispielsweise die Koordinaten in folgender Reihenfolge besitzt: (3, 1, 2), (3, 3, 2),
(1, 3, 2), (1, 1, 2).
Da Spatial aber der Geometrietyp 3D-Linie bekannt ist, kann auch ein MBV für diese 3DLinie erstellt werden. Dieses MBV ist natürlich auch gleichzeitig das MBV des Polyeders,
wodurch ein 3D-Index für Polyeder angelegt werden kann (vgl. Abbildung 4.13).
Abbildung 4.13: Knotenpunkte des Polyeders repräsentiert durch eine 3D-Linie (fett).
Das MBV für die 3D-Linie entspricht dem des Polyeders (gestrichelt).
Das Besondere an dieser Darstellungsform ist zum einen, dass innerhalb der SpatialGeometrie zusätzlich topologische Beziehungen gespeichert werden können und zudem Redundanzen vermieden werden.
4.5 Oracle Spatial Java Library
Dieses Kapitel richtet sich vornehmlich an Java-Programmierer, um ihnen einen Überblick
über die Spatial Java Library zu verschaffen.
Bisher fand die Kommunikation zu Oracle nur über die JDBC-Schnittstelle statt. Auf den
Spatial-Datentyp wurde bisher also nur mit SQL-Befehlen zugegriffen. Mit der Spatial Java
Library (SDO_API) steht eine Schnittstelle zur Verfügung, mit der man von Java aus direkten
Zugriff auf Spatial-Geometrien hat. Die 3D-Funktionalität beschränkt sich hier jedoch nur auf
das Lesen von 3D-Objekten.
66
KAPITEL 4 – EIGNUNG VON ORACLE SPATIAL
Das Java-Package besteht aus 3 Teilen:
SDOAPI.GEOM (geometrische Objekte)
Mit dem geometry factory interface (GeometryFactory) können Geometrien erstellt werden.
Diese Schnittstelle kapselt das Java-Programm von der Implementierungsseite ab. Dadurch
sollten Programme auch nach Änderungen auf der Implementierungsseite weiter stabil laufen.
SDOAPI.ADAPTER (Geometrie-Adapter)
Mit diesem Gerüst verschiedener Geometrie-Adapter werden Geometrien konvertiert. Fremdhersteller können Geometrie-Adapter entwickeln, welche dann in Java-Programmen genutzt
werden sollen. Oracle liefert bereits Adapter für die Konvertierung von Shapefiles, XML,
oder WKT (well-known text) mit.
SDOAPI.SREF (Räumliche Koordinatensysteme)
Es werden geographische, projizierte und lokale Koordinatensysteme unterstützt. Zur Zeit
werden allerdings keine Koordinatentransformationen unterstützt.
Das folgende Beispiel aus [Orad] zeigt eine rekursive Funktion, welche die übergebenen Geometrien auswertet. Für die Übergabe der Geometrien genügt ein SELECT-Befehl, der den
Datentyp MDSYS.SDO_GEOMETRY übergibt. Die Funktion zerlegt Geometrien solange bis
sie auf der niedrigsten Ebene, dem Punkt, angekommen ist.
Query = “SELECT id_objekt, world FROM objekt_reltab”;
OracleResultSet ors = (stm.executeQuery(query);
Struct origSTR = (STRUCT)ors.getObject(2);
origgeom = sdoAdapter.importGeometry(origSTR);
printGeometry(origgeom);
// Print a geometry object
protected static void printGeometry(Geometry geom, int indent)
{
if (geom == NULL)
return;
// Indentation
for (int i = 0; i < indent; i++)
System.out.print(" ");
if (geom instanceof Point)
{
// Print x, y ordinates of a point
Point point = (Point) geom;
System.out.println("Point: " + point.getX() + ", " + point.getY());
}
else if (geom instanceof LineString)
4.5. ORACLE SPATIAL JAVA LIBRARY
67
{
LineString lineString = (LineString) geom;
int nDim = lineString.getDimensionality();
double[] coordArray = lineString.getCoordArray();
int nPoints = coordArray.length / nDim;
System.out.print("LineString: " + nPoints + " points:");
// Print coordinates of this line string
for (int i = 0; i < coordArray.length; i++)
System.out.print(" " + coordArray[i]);
System.out.println();
}
else if (geom instanceof Polygon)
{
// Print a linear polygon by printing all its parts
Polygon polygon = (Polygon) geom;
System.out.println("Polygon: ");
for (Enumeration e = curvePolygon.getRings(); e.hasMoreElements();)
printGeometry((Geometry)e.nextElement(), indent+2);
System.out.println();
}
else if (geom instanceof GeometryCollection)
{
// Print a geometry collection by printing all its member geometries
GeometryCollection geomColl = (GeometryCollection) geom;
System.out.println("GeometryCollection: ");
for (Enumeration e = geomColl.getGeometries(); e.hasMoreElements();)
printGeometry((Geometry)e.nextElement(), indent+2);
System.out.println();
}
}
4.6 Beurteilung
Mit Oracle Spatial ist es also möglich, 3D-Objekte zu verwalten. Bei der räumlichen Abfrage
der Daten zeigt sich aber, dass exakte Ergebnisse nur im zweidimensionalen möglich sind,
weil die dritte Dimension bei den räumlichen Funktionen unberücksichtigt bleibt. Immerhin
lassen sich 3D-Objekte in der dritten Dimension durch MBV’s indizieren, wobei der Operator
SDO_FILTER diee MBV’s der Objekte, auf Interaktion mit einander prüfen kann. Abbildung
4.14 zeigt jedoch, wann die Indizierung keine verlässlichen Resultate mehr bringen kann:
68
KAPITEL 4 – EIGNUNG VON ORACLE SPATIAL
a)
b)
Abbildung 4.14: a) Mit Hilfe der MBV’s können beide Objekte von einander unterschieden werden. b) Die beiden Geometrien berühren sich zwar
nicht, aber dafür ihre MBV’s. Somit ergibt die Anfrage an den räumlichen Index ebenso wie die Untersuchung mit der 2D-Funktion kein
exaktes Ergebnis.
Abschließend kann man sagen, dass der Funktionsumfang von Spatial beachtlich ist. Die
räumliche Erweiterung von Oracle bietet viele verschiedene Koordinatensysteme sowie
Transformationen zwischen diesen Systemen an. Sie besitzt ausgereifte Techniken zur Abfrage von 2D-Daten und ist sogar in der Lage, die 2D-Abfragen auf 3D-Daten anzuwenden.
Die dritte Dimension wird bisher nur durch eine räumliche Indizierung unterstützt, mit der
sich aber das Suchergebnis bereits deutlich einschränken lässt. Das bietet wiederum die Möglichkeit, eigene Routinen zu entwickeln und auf diese Weise ein exaktes Suchergebnis zu erzielen. Solche Routinen können in Java oder C++ programmiert und als eigenständige Subroutinen in der Datenbank untergebracht werden, womit die Rechenleistung vom Server und
nicht vom Client aufgebracht werden muss.
Diese 3D-Routinen sollten folgende Aufgaben lösen:
•
•
•
Exakte Unterscheidung von 3D-Objekten (vgl. Abbildung 4.14)
Messung der Schrägdistanz im Modell
Berechnung von Höhe, Volumen und Schwerpunkt eines 3D-Objekts
Mit diesen zusätzlichen Funktionen könnte man das System ohne Einschränkung 3D-tauglich
nennen.
4.6. BEURTEILUNG
69
Während der Arbeit mit Spatial sind immer wieder kleine Probleme aufgetaucht, die hier noch
einmal angesprochen werden sollen:
Indexerstellung bei Objekttypen
Es ist durchaus möglich, den Datentyp MDSYS.SDO_GEOMETRY in einem Objekttyp unterzubringen und den Datentyp mit Inhalt zu füllen. Leider ist es nicht möglich, hierfür einen
Index zu erstellen. Aufgrund dessen musste der Objekttyp Objekt im objekt-relationalen
Datenmodell aus Abschnitt 3.2.1 in eine relationale Tabelle umgewandelt werden.
Keine 3D-Unterstützung durch SDO_API
Die Spatial Java Library ist zur Zeit nicht in der Lage, 3D-Objekte zu erstellen. Was per SQL
funktionierte, konnte mit der API nicht durchgeführt werden; Fehlermeldungen aller Art waren die Folge.
Limit von 999 Werten in SDO_ORDINATES
Wenn man per SQL Objekte mit mehr als 999 Werten im Feld SDO_ORDINATES übergeben
will, gibt es eine Fehlermeldung. Abhilfe schaffte hier ein sog. „Transactional Insert“. Dazu
wird die folgende PL/SQL Prozedur angelegt, zu der nur die Daten übermittelt werden. Der
Update-Befehl wird dann erst in dieser Prozedur (Stored Procedure) aufgerufen.
CREATE OR REPLACE PROCEDURE
INSERT_GEOM(GEOM MDSYS.SDO_GEOMETRY, objid INTEGER) IS
BEGIN
UPDATE objekt_reltab
SET world = (GEOM)
WHERE id_objekt = objid;
COMMIT;
END;
/
Vor dem Aufruf dieser Funktion müssen die Informationen mit einem DECLARE-Befehl zur
Übergabe an die Prozedur vorbereitet werden, erst dann wird die Prozedur aufgerufen.
DECLARE
geom mdsys.sdo_geometry:= mdsys.sdo_geometry(
3004, NULL, NULL,
mdsys.sdo_elem_info_array(
1, 1003, 1,
70
KAPITEL 4 – EIGNUNG VON ORACLE SPATIAL
16, 1003, 1,
31, 1003, 1,
46, 1003, 1,
61, 1003, 1,
76, 1003, 1,
91, 1003, 1,
103, 1003, 1,
115, 1003, 1
)
mdsys.sdo_ordinate_array(
50,50,50, 50,50,53, 50,58,53,
50,50,50, 56,50,50, 56,50,53,
56,50,50, 56,50,53, 56,58,53,
56,58,50, 56,58,53, 50,58,53,
50,58,53, 50,50,53, 53,50,56,
53,50,56, 56,50,53, 56,58,53,
50,58,53, 56,58,53, 53,58,56,
50,50,53, 56,50,53, 53,50,56,
50,58,53, 50,50,53, 49,50,52,
50,58,53, 50,50,53, 49,50,52,
BEGIN INSERT_GEOM(geom, 1000);
COMMIT;
END;
50,58,50,
50,50,53,
56,58,50,
50,58,50,
53,58,56,
53,58,56,
50,58,53,
50,50,53,
49,58,52,
49,58,52,
50,50,50,
50,50,50,
56,50,50,
56,58,50,
50,58,53,
53,50,56,
50,58,53
0,58,53)));
SDO_ELEM_INFO und SDO_ORDINATES
Zeigt man mit einem SELECT-Befehl den Datentyp MDSYS.SDO_GEOMETRY an und das
Objekt besitzt mehr als 99 Werte, also 33 Koordinaten, wird der Rest aus nicht nachvollziehbaren Gründen abgeschnitten. Dieser Fehler tritt nur bei der Ausführung über die JDBCSchnittstelle auf. Er tritt nicht auf, wenn man den SELECT-Befehl per Hand im SQLWorksheet eingibt. Erfreulicherweise beschränkt sich die 3D-Unfähigkeit der SDO_API nur
auf das Erstellen von 3D-Objekten, denn das Auslesen von 3D-Geometrien ist mit der API
möglich, so dass dieser Weg für die Ausgabe der Geometrien verwendet wurde.
Kapitel 5
Datenaustausch
Dieses Kapitel beschreibt die Werkzeuge, die den Datenaustausch mit der Datenbank vornehmen. Dazu gehören für den Import der Daten zwei Werkzeuge, von denen das eine Daten
der T-Mobile Deutschland GmbH in deren eigenem Datenformat importiert und das andere
VRML-Daten einlesen kann. In Abschnitt 5.2 wird die Erstellung von Spatial-Objekten erläutert und Abschnitt 5.3 beschäftigt sich mit den Export-Werkzeugen. Das eine exportiert die
Daten aus dem geometrisch-topologischen Modell und das andere verwendet nur den Inhalt
des Spatial-Layers. Die Selektion für den Export geschieht durch räumliche Anfragen.
5.1 Import
5.1.1 Daten der T-Mobile Deutschland GmbH
Mit freundlicher Genehmigung durch das Mobilfunk-Unternehmen T-Mobile Deutschland
GmbH konnte das System anhand von realen Daten evaluiert werden. Dabei handelt es sich
um einen Ausschnitt eines Gebäudemodells der Stadt Mainz mit etwa 10.000 Objekten, die
aus knapp 170.000 Koordinaten bestehen. Benötigt werden diese Daten zur rechnergestützten
Simulation der Ausbreitung von Funkwellen.
Mit Verfahren der photogrammetrischen Stereoauswertung werden Gebäude ab einer Grundfläche von 36 m² erfasst, die eine Mindesthöhe von 2,5 m besitzen. Für die Ausbreitung von
Funkwellen sind die Dachformen wichtig. Es wird unterschieden zwischen Flachdach, Pultdach, Satteldach, Walmdach und Zeltdach. Die Lagegenauigkeit der Gebäude liegt unter ±1
m, die Höhengenauigkeit beträgt 10% der Gebäudehöhe, mindestens aber ±0,5 m und höchstens ±2,0 m.
Abbildung 5.1: Beispielgebäude aus den T-Mobil-Daten. Es werden nur die 3DKoordinaten des Grundriss- und des Trauf-Polygons gespeichert.
71
72
KAPITEL 5 – DATENAUSTAUSCH
Die Daten liegen im Ascii-Format vor, wobei ein Gebäude durch ein Grundriss-Polygon, ein
Trauf-Polygon und je nach Dachform durch dessen Firstpunkte dargestellt wird. Zusätzlich
gibt es Angaben über die Dachform, die relative Gebäudehöhe und die absolute Höhe des
Gebäudes über NN als Mittelwert der Grundrisspunkte. Unter einem Grundriss-Polygon kann
man sich ein Polygon vorstellen, welches alle aufgenommen Grundriss-Punkte mit einander
verbindet. Analog dazu verhält es sich mit dem Trauf-Polygon, bei dem alle Traufpunkte mit
einander verbunden werden. Die Lage der Traufpunkte entspricht immer der Lage der Grundriss-Punkte, so dass von allen Traufpunkten auf den dazugehörigen Grundriss-Punkt herabgelotet werden kann (Siehe Abbildung 5.1). Die Lagekoordinaten liegen im Gauß-KrügerKoordinatensystem vor, die Höhe bezieht sich auf Normal Null.
Da das Dach nur durch seine Dachform und die entsprechenden Firstpunkte gegeben war,
hätte das Dach beim Import noch konstruiert werden müssen. Zur Evaluierung des Systems
reichte aber bereits die einfache Modellierung eines Gebäudes ohne sein Dach aus, so dass
nur Flachdach-Gebäude repräsentiert werden.
Mit dieser Modellierung können aber nur einfache Gebäude dargestellt werden. Deswegen
werden zusätzlich Innenhöfe oder Aufbauten mit der Kennziffer des dazugehörigen Gebäudes
gespeichert, wobei die Kennziffer ein negatives Vorzeichen erhält und um eine aufsteigende
dreistellige Zahl ergänzt wird.
Im Hinblick auf die Aggregationsmöglichkeit des Datenmodells war es sinnvoll, die Aufbauten zusammen mit den dazugehörigen Gebäuden zu einem Aggregat zu verbinden.
Nach dem Einlesen der Koordinaten können Trauf- und Grundriss-Polygon direkt als Maschen in der Datenbank gespeichert werden (Abbildung 5.2a). Um das Gebäude zu schließen,
müssen zusätzlich noch die Randflächen (Gebäudewände) erstellt werden. An Abbildung 5.2b
kann man sehen, dass die erste Fläche sich aus den Kanten 1, 2, 3 und 5 zusammensetzt, was
dem Prinzip entspricht, jede Kante nur einmal zu speichern. So besteht die zweite Fläche aus
den Kanten 4, 5, 6 und 8 und die letzte Fläche besitzt die Kanten 16, 17, 18 und 2.
a)
b)
16
13
17
15
18
2
1
4
8
3
7
5
10 14
11
6
9
12
Abbildung 5.2: Generierung der Randflächen. Die erste Fläche besitzt die Kanten 1, 2,
3 und 5. Die letzte besitzt die Kanten 16, 17, 18 und 2.
5.1. IMPORT
73
Speicherung im objekt-relationalen Datenmodell
Auf diese Weise werden also in der Tabelle Knoten_objtab (Siehe Abbildung 3.7) die
Koordinaten von Trauf- und Grundriss-Polygon gespeichert, die Kanten dieser Polygone sowie die Lote aller Traufpunkte auf die Grundrisspunkte werden in der Tabelle Kante_objtab abgelegt. Zur Berücksichtigung der Umlaufrichtung wird in der Liste der Kante,
die eine Fläche repräsentieren, zusätzlich noch eine „Sortiervariable“ gespeichert. Sortiert
man diese Liste von Kanten einer Fläche, ergibt sich daraus automatisch die richtige Umlaufrichtung. Alle Flächen werden so in der Tabelle Ring_objtab gespeichert. Da das Datenmodell von T-Mobile keine Löcher in den Polygonen vorsieht, wird ein Ring von einer Masche immer mit dem Attribut Aussen_ref referenziert. Alle Flächen werden auf diese Weise in einer Liste von Maschen gespeichert und so einem Volumen zugeordnet. Dieses Volumen wird in der Tabelle Volumengeometrie_objtab durch das Attribut Volumen_ref referenziert, wobei diese Volumengeomtrie Teil eines Aggregats sein kann
(aber nicht muss!). Zum „Objekt“ wird dieses Volumen mit dem Fremdschlüssel Volumen_ref in der Tabelle Objekt_reltab. In dieser Tabelle befinden sich alle Objekte des
3D-Stadtmodells. Von der Linie bis zum Aggregat aus mehreren Volumen besitzt jedes Objekt einen Eintrag in dieser Tabelle.
Die Integrität dieser Daten wird beim Import nicht überprüft, weil davon ausgegangen wird,
dass die Eingangsdaten diesbezüglich bereits untersucht worden sind. Durch die oben beschriebene Vorgehensweise ist jedoch sichergestellt, dass jedes Volumen geschlossen ist.
5.1.2 VRML
In Kapitel 2.4 wurde kurz auf den Zusammenhang zwischen den Koordinaten und deren Koordinatenindex eingegangen. Im Beispiel aus Abbildung 2.8 besitzt ein IndexedFaceSet
genau ein Fläche. Eine andere Variante besteht darin, ein IndexedFaceSet aus mehreren
Flächen zusammenzustellen. In diesem Fall werden alle verwendeten Koordinaten nur einmal
in Coordinate gespeichert und in coordIndex mehrmals verwendet. Das spart zwar
Speicherplatz, kann aber bei der Verwendung von Texturen zu Problemen führen. Mit ganz
schlechtem Beispiel geht hier ArcScene1 voran, welches ein ganzes 3D-Stadtmodell in ein
einziges IndexedFaceSet „einstampft“.
Das Werkzeug für den Import von VRML-Daten wurde mit verschiedenen Dateien aus dem
Internet und des Institutes für Photogrammetrie2 getestet. Es durchsucht eine VRML-Datei bis
es auf ein IndexedFaceSet trifft, dessen Fläche(n) als Maschen in der Datenbank gespeichert werden. Sind mehrere Flächen in einem IndexedFaceSet vorhanden, wie es bei 2
der Fall ist, wird davon ausgegangen, dass alle Flächen eines Objekts in diesem IndexedFaceSet abgelegt sind. Der andere Fall besteht darin, dass ein IndexedFaceSet (vergl. Abbildung 2.8) nur genau eine Fläche beinhaltet.
1
2
: Gehört zu ArcGIS 3D Analyst von ESRI, www.esri.com
: http://www.ipb.uni-bonn.de/ipb/projects/buildings/nussallee2.wrl.gz
74
KAPITEL 5 – DATENAUSTAUSCH
Dann werden alle Flächen, die sich in einem Gruppenknoten finden lassen, einem Volumen
zugeordnet.
Im Vergleich zu den T-Mobile-Daten müssen hier keine Flächen mehr konstruiert werden, ob
die Gebäude aus den VRML-Daten jedoch geschlossen sind, kann an dieser Stelle nicht beurteilt werden. Ebenso wenig werden andere Integritätsmerkmale überprüft, was in Zukunft aber
eine Aufgabe der Datenbank sein sollte.
5.1.3 Probleme und Verbesserungen
Bei den T-Mobile-Daten wurden nicht alle verfügbaren Informationen verarbeitet. Die Dachflächen fehlen, die relative Gebäudehöhe und die absolute Höhe des Gebäudes blieben unberücksichtigt. Die beiden letztgenannten Werte sollten aber ohnehin nicht in die Datenbank
aufgenommen werden, da solche Informationen mit geeigneten Funktionen automatisch ermittelt werden können. Ein Problem stellen jedoch die Grundrisspolygone dar. Im Gegensatz
zu den Traufpolygonen kann es passieren, dass diese Flächen nicht mehr in einer Ebene liegen. So etwas passiert beispielsweise dann, wenn ein Haus am Hang steht und die Punkte des
Grundrisspolygons unterschiedliche Höhen aufweisen. Streng genommen müssten diese Flächen erst mit einem Algorithmus trianguliert werden, bevor sie in die Datenbank eingehen. Da
einerseits Spatial solche Flächen akzeptiert und andererseits lediglich ein Prototyp entwickelt
werden sollte, wurde auf eine Triangulation verzichtet.
Das Werkzeug für den VRML-Import ist als wesentlich fragiler einzustufen. Aufgrund der
verschiedensten Möglichkeiten der Datenstrukturierung in einer VRML-Datei stößt dieses
Werkzeugen sehr schnell an seine Grenzen. Kaum lösbar werden die Probleme bei der Implementierung dann, wenn von der hierarchischen Gruppierung in einem VRML Scene Graph
kein Gebrauch gemacht wird, und, wie im vorhergehenden Abschnitt beschrieben, ganze 3DModelle in einem einzigen Kindknoten abgelegt werden. Es ist also grundsätzlich nicht auszuschließen, dass der VRML-Import für zukünftige VRML-Dateien noch angepasst werden
muss. Wirkliche Verbesserung würde hier Java3D1 bringen. Dabei handelt es sich um eine
Programmierschnittstelle für Java, mit der die Erstellung, Darstellung und Kontrolle über 3DObjekte möglich ist. Der Vorteil für den Import der VRML-Dateien liegt darin begründet,
dass man keine eigene Routine zum Einlesen der VRML-Daten benötigt, sondern dieser
Schritt von Java3D übernommen wird. Andere Vorteile, die Java3D mit sich bringt, werden in
Kapitel 7 genauer beschrieben.
1
: http://java.sun.com/products/java-media/3D/
5.2. ERSTELLUNG VON SPATIAL-OBJEKTEN
75
5.2 Erstellung von Spatial-Objekten
Beim Import werden die Geometrien noch nicht im Spatial-Layer eingetragen. Diese Aufgabe
wird von einem Werkzeug übernommen, das mit Hilfe eines SQL-Befehls eine bestimmte
Menge an Objekten auswählt und deren Geometrie in einem Spatial-Layer ablegt. Das Werkzeug besteht aus zwei Funktionen. Mit der einen werden nicht-aggregierte Objekte erfasst, mit
der anderen Funktion nur aggregierte. Nach der Durchführung beider Funktionen wird der
räumliche Index automatisch neu erstellt. Zum besseren Verständnis werden in diesem Abschnitt nur Gebäude aggregiert.
Erfassung von nicht aggregierten Gebäuden
SELECT
o.id_volumengeom,
m.masche_ref.aussen_ref.id_ring,
l.kante_ref.anfang_ref.id_knoten,
l.kante_ref.anfang_ref.x,
l.kante_ref.anfang_ref.y,
l.kante_ref.anfang_ref.z,
l.kante_ref.ende_ref.id_knoten,
l.kante_ref.ende_ref.x,
l.kante_ref.ende_ref.y,
l.kante_ref.ende_ref.z,
l.sortvar
FROM
ring_objtab r,
volumen_objtab v,
volumengeometrie_objtab o,
TABLE(r.kantenliste_ntab) l,
TABLE(v.maschenliste_ntab) m
WHERE
m.masche_ref.aussen_ref.id_ring = r.id_ring AND
o.volumen_ref.id_volumen = v.id_volumen
ORDER BY r.id_ring, l.sortvar
Abbildung 5.3 : SQL-Befehl zur Selektion aller Objekte, die im geometrischtopologischen Datenmodell gespeichert sind
Der SQL-Befehl in Abbildung 5.3 wählt alle Volumengeometrien aus, die sich im geometrisch-topologischen Modell befinden. Flächen- und Liniengeometrien wurden mangels existierender Daten nicht mit aufgeführt, wobei diese aber nach dem gleichen Muster zu selektie-
76
KAPITEL 5 – DATENAUSTAUSCH
ren wären. Die benötigten Informationen zur Erstellung der Spatial-Geometrie eines Gebäudes sind:
•
•
•
•
•
Die Objekt_ID, um alle Ringe einem bestimmten Gebäude zuordnen zu können.
Die Ring_ID, um alle Knoten dem jeweiligen Ring zuordnen zu können.
Die Knoten_ID des Anfangs- und Endknotens der Kanten, aus denen ein Ring besteht
Die Koordinaten des Anfangs- und des Endknotens einer Kante.
Die Sortiervariable, welche die Kanten bezüglich eines Ringes in der richtigen Reihenfolge sortiert, mit dem Befehl ORDER BY in der letzten Zeile.
Die Übernahme von inneren Ringen ist an dieser Stelle aus zwei Gründen nicht von Interesse:
Zum einen besitzen die gespeicherten Gebäude keine Fenster, somit auch keine inneren Ringe
in den Maschen. Zum anderen wäre es für den räumlichen Index sinnlos, innere Ringe zu
speichern, weil diese zur räumlichen Ausdehnung eines Gebäudes nicht beitragen würden.
Grundsätzlich ist die Möglichkeit der Speicherung von Polygonen mit Löchern aber durch
Spatial gegeben.
Um ein Gebäude im Spatial-Layer einzutragen, müssen die dazugehörigen Flächen gemäß
dem Geometriebeispiel in Abschnitt 4.3 in MDSYS.SDO_ORDINATE_ARRAY abgelegt werden. Genauso ist der jeweilige Geometrietyp (1003, 1 = geschlossenes Polygon) sowie die
Position der ersten Koordinate jeder Fläche in MDSYS.SDO_ELEM_INFO_ARRAY zu speichern. Wegen des Limits von 999 Parametern in MDSYS.SDO_ORDINATE_ARRAY (vgl.
Abschnitt 4.6) können diese Werte nicht direkt an die Datenbank übermittelt werden, sondern
müssen erst den Umweg über die Stored Procedure nehmen. Auf diese Weise wird dann jedes
einzelne Gebäude als neue Geometrie in der Tabelle objekt_reltab im Spatial-Layer
world eingetragen.
Erfassung von aggregierten Gebäuden
Es werden genau wie zuvor Volumengeometrien ausgewählt, deren aggregierte Gebäude(teile) zusammen im Spatial Layer abgelegt werden sollen. Durch die rekursive Aggregation ergeben sich hier jedoch einige Änderungen. Um alle Aggregate (Zusammengesetzte Gebäude) in einer Tabelle anzeigen zu lassen, kann man folgenden SQL-Befehl verwenden:
SELECT g.id_volumengeom
FROM objekt_reltab o, volumengeometrie_objtab g
WHERE g.id_volumengeom = o.volumen_ref AND g.is_aggr = 1;
Dieser einfache Befehl muss der eigentlichen Rekursion vorgeschaltet werden, weil der folgende SQL-Befehl nur die aggregierten Volumengeometrien von einer Volumengeometrie
(Im Beispiel die Volumengeometrie mit der ID 16) auflisten kann. Entscheidend für die Rekursion im diesem Beispiel ist der Befehl START WITH ... CONNECT BY PRIOR. Er
startet die Rekursion in der Volumengeometrie 16 und es werden alle aggregierten Volumen-
5.2. ERSTELLUNG VON SPATIAL-OBJEKTEN
77
geometrien angezeigt, die in der nested table stehen. Gleichzeitig werden aber alle diese gefundenen Einträge (m.volumengeom_ref.id_volumengeo) als neue Startwerte verwendet, um die Rekursion dort weiterzuführen. Dieser Vorgang funktioniert unabhängig von
der Rekursionstiefe und auch unabhängig davon, ob der Rekursionsgraph ausgeglichen ist
oder nicht.
SELECT
v.id_volumen,
m.masche_ref.aussen_ref.id_ring,
l.kante_ref.anfang_ref.id_knoten,
l.kante_ref.anfang_ref.x,
l.kante_ref.anfang_ref.y,
l.kante_ref.anfang_ref.z,
l.kante_ref.ende_ref.id_knoten,
l.kante_ref.ende_ref.x,
l.kante_ref.ende_ref.y,
l.kante_ref.ende_ref.z,
l.sortvar,
16
FROM
ring_objtab r,
volumen_objtab v,
TABLE(r.kantenliste_ntab) l,
TABLE(v.maschenliste_ntab) m
WHERE
v.id_volumen IN (
SELECT m.volumengeom_ref.volumen_ref.id_volumen
FROM
volumengeometrie_objtab o,
TABLE(o.volumenaggregat_ntab) m
WHERE m.volumengeom_ref.volumen_ref.id_volumen > 0
START WITH o.id_volumengeom
IN (
SELECT o.id_volumengeom
FROM volumengeometrie_objtab o
WHERE o.is_aggr = 1 AND o.id_volumengeom = 16)
CONNECT BY PRIOR
m.volumengeom_ref.id_volumengeom = o.id_volumengeom
) AND m.masche_ref.aussen_ref.id_ring = r.id_ring
ORDER BY r.id_ring, l.sortvar;
78
KAPITEL 5 – DATENAUSTAUSCH
Entsprechend dem o.g. Beispiel werden also in der Zeile der Volumengeometrie 16 (entspricht im Beispiel einem zusammengesetzten Gebäude) die Geometrien aller aggregierten
Gebäudeteile eingetragen. Diese Gebäudeteile liegen geometrisch im Spatial-Layer nun
zweimal vor. Einmal in der Zeile, in der nur der einzelne Gebäudeteil liegt und einmal zusammen mit den anderen Gebäudeteilen in der gerade eben erstellten Zeile.
a)
b)
c)
x
x
Abbildung 5.3: Gebäudeteil a und b werden zu Gebäude c aggregiert.
Belässt man die nun doppelt vorliegenden Geometrien im Spatial-Layer, würde diese Redundanz bei einer räumlichen Anfrage zu einem Problem führen. Bei der Suche, in welchem Gebäude sich der Punkt x befindet, würde die Antwort a und c lauten. Aus diesem Grund müssen
nach der Erstellung des Gebäudes c die Gebäudeteile a und b aus dem Spatial-Layer gelöscht
werden. Das Suchergebnis lautet jetzt nur noch c und ist somit eindeutig. Auf diese Weise
gehen keine Informationen verloren, denn a und b liegen weiterhin getrennt vor, sie besitzen
nur keinen Eintrag im Spatial-Layer.
Würde man erst gar nicht das Gebäude c erstellen, träte ein anderes Problem auf. Bei der
räumlichen Anfrage, die alle Häuser im Umkreis von 100 m ausgeben soll, würde evtl. der
Gebäudeteil b ohne den Teil a ausgegeben, wenn a, nicht aber b, außerhalb des Suchkreises
liegt. Dann würde jedoch der Eindruck entstehen, dass dieses Gebäude keine Garage oder
Anbau besitzt.
5.3. EXPORT
79
5.3 Export
Die Selektion für den Export wird durch die räumlichen Funktionen von Spatial unterstützt.
Der Benutzer kann die 3D-Koordinaten einer Bounding Box angeben und zusätzlich einen
Maskentyp (Abbildung 4.8) wählen, der Objekte bezüglich ihrer 2D-Interaktion filtert. Das
Suchergebnis wird dann in einer VRML-Datei ausgegeben (vgl. Abbildung 2.8). VRMLKoordinaten sind bislang nur in single-precision definiert (32Bit). Da Gauß-KrügerKoordinaten bereits 7 Vorkommastellen besitzen, treten Fehler im Dezimeter-Bereich auf.
Aufgrund dessen kann der Benutzer vor dem Export zwischen Gauß-Krüger- oder lokalen
Koordinaten auswählen. Ist letzteres der Fall, wird der Ursprung des lokalen Koordinatensystems im Header der VRML-Datei in Gauß-Krüger-Koordinaten angegeben.
Der Scene Graph der VRML-Datei besitzt in der obersten Ebene ausschließlich Gruppenknoten, von denen jeder einzelne ein Objekt (Gebäude) repräsentiert. Dessen Kindknoten besitzen
jeweils einen Objektknoten, der ein IndexedFaceSet mit einer Fläche beinhaltet. Das
Geometriebeispiel aus Abschnitt 4.3 würde demnach einen Gruppenknoten besitzen, der wiederum über 10 Kindknoten mit jeweils einem IndexFaceSet verfügt.
Daten können über zwei verschiedene Wege exportiert werden. Zum einen aus dem geometrisch-topologischen Modell und zum anderen aus dem Spatial-Layer. Der Export über den
Spatial-Layer ist zwar schneller (vgl. Kapitel 6), aber dafür besitzt dieser keine topologischen
Informationen.
5.3.1 Geometrisch-topologisches Modell
Dieses Modell stellt nicht nur die Flächen zur Verfügung, die ein Gebäude repräsentieren,
sondern kann auch Auskunft über die Nachbarn einer Fläche geben, ob sie Löcher enthält, wie
sie orientiert ist und welches Material sie besitzt. Zudem kommen noch die Informationen
über Aggregate hinzu. Beim Export in eine VRML-Datei gehen einige dieser topologischen
Merkmale verloren, was jedoch in der Datenstruktur von VRML begründet liegt, die diese
Informationen nicht aufnehmen kann. Aber gerade bei VRML-Daten spielt die Orientierung
und das Material eine sehr große Rolle, denn VRML-Daten dienen primär der Visualisierung.
Da die Eingangsdaten der T-Mobile Deutschland GmbH über keine unterschiedlichen Materialien verfügen, wurden Orientierung und Material einer Fläche nicht exportiert.
Der folgende SELECT-Befehl wählt die Geometrie aller Volumen aus, die in der ersten
WHERE-Klausel stehen. Diese beinhaltet zwei SELECT-Befehle, deren Ergebnis Volumen
sind und mit dem Befehl UNION (entfernt doppelte Zeilen) zusammengefasst werden. Der
eine SELECT-Befehl erfasst alle nicht-aggregierten Volumen und der andere behandelt nur
die aggregierten Volumen. Beide wenden jedoch die gleiche Methode zur räumlichen Selektion an, die bereits in Abschnitt 4.2 erläutert wurde.
80
KAPITEL 5 – DATENAUSTAUSCH
SELECT
v.id_volumen,
m.masche_ref.aussen_ref.id_ring,
l.kante_ref.anfang_ref.id_knoten,
l.kante_ref.anfang_ref.x,
l.kante_ref.anfang_ref.y,
l.kante_ref.anfang_ref.z,
l.kante_ref.ende_ref.id_knoten,
l.kante_ref.ende_ref.x,
l.kante_ref.ende_ref.y,
l.kante_ref.ende_ref.z,
l.sortvar
FROM
ring_objtab r,
volumen_objtab v,
TABLE(r.kantenliste_ntab) l,
TABLE(v.maschenliste_ntab) m
WHERE
v.id_volumen IN(
SELECT g.volumen_ref.id_volumen
FROM volumengeometrie_objtab g, (
SELECT r.id_objekt, r.volumen_ref, r.world
FROM objekt_reltab r
WHERE mdsys.sdo_filter(
r.world, mdsys.sdo_geometry(
3003,NULL,NULL,
mdsys.sdo_elem_info_array(1,1003,3),
mdsys.sdo_ordinate_array(x1,y1,z1, x2,y2,z2)
),'querytype=window'
) = 'TRUE'
) S
WHERE
s.volumen_ref = g.id_volumengeom AND is_aggr = 0 AND
mdsys.sdo_geom.relate(
S.world, 'ANYINTERACT', mdsys.sdo_geometry(
3003, NULL, NULL, mdsys.sdo_elem_info_array(1,1003,3),
mdsys.sdo_ordinate_array(x1,y1,z1, x2,y2,z2)
),0.5
) = 'TRUE'
UNION
SELECT m.volumengeom_ref.volumen_ref.id_volumen
FROM volumengeometrie_objtab o, TABLE(o.volumenaggregat_ntab) m
WHERE m.volumengeom_ref.volumen_ref.id_volumen > 0
START WITH o.id_volumengeom IN (
5.3. EXPORT
81
SELECT g.id_volumengeom
FROM volumengeometrie_objtab g, objekt_reltab o, (
SELECT r.id_objekt, r.world
FROM objekt_reltab r
WHERE mdsys.sdo_filter(
r.world, mdsys.sdo_geometry(
3003, NULL, NULL,
mdsys.sdo_elem_info_array(1,1003,3),
mdsys.sdo_ordinate_array(x1,y1,z1, x2,y2,z2)
), 'querytype=window'
) = 'TRUE'
) S
WHERE
o.volumen_ref = g.id_volumengeom AND mdsys.sdo_geom.relate(
S.world, 'ANYINTERACT', mdsys.sdo_geometry(
3003, NULL, NULL,
mdsys.sdo_elem_info_array(1,1003,3),
mdsys.sdo_ordinate_array(x1,y1,z1, x2,y2,z2)
),0.5
) = 'TRUE'
) CONNECT BY PRIOR m.volumengeom_ref.id_volumengeom = o.id_volumengeom
) AND m.masche_ref.aussen_ref.id_ring = r.id_ring
ORDER BY r.id_ring, l.sortvar
5.3.2 Spatial-Layer
Der Spatial Layer diente bisher nur der Beantwortung räumlicher Anfragen, z.B. welche Objekte innerhalb einer Suchbox liegen oder wie zwei Objekte mit einander interagieren. Das
Geometriebeispiel aus Abschnitt 4.3 zeigt aber, dass bei der Speicherung in einem SpatialLayer zwar die Topologie, nicht aber die Geometrie verloren geht. Es können also die gleichen Informationen in eine VRML-Datei exportiert werden, wie das im vorherigen Abschnitt
der Fall ist. Der SELECT-Befehl dazu ist deutlicher einfacher als im geometrischtopologischen Modell und wurde bereits in Abschnitt 4.2 vorgestellt.
Im folgenden Kapitel sollen die hier vorgestellten Prozesse auf ihre Performance untersucht
und beurteilt werden. Der anschließende Ausblick wird das Potential dieses Systems beschreiben und mögliche Erweiterungen für die Zukunft nennen.
Kapitel 6
Analyse
Dieses Kapitel untersucht die Performance und den Speicherverbrauch der Datenbank beim
Import und Export von realen Daten und beurteilt die Ergebnisse kritisch.
Die Testumgebung besteht aus einem AMD Athlon XP 2100+ (1800MHz) mit 512MB DDRRAM auf einem WindowsXP Betriebssystem. Oracle liegt in der Version 9.2.0.1.0 vor. Sämtliche Ergebnisse werden mit den zuvor beschriebenen Werkzeugen (vgl. Kapitel 5) ermittelt.
Abbildung 6.1 zeigt einen Screenshot des Java-Programms. Bei der Erstellung der Datenbank
wurde die Speicherverwaltung so konfiguriert, dass 90% des freien Speichers genutzt werden
können, wodurch der Datenbank ca. 300MB Arbeitsspeicher zur Verfügung stehen.
Abbildung 6.1: Screenshot des Javaprogramms
82
6.1 SPEICHERPLATZBEDARF
83
6.1 Speicherplatzbedarf
Je nachdem, welche Features bei einer Datenbank zusätzlich installiert werden, ändert sich
auch der Speicherplatzbedarf auf der Festplatte. Bei der Konfiguration mit dem Oracle Database Configuration Assistent wurden aus Kompatibilitätsgründen alle Einstellungen unverändert übernommen. Nach der Erstellung der Datenbank betrug der Platzbedarf 1,1 MBytes.
Dateiname
Dateigröße (Bytes)
CONTROL01.CTL
1.613.824
CONTROL02.CTL
1.613.824
CONTROL03.CTL
1.613.824
DRSYS01.DBF
20.979.712
INDX01.DBF
26.222.592
REDO01.LOG
104.858.112
REDO02.LOG
104.858.112
REDO03.LOG
104.858.112
SYSTEM01.DBF
346.038.272
TEMP01.DBF
41.951.232
TOOLS01.DBF
10.493.952
UNDOTBS01.DBF
277.880.832
USERS01.DBF
26.222.592
XDB01.DBF
39.985.152
In der Datei SYSTEM01.DBF wird der Inhalt der Datenbank aufbewahrt. Signifikante Änderungen der Dateigröße bei Benutzung der Datenbank sind lediglich bei dieser und bei der Datei UNDOTBS01.DBF zu beobachten. Die Datei TEMP01.DBF dient der Zwischenspeicherung von Daten, ihre Größe ändert sich schnell, nachdem mehrere SQL-Abfragen gestellt
wurden. Hier hat der Benutzer jedoch Möglichkeiten, den Speicherbedarf zu begrenzen. Abbildung 6.2 zeigt den Verlauf des Speicherverbrauchs der Dateien SYSTEM01.DBF und UNDOTBS01.DBF bei zunehmendem Datenbestand. Geht man von einem annähernd linearen
Verhältnis zwischen Speicherbedarf und der Anzahl der Gebäude aus, bedeutet das etwa 80
MBytes pro 10.000 Gebäude. Die Eingangsdaten betrugen für die annähernd gleiche Menge
lediglich 6,7 Mbytes. Es ist jedoch zu berücksichtigen, dass in der Datenbank zusätzlich noch
die Randflächen generiert, etliche Indizes und der Spatial-Layer erstellt wurden.
84
KAPITEL 6 – ANALYSE
500
450
MByte
400
SYSTEM01.DBF
UNDOBTS01.DBF
350
300
250
0
2000
4000
6000
Gebäude
8000
10000
12000
Abbildung 6.2: Speicherplatzverbrauch der Systemdateien abhängig von der Menge
der gespeicherten Gebäude
6.2 Import
Weil keine ausreichend große Menge an VRML-Daten vorliegt, wird lediglich der Import der
realen Daten der T-Mobile Deutschland GmbH analysiert. In der o.g. Testumgebung werden
dabei pro Minute ca. 100 Gebäude importiert. Die anschließende Erstellung der SpatialObjekte aus den vorhanden Daten verarbeitet etwa 230 Gebäude pro Minute. Bei 10.000 Gebäuden bedeutet das insgesamt Rechenzeit von knapp 145 Minuten.
6.3 Export
Da der Export der Daten die wesentliche Aufgabe dieses Systems darstellt, werden die dazu
vorhandenen Werkzeuge an dieser Stelle besonders genau untersucht. Der Export geschieht
ausschließlich in VRML-Dateien und ist einerseits aus dem topologischen Datenmodell und
anderseits aus dem Spatial-Layer möglich. Diese beiden Varianten werden im folgenden gegenübergestellt.
6.3. EXPORT
85
6.3.1 Topologie-Query
Die SQL-Abfrage (vgl. Abschnitt 5.3.1) für das topologische Datenmodell (im folgenden
„Topologie-Query“ genannt) wählt alle Koordinaten der Gebäude aus, die sich innerhalb einer
vorgegebenen Suchbox befinden. Gebäude, die sich aus mehreren Aggregaten zusammensetzten werden dabei ebenfalls berücksichtigt. Das Topologie-Query ist relativ komplex und wird
daher zusätzlich für die folgenden Analysen in seine Komponenten aufgespaltet. Diese Komponenten sind sogenannte Sub-Querys, also Unterabfragen innerhalb eines SELECT-Befehls.
Die Aufgabe dieser Komponenten sind die Rekursion, die räumliche Anfrage, der Bezug zwischen Objekt und Volumen und die Auswahl der Koordinaten der gesuchten Objekte.
Bei der Untersuchung stellt man fest, dass ein eindeutiger Zusammenhang zwischen der gespeicherten Datenmenge und der Dauer einer SQL-Anfrage besteht. Deshalb sind die folgenden Diagramme nach der Menge der abgespeicherten Daten unterteilt. Da sich die Daten der
T-Mobile Deutschland GmbH auf drei Dateien verteilen, werden die verschiedenen SQLAbfragen nach dem Import einer jeden Datei erstellt. Daraus ergeben sich drei Diagramme,
mit 2357, 5716 und mit 9943 gespeicherten Gebäuden.
25
Objekt-Bezug
Spatial
Sekunden
20
15
3
Rekursion
3
Geometrie
2
2
2
3
1
1
10
1
1
5
3
14
11
1
1
1
2
3
6
3
0
50
500
1000
Abgefragte Gebäude
2000
2357
Abbildung 6.3: Dauer der kompletten SQL-Abfrage für eine unterschiedliche Anzahl
von Gebäuden; Eine SQL-Abfrage besteht aus vier verschiedenen
Komponenten: der Auswahl der Geometrie, der Rekursion, der
Spatial-Abfrage und des Objekt-Bezugs.
86
KAPITEL 6 – ANALYSE
Bei 2357 Gebäuden in der Datenbank (Abbildung 6.3) sind die Ergebnisse noch nicht auffällig. Die Dauer des kompletten Topologie-Querys (Gesamthöhe einer Säule) richtet sich nach
der Anzahl der abgefragten Gebäude, wobei eine wirkliche Abhängigkeit nur für die Komponente „Geometrie“ nachgewiesen werden kann. Die anderen Komponenten verhalten sich fast
konstant.
Die einzelnen Komponenten des Topologie-Querys werden durch Differenz-Bildung zweier
SQL-Abfragen ermittelt. So ergibt sich z.B. der „Objekt-Bezug“ aus der Differenz der kompletten SQL-Abfrage und einer Abfrage, in welcher das Sub-Query für den „Objekt-Bezug“
nicht mehr existiert. Die o.g. Sub-Querys sind im folgenden aufgelistet:
Sub-Query „Objekt-Bezug“
Hier wird der Zusammenhang zwischen dem Objekt und der Volumengeometrie hergestellt
und gleichzeitig nur Elemente ausgewählt, die nicht aggregiert sind.
SELECT g.volumen_ref.id_volumen
FROM volumengeometrie_objtab g
WHERE s.volumen_ref = g.id_volumengeom AND is_aggr = 0;
Sub-Query “Spatial“
Dieses Sub-Query wählt zunächst alle Objekte innerhalb einer 3D-Box anhand seiner Indizes
(SDO_FILTER) aus und überprüft diese Ergebnis noch mit der 2D-Funktion von
SDO_RELATE.
SELECT g.volumen_ref.id_volumen
FROM volumengeometrie_objtab g, (
SELECT r.id_objekt, r.volumen_ref, r.world
FROM objekt_reltab r
WHERE mdsys.sdo_filter(
r.world, mdsys.sdo_geometry(
3003,NULL,NULL,
mdsys.sdo_elem_info_array(1,1003,3),
mdsys.sdo_ordinate_array(
3445646.0,5539951.0,1.0,3446021.0,5540252.0,9999.0)
),'querytype=window'
) = 'TRUE'
) S
WHERE
s.volumen_ref = g.id_volumengeom AND is_aggr = 0 AND
mdsys.sdo_geom.relate(
S.world, 'ANYINTERACT', mdsys.sdo_geometry(
3003, NULL, NULL, mdsys.sdo_elem_info_array(1,1003,3),
6.3. EXPORT
87
mdsys.sdo_ordinate_array(
3445646.0,5539951.0,1.0,3446021.0,5540252.0,9999.0)
),0.5
Sub-Query „Rekursion“
Wie beim Sub-Query Spatial werden hiermit die Objekte innerhalb einer 3D-Box ausgewählt,
nur dass hier die Objekte ausgegeben werden, die Aggregate besitzen. Die ID’s aller aggregierten Objekte wird durch Rekursion ermittelt und an den übergeordneten SELECT-Befehl
übergeben.
SELECT m.volumengeom_ref.volumen_ref.id_volumen
FROM volumengeometrie_objtab o,TABLE(o.volumenaggregat_ntab) m
WHERE m.volumengeom_ref.volumen_ref.id_volumen > 0
START WITH o.id_volumengeom IN (
SELECT g.id_volumengeom
FROM volumengeometrie_objtab g, objekt_reltab o, (
SELECT r.id_objekt, r.world
FROM objekt_reltab r
WHERE mdsys.sdo_filter(
r.world, mdsys.sdo_geometry(
3003, NULL, NULL,
mdsys.sdo_elem_info_array(1,1003,3),
mdsys.sdo_ordinate_array(
3446733.79,5549996.27,142.8,
3445133.79,5539196.27,104.8)
), 'querytype=window'
) = 'TRUE'
) S
WHERE
o.volumen_ref = g.id_volumengeom AND
mdsys.sdo_geom.relate(
S.world, 'ANYINTERACT', mdsys.sdo_geometry(
3003, NULL, NULL,
mdsys.sdo_elem_info_array(1,1003,3),
mdsys.sdo_ordinate_array(
3446733.79,5549996.27,142.8,
3445133.79,5539196.27,104.8)
),0.5
) = 'TRUE'
) CONNECT BY PRIOR
m.volumengeom_ref.id_volumengeom = o.id_volumengeom
88
KAPITEL 6 – ANALYSE
Haupt-Query „Geometrie“
Hierbei handelt es sich um das Query, welches die Ergebnisse aus den verschiedenen SubQuerys in seiner WHERE-Klausel vereinigt und dann die gefundenen Objekte mit Ihren Koordinaten ausgibt.
SELECT
v.id_volumen,
m.masche_ref.aussen_ref.id_ring,
l.kante_ref.anfang_ref.id_knoten,
l.kante_ref.anfang_ref.x,
l.kante_ref.anfang_ref.y,
l.kante_ref.anfang_ref.z,
l.kante_ref.ende_ref.id_knoten,
l.kante_ref.ende_ref.x,
l.kante_ref.ende_ref.y,
l.kante_ref.ende_ref.z,
l.sortvar
FROM
ring_objtab r, volumen_objtab v,
TABLE(r.kantenliste_ntab) l,
TABLE(v.maschenliste_ntab) m
WHERE
v.id_volumen IN() AND
m.masche_ref.aussen_ref.id_ring = r.id_ring;
Abbildung 6.4 zeigt das gleiche Balkendiagramm wie zuvor, allerdings hier mit mehr als doppelt so vielen Gebäuden in der Datenbank. Nicht nur die Abfrage der reinen Geometrien verlangsamt sich im Vergleich zu Abbildung 6.3 deutlich, sondern die Rekursion nimmt wesentlich mehr Zeit in Anspruch. Der geringe Anteil der Rekursion bei der Auswahl aller Gebäude
scheint in der Datenbank sehr effizient gelöst zu sein. In der kompletten SQL-Abfrage (vgl.
Abschnitt 5.3.1) führt der Befehl UNION zwei Suchergebnisse zusammen und löscht dabei
doppelte Zeilen. In dem Moment, wo mit dem ersten Select-Befehl bereits alle gesuchten Gebäude aufgedeckt werden, überspringt UNION das Rekursions-Query, weil dort keine zusätzlichen Gebäude mehr gefunden werden können.
6.3. EXPORT
89
60
Objekt-Bezug
50
Spatial
7
Rekursion
5
40
Sekunden
Geometrie
7
30
4
3
11
20
39
12
10
0
1
28
12
11
15
9
6
3
50
500
1000
2000
4000
5716
Abgefragte Gebäude
Abbildung 6.4: Die Datenbank enthält jetzt 5716 Gebäude. Die Rekursion nimmt deutlich mehr Zeit in Anspruch, allerdings nicht bei der Abfrage aller
Geometrien.
Sekunden
100
90
Objekt-Bezug
80
Spatial
70
Rekursion
60
Geometrie
6
7
5
6
5
5
4
16
50
20
40
72
26
30
20
24
25
31
10
0
55
25
6
9
12
50
500
1000
18
2000
4000
8000
9943
Abgefragte Gebäude
Abbildung 6.5: Die Datenbank beinhaltet nun 9943 Gebäude. Die Dauer zur Verarbeitung der Rekursion hat sich proportional zur Datenmenge verdoppelt.
90
KAPITEL 6 – ANALYSE
Die geringe Dauer der Rekursion bei 8000 Objekten (16 Sekunden) wie auch bei 4000 Objekten in Abbildung 6.4 (4 Sekunden) lässt sich ebenfalls mit dem UNION-Befehl erklären: Die
Rekursion wird um so schneller, je mehr Gebäude bereits durch den ersten Select-Befehl ausgewählt wurden. Diese Gebäude müssen in der Rekursion nicht noch einmal abgefragt werden.
Vergleicht man die Dauer der Rekursion in den drei verschiedenen Abbildungen 6.3 bis 6.5
beispielweise bei 1.000 oder 2.000 Gebäuden, ergibt sich mit den Zeiten 3 Sek., 12 Sek. und
25 Sek. bereits ein eindeutig lineares Verhältnis. Weitere Messungen ergaben an dieser Stelle
einen ungefähren Wert von 2,5 Sekunden pro 1.000 Gebäude. Gesetzt den Fall, die Datenbank
beinhaltet 20.000 Gebäude und es sollten 1.000 Objekte abgefragt werden, so würde die Rekursion mit 50 Sekunden etwa 70% der Gesamtdauer einer Abfrage in Anspruch nehmen.
6.3.1 Spatial-Query
Bleibt man zunächst bei den Abbildungen 6.3 bis 6.5, fällt die Auswahl der Gebäude unter
Zuhilfenahme des räumlichen Index mit sechs bis sieben Sekunden kaum ins Gewicht. Spatial
wird hier aber auch für den Export der Geometrien benutzt. Dabei werden die Koordinaten
nicht wie zuvor erst während der Abfrage zusammengestellt, sondern lediglich aus dem Spatial-Layer (vgl. Abschnitt 5.3.2) gelesen. Dort liegen die Flächen eines Gebäudes, egal ob mit
oder ohne Aggregate, bereits in 3D-Koordinaten vor. Der SQL-Befehl zur Abfrage des Spatial-Layers (im folgenden „Spatial-Query“ genannt) sieht folgendermaßen aus:
SELECT s.id_objekt, world
FROM (
SELECT r.id_objekt, r.world
FROM objekt_reltab r
WHERE mdsys.sdo_filter(
r.world, mdsys.sdo_geometry(
3003,NULL,NULL,
mdsys.sdo_elem_info_array(1,1003,3),
mdsys.sdo_ordinate_array(
3446733.79,5549996.27,142.8,3445133.79,5539196.27,104.8)
), 'querytype=window'
) = 'TRUE'
) S, volumengeometrie_objtab v
WHERE mdsys.sdo_geom.relate(
S.world,'ANYINTERACT', mdsys.sdo_geometry(
3003,NULL,NULL,mdsys.sdo_elem_info_array(1,1003,3),
mdsys.sdo_ordinate_array(
3446733.79,5549996.27,142.8,3445133.79,5539196.27,104.8)
),0.5) = 'TRUE' AND v.id_volumengeom = s.id_object
6.3. EXPORT
91
100
90
2357 Gebäude
80
5716 Gebäude
Sekunden
70
9943 Gebäude
60
50
40
30
20
10
0
0
1000
2000
3000
4000
5000
6000
Abgefragte Gebäude
7000
8000
9000
10000
Abbildung 6.6: Die Dauer der Abfrage ist bei diesem Spatial-Query nur abhängig von
der Menge der abgefragten Daten, nicht von der Größe der Datenbank.
Das Spatial-Query erzeugt das gleiche Suchergebnis, wie das wesentlich komplexere Topologie-Query, das zuvor untersucht wurde. Wie Abbildung 6.6 zeigt, ist das Spatial-Query unabhängig von der Menge der abgespeicherten Daten. Die Abfragedauer ist nahezu proportional
zur Menge der abgefragten Daten. Wie die Abbildung zeigt, liegt die Abfragedauer bei ca. 10
Sekunden pro 1.000 Gebäude.
6.4 Beurteilung
Die Performance der räumlichen Anfragen durch Spatial ist sehr hoch. Bei einer räumlichen
Selektion von weniger als etwa 2.000 Objekten braucht die Datenbank nicht mehr als eine
Sekunde für die Anwendung der räumlichen Funktionen. Der Geschwindigkeitsvorteil beim
Export aus der Spatial-Tabelle fällt jedoch gegenüber dem Export aus dem geometrischtopologischen Modell unerwartet gering aus. Beim Export von nur wenigen Gebäuden
(<1.000) ist die Performance noch zufriedenstellend. Geht die Anzahl jedoch darüber hinaus,
dauert der Export aus dem geometrisch-topologischen Modell nur noch unwesentlich länger
als aus der Spatial-Tabelle. Abbildung 6.7 zeigt die Abfragedauer von Topologie-Query und
Spatial-Query bei einem Datenbestand von 5716 und 9943 Gebäuden.
92
KAPITEL 6 – ANALYSE
120
106
5716 Spatial-Query
5716 Topologie-Query
9943 Spatial-Query
9943 Topologie-Query
100
Sekunden
80
92
84
75
62
60
56
47
40
32
20
34
30
23
20
16
10
1
39
35
18
6
10
48
44
37
19
10
1
0
50
500
1000
2000
4000
8000
9943
Abgefragte Gebäude
Abbildung 6.7: Vergleich von Spatial-Query und Topologie-Query bei zwei unter
schiedlich großen Datenbankbeständen. Das Spatial-Query ist bei
steigender Anzahl abgefragter Gebäude nicht deutlich schneller.
Probleme gibt es allerdings bei der Rekursion, also der Suche von aggregierten Objekten, die
in beliebig tiefe Aggregationsebenen verschachtelt sein können. Das Problem begründet sich
dadurch, dass bei jedem Element, was durch CONNECT BY PRIOR aufgerufen wird, die
Tabelle erneut durchsucht werden muss. Weil das Objekt M.VOLUMENGEOM_REF.
ID_VOLUMENGEOM nicht indiziert werden kann, wird die Tabelle VOLUMENGEOMETRIE.
OBJTAB bei jedem Aufruf von CONNECT BY PRIOR erneut durchsucht. Dies führt zu einem Performanceverlust, der proportional zur Tabellengröße ist.
Alle Zeiten, die hier gemessen wurden, ergeben sich aus dem Mittel von drei Messungen,
deren Standard-Abweichung unterhalb von einer Sekunde liegt. Wichtig zu erwähnen ist hierbei, dass immer der erste Aufruf eines SQL-Befehls ca. 10% bis 15% langsamer ist, als die
folgenden, was sich durch Cache-Strategien seitens der Datenbank erklären lässt. Um vergleichbare Ergebnisse zu erzielen, wurde also immer die Dauer der Folgebefehle gemessen. In
der Realität werden exakt dieselben SQL-Befehle nur selten hintereinander verwendet, daher
sollte man für reale Anwendungen nochmals 10% bis 15% auf die hier erzielten Messergebnisse aufaddieren. Es lässt sich jedoch vermuten, dass auf großen Servern mit sehr viel Arbeitsspeicher dieser Effekt nicht mehr auftritt.
6.4. BEURTEILUNG
93
Sicherlich gibt es viele Möglichkeiten in Oracle, mit denen die SQL-Abfragen oder auch
grundsätzlich die Suche in Tabellen beschleunigt werden kann. Die Standardverfahren dazu
wurden allerdings schon berücksichtigt:
Durch die Verwendung von Primärschlüsseln in den Objekttabellen sind diese bereits indiziert. Eine zusätzliche Indizierung der anderen Spalten bringt daher keine signifikante Leistungssteigerung, was sowohl für die normalen Tabellen, als auch für eingebettete Tabellen
(nested tables) gilt. Für die Objekt-Referenzen wurden Scope’s angelegt, die ObjektReferenzen dazu zwingen, nur noch auf eine bestimmte Tabelle zu zeigen. Die Nutzung von
Scope’s verringert den Speicherverbrauch und steigert die Effizienz. Die SQL-Abfragen wurden ebenfalls durch manuelle Tests optimiert. Leider hilft das Programm SQL-Analyse aus
dem Oracle Tuning Pack an dieser Stelle nicht weiter, weil es offensichtlich nicht in der Lage
ist, objekt-relationale SQL-Befehle zu analysieren.
An dieser Stelle kann nur die Vermutung ausgesprochen werden, dass mit einem relationalen
Modell die Effizienz eventuell steigen könnte. Vermuten lässt sich das zumindest beim
Importieren der Daten, weil dort mit Hilfe der Prepared Statements in relationalen Tabellen
höhere Geschwindigkeiten erzielbar sind. Wie sich die Geschwindigkeit bei der Rekursion
oder bei der Auswahl der Geometrien auswirkt, bei der zwischen sieben und neun Tabellen in
einem großen JOIN zusammengefasst werden müssten, lässt sich nicht vorhersagen. Das gesamte Datenmodell in ein relationales umzuwandeln wäre aber grundsätzlich möglich. Das
Datenmodell verliert dadurch keine Funktionalität, die Umsetzung der rekursiven Aggregation und der m:n-Beziehungen sind lediglich etwas aufwändiger zu modellieren.
Kapitel 7
Schluss & Ausblick
In dieser Arbeit wurde ein objekt-relationales Datenmodell zur Repräsentation von 3DStadtmodellen in eine Oracle Datenbank implementiert. Bei der Ableitung aus dem geometrisch-topologischen Modell „Regengeld“ wurden entsprechend dem objekt-relationalen Ansatz nested tables verwendet, die m:n-Relationen und auch rekursive Strukturen ermöglichen.
Da die Aufgabe unter anderem in der Verwaltung und Abfrage räumlicher Daten bestand,
wurde bei der Umsetzung die Erweiterung Spatial hinsichtlich ihrer 3D-Fähigkeiten untersucht. Zusätzlich wurden im Rahmen dieser Arbeit verschiedene Werkzeuge für den Import
und Export dieser räumlichen Daten in ein VRML-Modell entwickelt, welche sowohl einen
Datenaustausch als auch die Visualisierung der Daten realisieren. Dabei besteht die Möglichkeit, bei der Erstellung der VRML-Daten entweder auf das geometrisch-topologische Modell,
oder auf die von Spatial verwaltete Tabelle zurückzugreifen. Die Evaluation des Systems
wurde anhand von realen Daten durchgeführt, die Ergebnisse analysiert und kritisch beurteilt.
Die Ergebnisse der Untersuchung von Spatial zeigen, dass 3D-Daten verwaltet und auch abgefragt werden können. Die dreidimensionale Indizierung von Objekten mit Hilfe eines RBaums unter Verwendung von Minimum Bounding Volumes ist ebenfalls möglich. Bei der
3D-Analyse mit diesen Minimum Bounding Volumes zeigen sich jedoch Schwächen, denn
bei einer Suche nach bestimmten Objekten z.B. innerhalb einer Suchbox werden unter Umständen zu viele Objekte gefunden. Immerhin ergibt eine solche Suche niemals weniger Treffer, als tatsächlich vorhanden. Dieses Problem lässt sich reduzieren, in dem das 3DSuchergebnis noch mit 2D-Funktionen analysiert wird, wobei diese Funktionen nur unter Vernachlässigung der z-Koordinate exakte Ergebnisse produzieren.
Um die Datenbank 3D-tauglich zu nennen, fehlen ihr noch die folgende Funktionen:
•
•
•
Exakte Unterscheidung von 3D-Objekten (vgl. Abbildung 4.14)
Messung der Schrägdistanz im Modell
Berechnung von Höhe, Volumen und Schwerpunkt eines 3D-Objekts
Bisher bleibt die Implementierung solcher 3D-Funktionen dem Nutzer von Spatial überlassen,
der eigene Entwicklungen jedoch problemlos in die Datenbank integrieren kann.
94
7. SCHLUSS & AUSBLICK
95
Beim Import der Daten leidet die Performance unter der objekt-relationalen Datenstruktur,
weil hier kein Prepared Statements durchgeführt werden kann. Das größte Performanceproblem entsteht durch die rekursive Durchsuchung von Objekttabellen, weil die Tabelle bei
jedem Aufruf der rekursiven Funktion erneut vollständig abgearbeitet werden muss. Auf diese
Weise sinkt die Performance proportional zur Größe einer Tabelle.
Im Gegensatz dazu fällt die Performance von Spatial bei der räumlichen Selektion der Daten
kaum ins Gewicht. Ergibt die räumliche Selektion weniger als etwa 2.000 Objekte, braucht
die Datenbank unter den Testbedingungen (vgl. Kapitel 6) weniger als eine Sekunde für die
Anwendung der räumlichen Funktionen.
Der Geschwindigkeitsvorteil beim Export aus der Spatial-Tabelle fällt jedoch gegenüber dem
Export aus dem geometrisch-topologischen Modell unerwartet gering aus. Beim Export von
nur wenigen Gebäuden (<1.000) ist die Performance noch zufriedenstellend. Geht die Anzahl
jedoch darüber hinaus, dauert der Export aus dem geometrisch-topologischen Modell nur
noch unwesentlich länger als aus der Spatial-Tabelle. Attributive Anfragen an die Datenbank,
die nicht die komplette Geometrie eines Objektes wiedergeben sollen, können mit diesem
System nahezu in Echtzeit abgefragt werden und auch komplette Geometrien von etwa 200
bis 300 Objekten können praktisch ohne Zeitverzug ausgegeben werden.
Um aber von einem echten 3D-GIS sprechen zu können, fehlt dem System zur Zeit noch eine
graphische Benutzer-Oberfläche, einige 3D-Routinen und weitere Geschwindigkeitsverbesserungen, um auch größere Datenmengen effizient verwalten zu können. Zu diesem Zweck
werden folgende Vorschläge für weitere Untersuchungen und Entwicklungen gemacht:
Zur Visualisierung von 3D-Objekten in der Benutzeroberfläche bietet sich Java3D an. Damit
können Suchergebnisse von SQL-Abfragen in einem Ansichtsfenster dargestellt werden in
dem auch Selektionen oder die Auswahl von bestimmten Operationen möglich sind. Die 3DStreckenmessung lässt sich damit ebenso wie die Einblendung von Zusatzinformationen realisieren. Darüber hinaus ist Java3D auch in der Lage, den Import und Export von VRML- oder
X3D-Dateien übernehmen.
Durch die Möglichkeit der Implementierung eigener Java- oder C++-Routinen in die Datenbank, bieten sich neben den oben angesprochenen 3D-Funktionen noch andere an. So können
Funktionen entwickelt werden, welche die 3D-Daten auf Ihre Integrität prüfen. Diese Überprüfung muss nicht nur beim Import der Daten erfolgen, sondern auch dann, wenn die Datenbank durch den Nutzer geändert wird. Genauso können anwendungsspezifische Funktionen
implementiert werden, wie z.B. die Visualisierung von Hochwasserständen oder die Funkwellen-Ausbreitung eines Mobilfunkmastes.
Für Fachanwendungen sind Verknüpfungen zu weiteren Datenbeständen denkbar. Neben den
3D-Objekten können z.B. digitale Geländemodelle, Orthophotos oder zusätzliche fachspezifische Informationen in das System eingebettet werden.
96
KAPITEL 7 – SCHLUSS & AUSBLICK
Hinsichtlich der Performance gibt es sicher noch Möglichkeiten, SQL-Abfragen zu beschleunigen und auch die Suche in den Tabellen zu verbessern. Vor allem ist zu prüfen, welche Vorund Nachteile die Umsetzung in ein relationales Datenmodell bringt. Ob die Rekursion dadurch beschleunigt werden kann, bleibt offen. Die Partitionierung von Tabellen könnte hier
bereits Abhilfe schaffen.
Dieses System verfügt ohne Zweifel über ein großes Potential und ist bereits jetzt nicht mehr
weit von einem 3D-Basis-GIS entfernt. Daher lohnt es sich in jedem Fall weitere Untersuchungen und Entwicklungen an diesem System vorzunehmen. Nicht zuletzt gibt diese Arbeit
auch Aufschluss über die Praxistauglichkeit eines Datenmodells, welches zu einem Standard
für die Repräsentation von 3D-Stadtmodellen werden soll.
8 Anhang
/*
/*
/*
/*
/*
/*
/*
/*
SQL-Datei zur Erstellung der Datenbank
by Markus Reuter
*/
*/
*/
Hier werden die Objekttypen definiert. */
Da einige Beziehungen rekursiv sind,
*/
werden die Typen hier nur namentlich
*/
aufgeführt, anders als bei den ntab*/
Typen, die jetzt schon vollständig sind */
/* PunktGeometrie */
CREATE OR REPLACE TYPE PunktGeometrie_objtyp
/
/* Knoten */
CREATE OR REPLACE TYPE Knoten_objtyp
/
/* LinienGeometrie */
CREATE OR REPLACE TYPE LinienGeometrie_objtyp
/
/* LinienAggregat */
CREATE OR REPLACE TYPE LinienAggregat_objtyp AS OBJECT
(
LinienGeom_ref
REF LinienGeometrie_objtyp
) NOT FINAL
/
CREATE OR REPLACE TYPE LinienAggregat_ntabtyp AS TABLE OF
LinienAggregat_objtyp
/
/* Kante */
CREATE OR REPLACE TYPE Kante_objtyp
/
/* KantenListe */
CREATE OR REPLACE TYPE KantenListe_objtyp AS OBJECT
(
SortVar
NUMBER,
Kante_ref
REF Kante_objtyp
97
98
KAPITEL 8 – ANHANG
) NOT FINAL
/
CREATE OR REPLACE TYPE KantenListe_ntabtyp AS TABLE OF Kantenliste_objtyp
/
/* Ring */
CREATE OR REPLACE TYPE Ring_objtyp
/
/* RingListe */
CREATE OR REPLACE TYPE RingListe_objtyp AS OBJECT
(
Ring_ref
REF Ring_objtyp
) NOT FINAL
/
CREATE OR REPLACE TYPE RingListe_ntabtyp AS TABLE OF Ringliste_objtyp
/
/* FlaechenGeometrie */
CREATE OR REPLACE TYPE FlaechenGeometrie_objtyp
/
/* FlaechenAggregat */
CREATE OR REPLACE TYPE FlaechenAggregat_objtyp AS OBJECT
(
FlaechenGeom_ref
REF FlaechenGeometrie_objtyp
) NOT FINAL
/
CREATE OR REPLACE TYPE FlaechenAggregat_ntabtyp AS TABLE OF
FlaechenAggregat_objtyp
/
/* Material RGB */
CREATE OR REPLACE TYPE RGB_objtyp
/
/* Material Textur */
CREATE OR REPLACE TYPE Matrix_vartyp AS VARRAY(9) OF NUMBER
/
8. SQL-DATEI ZUR ERSTELLUNG DER DATENBANK
CREATE OR REPLACE TYPE Textur_objtyp
/
/* Material */
CREATE OR REPLACE TYPE Material_objtyp
/
/* Orientierung */
CREATE OR REPLACE TYPE Orientierung_vartyp AS VARRAY(3) OF
NUMBER
/
/* Masche */
CREATE OR REPLACE TYPE Masche_objtyp
/
/* MaschenListe */
CREATE OR REPLACE TYPE MaschenListe_objtyp AS OBJECT
(
Masche_ref
REF Masche_objtyp
) NOT FINAL
/
CREATE OR REPLACE TYPE MaschenListe_ntabtyp AS TABLE OF
MaschenListe_objtyp
/
/* VolumenGeometrie */
CREATE OR REPLACE TYPE VolumenGeometrie_objtyp
/
/* VolumenAggregat */
CREATE OR REPLACE TYPE VolumenAggregat_objtyp AS OBJECT
(
VolumenGeom_ref
REF VolumenGeometrie_objtyp
) NOT FINAL
/
CREATE OR REPLACE TYPE VolumenAggregat_ntabtyp AS TABLE OF
VolumenAggregat_objtyp
/
/* Volumen */
99
100
KAPITEL 8 – ANHANG
CREATE OR REPLACE TYPE Volumen_objtyp
/
/* Hier bekommen die Typen alle Attribute, */
/* da jetzt alle Typen namentlich definiert */
/* sind.
*/
/* PunktGeomtrie */
CREATE OR REPLACE TYPE PunktGeometrie_objtyp AS OBJECT
(
ID_Punkt
NUMBER,
Knoten_ref
REF Knoten_objtyp
) NOT FINAL
/
/* Knoten */
CREATE OR REPLACE TYPE Knoten_objtyp AS OBJECT
(
ID_Knoten
NUMBER,
x
NUMBER,
y
NUMBER,
z
NUMBER
) NOT FINAL
/
/* LinienGeometrie */
CREATE OR REPLACE TYPE LinienGeometrie_objtyp AS OBJECT
(
ID_Linie
NUMBER,
Kante_ref
REF Kante_objtyp,
LinienAggregat_ntab LinienAggregat_ntabtyp,
is_aggr
NUMBER
) NOT FINAL
/
/* Kante */
CREATE OR REPLACE TYPE Kante_objtyp AS OBJECT
(
ID_Kante
NUMBER,
Anfang_ref
REF Knoten_objtyp,
Ende_ref
REF Knoten_objtyp
) NOT FINAL
/
8. SQL-DATEI ZUR ERSTELLUNG DER DATENBANK
/* Ring */
CREATE OR REPLACE TYPE Ring_objtyp AS OBJECT
(
ID_Ring
NUMBER,
KantenListe_ntab
KantenListe_ntabtyp
) NOT FINAL
/
/* Material RGB */
CREATE OR REPLACE TYPE RGB_objtyp AS OBJECT
(
R
NUMBER,
G
NUMBER,
B
NUMBER
) NOT FINAL
/
CREATE OR REPLACE TYPE Textur_objtyp AS OBJECT
(
Bitmap
BLOB,
Transformation Matrix_vartyp
) NOT FINAL
/
/* Material Objekt */
CREATE OR REPLACE TYPE Material_objtyp AS OBJECT
(
Textur
Textur_objtyp,
RGB
RGB_objtyp
) NOT FINAL
/
/* FlaechenGeometrie */
CREATE OR REPLACE TYPE FlaechenGeometrie_objtyp AS OBJECT
(
ID_Flaeche
NUMBER,
Masche_ref
REF Masche_objtyp,
FlaechenAggregat_ntab
FlaechenAggregat_ntabtyp,
MaterialOben
Material_objtyp,
MaterialUnten
Material_objtyp,
is_aggr
NUMBER
101
102
KAPITEL 8 – ANHANG
) NOT FINAL
/
/* Masche */
CREATE OR REPLACE TYPE Masche_objtyp AS OBJECT
(
ID_Masche
NUMBER,
Aussen_ref
REF Ring_objtyp,
Innen_ntab
Ringliste_ntabtyp,
Orientierung
Orientierung_vartyp
) NOT FINAL
/
/* VolumenGeometrie */
CREATE OR REPLACE TYPE VolumenGeometrie_objtyp AS OBJECT
(
ID_VolumenGeom
NUMBER,
Volumen_ref
REF Volumen_objtyp,
VolumenAggregat_ntab
VolumenAggregat_ntabtyp,
IS_AGGR
NUMBER
) NOT FINAL
/
/* Volumen */
CREATE OR REPLACE TYPE Volumen_objtyp AS OBJECT
(
ID_Volumen
NUMBER,
MaschenListe_ntab MaschenListe_ntabtyp
) NOT FINAL
/
/*
/*
/*
/*
Bisher sind nur Objekt-Typen definiert
worden, aber es wurde noch kein Speicher
zur Verfügung gestellt. Daher werden
jetzt die Tablespaces definiert.
/* Knoten */
CREATE TABLE Knoten_objtab OF Knoten_objtyp
(
PRIMARY KEY (ID_Knoten)
)
OBJECT IDENTIFIER IS PRIMARY KEY
/
*/
*/
*/
*/
8. SQL-DATEI ZUR ERSTELLUNG DER DATENBANK
103
/* PunktGeometrie */
CREATE TABLE PunktGeometrie_objtab OF PunktGeometrie_objtyp
(
PRIMARY KEY (ID_Punkt),
FOREIGN KEY (Knoten_ref) REFERENCES Knoten_objtab ON DELETE CASCADE
)
OBJECT IDENTIFIER IS PRIMARY KEY
/
/* Kante */
CREATE TABLE Kante_objtab OF Kante_objtyp
(
PRIMARY KEY (ID_Kante),
FOREIGN KEY (Anfang_ref) REFERENCES Knoten_objtab ON DELETE CASCADE,
FOREIGN KEY (Ende_ref) REFERENCES Knoten_objtab ON DELETE
CASCADE
)
OBJECT IDENTIFIER IS PRIMARY KEY
/
/* LinienGeometrie */
CREATE TABLE LinienGeometrie_objtab OF LinienGeometrie_objtyp
(
PRIMARY KEY (ID_Linie),
FOREIGN KEY (Kante_ref) REFERENCES Kante_objtab ON DELETE
CASCADE
)
OBJECT IDENTIFIER IS PRIMARY KEY
NESTED TABLE LinienAggregat_ntab STORE AS LinienAggregat_stortab
/
/* Ring */
CREATE TABLE Ring_objtab OF Ring_objtyp
(
PRIMARY KEY (ID_Ring)
)
OBJECT IDENTIFIER IS PRIMARY KEY
NESTED TABLE KantenListe_ntab STORE AS RingKante_stortab
104
KAPITEL 8 – ANHANG
/
/* Masche */
CREATE TABLE Masche_objtab OF Masche_objtyp
(
PRIMARY KEY (ID_Masche),
FOREIGN KEY (Aussen_ref) REFERENCES Ring_objtab ON DELETE
CASCADE
)
OBJECT IDENTIFIER IS PRIMARY KEY
NESTED TABLE Innen_ntab STORE AS MascheInnen_stortab
/
/* FlaechenGeometrie */
CREATE TABLE FlaechenGeometrie_objtab OF
FlaechenGeometrie_objtyp
(
PRIMARY KEY (ID_Flaeche),
FOREIGN KEY (Masche_ref) REFERENCES Masche_objtab ON DELETE CASCADE
)
OBJECT IDENTIFIER IS PRIMARY KEY
NESTED TABLE FlaechenAggregat_ntab STORE AS FlaechenAggregat_stortab
/
/* Volumen */
CREATE TABLE Volumen_objtab OF Volumen_objtyp
(
PRIMARY KEY (ID_Volumen)
)
OBJECT IDENTIFIER IS PRIMARY KEY
NESTED TABLE MaschenListe_ntab STORE AS VolumenMaschen_stortab
/
/* VolumenGeometrie */
CREATE TABLE VolumenGeometrie_objtab OF VolumenGeometrie_objtyp
(
PRIMARY KEY (ID_VolumenGeom),
FOREIGN KEY (Volumen_ref) REFERENCES Volumen_objtab ON DELETE CASCADE
8. SQL-DATEI ZUR ERSTELLUNG DER DATENBANK
)
OBJECT IDENTIFIER IS PRIMARY KEY
NESTED TABLE VolumenAggregat_ntab STORE AS VolumenAggregat_stortab
/
/* Objekt (sdo_geometry kann nicht als
*/
/* Objekttyp erstellt werden, daher hier */
/* als relationale Tabelle
*/
CREATE TABLE Objekt_reltab
(
ID_Objekt
NUMBER,
Volumen_ref
NUMBER,
Flaeche_ref
NUMBER,
Linie_ref
NUMBER,
World
mdsys.sdo_geometry,
FOREIGN KEY (Volumen_ref) REFERENCES Volumengeometrie_objtab(ID_Volumengeom) ON DELETE CASCADE,
FOREIGN KEY (Flaeche_ref) REFERENCES
Flaechengeometrie_objtab(ID_Flaeche) ON DELETE CASCADE,
FOREIGN KEY (Linie_ref) REFERENCES
Liniengeometrie_objtab(ID_Linie) ON DELETE CASCADE,
PRIMARY KEY (ID_Objekt)
)
/
/* Koordinatensystem uns Genauigkeit festlegen */
insert into user_sdo_geom_metadata values
(
'Objekt_reltab','world', mdsys.sdo_dim_array
(
mdsys.sdo_dim_element('X', 0, 10000000, 0.001),
mdsys.sdo_dim_element('Y', 0, 10000000, 0.001),
mdsys.sdo_dim_element('Z', 0, 10000000, 0.001)
),
NULL
)
/
/* Ein Objekt erzeugen, um Index erstellen zu können */
insert into Objekt_reltab values
(
1, NULL, NULL, NULL,
105
106
KAPITEL 8 – ANHANG
mdsys.sdo_geometry
(
3004, NULL, NULL,
mdsys.sdo_elem_info_array(1, 1003, 1),
mdsys.sdo_ordinate_array
(
1,1,1, 1,1,1, 1,1,1,
2,2,2, 2,2,2, 2,2,2,
3,3,3, 3,3,3, 3,3,3,
1,1,1, 1,1,1, 1,1,1
)
)
)
/
/* Index erzeugen, danach nur noch "ALTER INDEX" */
create index world_spatial_idx
on Objekt_reltab(world)
indextype is mdsys.spatial_index parameters('sdo_indx_dims =
3')
/
/* Ändern der REF SCOPE Anweisung für Nested Tables */
/* LinienGeometrie */
ALTER TABLE LinienAggregat_stortab
ADD (SCOPE FOR (LinienGeom_ref) IS LinienGeometrie_objtab)
/
/* Ring */
ALTER TABLE RingKante_stortab
ADD (SCOPE FOR (Kante_ref) IS Kante_objtab)
/
/* FlächenGeometrie */
ALTER TABLE FlaechenAggregat_stortab
ADD (SCOPE FOR (FlaechenGeom_ref) IS FlaechenGeometrie_objtab)
/
/* Masche */
ALTER TABLE MascheInnen_stortab
ADD (SCOPE FOR (Ring_ref) IS Ring_objtab)
/
8. SQL-DATEI ZUR ERSTELLUNG DER DATENBANK
107
/* VolumenGeometrie */
ALTER TABLE VolumenAggregat_stortab
ADD (SCOPE FOR (VolumenGeom_ref) IS VolumenGeometrie_objtab)
/
/* Volumen */
ALTER TABLE VolumenMaschen_stortab
ADD (SCOPE FOR (Masche_ref) IS Masche_objtab)
/
/* Prozeduren */
CREATE OR REPLACE PROCEDURE INSERT_GEOM(GEOM
MDSYS.SDO_GEOMETRY, objid INTEGER) IS
BEGIN
update objekt_reltab set world = (GEOM) where id_objekt = objid;
COMMIT;
END;
/
Literaturverzeichnis
[Are03]
C. Arens, J. Stoter, P. van Oosterom, Modelling 3D spatial objects in a GEODBMS using a 3D primitive, AGILE conference, April 2003, Lyon, France
[Bru02]
A. Brunn, T. Kolbe, G. Gröger, W. Förstner, L. Plümer, Konzeption und Dokumentation eines Verfahrens zur Ableitung von 3D-Stadtmodellen aus der Regengelderfassung, Unveröffentlichter Abschlussbericht zur wissenschaftlichtechnischen Zusammenarbeit mit der Stadt Wuppertal, 2002
[Ege90]
M. J. Egenhofer, J. R. Herring, Categorizing Binary Topological Relations
Between Regions, Lines, and Points in Geographic Databases. Technical report, Department of Surveying Engineering, University of Maine, 1990.
[Fol95]
J. Foley, A. van Dam, S. Feiner, J. Hughes (1995), Computer Graphics,
Principles and Practice, Addison Wesley Longman, 2. Auflage.
[Fra02]
K.-H. Franke, 2002, Primitive Instancing, Institut für Praktische Informatik
und Medieninformatik TU-Ilmenau: http://kb-bmts.rz.tu-ilmenau.de/franke/
Scripte/Grafik/Ergaenzung_Primitive_Instancing.pdf
[Gut84]
A. Guttman, R-trees: a dynamic index structure for spatial searching. SIGMOD Record (ACM Special Interest Group on Management of Data),
14(2):47-57, 1984
[Kim89]
W. Kim, F.H. Lochovsky, Herausgeber. Object-Oriented Concepts, Databases
and Applications. ACM Press Frontier Series, Addison Wesley, Reading, MA,
1989
[Kin89]
R. King, My Cat is object-oriented. In [Kif89] Kapitel 2, Seiten 23-30, Addison-Wesley, 1989
[Klo98]
J. Kloss, VRML97, der neue Standard für Interaktive 3D Welten im World
Wide Web, Addison Wesley, Bonn, 1998
[Män88]
M. Mäntyla, 1988, An Introduction to Solid Modeling, Rockville, Maryland:
Computer Science Press
[McC02]
C. MCCullough-Dieter, Oracle 9i für Dummies, mitp-Verlag, Bonn, 2002
[Mol92]
M. Molenaar, 1992, A topology for 3D vector maps, ITC Journal 1992-1
108
LITERATURVERZEICHNIS
109
[OGCa]
Open GIS Consortium, OpenGIS Simple Features Specification for SQL,
http://www.opengis.org/techno/specs/99-049.pdf
[Oraa]
Oracle 9i Application Developer’s Guide – Object-relational Features,
Release 2 (9.2), März 2002,
http://download.oracle.com/docs/cd/B10501_01/appdev.920/a96594.pdf
[Orab]
Oracle 9i JDBC Developer’s Guide and Reference, Release 2(9.2), März 2002,
http://download.oracle.com/docs/cd/B10501_01/java.920/a96654.pdf
[Orac]
Oracle Spatial – User’s Guide and Reference, Release 9.2, März 2002,
http://download.oracle.com/docs/cd/B10501_01/appdev.920/a96630.pdf
[Orad]
Oracle Spatial – Java Library User’s Guide, Release 8.1.7, Juli 2002,
http://otn.oracle.com/docs/products/spatial/pdf/sdoapi.pdf
[Pfu02]
M. Pfund, 3D GIS Architecture, A Topological Data Structure, GIM International, Vol 16. Feb. 2002
[Pfu02b]
M. Pfund, 3D Geographic Information Systems, Institut für Geodäsie und Photogrammetrie, ETH Zürich,
http://www.gis.ethz.ch/research/gis/gis_3dgis.htm
[Rik94]
R. Rikkers et al., A query orientated implementation of a topologic data structure for 3-dimensional vector maps, Int. J. Geographical Information Systems,
Vol . 8, 1994
[RJB99]
J. Rumbaugh, I. Jacobson, G. Booch, The Unified Modeling Language Reference Manual, Addison-Wesley, Reading, 1999
[Sto03]
J.E. Stoter and S. Zlatanova, Visualisation and editing of 3D objects organised
in a DBMS, Proceedings of the EuroSDR Com V. Workshop on Visualisation
and Rendering, 22-24 January, Enschede, The Netherlands
[Ull88]
J.D. Ullman, Principles of Database and Knowledge-Base Systems, volume 1,
Computer Science Press, 1988