Problemseminar „Datenintegration“

WS 2000/2001

Datenbank-Speicherung von Internet-Daten (Oracle 8i, DB2)

Autor: Thomas Tym

Betreuer: Do Hong Hai

1. Einführung

Das Internet ist eines der größten Wachstumsmärkte zur Zeit. Dies begründet sich hauptsächlich durch die großen Chancen, die besonders der Handel über das Internet, der sogenannte E-Commerce, bietet. Dabei stehen alle Anbieter von Internetdiensten vor dem Problem, daß das Angebot an Internetdaten immer umfangreicher wird. Derzeit steigt nicht nur die Anzahl der im Internet vertretenen Internetseiten explosionsartig, sondern besonders der Umfang der zu diesen Seiten angebotenen Audio-, Bild-, Video- und Textdaten.

Einige der größten Nutzer von Multimediadaten auf Internetseiten sind unter anderen kommerzielle Handelsfirmen und Nachrichtenanbieter. Dies begründet sich bei E-Commerce-Angeboten im vorsichtigen Kundenverhalten. Jeder Kunde, der ein Produkt erwerben möchte, erwartet eine ausführliche Beschreibung des gewünschten Artikels. Um diese Anforderungen zu erfüllen, sind die Anbieter gezwungen, Textbeschreibungen, aussagekräftige Bilder oder sogar Video- und Audiodateien zu jedem Artikel anzubieten.

• So verwaltet z.B. amazon.de mehrere tausend Bücher, CDs, Computerspiele und vieles mehr. Für jeden Artikel werden das Titelbild, eine Kurzbeschreibung und eventuelle Kundenkritiken angezeigt. Zu den CDs werden zusätzlich Audiodateien mit den angespielten Liedern zum Probehören angeboten.

• Zur großen Gruppe von Nachrichtenanbietern, welche die Möglichkeiten von Multimediadaten auf Internetseiten nutzen, gehört z.B. cnn.de. Bei diesem Anbieter können mehrere tausend Nachrichten der letzten Monate ständig abgerufen werden. Dabei werden für fast alle Nachrichten Bilder, Audio- und Videodateien und Verweise auf weiterführende Artikel angeboten.

• Eine weitere wichtige Anwendung zur Speicherung von Internetdaten sind die sogenannten Digitalen Bibliotheken z.B. lips.informatik.uni-leipzig.de. Diese bieten eine große Anzahl an Textdokumenten zum online Lesen und zur Recherche.

1.1. Motivation

Die Verwaltung von Internetdaten beinhaltet zwei große Probleme:

• Verwaltung der Links

• Verwaltung der Internetdaten

Der Verwaltung der Links ist nach [FFLS99] eine der Hauptaufgaben des sogenannten Websitemanagement. Dazu gehört die Kontrolle, ob Links noch aktuell sind und ob die Seiten, auf die verwiesen wird, überhaupt noch existieren. Außerdem gehört dazu die Verwaltung der Verweise auf die innerhalb einer Internetseite benutzten Multimediadaten. Dies ist insbesondere wichtig, wenn hunderte oder sogar tausende von Internetseiten verwaltet werden müssen. Wichtig ist das Websitemanagement auch bei der Verwaltung von dynamischen HTML-Seiten, die aus den Multimedia- und Textdaten generiert werden.

Die folgende Arbeit beschäftigt sich hauptsächlich mit dem zweiten Problem, der Verwaltung der Internetdaten. Dabei liegt das Hauptaugenmerk auf der Speicherung der Internetdaten. Um eine Internetseite möglichst schnell auf dem Computer des Benutzers aufbauen zu können ist ein effektiver Zugriff auf die Daten nötig. Dazu gehört die Zugriffsgeschwindigkeit beim Suchen und Laden der Daten auf dem Server, wobei zur Zeit noch sehr viele dieser Daten durch ein Dateisystem verwaltet werden.

Zu den zu verwaltenden Internetdaten gehören folgende Datenformate:

• Internetseiten:

• HTML zur Darstellung

• XML zum Datenaustausch

• Textdokumente:

• PS (PostScript), PDF, reiner Text oder sogenannte Textverarbeitungs-formate wie doc (MS Word)

• Multimediadaten:

• Audiodaten, meistens MP3 oder WAV

• Bilddaten, meistens JPEG oder GIF

• Videodaten, meistens im MPEG oder Quicktime

Dabei besteht das Problem, daß bis auf das XML- und HTML-Format alle oben genannten Datenformate unstrukturiert sind. Das bedeutet, daß die Daten keinem festen Schema entsprechen und damit auch keine durch ein datenverarbeitendes System verwertbaren Schemainformationen enthalten. Diese Daten können deshalb nicht von einem Datenbanksystem zur strukturierten Speicherung oder Begrenzung einer Abfrage verwendet werden. Das XML-Format, und damit auch das HTML-Format, ist semistrukturiert. Das heißt, daß die Daten eine Struktur besitzen, die aber nicht umfassend definiert ist. Außerdem steht die Struktur nicht vor dem Verarbeiten der Daten fest.

Zusätzlich zu den eigentlichen Daten müssen noch die sogenannten Metadaten verwaltet werden. Diese enthalten Informationen über die Art der gespeicherten Daten. Dazu gehören der Datentyp und das Erstellungsdatum, aber auch Inhaltsangaben. Zusätzlich können Metadaten zur Verwaltung von datentypabhängigen Informationen verwendet werden. Für Bilder sind z.B. das Format und die Anzahl der Farben bei Bildern wichtig, während zu Videos die Zeitpunkte der Szenenwechsel gespeichert werden. Die Metadaten werden hauptsächlich verwendet, trotz der Unstrukturiertheit eine effektive Suche nach Daten zu ermöglichen.

