Auf der Grundlage einer vorhandenen Applikation wurde beim folgenden Beispiel zunächst ein konzeptionelles Datenmoder in einem Modellierungsprozeß wiedergewonnen und dieses anschließend in eine DB2-Datenbank überführt. Diese DB-Umgebung gehört zu den ersten umfassenden operationellen DB2-Anwendungen in Europa. Der Anwender arbeitet mit IBM-Hosts unter MVS/XA. Als weitere wichtige Software werden Cobol II, CICS, DBRAD und das Knowledgeware-CASE-Tool IEW verwendet.

Vor der Inangriffnahme des Projekts hatte das Kreditinstitut an zwei mit unterschiedlichen Hardware- und Software-Umgebungen (IBM und Unisys) ausgestatteten RZ-Standorten weitgehend identische Bankanwendungen entwickelt und gefahren. Betriebswirtschaftliche und strategische Gründe bewogen die Bank jedoch, mit einer einer heitlichen, modernisierten Gesamtapplikation operieren zu wollen, die alle Kernbereiche eines modernen Bankbetriebs unterstützen sollte.

Da sich die Bank auf der fachlichen Seite für eine Ausweitung der Funktionen und zugleich auf der technischen Seite für eine Neuausrichtung, auf eine moderne Systemplattform entschied, kam ein herkömmliches Re-Engineering mit Neustrukturierung und Optimierung der vorhandenen Programme nicht in Betracht.

Unternehmensweites Detenmodell wesentlich

Da Bankenanwendungen durchweg informationsorientiert sind, war die Erstellung eines logischen, unternehmensweiten Datenmodells (UDM) ein wesentlicher Teilaspekt der Entwicklungstätigkeiten. Als relativ stabile Ressource sollte dieses UDM die Basis für jetzige und zukünftige Anwendungsentwicklungen sein und in eine physische, relationale DB-Installation überführt werden. Aus wirtschaftlichen Gründen war eine Maßgabe, informationstechnische Daten und funktionale Inhalte der Altanwendungen weitestgehend in der Neukonzeption zu verwenden.

Da nur unzureichende Dokumentationen über die alten Datenstrukturen vorhanden waren, mußte in einer Informationsanalysephase ein konzeptionelles Schema der Altanwendung wiedergewonnen werden.

Verfahren wurde in einem Bottom-up-Ansatz (auch Entity-Synthese genannt), den man mit einem zeitlich versetzt laufenden Top-down-Verfahren kombinierte. Mittels Informationsanalysen der Altanwendungen wurde Bottom up ein konzeptionelles Datenmodell entwickelt und dann aufgrund der Ergebnisse des Top-down-Vorgehens verfeinert und detailliert.

Dadurch konnte man die vorhandenen datentechnischen Informationen der Altsysteme nahezu vollständig nutzen. Daneben ließen sich fachlich übergreifende Zusammenhänge erfassen und unabhängig von technischen Aspekten darstellen. Alle genannten Vorgehensschritte wurden im Rahmen des IBM-Dictionary DBRAD vorgenommen, in dem vier logische Ebenen definiert worden waren.

Die logischen Ebenen (von unten nach oben):

- konzeptionelles Schema lokal:

- Abbild der einzelnen Altanwendungen auf datentechnischer Ebene (Datenstrukturen),

- keinerlei Modifikationen;

- konzeptionelles Schema global:

- Synthese der Datenstrukturen der Altanwendungen,

- bereinigt um Redundanzen auf Feld- und DB/Dateiebene,

- Grobdatenmodell der Altanwendung;

- logisches Datenmodell:

- unternehmensweites, logisches Datenmodell,

- Entities, Attribute, Beziehungen, Domänen, Schlüsselkandidaten, Integritätsregeln, Häufigkeiten;

- physisches Datenmodell:

- physisches Datenmodell mit Berücksichtigung DBMS-spezifischer Kriterien,

- Abbild der gesamten DB2-Datenbank.

Um die alten DB-Strukturen für den Modellierungsvorgang verwendbar zu machen, wurde sie Tool-unterstützt bearbeitet und ausgewertet, und zwar unter Einsatz von DBRAD. Die Importfunktionen des Dictionaries dienten dazu, die Satzdefinitionen 1:1 in die unterste Ebene (siehe Abbildung) zu laden, wobei jedes Altsystem separat abgebildet wurde. Dies sorgte einerseits für die Dokumentation der Altanwendung und ergab andererseits - über die standardmäßig vorhandenen Reportfunktionen und zusätzlich erstellte QMF-Prozeduren die gewünschten Analysemöglichkeiten.

