Den schrittweisen Aufbau einer statistischen Datenbasis hatte sich ein Versicherungsunternehmen zum Ziel gesetzt. Bei der Realisierung des Projekts werden Generierung und Dialog über einen Thesaurus gesteuert. Harald Lucht * schildert die Einzelheiten.

In einer ersten Ausbaustufe des Projekts wurden Versicherungs-spezifische und allgemein volkswirtschaftliche Daten in aggregierter Form zeitreihenweise gespeichert. Unter anderem fanden folgende Bereiche (Zeitreihengruppen) Berücksichtigung:

- Beitragssätze,

- Rechnungsergebnisse und Finanzdaten,

- Versicherten-Daten,

- Wirtschaftsdaten.

Die abgelegten Daten sollten nach den Ausprägungen der verschiedenen Gliederungsebenen (Dimensionen) der jeweiligen Zeitreihe auswertbar beziehungsweise reportfähig sein.

Die Anforderung könnte zum Beispiel lauten: "Erzeuge eine Ausgabe über die Entwicklung der Beitragssätze zur Arbeitslosenversicherung im Zeitraum von 1960 bis 1980!".

Eine komplexere Anforderung wäre: "Erstelle eine Tabelle über Versicherte, getrennt nach Männern und Frauen, im Zeitraum von 1970 bis 1989 für die Bundesländer zum Beispiel Hamburg und Baden-Württemberg einschließlich Summenbildung über die angeforderten Ausprägungen." Selbstverständlich sind passende Überschriften, Quellenvermerke, Fußnoten und Legenden (zum Beispiel Angaben zur Datenqualität) für jede angeforderte Ausgabe zu erzeugen.

Grundlage des Datenretrivals stellt ein Informationssystem dar, das für die Fachabteilungen konzipiert wurde. Die Entwicklungsumgebung besteht aus den Software-AG-Produkten Adabas 4.0 und Natural 2.1 unter BS2000. Die Umstellung auf Adabas 5.0 steht unmittelbar bevor. Die Pilotierung einer ersten unvollständigen Grundausbaustufe begann nach etwa anderthalb Mannjahren Entwicklungsaufwand im Juni 1990. Der Einsatz Endbenutzer-orientierter Werkzeuge war aus hausinternen Gründen nicht möglich.

Aus der Vielfalt der Anfragekombinationen, bedingt durch die stark gegliederte Datenstruktur und die hohen Anforderungen an die Flexibilität des Systems, kam von Anfang an nur ein Generatorkonzept in Betracht. Ein "Ausprogrammieren" hätte unvertretbare Code-Redundanz beziehungsweise eine allgemeine Code-Explosion zur Folge - abgesehen von den negativen Auswirkungen auf Wartbarkeit und Erweiterbarkeit.

Die Bildung von Objekten in Form von Zugriffsklassen war eine hilfreiche Voraussetzung für die Generierung der Programme. Diese unterschiedlichen Grund-Zugriffsmuster mußten die möglichen Varianten der Datenselektion beziehungsweise -projektion entsprechend den Verarbeitungsanforderungen der Nutzer repräsentieren. Über einen formatierten Dialog wird der Anwender in die Lage versetzt, die gewünschte Suchanforderung in komfortabler Weise ergebnisorientiert abzusetzen.

Der Generator wiederum mußte so ausgelegt werden, daß sämtliche über den Dialog formulierbaren Anfragen datenbanktechnisch realisierbar sind und zu sachlogisch richtigen Ergebnissen führen. Bereits hier wurde deutlich, daß die Dialoggestaltung und die Generatorenentwicklung nur im Einklang mit dem Datenbankdesign erfolgen konnten. Darüber hinaus benötigt der Generator die Beschreibung der Datenbank-Strukturdaten, Angaben über die Nutzdaten und deren Beziehungen sowie Informationen zur Ausgabegestaltung.

Erst nach der Konsolidierung des Datenbankmodells sind diese Metadaten als Basisinformationen für einen Informationssystem-typischen Thesaurus eindeutig beschreibbar. Die weitere Modellierung des Thesaurus wird im Laufe der Implementierung an die verfahrenstechnischen Gegebenheiten der Anwendung schrittweise angepaßt (mehrmaliges Redesign).

Im Falle der Thesaurusmodellierung verschmelzen also die Phasen Datenbankdesign und Implementierung des auf den Nutzdaten operierenden Anwendersystems. Als Datenbasis diente eine Adabas-Datenbank, die neben den normalisierten Primärrelationen auch die erwähnten Thesaurus-Daten enthielt. Letztere dienen aus der Dialogsicht im wesentlichen dazu,

- die Suchobjekte zu identifizieren,

- die Masken mit Defaults zu versorgen und

- die Verzweigung während des Anwenderdialogs sicherzustellen.

Aus Generatorsicht ermöglichen die Thesaurus-Daten

- den Zugriff auf die Datenbank (Views, Deskriptoren),

- die Ausgabengestaltung (Header, Trailer, Feldformate) und

- die Gestaltung von Anfrage- oder Zugriffsprofilen für Statistikzwecke.