2. Konzepte zur Verwaltung von Internetdaten

2.1. Klassifikation

Zur Klassifizierung der Verwaltung von Internetdaten sind drei Kriterien entscheidend. Das erste Kriterium ist Art der Speicherung von Metadaten. Dabei können diese entweder in einem Datei- oder in einem Datenbanksystem gespeichert sein. Dieses Kriterium entscheidet, ob überhaupt ein Datenbanksystem zur Verwaltung der Daten verwendet wird. Das zweite Kriterium bestimmt den Ort, an dem die Internetdaten, also die eigentlichen Daten, gespeichert sind. Es existiert nur bei der Nutzung eines Datenbanksystems die Wahlmöglichkeit diese Daten in einem Datei- oder einem Datenbanksystem zu speichern. Dabei wird bei der Verwendung eines Dateisystems der Begriff Interne Speicherung und bei der Verwendung eines Datenbanksystems der Begriff Externe Speicherung verwendet. Bei der Nutzung eines Dateisystems zur Verwaltung der Metadaten ist nur die Dateisicherung der eigentlichen Daten sinnvoll.

Abbildung 1: Überblick über die Möglichkeiten zur Verwaltung von Internetdaten

Das dritte Kriterium kennzeichnet die durch das verwaltende System gebotene Konsistenzsicherung. Bei der Verwendung eines Dateisystems zur Speicherung der eigentlichen Daten kann die Konsistenz dieser Daten nicht sichergestellt werden. Dies gilt sowohl für den Fall der Verwaltung der Metadaten durch ein Datenbanksystem, als auch für die dateisystembasierte Verwaltung. Deshalb werden durch einzelne Hersteller Mechanismen bereitgestellt, um diese Sicherheitslücke für Datenbanksysteme zu schließen.

Der Verzicht auf ein Datenbanksystem zu Verwaltung der Daten lohnt nur, wenn ein sehr kleiner Internetauftritt durchgeführt wird. Für die Entwicklung einer kleinen Homepage, bei der nur eine Person Zugriff auf die Daten hat, ist die Sicherheit der Daten und der Verwaltungsaufwand auch bei der Verwendung von dynamischen HTML-Seiten in einem Dateisystem noch vertretbar. Die Spezifikation der Einbindung von Multimediadaten und von Verweisen in HTML-Seiten geht sogar von der Verwendung eines Dateisystems aus, da diese über Pfadangaben referenziert werden. Sobald aber eine größere Anzahl von verschiedenen Daten auf vielen Internetseiten angeboten werden sollen, ist nur noch eine Verwaltung durch ein Datenbanksystem empfehlenswert. Insbesondere können die Vorteile von dynamischen HTML-Seiten erst im Zusammenspiel mit einer Datenbank richtig ausgenutzt werden. Dabei können die Konsistenz der Multimediadaten und der Verweise durch z.B. Fremdschlüsseldeklarationen sichergestellt werden. Deshalb wird im Folgenden nicht weiter auf die dateisystembasierte Verwaltung der gesamten Daten eingegangen. Stattdessen konzentriert sich diese Arbeit auf die Verwendung eines Datenbanksystems. Die folgenden Abschnitte untersuchen die beiden datenbankbasierten Varianten zur Speicherung von Internetdaten.

2.2. Interne Speicherung

Bei der sogenannten internen Speicherung werden die Daten komplett durch Datenbankmechanismen verwaltet und gespeichert. Das Dateisystem hat keinen Einfluß auf die gespeicherten Daten. Zur Speicherung werden Varianten des SQL-Datentyps LOB (Large Object) verwendet. Die maximale Größe liegt meistens im Gigabytebereich und wird durch die jeweilige Implementierung bestimmt. Zu den verwendeten Varianten gehören

• BLOB (Binary Large Object)

• CLOB (Character Large Object)

Nach SQL-Standard verwaltet der BLOB-Datentyp eine Bitkette mit variabler Länge und wird zur Speicherung von Binärdaten verwendet. Der CLOB-Datentyp verwaltet eine Zeichenkette von variabler Länge. CLOB wird hauptsächlich zur Speicherung von großen Textdaten benutzt wird. Die genaue Speicherung und der Umfang der Metadaten ist implementationsabhängig. So können objektrelationale Datenbanksysteme eigene Datentypen definieren, in denen die eigentlichen Daten in einem LOB und die Metadaten in eigenen Attributen gespeichert werden. Rein relationale Datenbanken können auch speziell definierte Tabellen verwenden, um Metadaten zu verwalten.

2.3. Externe Speicherung

