Direktzugriff auf DB2-Daten und andere\Datendrehscheibe für Client-Server-Anwendungen realisieren

15.05.1992

Bei Downsizing-Projekten kommt es auch auf die Datenverteilung über unterschiedliche Plattformen hinweg an. Eine Möglichkeit besteht darin, DB2-Daten periodisch auf einen DB-Server zu transportieren und die Client-Anwendungen darauf zugreifen zu lassen. Zusätzlich bekommen Client-Anwendungen den Direktzugriff auf DB2-Daten und eventuell noch auf weitere Dateien.

Die Herausforderung liegt darin, eine plattformunabhängige Datenarchitektur zu schaffen, das Mengen- und Zeitproblem bei der Datenverteilung zu lösen und die richtigen DB-Produkte und Schnittstellen auszuwählen.

Welche Gründe gibt es für Downsizing? Als Serviceabteilung hat die Informationsverarbeitung die Aufgabe, die Unternehmensziele zu unterstützen, natürlich wirtschaftlich. Der Kostendruck, unter den die Informationsverarbeitung gesetzt wird, ist erheblich. Eine logische Konsequenz ist der Gedanke an Kostenersparnis durch Downsizing. Doch Downsizing und Kostenersparnis passen auch den bisherigen Erfahrungen nicht unbedingt zusammen. Die Wahrheit ist, daß nur derjenige, der den Schock des ersten Investments überwindet, diesen Weg beschreiten kann. Langfristige Kostenvorteile sind zur Zeit bestenfalls zu vermuten, nicht aber zu beweisen.

Der wesentliche Sinn, bereits jetzt in Downsizing-Projekte zu investieren, besteht darin, daß dadurch erst bestimmte Unternehmensziele erreichbar werden. Ein für diese Situation typisches Ziel ist die bessere Unterstützung des Vertriebs beziehungsweise der Außenstellen. Dies bedeutet den Einstieg in eine Infrastruktur, die ohne die Leistung und damit ohne die Kosten eines Mainframes auskommt. Eigentlich ist der Verzicht auf Mainframes sogar die Voraussetzung für einen Projekterfolg. Flexible Anpassung der Technik an die Anforderungen ist das Gebot der Stunde.

Ein weiterer wesentlicher Grund für Veränderungen liegt im User-Interface (UI) für den Endbenutzer. Natürlich kann man über Sinn und Unsinn eines bestimmten GUI (grafical user interface) beliebig lange diskutieren. Tatsache ist aber, daß jeder neue Technologieschritt auf diesen Benutzeroberflächen aufbaut, diese können aber selbst nur ein Zwischenschritt sein auf dem Weg zu einem vernünftigen Mensch-Maschine-Interface (zum Beispiel ein full motion user interface). Das Auslassen eines Technologieschrittes wie etwa der Einführung eines grafischen User-Interfases ist wegen des Know-how-Aufbaus nicht empfehlenswert. "Kostenstruktur verbessern", "Hilfe zur Erreichung der Unternehmensziele" und "modernes User-Interface" -sind das die Triebfedern für den Einstieg in Downsizing-projekte? Oder geht es einfach darum, mit neuen Projekten den Anschluß an neue Technologien nicht zu verlieren? Klar ist eines: Ein Verharren in einer zentralen Umgebung löst keine anstehenden Probleme.

Downsizing ja, aber für welche Aufgaben?

Die Überlegung, welche Projekte für Downsizing-Aktivitäten geeignet sind, sollten von verschiedenen Ansätzen ausgehen.

Dezentrale OLTP-Anwendungen: Die vorhandenen zentralen OLTP-Anwendungen sollten aus Kostengründen in der Regel unverändert bleiben und können durch dezentrale Anwendungen nur ergänzt werden. Die entscheidende Frage ist die Integration neuer Verfahren in die vorhandene Umgebung. Eine Antwort darauf kann die Realisierung einer Datendrehscheibe (zum Beispiel DB2) sein, über die der Datenaustausch zwischen den Anwendungen erfolgen kann. Eine direkte Programm-zu-Programm-Kommunikation ist meistens nur mit hohem Aufwand zu realisieren und bedeutet eine Überarbeitung vorhandener Anwendungen. Ein Weg, der mehr Erfolg verspricht und dem Unternehmen den Anwendern sofortigen Nutzen bringen kann, führt über eine Datendrehscheibe. Als Nutzen ist beispielsweise Kundennähe durch Dezentralisierung zu betrachten.

Aufbau neuer OLCP-Anwendungen: Online complex processing (OLCP) dient als Informationslieferant für Entscheidungsprozesse und eignet sich vor allem für die Realisierung komplexer und qualitativ hochstehender Auswertungen, Berichte und Statistiken.

