Warehouse auf SESAM-Basis - uni-mannheim.de file Warehouse auf SESAM-Basis. Zentraler Punkt des...

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/Server-

Umgebung ü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

I

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

1

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,

2

• 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

3

• 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

4

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

Frischdienst-Distributeure

Statistik - Datenbank

AktionenPreise

Daten

Daten- Transfer

Bestellung Ware Bestellung Ware

fz-Frischdienst-Zentrale GmbH & CoFRZ Rechenzentrum GmbH

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,

5

• 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 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.

6

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.

7

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“.

8

DSS

DSS PC PC

Abbildung 2: Data Warehouse-Struktur

FAKTURA

LOGISTIK

STATISTIK

Selektion, AggregationMetadaten

aggregierte

Daten

Detail-Daten

akt. Periode

Standard-Reports

Administrations-

Ebene

Berichtsebene

InternetAd-hoc Auskunft Downloading

Operative

Ebene

Warehouse-

Ebene

9

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

10

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 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 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:

11

• 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.

12

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.

13

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.

14

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 POSIX-

kompatiblen Umgebungen.

15

Client (PC, UNIX)

Netscape,Mosaic,

Internet Explorer, ...

Intranetoder

Internet

Server (UNIX)

HTTPD

Gateway

BS2000

SESAM/SQL

(Statistik-DB)

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.

16

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-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.

2.2.2 DRIVE / WINDOWS


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.

17

UPICH T T P DG a tew ay in 4G L

a ls O LTP -A nw endung

WWW-Server (SINIX)

UTM / UTM-DS E S A M /S Q LG a tew ay in 4G L

a ls O LTP -A nw endung

DB-Server (BS2000)

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


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.

18

• 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 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.

19

• 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.2000-

Server. DBA übernimmt dabei komplett das Verbindungsmanagement über das Netzwerk zur

Datenbank und führt wie oben beschrieben Anpassungen der SQL-Abfragen durch.

DBA.2000 - ServerSesam / SQL

WWW - Client Internet

WWW - ServerW3 / SQL - Gateway

DBA.X - Client

beliebige Plattform TCP/IP

SinixRDABS2000

Abbildung 5: Szenario mit DBA

20

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.

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.

21

Abbildung 6: FZ-Homepage

Jeder Nutzer des FZ-Data Warehouse muß sich ordnungsgemäß identifizieren. Auf der Login-

Seite 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.

22

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: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.

23

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

24

ä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.

25

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.

26

Sollen noch weitere Restriktionen eingegeben werden oder bestimmte Felder zur Ausgabe aus-

bzw. 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.

27

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.

28

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

29

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 HTML-

Kommandos 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.

30

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/Insert-

Operationen 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.

31

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.

32

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

33

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

34

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.

35

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.

36

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.).

Warehouse auf SESAM-Basis - uni-mannheim.de file Warehouse auf SESAM-Basis. Zentraler Punkt des...

Documents

Transcript of Warehouse auf SESAM-Basis - uni-mannheim.de file Warehouse auf SESAM-Basis. Zentraler Punkt des...