Die Mehrzahl der heute noch entwickelten Client-Server- Datenbankanwendungen beruht auf einem Zweischichtenmodell, bei dem der Client direkt mit dem Datenbank-Server kommuniziert. Die Architektur des World Wide Web, das über sogenannte Intranets die Unternehmens-DV erobert, ist aber dabei, einen Standard für mehrschichtige (sogenannte Multitier-)Anwendungen zu etablieren.
Beim Web-Modell schickt der Browser als Client Anfragen über das Hypertext Transfer Protocol (HTTP) an den Web-Server. Geht es um Anforderung von Hypertext-Markup-Language-(HTML-) Seiten, liefert er sie gleich selbst an den Browser. Ist der Rückgriff auf andere Datenquellen erforderlich, reicht er die Anfrage an Web-Server- Erweiterungen weiter. Dies sind derzeit meist Common-Gateway- Interface-(CGI-)Programme, die zusammen mit dem Web-Server die mittlere Schicht darstellen. Deren Aufgabe besteht darin, die Anfragen in ein Format zu übersetzen, das die dritte Schicht, der Datenbank-Server, akzeptiert (beispielsweise SQL). Das Datenbanksystem führt die gewünschten Aktionen aus und gibt das Ergebnis an das Gateway-Programm zurück. Dieses konvertiert die erhaltenen Daten ins HTML-Format und übergibt sie dem Web-Server, der sie an den Browser versendet.
Im Vergleich zu herkömmlichen zweischichtigen Anwendungen haben Web-basierte Datenbankprogramme mit zwei grundsätzlichen Schwierigkeiten zu kämpfen. Der Browser - im Gegensatz zu proprietären Clients - verfügt mit HTML nur über geringe Möglichkeiten der Eingabevalidierung und über gar keine Mittel zur Transaktionskontrolle. Zum zweiten handelt es sich bei HTTP, über das Web-Browser und -Server kommunizieren, um ein zustandsloses (stateless) Protokoll. HTTP-Verbindungen werden nach jeder vollzogenen Übertragung beendet.
Datenbank-Tools der zweiten Generation versuchen, diese Schwachpunkte auszubügeln, die vor allem das Online Transaction Processing (OLTP) beeinträchtigen. Web-basierte Data-Warehouse- Anwendungen leiden weniger unter diesen Einschränkungen, da sie keine Änderungen in der Datenbank vornehmen.
Was die Defizite von Web-Browsern als Datenbank-Front-ends anlangt, kristallisieren sich Client-seitige Lösungen heraus, die im wesentlichen auf vier Techniken beruhen: Helper-Applikationen, Plug-ins, Scripts und Java-Anwendungen.
Die beiden ersten Browser-Erweiterungen sind mit Vorsicht zu genießen, da sie grundlegende Vorteile von Intranets, nämlich die Plattformunabhängigkeit und wartungsfreundliche, schlanke Clients, zunichte machen können.
Bei Scriptsprachen für Web-Applikationen dominiert bis dato Netscapes "Javascript", mit dem auch die neueste Version des Microsoft-Browsers umgehen kann. Der Programmcode von Scripts ist Teil von HTML-Seiten und wird vom Browser interpretiert. Javascript ist mächtig genug, um die Validierung von HTML- Eingabefeldern vorzunehmen und einfache Transaktionskontrollen zu leisten (beispielweise über die Methoden "Begin Transaction", "Commit Transaction" und "Rollback Transaction").
Nichtpersistente HTTP-Verbindungen
Als ausgewachsene Programmiersprache bietet Java die meisten Kontrollinstrumente sowohl für den Input als auch den Output. Java-Applets werden ebenfalls über HTTP heruntergeladen, ermöglichen aber für den Zugriff des Clients auf die Datenbank auch die Verwendung anderer Protokolle. Entwickler können also mit Java gleich noch das Problem des zustandslosen HTTP-Protokolls bewältigen. Direkte Datenbankverbindungen werfen aber Sicherheitsprobleme auf, wenn sich der Client außerhalb der Firewall befindet.
Die Problematik nichtpersistenter HTTP-Verbindungen ist vielleicht die größte Herausforderung bei der Entwicklung Web-basierter Datenbankanwendungen. Normalerweise tauschen Datenbank-Client und -Server Statusinformationen über eine feste Verbindung aus.
Nun muß über eine Vielzahl kurzzeitiger Zugriffe hinweg verfolgt werden, in welcher Phase sich Transaktionen gerade befinden und welcher Anwender welche Verbindung hält. Kritisch ist dabei die Authentifizierung: Dem Anwender kann nicht zugemutet werden, sich in einer Sitzung Dutzende oder Hunderte Male neu anzumelden. Hinzu kommt, daß im einfachen CGI-Modell bei jedem Hit das betreffende Gateway-Programm hochgefahren und eine neue Datenbankverbindung aufgebaut werden muß. Dies führt zu einer erheblichen Belastung der Server.
Die Anbieter von Web-Werkzeugen gehen diese Problematik in erster Linie auf der Server-Seite an. Bei den Clients bieten sich dagegen hauptsächlich sogenannte "Cookies" an, die Statusinformationen auf der Festplatte des Web-Clients speichern. Als Alternative zum ursprünglichen CGI-Modell bilden sich zwei Web-Erweiterungen heraus, die Performance-Verbesserungen und erweiterte Möglichkeiten zur Verwaltung von Statusinformationen mit sich bringen: das hybride CGI- und das API-Modell.
Bei ersterem startet der Web-Server nach wie vor ein CGI-Programm, das sich jedoch auf die Übermittlung der Eingabedaten an einen Partnerprozeß beschränkt. Dieser ist unter Unix als Dämon, unter Windows NT als Dienst implementiert. Er wird in der Regel nur einmal geladen und bleibt ständig im Hintergrund verfügbar. Ein solcher Prozeß leistet praktisch die ganze Arbeit und hält über die Dauer von HTTP-Verbindungen hinaus Datenbankverbindungen offen. Diesen Ansatz verfolgen beispielsweise die Allaire Corp. mit "Cold Fusion" und Aspect Software Inc. mit "db-Web".
Der API-Ansatz umgeht das CGI vollständig und fügt dem Web-Server Erweiterungen über dessen Programmier-Schnittstelle hinzu. Unter Unix werden diese als Shared Objects, unter Windows NT als Dynamic Link Libraries (DLLs) realisiert. Die zwei diesbezüglich bekanntesten APIs sind Netscapes NSAPI und Microsofts ISAPI. Neben dem Vorteil geringen Overheads hat dieser Ansatz auch gewichtige Nachteile: Im Gegensatz zu CGI sind sie proprietär, und eine fehlerhafte Erweiterung kann den ganzen Web-Server zum Absturz bringen.