Bei der externen Speicherung wird die Speicherung der Daten durch das Dateisystem übernommen aber Verweise auf diese Dateien in einem Datenbanksystem verwaltet. Für viele Anwendungen ist nur eine Suchfunktionalität erforderlich, um Daten in Dateien zu finden. Für diese Suchfunktionalität ist es jedoch nicht erforderlich, die Daten in ein Datenbanksystem zu übertragen, da der Rohinhalt der Dateien für die Abfrage nicht benötigt wird. Meistens werden einige Merkmale z.B. eines Bildes oder Videos extrahiert und in der Datenbank gespeichert. Die Suche bezieht sich dann nur auf diese extrahierten Merkmale. Die Rohdaten werden als normale Dateien in einem Dateisystem abgelegt. In der Datenbank werden diese Dateien dann über Verweise referenziert. Diese Verweise können als Pfadangabe für das lokale Dateisystem in einem einfachen String gespeichert werden. Es ist aber auch möglich eine URL als Verweis zu speichern. Einige Datenbanksysteme bieten spezielle Datentypen um Verweise auf externe Daten zu implementieren. Dabei werden die Dateien ähnlich zu BLOBs verwaltet. Außerdem wurden durch verschiedene Hersteller Konzepte und Mechanismen vorgestellt, mit denen die Integrität der Daten besser geschützt werden können. Besonders zu nennen ist hierbei die Verwendung von DataLinks, auf die später bei den Erläuterungen zu DB2 genauer eingegangen wird.

2.4. Gegenüberstellung von interner und externer Speicherung

Die Vorteile der internen Speicherung von Daten bestehen darin, daß nur noch die Datenbank für die Verwaltung der Daten zuständig ist. Damit wird sichergestellt, daß keine andere Anwendung oder das Betriebssystem die Daten verändern oder löschen kann, ohne das die Datenbank davon erfährt und diese Operationen im Zweifelsfall verhindern kann. Bei der externen Speicherung ist solch eine Kontrolle normalerweise nicht vorhanden. Diese automatische Überwachung sichert aber in erheblichen Maß die Integrität der Daten. Außerdem gelten für die verwendeten Datentypen die gleichen Sicherheitsvorkehrungen, die das entsprechende Datenbanksystem auch für alle anderen SQL-Datentypen bereithält. Somit kann im Verlustfall eine Wiederherstellung durchgeführt werden kann. Die Vorteile der externen Speicherung bestehen darin, daß Anwendungen, die auf den Datenzugriff über das Dateisystem angewiesen sind, weiter verwendet werden können. Dadurch werden auch Kosten gesenkt. Für die Verwendung einer internen Speicherung müssten diese Anwendungen aufwendig geändert werden. Außerdem bietet die Verwendung eines Dateisystems eine höhere Leistungsfähigkeit in Bezug auf die normalen Dateioperationen (Laden, Löschen, Verändern) als ein Datenbanksystem, da ein Dateisystem für genau diese Anwendungen optimiert ist. In Tabelle 1 werden diese, sich auf die Rohdaten beziehenden, Eigenschaften, zusammengefaßt.

Tabelle 1: Vergleich Interne und Externe Speicherung

3. Speicherung von Internetdaten in Oracle 8i

Oracle bietet zur Speicherung von Multimediadaten ein besonderes Zusatzprodukt namens InterMedia an. Dieses wird normalerweise mit Oracle8i ausgeliefert. Dieses Paket ermöglicht es Oracle8i Multimediadaten intern und extern zu speichern, zu verwalten und darauf zuzugreifen [OIM00]. Ein weiteres Produkt, InterMedia Text, wird zur Verwaltung von Textdaten verwendet. Es bietet Such-, Auswertungs- und Anzeigefähigkeiten für Textdaten. Mit diesen beiden Produkten können alle Arten von Internetdaten verwaltet werden. Insbesondere kann InterMedia Text auch zur Verwaltung von XML-Dokumenten verwendet werden.

3.1. InterMedia und InterMedia Text

InterMedia und InterMedia Text bieten für ein Oracle8i-Datenbanksystem APIs um Multimedia- und Textdaten zu verwalten. Auf diese API kann mit verschiedenen Anfragesprachen, wie z.B. SQL, C++ oder Java, zugegriffen werden. Beide Produkte unterstützen eine Vielzahl von Datenformaten. So kann man u.a. mit InterMedia Bilddaten im BMP-, GIF- und JPG-Format verwendet werden. InterMedia Text unterstützt z.B. Daten im HTML-, RTF-, Microsoft Word- und PDF-Format.

Abbildung 2: Aufbau der InterMedia-Architektur (Aus [IM00])

Speicherungsmechanismen

InterMedia definiert neue Datentypen um Multimediadaten zu beschreiben. Als Grunddatentyp wird ORDSource definiert. ORDSource implementiert die grundsätzliche Speicherung und Verwaltung der Daten in Oracle8i. Die Datentypen für die Multimediadaten nutzen ORDSource und erweitern es mit besonderen Attribute. Die verwendeten Datentypen sind im einzelnen:

• ORDAudio für Audiodaten

• ORDImage für Bilddaten

• ORDVideo für Videodaten

• CLOB für Textdaten

In diesen Klassen werden Mediendaten und Metadaten gespeichert. Mediendaten sind die eigentlichen Audio-, Bild- oder Videodaten. Die Mediendaten der Objekte können direkt in der Datenbank in einem BLOB (Binary Large Object) oder extern, in einem sogenannten BFILE, gespeichert werden. In BLOB oder BFILE gespeicherte Daten können in Oracle8i jeweils bis zu 4 Gigabyte groß sein.

Um die Verwendung der Multimediaklassen näher zu erläutern, folgen einige Beispiele, die die Einbindung von Bildern in einer Oracle8i-Datenbank zeigen. In Beispiel 1 wird eine Tabelle zur Verwaltung von Angestellten erzeugt. Diese Tabelle enthält eine Spalte photo (Zeile 2), welche die Bilddaten aufnehmen soll.

CREATE TABLE emp(ename VARCHAR(50),salary INTEGER,job VARCHAR(50),

department INTEGER, photo ORDSYS.ORDImage);