Neben OLTP wird jetzt auch OLCP interessant

Dieses Geschäftsfeld umfaßt die Weiterentwicklung bisheriger IDV/DSS-Anwendungen und basiert auf neuen Technologien wie zum Beispiel ServerDB, unternehmensweitem Datenzugriff und Grafik-Oberflächen mit Bildern und Landkarten. Da dies in den meisten Unternehmen noch nicht ausreichend realisiert ist, bietet sich ein Investment geradezu an:

- vorhandene Infrastruktur wird genutzt;

- Aufbau einer zweiten Säule neben den produktiven OLTP-Anwendungen;

- sofortiger Nutzen für Fachbereiche, Außenstellen und Management;

- Einsatz fertiger Softwarepakete ohne Eigenentwicklung;

- Pilotprojekte sind überschaubar und mit vernünftigem Aufwand realisierbar;

Datendrehscheibe DB2: Sowohl OLTP- als auch OLCP-Anwendungen können entsprechend dem Konzept in Abbildung 1 realisiert werden:

- Periodische Datenverteilung aus DB2 in eine Server-Datenbank. Die Problematik besteht im Management großer Datenmengen, der dafür erforderlichen Transportzeit und in der Lade- beziehungsweise Update-Zeit für die Datenbank. Ein Beispiel hierfür finden Sie im letzen

Abschnitt.

- Aufbau einer Client-Server-Architektur mit Anschluß an den Host, normalerweise über eine Gateway-Technologie. Zur Verfügung stehen DB-Gateways von der Server-DB zu DB2. Diese Lösung wird von den meisten Server-DB-Herstellern angeboten. Sie ermöglicht einen direkten Datenbank-zu-Datenbank-Transfer. Hauptaufgabe des Gateway ist die Herstellung einer einzigen Datensicht für den Benutzer und die Umsetzung unterschiedlicher SQL-Dialekte. Zusätzlich gibt es Communications Server, die in erster Linie die unterschiedlichen Netzwerke miteinander und die Client-Workstations mit dem Host verbinden.

- Im Mittelpunkt der Client-Server-Architektur steht der DB-Server, dessen Aufgabe die Versorgung der Clients mit lokalen Daten ist. In Abhängigkeit vom erforderlichen Funktionsumfang und der zu bearbeitenden Datenmenge stehen drei Produktklassen zur Auswahl: File-Händler (zum Beispiel FileShare von Microfocus oder Btrieve von Novell) mit Transaktionssicherheit und Sekundär-Indizes bieten einen datenbankähnlichen Funktionsumfang mit geringerer Komplexität und Kosten als Datenbanksysteme. Relationale Datenbanksysteme sind in diesem Bereich State-of-the art. Bei der Auswahl ist auf den unterschiedlichen Funktionsumfang zu achten. Produktbeispiele sind SQLServer, SQLBase, Oracle oder Ingres. Die Datenbankmaschine von Teradata bietet in diesem Bereich schnelle Verarbeitungszeiten, aber auch sehr schnelle Ladeprogramme, um einen periodischen Update zeitgerecht durchführen zu können.

Die Clients wiederum benötigen für ein optimales Arbeiten den Zugriff auf möglichst viele Daten, die auch in unterschiedlichen Lokationen gespeichert sein können. Deshalb ist der Zugriff auf alle drei Ebenen wünschenswert:

- lokale Zugriffe auf den DB-Server (zirka 80 Prozent aller Zugriffe),

- remote Zugriffe auf DB2 und auf

- weitere Daten im Unternehmensverbund.

Die erforderlichen Schnittstellen gibt es bereits, sowohl für eine Eigenentwicklung als auch für fertige Lösungen im Rahmen von Tools (siehe Abbildung 2).

Ein Datenmodell nach der bekannten Entity-Relationship-Methode ist heute schon vielfach realisiert oder in Realisierung, wenigstens auf Projektebene. Dabei werden jedoch die Aspekte der Datenverteilung vielfach nicht berücksichtigt. Erforderlich ist daher eine plattformunabhängige Datenarchitektur. Dabei ist es sinnvoll, verschiedene Kriterien in Form eines Netzwerkes miteinander in Verbindung zu bringen:

- Verteilungskonzept: Regeln zur Speicherung der Daten in verteilten Lokationen.

- Redundanz: Regeln zur redundanten Speicherung von Daten (aus Gründen der Performance)

- Konsistenz: Regeln zum kontrollierten Update redundanter Daten.

- Aktualität: Regeln zur Definition des Aktualisierungsgrades (sofort, periodisch).

