Nur ein geringer Teil aller Daten ist in relationalen Datenbanktabellen gespeichert, die meisten elektronisch abgelegten Informationen liegen in anderen Strukturen vor: als Text, Bild, Ton, als Zeitreihe etc. Internet und Multimedia werden den nichtrelationalen "objektorientierten" Anteil gespeicherter Informationen in den nächsten Jahren noch einmal deutlich erhöhen.

Das bisherige relationale Modell hat allerdings den Vorteil, daß es auf einer mathematisch sauber formulierbaren Theorie beruht. Dadurch ist es sehr sicher und für bestimmte Zwecke im betriebswirtschaftlichen Bereich auch durchaus intuitiv eingängig. In methodischer Hinsicht ist das relationale Paradigma ein - unter anderem sicherheitstechnisch optimierter - Sonderfall des objektorientierten Beschreibungsansatzes.

Dieser neue Beschreibungs- oder Modellierungsansatz wird sicher in seiner ganzen Breite zur Abbildung der realen Welt zum Einsatz kommen. Anwendungen wie Präsentationen über das Internet und vor allem Web-orientierte, integrierte geschäftliche Transaktionen sowohl im inner- und zwischenbetrieblichen Sektor als auch in Richtung Endverbraucher werden dies zwingend erforderlich machen.

Die Kombination relationaler und nichtrelationaler Daten wird dabei sehr häufig sein. Man denke beispielsweise an die Zusammenführung von Versicherungsscheinen und Unfallbildern beziehungsweise textuellen Unfallbeschreibungen bei einer Autohaftpflichtversicherung. Oder an die Verbindung von betrieblichen Kennziffern und geografischen Daten bei der Planung einer Marketing-Kampagne.

Die Speicherung von relationalen und nichtrelationalen Daten ist die eine Sache, das Wiederfinden oder Eruieren informationeller Zusammenhänge eine andere. Jedenfalls ist es nicht selbstverständlich, daß sich aus einem Datenspeicher mit endlichem Aufwand und zu vernünftigen Kosten auch nützliche Informationen ziehen lassen.

Mit der Structured Query Language (SQL) setzte sich in den 80er Jahren eine deklarative, mengenorientierte Abfragesprache durch, die es ermöglicht, relativ effizient viele Informationen aus relationalen Tabellen abzufragen, zu verdichten und zusammenzuführen. Durch die seit Ende der 80er Jahre betriebene internationale Standardisierung von SQL ist eine Abfrage-Schnittstelle entstanden, die die wechselseitige Austauschbarkeit der verschiedenen Datenbankprodukte garantiert - zumindest solange man auf die Verwendung herstellerspezifischer Sonderwege verzichtet.

In nichtrelationalen Systemen gibt es kein Werkzeug, das ähnlich produkt- und herstellerübergreifend und zugleich so effizient ist wie SQL. Ein diesbezügliches Standardisierungsvorhaben im Bereich objektorientierter Datenbanken namens Object Query Language (OQL) orientiert sich an SQL, bleibt aber hinsichtlich technischer Reife und Akzeptanz bei den Herstellern noch weit hinter diesem zurück.

Angesichts dieser Situation lag es nahe, bei der Integration neuer Datenstrukturen die Vorteile von SQL nicht nur zu erhalten, sondern sie auszubauen. Konkret bedeutet dies, das Konzept relationaler Datenbanksysteme und die damit zusammenhängende Abfragetechnik beizubehalten und die Modellierung der in Frage stehenden Objekte in die alten Konzepte einzubinden.Eine Umsetzung in Tabellenstrukturen, wiewohl theoretisch durchaus möglich, kam nicht in Frage, da Objekte wie Texte, Bilder, geografische Daten oder Zeitreihen beim direkten Zugriff durch SQL äußerst schwer handhabbare Programme und lange Laufzeiten erzeugen. Da ist es viel sinnvoller, die Komplexität nicht in die SQL-Abfrage zu stecken, sondern in neuen Datentypen zu implementieren beziehungsweise Datentypen zuzulassen, die der Benutzer nach Bedarf selbst definiert. Gleichzeitig lassen sich dann auch die Methoden, also der Programmcode, festlegen, mit denen ein Zugriff auf die neuen Datentypen möglich ist.