Grobes Datenmodell der Altenwendungen

Somit konnten die Datenmodellierungsspezialisten beispielsweise gleichstrukturierte Altdatenbanken mit unterschiedlichen Namen, Kernentitäten oder auch Datenfeldredundanzen erkennen. Zudem erhielten sie einen Gesamtüberblick über die Daten und deren Beziehungen in den Altanwendungen.

Der nächste Schritt enthielt die Überführung des gewonnenen konzeptionellen Schemas in eine höhere Ebene (siehe Abbildung), ohne daß bereits fachliche Ansprechpartner hinzugezogen worden wären. Zugleich fand eine umfassende Konsolidierung statt, bei der beispielsweise alle Mehrfachvorkommen von Datenfeldern oder DB-Strukturen eliminiert wurden.

Damit lag ein grob strukturiertes Datenmodell der gesamten Altanwendung vor, dessen Informationseinheiten und Beziehungen frühere technische Einflüsse widerspiegelten. Die nachfolgende Vorgehensphase war darauf angelegt, eine Verschmelzung der Erkenntnisse aus der Informationsanalyse (Bottom up) mit den tatsächlich ermittelten fachlich-formalen Beziehungen der Informationsobjekte des Unternehmens herbeizuführen (Top down). Auf dieser Grundlage konnten die Modellierungsspezialisten ein logisches Gesamtdatenmodell des Unternehmens erstellen.

Dies wurde durch systematisch durchgeführte Interviews mit kompetenten Ansprechpartnern erzielt, wobei eine Ermittlung von Entitäten und deren Beziehungen untereinander erfolgte. Dabei stellten die Spezialisten die gegebenen informationstechnischen Zusammenhänge auf einem anfangs hohen Abstraktionslevel (Modellierung der Realität) dar. Gewonnene Erkenntnisse glichen sie ständig mit dem Grobdatenmodell der Informationsanalysephase ab und erweiterten und verfeinerten es.

Die Interviews wurden auch dazu genutzt, Schlüsselkandidaten, Integritätsregeln (RI) und die entsprechenden DELETE-Rules (Restrict, Cascade, Set Null) zu erarbeiten und die Wertebereiche (inklusive Nullwertbelegung) der einzelnen Attribute zu definieren.

Relationen bis zur dritten Normalform

Ergebnis dieser Aktivität war ein unternehmensweites logisches Datenmodell (Entity Relationship), aus dem später auch Projektdatenmodelle entwickelte wurden.

In diesem Zusammenhang wurde auch das CASE-Tool IEW mit seinen Funktionen zur Datenmodellierung eingesetzt. Die in der IEW-Wissensbasis (System-Enzyklopädie) enthaltenen Konstruktionselemente wurden laufend in das Host-Dictionary übertragen und dort um weitere Informationen (R1, DELETE-Rules, Domänen, Häufigkeiten etc.) ergänzt und zum logischen Gesamtdatenmodell zusammengeführt. Vor der Übertragung der IEW-Daten in das Host-Dictionary wurden die Datenstrukturen unter Zuhilfenahme der IEW-Funktionen bis zur, dritten Normalform normalisiert.

Da es sich bei der zu realisierenden Applikation um ein mandantenfähiges System handelte, war eine Übernahme der Altdaten sozusagen portionsweise - in einer einmaligen Übernahmeaktion pro Mandant - möglich. Die Übernahme gestaltete sich durch die Verwendung des Dictionary einfach. Denn durch die Definition von Überleitungsregeln zwischen "Datenfeld alt" und "Datenfeld neu" konnte sichtbar gemacht werden, wie die neuen DB-Strukturen zu füllen waren. Bei komplexen Überleitungsalgorithmen wurde im DBRAD eine Pseudocodebeschreibung hinterlegt. Außerdem ließen die im Dictionary hinterlegten Überleitungsregeln sich direkt als Vorgabe für die Datenübernahme verwenden.

Erster Schritt war eine 1:1-Übernahme des logischen in das physische Datenmodell (DM), was einer Abbildung in der obersten Ebene des Data-Dictionaries entsprach.