- Update: Regeln zur Update der gespeicherten Daten. Bei redundanten Daten muß eindeutig geklärt sein, ob nur an einer Stelle geändert wird oder ob ein Mehrfach-Update mit Konsistenzregeln möglich ist.

- Performance: Regeln zur Realisierung der 80-zu-20-Regel, das heißt, in 80 Prozent aller Fälle sollen die Daten lokal gelesen oder geändert werden, in 20 Prozent wird auf die zentrale Datenbank zugegriffen.

Selbstverständlich läßt sich eine derartige Datenarchitektur weder einfach noch schnell aufbauen. Vor allem deshalb nicht, weil sich die Anforderungen der einzelnen Punkte im Prinzip sogar widersprechen. Zum Beispiel ist eine gute Performance ohne Redundanz kaum möglich, andererseits sollten Redundanzen vermieden werden.

Die Datenarchitektur muß daher zwei wesentliche Anforderungen erfüllen:

- Kompromiß zwischen den genannten Punkten, um eine Realisierungsgrundlage zu schaffen, und

- Unabhängigkeit von den gewählten Verteilungsplattformen, um Änderungen beziehungsweise Erweiterungen jederzeit zu ermöglichen. Das heißt, alle Regeln müssen die grundsätzliche Problematik abdecken und nicht einzelne Ausprägungen. Zum Beispiel muß klar sein, ob ein Lagerbestand verteilt werden kann oder nicht. Wenn ja, ist die Zahl der unterschiedlichen Lokationen relativ unwichtig. Die Wichtigkeit der Datenarchitektur liegt in der Tatsache, daß ein grundsätzlicher Verteilmechanismus gefunden werden muß.

Die Datenarchitektur ist eine wesentliche Voraussetzung für den Einstieg in ein Verteilungskonzept und deutlich wichtiger als jede Technik, die eigentlich nur zur Umsetzung der Datenarchitektur dienen soll.

Das Beispiel in Abbildung 3 zeigt der prinzipiellen Verlauf einer periodischen Datenverteilung vom Host zum DB-Server.

Entscheidende Kriterien waren die große Datenmenge und die nächtlich zur Verfügung stehende Zeit von zirka vier Stunden. Bei der Planung des Verfahrens stellte sich sehr schnell ein Engpaß heraus: die Update-Geschwindigkeit der Datenbank.

Bei einer Schreibgeschwindigkeit von zirka zehn Sätzen pro Sekunde (einschließlich Sekundärindex) ergibt sich eine Stundenleistung von 36 000 Sätzen. Diese Geschwindigkeit reichte nicht aus, um alle Tagesänderungen in der Server-DB zu speichern. Als Lösung wurde der folgende Kompromiß gefunden:

Installation von vier parallelen Servern, um die Daten parallel in die unterschiedlichen Datenbanken laden zu können. Nur der Datentransport vom Host zum Server mittels File-Transfer erfolgt seriell. Da dieser lokale Transport eine hohe Geschwindigkeit hat, ist der Zeitaufwand dafür akzeptabel. Anschließend erfolgt das Neuladen beziehungsweise das Ändern der Server-DB. Am ersten Server wird wegen des extremen Umfangs nicht die ganze Datei neu geladen, sondern nur die täglich anfallenden Updates. Am zweiten Server wird die Datenbank täglich neu geladen, und die Indizes werden neu aufgebaut, da sich dies als der schnellere Weg im Vergleich zum Update-Weg herausgestellt hat. Dieser Vorgang wiederholt sich mit den beiden folgenden Datenbeständen .

Durch diese Konzeption konnte der Zeitbedarf auf zirka 3,5 Stunden reduziert werden, mit dem Vorteil einer hohen Ausfallsicherheit durch Installation von vier parallelen Servern.

Datendefinition beeinflußt Client-Server-Architektur

Die Einführung einer Client-Server-Architektur steht und fällt mit der Definition einer .Datenarchitektur. Dies ist der entscheidende Schritt für die optimale Versorgung der Client-Anwendungen mit Daten. Es ist aber auch der schwierigste, denn eine Reihe sich widersprechender Kriterien muß unter einen Hut gebracht werden. Anschließend ist darauf zu achten, daß der Datentransport zum Server nicht wegen zu langer Laufzeiten zum Scheitern verurteilt ist. Lösungsmöglichkeiten sind das Parallelisieren der Hardware und DB-Software sowie das Neuladen der Datenbank anstatt langwieriger Update-Läufe. Die Schnittstellen für die Client-Programme zum Datenzugriff stehen zur Verfügung, und auch Tools, die den Zugriff auf unternehmensweit gespeicherte Daten erlauben, sind vorhanden.

Das Fazit kann nur lauten, daß die Zeit sicherlich reif ist für den Einstieg in eine neue

Technologie.