Aus der zentralen Haltung auch der anwendungstechnischen Daten als Datenbank-Files ergaben sich hinsichtlich der Wartungsfreundlichkeit des Anwendersystems entscheidende Vorteile gegenüber konventioneller Programm-Datenverwaltung. Eine Änderung der Meta-Datenobjekte führt nicht zwangsläufig zu Programmanpassungen, da die Feldwerte, Feldbeschreibungen, Defaults, Formate für Bildschirm- und Druckausgabe etc. ausschließlich zentral in der Datenbank durch autorisierte Systembetreuer gepflegt werden können.

Ergebnisorientierte Bildschirmgestaltung

Im Dialogdesign wurde konsequent der Ansatz des ergebnisorientierten Bildschirmaufbaus verfolgt. Eingabe-abhängig werden dem Anwender nur die Masken vorgeblendet, die seinem Anfrageprofil exakt entsprechen. Die Selektionskriterien für das spezielle Suchobjekt erscheinen konsistenzgeprüft mit Feld-Defaults, die dem aktuellen Wertebereich der Nutzdaten-Ausprägungen entsprechen. Reine Ausgabefelder und Vorbelegungen werden grundsätzlich über den Thesaurus bedient.

Nicht vorbelegte Eingabefelder sind lediglich zu markieren. Auf diese Weise werden Eingabefehler praktisch ausgeschlossen und überflüssige Cursor-Bewegungen eliminiert.

Die Benutzerführung wurde zweigleisig ausgelegt: Der ungeübte Systembenutzer wird Menü-unterstützt über mehrere Hierarachiestufen zum Ergebnis geführt. Fortgeschrittene Anwender gelangen Thesaurusgesteuert über die Eingabe gebräuchlicher Kurzbezeichnungen sowie im Hause verwendeter Begriffe und Konventionen direkt in die Maske mit dem spezifischen Anfrageprofil.

Die Software-technischen Voraussetzungen basieren neben dem oben beschriebenen Thesaurus auch auf bestimmten Features von Natural. Zum Beispiel lassen sich die Ausgaben per Programm den logischen Bestimmungsorten zuordnen. Auch der Source-Bereich des Programmeditors kann als Ausgabemedium angesprochen werden. Die Code-Erzeugung basiert auf dieser Option.

Das auf diese Weise kreierte Programm muß unmittelbar nach Fertigstellung zum Ablauf gelangen. Dies geschieht über einen Stack, der erlaubt, sowohl auszuführende Programme als auch Systemkommandos zwischenzulagern und nach Beendigung des aktiven Programms in der gewünschten Reihenfolge abzuarbeiten.

Eine Alternative dazu wäre die dynamischen Substitution von zur Laufzeit versorgten Variablen, die in der Global-Data-Area (GDA) definiert sein müssen. Diese Möglichkeit erwies sich für die anstehende Problematik als zu unflexibel und als unzureichend verifizierbar.

Thesaurus als Bindeglied

Die Schnittstelle zwischen Dialog und Generator (Vorgabe der "weichen" Suchkriterien durch den Anwender) einerseits und zwischen Generator und Thesaurus (Ablage der "harten" Datenbank-Strukturdaten) andererseits wird durch die GDA realisiert. Die gesamte Programmkommunikation muß über diesen zentralen Bereich abgewickelt werden, da die Daten über mehrere Dialog- beziehungsweise Generierungsschritte zu erhalten sind.

Die Interpretation und Analyse im Vorfeld der eigentlichen Generierung führt zur Identifikation der Zugriffsklasse. Aus der jeweiligen Dialoganfrage muß erkannt werden, welche harten Selektionskriterien (Views, Deskriptoren) in Verbindung mit der schnellsten Zugriffsart (Read/Find) den Zugriff auf die Nutzdaten ermöglichen. Diese Strukturdaten werden durch die weichen Angaben aus dem Anwenderdialog (markierte Ausprägungen der Deskriptoren) in beliebiger Kombination dynamisch komplettiert. Das Bindeglied für eine möglichst intelligente Zusammenführung dieser Informationen zwecks Zugriff und Ausgabegestaltung stellt der Thesaurus dar.

Antwortzeiten unproblematisch

Die Nutzerakzeptanz wird neben den Software-ergonomischen Aspekten im wesentlichen Maße von der Performance beeinflußt. In der ersten Ausbaustufe werden nur zirka 160 000 Datensätze bei einem Platzbedarf von 120 000 PAM-Pages für die gesamte Anwendung gespeichert. Bei diesem begrenzten Datenvolumen und Einzelauskünften, die in der Regel weniger als 1000 Datensätze je Transaktion betreffen, dürfte das Antwortzeitverhalten unproblematisch sein.

Trotzdem wurden für häufige Standardanforderungen geeignete Superdeskriptoren im Datenbank-Design vorgesehen. Sollten sich Engpaßsituationen im Laufe der Pilotierung oder im späteren Produktivbetrieb ergeben, könnten dann gegebenenfalls Tuning-Maßnahmen eingeleitet werden.