DE19621788A1

DE19621788A1 - Datenbanksystem zur Verwaltung von Arrays

Info

Publication number: DE19621788A1
Application number: DE19621788A
Authority: DE
Inventors: Peter Dr Baumann
Original assignee: BAYERISCHES FORSCHUNGSZENTRUM fur WISSENSBASIERTE SYSTEME (FORWISS) 91058 ERLANGEN DE; BAYERISCHES FORSCHUNGSZENTRUM
Current assignee: BAUMANN, PETER, DR., 81735 MUENCHEN, DE
Priority date: 1995-08-30
Filing date: 1996-05-30
Publication date: 1997-03-06
Also published as: DE59601468D1

Description

Technischer Hintergrund der Erfindung Technisches Gebiet, auf das sich die Erfindung bezieht

Die vorliegende Erfindung bezieht sich auf ein anwendungsneutrales Datenbanksystem (DBS) zur Speicherung, Wiedergewinnung und Manipulation von beliebigen Arrays in Datenbanken. Der Begriff Array wird in diesem Zusammenhang in einem programmiersprachlichen Sinn verstanden: Eine Sequenz fester oder variabler Länge von gleichartig strukturierten Datenelementen (Zellen; in den Bereichen Computergraphik und Bildverarbeitung oft als Pixel bezeichnet), die über ihre (ganzzahligen) Positionsnummern adressiert werden. Die Zellen selbst können selbst wieder Arrays sein, so daß sich Arrays beliebiger Dimension konstruieren lassen.

Einschlägiger Stand der Technik mit Fundstellen

DBSe haben eine beträchtliche Tradition und spielen eine wichtige Rolle in der Speicherung, Wie dergewinnung und Manipulation großer Datenmengen. Dazu bieten sie Mittel für flexiblen Daten zugriff, Integritäts- und Konsistenzverwaltung, Mehrbenutzerverwaltung, Anfrage- und Speicheroptimierung, Backup und Recovery etc. Zur Kommunikation zwischen Datenbankanwen dung (Client) und dem Datenbankprogramm (Server) existieren diverse Techniken, die z. B. über Funktionsbibliotheken (Application Programmer′s Interface, API), die an die Anwendung gebun den werden, eine für die Anwendung unsichtbare Netzwerk-Datenkommunikation einschließlich Datenkonversion vornehmen.

