Die aktuelle Diskussion um Downsizing mittels Client-Server-Architektur hat zu Begriffsverwirrungen geführt. So werden die Begriffe SQL-Server und verteiltes Datenbank-Management-Konzept (VDBMS) oft - fälschlicherweise - synonym gebraucht. Michael Peltzer* bemüht sich um eine saubere Abgrenzung.

Das Angebot an verteilten Datenbank-Management-Systemen (VDBMS) hat sich inzwischen so weit entwickelt, daß es sich für den Praktiker lohnt, sich mit diesem Thema zu beschäftigen. Selbst wenn der aktuelle Stand der angebotenen Produkte noch nicht in jeder Hinsicht zufriedenstellt, so kann doch bereits entschieden werden, ob sich das eigene Haus in diese Richtung bewegen sollte.

Einheitliche Schnittstelle auf allen Knoten

Ausgangspunkt jedes VDBMS ist ein Computer-Netzwerk mit verschiedenen Rechnerknoten, die entweder lokal (LAN) oder über weite Strecken (WAN) verbunden sind. Die Knoten können nach Hardware und Betriebssoftware differieren vorausgesetzt daß verläßliche Kommunikationsdienste existieren.

Das Ideal läßt sich etwa so formulieren: Ein VDBMS bietet auf allen Knoten eine einheitliche Schnittstelle für den kontrollierbaren Zugriff auf alle im Netzwerk gespeicherten Daten der Datenbasis - und zwar ohne Berücksichtigung der aktuellen Speicherungsorte. Anders ausgedrückt: Ist ein VDBMS installiert, so kann der Benutzer (beziehungsweise eine Applikation) denselben zulässigen Request auf beliebige Daten der Datenbasis an jeden Knoten stellen und erhält jedesmal dasselbe Resultat.

Der Ausdruck "VDBMS" ist dabei ein wenig irreführend, denn er suggeriert, daß es sich um eine einzelne Softwarekomponente handelt. Tatsächlich geht es aber vielmehr um eine durch Kommunikation verschiedener Systeme erbrachte Leistung. Gerade im Idealfall ist es keineswegs ein und dasselbe Programm das auf allen Knoten läuft. In einem heterogenen Netzwerk existieren unter Umständen verschiedene DBMS-Produkte auf unterschiedlicher Betriebssystembasis.

Das Attribut "verteilt" bezeichnet die Fähigkeit einer Gruppe von DBMS-Produkten, dem Benützer - sei es eine Person oder eine Anwendung - in kontrollierbarer Weise die Gesamtdaten zur Verfügung zu stellen. Jedes einzelne System kann auf die lokalen Datenbasen der anderen zugreifen, ohne daß dies an der Schnittstelle bemerkt wird. So wird aus den an verschiedenen Knoten gespeicherten Daten eine verteilte Datenbasis, die dem Benutzer gegenüber wie eine zentralisierte Datenbank erscheint.

Sinn und Zweck der Definition

Zur Zeit gibt eine solche Gruppe von DBMS-Produkten nicht. Trotzdem hat diese Definition in verschiedener Hinsicht ihren Sinn:

- Sie legt das anerkannte Ziel der Entwicklung fest, so daß man in der Lage ist, Nutzen und prinzipielle Probleme zu erkennen.

- Sie unterscheidet VDBMS-Produkte von anderen Konzepten, etwa von einem SQL-Server.

- Sie erlaubt, Evolutionschritte zu beschreiben. Auf diese Weise kann man die Reife der verfügbaren Produkte beurteilen.

- Sie ermöglicht, die Probleme zu erkennen, die ein Anwender in seinem Unternehmen lösen muß, um ein VDBMS einzusetzen.

- Sie läßt zu, die technischen Schwierigkeiten zu betrachten, die in einem VDBM gelöst sein müssen. Hierdurch werden die verschiedenen Lösungen der Hersteller einschätzbar.

Laut Definition ist eine einheitliche Schnittstelle auf allen Knoten gefordert. Was heißt das konkret? Jedes DBMS muß denselben Set von Datenbankprimitiven und dieselbe Syntax verstehen Nehmen wir als Beispiel SQL, so bedeutet dies, daß alle DBMS-Produkte dasselbe SQL verstehen müssen. In der rauhen Wirklichkeit tritt einem aber eine Vielzahl verschiedenartiger Dialekte gegenüber.

Die Kommunikation ist der kritische Punkt

