Transcript 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: 1) Was bedeutet „Objektorientiert“ 2) Was bedeutet „Raumbezogen“? 3) Wie sind relationale Datenbanken aufgebaut?
4) Von relationalen zum objektorientierten Datenbankmodell 5) SQL und SQL-Standard 6) 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
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 Software produkte: 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 Vektor tabellen, den sogenannten
„Geometrie Columns“
aufgeführt sind 2)
sonstigen „Features“
, deren Datentyp einfacher oder benutzer definierter 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 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 Feature Table/View
Geometry Columns GID ESEQ ETYPE SEQ x1 y1 x2 y2 ...
...
x
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 X3 Y3 X4 Y4
1 1 2 2 2 3 4 1 2 1 2 2 1 1 3 3 3 3 3 3 3 1 1 1 1 2 1 1 0 30 40 0 0 0 5 30 0 50 15 50 0 30 30 30 30 30 30 60 30 60 5 40 0 0 60 30 60 30 30 0 0 10 10 10 20 20 20 20 10 10 10 60 0 0 40 20 45 20 45 15 50 15 5 NIL NIL NIL NIL 30 30 30 30 60 60 60 60 30 30 30 (0,60) (30,60) (60,60)
Zu Null setzen
(0,30)
(GID 3)
(30,30)
(GID 4) ESEQ 1 ESEQ 2
(60,30)
(GID 1)
(0,0)
(GID 2)
(30,0) (60,0)
Linien Punkte
Analoge Überlegungen für Punkte und Linien GID ETYPE SEQ X0 Y0 X1 Y1 X2 Y2 X3 Y3 X4 Y4
205 206 207 208 208 210 211 2 2 2 2 2 2 2 1 1 1 1 2 1 1 0 30 40 0 0 0 5 30 30 50 15 50 0 2 5 25 15 40 4 30 30 60 30 60 40 13 55 10 10 10 20 20 20 20 10 10 12 0 60 30 60 30 30 60 0 0 40 20 45 20 45 15 50 15 7 NIL NIL NIL NIL 33 30 30 30 60 60 60 60 30 30 37
GID ETYPE X
7 8 9 10 11 12 13 1 1 1 1 1 1 1
Y
0 0 10 10 30 40 0 5 50 15 0 30 30 30 ?
Geht aus Spezifikation nicht hervor
WKB Geometrie für Polygone B =1 T =3 NR =2 NP =3 X1 Y1 X2 Y2 X3 Y3 NP =3 X1 Y1 .....
Ring 1 Ring 2 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 Surface GeometryCollection
SQL muss abstrakte Datentypen (ADT) verarbeiten können Spezifikation standarisiert: Spezifikation standarisiert nicht :
LineString • Polygon MultiSurface
Namen und Geometrietypen definition für Speicherung
• MultiCurve
Syntax für die Speicherung und Funktionen
MultiPoint •
Name, Signaturen und Geo metriedefinition für die Funktionen
•
Die physikalische Speicherform
MultiPolygon MultiLineString
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