Um die Gesamtanwendung mandantenfähig zu machen, war zunächst die Frage zu klären, ob für die einzelnen Mandanten getrennte oder gemeinsame DB-Objekte zu kreieren seien. Das Ergebnis dieser Überlegungen mußte sich dann im physischen DB-Modell niederschlagen. Die Entscheidung fiel unter Gewichtung und Abwägung folgender Kriterien:

- optimales DB-Design,

- Sicherheitsaspekte

- Performance-Gesichtspunkte,

- Verfügbarkeit der Anwendung,

- Anforderungen der DB-Administration,

- Effektivität der Anwendungsentwicklung,

- Endbenutzerservice (QMF, Siron).

Für eine Realisierung von getrennten Datenbanken pro Mandant sprachen vor allem bestmögliche Sicherheit, zu erwartende Performance-Vorteile und hohe Verfügbarkeit. Es wäre damit jedoch eine hohe Anzahl an DB-Objekten und eine aufwendige DB-Administration in Kauf zu nehmen gewesen.

Für die Anwendungsentwicklung schien keine der beiden Alternativen gravierende Vor- oder Nachteil zu bieten. Im Bereich des Endbenutzerservices würden - so die Überlegungen - durch den gewählten Ansatz mandantenübergreifende Auswertungen (SQL-Union notwendig) erschwert, der Zugriffsschutz hingegen optimiert.

Nun war jedoch aus Gründen des Betriebssystems eine reine Implementierung getrennter Objekte je Mandant nicht möglich. Denn bei etwa 100 zukünftigen Mandanten und zirka 90 DB2-Tabellen pro Mandant hätte die Anzahl der insgesamt benötigten "Open Datasets" im Produktionsbetrieb die Maximalzahl der von MVS/XA zu verwaltenden Datasets überschritten.

Deshalb entschieden sich die Verantwortlichen für ein Mandantengruppenkonzept, in dem jeweils mehrere Mandanten zu einer Gruppe zusammengefaßt wurden (Daten mehrerer Mandanten in einer DB2-Tabelle). Dieses Konzept machte ein Mandantenkennzeichen im Schlüssel einer jeden Tabelle erforderlich. Zugriffssicherheit ließ sich in einer solchen DB-Umgebung nur über Gruppenberechtigungen realisierten. Grundsätzlich wurde ein Mandant durch eine Anwendergruppe (im Sicherheitssystem definiert) repräsentiert, an die man die jeweiligen DB2-Berechtigungen (Grants) vergeben hatte.

Von den DB2-Sicherheitseinrichtungen wurde nur in geringem Maße Gebrauch gemacht; Berechtigungen etwa zum Ausführen von DB2-Applikationsplänen erteilte man an die entsprechende Mandanteneinheit. Da innerhalb dieser Anwenderkreise jedoch eine Differenzierung stattfinden mußte, griff man auf Schutzmechanismen des Sicherheitssystems auf Transaktionsebene zurück, kreierte zusätzliche Anmeldeformalismen und vergab Teilberechtigungen ausschließlich für bestimmte Dialogzweige.

Optimale Unabhängigkeit von der DB-Umgebung

Die Projektverantwortlichen hatten im Rahmen der Entwicklung dieser Bankenapplikation stets das Ziel im Auge, eine größtmögliche Unabhängigkeit von der DB-Umgebung und damit eine dementsprechende Wartungsfreundlichkeit Anwendung zu erreichen. Das mehrfache Vorhandensein identischer Zugriffe auf physisch gleiche Tabellen oder Views mit lediglich unterschiedlichen Namen (pro Mandant) im Programmcode sollte vermieden werden.

Diese Vorgabe konnte man durch die, Verwendung von Synonymen, das heißt gleicher Namen -für alle Mandanten pro View, im Programm realisieren. Durch das Binden des DB2-Planes wurde dann über eine Anwendergruppendefinition die Verbindung zu den korrekten DB2-Tabellen hergestellt. Abgesehen von dieser durch das Erfordernis der Mandantenfähigkeit verursachten Problematik impliziert DB2 im Regelfall ohnehin eine relativ starke Losgelöstheit der Anwendung vom DB-Umfeld.

Die Datenbank wurde in Richtung auf eigene DB2-Pläne pro Mandant konzipiert, die sich lediglich durch den Eigentümer (Berechtigten) unterschieden. In der Online-Anwendung (CICS) mußte eine Zuordnung der richtigen DB2-Pläne pro Mandant erfolgen. (Dies ist bei den DB2-Releases 2.1 und 2.2 lediglich durch CICS-Dynamic-Plan-Allocation steuerbar. Ein CICS-Exit-Modul muß aufgrund eines Kennzeichens etwa eines Terminalnummernkreises - den DB2-Plan eines bestimmten Mandanten zuordnen.)

