Die verteilte Datenhaltung wird oft organisatorisch gelöst. Deshalb verkennen manche Unternehmen ihren Bedarf an entsprechenden Datenbanksystemen. Der Unternehmensberater Josef Kraus* zeigt auf, unter welchen Bedingungen verteilte DBs Vorteile bringen.

Heterogene Datenbankumgebungen bei großen Unternehmen können heute den Forderungen nach immer größerer Flexibilität und einer immer stärkeren betriebswirtschaftlichen Vernetzung der Anwendungssysteme nur bedingt gerecht werden. Das Ziel, vorhandene Rechnerleistung, Netzwerke und Anwendungssoftware effizienter einzusetzen, macht es unabdingbar, über den Einsatz neuer Technologien nachzudenken. Die Technik verteilter Datenbanken stellt einen Schritt in diese Richtung dar.

Da es sich im Rahmen der Informationsbewirtschaftung um strategische Entscheidungen über das Wie und das Womit der Etablierung solcher Technologien im Unternehmen handelt, ist es wichtig, sich frühzeitig mit den Fähigkeiten und Möglichkeiten von verteilten Systemen vertraut zu machen, um eine Perspektive für eine Datenbank- und IV-Strategie der kommenden Jahre zu erhalten.

Es kann deshalb nur ratsam sein, heute schon zu analysieren, ob konzeptionelle Datenstrukturen existieren, die einen potentiellen Verteilungsbedarf erkennen lassen, und wieweit die technische Realisierung mit den heute auf dem Markt befindlichen verteilten Datenbanksystemen möglich ist.

Die Technologie der "Distributed Databases" (DDB) ist nach heutigem Stand noch nicht so ausgereift, daß verteilte Datenbanken in einer operativen Umgebung realisierbar wären. Ein Hauptproblem ist dabei die Sicherstellung der Datenintegrität auf Netzwerkebene (Recovery und dynamischer Backout). Dieses Anwendungs-Manko ist derzeit bei allen untersuchten DDB-Produkten festzustellen. Immer noch werden die Systemprobleme von der Netzebene in die Anwendungen verlagert und dort gelöst.

Bei der technischen Implementierung und Realisierung von DDB-Produkten gibt es erhebliche Unterschiede - innerhalb des Produktspektrums der verschiedenen Hersteller nicht nur in der Art der Implementierung, sondern auch in der Konzeption. Die Alternativen heißen geschlossene Produktumgebung und, offene Architektur.

Unberüsksichtigte Unternehmensgesichtspunkte

Dennoch ist damit zu rechnen, daß ein operativ einsetzbares Produkt, das die meisten der genannten Kriterien erfüllt, in den nächsten vier bis fünf Jahren verfügbar sein wird. Seitens der IBM wird ein entsprechendes Produkt aller Voraussicht nach nicht vor Anfang der 90er Jahre für DB2/SQL-DS freigegeben werden.

Ein Bedarf zur Verteilung von Daten ist in den meisten Unternehmen bei bestehenden Anwendungssystemen meist nicht unmittelbar erkennbar. Der Grund hierfür liegt darin, daß mangels technologischer Möglichkeiten für einen Bedarf an verteilten Informationen bisher immer noch organisatorische Lösungen gefunden werden konnten.

Die Datenorganisation orientierte sich am technisch Machbaren. Für die Berücksichtigung von Unternehmensgesichtspunkten stand keine adäquate Technik zur Verfügung. Einige der heutigen Anwendungssysteme dokumentieren dies durch:

- redundante Datenhaltung,

- Abgleichprogramme/-Läufe und

- Koordination von Abgleichterminen.

Ein prinzipieller Bedarf für die Verteilung von Daten kann bei der Betrachtung der Datenobjekte im Rahmen einer Informationsanalyse offensichtlich werden. Unternehmens Informationen, die von verschiedenen Anwendungssystemen mit unterschiedlichen Standorten bearbeitet werden, weisen grundsätzlich auf einen Verteilungsbedarf hin.

Hohe Lasten auf dem zentralen Rechner und die damit verbundene Verschlechterung von Antwortzeiten führen zur Verärgerung der Benutzer. Eine Datenverteilung über DDB-Techniken kann bei bedarfsgemäß verteilten Informationen Abhilfe schaffen: Der zentrale "Informationsspeicher" wird entlastet und die Verfügbarkeit von Informationen erhöht. Außerdem verlangen bestimmte Unternehmensformen, die Datenbanken für operationale und die Datenbanken für dispositive (strategische) Informationssysteme entweder physisch oder räumlich zu trennen.

