Information, die sich nicht alphanumerisch darstellen läßt, wurde in der Vergangenheit pauschal als "unstrukturiert" mißdeutet und entweder gleich außerhalb der Datenbank in Dateien oder im "Datei-Ersatz" Blob gespeichert. Nun sind aber Rasterbilder zum Beispiel alles andere als unstrukturiert. Im Gegenteil: Sie weisen eine extrem reguläre Struktur auf, sogenannte Arrays, und zwar über einem bestimmten, vordefinierten Basistyp. Bei der Abbildung auf die Byteketten der Blobs geht jedoch die gesamte Semantik verloren:
- Die Dimension ist unbekannt, und damit ist selbst eine der grundlegenden Operationen, die Extraktion eines Bildausschnitts, unmöglich.
- Der Basistyp ist unbekannt, und folglich kann der Wert einzelner Pixel (oder abstrakt: Zellen) nicht abgefragt werden, geschweige denn abgeleitete Information wie die maximale und minimale Helligkeit eines Bildes.
Der Anwendungsentwickler legt ein bestimmtes Datenformat und Kompressionsverfahren fest. Ein Bild auszulesen, ist nur in exakt dem gleichen Format möglich, in dem es in die Datenbank eingebracht wurde. Weitere Unzulänglichkeiten der Blobs liegen in ihrer Architektur begründet.
- Die übliche Begrenzung der Blobs auf maximal 2 GB ist für viele heutige Anwendungen völlig inakzeptabel; so belegt eine einzige Klimasimulation 5 bis 50 GB.
- Da jedesmal das gesamte Blob gelesen (Plattenzugriffe) und übertragen (Netzverkehr) werden muß, leidet die Performance erheblich. Letztendlich führt die geringe Funktionalität und schlechte Performance der Blobs zu aufwendigen, fehleranfälligen und schwer wartbaren Applikationsprogrammen, die leistungsfähige, sprich teure Client-Hardware erfordern.
Dabei bilden MDD durchaus keine Randgruppe. Hat man sich erst einmal von der Blob-Denkweise befreit, dann erkennt man plötzlich eine Vielzahl weiterer Informationstypen dieser Art: Fax, EKG und Audio (1D), Rasterbilder (2D), Animationen und Voxeldaten (3D), animierte Voxeldaten wie Klimasimulationen (4D), der ISO/IEC-Imaging-Standard PIKS (5D) sowie Data-Warehouses (zum Beispiel 8D bis 15D).
Allgemein gesehen, fallen MDD immer dann an, wenn natürliche raum-zeitliche Phänomene von bildgebenden Sensoren (zum Beispiel Satelliten) oder anderen Meßwert-Aufnehmern (zum Beispiel Seismographen) digitalisiert werden. Aber auch rechnergenerierte Information wie Data-Warehouses oder Klimasimulationen führen zu MDD.
Ziel einer leistungsfähigen MDD-Verwaltung muß es daher sein, hohe Funktionalität zu bieten, beliebig große Datenvolumina zu unterstützen und dabei durch intelligente Optimierung hochperformant zu sein. Nachdem die Struktur dieser unstrukturierten Daten in letzter Zeit immer mehr erkannt wurde, laufen zur Zeit große Anstrengungen im Datenbankbereich, die Informationskategorie MDD zu unterstützen.
Auf kommerzieller Seite wird großes Augenmerk auf die effiziente Verwaltung von Unternehmensdaten gelegt. Eine wesentliche Besonderheit dieses Anwendungsgebiets ist, daß große Teile des Datenwürfels (95 Prozent) Nullwerte enthalten, der Datenwürfel ist somit dünn besetzt. Im technisch-wissenschaftlichen Bereich unterstützt QBISM (eine medizinische Datenbank für die Forschung) Ablage und Retrieval von mehrdimensionalen medizinischen Daten, während zum Beispiel "Paradise" (eine Geo-Datenbank für die Forschung) Rasterfunktionalität in einem Geo-Informationssystem bietet.
Vor allem in den USA werden - im Zuge des Aufbaus einer National Spatial Infrastructure - Speichertechniken entwickelt, um durch die Anbindung von Tertiärspeichermedien (insbesondere Bandarchiven) eine durchgängige Speicherhierarchie anzulegen. Systeme wie zum Beispiel "Optimass" vom Lawrence Livermore National Laboratory in Berkeley bieten zwar keine allgemeine Anfragesprache, können dafür aber Ausschnittsinformation in Terabyte-Datenbanken um mehrere Größenordnungen schneller bereitstellen als konventionelle Systeme.
Im EU-Projekt "Rasdaman" (siehe Seite 60) entwickelt das Bayerische Forschungszentrum für wissensbasierte Systeme (Forwiss) in München ein anwendungsneutrales Raster-DBMS für MDD-Objekte beliebiger Größe und Dimension.
Eingebettet in ein ODMG-konformes C++-API (ODMG = Objekt Data Management Group) steht eine SQL-Schnittstelle zur Verfügung, die um High-Level-Konstrukte zur MDD-Bearbeitung angereichert wurde. Anfrageergebnisse werden wahlweise im Hauptspeicherformat der Anwendung geliefert - so daß eine unmittelbare Weiterverarbeitung erfolgen kann - oder aber in einem von der Anwendung gewählten Datenformat, unabhängig von dem Format, in dem die Daten importiert wurden. MDD-Objekte beliebiger Dimension werden auf kleine, mit konventioneller Datenbanktechnologie verwaltbare Einheiten abgebildet. Ein wesentlicher Vorteil dieses Ansatzes ist, daß beliebige relationale und objektorientierte Datenbanksysteme als Plattform eingesetzt werden können.
Clusterungsmöglichkeiten waren ausschlaggebend
Nach einer Evaluierung verschiedener Systeme - einschließlich MDD-spezifischer Benchmarks - fiel die Wahl auf O2 von O2 Tech., Frankreich. Neben der Konformität mit dem ODBMS-Standard ODMG waren die Clusterungsmöglichkeiten von O2, die wesentlich zur Performance des Gesamtsystems beitragen, ein ausschlaggebendes Kriterium. Eine transparente Tertiärspeicheranbindung erlaubt es, auch extreme Datenmengen im Online-Zugriff zu halten. Durch intelligente Anfrageoptimierung kann die Datenbank-Engine die Zugriffe auf Sekundär- und Tertiärspeicher sowie den Netzverkehr zur Anwendung minimieren. Erstmals werden so alle klassischen Vorteile eines DBMS auch für dimensionsbehaftete Daten verfügbar.
Wiewohl die Idee der datenbankgestützten Verwaltung von MDD noch recht jung ist, darf man in den nächsten Jahren mit einer stürmischen Entwicklung und ständig wachsenden Marktvolumen sowie neuen Datenbanklösungen rechnen.
Das EU-Projekt "Rasdaman"
In dem EU-geförderten Espritprojekt Raster Data Management in Databases (RasDaMan) entsteht ein anwendungsneutrales Raster-DBMS mit MDD-beliebiger Größe und Dimension. Es wird momentan durch Beispielapplikationen in den Bereichen Medizin (PACS) und Geo-Informationssysteme in der Praxis getestet. Projektpartner sind Forwiss, STI S.A. (ein Softwarehaus in Madrid), das Geo-Forschungszentrum Potsdam, das Hospital General de Manresa (nahe Barcelona) und das spanische Nationale Geografische Institut.
Das dreijährige Forschungsprojekt läuft seit Ende 1996. Mittlerweile ist der erste Prototyp fertiggestellt und war auf der diesjährigen CeBIT im Stand des Deutschen Forschungsnetzes (DFN) zu sehen. Weitere Information sind im WWW unter http://www.forwiss.tu-muenchen.de/rasdaman zu finden.
Medizinische Bildverwaltung
Klinische Informationssysteme haben Tag für Tag eine kontinuierliche Flut von Bilddaten unterschiedlichster Art, sogenannte Modalitäten, zu bewältigen. Ungefähr 3 GB pro Tag beziehungsweise 1 TB (= 1000 GB pro Jahr) beträgt im Schnitt das Datenaufkommen in einem Krankenhaus. Rasterdatenbanksysteme können durch ihre flexiblen Selektionsmechanismen in großen Rasterdatenbeständen wertvolle Unterstützung leisten. Dem behandelnden Arzt helfen bei seiner Diagnose unterschiedliche Projektionen in volumetrischen Daten, Ausschnitte, Zoom und der Vergleich mit ähnlichen Fällen in der Patientendatenbank. Die teure Workstation auf dem Schreibtisch des Arztes läßt sich durch einen preisgünstigen PC ersetzen. Aber auch Forschung und Pharmakonzerne sind stark daran interessiert, daß der immense, bisher weitgehend ungenutzte Datenfundus aus Versuchsergebnissen den immer differenzierteren Analysen zur Verfügung steht.
Geo- und Umweltinformationssysteme
Bei der satellitengestützten Fernerkundung der Erde strömen permanent hohe Datenmengen zur Bodenstation, wo sie archiviert, verarbeitet und in veredelter Form verschiedensten Kunden zur Verfügung gestellt werden. Beispielsweise plant die NASA im Projekt Mission to Planet Earth, sechs Satelliten zu starten, die täglich 1 TB und im Laufe der 15 Missionsjahre 10 Petabyte (= 10000 TB) an Daten liefern und im WWW verfügbar sein sollen. Ein weiteres Beispiel ist die Sensorfusion. Die datenintensive Korrelation von 2D-Satellitenbildern mit 1D-Gewässerverschmutzungsdaten, wie sie durch Fluß-Bojen geliefert werden, erfolgt hier am besten direkt in MDD-Daten- banken.
Fallbeispiel: Simulationen
Vierdimensionale Klimasimulationen sind uns aus der täglichen Wettervorhersage wohlvertraut, ohne daß das dabei generierte Datenvolumen sichtbar wird. Die von Supercomputern errechneten Klima- und Meeresströmungsmodelle führen zu Ergebniswürfeln in der Größenordnung zwischen 5 und 50 GB. Im Automobilbau, in der Luftfahrt und zunehmend auch im Schiffsbau ersetzt man aufwendige Experimente an teuren Prototypen durch Simulationen am CAD-Modell. Die Analyse der Ergebnisse geschieht durch Visualisierungswerkzeuge, deren Datenzugriff einer effizienten Rasterdatenhaltung bedarf.
Ein generisch multidimensionales OLAP
Data-Warehouses verwenden eine multidimensionale Sicht auf aggregierte Unternehmensdaten. Relationales OLAP (Rolap) und generisch multidimensionales Olap (Molap) konkurrieren derzeit scharf auf dem Markt. Längerfristig scheint sich eine Koexistenz beider Lösungen abzuzeichnen. Standard-Schnittstellen für Herstellerunabhängigkeit sind daher gefragt.
Multidimensionale Diskrete Daten (MDD)
Bleibt abschließend die Frage, ob MDD relational, objektorientiert oder objektrelational sind. Entgegen oft und vehement geäußerten Herstelleraussagen ist die MDD-Problematik unabhängig von relationalen und objektorientierten Datenbanksystemen. Beide Typen bieten derzeit - soweit es sich um allgemein einsetzbare Systeme und nicht um Speziallösungen wie GIS und OLAP handelt - nur Blobs an. Auch mit der Erweiterbarkeit objektrelationaler Systeme wie etwa Informix/Illustra ist das Problem der MDD-Verwaltung noch lange nicht gelöst. Erstens muß die MDD-Erweiterung auch weiterhin implementiert werden, denn eine generische MDD-Unterstützung existiert bislang nicht. Und zweitens erlauben objektrelationale Systeme nicht die Art von Erweiterungen, die eine wirklich einheitliche MDD-Bearbeitung über beliebige Dimensionalität hinweg gestatten würde.
Angeklickt
Datenbanksysteme für Multidimensionale Diskrete Daten (MDDBMSe) müssen drei wesentliche Anforderungen erfüllen: hohe, flexibel einsetzbare Funktionalität, die Verwaltung extrem hoher Datenvolumina bis in den oberen Terabyte-Bereich sowie hohe Performance, die von der Größe des Anfrageergebnisses und nicht von der der Gesamtdatenbank bestimmt wird. Wesentliche Voraussetzungen sind eine intelligente Anfrageoptimierung im Datenbank-Server und eine für MDD optimierte Speicherverwaltung unter Einbeziehung von Tertiärspeicher.
*Dr. Peter Baumann ist stellvertretender Leiter der Forschungsgruppe "Wissensbasen" im Bayrischen Forschungszentrum für Wissensbasierte Systeme (Forwiss) in München.