WWW-Data Warehouse auf SESAM-Basis

Transkript

1 WWW-Data Warehouse auf SESAM-Basis RUM 49 / 96 Alexander Hofer Rechenzentrum Universität Mannheim Wolfgang Müller Frischdienst-Rechenzentrum Hannover

2 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/Server- Umgebung über das World Wide Web den Zugriff auf eine Statistikdatenbank ermöglicht. Partner des Projekts waren: Universität Mannheim Rechenzentrum Mannheim fz-frischdienst-zentrale GmbH & Co Hägenstraße Hannover (Anderten) Siemens Nixdorf Informationssysteme AG Otto-Hahn-Ring München

3 1 EINLEITUNG Beschreibung eines Data Warehouse Data Warehouse im FRZ Data Warehouse Entwicklung 6 2 DIE ANBINDUNG DES DATA WAREHOUSE AN DAS WWW Szenario Evaluierung von SNI-Software SQL-GATEWAY DRIVE / WINDOWS SQL*Connect to SESAM/SQL Database Access Service (DBA) Implementierung Web-Seiten / Masken Komponenten Probleme Ausblick 35 I

4 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

5 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

6 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

7 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 Handel Aktionen Bestellung Ware 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

8 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 Filialen und Lieferstellen, die durch die Frischdienst-Distributeure beliefert werden, gehen jeden Tag über 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 Statistik- Datenbank 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

9 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

10 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

11 LOGISTIK Operative Ebene FAKTURA STATISTIK Ebene DSS Detail-Daten akt. Periode Metadaten Selektion, Aggregation Administrations- Warehouse- Ebene aggregierte Daten Standard-Reports Ad-hoc Auskunft Downloading Internet Berichtsebene DSS PC PC Abbildung 2: Data Warehouse-Struktur 8

12 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 Lieferschein- Ebene 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

13 Teilmenge des Gesamt-Bestandes (Offline), die der Anwender im Dialog für Adhoc- Auskü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 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 Reihen- Definitionen 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 Verdichtungs- Programmen 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

14 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

15 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 Abfrage- System 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

16 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-Excel- Oberflä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

17 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 Web- Client. 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

18 Client (PC, UNIX) Netscape, Mosaic, Internet Explorer,... Intranet oder Internet BS2000 SESAM/SQL (Statistik-DB) Server (UNIX) HTTPD 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 UNIX- Kommunikationsrechner und die Datenhaltung wird durch SESAM/SQL auf dem BS2000-System geleistet. 15

19 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: SQL-GATEWAY Kurzbeschreibung: Das Produkt SQL-Gateway unterstützt den Anschluß von Query-Windows oder Query-Alpha- Anwendungen 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 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 UTM- UPIC-Schnittstelle in SINIX genutzt wird. 16

20 WWW-Server (SINIX) HTTPD Gateway in 4GL als OLTP- Anwendung UPIC DB-Server (BS2000) SESAM/SQL Gateway in 4GL als OLTP- Anwendung 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 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

21 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 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 SQL- Anweisung 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

22 Bewertung: DBA bietet eine Schnittstelle für mehrere Datenbanksysteme, wobei keine zusätzlichen DB- Connectivity-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 Server. 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 Server Sesam / SQL BS2000 RDA WWW - Server W3 / SQL - Gateway DBA.X - Client Sinix Abbildung 5: Szenario mit DBA 19

23 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 Indy- Workstation 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 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