Diese Vorgehensweise ergab das Konzept der objektrelationalen Datenbanken, das alle großen Anbieter mit dem klassisch relationalen Ansatz in den letzten Jahren in verschiedenen technischen Ausprägungen implementiert haben. Der Ansatz fand auch seinen Niederschlag in den Sprachkonzepten von SQL3, das derzeit in den einschlägigen Normierungsgremien Thema ist.

IBM hat in der eigenen Datenbank "DB2 Universal Database" (UDB) objektrelationale Technik implementiert. Gleichzeitig bietet die Firma in den sogenannten Relational Extenders vorkonfigurierte Pakete für Bild- und Textanalyse (Image- und Text-Mining), Speicherung von Audio- und Videosequenzen, geografische Kartensysteme (Spatial Extender) und Zeitreihenanalyse an.

Diese DB2-Erweiterungen stellen eine Sammlung von benutzerdefinierten Datentypen und Funktionen sowie prozeduralen Datenbankerweiterungen (Trigger, Stored Procedures und Con- straints) dar. Sie werden direkt und ohne Programmieraufwand mit dem DB2-Kern verbunden und bieten umfangreiche Such- und Abfragealgorithmen für den jeweiligen Bereich.Mittels der Extender lassen sich herkömmliche DB2-Daten neben Textdokumenten, Video- und Audiosequenzen, Landkarten und Zeitreihen in DB2-Tabellen unter dem jeweiligen Spezialdatentyp ablegen und über SQL-Anweisungen abfragen. Aus Gründen der Performance, wegen der vorhandenen Programmierinfrastruktur etc. werden auch komplexe Datentypen aufgebaut, auf die man nicht über SQL, sondern prozedural, beispielsweise über C, C++ oder Java, zugreift. Diese werden manchmal auch als "opake" Datentypen bezeichnet. Sie unterstützen keine Subtypen und damit keine Vererbungsmechanismen.

Im Vergleich zu traditionellen relationalen Basis-Datentypen werden an derartige Spezialtypen keinerlei zusätzliche Anforderungen bezüglich ihrer Struktur, zum Beispiel der Primärschlüsselspalten, gestellt.

So beschreiben die Attribute Sprache, Format und Code-Page ein Textdokument des Text-Extenders. Die vom Text-Extender mitgelieferten benutzerdefinierten Funktionen arbeiten mit ihren Speicher- und Abfrageoperationen auf diesen Attributen.

Farbverteilung und Textur sind unter anderem die Attribute, die die Struktur des benutzerdefinierten Image-Datentyps charakterisieren. Mit dem Image-Extender von DB2 UDB können Bilder nicht nur bezüglich Übereinstimmung oder Ähnlichkeit mit einer Vorlage durch SQL-Anweisungen abgefragt werden, sondern auch bezüglich einer bestimmten Farbverteilung und Textur.

Für eine interaktive Katalogsuche lassen sich beispielsweise Instanzen dieser Parameter eingeben, um so das Objekt der Wahl zu identifizieren oder ihm zumindest nahezukommen. Spezielle Indextechniken, die auf Bilddatentypen ausgelegt sind und über die in traditionellen relationalen Strukturen üblichen B-Trees hinausgehen, optimieren die Suche in der Datenbasis.

Für den Benutzer sind die Indextechniken nicht sichtbar: Er gibt das entsprechende SQL-Kommando mit den Extender-eigenen Funktionen ein und erhält dann das Ergebnis.

Eine Eigenschaft des Extender-Ansatzes bei DB2 UDB besteht darin, daß eine SQL-Abfrage in mehreren komplexen Datenstrukturen und auf traditionellen relationalen Datentypen gleichzeitig operieren kann. So kann etwa ein Versicherungsunternehmen Abfragen formulieren, die einerseits auf Bild- und Textinhalte (Image Extender und Text Extender) zugreifen, andererseits aber auch auf die üblichen Kundentabellen (siehe Kasten).

Der Text-Entender integriert an der Standard-SQL-Schnittstelle eine Volltextsuchmaschine in die DB2-Datenbank. Das macht zusätzliche Anwendungsprogrammier-Schnittstellen oder sonstige "Vorbehandlungen" für Suchoperationen in Textdokumenten überflüssig. Der Text-Extender von IBM "versteht" Textdokumente auf der Basis von Wörtern, Sätzen und Textabschnitten. Es lassen sich spezielle Wörter oder Wortfolgen suchen, oder eine "Nähe-Funktion" selektiert Dokumente, die bestimmte Wörter oder Wortfolgen enthalten, und zwar unabhängig von der Reihenfolge.

