Nur einfache Loesungen haben eine Chance, so jedenfalls Raymund Vorwerks* Meinung. Verteilte Datenbanken zaehlen jedoch nicht zu den leicht realisierbaren Dingen des DV-Alltags. Eine Alternative stellen aus seiner Sicht Objekte dar, die aus Daten und Funktionen bestehen. Sie bewegen sich ueber das Netz zum jeweiligen Adressaten. Der Server verwaltet nur noch den Thesaurus.
Wenn ueber Verteilung gesprochen werden soll, gibt es zwei Aspekte, die man beachten muss: Was soll verteilt werden, und wohin soll es verteilt werden. Der Zweck der Verteilung an sich wird zunaechst ausgeklammert.
Beginnen wir mit dem Was. Es ist ein Irrglaube, dass dem Verteilungsaspekt Genuege getan wird, wenn Daten - in welcher Granularitaet auch immer - dezentral gelagert werden. Sie haben ohne die zugehoerigen Verarbeitungsfunktionen keinerlei Bedeutung.
Die Verteilung von reinen Daten impliziert also sinnvollerweise auch die Distribution der ihnen zugeordneten Verarbeitungsfunktionen. Dies zieht die Bereitstellung der entsprechenden Infrastruktur nach sich, die fuer die Ausfuehrung der Funktionen notwendig ist. Die ausschliessliche Datenverteilung kann, wenn ueberhaupt, nur ein erster unvollstaendiger Schritt sein.
Der andere Aspekt beschaeftigt sich mit der Frage, wohin etwas verteilt werden kann. Grundsaetzlich ist jede Infrastruktur, die Daten verwaltet und verarbeitet, geeignet. In der heutigen Terminologie sprechen wir hier von Client-Server. Daten werden auf einen oder mehrere dezentrale Server verschoben oder kopiert, wobei man davon ausgeht, dass die betreffenden Clients die dazu erforderlichen Verarbeitungsfunktionen besitzen oder auch nicht. Client-Server als verkleinertes Abbild der bekannten Master-Slave- Grossrechnerarchitektur? Grob ausgedrueckt, trifft das in vielen Faellen tatsaechlich zu.
Replikate bergen die Gefahr von Inkonsistenz
Im Zusammenhang mit verteilten Datenbanken ist zudem eine weitere Begriffsklaerung notwendig: Erfolgt die Verteilung von Daten und Funktionen ueber "Move" oder ueber "Copy"? Beide Eigenschaften existieren in der Praxis, beide sind mit unterschiedlichen Problemen behaftet. Wenn ein Datum bewegt (move) wird, sollte man sicher sein, dass keine Kopien (Replikate) vorhanden sind. Auf konkurrierende Zugriffe und staendige Inhaltsabgleichungen kann daher verzichtet werden. Andererseits muessen Datenbewegungen nachvollziehbar sein - sie muessen eine Spur hinterlassen, damit sie sich wiederfinden lassen. Das bringt einen nicht unerheblichen Verwaltungsaufwand mit sich.
Bei kopierten Daten kann dies ein wenig anders sein: Hier existiert das Original, dessen Replikat verteilt wird. Allerdings sollten alle Veraenderungen eines Replikats allen anderen Replikaten eines Originals mitgeteilt werden. Eine solche Verteilung bereitet erhebliche inhaltliche Probleme, wenn mehrere Benutzer eines Replikats Veraenderungen vornehmen, die in der Summe - weil unkoordiniert - zu Inkonsistenzen fuehren koennen. Hier zeigt sich, dass die einfache Forderung nach Datenverteilung einen Rattenschwanz von Problemen nach sich zieht, die alle befriedigend geloest werden wollen.
Warum wird verteilt? Dafuer gibt es verschiedene Gruende. Das aelteste Argument ist die Sicherheit. Hiergegen ist nichts einzuwenden, da eine aktive Nutzung dieser Daten in der Regel nicht eintritt. Ein anderer Grund liegt im Wunsch, etwa den Netzverkehr zu verringern. Ausloeser kann aber auch die Forderung sein, dass Funktionen und Daten an der Stelle verwaltet werden, an der sie anfallen. Dieses Kriterium hat vermutlich das staerkste Gewicht, denn es beinhaltet die Delegation von Verantwortlichkeit an diejenigen, die diese auch wahrnehmen koennen. Es ist die Beantwortung der Frage, wem die Daten und Ablaeufe eigentlich gehoeren.
Wie sollte die Verteilung funktionieren? Zunaechst werden Daten und verarbeitende Funktionen zusammengefasst. Ein solches Konstrukt nennen wir, mit weiteren Eigenschaften versehen, ein Objekt. Dieses Objekt wird an den verteilt, der es benoetigt. Verteilt bedeutet hier zunaechst bewegt und nicht kopiert. Da die Verarbeitung heute, von Massenverarbeitung einmal abgesehen, auf einem Client stattfindet, ist der Adressat ein Client. Gleichzeitig wird ein Object-Trail, eine Spur gelegt, damit jeder, der dieses Objekt benoetigt, weiss, wo es sich zur Zeit befindet.
Ein wesentlicher Aspekt hierbei ist die Rolle, die das Objekt bei der Weitergabe einnimmt. Nicht jeder Benutzer muss oder darf alle Bestandteile des Objekts sehen oder gar veraendern. Durch die Rolle, die das Objekt im Kontext des Anwenders spielt, reduziert sich die Problematik der gleichzeitigen Verwendung eines Objekts. Durch die Definition einer Rolle laesst sich einfach festlegen, ob der Verteilprozess eine Kopie des Objekts oder das Original weitergibt. Wer veraendern darf, erhaelt das Original, jeder andere bekommt eine Kopie. Wer diese nicht mehr benoetigt, wirft sie - wie im richtigen Leben - weg. Das geaenderte Original jedoch wird zurueckgegeben. Je nach definierter Rolle sollten sich Kopien auch aktualisieren lassen. Das geaenderte Original informiert dann ueber den Object-Trail seine Replikate ueber den entsprechenden Eingriff.
Die Verwaltung dieser Objekte sollte mit Hilfe eines Thesaurus - der Begriff Repository soll hier vermieden werden, da der Thesaurus die Objekte selbst nicht enthalten muss - erfolgen, der ueber die verfuegbaren Objekte und ihre Rollen Auskunft gibt. Der Thesaurus kennt den Anfang des Object-Trails. Er kann ihn verfolgen und entsprechend der zugeteilten Rolle die Verteilung oder Herausgabe des gewuenschten Objekts veranlassen.
Im Prinzip handelt es sich bei dieser Art der Verteilung um ein einfaches Verfahren, das durch die Einfuehrung von Objekten - Daten und Funktionen - sowie deren Rollen moeglich wird. Der Unterschied zwischen Client und Server schwindet, da Objekte mehr sind als nur Daten und derjenige, der ein Objekt anfordert, auch die Verarbeitung verantwortlich ausfuehrt. Einzig der Thesaurus sollte tatsaechlich auf einem Server oder Host liegen. Es ist die Frage, ob diese Sicht zu einfach ist. Aber nur einfache Loesungen besitzen eine Chance auf Verwirklichung.
* Raymund Vorwerk ist Inhaber der VC Software Construction GmbH in Braunschweig.