Objektrelationale raumbezogene Datenbanken

Technische Grundlagen der Interoperabilität
Objektrelationale
raumbezogene Datenbanken
Seminar Geoinformation WS 2001/2002
Referent: Dirk Fitting
Betreuer: Dr. G. Gröger
Objektrelationale raumbezogene Datenbanken
Überblick:
Was bedeutet „Objektorientiert“
Was bedeutet „Raumbezogen“?
Wie sind relationale Datenbanken aufgebaut?
Von relationalen zum objektorientierten Datenbankmodell
SQL und SQL-Standard
Versuch der Standarisierung von Datenbanken für SQL
vom „OpenGIS Consortium“
7) Open GIS: Spezifikation für einfache räumliche objektrelationale
Datenbanken und Nutzung als GIS
8) Beschreibung von Architektur und Normativen der Spezifikation
1)
2)
3)
4)
5)
6)
Objektorientierte Modellierung
Objektorientierte Denkweise
Ganzheitliche Betrachtung der Objekte mit ihren Beschreibungen
(Attributen) und ihrer Funktionen bzw. Verhalten (Methoden)
Das objektorientierte Datenbankmodell
-„objektorientiert“
Konzepte aus der Informatik:
• Identität
• Klassenbildung
• Kapselung (Integration von Daten und Methoden, Zugriff nur über
Methoden)
• Vererbung (einfach, mehrfach)  Superklassen, Subklassen
Objektorientierte Modellierung
Objektorientierte Datenbanken
• machen Objekte persistent
• sind eng verbunden mit objektorientierten Sprachen (ODL)
• ihnen vorausgegangen sind objektorientierte Programmiersprachen
wie z.B. C++ (  Definition von abstrakten Datentypen (ADT))
„objektrelational“
• im SQL - Standard kein neues Paradigma
• Setzt auf dem alten relationalen Modell auf und erweitert es
 erweitern vorhandene persistente (relationale) Datenhaltung um