Zentrale Informationssysteme werden dann von regionalen und/oder lokalen Datenbanken mit Informationen versorgt. Dabei kann das zentrale Informationssystem aufgrund seiner anderslautenden Zielsetzung auch eine zur lokalen Datenbank unterschiedliche Datenstruktur aufweisen. Oft haben operationale und dispositive Datenbanken eine gemeinsame Schnittmenge an Informationen. Zudem ist die Informationsdatenbank speziell auf den dispositiven und strategischen Informationsbedarf im Unternehmen ausgerichtet.

Die Tatsache, daß heute - und nicht erst seit IBMs SAA-Konzept - ein ernstzunehmender Trend zu Abteilungs- und Arbeitsplatzrechnern existiert impliziert die Gefahr "verstreuter" und damit unkontrollierter und unkontrollierbarer Datenhaltung im Unternehmen. Andererseits soll dem Anwender jedoch die Intelligenz neuer und auf den individuellen Gebrauch ausgerichteter Werkzeuge nicht verwehrt bleiben. "Verteilte Datenhaltung" heißt dann vor allem Kontrollierbarkeit sowie Verfügbarkeit von Informationen in ihrer Gesamtheit, zu jedem beliebigen Zeitpunkt, an jedem beliebigen Ort.

Lokale Pflege und Überwachung von Daten kann substantielle Vorteile für das gesamte Informationssystem im Unternehmen haben. So ist eine lokale Abteilung von verantwortlich für Richtigkeit, Sicherheit und Aktualität ihrer Daten Darüber hinaus können und sollen Teile von Applikationssystemen lokal entwickelt werden, da vor Ort die Analytiker mit den besten Problem- und Detailkenntnissen sitzen.

Für die dezentrale DV sind gemeinsame Standards und Festlegungen über Bedeutung Formate und Pflege der Informationen zu etablieren und einzuhalten, da eine gemeinsam nutzbare Menge von Informationen "zentral" beziehungsweise allgemein verfügbar gemacht wird. Das können auch lokal entstehende Daten sein, die nach Abschluß eines Verarbeitungszyklus in die "zentrale Informationsbasis" eingebunden werden.

Probleme bei der Entwicklung extrem großer Systeme - für Großunternehmen keine Seltenheit - können durch lokale Datenhaltung unter Beachtung der erwähnten Regeln und Standards und mit Hilfe im DDB-System wirksamer Verteilungsmechanismen vermieden werden.

Schnellere Reaktion auf sich ändernde Märkte

Jedes größere Unternehmen, das sich aus produktionstechnischen und/oder organisatorischen Gründen auf mehrere Standorte stützt, verfügt heute über ausgebaute Rechnernetze. Sie werden sowohl für "Remote"-Aktivitäten als auch zum Datenaustausch genutzt.

Demnach sind gerade nach einem "File-Transfer" oft umfangreiche Folgeaktionen - auch organisatorischer Natur - nötig, um die Informationen in die vorhandenen Bestände zu integrieren (abzugleichen) Diese Vorgänge verändern in der Regel weder die Informationsqualität der Daten noch ihre Konsistenz. Sie sind lediglich administrativ begründbar und damit unproduktiver Aufwand.

Die in DDB-Umgebungen erreichbare und erzielte Transparenz entwickelter Anwendungssysteme machen diese auf alle angeschlossenen Knoten, ohne Anpassungsaufwand, portierbar Dies schützt die Investition in Eigenentwicklungen und hilft, Geschäftsprozesse über Unternehmensbereiche hinweg zu synchronisieren und zu standardisieren.

Verteilte Systeme bieten die Möglichkeit einer problemlosen, Datenumverteilung in beliebiger Zusammensetzung und an beliebige Knoten eines DDB-Systems. Dadurch wird die Reaktionsfähigkeit eines Unternehmens auf veränderte Marktsituationen wesentlich erhöht, ohne daß dafür DV-bedingte Kopfstände nötig werden.

In verschiedenen Unternehmen gewinnt der Faktor "Schutz der Daten vor Zerstörung" zunehmend an Gewicht. Auch dies ist ein Argument, Überlegungen zur lokalen "Verteilung von Informationen" anzustellen. Denn im Umfeld verteilter Datenbanken sollen auch "Originaldaten" und die zur Rekonstruktion von Datenbankinhalten notwendigen Informationen geografisch oder mindestens physisch getrennt voneinander gespeichert werden können.

