1. Einführung: Warum Datenbanken fürs WWW?
Werbung
Technische Universität München
Institut für Informatik
Hauptseminar im Wintersemester 2000/2001
Architektur und Implementierung von Internetdatenbanken
Lehrstuhl Prof. Bayer, Ph.D.
Ist Website Management ein Datenbankproblem?
Benötigen Datenbanken ein Webinterface?
Ausarbeitung
Willem Wijnakker
2. November 2000
Betreuer: Robert Fenk
1
1. Einführung: Warum Datenbanken fürs WWW?
Dieser Arbeit liegen zwei Kernproblematiken zugrunde, auf denen viele unterschiedliche Thematiken,
Anforderungen und Aspekte aufbauen und aus denen weitere Problematiken resultieren. Diese sind:
Webanbindung von Datenbanken (DBS -> Web)
Website Management mit Datenbanken (Web -> DBS)
Zum einen stellt sich die Frage, wie man existierende Datenbanken an das Web anbindet und zum anderen, wie
man Datenbanken für das Website Management nutzt? Nachfolgend soll ein Überblick über diesen
umfangreichen Themenkomplex gegeben werden, sowie die Unterschiede, trotz vorhandenen Parallelen,
hervorgehoben werden.
Webanbindung von Datenbanken
Datenbanken enthalten beispielsweise Informationen aus den vielfältigsten Abteilungen eines Unternehmens und
stellen diese den unterschiedlichen Arbeitsgruppen (Computergestützter Entwurf, Produktionsplanung,
Kundenbetreuung, usw.) über anwendungsspezifische Schnittstellen bereit. Die Homogenisierung des Zugangs
zu verteilten Daten und den Zugriff auf Legacy-Systeme kann eine leistungsfähige Middleware mit
standardisierten Schnittstellen unterstützen. Die Abbildung von Geschäftsprozessen unter Verwendung eines
ganzheitlichen Unternehmensinformationssystems (Enterprise information system) für Mitarbeiter, Management
und Kunden ist eine Forderung der Zeit und kann zur organisatorischen Selbstreinigung eines Unternehmens
führen. Daher ist die Einführung der Internet-Technologien in das firmeneigene Netz (Intranet) eine große
Chance.
Mehrere Gründe motivieren den Zugriff auf Datenbanken über das WWW:
1.
2.
3.
4.
5.
Der herkömmliche, transaktionsbasierte Zugriff auf Online-Daten in operativen Datenbanksystemen über
eine vereinfachte Oberfläche (DB-Anwendungen werden „internetfähig“).
Der Zugriff auf sekundäre Datenbestände (Kopien oder Data Warehouses, DW) zur Auswertung von Daten.
Die Verarbeitung von Daten unter Aspekten wie Schutz, Sicherheit und finanzieller Transaktionen
(Electronic Commerce, Merchant Server).
Die Verwaltung der Informationen, bei der die Dokumente als Informationsbausteine in einer Datenbank
modelliert und mit deren Funktionalität bearbeitet werden.
Wenn Daten in Dokumente mit Lebenszyklus und Zustand eingehen (Workflow Management Systeme,
WFMS) und als Teil der Geschäftsprozesse aufgefaßt werden.
Dabei steht bei 1), 3) und 4) die Verwendung der Datenbank als Technologiebasis, bei 2) und 5) als
Informationsquelle im Vordergrund. Die Varianten können sich untereinander mischen. So steht die
Entscheidung an, ob für einen Anwendungsfall nach 1) auf „heiße“ Daten zugegriffen werden soll (was auch
wegen Verfahrenssicherheit, Performance und Datenschutz nicht zweckmäßig sein muß), oder ob ähnlich 2)
„kalte“ Daten für den WWW-Zugriff vorgehalten werden.
Website Management mit Datenbanken
Die erste Frage, die sich stellt: Ist Website Management überhaupt ein Datenbankproblem?
In vielen heißen Debatten über die Anwendbarkeit von Datenbanktechnologie auf das Internet und das World
Wide Web ging als eines der Teilgebiete das der Webseitenkonstruktion und des Webseitenmanagements hervor.
Parallel dazu wurden viele Forschungsprojekte gestartet, um dieses Problem zu behandeln (Strudel, Araneus,
YAT und WebOQL). Das Hauptthema dieser Projekte ist das deklarative Management des Inhalts und der
Struktur von Webseiten. Diese Projekte nährten sich aus vorhergehenden wichtigen Arbeiten über Management
von halbstrukturierten Daten und Datenintegration.
Zusätzlich stiegen die Aktivitäten von Datenbankanbietern an, Werkzeuge zu entwickeln, mit denen man Daten
verwalten kann, die in Datenbanken abgelegt sind. Weitere Website Management Tools werden von anderen
Firmen hergestellt (z.B. FrontPage, NetObjects, etc.). Diese Produkte bieten immer mehr Möglichkeiten,
Daten aus verschiedenen externen Quellen aufzunehmen und die Struktur von Webseiten zu managen.
2
Als zentrale Fragestellung gilt, ob Website Management ein Datenbankproblem ist, als Ganzes oder zumindest
teilweise. Bei den Diskussionen sind folgende Meinungen vertreten:
Website Management ist kein Datenbankproblem. Wenn es auch einige Datenmanagement-Elemente an sich
hat, so sind diese jedoch gering. Website Management wird hauptsächlich eine Kombination der
Realisierung der Benutzerschnittstelle und der Entwicklung flexibler Tools zur Erstellung von CGI bin
Skripten bleiben. Oft wird hier mit dem Thema des Netzwerkmanagements verglichen, bei dem
Datenbanktechnologie nicht viel beigetragen hat.
Website Management ist ein gelöstes Datenbankproblem. Ausreichende Website Management Tools sind
bereits verfügbar. Darunter befinden sich Oracle, Informix, DB2, Sybase und andere. Es sind nur noch
geringfügige Änderungen und Erweiterungen der Benutzerschnittstelle nötig, um aktuelle Datenbankmanagement-Systeme an das Problem des Website Management anzupassen.
Website Management ist größtenteils ein Datenbankproblem. Entwickelt man ein Website ManagementSystem basierend auf Datenbankkonzepten, muß man viele Annahmen überdenken, die man bei
traditionellen Datenbanksystemen macht. So braucht man beispielsweise ein neues Datenmodell, welches
auch die Modellierung der Webseitenstruktur unterstützt, man benötigt neue Anfragesprachen, Designprinzipien für Webseiten, neue Datenverwaltungstechniken und neue Methoden, solche Systeme in eine
Programmierumgebung einzubetten.
2. Einsatzmöglichkeiten von DBS
Verwaltung von Hypertext-Dokumenten mit Hilfe eines DBS
Wird den Nutzern eine große Informationsmenge, in der Regel durch sehr viele HTML-Seiten, zur Verfügung
gestellt, so bietet sich die Verwaltung der Hypertext-Dokumente mit Hilfe eines DBS an. Viele DBS-Hersteller
bieten entsprechende Zusatzmodule zur Dokumentenverwaltung, d.h. der Speicherung von HTML-Texten
innerhalb einer DB, an. Je nach Produkt sind dabei unter anderem Versionierung, Datenkompression,
vereinfachte Zugriffsverwaltung sowie (verbesserte) Suchmöglichkeiten zu nennen. Um die gespeicherten
Dokumente im Browser anzeigen zu können, bedarf es einer geeigneten Schnittstelle zwischen DBS und WWWServer.
Beispiele für Web-Anbindungen von Datenbanken
Die zweite, weitaus häufiger genutzte Einsatzmöglichkeit von DBS im WWW ist die der Verwaltung
„traditioneller“ Daten. Diese werden über entsprechende Schnittstellen, die nachfolgend noch erörtert werden, zu
einem Browser übertragen oder aus diesem heraus aktualisiert.
Um den Bedarf an geeigneten Web-Anbindungen von Datenbanken zu motivieren, dienen einige der
kommenden Beispiele:
Bereitstellung aktueller (Börsen-)Daten:
In Verbindung mit dem Trend zu Direktbanken mit „Online-Banking“ bwz. „Online-Brokerage“
(Bank24/Deutsche Bank, comdirect, Dresdner Bank, Advance Bank, ConSors, etc.) und dem Wegfall von
persönlicher Beratung entsteht bei den Kunden ein Informationsbedarf, unter anderem nach aktuellen
Börseninformationen. Um diesen zu befriedigen, werden nun dem Kunden aktuelle Börsenkurse im WWW
zur Verfügung gestellt. Als zusätzlicher Service werden zudem grafisch aufbereitete Kursanalysen (Charts)
und kundenspezifische Portfolio-Analysen angeboten. Zudem existieren mittlerweile von verschiedenen
kommerziellen Anbietern entsprechende, weitergehende Angebote.
Nachrichten(-Ticker)
Von Zeitungen werden im WWW Ausschnitte der aktuellen Ausgabe sowie ein elektronisches Archiv mit
Suchmöglichkeiten angeboten. Da die Zeitungen über einen elektronischen Nachrichtenticker durch die
Presseagenturen beliefert werden, ist es ohne personellen Aufwand möglich, dem Benutzer einen Teil der
3
aktuellen Meldungen auf WWW-Seiten zur Verfügung zu stellen. Hierzu ist es notwendig, eingehende
Meldungen zu speichern sowie eine Überblicksseite automatisch zu aktualisieren.
Verfolgung von Vorgängen(Auftragsbearbeitung, Paketdienst):
Setzt ein Unternehmen intern eine elektronische Auftragsbearbeitung oder ein ähnliches, auf die jeweilige
Dienstleistung (z.B. Paketdienst) abgestimmtes System ein, so kann über das WWW als Kundenservice ein
Zugriff auf den aktuellen Bearbeitungszustand angeboten werden (z.B. UPS, FedEx). Neben dem PrestigeGewinn durch entsprechende Serviceleistungen können aber auch ökonomische Vorteile in Bezug auf
Einsparung von Personalkosten (telefonische Auskunft) erwartet werden.
Bestell-Center:
Viele Unternehmen verwenden das WWW als Plattform für die Firmenpräsentation, verbunden mit dem
Angebot einer Produktauswahl und der Möglichkeit zur Informationsanforderung. Hierbei sind die jeweils
vom Anwender anzugebenden Daten (Adresse, Kundennummer, etc.) nach einer eventuellen Prüfung in die
interne Kunden- und Auftragsdatenbank aufzunehmen.
Neben diesen Anwendungen haben sich zum einen durch den technischen Fortschritt, zum anderen durch die
zugenommene Akzeptanz auf Seiten der Benutzer sowie innerhalb der Unternehmen weitere WWW-basierte
Einsatzgebiete etabliert:
Intranet (EIS, WFMS):
Durch die Einführung von Intranets können auf Basis der Internet- und WWW-Technik
unternehmensinterne Anwendungen (plattformunabhängig) realisiert werden. Hierzu gehört sowohl die
eines Enterprise-Information-Systems (EIS), als auch Gruppenarbeitssysteme wie zum Beispiel WorkflowManagement-Systeme (WFMS). Mit Hilfe eines EIS kann nun allen Mitarbeitern, eventuell mit
Abstufungen der Zugriffsrechte, ein Großteil der bis dahin papierbasierten Informationen wie
Nachschlagewerke (Telefonbücher, Anschriftenlisten, usw.) und interne Mitteilungen mit
Suchmöglichkeiten zur Verfügung gestellt werden. Durch WFMS können (betriebsinterne) Vorgänge
gesteuert und koordiniert werden, wobei eine optimale und fehlertolerante Ausführung der Abläufe
angestrebt wird. Durch die Plattformunabhängigkeit von HTML und Java ist die WWW-Technik
prädestiniert, um als Basis für die Realisierung solcher Systeme in einem meist heterogenen und verteilten
Umfeld zu dienen.
E-Banking und E-Commerce:
Wird das Vertrauen bei den Geschäftspartnern, d.h. Kunden und Unternehmen, in die Sicherheit der
eingesetzten Technik weiter gestärkt, so wir der elektronische Handel sowie die Abwicklung von
Bankgeschäften weiterhin zunehmen. Neben der Einführung von elektronischem Geld ist besonders die
Unterstützung von Kreditkarten erforderlich. Die großen Kartenunternehmen haben sich die Freiheit
genommen, mit Industriepartnern an einem entsprechenden Abrechnungsstandard zu arbeiten. Zuvor wurde
ein Großteil der mit der Hilfe des WWW getätigten Bestellungen intern ausgedruckt und wie eine
schriftliche Bestellung behandelt. Setzt man jedoch ein Workflow-Management-System mit WWWAnbindung ein, so kann die Bestellung durch den Kunden der erste Schritt in einem durch ein WFMS
gesteuerten Bearbeitungsablauf sein.
Die dargestellten Beispiele zeigen jedoch nur einen Ausschnitt der Einsatzmöglichkeiten von DBS im
Zusammenspiel mit dem WWW. Das jeweils zur Verfügung stehende Potential wird oft nicht ausgeschöpft,
noch immer wird das WWW teilweise überhaupt nicht genutzt. So wird auch in Zukunft die Zahl der WWWgestützten Anwendungen zunehmen, damit auch die Zahl der angebundenen DBS.
3. Aufgaben des Website Managements mit Datenbanken:
Webseitenkonstruktion und Umstrukturierung
Ein Aspekt, bei dem Datenbankkonzepte und -technik angewendet werden kann, ist der des Aufbaus, der
Umstrukturierung und der Verwaltung von Internetseiten. Im Gegensatz zu den anderen zwei Klassen, bei denen
bereits Seiten existieren, betrachtet man hier den Erzeugungsprozeß von Webseiten. Diese können entweder
ausgehend von Rohdaten (abgelegt in Datenbanken oder strukturierten Files) oder durch Überarbeitung
4
existierender Seiten erstellt werden. Um diese Aufgaben auszuführen benötigt man Techniken zur Modellierung
der Struktur der Webseite und Sprachen zur Umgestaltung der Daten in die gewünschten Struktur.
Aufgrund der Tatsache, daß Webseiten einen unentbehrlichen Zugang zu komplexen Informationsstrukturen
bieten, ist es einleuchtend, die Technik von Datenbanksystemen für die Konstruktion und Instandhaltung von
Internetseiten anzuwenden. Man kann dabei zwei allgemeine Aufgabenklassen zur Webseitenkonstruktion
unterscheiden: eine, in der die Seiten aus einem Satz zugrundeliegender Datenquellen erzeugt werden, und eine
andere, bei der sie durch Umstrukturierung bereits existierender Webseiten erschaffen werden.
Es zeigt sich, daß für beide Klassen dieselben Techniken benötigt werden. Des weiteren kann man festhalten,
daß die Aufgabe, eine Schnittstelle vom Web zu Daten eines einzelnen Datenbanksystems herzustellen, eine
einfache Instanz der Problematik der Webseitenkonstruktion ist.
Um die Schwierigkeit bei der Konstruktion der Webseiten und dem möglichen Importieren von
Datenbanktechnik zu verstehen, muß man sich die Aufgaben vor Augen halten, die dazu realisiert werden
müssen: Die Daten selektieren und abrufen, die auf der Seite angezeigt werden sollen, die Struktur der Webseite
designen und das Konzipieren der grafischen Präsentation der Seiten. In den existierenden Website
Management-Tools sind diese Aufgaben zum Großteil ineinander verschachtelt. Ohne derartige Programme
müssen HTML Dateien oder Programme zur deren Generierung von Hand geschrieben werden und man muß
sich dabei gleichzeitig auf den Seiteninhalt, die Beziehung zu anderen Seiten und schließlich das Design
konzentrieren.
Als Folge lassen sich verschiedene wichtige Aufgaben, wie das automatische Aktualisieren, die Umgestaltung
einer Seite oder der Aufbau der referentiellen Integrität innerhalb der Seitenstruktur nur mühselig realisieren.
Es wurden verschiedene Systeme entwickelt mit dem Ziel, Datenbanktechnik mit der Problematik der
Webseitenkreation zu verbinden. Die Hauptaufgabe dieser Systeme ist, daß sie eine deklarative Repräsentation
der Struktur der Webseite geben. Diese ist definiert als eine Sicht auf existierende Daten. Die Sprachen, die
benutzt werden, um diese Sicht zu erstellen, resultieren in Graphen von Webseiten mit Hyperlinks, anstelle
simpler Tabellen. Die Systeme unterscheiden sich im verwendeten Datenmodell, der Anfragesprache und darin,
ob sie eine intermediäre, logische Repräsentation der Webseite besitzen, anstatt nur einer Repräsentation des
fertigen HTMLs.
Eine Webseite zu erzeugen, indem man eine deklarative Repräsentation der Struktur der Seite nutzt, hat mehrere
signifikante Vorteile. Da die Struktur einer Webseite und deren Inhalt durch eine Anfrage festgelegt ist und nicht
prozedural von einem Programm, ist es einfach, mehrere Versionen einer Seite zu kreieren. So ist es
beispielsweise möglich, auf einfache Art und Weise interne und externe Ansichten einer Unternehmensseite zu
realisieren oder auch Seiten, die auf individuelle Nutzer zurechtgeschnitten sind. Dazu müssen momentan
mehrere Programme geschrieben werden oder manuell verschiedene HTML-Dateien erstellt werden.
Verschiedene Versionen einer Seite können entweder durch das erstellen unterschiedlicher
Seitendefinitionsanfragen oder aber durch Verändern der graphischen Repräsentation unabhängig von der
zugrundeliegenden Struktur. Des weiteren fördert die deklarative Repräsentation der Struktur der Webseite auch
die einfache Entwicklung der Struktur einer Webseite. So zum Beispiel für die Reorganisation von Seiten, die
auf häufig genutzten Spuren basieren oder um den Inhalt der Seiten zu erweitern, braucht man nur einfach die
Seitenanfrage neudefinieren, anstatt Programme oder HTML-Dateien neu zuschreiben. Ein weiterer Vorteil einer
deklarativen Spezifikation von Webseiten ist die Möglichkeit, referentielle Beziehungen aufzusetzen und die
Seite automatisch zu aktualisieren, sobald sich Änderungen bei den zugrundeliegenden Daten ergeben.
Außerdem bietet eine solche deklarative Spezifikation eine Plattform für die Entwicklung von
Optimierungsalgorithmen zum Laufzeit-Management von datenlastigen Webseiten.
Auf unterster Ebene greift das System auf einen Satz von Datenquellen zu, die auf der Seite bereitgestellt werden
sollen. Die Daten können in Datenbanken, in strukturierten Dateien oder in existierenden Webseiten abgelegt
sein. Sie werden im System in einem Datenmodell repräsentiert und das System liefert den Datenquellen eine
einheitliche Schnittstelle. Der Hauptschritt bei der Webseitenkonstruktion ist das Erstellen eines Ausdrucks, der
die Struktur der Webseite deklarativ repräsentiert. Dieser Ausdruck wird in einer spezifischen Anfragesprache
verfaßt, die das System zur Verfügung stellt. Das Ergebnis der Anbindung dieser Anfrage an die
zugrundeliegenden Daten stellt die logische Repräsentation der Webseite innerhalb des Datenmodells des
Systems (z.B.: einen gerichteten Graphen) dar. Um letztendlich eine navigierbare Seite zu erhalten, beinhaltet
das System eine Methode (z.B.: HTML-Templates), die logische Struktur in einen Satz von HTML Dateien zu
übersetzen.
5
Navigierbare Webseite
Spezifikation
zur
graphischen
Präsentation
HTML Generator
Logische Repräsentation der Webseite
Deklarative Spezifikation
der Struktur der Webseite
Einheitliche Sicht der zugrundeliegenden Daten
Mediator
Wrapper
DB
Strukturierte
Files
HTML
Seiten
Abb.1: Architektur für Website Management Systeme
Modellierung und Anfragen des Webs
Betrachtet man das Web als gerichteten Graphen, dessen Knoten Webseiten sind und dessen Kanten die Links
zwischen den Seiten. Als erste Aufgabe kann man sich die Formulierung von Anfragen überlegen, um bestimmte
Webseiten zu erhalten. Die Anfragen können auf den Inhalt der gewünschten Seiten basieren und auf die
Struktur der Links, welche die Seiten verbindet. Die einfachste Instanz dieser Aufgabe, die von Suchmaschinen
im Internet erfüllt wird, ist Seiten aufzuspüren anhand der Wörter, die sie beinhalten. Eine simple
Verallgemeinerung einer solchen Anfrage besteht darin, komplexere Prädikate an die Inhalte einer Seite
hinzuzufügen ( z.B.: finde Seiten mit dem Wort „Clinton“ neben einem Link oder einem Bild).
Als Anfragebeispiel, das die Struktur der Seiten mit einbezieht, dient beispielsweise die Anfrage nach allen
Bildern, die vom Root-Verzeichnis der CNN Webseite innerhalb von 5 Links erreichbar sind.
Diese Art von Anfragen sind besonders hilfreich, wenn es darum geht, Verletzungen von Integritätsbeziehungen
einer Webseite oder einer Gruppe von Webseiten zu finden.
Von Bedeutung ist dabei sowohl die interne Struktur der Webseiten als auch die externe Struktur der Links, die
diese miteinander verbinden.
Man versucht, die Grenzen der Suchmaschinen zu überwinden, indem man die Linkstruktur in Anfragen
ausnutzt. Dafür liefert der Connectivity Server schnellen Zugang zu strukturellen Informationen. Google, eine
Suchmaschinen, macht intensiven Gebrauch der Webstruktur, um Suche und Indexierung zu verbessern.
Die Arten der Anfragesprachen gliedern sich in verschiedene Gruppen:
Hypertext/ Dokument Anfragesprachen:
Bereits vor der großen Webära wurden schon Modelle und Sprachen konzipiert, um strukturierte
Dokumente und Hypertext anzufragen. So wurden zum Beispiel Dokumente an objektorientierte
Datenbankinstanzen gekoppelt und somit semantische Aktionen an eine Grammatik angefügt. Dann kann
die Datenbankrepräsentation mit der Anfragesprache des Datenbanksystems angefragt werden. Dabei gilt als
neuer Aspekt die Möglichkeit, die Struktur mit Hilfe von Pfadvariablen abzufragen.
Graphenbasierte Anfragesprachen:
Infolge der Nutzung von Graphen zur Medellierung von Datenbanken entstanden die graphengestützen
Sprachen G, G+ und GraphLog. Diese Basieren auf gerichtete Graphen und ermöglichen reguläre
Pfadausdrücke und Graphenkonstruktion in Anfragen. Graphlog wurde in Hypertextanfragen integriert und
so wurde eine graphenbasierte Anfragesprache für objektorientierte Datenbanken geschaffen.
6
Anfragesprachen für halbstrukturierte Daten:
Diese Art von Anfragesprachen wie Lorel, UnQL und StruQL nutzen ebenfalls gerichtete Graphen als ein
flexibles Datenmodell. Im Kontrast zu den graphenbasierten Anfragesprachen besitzen sie die Fähigkeit, das
Schema der Daten anfragen zu können und Irregularitäten der Daten aufzuspüren, wie beispielsweise
fehlende oder wiederholte Felder und heterogene Einträge.
Jedoch sind diese Sprachen nicht speziell für das Internet entwickelt worden und unterscheiden zum Beispiel
nicht zwischen Kanten von Graphen, welche die Verbindung zwischen einem Dokument und eines seiner Teile
repräsentieren und Kanten die einen Hyperlink von einem Internetdokument zu einem anderen markieren.
Eine erste Generation von Anfragesprachen zielte darauf ab, die inhaltsbasierten Anfragen der Suchmaschinen
mit den sturkturbasierten Anfragen eines Datenbanksystems zu verbinden. Diese Sprachen, die W3QL, WebSQL
und WebLog umfassen, verknüpfen Restriktionen auf Textmuster in Dokumenten mit Graphenmustern, die eine
Linkstruktur beschreiben.
Die zweite Generation von Anfragesprachen, die auch Datenmanipulationssprachen genannt werden,
unterscheiden sich von der ersten Generation in zweierlei Hinsichten:
Erstens bieten sie Zugang zur Struktur der Internetobjekte, die sie bearbeiten, und modellieren sowohl die interne
Struktur von Internetdokumenten, als auch die externen Links die sie verbinden. Sie erlauben Referenzen, um
Hyperlinks zu gestalten, und einige sogar strukturierte Daten für eine einfachere Datenrepräsentation.
Zweitens bieten diese Sprachen die Möglichkeit, aus einem Anfrageergebnis neue komplexe Strukturen zu
erschaffen. Zu den Sprachen, welche die meist halbstrukturierten Daten des Internets unterstützen, zählen
WebOQL, StruQL und FLORID.
System
WebSQL
W3QS
WebLog
Lorel
WebOQL
UnQL
STRUDEL
ARANEUS
FLORID
Datenmodell
Relational
gerichtete Mehrfachgraphen
Relational
gerichtete Graphen
Hypertrees
gerichtete Graphen
gerichtete Graphen
Seitenschemata
F-logic (objektorientiert)
Sprache
SQL
SQL
Datalog
OQL
OQL
strukturelle Rekursion
Datalog
SQL
Datalog
Pfadausdrücke
ja
ja
nein
ja
ja
ja
ja
ja
ja
Graphenerzeugung
nein
nein
nein
nein
ja
ja
ja
ja
nein
Abb.2: Vergleich verschiedener Anfragesysteme
4. Webanbindung von Datenbanken
Bestimmte Webseiten können unter einer feineren Ebene betrachtet werden als andere, als Behälter von
strukturierten Daten (Datensätze oder Objekte). Zum Beispiel kann die Internet Movie Database als front end
interface zu einer Filmdatenbank gesehen werden. Bedenkt man das Wachstum solcher Seiten, stehen zwei
Aufgaben zur Überlegung.
1.
2.
Die erste Aufgabe ist es, eine strukturierte Repräsentation der Daten (z.B. einem einzelnen Datensatz)
aus den HTML-Seiten, die sie beinhalten, zu extrahieren. Diese Aufgabe wird durch WrapperProgramme erfüllt, deren Erstellung und Wartung einige Herausforderungen mit sich bringt. Dadurch
wird einem vorgetäuscht, die Webseite würde Datensätze liefern.
Die Kombination von zugrundeliegender Webseite und Wrapper bezeichnet man als Web-Source. Sieht
man diese Seiten als autonome und heterogene Datenbanken, läßt sich die zweite Aufgabe angeben, die
aus dem Stellen von Anfragen zur Datenintegration besteht. Diese wird durch Mediator- oder
Datenintegrations-systeme bewerkstelligt.
Die Aufgabe eines Internetinformations-Integrationssystems ist es, Anfragen zu beantworten, die
möglicherweise die Beschaffung und Kombination von Daten mehrerer Quellen erfordern. Beispielsweise
7
Anfragen wie: zeige mir einen Film, Spielzeit und Rückblick auf Filme mit Frank Sinatra, der heute Abend in
Paris gezeigt wird.
Es wurden verschiedene Systeme erstellt mit dem Ziel, Anfragen zu beantworten, die eine Vielzahl von
Internetquellen benutzen. Viele der Probleme, auf die man dabei gestoßen ist, sind vergleichbar mit denen bei
der Entwicklung heterogener Datenbanksysteme. Zusätzlich müssen Internet-Datenintegrationssysteme mit
großer und zunehmender Zahl an Internetquellen, geringen Meta-Informationen über die Charakteristiken der
Quelle und erhöhtem Grad an Autonomie der Quelle umgehen können.
Eine wichtige Unterscheidung bei der Erstellung von Datenintegrationssystemen besteht darin, ob man einen
Warenkorb oder einen virtuellen Ansatz benutzt. Bei der ersten Variante werden Daten von mehreren
Internetquellen in einen Warenkorb geladen. Dazu ist es nötig, daß der Warenkorb aktualisiert wird, wenn sich
die Daten ändern. Der Vorteil dabei ist aber, daß angemessene Performance zum Anfragezeitpunkt garantiert
wird. Beim virtuellen Ansatz verbleiben die Daten in den Quellseiten und Anfragen an das Datenintegrationssystem werden zur Laufzeit umgewandelt in Anfragen an die Quellen. Dabei werden die Daten nicht repliziert
und ist garantiert aktuell zum Abfragezeitpunkt.
Jedoch werden aufgrund der Selbständigkeit der Quellen effizientere Anfrageoptimierungen und Ausführungsmethoden benötigt, um entsprechende Performance zu gewährleisten.
Der virtuelle Ansatz eignet sich mehr für den Bau von Systemen mit einer großen Anzahl Quellen, sich ständig
verändernden Daten und geringer Kontrollierungsmöglichkeit der Internetquellen.
Evolutionsstufen der Datenbankanbindung an das WWW
Seit der Einführung des Common Gateway Interface (CGI) ist es durch das Server-seitige Ausführen von
Programmen möglich, in Datenbanken gespeicherte Informationen in HTML-Seiten einzubinden.
Bei der dabei verwendeten Technik kann man trotz der relativ kurzen Entwicklungsgeschichte schon deutliche
Evolutionsstufen erkennen.
Ausschlaggebend sind dabei Kriterien wie mögliche Transaktionsdauer sowie den Erstellungs- und
Wartungsaufwand der zugehörigen HTML-Seiten und Programme.
Die 1. Generation
Als Datenbankanbindung der ersten Generation bezeichnen wir die vom Informationsanbieter für die einzelnen
DB-Anfragen selbst erstellten Skripte oder Programme (meist Perl, C oder Shell-Skripte).
Sie werden durch den CGI-Mechanismus des WWW-Servers aufgerufen und mit entsprechenden Parametern
versorgt. Im Skript bzw. dem Programm sind die auszuführende DB-Anfrage und die zu erstellende HTMLErgebnisseite, in die das Anfrageergebnis eingebunden werden soll, fest kodiert. Die vom DBS gelieferte
Antwort, deren Struktur schon bei der Skript- bzw. Programmerstellung weitestgehend festgelegt werden muß,
wird gelesen und dann in HTML umgewandelt. Da die als Antwort zu übertragende HTML-Seite und auch die
DB-Anfrage fest kodiert sind, kann ein so erstelltes CGI-Programm nur einen bestimmten Auftrag ausführen,
d.h. für jede Aufgabe muß ein neues Programm erstellt werden.
Folgene Abbildung zeigt ein einfaches, in Perl geschriebenes CGI-Programm, das aus einer mSQL-DB mit
Bookmarks alle gespeicherten Namen von WWW-Seiten zusammen mit den zugehörigen URLs liest und daraus
eine Tabelle innerhalb eines HTML-Dokuments erzeugt.
#!/usr/bin/perl
# Msql-Package laden:
use Msql;
# Seitenkopf ausgeben:
print“Content-type: text/html\n\n“;
# [...]
# Verbindung mit dem DB-Server herstellen:
$testdb = Msql ->connect;
# Datenbank auswaehlen:
$testdb->selectdb(“bookmarks“);
8
# Datenbankanfrage stellen:
$sth = $testdb->query(“select name, url from bookmarks where url <>´´ order by name“);
# Resultat ausgeben:
print“<TABLE BORDER=1>\n“;
print“<TR>\n<TH>Name<TH>URL</TR>“;
$rows = $sth->numrows;
while ($rows>0)
{
@sqlrow = $sth->fetchrow;
print“<TR><TD>“,@sqlrow[0],“</TD><TD><A HREF=\““,
@sqlrow[1],“\“>“,@sqlrow[1],“</A></TD></TR>\n“;
$rows--;
}
print“</TABLE>\n“;
# Seitenende ausgeben:
# [...]
Abb.3: Web-Anbindung der 1. Generation (mSQL)
Die 2. Generation
Ausgehend von den Problemen mit den DB-Web-Anbindungen der ersten Generation und beschleunigt durch die
immense Nachfrage wurden von Datenbankherstellern und Drittfirmen Werkzeuge zum direkten DB-Zugriff mit
Hilfe des CGI entwickelt.
Folgende Techniken haben sich dabei etabliert:
CGI/Server-Erweiterungen:
Die häufigste Gemeinsamkeit aller Web-Anbindungen der zweiten Generation ist jeweils ein allgemeines
CGI-Programm, das bei jedem DB-Zugriff anstelle der bisherigen Individuallösungen aufgerufen wird.
Um die durch den Aufruf eines CGI-Programms entstehenden Geschwindigkeitsverluste zu vermeiden, wird
in einigen Ansätzen eine Erweiterung des WWW-Servers mit Hilfe der entsprechenden Server-API
(Application Programming Interface) vorgenommen. Hierdurch findet die Programmabarbeitung im
Adreßraum des WWW-Servers statt, ein Aufruf eines CGI-Programms ist nicht mehr erforderlich. Ein
zusätzlicher Vorteil besteht darin, daß eine ständige Verbindung zum DB-Server gehalten werden kann.
Etwaige Wartezeiten fallen nicht mehr an.
HTML/Makro-Programm:
Neben den bisher als Programmparametern in der URL übergebenen Anfrageinformationen muß in der
Regel nun auch eine Datei spezifiziert werden, deren Inhalt je nach Produkt variiert. Eine häufige Lösung ist
der Gebrauch von um Datenbankoperationen erweiterten HTML-Seiten.
Hierbei werden Anfragen, benötigte Variablen, etc. durch spezielle Befehle (<!msql>, <syb>, <?misql>) in
das normale Dokument eingebettet.
Ein wesentlicher Vorteil dieser Technik ist die Kontrollmöglichkeit der erstellten Seiten mit Hilfe eines
WWW-Browsers. Da die in den Seiten enthaltenen DB-Operationen, d.h. die dem Browser unbekannten
Anweisungen ignoriert werden, wird die Seite in der späteren Form dargestellt. Das in Abb.2 gezeigte
HTML-Dokument, in dem W3-mSQL verwendet wird, hat dieselbe Funktionalität wie das in Abb.1
dargestellte Perl-Skript, ist jedoch viel einfacher zu erstellen.
<HTML>
<head><title>The Bookmark Database</title></head>
<BODY>
<H1 align=center>The Bookmark Database</H1>
<!-- DB-Verbindung aufbauen -->
<! msql connect >
<HR NOSHADE><P>
9
<!-- Datenbank auswaehlen -->
<! msql database bookmarks>
<!-- Datenbankanfrage stellen -->
<! msql query “select url, name from bookmarks where url <>´´ order by name“ q1>
<!-- Resultat formatiert ausgeben -->
<!TABLE BORDER=2><TH> URL <TH> Name
<! msql print_rows q1 “<TR><TD>@q1.1</TD>
<TD><A [email protected]>@q1.0</TD></TR>“>
<!-- Resourcen freigeben und Verbindung schließen -->
<! msql free q1>
<! msql close>
</BODY></HTML>
Abb.4: Web-Anbindung der 2.Generation (W3-mSQL)
Eine zweite Technik besteht in der Auswertung einer Makrodatei, in der getrennt voneinander DBOperationen und entsprechende HTML-Seiten abgelegt werden.
Die Inhalte der unterschiedlichen Sektionen können zwar unabhängig voneinander mit entsprechenden
Werkzeugen entwickelt werden, allerdings ist nach dem Zusammenfügen eine spätere Nachbearbeitung nur
schwer möglich.
Schließlich besteht eine dritte Technik in der Erweiterung der DB-Programmierschnittstelle um Webspezifische Funktionalität, d.h. der Möglichkeit zur einfachen Generierung von HTML-Ausgaben.
Durch die Verwendung der Programmierschnittstelle steht, ähnlich wie bei den Ansätzen der ersten
Generation, der volle Funktionsumfang des DBMS zur Verfügung, man ist bei der Programmerstellung auf
Kosten der Einfachheit sehr flexibel.
Ablage der Seiten:
Während die meisten Produkte mit im normalen Dateisystem abgelegten Informationen (abgesehen von den
DB-Daten) arbeiten, speichern andere zusätzlich zu den „normalen“ Daten auch die HTML-Seiten in der
DB. Der erste Ansatz hat den Vorteil der einfachen Wartung mit Hilfe der üblichen Werkzeuge, der zweite
bietet die Vorteile eines DBS, unter anderem erweiterte Suchmöglichkeiten und die Verwaltung von
Zugriffsrechten.
Transaktionsdauer:
Von den angebotenen Produkten bieten nur wenige die Möglichkeit, mehrere DB-Operationen zu einer
Transaktion zusammenzufassen (Multi-Statement Transaction, MST), um so z.B. durch bedingte
Anweisungen eine größere Verarbeitungsflexibilität zu erlangen. Ein Großteil der Produkte unterstützt
lediglich Single-Statement Transaction (SST).
Die 3. Generation
Beruhen die beiden ersten Generationen von DB-Web-Anbindungen noch auf dem CGI, so beginnt mit der
dritten Generation die Ära von Java. Bedingt durch die Einschränkung der Transaktionsdauer und den Verzicht
auf Funktionalität in den beiden ersten Evolutionsstufen wurde nach einer adäquaten Lösung gesucht, um sich
von diesen Behinderungen zu lösen. Fündig wurde man 1995 mit der (Netz-) Programmiersprache Java. Sie
bietet die Möglichkeit, in HTML-Seiten eingebundene Java-Programme auf dem WWW-Server bereitzustellen,
diese zusammen mit der entsprechenden Seite beim Einladen durch den WWW-Browser in diesen zu übertragen
und dort auszuführen. Realisiert man nun DB-Schnittstellen in Java, so stehen alle Möglichkeiten von
Client/Server-Systemen zur Verfügung. Dazu öffnet die Java-Anwendung nach dem Programmstart eine
Verbindung zum DB-Server, mit dem es über die gesamte Verarbeitungsdauer hinweg in Kontakt steht.
Während bei den Produkten der zweiten Generation in der Regel mit formulierten SQL/OQL-Anfragen
gearbeitet wird, bietet sich durch die direkte DB-Verbindung ein breites Spektrum von potentiellen Lösungen:
10
Java Database Connectivity (JDBC):
JDBC ist an das weit verbreitete ODBC (Open Database Connecitivity) angelehnt und bietet wie das
Vorbild die Möglichkeit zur Ausführung von SQL-Befehlen, da es ebenso auf dem X/Open Call Level
Interface (CLI) basiert. Neben der Bereitstellung von reinen Java-Treibern besteht eine Alternative in der
Nutzung eines JDBC-Aufsatzes auf ODBC (JDBC-ODBC-Bridge), um die so bestehende Infrastruktur
ausnutzen zu können.
Aufrufschnittstelle (Call Level Interface, CLI):
Ein anderer Ansatz besteht darin, neben C, C++ oder Smalltalk auch für Java eine DBS-spezifische
Funktionsschnittstelle bereitzustellen. Diese Schnittstelle zum Absenden von SQL-Anfragen wird von den
meisten DBMS-Herstellern unterstützt. Durch das starke Wachstum von Java-Anwendungen beeinflußt,
wächst die Zahl der auf dem Markt verfügbaren Java-DB-Schnittstellen, darunter sind unter anderem
MsqlJava für mSQL, OCI/Java für Oracle, Confiserie für POET und ObjectStore PSE für Java, eine JavaBibliothek für persistente Objekte ähnlich der ObjectStore-Technik für C++ und Smalltalk.
public class bookmarks extends java.applet.Applet {
public static void main(String[ ] args) {
bookmarks d = new bookmarks( );}
public bookmarks( ) {
Msql msql;
try {
msql = new Msql( );
// Verbindung aufbauen und DB auswaehlen
msql.Connect(“agdvs2.informatik.uni-kl.de“, false);
msql.SelectDB(“bookmarks“);
//Anfrage stellen
MsqlResult result = msql.Query(“select name, url
from bookmarks where url <>´´ order by name“);
String row[ ];
while((row = result.FetchRow( )) != null) {
for(int i=0; i<row.length; i++)
// Ergebnis ausgeben
}
msql.Close( );
}
// ...
Abb.5: Web-Anbindung der 3. Generation (MsqlJava)
CORBA:
Das von OMG spezifizierte CORBA soll die Ortstransparenz von Objekten und die Ausführung von
Methoden auf ihnen unterstützen, um verteilte Systeme zu ermöglichen. Java bietet dagegen als eine ideale
Ergänzung Plattformunabhängigkeit von erstellten Programmen. Da in CORBA bereits Schnittstellen zu
verschiedenen DBS bestehen, kann nun durch die Realisierung eines Java-CORBA-Clients ein DB-Zugriff
vom WWW-Browser aus geschaffen werden. SUN unterstützt dies durch die Aufnahme einer
entsprechenden Spezifikation in Java sowie eigene Produkte.
ActiveX:
Das von Microsoft als Gegenpol zu CORBA geschaffene Gespann aus COM (Component Object Model)
bzw. DCOM (Distributed COM) und ActiveX gewann durch die Macht des Marktes bei Web-basierten
Datenbankschnittstellen an Bedeutung. Mit Hilfe von OLE-( Object Linking and Embedding) bzw.
„ActiveX-Controls“ ist es möglich, Applikationen mit entsprechender Unterstützung von (D)COM als
Objekte in andere einzubetten und „fernzusteuern“, ohne daß beim Entwurf eines Programmes
Schnittstelleninformationen über das andere vorhanden sein müssen (Binärkompatibilität). Neben
Textverarbeitungs- und Tabellenkalkulationsobjekten können nun auch Datenbank-„Frontends“ in ActiveXfähige WWW-Browser eingebunden und so eine Datenbankanbindung geschaffen werden. Hierzu steht auch
das „ActiveX Object Interface“ (auch „OLE DB“) zur Verfügung, das auf der Basis von COM für eine DBAnbindung sorgt.
11
Java:
Transaktionsdauer: Durch die Möglichkeit, DB-Verbindungen über längere Zeit zu etablieren, können nun
auch Anwendungen mit größerer Verarbeitungsdauer realisiert werden.
Komplexe Programme: Der Browser kann im Gegensatz zu den CGI-Lösungen, wo er nur zur Dateneingabe
diente, nun als Ausgabeinstrument einer komplexen Anwendung genutzt werden. Anfrageergebnisse können
mit Hilfe der grafischen Möglichkeiten von Java ohne das Anfallen hoher Bildübertragungskosten
visualisiert, Bedingungen schon direkt bei der Eingabe und nicht erst bei der Anfrageausübung überprüft
und komplexe Berechnungen, wie auch „normalen“ Anwendungen gewöhnt, ausgeführt werden.
Entwickelte Programme sind plattformunabhängig.
Direkte Verbindungen: Da die im WWW-Browser laufende Anwendung direkt mit dem DB-Server
kommuniziert, können die üblichen Mechanismen (2PC) zur Absicherung einer vom Anwender
kontollierbaren Ablaufsteuerung eingesetzt werden; die diesbezügliche Unsicherheit wie beim CGI entfällt.
Daher werden Java-Lösungen auch für „Internet-Banking“ eingesetzt.
Aufhebung des Flaschenhalsproblems: Alle DB-Aufrufe gehen ohne Umwege direkt an den DB-Server, die
Zwischenstufen WWW-Server als potentieller Flaschenhals entlastet, zum andern können die
Ausführungszeiten drastisch reduziert werden.
Längere Ladezeiten: Ein wesentlicher Nachteil dieser Generation ist die zu Beginn jeder Verarbeitung
erforderliche Übertragung der Anwendung einschließlich der DB-Schnittstelle in Form von Java-Klassen
vom WWW-Server zum Browser. Für Intranet-Anwendungen und entsprechende Übertragungsbandbreiten
fällt dies nicht ins Gewicht, aber bei Nutzung des Internets ergeben sich hier, besonders bei komplexen
Applikationen, erhebliche Ladezeiten.
Verlust von HTML: Da alle Daten mit Hilfe einer Java-Anwendung verarbeitet werden, steht HTML nur
noch zur Einbettung der Applikation, nicht aber zur Formulargestaltung und Ergebnisdarstellung zur
Verfügung. Formulare, Ergebnistabellen und Grafiken müssen nun in Java programmiert werden, was einen
deutlich höheren Aufwand und eine Abkehr von standardisierten Schnittstellen (HTML-Formulare)
bedeutet.
Sicherheitsproblematik: Das auf der Client-Seite im Browser auszuführende Programm wird von einem
WWW-Server heruntergeladen. Arbeitet man nicht in einem abgeschirmten Intranet, besteht bei der
Übertragung ohne Verschlüsselung Gefahr der Manipulation.
Einschränkung von Verbindungsmöglichkeiten: Je nach Systemumgebung und Einstellungen können im
Browser ausgeführte Java-Anwendungen Netzwerkverbindungen nur zum Rechner, von dem sie geladen
wurden, etablieren. Dies bedeutet, daß WWW-Server und DB-Server auf einem Rechner bereitgestellt
werden müssen. Hierdurch sind Kapazitätsengpässe bei der Rechenleistung möglich.
Um diese Einschränkung zu umgehen und zudem den DB-Server vom Internet abzuschirmen, kann auf dem
Rechner mit dem WWW-Server ein Kommunikations-Server (Broker) eingerichtet werden, der die Aufrufe
des Clients an den zuständigen DB-Server weiterleitet.
Erweiterungen von HTML/HTTP:
Im Bereich der CGI-basierten Ansätze haben Erweiterungen vom Übertragungsprotokoll HTTP, der
Dokumentensprache HTML sowie der Server-Funktionalität stattgefunden. HTTP wurde bereits um längere
Verbindungen ergänzt, um so mehrere Dokumentkomponenten auf einmal übertragen zu können. Hierdurch
wird der zeitaufwendige Verbindungsaufbau, der für jede einzuladende Komponente nötig war, vermieden.
Erweitert man nun die Verbindungsdauer auf den Austausch von mehreren Dokumenten, kann man
zusammen mit Verbesserungen der WWW-Server-Funktionalität (z.B. Zustandsverwaltung) längere
Transaktionen realisieren.
5. Architekturen und Verfahren
Zwischen CGI und Applikations-Server oder gar interoperablen Informationssystemen liegen technologische
Welten. Das äußert sich auch in der Architektur der Systeme. Die Ausgangssituation ist eine Zwei-Ebenen12
Architektur: Clients stellen Anfragen an den Server, er liefert statische HTML-Dateien und Bilder. Mit CGI ist
dynamisches HTML möglich. Durch diesen neuen Prozeß erweitert sich die Architektur auf drei Ebenen, bleibt
aber ebenso einfach und kompatibel wie die verwendeten Standards HTTP und CGI. Die Modellierung der
Dokumente findet eher im CGI-Programm als in einer Datenbank statt. Typisch sind schlanke Clients (thin
clients). Werkzeuge für die Programmerstellung sind spärlich gesät. Für die Programmierung des CGI dient eine
beliebige Programmiersprache.
Mit Javascript, Java und ActiveX können nun auch Aktivitäten im Client ablaufen. Neben der Präsentationslogik
kommt Anwendungslogik hinzu, nachdem die direkte Verbindung zur Datenbank über eine allgemeine DBSchnittstelle möglich wird: Java Database Connectivity. Der direkte DB-Zugriff ohne Serveraktivitäten
verringert die Architektur wieder auf zwei Ebenen. Durch aktive Clients und aktive Server entstehen „echte“
Client/Server-Systeme.
Neue Nachteile ergeben sich mit Java, Javascript und ActiveX durch das Verschicken des Codes zum Client:
einerseits ist die Netzbelastung höher, andererseits wird dadurch Know-How freigegeben. Es wird unbekannter
Code auf dem Client ausgeführt.
Abhilfe könnte für Java das „Java Electronic Commerce Framework“ (JEFC) schaffen, durch das neben
extensiven Sicherheitsverfahren (Java Secure API) lokale Kopien von Java-Dienstbibliotheken (Service
Cassettes) gehalten werden.
6. Vor- und Nachteile einiger unterschiedlicher Methoden
CGI-Programmierung (1. Generation):
Vorteile:
Schnelle und flexibelste Methode, um auf einzelne Elemente einer Datenbank zuzugreifen
DB-spezifische Operationen sind gezielt anwendbar
Völlig unabhängig vom eingesetztem WWW-Server
Nachteile:
Programmerstellung aufwendig (umständliche Parameterübergabe, keine CGI-Entwicklungsumgebung,
Debugging problematisch)
Formatierung des Dokuments erst nach der Programmausgabe überprüfbar
Keine Sitzungen, kein Transaktionskonzept über mehrere getrennte Zugriffe; dieselbe Operation könnte
daher im Fehlerfall eventuell mehrmals angestoßen werden
Geringe Performance bei großen Datenmengen wegen des Routings durch denn WWW-Server
Hohe Antwortzeiten wegen der permanenten Neustarts der DB-Client je Anfrage
Hohe Serverbelastung durch Prozeßanzahl
Fazit:
CGI-Programme sind eigentlich nur für den gezielten, transaktionslosen DB-Zugriff bei geringem
Datenaufkommen und kurzer CGI-Prozeßlaufzeit geeignet.
HTML-Makrosprache (2. Generation):
Vorteile:
Schnellste, einfache und relativ flexible Methode, um auf Elemente einer Datenbank zuzugreifen
Allgemeine DB-Anfragen sind wiederverwendbar (Zwei-Dateien-Methode)
Wenn HTML-Editoren die Makro-Anweisungen ignorieren, kann man mit ihnen die Zieldokumente
erstellen
Nachteile:
Abhängigkeit vom verwendeten Produkt (CGI-Anbindung) oder WWW-Server (Unterstützung von
Makrosprache und DB-Schnittstelle)
Bei der Interpretation im CGI kommen dessen Nachteile hinzu
Komplexe Anwendungsfunktionalität mit Makroprozeduren nicht realisierbar
13
Keine expliziten Sitzungen
Fazit:
Um Makros erweitertes HTML ist eine gegenüber CGI elegantere, weil wesentlich schneller zu erstellende und
besser zu wartende Variante des einfachen DB-Zugriffs. Die Auswahl des geeigneten WWW-Servers ist vom
Verfahren der Makro-Interpretation (CGI oder serverintern) und von der dabei unterstützten DB-Schnittstelle/
Makro-Sprache abhängig.
WWW-Server/API (2. Generation):
Vorteile:
Sitzungen sind im WWW-Server verwaltbar
Performance-Gewinn durch dauerhafte DB-Verbindung und den Datenaustausch zwischen WWW-Server
und DB-Client über den gemeinsamen Hauptspeicherbereich
DB-spezifische Operationen sind gezielt verwendbar
Zieldokument kann im HTML-Editor erstellt werden
Nachteile:
Programmerstellung aufwendig (Debugging problematisch)
Hoher Einarbeitungsaufwand in die API-Spezifika
Abhängigkeit von API-kompatiblen WWW-Servern
Gefahr des „Hängen-bleibens“ offener DB-Transaktionen durch noch nicht beendete Sitzungen
Fazit:
API-Programm-Module sind für den sitzungsorientierten DB-Zugriff bei hohem Datenaufkommen geeignet. Die
Module besitzen eine verallgemeinernde Funktionalität, was sich positiv auf ihre Wiederverwendbarkeit und
negativ auf die realisierbare Anwendungslogik auswirkt.
Application-Server (z.T. 3. Generation):
Vorteile:
Alle Vorteile der Arbeit mit Client/Server
Nahtloser Übergang zu einer Middleware möglich, deren breites Leistungsspektrum für Systemintegration
und Interoperabilität von WWW-Diensten nie erreicht werden wird
Nachteile:
Erhöhung der Netzbelastung durch die Übertragung größerer Anwendungen in den Client (fat clients) und
wenn servertypische Arbeiten (z.B. bedingte Selektion) erst im Client durchgeführt werden
AS können laut Java-Sicherheitsrahmen nur auf dem Rechner des WWW-Servers laufen (eventuell weitere
Vermittlung von Anfrage und Daten nötig)
Strenge Ausrichtung nach verwendeter Middleware und Werkzeugen zur Anwendungserstellung
Verlust der „Highlights“ des WWW: einfache Dokumenterzeugung mit HTML und Ersatz des simplen,
standardisierten HTTP durch beliebige Protokolle
Fazit:
Aktive Dokumente eröffnen dem WWW durch die Präsentationsvielfalt im Browser und spezifische Protokolle
neue Einsatzmöglichkeiten. Der Aufwand für die Erstellung einer AS-Anwendung scheint anfangs gering zu
sein. Das stimmt jedoch nur für den Zugriff auf einzelne DB-Elemente mit geringer Anwendungslogik. Die
Programmierung kompletter Anwendungen kommt eher einem Paradigmawechsel gleich, da die
Anwendungslogik im AS konzentriert und verallgemeinert werden muß.
7. Künftige Anforderungen
Das WWW wird mit seinen neuen Datentypen, den erweiterten Anwendungsmöglichkeiten und den gestiegenen
Benutzerzahlen nur unzureichend durch DBS unterstützt. Neue Anforderungen sind entstanden oder zeichnen
14
sich ab. Im folgenden werden die wichtigsten Forschungsschwerpunkte hinsichtlich der Synthese von WWW
und DBS skizziert:
Neue Datentypen für das Website Management
Für die Verwaltung der zur Verfügung zu stellenden Informationen bietet sich bei größeren Datenmengen der
Einsatz von DBS an. Allerdings unterstützen „traditionelle“ DBS nicht die Verwaltung von HTML-Seiten und
ihrer Komponenten, so daß neue Datentypen für die multimedialen Daten (Text, Bilder, Filme, Musik und auch
Programme) benötigt werden. Zwar existieren schon einige Lösungen, die das einfache Speichern ermöglichen,
weitergehende Funktionalität ist in der Regel aber nicht vorhanden.
Zukünftig zu erfüllende Anforderungen
Dateisystem:
Um zum einen die einfache Migration von auf dem Dateisystem basierenden, bestehenden WWW-Servern
hin zu DB-gestützten Lösungen realisieren zu können und zum anderen einfache Verweise innerhalb der DB
zu ermöglichen, bietet sich die Bereitstellung einer Verzeichnisstruktur durch das DBS an. Zudem lassen
sich Verzeichnisangaben innerhalb einer Adresse durch den Anwender einfacher merken als die meist
kryptischen Suchanfragen.
Intelligente (Volltext-)Suche:
Zu den Vorteilen eines DBS gegenüber einem einfachen Dateisystem gehören auch die (erweiterten)
Suchmöglichkeiten, wie zum Beispiel die Volltextsuche. Neben den Fähigkeiten von reinen TextretrievalSystemen wird noch eine weitere Funktionalität benötigt, um die HTML-Anweisungen sinnvoll
interpretieren und ausnutzen zu können. Möchte man alle gespeicherten Dokumente zum Thema HTML als
Ergebnisliste haben, so dürfen nicht alle Dokumente angezeigt werden (alle HTML-Texte beginnen mit der
Anweisung <HTML>...). Suche nach Autoren, Schlüsselwörtern, Erstellungsdatum oder nach bestimmten
Inhaltsstrukturen (enthält drei Querverweise, Listen, etc.) erscheinen angebracht.
Versionierung:
Die Möglichkeit zur (automatischen) Erhaltung und zum Lesen von älteren Dokumentenversionen bringt
viele Vorteile mit sich. Zum einen läßt sich verlustfrei editieren, zum anderen können so z.B. ohne großen
Aufwand bei ständig aktualisierten Texten auch ältere Versionen (beispielsweise die Titelseite eines
bestimmten Datums bei einer Zeitung) dem Anwender zur Verfügung gestellt werden. Zudem läßt sich mit
Hilfe der Versionierung ein großer Datenbestand für den Anwender konsistent halten: Es wird so lange die
alte Dokumentversion geliefert, bis alle Seiten und damit auch die Querverweise aktualisiert wurden, dann
erst wird auf die neuste Version umgeschaltet. Das Web DataBlade von Illustra bietet Versionierung als
„Time Travel“-Option an.
Referentielle Integrität:
Die Wartung der internen Querverweise der Hypertext-Dokumente ist eine sinnvolle Aufgabe, die jedoch
wegen des Aufbaus von HTML nur durch eine Analyse der HTML-Seiten möglich ist.
Einfaches Editieren:
Das Editieren der durch das DBS verwalteten Dokumente muß weiterhin mit den normalen Werkzeugen
ohne größeren Aufwand möglich sein.
Systeme für die Webanbindung von Datenbanken
Werden WWW-basierte Anwendungen realisiert, die Synchronisation erfordern, entstehen für die DBS eine
Reihe neuer Anforderungen:
Lange Transaktionen:
Im Gegensatz zu „normalen“, lokalen Applikationen entstehen durch die Internet-Nutzung teilweise
erhebliche Übertragungszeiten zwischen DB-Client und –Server. Kommt dazu noch Benutzeraktion
(„human in the loop“), so werden aus einfachen Transaktionen Lange Transaktionen mit den entsprechenden
Auswirkungen, Leistungsprobleme sind die Folge.
15
Neue Anwendungen und Synchronisation:
Werden im Rahmen einer Transaktion nicht nur vorgegebene Anwendungsschritte vollzogen, sondern die
Möglichkeit zur (mengenorientierten) Anfrageausführung und „Daten-Browsing“ gegeben, hat dies
Auswirkungen auf die Leistungsfähigkeit des DBS. Durch das „Browsing“ bzw. die Anfragen können große
Teile des Datenbestands für andere Transaktionen (zum Schreiben) gesperrt werden. Wie bei den Langen
Transaktionen entsteht ein geringer Systemdurchsatz durch Deadlocks oder Wartezeiten.
Authentisierung:
Anders als bei lokalen DB-Anwendungen, die nur einem begrenzten Personenkreis offenstehen und bei
denen Authentisierung bzw. Autorisierung meist über das Benutzerkennzeichen abgewickelt werden, lassen
sich WWW-basierte Applikationen von potentiell jedem Internet-Teilnehmer nutzen. Die vom WWW
bekannte Autorisierung über die Eingabe eines Namens und eines Passworts ist für kritische Anwendungen
(Bankgeschäfte über das Internet, etc.) nicht ausreichend. Weitergehende Maßnahmen wie beispielsweise
Transaktionsnummern (TANs) sowie Digitale Signaturen werden benötigt. Für das DBS entstehen neue
Verwaltungsaufgaben.
Systemarchitekturen für die Webanbindung von Datenbanken
Ein Großteil der CGI-Lösungen der ersten und zweiten Generation hat erhebliche Geschwindigkeitseinbußen
durch die mehrstufige Aufrufhierarchie. Der WWW-Server wird zum Flaschenhals, hohe Transaktionsraten sind
nicht möglich. Die Erweiterung des WWW-Servers mit Hilfe der Server-API beschleunigt nur die Verarbeitung,
der WWW-Server bleibt weiterhin ein Nadelöhr. Hauptproblem ist der zentralistische Ansatz, das heißt, alle
Zugriffe werden über einen WWW und einen DB-Server abgewickelt. Abhilfe schafft hier nur die Verteilung der
Last auf mehrere Server. Während sich statische Informationen relativ einfach auf mehrere WWW-Server
verteilen lassen, bereitet eine eventuelle Aufteilung von häufig aktualisierten und in DBS gehaltenen Daten mehr
Probleme. Die beiden folgenden (nicht disjunkten) Szenarien zeigen die Hauptprobleme.
Szenario 1:
Die DB-Daten werden nicht nur von WWW-Anwendungen, sondern auch von anderen, „traditionellen“
Applikationen (Legacy-Applikationen) genutzt, und das DBS bietet von sich aus keine Möglichkeit zur
Verteilung. Möchte man nun die Daten auf mehrere DB-Server aufteilen bzw. entsprechende Replikate
anbieten, müssen die (unterschiedlichen) DBS durch eine zusätzliche Schicht (Middleware) zwischen
WWW- und DB-Server untereinander synchronisiert und die Konsistenz der Replikate mit dem Original
bzw. die des Originaldatenbestands gewährleistet werden. Wichtig erscheint vor allem die sinnvolle
Integration der Legacy-Systeme.
Szenario 2:
Teile eines zentralen Datenbestands müssen weltweit verfügbar sein, andere länderspezifische
Informationen nur lokal. Um adäquate Übertragungsbandbreiten für alle Nutzer garantieren zu können,
werden daher alle benötigten Daten jeweils lokal, zum Teil als Replikat des globalen Datenbestands,
gehalten. Zur Gewährleistung der Datenkonsistenz wird ein Verteiltes DBS (Distributed DBS, DDBS)
benötigt. Anders als bei den meisten der bisherigen Ansätze für DDBS wird jedoch kein lokales Netz,
sondern das Internet verwendet.
16
WWW-Server
(Solaris, NT,...)
MiddlewareApplikation
LegacyApplikation
Middleware
WWW-Server
Relationaler
DB-Server
Legacy
DB-Server
Daten
DB-Server
Daten
Daten
Szenario 1
Daten
Szenario 2
Abb.6: Systemarchitekturen
Ein wichtiger Aspekt bei beiden Szenarien ist die Kooperation von DBS, sei es als Komponenten im Rahmen
eines DDBS oder als weitgehend autonome Systeme im Bereich von MDBS und FDBS. Geht man davon aus,
daß ein Großteil der „traditionellen“ Daten in (prä-)relationalen Systemen vorliegt, aber für die Verwaltung von
HTML-Seiten, wenn überhaupt, überwiegend objektorientierte oder objektrelationale Systeme eingesetzt
werden, so ist besonders die Kooperation zwischen den einzelnen „Generationen“ gefordert.
8. Zusammenfassung und Ausblick
Webanbindung von Datenbanken (DBS -> Web)
Die Menge angebotener Tools zur WWW-DB-Integration entwickelt sich fast so rasch wie das WWW selbst.
Verschiedene Verfahren haben sich durch client- und serverseitige Erweiterungen herausgebildet. Eine
Favorisierung einer der unterschiedlichen Basistechnologien wie CGI, API und Application-Server ist nicht
abzusehen, da die Anforderungen letztlich anwendungsspezifisch sind und die Komplexität mit
leistungsfähigeren Tools und Techniken sehr stark ansteigt.
Eine optimale Lösung für die DB-Anbindung an das WWW existiert bislang nicht, es gibt einen „Tradeoff“
zwischen der Mächtigkeit der Ansätze und der Einfachheit der Anwendungserstellung. Wünschenswert ist eine
Lösung mit der Mächtigkeit von Java in Verbindung mit der Einfachheit von HTML. Als Entwicklungstrend ist
daher auch die Ergänzung bestehender CGI-basierter Produkte um weitere Funktionalität festzustellen. Es gilt,
die Zustandslosigkeit von HTTP zu überwinden, um auch Anwendungen mit längeren Transaktionen zu
ermöglichen. In diesem Punkt sind eindeutig die Lösungen auf Basis von Java im Vorteil, da sie eine echte
Client/Server-Umgebung realisieren können.
Website Management mit Datenbanken (Web -> DBS)
Während schon mehr oder weniger geeignete Lösungen für die Anbindung bestehender DBS existieren, besteht
bei den DBS bezüglich der WWW-Unterstützung noch größerer Forschungsbedarf. Für die Verwaltung von
HTML-Dokumenten und ihrer multimedialen Komponenten mit Hilfe eines DBS werden geeignete Datentypen
benötigt. Die Koexistenz von neuen WWW-basierten und Legacy-Systemen ist eine Herausforderung, die
individueller Lösungen bedarf. Auch die Verwaltung und Anbindung der Daten global operierender und daher
17
weltweit vertretender Unternehmen auf Basis von Intra- und Internet bringt interessante Forschungsaspekte im
Bereich der Datenbanken mit sich. Die Plattformunabhängigkeit des WWW mit HTML und Java verdeckt die
Heterogenität auf der Benutzerseite und schafft gerade damit ganz neue Möglichkeiten für DB-gestützte
Anwendungen.
In vielen Hinsichten ist das WWW einer Datenbank unähnlich. So gibt es beispielsweise keine einheitliche
Struktur, keine Integritätsbeziehungen, keine Transaktionen, keine Standardanfragesprache oder Datenmodell.
Vielleicht erweisen sich die mächtigen Abstraktionen, die in der Datenbankgemeinde entwickelt wurden, als
Schlüssel dafür, die Komplexität des Internets zu verringern und wertvolle Dienste anzubieten.
Von besonderer Bedeutung ist die Sichtweise einer großen Webseite nicht nur als eine Datenbank, sondern als
ein Informationssystem umgeben von einer oder mehreren Datenbanken und versehen mit komplexer
Navigationsstruktur. In dieser Hinsicht hat eine Webseite viele Gemeinsamkeiten mit Informationssystemen
außerhalb des Webs. Eine solches Webseitendesign erfordert das Erweitern der Designmethoden für
Informationssysteme. Benutzt man diese Grundlagen, um Webseiten zu konstruieren, wird sich das auch auf die
Art der Webanfragen und die Art der Datenintegration von mehreren Webquellen auswirken.
Verschiedene Trends werden bedeutenden Einfluß auf die Nutzung von Datenbanktechnologie für Internetapplikationen haben. Der erste ist natürlich XML. Der beträchtliche Schwung von XML und
zusammenhängenden Metadaten kann die Ankopplung von Datenbankkonzepten ans Internet nur unterstützen,
indem die dringend gebrauchte Struktur in einem vielseitig akzeptierten Format bereitgestellt wird.
Während die Verfügbarkeit von Daten im XML-Format die Notwendigkeit verringern wird, sich auf WrapperProgramme zu fixieren, die für den Menschen lesbaren Code in Maschinencode konvertieren, bleibt die
Herausforderung der semantischen Integration der Daten von Internetquellen jedoch nach wie vor.
Ein zweiter Trend, der die Anwendbarkeit von Datenbanktechniken zur Anfrage des Internets beeinflussen wird,
ist das Wachstum des sogenannten „Verdeckten“ Netzes (hidden web). Dieses Netz bezieht sich auf die
Webseiten, die erzeugt werden von mit Benutzereingaben gefütterten Programmen und deshalb nicht von
Suchmaschinen (web crawler) zur Indexierung zugänglich sind. Es wurde behauptet, daß fast 80% des Webs
bereits im Verdeckten Netz ist. Wenn Tools von Daten aus diesem Netz profitieren sollen, muß man Techniken
zur Identifizierung von Seiten entwickeln, die Webseiten erzeugen, sie klassifizieren und automatisch
Anfrageschnittstellen an diese erstellen.
Es gibt keinen Mangel an möglichen Entwicklungsrichtungen auf diesem Gebiet. In der Vergangenheit
konzentrierte sich die Masse der Arbeit auf die logische Ebene, die Entwicklung von passenden Datenmodellen,
Anfragesprachen und Methoden, verschiedene Aspekte von Internetquellen zu beschreiben. Im Kontrast dazu
erhielten Probleme wie Anfrageoptimierung und -ausführung relativ wenig Aufmerksamkeit und bieten einen
Teil der wichtigeren Herausforderungen für zukünftige Arbeiten. Einige der bedeuterenden Richtungen, in die
man die vorhandenen Datenmodelle und Anfragesprachen erweitern muß, beinhaltet das Einbeziehen von
verschiedenen Formen von Metadaten über Quellen und die prinzipielle Kombination von Anfragen
strukturierter und unstrukturierter Daten an das WWW.
Die Technologien des Internets ebnen den Weg für ganzheitliche Informationssysteme. Sie bieten jedoch nur
Basisfunktionalität. Für den Ausbau von WWW-DB-Übergängen zu Unternehmensinformationssystemen
werden weitaus mächtigere Konzepte für Datenmodellierung (Meta-Informationen), Dokumentverwaltung, lange
und kooperative Transaktionen sowie Anfragesprachen benötigt. Es kommt darauf an, die Vorzüge offener
Kommunikationsplattformen mit der Leistungsfähigkeit von Datenbanksystemen und Middleware zu verbinden,
ohne auf einer neuen Stufe in die Welt proprietärer Systeme zurückzufallen.
9. Literatur
Benn W., Gringer I.: Zugriff auf Datenbanken über das World Wide Web
Florescu D., Levy A., Suciu D.: Is Website Management a Database Problem?
Florescu D., Levy A., Suciu D.: Database Techniques for the World-Wide Web: A Survey
Loeser H.: Datenbankanbindung an das WWW - Techniken, Tools und Trends
18
