- Fachgebiet Datenbanken und Informationssysteme

Entwurf und Implementierung einer
kartographischen Datenbank nach dem
AFIS-ALKIS-ATKIS-Referenzmodell
Studienarbeit von
Heike Opitz
Betreut von
Dipl.-Math. Sascha Klopp
28. Februar 2003
Inhaltsverzeichnis
1 Einleitung
3
2 Übersicht über das derzeitige ATKIS-Schema
2.1 Konzeptionelles Schema . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Relationales Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
4
5
3 Konzeptionelles Datenbank-Schema
3.1 Übersicht . . . . . . . . . . . . . .
3.2 Einteilung in REO und ZUSO . . .
3.3 Objektnamen . . . . . . . . . . . .
3.4 Attribute . . . . . . . . . . . . . .
3.5 Folie und Objektarten . . . . . . .
.
.
.
.
.
6
6
8
8
8
9
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10
10
11
12
13
13
14
14
15
16
16
16
17
17
17
.
.
.
.
.
4 Objektrelationales Datenbankschema
4.1 Benutzung des Datentyp REF . . . .
4.2 Objektklasse aa object . . . . . . . .
4.3 Objektklasse aa REO . . . . . . . . .
4.4 Objektklasse aa ZUSO . . . . . . . .
4.5 Objektklasse geom . . . . . . . . . .
4.6 Objektklasse above obj . . . . . . . .
4.7 Objektklasse ap gpo . . . . . . . . . .
4.8 Objektklasse präsentationsobjekt . . .
4.9 Objektklasse attr . . . . . . . . . . .
4.10 Objektklasse attr type . . . . . . . .
4.11 Objektklasse attr value . . . . . . . .
4.12 Objektklasse object race . . . . . . .
4.13 Objektklasse layer . . . . . . . . . .
4.14 Übersicht über die Objekttabellen . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Verwirklichung des Modells
19
5.1 Erstellung der Objektklassen und ihrer Tabellen . . . . . . . . . . . . . 19
5.2 Import der Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2.1 aaa attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1
5.2.2
5.2.3
5.2.4
aaa object name . . . . . . . . . . . . . . . . . . . . . . . . . . 22
aaa REO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
aaa ZUSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
A PL/SQL-Code zur Erzeugung des Datenbank-Schemas
27
B PL/SQL-Code zum Import der
B.1 aaa attribute . . . . . . . . .
B.2 aaa REO . . . . . . . . . . .
B.3 aaa ZUSO . . . . . . . . . . .
B.4 aaa object name . . . . . . .
B.5 Update aaa REO . . . . . . .
B.6 Update aaa ZUSO . . . . . .
33
33
34
35
37
38
39
Daten
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Kapitel 1
Einleitung
In Deutschland sind die Vermessungs- und Katasterverwaltungen der Bundesländer
dafür zuständig, raumbezogene Basisdaten für Verwaltung, Wirtschaft und private
Nutzer zu liefern. Diese Daten werden digital erfasst, was es notwendig macht, sie in
angemessener Form zu speichern.
Für diesen Zweck wurden schon früh die Projekte ALK und ALB für Daten des
Liegenschaftskatasters und auch das Projekt ATKIS für die Daten der Topographischen Landesaufnahme ins Leben gerufen. Dies geschah in den 70er und 80er Jahren.
Inzwischen haben die Hersteller und Nutzer dieser Daten umfangreiche Erfahrungen
gesammelt und auch die Technik und die Anforderungen der Nutzer haben sich weiterentwickelt. Aus diesem Grund wurde ein neues Konzept von der Arbeitsgemeinschaft
der Vermessungsverwaltungen der Länder der Bundesrepublik Deutschland (AdV) in
Angriff genommen.
Hieraus entsteht zur Zeit das AFIS-ALKIS-ATKIS-Referenzmodell, in dem nun
die AdV-Projekte Amtliches Festpunktinformationssystem (AFIS), Amtliches Liegenschaftskatasterinformationssytem (ALKIS) und Amtliches Topographisch-Kartographisches Informationssystem (ATKIS) zueinander in Beziehung gebracht werden.
Ziel der Studienarbeit ist es nun, eine objektrelationale Datenbank für ATKISDaten zu entwickeln, die diesem Referenzmodell entspricht. Außerdem sollen die Daten der bisherigen ATKIS-Datenbank, die am Institut für Informationssysteme, Fachgebiet Datenbankensysteme genutzt wird, in die neue übertragen werden. Auf das
Schema, welches der bisherigen Datenbank zu Grunde liegt, wird im Kapitel 2 dieser
Studienarbeit noch einmal eingegangen.
In Kapitel 3 der Arbeit wird zunächst das konzeptionelle Schema beschrieben,
welches der Datenbank zu Grunde liegt. Daran schließt sich die Beschreibung des
objektrelationalen Schemas mit seinen Objekten und Relationen an. Als letztes folgt
dann eine Beschreibung der Übertragung der Daten.
Für die Erstellung der Datenbank wird Oracle 9i und PL/SQL verwendet.
3
Kapitel 2
Übersicht über das derzeitige
ATKIS-Schema
In diesem Kapitel soll noch einmal eine Übersicht über das zur Zeit verwendete Schema gegeben werden. Für ausführliche Informationen kann in der Studienarbeit von
Stephan Falke [Fal00] oder im Informatik-Bericht vom August 2000 [KFL00] nachgelesen werden.
Im weiteren wird dieses Schema als ’altes Schema’ bezeichnet.
2.1
Konzeptionelles Schema
Zentrale Klasse ist hier die Klasse Objekt, die alle zu erfassenden Landschaftsobjekte
in ATKIS enthält. Jedem Objekt können mehrere Namen zugeordnet werden, sowie
mehrere Attribute. Des weiteren gehört es zu einer Folie und einer Objektart. Die
Klasse Objektgeometrie ist für Geometrieinformationen, die sowohl zu Objekten selbst
aber auch nur zu Objektteilen gehören können, zuständig. Im Modell gibt es auch
noch komplexe Objekte, die über die Beziehung ist Bestandteil von modelliert werden.
Objekte können auch über bzw. untereinander liegen, was über die Beziehung liegt
oberhalb von modelliert wird.
Die folgende Abbildung 2.1 entspricht der Abbildung 4.1 aus dem InformatikBericht.
4
Objektname
#Typ: VARCHAR2(2)
+Wert: VARCHAR2(31)
+GeometrieArt/Angabe: Geo_Table_Type
0..*
ist Bestandteil von
0..*
bezeichnet
1..1
0..*
Objekt
Objektart
#ObjID: VARCHAR2(7)
Folie
gehört zu
gehört zu
#Nummer: VARCHAR2(4)
+Modelltyp: VARCHAR2(2)
#Nummer: VARCHAR2(4)
1..1 +Bezeichnung: VARCHAR2(100)
0..* +Entstehungsdatum: Date 0..*
1..1
+Bezeichnung: VARCHAR2(100)
+Koordinaten: Punkt
1..1
1..1
0..1
ist Teil von
besitzt
gibt 2D-Lage an
0..1
Objektgeometrie
+Geometrie: SDO_GEOMETRY
0..*
0..*
gibt Lage an
0..1
0..1
0..*
Objektteil
#ObjektteilID: VARCHAR2(3)
besitzt
0..1
0..*
0..*
Objektattribut
0..* 0..*
hat
ist von
liegt oberhalb von
beschrieben durch
1..1
1..*
Attributtyp
#Typnummer: VARCHAR2(4)
#Name: VARCHAR2(100) 1..1
1..1
Attributwert
#Wert: VARCHAR2(4)
#Bezeichnung: VARCHAR2(100)
Abbildung 2.1: Altes Schema nach dem Informatik-Bericht [KFL00]
2.2
Relationales Schema
Aus dem konzeptionellen Schema gehen folgende Relationen hervor:
• object(ObjNo, LayerNo → layer, ObjectRaceNo → object race, CoordinateX,
CoordinateY, Actual, ModType, BuildDate)
• object geometry(ObjectNo → object, ObjectPartNo, ObjectGeometry)
• above(TopNo → object, TopPartNo, DownNo → object, DownPartNo)
• complex object(BigNo → object, SmallNo → object)
• object name(ObjectNo → object, TypeNo, Value, Geo)
• attribute(ObjectNo → object, ObjectPartNo, Type, Value)
• object race(ObjectRaceNo, Name)
• layer(LayerNo, Name)
• attribute type(AttTypeNo, Name)
• attribute value(Type, Value, Name)
5
Kapitel 3
Konzeptionelles
Datenbank-Schema
3.1
Übersicht
Dieses Datenbank-Schema ist abgeleitet aus dem AFIS-ALKIS-ATKIS-Referenzmodell.
So finden sich hier die Objekte unterteilt in räumlich Elementarobjekt und zusammengesetzte Objekte, die Präsentationsobjekte, Attribute, Layer und Objektarten
wieder.
Räumliche Elementarobjekte (REO) sind die Objekte, denen eine Geometrie zugeordnet wird und nicht weiter zerlegbar sind. Im Gegensatz dazu gibt es die zusammengesetzten Objekte (ZUSO), die wieder aus ZUSOs und REOs zusammengesetzt sind.
Jedes Objekt ist eindeutig einem Layer zugeordnet. Objekte der gleichen Objektart
liegen alle auf demselben Layer, zusammen mit Objekten anderer Objektarten. Diese
Objektarten gehen aus einem Objektartenkatalog hervor. Außerdem kann es zu jedem
Objekt noch Präsentationsobjekte geben, die zur Darstellung des Objektes dienen. Sie
enthalten die Bezeichnung und die Darstellung dieser Bezeichung in der fertigen Karte.
Im Signaturnummernkatalog sind bestimmte Signaturen für gewisse Objekte bereits
vordefiniert.
Die REOs haben außerdem noch die Eigenschaft, über bzw. untereinander zu
liegen, was in der Unter- bzw. Überführungfunktion modelliert wird.
Für andere Maßstäbe gibt es noch die Funktion ist abgeleitet aus, um das gleiche
Objekt in anderen Maßstäben zu identifizieren.
6
Abbildung 3.1: Konzeptionelles Schema
7
Folie
1..1
gehört zu
gehört zu
1..1
AU_Object
Unterführung
+Geometrie: SDO_GEOMETRY
Ueberführung
0..n
Objekt
1..1
hat
+Wert: VARCHAR2(4)
+Bezeichnung: VARCHAR2(100)
Attributwert
besitzt
0..*
1..1
1..1
Attributtyp
ist von
+Typnummer: VARCHAR2(4)
+Bezeichnung: VARCHAR2(100)
beschrieben durch
1..*
0..*
ObjektAttribut
0..*
0..*
besitzt
AP_TPO
+Geometrie: SDO_GEOMETRY
Präsentationsobjekt
+Schriftinhalt: VARCHAR2(31)
+fontSperrung: NUMBER = 0
+skalierung[0..1]: NUMBER = 1
+horizontaleAusrichtung: AP_HorizontaleAusrichtung = linksbündig
+vertikaleAusrichtung: AP_VertikaleAusrichtung = Basis
0..1
istTeilVon
0..n
ZUSO
AP_GPO
+signaturnummer: VARCHAR2
+darstellungsprioritätLinie[0..1]: NUMBER
+darstellungprioritaetFlaeche[0..1]: NUMBER
Zusammensetzung
bestehtAus
1..n
dientZurDarstellungVon
+Identifikator: VARCHAR2(7)
+Lebenszeitintevall: AA_Lebenszeitintervall
+anlass[0..1]: Sequence<AA_Anlassart>
0..* +zeigtAufExternes[0..1]: Set<Fachdatenverbindung>
0..*
+modellartenZugehoerigkeit: AA_Modellartenerkennung
hatDirektUnten
hatDirektOben
0..1
0..n
0..n
REO
+Nummer: VARCHAR2(4)
+Bezeichnung: VARCHAR2(100)
ist abgeleitet aus
0..n
Kartengeometrie
Objektart
+Nummer: VARCHAR2(4)
+Bezeichnung: Varchar2(100)
3.2
Einteilung in REO und ZUSO
Im alten Schema werden alle Objekte in einer Klasse spezifiziert. Diese Objekte sind
später in einigen Tabellen, wie zum Beispiel geometry, nochmal in Objektteile zerlegt,
oder können komplexe Objekte sein. Im neuen Schema gibt es jetzt zwei Klassen, in
denen Objekte definiert werden. Dabei fällt die Unterteilung in Objektteile weg. Im
neuen Schema sind die REOs Objekte, die nicht weiter zerlegt werden können. Daher
wurde der siebenstelligen Objektnummer jeweils die dreistellige Objektteilnummer
angehängt. So erhält man einen zehnstellige Objektidentifikator. Zusammengesetzte
Objekte bekommen den String ’000’ angehängt. So ergibt sich eine eindeutige Unterteilung in REO und ZUSO bei dem Identifikator.
Auf diese Weise enstehen aus den Objektteilen eigenständige Objekte und ihr
Oberobjekt wird zu einem zsammengesetzten Objekt.
Komplexe Objekte werden in diesem Schema einfach zu ZUSOs.
3.3
Objektnamen
Für Bezeichnungen und Beschreibungen der erfassten Objekte sind Präsentationsobjekte zuständig. Nach dem Referenzmodell erbt die Klasse Präsentatinsobjekt von den
Klassen ap tpo und ap gpo. In den Präsentationsobjekten werden alle Texte und Kartensignaturen definiert, die nicht vollautomatisch für einen bestimmten Zielmaßstab
erzeugt und platziert werden können. Die Informationen die hier aufgenommen wurden sind weit ausführlicher, als die des alten Schemas. So gab es in dem alten Schema
keine Signaturnummern und keine weiteren Angaben zu der Darstellung des Objektnamens. Jetzt gibt es noch die Eigenschaften Fontsperrung, Skalierung, horizontale
Ausrichtung und vertikale Ausrichtung, die die Darstellung des Objektnames noch
weiter beschreiben.
3.4
Attribute
Attribute werden sowohl REOs wie auch ZUSOs zugewiesen. Jedes Attribut hat einen
Wert und ist von einem bestimmten Attributtyp. Die Attributtypen sind für jeden
Maßstab fest definiert und daher unabhängig von den jeweiligen Daten. Ähnlich ist
es mit den Attributwerten. Eine ganze Reihe von Attributwerten sind bereits fest zu
Attributtypen angelegt und daher genauso unabhängig von den Daten. Zu einigen
Attributen wird aber auch direkt ein Wert angegeben, der dann nicht vorher schon
festgelegt war.
Die Attribute, Attributtypen und Attributwerte gab es bereits in genau der gleichen Form im alten Schema.
8
3.5
Folie und Objektarten
Die Folie und die Objektart sind ebenfalls statische Daten, die unabhängig von den
konkreten Daten sind. Auch diese Klassen gab es schon im alten Schema.
Jedes Objekt wird einer Objektart und einer Folie zugeordnet. Objekte der gleichen Objektart liegen auch auf der gleichen Folie. Zu jedem ATKIS-Modell eines
Maßstabs gibt es einen Objektartenkatalog. Die Folien sagen etwas über die Funktion der Objektart aus. Die Gliederung ist, anders als die Gliederung, die aus den
Objektartennummern hervorgeht, nicht hierarchisch. Daher wird die Folienzuordnung
vorgenommen, obwohl diese bereits aus der Objektartenzugehörigkeit hervor geht.
9
Kapitel 4
Objektrelationales
Datenbankschema
In diesem Kapitel wird auf die Implementation der Datenbank eingegangen. Es werden
die Klassen des erstellten Schemas beschrieben, sowie die Bedingungen der zugehörigen Objekttabellen. Zu jeder Klasse werden die einzelnen Einträge mit ihren Datentypen aufgeführt. Zusätzlich gibt es eine kurze Beschreibung, welche Informationen
der jeweilige Eintrag enthält.
Zuerst jedoch eine kleine Einführung zum Datentyp REF:
4.1
Benutzung des Datentyp REF
An vielen Stellen des Schemas wird jetzt der Datentyp REF benutzt. Er ersetzt frühere Fremdschlüsselbeziehungen. Einträge dieses Datentyps sind Zeiger auf Objekte. Bei
der Initialisierung des Datentyps muss eine Objektklasse angegeben werden, auf die
der Zeiger verweist. Wird so ein Datentyp in einer Tabelle verwendet, kann ihm eine
konkrete Zieltabelle zugewiesen werden. Diese Tabelle muss Objekte des Typs enthalten, der vorher dem Zeiger zugewiesen wurde oder aber Subtypen dieses Typs. Diese
Zuweisung wird als SCOPE bezeichnet. Durch die Zuweisung eines solchen SCOPES
wird der Speicherplatzbedarf dieses Zeigers in der Tabelle um einiges reduziert.
Man erhält einen Zeiger durch anwenden der integrierten Funktion REF(). Dies
soll einmal an einem Beispiel verdeutlicht werden.
SELECT REF(p)
FROM aaa_layer p;
Diese Anfrage liefert Zeiger, die auf die Objekte in der Tabelle aaa layer verweisen.
Die Zeiger können dann in anderen Tabellen als Eintrag gespeichert werden.
Um später auf die Daten, auf die der Zeiger zeigt direkt zuzugreifen, wird einfach
die integrierte Funktion DEREF() verwendet. Eine entsprechende Anfrage würde folgendermaßen aussehen:
10
SELECT DEREF(layer_ref)
FROM aaa_REO;
Diese Anfrage liefert die Objekte der Tabelle aaa layer, auf die die Referenzen
verweisen.
Die Funktionen REF() und DEREF() werden in der Oracle-Dokumentation noch
näher beschrieben.
4.2
Objektklasse aa object
Name
Obj ID
lebenszeitintervall
anlass
zeigtAufExternes
ObjRace ref
CoordinateX
CoordinateY
modType
layer ref
name ref
attr ref
Klasse aa
Name
beginnt
endet
Datentyp
Beschreibung
VARCHAR2(10)
Identifikation des Objekts
aa lebenszeitintervall
VARCHAR2(50)
VARCHAR2(50)
REF race
Referenz auf die zugehörige
Objektart (4.12)
NUMBER(9)
NUMBER(9)
VARCHAR2(2)
REF aa layer
Referenz auf den zugehörigen
Layer (4.13)
name ref table type Tabelle mit Referenzen auf zugehörige
Präsentationsobjekte (4.8)
attr ref table type
Tebelle mit Referenzen auf zugehörige
Attribute (4.9)
lebenszeitintervall:
Datentyp Beschreibung
DATE
DATE
Diese Klasse ist die zentrale Klasse zur Definition der Objekte. Sie definiert die gemeinsamen Eigenschaften der REOs und ZUSOs. Die Klasse wird als NOT FINAL
deklariert, damit die Klassen aa REO und aa ZUSO noch von ihr erben können. In
ihnen werden die Objekte noch einmal differenziert. Zu dieser Klasse gibt es keine
direkte Objekttabelle.
Die Obj ID ist ein zehnstelliger Charakterstring der zur Identifikation des Objektes
dient. Dabei sind die ersten sieben Stellen vom alten Schema übernommen. Die letzten
drei Stellen ergeben sich aus der neuen Zuordnung der Objekte zu REOs und ZUSOs.
Hierauf wurde in Kapitel 3.2 bereits näher eingegangen.
Das Lebenszeitintervall gibt an, wann das Objekt erstellt wurde, und wann es eventuell seine Gültigkeit verliert. anlass und zeigtAufExternes sind neu in dem ATKIS-
11
Referenzmodell vorgesehen. Die beiden Einträge CoordinateX und CoordinateY sind
zusätzlich aus dem alten Schema in diese Klasse mit aufgenommen worden, da sie
unter Umständen noch benötigt werden.
Die vier Einträge ObjRace ref, layer ref, name ref und attr ref enthalten jeweils
Referenzen des Datentyps REF. Dieser Datentyp implementiert Zeiger auf andere Tabellen. Eine nähere Beschreibung dieses Datentyps fand bereits in Kapitel 4.1 statt.
Da es bei den letzten beiden Einträgen vorkommen kann, dass auf mehrere Objekte
referenziert werden muss, werden hier geschachtelte Tabellen (nested tables) verwendet.
4.3
Objektklasse aa REO
Name
Datentyp
Beschreibung
modellartenZugehörigkeit VARCHAR2(7)
geo ref
REF geom
Referenz zur zugehörigen
Geometrie (4.5)
Diese Klasse erbt von der Klasse aa object. Sie dient zur Spezifikation von räumlichen
Elementarobjekten (REO). Jedes REO besitzt eine es beschreibende Geometrie. Diese
Geometrie wird, anders als nach dem allgemeinen Schema, nicht direkt in der Klasse
selbst abgelegt, sondern in der separaten Klasse geom (4.5). Dies fördert die Übersicht
und verringert die Datenmenge dieser Klasse.
Diese Klasse besitzt außerdem noch zwei Funktionen.
• hatDirektOben
Diese Funktion liefert eine Tabelle des Typs object table type zurück. Diese Tabelle enthält alle Obj IDs von Objekten, die über diesem Objekt liegen.
• hatDirektUnten
Diese Funktion liefert ebenfalls eine Tabelle des Typs object table type zurück.
In diesem Falle mit Obj IDs von Objekten, die unter diesem Objekt liegen.
Die Funktionen greifen dafür auf die Objekttabelle above (4.6) zu, in der diese Verhältnisse beschrieben sind.
Zu dieser Klasse gehört die Objekttabelle REO. Für ihre Spalten gelten noch folgende Bedingungen:
• Obj ID ist Primärschlüssel
• ObjRace ref darf nicht leer sein und hat als Zieltabelle object race
• layer ref darf nicht leer sein und hat als Zieltabelle layer
• geo ref darf nicht leer sein und hat als Zieltabelle geometry
12
• Die Einträge der nested table attr ref haben als Zieltabelle attribute
• Die Einträge der nested table name ref haben als Zieltabelle object name
4.4
Objektklasse aa ZUSO
Name
Datentyp
modellartenZugehörigkeit VARCHAR2(7)
combined of
combined of table type
Beschreibung
Referenzen zu zugehörigen
Unterobjekten
Diese Klasse erbt ebenfalls von der Klasse aa object. Sie dient zur Spezifikation von
zusammengesetzten Objekten (ZUSO). Diese Objekte haben Unterobjekte aus denen
sie zusammengesetzt sind. Dies können REOs aber auch wieder ZUSOs sein. Diese
Objekte werden in der nested table combined of referenziert. Dementsprechend enthält sie Objekte vom Typ REF aa object.
Zu dieser Klasse gehört die Objekttabelle ZUSO. Für diese sind folgende Bedingungen
definiert:
• Obj ID Primärschlüssel
• ObjRace ref darf nicht leer sein und hat als Zieltabelle object race
• layer ref darf nicht leer sein und hat als Zieltabelle layer
• Die Einträge der nested table attr ref haben als Zieltabelle attribute
• Die Einträge der nested table name ref haben als Zieltabelle object name
Für die Spalte combined of kann keine Zieltabelle angegeben werden, da die Zeiger
auf unterschiedliche Tabellen verweisen müssen.
4.5
Objektklasse geom
Name
Datentyp
Beschreibung
Obj ID
VARCHAR2(10)
Identifikator des Objekts
geometry mdsys.sdo geometry Geometrie des Objekts
Diese Klasse dient als Unterlage für eine Objekttabelle, in der die ausgelagerten
Geometrien aus der Tabelle ZUSO gespeichert werden. Die Geometrien werden in dem
Datentyp mdsys.sdo geometry gespeichert. In diesem Datentyp sind sie auch bereits in
der alten Datenbank gespeichert und können daher einfach übernommen werden. Eine
13
genauere Beschreibung dieses Datentyps kann man in der Studienarbeit von Stephan
Falke [Fal00] finden.
Für die Objekttabelle gelten noch folgende Bedingungen:
• Obj ID Primärschlüssel
• geometry darf nicht leer sein
4.6
Objektklasse above obj
Name
Datentyp
Beschreibung
top ID
VARCHAR2(10) Identifikator des oben liegenden Objekts
down ID VARCHAR2(10) Identifikator des unten liegenden Objekts
Objekte können sich gegenseitig überlappen, das heißt, ein Objekt liegt über dem
anderen. Diese Klasse dient dazu dieses zu modellieren. Auf die Objekttabelle dieser
Klasse wird von den beiden Funktionen der Klasse aa REO (4.3) zugegriffen.
In der Objekttabelle sind beide Einträge gemeinsam Primärschlüssel.
4.7
Objektklasse ap gpo
Name
Obj ID
Datentyp
VARCHAR2(10)
signaturnummer
darstellungsprioritätsLinie
darstellungprioritätsFläche
VARCHAR2(100)
NUMBER
NUMBER
Beschreibung
Identifikation des zugehörigen
Objekts
Diese Klasse ist im Referenzmodell vorgesehen. Sie dient nur als Oberklasse für die
Präsentationsobjekte. Die Signaturnummern sind im Signaturenkatalog definiert und
dienen zur Steuerung der Darstellung der Präsentationsobjekte.
14
4.8
Objektklasse präsentationsobjekt
Name
TypeNo
schriftinhalt
fontSperrung
skalierung
horizontaleAusrichtung
vertikaleAusrichtung
geometry
name count
Datentyp
VARCHAR2(2)
VARCHAR2(31)
NUMBER
NUMBER
VARCHAR2(13)
Beschreibung
Art des Namens
Bezeichnung des Objektes
0
1
Mögliche Werte: linksbündig,
rechtsbündig,
zentriert
VARCHAR2(5)
Mögliche Werte: Basis,
Mitte,
oben
mdsys.sdo geometry Geometrische Beschreibung des
Präsentationsobjekts
NUMBER
Zähler, der jeweils über Einträge
zum gleichen Objekt läuft
Diese Klasse dient zur Spezifikation von Präsentationsobjekten und erbt von der Klasse ap gpo. Präsentationsobjekte sind Objekte, die zur Beschreibung der eigentlichen
Objekte dienen. So enthalten sie im schriftinhalt die Bezeichnung des Objekts und
wie diese Bezeichnung auf der späteren Karte gestalltet werden soll. Dafür sorgen die
Werte bei fontSperrung, skalierung, horizontaleAusrichtung und vertikaleAusrichtung.
Der Grund für die Einführung der Spalte name count liegt in der Vergabe des Primärschlüssels in der zugehörigen Objekttabelle. Spalten des Datentyps
mdsys.sdo geometry können nicht zu einem Primärschlüssel hinzugenommen werden.
Ohne diese Spalte ließ sich keine Eindeutigkeit herstellen.
Der Eintrag TypeNo wurde aus dem alten Schema übernommen. Er kann drei
Werte annehmen, die folgende Bedeutung haben:
• GN: geographischer Name
• KN: Klassifizierungsname
• ZN: Zweitname
Die in der obigen Tabelle unterstrichenen Werte sind die Standardwerte die im
Referenzmodell festgelegt sind.
Zu den Präsentationsobjekten gehört nun die Objekttabelle object name. Für die
Tabelle gelten folgende Bedingungen:
• Primärschlüssel sind die Spalten Obj ID und name count
• TypeNo darf nicht leer sein
• schriftinhalt darf nicht leer sein
15
4.9
Name
Obj ID
Type
Value
Objektklasse attr
Datentyp
VARCHAR2(10)
REF attr type type
VARCHAR2(7)
Beschreibung
Identifikation des zugehörigen Objekts
Referenz zum zugehörigen Attributtyp (4.10)
Wert des Attributs
Diese Klasse dient zur Spezifikation von Attributen. Attribute sind immer von einem
bestimmten Typ und haben einen Wert.
Dieser Wert, der in der Spalte Value steht, ist entweder ein Verweis auf die Objekte
der Klasse attr value, welche dann die tatsächlichen Werte enthalten oder sind bereits
die Werte selbst. Aus diesem Grund kann hier kein Zeiger verwendet werden. Die
Typen hingegen sind alle in der Tabelle attribute type abgelegt und können in dieser
referenziert werden.
Die Objekttabelle attribute ist die zugehörige Objekttabelle, in der noch folgende
Bedingung gilt:
• Zieltabelle von Type ist attribute type
4.10
Objektklasse attr type
Name
Datentyp
Beschreibung
AttrTypeNo VARCHAR2(4)
Attributtypennummer
Name
VARCHAR2(100) Bezeichnung des Attributtyps
Diese Klasse dient zur Spezifikation von Attributtypen. In der zugehörigen Objekttabelle ist die AttrTypeNo Primärschlüssel.
Attributtypen sind für jeden Maßstab standardisiert und unabhängig von den
tatsächlich gespeicherten Informationen.
4.11
Name
Type
Value
Name
Objektklasse attr value
Datentyp
VARCHAR2(4)
VARCHAR2(7)
VARCHAR2(100)
Beschreibung
Verweis auf den zugehörigen Attributtyp
Attributwert
Bezeichnung
Diese Klasse dient zur Spezifikation von Attributwerten. In der zugehörigen Objekttabelle sind die Spalten Type und Value gemeinsam Primärschlüssel.
In der Tabelle werden Werte zu bestimmten Attributtypen abgelegt. Diese sind
dann ebenfalls standardisiert und unabhängig von den tatsächlich gespeicherten In-
16
formationen. Es gibt jedoch auch Attribute bei denen der Attributwert direkt beim
Attribut gespeichert wird.
4.12
Objektklasse object race
Name
Datentyp
Beschreibung
ObjectRaceNo VARCHAR2(4)
Identifikation der Objektart
Name
VARCHAR2(100) Bezeichnung der Objektart
Diese Klasse dient zur Spezifikation von Objektarten. Diese Objektarten sind für jeden
Maßstab in einem Objektartenkatalog definiert.Objektarten sind ebenfalls, wie auch
bereits in Kapitel 3.5 beschrieben, standardisiert.
Zu dieser Klasse gehört die Objekttabelle object race, welche als Primärschlüssel
ObjectRaceNo besitzt.
4.13
Objektklasse layer
Name
Datentyp
Beschreibung
LayerNo VARCHAR2(3)
Identifikation des Layer
Name
VARCHAR2(100) Bezeichnung des Layer
Diese Klasse dient zur Spezifikation der Layer. Jede Objektart ist einer Folie (Layer)
zugeordnet. Also liegen zum Beispiel alle Objekte der gleichen Objektart auf der
gleichen Folie. Die Folien sind auch standardisiert für die unterschiedlichen Maßstäbe.
Zu dieser Klasse gehört die Objekttabelle layer, welche als Primärschlüssel
LayerNo besitzt.
4.14
Übersicht über die Objekttabellen
Im folgenden Diagramm soll noch einmal ein Überblick über die Objekttabellen gegeben werden. Dabei sind zur Förderung der Übersichtlichkeit die Spalten der Tabellen
weggelassen worden. Auf diese wurde in diesem Kapitel auch schon ausführlich eingegangen. In dem Diagramm geht es vorallem um eine Übersicht, in welchen Beziehungen
die Tabellen zueinander stehen.
17
object_name
M
M
geometry
bezeichnet
bezeichnet
1
1
1
beschreibt
M
1
ZUSO
besteht aus
M
hat oben
1
1
M
REO
M
above
1
M
M
hat unten
liegt auf
liegt auf
1
1
Layer
M
M
ist von
1
ist von
1
1
1
object_race
besitzt
M
besitzt
M
attribute
M
hat
M
ist von
1
1
attribute_type
attribute_value
Abbildung 4.1: Beziehungen zwischen den Objekttabellen
18
Kapitel 5
Verwirklichung des Modells
Im folgenden wird beschrieben, wie die Daten von der alten Datenbank in die neue
Datenbank importiert werden. Damit es nicht zu Überschneidungen mit den Bezeichnungen der Tabellen aus dem alten Schema kommt, wird den Tabellen des neuen
Schemas ’aaa’ vorangestellt.
5.1
Erstellung der Objektklassen und ihrer Tabellen
Zunächst werden die Objektklassen und ihre Objekttabellen erzeugt. Dies soll hier
einmal am Beispiel der Tabelle aaa reo erläutert werden. Der vollständige Quelltext
steht in Anhang A.
Zunächst werden die Objektklassen aa object und aa reo implementiert:
CREATE TYPE aa_object AS OBJECT (
Obj_ID VARCHAR2(10),
lebenszeitintervall aa_lebenszeitintervall,
anlass VARCHAR2(50),
zeigtAufExternes VARCHAR2(50),
ObjRace_ref REF race,
CoordinateX NUMBER(9),
CoordinateY NUMBER(9),
modType VARCHAR2(2),
layer_ref REF aa_layer,
name_ref name_ref_table_type,
attr_ref attr_ref_table_type
) NOT FINAL;
/
19
CREATE TYPE aa_reo UNDER aa_object (
modellartenZugehoerigkeit VARCHAR2(7),
geo_ref REF geom,
MEMBER FUNCTION hatDirektOben RETURN object_table_type,
MEMBER FUNCTION hatDirektUnten RETURN object_table_type);
/
Diese Klassen dürfen in der Reihenfolge erst nach den Klassen aa lebenszeitintervall,
race, aa layer, name ref tabel type, attr ref tabel type und geom erzeugt werden, damit auf sie in dieser Klasse zugegriffen werden kann. So ergibt sich für alle Klassen
eine Reihenfolge in der sie implementiert werden müssen. Auch für die Vererbungen
ist dies wichtig.
Die Objekttabelle wird dann wie folgt erzeugt:
CREATE TABLE aaa_reo OF aa_reo (
Obj_ID PRIMARY KEY,
layer_ref NOT NULL SCOPE IS aaa_layer,
geo_ref NOT NULL SCOPE IS aaa_geometry,
ObjRace_ref NOT NULL SCOPE IS aaa_object_race
)
Da dies eine Objekttabelle ist, müssen nur noch die Bedingungen festgelegt werden. In dieser Tabelle bekommen zum Beispiel die Spalten layer ref, geo ref und
ObjRace ref, die vom Datentyp REF sind, Zieltabellen zugewiesen.
Bei dieser Klasse ist es nun so, dass auch die Funktionen noch näher definiert
werden müssen. Dies geschieht nachdem alle Objekttabellen erzeugt wurden.
CREATE OR REPLACE TYPE BODY aa_reo AS
MEMBER FUNCTION hatDirektOben RETURN object_table_type IS
TYPE ObjCurTyp IS REF CURSOR;
obj_cv ObjCurTyp;
tab object_table_type;
BEGIN
OPEN obj_cv FOR
SELECT top_ID
FROM aaa_above
WHERE SELF.Obj_ID = down_ID;
FETCH obj_cv BULK COLLECT INTO tab;
CLOSE obj_cv;
RETURN tab;
END;
20
MEMBER FUNCTION hatDirektUnten RETURN object_table_type IS
TYPE ObjCurTyp IS REF CURSOR;
obj_cv ObjCurTyp;
tab object_table_type;
BEGIN
OPEN obj_cv FOR
SELECT down_ID
FROM aaa_above
WHERE SELF.Obj_ID = top_ID;
FETCH obj_cv BULK COLLECT INTO tab;
CLOSE obj_cv;
RETURN tab;
END;
END;
/
Bei einer MEMBER FUNCTION gibt es den Parameter SELF, der als das Objekt
initialisiert wird, für das die Funktion aufgerufen wurde. Mit Hilfe dieses Parameters
liefern die SELECT-Anweisungen entsprechend zu dem Objekt, zu dem die Funktion aufgerufen wurde, die Objektnummern der Objekte, die über bzw. unter diesem
Objekt liegen. Diese werden in der Variable tab gespeichert und zurückgegeben.
Die Funktionen können zum Beispiel folgendermaßen benutzt werden:
SELECT value(p).hatdirektoben()
FROM aaa_reo p
WHERE lower(obj_id)=’n01a5yf002’;
Diese Anfrage liefert OBJECT_TABLE_TYPE(’N0061KV001’) zurück.
5.2
Import der Daten
In die so erstellten Tabellen müssen nun noch die Daten aus der alten Datenbank
übertragen werden. Dabei ist besonderes Augenmerk auf die korrekte Verteilung der
Objekte, komplexen Objekte und Objektteile auf REO und ZUSO zu legen.
Bei den Tabellen aaa object race, aaa layer, aaa attribute value und
aaa attribute type hat sich die Struktur der Tabelle nicht geändert, daher können
die Daten eins zu eins übertragen werden. Ähnlich einfach ist es bei den Tabellen
aaa above und aaa geometry. Hier müssen nur die Objektteilnummern an zugehörige
Objektnummer angehängt werden.
Hier ein Beispiel:
INSERT INTO aaa_above
SELECT topno || toppartno, downno ||downpartno
FROM above;
21
Auf die restlichen Tabellen wird separat eingegangen.
5.2.1
aaa attribute
In dieser Tabelle wird beim Attributtyp der Datentyp REF verwendet. Es muß also
über die Funktion REF() der Zeiger zur Tabelle aaa attribute type erzeugt werden. Da
dies nur für jeden Eintrag einzeln geschehen kann, wird ein Cursor über die Tabelle
attribute der alten Datenbank verwendet. Die Referenz bekommt man folgendermaßen:
SELECT REF(p) INTO type_ref
FROM aaa_attribute_type p
WHERE p.AttrTypeNo = attr_record.type;
Die Attribute sind zur Zeit zu Objektnummer und Objektteilnummer gespeichert.
Also kann die neue Objektnummer auch hier einfach aus den beiden Teilen zusammengesetzt werden. Der Attributwert wird übernommen.
5.2.2
aaa object name
Bei den Objektnamen ist es so, dass im alten Schema jedem Objekt mehrere Objektnamen zugeordnet sein können. Diese Objekte können in drei Kategorien eingeteilt
werden, die in der neuen Tabelle separat zu betrachten sind.
• Objekte, die komplexe Objekte waren:
Diese Objekte werden zu ZUSOs und die Objektnummer bekommt daher ’000’
angehängt.
• Objekte, die noch einmal aus Objektteilen bestanden:
Auch diese Objekte werden zu ZUSO und bekommen ’000’ an die Objektnummer
angehängt. Die REOs, die aus den Objektteilen hervorgehen, bekommen als
Objektnamen den des ZUSO zugewiesen, an dem sie beteiligt sind.
• Objekte, die nicht aus Objektteilen bestanden, aber auch nicht komplexes Objekt waren:
Die Objektnummern dieser Objekte enden auf ’001’ und sind jetzt REOs. Beim
Übertragen der Daten ist es besonders schwer, diese Objekte zu identifizieren, da
in der Tabelle object name keine Unterscheidung in Objektteile getroffen wurde. So ist nur schwer herauszufinden, welche Objekte nicht mehr in Objektteile
unterteilt sind.
Um die Probleme beim Identifizieren der Objekte zu umgehen, werden zunächst
die Tabellen aaa REO und aaa ZUSO vervollständigt. Danach kann für die Unterscheidung auf diese beiden Tabellen zurückgegriffen werden. Dies hat aber
zur Folge, dass wiederum die Referenzen, die in den beiden Tabellen auf die Tabelle mit den Objektnamen genommen werden, erst nachträglich erstellt werden
können.
22
Damit ergeben sich zwei Cursor, die durchlaufen werden müssen:
--alle, die jetzt ein ZUSO sind
CURSOR name_zuso_cursor IS
SELECT n.objectno || ’000’ id,n.type,p.*
FROM object_name n, TABLE(n.geometries) p,aaa_zuso z
WHERE n.objectno || ’000’=z.Obj_ID;
--alle, die jetzt kein zuso, also nur einmal im reo vorkommen
CURSOR name_reo_cursor IS
SELECT n.objectno || ’001’ id,n.type,p.*
FROM object_name n, TABLE(n.geometries) p,
(SELECT distinct substr(obj_id,1,7) id
FROM aaa_reo
MINUS
SELECT substr(obj_id,1,7) from aaa_reo
WHERE substr(obj_id,8,10)=’002’) r
WHERE n.objectno=r.id ;
Die geschachtelte Tabelle innerhalb der Ursprungstabelle wird innerhalb der Cursor aufgelöst. Um die Einträge zu selektieren, die in die letzte der oben genannten
Kategorie fallen, werden zunächst die alten Objektnummern (die ersten sieben Stellen) ausgewählt. Von diesen werden dann alle abgezogen, die auch auf ’002’ enden.
Dies sind alle, wo das alte Objekt mehrere Teilobjekte hatte.
Um die laufende Nummer zu erzeugen, wird in einer Variablen jeweils die im
letzten Durchlauf aktuelle Objektnummer gespeichert. Im nächsten Durchlauf wird die
Objektnummer mit dieser Variablen verglichen und entsprechend ein Zähler verändert.
Die Spalten signaturnummer, darstellungsprioritaetsLine und darstellungsprioritaetsFlaeche bleiben leer, da für sie keine Daten in der alten Datenbank vorhanden
sind. Die Spalten fontSperrung, skalierung, horizontaleAusrichtung und vertikaleAusrichtung werden auf die im Referenzmodell forgesehenen Standardwerte gesetzt. Diese
sind:
• fontSperrung=0
• skalierung=1
• horizontaleAusrichtung=’linksbuendig’
• vertikaleAusrichtung=’Basis’
Die restlichen Spalten können von der Ausgangstabelle übernommen werden.
23
5.2.3
aaa REO
Die REOs sind diejenigen Objekte des alten Schemas, die eine Geometrie haben. Daher
können die neuen Objekte einfach aus der Tabelle object in Kombination mit der Tabelle object geometry erzeugt werden, da die Zuordnung in der Tabelle object geometry
bereits zu den Objektteilen erfolgt.
Auch hier müssen die Referenzen vor dem Einfügen erzeugt werden. In den Spalten, wo geschachtelte Tabellen zum Einsatz kommen, wird zunächst eine leere Tabelle eingefügt. Diese Tabellen werden später gemeinsam gefüllt, nachdem die Tabelle
aaa object name vervollständigt wurde.
Die Spalten anlass, zeigtAufExternes und modellartenZugehoerigleit bleiben auf
Grund fehlender Daten leer.
Das Einfügen in die geschachtelten Tabellen geschieht mit einem Cursor Zeile für
Zeile. Die Einfügeoperation sieht dabei folgendermaßen aus:
INSERT INTO TABLE(SELECT attr_ref
FROM aaa_reo
WHERE Obj_ID=update_rec.Obj_ID)
(SELECT REF(p)
FROM aaa_attribute p
WHERE p.Obj_ID=update_rec.Obj_ID);
Entsprechend für die geschachtelte Tabelle mit den Verweisen zu den Namen.
5.2.4
aaa ZUSO
Die ZUSOs sind die Objekte, die entweder vorher aus Objektteilen bestanden haben
oder ein komplexes Objekt waren. Diese werden mit Hilfe von zwei unterschiedlichen
Originaltabellen selektiert. Daher sind hier zwei Cursor für das Übertragen der Daten
notwendig. Alle in diese Tabelle aufgenommenen Objektnummern bekommen ’000’
hinten angehängt.
Die Cursor sehen wie folgt aus:
• CURSOR zuso_cursor IS
SELECT o.*
FROM object o, object_geometry g
WHERE o.objno=g.objectno and g.objectpartno=’002’;
Hier werden alle Objekte ausgewählt, die mehr als eine Objetteilnummer besitzen. Diese gehören nun zu den ZUSOs, bestehen in ihrer Zusammensetzung
aber nur aus REOs.
24
• CURSOR zuso_complex_cursor IS
SELECT distinct o.*
FROM object o, complex_object c
WHERE o.objno=c.bigno;
Hier werden alle Objekte ausgewählt, die in der Tabelle complex onbject als
Oberobjekt ausgewiesen sind. Diese Objekte können jetzt aus REOs und ZUSOs
zusammengesetzt sein.
In dieser Tabelle bleiben ebenfalls die Spalten anlass, zeigtAufExternes und modellartenZugehoerigleit leer. Wie bei der Tabelle REO werden zunächst die geschachtelten
Tabellen leer initialisiert und nach der Bearbeitung der Tabelle aaa object name noch
einem Update unterzogen.
Das Update der beiden Spalten name ref und attr ref werden wie bei der Tabelle
aaa REO durchgeführt. Das Update der Spalte combined of ist um einiges schwieriger.
Dies liegt an den unterschiedlichen Möglichkeiten der Zusammensetzung der ZUSOs.
• Wenn das ZUSO früher ein Objekt mit Objektteilen war, ist es jetzt nur aus
Einträgen in der Tabelle aaa REO zusammengesetzt. Diese können einfach über
die alte Objektnummer, also sie ersten sieben Zeichen, ausgewählt werden.
INSERT INTO TABLE(select combined_of
from aaa_zuso
where Obj_ID=update_rec.Obj_ID)
(SELECT REF(p)
FROM aaa_reo p
WHERE substr(Obj_ID,1,7)=substr(update_rec.Obj_ID,1,7));
• Wenn das ZUSO aus einem früheren komplexen Objekt entstanden ist, besteht
es nun aus ZUSOs, die früher Objekte mit mehreren Teilobjekten waren, sowie
aus REOs, die früher Objekte ohne Teilobjekte waren.Es sind also Referenzen
zu zwei unterschiedlichen Tabellen, also werden zwei INSERT-Operationen benötigt. Die Verknüpfung geschieht hier über die alte Tabelle complex object, in
der ja gerade die alten Teilobjekte enthalten sind.
INSERT INTO TABLE(select combined_of
from aaa_zuso
where Obj_ID=update_rec.Obj_ID)
(SELECT REF(p)
FROM aaa_zuso p,complex_object c
WHERE substr(p.Obj_ID,1,7)=c.smallno
AND c.bigno=substr(update_rec.Obj_ID,1,7));
25
INSERT INTO TABLE(select combined_of
from aaa_zuso
where Obj_ID=update_rec.Obj_ID)
(SELECT REF(p)
FROM aaa_reo p, complex_object c
WHERE substr(p.Obj_ID,1,7)=c.smallno
AND c.bigno=substr(update_rec.Obj_ID,1,7));
26
Anhang A
PL/SQL-Code zur Erzeugung des
Datenbank-Schemas
--------Erzeugen der Objekttypen--------------CREATE TYPE race AS OBJECT (
ObjectRaceNo VARCHAR2(4),
Name VARCHAR2(100));
/
CREATE TYPE aa_layer AS OBJECT (
LayerNo VARCHAR2(3),
Name VARCHAR2(100));
/
CREATE TYPE above_obj AS OBJECT (
top_ID VARCHAR2(10),
down_ID VARCHAR2(10));
/
CREATE TYPE attr_type_type AS OBJECT (
AttrTypeNo VARCHAR2(4),
Name VARCHAR2(100));
/
CREATE TYPE attr_value_type AS OBJECT (
Type VARCHAR2(4),
Value VARCHAR2(7),
Name VARCHAR2(100));
/
27
CREATE TYPE attr AS OBJECT (
Obj_ID VARCHAR2(10),
Type REF attr_type_type,
Value VARCHAR2(7));
/
CREATE TYPE ap_gpo AS OBJECT (
Obj_ID VARCHAR2(10),
signaturnummer VARCHAR2(100),
darstellungsprioritaetsLinie NUMBER,
darstellungsprioritaetsFlaeche NUMBER
) NOT FINAL;
/
CREATE TYPE praesentationsobjekt UNDER ap_gpo (
TypeNo VARCHAR2(2),
schriftinhalt VARCHAR2(31),
fontSperrung NUMBER,
skalierung NUMBER,
horizontaleAusrichtung VARCHAR2(13),
vertikaleAusrichtung VARCHAR2(5),
geometry mdsys.sdo_geometry,
name_count NUMBER);
/
CREATE TYPE aa_lebenszeitintervall AS OBJECT (
beginnt DATE,
endet DATE);
/
CREATE TYPE ref_praes AS OBJECT (
ref REF praesentationsobjekt);
/
CREATE TYPE ref_attr AS OBJECT (
ref REF attr);
/
CREATE TYPE name_ref_table_type AS TABLE OF ref_praes;
/
28
CREATE TYPE attr_ref_table_type AS TABLE OF ref_attr;
/
CREATE TYPE aa_object AS OBJECT (
Obj_ID VARCHAR2(10),
lebenszeitintervall aa_lebenszeitintervall,
anlass VARCHAR2(50),
zeigtAufExternes VARCHAR2(50),
ObjRace_ref REF race,
CoordinateX NUMBER(9),
CoordinateY NUMBER(9),
modType VARCHAR2(2),
layer_ref REF aa_layer,
name_ref name_ref_table_type,
attr_ref attr_ref_table_type
) NOT FINAL;
/
CREATE TYPE geom AS OBJECT (
Obj_ID VARCHAR2(10),
geometry mdsys.sdo_geometry);
/
CREATE TYPE combined_of_table_type AS TABLE OF REF aa_object;
/
CREATE TYPE object_table_type AS TABLE OF VARCHAR2(10);
/
CREATE TYPE aa_reo UNDER aa_object (
modellartenZugehoerigkeit VARCHAR2(7),
geo_ref REF geom,
MEMBER FUNCTION hatDirektOben RETURN object_table_type,
MEMBER FUNCTION hatDirektUnten RETURN object_table_type);
/
CREATE TYPE aa_zuso UNDER aa_object (
modellartenZugehoerigkeit VARCHAR2(7),
combined_of combined_of_table_type);
/
29
--------Erzeugen der Tabellen---------------------CREATE TABLE aaa_layer OF aa_layer(
LayerNo NOT NULL constraint pk_layer_obj PRIMARY KEY
);
CREATE TABLE aaa_object_race OF race(
ObjectRaceNo PRIMARY KEY
);
CREATE TABLE aaa_geometry OF geom(
Obj_ID PRIMARY KEY,
geometry NOT NULL
);
CREATE TABLE aaa_above OF above_obj (
constraint pk_above PRIMARY KEY (top_ID,down_ID)
);
CREATE TABLE aaa_attribute_type OF attr_type_type(
AttrTypeNo NOT NULL constraint pk_attr_type PRIMARY KEY
);
CREATE TABLE aaa_attribute_value OF attr_value_type(
Type NOT NULL,
Value NOT NULL,
constraint pk_attr_value PRIMARY KEY (Type, Value)
);
CREATE TABLE aaa_attribute OF attr(
Obj_ID NOT NULL,
type NOT NULL SCOPE IS aaa_attribute_type,
value NOT NULL,
constraint pk_attr PRIMARY KEY (Obj_ID,type,value)
);
30
CREATE TABLE aaa_object_name OF praesentationsobjekt(
Obj_ID NOT NULL,
TypeNo NOT NULL,
schriftinhalt NOT NULL,
name_count NOT NULL,
constraint pk_obj_name PRIMARY KEY (Obj_ID, name_count)
);
CREATE TABLE aaa_reo OF aa_reo (
Obj_ID PRIMARY KEY,
layer_ref NOT NULL SCOPE IS aaa_layer,
geo_ref NOT NULL SCOPE IS aaa_geometry,
ObjRace_ref NOT NULL SCOPE IS aaa_object_race
)
NESTED TABLE name_ref STORE AS name_ref_reo_table,
NESTED TABLE attr_ref STORE AS attr_ref_reo_table;
CREATE TABLE aaa_zuso OF aa_zuso (
Obj_ID PRIMARY KEY,
layer_ref NOT NULL SCOPE IS aaa_layer,
ObjRace_ref NOT NULL SCOPE IS aaa_object_race
)
NESTED TABLE combined_of STORE AS combined_of_table,
NESTED TABLE name_ref STORE AS name_ref_zuso_table,
NESTED TABLE attr_ref STORE AS attr_ref_zuso_table;
ALTER TABLE name_ref_reo_table
ADD (SCOPE FOR (ref) IS aaa_object_name);
ALTER TABLE name_ref_zuso_table
ADD (SCOPE FOR (ref) IS aaa_object_name);
ALTER TABLE attr_ref_reo_table
ADD (SCOPE FOR (ref) IS aaa_attribute);
ALTER TABLE attr_ref_zuso_table
ADD (SCOPE FOR (ref) IS aaa_attribute);
31
CREATE OR REPLACE TYPE BODY aa_reo AS
MEMBER FUNCTION hatDirektOben RETURN object_table_type IS
TYPE ObjRecTyp IS RECORD (obj_ID VARCHAR2(10));
TYPE ObjCurTyp IS REF CURSOR RETURN ObjRecTyp;
obj_cv ObjCurTyp;
tab object_table_type;
BEGIN
OPEN obj_cv FOR
SELECT top_ID
FROM aaa_above
WHERE SELF.Obj_ID = down_ID;
FETCH obj_cv BULK COLLECT INTO tab;
RETURN tab;
END;
MEMBER FUNCTION hatDirektUnten RETURN object_table_type IS
TYPE ObjRecTyp IS RECORD (obj_ID VARCHAR2(10));
TYPE ObjCurTyp IS REF CURSOR RETURN ObjRecTyp;
obj_cv ObjCurTyp;
tab object_table_type;
BEGIN
OPEN obj_cv FOR
SELECT down_ID
FROM aaa_above
WHERE SELF.Obj_ID = top_ID;
FETCH obj_cv BULK COLLECT INTO tab;
RETURN tab;
END;
END;
/
32
Anhang B
PL/SQL-Code zum Import der
Daten
Zunächst der Code für die Tabellen, die fast eins zu eins übernommen werden:
INSERT INTO aaa_object_race SELECT * FROM object_race;
INSERT INTO aaa_attribute_value SELECT * FROM attribute_value;
INSERT INTO aaa_attribute_type SELECT * FROM attribute_type;
INSERT INTO aaa_layer SELECT * FROM layer;
INSERT INTO aaa_above
SELECT topno || toppartno, downno ||downpartno
FROM above;
INSERT INTO aaa_geometry
SELECT ObjectNo || ObjectPartNo, ObjectGeometry
FROM object_geometry;
B.1
aaa attribute
DECLARE
CURSOR attr_cursor IS
SELECT *
FROM attribute;
type_ref REF attr_type_type;
BEGIN
FOR attr_record IN attr_cursor LOOP
SELECT REF(p) INTO type_ref
33
FROM aaa_attribute_type p
WHERE p.AttrTypeNo = attr_record.type;
INSERT INTO aaa_attribute VALUES (
attr_record.objectno || attr_record.ObjectPartNo,
type_ref,
attr_record.value);
END LOOP;
END;
/
B.2
aaa REO
DECLARE
CURSOR reo_cursor IS
SELECT *
FROM object o,object_geometry g
WHERE o.objno = g.objectno;
layer_ref REF aa_layer;
geo_ref REF geom;
race_ref REF race;
BEGIN
FOR reo_record IN reo_cursor LOOP
--Referenz zur Layer-Tabelle-SELECT REF(p) INTO layer_ref
FROM aaa_layer p
WHERE p.layerno = reo_record.layerno;
--Referenz zur object_race Tabelle-SELECT REF(p) INTO race_ref
FROM aaa_object_race p
WHERE p.ObjectRaceNo = reo_record.ObjectRaceNo;
--Referenz zur Geometrietabelle-SELECT REF(p) INTO geo_ref
FROM aaa_geometry p
WHERE p.obj_ID = reo_record.objno || reo_record.objectpartno;
INSERT INTO aaa_reo VALUES(
reo_record.objno || reo_record.objectpartno,
aa_lebenszeitintervall(reo_record.builddate,NULL),
NULL,
NULL,
race_ref,
reo_record.coordinatex,
reo_record.coordinatey,
34
reo_record.modtype,
layer_ref,
name_ref_table_type(),
attr_ref_table_type(),
NULL,
geo_ref
);
END LOOP;
END;
/
B.3
aaa ZUSO
DECLARE
--Objekte die aus früheren Objektteilen bestehen
CURSOR zuso_cursor IS
SELECT o.*
FROM object o, object_geometry g
WHERE o.objno=g.objectno and g.objectpartno=’002’;
--Objekte die schon vorher zusammengesetzte Objekte waren
CURSOR zuso_complex_cursor IS
SELECT distinct o.*
FROM object o, complex_object c
WHERE o.objno=c.bigno;
layer_ref REF aa_layer;
race_ref REF race;
combined_zuso_ref REF aa_zuso;
combined_reo_ref REF aa_object;
BEGIN
FOR zuso_record IN zuso_cursor LOOP
--Referenz zur Layer-Tabelle-SELECT REF(p) INTO layer_ref
FROM aaa_layer p
WHERE p.layerno = zuso_record.layerno;
--Referenz zur object_race Tabelle-SELECT REF(p) INTO race_ref
FROM aaa_object_race p
WHERE p.ObjectRaceNo = zuso_record.ObjectRaceNo;
INSERT INTO aaa_zuso VALUES(
zuso_record.objno || ’000’,
aa_lebenszeitintervall(zuso_record.builddate,NULL),
NULL,
35
NULL,
race_ref,
zuso_record.coordinatex,
zuso_record.coordinatey,
zuso_record.modtype,
layer_ref,
name_ref_table_type(),
attr_ref_table_type(),
NULL,
combined_of_table_type()
);
END LOOP;
FOR zuso_complex_record IN zuso_complex_cursor LOOP
--Referenz zur Layer-Tabelle-SELECT REF(p) INTO layer_ref
FROM aaa_layer p
WHERE p.layerno = zuso_complex_record.layerno;
--Referenz zur object_race Tabelle-SELECT REF(p) INTO race_ref
FROM aaa_object_race p
WHERE p.ObjectRaceNo = zuso_complex_record.ObjectRaceNo;
INSERT INTO aaa_zuso VALUES(
zuso_complex_record.objno || ’000’,
aa_lebenszeitintervall(zuso_complex_record.builddate,NULL),
NULL,
NULL,
race_ref,
zuso_complex_record.coordinatex,
zuso_complex_record.coordinatey,
zuso_complex_record.modtype,
layer_ref,
name_ref_table_type(),
attr_ref_table_type(),
NULL,
combined_of_table_type()
);
END LOOP;
END;
/
36
B.4
aaa object name
DECLARE
--alle, die jetzt ein zuso sind
CURSOR name_zuso_cursor IS
SELECT n.objectno || ’000’ id,n.type,p.*
FROM object_name n, TABLE(n.geometries) p,aaa_zuso z
WHERE n.objectno || ’000’=z.Obj_ID;
--alle, die jetzt kein zuso, also nur einmal im reo vorkommen
CURSOR name_reo_cursor IS
SELECT n.objectno || ’001’ id,n.type,p.*
FROM object_name n, TABLE(n.geometries) p,
(SELECT distinct substr(obj_id,1,7) id
FROM aaa_reo
MINUS
SELECT substr(obj_id,1,7) from aaa_reo
WHERE substr(obj_id,8,10)=’002’) r
WHERE n.objectno=r.id ;
objno VARCHAR2(10);
objno_alt VARCHAR2(10) :=’’;
x NUMBER:=1;
ind NUMBER :=1;
i NUMBER :=1;
BEGIN
FOR name_zuso_record IN name_zuso_cursor LOOP
IF objno_alt = name_zuso_record.id
THEN ind:=ind+1;
ELSE objno_alt:=name_zuso_record.id;
ind:=1;
END IF;
INSERT INTO aaa_object_name VALUES (
name_zuso_record.id,
NULL,
NULL,
NULL,
name_zuso_record.Type,
name_zuso_record.name,
0,
1,
’linksbuendig’,
’basis’,
name_zuso_record.geo,
ind
37
);
END LOOP;
FOR name_reo_record IN name_reo_cursor LOOP
IF objno_alt = name_reo_record.id
THEN ind:=ind+1;
ELSE objno_alt:=name_reo_record.id;
ind:=1;
END IF;
INSERT INTO aaa_object_name VALUES (
name_reo_record.id,
NULL,
NULL,
NULL,
name_reo_record.Type,
name_reo_record.name,
0,
1,
’linksbuendig’,
’basis’,
name_reo_record.geo,
ind
);
END LOOP;
END;
/
B.5
Update aaa REO
DECLARE
CURSOR update_cursor IS
SELECT Obj_ID
FROM aaa_reo;
BEGIN
FOR update_rec IN update_cursor LOOP
INSERT INTO TABLE(SELECT attr_ref
FROM aaa_reo
WHERE Obj_ID=update_rec.Obj_ID)
(SELECT REF(p)
FROM aaa_attribute p
WHERE p.Obj_ID=update_rec.Obj_ID);
INSERT INTO TABLE(SELECT name_ref
FROM aaa_reo
38
WHERE Obj_ID=update_rec.Obj_ID)
(SELECT REF(p)
FROM aaa_object_name p
--sollte ein reo kein eigenes Präsentationsobjekt
--zugewiesen haben, so wird es dem des zugehörigen zuso
--zugeordnet, zu welchem es dann auch gehört.
WHERE substr(Obj_ID,1,7)=substr(update_rec.Obj_ID,1,7));
END LOOP;
END;
/
B.6
Update aaa ZUSO
DECLARE
CURSOR update_cursor IS
SELECT Obj_ID
FROM aaa_zuso;
BEGIN
FOR update_rec IN update_cursor LOOP
INSERT INTO TABLE(SELECT attr_ref
FROM aaa_zuso
WHERE Obj_ID=update_rec.Obj_ID)
(SELECT REF(p)
FROM aaa_attribute p
WHERE p.Obj_ID=update_rec.Obj_ID);
INSERT INTO TABLE(SELECT name_ref
FROM aaa_zuso
WHERE Obj_ID=update_rec.Obj_ID)
(SELECT REF(p)
FROM aaa_object_name p
WHERE p.Obj_ID=update_rec.Obj_ID);
INSERT INTO TABLE(select combined_of
from aaa_zuso
where Obj_ID=update_rec.Obj_ID)
(SELECT REF(p)
FROM aaa_reo p
WHERE substr(Obj_ID,1,7)=substr(update_rec.Obj_ID,1,7));
INSERT INTO TABLE(select combined_of
from aaa_zuso
where Obj_ID=update_rec.Obj_ID)
(SELECT REF(p)
FROM aaa_zuso p,complex_object c
39
WHERE substr(p.Obj_ID,1,7)=c.smallno
AND c.bigno=substr(update_rec.Obj_ID,1,7));
INSERT INTO TABLE(select combined_of
from aaa_zuso
where Obj_ID=update_rec.Obj_ID)
(SELECT REF(p)
FROM aaa_reo p, complex_object c
WHERE substr(p.Obj_ID,1,7)=c.smallno
AND c.bigno=substr(update_rec.Obj_ID,1,7));
END LOOP;
END;
/
40
Literaturverzeichnis
[dV02]
A. der Vermessungsverwaltungen. Dokumentation zur Modellierung der
Geoinformationen des amtlichen Vermessungswesens (GeoInfoDok) Version
1.0. 2002.
[Fal00]
S. Falke: Entwurf und Implementierung einer räumlichen Datenbank für
ATKIS-Daten mit Datenimport. Studienarbeit, Institut für Informatik, Universität Hannover, 2000.
[Gie01]
B. Gietz. Oracle9i Application Developer’s Guide - Object-Relational Features. Oracle Corporation, 2001.
[KFL00] C. Kleiner, S. Falke, U. W. Lipeck: Verwaltung geographischer Basisdaten
durch objekt-relationale Datenbanken am Beispiel von ATKIS und Oracle
8i. Informatik-Berichte DB-02/2000, Institut für Informatik, Universität
Hannover, 2000.
[PR01]
T. Portfolio, J. Russell. PL/SQL User’s Guide and Reference. Oracle Corporation, 2001.
[Rus01] J. Russell. Oracle9i Application Developer’s Guide - Fundamentals. Oracle
Corporation, 2001.
[Wat01] S. Watt. SQL*Plus User’s Guide and Reference. Oracle Corporation, 2001.
41