Die Notwendigkeit, Systeme in hoher Frequenz miteinander kommunizieren zu lassen, kann beispielsweise eine kontrollierte Redundanz von Informationen (Sichwort: "replizierte" Datenhaltung) in einem DDB-Netz sinnvoll erscheinen lassen. Verschiedene Anwendungsbereiche werden so von identischen Datenstrukturen aus bedient, benötigen dazu jedoch nicht das teure und oft überlastete System von Kommunikationsnetzen und ermöglichen außerdem, den Austausch von Transaktionen zwischen Systemen. Ein ab schließendes Argument für die Einführung verteilter Systeme sind die Kosten. Es ist die billigste Lösung, Daten dort zu pflegen, wo sie entstehen oder zumindest häufig gebraucht werden.

Umfangreiche Übertragungs- und Abstimmungsaktivitäten fallen somit erst gar nicht mehr an.

Die Erwartungen sind hoch, doch die Möglichkeiten der verteilten Datenverarbeitung beschränken sich technisch derzeit auf die Implementierung von

- File Transfer,

- Transaction Processing und

- "Distributed Databases" (DDB).

In bestimmten produktiven Umgebungen haben alle drei Techniken und ihre verschiedenen Mischformen ihre Daseinsberechtigung und werden auch entsprechend eingesetzt. Hier soll jedoch vor allem auf die Möglichkeiten verteilter Datenbanksysteme eingegangen werden.

Die Daten erscheinen als logische Einheit in einer verteilten Datenbankumgebung erscheint dem Anwender - Programmierer oder Endbenutzer - die Gesamtheit aller Daten als eine Einheit, eine "logische Datenbank". Dabei hat er bei seinen Aktionen weder auf den physischen Speicherungsort Rücksicht zu nehmen, noch muß er wissen, von wo letztlich seine Daten geholt oder wohin sie zurückgespeichert werden.

Diese Vorgänge bleiben für den Anwender unsichtbar oder, wie es im Fachjargon heißt, "transparent". Das Wissen über Verteilung, Strukturierung, Netzart und physische Speicherorte ist im Datenbanksystem beziehungsweise in seiner verteilten Variante festgelegt.

Das unterscheidet sich deutlich von Funktionen, wie sie heute unter dem Begriff "verteilte Datenbank" von den meisten DBMS-Herstellern angeboten werden. Um nämlich vom systemtechnischen Umfeld unabhängige, portable Anwendungen zu erhalten, ist auch in einem Netz verteilter Datenbanken die Transparenz dieser Verteilung gegenüber den eingesetzten Anwendungsprogrammen gefordert.

Dies bedeutet jedoch, daß die Kenntnis über den Ort, an dem die Daten physisch liegen, nicht in die Programme eingebettet sein darf. Vielmehr müssen von Kontrollmechanismen des DBMS zusammen mit dem Netzwerk-Treiber die gewünschten Daten jederzeit an ein beliebiges Programm im DDB-Netz geliefert werden können

Die Notwendigkeit, den Knoten zu kennen, an dem die Daten, die eine Applikation benötigt, liegen, verhindert die Unabhängigkeit der Programme gegenüber Datenstrukturierung im Netz und macht DB-übergreifende Operationen unmöglich Der Nutzen "verteilter DB-Systeme" kann aber gerade dann in Frage gestellt werden - und wird natürlich auch zurecht angezweifelt -, wenn nicht alle Anforderungen an die Fähigkeiten eines DDB-Systems vollständig erfüllt werden.

Die Technik "verteilter Datenbanksysteme" wird für die kommenden Jahre eine der wichtigsten Entwicklungen im Rahmen von DB-Systemen darstellen, darüber sind sich die Experten einig. Mit mächtigen Verteilungsfunktionen lassen sich nämlich heterogene Rechner- und Systemumgebungen innerhalb eines Unternehmens wieder zu einer organisatorischen Einheit zusammenfügen und integriert nutzen.

DDB-Mechanismen sind folglich so zu implemetieren, daß die Unternehmensorganisation optimal, gemäß den Markterfordernissen und den betriebswirtschaftlichen Erwägungen, ausgelegt werden kann Nicht die Technik bestimmt also zukünftig Organisationsstrukturen von Unternehmen, sondern die unternehmensindividuelle Notwendigkeit tritt wieder in den Vordergrund.

