Von: Dr. Klaus Grüning
Datenbanken sind nach wie vor die Grundlage für fast alle wesentlichen EDV-gestützten Vorgänge in Unternehmen. Ihr Aufbau ist für die Effizienz der Datenhaltung sowie für den schnellen Zugriff auf die Daten von entscheidender Bedeutung. Das Problem, das sich mit der Einführung verschiedener Datenbanken stellt, ist die Vielfalt an Formaten respektive die vielfältigen Arten, wie Daten in Datenbanken abgespeichert werden. In einer Unternehmenswirklichkeit, die zunehmend von heterogenen Systemumgebungen bestimmt wird, ist daher die Frage, wie man den Datenaustausch zwischen verschiedenen Datenbanken und Plattformen so unkompliziert wie möglich abwickelt, von wesentlicher Bedeutung. Der systemunabhängige Zugriff auf die Unternehmensdaten wird immer entscheidender für eine schnelle und störungstolerante Betriebsführung.
Datenbanken, Normalformen und Legacy Data
Die Datenbank als Verwaltungsinstrument von Daten ist wesentlich jünger als der Computer selbst. Sie geht zurück auf die Erkenntnis, dass die rasant steigenden Mengen an Daten, die ein Computer zu verwalten hat, möglichst effizient und zugriffsfreundlich aufbewahrt werden müssen, um den Suchaufwand so gering wie möglich zu halten. Die Struktur einer Datenbank ist auf diese Bedürfnisse ausgerichtet. Sie besteht aus vielen unterschiedlichen Tabellen, in denen jeweils bestimmte Daten abgespeichert werden. Zum Beispiel werden in der Adressdatenbank alle zu einer bestimmten Adressnummer gehörigen Adressdaten erfasst. Über diese Nummer können dann etwa die Buchhaltungs- oder die Auftragsdaten mit den Adressdaten verknüpft werden. So wird verhindert, dass die gleichen Daten je nach Anwendung immer wieder neu erfasst werden und damit Speicherplatz belegen.
Das Prinzip der relationalen Datenbanken (RDBs) geht auf E.F. Codd zurück, dessen Normalformen zum Grundwissen eines jeden Informatik-Studenten gehören. Während dieses Grundprinzip bei allen RDBs identisch ist, unterscheiden sie sich erheblich in den Details ihres Aufbaus, ganz zu schweigen von der jeweils zugrunde liegenden Programmiersprache.
Im Gegensatz zu dieser strukturierten Form der Datenaufbereitung und -ablage stehen ältere Datenbestände, so genannte Legacy Data, die in vielen Systemen immer noch vorhanden sind und einen teilweise unverzichtbaren, in jedem Fall aber wertvollen Informationsbestand des jeweiligen Unternehmens darstellen. Häufig sind diese Daten unstrukturiert, sequenziell oder in Vorformen der Datenbanken abgelegt - etwa nach der Methode "Index sequenziell" oder VSAM.
Datenintegration: Notwendigkeit und Herausforderung
Solange es in Unternehmen einen Zentralrechner gab, an dem eine bestimmte Anzahl so genannter Dumb Terminals hing, die auf die operationale Datenbank Zugriff nahmen, stellte sich die Frage der Integration von Daten aus verschiedenen Datenbanken nicht. Ausgelegt auf eine solche homogene Umgebung sind im Prinzip bis heute ERP-Anwendungen wie SAP, J.D. Edwards oder Baan. Sie decken alle wesentlichen Geschäftsfelder mit einer Standardanwendung ab, die keinerlei weitere Hard- oder Software benötigt. Unbeschadet des Erfolges dieser Anwendungssoftware sieht die Realität in den meisten Unternehmen anders aus: Es gibt nicht nur eine Anwendung, und es existieren in der Regel die den Notwendigkeiten der Anwendungen angemessenen Plattformen. Das bedeutet aber konkret, dass unternehmenskritische Daten in verschiedenen Formaten auf verschiedenen Rechnern bereit gehalten werden.
Eine typische Konstellation ist ein Mainframe oder eine AS/400 als Host-System, dazu kommt ein Windows-NT-Server, zum Beispiel für die Anbindung der Kassenterminals im Einzelhandel und vielleicht noch ein Unix-Derivat wie Linux, etwa als dedizierter Web-Server. Auf all diesen Plattformen werden Daten in unterschiedlichen Datenbanken vorgehalten. Die von den jeweiligen Systemen benötigten Informationen sind aber in weiten Teilen deckungsgleich. So benötigt etwa der für die Steuerung der Kassenterminals zuständige NT-Server die aktuellen Preise, die auf dem Produktivrechner erfasst werden, dieser muss umgekehrt den Warenausgang rückgemeldet bekommen, damit entsprechend disponiert werden kann. Das gleiche gilt für den Web-Server: Auch hier müssen die eingehenden Informationen der Produktiv-Datenbank verfügbar gemacht werden, beziehungsweise müssen umgekehrt Änderungen etwa des Lagerbestandes aktuell an den Web-Server weitergegeben werden.
Es gibt also die Notwendigkeit, die Daten auf den unterschiedlichen Plattformen miteinander zu synchronisieren, beziehungsweise durch Integration der heterogenen Systemumgebung zu gewährleisten, dass auf jeder Plattform die jeweils benötigten Informationen als aktuelle und konsistente Datenbestände vorliegen.
Etablierte Methoden des Datentransfers
Es gibt verschiedene Verfahren, mit denen man den Datenaustausch innerhalb heterogener Systemumgebungen regeln kann. An erster Stelle steht die Schnittstellenprogrammierung. Jede Standard-Anwendungssoftware bietet Import- und Export-Schnittstellen an. In der Regel sind das Dateien, die in proprietären Formaten gefüllt beziehungsweise bereitgestellt werden müssen. Das Problem der Schnittstellenprogrammierung besteht im Zeit- und damit im Kostenaufwand. Dieser fällt nicht einmalig, sondern wiederkehrend an. Jede größere Änderung der Anwendungssoftware - etwa ein Upgrade - oder des Betriebssystems - zum Beispiel ein Release-Wechsel - erfordert einen erneuten Eingriff an den Schnittstellen. Dazu kommt, dass Schnittstellenprogrammierung immer eine Manipulation der Anwendungssoftware bedeutet, was bei Standardlösungen, wie sie heute in der Regel im Einsatz sind, nach Möglichkeit vermieden werden sollte.
Eine andere Möglichkeit ist die Datenübertragung mittels File Transfer Utilities wie FTP oder Client Access. Hier werden regelmäßig ganze Dateien oder Tabellen verschoben, wobei neben dem Zeitaufwand der immer wiederkehrenden Eingaben je nach Größe (Datenmenge der Datei oder Tabelle) die Leitungsbelastung zum Problem werden kann.
Ebenfalls kritisch, allerdings nicht für die Leitung, wohl aber für den Host-Rechner, ist die SQL-Abfrage über eine ODBC (Open-Database-Connectivity) -Schnittstelle. Bei ihr wird die gesamte Datenbank des Quellsystems durchsucht, bis die gewünschte Information gefunden ist. Diese wird dann auf den Zielrechner "gezogen" (mit dem so genannten Pull-Verfahren). Dieses Verfahren wird so oft durchgeführt, wie jemand eine bestimmte Information sucht. Sind es mehrere Anwender, die auf diese Weise auf das Quellsystem zugreifen, steigert sich die Belastung entsprechend.
Hohe Belastung von Leitungen und Rechnern
Eine weitere Möglichkeit stellt innerhalb der IBM-Welt die APPC-Programmierung dar. SNA, das IBM-Netzwerkprotokoll, stellt mit APPC oder LU6.2 Programmaufrufe, so genannte APIs, zur Kommunikation verschiedener Programme zur Verfügung. Auch dies stellt also ein Toolset zur Programmierung von Datensynchronisationsaufgaben dar.
Sämtliche genannten Verfahren haben den Nachteil, dass sie keine dauerhaften Lösungen darstellen, sondern immer wieder anfallende Tätigkeiten mit sich bringen, die je nach Methode in höherem oder geringerem Ausmaß Arbeitszeit binden. Darüber hinaus ist die mit diesen Verfahren zum Teil verbundene Leitungs- oder Rechnerbelastung ein weiterer Nachteil.
Der Datenaustausch mit Hilfe einer Standard-Software, wie sie der kanadische Software-Entwickler Datamirror anbietet, soll die genannten Nachteile umgehen. Möglich wird dies durch ein grundsätzlich anderes Verfahren beim Datentransfer, als es in den bereits beschriebenen Methoden Anwendung findet. Der Transformations-Server nutzt das in jeder Datenbank geführte Protokoll über die ausgeführten Daten-Transaktionen. Dieses liest er aus und überträgt dann die abgeschlossenen Transaktionen auf die Zieldatenbank. Das heißt, im Gegensatz zu allen beschriebenen Methoden geht bei diesem Verfahren der Anstoß für die Übertragung von der Quelldatenbank aus, die den Transfer durch die protokollierte Datenbewegung veranlasst. Damit verringert sich auch die Leitungsbelastung, weil nur vergleichsweise geringe Datenmengen über die Leitung geschickt werden müssen. Experten gehen davon aus, dass die Menge an geänderten Daten in einer Datenbank zwischen einem und fünf Prozent des Gesamtdatenbestandes liegt. Selbst bei einem nur einmal täglich stattfindenden Transfer auf das Zielsystem liegt damit die Leitungsbelastung um ein Vielfaches unter dem für einen kompletten Download erforderlichen Wert. Möglich ist auch der Echtzeittransfer - das heißt, die Übertragung geschieht sofort dann, wenn eine Transaktion abgeschlossen ist. Nutzen Anwender die Software etwa, um ein Data-Warehouse mit den Daten aus der Produktivdatenbank zu versorgen, kann man so ein Höchstmaß an Aktualität der dort gefahrenen Auswertungen realisieren.
Nicht nur der weniger aufwendige und in der Regel bidirektionale Austausch von Daten macht eine Standardlösung attraktiv. Interessant sind auch die vielfältigen Möglichkeiten, wie die Daten in einem heterogenen Netz verteilt werden können. So ist es möglich, "Verteilungskaskaden" zu erstellen: Von einem Zentralrechner werden Daten auf verschiedene dezentrale Verteilungsrechner übertragen, die ihrerseits die Daten an weitere regionale Rechner weitergeben. Ein solches Modell ist überall dort nützlich, wo ein Unternehmen in räumlich auseinander liegende Einheiten aufgeteilt ist: Es lassen sich dadurch sowohl Kosten als auch die Verteilungszeiten minimieren. Denkbar ist dabei auch, bestimmten Anwendergruppen lediglich selektive Kopien zur Verfügung zu stellen. In Frage kommt etwa der Ausschnitt an Informationen aus der Gesamtmenge einer Bank, die für eine bestimmte Filiale wichtig sind, während diese ihrerseits alle Geschäftsinformationen an die Zentrale weitergibt.
Eine solche verteilte Datenvorhaltung bietet außerdem den Vorteil, dass bestimmte, leistungsintensive Arbeiten wie komplizierte Batch-Jobs oder Queries auf einer anderen Maschine mit den dorthin replizierten Daten durchgeführt werden können. Damit steht das Produktivsystem in dieser Zeit den Anwendern zur Verfügung, die Synchronisation zwischen den beiden Datenbanken kann nach Abschluss des Jobs "on demand" erfolgen.
Ein standardisierter Datentransfer muss die Möglichkeit bieten, die Daten während des Replikationsprozesses zu manipulieren. Dies ergibt sich bereits daraus, dass etwa die Feldgrößen in den unterschiedlichen Datenbanken unterschiedlich definiert sind. Gerade wenn man Datenbestände in ein Data-Warehouse replizieren will, ist die Möglichkeit unverzichtbar, die Daten auf Feldebene zu selektieren, vor allem aber auch zu verändern, etwa nur die Summen bestimmter Felder in die Zieldatenbank zu stellen. Die Idee eine Data-Warehouses ist es, die in den Produktivsystemen vorhandenen Daten in verschiedenen Ansichten verständlich darzustellen. Daher auch das Bild des so genannten OLAP-Würfels. (Online Analytical Processing). Im Hinblick auf den nötigen Datentransfer hat dies zwei Konsequenzen: Zum Ersten liegen die Daten in den Produktivsystemen optimiert für die automatische Verarbeitung vor, müssen also aufbereitet werden, um für den Anwender verständlich zu werden. Diesen Prozess nennt man Data Cleansing. Auf der technischen Ebene bedeutet das ein Umformatieren, Zusammenfassen, eventuell auch ein Berechnen neuer Daten.
Zum Zweiten steigt die zu speichernde Datenmenge durch die redundante Datenhaltung immens an. Data-Ware-Häuser mit mehr als 100 GByte Daten sind keine Seltenheit. Eine solche Datenmenge lässt sich nur vernünftig aktualisieren, wenn der Aufwand durch die Übertragungstechnik der Änderungen drastisch reduziert wird. Ein weiteres wichtiges Anwendungsgebiet der Datensynchronisation, bei dem es sehr auf schnelle Reaktion und Aktualität der Daten ankommt, ist das weite Gebiet des E-Commerce.
Ein potenzieller Kunde, der über das Internet eine Ware bestellt, erwartet, dass diese Ware in kurzer Zeit geliefert wird. Voraussetzung dafür ist aber eine optimale Synchronisation der Bestelldaten des Internet-Servers mit den Auftragsdaten des Produktions- und Logistik-Systems, das traditionell auf einem Host-Rechner läuft.
Störungstoleranter Betrieb durch Absicherung
Letztlich bietet die verteilte Datenvorhaltung in einem heterogenen Netz auch eine Absicherung der replizierten Datenbestände vor Datenverlust durch etwaige ungeplante Ausfallzeiten der operationalen Datenbank. So kann es zum Beispiel für ein Unternehmen, das die Auftragsannahme in einem Callcenter direkt in den Produktivrechner erfasst, katastrophale Folgen haben, wenn kurz vor Arbeitsende und damit vor der nächtlichen Bandsicherung ein Plattenausfall auftritt. Die Auftragsdaten eines ganzen Tages sind verloren. Eine Echtzeitübertragung der Datenbewegungen auf einen anderen Rechner, der zum Beispiel für ein Data-Warehouse genutzt wird, bietet hier Abhilfe. Die Daten des Tages bleiben erhalten und können zugleich für aktuelle Auswertungen genutzt werden. Dies ist natürlich keine Hochverfügbarkeitslösung, die bekanntlich den möglichst kurzfristigen Wiederanlauf der Anwendungen neben dem Erhalt der Daten zum Ziel hat. Dieses Verfahren gewährleistet jedoch die Informationsverfügbarkeit. Diese ist in allen Unternehmen von zentraler Wichtigkeit.
Die Realisierung der in fast jedem Betrieb anfallenden Datentransferprozesse durch eine Standardsoftware bietet erhebliche Vorteile gegenüber den herkömmlichen Verfahren. Datenaustausch wird mit einer solchen Lösung nicht nur flexibler handhabbar, sondern es lassen sich auch geplante oder in absehbarer Zukunft zu erwartende Projekte wie Data-Warehousing oder E-Commerce in eine solche Form der Datenverteilung integrieren. (js)
Zur Person
Dr. Klaus Grüning
ist Vertriebsleiter bei Datamirror in Darmstadt und Experte auf dem Gebiet Datenbanksynchronisation.