So könnte eine Abfrage die Namen aller Versicherten liefern, deren Unfallschadensakte Sätze wie "Bei dem Unfall entstanden große Schäden an der linken Vordertür" oder "Die rechte Tür an der Vorderseite des Wagens weist schwere Schäden auf" enthalten (siehe auch Kasten). Dabei wird die Transformation von der Pluralform "Schäden" zu der Singularform "Schaden", wie sie sich im SQL-Kommando findet, auto- matisch erledigt, da der Text- Extender Algorithmen zum Erkennen von Flexionsformen (Schaden = Schäden) und zur Synonymbehandlung (groß = schwer) enthält.

"Finde alle Kunden, die mehr als 150000 Mark im Jahr verdienen und höchstens 20 Kilometer von der umsatzstärksten Allkauf-Filiale in Niederbayern-Oberpfalz entfernt wohnen": Für solche Aufgaben wäre der Spatial Extender geeignet, allerdings nur in Verbindung mit DB2 UDB. Denn Voraussetzung ist die volle Integration des geografischen Informationssystems in die objektrelationale Datenbank.

Diese Aufgabenstellung zeigt den Wert einer Erweiterung herkömmlicher Datenbankinformationen um kartografische Darstellung in sogenannten Geographic Information Systems (GIS). Im Prinzip werden die Optimierungsstrategien des traditionellen relationalen Systems auch auf die "geografischen Tabellen" ausgedehnt.

Das Ergebnis würde eine präzise Planung von Marketing-Kampagnen oder die datenbankgesteuerte Standortauswahl für Geschäftsfilialen erheblich vereinfachen und beschleunigen. Die Interessenten können mit einem einheitlichen Satz von System-Management-Werkzeugen arbeiten.

Angeklickt

Mit welcher Sprache fragt man objektrelationale Datenbanken ab, wenn der Standard unter den Datenbankabfragesprachen, die Structured Query Language (SQL), auf große Datenmengen in relationalen Systemen optimiert ist? Es gibt mit der Object Query Language (OQL) eine Alternative. Doch der SQL-Erfinder IBM beurteilt die Entwicklung und Standardisierungsfortschritte negativ. Das Unternehmen geht von einer Koexistenz objektorientierter und relationaler Datenbanken aus, hier als "Relational Extenders" bezeichnet. Über Erweiterungen von SQL sollen sich die Vorteile beider Seiten gleichermaßen nutzen lassen.

Business Intelligence eingebaut

Die nachstehende SQL-Anweisung zeigt die Verbindung von Bild- und Textsuche mit traditioneller Suche in relationalen Datenbanktabellen (siehe auch Haupttext) und stellt folgende Situation dar:

Es gibt eine DB2-Tabelle "unfälle", die eine Spalte mit der Bezeichnung "bericht" enthält. In dieser Spalte findet sich eine detaillierte textuelle Unfallbeschreibung sowie eine Spalte mit der Bezeichnung "bild", in dem das beschädigte Fahrzeug gezeigt wird. Außerdem gibt es Spalten mit den Bezeichnungen "name", "alter" und "versicherungsschein-nr".

Die unten aufgeführte SQL-Anweisung ermittelt nun alle Unfälle von Kunden unter 25 Jahren, die sich mit roten Fahrzeugen ereigneten und bei der an der Vordertür ein schwerer Schaden entstanden ist. Für jedes Bild eines Schadenswagens liefert DB2 eine Bewertung der Farbwertübereinstimmung. Nur Bilder, die eine Bewertung größer 0,5 erreichen, werden ausgewählt.

Danach wird die oben beschriebene Textsuche an- gestoßen und mit der Bildergebnismenge abgeglichen. Die verbleibende Menge durchläuft die Selektion nach Kunden, die jünger als 25 Jahre alt sind, so daß am Ende nur Datensätze übrigbleiben, bei denen alle Kriterien erfüllt sind. Der DB2-Abfrageoptimierer legt die Reihenfolge der Teilschritte fest, wobei sie durchaus anders ausfallen kann, als hier beschrieben.

SELECT name, versicherungsschein_nr

FROM unfälle

WHERE enthaelt (bericht, "schaden"

IN SAME SENTENCE AS

"groß" AND "vordere Seite" AND "tür") = 1

AND bewertung (bild, "rötlich") > 0,5

AND alter <\ 25

Dr. Volkhard Wolf ist Software-Architekt bei IBM Deutschland in Stuttgart.