Untersuchungen haben gezeigt, daß die Frage nach dem Bedarf verteilter Datenbanken häufig durch organisatorische Lösungen umgangen und "verschleiert" worden ist. Bisher gibt man sich aus der Not heraus mit einem niedrigeren Aktualitätsniveau der Daten zufrieden, "weil es zur Zeit nicht anders machbar" erscheint Mit dem Einsatz verteilter Datenbanksysteme (DDB-Systeme) erwachsen aber sowohl neue Herausforderungen an die Datenbank-Technik als auch an geeignete organisatorische Umfelder.

Dazu gehört die lokale Anatomie. Jeder Knoten eines verteilten System repräsentieren. Die Kontrolle und Verwaltung der lokalen (Knoten-) Daten erfolgt über das lokale DBMS.

Datensicherheit, Zugriffsschutz, Datenintegrität und Buffer-Management sind an jedem Knoten unabhängig von der an geschlossenen Netzumgebung gewährleistet. Darüber hinaus müssen die durch das verteilte System bedingten zusätzlichen Kontrollaktivitäten - Sperren, -Authorisierungskontrolle, Integritätskontrolle - greifen.

Anwendungen mit dem Zugriff auf ausschließlich lokale Daten sollen unbeeinflußt vom Zustand des Gesamtsystems und der Gesamtumgebung ablaufen und dürfen nicht von der Fähigkeit anderer Knoten abhängen Andererseits darf ein DDB-Knoten aber auch nicht von eine zentralen System abhängig sein Lokale Autonomie schließt die Gleichberechtigung aller Knoten für alle Funktionen ein Das betrifft besonders Aktivitäten wie das Einrichten neuer Tabellen und Benutzer, Berichtigungen und/oder die Abwicklung von Recovery-Maßnahmen.

Die Abhängigkeit von einem zentralen DDB-Knoten hätte fatale Folgen hinsichtlich (vorprogrammierter) Systemengpässe und Systemanfalligkeit. So sind also auch Funktionen wie Data-Dictionary, Query-Optimierung, Sperrmaßnahmen und Datensicherheitsoperationen "verteilt" durchzuführen.

In einem verteilten System sollte es - ebenso, wie in einer nichtverteilten DBMS-Umgebung - keine Notwendigkeit zum Herunterfahren des Gesamtsystems geben. Ein DDB-System kann diese Anforderung nur erfüllen, wenn es in der Lage ist, während des laufenden Betriebs:

- Knoten hinzuzufügen oder zu entfernen,

- Kopien eines Datenbestandes (Replikate) anzulegen oder zu löschen,

- Fragmente von Tabellen zu erzeugen oder wieder zusammenzulegen und

- Anwendungen unbeeinflußt von Änderungen der physischen Verteilung ablaufen zu lassen.

Mit der Technik statischer Befehlsauflösung, wie sie etwa bei DB2 von IBM eingesetzt wird, lassen sich diese Bedingungen nicht erfüllen.

Grundsätzlich sollte für verteilte Systeme gelten, daß ein Benutzer/Programm nicht zu wissen braucht, wo die Daten in einem DDB-System physisch gespeichert sind. Das DBMS muß selbständig feststellen können, wo die angeforderten Daten zu finden sind. Die Lokalisierung hat sich automatisch an Veränderungen in der physischen Verteilung der Daten anzupassen. Es dürfen keine Einschränkungen hinsichtlich sich ein "Request" auf entfernte Daten bezieht.

Ziel eines verteilten Datenbanksystems ist es, möglichst viele Daten am Ort der Verarbeitung zu halten Dabei haben sich physische und logische Größen wie eine Tabelle den organisatorischen Anforderungen eines Unternehmens unterzuordnen Dies wiederum stellt höchste Anforderungen an die Flexibilität der Verteilungsmechanismen im DDB-System.

Ein funktionierendes DDB-System unterstützt eine beliebig häufige Replikation von Daten. Replizierte und damit kontrolliert redundante Daten erhöhen die Zugriffsgeschwindigkeit (Performance) und die Datenverfügbarkeit - solange noch eine gültige Kopie im DDB-Netz existiert.

Schwierigkeiten entstehen jedoch bei der Aktualisierung aller Replikate im Rahmen von Datenveränderungsfunktionen: Dann sind eine eine erhöhte Systembelastung, schlechtere lokale Antwortzeiten und Sicherheitsprobleme bei nichtverfügbaren Knoten zu erwarten.

