Masterarbeit Anfragebearbeitung in föderierten räumlichen

Fachgebiet Datenbanken und Informationssysteme
Institut für Praktische Informatik
Fakultät für Elektrotechnik und Informatik
Universität Hannover
Masterarbeit
im Studiengang Informatik
Anfragebearbeitung in föderierten
räumlichen Datenbanksystemen
Hendrik Warneke
Matr.Nr. 2067449
26. April 2006
Erstprüfer: Prof. Dr. Udo Lipeck
Zweitprüfer: Dr. Hans-Hermann Brüggemann
Zusammenfassung
Ein föderieres räumliches Datenbanksystem erlaubt es Anwendern, gleichzeitig mit Beständen von räumlichen Daten zu arbeiten, die in unterschiedlichen
Datenbanken gehalten werden, wobei diese Datenbanken zusätzlich autonom
betrieben und lokale Anwendungen nicht beeinträchtigt werden. Die in einem
föderierten System mögliche Heterogenität der Datenbestände erfordert es, dass
zur Bearbeitung von Anfragen, die auf Informationen aus mehreren Datenbanken gleichzeitig zugreifen, vielfältige Integrationskonflikte aufgelöst werden
müssen.
In dieser Arbeit wird eine Anfragesprache entworfen, die SQL um zusätzliche
Sprachkonstrukte zur Auflösung von Integrationskonflikten erweitert. Der Anwendungsschwerpunkt dieser Spracherweiterung liegt auf der Föderierung geographischer Datenbestände. Dem Benutzer der föderierten räumlichen Datenbank soll es erleichtert werden, Informationen aus heterogenen Datenbeständen
durch Anfragen zu verknüpfen und integrierte Sichten auf die enthaltenen Daten zu erstellen.
Zur Realisierung dieser Anfragesprache wird ein System entworfen, das Anfragen mit neuen Sprachkonstrukten in gewöhnliche SQL-Anfragen übersetzt.
Weiterhin wird eine prototypische Implementierung eines solchen Systems vorgestellt.
Inhaltsverzeichnis
1 Einleitung
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Grundlagen föderierter und räumlicher Datenbanksysteme
2.1 Multidatenbanksysteme . . . . . . . . . . . . . . . . . . . . .
2.2 Föderierte Datenbanksysteme . . . . . . . . . . . . . . . . . .
2.2.1 Schemaintegration . . . . . . . . . . . . . . . . . . . .
2.2.2 Anfragebearbeitung . . . . . . . . . . . . . . . . . . . .
2.2.3 Architektur . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Räumliche Datenbanksysteme . . . . . . . . . . . . . . . . . .
2.4 Föderation räumlicher Datenbanksysteme . . . . . . . . . . . .
2.4.1 Objektidentifikation . . . . . . . . . . . . . . . . . . .
2.4.2 Rubber Sheeting . . . . . . . . . . . . . . . . . . . . .
1
1
4
4
.
.
.
.
.
.
.
.
.
6
6
7
7
9
10
11
12
12
15
3 Integrationskonflikte und Multidatenbanksprachen
3.1 Klassifikation von Integrationskonflikten . . . . . . .
3.2 Multidatenbanksprachen . . . . . . . . . . . . . . . .
3.3 Mechanismen zur Konfliktauflösung . . . . . . . . . .
3.3.1 Beschreibungskonflikte . . . . . . . . . . . . .
3.3.2 Heterogenitätskonflikte . . . . . . . . . . . . .
3.3.3 Extensionale Konflikte . . . . . . . . . . . . .
3.3.4 Strukturelle Konflikte . . . . . . . . . . . . . .
3.4 Integrationskonflikte bei räumlichen Daten . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
18
20
21
22
23
23
24
30
4 Entwurf der SQL-Erweiterung
4.1 Grundbegriffe . . . . . . . . . . . . . . . . . . .
4.1.1 Das relationale Modell . . . . . . . . . .
4.1.2 NF2 -Relationen . . . . . . . . . . . . . .
4.1.3 Arrays . . . . . . . . . . . . . . . . . . .
4.1.4 Verlinken von Komponentendatenbanken
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
33
33
33
34
35
36
i
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
INHALTSVERZEICHNIS
4.2
4.3
4.4
4.5
Attributtransformation . . . . . . . . . . . . . . . . . .
4.2.1 Standardattribute . . . . . . . . . . . . . . . . .
4.2.2 Geometrische Attribute . . . . . . . . . . . . . .
4.2.3 Bemerkungen . . . . . . . . . . . . . . . . . . .
Mehrwertige Attribute . . . . . . . . . . . . . . . . . .
4.3.1 Aggregation . . . . . . . . . . . . . . . . . . . .
4.3.2 Aggregierungstabellen . . . . . . . . . . . . . .
4.3.3 Auflösen von Datenkonflikten . . . . . . . . . .
4.3.4 Bemerkungen . . . . . . . . . . . . . . . . . . .
Integrationsoperatoren . . . . . . . . . . . . . . . . . .
4.4.1 Der erweiterte Verbundoperator . . . . . . . . .
4.4.2 Der erweiterte Vereinigungsoperator . . . . . . .
4.4.3 Bemerkungen . . . . . . . . . . . . . . . . . . .
Substitution . . . . . . . . . . . . . . . . . . . . . . . .
4.5.1 Transformation von Relationennamen in Daten
4.5.2 Transformation von Attributnamen in Daten . .
4.5.3 Transformation von Daten in Relationennamen
4.5.4 Transformation von Daten in Attributnamen . .
4.5.5 Bemerkungen . . . . . . . . . . . . . . . . . . .
5 Entwurf des Anfragesystems
5.1 Architektur . . . . . . . . . . . . . .
5.2 Der Komponentendatenbankkatalog .
5.3 Übersetzen von SQLSF-Anweisungen
5.3.1 Attributtransformation . . . .
5.3.2 Aggregation . . . . . . . . . .
5.3.3 Integrationsoperatoren . . . .
5.3.4 Substitution . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
38
39
41
42
42
42
44
46
48
48
49
51
53
54
54
56
57
58
59
.
.
.
.
.
.
.
61
61
63
67
67
71
74
79
6 Methodik der Föderierung räumlicher Daten
86
6.1 Ablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.2 Anwendungsbeispiel . . . . . . . . . . . . . . . . . . . . . . . . . 89
7 Implementierung des Prototypen
7.1 SQLSF*Plus . . . . . . . . . . . .
7.2 Parser . . . . . . . . . . . . . . .
7.3 Komponentendatenbankkatalog .
7.4 Aggregation . . . . . . . . . . . .
7.5 Konfliktauflösung . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
94
94
96
98
98
99
8 Ausblick
101
A Die Grammatik von SQLSF
103
ii
Kapitel 1
Einleitung
1.1
Motivation
Wie in vielen anderen Bereichen werden auch geographische Informationen zunehmend elektronisch verarbeitet. Spezielle Software-System für diesen Zweck
heißen geographische Informationssysteme (GIS). Häufig sind diese in der Lage
mit geographischen Daten in vielen unterschiedlichen Formaten zu arbeiten.
Somit wird die Vervielfältigung und der Austausch dieser Daten, wie z.B. digitaler Landkarten, zwischen Behörden, Unternehmen oder anderen Organisationen durch den Einsatz moderner Kommunikationsnetze ernorm vereinfacht, so
dass einem Interessenten üblicherweise eine Vielzahl solcher Datensammlungen
zur Verfügung stehen.
Für die Verwaltung großer Mengen geographischer Daten verwendet man häufig
ein Datenbanksystem, das zusätzliche Funktionalität zum Umgang mit der
inhärenten räumlichen Ausprägung dieser Daten besitzt. Die Vorteile eines Datenbanksystems (z.B. Effizienz, Nebenläufigkeit usw.) lassen sich bei Einsatz
eines solchen räumlichen Datenbanksystems auch für die Arbeit mit geographischen Daten nutzen.
Je nachdem, wie die Bestände von geographischen Daten erhoben wurden, unterscheiden sich die enthaltenen Informationen über den durch die Daten beschriebenen geographischen Raum. In Abbildung 1.1 beispielsweise sind zwei
Datenbestände mit digitalem Kartenmaterial dargestellt, die eine unterschiedliche Thematik besitzen. Die geologische Karte unterteilt den Raum in Flächen,
für die jeweils die Beschaffenheit der Erdschichten beschrieben ist, während die
topographische Karte Objekte auf der Erdoberfläche, wie z.B. Straßen, Siedlungen oder Gewässer beschreibt.
1
Einleitung
(a) geologische Karte
(b) topographische Karte
Abbildung 1.1: Digitale Kartenblätter von Hannover mit unterschiedlicher Thematik
In Abbildung 1.2 sind Datenbestände dargestellt, die zwar die gleiche Thematik besitzen, allerdings für die Darstellung in unterschiedlichen Maßstäben
erhoben wurden. Die Datenbasis der Karte im feineren Maßstab enthält deutlich mehr Objekte und genauere Beschreibungen als die im gröberen Maßstab.
Weitere Ursachen für Unterschiede in den Datensammlungen sind beispielsweise verschiedene Datenanbieter oder eine unterschiedliche Aktualität der Daten.
Bestimmte Problemstellungen erfordern eine gemeinsame Nutzung mehrerer
Datenbestände. Dazu gehört die Gewinnung neuer Informationen durch Kombination geographischer Daten aus unterschiedlichen Quellen. Beispielsweise
könnte man die Beschreibung der Straßen in einer topographischen Karte mit
Informationen über die geologische Beschaffenheit des Untergrundes ergänzen,
indem man topographische und geologische Daten kombiniert. Ein weiteres
Anwendungsszenario ist die Übertragung von aktualisierenden Änderungen eines Datenbestandes auf einen anderen. Damit spart man sich für den zweiten
Datenbestand eine aufwendige Neuerfassung der geänderten geographischen
Daten.
Ein interessanter Ansatz zur gemeinsamen Nutzung ist die Föderierung der
Datenbestände. Dieser hat gegenüber einem zentralisierten Ansatz, bei dem
alle Daten in einem Datenbanksystem integriert werden, den Vorteil, dass die
einzelnen Datenbestände weiterhin autonom und unabhängig voneinander verwaltet werden können und somit Anwendungen, die mit diesen Daten arbeiten
nicht beeinträchtigt werden. Gleichzeitig erlaubt es eine zusätzlich eingeführte
2
1.1 Motivation
(a) Maßstab 1:250000
(b) Maßstab 1:1000000
Abbildung 1.2: Kartenblätter von Buchholz für die Darstellung in unterschiedlichen
Maßstäben
Ebene, auf der eine integrierte Sichtweise auf die Daten zur Verfügung gestellt
wird, Informationen aus verschiedenen Quellen zu verknüpfen.
Wie eine solche Föderierungsebene insbesondere für geographische Datenbanken zu realisieren ist, ist Gegenstand aktueller Forschung. Zu lösende Probleme
sind dabei z.B.
• Die Entwicklung eines Schemas des Gesamtdatenbestandes aus den Schemata der einzelnen Datenbanken.
• Die Identifikation von Datenobjekten aus verschiedenen Datenbeständen,
die dasselbe geographische Objekt (z.B. dieselbe Straße) modellieren, das
sogenannte Matching.
• Die Auflösung von Konflikten, die dadurch entstehen, dass sich die Eigenschaften modellierter geographischer Objekte in verschiedenen Datenbeständen unterscheiden.
Während bereits Verfahren zur Behandlung dieser Probleme vorgeschlagen
wurden, existiert noch kein Vorschlag für eine Anfragesprache, mit der über die
Föderierungsebene Informationen aus den Datenbeständen verknüpft werden
können, indem diese Verfahren ausgenutzt werden.
3
Einleitung
1.2
Zielsetzung
In dieser Arbeit soll untersucht werden, wie sich der Aufbau und die Benutzung
eines föderierten räumlichen Datenbanksystems durch passende Erweiterungen der als Standard etablierten Anfragesprache SQL unterstützen lassen. Den
Ausgangspunkt bildet zunächst eine Betrachtung SQL-basierter Multidatenbanksprachen, die für den Einsatz innerhalb eines Verbundes von Datenbanken
mit Standarddaten konzipiert wurden und die spezielle Spracherweiterungen
zur Unterstützung von Integrationsoperationen enthalten. Da auch in räumlichen Datenbanksystemen zum Teil mit Standarddaten operiert wird, sind diese
Erweiterungen auch bei der Föderierung geographischer Daten einsetztbar. Es
ist zu klären, inwieweit weitere Sprachkonstrukte benötigt werden, um Techniken zur Integration von räumlichen Daten zu unterstützen.
Aufbauend auf dieser Untersuchung soll prototypisch eine eigene Anfragesprache für föderierte räumliche Datenbanksysteme entwickelt und realisiert werden. Es sind gegebenenfalls neue Spracherweiterungen, schwerpunktmäßig für
die Anwendung von bereits erprobten Verfahren zur Integration von geographischen Daten, zu entwerfen. Insbesondere sollen für die Integration nützliche
Zusatzinformationen über die zu föderierenden Daten auf der Föderierungsebene abgespeichert und implizit zur Beantwortung von Anfragen genutzt werden
können. Beim Entwurf der Spracherweiterungen ist ein geeigneter Kompromiss aus einfacher Anwendbarkeit und der Ermöglichung vielfältiger Integrationsstrategien zu finden. Der Anwendungsbereich der Anfragesprache wird auf
geographische Daten in einem festen Format eingeschränkt.
Zur Realisierung der Anfragesprache ist ein System zu entwerfen, das eine
Bearbeitung entsprechender Anfragen vornimmt. Dabei soll es möglich sein,
sowohl direkt Anfragen an die föderierten Datenbestände zu stellen als auch
integrierte Sichten auf der Föderierungsebene zu definieren. Weiterhin ist zu
beschreiben, wie die Föderierung geographischer Datenbestände unter Einsatz
der neu entworfenen Anfragesprache durchgeführt werden kann und wie man
diese zur Verknüpfung von Informationen aus den Datenbeständen einsetzt.
1.3
Gliederung
In Kapitel 2 werden zunächst für diese Arbeit wichtige Begriffe und Techniken
erläutert. Insbesondere werden auch Verfahren vorgestellt, die bei der Integration geographischer Daten eingesetzt werden und an denen sich der Entwurf
4
1.3 Gliederung
der Anfragesprache orientiert. Kapitel 3 befasst sich mit den unterschiedlichen Arten von Konflikten bei der Integration von Standarddaten. Es werden
bereits existierende Vorschläge für SQL-Spracherweiterungen vorgestellt, mit
denen solche Konflikte bei der Bearbeitung der Anfrage automatisch aufgelöst
werden. Weiterhin wird die Anwendung dieser Erweiterungen auf Konflikte bei
der Integration geographischer Daten diskutiert.
Die in dieser Arbeit entworfene Anfragesprache wird in Kapitel 4 vorgestellt,
wobei jeweils Syntax, Semantik und Anwendungsbeispiele für jedes SQL erweiternde Sprachkonstrukt angegeben werden. Es folgt der Entwurf eines Systems,
durch das die neue Anfragesprache realisiert wird, in Kapitel 5. Dazu werden
unter anderem Algorithmen angegeben, die die Erweiterungen in standardkonforme SQL-Anweisungen übersetzen. Kapitel 6 stellt dar, wie Anfragen zur Verknüpfung von Informationen aus föderierten Datenbeständen formuliert werden
können. Weiterhin ist hier aufgeführt, welche Vorarbeiten zur Föderierung der
Datenbestände durchgeführt werden müssen. Schließlich wird in Kapitel 7 die
prototypische Implementierung des Anfragesystems beschrieben.
5
Kapitel 2
Grundlagen föderierter und
räumlicher Datenbanksysteme
In diesem Kapitel sollen grundsätzliche Konzepte erläutert werden, die für das
Verständnis dieser Arbeit notwendig sind. In Abschnitt 2.1 wird zunächst der
Begriff Multidatenbanksystem erläutert und charakteriesierende Eigenschaften
vorgestellt. Anschließend wird in Abschnitt 2.2 genauer auf eine Klasse von
Multidatenbanksystemen, die föderierten Datenbanksysteme eingegangen. Für
räumliche Datenbanksysteme wird in den folgenden Kapiteln eine bestimmte
Art der Realisierung vorausgesetzt, die in Abschnitt 2.3 beschrieben ist. Abschließend erläutert Abschnitt 2.4 Techniken, die zur Lösung einiger spezieller
Probleme bei der Integration räumlicher Datenbanksysteme eingesetzt werden
können, und die eine Grundlage der in Kapitel 4 entworfenen SQL-Erweiterung
bilden.
2.1
Multidatenbanksysteme
Im Gegensatz zu einem zentralen oder verteilten Datenbanksystem, bei dem alle Daten von einem einzigen Datenbankmanagementsystem verwaltet werden,
handelt es sich bei einem Multidatenbanksystem um einen Verbund mehrerer
Datenbanksysteme, die als die Komponentendatenbanksysteme oder Komponentendatenbanken 1 des Verbundes bezeichnet werden. Ein solcher Verbund
läßt sich anhand dreier Merkmale charakterisieren:
1
Die Begriffe Datenbanksystem und Datenbank werden hier synonym benutzt und bezeichnen immer die Gesamtheit aus Datenbankmanagementsystem und verwalteten Daten.
6
2.2 Föderierte Datenbanksysteme
Verteilung bezieht sich auf die Speicherung der Daten innerhalb des Multidatenbanksstems. In verteilten Systemen sind diese auf verschiedene
Rechner oder verschiedene Datenbanken verteilt.
Heterogenität tritt in Multidatenbanksystemen in vielfältiger Form auf. Beispiele sind die Verwendung unterschiedlicher Datenbankmanagementsysteme, unterschiedliche Modellierungen desselben Weltausschnittes oder
eine sich in verschiedenen Komponentendatenbanken unterscheidende Interpretation der Daten.
Autonomie beschreibt die Freiheitsgrade, die der Administrator einer Komponentendatenbank bei dessen Kontrolle hat. Kann eine Komponentendatenbank unabhängig von den anderen Datenbanken des Verbundes
entworfen und ihr Schema beim Eintritt in den Verbund unverändert
bleiben, spricht man von Entwurfsautonomie. Kommunikationsautonomie erlaubt es dem Administrator, über die Zugehörigkeit zum Verbund
und darüber, welche Daten und Dienste anderen Teilnehmern angeboten
werden, zu entscheiden. Die Möglichkeit, eigenständig zu bestimmen, ob
und zu welchem Zeitpunkt Anwendungen, Anfragen oder Änderungsoperationen ausgeführt werden, bezeichnet man als Ausführungsautonomie.
2.2
Föderierte Datenbanksysteme
Multidatenbanksysteme, in denen die Komponentendatenbanken einen hohen
Grad an Autonomie besitzen, bezeichnet man als föderierte Datenbanksysteme
[SL90]. Der allgemeine Aufbau eines föderierten Datenbanksystems ist in Abbildung 2.1 dargestellt. Der Föderierungsdienst integriert die Daten der Komponentendatenbanken und stellt sie für globale Anwendungen zur Verfügung.
Dazu verwendet er typischerweise eine eigene Datenbank, die als Arbeitsdatenbank bezeichnet wird. Die Komponentendatenbanken werden nicht verändert
und lokale Anwendungen, die auf die einzelnen Komponentendatenbanken zugreifen, dadurch nicht beeinträchtigt.
2.2.1
Schemaintegration
Eine Aufgabe des Föderierungsdienstes ist die Bereitstellung eines sogenannten globalen Schemas, das die im föderierten Datenbanksystem verwalteten
Daten in einheitlicher Form beschreibt. Dazu müssen die unabhängig voneinander entworfenen, heterogenen Schemata der Komponentendatenbanken zu
7
Grundlagen föderierter und räumlicher Datenbanksysteme
Globale
Anwendungen
Globale
Anwendungen
Föderierungsdienst
Arbeitsdatenbank
Lokale
Anwendungen
Lokale
Anwendungen
...
KDB 1
KDB n
Föderiertes Datenbanksystem
Abbildung 2.1: Allgemeiner Aufbau eines föderierten Datenbanksystems (nach [LMT04])
einem neuen Schema kombiniert werden. Diesen Prozess bezeichnet man als
Schemaintegration und das Ergebnis auch als integriertes Schema.
Die Schemaintegration wird in der Regel vollständig manuell oder halbautomatisch durchgeführt (siehe [Con97] für einen Vergleich mehrerer vorgeschlagener Ansätze). Um die Schemata der Komponentendatenbanken in Einklang
zu bringen, müssen vielfältige Probleme gelöst werden, die als Integrationskonflikte bezeichnet werden und auf die in Abschnitt 3.1 genauer eingegangen wird.
In der Literatur werden die folgenden Anforderungen an ein globales Schema
angegeben:
Vollständigkeit: Das integrierte Schema muss alle Informationen enthalten,
die in mindestens einem lokalen Schema vorhanden sind.
Korrektheit: Die im globalen Schema vorhandenen Informationen müssen äquivalent in mindestens einem lokalen Schema enthalten sein.
Minimalität: Informationen, die in mehreren lokalen Schemata vorhanden sind,
dürfen nur einmal im globalen Schema repräsentiert sein.
Verständlichkeit: Das globale Schema soll leicht verständlich sein.
8
2.2 Föderierte Datenbanksysteme
2.2.2
Anfragebearbeitung
Zur Beantwortung von Anfragen an ein föderiertes Datenbanksystem, im folgenden als globale Anfragen bezeichnet, kann es notwendig sein, Informationen
aus mehr als einer Komponentendatenbank zu kombinieren. Die Beantwortung
einer solchen Anfrage erfordert im Vergleich zum zentralen Datenbanksystem
zusätzliche Arbeit, die vom Föderierungsdienst geleistet werden muss. Der prinzipielle Ablauf ist in Abbildung 2.2 skizziert.
Globales Ergebnis
Globale Anfrage
Anfragezerlegung und
globale Optimierung
Postprocessing
Anfrage 1
...
Postprocessing
Anfrage k
Lokale
Anfrage 1
Konvertiertes
lokales Ergebnis 1
Anfrageübersetzer 1
Datenkonverter 1
Übersetzte
lokale Anfrage 1
Lokales
Ergebnis 1
...
DB 1
Zusammensetzen
und Nachbearbeitung
Lokale
Anfrage n
Konvertiertes
lokales Ergebnis n
Anfrageübersetzer n
Datenkonverter n
Übersetzte
lokale Anfrage n
Lokales
Ergebnis n
DB n
Abbildung 2.2: Allgemeiner Ablauf der Anfragebearbeitung in föderierten Datenbanksystemen
Zunächst werden aus der globalen Anfrage sogenannte lokale Anfragen erzeugt, die von den einzelnen Komponentendatenbanksystemen bearbeitet werden können. Eine lokale Anfrage muss dann in die von der jeweiligen Komponentendatenbank unterstützte Anfragesprache transformiert werden. Durch
Ausführung einer übersetzten lokalen Anfrage auf einem Komponentendatenbanksystem erhält man ein lokales Ergebnis, das zunächst in das vom Föderierungsdienst verwendete Datenmodell konvertiert werden muss. Die konvertierten lokalen Ergebnisse müssen dann zum globalen Ergebnis zusammengesetzt
9
Grundlagen föderierter und räumlicher Datenbanksysteme
werden. Das geschiet durch sogenannte Postprocessing-Anfragen, die bei der
Anfragezerlegung erzeugt werden müssen.
2.2.3
Architektur
Zur Realisierung eines föderierten Dantenbanksystems werden in der Literatur verschiedene Architekturen vorgeschlagen (siehe [Con97]). Im Rahmen dieser Arbeit wird die sogenannte 5-Ebenen-Schema-Architektur verwendet (siehe
Abbildung 2.3).
Externes Schema 1
...
Externes Schema m
Föderiertes Schema
Exportschema 1
...
Exportschema n
Komponentenschema 1
...
Komponentenschema n
Lokales Schema 1
...
Lokales Schema n
...
DB 1
DB n
Abbildung 2.3: 5-Ebenen-Schema-Architektur
Lokale Schemata bezeichnen die konzeptionellen Schemata der Komponentendatenbanken. Da diese von lokalen Anwendungen zum Zugriff auf die
Datenbank verwendet werden, dürfen sie aufgrund der geforderten Autonomie der Komponentendatenbanken durch den Integrationsprozess beim
Aufbau der Föderation nicht verändert werden. In heterogenen Verbunden können die lokalen Schemata unterschiedlicher Komponentendatenbanken in unterschiedlichen Datenmodellen vorliegen.
10
2.3 Räumliche Datenbanksysteme
Komponentenschemata gehen aus den lokalen Schemata durch Transformation in ein anderes Datenmodell, das gemeinsame Datenmodell der Föderation, hervor. Durch diesen Schritt kann in darüberliegenden Ebenen von
der Heterogenität der Komponentendatenbanken abstrahiert werden.
Exportschemata begrenzen den Zugriff des föderierten Datenbanksystems auf
die Daten der Komponentendatenbanken, indem sie diejenigen Ausschnitte der Komponentenschemata definieren, die der Föderation zur Verfügung
gestellt werden. Dadurch lässt sich ein gewisser Grad an Kommunikationsautonomie erreichen.
Föderiertes Schema enthält das aus der Integration der Exportschemata enstandene globale Schema, eine integrierte Beschreibung aller durch die
Komponentendatenbanken zur Verfügung gestellten Daten. Weiterhin sind
alle Daten enthalten, die der Föderierungsdienst zur Bearbeitung von
mittels des globalen Schemas formulierten Anfragen oder Änderungen
sowie zum Verwalten der Föderation benötigt.
Externe Schemata verbergen die Komplexität des föderierten Schemas vor
globalen Anwendungen oder Nutzern, indem nur der für diese relevante Teil des föderierten Schemas beschrieben wird.
2.3
Räumliche Datenbanksysteme
Werden in einem Datenverarbeitungssystem Objekte der realen Welt mitsamt
räumlicher Eigenschaften modelliert, so spricht man allgemein von räumlichen
Daten. Datenbanksysteme, die in der Lage sind, solche Daten zu speichern,
zu manipulieren und auf Anfrage auszuliefern, bezeichnet man als räumliche
Datenbanksysteme. Eines der wichtigsten Anwendungsgebiete für diese Datenbanksysteme ist die Speicherung digitaler Landkarten in Geo-Informationssystemen. Modellierte Objekte in der Datenbank entsprechen in diesem Kontext
z.B. Abschnitten von Verkehrswegen und Gewässern oder Teilen von Landschaftsflächen.
Ein naheliegender Ansatz für die Realisierung eines räumlichen Datenbanksystems ist die Erweiterung eines (objekt-)relationalen Datenbanksystems um
geometrische Datentypen (z.B. Punkt, Linie oder Fläche) und Operationen.
Relationen in einem solchen System können sowohl Standardattribute, die alphanumerische Werte (z.B. der Name einer Straße) enthalten, als auch geometrische Attribute, zur Repräsentation der geometrischen Ausprägung der
11
Grundlagen föderierter und räumlicher Datenbanksysteme
modellierten räumlichen Objekte. Eine beispielhafte Relation ist in Abbildung
2.4 dargestellt.
objektID
36576
36577
36578
Geo Objekt
objektart
bezeichnung
Straße
Schneiderberg
Platz
Welfengarten
Straße
Callinstr.
geometrie
Abbildung 2.4: Relation mit drei Standard- und einem geometrischen Attribut
Zur Repräsentation von geometrischen Attributen können unterschiedliche Ansätze verwendet werden (siehe [RSV02]). In dieser Arbeit wird von einer vektoriellen Darstellung ausgegangen. Das bedeutet, dass Geometrien durch eine
Menge repräsentativer Punkte, z.B. die Endpunkte einer Linie oder die Stützpunkte eines Polygons, beschrieben sind. Eine Geometrie und damit die räumliche Ausprägung eines geographischen Datenobjektes kann auch aus mehreren
Linien oder Polygonen bestehen.
2.4
Föderation räumlicher Datenbanksysteme
Aufgrund des besonderen Charakters räumlicher Daten treten bei deren Integration aus verschiedenen Quellen Probleme auf, die durch spezialisierte Techniken gelöst werden müssen. Daraus entstehen zum Teil weitere Anforderungen
für die Bearbeitung von Anfragen in einem föderierten räumlichen Datenbanksystem.
2.4.1
Objektidentifikation
Während bei nicht-räumlichen Daten häufig über die Grenzen eines Datenbanksystems hinaus einheitliche Identifikatoren existieren (man denke an ISBN,
Immatrikulations- oder Personalausweisnummer), gibt es diese bei räumlichen
Datenbanken häufig nicht. In diesem Fall ist es daher schwieriger, Datenobjekte aus zwei unterschiedlichen Komponentendatenbanken zu bestimmen, die
dasselbe Objekt in der realen Welt beschreiben.
Solche Korrespondenzbeziehungen weden allerdings für die Integration der Daten in einer Föderation von räumlichen Datenbanksystemen benötigt, um beispielsweise beschreibende Eigenschaften eines Objektes aus unterschiedlichen
12
2.4 Föderation räumlicher Datenbanksysteme
Komponentendatenbanken zu einer umfassenderen Beschreibung zu kombinieren. Daher erschließt man diese Beziehungen aus übereinstimmenden oder ähnlichen geometrischen und thematischen Merkmalen der Datenobjekte.
(a) 1:1 Zuordnung
(b) 1:n Zuordnung
(c) m:n Zuordnung
Abbildung 2.5: Unterschiedliche Klassen von Zuordnungen
Diese erschlossenen Korrespondenzbeziehungen bezeichnet man als Zuordnungen oder Links. Da bei der Erfassung geographischer Daten ein kontinuierliches
Abbild der Erdoberfläche in diskrete Objekte eingeteilt werden muss und diese
Einteilung auf viele unterschiedliche Arten erfolgen kann, sind diese Zuordnung oftmals nicht eindeutig. Man unterscheidet anhand der Kardinalität drei
Klassen von Zuordnungen zwischen Objekten aus zwei unterschiedlichen Komponentendatenbanken (siehe Abbildung 2.5):
1:1 Zuordnung: Ein Objekt in der Komponentendatenbank A ist genau einem
Objekt aus der Komponentendatenbank B zugeordnet. Diesem sind keine
anderen Objekte aus A zugeordnet.
1:m Zuordnung: Ein Objekt in der Komponentendatenbank A ist mehreren
Objekten in der Komponentendatenbank B zugeordnet. Diese stehen allerdings nicht mit anderen Objekten aus A in einer Zuordnungsbeziehung.
n:m Zuordnung: Ein Objekt in der Komponentendatenbank A ist mehreren
Objekten in der Komponentendatenbank B zugeordnet. Diese können
wiederum mehreren Objekten aus A zugeordnet sein.
Der für die Integration einfachste Fall sind die 1:1 Zuordnungen, da man es hier
offensichtlich mit zwei einzelnen Datenobjekten zu tun hat, die dasselbe Objekt
in der realen Welt beschreiben. In den anderen Fällen behilft man sich oftmals
dadurch, dass man in jeder Komponentendatenbank Datenobjekte, die über
13
Grundlagen föderierter und räumlicher Datenbanksysteme
eine Kette von Zuordnungen zusammenhängen, zu zusammengesetzten Objekten aggregiert (in Abbildung 2.5 rot dargestellt). Zwischen diesen aggregierten
Objekten bestehen dann 1:1 Zuordnungen.
Den Prozess der Erschließung von Korrespondenzbeziehungen bezeichnet man
als Matching. Um qualitativ möglichst hochwertige Ergebnisse - also eine möglichst vollständige und fehlerfreie Menge von Zuordnungen - zu erzielen, werden aufwendige Verfahren in einem mehrstufigen Matchingprozess eingesetzt
(siehe ausführliche Beschreibung in [ML04]). Dabei wird vorausgesetzt, dass
in jeder Komponentendatenbank eine Relation existiert, die alle modellierten
räumlichen Objekte enthält. Diese kann gegebenefalls über eine Sicht realisiert
sein. Da der Matchingprozess viel Rechenzeit erfordert, werden die berechneten
Zuordnungen üblicherweise in der Arbeitsdatenbank der Föderation abgespeichert. Dabei werden diese Daten entsprechend dem in Abbildung 2.6 gezeigten
Schema strukturiert.
0..*
0..*
Object_Link
+topo_Relation
1
1
Object_A
Object_B
1..*
1..*
1
1
Aggregated_Object_B
Aggregated_Object_A
0..1
0..1
1..*
Link
1..*
+Status
1
0..*
Link_Quality
+Criterion
+Value
Abbildung 2.6: Schema zur Abspeicherung von Zuordnungen aus [LMT04]
Die Klassen Object A und Object B enthalten Repräsentationen der gematchten Originalobjekte aus zwei Komponentendatenbanken. Die aus diesen Objekten zusammengesetzten aggregierten Objekte sind durch Instanzen der Klassen
Aggregated Object A und Aggregated Object B repräsentiert. Zuordnungen
zwischen diesen aggregierten Objekten werden in einer Klasse Link gespeichert. Zu jeder Zuordnung können Qualitätskriterien und -werte in der Klasse Link Quality verzeichnet werden. In der Klasse Object Link werden die
14
2.4 Föderation räumlicher Datenbanksysteme
beim Matching ermittelten räumliche Beziehungen (z.B. benachbarte oder sich
schneidende Objekte) zwischen den Originalobjekten gespeichert.
2.4.2
Rubber Sheeting
Im Allgemeinen kann man nicht davon ausgehen, dass Objekte der realen Welt
in unterschiedlichen Komponentendatenbanken durch die selbe Geometrie beschrieben werden. Aufgrund von unterschiedlicher Erfassung der räumlichen
Daten entprechen Punkte mit den gleichen Koordinaten in unterschiedlichen
Komponentendatenbanken nicht unbedingt demselben Punkt der realen Welt.
Rubber Sheeting ist ein Verfahren zur Transformation von Geometrien, dass diese Probleme berücksichtigt. Man kann sich diese Transformation anschaulich
wie die Verzerrung einer Gummihaut vorstellen auf der die zu transformierenden Geometrien aufgemalt sind. Es wird eine Menge sogenannter Passpunkte
benötigt, die aus n Paaren (qk , zk ) von übereinstimmenden Punkten aus unterschiedlichen Komponentendatenbanken besteht. Diese Passpunkte müssen vor
der Anwendung der Transformation entweder manuell (z.B. über eine graphische Schnittstelle) identifiziert oder automatisch bestimmt werden. Hat man
bereits Objektzuordnungen berechnet, so kann man beispielsweise die Endpunkte einander zugeordneter Liniensegmente verwenden.
Abbildung 2.7: Linienhafte Objekte aus unterschiedlichen Komponentendatenbanken vor
und nach der Transformation der roten Objekte mittels Rubber Sheeting
Man transformiert eine Geometrie aus einer Komponentendatenbank, indem
man deren repräsentative Punkte mit Hilfe der Passpunkte in eine Darstellung
15
Grundlagen föderierter und räumlicher Datenbanksysteme
entsprechend der anderen Komponentendatenbank umrechnet. Die folgende
Beschreibung des Verfahrens orientiert sich an [Lau98].
Punkte im zweidimensionalen Raum werden als Vektoren aufgefasst. Der Ansatz für eine Funktion zur Transformation eines Punktes p = (x, y) mit den
Koordinaten x und y ist die Vektorsumme aller bekannten Passpunkte zk in der
Zieldatenbank gewichtet mit einem vom zu transformierenden Punkt abhängigen Gewichtsfaktor wk (p):
f (p) =
n
X
zk · wk (p)
k=1
Die zugrundeliegende Idee ist, dass der Passpunkt zk aus der Zieldatenbank
ein umso stärkeres Gewicht erhält, je näher der zu transformierende Punkt
p dem zugehörigen Passpunkt qk in der Quelldatenbank ist. Im Extremfall,
d.h. der zu transformierende Punkt entspricht einem der Passpunkte in der
Quelldatenbank, also p = qk , soll gelten:
(
1 für i = k,
wi (p) =
0 sonst.
Dadurch wird erreicht, dass die Passpunkte tatsächlich aufeinander abgebildet
werden, also f (qk ) = zk für alle k mit 1 ≤ k ≤ n gilt. Da es sich um eine stetige
Abbildung handelt, werden auch alle Punkte aus einer Umgebung von qk in
eine Umgebung von zk abgebildet.
In [Lau98] wird die folgende Gewichtsfunktion vorgeschlagen:
wk (p) =
1 + dk (p)m ·
1
P
j6=k
dj (p)−m
Dabei bezeichnet dk (p) den euklidischen Abstand des Punktes p von dem k-ten
Passpunkt qk = (xk , yk ) in der Quelldatenbank, also
p
dk (p) = (x − xk )2 + (y − yk )2
Es ist leicht einzusehen, dass diese Gewichtsfunktionen die gewünschten Eigenschaften haben. Mit dem Parameter m kann gesteuert werden, wie stark
die Verzerrung in der Nähe der Passpunkte ausfällt. Genauere Untersuchungen
über sinnvolle Werte von m finden sich in [Kre04].
16
Kapitel 3
Integrationskonflikte und
Multidatenbanksprachen
Das Schema einer Komponentendatenbank enthält eine semantische Beschreibung der in der Datenbank vorhandenen Informationen. Es existieren viele
verschiedene Datenmodelle um diese Beschreibungen auszudrücken und somit Schemata zu definieren (Relationales Modell, Objektorientiertes Modell,
Entity-Relationship-Modell u.a.). Weiterhin gibt es sogar innerhalb eines Datenmodells normalerweise viele verschiedene Möglichkeiten ein Konzept aus
der realen Welt zu repräsentieren. Wenn gleiche Konzepte in den Schemata verschiedener Komponentendatenbanken auf unterschiedliche Art modelliert sind,
entstehen bei der Integration zu einem föderierten Schema vielfältige Probleme.
Diese werden in der Literatur als Integrationskonflikte bezeichnet.
Um Anfragen in Multidatenbanksystemen zu stellen oder Daten zu manipulieren wurden sogenannte Multidatenbanksprachen entwickelt. Diese erlauben
einen globalen, simultanen Zugriff auf mehrere Komponentendatenbanken und
können zur Definition von integrierten Sichten oder eines globalen Schemas
verwendet werden.
In Abschnitt 3.1 wird eine Klassifizierung von Integrationskonflikten vorgestellt. Diese erweist sich als hilfreich um anschließend in Abschnitt 3.3 Lösungsansätze, die von verschiedenen, in Abschnitt 3.2 vorgestellten Multidatenbanksprachen für unterschiedliche Arten von Konflikten angeboten werden, diskutieren zu können. Zum besseren Verständnis soll die Diskussion beispielhaft
für die in Abbildung 3.1 dargestellten Datenbanken erfolgen. Abschnitt 3.4 beschreibt Konflikte, auf die man bei der Integration von räumlichen Daten stösst
und die nicht mit den in Abschnitt 3.2 vorgestellten Multidatenbanksprachen
behandelt werden können.
17
Integrationskonflikte und Multidatenbanksprachen
Datenbank A:
id
1
2
3
Datenbank B:
Straße
objektart
länge m
Kreisstraße
500
Landstraße
2500
Landstraße
3200
breite
7
10
11,5
Datenbank C:
id
11
12
Straße
kennung obj art
B 83
1103
L 342
1105
länge km
25,0
5,7
Datenbank D:
id
2
3
Straße
objektart
länge
Bundesstraße 24000
Autobahn
75000
sid
2
3
3
Kennung
art wert
D
B83
D
A2
EU
E30
breite
9
18
id
3
Autobahn
länge breite
75000
18
id
2
Bundesstraße
länge breite
24000
9
sid
2
3
Kennung
D
EU
B83
A2 E30
Abbildung 3.1: Beispieldatenbanken
3.1
Klassifikation von Integrationskonflikten
Grundsätzlich unterscheidet man in der Literatur zwischen Schemakonflikten
und Datenkonflikten. Schemakonflikte können allein durch Betrachtung der
zu integrierenden Schemata identifiziert werden, während Datenkonflikte erst
nach der Schemaintegration aufgrund von Inkonsistenzen zwischen den Ausprägungen auftreten. Für die Klassifikation von Schemakonflikten wird in aktueller Literatur häufig die Einordnung aus [SPD92] übernommen. Diese unterscheidet vier Konfliktarten auf Schemaebene:
Beschreibungskonflikte entstehen, wenn einander entsprechende Konzepte mit
unterschiedlichen Eigenschaften modelliert werden. Unter diesen Begriff
fallen z.B. Homonyme, Synonyme, unterschiedliche Attribute, unterschiedliche Einheiten, unterschiedliche Wertebereiche und unterschiedliche Integritätsbedingungen. Man betrachte die Straße-Relationen aus den Datenbanken A und B in Abbildung 3.1. Die Attribute objektart und obj art
bezeichnen die selbe Eigenschaft, die Länge ist in unterschiedlichen Maßeinheiten angegeben und in Datenbank A ist keine Kennung, in B hingegen
keine Breite gespeichert.
Heterogenitätskonflikte liegen vor, wenn die zu integrierenden Schemata in
unterschiedlichen Datenmodellen vorliegen, z.B. relational versus objektorientiert.
18
3.1 Klassifikation von Integrationskonflikten
Semantische Konflikte treten auf, wenn sich Relationen überlappen, also sich
überschneidende Mengen von Real-Welt Objekten repräsentieren. Dabei
entsteht das Problem, welche Datensätze in verschiedenen Relationen einander entsprechen. Man betrachte beispielsweise die Datenbanken B und
C, in denen jeweils die Straße mit der Kennung B 83 modelliert ist. Diese
Konfliktart ist Voraussetzung für das Auftreten der sogenannten Datenkonflikte, bei denen sich die Attributwerte korrespondierender Objekte
unterscheiden.
Strukturelle Konflikte sind dadurch charakterisiert, dass innerhalb desselben
Datenmodells unterschiedliche Modellierungskonzepte verwendet wurden,
um gleiche Ausschnitte der realen Wert zu modellieren. Im relationalen
Modell liegen Daten oft unterschiedlich fragmentiert vor, wobei man zwischen horizontaler und vertikaler Fragmentierung unterscheidet. Während beispielsweise alle Straßen in der Datenbank C in einer Relation
gespeichert sind, liegen diese in Datenbank D horinzontal entsprechend
ihrer Objektart fragmentiert vor. Ein Beispiel für unterschiedliche vertikale Fragmentierung ist die Modellierung der Straßenkennung in einer
separaten Relation in der Datenbank C, während in Datenbank B die Kennung mit den anderen Attributen gemeinsam in einer Relation vorliegt.
Eine weitere Art von strukturellen Konflikten, die sogenannten DatenMetadaten-Konflikte, tritt auf, wenn in einer Komponentendatenbank
explizit vorhandene Informationen in einer anderen Komponentendatenbank nur implizit aus deren Schema bestimmt werden können. Zum Beispiel entfällt in der Datenbank D eine explizite Speicherung der Objektart
einer Straße, da sich diese aufgrund der horizontalen Fragmentierung aus
dem Namen der Relation also aus dem Schema ergibt. Bei den Straßenkennungen in der Datenbank C enthält das Attribut art die Information,
ob es sich um eine nationale oder europäische Kennung handelt. Diese Information existiert in der Datenbank D nur implizit als Name des
Attributs, das die Kennung als Wert enthält.
Als Datenkonflikte werden Situationen bezeichnet, in denen Datenbankobjekte, die das selbe Objekt in der realen Welt modellieren, in unterschiedlichen
Datenbanken verschiedene Werte für eine Eigenschaft besitzen, wie z.B. die
Länge der Straße mit der Kennung B 83 in den Datenbanken B und C. Damit
überhaupt Datenkonflikte auftreten können, müssen sich die Extensionen der
zu integrierenden Datenbanken überlappen, also ein semantischer Konflikt vorliegen. Daher erscheint es für die folgenden Betrachtungen sinnvoll, Daten- und
semantische Konflikte zu sogenannten extensionalen Konflikten zusammenzufassen und Lösungsansätze vorzustellen, die beide Konflikttypen behandeln.
19
Integrationskonflikte und Multidatenbanksprachen
3.2
Multidatenbanksprachen
Aufgrund umfangreicher Forschung auf dem Gebiet der Interoperabilität von
Datenbanken existieren zahlreiche Vorschläge für Multidatenbanksprachen, die
ein simultanes Arbeiten mit mehreren heterogenen Datenbanken ermöglichen
sollen. Die Komplexität dieser Sprachen ist im Vergleich zu den etablierten
Lösungen für zentrale Datenbanksysteme deutlich höher und die Formulierung
korrekter Anfragen schwieriger, weshalb eine Verwendung als Anfragesprache
für Benutzer eines Multidatenbanksystems nicht immer sinnvoll erscheint.
Die Mehrheit der hier vorgestellten Multidatenbanksprachen ist daher darauf
ausgelegt, sogenannte integrierte Sichten zu erstellen, die Integrationskonflikte auflösen und die Daten der Komponentendatenbanken in integrierter Form
darstellen. Es kann dann eine übliche Anfragesprache wie SQL verwendet werden, um Anfragen an die Sichten zu stellen, wodurch die Komplexität der
Integration beim Arbeiten mit dem System verborgen wird.
Wie leicht einzusehen ist, kann das Konzept der integrierten Sichten auch verwendet werden, um deklarativ und mit geringem Aufwand ein globales Schema
innerhalb eines föderierten Datenbanksystems zu erstellen. Der Einsatz einer
Multidatenbanksprache ist in diesem Fall besonders sinnvoll, wenn das globale
Schema nicht für alle Zeiten fix ist, sondern oft geändert werden muss, z.B.
um neue Komponentendatenbanken in die Föderation aufzunehmen oder um
verschiedene Konfliktlösungsstrategien auszuprobieren.
Multidatenbanksprachen unterscheiden sich in erster Linie in dem verwendeten Datenmodell. Da das dieser Arbeit zugrundeliegende Anwendungsszenario ein (objekt-)relationales Datenmodell impliziert, handelt es sich bei den
folgenden Beispielen für Multidatenbanksprachen um Erweiterungen der am
weitesten verbreiteten relationalen Anfragesprache SQL. Sprachvorschläge für
die Integration von Daten in anderen Modellen (z.B. Logik-Datenmodell, objektorientiertes Datenmodell, usw.) werden hier nicht betrachtet, da diese im
Wesentlichen auf denselben Ideen aufbauen. Beispiele für die Anwendung der
hier vorgestellten Sprachen folgen im nächsten Abschnitt.
MSQL (Multidatabase SQL [LAN+ 89]) ist die älteste der hier vorgestellten
Sprachen und hat die Entwicklung der folgenden Multidatenbanksprachen maßgeblich beeinflusst. Sie ermöglicht es, mehrere Datenbanken innerhalb eines Verbundes gleichzeitig abzufragen und auch zu ändern. Allerdings ist die Möglichkeit, Daten mittels der Multidatenbanksprache zu
manipulieren für das Anwendungsszenario in dieser Arbeit nicht relevant.
20
3.3 Mechanismen zur Konfliktauflösung
SQL/M ([KCGS95]) wird innerhalb des Datenbanksystems UniSQL verwendet, um integrierte Sichten, die dort als virtuelle Relationen bezeichnet
werden, zu erstellen. Das verwendete Datenmodell ist zwar objektorientiert, erlaubt jedoch auch die Integration von relationalen Datenbanken.
SchemaSQL ([LSS96]) wurde hauptsächlich zur Auflösung von strukturellen
Konflikten entwickelt und erlaubt eine einheitliche Behandlung von Metadaten und Daten innerhalb von Anfragen. Dies wird erreicht, indem es
eine spezielle Syntax ermöglicht, Variablen an Metadaten, also an Namen
von Datenbanken innerhalb der Föderation, an Namen von Relationen
in einer Datenbank und an Namen von Attributen einer Relation, zu
binden. Damit wird die Funktionalität von SQL erweitert, das lediglich
Tupelvariablen gestattet. Ein weiteres Feature von SchemaSQL ist die
Definition von Sichten, deren Schema dynamisch von den Ausprägungen
der Komponentendatenbanken in der Föderation abhängt.
FraQL (Federated Query Language [SCS00]) enthält ähnliche Konzepte wie
SchemaSQL zur Behandlung von Metadaten und strukturellen Konflikten. Zusätzlich sind Erweiterungen zur Behandlung von Beschreibungsund extensionalen Konflikten enthalten.
FISQL/FIRA (Federated Interoperable SQL/Federated Interoperable Relational Algebra [WR05]) ist eine für theoretische Untersuchungen entwickelte Erweiterung der Relationalen Algebra samt zugehöriger Anfragesprache, die wie SchemaSQL eine gleichwertige Behandlung von Daten
und Metadaten erlaubt. Weiterhin wird in diesem Ansatz das übliche relationale Modell dahingehend erweitert, dass das Ergebnis einer Anfrage
aus mehreren Relationen (auch dynamisch vielen) bestehen kann.
3.3
Mechanismen zur Konfliktauflösung
Im folgenden werden Sprachkonstrukte der letzten drei in Abschnitt 3.2 vorgestellten Multidatenbanksprachen zur Auflösung der unterschiedlichen Arten
von Integrationskonflikten anhand von Beispielen vorgestellt. Diese Konfliktauflösungsmechanismen werden, was das relationale Datenmodell betrifft, hier
als überlegen gegenüber denen der älteren beiden Sprachen betrachtet.
21
Integrationskonflikte und Multidatenbanksprachen
3.3.1
Beschreibungskonflikte
Datenbank A:
id
1
2
3
Straße
objektart
länge m
Kreisstraße
500
Landstraße
2500
Landstraße
3200
Datenbank B:
breite
7
10
11,5
id
11
12
13
kennung
B 83
L 342
U 25
nummer
1105
1103
Straße
obj art
1103
1105
1107
länge km
25,0
5,7
10,3
OArten
art
Landstraße
Bundesstraße
Abbildung 3.2: Beispieldatenbanken zu Beschreibungskonflikten
Die Möglichkeit, Schemaelemente umzubenennen, existiert bereits in SQL und
kann somit auch in Multidatenbanksprachen benutzt werden, um Synonyme
und Homonyme aufzulösen. Um die Schemata der Datenbanken A und B anzugleichen, könnte man z.B. die Attribute länge km und länge m in länge
sowie obj art in objektart umbenennen. Das Problem der unterschiedlichen Längeneinheiten km und m bekommt man durch Umrechnen in den Griff.
Da diese Umrechnungen auch komplizierter ausfallen können, wie im Fall der
Objektarten-Attribute, die offensichtlich unterschiedliche Wertebereiche besitzen, erlauben es einige Multidatenbanksprachen, benutzerdefinierte Funktionen
zu benutzen. Die Sprache FRAQL bietet außerdem die komfortable Erweiterung, zur Umrechnung statt einer Funktion direkt eine Ersetzungstabelle anzugeben. Mit der Anweisung
SELECT @Table(attribute, source, destination, default)
FROM Relation
wird die Relation Table benutzt, um Werte des Attributs attribute der Relation Relation umzurechnen. Dazu wird der jeweilige Wert des Attributs
attribute in der Spalte source der Tabelle Table gesucht und durch den korrespondierenden Wert in der Spalte destination ersetzt. Wird in der Relation Table kein passender Eintrag gefunden, wird durch den Wert von default
(entweder ein Attribut oder ein konstanter Wert) ersetzt.
Im Beispiel 3.1 werden die benutzerdefinierte Funktion km to m zum Umrechnen der Länge und die OArten-Tabelle der Datenbank B zum Umrechnen der
Objektart in eine zur Datenbank A konforme Darstellung benutzt. Das in der
Datenbank B fehlende Attribut Breite wird durch einen Default-Wert ersetzt.
22
3.3 Mechanismen zur Konfliktauflösung
SELECT id,
km_to_m(länge_km) AS länge,
@B.OArten(obj_art, nummer, art, ’NN’) AS objektart,
’NN’ AS breite
FROM B.Straße
id
11
12
13
länge
25000
5700
10300
objektart
Bundesstraße
Landstraße
NN
breite
NN
NN
NN
Beispiel 3.1: Umwandlung der Datenbank B in eine zur Datenbank A konforme Darstellung
3.3.2
Heterogenitätskonflikte
Üblicherweise geht man bei der Betrachtung der hier vorgestellten Multidatenbanksprachen davon aus, dass die zu integrierenden Schemata in einem einheitlichen Datenmodell vorliegen oder innerhalb des Integrationsprozesses dahingehend transformiert werden. Dadurch treten dann bei der Anwendung von
Multidatenbanksprachen keine Heterogenitätskonflikte mehr auf. Eine Ausnahme bildet hier die Sprache SQL/M, mit der man zumindest relationale und
objektorientierte Schemata integrieren kann. Da eine solche Funktionalität für
das in dieser Arbeit betrachtete Anwendungsszenario allerdings nicht benötigt
wird, wird hier nicht weiter darauf eingegangen.
3.3.3
Extensionale Konflikte
Man betrachte die Datenbanken A und C in Abbildung 3.3. Will man die Straßen
aus beiden Datenbanken zu einer Relation vereinigen, so tritt dabei das Problem auf, dass die Straße mit der ID 2 in beiden Straße-Relationen auftritt. Die
mit dem aus SQL bekannten UNION-Operator berechnete Vereinigung würde
also zwei Einträge für dieselbe Straße enthalten.
Datenbank A:
id
1
2
Straße
objektart
länge
Bundesstraße 25000
Autobahn
70000
Datenbank C:
breite
10
18
id
2
3
Straße
objektart
länge
Autobahn
75000
Bundesstraße 16000
breite
20
12
Abbildung 3.3: Beispieldatenbanken zu extensionalen Konflikten
In FraQL ist dieses Problem dadurch gelöst, dass man bei der Vereinigung der
Relationen durch eine optionale On-Klausel angeben kann, welche Attribute
23
Integrationskonflikte und Multidatenbanksprachen
übereinstimmen müssen, damit ein Tupel dasselbe Objekt repräsentiert. Bei
den Datenbanken in Abbildung 3.3 ist dies nur das Attribut id. Die mit der
Anfrage in Beispiel 3.2 berechnete Vereinigung enthält dann für Objekte mit
derselben ID nur einen entprechenden Eintrag.
SELECT *
FROM A.Straße
UNION C.Straße ON id RECONCILED BY resolveAC
id
1
2
3
objektart
Bundesstraße
Autobahn
Bundesstraße
länge
25000
72500
16000
breite
10
19
12
Beispiel 3.2: Vereinigung der Straße-Relationen der Datenbanken A und C
Es ist dabei jedoch nicht automatisch klar, welche Werte die Attribute objektart, länge und breite bekommen, da sich diese in den lokalen Datenbankrelationen unterscheiden können. FraQL bietet deshalb die Möglichkeit, sogenannte Konfliktauflösungsfunktionen zu programmieren, die jeweils zwei als
übereinstimmend identifizierte Tupel aus den Ausgangsrelationen als Eingabe erhalten und jeweils ein Tupel als Ergebnis liefern. Mit einer optionalen
Reconciled-By-Klausel kann bei einer Integrationsoperation angegeben werden,
dass eine solche benutzerdefinierte Funktion zur Auflösung von eventuell in den
Daten auftretenden Konflikten verwendet werden soll. Im Beispiel 3.2 errechnet die Funktion resolveAC jeweils den Durchschnitt aus den unterschiedlichen
Längen- und Breitenwerten für das Tupel mit der ID 2.
Leider schränkt dieser Ansatz die Wiederverwendbarkeit einer Konfliktauflösungsfunktion stark ein, denn diese kann nur für die Integration von Relationen mit einem bestimmten Schema verwendet werden. Will man Relationen
mit einem anderen Schema integrieren oder Konflikte zwischen unterschiedlichen Attributwerten auf andere Art auflösen, muss jeweils eine neue Konfliktauflösungsfunktion programmiert werden.
3.3.4
Strukturelle Konflikte
Durch Fragmentierung entstehende strukturelle Konflikte lassen sich mit den
Möglichkeiten von SQL auflösen, indem Fragmente durch Vereinigung oder
Verbund zusammengesetzt werden. Allerdings bietet SQL keine Möglichkeit,
Metadaten in Daten zu transformieren und umgekehrt. Zur Behandlung von
Daten-Metadaten-Konflikten sind Erweiterungen notwendig, wie sie die Multidatenbanksprachen SchemaSQL, FraQL und FISQL anbieten. Diese erlauben
24
3.3 Mechanismen zur Konfliktauflösung
einen Zugriff auf Metadaten, z.B. die Namen von Relationen in einer Datenbank
oder die Namen von Attributen einer Relation, innerhalb einer Anfrage. Mit
diesen Erweiterungen wird eine sehr elegante Umstrukturierung von Schemata
ermöglicht. Die Umsetzung ist jedoch in den vorgestellten Sprachen leicht unterschiedlich, was im Folgenden anhand der Beispieldatenbanken in Abbildung
3.4 demonstriert wird.
Datenbank C:
id
2
3
Straße
objektart
länge
Bundesstraße 15000
Autobahn
75000
sid
2
3
3
Kennung
art wert
D
B83
D
A2
EU
E30
Datenbank D:
breite
9
18
id
3
Autobahn
länge breite
75000
18
id
2
Bundesstraße
länge breite
15000
9
sid
2
3
Kennung
D
EU
B83
A2 E30
Abbildung 3.4: Beispieldatenbanken zu strukturellen Konflikten
Transformation von Metadaten in Daten
In SchemaSQL können in der FROM-Klausel einer Anfrage fünf verschiedene
Arten von Mengen definiert werden, an deren Elemente eine Variable gebunden
wird:
1. Der Ausdruck -> D bindet die Variable D an die Namen aller Datenbanken
in der Föderation.
2. Der Ausdruck db-> R bindet die Variable R an die Namen aller Relationen
in der Datenbank db.
3. Der Ausdruck db::rel-> A bindet die Variable A an die Namen aller
Attribute der Relation rel in der Datenbank db.
4. Der Ausdruck db::rel T bindet die Variable T an alle Tupel der Relation
rel in der Datenbank db. Dies entspricht den Tupelvariablen aus SQL.
5. Der Ausdruck db::rel.attr W bindet die Variable W an alle Werte des
Attributs attr der Relation rel in der Datenbank db. Solche Variablen
nennt man auch Bereichsvariablen.
Variablen können in einer Anfrage anstelle von Relationen- oder Attributnamen angegeben werden. Im Gegensatz zur Verwendung konstanter Relationenoder Attributnamen wird damit erreicht, dass erst zur Laufzeit bestimmt wird,
welche Relationen und Attribute in der Anfrage referenziert werden.
25
Integrationskonflikte und Multidatenbanksprachen
CREATE VIEW Straße(id, objektart, länge, breite) AS
SELECT T.id, R, T.länge, T.breite
FROM D -> R,
D::R T
WHERE R <> ’Kennung’
CREATE VIEW Kennung(sid, art, wert) AS
SELECT T.sid, A, T.A
FROM D::Kennung-> A,
D::Kennung T
WHERE A <> ’sid’
Beispiel 3.3: Umwandlung der Datenbank D nach C mit SchemaSQL
Im Beispiel 3.3 wird die Anwendung dieser Konstrukte demonstriert, indem die
Datenbank D mittels SchemaSQL derart umstrukturiert wird, dass ihr Schema dem der Datenbank C entspricht. Dazu müssen zunächst alle StraßentypRelationen zu einer Sicht zusammengefasst werden, die eine zusätzliche Spalte
für die Objektart enthält. Man beachte, wie die Variable R an alle Relationennamen außer Kennung gebunden und sofort verwendet wird, um die Variable T
an alle Tupel aus einer dieser Relationen zu binden. Zu jedem Tupel wird im
Ergebnis der Name der Ursprungsrelation als Wert des Attributs objektart
hinzugefügt.
Bei der Umstrukturierung der Relation Kennung wird die Variable A an die
Namen aller Attribute außer sid gebunden. Das Ergebnis enthält ein Tupel
für jede Kombination von Werten von T und A, wobei der Wert von A als Wert
des Attributs art und der Wert des zugehörigen Attributs von T als Wert des
Attributs wert angenommen wird. Das Ergebnis dieser Umstrukturierungsoperationen entspricht genau der Datenbank C in Abbildung 3.4.
Die Multidatenbanksprache FISQL nutzt ähnliche Konzepte wie SchemaSQL,
allerdings mit etwas veränderter Syntax. Hier gibt es keine Create-View-Anweisung um das Ausgabeschema festzulegen. Stattdessen wird der Name der Ergebnisrelation durch eine Into-Anweisung und die Namen ihrer Attribute wie
aus SQL bekannt durch Umbenennung in der Select-Klausel angegeben. Die
Bindung von Variablen an Metadaten in der From-Klausel erfolgt implizit, indem anstelle eines Relationen- oder Attributnamens der Name der Variable
eingesetzt wird.
Auf diese Weise wird in der ersten Anfrage im Beispiel 3.4 die Variable R
implizit an die Namen und die Variable T an die Tupel aller Relationen außer
Kennung in der Datenbank D gebunden. Der Relationenname ergibt im Ergebnis
26
3.3 Mechanismen zur Konfliktauflösung
SELECT T.id, R AS "objektart", T.länge, T.breite
INTO "Straße"
FROM D.R AS T
WHERE R <> "Kennung"
SELECT T.sid, A AS "art", T.A AS "wert"
INTO "Kennung"
FROM D.Kennung.A
D.Kennung AS T
WHERE A <> "sid"
Beispiel 3.4: Umwandlung der Datenbank D nach C mit FISQL
den Wert des Attributs objektart. In der zweiten Anfrage erfolgt implizit eine
Bindung der Variable A an die Namen der Attribute der Relation Kennung in
der Datenbank D.
Einen etwas anderen Ansatz verfolgt die Sprache FraQL. Dort gibt es keine
spezielle Spracherweiterung zur Bindung von Variablen an Metadaten. Stattdessen können Metadaten aus dem Schemakatalog, einer Sammlung spezieller
Relationen, die vom Föderierungsdienst gepflegt werden müssen, abgefragt und
somit wie gewöhnliche Daten behandelt werden. Im Gegensatz zu SchemaSQL
und FISQL wird das Ersetzen von konstanten Relationen- oder Attributnamen
durch Datenwerte mit dem Substitutionsoperator $ syntaktisch hervorgehoben.
Weiterhin ist es in FraQL erforderlich, dass beim Erstellen einer Sichtrelation
das Schema durch die Angabe eines Typs festgelegt wird.
CREATE TABLE Straße OF Straße_Typ_C AS
SELECT T.id, R.table_name AS objektart, T.länge, T.breite
FROM catalog.tables R,
$(R.table_name) T
WHERE R.schema = ’D’
AND R.table_name <> ’Kennung’
CREATE TABLE Kennung OF Kennung_Typ_C AS
SELECT T.sid, A.column_name, T.$(A.column_name)
FROM D.Kennung T,
catalog.columns A
WHERE A.table = ’Kennung’
AND A.column_name <> ’sid’
Beispiel 3.5: Umwandlung der Datenbank D nach C mit FraQL
Im Beispiel 3.5 stammen in der ersten Anfrage die Namen der abzufragenden
Relation aus der Relation tables und werden in der From-Klausel anstelle ei27
Integrationskonflikte und Multidatenbanksprachen
nes konstanten Relationennamens eingesetzt. In der zweiten Anfrage bekommt
man die Namen der abzufragenden Attribute der Relation Kennung aus der
Relation columns, und setzt diese anstelle eines konstanten Attributnamens in
der Select-Klausel ein.
Transformation von Daten in Metadaten
Bei der inversen Transformation, also der Umstrukturierung der Datenbank C
entsprechend dem Schema der Datenbank D, beeinflussen die in C vorhandenen Daten, welche Relationen und Attribute im Ergebnis der Transformation
auftreten. Für jeden Wert des Attributs objektart in der Relation Straße
muss das Ergebnis eine eigene Relation und für jeden Wert des Attributs art
der Relation Kennung ein zusätzliches Attribut enthalten. SchemaSQL erlaubt
es, Variablen in der Create-View-Klausel anstelle von Relationen- oder Attributnamen einzusetzen, um Datenwerte in Elemente des Ergebnisschemas
umzuwandeln.
CREATE VIEW W(id, länge, breite) AS
SELECT T.id, T.länge, T.breite
FROM C::Straße T,
T.objektart W
CREATE VIEW Kennung(sid, W) AS
SELECT T.sid, T.wert
FROM C::Kennung T,
T.art W
Beispiel 3.6: Umwandlung der Datenbank C nach D mit SchemaSQL
In der ersten Anfrage in Beispiel 3.6 wird die Relation Straße in Teilrelationen entsprechend der Objektart fragmentiert. Dazu wird die Variable W an die
Objektarten der Tupel in der Relation Straße gebunden. Die Werte von W werden als Namen der zu erstellenden Sichtrelationen verwendet und die übrigen
Attributwerte jedes Tupels werden übernommen. Das Ergebnis dieser Anweisung sind also mehrere Relationen, die die Straßen mit der jeweils passenden
Objektart enthalten.
Die Umstrukturierung der Kennungen funktioniert auf ähnliche Weise. Die
Variable W wird an die Arten von Kennungen gebunden und die erzeugte Sichtrelation erhält ein Attribut für jeden Wert von W. Der Wert des Attributs
wert wird als Wert des Attributs, das mit der passenden Kennung benannt
ist, übernommen. Somit entspricht das Ergebnis dieser Umstrukturierung der
Datenbank D in Abbildung 3.4.
FISQL erlaubt es ebenfalls, Anfragen mit dynamischem Ausgabeschema zu
28
3.3 Mechanismen zur Konfliktauflösung
formulieren. Variable Ausdrücke können in der Into-Klausel verwendet werden, um die Relationen im Ergebnis dynamisch zu bestimmen, und in einer
zusätzlichen On-Klausel, die Anstelle der As-Klausel verwendet wird, um ein
Ergebnis mit dynamisch bestimmten Attributen zu erhalten.
SELECT T.id, T.länge, T.breite
INTO T.objektart
FROM C.Straße AS T
SELECT T.sid, T.wert ON T.art
INTO "Kennung"
FROM C.Kennung AS T
Beispiel 3.7: Umwandlung der Datenbank C nach D mit FISQL
In der ersten Anfrage im Beispiel 3.7 werden die Werte des Attributs objektart
der Relation Straße in der Datenbank C mittels der INTO-Anweisung als Namen
der Ergebnisrelationen festgelegt. In der zweiten Anfrage wird mit der ONKlausel bestimmt, dass das Ergebnis Attribute enthält, die entsprechend der
Werte des Attributs art der Relation Kennung in der Datenbank C benannt
sind.
In Bezug auf die zweite Anfrage unterscheidet sich die Semantik von SchemaSQL und FISQL (siehe Ergebnisse in Abbildung 3.5). SchemaSQL fasst die
Tupel mit dem gleichen sid-Wert zu einem Ergebnistupel zusammen, während
FISQL für jedes Ausgangstupel ein Ergebnistupel liefert.
sid
2
3
Kennung
D
EU
B83
A2 E30
sid
2
3
3
(a) SchemaSQL
Kennung
D
EU
B83
A2
E30
(b) FISQL
Abbildung 3.5: Ergebnisse der Umstrukturierung der Relation Kennung
In diesem Fall erhält man mit SchemaSQL das gewünschte Ergebnis, allerdings
nur deshalb, weil es zu jeder Kombination aus Attributwerten von sid und art
nur einen eindeutigen Attributwert von wert gibt. Sollte dies nicht gelten, so
führt das Zusammenfassen zu unerwünschten Ergebnissen.
FraQL erlaubt keine Substitution in der Create-Table-Klausel oder einer Attributumbennenungsanweisung und erfordert die Festlegung des Schemas beim
29
Integrationskonflikte und Multidatenbanksprachen
Erstellen einer Sichtrelation durch die Angabe des Typs. Sichten mit dynamisch bestimmten Schema, wie sie bei der Transformation der Datenbank C
entsprechend dem Schema von D hilfreich sind, sind mit FraQL daher nicht
möglich.
Es sei hier angemerkt, dass die hier vorgestellten Beispiele auch durch SQLAnweisungen realisiert werden könnten, wenn alle in der Datenbank auftretenden Arten von Straßen und Kennungen bekannt sind, indem man diese als
Konstanten in die Anweisungen kodiert. Bei größerer Anzahl von unterschiedlichen Arten wird diese Lösung aber immer umständlicher, während die obigen
Anweisungen in den Multidatenbanksprachen unverändert bleiben können.
3.4
Integrationskonflikte bei räumlichen Daten
Bei der Arbeit mit räumlichen Daten verwendet man wie in Abschnitt 2.3 beschrieben Standard- und geometrische Attribute gemeinsam. Somit können die
bis hierher vorgestellten Konflikte auch bei der Integration räumlicher Daten
auftreten. Im Folgenden werden einige Konflikte beschrieben, die durch die Hinzunahme von geometrischen Attributen zusätzlich auftreten, und diskutiert,
wie diese Konflikte in die Klassifikation in Abschnitt 3.1 eingeordnet werden
können. Außerdem wird eine Einschätzung vorgenommen, wie sich die Konfliktauflösungsmechanismen der Multidatenbanksprachen aus Abschnitt 3.2 auf solche durch geometrische Attribute verursachte Konflikte anwenden lassen.
Die Semantik eines geometrischen Attributwertes, der durch repräsentative
Punkte in einem Koordinatensystem gegeben ist, ergibt sich im Fall von geographischen Objekten dadurch, dass Punkte in diesem Koordinatensystem realen
Punkten auf der Erdoberfläche entsprechen. Da man die Abbildung von Punkten in der Datenbank auf reale Orte auf viele unterschiedliche Arten realisieren
kann, wird man eher häufig auf den Fall stoßen, dass die räumliche Ausprägung
von Objekten der realen Welt in unterschiedlichen Komponentendatenbanken
durch unterschiedliche Geometrien repräsentiert ist.
Anders ausgedrückt bedeutet dies, dass der Wert eines geometrischen Attributs
verschiedene Bedeutungen besitzen kann, wenn man diesen in Kontext von unterschiedlichen Komponentendatenbanken betrachtet. Dieser Fall ähnelt vom
Prinzip her beispielweise einem Attribut länge, das in zwei verschiedenen Komponentendatenbanken jeweils die Länge eines Objektes durch einen Zahlenwert
beschreibt, wobei dieser Wert im Kontext der ersten Datenbank als Angabe in
30
3.4 Integrationskonflikte bei räumlichen Daten
Kilometern, im Kontext der anderen Datenbank jedoch als Angabe in Metern
interpretiert wird. Somit kann man hier von einem Beschreibungskonflikt sprechen.
Für die Auflösung von Beschreibungskonflikten bei Standardattributen wird in
Abschnitt 3.3.1 die Verwendung von Umrechnungsfunktionen oder Ersetzungstabellen vorgeschlagen. Prinzipiell kann man auch benutzerdefinierte Funktionen zur Umrechnung von Geometrien erstellen, wobei die zu realisierende
Abbildung dabei meistens recht komplex und daher mit hohem Programmieraufwand verbunden ist. Ersetzungstabellen können auf geometrische Attribute
aufgrund der Vielzahl an möglichen Geometrien nicht angewendet werden.
Mit dem in Abschnitt 2.4.2 beschriebenen RubberSheeting existiert jedoch ein
Verfahren, das Geometrien mit Hilfe von Passpunkten umrechnet. Eine Tabelle,
die Passpunkte aus zwei Komponentendatenbanken enthält, stellt in gewissem
Sinne ein geometrisches Analogon zu einer Ersetzungstabelle dar, denn durch
die Passpunkttabelle wird eine Ersetzungsvorschrift für einzelne Punkte aus
den Koordinatensystemen der Komponentendatenbanken definiert. Somit erscheint es als sinnvoll, für die Umrechnung von Geometrien eine Unterstützung
von Passpunkttabellen innerhalb einer Multidatenbanksprache anzubieten, was
aufgrund der Ausrichtung der Sprachen aus Abschnitt 3.2 auf Standarddaten
bisher nicht realisiert ist.
Beschreiben räumliche Daten aus unterschiedlichen Komponentendatenbanken
zumindest teilweise denselben geographischen Raum, können extensionale Konflikte auftreten, wenn beispielsweise die innerhalb des beschriebenen Gebiets
verlaufenden Straßen in beiden Komponentendatenbanken modelliert sind. Wie
bereits in Abschnitt 2.4.1 beschrieben wurde, hat man oftmals keine über die
Grenzen einer Komponentendatenbank hinaus eindeutigen Identifikatoren für
die modellierten Objekte zur Verfügung, um übereinstimmende Objekte zu
identifizieren. Daher berechnet man mit großem Aufwand Tabellen, die solche
übereinstimmenden Objekte einander zuordnen. Ebenfalls beschrieben wurde
bereits, dass dabei aufgrund von unterschiedlicher Einteilung eines geographischen Gebietes in räumliche Datenobjekte mehrdeutige Zuordnungen zwischen
diesen Objekten auftreten.
Diese Probleme sind nicht auf räumliche Daten beschränkt. Auch bei Standarddaten können Fälle auftreten, in denen man explizit n:m-Zuordnungen zwischen modellierten Objekten abspeichern und ausnutzen möchte. Man denke
beispielsweise an Datenbanken, die Texte enthalten, wobei in der einen Datenbank die Texte in Abschnitte gegliedert und in der anderen in Seiten unterteilt
sind. Dennoch bieten die in Abschnitt 3.2 vorgestellten Multidatenbanksprachen keine Spracherweiterungen zur Verwendung von explizit abgespeicherten
31
Integrationskonflikte und Multidatenbanksprachen
Objektzuordnungen an, da solche Fälle bei Standarddaten offenbar weniger
häufig auftreten. Beim Entwurf einer Multidatenbanksprache für räumliche Datenbanken wird man auf derartige Erweiterungen aber nicht verzichten können.
Die Identifizierung von übereinstimmenden Objekten über mehrdeutige Zuordnungen verkompliziert ebenfalls die Auflösung von Datenkonflikten. In solchen
Fällen können diese Konflikte nicht nur auftreten, wenn übereinstimmende
Objekte in verschiedenen Komponentendatenbanken einen unterschiedlichen
Wert für eine Eigenschaft besitzen, sondern auch, wenn innerhalb einer Komponentendatenbank Objekte mit sich unterscheidenden Eigenschaften zu einem
aggregierten Objekt zusammengefasst werden. Man stelle sich beispielsweise
modellierte Straßenabschnitte vor, denen jeweils unterschiedliche Breitenwerte
zugeordnet sind, wobei der Datenkonflikt darin besteht, dass beim Zusammenfassen dieser Abschnitte zu einem größeren Abschnitt diesem nicht ohne
weiteres eine eindeutige Breite zugeordnet werden kann.
Zur Auflösung solcher durch die Aggregation verursachter Datenkonflikte kann
das Konzept für Konfliktauflösungsfunktionen aus Abschnitt 3.3.3 nicht angewendet werden, da in dem durch die Sprache FraQL realisierten Ansatz eine
Konfliktauflösungsfunktion immer aus genau zwei als übereinstimmend identifizierten Tupeln ein Ergebnistupel berechnet, aggregierte Objekte jedoch aus
beliebig vielen einzelnen Objekten zusammengesetzt sein können.
32
Kapitel 4
Entwurf der SQL-Erweiterung
In diesem Kapitel wird der Entwurf einer SQL-Erweiterung SQLSF 1 vorgestellt, die zur Integration von räumlichen Daten verwendet werden kann. Diese
ist zum Teil inspiriert von den in Kapitel 3 vorgestellten Sprachkonstrukten,
allerdings sind Konzepte wie mehrwertige Attribute oder Komponentendatenbanklinks im Kontext von Multidatenbanksprachen neu.
In Abschnitt 4.1 werden zunächst einige grundlegende Begriffe erläutert, die
beim Entwurf der Sprache eine Rolle spielen. Der folgende Abschnitt 4.2 beschreibt die Verwendung von Ersetzungstabellen und Passpunkten zur Umrechnung von Attributwerten. In Abschnitt 4.3 werden Sprachkonstrukte zum
Erzeugen von mehrwertigen Attributen und zum Umgang mit Datenkonflikten
eingeführt. Abschnitt 4.4 stellt Integrationsoperatoren vor, die abgespeicherte
Zuordnungen zwischen Objekten ausnutzen und Abschnitt 4.5 beschreibt eine
Spracherweiterung zur Realisierung von Daten-Metadaten-Transformationen.
4.1
4.1.1
Grundbegriffe
Das relationale Modell
Eine Datenbank besteht aus einer Menge von Relationen und einem Schema.
Das Schema ordnet jeder Relation einen in der jeweiligen Datenbank eindeutigen Namen und eine Menge von Attributen zu. Jedem einer Relation zugeordneten Attribut wird wiederum durch das Schema ein innerhalb der Attri1
Structured Query Language for Spatial Federations
33
Entwurf der SQL-Erweiterung
butmenge dieser Relation eindeutiger Name und ein Wertebereich, der auch
Datentyp des Attributs genannt wird, zugeordnet.
Eine Relation besteht aus einer Menge von Tupeln. Ein Tupel definiert für alle
Attribute einer Relation eine Zuordnung eines Wertes aus dem Wertebereich
des Attributs zu diesem Attribut. Weiterhin ist durch das Schema für jede Relation ein Schlüssel festgelegt. Dieser besteht aus einer Teilmenge der Attribute
der Relation, wobei in dieser Relation keine zwei Tupel existieren dürfen, die
den Attributen des Schlüssels dieselben Werte zuordnen. In Abbildung 4.1 sind
die im Folgenden verwendeten Abkürzungen für diese Begriffe aufgelistet.
name(R)
attributes(R)
key(R)
name(A)
type(A)
t.A
Name der Relation R
Menge der Attribute der Relation R
Schlüssel der Relation R
Name des Attributs A
Wertebereich des Attributs A
Wert des Attributs A im Tupel t
Abbildung 4.1: Abkürzungen
4.1.2
NF2 -Relationen
Eine Relation ist in 1NF (1.Normalform), wenn alle Attribute einzelne atomare
Werte besitzen. Wird diese Bedingung nicht eingehalten, indem Attributen
mehr als ein Wert zugeordnet wird, spricht man von NF2 -Relationen (NonFirst-Normal-Form). Es existieren verschiedene Ansätze zur Repräsentation
von NF2 -Relationen, die in Abbildung 4.2 beispielhaft dargestellt sind. Dabei
handelt es sich um Relationen, die aggregierte Straßen-Objekte modellieren,
welche aus mehreren einzelnen Objekten zusammengesetzt sind.
Der erste Ansatz (ausführlich vorgestellt z.B. in [OOM87]) in Abbildung 4.2 (a)
erlaubt es, dass der Wert eines Attributs eine Menge von atomaren Werten ist,
z.B. die Menge der Identifikationsnummern der zu einem aggregierten Objekt
zusammengefassten Objekte. Diese Darstellung hat allerdings den Nachteil,
dass nicht rekonstruierbar ist, welche einzelnen Werte unterschiedlicher Attribute zu demselben einzelnen Objekt gehören.
In Abbildung 4.2 (b) werden Arrays als Attributwerte eingesetzt. Die dabei
implizit vorhandene Nummerierung der einzelnen Attributwerte über den Index wird zur Modellierung der Zusammengehörigkeit von Attributwerten verwendet, indem zusammengehörende Werte unterschiedlicher Attribute an der
selben Position im Array abgelegt sind.
34
4.1 Grundbegriffe
aid
1
Straße
oid
breite
{235, {15m,
236,
12m}
237}
{214,
215}
2
{16m,
14m}
(a) Mengen als Attributwerte
aid
1
2
aid
Straße
oid
[1] 235
[2] 236
[3] 237
breite
[1] 15m
[2] 12m
[3] 15m
[1] 214
[2] 215
[1] 16m
[2] 14m
(b) Arrays als Attributwerte
Straße
nested table
1
oid
235
236
237
breite
15m
12m
15m
2
oid
214
215
breite
16m
14m
(c) Relationen als Attributwerte
Abbildung 4.2: Unterschiedliche Ansätze zur Realisierung von NF2 -Relationen
Eine weitere Möglichkeit ist die Verwendung von sogenannten Nested-Relations
(siehe z.B. Beschreibung in [EN00]). Dabei können einem Attribut einer Relation wiederum Relationen als Werte zugewiesen werden (siehe Abbildung 4.2 (c)).
Im Beispiel entspricht jedes Tupel in einer der geschachtelten Relationen einem
einzelnen Straßenabschnitt, der zu dem jeweiligen aggregierten Straßenobjekt
gehört.
4.1.3
Arrays
Um Tupel darstellen zu können, die für einzelne Attribute mehr als einen Wert
besitzen, werden hier Arrays als Datentypen von Attributen erlaubt. Die Verwendung von Arrays bietet sowohl den Vorteil einer relativ einfachen Struktur
der damit gebildeten NF2 -Relationen als auch die Rekonstruierbarkeit der Zusammengehörigkeit von Attributwerten. Weiterhin sind Arrays seit 1999 auch
Bestandteil des SQL-Standards (siehe z.B. [EM99]) und in vielen Datenbanksystemen bereits implementiert.
Um auch Skeptiker zu überzeugen, die hartnäckig eine Einhaltung der 1. Normalform fordern, wird in [EM99] argumentiert, dass Arrays diese nicht wirklich
verletzen, da es sich lediglich um einen zusammengesetzten Datentyp handelt,
der einen komfortablen Zugriff auf einzelne Bestandteile erlaubt. Konzeptionell
besteht somit kein Unterschied zu einer Zeichenkette, die ebenfalls aus mehreren kürzeren Zeichenketten zusammengesetzt sein kann und mittels einer
Substring-Funktion zerlegbar ist.
35
Entwurf der SQL-Erweiterung
Ein Array von n Elementen aus einer Menge Σ ist eine Abbildung
ωn : {1, . . . , n} → Σ
von der Menge der ersten n natürlichen Zahlen in die Menge Σ. Die Menge
aller Arrays von Elementen aus Σ sei definiert als die Menge aller derartiger
Abbildungen:
∞
[
Array [Σ] =
{ωn }
n=1
Der Datentyp eines mehrwertigen Attributs ist dann eine solche Menge von
Arrays. Beispielsweise ist der Datentyp des Attributs oid in Abbildung 4.2(c)
die Menge aller Arrays mit natürlichen Zahlen als Elementen:
type(oid) = Array[N]
4.1.4
Verlinken von Komponentendatenbanken
Wie bereits in Abschnitt 2.2 beschrieben, verwendet der Föderierungsdienst
eines föderierten Datenbanksystems eine Arbeitsdatenbank, in der Informationen gespeichert werden, die man zur Integration der Daten aus den beteiligten Komponentendatenbanken benötigt. Einige der im folgenden definierten
Spracherweiterungen basieren darauf, dass diese Informationen in Form von
Links organisiert sind, die immer zwei Komponentendatenbanken miteinander
verbinden.
Mit diesen Erweiterungen können Daten aus zwei Komponentendatenbanken
mittels eines solchen Komponentendatenbanklinks verknüpft werden, wobei implizit die unter diesem Link abgespeicherten Informationen verwendet werden.
Ein solcher Komponentendatenbanklink besitzt hier implizit immer eine Richtung, die dadurch gegeben ist, dass eine Komponentendatenbank als linke und
die andere als rechte Komponentendatenbank bezeichnet wird.
Es wird hier bei der Verwendung von Komponentendatenbanklinks vorausgesetzt, dass in jeder Komponentendatenbank Identifikatoren für die enthaltenen
Objekte existieren und dass diese zumindest in der jeweiligen Datenbank eindeutig sind. Die Attribute, die diese Identifikatoren enthalten, heißen im folgenden Identifikatorattribute. Abbildung 4.3 zeigt beispielhaft einige Tabellen in
der Arbeitsdatenbank, die Informationen zur Integration von zwei Komponentendatenbanken enthalten und einem Komponentendatenbanklink zugeordnet
werden können.
36
4.1 Grundbegriffe
Arbeitsdatenbank:
ObjektartTransition
objektartA
objektartB
Landstraße
3105
Gewerbegebiet
2013
Siedlung
2203
xA
52.32
64.22
81.32
ReferencePoints
yA
xB
yB
44.21 50.79 43.25
15.37 89.36 15.68
13.28 72.74 14.05
AggregationA
oid
aggID
321
81
322
82
323
81
324
83
AggregationB
oid
aggID
561
11
562
12
563
11
ObjektLinkAB
aid
bid
321
562
322
561
322
563
323
562
LinkAB
aid bid
81
12
82
11
Abbildung 4.3: Tabellen mit Informationen zum Verlinken von zwei Komponentendatenbanken
• Ersetzungstabellen, wie die Tabelle ObjektartTransition, sind für die
Umrechnung von Attributwerten bestimmt. Solche Tabellen müssen mindestens zwei Spalten, im folgenden als linkes und rechtes Werteattribut
bezeichnet, besitzen, die mögliche Werte eines Attributs aus der linken und die zugehörigen Werte eines Attributs aus der rechten Komponentendatenbank enthalten. Es können dem Komponentendatenbanklink zusätzlich Default-Werte zur Umrechnung von nicht in der Tabelle
auftretenden Werten zugeordnet werden.
• Für die Transformation von Geometrien kann einem Komponentendatenbanklink eine Tabelle mit Passpunkten zugewiesen werden, im Beispiel
die Tabelle ReferencePoints, die vier Spalten mit den Koordinaten von
jeweils zwei übereinstimmenden Punkten aus den Komponentendatenbanken enthält. Durch diese Tabelle und das in Abschnitt 2.4.2 beschriebene Rubber Sheeting wird eine Abbildung zur Umrechnung von Geometrien der Komponentendatenbanken definiert, wobei zu einer Passpunktabelle noch ein Parameter für die Stärke der Verzerrung festgelegt
werden muss.
• Bei der Objektzuordnung (siehe Abschnitt 2.4.1) berechnete Tabellen, die
einzelne Objekte einer Komponentendatenbank zu aggregierten Objekten
zusammenfassen (beispielsweise AggregationA und AggregationB), besitzen zwei Spalten für die Identifikatoren der aggregierten und zugehörigen einzelnen Objekte. Im folgenden werden diese Tabellen als Aggregierungstabellen und ihre Spalten als Identifikatorattribut bzw. Aggregierungsidentifikatorattribut bezeichnet. Einem Komponentendatenbanklink
kann jeweils eine Aggregierungstabelle für die linke und rechte Komponentendatenbank zugeordnet sein.
37
Entwurf der SQL-Erweiterung
• Tabellen zur Abspeicherung von Zuordnungen enthalten zwei Spalten für
die Identifikatoren der zugeordneten Objekte. Man kann einem Komponentendatenbanklink eine Tabelle mit Zuordnungen von einzelnen Objekten (z.B. ObjektLinkAB) und eine Tabelle mit Zuordnungen von aggregierten Objekten (z.B. LinkAB) zuweisen. Solche Tabellen werden im
folgenden als Objektlinktabellen bzw. Linktabellen und ihre Spalten als
linkes und rechtes Identifikatorattribut bzw. Aggregierungsidentifikatorattribut bezeichnet.
Bevor solche Tabellen implizit zur Beantwortung von Anfragen, die Informationen aus zwei Komponentendatenbanken integrieren, ausgenutzt werden
können, muss ein Komponentendatenbanklink zwischen diesen Datenbanken
angelegt und die Tabellen als Bestandteile dieses Links registriert werden. Dabei werden die Namen der Tabellen, der Spalten und der in den Komponentendatenbanken referenzierten Attribute im Anfragesystem abgespeichert, so
dass diese bei der Formulierung von Anfragen nicht mehr angegeben werden
müssen. In Abschnitt 5.2 ist ausführlich beschrieben, wie man im Anfragesystem Komponentendatenbanklinks anlegt und wie man zugeordnete Tabellen
registriert.
4.2
Attributtransformation
Die Auflösung von Beschreibungskonflikten erfordert es, Attributwerte umzurechnen, da sich die Semantik eines Wertes innerhalb verschiedener Komponentendatenbanken unterscheiden kann. Wie bereits in Abschnitt 3.3.1 beschrieben können mit den Möglichkeiten von SQL benutzerdefinierte Funktionen zur
Umrechnung verwendet werden.
Eine andere dort beschriebene Option, Abbildungen auf Tupelebene zu realisieren, ist die Verwendung von Ersetzungstabellen. Auch für SQLSF wird im
folgenden eine Möglichkeit erläutert, Ersetzungstabellen für Standardattribute
zu verwenden. Für geometrische Attribute können Tabellen mit Passpunkten
verwendet werden, um die enthaltenen Geometrien umzurechnen. Die folgenden Beispiele beziehen sich auf die Datenbanken in Abbildung 4.4.
Die Datenbanken A und B enthalten jeweils eine Relation mit geographischen
Objekten, wobei sich die Darstellung der Attributart unterscheidet. Um diese
Darstellungen ineinander umzurechnen, soll die Tabelle ObjektartTransition
in der Arbeitsdatenbank verwendet werden. Die Tabelle ReferencePoints
enthält die Koordinaten von Passpunkten aus den Komponentendatenbanken.
38
4.2 Attributtransformation
Datenbank A:
oid
101
102
103
104
Objekt
objektart
Landstraße
Gewerbegebiet
Siedlung
Weg
Datenbank B:
geometrie
oid
101
102
103
104
Objekt
objektart geometrie
3105
2013
2203
9999
Arbeitsdatenbank:
ObjektartTransition
objektartA
objektartB
Landstraße
3105
Gewerbegebiet
2013
Siedlung
2203
xA
52.32
364.22
81.32
ReferencePoints
yA
xB
44.21
50.79
15.37 389.36
103.28 72.74
yB
43.25
15.68
96.05
Abbildung 4.4: Beispieldatenbanken sowie Ersetzungs- und Passpunkttabelle in der Arbeitsdatenbank
4.2.1
Standardattribute
Während FraQL einen Vorschlag enthält, mit dem Ersetzungstabellen für einzelne Attribute in der Anfrage referenziert werden können, wird es hier ermöglicht, Ersetzungstabellen, die als Bestandteil eines Komponentendatenbanklinks eingerichtet wurden, implizit zur Umrechnung innerhalb von Anfragen zu
verwenden. Dazu müssen dass umzurechnende Attribut und der Komponentendatenbanklink innerhalb einer Transform-Klausel angegeben werden, die Anstelle eines gewöhnlichen Ausdrucks in der Select-Klausel angewendet werden
kann.
Bei dieser Art von Verwendung eines Komponentendatenbanklinks muss durch
das Schlüsselwort LEFT bzw. RIGHT angegeben werden, auf welcher Seite des
Links sich die Datenbank befindet, aus der das umzurechnende Attribut stammt.
Sei R eine Relation in einer Komponentendatenbank K1 mit mindestens zwei
Attributen A und B. Weiterhin existiere ein Komponentendatenbanklink L,
der K1 mit einer anderen Komponentendatenbank K2 verbindet. Sei T ab eine
Ersetzungstabelle mit den Werteattributen B1 und B2 , die dem Komponentendatenbanklink L zur Umrechnung des Attributs B in ein Attribut B 0 in
der Komponentendatenbank K2 zugeordnet ist. Dabei enthalte das linke Werteattribut B1 paarweise verschiedene mögliche Werte von B und das rechte
Werteattribut B2 die semantisch äquivalenten Werte von B 0 . Sei schließlich D
ein dieser Umrechnung zugeordneter Default-Wert für B 0 .
39
Entwurf der SQL-Erweiterung
Die Anweisung
SELECT A, TRANSFORM B USING LEFT LINK L
FROM R
definiert eine neue Relation S mit zwei Attributen A und B 0 , die für jedes
Tupel t aus der Ursprungsrelation R ein Tupel s(t) enthält.
attributes(S) = {A, B 0 }
S = {s(t) | t ∈ R}
Dabei wird der Wert des Attributs A von s(t) unverändert übernommen,
während das Attribut B 0 den Wert des Attributs B2 in der Zeile der Ersetzungstabelle T ab erhält, deren Wert des Attributs B1 mit dem Wert des Attributs B von t übereinstimmt. Falls keine solche Zeile in der Ersetzungstabelle
T ab existiert, wird dem Attribut B 0 der Default-Wert D zugewiesen. Diese
Definition ist eindeutig, da B1 keine doppelten Werte enthält. Also gilt:
s(t).A = t.A
(
t0 .B2
0
s(t).B =
D
falls t0 ∈ T ab existiert mit t0 .B1 = t.B,
sonst.
Dieselbe Ersetzungstabelle kann auch verwendet werden, um die Werte des
Attributs B 0 in der rechten Komponentendatenbank K2 in die Darstellung von
K1 zu transformieren. In diesem Fall ist anstelle von LEFT das Schlüsselwort
RIGHT zu verwenden.
Als Beispiel sei angenommen dass für die Datenbanken A und B in Abbildung
4.4 ein Komponentendatenbanklink mit dem Namen A B eingerichtet, die Tabelle ObjektartTransition für die Umrechnung der Objektart-Attribute registriert und dabei für die Datenbank B die Default-Objektart 9999 festgelegt
wurde.
In der Anfrage in Beispiel 4.1 muss dann nur der Name des Datenbanklinks
referenziert werden, um die alphanumerische Objektart der Objekte aus der
Datenbank A anhand der Ersetzungstabelle in die numerische Darstellung der
Datenbank B zu transformieren. Da die Tabelle ObjektartTransition keine
Ersetzung für den Wert Weg enthält, wird dem entsprechenden Objekt die
festgelegte Default-Objektart zugewiesen.
40
4.2 Attributtransformation
SELECT oid,
TRANSFORM objektart USING LEFT LINK A_B,
geometrie
FROM A.Objekt
oid
101
102
103
104
objektart
3105
2013
2203
9999
geometrie
Beispiel 4.1: Umrechnung der Objektart durch Verwendung eines Komponentendatenbanklinks mit zugeordneter Ersetzungstabelle
4.2.2
Geometrische Attribute
Für die Umrechnung eines geometrischen Attributs kann in dieser SQL-Erweiterung implizit eine Tabelle mit Passpunkten, die für ausgewählte Punkte
beschreibt, wie diese umzurechnen sind, verwendet werden. Dazu muss diese Tabelle ebenfalls einem Komponentendatenbanklink zugeordnet sein, der
die Komponentendatenbank mit den umzurechnenden Geometrien mit einer
weiteren Datenbank verbindet. Bei Anwendung der Transform-Klausel auf ein
geometrisches Attribut wird dann implizit das in Abschnitt 2.4.2 beschriebene
Rubber Sheeting ausgeführt, wobei die dem referenzierten Komponentendatenbanklink zugeordnete Passpunkttabelle und der zugehörige Verzerrungsparameter verwendet werden.
In der Anfrage in Beispiel 4.2 wird die Transform-Klausel verwendet, um die
Geometrien aus der Komponentendatenbank B in Abbildung 4.4 in eine an
die Datenbank A angepasste Darstellung zu transformieren. Es sei wiederum
angenommen, dass zwischen den Datenbanken ein Komponentendatenbanklink
SELECT oid,
objektart,
TRANSFORM geometrie USING RIGHT LINK A_B
FROM B.Objekt
oid
101
102
103
104
objektart
3105
2013
2203
9999
geometrie
Beispiel 4.2: Transformation von Geometrien durch implizite Verwendung einer Passpunkttabelle
41
Entwurf der SQL-Erweiterung
mit dem Namen A B eingerichtet und diesem die Tabelle ReferencePoints als
Passpunkttabelle zugeordnet wurde.
4.2.3
Bemerkungen
Neben Ersetzungs- und Passpunkttabellen sind andere Möglichkeiten vorstellbar, Beschreibungskonflikte auf Standard- oder geometrischen Attributen durch
Transformation von Attributwerten aufzulösen. Alternative Verfahren können
als benutzerdefinierte Funktionen innerhalb des föderierten Datenbanksystems
erstellt und anschließend in Anfragen angewendet werden. Dies stellt allerdings
keine Erweiterung zum aus SQL bekannten Sprachumfang dar und ist deshalb
hier nicht beschrieben.
4.3
Mehrwertige Attribute
Mehrwertige Attribute werden in dieser Spracherweiterung benutzt, um Datenkonflikte zu repräsentieren. Diese treten auf, wenn Objekte aus unterschiedlichen Komponentendatenbanken, deren Attributwerte sich unterscheiden, zusammengefasst werden. Außerdem stösst man auf diese Konflikte, wenn man
mehrere Objekte in einer Komponentendatenbank zu einem aggregierten Objekt zusammenfasst. Die folgenden Abschnitte enthalten Sprachvorschläge zur
Unterstützung dieser Operationen und zur Auflösung von Datenkonflikten. Diese Vorschläge werden anhand der Datenbanken in Abbildung 4.5 demonstriert.
Die Datenbanken A und B enthalten jeweils eine Relation mit Straßen-Objekten.
In der Arbeitsdatenbank befindet sich jeweils eine Aggregierungstabelle für jede
Komponentendatenbank, die einzelne Objekte aus dieser Komponentendatenbank zu aggregierten Objekten zusammenfasst.
4.3.1
Aggregation
Mit der hier vorgestellten Erweiterung der Anfragesprache SQL ist es möglich,
die Tupel in einer Relation zu Tupeln mit mehrwertigen Attributen zu aggregieren. Dazu wird hier die Verwendung einer Aggregate-Klausel vorgeschlagen, die
ähnlich der aus SQL bekannten Group-By-Klausel Tupel zusammenfasst, die
in bestimmten Attributwerten übereinstimmen. Der Unterschied besteht darin,
dass die Group-By-Klausel nur zusammen mit Aggregierungsfunktionen eingesetzt werden darf, die aus mehreren Attributwerten einen einzigen berechnen,
42
4.3 Mehrwertige Attribute
Datenbank A:
oid
214
215
235
236
237
länge
6100m
4800m
3200m
4300m
1500m
Datenbank B:
Straße
breite
16m
14m
15m
12m
15m
geometrie
oid
14
15
16
36
37
länge
5400m
4600m
700m
5100m
1900m
Straße
breite
17m
15m
14m
13m
16m
geometrie
Arbeitsdatenbank:
AggregationA
aid
oid
1
214
1
215
2
235
2
236
2
237
AggregationB
aid
oid
1
14
1
15
1
16
2
36
2
37
Abbildung 4.5: Komponentendatenbanken mit Straßen-Relationen und in der Arbeitsdatenbank abgespeicherte Aggregierungstabellen
und somit das Anfrageergebnis die 1.Normalform besitzt. Mit der AggregateKlausel gebildete Relationen enthalten hingegen Attribute, deren Werte Arrays
sind, die die zusammengefassten Attributwerte als Elemente enthalten.
Sei R eine Relation mit mindestens m + 1 Attributen A und B1 , . . . , Bm und
seien a1 , . . . , an alle paarweise verschiedenen Attributwerte, die das Attribut A
in der Relation R annimmt.
Die Anweisung
SELECT A,B1 ,. . . ,Bm
FROM R
AGGREGATE BY A
definiert eine neue Relation S mit dem unveränderten Attribut A und m mehr0
wertigen Attributen B10 , . . . , Bm
, deren Typ die Menge aller Arrays von Elementen des Typs des jeweiligen Ursprungsattributs ist. Also gilt für alle j mit
1≤j≤m:
type(Bj0 ) = Array[type(Bj )]
Die Relation S enthält ein Tupel si für jede Gruppe θi der ni Tupel aus R, die
den Wert ai des Attributs A besitzen.
S = {si | 1 ≤ i ≤ n}
43
Entwurf der SQL-Erweiterung
Dabei gilt für alle i mit 1 ≤ i ≤ n :
θi = {t | t ∈ R ∧ t.A = ai }
Der Wert des Attributs A des Tupels si wird unverändert übernommen und
der Wert von Bj0 ist ein Array, das die Werte des Attributs Bj aller Tupel aus
θi enthält. Dabei stehen die Werte des k-ten Tupels tik aus θi in allen m Arrays
an der Position k. Also gilt für alle i, j mit 1 ≤ i ≤ n und 1 ≤ j ≤ m :
si .A = ai
si .Bj0 [k] = tik .Bj
für 1 ≤ k ≤ ni und ni = |θi |
Ein Beispiel für die Verwendung der Aggregate-Klausel zeigt die Anwendung
der Anfrage in Beispiel 4.3 auf die Datenbanken in Abbildung 4.5. Dabei wird
zunächst die Straße-Relationen aus der Datenbank A mit der entsprechenden
Aggregierungstabelle aus der Arbeitsdatenbank verbunden. Anschließend werden Objekte, die zu demselben aggregierten Objekt gehören, zusammengefasst.
SELECT a.aid, s.länge, s.breite, s.geometrie
FROM A.Straße s
JOIN AggregationA a ON s.oid = a.oid
AGGREGATE BY a.aid
aid
1
länge
[1] 6100m
[2] 4800m
breite
[1] 16m
[2] 14m
geometrie
[1]
[2]
2
[1] 3200m
[2] 4300m
[3] 1500m
[1] 15m
[2] 12m
[3] 15m
[1]
[2]
[3]
Beispiel 4.3: Verbund einer Relation mit der passenden Aggregierungstabelle und Aggregation zusammengehörender Objekte
Das Ergebnis dieser Anfrage ist eine Relation mit drei mehrwertigen Attributen länge, breite und geometrie, wobei diese für jedes aggregierte Objekt
die Attributwerte der zugehörigen einzelnen Objekte enthalten. Dabei sind Attributwerte, die zum selben einzelenen Objekt gehören in allen drei Arrays an
derselben Position zu finden.
4.3.2
Aggregierungstabellen
Eine andere Möglichkeit, Objekte auf diese Art zusammenzufassen, besteht hier
darin, einen Komponentendatenbanklink auszunutzen, dem die entsprechenden
44
4.3 Mehrwertige Attribute
Aggregierungstabellen zugeordnet sind. In diesem Fall müssen die Tabelle und
die benötigten Spalten nicht mehr in der Anfrage referenziert werden. Stattdessen wird die Aggregate-Klausel mit einer Using-Link-Klausel kombiniert, so
dass nur noch der Name des Komponentendatenbanklinks und auf welcher Seite sich die Datenbank mit den zu aggregierenden Objekten befindet angegeben
werden muss.
Voraussetzung ist, dass die zu aggregierende Relation die Identifikatoren aus
der jeweiligen Komponentendatenbank enthält. Dem Ergebnis wird implizit
das Attribut mit den Identifikatoren der aggregierten Objekte hinzugefügt.
Man betrachte die Anfrage in Beispiel 4.4, die die Objekte in der Datenbank A
in Abbildung 4.5 aggregiert. Es sei angenommen, dass zwischen den Datenbanken A und B ein Komponentendatenbanklink mit dem Namen A B eingerichtet
und die Aggregierungstabellen AggregationA und AggregationB für die linke
bzw. rechte Komponentendatenbank registriert wurden.
In diesem Fall kann die Aggregate- mit einer Using-Link-Klausel kombiniert
werden, durch die festgelegt wird, dass implizit die dem Komponentendatenbanklink A B zugeordneten Aggregierungstabellen zur Bildung der aggregierten
Objekte benutzt werden. Das Schlüsselwort LEFT gibt an, dass die Objekte der
linken Komponentendatenbank aggregiert werden sollen und somit implizit die
Aggregierungstabelle AggregationA verwendet werden muss. Zur Aggregation der Objekte in der Datenbank B müsste folglich das Schlüsselwort RIGHT
verwendet werden. Man erhält mit dieser Anfrage dasselbe Ergebnis wie in
Beispiel 4.3, da das Attribut aid implizit zum Ergebnis hinzugefügt wird.
SELECT länge, breite, geometrie
FROM A.Straße
AGGREGATE USING LEFT LINK A_B
aid
1
länge
[1] 6100m
[2] 4800m
breite
[1] 16m
[2] 14m
geometrie
[1]
[2]
2
[1] 3200m
[2] 4300m
[3] 1500m
[1] 15m
[2] 12m
[3] 15m
[1]
[2]
[3]
Beispiel 4.4: Aggregation der Straßen-Objekte aus der Datenbank A mittels abgespeicherter
Aggregationstabelle
45
Entwurf der SQL-Erweiterung
4.3.3
Auflösen von Datenkonflikten
Für die Auflösung von Datenkonflikten, die in Form eines mehrwertigen Attributs repräsentiert sind, genügt es, auf Tupelebene Abbildungen anzuwenden, die aus den Werten eines mehrwertigen Attributs einen eindeutigen Wert
berechnen. Solche Abbildungen lassen sich als benutzerdefinierte Funktionen
innerhalb des Datenbanksystems realisieren. Diese können dann in Anfragen
verwendet werden, um ein Array mit zueinander in Konflikt stehenden Werten
in einen aufgelösten Wert umzuformen.
Im folgenden werden einige nützliche Konfliktauflösungsfunktionen vorgeschlagen. Diese sollen als Standardauflösungsmethoden bereits Bestandteil eines
SQLSF-Anfragesystems sein. Für Fälle in denen diese Funktionen nicht ausreichen, können innerhalb des Datenbanksystems weitere Konfliktauflösungsfunktionen programmiert werden. Wie dies zu erreichen ist, ist implementationsabhängig und wird in Abschnitt 7.5 für den in dieser Arbeit erstellten
Prototypen beschrieben. Es werden hier nur die in dieser Arbeit am häufigsten
verwendeten Datentypen Zahl, Zeichenkette und Geometrie betrachtet.
Konfliktauflösungsfunktionen für Zahlen
• sumOf : Array[Number] → Number
Berechnet die Summe der Elemente eines Arrays von Zahlen.
• avgOf : Array[Number] → Number
Berechnet den Durchschnitt der Elemente eines Arrays von Zahlen.
• weightedAvgOf : Array[Number] × Array[Number] → Number
Berechnet den Durchschnitt der Elemente des zweiten Arrays gewichtet
mit denen des ersten.
• maxOf : Array[Number] → Number
Berechnet das Maximum der Elemente eines Arrays von Zahlen.
• minOf : Array[Number] → Number
Berechnet das Minimum der Elemente eines Arrays von Zahlen.
Konfliktauflösungsfunktionen für Zeichenketten
• maxOf : Array[String] → String
Berechnet das Maximum einer alphabetischen Ordnung der Elemente
eines Arrays von Zeichenketten.
• minOf : Array[String] → String
Berechnet das Minimum einer alphabetischen Ordnung der Elemente eines Arrays von Zeichenketten.
46
4.3 Mehrwertige Attribute
Konfliktauflösungsfunktionen für Geometrien
• spatialUnionOf : Array[Geometry] → Geometry
Berechnet die Vereinigung der Elemente eines Arrays von Geometrien.
• spatialIntersectionOf : Array[Geometry] → Geometry
Berechnet den Schnitt der Elemente eines Arrays von Geometrien.
Manche Methoden zur Konfliktauflösung, wie z.B. die Bevorzugung von Werten
aus einer der Komponentendatenbanken, können bei allen Typen von Attributwerten eingesetzt werden. Daher werden hier Konfliktauflösungsfunktionen der
folgenden Art für jeden der obigen drei Datentypen vorgeschlagen.
• preferLeftT ypeOf : Array[T ype] → T ype
Liefert das erste Element eines Arrays von Elementen eines bestimmten
Typs. Falls dieses Element ein Nullwert ist, wird das zweite zurückgegeben.
• preferRightT ypeOf : Array[T ype] → T ype
Liefert das zweite Element eines Arrays von Elementen eines bestimmten
Typs, falls dieses Element von Null verschieden ist, ansonsten das erste.
• firstT ypeOf : Array[T ype] → T ype
Liefert das erste von Null verschiedene Element eines Arrays von Elementen eines bestimmten Typs.
In Beispiel 4.5 ist noch einmal die Aggregation der Straßen-Objekte aus Datenbank A dargestellt, allerdings diesmal mit Auflösung der Datenkonflikte durch
passende Funktionen. Das Ergebnis dieser Anfrage enthält damit auch weiterhin ein Tupel für jedes aggregierte Objekt, allerdings sind die Attribute länge,
breite und geometrie hier nicht mehrwertig.
SELECT aid, sumOf(länge) AS länge,
weightedAvgOf(länge, breite) AS breite,
spatialUnionOf(geometrie) AS geometrie
FROM A.Straße
AGGREGATE USING LEFT LINK A_B
aid
1
2
länge
10900
9000
breite
15.1
13.6
geometrie
Beispiel 4.5: Aggregation der Straßen aus Datenbank A mit Konfliktauflösung
Die Länge eines aggregierten Objekts wird mit der Funktion sumOf durch Summation der Längen der zugehörigen einzelnen Objekte gebildet. Zur Berech47
Entwurf der SQL-Erweiterung
nung eines Breitenwertes wird mit der Funktion weightedAvgOf der Durchschnitt der einzelnen Breitenwerte gewichtet mit der zugehörigen Länge berechnet. Die Geometrie des aggregierten Objekts erhält man hier durch Berechnung
der Vereinigung aller einzelnen Geometrien mit der Funktion spatialUnionOf.
4.3.4
Bemerkungen
Etwas umständlicher ist die hier beschriebene Art von Aggregation auch durch
eine Anfrage mit Group-By-Klausel darstellbar. Allerdings benötigt man für
jeden Datentyp eines zu aggregierenden Attributs eine eigene Aggregierungsfunktion, die Elemente dieses Datentyps zu einem Array zusammenfasst. Im
Beispiel 4.6 sind dies Funktionen für die Aggregation von Zahlen und Geometrien. Somit liefert diese Anfrage das selbe Ergebnis wie Beispiel 4.3.
SELECT a.aid, aggregateNumber(s.länge) AS länge,
aggregateNumber(s.breite) AS breite,
aggregateGeometry(s.geometrie) AS geometrie
FROM A.Straße s
JOIN AggregationA a ON s.oid = a.oid
GROUP BY a.aid
Beispiel 4.6: Aggregation mit Group-By-Klausel
4.4
Integrationsoperatoren
Dieser Abschnitt beschreibt Operatoren zur Integration von Objekten aus unterschiedlichen Komponentendatenbanken, für die explizit Zuordnungen in der
Arbeitsdatenbank abgespeichert sind. Dazu werden die SQL-Operatoren zur
Berechnung von Verbund und Vereinigung dahingehend erweitert, dass implizit
die in dem Zuordnungsschema aus Abschnitt 2.4.1 strukturierten Zuordnungen
ausgenutzt werden, so dass man diese Operatoren verwenden kann, ohne die
Details des Zuordnungsschemas zu kennen. Die Anwendung dieser Operatoren erfolgt durch Kombination der Join- bzw. Union-Klausel mit der in dieser
Arbeit neu eingeführten Using-Link-Klausel.
Als Beispiel betrachte man die Datenbanken in Abbildung 4.6. Die Komponentendatenbanken enthalten jeweils eine Tabelle mit räumlichen Objekten.
In der Arbeitsdatenbank enthält die Tabelle ObjektLinkAB Zuordnungen der
einzelnen räumlichen Objekte. Die Tabellen AggregationA und AggregationB
48
4.4 Integrationsoperatoren
enthalten Repräsentationen für die beim Matching gebildeten aggregierten Objekte in der Datenbank A bzw. B und ordnen diesen aggregierten Objekte die
zugehörigen Einzelobjekte zu. Die Tabelle LinkAB enthält die Zuordnungen der
aggregierten Objekte.
Datenbank A:
oid
321
322
323
324
Datenbank B:
Objekt
objektart geometrie
Straße
Siedlung
Straße
Straße
oid
561
562
563
Objekt
objektart geometrie
Siedlung
Straße
Siedlung
Arbeitsdatenbank:
AggregationA
oid
aggID
321
81
322
82
323
81
324
83
AggregationB
oid
aggID
561
11
562
12
563
11
ObjektLinkAB
aid
bid
321
562
322
561
322
563
323
562
LinkAB
aid bid
81
12
82
11
Abbildung 4.6: Komponentendatenbanken und abgespeicherte Zuordnungen
4.4.1
Der erweiterte Verbundoperator
Zunächst wird ein erweiterter Operator zur Berechnung von Verbunden eingeführt. Hat man einmal die notwendigen Daten zur Zuordnung von Objekten aus unterschiedlichen Komponentendatenbanken in der Arbeitsdatenbank
hinterlegt und einen entsprechenden Komponentendatenbanklink eingerichtet,
kann dieser Link in der Anfrage referenziert werden, um einen Verbund der
über diesen Link zugeordneten Objekte zu berechnen. Dazu ist es erforderlich, dass die zu verbindenden Relationen die Identifikatoren aus der jeweiligen
Komponentendatenbank enthalten.
In der Anfrage in Beispiel 4.7 werden zugeordnete Objekte, die jeweils durch das
Attribut oid identifiziert sind, aus den Datenbanken A und B verbunden. Dazu
wird die Using-Link-Klausel in Verbindung mit der Join-Klausel eingesetzt um
anzugeben, dass die Zuordnungen des Komponentendatenbanklinks A B, also
in diesem Fall die Tabelle ObjektLinkAB, benutzt werden sollen. Das Ergebnis
dieser Anfrage enthält für jede in der Tabelle ObjektLinkAB abgespeicherte
Zuordnung ein Tupel, das die Attributwerte der einander zugeordneten Objekte
enthält.
49
Entwurf der SQL-Erweiterung
SELECT o1.oid, o1.objektart, o1.geometrie,
o2.oid, o2.objektart, o2.geometrie
FROM A.Objekt o1
JOIN B.Objekt o2 USING LINK A_B
oid
321
322
322
323
objektart
Straße
Siedlung
Siedlung
Straße
geometrie
oid
562
561
563
562
objektart
Straße
Siedlung
Siedlung
Straße
geometrie
Beispiel 4.7: Berechnung des Verbunds zugeordneter Objekte
Der erweiterte Verbundoperator kann auch verwendet werden, um Verbunde
von Relationen mit aggregierten Objekten zu berechnen. Dazu betrachte man
die Relationen Agg ObjektA und Agg ObjektB in Abbildung 4.7 die aggregierte Objekte aus den Datenbanken A bzw. B enthalten. Solche Relationen kann
man beispielsweise mit den in Abschnitt 4.3 beschriebenen Spracherweiterungen herstellen.
aggID
81
82
83
Agg ObjektA
objektart geometrie
Straße
Siedlung
Straße
aggID
11
12
Agg ObjektB
objektart geometrie
Siedlung
Straße
Abbildung 4.7: Tabellen mit aggregierten Objekten
Um Tabellen mit aggregierten Objekten mittels des erweiterten Verbundoperators zu verknüpfen, müssen diese Tabellen die Identifikatoren der aggregierten
Objekte aus den Aggregierungstabellen enthalten. Innerhalb der Using-LinkKlausel gibt man durch das Schlüsselwort AGGREGATED an, dass die zu verbindenden Relationen aggregierte Objekte enthalten, was dazu führt, dass implizit
die Linktabelle zur Verknüpfung der Relationen verwendet wird. Daher werden
die Relationen mit aggregierten Objekten aus Abbildung 4.7 in der Anfrage aus
Beispiel 4.8 implizit mit der Tabelle LinkAB verbunden.
Schließlich kann es auch wünschenswert sein, aggregierte Objekte aus einer
Komponentendatenbank mit den zugehörigen einzelnen Objekten aus der anderen Komponentendatenbank zu verbinden. Dazu muss man in der Anfrage
spezifizieren, welche der zu verbindenden Relationen die aggregierten und welche die einzelnen Objekte enthält. Dazu wird hier das Schlüsselwort LEFT bzw.
RIGHT verwendet, das angibt, dass die Relation auf der linken bzw. rechten Seite
des Komponentendatenbanklinks aggregierte Objekte enthält. Die Relationen
50
4.4 Integrationsoperatoren
SELECT o1.aggID, o1.objektart, o1.geometrie,
o2.aggID, o2.objektart, o2.geometrie
FROM Agg_Objekt_A o1
JOIN Agg_Objekt_B o2 USING AGGREGATED LINK A_B
aggID
81
82
objektart
Straße
Siedlung
geometrie
aggID
12
11
objektart
Straße
Siedlung
geometrie
Beispiel 4.8: Berechnung eines Verbunds aggregierter Objekte
werden dann über die Aggregierungstabelle, die der Seite mit den einzelnen
Objekten entspricht, und die Linktabelle verbunden.
Beispiel 4.9 zeigt eine Anfrage, die einen Verbund der aggregierten Objekte
aus der Datenbank A mit den einzelnen Objekten aus B berechnet. Für jede
Zuordnung in der Relation, die man erhält, wenn man die Tabellen LinkAB und
AggregationB verbindet, enthält das Ergebnis ein Tupel mit den Attributwerten der zugeordneten Objekte.
SELECT o1.aggID, o1.objektart, o1.geometrie,
o2.oid, o2.objektart, o2.geometrie
FROM Agg_Objekt_A o1
JOIN B.Objekt o2 USING LEFT AGGREGATED LINK A_B
aggID
81
82
82
objektart
Straße
Siedlung
Siedlung
geometrie
oid
562
561
563
objektart
Straße
Siedlung
Siedlung
geometrie
Beispiel 4.9: Berechnung eines Verbunds aggregierter und zugeordneter einzelner Objekte
4.4.2
Der erweiterte Vereinigungsoperator
Eine andere Operation, die zur Integration eingesetzt werden kann, ist die Vereinigung, die in SQL mit der Union-Klausel angewendet werden kann. Um auch
bei der Vereinigung Zuordnungen zwischen Objekten aus unterschiedlichen
Komponentendatenbanken auszunutzen, kann die Union-Klausel in SQLSF
ebenfalls mit der Using-Link-Klausel kombiniert werden.
Dieser erweiterte Vereinigungsoperator wird im Gegensatz zu dem normalen
Vereinigungsoperator jedoch nicht zur Vereinigung kompletter Unteranfragen
eingetzt, sondern analog zu dem erweiterten Verbundoperator im Anschluss
an die From-Klausel verwendet. Weiterhin wird der erweiterte Vereinigungsoperator ebenfalls in drei Varianten eingeführt, um es zu ermöglichen, einzelne
51
Entwurf der SQL-Erweiterung
Objekte, aggregierte Objekte oder einzelne mit aggregierten Objekten zusammenzufassen, und wie beim erweiterten Verbundoperator müssen die zu vereinigenden Relationen die entsprechenden Identifikatoren enthalten.
Es ist für die Anwendung dieses Operators nicht zwingend erforderlich, dass die
Schemata der zu vereinigenden Relationen übereinstimmen, allerdings müssen
alle in der Select-Klausel referenzierten Attribute in beiden Ausgangsrelationen
vorhanden sein.
Seien R1 und R2 Relationen mit den Identifikatorattributen I1 bzw. I2 . Weiterhin besitze jede dieser Relationen mindestens die Attribute A1 , . . . , An . Sei
T eine Objektlinktabelle mit den Identifikatorattributen B1 und B2 , die dem
Komponentendatenbanklink L zugewiesen ist, der die Komponentendatenbanken, in denen sich die Relationen R1 und R2 befinden, verbindet.
Die Anweisung
SELECT A1 ,. . . ,An
FROM R1
UNION R2 USING LINK L
definiert eine Relation S mit n mehrwertigen Attributen A01 , . . . , A0n , die Arrays von Elementen des Datentyps der ursprünglichen Attribute A1 , . . . , An
enthalten.
attributes(S) = {A01 , . . . , A0n }
type(A0i ) = Array[type(Ai )] für 1 ≤ i ≤ n
Die Relation S enthält ein Tupel s(t1 , t2 ) für jedes Paar (t1 , t2 ) von durch die
Tabelle T zugeordneten Tupeln aus den Relationen R1 und R2 , ein Tupel s(t01 )
für jedes Tupel t01 aus R1 , das keinem Tupel aus R2 zugeordnet ist, und ein
Tupel s(t02 ) für jedes Tupel t02 aus R2 , das keinem Tupel aus R1 zugeordnet ist.
S = {s(t1 , t2 ) | (t1 , t2 ) ∈ R1 × R2 ∧ ∃z ∈ T (t1 .I1 = z.B1 ∧ z.B2 = t2 .B2 )}
∪ {s(t01 ) | t01 ∈ R1 ∧ ∀z ∈ T (t01 .I1 6= z.B1 )}
∪ {s(t02 ) | t02 ∈ R2 ∧ ∀z ∈ T (t02 .I2 6= z.B2 )}
Dabei enthalten die Attribute der Tupel in S jeweils die zwei Werte der zu52
4.4 Integrationsoperatoren
gehörigen Attribute der Tupel aus R1 und R2 . Fehlende Attributwerte aufgrund
nicht zugeordneter Tupel werden durch Nullwerte repräsentiert.
s(t1 , t2 ).Ai [1]
s(t1 , t2 ).Ai [2]
s(t01 ).Ai [1]
s(t01 ).Ai [2]
s(t02 ).Ai [1]
s(t02 ).Ai [2]
=
=
=
=
=
=
t1 .Ai
t2 .Ai
t01 .Ai
null
null
t02 .Ai
Die Semantik der Operatoren, die aggregierte Objekte bzw. aggregierte und
einzelne Objekte vereinigen, ist äquivalent, außer dass analog zu den erweiterten Verbundoperatoren eine andere Relation T zur Definition der Zuordnungen
verwendet werden muss.
Beispiel 4.10 zeigt die Vereinigung der Relationen mit aggregierten Objekten
in Abbildung 4.7. Dabei werden zwei Objekte immer dann zusammengefasst,
wenn sie über die Tabelle LinkAB einander zugeordnet sind. Das aggregierte
Objekt mit der ID 83 ist keinem Objekt zugeordnet, so dass nur die ersten
Elemente der mehrwertigen Attributwerte einen Wert besitzen.
SELECT aggID, objektart, geometrie
FROM Agg_ObjektA
UNION Agg_ObjektB USING AGGREGATED LINK A_B
aggID
[1] 81
[2] 12
objektart
[1] Straße
[2] Straße
geometrie
[1]
[2]
[1] 82
[2] 11
[1] Siedlung
[2] Siedlung
[1]
[2]
[1] 83
[1] Straße
[1]
Beispiel 4.10: Berechnung der Vereinigung zugeordneter aggregierter Objekte
4.4.3
Bemerkungen
Welche Variante des erweiterten Verbund- oder Vereinigunsoperators man zur
Integration von bestimmten Daten einsetzt, hängt von diesen Daten ab. Es
wird hier empfohlen, bei 1:1-Zuordnungen zwischen den einzelnen Objekten
die Operatoren mit impliziter Ausnutzung der Zuordnungen zwischen einzelnen
Objekten zu verwenden.
53
Entwurf der SQL-Erweiterung
Die Operatoren, die die Zuordnungen zwischen den aggregierten Objekten ausnutzen, bieten sich für die Integration von über n:m-Zuordnungen verlinkten
Objekten an. Die Varianten der Integrationsoperatoren, die aggregierte Objekte aus einer und einzelne Objekte aus der anderen Komponentendatenbank
integrieren, werden am sinnvollsten zur Integration von 1:m-zugeordneten Objekten eingesetzt. Jedoch sei hier nicht ausgeschlossen, dass für bestimmte Situationen auch eine Verwendung außerhalb dieser Empfehlungen geeignet sein
kann.
4.5
Substitution
Um Transformationen zwischen Daten und Metadaten zu realisieren, wird SQL
um ein Konzept zur Substitution von Relationen- und Attributnamen erweitert. Dieses entspricht im Wesentlichen dem aus der Multidatenbanksprache
FraQL, allerdings in der Art erweitert, dass es möglich wird, Anfragen mit
dynamischem Ausgabeschema zu formulieren.
Als Quelle für Metadaten können beliebige Relationen verwendet werden, beispielsweise auch der bereits vorhandene Schemakatalog des verwendeten Datenbanksystems. Mit solchen Transformationen lassen sich strukturelle Konflikte,
die beispielsweise bei den Datenbanken in Abbildung 4.8 vorliegen, auflösen.
4.5.1
Transformation von Relationennamen in Daten
Zunächst sei die Transformation von Relationennamen in Daten, die durch
Verwendung des Substitutionsoperators anstelle eines Relationennamens in der
From-Klausel realisiert wird, beschrieben. Die Relation T ables besitze mindestens das Attribut N ame und enthalte die Namen aller Relationen R1 , . . . , Rn
einer Datenbank. Jede dieser Relationen enthalte mindestens das Attribut A.
Die Anweisung
SELECT A, T ables.N ame AS B
FROM T ables,
$(T ables.N ame)
definiert eine neue Relation S mit den Attributen A und B. Diese enthält
für jedes Tupel t aus einer der Ursprungsrelationen R1 , . . . , Rn ein Tupel s(t),
54
4.5 Substitution
Datenbank A:
Verkehr
oid
objektart
geometrie
1
Straße
2
Schienenbahn
3
Flughafen
oid
1
1
2
2
3
Datenbank B:
Straße
oid geometrie
1
Schienenbahn
oid geometrie
2
Flughafen
oid geometrie
3
Attribut
name
wert
Breite
15m
Zustand
in Betrieb
Kategorie
S-Bahn
Breite
2m
Zustand
im Bau
oid
1
2
3
Breite
15m
2m
-
Beschreibung
Zustand
in Betrieb
im Bau
Kategorie
S-Bahn
-
Arbeitsdatenbank:
Tables
name
Verkehr
Attribut
Straße
Schienenbahn
Flughafen
Beschreibung
db
A
A
B
B
B
B
Columns
name
table
oid
Attribut
Breite
Attribut
Zustand
Attribut
Kategorie Attribut
oid
Straße
...
...
Abbildung 4.8: Beispieldatenbanken mit strukturellen Konflikten
das den Wert des Attributs A unverändert übernimmt und den Namen der
Ursprungsrelation als Wert des Attributs B enthält.
attributes(S) = {A, B}
n
[
S =
{s(ti ) | ti ∈ Ri }
i=1
Dabei gilt für alle i mit 1 ≤ i ≤ n :
s(ti ).A = ti .A
s(ti ).B = name(Ri )
Dieses Konzept kann beispielsweise angewendet werden, um die Relationen aus
der Datenbank B, die geographische Objekte beschreiben, zu einer Relation
zusammenzufassen (siehe Beispiel 4.11) und somit die Darstellung aus der Datenbank A zu erhalten. Die dabei erzeugte Sichtrelation enthält ein zusätzliches
Attribut, das die Ursprungsrelation eines Tupels als Wert enthält.
55
Entwurf der SQL-Erweiterung
CREATE VIEW Verkehr AS
SELECT t.oid, Tables.name AS objektart, t.geometrie
FROM Tables,
B.$(Tables.name) t
WHERE Tables.db = ’B’ AND Tables.name <> ’Attribut’
Beispiel 4.11: Anwendung des Substitutionsoperators in der From-Klausel
4.5.2
Transformation von Attributnamen in Daten
Die Transformation von Attributnamen in Daten geschieht hier durch Verwendung des Substitutionsoperators anstelle eines Attributnamens in der SelectKlausel. Sei Columns eine Relation mit mindestens den Attributen N ame und
T able. Diese Relation enthalte die Namen aller Attribute in einer Datenbank
sowie die Namen der zugehörigen Relationen. Die Datenbank enthalte mindestens die Relation R mit den Attributen A1 , . . . , An .
Die Anweisung
SELECT Columns.N ame AS B, R.$(Columns.N ame) AS C
FROM Colums
R
WHERE Columns.T able = name(R)
definiert eine neue Relation S mit den Attributen B und C. Diese enthält
für jedes Tupel t aus der Relation R die n Tupel s1 (t), . . . , sn (t). Die Werte
der Attribute B und C entsprechen dem Namen und dem Wert jeweils eines
Attributs von t.
attributes(S) = {B, C}
[
{si (t) | 1 ≤ i ≤ n}
S =
t∈Rel
Dabei gilt für alle i mit 1 ≤ i ≤ n :
si (t).B = name(Ai )
si (t).C = t.Ai
Mit Hilfe dieses Konzepts kann beispielsweise die Relation Beschreibung in
der Datenbank B in Abbildung 4.8 in die Darstellung in der Datenbank A umgewandelt werden (siehe Beispiel 4.12). Dazu werden alle Werte der Attribute
außer oid in die Spalte wert eingetragen. Zu jedem Wert enthalten die Spalten
oid und name die ID des zugehörigen Tupels bzw. den Namen des zugehörigen
Attributs.
56
4.5 Substitution
CREATE VIEW Attribut AS
SELECT t.oid, Columns.name AS name, t.$(Columns.name) AS wert
FROM Columns
B.Beschreibung t
WHERE Columns.table = ’Attribut’ AND Columns.name <> ’oid’
Beispiel 4.12: Anwendung des Substitutionsoperators in der Select-Klausel
4.5.3
Transformation von Daten in Relationennamen
Zur Transformation von Daten in Relationennamen verwendet man den Substitutionsoperator anstelle eines Relationennamens in der Create-View-Klausel.
Sei R eine Relation mit mindestens zwei Attributen A und B, und seien
a1 , ..., an alle paarweise verschiedenen Werte, die das Attribut A in der Relation R annimmt.
Die Anweisung
CREATE VIEW $(t.A) AS
SELECT t.B
FROM R t
definiert n neue Relationen S1 , . . . , Sn , deren Namen den Werten a1 , ..., an entsprechen. Diese Relationen besitzen genau ein Attribut B und enthalten für
jedes Tupel t aus R, dessen Wert des Attributs A mit dem Namen der Relation übereinstimmt, ein Tupel s(t). Dabei wird der Wert des Attributs B
unverändert übernommen. Es gilt also für alle i mit 1 ≤ i ≤ n:
name(Si ) = ai
attributes(Si ) = {B}
Si = {s(t) | t ∈ R ∧ t.A = ai }
Dabei gilt:
s(t).B = t.B
Dieses Konzept kann verwendet werden, um die Relation Verkehr in der Datenbank A in Abbildung 4.8 so zu partitionieren, dass die in der Datenbank
B dargestellten Relationen entstehen (siehe Beispiel 4.13). Dabei werden die
Objektarten als Namen der zu erzeugenden Sichten und als Kriterium zur Partitionierung verwendet.
57
Entwurf der SQL-Erweiterung
CREATE VIEW $(t.objektart) AS
SELECT t.oid, t.geometrie
FROM Verkehr t
Beispiel 4.13: Verwendung des Substitutionsoperators in der Create-View-Klausel
4.5.4
Transformation von Daten in Attributnamen
Die Transformation von Daten in Attributnamen erreicht man durch Verwendung des Substitutionsoperators anstelle eines Alias in der Select-Klausel. Sei R
eine Relation mit mindestens zwei Attributen A und B und seien b1 , . . . , bn alle
paarweise verschiedenen Werte, die das Attribut B in der Relation R annimt.
Die Anweisung
SELECT t.A AS $(t.B)
FROM R t
definiert eine neue Relation S mit genau n Attributen B1 , . . . , Bn , deren Namen
den Werten b1 , . . . , bn entsprechen. S enthält für jedes Tupel t aus der Relation
R ein Tupel s(t). Dieses enthält den Wert des Attributs A von t als Wert des
Attributs, dessen Name mit dem Wert des Attributs B von t übereinstimmt.
Die Werte aller übrigen Attribute sind Nullwerte.
attributes(S) = {B1 , . . . , Bn }
S = {s(t) | t ∈ R}
Dabei gilt für alle i mit 1 ≤ i ≤ n :
name(Bi ) = bi
(
t.A falls t.B = bi ,
s(t).Bi =
null sonst.
Im Beispiel 4.14 wird diese Art der Umstrukturierung auf die Attribut-Relation
der Datenbank A in Abbildung 4.8 angewendet. Die Werte des Name-Attributs
werden in Attribute transformiert. Für jedes Tupel wird der Wert in der Spalte
oid übernommen und der in der Spalte wert dem Attribut zugewiesen, dessen
Name dem Wert in der Spalte name entspricht.
Das Ergebnis der Anfrage in Beispiel 4.14 entspricht noch nicht dem gewünschten Ergebnis, der Attribut-Relation der Datenbank B in Abbildung 4.8, da hier
keine implizite Aggregation der Tupel mit demselben Wert des Attributs oid
erfolgt. Um doch das gewünschte Ergebnis zu erhalten, kann die Aggregation
58
4.5 Substitution
CREATE VIEW Beschreibung_A AS
SELECT t.oid, t.wert AS $(t.name)
FROM A.Attribut t
oid
1
1
2
2
3
Beschreibung A
breite
zustand
kategorie
15m
in Betrieb
S-Bahn
2m
im Bau
Beispiel 4.14: Verwendung des Substitutionsoperators in der Alias-Definition
explizit mit der in Abschnitt 4.3.1 vorgestellten Spracherweiterung erfolgen.
Weil dabei die Attribute breite, zustand und kategorie zu mehrwertigen
Attributen umgewandelt werden, muss man hier noch eine Konfliktauflösungsfunktion (im Beispiel 4.15 als firstOf bezeichnet) anwenden, die ein Array,
das außer Nullwerten höchstens einen wirklichen Wert enthält, in genau diesen
Wert umwandelt.
CREATE VIEW Beschreibung AS
SELECT oid, firstOf(breite) AS breite,
firstOf(zustand) AS zustand,
firstOf(kategorie) AS kategorie
FROM Beschreibung_A
AGGREGATE BY oid
Beispiel 4.15: Aggregation der Attribut-Relation
4.5.5
Bemerkungen
Eine von den oben beschriebenen Fällen abweichende Verwendung von Substitutionsoperatoren (denkbar wären beispielsweise Substitutionsoperatoren in
der Where-Klausel oder anstelle von Funktionsnamen) wird in dieser Erweiterung zunächst nicht unterstützt.
Man kann sich den Substitutionsoperator $ als eine Art Makro vorstellen. In
einem ersten Schritt zur Ausführung der Anfrage werden alle möglichen Werte
des zu substituierenden Ausdrucks bestimmt. Für jeden Wert wird die Anfrage
umgeschrieben, indem das Makro durch den Wert ersetzt wird. Das Endergebnis erhält man durch geeignetes Zusammensetzen der Ergebnisse der substituierten Anfragen. Diese mehr operationale Sichtweise eignet sich auch gut für
59
Entwurf der SQL-Erweiterung
den Entwurf von Algorithmen zur Bearbeitung von Anfragen mit Substitutionsoperatoren in Abschnitt 5.3.4.
Es ist möglich, mehrere Substitutionsoperatoren in einer Anfrage zu verwenden.
Durch geschickte Kombination lassen sich damit beispielsweise Anweisungen
konstruieren, die noch mächtigere strukturelle Transformationen ausführen.
Die Anweisung in Beispiel 4.16 führt zwei Metadatentransformationen gleichzeitig aus. Angewendet auf die Datenbank A in Abbildung 4.8 erstellt sie eine
Sichtrelation für jede in der Relation Verkehr auftretende Objektart. Dabei
erhält jede Sichtrelation genau die Attribute, deren Name bei Ojekten der zugehörigen Objektart in der Relation Attribut auftritt.
CREATE VIEW $(v.objektart) AS
SELECT v.oid, v.geometrie, a.wert AS $(a.name)
FROM Verkehr v,
Attribut a
WHERE v.oid = a.oid
oid
1
oid
2
geometrie
Straße
breite
15m
zustand
in Betrieb
Schienenbahn
geometrie kategorie
S-Bahn
oid
3
breite
2m
Flughafen
geometrie zustand
im Bau
Beispiel 4.16: Anfrage mit mehreren Substitutionsoperatoren
60
Kapitel 5
Entwurf des Anfragesystems
In den folgenden Abschnitten wird ein Anfragesystem zur prototypischen Umsetzung der in Kapitel 4 entwickelten SQL-Erweiterung entworfen. Dabei wird
versucht, die benötigten Konzepte möglichst unabhängig von einem konkreten
Datenbankmanagementsystem vorzustellen. An einigen Stellen lässt es sich jedoch nicht vermeiden, auf systemspezifische Funktionalität zurückzugreifen,
worauf durch Bemerkungen hingewiesen wird.
Abschnitt 5.1 stellt zunächst eine geeignete Software-Architektur vor. Abschnitt 5.2 beschreibt die für die Ausführung von SQLSF-Anweisungen benötigten Metadaten und wie diese im Anfragesystem registriert werden können. In
Abschnitt 5.3 werden schließlich Algorithmen zur Übersetzung von SQLSF- in
Standard-SQL-Anweisungen angegeben.
5.1
Architektur
Zur Bearbeitung von Anfragen, die die in Kapitel 4 vorgestellten Erweiterungen
enthalten, wird die in Abbildung 5.1 gezeigte Software-Architektur vorgeschlagen. Das Anfragesystem setzt auf einem objekt-relationalen Datenbankmanagementsystem auf. Es wird angenommen, dass alle an der Föderation beteiligten Komponentendatenbanken entweder direkt von diesem Datenbankmanagementsystem verwaltet werden oder über sogenannte Datenbankwrapper 1 an
dieses angeschlossen sind.
1
Diese heißen bei Oracle Datenbanklinks, werden jedoch in dieser Arbeit Wrapper genannt, um Verwechslungen mit den Komponentendatenbanklinks zu vermeiden.
61
Entwurf des Anfragesystems
Frontend
Parser
Ausführungskomponente
DBMS
KDBkatalog
SQL-Anweisung
SQL-Anweisung
SQL-Anweisung
Zugriff über Wrapper
...
Arbeitsdatenbank
KDB
...
KDB
KDB
KDB
Abbildung 5.1: Architektur des Anfragesystems
Der Zweck eines solchen Datenbankwrappers ist es, dem Benutzer zu ermöglichen, auf eine Datenbank zuzugreifen, die von einem anderen Datenbankmanagementsystem verwaltet wird. Dabei sorgt das System dafür, dass sich der Zugriff auf eine derartig angeschlossene Datenbank nicht von dem Zugriff auf eine
lokale Datenbank unterscheidet, indem es den für den externen Zugriff benötigten Overhead (z.B. Kommunikation, Authentifizierung usw.) übernimmt.
Die Eingabe von Anweisungen und das Anzeigen von Ergebnissen geschieht
über ein Frontend, das als Schnittstelle zum Benutzer oder anderen Anwendungen fungiert. Anweisungen werden von einem Parser analysiert und bei
erfolgreicher Überprüfung der Syntax in eine interne Repräsentation umgewandelt. Diese wird an die Ausführungskomponente zur Auswertung der Anweisung
übergeben.
Die Ausführungskomponente erzeugt Anweisungen in dem SQL-Dialekt des
zugrundeliegenden Datenbankmanagementsystems. Mit diesen wird auf Informationen aus den verfügbaren Komponentendatenbanken und der Arbeitsdatenbank zugegriffen, Metadaten aus einem sogenannten Komponentendatenbankkatalog (siehe Abschnitt 5.2) abgefragt oder neue Datenbankobjekte wie
Tabellen, Sichten und Prozeduren erzeugt. Aus den erhaltenen Ergebnissen
muss die Ausführungskomponente eventuell weitere Anweisungen generieren
um die über die Benutzerschnittstelle eingegebene Anweisung vollständig auszuführen. Die Ergebnisse der Anweisung werden an das Frontend übergeben,
das diese geeignet darstellt.
62
5.2 Der Komponentendatenbankkatalog
5.2
Der Komponentendatenbankkatalog
Die Beantwortung von SQLSF-Anfragen erfordert die implizite Verwendung
von in der Arbeitsdatenbank gespeicherten Informationen, wie beispielsweise
Umrechnungstabellen für Attributwerte oder Zuordnungen von Datenobjekten.
Da diese zusätzlichen Daten nicht direkt in der Anfrage referenziert werden,
benötigt der Anfrageprozessor Metadaten, die derartige Informationen zur Integration der Komponentendatenbanken beschreiben. Diese Metadaten werden
in der Arbeitsdatenbank strukturiert nach dem Schema in Abbildung 5.2 vor-
ComponentDB
1
1
+Name {pk}
+Schema
+Wrapper
+ObjectIDColumn
+ObjectGeometryColumn
isLeftCDB
isRightCDB
*
*
ComponentDBLink
leftAggregatedObjects
1
rightAggregatedObjects
1
+Name {pk}
1
1
1
1
0..1
0..1
LinkTable
Links
ObjectLinks
+Name {pk}
+LeftAggregatedIDColumn
+RightAggregatedIDColumn
ObjectLinkTable
+Name {pk}
+LeftObjectIDColumn
+RightObjectIDColumn
belongsToLink
referencePoints
*
0..1
AttributeTransitionTable
ReferencePointsTable
+Name {pk}
+LeftValueColumn
+RightValueColumn
+LeftReferencedColumn
+RightReferencedColumn
+LeftDefaultValue
+RightDefaultValue
+Name {pk}
+RSParameter
+LeftXColumn
+LeftYColumn
+RightXColumn
+RightYColumn
AggregatedObjectTable
0..1
0..1
+Name {pk}
+AggregatedIDColumn
+ObjectIDColumn
Abbildung 5.2: Das Schema des Komponentendatenbankkatalogs
63
Entwurf des Anfragesystems
gehalten und als Komponentendatenbankkatalog bezeichnet. Dieser Katalog
muss beim Erstellen einer Föderation mit Informationen gefüllt werden, wozu SQLSF entsprechende Anweisungen zur Verfügung stellt, die im Folgenden
anhand von Beispielen vorgestellt werden.
In der Relation ComponentDB werden die an der Föderation beteiligten Komponentendatenbanken verzeichnet. Die Beschreibung enthält den Namen der
Komponentendatenbank, über den diese eindeutig identifiziert ist, das Schema, in dem die Tabellen der Komponentendatenbank liegen, und den Namen
eines Datenbankwrappers, sofern sich die Komponentendatenbank in einem
anderen System befindet.
Es wird hier vorausgesetzt, dass für Objekte in einer Komponentendatenbank
eindeutige Identifikatoren existieren. Der Name des entsprechenden Identifikator- und des Geometrieattributs können ebenfalls im Katalog gespeichert werden. Dabei dürfen die Objekte auf mehrere Relationen aufgeteilt sein, wobei allerdings das Identifikator- und das Geometrieattribut in allen Relationen gleich
benannt sein muss.
Beispiel 5.1 zeigt, wie eine Komponentendatenbank unter dem Namen cdbA
mit der entsprechenden Register-Anweisung im Komponentendatenbankkatalog registriert und mit der Unregister-Anweisung dieser Eintrag entfernt wird.
Schema A:
REGISTER ComponentDB cdbA AS
Schema = A,
ObjectIDColumn = oid,
ObjectGeometryColumn = geometrie
UNREGISTER ComponentDB cdbA
oid
321
322
323
324
Objekt
objektart geometrie
Straße
Siedlung
Straße
Straße
Beispiel 5.1: Registrierung einer Komponentendatenbank
Die Komponentendatenbanklinks zur Integration von jeweils zwei Komponentendatenbanken werden in der Relation ComponentDBLink gespeichert. Ein solcher Link wird eindeutig über einen Namen identifiziert und besitzt implizit
eine Richtung, die dadurch gegeben ist, dass eine linke und eine rechte Komponentendatenbank verbunden wird. Einem Komponentendatenbanklink können
verschiedene Tabellen mit Informationen zur Integration der Komponentendatenbanken zugeordnet sein. Im einzelnen sind dies jeweils eine Aggregierungstabelle für die linke und rechte Komponentendatenbank, eine Linktabelle, eine
Objektlinktabelle, eine Tabelle mit Passpunkten und beliebig viele Ersetzungstabellen für Standardattribute.
64
5.2 Der Komponentendatenbankkatalog
Beispiel 5.2 zeigt das Einrichten eines Komponentendatenbanklinks mit dem
Namen cdbA cdbB zum Verbinden der Komponentendatenbanken cdbA und
cdbB. Mit der zugehörigen Unregister-Anweisung kann dieser Link wieder entfernt werden.
REGISTER ComponentDBLink cdbA_cdbB
FOR cdbA AND cdbB
UNREGISTER ComponentDBLink cdbA_cdbB
Beispiel 5.2: Registrierung eines Komponentendatenbanklinks
Die Relation AggregatedObjectTable beschreibt Aggregierungstabellen in der
Arbeitsdatenbank der Föderation, wobei diese über den Tabellennamen identifiziert werden. Weiterhin werden die Namen des Aggregierungsidentifikatorund des Identifikatorattributs als Werte der Attribute AggregatedIDColumn
und ObjectIDColumn abgespeichert. In Beispiel 5.3 wird beispielhaft eine Aggregierungstabelle registriert und der Eintrag wieder entfernt.
REGISTER AggregatedObjectTable AggregationA
FOR LEFT LINK cdbA_cdbB AS
AggregatedIDColumn = aggID,
ObjectIDColumn = oid
UNREGISTER AggregatedObjectTable AggregationA
AggregationA
oid
aggID
321
81
322
82
323
81
324
81
Beispiel 5.3: Registrierung einer Aggregierungstabelle
In der Relation LinkTable sind Linktabellen in der Arbeitsdatenbank der
Föderation verzeichnet. Neben dem Namen der Tabelle umfasst die Beschreibung die Namen der Aggregierungsidentifikatorattribute als Werte des Attributs LeftAggregatedIDColumn bzw. RightAggregatedIDColumn. Beispiel 5.4
zeigt die Registrierung einer Linktabelle für den Komponentendatenbanklink
cdbA cdbB und die Entfernung des Eintrags.
REGISTER LinkTable LinkAB
FOR LINK cdbA_cdbB AS
LeftAggregatedIDColumn = aid,
RightAggregatedIDColumn = bid
LinkAB
aid bid
81
12
82
11
UNREGISTER LinkTable LinkAB
Beispiel 5.4: Registrierung einer Zuordnungstabelle für aggregierte Objekte
Die Relation ObjectLinkTable beschreibt Objektlinktabellen in der Arbeitsdatenbank der Föderation. Dazu ist der Name der jeweiligen Tabelle sowie die
65
Entwurf des Anfragesystems
Namen der Identifikatorattribute als Werte der Attribute LeftObjectIDColumn
und RightObjectIDColumn abgespeichert. Die Registrierung einer Objektlinktabelle für den Komponentendatenbanklink cdbA cdbB und das Entfernen dieses Eintrags wird in Beispiel 5.5 vorgeführt.
REGISTER ObjectLinkTable ObjectLinkAB
FOR LINK cdbA_cdbB AS
LeftObjectIDColumn = aid,
RightObjectIDColumn = bid
UNREGISTER ObjectLinkTable ObjectLinkAB
ObjektLinkAB
aid
bid
321
562
322
561
322
563
323
562
Beispiel 5.5: Registrierung einer Zuordnungstabelle für einzelne Objekte
Tabellen mit Passpunkten sind in der Relation ReferencePointsTable verzeichnet und ebenfalls über den Namen identifiziert. Solche Tabellen müssen
mindestens vier Spalten für die x- und y-Koordinaten eines Punktepaars besitzen. Die Attribute LeftXColumn, LeftYColumn, RightXColumn und RightYColumn enthalten die Namen dieser Spalten. Das Attribut RSParameter gibt
den Wert für die Stärke der Verzerrung an, mit dem das Rubber-SheetingVerfahren bei Verwendung der jeweiligen Passpunktabelle parametrisiert wird.
In Beispiel 5.6 wird gezeigt, wie eine Passpunktabelle im Komponentendatenbankkatalog registriert und der Eintrag entfernt wird.
REGISTER ReferencePointsTable ReferencePointsAB
FOR LINK cdbA_cdbB AS
RSParameter = 2,
ReferencePointsAB
LeftXColumn = xA,
xA
yA
xB
yB
52.32
44.21
50.79 43.25
LeftYColumn = yA,
364.22 15.37 389.36 15.68
RightXColumn = xB,
81.32 103.28 72.74 96.05
RightYColumn = yB
UNREGISTER ReferencePointsTable ReferencePointsAB
Beispiel 5.6: Registrierung einer Zuordnungstabelle für einzelne Objekte
Die Relation AttributeTransitionTable beschreibt Ersetzungstabellen für
Attributwerte. Primärschlüssel dieser Relation ist der Name der Ersetzungstabelle. Die Attribute LeftReferencedColumn und RightReferencedColumn
enthalten den Namen des umzurechnenden Attributs in der linken bzw. rechten
Komponentendatenbank und die Attribute LeftValueColumn und RightValueColumn die Namen der Werteattribute. Defaultwerte in der linken bzw. rechten
Komponentendatenbank werden durch die Attribute LeftDefaultValue und
RightDefaultValue vorgegeben. Die Registrierung einer Ersetzungstabelle für
Attributwerte ist in Beispiel 5.7 dargestellt.
66
5.3 Übersetzen von SQLSF-Anweisungen
REGISTER AttributeTransitionTable ObjektartTransitionAB
FOR LINK cdbA_cdbB AS
LeftValueColumn = objektartA,
ObjektartTransitionAB
RightValueColumn = objektartB,
objektartA
objektartB
LeftReferencedColumn = objektart,
Landstraße
3105
RightReferencedColumn = objektart,
Gewerbegebiet
2013
LeftDefaultValue = ’sonstiges’,
Siedlung
2203
RightDefaultValue = 9999
UNREGISTER AttributeTransitionTable ObjektartTransitionAB
Beispiel 5.7: Registrierung einer Ersetzungstabelle für Attributwerte
5.3
Übersetzen von SQLSF-Anweisungen
Eine Anforderung beim Entwurf der Anfragesprache ist, dass sich die SQLSFAnweisungen in Standard-SQL-Anweisungen umwandeln lassen. Dies erlaubt
eine einfache Realisierung des Anfragesystems und ermöglicht es dem Optimierer des verwendeten Datenbanksystems effiziente Zugriffspfade für die in der
Anfrage referenzierten Daten zu bestimmen. Außerdem können auf diese Weise
durch SQLSF-Anweisungen SQL-Sichten erzeugt werden.
Wie die in Kapitel 4 eingeführten Erweiterungen in gewöhnliche SQL-Anfragen
übersetzt werden können, ist in den folgenden Unterabschnitten beschrieben.
Die vorgestellten Verfahren sind als Anleitung zur Implementierung von Algorithmen zu verstehen, die auf geeigneten Datenstrukturen zur systeminternen
Repräsentation der Anfragen die einzelnen Schritte umsetzen. Weiterhin sind
Bedingungen angegeben, die man bei der Formulierung von Anweisungen beachten muss, damit diese Verfahren korrekte Ergebnisse liefern.
5.3.1
Attributtransformation
Die Übersetzung von Anfragen mit Transform-Klausel hängt davon ab, ob diese Klausel auf ein Standard- oder geometrisches Attribut angewendet wird. Im
ersten Fall muss die zu verwendende Ersetzungstabelle bestimmt und in der Anfrage eingesetzt werden, im zweiten Fall ist eine Rubber-Sheeting-Implementierung mit entsprechender Passpunktabelle und Parameter aufzurufen.
Anwendung von Ersetzungstabellen
1. Bestimme für den in der Using-Link-Klausel angegebenen Komponentendatenbanklink die Ersetzungstabelle, durch die das zu transformierende
67
Entwurf des Anfragesystems
Attribut auf der in der Anfrage angegebenen Seite des Links referenziert
wird. Bestimme zu dieser Ersetzungstabelle weiterhin die Namen ihrer
Werteattribute und den für die andere Komponentendatenbank angegebenen Default-Wert. Diese Daten erhält man durch eine entsprechende
Anfrage an den Komponentendatenbankkatalog.
2. Füge hinter der From-Klausel eine Left-Outer-Join-Klausel mit dem Namen der Ersetzungstabelle ein. Konstruiere zu dieser Klausel eine JoinBedingung, die das zu transformierende Attribut mit dem Werteattribut,
das der in der Using-Link-Klausel angegebenen Seite des Komponentendatenbanklinks entspricht, vergleicht. Stelle dabei den Attributnamen
den Namen oder Tupelalias der zu transformierenden Relation bzw. den
Namen der Ersetzungstabelle voran.
3. Ersetze die gesamte Transform-Klausel durch den Aufruf einer NVLFunktion2 . Die Parameter sind der Name des Werteattributs, das nicht
der in der Using-Link-Klausel angegebenen Seite entspricht, wobei diesem der Name der Ersetzungstabelle vorangestellt werden muss, und der
zugehörige Default-Wert.
Anwendung von Passpunkttabellen
1. Bestimme für den in der Using-Link-Klausel angegebenen Komponentendatenbanklink die zugehörige Passpunkttabelle, die Namen ihrer Spalten
und den zugehörigen Parameter durch eine Anfrage an den Komponentendatenbankkatalog.
2. Ersetze die Transform-Klausel durch den Aufruf einer Funktion, die das
Rubber Sheeting implementiert. Als Parameter sind dieser Funktion das
zu transformierende Attribut, der Name der Passpunkttabelle, die Namen ihrer Spalten sowie der zu verwendende Parameterwert zu übergeben. Enthält die Transform-Klausel das Schlüsselwort RIGHT, muss die
Reihenfolge der Spalten vertauscht werden, um das Rubber Sheeting in
die entgegengesetzte Richtung anzuwenden.
Bemerkungen
• Enthält die From-Klausel bei der Umrechnung eines Standardattributs
mehrere Einträge, so muss dem in der Transform-Klausel referenzierten
Attribut der Tabellenname oder Tupelalias vorangestellt werden. Das
2
Diese Oracle-spezifische Funktion erhält zwei Parameter und gibt als Ergebnis den Wert
des ersten zurück, falls dieser kein Nullwert ist. Ansonsten wird der Wert des zweiten Parameters zurückgegeben.
68
5.3 Übersetzen von SQLSF-Anweisungen
Anfragesystem kann sonst beim Konstruieren der Vergleichsbedingung
nicht entscheiden, aus welcher Relation das Attribut stammt.
• Das Hinzufügen des Tabellennamens oder Tupelalias zu den Attributen
ist notwendig, da eine Spalte in der umzurechnenden Relation und ein
Werteattribut gleich benannt sein könnten.
• Durch die Verwendung eines Outer-Joins in Schritt 3 werden nicht in der
Ersetzungstabelle auftretende Werte zunächst in einen Nullwert transformiert. Die NVL-Funktion ersetzt diesen durch den Default-Wert.
Beispiel
Datenbank A:
oid
321
322
323
324
Arbeitsdatenbank:
ObjektartTransitionAB
objektartA
objektartB
Landstraße
3105
Gewerbegebiet
2013
Siedlung
2203
Objekt
objektart geometrie
Straße
Siedlung
Straße
Straße
xA
52.32
364.22
81.32
ReferencePointsAB
yA
xB
yB
44.21
50.79 43.25
15.37 389.36 15.68
103.28 72.74 96.05
Abbildung 5.3: Beispieldatenbanken zur Attributtransformation
Die Anfrage in Beispiel 5.8 transformiert die Attribute objektart und geometrie der Relation Objekt in der Datenbank A in Abbildung 5.3 mittels der
Ersetzungstabelle AttributTransitionAB und der Passpunkte in der Tabelle
ReferencePointsAB. Dabei wird ausgenutzt, dass diese Tabellen als Bestandteile des Komponentendatenbanklinks cdbA cdbB registriert sind und folglich
nicht explizit in der Anfrage referenziert werden müssen.
SELECT oid,
TRANSFORM objektart USING LEFT LINK cdbA_cdbB,
TRANSFORM geometrie USING LEFT LINK cdbA_cdbB
FROM A.Objekt
Beispiel 5.8: Beispiel zur Übersetzung von Transform-Klauseln
Zur Übersetzung der ersten Transform-Klausel muss zunächst die Anfrage in
Beispiel 5.9 an den Komponentendatenbankkatalog gestellt werden. Diese liefert den Namen der für das zu transformierende Attribut registrierten Ersetzungstabelle, den Namen des linken und rechten Werteattributs sowie den
69
Entwurf des Anfragesystems
Default-Wert des zu transformierenden Attributs in der rechten Komponentendatenbank.
SELECT AttributeTransitionTable.Name,
AttributeTransitionTable.LeftValueColumn,
AttributeTransitionTable.RightValueColumn,
AttributeTransitionTable.RightDefaultValue
FROM AttributeTransitionTable
WHERE AttributeTransitionTable.Link = ’cdbA_cdbB’
AND AttributeTransitionTable.LeftReferencedColumn = ’objektart’
Beispiel 5.9: Anfrage an den Komponentendatenbankkatalog
Um die zweite Transform-Klausel zu übersetzen werden durch eine Anfrage
an den Komponentendatenbankkatalog (siehe Beispiel 5.10) die Namen der zu
benutzenden Passpunktabelle und ihrer Spalten sowie der Wert des für diese
Transformation registrierten Parameters bestimmt.
SELECT ReferencePointsTable.Name,
ReferencePointsTable.RSParameter,
ReferencePointsTable.LeftXColumn,
ReferencePointsTable.LeftYColumn,
ReferencePointsTable.RightXColumn,
ReferencePointsTable.RightYColumn
FROM ReferencePointsTable, ComponentDBLink
WHERE ReferencePointsTable.Name
= ComponentDBLink.ReferencePoints
AND ComponentDBLink.Name = ’cdbA_cdbB’
Beispiel 5.10: Anfrage an den Komponentendatenbankkatalog
Mit den oben bestimmten Werten kann jetzt die ursprüngliche Anfrage übersetzt werden, was zu dem in Beispiel 5.11 gezeigten Ergebnis führt. Dazu wird
zunächst eine Vergleichsbedingung mit dem Attribut objektartA der Ersetzungstabelle ObjektartTransitionAB und dem Attribut objektart aus der
Relation Objekt gebildet. Anschließend wird der ursprünglichen Anfrage eine
Left-Outer-Join-Klausel mit der Ersetzungstabelle und der soeben konstruierten Bedingung hinzugefügt.
An dieser Stelle würde man durch Ersetzen der ersten Tranform-Klausel durch
das Attribut objektartB der Ersetzungstabelle die ersetzten Attributwerte
sowie Nullwerte, falls bestimmte Attributwerte nicht ersetzt werden können,
erhalten. Die NVL-Funktion ersetzt diese Nullwerte durch den für diese Transformation spezifizierten Default-Wert.
70
5.3 Übersetzen von SQLSF-Anweisungen
Die zweite Transform-Klausel wird durch eine Funktion ersetzt, die das Rubber
Sheeting implementiert. Diese wird auf das Geometrie-Attribut der ObjektRelation angewendet und mit den oben bestimmten Namen der Passpunkttabelle und ihrer Spalten sowie dem oben bestimmten Wert parametrisiert. Wäre
die ersetzte Transform-Klausel mit dem Schlüsselwort RIGHT gebildet worden,
so hätte die Reihenfolge der A- und B-Spalten vertauscht werden müssen, um
eine Transformation der Geometrien aus B zu realisieren. Die übersetzte Anfrage wird in Beispiel 5.11 gezeigt.
SELECT oid,
NVL(ObjektartTransitionAB.objektartB, 9999),
RubberSheeting(geometrie, ’RerefencePointsAB’,
’xA’, ’yA’, ’xB’, ’yB’, 2)
FROM A.Objekt
LEFT OUTER JOIN ObjektartTransitionAB
ON ObjektartTransitionAB.objektartA = Objekt.objektart
Beispiel 5.11: Übersetzte Anfrage
5.3.2
Aggregation
Das Zusammenfassen von Attributwerten zu einem Array, das diese Werte
als Elemente enthält, wird erreicht, indem die SQLSF-Anfrage mit AggregateKlausel in eine äquivalente SQL-Anfrage mit Group-By-Klausel umgeformt
wird. Dabei müssen in der Select-Klausel passende Aggregierungsfunktionen
eingesetzt werden, die ein entsprechendes Array aus den gruppierten Werten eines bestimmten Datentyps erzeugen. Ist in der SQLSF-Anfrage die AggregateKlausel mit einer Using-Link-Klausel kombiniert, so muss die Anfrage zunächst
um eine Join-Klausel ergänzt werden, die einen Verbund mit der passenden Aggregierungstabelle herstellt.
Somit läuft die Übersetzung einer Anfrage mit Aggregate-Klausel in zwei Phasen ab, wobei die erste übersprungen wird, falls in der Aggregate-Klausel bereits
die Liste der Attribute angegeben ist, nach denen gruppiert werden muss (siehe
Abschnitt 4.3.1).
Phase I: Einfügen der Aggregierungstabelle
1. Bestimme für den in der Using-Link-Klausel angegebenen Komponentendatenbanklink und die angegebene Seite (links oder rechts) den Namen der entsprechenden Aggregierungstabelle, die Namen ihres Aggregierungsidentifikator- und Identifikatorattributs sowie den Namen des Identifikatorattributs in der Komponentendatenbank, die die zu aggregierende
71
Entwurf des Anfragesystems
Relation enthält, durch eine Anfrage an den Komponentendatenbankkatalog.
2. Füge vor der Aggregate-Klausel eine Join-Klausel mit dem Namen der
Aggregierungstabelle ein. Konstruiere zu dieser Klausel eine Join-Bedingung, die die Identifikatorattribute der zu aggregierenden Relation und
der Aggregierungstabelle vergleicht. Dabei muss den Attributnamen der
Tabellenname oder Tupelalias vorangestellt werden.
3. Ersetze in der Aggregate-Klausel die Using-Link-Klausel durch das Schlüsselwort BY gefolgt von dem Namen des Aggregierungsidentifikatorattributs mit vorangestelltem Namen der Aggregierungstabelle.
4. Füge das in Schritt 3 eingesetzte Attribut mit dem Tabellennamen auch
als zusätzlichen Eintrag in die Select-Klausel ein.
Phase II: Einfügen der Gruppierung
1. Bestimme die Attribute, die in der Select-Klausel aber nicht in der Aggregate-Klausel der ursprünglichen Anfrage referenziert werden, sowie die
Datentypen dieser Attribute.
2. Ersetze in der Select-Klausel der ursprünglichen Anfrage jedes in Schritt 1
erhaltene Attribut durch den Aufruf einer Aggregierungsfunktion, die
Elemente des Datentyps dieses Attributs zu einem Array zusammenfasst,
mit diesem Attribut als Argument.
3. Ersetze die Aggregate-Klausel durch eine Group-By-Klausel mit derselben Attributliste.
Bemerkungen
• Bei mehreren Einträgen in der From-Klausel muss die Relation, die das
Identifikatorattribut enthält, als letztes angegeben sein. Es könnten theoretisch mehrere dieser Relationen ein Attribut mit demselben Namen wie
das Identifikatorattribut enthalten. In diesem Fall muss trotzdem eine Relation festgelegt sein, mit der die Aggregierungstabelle verbunden wird.
Daher wird standardmäßig die letzte Relation für den Verbund verwendet.
• Das Hinzufügen des Tabellennamens oder Tupelalias zu den Attributen
ist notwendig, da eine Spalte in der zu aggregierenden Relation und ein
Attribut der Aggregierungstabelle gleich benannt sein könnten. Wird ein
solches Attribut in der Select-Klausel referenziert, muss diesem bereits
bei der Formulierung der Anfrage der Name der Relation vorangestellt
werden.
72
5.3 Übersetzen von SQLSF-Anweisungen
Beispiel
Datenbank A:
oid
321
322
323
324
Arbeitsdatenbank:
Objekt
objektart geometrie
Straße
Siedlung
Straße
Straße
AggregationA
oid
aggID
321
81
322
82
323
81
324
81
Abbildung 5.4: Beispieldatenbanken zur Aggregation
Die Anfrage in Beispiel 5.12 aggregiert die Objekte in der Datenbank A in
Abbildung 5.4. Die Aggregierungstabelle AggregationA wurde für den Komponentendatenbanklink cdbA cdbB registriert, der diese Datenbank mit einer
anderen verbindet.
SELECT objektart, geometrie
FROM A.Objekt
AGGREGATE USING LEFT LINK cdbA_cdbB
Beispiel 5.12: Beispielanfrage mit Aggregate-Klausel
Zunächst werden aus dem Komponentendatenbankkatalog Informationen über
die der linken Datenbank zugeordnete Aggregierungstabelle abgefragt. Die dazu verwendete SQL-Anfrage ist in Beispiel 5.13 abgebildet. Diese liefert den Namen der linken Aggregierungstabelle, den Namen des Aggregierungsidentifikator- und Identifikatorattributs der Aggregierungstabelle und den Namen des
Identifikatorattributs in der linken Komponentendatenbank.
SELECT AggregatedObjectTable.Name,
AggregatedObjectTable.AggregatedIDColumn,
AggregatedObjectTable.ObjectIDColumn,
LeftCDB.ObjectIDColumn
FROM AggregatedObjectTable, ComponentDBLink,
ComponentDB LeftCDB
WHERE ComponentDBLink.LeftAggregatedObjects
= AggregatedObjectTable.Name
AND ComponentDBLink.LeftCDB = LeftCDB.Name
AND ComponentDBLink.Name = ’cdbA_cdbB’
Beispiel 5.13: Anfrage an den Komponentendatenbankkatalog
Diese Informationen werden in Phase I ausgenutzt, um eine Join-Klausel einzufügen, die die Relation Objekt mit der Aggregierungstabelle AggregationA
73
Entwurf des Anfragesystems
über die oid-Spalten verbindet. Weiterhin wird die Aggregate-Klausel ersetzt,
so dass anstelle der Using-Link-Klausel das Attribut aggID, nach dem gruppiert werden soll, direkt angegeben ist. Dieses Attribut wird auch in die SelectKlausel eingefügt. Das Zwischenergebnis nach Phase I ist in Beispiel 5.14 abgebildet.
SELECT AggregationA.aggID, objektart, geometrie
FROM A.Objekt
JOIN AggregationA ON AggregationA.oid = Objekt.oid
AGGREGATE BY AggregationA.aggID
Beispiel 5.14: Übersetzte Anfrage nach Phase I
In Phase II müssen die Attribute objektart und geometrie durch Aufrufe einer geeigneten Aggregierungsfunktion ersetzt werden. Außerdem wird die
Aggregate- durch eine Group-By-Klausel ausgetauscht, in der weiterhin das
Attribut aggID steht. Somit erhält man schließlich die übersetzte Anfrage in
Beispiel 5.15.
SELECT AggregationA.aggID,
aggregateString(objektart),
aggregateGeometry(geometrie)
FROM A.Objekt
JOIN AggregationA ON AggregationA.oid = Objekt.oid
GROUP BY AggregationA.aggID
Beispiel 5.15: Übersetzte Anfrage
5.3.3
Integrationsoperatoren
Zur Übersetzung von Anfragen mit erweiterter Join- bzw. Union-Klausel muss
man zunächst die Tabellen in der Arbeitsdatenbank durch eine Anfrage an
den Komponentendatenbankkatalog bestimmen, über die die zu integrierenden
Relationen verknüpft werden. Welche Tabellen verwendet werden, hängt davon
ab, welcher der folgenden vier Fälle eintritt.
In Abhängigkeit davon, ob man einen Verbund oder eine Vereinigung berechnen will, muss eine Verknüpfung der Objekte über die Tabellen der Arbeitsdatenbank durch Hinzufügen entsprechender Join- bzw. Outer-Join-Klauseln
hergestellt werden. Bei der Vereinigung müssen die zwei Attribute gleichen
Namens aus den unterschiedlichen Komponentendatenbanken noch zu einem
mehrwertigen Attribut zusammengefasst werden.
74
5.3 Übersetzen von SQLSF-Anweisungen
Fall 1
Es sollen einzelne Objekte aus beiden Komponentendatenbanken verknüpft
werden. Man benötigt die Objektlinktabelle ihre Identifikatorattribute und die
Identifikatorattribute in den zu verbindenden Komponentendatenbanken zum
angegebenen Komponentendatenbanklink.
1. Füge vor der erweiterten Operatorklausel eine Join-Klausel ein, die den
Namen der Objektlinktabelle enthält. Konstruiere zu dieser Klausel eine
Join-Bedingung, die die Identifikatorattribute der linken Komponentendatenbank und der Objektlinktabelle vergleicht.
2. Ersetze die Using-Link-Klausel durch eine On-Klausel. Konstruiere dazu
eine Join-Bedingung, die die Identifikatorattribute der Objektlinktabelle
und der rechten Komponentendatenbank vergleicht.
Fall 2
Es sollen aggregierte Objekte aus beiden Komponentendatenbanken verknüpft
werden. Man benötigt die Linktabelle, ihre Aggregierungsidentifikatorattribute und die Aggregierungsidentifikatorattribute der Komponentendatenbanken
zum angegebenen Komponentendatenbanklink.
1. Füge vor der erweiterten Operatorklausel eine Join-Klausel ein, die den
Namen der Linktabelle enthält. Konstruiere zu dieser Klausel eine JoinBedingung, die die Aggregierungsidentifikatorattribute der linken Komponentendatenbank und der Linktabelle vergleicht.
2. Ersetze die Using-Link-Klausel durch eine On-Klausel. Konstruiere dazu eine Join-Bedingung, die die Aggregierungsidentifikatorattribute der
Linktabelle und der rechten Komponentendatenbank vergleicht.
Fall 3
Es sollen aggregierte Objekte aus der linken mit einzelnen Objekten aus der
rechten Komponentendatenbank verknüpft werden. Man benötigt die Linktabelle, ihre Aggregierungsidentifikatorattribute, das Aggregierungsidentifikatorattribut der linken Komponentendatenbank, die linke Aggregationstabelle, ihr Aggregierungsidentifikator- und Identifikatorattribut und das Identifikatorattribut der rechten Komponentendatenbank zum angegebenen Komponentendatenbanklink.
1. Füge vor der erweiterten Operatorklausel eine Join-Klausel ein, die den
Namen der Linktabelle enthält. Konstruiere zu dieser Klausel eine JoinBedingung, die die Aggregierungsidentifikatorattribute der linken Komponentendatenbank und der Linktabelle vergleicht.
75
Entwurf des Anfragesystems
2. Füge vor der erweiterten Operatorklausel eine Join-Klausel ein, die den
Namen der rechten Aggregierungstabelle enthält. Konstruiere zu dieser
Klausel eine Join-Bedingung, die die Aggregierungsidentifikatorattribute
der Linktabelle und der rechten Aggregierungstabelle vergleicht.
3. Ersetze die Using-Link-Klausel durch eine On-Klausel. Konstruiere dazu
eine Join-Bedingung, die die Identifikatorattribute der rechten Aggregationstabelle und der rechten Komponentendatenbank vergleicht.
Fall 4
Es sollen einzelne Objekte aus der linken mit aggregierten Objekten aus der
rechten Komponentendatenbank verknüpft werden. Man benötigt die linke Aggregierungstabelle, ihre Aggregierungsidentifikator- und Identifikatorattribute,
das Identifikatorattribut der linken Komponentendatenbank, die Linktabelle
sowie die Aggregierungsidentifikatorattribute der Linktabelle und der rechten
Komponentendatenbank zum angegebenen Komponentendatenbanklink.
1. Füge vor der erweiterten Operatorklausel eine Join-Klausel ein, die den
Namen der linken Aggregierungstabelle enthält. Konstruiere zu dieser
Klausel eine Join-Bedingung, die die Identifikatorattribute der linken
Komponentendatenbank und der linken Aggregierungstabelle vergleicht.
2. Füge vor der erweiterten Operatorklausel eine Join-Klausel ein, die den
Namen der Linktabelle enthält. Konstruiere zu dieser Klausel eine JoinBedingung, die die Aggregierungsidentifikatorattribute der linken Aggregierungstabelle und der Linktabelle vergleicht.
3. Ersetze die Using-Link-Klausel durch eine On-Klausel. Konstruiere dazu eine Join-Bedingung, die die Aggregierungsidentifikatorattribute der
Linktabelle und der rechten Komponentendatenbank vergleicht.
Übersetzen der erweiterten Vereinigung
In den oben angegebenen Schritten für den jeweils eintretenden Fall müssen
Left-Outer-Join-Klauseln anstelle von Join-Klauseln eingefügt werden. Zusätzlich sind die folgenden Schritte auszuführen:
1. Ersetze den Union-Operator durch einen Outer-Join-Operator.
2. Ersetze jedes in der Select-Klausel referenzierte Attribut durch den Aufruf eines Array-Konstruktors3 für den Datentyp dieses Attributs. Setze
für beide zu vereinigenden Relationen das Attribut mit dem vorange3
Auf diese Art werden bei Oracle Arrays erstellt.
76
5.3 Übersetzen von SQLSF-Anweisungen
stellten Namen oder Tupelalias der Relation in die Parameterliste dieses
Konstruktors ein.
Bemerkungen
• Bei der Konstruktion der Join-Bedingungen muss den Attributen jeweils
der Name oder Tupelalias der Relation vorangestellt werden, um Mehrdeutigkeiten zu vermeiden, da Attribute in den zu verbindenden Relationen und den Tabellen in der Arbeitdatenbank gleich benannt sein könnten. Referenziert man ein solches Attribut in der Select-Klausel, muss
bei der Formulierung der Anfrage der Name der Relation vorangestellt
werden.
• Bei mehreren Einträgen in der From-Klausel muss die Relation, die das
Aggregierungsidentifikator- bzw. Identifikatorattribut enthält als letztes
angegeben sein. Das (Aggregierungs-)Identifikatorattribut dieser Relation wird standardmäßig für den Verbund mit den Tabellen der Arbeitsdatenbank verwendet.
• Bei der Verknüpfung einer Relation mit aggregierten Objekten muss das
Aggregierungsidentifikatorattribut dieser Relation den selben Namen besitzen, wie das der entsprechenden Aggregierungstabelle, da sonst kein
Verbund mit der Linktabelle hergestellt werden kann. Bildet man diese Relationen mit der in Abschnitt 4.3.2 vorgestellten Erweiterung ist
dies immer der Fall. Daher müssen auch die Namen der Aggregierungsidentifikatorattribute für die Komponentendatenbanken nicht registriert
werden.
Beispiel
aggID
81
82
83
Agg ObjektA
objektart geometrie
Straße
Siedlung
Straße
aggID
11
12
Agg ObjektB
objektart geometrie
Siedlung
Straße
Arbeitsdatenbank:
AggregationA
oid
aggID
321
81
322
82
323
81
324
83
AggregationB
oid
aggID
561
11
562
12
563
11
LinkAB
aid bid
81
12
82
11
Abbildung 5.5: Beispielrelationen zu Integrationsoperatoren
77
Entwurf des Anfragesystems
Die Anfrage in Beispiel 5.16 berechnet eine Vereinigung der Relationen aus
Abbildung 5.5, die aggregierte Objekte aus zwei über den Komponentendatenbanklink cdbA cdbB verbundenen Datenbanken enthalten. Für den Komponentendatenbanklink wurden die Aggregierungstabellen AggregationA und
AggregationB sowie die Linktabelle LinkAB registriert.
SELECT aggID, objektart, geometrie
FROM Agg_ObjektA
UNION Agg_ObjektB USING AGGREGATED LINK cdbA_cdbB
Beispiel 5.16: Anfrage mit erweitertem Union-Operator
Zunächst wird mittels der Anfrage an den Komponentendatenbankkatalog in
Beispiel 5.17 der Name der Linktabelle und die Namen der Aggregierungsidentifikatorattribute der Linktabelle und der Aggregierungstabellen bestimmt.
Letztere entsprechen den Aggregierungsidentifikatorattributen der zu vereinigenden Relationen.
SELECT LinkTable.Name,
LinkTable.LeftAggregatedIDColumn,
LinkTable.RightAggregatedIDColumn,
LeftAggregatedObjects.AggregatedIDColumn,
RightAggregatedObjects.AggregatedIDColumn
FROM LinkTable, ComponentDBLink
AggregatedObjectsTable LeftAggregatedObjects,
AggregatedObjectsTable RightAggregatedObjects
WHERE LinkTable.Name = ComponentDBLink.Links
AND ComponentDBLink.LeftAggregatedObjects
= LeftAggregatedObjects.Name
AND ComponentDBLink.RightAggregatedObjects
= RightAggregatedObjects.Name
AND ComponentDBLink.Name = ’cdbA_cdbB’
Beispiel 5.17: Anfrage an den Komponentendatenbankkatalog
In die ursprüngliche Anfrage in Beispiel 5.16 wird eine Left-Outer-Join-Klausel
mit der Relation LinkAB und passender Join-Bedingung eingefügt. Der UnionOperator wird durch einen Outer-Join-Operator und die Using-Link-Klausel
durch eine On-Klausel mit geeigneter Join-Bedingung ersetzt. Es werden die
Attribute in der Select-Klausel verdoppelt und jeweils der Tupelalias von einer der Ursprungsrelationen vorangestellt. Auf jedes gleichnamige Attributpaar
wird dann ein zu dem Typ dieser Attribute passender Array-Konstruktor angewendet. Beispiel 5.18 zeigt die übersetzte Anfrage.
78
5.3 Übersetzen von SQLSF-Anweisungen
SELECT ArrayOfNumber(o1.aggID, o2.aggID),
ArrayOfString(o1.objektart, o2.objektart),
ArrayOfGeometry(o1.geometrie, o2.geometrie)
FROM A.Objekt o1
LEFT OUTER JOIN LinkAB ON o1.oid = LinkAB.aid
OUTER JOIN B.Objekt o2 ON ObjektLinkAB.bid = o2.oid
Beispiel 5.18: Übersetzte Anfrage
5.3.4
Substitution
Da in den Veröffentlichungen zu FraQL kein Algorithmus zum Bearbeiten
von Substitutionsoperatoren gefunden wurde, wird hier ein selbst entwickeltes Verfahren vorgestellt, das sich an den Algortihmen zum Bearbeiten von
SchemaSQL-Anweisungen orientiert. Dieses Verfahren läuft in zwei Phasen ab.
In der ersten Phase wird zu der ursprünglichen Anfrage eine weitere Anfrage konstruiert, deren Ergebnisse die Werte darstellen, die für die zu substituierenden Ausdrücke einzusetzen sind. Diese Anfrage wird im Folgenden als
Instanzierungsanfrage und das zugehörige Ergebnis als Instanzierungstabelle
bezeichnet.
In der zweiten Phase wird für jede Zeile der Instanzierungstabelle aus der
ursprünglichen Anfrage eine substituierte Anfrage konstruiert, indem die zu
substituierenden Ausdrücke durch die Werte in dieser Zeile ersetzt werden. Anschließend werden alle diese Anfragen zu einer Anfrage zusammengesetzt, die
das Ergebnis der ursprünglichen SQLSF-Anfrage berechnet. Eventuell können
bei einem Durchlauf der zwei Phasen nicht alle Substitutionsoperatoren aufgelöst werden. In diesem Fall muss der Algorithmus rekursiv auf die substituierten Anfragen angewendet werden.
Phase I: Konstruktion der Instanzierungsanfrage
1. Bestimme alle Einträge in der From-Klausel der ursprünglichen Anfrage, in denen kein Substitutionsoperator auftritt. Konstruiere mit diesen
Einträgen die From-Klausel der Instanzierungsanfrage.
2. Bestimme alle Ausdrücke, die in der ursprünglichen Anfrage innerhalb eines Substitutionsoperators auftreten und nur die Relationen aus Schritt 1
referenzieren. Konstruiere mit dem Schlüsselwort Distinct und diesen
Ausdrücken die Select-Klausel der Instanzierungsanfrage.
3. Bestimme alle mit dem And-Operator verbundenen Teilbedingungen in
der Where-Klausel der ursprünglichen Anfrage, die nur die Relationen
aus Schritt 1 referenzieren. Konstruiere mit diesen Teilbedingungen die
Where-Klausel der Instanzierungsanfrage.
79
Entwurf des Anfragesystems
4. Stelle die Instanzierungsanfrage an das Datenbanksystem.
Phase II: Substitution und Zusammensetzung
Für jede Zeile der Instanzierungstabelle:
1. Erstelle eine Kopie der ursprünglichen Anfrage.
2. Ersetze in der kopierten Anfrage die zu substituierenden Ausdrücke durch
die zugehörigen Werte in der aktuellen Zeile der Instanzierungstabelle.
3. Ergänze die Where-Klausel der substituierten Anfrage mit dem AndOperator um eine Bedingung der Form Ausdruck = ’Wert’ für jeden
substituierten Ausdruck.
4. Ergänze die Select-Klausel der substituierten Anfrage um einen Eintrag
der Form NULL AS Wert für jeden Wert in einer Spalte der Instanzierungstabelle, die zu einem substituierten Spaltenalias gehört. Die Werte
in der aktuellen Zeile sind davon allerdings ausgenommen.
5. Falls die substituierte Anfrage noch weitere Substitutionsoperatoren enthält,
wende den Algorithmus rekursiv auf diese Anfrage an.
Setze alle substituierten Anfragen mit dem Union-Operator zusammen.
Bemerkungen
• Substitutionsoperatoren in der Create-View-Klausel müssen vor den anderen Substitutionsoperatoren in einem eigenen Durchlauf des Verfahrens
ersetzt werden. In diesem Fall darf man die substituierten Create-ViewAnweisungen nicht zusammensetzten sondern muss diese einzeln bearbeiten.
• Innerhalb der Substitutionsoperatoren muss allen Verweisen auf ein Attribut der Name einer Tupelvariable oder Tabelle vorangestellt sein. Dieser wird benötigt, um in Phase I zu bestimmen, welche Einträge in der
From-Klausel innerhalb des Substitutionsoperators referenziert werden.
• Innerhalb der Where-Klausel ist allen Verweisen auf ein Attribut der Name einer Tupelvariable oder Tabelle voranzustellen. Dieser wird ebenfalls
benötigt, um in Phase I die referenzierten Relationen einer Teilbedingung
zu bestimmen.
• Die Bedingung in der Where-Klausel muss in konjunktiver Normalform
formuliert werden. Diese Voraussetzung muss erfüllt sein, damit die Bedingung innerhalb von Phase I in Teilbedingungen zerlegt werden kann.
80
5.3 Übersetzen von SQLSF-Anweisungen
• Jeder Ausdruck innerhalb eines Substitutionsoperators muss vom Datentyp Zeichenkette sein, damit aus den Ergebnissen die substituierte
Anfrage gebildet werden kann.
• Das zusätzliche Einfügen von Einträgen in der Select-Klausel bei der Substitution eines Spaltenalias ist notwendig, damit die Schemata der substituierten Anfragen kompatibel sind und diese mit dem Union-Operator
zusammengesetzt werden können.
• Der rekursive Aufruf des Verfahren in Schritt 5 von Phase II wird nur
benötigt, wenn ein Substitutionsoperator in der Create-View-Klausel mit
weiteren Substitutionsoperatoren kombiniert wird (siehe Beispiel 5.22)
oder wenn sich ein Attribut innerhalb eines Substitutionsoperators auf
einen Eintrag in der From-Klausel bezieht, der selbst noch einen Substitutionsoperator enthält. Die Formulierung von sinnvollen Anfragen zu
dem zweitem Fall ist allerdings schwierig und wird bei der in dieser Arbeit beschriebene Verwendung auch nicht benötigt. Daher wird hier nicht
weiter darauf eingegangen.
Beispiele
Im folgenden wird die Übersetzung von SQLSF-Anfragen mit Substitutionsoperatoren anhand zweier Beispiele verdeutlicht. Die Anfragen werden jeweils
an die Datenbanken in Abbildung 5.6 gestellt.
Die Anfrage in Beispiel 5.19 wandelt die Relationen in der Datenbank A in
die Darstellung in der Datenbank B um. Dazu müssen die Attributwerte aller
Attribute außer oid bestimmt und gemeinsam mit der Identifikationsnummer
und dem Attribut- sowie Tabellennamen in einer Zeile der Ergebnisrelation
dargestellt werden.
SELECT oid, t.name, c.name, $(c.name) AS wert
FROM Tables t, Columns c,
A.$(t.name)
WHERE c.table = t.name AND
t.schema = ’A’
AND
c.name <> ’oid’
Beispiel 5.19: Beispielanfrage zur Transformation von Metadaten in Daten
Zunächst muss die zu dieser Anfrage passende Instanzierungsanfrage bestimmt
werden. Da der dritte Eintrag in der From-Klausel einen Substitutionsoperator enthält, werden nur die ersten beiden Einträge in die From-Klausel der
Instanzierungsanfrage übernommen. Die Ausdrücke innerhalb der Substitutionsoperatoren beziehen sich auf die Relationen Columns und Tables und bilden
81
Entwurf des Anfragesystems
Datenbank A:
Straße
oid breite
zustand
1
15m
in Betrieb
oid
2
Schienenbahn
kategorie breite
S-Bahn
2m
Datenbank B:
oid
1
1
2
2
3
Attribut
tabelle
attribut
Straße
breite
Straße
zustand
Schienenbahn katagorie
Schienenbahn
breite
Flughafen
zustand
wert
15m
in Betrieb
S-Bahn
2m
im Bau
Flughafen
oid zustand
3
im Bau
Schemakatalog:
Tables
name
schema
Straße
A
Schienenbahn
A
Flughafen
A
Attribut
B
Columns
name
table
breite
Straße
zustand
Straße
kategorie Schienenbahn
...
...
Abbildung 5.6: Beispieldatenbanken
daher die Einträge in der Select-Klausel der Instanzierungsanfrage. Da auch
in beiden Teilbedingungen, die die Where-Klausel bilden, nur die selben zwei
Relationen referenziert werden, kann die gesamte Where-Klausel unverändert
übernommen werden. Beispiel 5.20 zeigt die fertige Instanzierungsanfrage und
das berechnete Ergebnis, die Instanzierungstabelle.
t.name
Straße
Straße
Schienenbahn
Schienenbahn
Flughafen
SELECT DISTINCT t.name, c.name
FROM tables t, columns c
WHERE c.table = t.name AND
t.schema = ’A’
AND
c.name <> ’oid’
c.name
breite
zustand
kategorie
breite
zustand
Beispiel 5.20: Instanzierungsanfrage und zugehörige Instanzierungstabelle
Da die Instanzierungstabelle fünf Zeilen enthält, müssen fünf Kopien der ursprünglichen Anfrage erzeugt werden, wobei in jeder die Substitutionsoperatoren durch die Werte in einer Zeile ersetzt werden. In der ersten kopierten Anfrage wird beispielsweise der Substitutionsoperator in der Select-Klausel durch
breite und der in der From-Klausel durch Straße ersetzt. Außerdem werden die entsprechenden Bedingungen in der Where-Klausel hinzugefügt. Alle
substituierten Anfragen werden schließlich mit Union-Operatoren zusammengesetzt. Ein Teil der übersetzten Anfrage ist in Beispiel 5.21 gezeigt, wobei die
bei der Substitution eingesetzten Teile rot hervorgehoben sind.
82
5.3 Übersetzen von SQLSF-Anweisungen
SELECT oid, t.name, c.name, breite AS wert
FROM tables t, columns c
A.Straße
WHERE c.table = t.name AND
t.schema = ’A’
c.name <> ’oid’ AND
c.name = ’breite’ AND
t.name = ’Straße’
UNION
SELECT oid, t.name, c.name, zustand AS wert
FROM tables t, columns c
A.Straße
WHERE c.table = t.name AND
t.schema = ’A’
c.name <> ’oid’ AND
c.name = ’zustand’ AND
t.name = ’Straße’
UNION ...
Beispiel 5.21: Übersetzte Anfrage
Die Anfrage in Beispiel 5.22 erzeugt bei Anwendung auf die Datenbank B in
Abbildung 5.6 Sichtrelationen, die mit den Werten des Attributs tabelle benannt sind. Aufgrund der Verwendung des Substitutionsoperators anstelle eines
Spaltenalias erhält jede Sicht Attribute, deren Namen den Werten in der Spalte
attribut entsprechen. Somit wird annähernd4 die Darstellung der Datenbank
A erzeugt.
CREATE VIEW $(a.tabelle) AS
SELECT oid, wert AS $(a.attribut)
FROM B.Attribut a
Beispiel 5.22: Beispielanfrage zur Transformation von Daten in Metadaten
Bei der Bearbeitung dieser Anfrage muss zunächst der Substitutionsoperator in
der Create-View-Klausel ersetzt werden. Dazu werden mit der Instanzierungsanfrage in Beispiel 5.23 die Werte des Attributs tabelle der Relation Attribut
bestimmt, so dass man die ebenfalls abgebildete Instanzierungstabelle erhält.
Da die Instanzierungstabelle drei Zeilen enthält, werden drei substituierte Anweisungen erzeugt. In jeder Anweisung wird der Substitutionsoperator in der
Create-View-Klausel durch einen Wert in der Instanzierungstabelle ersetzt und
4
Um die genaue Darstellung der Datenbank A zu erhalten, müssen noch Tupel mit gleichem Identifikator zusammengefasst werden (siehe Abschnitt 4.5.4).
83
Entwurf des Anfragesystems
tabelle
Straße
Schienenbahn
Flughafen
SELECT DISTINCT a.tabelle
FROM B.Attribut a
Beispiel 5.23: Instanzierungsanfrage zum Substitutionsoperator in der Create-View-Klausel
eine entsprechende Bedingung hinzugefügt (siehe Beispiel 5.24). Da es sich um
DDL-Anweisungen handelt, dürfen diese nicht mittels des Union-Operators
zusammengesetzt werden. Die Substitutionsoperatoren in der Select-Klausel
müssen durch rekursive Anwendung des Verfahrens auf die einzelnen Anweisungen bearbeitet werden.
CREATE VIEW Straße AS
SELECT oid, wert AS $(a.attribut)
FROM B.Attribut a
WHERE a.tabelle = ’Straße’
CREATE VIEW Schienenbahn AS
SELECT oid, wert AS $(a.attribut)
FROM B.Attribut a
WHERE a.tabelle = ’Schienenbahn’
CREATE VIEW Flughafen AS
SELECT oid, wert AS $(a.attribut)
FROM B.Attribut a
WHERE a.tabelle = ’Flughafen’
Beispiel 5.24: Anweisungen nach Ersetzung des Substitutionsoperators in der Create-ViewKlausel
Im Folgenden wird nur die rekursive Bearbeitung der ersten Anweisung in
Beispiel 5.24 beschrieben. Diese enthält eine einschränkende Where-Klausel,
die für die Instanzierungsanfrage in Beispiel 5.25 übernommen wird. Somit
taucht ein Wert aus der Spalte attribut nur dann in der Instanzierungstabelle
auf, wenn der Wert des Attributs tabelle in der zugehörigen Zeile dem Wert
’Straße’ entspricht.
SELECT DISTINCT a.attribut
FROM B.Attribut a
WHERE a.tabelle = ’Straße’
attribut
breite
zustand
Beispiel 5.25: Instanzierungsanfrage zum Substitutionsoperator in der Select-Klausel
Für jeden Wert in der Instanzierungstabelle wird die Anfrage, mit der die Sicht
Straße gebildet wird, kopiert, wobei der Substitutionsoperator durch einen
84
5.3 Übersetzen von SQLSF-Anweisungen
Wert in der Instanzierungstabelle ersetzt und eine entsprechende Bedingung
hinzugefügt wird. Weiterhin muss beispielsweise beim Einsetzen des Wertes
breite für jeden weieteren Wert in der Instanzierungstabelle (hier nur der
Wert zustand, ein entsprechend benanntes Attribut mit dem Wert NULL in die
Select-Klausel eingefügt werden. Dadurch werden die Schemata der substituierten Anfragen angeglichen, so dass diese anschließend mit dem Union-Operator
zusammengesetzt werden können und man die übersetzte Anweisung in Beispiel 5.26 erhält.
CREATE VIEW Straße AS
SELECT oid, wert AS breite, NULL AS zustand
FROM B.Attribut a
WHERE a.tabelle = ’Straße’ AND
a.attribut = ’breite’
UNION
SELECT oid, NULL AS breite, wert AS zustand
FROM B.Attribut a
WHERE a.tabelle = ’Straße’ AND
a.attribut = ’zustand’
Beispiel 5.26: Übersetzte Anweisung
85
Kapitel 6
Methodik der Föderierung
räumlicher Daten
Der Anwendungsbereich der in Kapitel 4 entworfenen Sprache SQLSF ist es,
den Benutzer dabei zu unterstützen aus unterschiedlichen räumlichen Datenbeständen, die dasselbe geographische Gebiet beschreiben, einen föderierten
Datenbestand aufzubauen. Es wird hier angenommen, dass die Datenbestände
als Sammlungen von Relationen gegeben sind, auf die einheitlich über ein Datenbanksystem zugegriffen werden kann. Wie bereits in Kapitel 3 erläutert
wurde, können sich solche Datenbestände trotzdem stark unterscheiden.
Der folgende Abschnitt 6.1 schlägt eine Vorgehensweise zum Aufbau eines föderierten räumlichen Datenbestandes vor. Das Ziel dabei ist es, durch die Erstellung geeigneter Sichten ein globales Schema zu konstruieren, so dass man durch
Anfragen an diese Sichten Informationen in integrierter Form erhalten kann.
Es wird dabei schrittweise vorgegangen, wobei jeder Schritt durch die Sprache SQLSF unterstützt wird. Je nach der Beschaffenheit der zu integrierenden
Datenbanken kann es sinnvoll sein, die Reihenfolge dieser Schritte etwas zu
verändern, so dass die hier angegebene Abfolge nicht in jedem Fall optimal ist.
In Abschnitt 6.2 wird die hier vorgeschlagene Vorgehensweise zum Erstellen
einer Föderation mit Hilfe von SQLSF am Beispiel von zwei relativ einfachen
Datenbanken vorgeführt, für die durch Sichten ein globales Schema aufgebaut
wird, über das man mit gewöhnlichen SQL-Anfragen auf die integrierten Informationen aus den Datenbanken zugreifen kann.
86
6.1 Ablauf
6.1
Ablauf
1. Transformation in einheitliche Struktur
Zunächst löst man strukturelle Konflikte zwischen den Komponentendatenbanken auf, indem man mit den Möglichkeiten von SQLSF für beide Datenbanken
Sichten konstruiert, die eine strukturell einheitliche Darstellung der enthaltenen Informationen anbieten. Geschickterweise geht man dabei derart vor, dass
möglichst wenige Sichtrelationen erzeugt werden, die dennoch alle zu integrierenden Objekte enthalten. Eine starke Fragmentierung hat den Nachteil, dass
man in den folgenden Schritten jede Relation einzeln transformieren muss.
Selbst wenn keine strukturellen Konflikte zwischen den Komponentendatenbankschemata bestehen, kann es zur Föderierung der Datenbestände notwendig
sein, deren Struktur zu verändern. Beispielsweise erfordert es das in [ML04] beschriebene Verfahren zum Matching von Objekten, dass in jeder Komponentendatenbank eine Relation existiert, die zumindest einen Schlüssel, die Objektart
und die Geometrie aller modellierten Objekte enthält. Gewissermaßen besteht
also auch in diesem Fall ein struktureller Konflikt, sofern die zu föderierenden
Daten nicht bereits wie gefordert strukturiert sind.
2. Einrichten eines Komponentendatenbanklinks
Bevor man Anfragen an die integrierten Datenbestände stellen kann, müssen
die Komponentendatenbanken im Komponentendatenbankkatalog registriert
und Komponentendatenbanklinks zum Verknüpfen der Daten eingerichtet werden. Dies erreicht man über die entsprechenden SQLSF-Anweisungen zur Manipulation des Komponentendatenbankkatalogs (siehe Abschnitt 5.2).
Um diese Links tatsächlich verwenden zu können, müssen die benötigten Zusatzinformationen, wie Matching- oder Ersetzungstabellen, generiert und dem
entsprechenden Link zugeordnet werden. Sobald diese Daten in der Arbeitsdatenbank vorliegen, z.B. nach einem Import oder der erfolgreichen Durchführung
eines Matching-Verfahrens, können wiederum geeignete Manipulationsanweisungen verwendet werden, um die Tabellen als Bestandteile eines Komponentendatenbanklinks im Komponentendatenbankkatalog zu registrieren.
3. Umrechnen von Attributen
Zur Auflösung von Beschreibungskonflikten muss man sich zunächst für eine
einheitliche Darstellung entscheiden. Hier ist es sinnvoll, die Darstellung aus
einer der Komponentendatenbanken zu übernehmen, um sich die Umrechnung
von Objekten aus dieser Komponentendatenbank zu sparen. Für Umrechnungen, die sich nicht mit Hilfe der in Schritt 2 im Komponentendatenbankkatalog
87
Methodik der Föderierung räumlicher Daten
registrierten Tabellen durchführen lassen, müssen Umrechnungsfunktionen programmiert werden, sofern diese nicht bereits bei der Föderierung anderer Komponentendatenbanken angelegt wurden und wiederverwendet werden können.
4. Aggregieren von Objekten
Will man auf globaler Ebene mit aggregierten Objekten arbeiten, so empfielt
es sich, entsprechende Sichten vorzubereiten, die die Objekte in aggregierter
Form anbieten. Dabei kann man bereits Datenkonflikte auflösen, die dadurch
entstehen, dass einzelne Objekte mit unterschiedlichen Attributwerten zusammengefasst werden. Hat man sich für eine Strategie zum Auflösen dieser Datenkonflikte entschieden, muss man, sofern diese nicht bereits existieren, geeignete
Konfliktauflösungsfunktionen programmieren, die aus den mehrwertigen Attributwerten der aggregierten Objekte eindeutige Attributwerte berechnen.
Falls es die Anwendung erfordert, dass für unterschiedliche Anfragen Datenkonflikte auf unterschiedliche Art gelöst werden müssen, kann man auch mehrere
Sichten mit denselben aggregierten Objekten aber unterschiedlich berechneten
Attributwerten erstellen oder die Auflösung auf spätere Schritte verschieben.
5. Verknüpfen von Daten
In diesem Schritt verknüpft man die Objekte aus den Komponentendatenbanken mit den geeigneten Integrationsoperatoren. Hierbei muss man sich zunächst
entscheiden, ob man die Objekte im globalen Schema in verbundener oder
vereinigter Form benötigt. Will man beispielsweise Objekte aus einer Komponentendatenbank um Informationen ergänzen, die zugeordnete Objekte in
der anderen Komponentendatenbank beschreiben, bietet sich der Einsatz eines erweiterten Verbundoperators an. Möchte man lieber eine Sicht auf die
Gesamtheit der in den Komponentendatenbanken vorhandenen Objekte, setzt
man erweiterte Vereinigungsoperatoren ein.
Weiterhin ist für jede Komponentendatenbank zu entscheiden, ob man auf der
Föderierungsebene mit aggregierten oder einzelnen Objekten aus der Komponentendatenbank arbeiten will. In Abhängigkeit von dieser Entscheidung setzt
man zur Integration der Objekte aus jeweils zwei Komponentendatenbanken
die passende Variante des gewünschten Integrationsoperators ein.
Benutzt man einen Vereinigungsoperator zur Integration von Objekten aus zwei
Komponentendatenbanken, sind noch Datenkonflikte aufzulösen, was man wie
in Schritt 4 durch Anwendung passender Konfliktauflösungsfunktionen erreicht.
6. Erzeugen des globalen Schemas
Falls die in Schritt 5 erzeugten Sichten noch nicht bereits dem gewünschten
88
6.2 Anwendungsbeispiel
globalen Schema entsprechen, können noch weitere Transformationen darauf
angewendet werden. Beispielsweise kann es wünschenswert sein, zur besseren
Übersichtlichkeit die in Schritt 1 zusammengefassten Informationen durch eine
weitere strukturelle Transformation nach der Integration wieder zu fragmentieren, also ein globales Schema zu erzeugen, dass wieder aus mehr Relationen
besteht.
6.2
Anwendungsbeispiel
Im Folgenden wird der in Abschnitt 6.1 beschriebene Ablauf zum Erstellen
eines globalen Schemas an einem Beispiel vorgeführt. Es sollen die Datenbanken
in Abbildung 6.1, in denen Siedlungen modelliert sind, föderiert werden. Durch
Anfragen an das globale Schema soll man Informationen über alle in mindestens
einer der beiden Komponentendatenbanken modellierten Siedlungen erhalten
können. Dabei darf eine Siedlung im föderierten Datenbestand allerdings nur
durch ein Datenobjekt beschrieben sein. Das globale Schema soll strukturell
dem Schema der Datenbank A entsprechen, also aus jeweils einer Sichtrelation
für jede Siedlungsart bestehen.
Datenbank A:
Datenbank B:
ID
51
52
Wohngebiet
Einwohner Geometrie
312
228
ID
63
Industriegebiet
Einwohner Geometrie
26
ID
82
Gewerbegebiet
Einwohner Geometrie
102
ID
204
205
212
238
239
Funktion
2101
2101
2103
2108
2108
Siedlung
Einwohner
402
144
15
54
52
Geometrie
Abbildung 6.1: Beispieldatenbanken
Zunächst werden die Relationen aus der Datenbank A zu einer Relation zusammengefasst. Damit wird der strukturelle Unterschied, der zwischen den Komponentendatenbanken besteht, beseitigt. Außerdem hat dieses Vorgehen den
Vorteil, dass nach der Transformation nur noch jeweils eine Relation pro Komponentendatenbank zu integrieren ist. Als Metadatenquelle für die Namen der
Tabellen in der Datenbank A kann beispielsweise der Schemakatalog des Da89
Methodik der Föderierung räumlicher Daten
tenbanksystems verwendet werden, was im Beispiel 6.1 vereinfacht durch die
Relation Tables dargestellt ist.
CREATE VIEW SiedlungA AS
SELECT t.id, Tables.name AS funktion, einwohner, t.geometrie
FROM Tables, A.$(Tables.name) t
WHERE Tables.db = ’A’
ID
51
52
63
82
SiedlungA
Funktion
Einwohner
Wohngebiet
312
Wohngebiet
228
Industriegebiet
26
Gewerbegebiet
102
Geometrie
Beispiel 6.1: Zusammenfassen von Relationen
Anschließend können durch ein Matching der räumlichen Objekte Zuordnungen zwischen diesen berechnet werden. Die Ergebnisse werden in den Tabellen
AggregationA, AggregationB und LinkAB in der Arbeitsdatenbank abgespeichert. Weiterhin werden noch die Tabelle FunktionTransition zur Umrechnung des Funktion-Attributs und eine Passpunkttabelle in der Arbeitsdatenbank abgelegt (siehe Abbildung 6.2). Mit den in Abschnitt 5.2 vorgestellten
Anweisungen kann nun ein Komponentendatenbanklink, der hier mit A B benannt wird, erzeugt werden, dem man dann diese Tabellen zuordnet.
Arbeitsdatenbank:
FunktionTransition
funktionA
funktionB
Wohngebiet
2101
Industriegebiet
2103
Gewerbegebiet
2108
xA
52.32
64.22
81.32
Passpunkte
yA
xB
44.21 50.79
15.37 89.36
13.28 72.74
yB
43.25
15.68
14.05
AggregationA
oid
aggID
51
15
52
15
63
21
82
24
AggregationB
oid
aggID
204
3
205
3
212
8
238
11
239
11
LinkAB
aid bid
15
3
24
11
Abbildung 6.2: Tabellen mit Informationen zum Verlinken der Komponentendatenbanken
Als nächstes werden Beschreibungskonflikte aufgelöst. Es wird entschieden, die
Darstellung der Attributwerte aus der Komponentendatenbank A auf globaler
Ebene zu übernehmen, so dass nur die Attributwerte aus der Komponentendatenbank B umgerechnet werden müssen. Für das Attribut funktion kann
die Ersetzungstabelle FunktionTransition und zur Transformation der Geometrien die Passpunkte benutzt werden. Diese Umrechnungen werden in der
90
6.2 Anwendungsbeispiel
Sichtdefinition in Beispiel 6.2 durch Anwendung der Transform-Klausel auf die
entsprechenden Attribute realisiert. Da sich die Darstellung der Einwohnerzahl in den beiden Komponentendatenbanken nicht unterscheidet, muss das
Attribut einwohner nicht umgerechnet werden.
CREATE VIEW SiedlungB AS
SELECT id, TRANSFORM funktion USING LINK A_B,
einwohner,
TRANSFORM geometrie USING LINK A_B
FROM B.Siedlung
ID
204
205
212
238
239
SiedlungB
Funktion
Einwohner
Wohngebiet
402
Wohngebiet
144
Industriegebiet
15
Gewerbegebiet
54
Gewerbegebiet
52
Geometrie
Beispiel 6.2: Auflösung von Beschreibungskonflikten
Hätte man eindeutige Zuordnungen zwischen den räumlichen Objekten zur
Verfügung, könnte man an dieser Stelle die Objekte vereinigen. Da dies allerdings nicht zutrifft, werden zunächst für beide Komponentendatenbanken
Sichten mit aggregierten Objekten gebildet.
Dabei muss man sich überlegen, wie man mit Datenkonflikten umgeht, wenn
man mehrere Objekte mit jeweils eigenen Attributwerten zu einem aggregierten
Objekt zusammenfasst. In Beispiel 6.3 werden diese Konflikte bereits bei der
Aggregation durch Anwendung geeigneter Funktionen aufgelöst.
Zunächst sei angenommen, dass nur solche einzelnen Objekte zu einem aggregierten Objekt zusammengefasst werden, die denselben Wert für das Attribut
funktion besitzen1 . Daher kann ein bei der Aggregation gebildeter mehrwertiger Attributwert für dieses Attribut in einen eindeutigen Wert transformiert
werden, indem einfach das erste definierte Element des Arrays selektiert wird.
Die Datenkonflikte des Einwohner-Attributs werden sinnvollerweise durch Berechnung der Summe der Elemente eines mehrwertigen Attributwerts beseitigt.
Die Geometrien der einzelnen Objekte werden durch geometrische Vereinigung
zu Geometrien für aggregierte Objekte zusammengefasst.
1
Diese Annahme ist durchaus realistisch, wenn man sich vorstellt, dass während des Matchingprozesses das Attribut funktion als partitionierendes Kriterium zur Einteilung der
Objekte in Vergleichsmengen verwendet wird und nur Zuordnungen von Objekten aus korrespondierenden Mengen erzeugt werden. Ausführlicher sind solche Techniken beispielsweise
in [Man02] beschrieben.
91
Methodik der Föderierung räumlicher Daten
CREATE VIEW Agg_SiedlungA AS
SELECT firstOf(funktion) AS funktion,
sumOf(einwohner) AS einwohner,
spatialUnionOf(geometrie) AS geometrie
FROM SiedlungA
AGGREGATE USING LEFT LINK A_B
aggID
15
21
24
Agg SiedlungA
Funktion
Einwohner
Wohngebiet
540
Industriegebiet
26
102
Gewerbegebiet
Geometrie
CREATE VIEW Agg_SiedlungB AS
SELECT firstOf(funktion) AS funktion,
sumOf(einwohner) AS einwohner,
spatialUnionOf(geometrie) AS geometrie
FROM SiedlungB
AGGREGATE USING RIGHT LINK A_B
aggID
3
8
11
Agg SiedlungB
Funktion
Einwohner
Wohngebiet
546
Industriegebiet
15
Gewerbegebiet
106
Geometrie
Beispiel 6.3: Aggregieren von Objekten und Konfliktauflösung
Im nächsten Schritt können, wie in Beispiel 6.4 dargestellt wird, die aggregierten Objekte aus den unterschiedlichen Komponentendatenbanken zusammengefasst werden. Dabei treten wiederum Datenkonflikte auf, die durch mehrwertige Attribute repräsentiert sind und für die man sich geeignete Auflösungsstragien einfallen lassen muss.
Für das Attribut funktion wird entschieden, dass die Werte aus der Datenbank
A verlässlicher, und daher zu bevorzugen sind. Der Attributwert eines Objekts
aus der Datenbank B wird nur dann übernommen, wenn dieses Objekt keinem Objekt aus A zugeordnet ist. Datenkonflikte auf dem Einwohner-Attribut
werden beseitigt, indem der Durchschnitt der konkurrierenden Werte berechnet wird. Der aufgelöste Geometrie-Attributwert wird durch die geometrische
Durchschnittsoperation berechnet.
Schließlich muss aus der in Beispiel 6.4 gebildeten Sicht noch die für das globale Schema gewünschte Darstellung erzeugt werden. Dazu werden die Objekte
anhand des Attributs funktion auf unterschiedliche Sichtrelationen aufgeteilt.
92
6.2 Anwendungsbeispiel
CREATE VIEW SiedlungAB AS
SELECT preferLeftOf(funktion) AS funktion,
avgOf(einwohner) AS einwohner,
spatialIntersectionOf(geometrie) AS geometrie
FROM Agg_SiedlungA
UNION Agg_SiedlungB USING AGGREGATED LINK A_B
SiedlungAB
Funktion
Einwohner
Wohngebiet
543
Industriebegiet
26
Industriegebiet
15
Gewerbegebiet
104
Geometrie
Beispiel 6.4: Vereinigung der aggregierten Objekte und Auflösung von Datenkonflikten
Dabei wird an den Namen jeder gebildeten Sicht das Suffix AB angehängt, um
kenntlich zu machen, dass diese Relation aus der Integration der Datenbanken
A und B entstanden ist. Die entsprechende Anweisung und das fertige globale
Schema werden in Beispiel 6.5 gezeigt.
CREATE VIEW $(SiedlungAB.funktion || ’AB’) AS
SELECT einwohner, geometrie
FROM SiedlungAB
WohngebietAB
Einwohner Geometrie
543
IndustriegebietAB
Einwohner Geometrie
26
15
GewerbegebietAB
Einwohner Geometrie
104
Beispiel 6.5: Das globale Schema
93
Kapitel 7
Implementierung des
Prototypen
Das in Kapitel 5 entworfene System zur Realisierung von SQLSF wurde im
Rahmen dieser Arbeit prototypisch umgesetzt. Dazu wurden im wesentlichen
die Programmiersprache Java und Oracle 10g als Datenbankmanagementsystem verwendet. Diese Implementierung ist im Folgenden beschrieben.
Abschnitt 7.1 erläutert zunächst den allgemeinen Aufbau des Programms. In
Abschnitt 7.2 wird die Erzeugung eines SQLSF-Parsers und die programmintern benutzte Datenstruktur zur Darstellung der Anweisungen erläutert. Die
Implementierung des Komponentendatenbankkatalogs ist in Abschnitt 7.3 beschrieben und die der mehrwertigen Attribute durch Arrays in Abschnitt 7.4.
Schließlich erklärt Abschnitt 7.5 die Realisierung von Konfliktauflösungsfunktionen und gibt an, wie das System durch eigene Auflösungsmethoden erweitert
werden kann.
7.1
SQLSF*Plus
Um SQLSF-Anweisungen auf dem föderierten Datenbanksystem ausführen zu
können, wurde eine kommandozeilenbasierte Benutzerschnittstelle mit dem Namen SQLSF*Plus implementiert1 . Man startet das Programm mit dem Befehl:
sqlsfplus [ -debug ] <Benutzername>
1
Die Benennung orientiert sich an dem bekannten textbasierten Datenbankfrontend
SQL*Plus von Oracle, das als Vorbild für die in dieser Arbeit realisierte Schnittstelle verwendet wurde.
94
7.1 SQLSF*Plus
Nach erfolgreicher Authentifikation kann man SQLSF-Anweisungen, die jeweils
mit einem Semikolon abzuschließen sind, eingeben, woraufhin das Ergebnis der
Anweisung angezeigt wird. Wurde das Programm im Debug-Modus gestartet,
so werden zusätzlich die übersetzten SQL-Anweisungen angezeigt. Mit dem
Kommando exit beendet man das Programm.
Die Übersetzung von eingegebenen Anweisungen ist komplett in Java realisiert,
wobei für Zugriffe auf die Datenbank die Schnittstelle JDBC verwendet wird.
Diese Anweisungen werden von einem Parser syntaktisch analysiert und in Syntaxbäume umgewandelt, auf denen dann die Transformationen zur Erzeugung
von SQL-Anweisungen ausgeführt werden. Zusätzlich zu diesem Parser, dessen
Implementierung im Paket parser vorliegt, wurden die folgenden Module in
Form von Java-Klassen erstellt:
Frontend nimmt Anweisungen von der Kommandozeile entgegen, formatiert
die Ergebnisse von Anfragen und gibt diese ebenfalls auf der Kommandozeile aus.
CommandTranslator koordiniert die Übersetzung von SQLSF-Anweisungen in
Standard-SQL, indem je nach Bedarf die folgenden Untermodule, die Implementierungen der in Abschnitt 5.3 entwickelten Verfahren enthalten,
aufgerufen werden.
TransformationTranslator enthält die Routinen zur Übersetzung von Anweisungen mit Transform-Klausel.
AggregationTranslator realisiert die Verfahren zur Übersetzung von Anweisungen mit Aggregate-Klausel.
IntegrationTranslator bearbeitet Anweisungen, die erweiterte Integrationsoperatoren enthalten.
SubstitutionTranslator übersetzt Anweisungen, in denen Substitutionsoperatoren auftreten.
RegistrationTranslator führt Anweisungen zur Registrierung von Informationen im Komponentendatenbankkatalog aus.
ParseTreeModification enthält statische Methoden für die Modifizierung
von Syntaxbäumen.
95
Implementierung des Prototypen
7.2
Parser
Zum Erzeugen des Parsers wurde der Parsergenerator JavaCC2 4.0 verwendet.
Dieser erzeugt aus einer syntaktischen Spezifikation einer Sprache die JavaQuellen für eine Programmkomponente zur syntaktischen Analyse einer Eingabe. In der Distribution von JavaCC enthalten ist der Preprozessor JJTree.
Dieser kann verwendet werden, um einen Parser zu erzeugen, der aus einer Eingabe eine interne Repräsentation in Form eines Syntaxbaums aufbaut. Diese
Funktionalität wird benötigt um die Eingabe nach der syntaktischen Analyse
zu verarbeiten. Ein weiteres mitgeliefertes Werkzeug ist JJDoc. Dieses kann
verwendet werden, um zu Dokumentationszwecken eine Darstellung der zum
Erzeugen des Parsers verwendeten Grammatik in Backus-Naur-Form zu erzeugen.
JJDoc
sqlsfparser.txt
JJTree
sqlsfparser.jjt
JavaCC
sqlsfparser.jj
Java-Quelldateien
für Parser
Java-Quelldateien
für Syntaxbaum
Abbildung 7.1: Prozess der Erzeugung der Quellen für den Parser
Abbildung 7.1 zeigt schematisch den Prozess zur Erzeugung der Java-Quelldateien für den Parser. Zunächst wird eine syntaktische Spezifikation der Sprache
SQLSF erstellt, die sowohl die Grammatik als auch Aktionen beschreibt, die
der Parser bei der syntaktischen Analyse ausführen soll. Diese syntaktische
Spezifikation in der Datei sqlsfparser.jjt wird zunächst an den Preprozessor JJTree übergeben. Dieser erzeugt eine neue syntaktische Spezifikation,
die mit Java-Codeblöcken zur Erzeugung eines Syntaxbaumes angereichert ist.
Außerdem werden dabei bereits die Java-Quelldateien mit den Klassen zur
programminternen Repräsentation des Syntaxbaums generiert.
Die erweiterte syntaktische Spezifikation in der Datei sqlsfparser.jj wird
anschließend an den eigentlichen Parsergenerator JavaCC übergeben, der dar2
Java Compiler Compiler : https://javacc.dev.java.net/
96
7.2 Parser
aus die fertigen Java-Quelldateien des SQLSF-Parsers erzeugt. Schließlich wird
mit dieser Spezifikation noch das Programm JJDoc aufgerufen, das die Datei
sqlsfparser.txt mit der gesamten Grammatik in Backus-Naur-Form zu Dokumentationszwecken generiert.
Abbildung 7.2 gibt einen Überblick über die von JJTree erzeugte Datenstruktur zur programminternen Repräsentation eines SQLSF-Syntaxbaums. Bei der
Analyse einer eingegebenen Anweisung wird zu jeder angewendeten Produktion der SQLSF-Grammatik eine Instanz der Klasse SimpleNode erstellt. Diese
Instanz wird dem Knoten, der die übergeordnete Produktion repräsentiert, als
Kind zugewiesen. Das Attribut ID gibt an, um welche Produktion es sich handelt.
Eine Programmkomponente, die mit Syntaxbäumen arbeitet, kann das Interface SQLSFParserTreeConstants implementieren, das eine Konstante für jede
Produktion der Grammatik definiert, so dass durch Vergleich der ID eines
Knotens mit diesen Konstanten festgestellt werden kann, welches syntaktische
Konstrukt der Knoten repräsentiert. Zum Zugriff auf Eltern- oder Kindknoten und zur Transformation von Syntaxbäumen können die im Interface Node
spezifizierten Methoden verwendet werden.
<<Interface>>
SQLSFParserTreeConstants
+JJTCOMMAND: int = 0
+JJTQUERY: int = 1
+JJTDDL_STATEMENT: int = 2
+...
*
children
<<Class>>
SimpleNode
<<Interface>>
1
Node
parent
+jjtOpen(): void
+jjtClose(): void
+jjtSetParent(Node n): void
+jjtGetParent(): Node
+jjtAddChild(Node n, int i): void
+jjtGetChild(int i): Node
+jjtGetNumChildren(): int
#ID: int
#Content: String
Abbildung 7.2: Datenstruktur der Syntaxbäume im Überblick
Die von JJTree erzeugte Datenstruktur wurde für den SQLSF-Parser um ein
Attribut Content erweitert. Durch Einfügen entsprechender Aktionen in die
syntaktische Spezifikation wurde dafür gesorgt, dass bei der Anwendung von
Produktionen, die Literale oder Namen von Datenbankobjekten repräsentieren,
die geparste Zeichenkette in diesem Attribut gespeichert wird. Diese Informationen werden nach der Transformation des Syntaxbaumes benötigt, um daraus
eine SQL-Anfrage zu erzeugen.
97
Implementierung des Prototypen
Da der Aufwand für eine vollständige Umsetzung des SQL-Standards hier nicht
vertretbar wäre, wurde nur eine ausgewählte Teilmenge des Sprachumfangs von
SQL als Basis für die mit diesem Prototypen realisierte Erweiterung verwendet.
Die vollständige Grammatik der mit diesem Prototypen verwendbaren Sprache
ist in Anhang A enthalten.
7.3
Komponentendatenbankkatalog
Zur Realisierung des Komponentendatenbankkatalogs wurde das in Abschnitt
5.2 entworfene Schema durch Erstellung entsprechender Relationen in der Datenbank umgesetzt. Dabei wurden zu der Deklaration der Tabellen noch CheckConstraints hinzugefügt, die die Einhaltung einiger einfacher Integritätsbedingungen überwachen. Zur Veranschaulichung wird in Beispiel 7.1 die Implementierung der Relation mit den Metadaten der Aggregierungstabellen angegeben. Das Check-Constraint überprüft für jede registrierte Tabelle, ob das
Aggregierungsidentifikator- und Identifikatorattribut unterschiedliche Namen
besitzen.
CREATE TABLE AggregatedObjectTable (
Name VARCHAR2(30) PRIMARY KEY,
AggregatedIDColumn VARCHAR2(30) NOT NULL,
ObjectIDColumn VARCHAR2(30) NOT NULL,
CONSTRAINT ck_aot_dis_cols CHECK
(AggregatedIDColumn <> ObjectIDColumn)
);
Beispiel 7.1: Realisierung einer Relation des Komponentendatenbankkatalogs
7.4
Aggregation
Die für das Anfragesystem benötigte Repräsentation von Arrays innerhalb
der Datenbank wurde durch die propietären Varying Arrays von Oracle realisiert (siehe [Lon04]), die es ermöglichen, Arrays von Werten desselben Datentyps als Attributwerte in einer Relation zu speichern. Bevor man Werte
eines Datentyps aggregieren kann, müssen der zugehörige Array-Typ und die
zugehörige Aggregierungsfunktion erstellt werden. Für die im Verlauf dieser
Arbeit am häufigsten verwendeten Datentypen NUMBER, VARCHAR2 und
SDO GEOMETRY wurden diese bereits vorbereitet.
98
7.5 Konfliktauflösung
Um auch mit weiteren Datentypen arbeiten zu können wurde eine generische
Implementierung in Form von Templates der für die Aggregation erforderlichen
Komponenten vorgenommen, aus der man durch Ersetzen eines Platzhalters
durch den gewünschten Datentyp eine konkrete Implementierung erhält.
Da es erforderlich ist, bei der Definition des Array-Typs die maximale Anzahl von Elementen zu spezifizieren, wurde diese in der Implementierung auf
256 festgesetzt, was sich nach einer Analyse der zur Verfügung stehenden geographischen Daten als bei weitem ausreichend erwies. Sollten größere Arrays
benötigt werden, kann dies durch einfaches Ändern der Konstante in der jeweiligen Array-Typ-Definition erreicht werden.
Leider erlaubt es Oracle nicht, Vergleichsoperatoren auf Attribute vom Datentyp Array anzuwenden3 . Damit können beispielsweise nicht ohne weiteres
Verbunde über solche Spalten berechnet werden. Um dieses Problem zu umgehen, wurde die generische Implementierung um die folgenden Funktionen
ergänzt.
• ArrayOfT ypeEquals : Array[T ype] × Array[T ype] → Number
Vergleicht die Elemente der zwei Arrays eines Typs und liefert 1, falls
alle Elemente übereinstimmen, 0 sonst.
• ArrayOfT ypeContains : Array[T ype] × T ype → Number
Liefert 1, falls das Array von Elementen eines Typs den spezifizierten
Wert enthält, 0 sonst.
Konkrete Ausprägungen dieser Funktionen wurden für die Datentypen NUMBER, VARCHAR2 und SDO GEOMETRY implementiert, womit beispielsweise auf die in Beispiel 7.2 angegebene Art ein Verbund über mehrwertige
Attribute berechnet werden kann.
SELECT *
FROM Agg_Objekt_A, Agg_Objekt_B
WHERE ArrayOfNumberEquals(Agg_Objekt_A.oid, Agg_Objekt_B.oid) = 1
Beispiel 7.2: Berechnung eines Verbunds über mehrwertige Attribute
7.5
Konfliktauflösung
Zur Auflösung von Datenkonflikten wurden die in Abschnitt 4.3.3 vorgestellten
Funktionen implementiert. Beispiel 7.3 zeigt die Implementierung einer Kon3
Da Arrays seit 1999 Bestandteil des SQL-Standards sind, darf man hoffen, dass Oracle
deren Unterstützung zukünftig noch verbessert.
99
Implementierung des Prototypen
fliktauflösungsfunktion in PL/SQL, die bei einem mehrwertigen Attributwert,
der zwei Geometrien enthält, den ersten Wert bevorzugt.
CREATE FUNCTION preferLeftGeometryOf(mvGeometry ArrayOfGeometry)
RETURN MDSYS.SDO_GEOMETRY AS
BEGIN
IF mvGeometry(1) IS NOT NULL THEN
RETURN mvGeometry(1);
ELSE
RETURN mvGeometry(2);
END IF;
END;
Beispiel 7.3: Beispiel für die Implementierung einer Konfliktauflösungsfunktion
Durch Programmierung solcher Funktionen kann das System um weitere Konfliktauflösungsmöglichkeiten erweitert werden. Da sich das Konzept einiger der
in Abschnitt 4.3.3 vorgestellten Methoden auf weitere Datentypen übertragen
lässt, wurden entsprechende generische Implementierungen erstellt, aus denen
man durch Ersetzen eines Platzhalters durch einen konkreten Datentyp eine
konkrete Implementierung der Konfliktauflösungsfunktion für diesen Datentyp
erhält.
Funktionen zur Auflösung von Beschreibungskonflikten durch Umrechnung von
Attributwerten wurden hier nicht vorbereitet, da es in diesem Fall schwerer ist,
sich allgemein verwendbare Funktionen auszudenken. Für konkrete Anwendungen kann das System ebenfalls leicht um passende Umrechnungsfunktionen
erweitert werden, wie Beispiel 7.4 zeigt.
CREATE FUNCTION DMtoEUR(dm NUMBER)
RETURN NUMBER AS
BEGIN
RETURN 0.511291881 * dm;
END;
Beispiel 7.4: Funktion zur Umrechnung von DM in Euro
Für die Realisierung des Rubber Sheeting wurde die Implementierung aus
[Kre04] übernommen und an die Anforderungen in dem in dieser Arbeit entworfenen System angepasst.
100
Kapitel 8
Ausblick
Die in dieser Arbeit als Erweiterung von SQL realisierte Anfragesprache kann
eingesetzt werden, um innerhalb eines Datenbanksystems mit unterschiedlichen Sammlungen von räumlichen Daten zu arbeiten. Insbesondere wird man
dabei unterstützt, ein globales Schema zu definieren, das eine integrierte Sichtweise auf die Daten anbietet und es ermöglicht, Anfragen an den integrierten
Datenbestand zu stellen. Damit wird das räumliche Datenbanksystem durch
die Verwendung eines Systems zur Bearbeitung von SQLSF-Anweisungen um
eine für die Föderierung der Datenbestände wichtige Funktionalität ergänzt.
Durch die im Folgenden angesprochenen Punkte werden Möglichkeiten für eine
weitere Ergänzung dieser Funktionalität vorgeschlagen.
Erweiterung des Sprachumfangs von SQLSF
Es wurde bereits an anderer Stelle erwähnt, dass als Grundlage für die in dieser Arbeit realisierte Spracherweiterung nur eine ausgewählte Teilmenge des
Sprachumfangs von SQL verwendet wurde. Der erste Ansatzpunkt für eine Erweiterung ist es daher, den vollen Sprachumfang von SQL in Verbindung mit
SQLSF-Anweisungen nutzbar zu machen. Ziel dabei ist es, eine einheitliche
Schnittstelle anzubieten über die sowohl SQLSF-Anweisungen abgesetzt als
auch beliebige SQL-Anweisungen auf dem föderierten Datenbanksystem ausgeführt werden können. Für eine solche Aufgabenstellung wäre ein erweiterbarer SQL-Parser wünschenswert, der es erlaubt, die SQL-Syntax durch eigene
Sprachkonstrukte zu ergänzen und Verfahren zum Bearbeiten dieser Konstrukte hinzuzufügen.
Geometrische Konfliktauflösung
Ein Problem, das in dieser Arbeit leider nicht zufriedenstellend gelöst wer101
Ausblick
den konnte, ist die Auflösung von Datenkonflikten auf geometrischen Attributen. Unterscheiden sich die Geometrien zweier zugeordneter Objekte aus unterschiedlichen Komponentendatenbanken, möchte man zur Integration der Objekte eventuell eine Art ”Mittelwert” der Geometrien berechnen. Dabei beginnt
die Schwierigkeit bereits damit, zu definieren, was man unter dem Mittelwert
zweier Geometrien versteht.
Eine erste Idee bestand darin, einen der in Konflikt stehenden Werte mit einem
”halben” Rubber Sheeting zu transformieren, also die Stützpunkte der Geometrie um die Hälfte des durch das Rubber Sheeting berechneten Vektors zu
verschieben. Allerdings sieht man leicht ein, dass dies nicht dem Konzept eines
Mittelwerts entspricht. Wendet man die Transformation beispielsweise auf eine
Geometrie aus der ersten Komponentendatenbank an, so geht die zugehörige Geometrie aus der zweiten Komponentendatenbank überhaupt nicht in die
Berechnung ein, da lediglich die Passpunkte verwendet werden. Dieser Ansatz
wurde daher verworfen.
Optimierung von SQLSF-Anfragen
Um die Effizienz von SQLSF-Anfragen oder Anfragen an mit SQLSF-gebildete
Sichten zu verbessern, könnte es sich lohnen, Alternativen zu den Übersetzungsverfahren aus Abschnitt 5.3 zu untersuchen. Insbesondere die Bearbeitung von Substitutionsoperatoren erzeugt recht lange SQL-Anfragen, die viele
Unteranfragen enthalten. Im Extremfall enthält eine übersetzte Anfrage eine Unteranfrage für jedes Ergebnistupel. Intelligentere Verfahren könnten hier
bessere Übersetzungen liefern. Eventuell erhält man auch durch den Einsatz
von Optimierungsverfahren für Multidatenbanksysteme (siehe z.B. [YM98])
einen Performanzgewinn.
Weitere Aufgaben bei der Föderierung
Zur vollständigen Verwirklichung eines föderierten räumlichen Datenbanksystems wird mehr als die in dieser Arbeit realisierte Funktionalität benötigt. In
[Con97] werden beispielsweise auch Konzepte zur globalen Integritätssicherung
oder globalen Transaktionsverwaltung in föderierten Datenbanksystemen mit
Standarddaten untersucht. Für diese Konzepte ist noch zu untersuchen, welche zusätzlichen Anforderungen sich durch die Hinzunahme räumlicher Daten
ergeben und ob sich bereits existierende Lösungsansätze übertragen lassen.
Gegebenenfalls müssen für räumliche Daten spezialisierte Techniken eingesetzt
werden.
102
Anhang A
Die Grammatik von SQLSF
Im Folgenden ist die vollständige Grammatik, die zur Implementierung des
SQLSF-Prototypen verwendet wurde, in erweiterter Backus-Naur-Form dargestellt.
Command ::= "EXIT" |
( Query | DDL_Statement | Register_Statement ) ";"
Query ::= Simple_Query ( Set_Operator Simple_Query )*
Simple_Query ::= Select_Clause
From_Clause
( Where_Clause )?
( Join_Clause | Union_Clause )*
( ( Aggregation_Clause | Grouping_Clause )
( Having_Clause )? )?
Select_Clause ::= "SELECT" ( "DISTINCT" )?
( "*" | Select_List_Entry
( "," Select_List_Entry )* )
Select_List_Entry ::= ( Expression | Transform_Clause )
( "AS" Column_Alias )?
Expression ::= Simple_Expression ( Operator Simple_Expression )*
103
Die Grammatik von SQLSF
Simple_Expression ::= Literal |
Function_Expression |
( Tuple_Alias "." )? Attribute_Name
Literal ::= Number | String
Number ::= (["0"-"9"])+ ("." (["0"-"9"])+ )?
String ::= "’" ( ~["’"] )* "’"
Function_Expression ::= Function_Name
"(" Expression ( "," Expression )* ")"
Function_Name ::= Identifier
Identifier ::= ["A"-"Z","_"] ( ["A"-"Z","_","0"-"9"] )*
Tuple_Alias ::= Identifier
Attribute_Name ::= Identifier | Substituted_Expression
Substituted_Expression ::= "$" "(" Expression ")"
Operator ::= "+" | "-" | "*" | "/" | "||"
Transform_Clause ::= "TRANSFORM"
( Tuple_Alias "." )? Attribute_Name
Using_Directed_Link_Clause
Using_Directed_Link_Clause ::= "USING" ( "LEFT" | "RIGHT" )
"LINK" Link_Name
Link_Name ::= Identifier
Column_Alias ::= Identifier | Substituted_Expression
From_Clause ::= "FROM" From_List_Entry ( "," From_List_Entry )*
From_List_Entry ::= ( Subquery |
( Schema_Name "." )? Table_Name )
( Tuple_Alias )?
104
Subquery ::= "(" Query ")"
Schema_Name ::= Identifier
Table_Name ::= Identifier | Substituted_Expression
Where_Clause ::= "WHERE" Condition
Condition ::= Disjunctive_Condition
( "AND" Disjunctive_Condition )*
Disjunctive_Condition ::= Simple_Condition
( "OR" Simple_Condition )*
Simple_Condition ::= ( "NOT" )? Expression Predicate Expression
Predicate ::= "<" | ">" | "=" | "<>" | "<=" | ">=" | "LIKE"
Join_Clause ::= "JOIN" From_List_Entry ( Tuple_Alias )?
( "ON" Condition | Using_Link_Clause )
Using_Link_Clause ::= "USING"
( ( "LEFT" | "RIGHT" )? "AGGREGATED" )?
"LINK" Link_Name
Union_Clause ::= "UNION" From_List_Entry ( Tuple_Alias )?
Using_Link_Clause
Aggregation_Clause ::= "AGGREGATE"
( "BY" Expression ( "," Expression )* |
Using_Directed_Link_Clause )
Grouping_Clause ::= "GROUP" "BY" Expression ( "," Expression )*
Having_Clause ::= "HAVING" Condition
Set_Operator ::= ( "UNION" | "INTERSECT" | "MINUS" )
105
Die Grammatik von SQLSF
DDL_Statement ::= "CREATE"
( "TABLE" | "VIEW" ) New_Relation_Name
"AS" Query
New_Relation_Name ::= Identifier | Substituted_Expression
Register_Statement ::= Register_Link_Clause |
Unregister_Link_Clause |
Register_CDB_Clause |
Unregister_CDB_Clause |
Register_Table_Clause |
Unregister_Table_Clause
Register_Link_Clause ::= "REGISTER" "COMPONENTDBLINK" Link_Name
"FOR" CDB_Name "AND" CDB_Name
CDB_Name ::= Identifier
Unregister_Link_Clause ::= "UNREGISTER"
"COMPONENTDBLINK" Link_Name
Register_CDB_Clause ::= "COMPONENTDB" CDB_Name "AS"
Column_Value_Pair
( "," Column_Value_Pair )*
Column_Value_Pair ::= Attribute_Name "=" Identifier
Unregister_CDB_Clause ::= "UNREGISTER" "COMPONENTDB" CDB_Name
Register_Table_Clause ::= "REGISTER" Table_Type Table_Name
"FOR" ( "LEFT" | "RIGHT" ) Link_Name
"AS" Column_Value_Pair
( "," Column_Value_Pair )*
Table_Type ::= "AGGREGATEDOBJECTTABLE" |
"LINKTABLE" |
"OBJECTLINKTABLE" |
"REFERENCEPOINTSTABLE" |
"ATTRIBUTETRANSITIONTABLE"
Unregister_Table_Clause ::= "UNREGISTER" Table_Type Table_Name
106
Literaturverzeichnis
[Con97]
S. Conrad: Föderierte Datenbanksysteme: Konzepte der Datenintegration. Springer-Verlag, 1997.
[DPS98]
T. Devogele, C. Parent, S. Spaccapietra: On Spatial Database Integration. International Journal of Geographical Information
Science 12:4 (1998), 335–352.
[EM99]
A. Eisenberg, J. Melton: SQL: 1999, formerly known as SQL 3.
SIGMOD Record 28:1 (1999), 131–138.
[EN00]
R. Elmasri, S. B. Navathe: Fundamentals of Database Systems, third
edition. Addison-Wesley, 2000.
[GMS94] M. Goossens, F. Mittelbach, A. Samarin: The LATEXCompanion.
Addison-Wesley Publishing Company, 1994.
[JS82]
G. Jaeschke, H.-J. Schek: Remarks on the Algebra of Non First
Normal Form Relations. In Proceedings of the ACM Symposium on
Principles of Database Systems, 1982, 124–138.
[KCGS95] W. Kim, I. Choi, S. Gala, M. Scheevel: On Resolving Schematic
Heterogeneity in Multidatabase Systems. In Kim [Kim95], 521–550.
[Kim95]
W. Kim (ed.): Modern Database Systems: The Object Model, Interoperability, and Beyond. ACM Press/Addison-Wesley Publishing
Company, 1995.
[KLK91]
R. Krishnamurthy, W. Litwin, W. Kent: Language Features for Interoperability of Databases with Schematic Discrepancies. In Proceedings of the 1991 ACM SIGMOD International Conference on
Management of Data, 1991, 40–49.
[Kre04]
F. Kreutz: Zuordnung von flächenhaften Objekten bei der Föderierung kartographischer Datenbanken. Diplomarbeit, Universität
Hannover, 2004.
107
LITERATURVERZEICHNIS
[KS91]
W. Kim, J. Seo: Classifying Schematic and Data Heterogeneity in
Multidatabase Systems. IEEE Computer 24:12 (1991), 12–18.
[Lam94]
L. Lamport: LATEX: A Document Preparation System, second edition. Addison-Wesley Publishing Company, 1994.
[LAN+ 89] W. Litwin, A. Abdellatif, B. Nicolas, P. Vigier, A. Zeroual: MSQL:
A Multidatabase Language. Information Sciences 49:1-3 (1989),
59–101.
[Lau98]
R. Laurini: Spatial Multi-Database Topological Continuity and Indexing: A Step Towards Seamless GIS Data Interoperability. International Journal of Geographical Information Science 12:4 (1998),
373–402.
[LMT04] U. W. Lipeck, D. Mantel, M. Tiedge: Identifikation kartographischer Objekte in föderierten räumlichen Datenbanken. Informatik
Berichte DB 01/2004, Institut für Informationssysteme, Universität
Hannover, 2004.
[Lon04]
K. Loney: Oracle Database 10g: The Complete Reference. McGrawHill/Osborne, 2004.
[LSS96]
L. V. S. Lakshmanan, F. Sadri, I. N. Subramanian: SchemaSQL A Language for Interoperability in Relational Multi-Database Systems. In Proceedings of 22th International Conference on Very Large
Data Bases, 1996, 239–250.
[LSS99]
L. V. S. Lakshmanan, F. Sadri, I. N. Subramanian: On Efficiently
Implementing SchemaSQL on an SQL Database System. In Proceedings of 25th International Conference on Very Large Data Bases,
1999, 471–482.
[LSS01]
L. V. S. Lakshmanan, F. Sadri, I. N. Subramanian: SchemaSQL
- An Extension to SQL for Multidatabase Interoperability. ACM
Transactions on Database Systems 26:4 (2001), 476–519.
[Man02]
D. Mantel: Konzeption eines Föderierungsdienstes für geographische Datenbanken. Diplomarbeit, Universität Hannover, 2002.
[ML04]
D. Mantel, U. W. Lipeck: Datenbankgestütztes Matching von Kartenobjekten. Mitteilungen des Bundesamtes für Kartographie und
Geodäsie 31, 2004.
[MY95]
W. Meng, C. Yu: Query Processing in Multidatabase Systems. In
Kim [Kim95], 551–572.
108
LITERATURVERZEICHNIS
[OOM87] G. Özsoyoglu, Z. M. Özsoyoglu, V. Matos: Extending Relational
Algebra and Relational Calculus with Set-Valued Attributes and
Aggregate Functions. ACM Transactions on Database Systems 12:4
(1987), 566–592.
[RSV02]
P. Rigaux, M. Scholl, A. Voisard: Spatial Databases: With Application to GIS. Morgan Kaufmann Publishers, 2002.
[SAW98] M. Sester, K.-H. Anders, V. Walter: Linking Objects of Different
Spatial Data Sets by Integration and Aggregation. GeoInformatica 2:4 (1998), 335–358.
[SC99]
K.-U. Sattler, S. Conrad: Konfliktbehandlung in einer Anfragesprache für Datenbankföderationen. In Workshop Föderierte Datenbanken, 1999, 144–157.
[SCS00]
K.-U. Sattler, S. Conrad, G. Saake: Adding Conflict Resolution Features to a Query Language for Database Federations. In Proceedings
of the 3rd Workshop EFIS, 2000, 41–52.
[SCS03]
K.-U. Sattler, S. Conrad, G. Saake: Interactive Example-Driven
Integration and Reconciliation for Accessing Database Federations.
Information Systems 28:5 (2003), 393–414.
[SL90]
A. P. Sheth, J. A. Larson: Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous Databases. ACM
Computing Surveys 22:3 (1990), 183–236.
[SMW04] M. Skulschus, S. Michaelis, M. Wiederstein: Oracle 10g Programmierhandbuch. Galileo Press, 2004.
[SPD92]
S. Spaccapietra, C. Parent, Y. Dupont: Model Independent Assertions for Integration of Heterogeneous Schemas. The VLDB Journal 1
(1992), 81–126.
[WG01]
C. M. Wyss, D. V. Gucht: A Relational Algebra for Data/Metadata
Integration in a Federated Database System. In Proceedings of the
2001 ACM International Conference on Information and Knowledge
Management, 2001, 65–72.
[WR05]
C. M. Wyss, E. L. Robertson: Relational Languages for Metadata
Integration. ACM Transactions on Database Systems 30:2 (2005),
624–660.
[YM98]
C. T. Yu, W. Meng: Principles of Database Query Processing for
Advanced Applications. Morgan Kaufmann Publishers, 1998.
109
Erklärung
Hiermit versichere ich, Hendrik Warneke, die vorliegende Masterarbeit ohne
fremde Hilfe und nur unter Verwendung der von mir aufgeführten Quellen und
Hilfsmittel angefertigt zu haben.
Hannover, 26. April 2006.