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 int main() { //keine Parameter char *inputStreamData; cin >> inputStreamData; //einlesen cout