Allerdings sind diese Vorteile bisher nur für Datenelemente wie ganze Zahlen und Strings sowie seit einiger Zeit für sogenannte lange Felder oder Blobs (binary large objects), also variabel lange Byteketten, verfügbar. Allgemeine Rasterdaten (z. B. Audio (1D), Rasterbilder (2D) und Video (3D) werden gemäß gängiger Praxis als Bitketten betrachtet und auf lineare Blobs abgebildet; bei spielsweise konstatieren in [MwLW-89] die Autoren zuerst "die Bild-Rohdaten bilden eine Pixel matrix", um dann fortzufahren "die Rohdaten erscheinen [in der Datenbank] einfach als ein Bitstring".

Aufgrund des Semantikverlusts durch die FORTRAN-artige Linearisierung in der Datenbank kön nen Rasterdaten nur als Ganzes oder zeilenweise gelesen und geschrieben werden. Rasterstrukturen können nicht in Suchkriterien angegeben werden und können auch nicht durch das DBS bearbeitet werden, um etwa relevante Ausschnitte zu extrahieren. Darüberhinaus muß sich die Anwendung auf eines aus der Vielzahl existierender Datenformate zur Codierung und Kompression festlegen. Diese Wahl ist für auch alle anderen Datenbank-Applikationen verbindlich, die darauf zugreifen, und ihnen allein obliegt die korrekte Decodierung und Dekompression. Dem Datenbank-Anwen dungsprogrammierer wird damit eine Vielzahl von maschinennahen, sich wiederholenden, fehler anfälligen und zeitraubenden Programmieraufgaben aufgebürdet.

Weiterhin zerstört die Linearisierung von Arrays im Sekundär- und Tertiärspeicher die Nachbar schaftsbeziehung zwischen Arrayelementen, wie Abb. 2 zeigt. Ein Ausschnitt, der auf logischer Ebene ein hohes Maß an Lokalität aufweist, wird auf dem Hintergrundspeicher in einer Art ver streut, die nur den zeilenweisen Zugriff begünstigt und alle anderen Zugriffsarten drastisch benach teiligt. Die Folge ist ein ungenügendes Antwortzeitverhalten.

Ein typisches System wird in [MwLW-89] beschrieben: Rasterbilder liegen in der Datenbank als Blobs, codiert in einem von mehreren möglichen Bildaustauschformaten (z. B. TIFF oder GIF); ein zusätzliches Flag zeigt der Anwendung das aktuell verwendete Format an. Das EXTRA/EXCESS- System [VaDe-91] bietet eine Algebra für die Modellierung und Abfrage von Rasterdaten, jedoch keine darauf abgestimmte Speichertechnik, so daß nur kleine Arrays (z. B. 4×4-Matrizen) effizient verwaltet werden können. Sarawagi und Stonebraker [SaSt-94] haben kürzlich eine Speicherarchi tektur für Arrays vorgeschlagen, die auf Kachelung (siehe unten) basiert, aber ohne räumlichen Index zur Zugriffsbeschleunigung und ohne optimierbare Anfrageunterstützung neben der reinen Ausschnittsbildung. In [Baum-94] wird ein Ansatz für die Rasterdatenverwaltung vorgeschlagen, der sowohl die konzeptuelle als auch die physische Ebene behandelt. Eine allgemeine Lösung für das Problem der Datenunabhängigkeit, also der Bearbeitung von Rasterdaten in einer DML bzw. einem API ohne Kenntnis und Bezugnahme auf ihre physische Ablagestruktur, Codierung und Kompression, existiert derzeit nicht.

In der Bildverarbeitung werden Kachelungstechniken für die Bearbeitung von Bildern verwendet, die aufgrund ihrer Größe nicht als Ganzes in den Hauptspeicher passen (siehe z. B. [Tamu-80]. Eine Kachel ist ein rechteckiger Bildausschnitt. Das Bild wird so in Kacheln zerlegt, daß sich diese nicht überlappen und insgesamt das gesamte Bild überdecken (siehe Abb. 5.1). Innerhalb einer Kachel werden die Daten vermöge eines konventionellen Linearisierungsschemas abgelegt. Kachelung kann vorteilhaft eingesetzt werden, um Nachbarschaft innerhalb eines Arrays auf einem linearen Speichermedium zu simulieren, und bildet daher eine wichtige Grundlage für die vorliegende Erfindung.

Für die Verwaltunggeometrischer Daten wie Punkte, Linien und Flächen existiert eine Vielzahl von räumlichen Indizes (Geo-Indizes), um den Zugriff auf derartige Datenelemente in einer Daten bank zu beschleunigen [Guet-94]. In der vorliegenden Erfindung wird ein derartiger Geo-Index zur schnellen Kachelsuche eingesetzt.

Darstellung der Erfindung Zu lösende technische Aufgabe

Die vorliegende Erfindung beschreibt ein DBS für Rasterdaten, das folgendes leistet:

- Verwaltung der vollen Semantik von beliebigen Arrays.
- Deklarative Speicherung, Wiedergewinnung und Bearbeitung von Rasterdaten auf der semanti schen Ebene von Arrays.
- Datenunabhängigkeit: Die Präsentation von Arraydaten durch das DBS ist explizit von der Anwendung in einer Vielzahl unterschiedlicher Datenformate wählbar, unabhängig vom daten bank-internen Speicherformat, der Codierung und Kompression.
- Eine Speichertechnik, die die effiziente Verwaltung sehr großer Arrays erlaubt, die sich über mehrere, möglicherweise heterogene, Datenträger erstrecken können.
- Speicher- und Anfrageoptimierung.

Vorteilhafte Wirkungen der Erfindung

Ein erfindungsgemäßes DBS ist insbesondere für Raster-Applikationen geeignet, die hohe Anfor derungen hinsichtlich Funktionalität, Datenvolumen, Netzwerkfähigkeit und Antwortzeitverhalten stellen. Zu den wichtigsten Anwendungsfeldern zählen verteilte, offene Multimediasysteme, Medi zinische Bildverarbeitung/PACS/Krankenhaus-Informationssysteme, geographische und Umwelt- Informationssysteme (GIS/EIS) sowie wissenschaftliche Visualisierung (Maschinenbau, Meteoro logie, Hydrologie, Astronomie). Im einzelnen lassen sich folgende Vorteile erzielen:

- Anwendungsneutralität: Die Array-spezifischen Datenstrukturen und Operationen lassen sich beliebig mit konventionellen Definitionen, Ausdrücken und Prädikaten mischen; damit kann ein erfindungsgemäßes DBS in einer Vielzahl von Anwendungsfeldern eingesetzt werden.
- Datenunabhängigkeit: Die DBS-Funktionalität ist auf beliebigen Plattformen und Netzwerken verfügbar und unabhängig von einem speziellen Datenformat oder einer bestimmten Menge von Datenformaten.
- Datenbank-Anwendungsprogrammierer werden von maschinennahen, sich wiederholenden, fehleranfälligen und zeitraubenden Aufgaben befreit, indem vom DBS einheitliche Standard- Lösungen angeboten werden.
- Geringerer Ressourcenverbrauch aufgrund einer angepaßten Speicherarchitektur und einer deklarativen, optimierbaren Anfragesprache; insbesondere hängt das Antwortzeitverhalten vom Anfrageergebnis ab und nicht vom Gesamtdatenvolumen, auf dem die Anfrage ausgeführt wird.
- Transparente Integration von Speichermedien (z. B. Festplatte, Jukebox, Bandarchive) für Datenmengen beliebiger Größe, insbesondere für Arrays, die sich über mehrere Datenträger erstrecken.
- Klassische Datenbankdienste wie Transaktionsunterstützung, Integritätsverwaltung und Reco very werden für Rasterdaten verfügbar.

Erläuterungen zu den Abbildungen

Abb. 1: Schematischer Aufbau einer erfindungsgemäßen Anordnung:
Ein oder mehrere Rechner, auf denen Rasterdaten-Anwendungen laufen, sind über ein lokales oder Weitverkehrsnetz mit dem Server verbunden, auf dem das Raster-DBS läuft.

Abb. 2: Zerstörung der räumlichen Nachbarschaft durch die Linearisierung im Zuge der Speicherabbildung, gezeigt am Beispiel der Array-Ausschnittsbildung. (Kreise bedeuten durch den Ausschnitt selektierte Zellen, Punkte repräsentieren von der Anfrage nicht erfaßte Zellen.)

Abb. 2.1: 2-D Bild mit markiertem Ausschnitt (logische Sicht).

Abb. 2.2: Linearisiertes Bild mit verteilten Bestandteilen des selektierten Ausschnitts.

Abb. 3: Visualisierung der Wirkung von Beispielsanfragen auf Arrays (selektierte Teile schraffiert dargestellt).

Abb. 3.1: Trimm-Operation, angewendet auf ein 2-D-Array.

Abb. 3.2: Projektion entlang der x/z-Ebene eines 3-D-Arrays; das Ergebnis ist ein 2-D-Array.

Abb. 3.3: Projektion entlang der y-Achse eines 3-D-Arrays; das Ergebnis ist ein 1-D-Array.

Abb. 4: Erweiterung eines variablen 2-D-Arrays im Zuge einer Zuweisung.

Abb. 5: Rasterdatenspeicherung mittels einer Kombination von Kachelung und Geo- Index; hier: Beispiel der Abspeicherung eines 2-D-Arrays.

Abb. 5.1: Zerlegung eines 2-D-Bilds in Kacheln.

Abb. 5.2: Geo-Index zur Kachel-Zerlegung in Abb. 5.1.

Abb. 6: Retrieval-Algorithmus als Flußdiagramm.

Abb. 7: Update-Algorithmus als Flußdiagramm.

Abb. 8: Systemarchitektur eines erfindungsgemäßen Rasterdatenbanksystems. Die mit Pfeilen markierten internen Schnittstellen eignen sich besonders zum Dazwischenschalten von Netzwerkkommunikation.

Beschreibung eines Weges zur Ausführung der Erfindung

Die vorliegende Erfindung wird unter Bezugnahme auf eine bestimmte geeignete Ausführung beschrieben. Die Erfindung ist jedoch nicht auf diese Ausführung beschränkt; vielmehr lassen sich viele Variationen und Modifikationen vornehmen, ohne den Bereich der Erfindung zu verlassen, wie er in den unten angegebenen Ansprüchen bzw. deren Äquivalent dargestellt ist.

Raster-Semantik

Im folgenden findet die C++-artige DDL eines objektorientierten DBS Verwendung; für die Bei spielsanfragen wird eine SQL-artige DML benutzt. Es ist offensichtlich, wie die dahinterliegenden Konzepte auf andere Modelle und Systeme zu übertragen sind; die Erfindung beschränkt sich in keiner Weise auf eine bestimmte Syntax, Programmiersprache, ein Betriebssystem oder ein bestimmtes Datenbank-Paradigma.

Strukturdefinition

Das konzeptuelle Schema wird anhand einer Beispiels-Miniwelt beschrieben, die dem Bereich Sensor-Fusion in Umweltinformationssystemen entstammt. Drei Objektklassen SeismicSensor für variabel-lange 1-D-Zeitreihen, LandsatTM für Landsat-TM-Satellitenbilder im Format 7020×5760 (2-D) und WeatherSimulation für atmosphärische Temperaturverteilungen in einem 1000×1000×1000-Bereich (3-D) werden unten definiert; das Symbol # notiert eine variable Anzahl von Zellen in der angegebenen Dimension:

Operationen

Die Arrayoperationen lassen sich in wertebasierte Operationen, Änderungsoperationen und allge meine Konstruktoren einordnen. Folgende wertebasierten Operationen werden vorgeschlagen:
Konstanten. Für den Gebrauch in Anfrageausdrücken oder um ein Array zu initialisieren, lassen sich Zellwerte explizit oder implizit angeben. Beispiel: "Ein 2×2-Ganzzahl-Array, überall mit 0 besetzt." Dies wird durch eine direkte Auflistung beschrieben, wobei die Arraystruktur angemessen erscheint, hier durch geschweifte Klammern:

{ {0, 0}, {0, 0} }

Eine implizite Angabe geschieht durch einen deskriptiven Ausdruck der Art

{O: [1024] [768] }

der in diesem Fall bedeutet "ein 1024 × 768 Bild mit 0 in allen Zellen".

Trimmen erzeugt einen rechteckigen Arrayausschnitt. Beispielsweise läßt sich die Anfrage "der Bildausschnitt aller Landsat-TM-Bildern, der durch die Eckpunkte (x0, y0) und (x1, y1) festgelegt ist" (vgl. Abb. 3.1) formulieren als

Projektion extrahiert eine Schicht der Dicke 1 aus einem Array (Abb. 3.2). Beispiel. "Die Lufttem peraturverteilung über dem gesamten Simiulationsgebiet in einer Höhe über Grund h" wird ausge drückt als

Induzierte Operationen. Für jede auf dem Array-Basistyp verfügbare Operation (z. B. Subtraktion auf Grauwert-Pixeln) wird eine korrespondierende Operation zur Verfügung gestellt, die diese Basisoperation simultan auf alle Arrayzellen anwendet (z. B. Subtraktion zweier Grauwertbilder). Beispiel: "Den c3-Kanal aller Landsat-TM-Bilder, um den Wert d in der Intensität vermindert":

Prädikats-Iteratoren. Das Rasterprädikat some (p) ergibt true genau dann, wenn mindestens eine der Zellen eines Booleschen Arrays p den Wert true enthält. Entsprechend evaluiert all (p) zu true genau dann, wenn alle Zellen von p true enthalten. Beispiel: "Der Ort aller Seismik- Sensoren, an denen irgendwann in der Vergangenheit die Erdbebenaktivität t überstiegen hat":

Als nächstes werden Änderungsoperationen aufgelistet.

Initialisierung

Diese Operation, die implizit bei jeder Erzeugung eines Arrays als Teil eines Tupels, eines Objekts o. ä. aufgerufen wird, setzt alle Zellen auf Nullwerte und die Länge variabler Arrays auf 0.

Zuweisung

Durch eine Zuweisung erhalten die Zellen in einem Array oder einem Teil eines Arrays neue Werte. Falls das Array variabel ist und die zu besetzenden Zellpositionen nicht alle in dem vorher existierenden Array liegen, wird das Array entsprechend erweitert. Beispielsweise wird in Abb. 4 das existierende Array a. old um den Teil v. new erweitert, der a. old nur teilweise überdeckt. Daher wird als erweitertes Array a. neu gebildet. Zwei neu erzeugte Gebiete a. aux1 und a . aux2 dienen zur Erhaltung der Rechteckform und werden mit Nullwerten initialisiert.

Zuletzt werden allgemeine Konstruktionsprinzipien aufgeführt, die für die Flexibilität und Allge meinheit der Erfindung wesentlich sind.

Orthogonale Anfragesprache

Die oben angegebenen Operationen sind vorzugsweise in eine deklarative DML eingebettet, die beschreibt, was getan werden soll, und nicht, wie es geschehen soll, und damit den Weg für intelligente Optimierung bereitet. Ausdrücke und Prädikate werden (rekursiv) gebildet aus den Array-Basisoperationen, den bekannten Booleschen Operatoren, Klammerung, funktionale Schachtelung sowie u. U. den Aufruf weiterer Funktionen bzw. Methoden.

Beispiel 1

"Die Temperaturverteilung in der Höhe h von allen Simulationen, bei denen irgendwo in dem durch die Eckpunkte (x0, y0, z0) and (x1, y1, z1) markierten Gebiet die Temperatur t über schritten wird." Trimmen in drei Dimensionen wird hier kombiniert mit dem induzierten Vergleich und dem Kollabieren in einen einzigen Booleschen Wert durch den some-Operator:

Beispiel 2

"Die Landsat-TM-Bilder, die Regionen mit beobachteter seismischer Aktivität enthal ten, sowie die zugehörigen Sensorpositionen". Zusätzlich zu den Rasteroperationen finden hier geometrische Operationen area () und contains Verwendung sowie Schachtelung:

Datenunabhängigkeit

Rasterdaten werden dem Anwendungsprogramm als generische Arrays präsentiert; die Funktionalität, die auf Arrays angeboten wird, ist unabhängig von ihrer physischen Struktur in der Datenbank. Finden keine anderweitigen Festlegungen statt, dann passieren Daten die DBS-Schnittstelle in der Hauptspeicher-Darstellung der Zielmaschine und der Programmier sprache der Applikation, z. B. als C++-Array, so daß eine unmittelbare Weiterverarbeitung durch die Mittel der Applikations-Programmiersprache möglich ist; diese Repräsentation wird im folgenden die direkte Darstelhing eines Arrays bzgl. einer bestimmten Zielumgebung genannt. Alternativ kann die Datenbankanwendung mittels vom DBS bereitgestellter Funktionen explizit eine andere Darstellung anfordern (z. B. JPEG, um Hardware-Unterstützung auf der Anwendungsseite nutzen zu können). Sämtliche Umwandlung und Kompression bzw. Dekompression, die aufgrund von Unterschieden im DBS-internen Speicherformat und dem für die Anwendung benötigten Format erforderlich werden, erfolgt DBS-intern und für die Anwendung unsichtbar.

Wird z. B. eine TIFF-Codierung angefordert (vorausgesetzt, TIFF ist auf die vorliegende Array struktur anwendbar), dann wird die eingebaute Funktion tiff () aufgerufen. Beispiel: "Alle Land sat-TM-Bilder in TIFF-Format":

select tiff(LandsatTM.data)

Wie die meisten anderen Bilddatenformate auch, beinhaltet TIFF weitere sogenannte Registrie rungsdaten; diese werden vom DBS auf Nullwerte gesetzt.

Im Fall von JPEG muß zusätzlich der Prozentsatz der Qualitätsreduktion angegeben werden, da JPEG mit wählbarer Verlustrate komprimiert:

select jpeg(LandsatTM.data, 25)

Die datenbank-interne Repräsentation ist der Anwendung nicht bekannt; sie kann, muß aber nicht eines dieser Formate sein. Falls das interne Format nicht dem angeforderten entspricht, erzeugt der Anfrageprozessor den erforderlichen Code zur Umwandlung.

Systemarchitektur

Vorzugsweise wird für ein Raster-DBS eine Hardware-Architektur wie in Abb. 1 und eine Soft ware-Architektur wie in Abb. 8 eingesetzt. Die Anwendungsschnittstelle (API) bietet zwei grund sätzliche Zugriffswege: Der Anfrageprozessor erlaubt die Definition und Manipulation von Arrays wie oben beschrieben; insbesondere erstellt er den Plan für die Anfragebearbeitung. Die Rasterim port- und -exportschnittstelle dient als Massendaten-Schnittstelle im Fall, daß Arrays als Ganzes ein- oder ausgelagert werden sollen. Dieser Spezialfall des Rasterdatenzugriffs erfordert nur sehr einfache Operationen, aber sehr effiziente Abarbeitung, weswegen er vorteilhaft eigens unterstützt wird. Der Anfrageoptimierer versucht, den Abarbeitungsplan so umzustellen, daß verschiedene Dienstqualitäts-Kriterien wie Anzahl der Plattenzugriffe, Kompressions/Dekompressionsaufwand und Netzlast optimiert werden. Das Basis-Zugriffsmodul bildet die virtuelle Maschine, auf der der Anfrageprozessor den Abarbeitungsplan ausführt. Hier werden Kacheln geladen, der angeforderte Inhalt wird daraus extrahiert, induzierte Operationen werden ausgeführt und das Anfrageergebenis wird vorbereitet und in das angeforderte Datenformat konvertiert. Der Speicherverwalter bearbei tet vollständige Kacheln, für die Schreib- und Lese primitive angeboten werden. Zur Beschleuni gung der Kachelbestimmung wird intern ein Geo-Index mitgeführt.

Innerhalb einer Kachel erfolgt eine konventionelle Linearisierung oder eine beliebige andere Spei cherabbildung. Der Speicherverwalter setzt auf einer Schnittstelle auf, die persistente, direkt adres sierbare Datenbereiche fester oder variabler Länge und ohne weitere Semantik bietet.

Es ist möglich - allerdings nicht notwendig - ein konventionelles DBS (z. B. relational oder objekt orientiert) unter den Speicherverwalter zu setzen, um Transaktions-, Recovery- und weitere Basis mechanismen auszunutzen. In diesem Fall dient das unterliegende DBS als persistenter Speicherverwalter, der Kacheln und/oder Index-Records z. B. in Blobs verwaltet, ohne besondere Kenntnis der Semantik zu besitzen. Beispielsweise kann in einem relationalen DBS eine Relation Teiles definiert sein, die die Kacheln aller Arrays, unabhängig von ihrer Dimension, aufnimmt:

Tiles (oid: integer, tid: integer, c_e: integer, tile: long)

Dabei ist oid der Objektidentifikator des Arrays, tid ist der Kachelidentifikator, in c_e ist die jeweilige Kachelcodierung und -kompression vermerkt, und tile enthält die Kacheldaten selbst. Man beachte, daß an jeder Stelle in dieser Architektur Netzwerkkommunikation stattfinden kann; insbesondere können Arrayaufbau aus Kacheln bzw. Arrayzerlegung in Kacheln sowie Kompres sion und Dekompression vom Server zur Applikationsmaschine verlegt werden, wobei jedoch auf strikte Transparenz zu achten ist.

Anfragebearbeitung

Im folgenden wird von einer DML-Spracheinbettung in C und einer vereinfachten API-Funktion dbCall () Gebrauch gemacht, um die Grundprinzipien der Anfragebearbeitung zu erläutern. Um die volle oben beschriebene Funktionalität bereitzustellen, sind aufwendigere Interface-Techniken erforderlich, wie sie z. B. in relationalen DBSen Stand der Technik sind.

Codierung/Kompression versteht sich immer ausgehend vom Hauptspeicherformat, Decodierung/ Dekompression geschieht immer in das Hauptspeicherformat der jeweils benutzten Plattform. Dazu besitzt jedes Array einen Indikator, der sein aktuelles Datenformat angibt. In der Datenbank ist er mit der Kachel abgelegt; am API wird er entweder durch die Applikation explizit gesetzt oder vom Präprozessor implizit im Zuge der Quellcode-Analyse erzeugt.

Für die Beschreibung des Verfahrens wird davon ausgegangen, daß zwischen dem Datenbankser ver einerseits und dem Datenbank-API und der Anwendung andererseits Netzwerkkommunikation stattfindet, die bei heterogenen Plattformen eine Übertragungscodierung notwendig macht. Dabei kann zur Verringerung des Kommunikationsaufwands Kompression stattfinden. Die zur Anwen dung kommenden Verfahren zur Kompression und das Codierung von Arrays werden nicht weiter spezifiziert, da sie nicht Gegenstand der vorliegenden Erfindung sind; es können beliebige Metho den eingesetzt werden.

Die Kommunikation via Netzwerk kann an der angegebenen Stelle in der Systemarchitektur erfol gen, sie kann ganz entfallen oder sie kann zwischen anderen DBS-Komponenten stattfinden (vgl. die Pfeile in Abb. 8), wobei die Codierung auf den jeweils auftretenden Einheiten (z. B. Kacheln) erfolgen muß.

Retrieval

Für die Anfrage "Den Landsat-TM-Ausschnitt zwischen (50, 100) und (100, 200), davon den Kanal c3" sei folgendes C-Codestück im Anwendungsprogramm formuliert:

Die zwei Doppelkreuze ## machen die Statements dem Präprozessor bekannt, der aus diesem Quellcode Datenbank-API-Aufrufe generiert. Diese werden um Angaben zum Datenformat ergänzt. Programmvariablen sind hier durch einen vorangestellten Doppelpunkt gekennzeichnet, der vom Präprozessor bei der Codeerzeugung ausgefiltert wird:

Der erste dbCall ()-Parameter ist der Anfragestring, wie er an den Anfrageprozessor übermittelt wird; der Variablenname in der into-Klausel ist ersetzt durch einen Positionsindikator für den ersten (und hier einzigen) Resultatparameter landsatPart. Der zweite Parameter ist ein Zeiger auf das Resultatarray, in das vom API das Anfrageergebnis gestellt wird. Der dritte Parameter signalisiert dem API, ob das Ergebnisarray in der direkten Darstellung der Anwendung (CLIENT_INTER NAL_FORMAT) oder in einem in der Anfrage genauer spezifizierten Datenformat (EXTERNAL_FOR MAT) abzuliefern ist; aufgrund des Formatindikators CLIENT_INTERNAL_FORMAT als letztem Parameter wird das API nach erfolgter Anfragebearbeitung durch das DBS das Anfrageergebnis in der Programmvariablen landsatPart in der direkten Darstellung der Applikation bereitgestellt. Soll das Anfrageergebnis in einem dem DBS bekannten anderen Datenformat geliefert werden, dann macht die Applikation dies durch den Aufruf der zugehörigen Konversionsfunktion bekannt, beispielsweise durch den Aufruf einer Standardfunktion jpeg () zur JPEG-Codierung mit 25% Reduktion:

Der Präprozessor generiert daraus

Damit stellt das API das vom Server generierte Array in der Programmvariablen landsatPart JPEG-codiert bereit.

Bei der Ausführung derartiger Datenbankaufrufe erfolgt die weitere Bearbeitung der Anfrage gemäß obiger Architektur nach folgendem Algorithmus (Abb. 6):

1. übertrage Anfrage zum Server;
2. erzeuge und optimiere Anfrageplan aus der Anfrage;
3. allokiere das Resultatarray;
4. bestimme unter Zuhilfenahme des Geo-Index die M Menge der betroffenen Kacheln;
5. für alle Kacheln k_i aus M;
5.1 lade k_i in den Hauptspeicher;
5.2 decodiere k_i gemäß Codierungsinformation der Kachel;
5.3 dekomprimiere k_i gemäß Codierungsinformation der Kachel;
5.4 kopiere relevante Zellen aus k_i gemäß Anfrageplan in das Resultatarray;
6. führe restliche Operationen gemäß Anfrageplan auf dem Ergebnisarray aus;
7. falls für das Resultatarray die direkte Darstellung der Anwendung angefordert ist:
7. 1 komprimiere das Array;
7.2 codiere das Array;
8. transferiere Resultatarray zur Anwendung;
9. falls für das Resultatarray die direkte Darstellung der Anwendung an gefordert ist:
9.1 decodiere das Array in das Hauptspeicherformat der Anwendung;
9.2 dekomprimierte das Array;

In Schritt 1 wird die Anfrage vom Client zum Server übertragen. Im nächsten Schritt wird der Zugriffsplan vom Anfrageprozessor und dem Optimierer erstellt. In Schritt 3 wird im Server der Speicherplatz für das Anfrageergebnis bereitgestellt. Der Speicherverwalter bestimmt in Schritt 4 aus dem Anfrageplan unter Zuhilfenahme des Geo-Index die Menge der betroffenen Kacheln M. Gesteuert vom Anfrageprozessor, lädt das Basis-Zugriffsmodul diese Kacheln der Reihe nach (5.1), expandiert (5.2) und dekomprimiert (5.3) sie in die direkte Darstellung des Servers und kopiert den relevanten Ausschnitt in das Resultatarray (5.3); In den Schritten 5.2 und 5.3 wird die bei jeder Kachel gespeicherte Information, nach welchem Verfahren der Kachelinhalt codiert und komprimiert wurde, verwendet (vgl. Abschnitt 5.2). Eventuelle weitere Anweisungen aus dem select-Teil der Anfrage werden vom Basis-Zugriffsmodul in Schritt 6 ausgeführt; unter anderem zählt dazu eine eventuell von der Anwendung angeforderte Umwandlung des Ergebnisses in ein Format, das von der direkten Darstellung der Anwendung verschieden ist.

Falls das Ergebnisarray in einem solchen Datenformat codiert ist, wird es in allen folgenden Schrit ten als Bytestring ohne weitere Semantik betrachtet und in Schritt 8 zur Anwendung transferiert, d. h. Schritt 7 und 9 entfallen. Anderenfalls wird das Array, das in der direkten Darstellung des Ser vers vorliegt, auf der semantischen Ebene des Arrays (also unter Ausnutzung des Strukturwissens) komprimiert und codiert (Schritt 7) und auf der Anwendungsseite im API wieder decodiert und dekomprimiert (Schritt 9). Damit liegt das Ergebnisarray schließlich in dem von der Anwendung angegebenen Speicherbereich entweder in der direkten Darstellung der Applikation oder im son stigen angeforderten Datenformat vor.

Update

Als Beispielsanfrage diene "Ersetze in allen Landsat-TM-Bildern im Kanal c3 im Bereich zwischen (51, 101) und (100, 200) die Werte durch das Array e". Das entsprechende C-Codestück lautet

Der Präpozessor erzeugt daraus

Auf den ersten Parameter mit dem Anfragestring (der Variablenname ist wiederum ersetzt durch den Positionsindikator) folgt die Programmvariable e mit dem Eingabearray. Aufgrund des For matindikators CLIENT_INTERMAL_FORMAT als letztem Parameter erwartet das API eine direkte Darstellung der Daten in e.

Liegen die Eingabedaten in einem anderen dem DBS bekannten Format vor, dann macht die Appli kation dies durch den Aufruf der zugehörigen Konversionsfunktion bekannt, beispielsweise durch den Aufruf einer Standardfunktion inv_jpeg () zur JPEG-Decodierung:

und der Präprozessor generiert daraus

Das API transferiert den Inhalt von e zum Server, so daß dort ein JPEG-codiertes Array ankommt.

Die weitere Ausführung durch das DBS geschieht gemäß obiger Architektur nach folgendem Algo rithmus (vgl. Abb. 7):

1. falls das Eingabearray in der direkten Darstellung der Anwendung vorliegt:
1.1 komprimiere das Array;
1.2 codiere das Array;
2. übertrage Anfrage und Eingabearray zum Server;
3. falls das Eingabearray in der direkten Darstellung der Anwendung vorliegt:
3.1 decodiere das Array;
3.2 dekomprimiere das Array;
4. erzeuge und optimiere Anfrageplan aus der Anfrage;
5. modifiziere Eingabearray gemäß Anfrageplan;
6. bestimme mittels Geo-Index die Menge M der betroffenen Kacheln;
7. für alle Kacheln k_i aus M:
7.1 lade k_i in den Hauptspeicher;
7.2 decodiere k_i;
7.3 dekomprimiere k_i;
7.4 schreibe relevante Zellen aus dem Eingabearray nach k;
7.5 codiere k_i;
7.6 komprimiere k_i;
7.7 speichere k_i;

Falls das Eingabearray in der direkten Darstellung der Anwendung vorliegt, wird es in Schritt 1 mittels eines Verfahrens zur Array-Kompression und -Codierung in ein systemneutrales Format konvertiert, in Schritt 2 zusammen mit der Anfrage zum Server übertragen und dort in die direkte Darstellung des Servers übergeführt (Schritt 3.1 und 3.2). Liegt das Eingabearray in einem anderen Format vor, dann wird es beim Transfer als Bytestring ohne weitere Semantik betrachtet und in Schritt 2 zum Server transferiert.

In Schritt 4 wird die Anfrage in den internen Anfrageplan übersetzt und optimiert. Bei seiner Aus führung werden zuerst in Schritt 5 in der Anfrage spezifizierte Modifikationen auf dem Eingabear ray vorgenommen; unter anderem wird das Eingabearray, falls es codiert vorliegt, durch Anwendung der in der Anfrage spezifizierten Konversionsfunktion in die direkte Darstellung des Servers übergeführt.

Aus den Trimm-Angaben in der Anfrage bestimmt der Speicherverwalter im Schritt 6 mithilfe des Geo-Index die betroffenen Kacheln, welche im Schritt 7.1 vom Speicherverwalter geladen und an das Basis-Zugriffsmodul übergeben werden. Gesteuert vom Anfrageprozessor, expandiert dieses die Kacheln (Schritt 7.2 und 7.3) abhängig von der Codierungsinformation bei jeder Kachel, aktua lisiert die Kacheln mit den relevanten Zellen aus dem expandierten Eingabearray (7.4), führt die Kacheln wieder in das vom Kachelindikator vorgegebene Speicherformat zurück (Schritt 7.5 und 1.6) und übergibt sie schließlich wieder an den Speicherverwalter zum Zurückschreiben in die Datenbank (7.7).

Erfindungswesentliche Gedanken

1. DBS zur Verwaltung von Arrays. Das DBS kann als eigenständiges System implementiert sein oder als Bestandteil eines anderen DBS.
2. Besagtes DBS mit der Fähigkeit, Arrays
- - mit einer beliebigen Anzahl von Dimensionen
- - einer beliebigen, unter Umständen variablen Anzahl von Zellen pro Dimension
- - über beliebigen Basistypen.
zu verwalten.
3. Logische Ebene:
- - Das DBS besitzt eine DDL zur Strukturdefinition von Arrays.
- - Das DBS besitzt eine DML im herkömmlichen Datenbank-Sinn, die Arrays mittels beliebi ger Ausdrücke und Prädikate (evtl. gemischt mit solchen über konventionellen Datentypen) zu bearbeiten erlaubt.
- - Datenunabhängigkeit auf Rasterdaten: Die Präsentation von Arraydaten durch das DBS ist unabhängig vom datenbank-internen Speicherformat, der Codierung und Kompression sowie von Programmiersprache, Betriebssystem und Hardware von Client und Server. Die Appli kation kann auswählen, welches Format die Rasterdaten besitzen sollen; zur Auswahl stehen die maschineninterne Hauptspeicherdarstellung in der Applikation sowie eine beliebige Anzahl von Datenaustauschformaten.
4. Physische Ebene:
- - Das DBS verwendet eine Kombination aus n-dimensionaler Kachelungstechnik und einem n-dimensionalen Geo-Index, um eine schnelle und effiziente Verwaltung von Arrays beliebi ger Größe und Dimension zu erreichen.
- - Jede Kachel kann individuell auf einem beliebigen Speichermedium abgelegt werden, so daß das DBS ein Array über eine beliebige Anzahl möglicherweise heterogener Datenträger ver teilen kann, ohne daß dies der Anwendung sichtbar wird.
- - Das DBS kann intern eine Vielzahl von Kompressionsverfahren einsetzen, um die Ablage und Übertragung von Rasterdaten zu optimieren, ohne die Kompression/Dekompression für die Anwendung sichtbar zu machen.
- - Durch einen Indikator, der mit jeder Kachel gespeichert wird, kann die Codierung und Kom pression für jede Kachel einzeln festgelegt werden; insbesondere lassen sich verschiedene Kacheln desselben Arrays unterschiedlich behandeln.
- - Jedes Array im Hauptspeicher (beim DBS-Server oder im API auf Client-Seite) besitzt einen Indikator für die Codierung/Kompression, in der es vorliegt; dieser Indikator ist wesentlich, um beliebige Datenformate auf API-Ebene anbieten zu können, also zur Realisierung von Datenunabhängigkeit.
- - Ein Anfrageoptimierer kann, basierend auf der Datendefinition, der Speicherorganisation sowie anderer brauchbarer Information, den Ausführungsplan einer Anfrage nach einer Viel zahl von Methoden so reorganisieren, daß Dienstqualitätskriterien wie CPU-Last, Speicher zugriff, Netzlast und Antwortzeiten optimiert werden.
- - Als mögliche Implementierung können Kacheln auf Attribute eines anderen DBS (z. B. rela tional oder objektorientiert) dergestalt abgebildet werden, daß jedes Tupel bzw. jedes Objekt eine Kachel enthält (zuzüglich etwaiger Verwaltungsinformation). Damit lassen sich mit beschränktem Aufwand klassische Datenbankeigenschaften wie Transaktionsschutz und Recovery realisieren.

Literaturreferenzen

[Baum-94]

P. Baumann: On the Management of Multidimensional Discrete Data. VLDB Journal 3(4) 1994, Special Issue on Spatial Databases, pp. 01-444

[Guet-94]

R. H. Gueting: An Introduction to Spatial Database Systems. VLDB Journal 3(4)1994, Special Issue on Spatial Databases, pp. 357-400

[MwLW-89]

K. Meyer-Wegener; W. Lum; C. Wu: Image Management in a Multimedia Database. Proc. Wor king Conference on Visual Databases, Tokyo, Japan, April 1989, Springer 1989, pp. 29-40

[SaSt-94]

S. Sarawagi, M. Stonebraker: Efficient Organization of Large Multidimensional Arrays. Proc. 10th Int. Conf. on Data Engineering, February 1994

[Tamu-80]

H. Tamura: Image Database Management for Pattern Infornzation Processing Studies. S. Chang, K. Fu (eds): Pictorial Information Systems, Lecture Notes in Computer Science Vol. 80, Springer 1980, pp. 198-227

[VaDe-91]

S. Vandenberg, D. DeWitt: Algebraic Stipport for Complex Objects with Arrays, Identity, and Inheritance. Proc. ACM SIGMOD Conf. 1991, pp. 158-167

Claims

1. Datenbanksystem mit einer Speichereinrichtung zum Speichern von codierten und/oder komprimierten multidimensionalen Ar raydaten, einer Anwendungsprogrammierschnittstelle und einer Verarbeitungseinrichtung zum Durchführen einer Abspeiche rungs- oder Abfrageverarbeitung von Arraydaten und zum Be reitstellen verarbeiteter Daten an die Speichereinrichtung oder an die Anwendungsprogrammierschnittstelle, wobei das Verarbeiten und Bereitstellen an die Speichereinrichtung in einem internen Datenformat erfolgt und das Verarbeiten und Bereitstellen an die Anwendungsprogrammierschnittstelle in einem über die Anwen dungsprogrammierschnittstelle beliebig wählbaren Datenformat erfolgt.

2. Datenbanksystem nach Anspruch 1, wobei das Verarbeiten und Bereitstellen an die Anwendungsprogrammierschnittstelle wahl weise in einem zur unmittelbaren Weiterverarbeitung durch eine Anwendung geeigneten Datenformat oder einem über die An wendungsprogrammierschnittstelle beliebig wählbaren Datenfor mat erfolgt.

3. Datenbanksystem nach Anspruch 1 oder 2, wobei die Eingabe von Arraydaten über die Anwendungsprogrammierschnittstelle in einem beliebigen Datenformat erfolgt.

4. Datenbanksystem nach einem der Ansprüche 1 bis 3, wobei die Anwendungsprogrammierschnittstelle eine deklarative Schnitt stelle zur Definition, Abspeicherung, Änderung und Wiederge winnung von Arrays beinhaltet.

5. Datenbanksystem nach einem der Ansprüche 1 bis 4, wobei die Verarbeitungseinrichtung eine Import-/Exportschnittstelle, einen Anfrageprozessor und einen Anfrageoptimierer umfaßt.

6. Datenbanksystem nach einem der Ansprüche 1 bis 5, wobei die Speichereinrichtung einen Speicherverwalter umfaßt.

7. Verfahren zum Verarbeiten multidimensionaler Arraydaten in ei nem Datenbanksystem mit den folgenden Schritten:

1. Komprimieren und Codieren eines über eine Anwendungs programmierschnittstelle eingegebenen Arrays, falls das ein gegebene Array in einem zur unmittelbaren Weiterverarbei tung durch eine Anwendung geeigneten Datenformat vor liegt;
2. Übertragen eines in Schritt 1 eingegebenen Arrays und einer eingegebenen Anfrage an eine Verarbeitungseinheit;
3. Decodieren und Dekomprimieren des Arrays, falls das Array in einem zur unmittelbaren Weiterverarbeitung durch die Anwendung geeigneten Datenformat vorliegt;
4. Erzeugen und Optimieren eines Anfrageplanes aus der einge gebenen Anfrage;
5. Modifizieren des Eingabearrays gemäß dem Anfrageplan;
6. Ermitteln von durch den Anfrageplan betroffenen Arraydaten oder Array-Teildaten, die in einer Speichereinrichtung des Datenbanksystems abgespeichert sind;
7. Laden in die Verarbeitungseinrichtung, Decodieren und De komprimieren der ermittelten Arraydaten oder Array- Teildaten, Überschreiben der Arraydaten oder Array- Teildaten mit den Daten des eingegebenen Arrays und an schließendes Codieren, Komprimieren und Abspeichern der überschriebenen Arraydaten oder Array-Teildaten.

8. Verfahren nach Anspruch 7, wobei Schritt 5 das Übersetzen des Eingabearrays aus einem beliebigen Datenformat umfaßt.

9. Verfahren nach Anspruch 7 oder 8, wobei die Arrays unter Zuord nung eines Indexes in Array-Teildaten unterteilt in der Spei chereinrichtung abgespeichert sind und wobei die Ermittlung der betroffenen Arraydaten oder Array-Teildaten in Schritt 6 anhand des Indexes erfolgt.

10. Verfahren zum Verarbeiten multidimensionaler Arraydaten in ei nem Datenbanksystem mit den folgenden Schritten:

1. Übertragen einer über über eine Anwendungsprogrammier schnittstelle eingegebenen Anfrage an eine Verarbeitungs einheit;
2. Erzeugen und Optimieren eines Anfrageplans auf der Grund lage der eingegebenen Anfrage;
3. Allokieren von Speicherplatz für durch die Anfrage gewon nene Resultatarrays;
4. Ermitteln von durch den Anfrageplan betroffenen Arraydaten oder Array-Teildaten, die in einer Speichereinrichtung des Datenbanksystems abgespeichert sind;
5. Laden in die Verarbeitungseinrichtung, Decodieren und De komprimieren der ermittelten Arraydaten oder Array- Teildaten, Kopieren von relevanten Array-Teildaten in das Resultatarray gemäß dem Anfrageplan;
6. Ausführen weiterer Operationen gemäß dem Anfrageplan;
7. Komprimieren und Codieren der Arraydaten, falls die Darstel lung in der Eingabe- und Ausgabeeinrichtung in einem zur unmittelbaren Weiterverarbeitung durch die Anwendung ge eigneten Datenformat angefordert ist;
8. Übermitteln des Resultatarrays an die Anwendungspro grammierschnittstelle;
9. Decodieren und Dekomprimieren des Resultatarrays, falls die Darstellung in der Eingabe- und Ausgabeeinrichtung in einem direkten Anwendungsformat angefordert ist.

11. Verfahren nach Anspruch 10, wobei Schritt 6 die Erzeugung eines beliebigen Datenformats umfaßt.

12. Verfahren nach Anspruch 10 oder 11, wobei die Arrays unter Zu ordnung eines Indexes in Array-Teildaten unterteilt in der Spei chereinrichtung abgespeichert sind und wobei die Ermittlung der betroffenen Arraydaten oder Array-Teildaten in Schritt 4 anhand des Indexes erfolgt.

13. Verfahren nach Anspruch 9 oder 12, wobei die Array-Teildaten Kacheln sind.

14. Verfahren nach einem der Ansprüche 9, 12 oder 13, wobei der Index ein Geo-Index ist.