Hat das lokale DBMS die Anfrage verstanden, so muß es, falls entfernte Daten gebraucht werden, mit anderen DBMS-Produkten kommunizieren. Dies ist der kritische Punkt, denn Voraussetzung dafür sind kompatible technische Lösungen auf beiden Seiten, und zwar für

- Recovery,

- Concurrent Control,

- Integrität und

- Sicherheit.

Dadurch wird ein standardisiertes Protokoll erforderlich, das Nachrichten nach Inhalt und Format fixiert, mit denen die angesprochenen Sachverhalte reguliert werden. Folglich ist es notwendig, daß die Datentypen ineinander überführbar sind, daß ein gleichartiges Transaktions-Management vorliegt, daß Locking oder Time-Stamping in kompatibler Weise durchgeführt werden, daß identische Integritätsregeln implementiert und zueinander passende Zugriffsmechanismen sowie gegebenenfalls Verschlüsselungsprozeduren verfügbar sind.

Nehmen wir den einen SQL-Standard "SQL*" und ein Kommunikationsprotokoll "DP" an, so können wir ein VDBMS kurz beschreiben als eine Gruppe unter Umständen verschiedener DBMS-Produkte, die sämtlich SQL* und DP implementiert haben. Die Komplexität von DP liegt darin begründet, was ein VDBMS ausmacht. Es geht ja nicht nur um den Datenaustausch zwischen den verschiedenen Knoten, sondern auch darum, daß die respektiven lokalen Datenbasen als eine einzige virtuelle Datenbasis erscheinen sollen. In dieser Hinsicht kann man ein VDBMS auch negativ definieren: Es verhindert, daß der Benutzer die Komplexität, die mit der Datenverteilung wächst, selbst bewältigen muß.

Extrem hohe Anforderungen

Die Anforderungen, die die Realisierung eines idealen VDBMS stellt, sind extrem hoch. Auf der einen Seite wird die Integrität sehr heterogener Komponenten - von verschiedenen Herstellern und mit unterschiedlicher Architektur verlangt. Auf der anderen Seite ist ein Bestandteil des Ideals die volle Verteilungstransparenz. Das heißt, sowohl für Lese- als auch für Schreibzugriffe bleiben Veränderungen der Datenverteilung ohne Konsequenzen für Programme und interaktive Benutzer.

Die heute erhältlichen Produkte erfüllen dieses Ideal nicht vollständig-, sie realisierten dieses Konzept nur teilweise. Meist werden zum Beispiel identische DBMS-Produkte oder homogene Netze verlangt, um die Heterogenität zu reduzieren.

Ein Maximum an lokaler Autonomie

Auf der Seite der Transparenz gibt es ebenfalls Einschränkungen. So ist meist keine Fragmentierung von Relationen zugelassen beziehungsweise die Replikatbildung beschränkt. Oder das Produkt bietet keine volle Lokationstransparenz mit gleichzeitigem Schreibzugriff auf mehrere Knoten.

Wenn wir sagen, ein VDBMS sei eine Gruppe kooperierender DBMS, dann ist hierin die Forderung eingeschlossen, ein Maximum an lokaler Autonomie zu realisieren. Umgekehrt ausgedrückt: Es sollten nur notwendigerweise von einer Stelle aus zu erledigende Aufgaben von zeitweilig priviliegierten Knoten bearbeitet werden.

Der Grund für eine solche Design-Entscheidung ist simpel. Je höher der Grad der lokalen Autonomie, um so höher ist die Verfügbarkeit von Teilsystemen im Fehlerfall. Außerdem könnte die Zentralstelle ein Engpaß werden und die Leistung des Gesamtsystems reduzieren auch wenn auf fast allen Knoten Reserven vorhanden sind.

Hinzu kommt, daß bei verteilten Systemen, die nicht ausschließlich aus LANs bestehen, die Zeitverzögerung durch den Nachrichtenverkehr mit weitentfernten Knoten die Performance maßgeblich beeinträchtigt. In dieser Hinsicht bedeutet maximale lokale Autonomie nichts anderes als Minimierung des Nachrichtenaustausches.

Die Selbständigkeit ist niemals total

Auf der anderen Seite schließen sich völlige lokale Selbständigkeit und verteilte Verarbeitung aus. Jede Applikation, die entfernte Daten verlangt, setzt die Funktion mindestens eines weiteren funktionierenden Knotens voraus. Selbst volle Redundanz der Datenhaltung eine praktisch unsinnige Voraussetzung - führt nicht zu voller Autonomie: Da die im Netzwerk gespeicherten Gesamtdaten eine virtuelle Einheit bilden, muß über die lokalen Grenzen hinweg Integrität gewahrt bleiben.