Eine Lösung hierfür würden sogenannte "Snapshots" bilden. Sie stellen einen Extrakt aus Basistabellen dar, der separat abgespeichert wird. Solche "Snapshot"-Daten besitzen die Aktualität der Daten zum Zeitpunkt ihres "Einfrierens". Der Unterschied zwischen "Snapshot"-Daten und einem "View" liegt in der unterschiedlichen Aktualität der Daten. Deshalb ist die Verwendung von "Snapshots in operativen DB-Umgebungen mit Vorsicht zu genießen.

Kritischer noch als in relationalen Datenbanksystemen ist die Leistung der Optimierungsfunktionen ("Optimizer") in einem DDB-System Bedingt durch weite Strecken und lange Übertragungszeiten können ineffiziente Befehlsauflösungen katastrophale Antwortzeiten auslösen.

Hauptkriterium für den "Optimizer muß dabei die Minimierung der Übertragungszeit und der I/O-Operationen, gefolgt von der Minimierung des CPU-Zeitbedarfes, sein. Eine zweite Stufe der Optimierung wird von den lokalen DBMS am lokalen Knoten durchgeführt. Hier leisten relationale DBMS heute schon mehr oder weniger gute Arbeit.

Der Benutzer von DDB-Systemen sollte keine Kenntnis darüber benötigen, welche Knoten in seine Transaktionen involviert sind. Das DDBMS hat ihm gegenüber dieselbe Sicherheit bezüglich Datenintegrität und Recovery-/Restart-Verfahren zu bieten sie wie bei lokaler Verarbeitung.

Probleme, die hier auftreten, sind vorwiegend technischer Art und noch nicht bis ins Detail zufriedenstellend gelöst. Außerdem erfordert diese DDBS-Fähigkeit aufwendige Koordinierungsaktivitäten der lokalen Datenbanksysteme sowie systemübergreifende "Deadlock"-Erkennung und Unterbreichungsmöglichkeiten in der Koordinationsphase (Commit-Phase).

Ein DDBS ist theoretisch auf Systemen unterschiedlicher Rechnertypen mit unterschiedlichen Betriebssystemen uneingeschränkt einsetzbar Dadurch kann es zu einem wichtigen Integrator heterogener System- und Hardware-Umgebungen werden. Dennoch stellt diese Forderung hohe und höchste Ansprüche an die Portabilität und Offenheit von Datenbank-Software. So sollte ein DDB System unterschiedliche Kommunikationswege zwischen den Knoten unterstützen.

Keinesweges trivial ist die Forderung, daß DDB-Systeme mit unterschiedlichen lokalen Datenbanksystemen zusammen arbeiten können. So ist selbst die SQL-Datenbank-Abfragesprache in den verschiedenen SQL-Systemen keineswegs identisch.

Sind jedoch all diese Bedingungen erfüllt, steht dem Siegeszug verteilter Datenbanksysteme nichts mehr im Wege. Der Einstieg in diese Technologie muß allerdings heute schon vorbereitet werden. Voraussetzungen hierfür sind:

- ein Datenmanagement, das die Koordination der lokalen Bereich des Datenmanagements übernimmt,

- homogenisierbare Datenbank-Basissoftware an allen einzubeziehbaren Standorten und

- Verifizierung aller Anwendungssoftware hinsichtlich ihrer Eignung für DDB-Umgebungen.

Der Vorgang der Informationsbedarfsanalyse für die Auftraggeber, sprich Fachabteilungen, wird um eine neue Dimension erweitert. Er muß "global" durchgeführt werden. Dabei sind Faktoren wie

- Aktualitätsbedarf,

- Verteilungsbedarf,

- Verteilungsmodell und

- Aktualisierungskonzept

in diese Betrachtungen einzubeziehen. Ein Verteilungsmodell wird daher in einer sinnvollen Lösung aus einer Kombination von verteilten Transaktionen, replizierten (redundanten) und partitionierten Daten bestehen.

Nach welchen Kriterien sich der Verteilungsbedarf ausrichtet und wie er letztlich realisiert wird, muß vom Unternehmen in einem individuellen Prozeß der Entscheidungsfindung festgelegt werden. Dabei ist es unerläßlich, die fachlichen Vertreter der Bereiche einzubeziehen.

Nur wenn dieses Umfeld klärbar und geklärt ist, kann der erwartete Nutzen aus der Technologie der verteilten Informationsverarbeitung gezogen und Effizienz und Flexibilität im Unternehmen verbessert werden.

Josef Kraus ist Geschäftsführer der Sysco Consulting J. Kraus in Ottobrunn.