objektorientierte Modellierungsmittel
Raumbezogene Datenmodelle und -strukturen
- Raumbezogene Daten versuchen die Realwelt zu modellieren
- Realweltobjekte sind komplex strukturierte Objekte mit:
• zahlreichen raumbezogenen Eigenschaften (Attributen):
Geometrie, Sachdaten, Aufgaben, etc.
• räumliche Beziehungen zwischen den Objekten:
z.B.
räumlich - topologisch: Gebäude steht auf Grundstück
räumlich - geometrisch: Gebäude hat einen Abstand zu
seinem Nachbargebäude
Aufbau und Struktur von relationalen Datenbanken*
- Attribute: Eigenschaften die in einer Datenbank gespeichert werden
- Domänen: Wertebereiche zur Beschreibung von Daten (integer, string, ...)
- Relationen (Menge von Tupeln) und Relationsschema (Definition)
- Tupel: Menge von Attributen
- Schlüssel, Primärschlüssel und Fremdschlüssel
1) Primärschlüssel identifiziert eindeutig ein Tupel einer Relation
2) Fremdschlüssel stellen Beziehungen zwischen Relationen her
- Datenbankschema und Datenbank
Schema für eine relationale Datenbank wird festgelegt durch:
1) Eine Menge von Bezeichnern für Relationen
2) Für jede Relation ein Relationsschema
3) Für jede Relation weitere Konsistenzbedingungen
* G. Matthiessen / M. Unterstein: Relationale Datenbanken und SQL; Addison-Wesley Verlag
SQL und SQL-Standard
(SQL – Structed Query Language)
- SQL hat sich als Standardabfragesprache für relationale
Datenbanken etabliert
- Mit SQL lassen sich alle Operationen der Relationsalgebra
realisieren
- Sprachelemente von SQL lassen sich einteilen in:
1) DDL (Data Definition Language)
2) DML (Data Manipulation Language)
- SQL und SQL92 (Entwicklungsstufe 1992)
Open GIS
Simple Feature Spezifikation
für SQL
Architektur für SQL92
Implementation von Tabellen typisierter Klassen
Open GIS Consortium.Inc
- Vereinigung
- Zusammenschluss mehrer GIS Hersteller, Universitäten,
staatliche Institute, etc.
Ziel:
- Kompatibilität
- offene interoperable GIS- Systeme
- Nutzung von Geodaten auf der ganzem Welt
- Vorraussetzung: Einheitlicher Aufbau der Datenbanken
Spezifikation
- Spezifikation für interoperable Systeme:
Standarisierung für SQL-Schema zur Speicherung,
Verwaltung, Erweiterung und Bearbeitung raumbezogener
Daten (GIS-Geoinformationssystem).
Implementation beinhaltet keine Funktionen für Zugriff,
Erhaltung oder Bearbeitung von geometrischen Objekten.
- Anwendungssprachen können diese Anfragen basierend auf
SQL – Prozeduren übernehmen.
Zugriff und Nutzung aller Interessenten durch Softwareprodukte: Small World, Oracle, Informix, Access etc.
Architektur – SQL Implementation von „Feature
Tables“
Datenbankschema
- Jedes „Feature table or view“ charakterisiert eine „Feature class“
- jedes „Feature table or view“ besitzt eine Anzahl von „Features“,
die als „rows“ in dem „view“ aufgeführt werden.
1) geometrischen „Features“, deren Geometrie in extra Vektortabellen, den sogenannten „Geometrie Columns“ aufgeführt sind
2) sonstigen „Features“, deren Datentyp einfacher oder benutzerdefinierter Form ( z.B. in C++: Struct ,case, usw.) sind
- die Verbindung zwischen den geometrischen „Features“ und der
„Feature table or view“ wird durch den GID (foreign key
reference) hergestellt
- eindeutige Zuordnung des GID
Datenbankschema (Open GIS)
Geometry columns
Feature Table/View
F_Table_Catalog
F_Table_schema
F_Table_Name
F_Geometry_Columns
G_Table_Calalog
G_Table_Schema
G_Table_Name
storage_Type
geometry_Type
Coord_Dimension
Max PPR
SRID
<Attributes>
GID
<Attributes>
Spatial_Reference_System
SRID
Auth_Name
Auth_SRID
SRText
Standarisierte Geometrie
(Numeric Type)
Geometry Columns
GID
ESEQ
ETYPE
SEQ
x1
y1
x2
y2
...
...
x <Max>
y <Max>
GID
xMIN
yMIN
xMAX
yMAX
oder
WKB Geometrie
(Binary Type)
Geometry Columns
Bounding box
Architektur im SQL-Standard
Drei Speicherungsformen für geometrische „Feature Tables“:
SQL92 - Implementation für „Feature Tables“
1) Vektormatrix – standarisierte Geometrie
2) Binäres Koordinaten-Tupel - WKBGeometry
(Well - Known Binary- Representation for Geometry)
SQL92 mit Geometrietypen-Implementation für
„Feature Tables“
3) Objektorientierte Speicherung mit Hierachietypen
standarisierte Geometrie für Polygone
GID ESEQ ETYPE SEQ X0 Y0 X1 Y1 X2 Y2
1
1
3
1
0 0 0 30 30 30
1
2
3
1 10 10 10 20 20 20
2
1
3
1 30 0 30 30 60 30
2
2
3
1 40 5 40 20 45 20
2
2
3
2 50 15 50 5 40 5
3
1
3
1
0 30 0 60 30 60
4
1
3
1 30 30 30 60 60 60
(0,60)
(30,60)
X3 Y3
30 0
20 10
60 0
45 15
NIL NIL
30 30
60 30
X4 Y4
0 0
10 10
60 0
50 15
NIL NIL
0 30
30 30
(60,60)
Zu Null setzen
Eindeutiges
Anzahl
Geometrietyp
Reihenfolge
derObjektkennzeichen
Einzelsegmente
(0,30)
(GID 3) (30,30) (GID 4)
ESEQ 1
(GID 1)
(0,0)
(60,30)
ESEQ 2
(GID 2)
(30,0)
(60,0)
Analoge Überlegungen für Punkte und Linien
Linien
Punkte
GID ETYPE SEQ X0 Y0 X1
205
2
1
0 0 30
206
2
1
10 10 10
207
2
1
30 0 30
208
2
1
40 5 40
208
2
2
50 15 50
210
2
1
0 30 0
211
2
1
30 30 30
GID ETYPE X
7
1
0
8
1
10
9
1
30
10
1
40
11
1
50
12
1
0
13
1
30
Y
0
10
0
5
15
30
30
Y1
2
20
30
20
5
60
60
X2
25
20
60
45
40
30
60
Y2
15
20
30
20
7
60
60
X3
4
20
60
45
NIL
30
60
Y3
40
10
0
15
NIL
30
30
X4
13
10
60
50
NIL
0
30
Y4
55
12
0
15
NIL
33
37
?
Geht aus Spezifikation
nicht hervor
WKB Geometrie für Polygone
Datenformat
Geometrietyp
BestehtRing
3aus
= Polygon
hat
2 Ringen
3 Punkte
B
=1
T
=3
NR
=2
NP
=3
X1
Y1
X2
Y2
X3
Y3
NP
=3
X1
Y1
Ring 2
Ring 1
Polygon
.....
Objektorientierte Speicherung mit Geometrietypen
Vererbung von Methoden steht im Vordergrund
Geometrie
Kapselung - Zugriff nur über Methoden
Struktur und Speicherung der Daten nur sekundär von Interesse
Curve type)
Point
Surface
GeometryCollection
(numeric
und binary
SQL muss abstrakte Datentypen (ADT) verarbeiten können
Spezifikation standarisiert:
Spezifikation standarisiert nicht :
Polygon
MultiSurface
MultiCurve MultiPoint
LineString
• Namen und Geometrietypen• Syntax für die Speicherung
definition für Speicherung
und Funktionen
• Name, Signaturen und Geo• Die physikalische Speicherform
metriedefinition für die MultiPolygon
MultiLineString
Funktionen
Probleme dieser Spezifikation
• Standarisierungen für Nutzer der Spezifikation zu
undetailliert
• Vorschriften dieser Spezifikation sind mehrdeutig
• Auslegung der vorgeschlagenen Normativen kann
unterschiedlich ausfallen
Seminar Geoinformation WS 2001/2002
Danke für die Aufmerksamkeit