Gehen wir von den Daten D aus, die auf den Knoten K1 und K2 redundant, gespeichert sind. Falls K1 und K2 wegen eines Netzfehlers nicht mehr kommunizieren können, muß das VDBMS verhindern, daß Anwendungen unabhängig voneinander die Daten auf K1, nennen wir sie D(K1), und die auf K2(D(K2)), verändern. Eine Möglichkeit besteht darin, D(K1) zur Primärkopie zu erklären und D(K2) gegebenenfalls zu sperren, wodurch die Gleichberechtigung der DBMS-Produkte partiell aufgehoben wird. Situationen, die das erfordern, gibt es häufiger.

Ein Knoten als Koordinator

Das zum Management verteilter Transaktionen gehörende Two-Phase-Commit-Protokoll setzt die Auswahl eines partizipierenden Knotens als Koordinator voraus. Auch Daten, die von entfernt gespeicherten anderen Daten abhängig sind, können nicht rein lokal verändert werden, sondern erfordern die Kommunikation mit anderen Knoten.

Hier sind zwei Fälle relevant: Zum einen kann es sich um Fragmente einer Relation handeln, wenn die Gesamtrelation aus einer Vereinigung disparat gespeicherter Teile besteht; zum anderen gibt es Integritätsregeln, die Daten auf verschiedenen Knoten betreffen; zum Beispiel darf keine Abteilung X auf K1 gelöscht werden, wenn zu K2, wo Mitarbeiter von X gespeichert sind, keine Verbindung besteht.

Die wichtigsten Konsequenzen aus der Forderung nach Selbständigkeit sind negativer Art. Ein VDBMS sollte keinen zentralen Katalog, keine zentrale Sicherheitskontrolle und keinen Zentralspeicher für Zugriffspfade besitzen.

Ganz simpel ein relationales DBMS

Im komm erziehen Umfeld ist durch die Downsizing-Debatte - basierend auf dem Client-Server-Konzept - der SQL-Server ins Gerede gekommen. Deshalb lohnt es sich in unserem Zusammenhang, kurz eine Abgrenzung vorzunehmen und den Zusammenhang mit einem VDBMS zu verdeutlichen.

Unter Client-Server-Konzept wird in der Presse etwas anderes verstanden als in der wissenschaftlichen Debatte, aus der der Ausdruck stammt. Es geht schlicht um ein LAN aus PCs, die entweder als Front-end-Geräte für die Benutzer (Clients) oder - zumeist die leistungsfähigeren Geräte - als Server fungieren.

Im zweiten Fall sind eine Datenbank oder zu verteilende Programme auf dem Personal Computer installiert.

Bei einer typischen verteilten Verarbeitung laufen auf dem Client-PC die Anwendungslogik und die - meist grafische Präsentationsschicht (Benutzerdialog). Dieser Client sendet SQL-Requests an den Server-PC, auf dem der, SQL-Server installiert ist. Dieses ist ganz simpel ein relationales DBMS, das die Requests verwaltet und für die Integrität der Daten sorgt.

SQL-Server und VDBMS haben also konzeptionell nichts miteinander zu tun. Allerdings könnte ein SQL-Server zu jener Gruppe von DBMS-Produkten gehören, die ein VDBMS bilden. Diese Idee ist in verschiedener Hinsicht reizvoll.

Einheitliche Sicht der Daten

Gehen wir von über weite Entfernungen verbundene LANs aus, in denen Großcomputer und PCs (als Benutzer-Front-end) vorkommen. Falls es keinen speziellen Grund gibt, die Benutzer-PCs als Speichermedium für die Datenbank zu verwenden, könnte man die von einer gewissen Anwendergruppe im wesentlichen genutzten Daten auf einen SQL-Server legen. Wären nun SQL-Server uns Host-Datenbanken VDBMS-fähig, so hätte man eine einheitliche unternehmensweite Sicht der Daten - ohne den in diesem Fall überflüssigen Überbau aus den auf jedem PC installierten DBMS-Produkten.

Verhält es sich hingegen so, daß die PC-Nutzer hauptsächlich ihre eigenen Daten verarbeiten und nur gelegentlich global zugreifen so ist das SQL-Server-Konzept gegenüber einem als VDBMS kooperierenden PC-DBMS im Nachteil, da die Verfügbarkeit voneinander unabhängiger Daten vom Funktionieren desselben Knotens, eben des Server-PCs, abhängig gemacht wird.