Von: Jan Hermelink, Georg von Stein
Das grundsätzliche Modell einer Intranet-Datenbank besteht aus einem Datenbanksystem, einem Web-Server und einem Browser. Der Browser kommuniziert über das Verbindungsprotokoll HTTP und die Seitenbeschreibungssprache HTML mit dem Web-Server und "weiß" nichts von der Datenbank: aus seiner Sicht erhält er HTML-Code vom Web-Server, den er darstellen muß. Es ist Aufgabe des Web-Servers, eine Verbindung zum Datenbanksystem aufzubauen und die Daten so umzusetzen, daß der Browser sie darstellen kann. Aber es gibt auch eine Alternative zu dem grundsätzlichen Modell: die direkte Verbindung vom Browser zur Datenbank. Dieser Ansatz setzt jedoch auf Seite des Browsers Java oder ActiveX voraus. Der wesentliche Vorteil beider Ansätze ist die Plattformunabhängigkeit. Der Zugriff über den Browser ist unter den verschiedenen Betriebssystemen (Windows 3.1, Windows NT, Macintosh, Unix, OS/2, Hostsysteme et cetera) möglich und meist unabhängig von einem bestimmten Browser-Hersteller. Ergänzt werden kann das Grundmodell durch spezielle Administrations-, Wartungs- und Entwicklungswerkzeuge, die in der Regel nicht auf HTML beziehungsweise HTTP basieren und nur auf einer bestimmten Betriebssystem-Plattform ablaufen. So kann es sein, daß man für das Einrichten von Benutzerkennungen in der Datenbank ein Verwaltungsprogramm verwenden muß, das nur unter Unix und nicht im gesamten Intranet ablauffähig ist. Beim Einbinden einer Datenbank in ein Intranet spielt eine entscheidende Rolle, daß man plattformunabhängig über HTML als einheitliche Schnittstelle auf Unternehmensdaten zugreifen kann.
Auswahlkriterien
Für jedes Datenbanksystem müssen die Daten, die gespeichert werden sollen, in irgendeiner Weise strukturiert werden. Sie müssen deshalb zunächst festlegen, ob Sie ein relationales oder ein objektorientiertes Datenbanksystem einsetzen wollen. Da relationale Systeme derzeit deutlich häufiger als andere im Intranet eingesetzt werden, setzen wir hier einen Schwerpunkt auf deren Einbindung. Im relationalen Modell werden Daten ausnahmslos als Tabellen strukturiert: die Spalten der Tabelle sind die Datenfelder, die Zeilen die einzelnen Datensätze. Sollen beispielsweise Personaldaten gespeichert werden, so muß für jeden Mitarbeiter ein Datensatz (Tabellenzeile) angelegt werden, der die einzelnen Merkmale des Mitarbeiters wie Name, Abteilung, Eintrittsdatum et cetera (Tabellenspalte) enthält. Dieses Modell ist einfach zu verstehen und seit den 70er Jahren weit verbreitet: Datenbank-Hersteller und -Entwickler haben große Erfahrung damit, woraus die in der Regel sehr gute Performance und Verbreitung von relationalen Datenbanken resultiert.
Als erstes ist bei relationalen Systemen zu klären, ob ein "kleines System" wie "dBase" oder "Microsoft Access", das sich auf einem beliebigen Fileserver installieren läßt, ausreicht oder ob Sie Systeme wie Sybase, Oracle, Informix, CA "Open Ingres" benötigen, die auf einem eigenen Datenbank-Server laufen. Folgende Kriterien sollten die Wahl des Datenbanksystems beeinflussen:
Skalierbarkeit des Systems, Benutzer-Identifikation, Datenzugriff und SQL und Bedeutung des Datenbankprotokolls.
Eine Datenbanklösung im Intranet, die für viele einen Nutzen bringt, bewirkt in der Regel, daß Datenmenge und Zahl der Anwender, die gleichzeitig auf die Datenbank zugreifen, stärker als vorhergesehen anwachsen. Dadurch kann es zu Engpässen beim Datenzugriff kommen. Wenn Maßnahmen wie der Einbau schneller Platten und die Verwendung eines schnellen Datenbankrechners nicht mehr ausreichen, sollte eine Datenbank durch folgende Maßnahmen skalierbar sein:
Einsatz mehrerer Prozessoren: Viele Datenbanksysteme wie Oracle, Informix, Sybase oder der "MS SQL -Server" sind auf einem Mehrprozessorsystem in der Lage, mehrere Datenbankabfragen parallel abzuarbeiten. Ist dies nicht der Fall, wie zum Beispiel bei dem Shareware-Datenbanksystem "msql" von Hughes Technologies, bringt der Einsatz eines solchen Systems nichts. Wechsel auf eine andere Hardware-Plattform: Unter Umständen kann eine Leistungssteigerung durch Wechsel auf eine andere Hardware erreicht werden (beispielsweise von Intel- auf RISC-Prozessoren). Dies setzt jedoch voraus, daß eine Version des Datenbanksystems auch auf der neuen Plattform läuft. Einsatz eines anderen Betriebssystems: Da im Intranet eigentlich Plattformunabhängigkeit herrschen sollte, spielt die Migrationsfähigkeit von Datenbanken auf unterschiedliche Betriebssysteme eine nicht zu unterschätzende Rolle. So kann der Wechsel auf eine andere Hardware-Plattform auch den Wechsel des Betriebssystems bedingen. Auch in diesem Falle muß eine Version des Datenbanksystems für das neue Betriebssystem verfügbar sein. Eine Migration von NT auf Unix wäre mit Oracle beispielsweise möglich, mit Microsofts SQL-Server aber nicht.
Identifikation
Alle Datenbanksysteme erlauben die Einrichtung von Datenbank-Kennungen. Diese haben jedoch den Nachteil, daß sich der Benutzer erneut bei der Datenbank registrieren muß, obwohl er in der Regel bereits im Intranet angemeldet ist. Im Gegensatz dazu erlauben einige Datenbanksysteme, beispielsweise der Microsoft SQL-Server, die Integration von Netzkennungen. Das heißt, durch seine Netzkennung ist der Benutzer dem Datenbanksystem bereits bekannt, ohne sich erneut anmelden zu müssen. Dies erspart nicht nur dem Benutzer Arbeit, weil er nicht erneut eine Kennung und ein Paßwort eingeben muß, sondern auch den Administratoren des Intranets, da sie keine eigenen Datenbank-Kennungen einrichten müssen.
Datenzugriff mit SQL
Wenn die Struktur einer Datenbank erst einmal steht, muß sie zum Leben erweckt werden. Daten müssen hinzugefügt, geändert, gelöscht und vor allem abgefragt werden. Für Operationen in relationalen Datenbanken hat sich die mittlerweile über 20 Jahre alte Sprache SQL (Structured Query Language) als Standard eingebürgert (ANSI-SQL92).
Das Prinzip, nach dem SQL arbeitet, ist einfach: Sie senden eine SQL-Anweisung wie SELECT an die Datenbank, und diese führt die gewünschte Aktion durch - schickt also beispielsweise Daten zurück. Solange Sie sich an das standardisierte ANSI-SQL halten, können Sie sogar relativ einfach auf eine andere Datenbank wechseln. Zur Leistungssteigerung lassen sich "Stored Procedures" einsetzen; das sind Abfolgen von SQL-Anweisungen, die in der Datenbank voroptimiert gespeichert werden. Beim Aufruf einer Stored Procedure müssen nur ihr Name und eventuelle Parameter angegeben werden, um die dahinterstehenden SQL-Anweisungen auszuführen. Dieses Verfahren hat zwei Vorteile: Zum einen müssen nicht die gesamten SQL-Anweisungen zum Datenbankserver übertragen werden, was bei komplexeren Operationen die Netzwerkbelastung vermindert. Zum anderen kann das Datenbanksystem die SQL-Anweisungen in einer optimierten Form ablegen, so daß sie schneller ausgeführt werden. Wenn Sie Stored Procedures einsetzen, um die Leistungsfähigkeit moderner Datenbanksysteme zu erhöhen, ist der Wechsel auf ein anderes Datenbanksystem allerdings nicht mehr so leicht. Gerade bei einer stark genutzten Intranet-Datenbanklösung kann der dadurch erzielte Performance-Gewinn entscheidend sein. Sie handeln sich aber wegen der fehlenden Standardisierung eine starke Abhängigkeit von einem bestimmten Datenbanksystem ein. Wechseln Sie zu einem anderen Hersteller, müssen sämtliche Stored Procedures umgeschrieben werden, was bei einem größeren Projekt leicht Aufwand in Höhe eines Mannmonates bedeuten kann. In der nächsten Version des SQL-Standards ist allerdings geplant, die Syntax dieser Stored Procedures zu vereinheitlichen.
Protokolle
Das letzte Kriterium ist das Protokoll, über das SQL-Anweisungen zwischen dem WWW-Server und dem Datenbank-Server hingeschickt und Daten zurückgeschickt werden. Es legt fest, wie Daten und SQL-Code über das Netzwerk gesendet werden. Klassischerweise verwendet jeder Datenbankhersteller sein eigenes proprietäres Protokoll (wie zum Beispiel "SQL Net" von Oracle oder "TDI" von Microsoft). Der Nachteil liegt auf der Hand: Will man im Intranet auf ein anderes, eventuell leistungsfähigeres Datenbanksystem wechseln, sind sämtliche Anwendungen umzuschreiben.
Seit einigen Jahren hat sich jedoch eine Alternative zu den herstellerspezifischen Protokollen durchgesetzt: die ursprünglich von Microsoft entwickelte, heute aber für viele Plattformen erhältliche Datenbankschnittstelle ODBC (Open Database Connectivity). ODBC ist kein eigenes Datenbankprotokoll, sondern legt eine zusätzliche Schicht zwischen Ihre Datenbankanwendung und das jeweilige proprietäre Protokoll. Ihre Anwendung kommuniziert über einen ODBC-Treiber, der auf dem jeweiligen Rechner installiert sein muß, mit der Datenbank und kann damit eine einheitliche Schnittstelle gegenüber der Datenbank verwenden. Diese Einheitlichkeit besteht auf zwei Ebenen:
Der ODBC-Treiber bietet eine ANSI-SQL-konforme SQL-Schnittstelle. Ist das verwendete Datenbanksystem nicht ANSI-SQL konform, so ist es Aufgabe des Treibers, die SQL-Anweisungen entsprechend umzusetzen. Außerdem definiert der Treiber gegenüber der Anwendung eine einheitliche Schnittstelle zum Absetzen von SQL-Anweisungen und zum Empfangen von Daten aus der Datenbank. Der Treiber muß die jeweilige Anpassung an das proprietäre Datenbank-Protokoll vornehmen.
Der Vorteil der Vereinheitlichung: Beim Wechsel auf ein anderes Datenbanksystem im Intranet muß nur der ODBC-Treiber ausgetauscht werden - die Anwendung selbst bleibt unverändert. Ein Haken an der Sache ist allerdings, daß die oben angesprochenen Stored Procedures davon unberührt bleiben: Sie müssen auf jeden Fall für das neue System umgeschrieben werden. Ein weiteres Problem ist die schlechte Performance mancher ODBC-Treiber. So weisen die Oracle-Treiber von Oracle selbst eine schlechtere Performance auf als die von Visigenic oder Intersolv. Dennoch erfreut sich ODBC großer Beliebtheit. Ein Grund ist sicher auch darin zu sehen, daß auf der Seite der Entwickler der Aufwand für die Einarbeitung in datenbankspezifische Schnittstellen entfällt.
Java Database Connectivity
Javasoft hat den Ansatz von ODBC für Java aufgegriffen und mit dem Java Entwickler Kit in der Version 1.1 eine Schnittstelle namens JDBC (Java Database Connectivity) verfügbar gemacht, die den Datenbankzugriff ähnlich wie ODBC ermöglicht. JDBC hat jedoch gegenüber ODBC zwei entscheidende Vorteile, die gerade in Intranets zum Tragen kommen: Erstens sind die Treiber in Java geschrieben und damit plattformunabhängig einsetzbar, wohingegen ODBC-Treiber abhängig von einer bestimmten Systemumgebung sind. Zweitens sind ODBC-Treiber auf jedem Rechner zu installieren, auf dem sie benutzt werden sollen. Im Gegensatz dazu sind JDBC-Treiber sofort ablauffähig. Ihre Installation ist somit kostengünstiger und kann nach Bedarf erfolgen.
Was bedeutet dies für unser Intranet? Da der Web-Server über ein bestimmtes Protokoll mit dem Datenbankserver kommuniziert, müssen beide Seiten dieses Protokoll verstehen, oder der Web-Server verwendet ODBC beziehungsweise JDBC, um protokollunabhängig zu bleiben. Beim Einsatz von ODBC oder JDBC wiederum ist zu berücksichtigen, daß man sich dabei unter Umständen Performance-Nachteile einhandeln kann - abhängig vom Datenbanksystem und den verwendeten Treibern.
Wir haben uns damit beschäftigt, wie der Datenbank-Server und der Web-Server Daten miteinander austauschen. Doch wie kommen die Daten aus Sicht des Web-Servers vom und zum Client? Die Kommunikation zwischen Web-Server und Browser erfolgt in der Regel über das Verbindungsprotokoll HTTP und die Seitenbeschreibungssprache HTML. Das heißt, der Web-Server muß die Daten in HTML umsetzen, damit sie der Client darstellen kann. Falls der Benutzer die Daten ändern will, so muß es möglich sein, im Browser Eingaben zu machen, diese Eingaben an den Web-Server zurückzuschicken und in der Datenbank zu speichern .
Seiten dynamisch generieren
Für diese Umsetzung gibt es mehrere Möglichkeiten. CGI, das Common Gateway Interface, ist eine ausgereifte Methode, um HTML-Seiten dynamisch zu generieren. Die Seiten sind also nicht statisch als Datei auf dem Web-Server gespeichert, sondern werden von einem Programm auf dem Server bei jedem Zugriff neu erstellt. Jedesmal, wenn die entsprechende Seite mit dem Browser aufgerufen wird, generiert ein Programm die Seite neu. Dieses Programm legt den Inhalt der Seite aktuell fest, fragt also beispielsweise über SQL eine Datenbank ab und bereitet die Daten mit Hilfe der Übersetzung von SQL-Daten in HTML auf. Das CGI-Programm kann mit HTML Formulare erstellen, in die der Benutzer Daten einträgt. Sendet er das Formular an den Web-Server zurück, so werden dem CGI-Programm die Benutzerdaten übergeben; dieses wiederum übermittelt die Daten an die Datenbank.
Der Einsatz von CGI hat einige Vorteile: Jeder Web-Server beherrscht CGI. Es ist also jederzeit möglich, CGI-Programme zwischen Web-Servern verschiedener Hersteller auszutauschen. Weiterhin funktioniert CGI mit beliebigen Web-Browsern, denn der Browser sieht nur den HTML-Code, den das CGI-Programm generiert. Ein weiterer Vorteil ist die enorme Flexibilität von CGI: Man kann die Daten in jeder Form darstellen, die mit HTML möglich ist. Die Verwendung von CGI bringt jedoch auch erhebliche Nachteile mit sich: Für jeden Zugriff auf die Seite muß ein Programm aufgerufen werden. Dies belastet gerade bei häufig abgefragten Seiten den Server erheblich, da jedesmal ein eigener Prozeß gestartet wird, der abhängig von verwendeter Sprache und System unterschiedlich viel Speicher und Prozessorzeit benötigt. Bei der Skriptsprache Perl können Sie beispielsweise von mindestens 1 MByte ausgehen. Darüber hinaus sind CGI-Programme erst einmal zu erstellen - die Web-Administratoren müssen also über Programmierkenntnisse verfügen.
Wegen dieser Nachteile von CGI gibt es auch Alternativen für die Einbettung der Ergebnisse von Datenbankabfragen in HTML, die jedoch abhängig vom verwendeten Web-Server sind. Wir gehen hier auf Lösungen von Microsoft und Netscape ein: Wer seine Datenbank über den Microsoft "Internet Information Server" anspricht, kann mit dem "Internet Database Connector" (IDC) von Microsoft Daten in eine HTML-Seite einfügen, ohne dafür programmieren zu müssen. Jede mit IDC erstellte Web-Seite wird nämlich durch zwei Dateien beschrieben: Die eine enthält eine SQL-Abfrage, die andere Datei besteht aus HTML-Code mit speziellen Variablen, die auf die Datenbank-Felder Bezug nehmen. Bei jedem Zugriff auf die Seite erfolgt die SQL-Abfrage, und die Variablen im HTML-Dokument werden durch die entsprechenden Daten ersetzt. IDC funktioniert nur mit Datenbanken, die sich über ODBC ansprechen lassen und bietet keine Möglichkeit, Daten an die Datenbank zurückzusenden. Auf der anderen Seite hat man damit eine sehr einfache und leistungsfähige Möglichkeit, Daten als HTML-Seiten darzustellen.
Die IDC-Datei in Bild 2 besteht aus normalem HTML-Code, mit Ausnahme des Abschnittes zwischen <%begindetail%> und <%enddetail%>. Diesen Abschnitt setzt IDC in normalen HTML-Code um, indem er für jeden Datensatz der zugehörigen SELECT-Anweisung wiederholt wird und dabei alle Bezüge wie <%Vorname%> durch die entsprechenden Datenbankfelder ersetzt werden. Die Anzeige der obigen IDC-Datei in einem Browser könnte also folgendermaßen aussehen:
Kunden
Andrea Bethel
Max Meyer
Hans von Miller
Die "Active Server Pages" (ASP) sind beim Microsoft Internet Information Server ab Version 3.0 eine interessante Alternative zu CGI: Eine ASP besteht aus HTML-Code, der gemischt werden kann mit Programm-Code in verschiedenen Programmiersprachen. Momentan sind Javascript, Visual Basic Script und Perl möglich. Sobald eine ASP aufgerufen wird, kommt der Programm-Code zur Ausführung. Dieser kann beispielsweise die Verbindung zu einer Datenbank aufbauen und mit den erhaltenen Daten zusätzlichen HTML-Code generieren. Der Vorteil von ASPs ist ihre große Flexibilität: man hat damit ähnliche Möglichkeiten wie bei CGI. Die Performance ist wesentlich besser als bei CGI, da kein externes Programm aufgerufen wird. Nachteile sind eine geringere Performance gegenüber IDC, weil der Programm-Code ausgeführt werden muß, sowie der höhere Aufwand zur Erstellung der ASP: Wie bei CGI sind Active Server Pages zu programmieren.
Die ASP-Datei aus Bild 3 besteht aus normalem HTML-Code, mit Ausnahme jeweils der Abschnitte zwischen <% und %>. Mit <% wird im obigen Beispiel Visual-Basic-Code eingeleitet, mit %> beendet. Ein = nach dem einleitenden <% bewirkt, daß der entsprechende Code-Abschnitt von ASP durch das Ergebnis des Codes ersetzt wird. Die Anzeige der obigen ASP-Datei in einem Browser könnte also folgendermaßen aussehen:
Hallo Jan und Georg!
Bei uns ist es 24.08.97 12:33:24,
"Livewire" von Netscape verfolgt einen ähnlichen Ansatz wie die ASP-Technologie, ist jedoch im Gegensatz dazu ein Produkt, welches zusätzlich zu erwerben ist. Mit Livewire (siehe Bild 4) lassen sich HTML und Programm-Code (derzeit nur Javascript möglich) nach demselben Prinzip wie bei den Active Server Pages mischen. Die mit Livewire erstellen Seiten müssen jedoch anders als ASPs kompiliert werden, was sich zwar geringfügig positiv auf die Performance auswirkt, aber den administrativen Aufwand bei Änderungen erhöht. Mit Hilfe der "Livewire Database Connectivity Library" kann man innerhalb von Livewire-Seiten über Javascript auf Datenbanken von Oracle, Informix und Sybase sowie auf alle ODBC-Datenbanken zugreifen.
Falls innerhalb des Intranets ausschließlich Browser eingesetzt werden, die Java oder ActiveX unterstützen, ist auch ein direkter Zugriff vom Browser auf die Datenbank möglich. Dies ist unter Umständen leistungsfähiger, da der Umweg über den Web-Server vermieden wird. Die spätere Öffnung der Datenbank zum Internet kann aber problematischer werden - immer noch verwenden einige Internet-Teilnehmer Browser, die nicht Java-fähig sind, und ActiveX wird gar nur vom Microsoft Internet Explorer unterstützt.
Für den Zugriff über ActiveX ist ein ActiveX-Steuerelement in den HTML-Code einzubetten. Von Microsoft sind frei erhältliche Steuerelemente verfügbar, mit denen sich HTML-Formulare mit ODBC-Datenbanken verknüpfen lassen. Darüber hinaus ist es möglich, derartige Steuerelemente selbst zu entwickeln. Als Schnittstelle wird üblicherweise ODBC verwendet. Diese Lösung hat jedoch gravierende Nachteile: Erstens muß der verwendete Browser ActiveX unterstützen. Zweitens muß auf jedem Rechner, von dem aus auf die Datenbank zugegriffen werden soll, der entsprechende ODBC-Treiber installiert werden - ein administrativer Aufwand, den man in der Regel nicht auf sich nehmen wird.
Datenbankzugriff
Soll der Zugriff direkt vom Browser aus über Java geschehen, so ist ein Applet, ein Java-Programm, das innerhalb des Browsers abläuft, zu erstellen. Der Datenbankzugriff geschieht typischerweise über JDBC, wobei allerdings berücksichtigt werden sollte, daß JDBC-Treiber momentan noch nicht für alle Systeme und teilweise nicht in ausreichender Performance und Stabilität verfügbar sind. Das Bestechende an dieser Lösung ist jedoch ihre Flexibilität: Java-Applets können von allen modernen Browsern ausgeführt werden, und JDBC-Treiber benötigen keine vorherige Installation. Der direkte Datenbankzugriff über ein Java-Applet kann also eine ernstzunehmende Alternative sein, wenn höchste Performance gefordert wird oder wenn die Art der Daten eine Darstellung in HTML nicht zuläßt. Dank des JDBC-Konzeptes ist auf dem Client-Rechner lediglich ein javafähiger Browser erforderlich. Der Einsatz von ActiveX und ODBC ist jedoch im typischen Intranet in der Regel nicht sinnvoll, da er eine bestimmte Konfiguration des Clients voraussetzt. (gob)
Jan Hermelink
ist Consultant und Entwickler in München
(EMail: Jan.Hermelink@econet.de).
Georg von Stein
betreut Intranet-Projekte bei Kürvers Informationsmanagement und ist als freier Journalist tätig
(EMail: Georg.Stein@ki-team.de).