Die Zahl der DB2-Installationen wächst rapide, Dennoch sind große operationale Anwendungen auf der Basis dieses Datenbanksystems noch relativ selten. Die Gründe dafür reichen von Performance-Problemen im Online-Einsatz bis zum Fehlen einer integrierten Entwicklungsumgebung. Bei entsprechendem Aufwand jedoch läßt sich DB2 durchaus für operationale Applikationssysteme verwenden.
Nachdem IBM über Jahrzehnte hinweg das hierarchische Datenbanksystem IMS forciert hat, bezeichnet das Unternehmen nun seit einigen Jahren das relationale System DB2 als seine strategische Plattform für das Daten-Management. Allerdings weist DB2 - zumindest in der heutigen Implementierung einige Mängel auf, die die Entwicklung von operationalen Anwendungen auf DB2-Basis erschweren. Daher ist es nicht verwunderlich, daß viele IBM-Anwender zwar über DB2 verfügen, es jedoch nicht für transaktionsintensive Applikationen einsetzen.
Die Schwachstellen von DB2 lassen sich umgehen
Die derzeitigen Schwachstellen von DB2 lassen sich unter vier Hauptpunkten zusammenfassen. An erster Stelle ist hier das Performance-Verhalten zu nennen, das in zeitkritischen Online-Anwendungen trotz aller Verbesserungen nach wie vor zu Problemen führen kann. Damit scheinen - zumindest auf den ersten Blick - Schwierigkeiten nicht nur bei der Applikationsentwicklung, sondern vor allem auch im produktiven Einsatz programmiert zu sein. Bei der Erstellung der Anwendungen kommt erschwerend hinzu, daß IBM derzeit noch keine integrierte CASE-Umgebung für die Entwicklung von operationalen DB2-Anwendungen anbietet. Da zudem keine vordefinierte Applikationsarchitektur für DB2 zur Verfügung gestellt wird, entsteht bei der Entwicklung von komplexen Online-Anwendungen ein erheblicher Aufwand für die Realisierung einer solchen Architektur. Das Fehlen einer integrierten Entwicklungsumgebung und einer vordefinierten Applikationsarchitektur erhöht den Aufwand für die Ausbildung der mit dem System befaßten Software-Entwickler erheblich.
Unsere bisherigen Erfahrungen zeigen jedoch, daß es Möglichkeiten gibt, diese Probleme zu lösen.
Wie, das soll hier anhand eines repräsentativen Beispiels näher erläutert werden. Bei diesem Beispiel handelt es sich um ein komplexes Wertpapierabrechnungs- und -verwaltungssystem, das Andersen Consulting derzeit für eine große deutsche Privatbank entwickelt. Der Funktionsumfang erstreckt sich von der Ordereingabe über Effektenabrechnung, Zins- und Kuponabrechnung, Liefersystem, Online-Stammdatenpflege, Kapitalveränderung, Verlosung, Kündigung, Hauptversammlung, Eigenbestandsverwaltung, Nostro und Depotbuchhaltung bis hin zu Portfolio-Management und -Analyse. Das gesamte Projekt wurde in vier Phasen unterteilt. Der Funktionsumfang der ersten beiden Phasen wurde termingerecht realisiert und ist seit einigen Monaten im Einsatz.
Zur Realisierung der komplexen Online-Funktionen mit einer Vielzahl aufwendiger Auswahl-Bildschirme wird das System im Endausbau mehr als 300 Online-Programme umfassen.
Für den Batch-Teil sind 280 Programme vorgesehen, von denen rund ein Drittel zur Datenextraktion im Rahmen einer umfangreichen Report-Architektur dient. Die 180 DB2 Tabellen werden im Durchschnitt mehr als 11 GB Daten enthalten. Insgesamt sollen 200 Anwender in den einzelnen Fachbereichen mit diesem System arbeiten.
Als Entwicklungs und Prodüktionsrechner steht ein Großcomputer vom Typ IBM 3090600E mit dem Betriebssystem MVS/ESA zur Verfügung. Neben dem Datenbanksystem DB2, Version 2.2, kommen der Transaktionsmonitor CICS sowie die Query-Systeme Spufi und QMF zum Einsatz. Als Programmiersprache wird Cobol-II verwendet. Für die Software-Entwicklung findet die integrierte CASE-Umgebung Foundation mit den Komponenten Method/1, Design/1 und Install/1 Anwendung.
Wesentlich für den Einsatz im hier beschriebenen Projekt ist, daß sich die einzelnen Tools gegenseitig ergänzen und den gesamten Software-Lebenszyklus abdecken.
Method/1 bietet neben einem kundenspezifisch anpaßbaren Vorgehensmodell ein Projekt-Management-System sowie ein System zur Verwaltung von Änderungsanforderungen. Design/1 unterstützt Tätigkeiten, die den Entwurf und die Dokumentation eines Anwendungssystems betreffen, wie zum Beispiel Datenmodellierung, Prototyping, Modul- und Bildschirmentwurf Install/1 beinhaltet neben einem aktiven Repository und einer Applikationsarchitektur Funktionen zur Programmierunterstützung. Diese Komponente ist für verschiedene Datenbanksysteme verfügbar; die hier installierte Version unterstützt speziell die Entwicklung von DB2-Anwendungen.
Zentraler Bestandteil der Komponente Install/1 ist ein DB2-basiertes aktives Repository, das alle relevanten Informationen für die Entwicklung einer DB2-Anwendung auf nimmt und deren referentielle Integrität gewährleistet. Zu diesen Informationen zählen unter anderem Daten über DB2-Datenbanken, DB2-Storage. Groups, DB2-Tabellen, Datenelemente, Copybooks, Programme, DB2-Pläne und Conversations.
Im Beispielprojekt brachte der Einsatz von Install/1 insbesondere für die Datenadministration entscheidende Vorteile. So werden zum Beispiel DB2-Objekte wie Storage-Groups oder Tabellen direkt aus den Repository-Informationen generiert. Dadurch ist sichergestellt, daß die Daten im Repository und im DB2-Katalog immer auf dem gleichen aktuellen Stand sind. Das Tool verfügt zudem über eine Reihe von standardisierten Report-Funktionen, die auf der Basis der Repository-Informationen unter anderem Attribute-Reports oder Impact-Analysen erzeugen. Des weiteren unterstützt das Entwicklungswerkzeug die Migration der DB2-Objekte zwischen den einzelnen Umgebungen.
Auch im Bereich der Programmierung konnte durch den Einsatz des Tools Install/1 eine deutliche Steigerung der Produktivität erreicht werden. Ausschlaggebend hierfür war in erster Linie die vordefinierte Online-Architektur. Hierbei sind übergreifende Funktionen zentral abgelegt, so daß sie nicht in jedem einzelnen Programm erneut realisiert werden müssen. Dazu gehören insbesondere die Bereiche Ablaufsteuerung der Dialoge, Eingabevalidierung, Sicherheitseinrichtungen, Hilfefunktionen und Unterstützung der Landessprache (National Language Support)
Für jede Aufgabenstellung (Auswahl-, Update-Bildschirm etc.) existiert ein spezielles Programm-Skelett (Shell). Diese Shells enthalten zum einen sämtliche Schnittstellen zur Nutzung der übergreifenden Funktionen, zum anderen schon vordefinierte Teile des aufgabenspezifischen Codes. Durch die Verwendung der Online-Architektur reduziert sich der Codier- und Testaufwand erheblich. Somit kann sich der Programmierer auf die Lösung der fachlichen Probleme und auf die Erstellung der SQL-Anweisungen konzentrieren. Um SQL-Statements interaktiv generieren zu können, bietet Install/1 eine Funktion für alle im Repository definierten DB2-Tabellen. Weiterhin unterstützt das Tool den Unit-Test eines DB2-Programms mittels einer Einrichtung zur interaktiven Erstellung von Testdaten für DB2-Tabellen. Dadurch wird es jedem. Programmierer ermöglicht, mehrere Versionen eigener Testdaten anzulegen und zu pflegen.
Da das Bankhaus mit diesem Projekt das Datenbanksystem DB2 erstmalig einsetzte bestand eine wesentliche Aufgabe darin, die DB2/SQL-Kenntnisse der insgesamt 50 Projektmitarbeiter in kurzer Zeit auf einen einheitlichen Stand zu bringen. Dies erfolgte durch entsprechende Schulungsmaßnahmen und Selbststudien unter Verwendung eines interaktiven Lernprogramms. Hierbei konnte eine deutliche Abflachung der Lernkurve festgestellt werden, da SQL im Vergleich zu herkömmlichen Datenmanipulationssprachen leicht erlernbar ist. Der entscheidende Fortschritt wurde jedoch erst durch die konsequente Anwendung von CASE-Tools mit den oben genannten Möglichkeiten zur Unterstützung des Entwicklungsprozesses von DB2-Anwendungen erzielt.
Dem Integrationstest kommt in jedem Projekt eine hohe Bedeutung zu. Wegen der möglichen Performance-Probleme empfiehlt es sich bei DB2-Anwendungen, nicht nur die Funktionalität, sondern auch das Zeitverhalten der Applikationen zu prüfen. Dies wird im vorliegenden Fall intensiv getan, unter anderem durch eine Analyse der Zugriffspfade mit Hilfe der DB2-Funktion Explain. Sie protokolliert das Verhalten des DB2-Optimizers im Hinblick auf Indexverwendung und interne Sortiervorgänge beim Datenzugriff.
Um die Aussagekraft der Testergebnisse zu verstärken, werden Testdaten angelegt, die vom Inhalt wie auch vom Umfang her den Produktionsbedingungen entsprechen. Die Testergebnisse erfahren eine gründliche Analyse und in Fällen, in denen es erforderlich erscheint, gehen entsprechende Tuning-Maßnahmen vonstatten. Dabei werden unter anderem neue DB2-Indizes angelegt oder bestehende modifiziert, falls die Tests deren mangelnde Einsatzfähigkeit belegen.
Im Bedarfsfall erfolgen in den Programmen eine nochmalige Überprüfung und gegebenenfalls eine Anpassung der SQL-Statements. Um die Notwendigkeit und die Wirksamkeit der Reorganisationsmaßnahmen zu überprüfen, werden ausgewählte Kennzahlen des DB2-Katalogs periodisch überwacht.
Wichtig ist jedoch, nicht erst in der Testphase mit der Performance-Optimierung zu beginnen. So fanden im vorliegenden Projekt bereits beim Design der Datenbank und der SQL-Anweisungen in den Programmen die bekannten Regeln zur Optimierung der Performance Berücksichtigung. Dazu wurden schon zu Projektbeginn entsprechende Richtlinien für den DB2-Einsatz erstellt und in die Entwicklungsstandards aufgenommen. Durch eine logische und strukturierte Vorgehensweise läßt sich hier viel bewirken, insbesondere natürlich bei komplexen Systemen.
Dies belegen Messungen im Online-Bereich. Die bereits in Produktion befindlichen Systemkomponenten erzielen eine durchschnittliche Antwortzeit von 0,7 Sekunden, wobei 87 Prozent der Antworten innerhalb von einer Sekunde und 96 Prozent der Antworten innerhalb von zwei Sekunden erfolgen.
Nach unseren Erfahrungen gibt es eine Strategie, die eine unabdingbare Voraussetzung für die erfolgreiche Entwicklung eines DB2-Anwendungssystems darstellt. Dazu gehört, daß schon in der Design-Phase die Grundregeln zur Optimierung des Performance-Verhaltens berücksichtigt werden. Weiterhin sollte zur Reduzierung der Lernkurve und zur Erhöhung der Produktivität eine integrierte CASE-Umgebung eingesetzt werden. Sie muß ein aktives Repository beinhalten, das in der Lage ist, alle für die Entwicklung einer DB2-Anwendung wichtigen Informationen aufzunehmen. Durch den Einsatz einer vordefinierten Applikationsarchitektur wird eine Reduzierung des Codier- und Testaufwands erreicht. Somit kann sich der Programmierer mehr auf die Lösung der fachlichen Problemstellung und auf das Arbeiten mit dem Datenbanksystem konzentrieren.
Durch einen ausgeprägten Integrationstest, der eine Überprüfung des Performance-Verhaltens einschließt, lassen sich exakte Anhaltspunkte für die Optimierung des Systems gewinnen. Um hier Fehlerquellen von vornherein auszuschließen, sollten die im Integrationstest verwendeten Testdaten hinsichtlich Inhalt und Umfang den Produktionsbedingungen entsprechen. Auf Grundlage der so gewonnenen Ergebnisse werden aus den zur Verfügung stehenden Tuning-Möglichkeiten die jeweils passenden ausgewählt. Sie sollten konsequent zum Einsatz kommen, um ein optimales Gesamtergebnis zu erzielen.