3. Z-Ordering: Eine raumfüllende Kurve für - Angizeh: Iran
Werbung
Rheinische Friedrich-Wilhelms-Universität. Bonn Institut für Informatik III Ausarbeitung Unterstützung räumlicher Anfragen mit konventionellen Indexstrukturen Jamshid Azizi Matr. Nr. :1125220 Bonn, Juni 2001 Betreuer: Dr. Thomas Bode [email protected] [email protected] Inhaltsverzeichnis 1. Einleitung ................................................................................................................ 2 2. Anforderungen an ein räumliches Datenbanksystem ............................................. 3 2.1 Oracle8i Spatial ................................................................................................. 4 2.2 Räumliche Datenmodellierung .......................................................................... 4 2.3 Räumliche Indizierung....................................................................................... 4 2.4 Oracle8i interMedia Text Data Cartridge (OiMTDC)......................................... 5 2.5 Oracle8i Spatial Data Cartdridge ...................................................................... 6 2.6 Oracle8i Visual Information Retrieval Data Cartdridge (OVIRDC)..................... 7 3. Z-Ordering: Eine raumfüllende Kurve für Objekte mit äumlicher Ausdehnung ....... 7 3.1 Nachteile der Hybridlösung ............................................................................... 7 3.2 Z-Ordering......................................................................................................... 8 3.2.1 Z-Ordering in Punktdatenbanksystemen .................................................... 8 3.3.2 Anfrageablauf im Z-Ordeing ....................................................................... 9 3.2.3 Eine Einfache Methode für Polygondatenbanken ..................................... 10 3.3 Ein-Wert-Approximation .................................................................................. 10 3.4 Optimierte Redundanz .................................................................................... 11 3.5 Alternative Techniken...................................................................................... 12 4. Indexauswertung .................................................................................................. 12 4.1 Implementierung und Prädikatfilterung............................................................ 13 4.2 Indizierung für GIS Applikationen .................................................................... 15 4.3 Durchführung .................................................................................................. 18 5. Zusammenfassung ............................................................................................... 19 Literaturverzeichnis .................................................................................................. 21 1. Einleitung Mit dem Anstieg der Speicherkapazitäten und Prozessorleistungen können immer größere Datenmengen verarbeitet werden, deren Charakter sich gleichzeitig verändert. Bei der Speicherung von gleichartigen Daten beschränkten sich Abfragen nur darauf, ob die gesuchten Daten in der Datenbank vorhanden sind oder nicht, oder ob Daten mit gewissen Eigenschaften in einem vorgegebenen Intervall liegen oder nicht. Mit zunehmender Komplexität der Daten steigen die Ansprüche an deren Bearbeitung (Echtzeitverarbeitung, Hypertext oder Multimedia). Die stärkere Verbreitung des Internet ermöglicht und erfordert, dass Daten nicht nur aus lokalen Datenbanken abgefragt werden. Für die komplexe Bearbeitung von weltweiten Problemen (z.B. im Umweltbereich) ist es sinnvoll und absolut 2 notwendig, überall auf der Welt verteilte Datenbanken noch effektiver miteinander zu vernetzen. Die Verwaltung und Bearbeitung räumlicher Datenobjekte stellt hohe Anforderungen an Datenbanken. Solche Datenobjekte bedecken oft komplizierte Bereiche im multidi-mensionalen Raum und können daher nicht mehr sinnvoll durch Punkte dargestellt werden. Beispielsweise repräsentieren politische Bezirke auf Landkarten Bereiche mit einer Fläche ungleich Null im zweidimensionalen Raum. Eine häufige Operation ist dann die Suche nach allen Objekten innerhalb eines vorgegebenen Gebietes. Zum Beispiel alle Bezirke zu finden, die - zumindest zum Teil - innerhalb einer 50-Kilometer-Zone um einen speziellen Punkt liegen. Diese Art der räumlichen Suche wird oft in der Computergrafik, in CADSystemen oder auch in allen Arten von geographischen Informationssystemen verwendet. Dafür wurden mehrdimensionale Datenstrukturen entwickelt, für die eine effiziente Suchmethode benötigt wird. Ein Index, der auf den räumlichen Daten der Objekte basiert, wäre daher wünschenswert. Die Indexstrukturen eindimensionaler Datenbanken sind für eine räumliche Suche ungeeignet. So sind z.B. Strukturen, die auf exakte Gleichheit von Werten aufbauen (beispielsweise Hash-Tables) unbrauchbar, weil eine Bereichssuche benötigt wird. Strukturen, die eine eindimensionale Ordnung von Indexwerten verwenden, wie z.B. B-Bäume [Kem 99]*, funktionieren ebenfalls nicht, weil der Suchbereich multidimensional ist. Um räumliche Indexstrukturen in kommerzielle Datenbankmanagementsysteme (DBMS) zu integrieren, sind herkömmliche relationale Datenbanken nicht ausreichend funktionsfähig. In Kapitel 2 wird die Bearbeitung von räumlichen Daten innerhalb eines DBMS durch Oracel8i Spatial erläutert. In Kapitel 3 wird beschrieben, wie Daten aus dem multidimensionalen Raum übertragen werden. Bisher gelang keine gute Übertragung bei Rechtecken und Polygonen. Es muss eine Objektduplizierung verhindert werden und ein Überlappen von Z-Elementen möglich sein. Ziel ist ein neues Kodierungsschema für die Z-Elemente und eine Optimierung des Algorithmus im Anfrageprozess. In Kapitel 4 soll gezeigt werden, wie durch die Indizierung von nutzerdefinierten Typen mit nutzerdefinierten Prädikaten eine effizientere Abfrage und Suche der nutzerdefinierten Objekte erreicht werden kann. 2. Anforderungen an ein räumliches Datenbanksystem Anders als traditionelle erfordern räumliche Anwendungen, dass die Datenbanken komplexe Datentypen wie Punkte, Linien und Polygone verstehen. Folglich müssen relationale Datenbanken in mehreren Gebieten erweitert werden, um die Speicherung und Wiederverwendung von räumlichen Daten zu verbessern. Jedes Datenbanksystem, das versucht, sich mit räumlichen Anforderungen zu befassen, muss mit folgenden Funktionen ausgestattet sein: 1. Satz räumlicher Datentypen zur Darstellung einfacher und komplizierter räumliche Datentypen und auf diesen basierenden Operationen 2. Räumlichen Typen und Operationen an ihrer Spitze sollten Teil der Standardsprache sein (wird für Zugang und Veränderung von nicht räumlichen Daten in diesem System benötigt). So müsste SQL im Fall von relationalen Datenbanksystem so erweitert werden [Dit 01]*, dass es in der Lage ist, räumliche Typen und Operationen zu unterstützen. 3 3. Die Systeme sollten Leistungssteigerungen (Indizierung) anstreben, um räumliche Abfragen, Parallelbearbeitung u.ä. zu ermöglichen. 2.1 Oracle8i Spatial Oracle8i Spatial [Rav&Sha 99]* stellt eine komplett offene, auf Standards basierende Architektur für die Bearbeitung von räumlichen Daten innerhalb eines Datenbankmanagementsystems (DBMS) zur Verfügung. Benutzer können die gleiche Fragesprache (Industrie-Standard SQL) benutzen, um auf die räumlichen Daten und alle anderen Daten in der Datenbank zuzugreifen. Die Funktionalität, die durch Oracle8i Spatial zur Verfügung gestellt wird, ist komplett im Datenserver von Oracle integriert. Benutzer der räumlichen Daten erreichen Zugang zu Standard Oracle8i, sowie eine flexible client/server Architektur und Objektfähigkeiten (robustes Datenmanagement, Datenvollständigkeit, Wiederverwendbarkeit, Sicherheitseigenschaften), welche virtuell mit anderen Strukturen nicht zu erreichen sind. Oracle8i Spatial schafft Voraussetzungen für das Mischen von GIS- (Geographisches Informationssystem) und MIS- (Management Informationssystem) Datenspeichern und es ermöglicht, eine einheitliche Datenmanagementstruktur für alle Daten des Unternehmens zu implementieren. Das Oracle8i Spatial [Rav&Sha 99]* stellt eine skalierbare integrierte Lösung für Managementstrukturen und räumliche Daten innerhalb des Oracle Servers dar. 2.2 Räumliche Datenmodellierung Oracle8i Spatial unterstützt 3 einfache geometrische Typen und Geometrien, die aus einer Sammlung dieser 3 Typen zusammengestellt sind. Die 3 Typen sind Punkt (i), Linie (ii) und N-Punkt Polygon (iii), wobei all diese einfachen Typen zweidimensional (2-D) sind. Nachfolgend sollen die einzelnen Typen definiert werden. Ein zweidimensionaler (2-D) Punkt ist ein Element, das aus zwei Ordinaten (X,Y) besteht. Linien bestehen aus einem oder mehreren Punktpaaren, welche die Liniensegmente definieren. Alle zwei Punkte im Liniensegment können entweder durch eine gerade Linie oder durch einen Kreisbogen miteinander verbunden sein. Das heißt Linien können aus geraden Liniensegmenten, aus Bogensegmenten oder einer Mischung von beiden zusammengesetzt sein. Polygone sind aus verschiedenen Linien zusammengesetzt, die einen geschlossenen Ring formen und den Innenraum des Polygons einschließen. 2.3 Räumliche Indizierung Die Einführung der räumlichen Indizierungsfähigkeiten in die Oracle Datenbankmaschine ist eine Schlüsselfähigkeit. Ein räumlicher Index funktioniert mehr als jeder andere Index als ein Mechanismus, der die Suche in den Tabellen (oder Datenräumen) auf räumliche Kriterien beschränkt. Ein Index muss in der Lage sein, effizient Fragen abzuarbeiten und Objekte in einem Datenraum zu finden, die einen Anfrageraum überlappen. Dies wird üblicherweise durch ein Fragepolygon definiert. Der Index muss Paare von Objekten innerhalb zweier Datenräume finden, die räumlich miteinander interagieren. Definition: Ein räumlicher Index in einer räumlichen Umgebung (cartridge) ist ein logischer Index [Ra&Sh 99]*. Die Zugänge zum Index sind von der Platzierung der Geometrie in einem Koordi- 4 natenraum abhängig. Die Indexwerte befinden sich in einer anderen Domain. Indexzugänge nehmen Werte von einer linear angeforderten Ganzzahldomain an, während Koordinaten für eine Geometrie Paare von Ganzzahlen, floating oder Zahlen mit doppelter Genauigkeit sein können. 2.4 Oracle 8i interMedia Text Data Cartridge (OiMTDC) OiMTDC unterstützt eine „Voll-Text-Indizierung“ von Textdokumentationen. Der Textindex ist ein umgewandelter Index, der eine Ereignisliste für jeden Petrinetzknoten in jedem der Textdokumente speichert. Der umgewandelte Index wird in einer indexorganisierten Tabelle gespeichert. Er wird in der Tabelle bearbeitet (Einsetzen, Aktualisieren und Löschen) in der definierte Textindex modifiziert wird. Die Textcartdridge definiert einen Operator „CONTAINS“ der als Input eine Textspalte und ein Schlüsselwort nimmt. Dies kehrt als richtig oder falsch zurück, je nachdem ob das Schlüsselwort in der Textspalte enthalten ist. Die Vorteile dieses ausgedehnten Indizierungsbearbeitungsrahmens sind nach einer Auswertung von gleichen Anfragen vor und nach Oracle8i erkennbar. Beispiel 1. Nehmen wir folgende Anfrage an: SELECT * FROM docs WHERE Contains (resume, ’Oracle’); Im Vergleich zum Zustand von Oracle8i war der Textindizierungscode (obwohl er logisch betrachtet ein Teil vom Oracle Server war) dem Anfrageoptimierer nicht als ein gültiger Zugangspfad bekannt. In Folge dessen wurden Textanfragen immer als zweistufige Prozesse angesehen. 1. Reihen, die die Aussage erfüllen, werden identifiziert. Die Feldnamen der Reihen von allen relevanten Reihen werden in einer temporären Ergebnistabelle (genannt Ergebnis) geschrieben. 2. Die Originalanfrage wird als Resultat aus der Originalanfrage (minus den Textoperator) und der temporären Ergebnistabelle, bestehend aus allen Feldnamen der Reihen die den Textoperator erfüllen wie folgt gebildet: SELECT d.* FROM docs d, results r WHERE d.rowid = r.rid; In Oracle 8i bei dem man die ausgedehnte Indizierungsmethode nutzt, wird die Anfrage in einem Schritt (in Fließbandform- Einrichtung zur überlappten Befehlsausführung) durchgeführt. Der Textindizierungsblock wird zur vorherbestimmten Zeit bei dem Kern des Programmes aufgerufen. Es gibt keinen Bedarf für eine temporäre Ereignistabelle, weil die Feldnamen der relevanten Reihen durch das ODCI Interface zum Server zurückströmen. Das beinhaltet gleichzeitig, dass es keine zusätzlichen Verbindungen gibt, die in diesem Durchführungsmodell dargestellt werden müssen. Ausserdem müssen nicht alle Reihen, welche die Textaussage erfüllen identifiziert werden, bevor die erste Ergebnisreihe zu ihrem Benutzer zurückgekehren kann. Die Textanfrage wurde so erweitert, dass sie I/O reduziert, weil keine temporäre Ergebnistabelle notwendig ist. Sie reduziert die benötigte Zeit, weil die Reihen, welche die Textanfrage erfüllen nach Anforderung identifiziert werden. Die Textanfrage wurde verbessert, weil die Zahl der Verbindungen dadurch reduziert wurde, dass es keine 5 zusätzlichen Verbindungen mit der temporären Ergebnisstabelle gibt. Die Reduzierung der Zahl der Verbindungen bewirkt eine höhere Effektivität des Optimierers, da der Suchraum reduziert wurde. Es konnte eine mehr als 10-fache Verbesserung der Darstellung für bestimmte suchintensive Anfragen nach der Inegration, die den ausgedehnten Indexrahmen benutzt, festgestellt werden. 2.5 Oracle8i Spatial Data Cartdridge Die Oracle8i räumliche cartdridge erlaubt dem Nutzer den räumlichen Index und die Anfragen an die räumlichen Daten zu speichern. Die räumlichen Daten modelliert. Ein räumlicher sind als ein Objekttyp SDO-GEOMETRY Index kann auf einer SDO- Geometrie Spalte aufgebaut werden. Der räumliche Index besteht aus einer Sammlung von Verteilungen, die zu jedem räumlichen Objekt dazugehören, diese Sammlung wird in der Oracle-Tabelle gespeichert. Der räumliche Index ist eine Instanz eines räumlichen Indextypes, der die Routinen für das Kreieren, Pflegen und Befragen des räumlichen Index definiert. Der räumliche Indextyp unterstützt einen Operator, der als „Overlaps“ bezeichnet wird. Dieser legt fest, welche Geometrien von 2 gegebenen Ebenen einander überlappen. Beispiel 2. eine räumliche Anfrage ist von folgender Form: SELECT r.gid, p.gid FROM roads r, parks p WHERE overlaps (r,p); Der ausgedehnte Indizierungsrahmen hat die Nutzung des Magnetbandes (cassett) von Oracle wesentlich verbessert. Vor Oracle8i musste der Benutzer explizit das PPISQL [Dit 01]* Paket aufrufen, um einen Index zu kreieren oder den räumlichen Index zu pflegen, welcher der DML-(Data Manipulation Language) Operation zur grundlegenden räumlichen Tabelle folgt. Mit diesem Rahmen wird der räumliche Index impliziet gepflegt, so als wäre er ein eingebauter Index. Auch mit dem ausgedehnten Indizierungsrahmen wird die Logik der Nutzung des Index um die anfragen zu bearbeiten, in die Indexroutinen eingeschlossen und der Endnutzer wird nicht mit den Details der Indeximplementierung belastet. Vor Oracle8i musste die räumliche Anfrage wie folgt formuliert werden: SELECT DISTINCT r.gid, p.gid FROM roads_sdoindex r, parks_sdoindex p WHERE (r.grpcode = p.grpcode) AND (r.sdo_code BETWEEN p.sdo_code AND p.sdo_maxcode OR p.sdo_code BETWEEN r.sdo_code AND r.sdo_maxcode) Der Nachteil dieser Methode ist, das der Anfragealgorithmus, der geschützt (geregelt) sein kann, muss dem Nutzer erklärt werden, die innere Logik muss also ein extra SQL Statement ausgedrückt werden. Vom Nutzer wird erwartet, dass er die Details der Speicherstruktur für den Index kennt. In Ergänzung zur erheblichen Vereinfachung der Anfragen, erlaubt der Oracle8i Rahmen eine Veränderung der zugrundeliegenden räumlichen Indizierungsmethoden, ohne vom Endnutzer zu fordern, dass er seine Anfragen ändert. Die Darstellung von räumlichen Daten welche den ausgedehnten Indizierungsrahmen nutzen war genauso gut wie die Darstellung der vorherigen Implementierung. 6 2.6 Oracle 8i Visual Information Retrieval Data Cartdridge (OVIRDC) Das OVIRDC unterstützt eine inhaltsgestützte Wiederbenutzung von Abbildungen. Eine Abbildung wird als ein ORDImage Objekttyp modelliert. Ein BLOB Attribut speichert die Reihenbytes der Abbildung. Die Abbildungsweise unterstützt den Aufbau von Imageindexen. Für den Grund des Aufbaus von Indexen wird jede Abbildung in eine Signatur umgeformt. Diese ist eine Abstrahierung des Inhaltes der Abbildung in Form von visuellen Attributen. Ein Satz von Ziffern, der eine grobe Repräsentation der Signatur ist, wird dann in einer Tabelle gespeichert, welche die Indexdaten repräsentiert. Diese Cartdridge unterstützt den Operator Similar. Dieser Operator sucht nach einer Abbildung, die der Anfragebildung ähnlich ist. Den Nutzen der ausgedehnten Indexierung kann man nach der Analyse der Durchführung von einer gleichen Abbildungsanfrage vor und nach Oracle 8i erkennen. Nehmen wir folgende Anfrage an: SELECT * FROM images T WHERE VIRSumilar (T.img.Signature, querySignature, ‘globalcolor =0.5, localcolor= 0.0, texture=0.5, structure =0.0’, 10,1); Nach Auslösen der vorherigen Oracle8i hat die Abbildungs Cartdridge keine Indizierungsunterstützung. Also musste der Operator wie eine Tabellenanfrage untersucht werden. Der Abbildungsvergleich musste für jede Reihe gemacht werden. In Oracle8i, bei dem der ausgedehnte Indizierungsrahmen benutzt wird, kann der VIRSimilar in 3 Phasen untersucht werden. Die erste Phase ist ein Filter, der eine Reihenfolgenanfrage in der Indexdatentabelle erzeugt. Die zweite Phase ist ein weiterer Filter, der eine Berechnung des Ausmaßes des Abstandes durchführt. Die dritte Phase verwirklicht den aktuellen Abbildungsvergleich. Auf diese Weise wird das komplexe Problem der hochdimensionalen Indizierung auf entschieden einfachere Komponenten heruntergebrochen. Außerdem sind die ersten beiden Phasen des Filterns sehr selektiv. Sie führen zu einer großen Reduzierung des Datensatzes bei dem noch ein Abbildungsvergleich durchgeführt werden muss. Die Durchführung der Imageanfrage wurde durch den Mehrebenenfilterprozess anstelle eines Abbildungsvergleiches für jede Reihe verbessert. Auch erfolgte eine Optimierung der Ranganfrage zur Indexdatentabelle, die Indizies nutzt. Also ist es in Oracle8i jetzt möglich, einen Abbildungsvergleich von Tabellen, die Millionen von Reihen besitzen durchzuführen, etwas was vorher nicht möglich war. 3. Z-Ordering: Eine raumfüllende Kurve für Objekte mit äumlicher Ausdehnung Im geographischen Informationssystem werden bisher thematische Attribute (Niederschlagsmenge) in relationalen Datenbanksystemen und räumliche Attribute außerhalb der Datenbank in File-basierten multidimensionalen Indexstrukturen gespeichert (Hybridlösung). 3.1 Nachteile der Hybridlösung Schwierige Integrierung der auf zwei Arten gespeicherten Daten. 7 Wenn es nicht gelingt eine Update-Operation in der relationalen Datenbank durchzuführen, gibt es einen Konkurenzkonflikt, d.h. im räumlichen Index darf keine Veränderung durchgeführt werden, um die Konsistenz zu garantieren. Darfür müsste ein zeitaufwendiges Übergabeprotokoll für heterogene Datenbanksysteme implementiert werden. Außerdem haben Filesysteme und Datenbanksysteme üblicherweise unterschiedliche Methoden zur Datensicherheit Backup und Parallelenzugang. Die filebasierte Speicherung garantieret nicht die physische und logische Datenunabhängigkeit, so dass Veränderung in laufenden Anwendungen kompliziert sind. Eine Möglichkeit die Nachteile zu überwinden, bietet das objektrelationale Datenbanksystem, da es durch applikationsspezifische Datentypen (called data cartridges or data blades) erweitert werden kann. Die Idee ist Daten-Cartides für räumliche Attributen zu definieren und räumlichen Attribute in die Datenbank zu übernehmen. Für die Daten intensiven GIS-Systeme ist es notwendig multidimensionalen Indexstrukturen in die Datenbank zu integrieren. Das erfordert ein Zugang zum Blockmanagement des Datenbanksystems. Das ist bei den meisten kommerziellen Datenbanksystemen nicht gewährleistet, z.B. der gültige Universalserver von Oracel stellt keine Dokumentation für das blockorientierte Interface zu Verfügung. Die Daten-Cartridges erlauben nur einen Zugang zu Beziehungen über das SQL-Interface, so sind also objektrelationale Datenbanksysteme nicht hilfreich für unsere Integrationsprobleme. Man kann schlussfolgern, dass unabhängig davon, ob man objektrelationale Datenbanksysteme oder nur relationale Datenbanksysteme benutzt, der einzige Weg, um räumliche Attribute innerhalb der Datenbank zu speichern der ist, sie in dem relationalen Modell abzubilden. Eine frühe Lösung für das Management von multidimensionalen Daten in Beziehung basiert auf raumfüllenden Kurven. Raumfüllende Kurven bilden Punkte eines multidimensionalen Raumes in eindimensionalen Werten ab. Dabei werden Distanzen bewahrt, d.h., wenn zwei Punkte in multidimensionalen Raum eng beieinander liegen, liegen sie auch in eindimensionalen Raum eng beieinander. Die Suche nach übereinstimmenden Objekten ist normalerweise begrenzt auf ein bestimmtes Gebiet in dem eingebetteten Raum. Das Konzept der raumfüllenden Kurven wurde erweitert, um mit Polygonen arbeiten zu können. Diese Idee basiert auf der Zerlegung der Polygone entsprechend der raumfüllenden Kurve. Ein Nachteil dieser Methode ist ihre Empfindlichkeit gegenüber einer passenden Auswahl der Auflösungsparameter. Daher muss nach einer Methode zur Anwendung der raumfüllenden Kurven für räumlich erweiterte Objekte gesucht werden, welche nicht auf der Zerlegung basiert. 3.2 Z-Ordering Z-Ordering basiert auf der rekursive Zerlegung des Datenraumes, wie er von der raumfüllende Kurve zur Verfügung gestellt wird. 3.2.1 Z-Ordering in Punktdatenbanksystemen Wir nehmen einen Punkt an, von einem zweidimensionalen Einheitsquadrat [0..1]². 8 Der Algorithmus teilt das Einheitsquadrat in vier Quadranten von gleicher Größe auf, welche kanonisch nummeriert sind von null bis drei. (sieh Abb. 3.1) 23 22 2 3 0 1 2 212 212 20 210 21211 0 3 1 Abbildung 3.1 Z-Ordering in Punktdatenbanksystemen Wir notieren die Zahl des Quadranten und teilen diesen Quadranten in seine vier unter Quadranten. Das wird rekursiv wiederholt bis eine bestimmte Grundauflösung erreicht wurde. Die feste Zahl der rekursiven Wiederholung wird als Auflösungsniveau „g“ bezeichnet. Dann hören wir auf und nutzen die erhaltene Reihenfolge von „g Ziffern“ (genannt Quadrantenreihenfolge) als Anordnungsschlüssell für die Punkte ( wir ordnen lexikographisch). Jede Quadrantenreihenfolge bezeichnet eine Region des Datenraumes, die wir als Element bezeichnen. Z.B. steht die Reihenfolge <00> für ein Element mit der Seitenlänge 0.25, welches die untere linke Ecke in dem Datenraum berührt. Elemente bei der Basisauflösung, welche durch die Quadrantenreihenfolge mit der Länge „g“ repräsentiert werden, werden Zellen genannt. Wenn ein Element e1 in einem anderen Element e2 enthalten ist, dann ist die dazugehörige Quadrantenreihenfolge Q(e2 ) ist ein Präfix von Q(e1 ). Je länger ein Quadrantenreihenfolge ist, desto kleiner ist das dazugehörige Element. In dem Einheitsquadrat wird die Fläche von einem Element durch eine Reihenfolge mit der Länge „l“ (1/4) l repräsentiert. In einem Punkdatenbanksystem werden nur Zellen mit der Basisauflösung genutzt. Deshalb besitzen alle Quadrantenreihenfolgen die gleiche Länge und wir können die Quadrantenreihenfolgen als Ziffern interpretieren , die in einem Vierergruppensystem (Basis 4) vorkommen. Die Interpretierung von Reihenfolgen als Ziffern erleichtert ihr Management im Index und verändert nicht die Reihenfolge der Punkte, weil die lexikographische Ordnung der weniger gleichen Beziehung von Ziffern entspricht. Die Punkte werden in einer reihenfolgeerhaltenden und eindimensionalen Indexstruktur wie dem B+-Baum [Kem 99]* gesteuert. 3.3.2 Anfrageablauf im Z-Ordeing Wir nehmen an, eine Fensteranfrage mit einem spezifisierten Fenster. Der Datenraum ist unterteilt in seine vier Quadranten. Jeder Quadrant wird auf Überlappung mit der Anfragefenster überprüft. Wenn der Quadrant sich nicht mit dem Anfragefenstern überlappt, muss nichts getan werden. Wenn der Quadrant komplett in dem Anfragefenstern eingeschlossen ist, müssen wir alle Punkte von der 9 Datenbank wiedergewinnen, die Quadrantenreihenfolge von diesem Element als Präfix von ihrem Schlüssel haben. Wenn die Schlüsseln als Ganzzahlen dargestellt werden, müssen wir ein Intervall von Unterreihenfolgenziffern wiedergewinnen. Alle restlichen Quadranten, welche durch das Fenster überlappt werden, aber nicht komplett im Fenster eingeschlossen sind („wirkliche“ Schnittpunkte) werden rekursiv aufgeteilt, bis die Basis Auflösung erreicht wird. 3.2.3 Eine Einfache Methode für Polygondatenbanken Um das Konzept des Z-Ordering für das Management von Objekten mit räumlichen Ausdehnung (Rectangels oder Polygonen) auszudehnen, müssen wir das Problem betrachten, dass ein gegebenes Polygon sich mit vielen Zellen schneiden. Eine einfache Methode könnte darin bestehen, jede Zelle, welche durch das Objekt bedeckt wird, in der Datenbank zu speichern. Offensichtlich bewirkt diese Methode einen riesigen Speicheraufwand, es sei denn, das grundlegende Rasterfeld ist sehr grob. Deshalb sind mehrere Methoden vorgeschlagen wurden, um den Aufwand zu reduzieren, wenn ein feineres Rasterfeld benutzt wird. 3.3 Ein-Wert-Approximation Die Objekten werden an das kleinste Element, welches des vollständige Objekt einschließt angenähert (sieh Abb. 3.2). 22 23 2 0 3 1 20 21 32 33 30 31 02 03 12 13 00 01 10 11 Abbildung 3.2 Z-Ordering in Polygondatenbanksystemen In diesem Fall wird unser rekursiver Algorithmus für die Ermittlung der Quadrantenreihenfolge wie folgt modifiziert: Teilen Sie den gegenwärtigen Datenraum in vier Quadranten. Wenn genau ein Quadrant durch das Objekt geschnitten wird, fahren Sie rekursiv mit diesem Quadranten fort. Wenn mehr als ein Quadrant geschnitten wird, dann hören Sie auf. Benutzen Sie die Quadranten Reihenfolge, welche zu diesem Punkt als an Ordnungsschlüssel gebracht wurde. Diese Methode hat der offensichtliche Vorteil, das jeder Gegenstand durch einen einzelnen Schlüssel, und nicht durch ein Satz von Schlüssel wie in unserer einfachen Methode dargestellt wird. Aber diese Methode enthält auch mehrere Nachteile. Der erste Nachteil ist, dass die Quadrantenreihenfolgen in dieser Approximation verschiedene Längen haben, abhängig von der Auflösung des kleinsten enthaltenen Quadranten. So ist unsere einfache Interpretierung als ein numerischer Wert nicht möglich. Schlüssel müssen als Strings mit unterschiedlicher Länge und lexikographisch verglichen, gespeichert werden, was weniger effizient ist, als der numerische Vergleich. Das zweite Problem ist, das Objekt nur sehr unzureichend abgebildet werden. So wird zum Beispiel jedes Polygon, welches eine der achsenparallelen Linien in der Mitte 10 des Datenraumes (die Linie x= 0.5 und die Linie y= 0.5) durchschneidet, kann nur durch die leere Quadrantenreihenfolge approximiert werden. Wenn das Polygon, das approximiert werden muß, sehr groß ist scheint eine Approximation durch eine leere Reihenfolge oder durch eine sehr kurze Reihenfolge gerechtfertigt zu sein. Für kleine Polygone ist der Verhältnisannäherungsfehler zu groß. Der relative Raum Aufwand für die Objektapproximation ist so unbegrenzt. In Wirklichkeit sind die Objekte, welche sich durch die leeren Quadrantenreihenfolgen angenähert haben, Kandidaten für jede Anfrage, die der Nutzer stellt. Je mehr Objekte mit kurzer Quadrantenreihenfolge in der Datenbank gespeichert werden, um so schlechter ist die Trennschärfe (die Auswahlkraft) des Index. 3.4 Optimierte Redundanz Um einen unbegrenzten Approximationsaufwand zu verhindern, schlägt Orenstein [Böh 99]* eine Kombination der einfachen Methode und der Ein-Reihenfolge Darstellung vor. Er adoptiert die Idee von der Aufspaltung der Objekte von der einfachen Methode, aber er zerlegt nicht unbedingt jedes Objekt bis die Basisauflösung erreicht ist. Stattdessen schlägt er zwei verschieden Kriterien vor (bezeichnet als größenbegrenzt und fehlerbegrenzt) um die Zahl der Quadranten zu kontrollieren, in die ein Objekt zerlegt wird. Jedes Unterobjekt wird in dem Index gespeichert, in dem man seine Quadrantenreihenfolge benutzt, die als String dargestellt wird. Ob gleich diese Konzept eine Objektduplizierung einschließt (welche nach Orenstein als Redundanz bezeichnet wird), ist die Zahl der Datensätze, welche in dem Index gespeichert werden, nicht direkt durch die Rasterauflösung wie in der einfachen Methode determiniert. Anders als in der EinReihenfolge Methode, ist es nicht notwendig, kleine Objekte durch leere Reihenfolgen oder durch sehr kurze Reihenfolgen zu repräsentieren. Übereinstimmend mit Orenstein ist eine Aufspaltung in 2-4 Teile typisch für eine zufriedenstellende Suchleistung. Orensteins Methode erleichtert die Probleme der zwei vorher genannten Methoden, aber eine Doppelbeseitigung ist immer noch erforderlich und die Schlüssel sind immer noch Reihenfolgen mit unterschiedlicher Länge. Orenstein begründet den optimalen Grad der Redundanzen nur experimentell. Eine analytische Lösung wurde von Gaede (Gae 95) vorgeschlagen, der die Komplexität der gespeicherten Polygone identifizierte, beschrieben durch ihre Parameter und ihre fractale Dimension, als den Hauptparameter für die Optimierung. Einweitere Problem, das entsteht, wenn Redundanzen erlaubt sind, entsteht in Verbindung mit dem zweiten Filter in einer Mehr-Schritt-Umgebung. Informationen welche für ein schnelles Filtern von falschen Hits benutz werden können, so wie die ergänzende herkömmliche Approximation (Minimum Boundaring Rectangles MRB) sollten wegen ihrer hohen Speicherfähigkeit keine Subjekt der Duplizierung sein. Um eine Duplizierung einer solchen Information zu verhindern, muss dies in einer separaten Tabelle gespeichert werden, welche ergänzende Verbindungen im Frageprozess enthält. Eine weiter Konseqenz aus der Analyse von Gaede ist, dass die Anzahl der Intervalle, welche von der Fragenfenstern generiert werden, proportional zur Zahl der Rasterzellen ist, welche von der Grenze des Anfragefensters geschnitten werden. Das bedeutet, dass eine zu feine Auflösung der Raster zur einer großen Zahl von Intervallen führt und auf diese Weise das Ausführungsverhalten beeinfluss, wenn eine relationale Datenbank genutzt wird. Der Grund ist, dass die Intervalle durch der Datenbankserver transferriert und bearbeitet werden müssen, was nicht vermeidbar ist, wenn die Zahl der Intervalle sehr hoch ist. 11 3.5 Alternative Techniken Verschiedene Verbesserung des Z-Orderingkonzept sind sehr gut bekant (sieh Abb. 3.3 [Böh 99]*). a) Hilbert b) Peano(Z-Order) c) Gray-Codes d) Z-Mirror e) U-Index Abbildung 3.3 Verschiedene Verbesserung des Z-Orderingkonzept Einige Autoren schlagen die Nutzung von verschiedene kurven so wie z.B. die Graycodes, die Hilbert Kurve oder andere Variationen. Viele Studien bevorzugen die Hilbert Kurve unter der Vorschläge, wegen ihrer besseren Distanzbewahrungsfähigkeit [Böh 99]* schlägt eine große Auswahl von Raumfüllenden kurven vor und macht eine vergleichende Darstellungsstudie, in dem er einer relationale Implementierung nutzt. Auch diese Darstellungsbewertung enthält nicht eine wesentliche Verbesserung der Darstellung der Hilbert Kurve oder andere Raumfüllende Kurven über Z-Ordering. Daher nutzen wir die Peano/Morton Kurve, weil sie einfacher zu berechen ist. 4. Indexauswertung Die Indexauswertung wird von Frageoptimierern durchgeführt, um jeden Index für eine effiziente Fragedurchführung nutzen zu können. Traditionell müssen Frageoptimierer in der Lage sein, nur einfache relationale Operatoren für die Indizierung auszunutzen, solange der dazugehörige Wertebereich einfach bestimmt werden kann. Für die Indexausnutzung mit nutzerdefinierten Prädikaten, muss der Anfragekompiler in der Lage sein, diese relationalen Operatoren zu finden um sie nutzen zu können. Die Bestimmung der verwendeten Funktionen muss folgendermaßen spezifiziert sein, Entweder kann die Funktion als Prädikat genutzt werden und wenn es so ist, muss sie herausfinden, welche Suchmethode benutzt werden kann, wenn bestimmte Operatoren Suchargumente sind. Für Details zu der Syntax von Prädikaten siehe Abschnitt 4.1. Beispiel 4.1 Beachten wir folgendes Beispiel: CREAT TABLE customer (name varchar(20), id integer, …, xyloc location); ... CREAT INDEX locationIndx on customer(xyloc); … SELECT * FROM customer WHERE within(xyloc, circle(…)); Für die Anfrage in Bsp. 4.1. wird angenommen, dass „within“ als Prädikat definiert wurde, dass eine dazugehörige Suchmethode hat, wenn der zweite Operant ein Suchargument ist. Der Anfragekompiler kann aus zwei Gründen einen Indexscan auswählen, um von der Tabelle „customer“ Aufzeichnungen zu erhalten. Der erste ist, dass es einen Index auf einem „xyloc“ Attribut gibt. Der zweite Grund ist, 12 dass der Fragekompiler erkennt, dass der 2. Operant von „within“ begrenzt ist und erkennt, dass „within“ ein Prädikat mit einer Suchmethode ist, wenn der 2. Operant ein Suchargument ist. Der Indexscan wird die dazugehörige Suchmethode nutzen, um einen Satz von Suchschlüsseln zu generieren. Diese stellen den kleinsten Satz von Gitterzellen dar, die den Kreis im 2. Operanten bedecken. Der Satz von Suchschlüsseln wird von der zugrundeliegenden Suchmethode genutzt, um die relevanten Aufzeichnungen von der Tabelle „customer „ wiederzugewinnen. 4.1 Implementierung und Prädikatfilterung Der Hochniveaurahmen zur Indexierung von nutzerdefinierten Typen wurde in IBM DB2 implementiert. Neben der Indexverwaltung, nutzerdefinierten Prädikaten und der Indexauswertung, stellt die Implementierung auch eine Nutzerkontrolle über die mehrstufige Bewertung von nutzerdefinierten Prädikaten durch Filterung zur Verfügung. Das vermeidet die potentiell teure Bewertung der nutzerdefinierten Prädikate und reduziert sowohl die I/O und die CPU-Kosten. Abbildung 4.1 zeigt die Syntax für die Indexerweiterung mit der assoziierten Schlüsseltransformation und Suchmethoden. Die semantische Beziehung, welche zur Suchmethode korrespondiert, wird nicht ausdrücklich spezifiziert. Die CREATE INDEX EXTENSION Anweisung legt eine parametrische Indexauswertung fest. Eine parametrische Indexauswertung wird als Instanz gebildet, wenn ein Index in einer Tabelle kreiert wird, der CREATE INDEX Anweisungen nutzt. Die Parameter der Indexerweiterung können für eine Spezifizierung genutzt werden, z.B. die Zahl der Ebenen und die Größe einer Gitterzelle in einem mehrstufigen Zellindex. Die Schlüsselaspekte der Indexerweiterung schließen die Schlüsseltransformationsfunktion ein, indiziert durch KEYTRANSFORMATION INVOKATION und die dazugehörigen Such-Methoden. Jede Suchmethode enthält eine Suchschlüsselerstellungsfunktion indiziert durch SEARCH KEY PRODUCTION, die einen Satz von Suchschlüsseln berechnet, wenn die Suchargumente und eine Indexfilterfunktion indiziert durch Indexfilter gegeben sind, die in der Indexkomponente genutzt werden. Die Nutzerkontrolle über den Indexfilter ist ein leistungsstarkes Konzept. Es stellt eine frühzeitige Filterung zur Verfügung, in der der Indexschlüssel genutzt wird. Das verhindert die I/O Kosten für die Wiedergewinnung von Daten, welche offensichtlich nicht die Suchkriterien erfüllen, solange die Daten nicht von einer Diskette wiedergewonnen werden können, die den Indexscan nutzt bis der Indexschlüssel festgelegt ist. Das ermöglicht das Nutzen multipler Indexierungsmechanismen in einer einzigen Suchkombinierung. dies geschieht, in dem ein Indexfilter geplugged wird, der eine ergänzende Suche darstellt, in dem eine externe Suchmaschine genutzt wird. Abbildung 4.2 zeigt die Syntax von nutzerdefinierten Funktionen, die als Prädikate dienen können. Jede Prädikatspezifikation indiziert eine optionale Filterfunktion und die dazugehörige Suchmethode für verschiedene Sucheigenschaften. Der Datenfilter dient dazu, die potentiell teure Bewertung der Prädikate durch ein Herausfiltern der Aufnahmen, die das Prädikat nicht erfüllen , zu verhindern, in dem man eine einfache und billigere Operation nutzt. In EXPLOITATION RULE indizieren die Parameter, die auf WHEN KEY folgen, ein Suchargument. Das optionale Schlüsselwort EXACTLY das dem AS PREDICATE folgt, benötigt eine kleine Erklärung. <creat index extension> ::= 13 CREAT INDEX EXTENSION <header> <index maintenance > <index search> <header> ::= <indexExtensionName> ({<parmName> <parmType>}+) <index maintenace> ::= WITH INDEX KEYS FOR ({ <colName> <colType>}+) /*index columns*/ GENERATED BY <key transform> <index search> ::= WITH SEARCH METHODS FOR INDEX KEYS ({<colName> <colType>}+){<search method>}+ <searchmethod> ::= WHERE <searchmethodName> USING ({<colName> <colType>+) /*search arguments*/ REANGE THROUGH <search key producer> CHECK WITH <index filter> <creat index> ::= CREAT [UNIQUE] INDEX <index Name> ON <table Name> ({<colName> [ASC | DESC]}+) USING <indexExtensionName> ({<constant>}+) Abbildung 4.1 Syntax für die Indexerweiterung mit der assoziierten Schlüsseltransformation und Suchmethoden [Che 99]* <creat function> ::= CREAT FUNCTION <functionName> {<parmName> <dataType>}+ <predicate specification>+ <predicate specification> ::= AS PREDICATE [EXACTLY] [FILTER BY <data filter>] [<index exploitation>] <index exploitation> ::= SEARCH BY INDEX EXTENSION <indexExtensionName> <exploitation rule>* <exploitation rule> ::= WHERE KEY ({<paramName>}+) /*search target*/ USE <searchmethodName> ({<paramName>}+) Abbildung 4.2 Syntax von nutzerdefinierten Funktionen [Che 99]* Wenn ein Indexscan ausgeführt wird, der ein Prädikat nutzt, wird die dazugehörige Suchmethode, die eine nutzerdefinierte Funktion ist, aufgerufen. Sie berechnet einen Scan von Suchschlüsseln für die Suchziele, indem sie Suchargumente nutzt. Die Suchschlüssel werden zu den zugrundeliegenden Zugangsmethoden gesendet, um die relevanten Aufnahmen wiederaufzurufen. Der Indexfilter ist verbunden mit der Suchmethode, die bei Vorhandensein angewendet wird, bevor die Aufnahmen von der Diskette wiederverwendet werden. der relationale Datenbankmanager wendet den Datenfilter an, 14 der mit der Prädikatspezifizierung verbunden ist. Zum Abschluss werden die Aufnahmen bewertet, indem man das Prädikat nutzt, das den Datenfilter passiert hat. Wenn der Indexfilter und der Datenfilter nur eine Annäherung an das Prädikat ermöglichen, z.B. bei räumlichen Applikationen, dann ist der letzte Schritt der Prädikatbewertung notwendig. In anderen Anwendungen als der Dokumentensuche können die Filter exakt den Satz von Antworten berechnen, der das Prädikat erfüllt. Der letzte Schritt der Prädikatbewertung sollte in diesem Falle nicht ausgeführt werden. Das Schlüsselwort exakt indiziert eine solche Situation. Abbildung 4.3 zeigt die Architektur der Implementierung in DB2. Sie kann jede zugrundeliegende Zugangsmethode, die verfügbar ist, verdrängen. die rechtwinkligen Boxen stellen Plätze dar, wo nutzerdefinierte Funktionen in eine Unterstützung der nutzerdefinierten Suchen eingeschaltet werden. Die Schlüsseltransformation wird im Indexmanager zur Indexverwaltung aufgerufen, wenn die Tupels in der Tabelle eingefügt, gelöscht oder aktualisiert werden. Der Anfragekompiler nutzt Spezifikationen von nutzerdefinierten Prädikaten für eine Indexausnutzung. Während der Suche, die auf einem nutzerdefinierten Prädikat beruht, wird die dazugehörige Suchmethode durch den relationalen Datenmanager aufgerufen, um einen Satz von Suchschlüsseln zu generieren. Für das Wiederaufrufen, das auf nutzerdefinierten Prädikaten beruht, sind 2 Filter in der Architektur eingeschlossen. Der Grund ist die Verhinderung einer potentiell teuren Bewertung von nutzer- definierten Prädikaten. Die Indexfilter filtern Aufnahmen heraus, bevor sie von den Puffern innerhalb des relationalen Datenbankmanagers wiederhergestellt werden, Die Datenfilter im relationalen Datenbankmanager stellen eine Chance der kosteneffizienten Filterung vor einer teuren Bewertung der Prädikate dar. Query Query Compiler: Predicate Specification Index EXploitation Insert/Delete/Update Relational Search Keys Predicate Ecal Data Mgr: Search Table Update Data Filter Methods Index Mgr: Search Keys Key Transform Index Update Search Index Filter Table Access Methods Abbildung 4.3 Architektur der Implementierung in DB2 [Che 99]* 4.2 Indizierung für GIS Applikationen Im traditionellen GIS wird die Indizierung von räumlichen Daten durch einen Satz von systemgebundenen APIs (application programming interface) ermöglicht. Wenn eine Anfrage das Suchen von räumlichen Daten beinhaltet, werden die räumlichen Daten für die Indexauswertung transformiert. Die resultierende Anfrage wird zur Optimierung und Bewertung zur Datenbank 15 gesendet. Das Fehlen der Integration von räumlichen Indizes in der Datenbankmaschine führt zu Integritätsproblemen und falschen Treffern bei der Darstellung. Unser Hochniveauindexierungsrahmen hat eine räumliche Indizierung in einer Datenbank ermöglicht und nutzt außerdem Vorteile der spezifischen Suchmethoden, die in GIS entwickelt wurden für die folgenden nutzerdefinierten Typen: CEART TYPE envelop As (xmin int, ymin int, xmax int, ymax int); CREAT TYPS shape AS (gtype varchar(20), mbr envelop. Numpart sint, numpoint sint, geometry BLOB(1M)) NOT INSTANTIABLE; CREAT TYPE point UNDER shape; CREAT TYPE line UNDER shape; CREAT TYPE polygon UNDER shape; Beispiel bei denen Formen als Unterstützungstypen für verschiedene Untertypen dienen, sowie Linien und Polygone. Zwei Tabellen werden in der Datenbank definiert, eine speichert die Informationen über Schulen und die andere beinhaltet Informationen über die Haushalte des Einzugsgebietes. CREAT TABLE schools AS (name varchr(20), district varchar(20), address varchar(20), area ahape PRIMARY KEY (name, district)); CREAT TABLE households AS (address varchar(20), annualincome int, location shape); Die folgende Anfrage versucht, das durchschnittliche Einkommen der Haushalte, das als eine attendance von den spezifischen Schulen zu berechnen. SELECT avg(h.annualincome) FROM houses h, schools s WHERE s.name = ‚Armstrong Elementary‘ AND s.district = ‚Highland Park‘ AND Within(h.location, s.area); Um der effizienten Ausführung dieser Frage zu folgen, benötigen wir eine Indexerweiterung. Diese erhalten wir, indem wir die nutzerdefinierte Schlüssseltransformation und Suchmethode für geographische Formen einschließen und indem wir einen Index in die Tabelle Haushalt einsetzen. Außerdem müssen wir die Prädikate für „within“ spezifizieren und die dazugehörigen Suchmethode nutzen. Das folgende Statement bestimmt die Indexauswertung über den Typ geographische Formen. Es nutzt einen mehrstufigen Gitterindex für die geographische Form. CREAT INDEX EXTENSION gridshape (levels varchar(20) FOR BIT DATA) WITH INDEX KEYS for (sh shape) GENERATED BY gridkeys ( Levels, sh..mbr..xmin, sh..mbr..ymin, sh..mbr..xmax, sh..mbr..ymax) WITH SEARCH METHODS FOR INDEX KEYS (level,int , gx int, gy int, xmin int, Ymin int, xmax int, ymax int) WHERE search_within USING (area shape) RANGE THROUGH gridrange( Levels, area..mbr..xmin, area..mbr..ymin, 16 area..mbr..xmax, area..mbr..ymax) CHECK WITH checkdüplicte( Levels, loc..mbr..xmin, loc..mbr..ymin, loc..mbr..xmax, loc..mbr..ymax) CHECK WITH mbroverlap( Xmin, ymin, xmax, ymax, loc..mbr..xmin, loc..mbr..ymin, loc..mbr..xmax, loc..mbr..ymax ); Die Indexerweiterung spezifiziert die Funktion für die Schlüsseltransformation, Gitterstücke und Zweisuchmethode (DB2). Sie nutzt die doppelte Datennotierung für die Zugang zu Attributen von Objekten des nutzerdefinierten Typs. Eine ist für die Suche in einem spezifischen Gebiet, die andere ist für das Auffinden von geographischen Formen, die eine spezifische Lokalisierung haben. Beide Suchmethoden nutzen die gleiche Funktion, den Gitterwertebereich, um ein Set von Indexen für potentielle Suchziele zu generieren. Jede Suchmethode hat ihre eigene Filterfunktion. Alle Funktionen werden durch die nutzerdefinierte Funktion beachtet, wenn Definitionen gegeben werden. Wir sind soweit, einen Index für die Lokalisationsspalte der Tabelle zu erstellen. CREAT INDEX houselocIDX ON households(location) USING gridshape (’10 100 1000‘); Die Parameter sind von drei Ebenen von verschiedenen Gitterzellengrößen. Für die Indexerweiterung benötigen wir Prädikate und die zugehörige Suchmethode die folgende Spezifizierung nimmt das „within“ als ein Prädikat. CREAT FUNCTION within(s1 shape, s2 shap) RETURNS int LANGUAGE C ... EXTERNAL NAME ‚/lib/gislib!within‘ AS PREDICATE FILTER BY mbrwithin (s1..mbr..xmin, s1..mbr..ymin, s1..mbr..xmax, s1..mbr..ymax, s2..mbr..xmin, s2..mbr..xmin, s2..mbr..xmax, s2..mbr..ymax) SELECT BY INDEX EXTENSION gridshape WHEN KEY (s1) USE search_within(s2) WHEN KEY (s2) USE search_contain(s1); Die letzten drei Zeilen indizieren, das Suchen, die auf Prädikate von „within“ basieren, durchgeführt werden, indem sie eine Indexerweiterung gridshape nutzen, wenn das erste Argument S1 ein Suchziel ist, soll man die Suchmethode search_ within mit S2 als Suchargument nutzen. Der Anfragekompiler ist in der Lage, einen Plan zu generieren, der den Vorteil vom Zugangspfad, der vom Index „on location“ von der Tabelle „Haushalter“ nutzen kann. Die Schlüsseltransformation, der Suchschlüsselproducer und die Filterfunktionen werden automatisch an einem vorbestimmten Platz aufgerufen. 17 4.3 Durchführung Unser rahmen für eine Hochniveauindizierung (high level indexing) von nutzerdefinierten Typenerweitert die Ausdruckskraft und integriert die Optimierung von SQL anfragen für nutzerdefinierte Typen. Dieser Abschnitt stellt einige Messungen von vorhergehenden Darstellungen für GIS Applikationen dar. Dabei werden die existierenden GIS-Architekturen und unser integrierter Zugang genutzt. Die existierende GIS-Architektur wird von SDE: 3.0.2 bei DB2 UDB Version 5 von [ESRI]* dargestellt. Dabei wird eine räumliche Datenmaschine außerhalb der Datenbank für die räumliche Optimierung genutzt. Gegeben ist eine Tabelle mit Geschäftsdaten und eine Spalte mit räumlichen Attributen und geometrischen Formen. Die räumliche Spalte in der Originaltabelle (genannt Business-Tabelle) wird durch eine ID-Spalte ersetzt, die ein äußerer Schlüssel für die Eigenschaftstabelle ist. In Ergänzung zur Eigenschaftstabelle ist SDE Verwaltung eine räumliche Indextabelle, die auch Indexmethoden aus unserem Beispiel nutzt, und auf 3 Ebenen basiert. Die räumliche Indextabelle enthält die Merkmale ID (das ist ein äußerer Schlüssel für die Eigenschaftstabelle) und die Indexinformation für die Lokalisierung der linken niedrigen Gitterzelle und das MBR der Merkmale. Wenn eine räumliche Suchanfrage durchgeführt wird, nutzt SDE die räumliche Indextabelle und die Eigenschaftstabelle um eine Liste von ID-Kandidatenformen zu berechnen, welche das räumliche Prädikat erfüllen. die berechnete Liste der Kandidatenformen wird danach genutzt, um die Daten der Businesstabelle wieder herzustellen. Das wird gemacht, indem man die remaining Prädikate im „WHERE“ Satz auf die räumliche Suchanfragen anwendet. Das aktuelle SDE verbindet die Businesstabelle und die Eigenschaftstabelle, indem es verschiedene Anfragen ausführt. Unser integrierter Zugang zur Hochniveauindexierung von nutzerdefinierten Typen ist in DB 2 SpatialExtender implementiert. Wir nutzen die Census-Blockdaten für den Staat Kentucky, der 137173 Polygone hat, mit den durchschnittlich 31 Punkten im Polygon. Die Tabelle „Kentucky“ Blocks hat in der Spalte „Grenzen von räumlichen Typen“ Polygon in Ergänzung zu anderen Attributen wie die Namen oder die totale Population. Jedes Polygon repräsentiert ein Gebiet, dass wenigstens 4 und höchstens 3416 Punkte enthält. CREAT TABLE kentuckyBlocks 8name varchar(20), ..., boundary POLYGON) Die folgenden Anfragen repräsentieren einige typische Operationen in GIS Applikationen: loading: einschließlich Rohdatenladung durch eine Sequenz von SQL, dem inneren Stellungsrahmen und der Verwaltung der räumlichen Indizes. region queries: für die 3 vordefinierten Regionen in verschiedenen Lokalisierungen mit folgender Größe von Antwortsätzen 3155, 2387 und 1457. point queries: 100 Zufallspunkte, die eine Nutzerpunktierung in einem Polygon während des räumlichen browsings simulieren. region queries with attributes: das gleiche wie Regionanfrage, ausgenommen die nicht räumlichen Attribute wie Name oder Population, werden auch in Ergänzung zu den räumlichen Daten abgerufen 18 fetch all: Messen wie schnell die Daten aus der Datenbank werden herausgepumpt werden können. Alle Anfragen durchlaufen den IBM RS6000/J 40 Server während der off Stunden, um Veränderungen durch Nutzer und Prozesse zu minimieren. Die GIS Kundenprogramme werden mit derselben Maschine durchgeführt. Die Verwaltung der Anfrageausführungszeit (gerundet auf Sekunden) werden in Tabelle 1 angezeigt. Das Laden der Daten wurde durchgeführt, während der Rest der Anfragen 3 mal durchgeführt wurde und die Durchschnittwerte angezeigt wurden. Sowohl beim Laden (load) als auch bei Ruf sie alle auf (fetch all) führen wir die innere Tabelle durch und die integrierte Methode ist über vier mal schneller. Im Fall von Laden (load) werden aus einem eingefügten statement für eine Reihe in der integrierten Methode drei eingefügte Statements in der GIS Methode, ein für die businesstabelle, ein für die Eigenschaftstabellen und ein Statement für die räumliche Indextabelle. Im Fall von fetch solange die GIS Methode die Verbindung von zwischen der Businesstabelle und der Eigenschaftstabelle selber abhandelt, führt es eine separate Anfrage gegen die Eigenschaftstabelle wiederholt durch, solange für jedes Datenset von der Businesstabelle wiederaufgerufen werden muss. Für Regionenanfragen ohne nicht-räumliche Attribute ist die integrierte Methode über 2,5 mal schneller als die GIS Methode, aber sie ist über 3 mal schneller als für Fragen mit nicht-räumlichen Daten. Der Unterschied besteht darin, dass im letzten Fall der Zugang zur Businesstabelle involviert ist. Die GIS Methode ist sehr gut, für Punktanfragen. Letztlich zeigt das Resultat, dass unsere integrierte Methode der Hochniveauindexierung von räumlichen Daten eine viel bessere Darstellung bietet. Das zeigt die Bedeutung der Verbesserung der Datenbankmaschine für die erweiterte Indizierung von komplexen Daten. 5. Zusammenfassung In der Arbeit wurde zunächst im 2. Kapitel Oracle 8i Spatial vorgestellt, da es die Vermischung von Datenspeichern des GIS und des MIS ermöglicht. Ausserdem konnte damit eine einheitliche Datenmanagementstruktur für alle Unternehmensdaten implementiert werden. Es wurde beschrieben, wie durch Oracle8i Spatial drei einfache geometrische Typen und Geometrien, die aus einer Sammlung dieser 3 Typen bestehen, unterstützt werden. Dabei handelt es sich um zweidimensionale Typen. Durch die Oracle 8i Spatial Data Cartdridge ist der Nutzer in der Lage, den räumlichen Index und die Anfragen an die räumlichen Daten zu speichern. Dabei gehört zu jedem räumlichen Objekt eine Sammlung von Verteilungen, welche in der Oracle Tabelle gespeichert wurden. Durch den räumlichen Index wurden Routinen für das Kreieren, Pflegen und Befragen der räumlichen Indexe definiert. Im 3. Kapitel wurden die Nachteile der bisherigen getrennten Speicherung von thematischen und räumlichen Attributen vorgestellt (z. B. Konkurrenzkonflikte). Die Schwierigkeit, Veränderungen in der laufenden Anwendung umzusetzen, wurde als Motivation für eine Weiterentwicklung dargestellt. Um ein erfolgreiches Management von multidimensionalen Daten durchzuführen, wurden in einer frühren Lösung raumfüllende Kurven entwickelt. Auf die Erweiterung 19 dieses Konzeptes zur Bearbeitung von Polygonen wird auch im 3. Kapitel eingegangen. Da diese bisher verwendete Methode bei der Auswahl der Auflösungsparameter zu sensibel ist, wurde nach einer neuen Methode gesucht, die nicht auf der Zerlegung der räumlichen Daten beruht. So kommt es abschließend in Kapitel 3 zur Darstellung des Z-Ordering, bei dem Daten aus dem multidimen- sionalen Raum übertragen werden. Dabei wird eine bessere Übertragung von Rechtecken und Polygonen angestrebt. Es konnte eine neues Kodierungsschema für die Z-Eelemente und eine Optimierung des Abfrageprozesses erreicht werden. Universelle Applikationen, die sowohl komplexe Anfragen als auch komplexe Daten umfassen, erfordern eine leistungsstarke und flexible Indexunterstützung für nicht traditionelle Daten wie geographische Informationen oder strukturierte Dokumente. Die Indizierung von nutzerdefinierten Typen mit nutzerdefinierten Prädikaten ist eine Grundbedingung um den Anforderungen der modernen Datenbankapplikationen zu entsprechen. Die Anfrageüberarbeitungsmethode transformiert Anfragen, die nutzerdefinierte Prädikate enthalten. Das erfordert keine Modifikation der Datenbankmaschine. Man kann auch applikationsspezifische Zugangsmethoden implementieren, z.B. generalisierte Suchbäume. Sie haben den Vorteil, dass sie eine direkte Unterstützung für applikationsspezifische Suchen anbieten. Leider haben bisher nur R- und B-Bäume [Kem 99]* den Weg in die kommerziellen Datenbanksysteme gefunden. Ein Grund dafür ist, das die Implementierung von neuen Zugangsmethoden oder eines generischen Suchbaumes [Kem 99]* ein sehr aufwendiges Vorhaben ist, solange eng mit den Niedrigniveaukomponenten der Datenbankmaschine, wie Parallelitätskontrolle Lockmanager und Puffermanager interagiert werden muss. Die Zuverlässigkeit ist von zunehmender Bedeutung für ein ausgereiftes Datenbankprodukt. Außerdem verlangen die Applikationen neue Datentypen und eine fortgeschrittene Suche, wie z.B. nach dem nächsten Nachbarn von räumlichen Daten oder eine reguläre Pfaderweiterung für halbstrukturierte Daten. Unser Rahmen für eine Hochniveauindexierung von nutzerdefinierten Typen verallgemeinert die erweiterte sekundären Indizes [[Lyn 88] und [Sto 86]*. Er ist eng integriert mit den Datenbankmaschinen, speziell mit dem Indexmanager und dem Frageoptimierer. Er ist orthogenal zu den zugrundeliegenden Zugangsmethoden und kann die Vorteile von allen spezifizierten Zugangsmethoden nutzen, wann immer sie verfügbar sind. Unser Hauptbeitrag ist nicht die Entwicklung einer neuen Zugangsmethode, oder eines speziellen Suchalgorithmus, sondern die Herstellung eines Rahmens, in welchem der Nutzer die direkte Kontrolle über die Indexverwaltung, Auswertung und Filterung hat. Außerdem können die Nutzer ihre eigenen Schlüsseltransformationen bestimmen. Die Idee der Schlüsseltransformation ist nicht neu, so z. B. das Transformieren von geographischen Objekten in MBRs für R-Bäume [Gut 84]* oder in ein Set von z-Werten. Im folgenden geben wir dem Nutzer jedoch die Möglichkeit, zu unterscheiden, welche Abstraktionen oder Approximationen er für den Indexschlüssel für den nutzerdefinierten Typ nutzen will. Die Nutzer können ihren eigenen Suchcodes produzieren. Dennoch sind die Suchschlüsselproducer nicht in der Lage, selber eine fortgeschrittene Suche wie nach Ebenen oder nach dem nächsten Nachbarn zu unterstützen (was die direkte Unterstützung von der zugrundeliegenden Suchmethode erfordern würde). Die Schlüsseltransformation überwindet die semantische Lücke zwischen nutzerdefinierten Prädikaten und den begrenzten Zugangsmethoden, die verfügbar sind. Die Nutzer können ihre eigenen Filter bestimmen, um eine teure Prädikatbewertung zu verhindern. Eine mehrstufige Prädikatbewertung wurde erklärt [Bri 93]*. Die Forscher 20 haben auch Anfrageoptimierungsausgaben mit teuren Prädikaten untersucht und mit einer Filterung, die angenäherte Prädikate nutzt. Unser Beitrag ist die Integrierung einer mehrstufigen Bewertung von Prädikaten mit der Datenbankmaschine, speziell dem Indexmanager. Das stellt einen Rahmen für die Implementierung zur Verfügung, bei dem approximierte Prädikate effektiv für eine effiziente Anfrageausführung genutzt werden können. Wie wir gezeigt haben, ist der Indexfilter eine leistungsstarke Technik. Sie ermöglicht es, Kosten für I/O zu verringern, da eine Wiederherstellung von nutzlosen Daten in dem Memory Puffer verhindert wird. Das ermöglicht einen interessanten Mechanismus, bei dem verschiede Indexierungsmechanismen in einer Suche kombiniert werden, z. B. die strukturierte Suche mit der externen Volltextindexierung. Die enge Integration mit der Datenbankmaschine bedeutet, dass es für Fragekompiler möglich ist, nutzerdefinierte Prädikate in dem Standardrahmen der Frageoptimierung zu nutzen. Das heißt, dass die vollen Befragungsfähigkeiten von SQL, einschließlich verschiedener Prädikate in einem „WHERE“ Satz, aggregierte Funktionen, Unteranfragen, und Rekursionen nun für die universalen Applikationen durch DB2 verfügbar sind. Literaturverzeichnis [Bri 99] http://www.fh-oldenburg.de/iapg/personen/brinkhof/BTW93.pdf [BKS 90] N. Beckmann, H.-P. Kriegel, R. Schneider und B.Seeger: "The R*-tree: An Efficient and Robust Access Method for Points and Rectangles". In Proc. of ACM SIGMOD Conference on Management of Data, pp. 322331, Institut für Praktische Informatik, Universität Bremen, 1990. [Böh 99] C. Böhm, G. Klump and H. P. Kiegel, XZ-Ordering: A Space-Filling Curve for Objects with Spatial Extension, University of Munich, CSI, Germany, 1999. [Bri 93] T. Brinkhoff, H.-P. Kriegel, and R. Schneider, Comparisons of approximation of complex objects used for approximation-based query processing in spatial database system. In IEEE Intl. Conference on Data Engineering, pages 40-49, 1993. [Che 99] W. Chen, J. H. Chow, Y. C. Fuh, J. Gradbois, M. Jon, N. Mattos, B. Tran, Y. Wang, High Level Indexing of User-Defined Types, IBM Santa Tereasa laboratory, ESRI, 1999. [Dit 01] R. Dittrich and A. Geppert, Component Database Systems by Klaus 2001. [ESRI] ESRI Environmental System Research Institute (ESRI), Home page http://www.esri.com. [Gut 84] A. Guttman: "R-trees: A Dynamic Index Structure for Spatial Searching". In Proc. of ACM SIGMOD Conference on Management of Data, pp. 4757, University of California, Berkeley, 1984. [Kem 99] Kemper, Alfons, Datenbanksysteme , korr. Auf. –München; Wien: Oldenbourg,1999. [Lyn 88] C.A. Lynch and M.Stonebraker, Extended user-defined indexing with application to textual databases, In Intl. Conference on Very Large Data Bases, pages 306-317, 1988. [Ra&Sh 99] S. Ravada and J. Sharma, Oracle8i Spatial: Experiences with Extensible Databases, Berlin, Heidelberg 1999. [Sto 86] M. Stonebraker, Inclusion of new types in relational data base system, in IEEE Intl, Conference on Data Engineering, pages 262-269, February 1986. 21
