Datenbanktechniken für das World Wide Web

Datenbanktechniken für das
World Wide Web
Ausarbeitung für das Seminar Weltweite Datenbanken WS 2000/01
von Torben Christian Sliwka
06.05.2001
Vorwort
Die Vereinigung von Datenbanken mit den Techniken des World Wide Web stellt für beide
Systeme eine Erweiterung ihrer jeweiligen Funktionalitäten über den ursprünglich intendierten
Rahmen hinaus dar.
Web-Oberflächen, mit HTML (HyperText Markup Language) und eingeschränkten ScriptErweiterungen, dienten der elaborierten Darstellung von mehr oder weniger statischen
Informationen mittels eines einfachen Übertragungsprotokolls.
Datenbanken stellten durch wohldefinierte Abfrage- und Schreibeoperationen einen sicheren,
transaktionsbasierten, revertierbaren und benutzerspezifischen Zugriff auf einen Datenbestand
sicher.
Die Vereinigung dieser beiden Technologiebereiche verspricht eine deutlich verbesserte
Erreichbarkeit von Datenbankinhalten. Die Datenbestände sind nicht räumlich beschränkt
zugänglich, sondern im Idealfall global. Der Zugriff ist mit einer großen Vielfalt an
Plattformen möglich, da HTTP-Clients für viele Plattformen verfügbar sind. Oberflächen für
den Datenbankzugriff können mit einem fast beliebigen Freiheitgrad an individuelle
Anforderungen (oder Geschmacksvorlieben) angepaßt werden.
Mit dieser Synthese ist fast immer ein Abwägen von Einschränkungen auf beiden Seiten
verbunden. Im Folgenden sollen verschiedene Technologien vorgestellt werden, die sich mit
ihren jeweiligen Stärken für unterschiedliche Anwendungsbereiche anbieten.
2
Inhaltsverzeichnis
1
EINLEITUNG...............................................................................................................................................4
1.1
1.2
1.3
1.4
2
TECHNOLOGIEN FÜR DIE DATENBANKNUTZUNG IM WWW.....................................................8
2.1
2.2
2.3
2.4
2.5
2.6
2.7
3
DAS WWW MODELLIEREN ..................................................................................................................17
ANFRAGESPRACHEN FÜR DAS WEB ......................................................................................................18
DATENINTEGRATION............................................................................................................................20
4.1
4.2
5
GRUNDLAGEN VON CGI.........................................................................................................................8
DATENBANKZUGRIFF IM CGI-PROGRAMM ...........................................................................................10
APPLETS ...............................................................................................................................................11
EXTERNE ANWENDUNGEN UND PLUG-INS ...........................................................................................12
SERVER-SEITIGE HTML-MACROS .......................................................................................................13
WEB-SERVER MIT API .........................................................................................................................15
SERVLETS ............................................................................................................................................15
DAS WEB ALS DATENBANK .................................................................................................................17
3.1
3.2
4
DATENBANKEN UND DAS WWW ...........................................................................................................4
ALLGEMEINE STRUKTUR ........................................................................................................................5
DATENBANKEN UND HTTP....................................................................................................................6
KONSISTENZ UND ZUSTÄNDE .................................................................................................................7
KLASSIFIZIERUNG.................................................................................................................................20
AUFBAU VON DATENINTEGRATIONSSYSTEMEN....................................................................................21
ABSCHLIESSENDE ANMERKUNGEN.................................................................................................22
5.1
5.2
ZUSAMMENFASSUNG............................................................................................................................22
AUSBLICK ............................................................................................................................................23
3
1 Einleitung
Ziel bei der Verbindung von Datenbanken und Web ist ein Zusammenführen der Vorteile
beider Technologien. Die technischen Anforderungen an beide Klassen von Systemen
unterscheiden sich allerdings, was bei der Kombination einige Probleme aufwirft, und ein
Abwägen der jeweils verfügbaren Leistungsmerkmale erfordert.
1.1 Datenbanken und das WWW
Die heute üblichen relationalen Datenbank-Managementsysteme (RDBMS) besitzen die
Eigenschaft, umfangreiche Mengen an Information auf homogene Weise, in der Regel als eine
Liste von Tupeln aus Daten-Attributen, zu speichern. Der Zugriff auf den Datenbestand
erfolgt über streng definierte Schnittstellen in Form einer Anfragesprache (query language).
Dies erfordert wohlgeformte Anfragekonstrukte auf Grundlage algebraischer Regeln, liefert
aber auch ebenso wohlgeformte Resultate.
Der gleichzeitige Zugriff mehrerer Benutzer auf die Datenbasis ist möglich; das DatenbankManagementsystem sorgt implizit dafür, daß der Zustand der abgelegten Daten zu jedem
Zeitpunkt konsistent ist. Tritt ein Konflikt zwischen Eingaben verschiedener Benutzer auf,
oder erfolgt eine Beendigung des Datenbankzugriffs, bevor der Anwender wieder einen
konsistenten Datenzustand herstellt, also die Transaktion abschließen konnte, so ermöglicht
eine Revertierungsfunktion zu jeder Zeit eine Rückkehr zum letzten konsistenten Zustand.
Grundsätzliche Aufgabe des Datenbanksystems ist also die Gewährleistung von Atomarität
der DB-Operationen, Konsistenz der Daten, Isolation und Dauerhaftigkeit, auch als ACIDPrinzip bekannt (Atomicity, Consistency, Isolation, Durability).
Die verschiedenen Anwender eines Datenbanksystems können die für sie relevanten oder
freigegebenen Daten in einer jeweils besonders angepaßten Form, einer sogenannten Sicht,
dargestellt bekommen.
Benutzern können Einzel- und Gruppenrechte zugeteilt werden, um den Umfang der für sie
erlaubten Lese- und Schreibzugriffe auf die Daten zu differenzieren. Die Datenbank-Sitzung
beginnt in diesem Fall mit einer Authentisierung über ein Paßwort oder einen Schlüssel.
Schließlich geschieht all dies in einer aktuellen Datenbank mit einer hohen Performanz, die
durch Cache-Verfahren, also dem Vorhalten häufig abgefragter Daten oder Operationen, und
Optimierung der Datenstruktur hin auf Verkürzung der Zugriffszeit erreicht wird.
Datenbanksysteme sind in Wirtschaft und Verwaltung seit Jahrzehnten im Einsatz. Die
meisten in irgendeiner Form bedeutsamen Informationen aus allen Bereichen von Gesellschaft
und Wirtschaft liegen in Datenbanken gespeichert vor.
Das World Wide Web ist eine Menge von Rechnern, auf denen Server für HTTP laufen, und
die Dokumente im HTML-Format zur Verfügung stellen. Hypertext-Referenzen (links) stellen
zwischen den Dokumenten Verbindungen her. HTML stellt dabei, für sich genommen, nur die
Möglichkeit dar, statische, textuelle Informationen mit einigen Formatierungen (Schriftgrößen
und -typen, Absatzausrichtung, Tabellen etc.) zu versehen. Die fortlaufende Aktualisierung
des Standards, und seine Erweiterung um Script-Möglichkeiten erlauben inzwischen die
Gestaltung
fast
beliebiger
statischer
oder
dynamischer
Oberflächen
für
Informationsdarstellung und Interaktion mit Benutzern.
4
Clients für HTTP (Browser), die in Abhängigkeit der gegebenen Technologie HTML-Seiten
mehr oder weniger getreu darstellen können, existieren für fast alle mit graphischer
Ausgabemöglichkeit versehenen Geräte die Informationen verarbeiten.
Eine idealtypische Web-Datenbank würde nun die Vorteile beider Systemansätze vereinen:
die Oberfläche für Ein- und Ausgabemasken ist einfach wie eine Web-Seite zu gestalten, der
Datenbankzugriff kann von überall auf der Welt mit einem beliebigen Web-Browser
geschehen, durch die DBMS-inhärenten Sicherheitseigenschaften ist die Datenbank trotzdem
vor dem Zugriff durch Unbefugte geschützt, unabhängig von der Zugriffsmethode ist die
Datenkonsistenz immer gewährleistet, und schließlich: Das System ist performant wie eine
„normale“ Datenbank und die einmal gewählte Technologie bleibt für wachsende
Anforderungen skalierbar.
Diese Anforderungen sind in ihrer Gänze nicht erfüllbar. Tatsächlich wird die Erfüllung einer
Anforderung oft die einer anderen erschweren oder sogar ausschließen. Die zu wählende
Technologie hängt in hohem Maße von der jeweiligen Anwendung ab; wenn sich das
Anforderungsprofil nun verschiebt, und sei es auch nur durch eine größere Zahl von
Anwendern, kann unter Umständen die eingesetzte Technologie systembedingt nicht mehr
weiterverwendet werden. Dem Einsatz eines WWW-basierten Informationssystems muß
deswegen eine sorgfältige Planung mit mittel- bis langfristigem Planungshorizont
vorausgehen.
1.2 Allgemeine Struktur
Aus den oben genannten Anforderungen ergeben sich einige Eigenschaften, welche eine Webbasierte Datenbank im allgemeinen haben wird, und welche grundlegenden Technologien zum
Einsatz kommen.
DBMS
HTTP-Protokoll
HTML-Client
Web-Server
Abbildung 1: Allgemeine Struktur von Web-Datenbanken
Web-Server
Das System basiert auf Dokumentformaten und Übertragungsprotokollen des WWW.
Voraussetzung für Verwaltung und Übertragung von HTML-Dokumenten, Scripten,
Dienstprogrammen und Konfigurationsdaten ist ein Web-Server. Der Server reagiert auf
Anfragen eines Client und stellt diesem über das HTT-Protokoll das jeweils von ihm
geforderte Dokument zur Verfügung. Beim angeforderten Dokument kann es sich um eine
5
Datei, in der Regel im HTML-Format, mit möglicherweise eingebundenen Graphiken oder
Animationen, aber auch um einen Programmaufruf handeln. Für den Client ist es
gleichbedeutend, ob er ein Dokument erhält welches aus einer Datei stammt, oder ob es die
Ausgabe eines Server-seitigen Programms ist.
Wenn aus einer Client-Anfrage hervorgeht, daß ein Datenbankzugriff erforderlich ist,
geschieht dies ebenfalls durch Server-seitige Programme. Die Ergebnisse von Anfragen
werden in Form von Hypertext-Dokumenten an den Client übertragen. Der Web-Server ist
also das verbindende Element zwischen Anwender und DBMS.
Web-Client
Der HTTP-Client in Form eines Browsers gibt dem Anwender eine Schnittstelle, um Daten
mit dem System auszutauschen. Die Darstellung der Resultate von Datenbankanfragen erfolgt
mittels der vom Server geschickten Dokumente. Die Anfrage selbst gestaltet sich etwas
komplizierter: sie kann als Parameter für ein Programm auf dem Server, oder auch als im
HTML-Code genestete Server-Befehle formuliert werden (siehe 1.4).
Um die Interaktion mit der Datenbank vom Benutzer zu kapseln, erfolgt die Eingabe der
Daten z.B. in einem Textfeld oder durch Anklicken einer Hypertext-Komponente; Elemente,
die leicht über HTML und Scriptfunktionen realisiert werden können. Bei der Ausgabe von
Daten müssen diese wiederum als HTML-Text formatiert werden, um sie im Browser des
Anwenders richtig darzustellen.
Datenbanksystem
Das Datenbanksystem erhält Anfragen vom Web-Server und liefert die Resultate dorthin
zurück. Die Programme auf dem Web-Server eröffnen eine Datenbankverbindung, starten
eine Sitzung und führen Zugriffe auf den Datenbestand in der vom DBMS (DatenbankManagementsystem) unterstützten Anfragesprache durch. Somit ist es für das
Datenbanksystem gleichbedeutend, ob es sich um eine Anfrage des Web-Servers oder z.B.
einer Datenbank-Applikation aus dem Firmennetz handelt.
Beim oben vorgestellten allgemeinen Ablauf eines Datenbankzugriffs wäre der
authentifizierte Benutzer also ein zum Web-Server gehöriger Prozeß (wie z.B. ein CGIScript), nicht aber der eigentlich entscheidende Benutzer des Web-Client. Für der
Öffentlichkeit allgemein zugängliche Informationsbestände stellt dies natürlich kein Problem
dar, wohl aber wenn man den Benutzerkreis einschränken muß. In 2.1 werden hierzu
unterschiedliche Lösungsansätze vorgestellt.
1.3 Datenbanken und http
HTTP (HyperText Transfer Protocol) wurde, wie es der Name nahelegt, zum Austausch
(statischer) Hypertext-Dokumente eingeführt. Natürlich ist auch das Versenden andersartiger
Dateien möglich, an eine Übermittlung von dynamischen Inhalten oder Datenbankzugriffen
wurde zum Zeitpunkt der Konzeption aber nicht gedacht. Das HTT-Protokoll kennt keinen
Zustandsspeicher oder ähnliche Mechanismen, um Verbindungsdaten über mehrere HTTPAnfragen an einen Server hinweg zu erhalten. Für den Server ist es prinzipiell gleich, ob eine
weitere Anfrage vom gleichen Client stammt wie eine zuvor eingegangene, oder ob es sich um
einen neu hinzugekommenen Client handelt.
6
Datenbanken hingegen basieren auf dem Konzept, das verschiedene Zustände der Daten
zwischengespeichert werden, um die Integrität der Daten erhalten bzw. wieder herstellen zu
können. Eine Sitzung ist in diesem Zusammenhang eine Folge von Zugriffen auf den
Datenbestand, welche einem eindeutig zu identifizierenden Benutzer zugeordnet ist. Lesende
Zugriffe können dabei ignoriert werden; für ändernde Zugriffe in Form von Transaktionen
muß aber sichergestellt sein, daß stets der letzte konsistente Zustand der Daten
zwischengespeichert wurde, um die Transaktion abbrechen oder nachträglich revertieren zu
können.
Die Zustände der Daten und die Erhaltung ihrer Konsistenz stellen in diesem Zusammenhang
kein Problem dar, da natürlich auch das Serverprogramm für den Datenbankzugriff nur
atomare Transaktionsoperationen auf den Daten durchführen kann. Das Konzept einer dem
jeweiligen Benutzer zuordbaren Sitzung ist über HTTP ohne weiteres aber nicht einsetzbar.
1.4 Konsistenz und Zustände
Zur Lösung des Problems der Zustandslosigkeit [EKR97] existiert natürlich die Möglichkeit,
das bestehende Protokoll behutsam zu erweitern, bzw. ein Zustand-stützendes Protokoll
einzuführen, allerdings lassen der Zeitaufwand für die Standardisierung und zu erwartende
Inkompatibilitäten diesen Ansatz wenig versprechend erscheinen. Für den praktischen Einsatz
benötigt man also einen Weg das Problem zu umgehen.
Zustände in Cookies speichern:
Es gibt bereits ein weit verbreitetes Mittel um Informationen, die von einem Server übertragen
wurden, dauerhaft auf dem Client-Rechner abzulegen: Cookies sind einfache Texdateien mit
Informationen über eine besuchte Seite und den besuchenden Client.
Beispiel: Ein Cookie
mycookie
general
www.somesite.com/
0
3429005568
29398667
2748658336
29397259
*
//Bezeichner
//Klassifizierung, oft alphanumerische Zeichenfolge
//Ursprung
//Datenblock
//Abschluß
Der Zugriff auf die in Cookies abgelegten Informationen ist nur dem Ursprungs-Server
gestattet. Er kann durch sie feststellen, ob der jeweilige Client gerade eine aktive
Datenbankverbindung unterhält, und führt sie gegebenenfalls weiter anstatt eine neue zu
starten. Allerdings sind Cookies nicht für alle Anwender akzeptierbar, da sie auch zur
Profilierung von einzelnen Benutzern verwendet werden können.
Den URL um Zustandsinformationen erweitern:
Eine Weitere Möglichkeit ist es, das an einen Client zu versendende Hypertext-Dokument bei
der dynamischen Erstellung oder Script-basierten Bearbeitung (siehe 2.5) mit einer Kennung
zu versehen. Bei Benutzeranfragen über dieses Dokument (z.B. über Eingabemaske) werden
7
nicht nur die explizit eingegebenen Daten als Parameter am Ende des URL (Uniformer
Ressourcen-Lokator) zurück an den Server übermittelt, sondern auch Informationen zur
Sitzung. Das Serverprogramm vergleicht die Kennung einer Datenbank-Anfrage mit der Liste
von Kennungen aktuell offener Sitzungen; ist eine entsprechende Sitzung bereits aktiv, so
wird diese weiterverwendet. Eine Datenbankverbindung bleibt so über mehrere Zugriffe
hinweg erhalten.
Beide oben vorgestellten Verfahren benötigen allerdings eine Möglichkeit zur impliziten
Beendung einer Sitzung, da der Anwender immer die Verbindung Client-seitig beenden kann,
ohne die Sitzung formell zu schließen. In der Regel bedient man sich hier einer Zeitgrenze,
bei deren Überschreitung ohne erneuten Datenbankzugriff durch den Benutzer, das Serverseitige Programm die Sitzung selbsttätig beendet und eventuell offene Transaktionen
revertiert. Somit wird die Konsistenz der Daten sichergestellt und die Belastung des WebServers und der Datenbank in Grenzen gehalten.
2 Technologien für die Datenbanknutzung im WWW
Da WWW-Seiten im klassischen Sinne etwas sehr statisches sind, sind offenbar Techniken
nötig, um sie mit Funktionalität auszustatten und für den Anwender interaktiv zu machen. Die
grundlegende Möglichkeit dafür ist seit geraumer Zeit das CGI-Konzept. In den vergangenen
Jahren sind jedoch einige neue Konzepte, sowohl auf Seiten des WWW-Clients als auch des
Web-Servers hinzugekommen.
2.1 Grundlagen von CGI
Bei CGI-Scripten handelt es sich in aller Regel um normale Programme, oder eben
Interpreter-abhängige Scripte, welche auch ohne Web-Server lauffähig oder sinnvoll sein
können. Sie ermöglichen es, auf eine Anfrage von außen (vom Client) her vielseitige
Funktionalitäten zur Verfügung zu stellen, die vom eigentlich verwendeten Web-Server
unabhängig sind.
Prinzipiell ist es egal, für welche Implementierungssprache man sich entscheidet;
Voraussetzung ist, daß sie auf dem Server-System lauffähig ist. Will man Beispielsweise eine
einfache dynamische Funktionalität als Interpreter-Script implementieren, so muß nur
gewährleistet sein, daß das jeweilige Programm (z.B. CShell oder (G)Awk) installiert ist. Viel
häufiger trifft man in diesem Zusammenhang jedoch auf Perl-Scripte oder C-Programme.
Bei CGI (Common Gateway Interface) selbst handelt es sich erst einmal nur um einen
Standard der festlegt, wie ein Programm gestartet wird, wie ihm Daten (z.B. Parameter)
zugeführt werden und wie die Ergebnisdaten des Programms zu Weiterverarbeitung
„abgegriffen“ werden können.
8
DBMS
HTML-Client
Ergebnis
HTTP
Anfrage
Web-Server
HTML
-Seite
ruft a
uf
select
Name
from
Personen
CGI-Programm
Abbildung 2: CGI-Programme liefern DB-Inhalte an einen Web-Server
Welches Programm ausgeführt werden soll, wird in der Regel über eine Hypertext-Referenz
festgelegt: die zugehörige Adresse umfaßt den Ort (in der Verzeichnisstruktur auf ServerSeite), an dem die Programmdatei zu finden ist, so wie normalerweise einige Parameter für
das Programm.
Beispiel:
http://134.106.1.33/cgi-bin/createindex.cgi?02022000Meldungen
verwendetes
Protokoll und ServerAdresse
Programmdatei in
der ServerVerzeichnisstruktur
Eingabedaten für das
Programm, z.B. aus
Eingabemaske
Abbildung 3: Exemplarischer URL für CGI-Anwendungen
Die Kommunikation mit dem CGI-Programm erfolgt über Datenströme, also stdin und stdout.
Während der Abarbeitung liest das Programm Zeichenketten aus dem Puffer des
Eingabedatenstroms, führt auf diesen Daten Operationen aus und schreibt die Ergebnisdaten
als Zeichenketten in den Ausgabepuffer. Dabei muß das keinesfalls in „einem Rutsch“
geschehen: da es sich um Puffer handelt, können Daten zu den jeweiligen
Verarbeitungsschritten sequentiell eingelesen/geschrieben werden; schon bereitgestellte Daten
können unter Umständen vor Abschluß des Programms durch den Server verschickt werden.
9
Beispiel: Arbeiten mit Datenströmen
#include <iostream>
int main() {
//keine Parameter
char *inputStreamData;
cin >> inputStreamData;
//einlesen
cout << “content-type: text/html \n\n“;
//HTML-formatierte Ausgabe
cout << “<body>\n“;
cout << “<h3>“);
cout << “Sie sagten: <ul>“ << inputStreamData << “</ul>“;
cout << “</h3>\n“;
cout << “</body>“;
return(0);
}
2.2 Datenbankzugriff im CGI-Programm
Stellt die für die CGI-Funktionalität gewählte Programmiersprache Schnittstellen für den
Datenbankzugriff zur Verfügung, und die meisten tun dies, so kann man auf diese Weise wohl
am einfachsten einen Datenbankzugriff implementieren [HeSa00]. Problematisch ist in
diesem Kontext jedoch die Authentifizierung der Benutzer. Man kann natürlich die Daten
undifferenziert der Allgemeinheit zugänglich machen. Eine Möglichkeit besteht darin, die
Benutzerinformationen dem Programm über seine Parameterliste mitzuteilen, welche z.B. aus
einem Eintrag in einer Login-Maske erzeugt werden kann.
Beispiel: Mit eingebetteten SQL-Anweisungen Daten auslesen
char *getUserData(char const cuId[12]) {
BEGIN DECLARE SECTION
char id[12], name[30], fName[30], currentUserId[12];
int nOrders;
END DECLARE SECTION
CurrentUserId=cuId
EXEC SQL CONNECT "dba" IDENTIFIED BY "sql";
EXEC SQL select KundenNr, Name, Vorname, AnzahlBestellungen
INTO :id, :name, :fName, :nOrders
FROM Kunden
WHERE id = :currentUserId;
EXEC SQL COMMIT WORK;
EXEC SQL DISCONNECT;
return(“%s %s\n(Kunden-Nr %s) hat bisher %n Bestellungen aufgegeben“,
fName, Name, id, nOrders);
}
Die Anweisungen innerhalb des DECLARE-Blocks und hinter EXEC SQL Anweisungen werden durch
einen Präcompiler ausgewertet, und der Quelltext statisch an die Programmierschnittstelle des
Datenbanksystems gebunden.
Diese unkomplizierte Vorgehensweise bietet sich vielleicht für personalisierbare Web-Seiten
nach dem Muster Mycommercial-website.com an, ist aber für Daten die eines wirklichen
Schutzes bedürfen inakzeptabel; hier sollte auf jeden Fall auf die sicheren
Authentifikationsverfahren der verwendeten Datenbank zurückgegriffen werden.
Es ergeben sich noch einige weitere Probleme. Für jede Benutzeranfrage auf die Funktion
eines CGI-Programmes wird eine neue Instanz dessen erzeugt. Diese belegt zusätzlich noch
10
einmal den gesamten für das Programm nötigen Arbeitsspeicher und, was schlimmer ist,
erhöht die Anzahl der durch das System zu verwaltenden Prozesse.
Weiterhin muß das Programm nach seinem Start eine Datenbanksitzung (Session) beginnen
und diese auch vor dem Beenden wieder schließen; längerfristige (klassische) Sitzungen des
Anwenders, welche z.B. auch das Neuladen einer Seite oder eine kurzfristige
Verbindungsunterbrechung überstehen könnten, sind mit den bisher vorgestellten Verfahren
nicht möglich. Datenbankinteraktion die sich über mehrere Zugriffe erstreckt, zieht also
immer einen überflüssigen Überhang an Verbindungsaufbau- und VerbindungsabbauOperationen mit sich, welcher die Datenbearbeitung verlangsamt.
2.3 Applets
In den vergangenen Jahren hat sich Java für immer mehr Client-seitige Web-Applikationen
durchgesetzt. Inzwischen besitzt jeder verbreitete Web-Browser eine Laufzeitumgebung für
Java, was es ermöglicht, die Datenbank-Funktionalität aus den HTML-Dokumenten
herauszunehmen und in Java-Applets zu kapseln. Das Applet selbst ist ein kleines Programm,
das vom Server übermittelt und Client-seitig ausgeführt wird. Aus Sicherheitsgründen
unterliegt das Applet einigen Einschränkungen: der Zugriff auf das lokale System ist klar
begrenzt (Ausführung im „Sandkasten“), eine Verbindungsaufnahme ist nur zu dem Server
erlaubt, von dem das Applet selbst geladen wurde.
Java bringt eigene Mechanismen (JDBC, SQLJ) für den Zugriff auf (entfernte) Datenbanken
mit sich. Die Verbindung kommt dabei nicht über HTTP, sondern über ein eigenes Protokoll
an einem anderen Port zustande, die klassische Datenbank-Sitzungen ermöglichen. Das
Applet wird außerdem in der Regel die Eingaben einer Vorprüfung unterziehen, um
eindeutige Falscheingaben auszufiltern, und die Datenbank zu entlasten.
JDBC / J
SQL
Applet
DB-Teil
-?Aufruf
Web-Teil
HTTP
Server
HTML-Client
Abbildung 4: Kapselung der DB-Zugriffe in einem Applet
Applets verlassen aber den Pfad einer vollständigen Web-Integration: das Applet kann nicht
Eingaben aus HTML-Masken übernehmen oder Resultate in HTML-Text einfügen. Zwar ist
es möglich, mittels in das Dokument eingebetteter JavaScript-Anweisungen Daten aus dem
Dokument an das Applet zu übergeben, und mehrere Dokumente über die gleiche Verbindung
11
zu bedienen, allerdings müssen Applet und HTML-Code bei jeder Anpassung eng aufeinander
und auf den jeweiligen Browser abgestimmt werden. Die Übertragung der Applet-Daten
zurück ins Dokument ist im allgemeinen nicht möglich, und kann bei Einsatz einer einzigen
Version des Dokuments für alle Browser nicht verwendet werden. Auf Grund der oben schon
genannten Sicherheitseinschränkungen, muß der Datenbank-Server für die Applets auf dem
physisch gleichen System laufen wie der Web-Server der das Applet verschickte, was
Leistungsprobleme aufwerfen kann (gleicher Prozeßraum, geteilter Hauptspeicher und daraus
folgende Ressourcenknappheit).
2.4 Externe Anwendungen und Plug-Ins
Der nächste Schritt bei der Verselbständigung der Datenbank-Schnittstelle wäre die
Verwendung einer von Web-Browser und HTML-Einbindung unabhängigen DatenbankAnwendung. Bei der Entwicklung wären Programmiersprache, Architektur und verwendetes
Protokoll frei wählbar, und die Eigenschaften der jeweils verwendeten Datenbank voll
ausnutzbar. Im Vergleich dazu steht bei Java-Applets nur eine Untermenge der JDBCFunktionalität mit allgemeinem Charakter zur Verfügung. Das Datenbanksystem kann in
diesem Fall vom Web-Server physisch vollkommen getrennt sein, was die Performanz der
beiden Systeme steigert, und sie voneinander unabhängig skalierbar macht (z.B. muß bei
erhöhtem Zugriff auf die Web-Präsenz nicht unbedingt das Datenbanksystem auf eine
leistungsfähigere Plattform umgestellt werden).
Datenbank-Server
DB-”Betrachter”
Aufruf
HTTP
Web-Server
HTML-Client
Abbildung 5: DB-Zugriffe mit eigenständiger Anwendung
Um das Programm bei einem gewünschten Datenbank-Zugriff aus dem Browser heraus
starten zu können, sendet der Server bei einer entsprechenden Anfrage ein MIME-codiertes
Dokument. MIME (Multi-purpose Internet Mail Extension) ist eine Dokumentkennung die
festlegt, welchen Typs der Inhalt eines Dokumentes ist. Um auf das empfangene Dokument
richtig reagieren zu können, muß der entsprechende MIME-Typ auf dem Client-System
registriert worden sein. Stößt der Browser nun auf eine Extension wie z.B.
application/corpdbaccess, und ist in der Liste der MIME-Typen zu dieser Extension eine
12
lokale Anwendung eingetragen, so wird sie vom Browser gestartet und beginnt die eigentliche
Datenbank-Verbindung.
Obwohl es sich um einen leistungsfähigen und sicheren Ansatz für entfernte DatenbankZugriffe handelt, wurde das Ziel der Web-Integration mit vielen seiner Vorteile praktisch
aufgegeben. Das System ist nicht mehr plattformunabhängig, sondern nur auf den bei der
Entwicklung berücksichtigten Plattformen lauffähig. Die Anwendung hat keine WebOberfläche, damit werden oft Gestaltungsmöglichkeiten eingeschränkt, da Oberflächen für
klassische Anwendungen gegenüber dem Web weniger Möglichkeiten bei der graphischen
Darstellung bieten. Des weiteren erfordert eine Neugestaltung oft auch eine
Neuprogrammierung.
Plug-Ins funktionieren nach dem gleichen Prinzip, sind aber noch enger an den jeweiligen
Browser gebunden und erscheinen im selben Fenster wie die HTML-Darstellung. Beide
Ansätze haben das große Problem, daß vor einer Verwendung ein Prozeß des Herunterladens
und Installierens der Applikation steht. Eine solche Lösung bietet sich nur an, falls ein enger,
überschaubarer Personenkreis für die Verwendung der Datenbank vorgesehen ist, und der
Betreiber (z.B. der Arbeitgeber oder ein marktführender Anbieter) die zu verwendenden
Client-Systeme vorgeben kann. Anderenfalls ist bereits ein gewisses Vertrauensverhältnis
zwischen Anwender und Betreiber vorauszusetzen, da die Applikation über die
Systemressourcen des Anwenders verfügen kann.
2.5 Server-seitige HTML-Macros
Eine weitere Möglichkeit, dynamische Web-Seiten zu gestalten, sind HTML-MacroErweiterungen. Die Dokumente enthalten Script-Anweisungen, welche durch den Web-Server
vor dem Versenden ausgeführt werden. Die Rückgabewerte der Script-Funktionen (z.B.
Datenbankzugriffe) werden anschließend in das Dokument eingefügt, und ersetzen die ScriptMacros; dabei können natürlich auch Client-seitig auszuführende Scripte (JavaScript)
dynamisch eingebaut werden.
HT
TP
HTML-Client
HT
TP
Dateizugriff
Web-Server
Abbildung 6: Der Server interpretiert Macro-Anweisungen
13
Die Syntax dieser Macros ist abhängig vom verwendeten Web-Server. Der NIS von Netscape
verwendet ein System namens LiveWire, der IIS von Microsoft verwendet sogenannte Active
Server Pages, die eingebettete Anweisungen in VBScript oder JavaScript enthalten [ASP96].
Beispiel: Einbettung von ASP-Anweisungen
<%
//Anfang des Macros
if Time>=#12:00:00 AM# and Time<#12:00:00 PM# then
greeting=“Guten Morgen!“
else
greeting=“Hallo!“
end if
%>
//Wertzuweisung
//Ende des Macros
...
<font color=green>
<%=greeting%>
</font>
//HTML-Anweisungen
//Ergebnis einfügen
Dieses Verfahren hat wie CGI den Nachteil, daß längerfristige Datenbankverbindungen nicht
direkt unterstützt werden. Die Verbindung zur Datenbank besteht nur während des Parsens der
Datei durch den Server-eigenen Macro-Interpreter, wird anschließend beendet, und die
erhaltenen Ergebnisse werden formatiert und eingefügt. Microsoft und Netscape unterstützen
dabei mit ihren Technologien die bedeutenden, kommerziellen Datenbanksysteme. Die
Eigenschaften bezüglich Transaktionssteuerung und Authentifizierung entsprechen den von
CGI bekannten.
Vorteilhaft gegenüber dem CGI-Konzept ist die schnelle und leichte Programmierung der
Macros, die normalerweise keine Programme darstellen, sondern als kompakte Anweisungen
über das Dokument verteilt sind. Der Entwicklungsprozeß ist damit gegenüber CGI stark
vereinfacht; es besteht aber auf Grund der konzeptionellen Einschränkungen nicht die
Möglichkeit komplexe Anwendungen zu implementieren. Ein möglicher Leistungsvorteil
ergibt sich durch die Auslagerung der Datenbankzugriffe auf den Server, allerdings hängt dies
von der Qualität der jeweiligen Implementierung ab.
Offensichtliches Problem ist die Plattformabhängigkeit der Systeme: ein Austausch des
verwendeten Web-Servers ist nur mit gleichzeitiger Neuprogrammierung der dynamischen
Dokumentbestände möglich. Die Abhängigkeit besteht dabei vom verwendeten Server, dem
Datenbanksystem und möglicherweise dem Betriebssystem.
Eine neuere Entwicklung auf diesem Gebiet sind die Java Server Pages (JSP), die von Sun
Microsystems als eine Erweiterung des Servlet-Konzepts (siehe 2.7) eingeführt wurden
[JSP01]. Dabei werden Java-Anweisungen, in der Form, wie sie auch in einer JavaAnwendung vorkommen, in den HTML-Quelltext eingebettet. Vorteilhaft dabei ist die
Möglichkeit,
weitergehende
Programmierparadigmen
wie
die
objektorientierte
Programmierschnittstelle zu ignorieren. Auch hier ist die Implementierung komplexer
Anwendungsfunktionalität nicht ohne weiteres möglich. Trotz der plattformübergreifenden
Natur des Konzepts ist es auf bisher auf einige Server-System-Kombinationen beschränkt, da
es sich um eine neue Technik handelt. Die sonstigen Eigenschaften dieses Ansatzes
entsprechen im wesentlichen denen von Servlets.
14
2.6 Web-Server mit API
Eine Server-eigene Programmier-Schnittstelle (API, Application Programming Interface)
dient zur Erweiterung des Server-seitigen Programmierkonzeptes, wie es aus der CGIProgrammierung bekannt ist. Wie schon erwähnt, besitzt das CGI-Konzept einige Schwächen
wie die hohe Anzahl von Prozessen und das Fehlen persistenter Datenbankverbindungen, was
ständigen Verbindungsaufbau und -abbau mit entsprechendem Überhang bedingt. Diese
Probleme können bei Verwendung einer Server-API gelöst werden, indem Teile der
benutzerspezifischen Funktionalität an den Server delegiert werden. Eine
Datenbankverbindung wird nun durch den Server gestartet und behandelt; sie dient dann für
die Datenbankanbindung über mehrere Zugriffe hinweg. Die hohe Prozeßlast wird dadurch
reduziert, daß nicht für jedes Server-Programm ein eigener Prozeß läuft, sondern der Server
ihre Funktionalität in einer geringeren Anzahl von Prozessen zusammenfaßt.
HTML-Client
HT
fe
fru
u
I-A
AP
TP
DLL
DB
Web-Server
-An
fra
ge
n
DBMS
Abbildung 7: Ein Programmierbarer Web-Server
Um Anwenderprogramme innerhalb des Server-Prozeßraums und -Speichers laufen zu lassen,
muß das jeweilige Programm zum Compilierungszeitpunkt statisch an die jeweilige API
gebunden werden. Der Programmstart erfolgt anschließend über den Web-Server, der die
gewünschte Funktion (Server-eigene oder selbstprogrammiert) mit dem URL mitgeteilt
bekommt.
Die zwei verbreiteten APIs sind ISAPI von Microsoft und NSAPI von Netscape. Da sie nur für
die jeweiligen WWW-Server verfügbar sind, ist man mit den einmal programmierten ServerFunktionen also auf einen Anbieter festgelegt. Ein weiterer Nachteil ist, daß sich die
Entwickler sich erst auf die Eigenheiten der verwendeten Schnittstelle einstellen müssen.
Weiter muß ein Verfahren gefunden werden, um Datenbanksitzungen implizit beenden zu
können, da sich bei längerfristigen Sitzungen über HTTP der Client einfach die Verbindung
einseitig unterbrechen kann [BeGr98].
2.7 Servlets
Auch das Konzept der Servlets beruht auf einer Server-Programmierschnittstelle. Es stellt eine
Erweiterung der Programmiersprache Java dar und wurde von Sun Microsystems als
Alternative für die oben genannten APIs eingebracht. Die Programmierung erfolgt wie bei
einer normalen (Client-seitigen) Java-Anwendung. Wie die Kern-API von Java sind auch die
Server-Erweiterungen (javax.*) objektorientiert. Eine Java-Klasse wird dadurch an den Server
gebunden, indem sie die Schnittstelle javax.servlet.Servlet implementiert, und die zugehörigen
15
Methoden überschreibt. Für die Erweiterung eines WWW-Servers ist normalerweise die
abgeleitete Klasse HttpServlet zu implementieren [Mar97].
Servlet
HttpServletRequest
*
service()
init()
getServletConfig()
destroy()
getServletInfo()
getParameter()
getQueryString()
...
HttpServletResponse
HttpServlet
1
doPost()
doGet()
...
sendError()
* getOutputStream()
setCOntentType()
setContentLength()
...
Abbildung 8: Grobe Übersicht der Servlet-Klassen und -Methoden
Vorteilhaft an diesem Konzept ist die Plattformunabhängigkeit, da die eigenen Servlets
potentiell auf allen Systemen verwendet werden können, auf welche die JavaLaufzeitumgebung portiert wurde. Für die Entwicklung stehen alle bereits bestehenden JavaKomponenten und erweiterungen (z.B. Beans) zur Verfügung. Der konzeptionelle
Unterschied zur Programmierung herkömmlicher Java-Applikationen oder -Applets ist
minimal. Die Servlet-Klassen werden nur jeweils einmal instantiiert und behandeln
anschließend alle zugehörigen Funktionen, wie Ein- und Ausgabe und Datenbankzugriffe in
der Java-eigenen multi-Thread-Laufzeitumgebung. Dadurch wird auch hier gegenüber
klassischer CGI-Programmierung eine Leistungssteigerung auf dem Server-Rechner und beim
Datenbanksystem erreicht.
Beispiel: Eine Implementierung für HttpServlet.doPost()
//doPost() wird wird automatisch durch service() aufgerufen. doGet()
//unterscheidet sich nur dadurch, daß Parameter im URL codiert wären
protected void doPost(HttpServletRequest req,
HttpServletResponse resp) throws IOException {
String query=req.getParameter(“Eingabe“);
//Formular “Eingabe“ einlesen
StringBuffer buffer=new StringBuffer();
buffer.append(“<html>\n“);
//HTML-Quelle erzeugen
buffer.append(“<body>\n“);
buffer.append(“<h1>Ihre Eingabe war:</h1>\n“);
buffer.append(“<blockquote>“);
buffer.append(query);
buffer.append(“</blockquote>\n“);
buffer.append(“</body>\n“);
buffer.append(“</html>“);
resp.setContentType(“text/html“);
//MIME-Typ festlegen
resp.setContentLength(buffer.length());
//Länge festlegen
resp.getOutputStream().print(buffer.toString());
//versenden
}
16
Das Ganze muß in ein HTML-Formular eingebunden werden:
<form: action=“http://localhost:8080/servlets/echo-ausgabe“ method=“POST“>
<input name=“Eingabe“> <input type=“SUBMIT“>
</form>
Der Entwickler muß bei der Implementierung der Methoden doGet() und doPost() selbst dafür
sorgen, daß Formulardaten ausgewertet, und Ausgaben schon im Servlet als HTML-Daten
formatiert werden. Dabei können aber unter Umständen schon verfügbare Komponenten
eingebunden werden, um den Programmieraufwand zu reduzieren. Trotz der Erweiterungen
an der Java-API handelt es sich bei Servlets im Grunde um eine Standardisierungsbemühung.
Die tatsächliche Implementierung der API-Funktionen hängt von den jeweils verwendeten
Web-Servern ab, wodurch das Versprechen von Plattformunabhängigkeit nur bedingt
eingelöst werden kann. Allerdings sind die Erweiterungen inzwischen für Netscape-NIS,
Microsoft-IIS, Apache u.a. verfügbar, was eine recht breite Basis verwendbarer Systeme
darstellt.
3 Das Web als Datenbank
Große Datenbestände finden sich nicht nur in normalen Datenbanksystemen, wie sie seit
langer Zeit im Einsatz sind, sondern natürlich auch im WWW. Während die Suche nach
Informationen in Datenbanken seit jeher durch standardisierte Anfrageverfahren und
wohlgeordnete Datenbestände erleichtert wird, gilt keine dieser Voraussetzungen für die
Daten im WWW. Die Daten Im Web unterliegen keiner übergeordneten Strukturierung und
liegen in der Regel nicht geordnet vor.
3.1 Das WWW modellieren
Ein erster Ansatz könnte nun darin bestehen, daß man, wenn schon die Daten nicht zu ordnen
sind, doch wenigstens die sie enthaltenden Dokumente einer Ordnung unterwirft. Die
Hypertext-Dokumente im Web sind in der Regel durch Referenzen (Links) miteinander
verbunden. Möchte man dies modellieren, so stellen die Links gerichtete Kanten dar, welche
Knoten Verbinden, als welche man die zugehörigen Dokumente begreifen kann.
Dokument 2
Dokument 1
“Mitarbeiter”
“meine Firma”
“Seite eines Bekannten”
Dokument 3
Dokument 4
Abbildung 9: Das Web ist ungeordnet
17
Allerdings ist man immer noch nicht in der Lage auf Grund dieser formalen Beschreibung als
Graph eine Suche auf den Dokumenten Durchzuführen: man weiß weder wo man anfangen
soll, noch mit was für einer Reichweite (Tiefe) zu suchen ist. Beachten wir diese
Voraussetzungen, so ergibt sich als zugehörige Graph-Normalform natürlicherweise eine
baumartige Struktur.
Wurzel
2.
1.
1.
2.
2.
2.
2.
3.
3.
3.
3.
3.
3.
3.
HTML-Dokument
Hypertext-Referenz
Abbildung 10: Hypertext-Dokumente in einer Baumstruktur
Ausgehend von einem festgelegten Startknoten, mit einer vorgegebenen Suchtiefe und mit
Angabe von Link- und Dokumenteigenschaften, lassen sich aus einer solchen Baumstruktur
gezielt Dokumente mit den gewünschten Eigenschaften heraussuchen [EKR97].
Der Einsatz solcher Verfahren bietet sich zum Beispiel für eine Suchmaschine an: durch
Einbeziehung der Link-Struktur ließe sich über die Anzahl von Verknüpfungen aus
themenrelevanten Seiten heraus auf ein einzelnes Dokument, dessen Bedeutung für das
Thema einschätzen.
3.2 Anfragesprachen für das Web
Um eine einfache Benutzung der Suchalgorithmen in baumartigen Dokumentstrukturen zu
ermöglichen, versuchte man für die Beschreibung der Suchaufgabe Sprachen zu definieren,
die den schon bekannten Anfragesprachen für herkömmliche Datenbanken ähnelten. Bei
unterschiedlichen Forschungsgruppen entstanden unter anderem W3QL [KS95] und WebSQL
[MMM97]. Wie es der Name nahelegt, ist WebSQL an Konzept und Syntax der
Anfragesprache SQL angelehnt. Das Web wird hier als eine virtuelle relationale Datenbank
mit zwei Relationen Dokument und Anker (=Link) aufgefaßt. Für jedes HTML-Dokument
existiert in der Dokument-Relation ein Tupel, und für jeden in den Dokumenten enthaltenen
Link gibt es ein Tupel in der Anker-Relation. Da es sich nur um virtuelle Relationen handelt,
basiert die Semantik von WebSQL auf ihrer portionsweisen Materialisierung. Die
Materialisierung erfolgt durch das verfolgen von Referenzen aus bekannten Dokumenten
heraus, und wird in der from-Klausel festgelegt.
18
Beispiel: Eine Anfrage mit WebSQL
select lokalesDokument.url,
entferntesDokument.url,
link.label
from Document lokalesDokument
such that “www.startseite.de“ ->* lokalesDokument,
Document entferntesDokument
such that lokalesDokument => entferntesDokument,
Anchor link
such that link.base = lokalesDokument.url
where link.href = entferntesDokument.url
Es werden Tripel aus je zwei Dokument-Adressen und einer Link-Beschriftung ausgewählt, wobei das
erste Dokument lokal vorliegt und in beliebig vielen Schritten von der Startseite aus zu erreichen ist,
und das zweite Dokument vom ersten aus nach einem Schritt erreichbar ist.
Solche Web-Suchsprachen der ersten Generation sind also in der Lage Dokumente und Links
bezüglich ihrer Eigenschaften anzufragen und zurückzuliefern. Auch wenn sie eine
Textmuster-Suche innerhalb der jeweiligen Dokumente unterstützen, betrachten sie
Hypertext-Dokumente als atomare Einheiten und bieten keinen Zugriff auf die einzelnen
HTML-Elemente.
Web-Anfragesprachen der zweiten Generation erlauben den Zugriff auf die inneren Strukturen
der Web-Objekte die sie manipulieren; sie werden auch als Web-Datenmanipulationssprachen
bezeichnet. HTML-Dokumente müssen hier bei der Bearbeitung einem Parser unterworfen
werden, der die ermittelten Dokumentbestandteile in einer baumartigen Datenstruktur
verwaltet. Da auch die Dokumentobjekte selbst in einer solchen Struktur gehalten werden,
wird das vorher eingeführte theoretische Konzept erweitert: interne Kanten stellen
Beziehungen zwischen Dokument-Bestandteilen und externe Kanten Beziehungen zwischen
den Dokumenten selbst (Links) dar. Ein solches Konzept bietet sich für die Verwaltung einer
größeren Anzahl von Dokumenten an, wie sie z.B. in Redaktionssystemen nötig ist. In den
ausgewählten Dokumenten können Daten nicht nur ausgelesen, sondern auch aktualisiert
werden.
Beispiel für eine solche Manipulationssprache ist StruQL [FFLS97], das sogar explizit
Bestandteil eines Web-Seiten-Redaktionssystems ist. Diese Sprachen basieren in ihrer Syntax
ebenfalls (vage) auf bekannten SQL-Klauseln, sind aber auf Grund der mit dem
Anwendungsbereich verbundenen Erstellung und Veränderung von Hypertext-Dokumenten
im Wesentlichen funktionale Sprachen. Beide vorgestellten Sprachklassen sind Ergebnis
neuerer wissenschaftlicher Forschung und noch nicht Gegenstand von praktischem
(kommerziellem) Einsatz und Standardisierungsbemühungen. Die heute für diese
Aufgabenstellung bei Suchmaschinen und Redaktionssystemen im Einsatz befindlichen
Architekturen und Algorithmen in sind in ihrer Mehrzahl proprietär, nicht offengelegt, und
stellen nicht selten die Existenzgrundlage eines Unternehmens dar.
19
4 Datenintegration
Das WWW enthält eine ständig wachsende Zahl an Informationsquellen verschiedenster Art.
Wie oben erwähnt, finden sich solche Daten-„Tupel“ oft als Bestandteile eines HTMLDokuments; sie können aber auch, hinter einer Benutzeroberfläche verborgen, in einer
herkömmlichen Datenbank gespeichert sein. Datenintegration hat es zum Ziel, verteilte
Datenquellen verschiedenster Art über eine einheitliche Schnittstelle zugänglich zu machen.
4.1 Klassifizierung
Es stellt sich die Frage, ob es im realen Einsatz möglich ist, für jede Anfrage die zugehörige
Verarbeitung, Weiterleitung, Beantwortung und Ausgabeformatierung abzuwarten. Da über
die Leistungsfähigkeit und Zuverlässigkeit der verwendeten Quellen keine allgemeinen
Feststellungen zu treffen sind, würde dies auch für das Integrationssystem an sich gelten. Es
gibt im Wesentlichen zwei Klassen von Daten-Integrationssystemen:
Data Warehouses
Die klassischen Datenintegrationssysteme sind sogenannte Data Warehouses (in der
deutschen Literatur manchmal auch Daten-Warenhäuser, [Krc97]). Die Daten werden wie
bereits erläutert aus den verschiedenen Quellen geladen. Allerdings geschieht dies nicht zum
Zeitpunkt der Benutzeranfrage, sondern unabhängig davon, in einer bestimmten
Regelmäßigkeit. Offensichtlicher Vorteil dieser Idee ist, daß das System auf Benutzeranfragen
performanter reagieren kann, da die angefragten Daten schon lokal oder auf einem gut
erreichbaren, eigenen Datenbanksystem vorliegen.
Der offensichtliche Nachteil des Konzepts liegt darin, daß nicht garantiert werden kann, ob
die lokal vorgehaltenen Daten mit denen in der eigentlichen Quelle zu jedem Zeitpunkt
identisch sind, da sich zwischen dem Importieren der Daten ins Warenhaus und dem
Benutzerzugriff der Inhalt der eigentlichen Datenquelle geändert haben kann.
Virtuelle Datenintegration
Der Ansatz bei virtuellen Datenintegrationssystemen besteht darin, daß die Quelldaten nicht
immer lokal vorliegen, sondern zur Laufzeit aus den entfernten Datenquellen geladen werden.
Wie schon angemerkt, wirft dieses Vorgehen Fragen zur Leistungsfähigkeit des Systems auf.
Im Unterschied zum Data Warehousing müssen hier also die Komponenten zur AnfrageAuswertung, Ablaufoptimierung, und Ausführungssteuerung (in Abbildung 11 die
umrandeten Bereiche) deutlich höher entwickelt sein, um den Anwendern unverantwortlich
lange Reaktionszeiten zu ersparen. Aus diesem Grund richtet sich in letzter Zeit der Großteil
an Forschung im Bereich Datenintegration auf diese Systeme.
Trotz der Optimierungsstrategien werden Anfragen auf die lokal gespiegelten Daten im
Durchschnitt schneller ausgeführt werden können als auf die ursprünglichen Datenquellen.
Die Entscheidung für einen der beiden Ansätze hängt also von der Art verwendeter Quellen
ab: ob sie häufig wechselnden Inhalts sind, wie zuverlässig sie erreichbar sind, wie sie in ihrer
Priorität zu bewerten sind und wie umfangreich die jeweiligen Datenbestände sind. Ein
weiteres Kriterium für den Import in ein Integrationssystem ist die Fragestellung, inwieweit
die Datenquellen überhaupt ohne eine spezielle Client-seitige Software verwendbar sind.
20
Sollte das nicht der Fall sein, bietet sich ein zentralisierter Zugriff über ein
Datenintegrationssystem an, um aufwendige Änderungen an allen betroffenen Clients zu
vermeiden.
Benutzungsoberfläche
Globale Sichtdefinition
Resultate
(WWW-basiert)
Anfrage
QuellenBeschreibungen
Relevanzprüfung
Plan-
Inhalte
&
Fähigkeiten
Logik-Planer
Generator
Ausführungs-Planer
Ausführungsplan
AusführungsLogik
Selektion, Projektion, Verbund ...
Schnittstellen-Programm
Schnittstellen-Programm
Schnittstellen-Programm
Schnittstellen-Programm
,,INTERNET’’
#Mitarbeiter
Meyer
Maier
Müller
Kunz
Strukturierte Dateien
Name
Tel..
Adr.
Hypertext-Formulare
Relationale Datenbank
Objektorientierte Datenbank
Abbildung 11: Beispiel für die Architektur eines Datenintegrationssystems (nach [FLM98])
4.2 Aufbau von Datenintegrationssystemen
Aufgabe eines Web-basierten Datenintegrationssystems ist es, die Informationen aus
verschiedensten WWW-Quellen auf Anfrage zu extrahieren und so darzustellen, als würden
die verwendeten Quellen Datentupel anstatt liefern, anstelle von Daten, die keiner festen
Ordnung unterliegen. Kriterium für das Ermitteln einer Ordnung über den Daten ist in diesem
Fall deren Anordnung innerhalb eines Dokuments, nicht die (Hyperlink-)Struktur zwischen
Dokumenten. Um dies zu ermöglichen bedient man sich einer Reihe von besonders auf die zu
verwendenden Quellen maßgeschneiderter Zugriffsfilter (Wrappers). Dabei handelt es sich um
(Teil-)Programme des Systems, die Anfragen, formuliert für die jeweiligen Schemata einer
Datenquelle, in tatsächliche Zugriffe auf diese umwandeln. Ist die Quelle keine Datenbank, so
ist dieses Schema nur virtuell.
Bei den verwendeten Datenquellen muß es sich dabei nicht um eine Hypertext-FormularOberfläche handeln, auch algorithmisch verwertbare (wohlstrukturierte) Dateien sowie direkt
zugängliche Datenbanksysteme kommen in Frage. Der Zugriff auf Datenbanksysteme kommt
dabei ohne Dokumentanalyse-Algorithmen aus, allerdings ist sicherzustellen, daß nach der
Umsetzung der Anfragen in das Schema der einzubindenden Datenbank auch die Semantik
erhalten bleibt. Für den Zugriff auf strukturierte Dateien benötigt man eine Logik, welche die
21
benötigten Informationen ausliest, und als Anfrage-Resultat des zugehörigen virtuellen
Schemas formuliert. Am Schwierigsten ist der Zugriff auf Hypertext-Dokumente: es wird ein
HTML-Parser benötigt, der Datenwörter aus Dokumenten extrahiert, und eine Logik, welche
die Daten in das verwendete Schema bringt. Problematisch dabei ist, daß sich die Struktur von
Web-Dokumenten, und damit auch die Semantik der extrahierten Daten, relativ häufig ändern,
während einmal eingeführte Dateiformate oder Datenbankschemata nur selten und ungern
gewechselt werden.
Ein offensichtliches Problem beim Anbinden solcher Datenquellen über das Internet (bzw.
Intranet) sind Einschränkungen bei den jeweils zulässigen Anfragen (z.B. Sicherheitsgründe,
Implementierung der Web-Formulare), und Randbedingungen, welche bezüglich der
vorliegenden Daten zu berücksichtigen sind (z.B. Vollständigkeit, Fehlerfreiheit).
Der eigentliche Kern des Integrationssystems hat also die Aufgabe, Anfragen, die für ein
intermediäres Vermittlerschema formuliert wurden, an die Schnittstellenprogramme
weiterzureichen. Hierzu muß die Anfrage analysiert werden, um die relevanten Datenquellen
zu ermitteln. Nötig dafür ist eine Quellenbeschreibung und eine Definition der jeweiligen
Sichten auf die Daten. Es wird ein Plan zur Abfrage der ermittelten Datenquelle(n) erstellt,
und die jeweiligen Anfrageklauseln werden formuliert.
Die Resultate der Anfrage können wie normale Datenbankergebnisse mit einer (Web-)
Oberfläche an den Benutzer weitergeleitet werden.
5 Abschließende Anmerkungen
Wie eingangs erwähnt, stellt die Verbindung von Datenbank- und Web-Technologien die
Entwickler vor einige Probleme. Es existiert allerdings auch eine Reihe von Lösungsansätzen.
Diese besitzen unterschiedliche Schwerpunkte bezüglich ihrer Zielsetzung, und sind jeweils
Ergebnis eines Abwägens von Anforderungen und technisch bedingten Einschränkungen.
5.1 Zusammenfassung
Trotz seines Alters ist die CGI-Programmierung immer noch die am weitesten verbreitete
Methode zur dynamischen Generierung von Web-Seiten. Grund dafür ist die weite
Verbreitung der zugehörigen Programmierkenntnisse; jede andere Technologie braucht einige
Jahre, bis sich eine vergleichbare Entwicklergemeinde herausgebildet hat. Weitere Vorteile
sind die Flexibilität und der plattformübergreifende Charakter von CGI.
Die erweiterten Server-API-Konzepte haben den Nachteil, daß sie die Freiheit bei der Wahl
der Scriptsprache einschränken, und ein Erlernen der API-Syntax erforderlich wird. Größere
Chancen ergeben sich für dynamische Web-Seiten auf Basis eingebetteter Script-Kommandos;
die Entwicklung ist leicht zu erlernen, da kaum höhere höhere Programmierkonzepte oder
Schnittstellen zu beachten sind, und Anweisungen direkt an die passende Stelle im HTMLCode eingefügt werden.
Trotz der Vorteile bei Sicherheit und Transaktionssteuerung werden die Client-seitigen
Erweiterungen wie Plug-Ins oder dedizierte, nicht voll Web-integrierte Applets für den
allgemeinen Datenbankzugriff nicht von großer Bedeutung sein, wohl aber sind sie Mittel der
Wahl, wenn der Zugriff Beschränkungen unterliegen soll. Es zeigt sich wieder, daß
22
allgemeine Empfehlungen in diesem Bereich nicht sinnvoll sind, sondern die passende
Technologie in höchstem Maße vom Einsatzzweck abhängt.
Allgemein entwickelt sich jedoch der Trend von proprietären Lösungen weg, da sich sowohl
Server- als auch Client-Systemarchitekturen zunehmend diversifizieren, und eine
Interoperabilität der verschiedenen Systembestandteile eine berechtigte Kundenforderung ist.
5.2 Ausblick
Die Verbindung WWW-Datenbanken wird in Zukunft weiter an Bedeutung gewinnen, da
sowohl die Verwendung von Web-Oberflächen in allen Anwendungsbereichen zunimmt, als
auch die Menge zu handhabender Daten. Datenbanksysteme befinden sich auf dem
Vormarsch und verdrängen immer mehr die vorher oft firmentypische und zueinander
inkompatible dateiorientierte Datenverwaltung. Zusammen mit dem offenen DokumentAustauschformat XML (eXtensible Markup Language) sorgen sie auch in diesem Bereich für
eine Zurückdrängung proprietärer Standards.
Es bleibt der Wunsch nach einer quasi „natürlichen“ Hypertext-Anbindung von
Datenbanksystemen; also eine nahtlose Einbettung von echten Datenbanksitzungen, mit all
ihren Vorteilen. Ein interessanter Ansatz in dieser Richtung ist die Entwicklung von XMLbasierten Anfragesprachen.
Auch auf absehbare Zeit wird damit der Bereich WWW-Datenbank-Kopplung Gegenstand
von wissenschaftlicher Forschung und Standardisierungsbemühungen sein.
23
Literatur:
[ASP96] Was ist Active Server Pages?
Microsoft Corporation 1996; http://www.altmuehlnet.de/~schneider-m/asp
[BeGr98] Zugriff auf Datenbanken über das World Wide Web
Wolfgang Benn, Ingo Gringer; Informatik-Spektrum 21 (S. 1-8), Springer 1998
[EKR97] Connecting Databases to the Web: A Taxonomy of Gateways
Gerald Ehmayer, Gerti Kappel, Siegfried Reich; Johannes Kepler Universität Linz 1997
[FFLS97] A Query Language for a Web-Site Management System
Mary Fernandez, Daniela Florescu, Alon Levy, Dan Suciu;
SIGMOD Records 26-3, 1997
[FLM98] Database Techniques for the World Wide Web: A Survey
Daniela Florescu, Alon Levy, Alberto Mendelzon; SIGMOD Records 27-3, 1998
[HeSa00] Datenbanken: Konzepte und Sprachen
Andreas Heuer, Gunter Saake; MITP-Verlag 2000
[JSP01]
Java Server Pages: Dynamically Generated Web Content
Sun Microsystems Inc. 2001; http://www.javasoft.com/products/jsp/index.html
[Krc97]
Informationsmanagement
Helmut Krcmar; Springer Verlag 1997
[KS95]
W3QS: A Query System for the World Wide Web
David Konopnicki, Oded Shmueli;
Proceedings of the International Conference on Very Large Data Bases, Zürich 1995
[Mar97]
Dynamic WebPages in Java: Servlet
Benoît Marchal 1997; http://www.javacats.com/US/articles/servlet.html
[MMM97] Querying The World Wide Web
A. Mendelzon, G. Mihaila, T. Milo; International Journal on Digital Libraries, April 1997
Entstanden im Rahmen des Seminars „Weltweite Datenbanken“ der Abteilung Informationssysteme im
Fachbereich Informatik, Universität Oldenburg im Wintersemester 2000/01
24