Beispiel 1: Erzeugen einer Tabelle mit einer Spalte photo für Bilddaten (Aus [IM00])

In Beispiel 2 werden Bilddaten aus dem Dateisystem in die Datenbank kopiert und in der Tabelle aus Beispiel 1 gespeichert. Durch den INSERT-Befehl in Zeile 5 und 6 werden die Spalten mit Daten gefüllt. Die Spalte photo wird dabei mit einem leeren Bild initialisiert und in Zeile 7 für ein Update selektiert. In Zeile 8 werden die Bilddaten aus einer Datei test.gif aus einem Verzeichnis IMGDIR in das Objekt Image mit dem Datentyp ORDImage importiert. Die Daten werden dabei als BLOB gespeichert. In Zeile 9 wird das Update durchgeführt, indem die Daten aus Image in der entsprechenden Zeile in die Spalte photo kopiert werden.

DECLARE

Image ORDSYS.ORDImage;-- application variables

ctx RAW(4000) := NULL;

BEGIN

INSERT INTO emp VALUES ('John Doe', 24000, 'Technical Writer', 123,

ORDSYS.ORDImage.init());

SELECT photo INTO Image FROM emp WHERE ename = 'John Doe' for UPDATE;

Image.setSource('FILE', 'IMGDIR', 'jdoe.gif'); Image.import(ctx);

UPDATE emp SET photo = Image WHERE ename = 'John Doe'; COMMIT;

END;

Beispiel 2: Einfügen von Bilddaten aus einer Datei in eine Tabelle (Aus [IM00])

DECLARE

Image ORDSYS.ORDImage;

BEGIN

INSERT INTO emp VALUES ('John Doe', 24000, 'Technical Writer', 123,

ORDSYS.ORDImage.init('file','ORDIMAGEDIR','jdoe.gif'));

SELECT photo INTO Image FROM emp WHERE ename = 'John Doe' for UPDATE;

Image.setProperties;

UPDATE emp SET photo = Image WHERE ename = 'John Doe'; COMMIT;

END;

Beispiel 3: Referenzieren von Bilddaten mit einem BFILE (Aus [IM00])

Die Verwendung einer extern gespeicherten Bilddatei mit InterMedia für die Angestelltentabelle zeigt Beispiel 3. Dazu wird ein BFILE verwendet. BFILE sind extern gespeicherte Daten, die durch Oracle8i bei der Verarbeitung wie BLOB benutzt werden. Zur Definition eines BFILE werden folgende Daten benötigt:

• Typ des BFILE, der bestimmt ob die Daten lokal im Dateisystem oder auf einem HTTP-Server gespeichert sind

• Pfad zu der referenzierten Datei

• Name der referenzierten Datei

Der Konstruktor (Zeile 5) benötigt nun als Parameter den Pfad, den Dateinamen und das Kennwort 'file' um die Bilddaten mit Hilfe eines BFILE zu speichern. Dabei wird in dem BFILE die Datei jdoe.gif aus dem Verzeichnis ORDIMAGEDIR referenziert. In Zeile 6 wird die entsprechende Zeile in der Spalte photo für ein Update selektiert, in Zeile 7 die Properties des Bildes gesetzt und in Zeile 8 das Update durchgeführt, indem die Daten aus Image in der entsprechenden Zeile in die Spalte photo kopiert werden.

Da alle drei Multimediaklassen auf der Klasse ORDSource basieren, wird diese zur Verwaltung der allgemeinen Attribute verwendet. Tabelle 2 zeigt die in ORDSource gespeicherten Informationen. Für jede einzelne der Klassen ORDAudio, ORDImage und ORDVideo werden eigene, spezielle Attribute definiert. Die Attribute der Klasse ORDImage werden als Beispiel in Tabelle 3 dargestellt.

Tabelle 2: Attribute der Klasse ORDSource

Tabelle 3: Attribute der Klasse ORDImage

InterMedia Text stellt keine eigenen Datentypen zur Verfügung, sondern verwendet zur Speicherung von Textdaten die SQL-Datentypen VARCHAR, CHAR, CLOB und BLOB sowie den speziellen Oracle-Datentyp BFILE. Der Datentyp CLOB kann, wie auch ein BLOB, in Oracle8i Daten bis zu einer Größe von 4 GigaByte speichern.

Beispiel 4 zeigt die Erstellung einer Tabelle und das Einfügen von Textdaten:

CREATE TABLE docs ( id NUMBER PRIMARY KEY, text VARCHAR2(2000));

INSERT INTO docs VALUES( 1, 'this is the first text document');

Beispiel 4: Aus [IMT99]

Funktionalität

InterMedia stellt für ORDAudio, ORDImage und ORDVideo die gleichen Konstruktoren zu Verfügung. Es werden zwei Standardkonstruktoren definiert:

• init() erzeugt einen leeren BLOB bei der Speicherung des jeweiligen Datentyps

• init(srcType, srcLocation, srcName) initialisiert ein Objekt des entsprechenden Datentyps und speichert die gegebenen Attribute in ORDSource

InterMedia implementiert für die drei Multimediaklassen jeweils spezielle Funktionen zum Bearbeiten der Attribute. Außerdem werden Methoden zur Anwendung der gespeicherten Daten angeboten. Tabelle 4 zeigt einige Beispiele für Methoden die Intermedia für die jeweilige Klassen bereitstellt:

Tabelle 4: Beispielmethoden der Extender

