next up previous contents
Next: Gateway-Strategien Up: Design eines Datenbank-Gateways Previous: WWW-Server mit SQL-Funktionalität

Alternative Datenhaltung für die JAWA

Neben der in Kapitel [*] beschriebenen Speicherung der Jahreswagendaten in einem relationalen Datenbanksystem bietet sich die Möglichkeit an, eine sequentielle Datei als Datenbasis für die JAWA zu verwenden. Anstatt die Jahreswagendaten nach dem Transfer vom Großrechner auf das Unix-basierte System in die dortige relationale Datenbank einzuspielen, könnten die Daten als sequentielle Datei (,,flat file``) dem CGI-Skript zur Verfügung gestellt werden. Das bedeutet, daß die sequentielle Datei mit dem Extrakt der Jahreswagendaten nur noch vom Großrechner auf das Unix-basierte System übertragen wird und dort als Datenbasis für die JAWA verwendet werden kann (Abbildung [*]). Damit beschränken sich die Zugriffe des CGI-Skripts nur noch auf Dateizugriffe.


  
Abbildung: Sequentielle Datei als Datenbasis für die JAWA

Dies bedeutet, daß keine teuren Datenbankzugriffe mehr notwendig sind, um die gewünschten Daten aus dem Datenbestand zu extrahieren. Anstatt aufwendiger SQL-Anweisungen verwendet das CGI-Skript ausschließlich einfache Dateioprationen für den Zugriff auf die Daten. Zudem muß nicht explizit ein relationales Datenbanksystem angeschafft und installiert werden, falls es nicht schon vorhanden ist und für die JAWA verwendet werden kann. Betrachtet man die mögliche Archtiektur des CGI-Skripts, kommt dafür nur das ,,Standalone-Gateway`` in Frage. Anstatt mit dem relationalen Datenbanksystem zu kommunizieren, operiert das CGI-Skript ausschließlich auf einer Datei. ,,Client/Server-Gateway`` und ,,WWW-Server mit SQL-Funktionalität`` kommen als Architekturmodell bei dieser Alternative nicht in Frage, weil das CGI-Skript keine explizite Verbindung zu einem weiteren Kommunikationspartner, wie beispielsweise dem Datenbanksystem, aufrechterhalten muß. Weitere Vorteile dieses Ansatzes sind die geringe Komplexität der Anwendung und die daraus resultierende einfache Implementierung. Betrachtet man die Fehleranfälligkeit des Systems, stellt man fest, daß nur das CGI-Skript selbst als Fehlerquelle in Frage kommt. Bei der Implementierung des CGI-Skripts würde sich perl [WS91] als Programmiersprache anbieten. Es zeichnet sich durch das Bereitstellen einfacher und sehr effizienter Möglichkeiten aus, auf Dateien zuzugreifen und diese zu modifizieren. Außerdem enthält perl eine gute ,,Pattern Matching``-Funktionalität.

Neben den vielen Vorteilen stehen diesem Ansatz auch einige Nachteile gegenüber. Enthält die sequentielle Datei sehr viele Datensätze, erweist sich die Wartung der Datei als schwierig, da im Gegensatz zu relationalen Datenbanksystemen kein Standard wie beispielsweise SQL existiert, um die Datensätze einfach und komfortabel zu modifizieren. Das Ändern von Datensätzen, wie beispielsweise das Entfernen, Hinzuzufügen oder Modifizieren, erfordert das manuelle Editieren der Datei. Ein weiteres Problem stellt die Modellierung der Daten dar. Einfache Datenstrukturen lassen sich ohne größeren Aufwand auf Daten in Dateien abbilden. Problematischer erweist sich die Lage bei komplexen Datenstrukturen. Lassen sich beispielsweise Daten im relationalen Modell durch eine Tabelle modellieren, ist die Abbildung des relationalen Modells auf eine Datei einfach. Möchte man aber beispielsweise komplexere Datenstrukturen in einer Datei abbilden, können dabei Probleme auftreten. Betrachtet man die Btx-basierende Anwendung ,,Gebrauchtwagenbörse`` [BMW92], sind dort mehrere Tabellen notwendig, um die Daten im relationalen Modell zu modellieren. Eine Abbildung dieses Modells auf eine Datei würde sich als äußerst schwierig erweisen. Je mehr Datensätze eine Datei enthält desto zeitaufwendiger gestaltet sich das Suchen innerhalb dieser Datei. Der Zeitvorteil, der sich durch den Zugriff auf eine Datei ergibt, wird zunehmend kleiner, je größer die Datei ist, auf die zugegriffen wird. Ab einer bestimmten Dateigröße ist es sogar vorteilhafter, die Daten in einer relationalen Datenbank zu speichern, weil die Datenbankzugriffe dann trotz des zeitaufwendigen Verbindungsaufbaus schneller erfolgen als normale Dateizugriffe. Betrachtet man beim Design eines solchen Gateways den Betriebsaspekt ,,Caching``, stellt man fest, daß man einen eigenen Cache entwickeln und implementieren muß, um Benutzeranfragen zwischenzuspeichern. Bei Verwendung von relationalen Datenbanksystemen als Datenbasis ist dies nicht erforderlich, weil dort das Datenbanksystem selbst das Zwischenspeichern von Anfragen übernimmt.

Für die JAWA besteht zwar die Möglichkeit eine sequentielle Datei mit den Jahreswagendaten als Datenbasis für die Anwendung zu verwenden. Da aber der zu entwickelnde Prototyp der JAWA als Grundlage für die Entwicklung weiterer WWW-Anwendungen dienen soll, beispielsweise als Grundlage einer möglichen WWW-basierten ,,Gebrauchtwagenbörse``, wird ein relationales Datenbanksystem als Datenbasis für die Anwendung vorgezogen. Anhand des Prototypen der JAWA soll der Zugriff auf Datenbanken aus dem WWW heraus exemplarisch dargestellt werden.


next up previous contents
Next: Gateway-Strategien Up: Design eines Datenbank-Gateways Previous: WWW-Server mit SQL-Funktionalität
Root on HPHEGER0
8/27/1998