WWW-Data Warehouse auf SESAM-Basis
Werbung
WWW-Data Warehouse auf SESAM-Basis RUM 49 / 96 Alexander Hofer Rechenzentrum Universität Mannheim Wolfgang Müller Frischdienst-Rechenzentrum Hannover Dieser Bericht beschreibt die Aufgabenstellung, Durchführung und die Ergebnisse des Projekts WWW-Data Warehouse auf SESAM-Basis. Zentraler Punkt des Projekts war die Konzeption und Implementierung eines Prototyps für ein Informationssystem der Frischdienst-Zentrale in Hannover, das in einer Client/ServerUmgebung über das World Wide Web den Zugriff auf eine Statistikdatenbank ermöglicht. Partner des Projekts waren: Universität Mannheim Rechenzentrum 68131 Mannheim fz-Frischdienst-Zentrale GmbH & Co Hägenstraße 1 30559 Hannover (Anderten) Siemens Nixdorf Informationssysteme AG Otto-Hahn-Ring 6 81739 München 1 EINLEITUNG 1 1.1 Beschreibung eines Data Warehouse 2 1.2 Data Warehouse im FRZ 3 1.3 Data Warehouse Entwicklung 6 2 DIE ANBINDUNG DES DATA WAREHOUSE AN DAS WWW 14 2.1 Szenario 14 2.2 Evaluierung von SNI-Software 16 2.2.1 SQL-GATEWAY 16 2.2.2 DRIVE / WINDOWS 16 2.2.3 SQL*Connect to SESAM/SQL 17 2.2.4 Database Access Service (DBA) 18 2.3 Implementierung 20 2.3.1 Web-Seiten / Masken 20 2.3.2 Komponenten 29 2.4 Probleme 33 2.5 Ausblick 35 I 1 Einleitung Bill Inmon, „Vater“ des Data Warehouse-Konzepts (Warehouse = Warenlager, Lagerhaus) definiert Data Warehouse als „themenorientierte, zeitlich veränderliche und nicht flüchtige Datensammlung zur Unterstützung von Management-Entscheidungen“. Nun kann der Begriff „Datensammlung“ sowohl die Tätigkeit (Sammeln von Daten) als auch deren Ergebnis (gesammelte Daten) bezeichnen. In der aktuellen Warehouse-Diskussion werden derzeit beide Begrifflichkeiten verwendet: Data Warehouse im Sinne von Ergebnis meist für die Beschreibung eines Datenhaltung-Systems; im Sinne von Tätigkeit als Beschreibung eines ganzheitlichen Geschäftsprozesses und dessen Endprodukt. Daten zur Unterstützung von Management-Entscheidungen zu sammeln ist nun keineswegs neu, sondern wird schon seit längerem mit unterschiedlichen Methoden und vermutlich unterschiedlichem Erfolg praktiziert. Wenn wir es hier also mit einem - salopp gesprochen - „alten Hut“ zu tun haben, stellt sich natürlich die Frage warum gerade heute dieses Thema die aktuelle Diskussion, und das nicht nur innerhalb der IT-Branche, so stark prägt. Während in der Vergangenheit meist versucht wurde, Informations-Systeme auf der Basis transaktionsorientierter (OLTP) Operativ-Systeme zu betreiben, hat sich mittlerweile die Erkenntnis durchgesetzt, daß das analytisch geprägte Warehousing (OLAP) andere, speziell auf diese Tätigkeit zugeschnittene Voraussetzungen braucht. Deshalb geht man zunehmend dazu über, Warehousing auf einer eigens dafür vorgesehenen IT-Ebene mit z.T. eigener Hardware, eigener Datenspeicherung und eigenen Anwender-Tools parallel zu den Operativ-Systemen zu betreiben. Begünstigt wird dieser Trend heute durch • leistungsfähige Hardware - vor allem im Midrange-Bereich, • sinkende Preise bei CPU und Plattenspeicher, • vielfältige LAN/WAN-Verbindungsmöglichkeiten, 1 • die für Analysen optimale Datenaufbereitung in Form von OLAP-Speicherungen. Darüber hinaus stehen zur Auswertung der in einem Warehouse abgelegten Informationen mittlerweile komfortable Tools zur Verfügung, die über Standardfunktionen hinaus in der Regel auch Entwicklungsumgebungen auf der Basis objektorientierter Programmierung für eigene Funktionen anbieten. 1.1 Beschreibung eines Data Warehouse Das Data Warehouse gibt es nicht. Warehouse-Lösungen weisen branchen- und unternehmensspezifische Unterschiede auf und können auch in den betriebswirtschaftlichen Zielsetzungen sowie in der technischen Auslegung erheblich voneinander abweichen. Trotzdem gibt es aber wiederum auch Gemeinsamkeiten, die sich in vielen Warehouse-Lösung mehr oder weniger vollständig wiederfinden. Data Warehouse läßt sich also derzeit nicht als neuer Standard, sondern eher als gemeinsames Dach interpretieren, unter dem sich eine ganze Reihe unterschiedlicher Lösungen angesiedelt haben, die möglicherweise zu gleichen oder ähnlichen Zielen führen sollen. Als Beispiele häufiger gemeinsamer Zielsetzungen von Warehouse - Lösungen ließen sich auf betriebswirtschaftlicher Basis u.a. • Analysen von Umsätzen, Absatzkanälen, Marketingprogrammen, • Analysen der Kunden- und Produkt-Profitabilität, • Einkaufs-, Investitions- und Personal-Controlling, • Ergebnisrechnung, Budgetierung und Risk-Management und als System-Komponenten 2 • hoch aggregierte, schwach aggregierte und Detail-Daten, • Metadaten, • Altdaten, • relationale und/oder OLAP-Datenbanken, • Auswahl- und Verdichtungsprogramme, • Auswertungs-Tools, • Netzwerke anführen. Data Warehouses enthalten viele Bestandteile und werden aus unterschiedlichen Teilen zusammengebaut. Jedes einzelne davon kann - im Prinzip - unter dem Gesichtspunkt optimaler Aufgabenerfüllung separat ausgewählt werden. Da sich Data Warehouse-Prozesse zudem auch oft über verschiedene System- und Hardware-Plattformen hinweg abspielen, gilt auch hier die gleiche Philosophie, Teilprozesse durch die jeweils am besten geeignete Hardware, System- und/oder Anwendungs-Software zu unterstützen. Die Kompatibilität der Komponenten untereinander wird dabei durch Standard-Schnittstellen wie z.B. SQL, ODBC und Netzwerk-Standards wie TCP/IP mittlerweile sehr gut gewährleistet. Unterhalb des Data Warehouse als Abbild des Gesamtunternehmens gibt es noch den Begriff des „Data-Mart“, in dem nur ein oder mehrere Teile des Unternehmens gespiegelt werden. Aus verschiedenen Data-Marts läßt sich wiederum ein Data Warehouse bauen. Dieses Vorgehensmodell bietet den Vorteil, über Prototyping sein Warehouse sukzessive aufzubauen getreu der in Warehouse-Projekten vertretenen Philosophie „Think big, start small“. 1.2 Data Warehouse im FRZ Die Frischdienst-Zentrale (FZ) mit Sitz in Hannover ist ein Zusammenschluß von eigenständigen Frischdienst-Distributeuren, für die sie Marketing-Aktivitäten koordiniert und als IT-Dienstleister 3 auftritt. Das gesellschaftseigene Frischdienst-Rechenzentrum (FRZ) ist für den Betrieb der notwendingen Infrastruktur der Informationstechnologie zuständig und betätigt sich als Servicezentrum, Softwarehaus und Beratungsunternehmen. Die FZ fungiert als Bindeglied zwischen ihren Mitgliedern und deren Lieferanten und Kunden, wobei die Kernbereiche der Unternehmen im Handel mit Lebensmitteln im allgemeinen bzw. mit Frisch- und Tiefkühlwaren im speziellen liegen. Produzent Bestellung Handel Ware Aktionen Preise Bestellung Ware Frischdienst-Distributeure Daten- Transfer fz-Frischdienst-Zentrale GmbH & Co FRZ Rechenzentrum GmbH Daten Statistik - Datenbank Abbildung 1: Waren- und Informationsfluß Typische betriebswirtschaftliche Fragestellungen, die durch Analyse der Warehouse-Daten beantwortet werden sollen, sind sowohl für den FZ Gesellschafter als auch für Produzent und Handel: • Trends und Entwicklungen über Absatz- und Umsatzzahlen, • Marktanteile und Wettbewerbsvergleiche von Produzenten, • Indizes für verschiedene Zeiträume , • Absatz- / Umsatzdaten für den Handel, 4 • Testmarkt-Service durch eine spezifische und zeitnahe Unterstützung bei der Einführung neuer Produkte, • logistische Kennzahlen. Im Rahmen ihrer Geschäftstätigkeit fällt in der FZ-Gruppe eine große Menge Daten an. Aus den 35.000 Filialen und Lieferstellen, die durch die Frischdienst-Distributeure beliefert werden, gehen jeden Tag über 30.000 Aufträge mit je 30 bis 35 Positionen ein. In der Woche sind somit ca. 5,5 Mio Positionen zu fakturieren. 75% der Aufträge gehen per MDE (Mobile Datenerfassung) und 20% per Zentral-DFÜ (Datenfernübertragung) ein. Diese Flut an Informationen ist nur mit leistungsfähiger Datenverarbeitung zu bewältigen. Zu diesem Zweck setzt das FRZ zwei SNI H130-Mainframes in größeren Ausbaustufen ein. Außerdem müssen die Daten gut aufbereitet und anforderungsbezogen in einer StatistikDatenbank abgespeichert werden, damit sie sinnvoll analysiert und interpretiert werden können. Diese Datenbank bildet die Grundlage für ein Data Warehouse, aus dem die Hersteller, der Handel und die Distributeure als Abnehmer des statistischen Materials wie in einem Warenhaus interessante Produkte, d.h. Informationen, auswählen können. Die Roh-Daten entstehen bei den FZ-Gesellschaftern in den Warenwirtschafts-, Logistik- und Vertriebs-Systemen. Sie werden für jeden Gesellschafter individuell nach Art und Umfang, mengen- und wertbezogen in einem Zyklus von einer Woche, Monat oder Jahr verarbeitet und aufbereitet. Somit sind sie Basis für Prognosen und können in ein Management Information System (MIS) eingehen. Der Abnehmer bzw. Mandant ist immer Eigentümer der Daten. Die Aktualisierung der einzelnen Datenreihen in der Statistik-Datenbank ist aufgrund der großen Datenmengen sehr zeitintensiv. 5 1.3 Data Warehouse Entwicklung Auch in der Vergangenheit wurden im FRZ schon die in den operativen Systemen entstandenen Daten für Analysezwecke zur Verfügung gestellt. Das geschah auf die seinerzeit übliche, meist starre und batchorientierte Weise in Form standardisierter Berichte. Die in dieser Zeit entstandenen Systeme waren irgendwann nicht mehr sinnvoll weiterzuentwickeln, so daß nur eine generelle Überarbeitung mit gleichzeitiger Vereinheitlichung der Verfahrens- und Datenstrukturen den veränderten technischen Gegebenheiten und Ansprüchen der Anwender wieder gerecht werden konnte. Zu letzterem sei insbesondere der Wunsch nach größerer Flexibilität, nach Dialogverfügbarkeit und der Einbeziehung logistischer Größen in das Berichtswesen hervorzuheben. Anfang der 90er Jahre fiel im FRZ die Entscheidung, die bisherigen stat. Fortschreibungs-Systeme durch ein neues, einheitliches Verfahren abzulösen. Gemeinsam mit SNI wurde 1991 ein Konzept entwickelt, das die periodische Überführung der aus den Operativ-Systemen gewonnenen Daten anhand individueller Anwender-Vorgaben in ein SESAM-basiertes „Warehouse“ vorsah, und das bis 1993 in einem gemeinsamen Projekt umgesetzt wurde. Dabei sollte der Anwender frei entscheiden können, welcher Art und welchen Umfangs die abgespeicherten statistischen Daten sind und wie lange sie gespeichert bleiben. Als Regulativ für den Umfang der Daten sollten die Kosten dienen. Deshalb mußte der Anwender vom System nach der Abspeicherung Informationen über die Speicherbelegung erhalten. Außerdem sollte er die Verdichtungskriterien, die Auswahlkriterien und die Zeiträume frei definieren können. Die periodisch anfallenden Bewegungsdaten aus den Operativsystemen enthalten die komplette Auftragsposition. Aus diesen Daten sollte über Verdichtung nach den angegebenen Ordnungsbegriffen der einzelnen Vorschriften, „Reihen“ genannt, ein Zeitreihensatz gewonnen werden. Zusätzlich mußten dann Jahres-, Quartals-, Monats- und Wochenwerte gebildet bzw. fortgeschrieben werden. 6 Die Datenbasis sollte in Form eines Ringspeichers gefüllt werden, d.h. für jede Zeitart gibt es eine Maximalzahl von Werten. Zyklisch sollten die aktuellen Reihenzeilen dazugeladen und die alten gelöscht werden. Die Speicherung der Statistikdaten sollte in relationalen Datenbanken (SESAM) erfolgen. Dies hatte den Vorteil, Datenbankfunktionen auch für das Berichtswesen nutzen zu können. Für die Retrievalfunktionen (Dialog) war das hauseigene Datenverwaltungs-Auskunftsystem (OVERDRIVE) vorgesehen. Darüber hinaus sollte auch die Möglichkeit der ebenfalls schon vorhandenen Micro-Mainframe-Connection genutzt werden, d.h. der Anwender konnte sich selektierte Untermengen der Daten auf seinen PC holen und dort PC-Funktionen wie Tabellenkalkulation, List- und Graphik-Funktionen nutzen. Später kamen dann noch eine separate Downloading-Funktion nur für Warehouse-Daten und die - nachfolgend im Detail ausführlich erläuterte - Internet-Anbindung dazu. Außerdem sollte der bisherige Druckoutput mindestens gleichen Inhalts und in gleicher Qualität bei vergleichsweise geringem Verwaltungsaufwand möglich sein. Entsprechende Tools, die sich als Unterstützung geeignet hätten, waren zum damaligen Zeitpunkt am Markt noch kaum vorhanden und so entschied man sich im FRZ für eine Eigenentwicklung. Ein besonderes Problem für die Programmierung ergab sich aus der offenen Verfahrens-Struktur, die eine nahezu unbegrenzte Kombination von Auswahl- und Verdichtungskriterien zuließ. Dieser theoretisch möglichen Vielfalt in Form fest programmierter Abfrage-Routinen Herr zu werden hätte den Rahmen jedes Programms gesprengt. Deshalb wird das Auswahl- und Verdichtungsprogramm dynamisch erst zum Zeitpunkt der Verarbeitung aus den dann aktuellen Anwendervorgaben generiert und zur Ausführung gebracht. Als einheitliche Programmiersprache wurde durchgängig COBOL85 festgelegt. Das gilt auch für die „generierten Programme“. 7 LOGISTIK Operative FAKTURA Ebene STATISTIK Administrations- Detail-Daten DSS akt. Periode Ebene Metadaten Selektion, Aggregation aggregierte Warehouse- Daten Ebene Standard-Reports Ad-hoc Auskunft Downloading Internet Berichtsebene DSS Abbildung 2: Data Warehouse-Struktur 8 PC PC Operative Ebene Hier entstehen die Rohdaten, die nach der Rechnungs-Schreibung um Stammdaten ergänzt und mit Ist-Werten versehen in eine sequentielle Datei als Detail-Daten auf LieferscheinEbene ausgegeben werden. Sie kann je nach Größe des Mandanten bis zu 1,5 Mio. Datensätze (a 500 Byte) in der Woche oder 5-6 Mio. im Monat betragen. Administrations-Ebene Das System wird ausschließlich über Meta-Daten administriert. Dafür stehen dem Anwender Dialogfunktionen zur Verfügung, mit denen er erklärt welche „Reihen“ in welcher Weise gebildet und abgespeichert werden sollen. Dabei muß er Angaben machen, welche Daten aus der Gesamtheit der Bestellpositionen (Detaildaten) selektiert werden sollen, über welche Felder in welcher Hierarchie die Werte verdichtet werden sollen und in welchem Zeitzyklus, wöchentlich, monatlich, quartalsweise oder jährlich die Reihe gebildet und fortgeschrieben werden soll. Eine Reihe kann z.B. für die monatlichen Gesamtumsätze eines Kunden gegliedert nach Artikeln eingerichtet werden, eine andere für den wöchentlichen Gesamtumsatz des Unternehmens gegliedert nach Niederlassungen und eine weitere für die Beobachtung der Absatzmengen ganz bestimmter Artikel z.B bei Neueinführungen während der Einführungsphase. Es liegt in der Hand des Anwenders, die Menge der gespeicherten Daten klein zu halten, indem er möglichst genaue Auswahlkriterien angibt und möglichst sinnvoll verdichtet. Eine Hilfe soll die Speicherumfangsinformation sein, die Auskunft über den belegten Platz und die Kosten gibt. Der Anwender muß bei der Definition noch bestimmen, ab wann die Reihe erstellt werden soll, ob sie nur offline oder auch online gespeichert wird und wieviele Zyklen (Wochen, Monate etc.) sie max. umfassen soll. Die Trennung in Offline- und Online-Bestand erwies sich in Hinblick auf das große Datenvolumen als notwendig. Der Online-Bestand ist die 9 Teilmenge des Gesamt-Bestandes (Offline), die der Anwender im Dialog für AdhocAuskünfte und PC-Weiterbearbeitung vorhalten möchte. Die Änderung vorhandener Reihendefinitionen unterliegt einer Versionsführung, d.h. bei jeder Änderung wird die Version hochgezählt, wenn mit der aktuellen Version bereits Werte gebildet wurden. Insgesamt können 99.999 unterschiedliche Reihendefinitionen hinterlegt werden. Ähnlich der Reihendefinitionen werden vom Anwender auch Druckvorschriften erstellt, die erklären, auf welche Weise eine Reihe als Standard-Report abzubilden ist. Metadaten Zu den Metadaten zählen im Wesentlichen die vom Anwender angelegten ReihenDefinitionen und Druckvorschriften und die vom System eingestellten Speicherumfangsinformationen (Anzahl der aktuell gespeicherten Sätze pro Reihe und Zeitraum, Anzahl gedruckte Seiten und Zeilen pro Vorschrift und Zeitraum). Die Metadaten geben nicht nur dem Anwender Aufschluß über Art und Umfang der im Warehouse gespeicherten Daten, sondern dienen auch den Auswahl- und VerdichtungsProgrammen und den Standard-Reports als Verarbeitungsvorschrift. Warehouse-Ebene Über Batch werden im Wochen- und Monatsrhytmus jeweils nach Faktura die neuen Detaildaten lt. Anweisung (Reihendefinitionen) selektiert und aggregiert und in das Warehouse eingearbeitet. Danach steht der komplette, aktualisierte Warehouse-Bestand bis zur nächsten Verarbeitung für Auswertungen zur Verfügung. Die Speicherung der Warehouse-Daten erfolgt nach den vom Anwender vorgegebenen Reihendefinitionen individuell strukturiert: 10 • in zeitlichen Strukturen: - Woche, Monat, Quartal oder Jahr • in organisatorischen Strukturen: - Waren / Artikeln (z.B. gesamtes Produktspektrum, Sortimente, Warengruppen oder einzelne Artikel) - Produzenten bzw. Lieferanten - FZ-Partner und deren Niederlassungen - Kunden (Einzelhändler-Strukturen bis zum Outlet) - geographische Aspekte • in kaufmännischen Größen: - Mengen, Werte, Indizes, usw. • in logistischen Größen: - z.B. Kolli, Tonnage, Volumen, etc. Jeder im Warehouse abgelegte Satz bekommt einen eindeutigen Schlüssel, der sich aus Reihen-Nr., Version, Reihen-Zeile (gebildet aus den Inhalten der als Verdichtungshierarchie vom Anwender genannten Felder) und Zeitraum ergibt und über den er identifiziert werden kann. Prinzipiell lassen sich auch die Detail-Daten der Warehouse-Ebene zurechnen, da auch sie mit speziell auf diese Struktur ausgerichteten Reports individuell und „Zeitpunkt“-bezogen - zusätzlich zu der „Zeitraum“-bezogenen Darstellung der aggregierten Daten ausgewertet werden können. Des weiteren sind auf dieser Ebene auch bilaterale Formate zu erwähnen, die zur Übermittlung von Detaildaten per Datenträger oder DFÜ bedient werden. 11 Berichtsebene Für die Auswertung der aggregierten Warehouse-Daten stehen unterschiedliche Hilfsmittel zur Verfügung. Nach der ursprünglichen Philosophie des Verfahrens, die es dem Anwender ermöglicht, eine Vielzahl von „Ergebnissen“ schon in Form von unterschiedlich verdichteten Reihen anzulegen, schien ein reines Abrufen oder Darstellen dieser Ergebnisse ohne zusätzliche Berechnungsmöglichkeiten erst einmal völlig hinreichend. Deshalb unterstützen die auf der Berichtsebene vorhandenen Tools im Wesentlichen nur Darstellung oder Übernahme der in Reihen abgelegten Ergebnisse. Standard-Reports: Als Standard-Reports werden Batchprogramme eingesetzt, die anhand der in den Metadaten abgelegten Druckvorschriften die im Offline-Bestand gespeicherten Reihen immer direkt nach einem Aktualisierungslauf automatisch drucken. Derzeit kann der Anwender zwischen vier verschiedenen Layout-Formaten wählen. Eine Reihe kann auch auszugsweise und auf höheren Aggregations-Stufen dargestellt werden. Über 40 verschiedene Wert- und Rechenfelder können wahlweise pro angeschriebener Aggregations-Stufe ausgewertet werden. Über den Umfang des Druck-Outputs wird ebenfalls in den Metadaten pro Druckvorschrift und Zeitraum Buch geführt. Adhoc-Auskunft: Hierfür wird ein Drive-Programm eingesetzt, das ursprünglich als offenes AbfrageSystem vor allem in der Stammdatenverwaltung seine Verwendung fand. Es ermöglicht dem Anwender auf der Basis von Tabellen- und Feld-Auswahlen Datenbankinhalte selektiv anzeigen zu lassen. Verknüpfungen mit anderen Tabellen, Summenbildungen und Druck sind ebenfalls möglich. 12 Downloading Für den Import von Warehouse-Daten in PC-Systeme (MS Office) stehen zwei Methoden zur Verfügung: Methode 1 ermöglicht es dem Anwender, aus der Adhoc-Auskunft heraus, die gewonnene Datenmenge auf einen PC zu holen. Methode 2 unterstützt mit einem Add-In den Daten-Transfer aus der MS-ExcelOberfläche heraus und bietet als weitere Funktionen den automatischen Aufbau einer EXCEL-Tabelle aus den übernommen Daten und eine Ampelfunktion für die Analyse der Werte. Internet Den Internet-Zugang zum Warehouse stellt eine Applikation sicher, die als Prototyp in einem gemeinsamen Projekt von SNI, Univ. Mannheim und FRZ entwickelt wurde und die als Vorführversion erstmalig auf der INTERCOOL ´96 in Düsseldorf vorgestellt wurde. Die in diesem Projekt gewonnenen Erfahrungen über die Kombination bewährter mit innovativer Technologie sind im nachstehenden Kapitel zusammengefaßt. 13 2 Die Anbindung des Data Warehouse an das WWW In den folgenden Abschnitten wird die Konzeption und Implementierung eines Prototyps beschrieben, der über das World Wide Web den Zugriff auf die Statistikdatenbank der FZ ermöglicht. 2.1 Szenario Idee war, den Zugang zu den Statistikdaten bzw. dem FZ-Data Warehouse über das Internet oder ein Intranet zu ermöglichen. Lieferanten, Kunden und die Frischdienst-Zentrale selbst können somit aktuelle Daten in individueller Form abrufen. Dieses System gibt ihnen die Möglichkeit, einen schnellen und einfachen Überblick über Trends im Markt zu bekommen. Neben den anderen erwähnten Wegen der Informationsverteilung können die Daten aus dem Informationsystem leicht in eigene Applikationen übernommen werden. Als Frontend dient dafür ein World Wide WebClient. Aus einer solchen Lösung ergeben sich mehrere Vorteile: • Das World Wide Web ist ein akzeptiertes und allgemein eingeführtes System, das durch seine graphische Oberfläche leicht zu bedienen ist. • Es fallen keine oder nur geringe Lizenzkosten für die Clients an. • Für jede Betriebssystemplattform sind WWW-Browser verfügbar. Dadurch bekommt man maximale Flexibilität beim Einsatz des Systems. Serverseitig harmoniert das WWW-Datenbank Gateway mit jedem WWW-Server auf UNIX-Plattformen oder allgemein in POSIXkompatiblen Umgebungen. 14 Client (PC, UNIX) Netscape, Mosaic, Internet Explorer, ... Intranet oder Internet BS2000 Server (UNIX) HTTPD SESAM/SQL (Statistik-DB) Gateway Abbildung 3: Szenario SESAM/SQL-Anbindung Der Benutzer wählt über die Homepage der Frischdienst-Zentrale den Data Warehouse-Zugang an. Nach ordnungsgemäßer Authentifikation auf Seiten des WWW-Servers kann er über Formulare geführt seine Anfragen absetzen. Ein Gateway (Backend), das von dem WWW-Server aufgerufen wird, übernimmt dabei folgende Aufgaben: • dynamische Generierung der Seiten und Formulare, • aus den Nutzereingaben Queries in SQL-Form (Structured Query Language) erzeugen und diese zur Datenbank weiterleiten, • die Ergebnisse der Datenbankabfrage nach den Nutzervorgaben aufbereiten. Als Ausgabeart der selektierten Daten soll zwischen der Darstellung in Tabellenform, reiner Text, Exportdaten oder Grafik gewählt werden können. Bei diesem Szenario handelt es sich um eine 3-stufige Client/Server-Architektur: die Präsentation erfolgt durch den WWW-Browser, die Applikation, d.h. das Gateway, läuft auf dem UNIXKommunikationsrechner und die Datenhaltung wird durch SESAM/SQL auf dem BS2000-System geleistet. 15 2.2 Evaluierung von SNI-Software In einer Anfangsphase wurden verschiedene Software-Produkte von SNI für die Nutzung im Gateway zum Zugriff auf BS2000 Datenbanken auf deren Eignung hin untersucht: 2.2.1 SQL-GATEWAY • Kurzbeschreibung: Das Produkt SQL-Gateway unterstützt den Anschluß von Query-Windows oder Query-AlphaAnwendungen auf SINIX an SESAM/SQL und UDS/SQL-Datenbanken auf BS2000. Dies umfaßt eine UTM (SINIX) Anwendung, einen Gateway-Client, eine oder mehrere UTM (BS2000) Anwendungen und die BS2000-DB-Server. • Idee: Unter SINIX wird ein Gateway implementiert, das auf QUERY-Alpha aufsetzt bzw. dieses als Client ganz ersetzt. Der Zugriff auf SESAM geschieht über SQL. • Problem: Die Entwicklung des SQL-Gateway wurde von SNI wegen fehlender Marktakzeptanz eingestellt und kann somit keine Grundlage für den Einsatz der Implementierung in der Produktion sein, da es nicht mehr gepflegt und weiterentwickelt wird. 2.2.2 DRIVE / WINDOWS • Kurzbeschreibung: 4GL-Sprache und -Entwicklungsumgebung für die Erstellung portabler OLTP-Anwendungen nach dem Client/Server-Konzept mit einheitlicher Schnittstelle zu den DBMS SESAM, UDS und Informix auf Basis des ISO-SQL-Standards. Drive/Windows ist auf den Plattformen BS2000/OSD, SINIX und MS-Windows verfügbar. • Idee: Implementierung des Gateways in der 4GL-Sprache von Drive/Windows, wobei die UTMUPIC-Schnittstelle in SINIX genutzt wird. 16 WWW-Server (SINIX) G a te w a y in 4 G L a ls O L T P A nw en d u n g HTTPD UPIC DB-Server (BS2000) G a te w a y in 4 G L a ls O L T P A nw en d u n g S E S A M /S Q L UTM / UTM-D Abbildung 4: Szenario UPIC-Anbindung • Problem: Drive/Windows bietet zum Zeitpunkt dieser Untersuchung keine reguläre Möglichkeit, Parameter (z.B. Queries) über die Standard-Eingabe einzulesen. Dies ist aber für die Verwendung der 4GL-Anwendung als Skript, das aus einem Formular heraus aufgerufen wird, unbedingt notwendig. 2.2.3 SQL*Connect to SESAM/SQL • Kurzbeschreibung: Mit SQL*Connect to SESAM/SQL können Anwender mit ORACLE-Produkten auf Daten lesend zugreifen, die in der relationalen Datenbank SESAM/SQL gespeichert sind. Somit können ORACLE Datenbanken auf PC’s und SINIX Systemen mit SESAM/SQL Datenbanken auf einem BS2000-System verbunden werden. Das gilt für alle ORACLE Anwendungen unabhängig davon, ob sie mit SQL*FORMS, SQL*REPORTWRITER oder mit Embedded SQL (z.B. PRO*C oder PRO*COBOL) realisiert sind. Die Auswahl der Daten erfolgt dabei auf der BS2000-Seite, das heißt es werden nur die Netto-Daten (Treffer) über das Netzwerk übertragen. 17 • Idee: Vorhandene und bewährte Oracle-Gateways nutzen, um auf die Statistik-Datenbank unter SESAM/SQL zuzugreifen. • Problem: Es ist nur ein read-only Zugriff möglich, und es entstehen durch den Einsatz zusätzlicher Software (ORACLE DBMS) unnötige Kosten und Performance-Einbußen. 2.2.4 Database Access Service (DBA) Zum Zeitpunkt des Projektbeginns war von SNI nur ein Produkt verfügbar, das die Anbindung der BS2000-Datenbank über einen UNIX-Client und CGI ermöglicht: DBA. • Produktbeschreibung: DBA ermöglicht den Zugriff von MS-Windows und SINIX Anwendungen auf die BS2000/OSD-Datenbanksysteme SESAM/SQL und UDS/SQL sowie ORACLE und INFORMIX unter UNIX über OSI-, TCP/IP-Verbindungen. DBA besteht aus zwei Hauptkomponenten: den DBA-Clients (DBA.D für MS-Windows, DBA.X für SINIX/UNIX) und den DBA-Servern (DBA.X für SINIX/UNIX und DBA.2000 für BS2000). Die Kommunikation zwischen einer Anwendung und DBA erfolgt über die ESQL/C-Schnittstelle. Der DBA-Server nimmt die Anforderungen von den Clientsystemen entgegen, leitet sie an das Datenbanksystem weiter und liefert die Suchergebnisse an den Client zurück. Basis der Kommunikation ist die deklarative Datenbanksprache SQL. Der Server paßt dabei die SQLAnweisung an den SQL-Dialekt des Datenbanksystems an. Dadurch kann ein DBA-Client ohne Änderung mit jedem DB-System kommunizieren, für das ein DBA-Server vorhanden ist. Es können gleichzeitig mehrere Verbindungen zu unterschiedlichen DB-Systemen aufgebaut werden. • Idee: Mit der DBA.X Entwicklerversion wird das Gateway implementiert. 18 • Bewertung: DBA bietet eine Schnittstelle für mehrere Datenbanksysteme, wobei keine zusätzlichen DBConnectivity-Produkte benötigt werden. Zusätzlich ist eine einheitliche SQL-Syntax vorhanden, wobei Norm-SQL-Funktionen, die dem DB-System fehlen, teilweise nachgebildet werden. Die ESQL/C-Schnittstelle erlaubt die Verwendung statischer und dynamischer SQL-Anweisungen im Rahmen von SQL ISO 9075:1989(E) mit Erweiterungen (z.B. dynamische SQL) aus ISO 9075:1992 (SQL2) und den X/Open XPG4 Vorschlägen. Durch ESQL/C ist es problemlos möglich, Anwendungen als CGI-Skript oder als Teil eines CGI-Skriptes zum Datenbankzugriff zu erstellen. DBA stellt somit im Vergleich zu den vorhergehenden Produkten die allgemeinere Lösung dar, weil die DBA-Clients, aber auch die DBA-Server als Schnittstelle zur Datenbank für verschiedene Plattformen verfügbar sind. Durch den Einsatz von DBA ergibt sich folgendes Szenario: Das Gateway setzt auf einer mit ESQL/C implementierten Datenbankschnittstelle auf und kommuniziert über den DBA.X-Client per RDA (Remote Database Access) mit dem DBA.2000Server. DBA übernimmt dabei komplett das Verbindungsmanagement über das Netzwerk zur Datenbank und führt wie oben beschrieben Anpassungen der SQL-Abfragen durch. beliebige Plattform TCP/IP WWW - Client Internet DBA.2000 - Server Sesam / SQL WWW - Server W3 / SQL - Gateway DBA.X - Client BS2000 RDA Abbildung 5: Szenario mit DBA 19 Sinix 2.3 Implementierung Im Rahmen dieses Projekts war nun ein Prototyp zu erstellen, der das beschriebene Szenario mit den Produkten SESAM/SQL und DBA umsetzt. Hardwareseitig standen dazu im Rechenzentrum der Universität Mannheim ein BS2000-Rechner vom Typ H60-F2 mit einem Prozessor und 32 MB Hauptspeicher und eine SINIX Workstation RM600 zur Verfügung. Da der Mainframe seit längerer Zeit nicht mehr im Benutzerbetrieb ist, mußten zahlreiche Betriebssystemkomponenten durch aktuelle Versionen ersetzt werden. Da sich die Auswahl, Lieferung und Konfiguration der benötigten Software verzögerte, hat sich das Rechenzentrum pragmatisch für eine Abwandlung der Teststellung entschieden. Um schnell zu einem funktionsfähigen Prototypen für das FRZ zu kommen, sieht das veränderte Szenario nun vor, statt SESAM/SQL auf BS2000 die Shareware Datenbank mSQL auf einer SGI IndyWorkstation zur Speicherung der Statistikdaten zu nutzen. Gleichzeitig wird auf diesem Rechner der WWW-Server betrieben. Von der Konzeption her macht es für das modular aufgebaute Gateway keinen Unterschied, ob die Datenbank lokal oder über das Netzwerk auf einem entfernten Rechner läuft. Nach der Implementierung der vom FRZ geforderten Funktionalität erfolgt nun in der nächsten Phase die Umsetzung mit DBA und SESAM/SQL. Im folgenden wird das Ergebnis der Implementierung dargestellt, d.h. die statischen und dynamischen WWW-Seiten wie sie der Demo-Benutzer Strothmann angezeigt bekommt. Dabei werden schon grundlegende Funktionen der Programmierung angesprochen. Danach werden spezielle Aspekte der Implementierung der beiden Komponenten des Informationssystem erläutert. 2.3.1 Web-Seiten / Masken Da die Frischdient-Zentrale bisher noch keinen Internet-Anschluß zur Verfügung hat und auch im Intranet noch kein Informationssystem auf der Basis der World Wide Web aufgebaut ist, wurde eine minimale Homepage zu Präsentationszwecken erstellt. Von dort aus kommt man über einen Hypertextlink zu der Einstiegsseite des Informationssystems. 20 Abbildung 6: FZ-Homepage Jeder Nutzer des FZ-Data Warehouse muß sich ordnungsgemäß identifizieren. Auf der LoginSeite ist deshalb ein Formular, in das der Benutzer-Name und das Kennwort eingetragen werden. Mit dem Abschicken dieser Seite wird eine Verbindung zur Datenbank aufgebaut, um die Eingaben mit den Werten einer Paßwort-Tabelle abzugleichen. Bei dem Feld für die Kennung sind durch JavaScript-Routinen Konsistenzprüfungen hinterlegt, die im Fall, daß eine Eingabe nicht einem fest definierten Format genügt, dies mit einer Fehlermeldung quittieren und das Abschicken des Formulars unterbinden. Somit werden auch unnötige Datenbankanfragen vermieden. 21 Abbildung 7: Login FZ-Data Warehouse Alle Login-Versuche werden protokolliert. Die Protokolleinträge enthalten das Datum, den Rechnernamen und die IP-Nummer, von der die Aktion ausging, und eine Statusinformation, ob die Identifikation erfolgreich war. Falls ein Nutzer seinen Request über einen Proxy geschickt hat oder er sein System mit fremden IP-Nummern konfiguriert hat, sind die protokollierten Informationen allerdings nur wenig aussagekräftig. +-------+------------+------------+---------------------------+----------------------------------------------------------------------------------+ | KDNR | DATE | TIME | STATUS | DIV | +-------+------------+------------+---------------------------+----------------------------------------------------------------------------------+ | 95340 | 1996/07/04 | 20:04:29 | LOGIN OK | impact.uni-mannheim.de (134.155.50.209) | | 95340 | 1996/07/04 | 20:04:46 | Access denied | impact.uni-mannheim.de (134.155.50.209) | | 95340 | 1996/07/04 | 20:05:05 | LOGIN OK | impact.uni-mannheim.de (134.155.50.209) | | 95340 | 1996/07/04 | 20:08:48 | LOGIN OK | impact.uni-mannheim.de (134.155.50.209) | | 95340 | 1996/07/04 | 20:08:54 | LOGIN OK | impact.uni-mannheim.de (134.155.50.209) | | 99999 | 1996/07/04 | 20:09:11 | LOGIN OK | impact.uni-mannheim.de (134.155.50.209) | | 99999 | 1996/07/04 | 20:10:16 | LOGIN OK | impact.uni-mannheim.de (134.155.50.209) | | 95340 | 1996/07/04 | 20:10:27 | Access denied Abbildung 8: Zugriffsprotokoll Bei einer erfolgreichen Anmeldung am System wird der Data Warehouse-Benutzer mit der Begrüßungsseite des Informationssystems konfrontiert. Zur Bestätigung wird sein Firmenname und seine Benutzerkennung angezeigt. Bei dem Prototyp dient bis auf weiteres die Lieferantennummer als Kennung. 22 Abbildung 9: Auswahlmenü In dieser Version wurde auch ein kleines News-System implementiert. Der Benutzer sieht bei dieser Seite alle Nachrichten, die seit seinem letzten Einloggen neu und bisher noch nicht verfallen sind. Über diese Funktion kann der Betreiber des Warehouse einzelnen oder allen Usern aktuelle Nachrichten zukommen lassen. Des weiteren wird dann eine Auswahl der individuell für Kunden oder Lieferanten erstellten Auswertungen angezeigt. Jeder bekommt seine Datenreihen angezeigt, aber auch Informationen, die für alle freigegeben wurden. Es sei an dieser Stelle darauf hingewiesen, daß Datenschutz bei dieser Anwendung eine besondere Rolle spielt, da manche Benutzer dieses Informationssystems direkte Konkurrenten im Markt sind und deshalb Informationen über Produkte und Regionen 23 äußerst sensitiv sind. Nur die Frischdienst Zentrale ist befugt, alle Nachrichten zu lesen und alle Datenreihen zu verarbeiten. Zu jedem Objekt resp. Reihe wird die Nummer und eine Kurzbeschreibung, die die zugrundeliegenden Auswertungskriterien angibt, angezeigt. Man kann über Buttons entweder ausführlichere Informationen oder die Daten einer Reihe anzeigen lassen. Abbildung 10: Reihenbeschreibungen Als Beschreibungen werden detaillierte Angaben über die Reihendefinition, Auswahlangaben einer Reihe und die Verdichtungsfelder aufgeführt. 24 Abbildung 11: Ausgabeoptionen Wählt man die Werteausgabe an, erscheinen Formulare, in denen verschiedene Einstellungen für die Selektion und Ausgabeform der Informationen gewählt werden können. Da jeder Datenreihe als Dimension die Zeit zugrundeliegt, kann man deren Auswahl auf ein Intervall beschränken. Weiterhin sind neben der Selektion der Verdichtungsstufen mehrere Ausgabearten vorgesehen: (HTML-) Tabellen, reiner Text, Exportformat oder Grafik (ist im Prototyp noch nicht verfügbar). Im nächsten Feld ist die Anzahl der jeweils auf einer Bildschirmseite anzuzeigenden Anzahl an Datensätzen zu wählen. Der Vorgabenwert von fünf Datensätzen kann gelöscht werden, um alle Sätze einer Abfrage zusammen anzuzeigen. 25 Sollen noch weitere Restriktionen eingegeben werden oder bestimmte Felder zur Ausgabe ausbzw. abgewählt werden, kann man über den Button Optionen in eine entsprechende Maske springen. Dort sind in Abhängigkeit des Verdichtungsformats der ausgewählten Reihe bestimmte Felder vorselektiert. Abbildung 12: Optionen Zur näheren Erklärung der Feldkürzel kann von hier aus eine Hilfeseite mit Feldbeschreibungen aufgerufen werden. 26 Abbildung 13: Feldbeschreibungen Hat man Tabelle als Ausgabeart gewählt, werden alle bzw. nur die selektierten Felder ausgegeben. Um lange Wartezeiten beim Aufbau der HTML-Tabellen zu vermeiden, werden standardmäßig immer nur die nächsten fünf Datensätze angezeigt. Mit einem Button kann der Benutzer zu den in der Datenbank folgenden fünf Datensätzen bis hin zum Ende durchblättern. Eine andere Möglichkeit ist der Rücksprung zur Seite mit den Ausgabeoptionen. 27 Abbildung 14: Ausgabe der Datenreihen im Tabellenformat Falls man eine größere Anzahl von Sätzen (> 500) auf einmal anschauen will oder der Arbeitsplatzrechner weniger leistungsfähig ist, sollte man die Textform als Darstellungsart wählen. HTML-Tabellen mit vielen Zeilen und Spalten sind sehr speicherintensiv. Computer mit nur geringem Speicherausbau können u.U. solche Tabellen nicht bewältigen und deshalb Fehlfunktionen hervorrufen. In der Textdarstellung treten diese Probleme nicht auf; man kann sich hierbei durchaus immer alle Sätze auf einer Seite anzeigen lassen. Abbildung 15: Textformat 28 Eine andere Möglichkeit ist die Ausgabe der Daten getrennt durch ein Semikolon. Diese Präsentation dient dem Import in Programme wie bspw. Excel, wo eine individuelle Auswertung und Aufbereitung mit evtl. bereits vorhandenen Makros stattfinden kann. Hier bietet sich an, alle Sätze in einer Seite abzurufen, um dann im Browser (z.B. Netscape Navigator) über den Menüpunkt Save As den Seiteninhalt abzuspeichern. Nun müssen lediglich mit einem Editor einige Formatbefehle von HTML am Anfang und am Ende entfernt werden. Bei Microsoft Excel kann man wählen ab welcher Zeile der Datenimport beginnen soll, womit die führenden HTMLKommandos bequem übersprungen werden können. Bei den meisten Datenbank- und Tabellenverarbeitungsprogrammen kann das Trennzeichen der einzelnen Datenspalten vorgegeben werden. Somit wird dann jeder Datensatz in eine neue Zeile und jedes Feld in eine eigene Spalte eingelesen. Abbildung 16: Exportformat In dem Prototyp wurde beim Layout und der Benutzerführung ausschließlich auf Funktionalität geachtet. Um die Übersichtlichkeit und Ergonomie zu erhöhen sind neben neuen Features Verbesserungen in den folgenden Versionen vorgesehen. 2.3.2 Komponenten Die Implementierung des Informationssystems besteht aus zwei Hauptkomponenten: einem WWW-SQL-Gateway, das die HTML-Seiten in Abhängigkeit der Benutzereingaben dynamisch erzeugt und die Datenbankschnittstelle, die die vom Gateway übergebenen Operationen auf der Datenbank ausführt und die Ergebnisse in Rohform an das Gateway zurückliefert. 29 2.3.2.1 Datenbankschnittstelle Die Datenbankschnittstelle wurde in der Sprache C implementiert, um die C-API von mSQL zu nutzen und diese später leicht durch das ESQL/C Interface von DBA austauschen zu können. Dieses Modul ist in seiner Implementierung abhängig von der jeweils verwendeten Datenbank, wobei beim Einsatz von DBA an dieser Stelle nur minimale Änderungen notwendig sind, um z.B. statt SESAM/SQL auf BS2000, INFORMIX oder ORACLE auf einem SINIX-Server zu nutzen Die Konzeption des Interface erlaubt es, daß beliebige Applikationen darauf aufsetzen können, um Zugriff auf die dahinterliegende Datenbank zu erhalten. Alle für eine DB-Operation notwendigen Parameter werden beim Aufruf des C-Programms vom Gateway übergeben: • Datenbankname: Auswahl der Datenbank, in der Tabellen angesprochen werden sollen • Tabellenname: Für die Ausgabe der Feldnamen einer Tabelle oder zur Ermittlung der Feldtypen ist die explizite Übergabe eines Tabellennamens vorgesehen. • Operationscode: Das DB-Interface unterstützt verschiedene Funktionen, die durch den Operationscode angestoßen werden. Es können alle verfügbaren Datenbanken, Tabellen einer Datenbank, Feldnamen bzw. Feldtypen einer Tabelle ausgegeben werden und Abfragen oder Update/InsertOperationen ausgeführt werden. • nächster zu lesender Datensatz: Hiermit wird der Cursor in einer Tabelle auf einen vorgegebenen Datensatz bewegt. • Anzahl der zu lesenden Datensätze: Falls nur eine beschränkte Anzahl von Sätzen ausgegeben werden soll, kann dies hier festgelegt werden. • auszuführendes Datenbank-Kommando: Mit diesem Parameter wird die auszuführende DB-Operation übergeben, z.B. ein Select- oder Update-Befehl in der üblichen SQL-Notation. 30 Die Ergebnisse werden in die Standardausgabe geschrieben. Bei Queries ist die Ausgabe wie folgt aufgebaut: Anzahl der selektierten Felder Feldname1; Feldname2; Feldname3; ... Anzahl der selektierten Datensätze Datensatz1 Datensatz2 Datensatz3 . . Bei den Datensätzen werden nur für die gewählten Felder die Werte getrennt durch ein Semikolon ausgegeben. Die Ergebnisse werden vom Gateway über die Standardeingabe eingelesen und weiterverarbeitet. Bei jedem Datenbank-Request des Gateways wird das Interface gestartet, baut eine Verbindung zum DBS auf und nach Beendigung der Operation wieder ab. Danach terminiert das Interface wieder. Bei einfachen Anfragen im lokalen Netz, bei denen die Leistungsanforderungen an die Datenbank gering sind und die Netz-Bandbreite keine Rolle spielt, kann gerade der Verbindungsauf- und abbau zum Flaschenhals werden. Ein Ausweg wäre ein DB-Handler, der die DB-Verbindung während einer Sitzung immer aufrecht erhält. 2.3.2.2 WWW-SQL-Gateway Da die wesentlichen Funktionen des Gateways schon bei der Erläuterung der Benutzerseiten aufgezeigt wurden, soll im folgenden nur auf spezielle Implementierungsaspekte eingegangen werden. 31 Das WWW-SQL-Gateway ist im Gegensatz zur Datenbankschnittstelle in PERL programmiert. In einer ersten Version wurde es allerdings mit C realisiert, was sich aber später als zu unhandlich erwies (v.a. bei der Stringverarbeitung). Zusätzlich gab es Probleme mit der Portabilität zwischen Linux- und Silicon Graphics-Plattformen, auf denen die Komponenten getestet wurden. Das Gateway wird aus den Formularen heraus aufgerufen und bekommt über die POST-Methode die Daten aus den Formularen in stdin übergeben. Die Daten werden über die Prozedur CGI_parse interpretiert, d.h. für jedes Feld im Formular wird eine entsprechende Variable definiert, deren Wert der Benutzereingabe bzw. dem Default-Wert entspricht. Bei der Wertzuweisung wird gleichzeitig überprüft, ob der Benutzer versucht hat, durch Manipulation über das CGI Betriebssystemkommandos abzusetzten. Mit jeder HTML-Seite bzw. Maske wird durch versteckte Eingabefelder des Formulars eine Stufennummer übermittelt. Diese dient dem Gateway zur Erkennung der nächsten zu generierenden Seite. Die Login-Seite des Data Warehouse hat die Stufe null, die Einstiegsseite mit der Datenreihenauswahl die Stufe eins, usw. In der Stufe 0, d.h. nach dem Abschicken der Benutzer-Kennung und des Paßworts, wird, wie schon bei den Masken kurz angesprochen, ein Abgleich der Nutzerdaten durchgeführt. Jeder Login-Versuch, egal ob erfolgreich oder nicht, wird protokolliert. Dieses Aufzeichnen sicherheitsrelevanter Systemereignisse in Logdateien nennt man Auditing und die elementare Informationseinheiten (Einträge der Tabelle) werden als Audit Records bezeichnet. Somit kann man immer nachvollziehen wer wann versucht hat sich von einem bestimmten Rechner aus im System anzumelden. Ab der Einstiegsseite, Stufe 1, gibt es neben der Stufennummer weitere persistente Informationen, die zur jeweils nächsten Seite, d.h. für den nächsten Aufruf des Gateways, gesichert werden müssen. Das Speichern von Zustandsinformationen geschieht ausschließlich im Client und zwar in verstecken Feldern der Formulare. So müssen z.B. beim Wechsel von der Stufe 1 zur Stufe 2, der 32 Seite mit den Ausgabeoptionen und Restriktionen, zusätzlich die Reihennummer und die Benutzerkennung übernommen werden. In die Seite zur Anzeige der Werte und beim Blättern in den Werten wird zusätzlich noch die Nummer des nächsten anzuzeigenden Datensatzes gerettet. Zum Zweck der Modularisierung wurden einige Funktionen in Prozeduren innerhalb des Gateways ausgelagert: • Date_Time: liest die aktuelle Uhrzeit und Datum aus und speichert es in geeigneten Datenstrukturen • html_header und html_footer: Ausgabe des Dokumententitels und evtl. Debugging-Informationen am Seitenende • fields und rows: Anzahl der selektierten Felder / Datensätze zusammen mit den Feldnamen / Werten von der Datenbankschnittstelle übernehmen • dbx: die Parameter Datenbankname, Tabellenname, Operationscode, nächste Datensatznummer, Anzahl der auszugebenden Datensätze und das DB-Kommando an die Datenbankschnittstelle übergeben 2.4 Probleme Durch das veränderte Szenario und die Tatsache, daß es sich bei dieser Implementierung nur um einen Prototyp handelt, der die Möglichkeiten für eine Datenbankanbindung an das World Wide Web in einer vorgegebenen Client/Server-Umgebung aufzeigt, ergeben sich einige Probleme, die durch weitere Entwicklungen leicht behoben werden können. Dafür bildet die vorliegende Implementierung eine gute Grundlage. mSQL unterstützt in der aktuellen Version (V 1.0.16) nur eine Untermenge von SQL89. Wichtige Elemente wie die Gruppierung oder Summenfunktion bei SELECT sind nicht vorhanden und werden erst in der Version 2.0 verfügbar sein. Bei Joins, die über mehrere Tabellen gehen, sinkt 33 die Performance auf ein nicht mehr für einen Einsatz im Produktionsbetrieb akzeptables Niveau. Bei dieser wenig ressourcenschonenden Ausführung werden zudem temporäre Dateien angelegt, die leicht mehrere hundert Megabyte umfassen können. Es besteht somit die Gefahr, daß das Dateisystem „überläuft“. Der Datenimport stellt ein zusätzliches Problem dar. Von der Statistikdaten wurde zu Testzwecken ein Snapshot erstellt, der nur unter großem Zeitaufwand in mSQL eingelesen werden konnte, trotz einer halbautomatisierten Vorgehensweise. Es mußten z.B. verschiedene Sonderzeichen umgewandelt oder aus dem Datenbestand ersatzlos gelöscht werden, um einen fehlerlosen Betrieb von der Datenbank gewährleisten zu können. Die Nutzung von JavaScript oder Java, um Anwedungslogik wie z.B. Konsistenzprüfungen in Richtung Client zu verlagen, hat neben den schon erwähnten Vorteilen auch einige Nachteile. Grundsätzlich schränkt man damit den Benutzerkreis ein, da zum Zeitpunkt dieses Berichts bei weitem nicht alle verbreiteten Browser Java/JavaScript unterstützen. Bei dem Anmeldevorgang zum FZ-Data Warehouse kommt dieses Problem allerdings nicht zum Tragen, daß solche Browser die Programmierung einfach ignorieren. Die JavaScripte sind von HTML-Kommentar-Tags umgeben, so daß sie nicht interpretiert werden. Alle Seiten des Informationssystems, außer der Login-Seite, werden durch das Gateway dynamisch erzeugt. In der Regel kann man bei einem WWW-Browser mit den FORWARD- und BACK-Buttons zwischen den in einer Sitzung besuchten Seiten hin- und herblättern. Einige Browser springen dabei jedoch zu der letzten statischen Seite zurück, konkret zur der Einstiegsseite, bei der sich der Benutzer identifizieren muß. Ein ähnlicher Effekt kann auftreten, wenn der lokale Cache-Speicher des Clients zu klein eingestellt ist. Um mit größtmöglicher Sicherheit gewährleisten zu können, daß kein Nutzer durch Manipulation unbefugt auf Daten anderer Benutzer zugreifen kann, sollte bei jedem Datenbankzugriff ein erneuter Abgleich der Nutzerdaten mit der Paßwortdatenbank erfolgen. Durch die zusätzlichen Abfragen entsteht ein zwar ein gewisser Overhead, der aber durchaus notwendig scheint. 34 2.5 Ausblick Aufbauend auf dem Prototyp sind in den nachfolgenden Versionen zahlreiche Verbesserungen und Erweiterungen möglich. In einem ersten Schritt ist mSQL durch DBA und SESAM/SQL auszutauschen, wie es in dem ursprünglichen Szenario dargestellt wurde. Damit steht eine leistungsfähige Datenbank zur Verfügung, und zudem entfällt die Problematik des Datenimports. DRIVE/WINDOWS und SESAM/SQL bieten gute Tools zum Abfragen und Pflegen von Datenbanken. Trotzdem ist es durchaus sinnvoll, auch die Administration des Informationssystems zusammen mit den Benutzerfunktionen unter der WWW-Oberfläche zu vereinen. Dazu gehören die Verwaltung der News-Area, des Auditing und der Tabelle für die Freischaltung der Datenreihen. Somit kann das System von jeder Rechnerplattform aus benutzt und gepflegt werden. Zur weiteren Entkopplung der Module und vereinfachten Konfiguration für verschiedene Anwendungszwecke können Layout-Schablonen eingeführt werden. Diese ermöglichen das Abändern des Erscheinungsbildes der HTML-Seiten, in dem sie von dem Gateway zur Generierung der dynamischen Seiten genutzt werden. In der aktuellen Implementierung beinhaltet das Gateway sowohl die Anwendungslogik als auch die Präsentation der Datenbankergebnisse. Falls in Zukunft mehrere Tabellen immer wieder benutzt werden sollen indem man zwischen ihnen navigieren will, bietet sich an, die Relationen und Entities in einem Graphen abzuspeichern. Die Entities sind dabei die Knoten und die Relationen werden als Kanten dargestellt. Somit ist der Zusammenhang der Tabellen eindeutig erfaßt und kann für die Gestaltung der Benutzeroberfläche beliebiger Anwendungen als Grundlage dienen. Falls man später einmal das Gateway in Java implementieren will, kann man die Datenbankschnittstelle durch einen JDBC-Treiber ersetzen. Allerdings ist eher unwahrscheinlich, daß SNI solch einen Treiber für SESAM/SQL selbst anbieten wird. Da die Spezifikation von JDBC frei zugänglich ist, sind alle Informationen vorhanden, um einen JDBC-Treiber für SNI Datenbanken selbst zu implementieren. 35 Schon jetzt ist über das Internet eine große Anzahl von Java-Applets, die das einfache Erzeugen von Präsentationsgrafiken zulassen, erhältlich. Durch Parameterübergabe der Datenreihe, Legende und Diagramminformationen lassen sich z.B. mit dem Java Applet NetCharts (URL http://www.netcharts.com/) ansprechende Grafiken erzeugen. Somit kann sich der Data Warehouse-Benutzer schnell einen Überblick über aktuelle Entwicklungen verschaffen, ohne daß er die Zahlenkolonnen mühsam interpretieren muß oder die Daten über die Exportdarstellung in sein eigenes Präsentationsprogramm einlesen muß, um sie graphisch aufzubereiten. Ein grundsätzliches Problem ist allerdings dabei die Mehrdimensionalität der Daten (z.B. Zeit, Produktgruppen, Absatzgebiete, Großhändler, etc.). 36