Diese Methoden können aufgrund der objektrelationalen Funktionalität von Oracle8i in SQL-Anweisungen verwendet werden. Dies gilt im Besonderen für die SELECT-Anweisung. Beispiel 5 zeigt die Verwendung dieser Methoden. Dabei sollen in der Tabelle aus Beispiel 1 alle Angestellten ausgegeben werden, deren Bilder eine Breite größer als 32 Pixel haben:

SELECT E.ename, E.photo.getWidth()

FROM emp E

WHERE E.photo.getWidth() > 32;

Beispiel 5: Verwendung der getWidth()-Funktion (Aus [IM00])

CREATE INDEX myindex ON docs(text) INDEXTYPE IS CTXSYS.CONTEXT;

Beispiel 6: Erstellen eines Indexes mit InterMedia Text (Aus [IMT99])

Eine der Hauptfunktionen von InterMedia Text ist die Erstellung von Indexdaten für Textdaten. Um z.B. einen Index für die Tabelle aus Beispiel 4 zu erzeugen verwendet man den Befehl aus Beispiel 6. Mit diesem Befehl führt InterMedia Text folgende Aktionen aus:

• überprüft, ob die angegebene Spalte einen unterstützten Datentyp enthält

• versucht, das Textformat herauszufinden (HTML, PDF usw.)

• versucht, die Sprache des Textes herauszufinden

• falls dies nicht gelingt wird standardmäßig die Sprache der Datenbankinstallation verwendet

• erstellt einen Index für die Tabellenspalte

Intermedia Text besitzt besondere Indexalgorithmen für bestimmte Sprache. Z.B. werden für englischsprachige Texte Themeninformationen verwaltet, die eine spätere Suche erleichtern und die Genauigkeit der Suche erhöhen. Für deutschsprachige Texte werden die Groß- und Kleinschreibung besonders beachtet, die Unterstützung für die Sonderzeichen und Umlaute aktiviert und die Erstellung eines Composite Index unterstützt.

Um den erstellten Index zu nutzen kann die Funktion contains verwendet werden. Beispiel 7 zeigt die Verwendung eines Indexes zur Suche. Die Beispielanfrage sucht alle Texte in der Spalte text in der Tabelle docs, welche die Zeichenkette 'oracle' enthalten:

SELECT SCORE(1) id FROM docs WHERE CONTAINS (text, 'oracle', 1) > 0;

Beispiel 7: Suchanfrage mit contains (Aus [IMT99])

Die Anfragen mit contains lassen sich durch folgende Optionen verfeinern:

Tabelle 5: Möglichkeiten zur Verfeinerung der Suche nach Textdaten

4. Speicherung von Internetdaten in DB2

DB2 verfügt über zwei Mechanismen zur Verwaltung von Internetdaten in einem Datenbanksystem. Der erste Mechanismus, die sogenannten Extender, bieten spezielle Datentypen für die zu speichernden Daten, während mit dem zweiten Mechanismus, der Datalink-Technologie, die Integrität von Daten im Dateisystem gesichert wird. Außerdem können beide Mechanismen in Verbindung verwendet werden. Die folgenden Ausführungen beziehen sich alle auf DB2 Version 7.

4.1. Extender

Zur Speicherung von besonderen Daten liefert IBM sogenannte Extender zu seiner Datenbank DB2 mit aus. So gibt es einen Audio-, einen Image-, einen Text- und einen Video-Extender. Diese Extender definieren Datentypen und Methoden für die jeweilig zu speichernden Daten. Außerdem helfen die Extender bei der Verwaltung der Daten, indem sie besonders leistungsstarke Abfragen für die Daten bieten. Es existiert auch ein XML-Extender, auf den aber in dieser Arbeit nicht eingegangen wird, da die für das Internet wichtige Funktionalität durch den Text-Extender unterstützt wird.

Speicherungsmechanismen

Diese Datentypen nutzen die objektrelationalen Funktionen von DB2 aus. Dabei können die eigentlichen Daten in einem BLOB gespeichert werden, falls es sich um Audio-, Bild- und Videodaten handelt oder in einem CLOB (Character Large Object), falls es sich um Textdaten handelt. Aufgrund der möglichen Größe der LOBs (bis zu 2 GB) in DB2 werden diese nicht direkt in der Tabelle des Benutzers gespeichert, sondern jedes LOB ist durch einen Deskriptor für große Objekte gekennzeichnet. Mit Hilfe des Deskriptors wird auf das große Objekt zugegriffen, welches an einem anderen Ort in der Datenbank oder sogar in einer externen Datei im Dateisystem gespeichert sein kann. Da Audio-, Bild-, und Videodaten alle in BLOBs gespeichert werden, sind eindeutige Datentypen nötig, damit zwischen den verschiedenen Datenarten unterschieden werden kann. Außer dem Text-Extender definiert jeder Extender einen Datentyp für seinen speziellen Typ von Daten (z.B. der Audio-Extender DB2AUDIO oder der Image-Extender DB2IMAGE). Die Extender sind erweiterbar ausgelegt, so daß ohne Probleme neue Datentypen für neue Anforderungen erstellt werden können.

ENABLE DATABASE FOR DB2IMAGE

CREATE TABLE employee (id char(6),name varchar(40),picture DB2IMAGE);

ENABLE TABLE employee FOR DB2IMAGE;

ENABLE COLUMN employee picture FOR DB2IMAGE;