Resultat dieser Art der Planzuordnung ist, daß neue Mandanten ohne Modifikationen in den Anwendungsprogrammen in das System aufgenommen werden können. Dann sind lediglich bestimmte DB-Objekte (Views, Synonyme, Pläne) zu erzeugen; außerdem muß eine Benutzergruppendefinition erfolgen.

Bei mandantenübergreifenden Batch-Anwendungen und den dabei Notwendigen DB2-Planwechseln wird die Call-Attachment-Facility (CAF) des DB2 verwendet. Im Gegensatz zu Online-Anwendungen erfordert diese Technik allerdings Eingriffe in die Batch-Programme, da CAF keine SQL-Returncodes bereitstellt, sondern lediglich Returncodes, die nicht mit SQL-Fehlerroutinen behandelt werden können.

Einen Einblick in das professionelle Vorgehen der Projektverantwortlichen vermittelt unter anderem - der Einsatz des Data-Dictionary DBRAD. Dessen Generatorfunktionen bieten die Möglichkeit, DB-Objekt (DDL und DML) vollautomatisch generieren zu lassen. Diese Funktionen wurden zwar in vollem Maße genutzt, doch wären wegen nicht ausreichender Steuermöglichkeiten des Generators Nachbearbeitungen aller erzeugten Definitionen notwendig geworden.

So hätten DDL-Objekte Änderungen in bezug auf die Mandantenfähigkeit und die Namenskonventionen erfordert. Erst dann hätte das eigentliche Erstellen des DB2-Umfeldes erfolgen können. Da die ständigen Nachbearbeitungen zum Teil eklatante Zeitverzögerungen hervorgerufen hätten, wurde der Originalgenerator entsprechend den Anforderungen angepaßt.

Nicht ohne weiteres ließ sich auch das Generieren der DML-Objekte übernehmen. Es handelte sich dabei um Fachlogikfremde SQL-Statements (Select, Insert, Update, Delete). Diese Modelle wurden im Rahmen der Anwendungsentwicklung als Basis verwendet und dann fachlogisch "angereichert".

Zweistufiges Performance-Tuning

Der Produktionsaufnahme des neuen Anwendungssystems war eine umfangreiche Tuning-Phase vorgeschaltet, die eine höchstmögliche Performance der DB2-Datenbank bezweckte. Die Tuning-Maßnahmen erfolgten in den Stufen A (Optimierung von SQL-Statements und Indizes mittels Analyse der DB2-Plan-Tabellen) und B (Detaillierte Performance-Analysen mittels DB2-Performance-Monitor).

Bei A kam als Hilfsmittel Easy Explain Explanation zur Anwendung. Dabei ging es um

- eine optimale Struktur der SQL-Statements,

- eine optimale Reihenfolge der WHERE-Prädikate,

- das Eliminieren redundanter Prädikate in WHERE-Statements,

- eine optimale Indexverwendung,

- die Vermeidung kleiner und nicht benutzter Indizes,

- die Verwendung von MIAP (Multiple Index Access Paht),

- die Vermeidung von Table-Space-Scans,

- die Verwendung des DB2-Sequential Prefetch und

- den effektiven Einsatz des Clustering Index.

Bei B kam als Hilfsmittel Insight DB2 zur Anwendung. Im einzelnen ging es dabei um

- das Überarbeiten der DB2-Installationsparameter,

- das optimale Organisieren der Table-Spaces,

- das Optimieren des Bufferpools,

- die Überarbeitung des THREAD-Managements,

- eine optimale Locking-Strategie,

- das Überarbeiten der Bind-Parameter und

- eine optimale Commit-Frequenz (Batch-Anwendungen).

Das Tuning ergab eindeutig, daß in den Online-Anwendungen nur wenige laufzeitkritische Programme existieren. Probleme hingegen bereiteten die Batch-Programme, weil sie in der Regel eine Direktverarbeitungslogik enthielten. Durch teilweise tiefgreifende Modifikationen (Umstellung auf sequentielle Verarbeitung; DB2 Sequential Prefetch) konnten hier nachhaltige Laufzeitverbesserungen erzielt werden.