EXEC SQL INSERT INTO EMPLOYEE VALUES(

'128557', 'Anita Jones',

DB2IMAGE(

CURRENT SERVER, /*database server name*/

'/employee/images/ajones.bmp', /*image source file*/

'ASIS', /*keep the image format*/

:MMDB_STORAGE_TYPE_INTERNAL, /*store image in DB as BLOB*/

'Anita''s picture')); /*comment*/

Beispiel 8: Verwendung von Bilddaten in DB2

Die Verwendung der Extender-Datentypen zeigt anhand von DB2Image Beispiel 8. Mit dem Befehl in Zeile 2 wird eine Tabelle mit einer Spalte für Bilddaten erstellt. Die Tabelle und auch die Tabellenspalte für die Bildspeicherung muß für den Extender aktiviert werden (Zeile 3 und 4). Nun können Daten in die Tabelle eingefügt werden (Zeile 5 bis 12). Dazu liest der Image-Extender die Attribute des Bildes, wie z.B. Höhe, Breite und Anzahl der Farben aus der Quelldatei. Die Datei wird in die Datenbank kopiert und in einer der Tabellen zur Verwaltungsunterstützung als BLOB eingefügt. Dabei erstellt der Extender eine eindeutige Kennung für das Bild und trägt die folgenden Informationen in eine Tabelle zur Verwaltungsunterstützung ein:

• Kennung für das Bild

• eine Zeitmarke

• Bildgröße in Byte

• Kommentar

• Inhalt des Bildes

Die Extender verwenden Metadaten um auf die Multimediadaten zugreifen zu können. Zur Speicherung der Metadaten werden sogenannte Tabellen zur Verwaltungsunterstützung genutzt. Die Extender nutzen diese Tabellen zur Speicherung der für sie aktivierten Benutzertabellen und der in diese Tabellen aktivierten Spalten. Die Abbildungen 3 zeigt die Struktur der Tabellen zu Verwaltungsunterstützung.

Beim Speichern eines Audio, Bild- und Videoobjekts in einer Benutzertabelle wird nicht das Objekt selber sondern nur eine Kennung, also ein Verweis, auf dieses Objekt gespeichert. Das eigentliche Objekt, oder bei der externen Speicherung ein Verweis auf eine Datei, wird dann in einer Tabelle zur Verwaltungsunterstützung gespeichert, die von allen Extendern verwendet wird. Die Extender verwenden diese Tabelle für die Attribute, die in allen Extenderdatentypen gleich definiert sind. Dabei kann für die Speicherung der eigentlichen Daten ein BLOB oder ein Verweis auf eine extern gespeicherte Datei verwendet werden. Jeder Extender besitzt außerdem eigene Tabellen, in denen die speziellen Attribute der jeweiligen Datentypen, gespeichert sind.

Abbildung 3: Struktur der Tabellen zu Verwaltungsunterstützung (Aus [IAVE00])

Eine besondere Form von Metadatentabellen in DB2 sind die sogenannten QBIC-Kataloge. Diese Kataloge enthält Daten zu visuellen Merkmalen von Bildern. Der Image-Extender benutzt diese Kataloge, um nach dem Inhalt von Bildern zu suchen. Bei der Erstellung des QBIC-Katalogs zu einer Tabellenspalte kann man folgende zu katalogisierende Merkmale angeben:

• Durchschnittsfarbe des Bildes

• Histogrammfarbe

• Positionsgebundene Farbe

• Textur

Während der Katalogisierung berechnet der Image-Extender für jedes Bild einen entsprechenden Wert, der dann in dem Katalog gespeichert wird. Nach diesen Merkmalen kann dann in SQL-Anweisungen gesucht werden. Eine weitere besondere Metadatentabelle sind die Videoindizes, die der Video-Extender verwendet, um bestimmte Einzelbilder und Szenenwechsel in Videodaten zu katalogisieren und damit wieder auffindbar zu machen.

Funktionalität

Da die Speicherung der Daten objektorientiert abläuft, können für jeden Datentyp spezielle Methoden definiert werden. Standardmäßig definieren die Extender jeweils eine große Anzahl von Methoden für ihre Standardtypen. So werden z.B. Funktionen zum Konvertieren von Daten in andere Formate angeboten oder zum Anzeigen und Abspielen von Multimediaobjekten. Die folgende Tabelle enthält einige Beispielfunktionen, die von den Extendern bereitgestellt werden:

Tabelle 6: Beispiele für durch Extender bereitgestellte Funktionen

Ausgehend von Beispiel 8 zeigt Beispiel 9 die Verwendung der Funktion Format. Die Anweisung ruft die Namen aller Mitarbeiter ab, deren Bild in der Spalte picture in der Tabelle employee im GIF-Format gespeichert sind. Entscheidend ist dabei die Select-Anfrage in den Zeilen 3 und 4.

EXEC SQL BEGIN DECLARE SECTION; char hvname[30];

EXEC SQL END DECLARE SECTION;

EXEC SQL SELECT NAME INTO :hvname

FROM EMPLOYEE WHERE FORMAT(PICTURE)='GIF';

Beispiel 9: Verwendung der Funktion Format (Aus[IAVE00])

Der DB2-Text-Extender ermöglicht es, nach [TE00], auf unterschiedlichste Art und Weise auf Textdokumente zuzugreifen und abzurufen. Diese Funktionen werden unter anderem angeboten:

• Suchen nach Dokumenten, die bestimmten Text, bestimmte Synonyme eines Wortes oder Suchbegriffe in der Nähe, also im selben Satz oder Absatz, enthalten.

• Suche nach Platzhalterzeichen mit Platzhalterzeichen am Anfang, in der Mitte und am Ende eines Wortes

• Suche nach Dokumenten in verschiedenen Sprachen und Dokumentformaten

• Suche nach grober Übereinstimmung „fuzzy“, nach Wörtern die ähnlich geschrieben sind.

• Freitextsuche mit Suchargument in natürlicher Sprache

• Suche nach Wörtern, die wie der Suchbegriff klingen

SELECT * FROM MyTextTable

WHERE version = '2' AND DB2TX.CONTAINS (DB2BOOKS_HANDLE,

'“authorization“ IN SAME PARAGRAPH AS “table“

AND SYNONYM FORM OF “delete“') = 1;

Beispiel 10: Aus [TE00]

Diese Suchfunktionen können voll in Select-Anweisungen integriert werden, wie Beispiel 10 zeigt. DB2TX.CONTAINS ist eine von mehreren DB2 Text-Extender-Suchfunktionen. DB2BOOKS_HANDLE ist der Name einer Kennungsspalte, die auf die Spalte DB2BOOKS verweist, welche die zu durchsuchenden Textdokumente enthält. Der Rest der Anweisung ist ein Beispiel für ein Suchargument, das nach der Zeichenkette 'authorization' sucht, welches im selben Absatz wie 'table' vorkommt sowie nach 'delete' oder einem Synonym von 'delete' sucht.

4.2. DataLinks

Abbildung 4: Benutzung von DataLinks zur Verwaltung (Aus [JRD99])

Bei der Verwendung von DataLinks bleiben die genutzten Daten im Dateisystem gespeichert. Die Data Link-Technologie sichert der Datenbank Zugriffskontrolle auf die durch sie verwalteten Dateien. Damit wird die referentielle Integrität der extern gespeicherten Daten drastisch erhöht. Außerdem werden koordinierte Sicherungen und Wiederherstellungen von Daten ermöglicht [HN00]. Das DataLinks-System besteht nach [JRD99] aus drei Komponenten:

• dem DataLinks Manager, bestehend aus DataLinks File Manager (DLFM) und DataLinks File Filter(DLFF)

• dem DATALINK Datentyp

• DBS/DLFM APIs, mit denen DB2 mit dem DataLinks Manager auf dem Dateiserver kommuniziert

Abbildung 4 zeigt wie Anwendungen die SQL-API nutzen um Daten und Referenzen auf externe Dateien in einer Datenbank zu suchen, und dann eine Standard-Dateizugriffs-API verwenden, um auf die referenzierten Dateien zuzugreifen.

Der Data Links Manager

Abbildung 5: Die DataLinks Architektur (Aus [JRD99])

Um auf diese Daten aus der Datenbank heraus zugreifen zu können, muß auf jedem Dateisystem, dessen Dateien geschützt werden sollen, der DataLinks Manager installiert sein (Abbildung 5). Dieser DataLinks Manager enthält zwei Komponenten. Der DataLinks File Manager (DLFM) ist für die Kommunikation mit dem Datenbankserver zuständig. Er überträgt die angeforderten Daten an die Datenbank und speichert die durch die Datenbank veränderten Daten im Dateisystem. Er ist außerdem für die Sicherung und Wiederherstellung von Daten verantwortlich. Der DLFM empfängt und verarbeitet nach [DLME00] Nachrichten über das Verbinden und Aufhebung der Verbindung von Dateien. Diese Nachrichten sind das Ergebnis von SQL-Anweisungen Insert, Update und Delete, die auf eine DATALINK-Spalte verweisen. Dabei kann eine Datenbank mit mehreren DataLinks Managern auf verschiedenen Dateiservern zusammenarbeiten.

Der DataLinks File Filter (DLFF) sorgt dafür, daß unerwünschte Zugriffe auf die durch DataLinks referenzierten Dateien unterbleiben. Für jede durch Datalinks referenzierte Datei lassen sich Zugriffsbeschränkungen definieren. Die Einhaltung dieser Zugriffsbeschränkungen werden durch den DLFF kontrolliert und gegebenenfalls unterbunden. So werden Anweisungen zum Umbenennen, Ändern und Löschen von referenzierten Dateien abgefangen und verhindert. Damit werden tote Verweise und ähnliche Störungen der Integrität verhindert.

Der DATALINK-Datentyp

Um extern gespeicherte Daten in der Datenbank zu repräsentieren verwendet man nun den DATALINK-Datentyp. Dieser enthält eine URL (Uniform Ressource Locator) als Verweis auf die externe Datei und Werte, welche die verschiedenen Zugriffsrechte auf diese Datei bestimmen. Diese Zugriffsrechte sind im einzelnen:

• INTEGRITY – Für jeden Wert in der DATALINK-Spalte erwartet DB2 einen installierten DataLinks Manager auf dem referenzierten Dateiserver

• READ PERMISSION – Bestimmt, ob die Leserechte durch die Datenbank oder das Dateisystem vergeben werden

• WRITE PERMISSION- Bestimmt, ob die Schreibrechte beim Dateisystem liegen oder blockiert (blocked) sind

• RECOVERY – Bestimmt, ob sich der DataLinks Manager um die Sicherung und Wiederherstellung der referenzierten Dateien kümmern soll

• ON UNLINK – Bestimmt, was mit der Datei passieren soll, wenn sie nicht mehr vom Data Links Manager verwaltet wird. Mögliche Optionen sind löschen oder wiederherstellen der alten Einstellungen.

Beispiel 11 zeigt die Anwendung von Datalinks, um externe Dateien zu schützen. Zeile 7 bestimmt, daß die Integrität für alle Dateien gesichert werden soll. In Zeile 8 wird das Dateisystem als Leserechtverwalter definiert um weiter auf die Daten lesend zugreifen zu können. Zeile 9 blockiert den Schreibzugriff auf die referenzierten Dateien. Zeile 10 veranlaßt den Data Links Manager, sich um die Sicherung und eventuelle Wiederherstellung der Daten zu kümmern. Zeile 11 sorgt dafür, daß die Dateien, falls sie nicht mehr vom Data Links Manager verwaltet werden, wiederhergestellt werden.

CREATE TABLE PRODUCT

(PRODUCT_ID CHAR(8),

PRODUCT_NAME VARCHAR(150),

PRODUCT_AVI DATALINK(200)

LINKTYPE URL

FILE LINK CONTROL

INTEGRITY all

READ PERMISSION FS

WRITE PERMISSION BLOCKED

RECOVERY yes

ON UNLINK restore );

Beispiel 11: Verwendung von Datalinks in Tabellen (Aus [JH99])

5. Vergleich von Oracle 8i, DB2

Tabelle 7: Vergleich von Oracle8i und DB2

Oracle8i InterMedia und die DB2-Multimedia-Extender bieten ähnliche Mechanismen, um Internetdaten zu verwalten. Beide Datenbanksysteme definieren spezielle Datentypen für besondere Daten wie Bilder, Audio- und Videodaten und nutzen damit die objektrelationale Funktionalität des jeweiligen DBMS. Für diese Datentypen werden sowohl bei Oracle InterMedia als auch bei DB2 Extender Funktionen zum vereinfachten und effektiveren Zugriff auf die Daten angeboten. Beide Produkte sind sehr einfach erweiterbar. Gemeinsam ist beiden Datenbanksystemen auch die Möglichkeit Daten sowohl intern, als auch extern zu speichern. Auch die Funktionalität von Oracle8i-InterMedia-Text und DB2-Text-Extender sind ähnlich. Bei beiden Implementationen verfügen die Multimedia- und Text-Erweiterungen über in etwa die gleiche Anzahl an unterstützten Datenformaten.

Außerdem bietet DB2 mit der DataLinks-Technologie einen interessanten Ansatz, um Maßnahmen zu Konsistenzsicherung dieser extern gespeicherten Daten zu ermöglichen. Dies ist ein großer Vorteil gegenüber Oracle8i. Trotzdem sind die Funktionalitäten, welche durch Oracle InterMedia und DB2 Extender bereitgestellt werden, insgesamt gleich mächtig. Damit stellen Oracle8i und DB2 effektive, performante und nutzerfreundliche Funktionen bereit, um Internetdaten in einer Datenbank verwalten zu können. Tabelle 7 stellt alle wichtigen Eigenschaften noch einmal im Vergleich zwischen Oracle8i und DB2 zusammen.

6. Zusammenfassung

Dieses Dokument zeigt die vorhandenen Möglichkeiten zur Integration von Internetdaten in ein Datenbanksystem auf. Dabei wurde die Hauptentwicklungsrichtung mit der Definition von speziellen Datentypen und der Konsequenten Nutzung von objektrelationalen Fähigkeiten der modernen Datenbanken untersucht. Zusätzlich stellt aber der Ansatz zu Integration von Daten über DataLinks einen nicht zu unterschätzenden Vorteil zur Verfügung, da damit die Vorzüge der internen Speicherung, nämlich die höhere Sicherheit, mit den Vorteilen der externen Speicherung, besonders der Geschwindigkeit und der Nutzung von vorhandener Software, verbunden werden können. Besonders wichtig wird diese Technologie, wenn sie in den SQL-Standard aufgenommen und in die vorhandenen Multimedia- und Text-Extender integriert wird. Die Möglichkeiten zur Verwaltung von Internetdaten durch Datenbanken werden in der Zukunft einen noch größeren Einfluß auf die Konkurrenzfähigkeit von im Internet vertretenen Firmen besitzen, da beim Werben um den Kunden Geschwindigkeit, Sicherheit und Zuverlässigkeit der angebotenen Dienste entscheidend sind.

7. Literaturverzeichnis

[DLME00]	IBM DB2 Data Links Manager Einstieg, Version 7 April 2000
[FFLS99]	Mary Fernandez, Daniela Florescu, Alon Levy, Dan Suciu : Verifying Integrity Constraints on Web-Sites.Proceedings of the 16th International Joint Conference on Artificial Intelligence 1999
[HN00]	Hui-I Hsiao , Inderpal Narang : DLFM: A Transactional Resource Manager. SIGMOD Conference 2000 : 518-528
[IAVE00]	IBM DB2 Universal Database Image, Audio and Video Extender Verwaltung und Programmierung, Version 7 April 2000
[IM00]	Oracle interMedia Audio, Image and Video User's Guide and Reference Release 8.1.7, September 2000: Part No: A85336-01
[IMT99]	Oracle interMedia Text Reference Release 2 (8.1.6), December 1999: Part No: A77063-01
[JH99]	Jan Henderyckx : Inside DB2 Data Links Manager.DB2 Magazine 1999
[JRD99]	Judith R. Davis : DataLinks: Managing External Data with DB2 Universal Database, Februar 1999
[TE00]	IBM DB2 Universal Database Text Extender Verwaltung und Programmierung, Version 7 Juni 2000