11.2 Alternativen zur verteilten Transaktionsverarbeitung

11.2.3 Verteilung von DB-Operationen (Fernzugriff auf Datenbanken)

Bei dieser Verteilungsform kooperieren die Anwendungsprogramme direkt mit mehreren LDBS, um auf ihre Datenbanken zuzugreifen. Dies ermöglicht größere Freiheitsgrade zur Realisierung verteilter Transaktionen als bei der programmierten Verteilung. Das Verteilungsgranulat "DB-Operation" bedeutet, daß jede DB-Operation nur Daten eines Rechners referenzieren darf (keine Kooperation zwischen den DBS). Die Verteilung einzelner DB-Operationen verursacht jedoch einen höheren Kommunikationsaufwand als bei der programmierten Verteilung. Besonders aufwendig können Leseoperationen werden, die große Ergebnismengen zurückliefern. Denn diese Ergebnismengen werden seitens der Anwendung üblicherweise satzweise abgerufen (Cursor-Konzept). Muß jedes Ergebnistupel einzeln von einem anderen Rechner angefordert werden, entsteht ein extremer Kommunikationsbedarf, der i.a. nicht akzeptabel sein dürfte (s. Übungsaufgaben).

Zudem ergibt sich eine sehr komplexe Anwendungsprogrammierung, da nur eine geringe Verteilungstransparenz unterstützt wird. Insbesondere muß i.a. explizit mit jedem an der Verarbeitung zu beteiligenden DBS eine logische Verbindung aufgebaut werden. Operationen über mehrere Datenbanken hinweg (z.B. Join-Berechnung) sind explizit auszuprogrammieren. Ferner muß der Anwendungsprogrammierer mit mehreren DB-Schemata arbeiten, so daß die semantische Heterogenität vollständig sichtbar ist. Weiterhin führt die Weitergabe von Schemaangaben an externe Knoten zu einer reduzierten Datenunabhängigkeit der Anwendungen und beeinträchtigt die Knotenautonomie. Ortstransparenz läßt sich erreichen, wenn in den DB-Operationen logische Namen verwendet werden bzw. eine Synonym-Funktion (Kap. 4.4) unterstützt wird.

Beispiel 11-2

Die Realisierung der Geldüberweisung aus dem vorhergehenden Beispiel könnte (wiederum stark vereinfacht) mit dieser Verteilungsform folgendermaßen realisiert werden: 

    Eingabedaten lesen (Konten K1, K2; Banken B1, B2; Betrag Delta)
    BEGIN-Transaction;
     CONNECT  TO  R1.DB1 ...  (Verbindung mit DBVS von Bank B1)
     UPDATE  ACCOUNT SET  BALANCE = BALANCE - :Delta 
      WHERE  ACCT_NO = :K1; 
     CONNECT  TO  R2.DB2 ... (Verbindung mit DBVS von Bank B2)
     UPDATE  GIROKTO SET  KSTAND = KSTAND + :Delta 
      WHERE  KNUMMER = :K2; 
    COMMIT-Transaction; 
    Ausgabenachricht ausgeben; 
    Verbindungen abbauen (DISCONNECT);
Vor dem Zugriff auf ein bestimmtes LDBS muß der Benutzer zunächst eine Verbindung mit ihm aufbauen und sich authentifizieren (CONNECT). Vereinfachenderweise wurde angenommen, daß beide an der Verarbeitung beteiligte LDBS SQL unterstützen. Trotzdem erkennt man an den Objektangaben der UPDATE-Anweisungen, daß der Programmierer unterschiedliche Schemaangaben berücksichtigen muß (ACCOUNT, BALANCE, ACCT_NO vs. GIROKTO, KSTAND, KNUMMER). Dies erschwert die Programmierung und reduziert die Datenunabhängigkeit gegenüber externen Schemaänderungen. Umgekehrt bewirkt aus Datenbanksicht die Weitergabe von Informationen zum DB-Aufbau an andere Rechner eine Einschränkung der Knotenautonomie, die gerade bei Bankanwendungen kaum toleriert werden dürfte.

Um den Programmierer nicht auch noch mit unterschiedlichen Anfragesprachen zu konfrontieren, ist als Mindestanforderung die Unterstützung einer gemeinsamen Anfragesprache zur Formulierung der DB-Operationen zu verlangen. Dies ist gegeben, wenn alle beteiligten LDBS homogen sind (gleiche Produktversion desselben Herstellers). Daher wurde die Verteilung einzelner DB-Operationen auch zunächst für solch homogene Fälle unterstützt. Beispiele sind CICS Function Request Shipping (Verteilung von DL/1-Operationen), UDS-D oder Sesam-DCN, wobei die Weiterleitung der Operationen zum Teil über die DBVS erfolgt. Im Falle unterschiedlicher DBVS-Hersteller bestehen jedoch in der Anfragesprache mehr oder weniger große Unterschiede, selbst wenn alle SQL unterstützen. Zur Überbrückung solcher Unterschiede ist daher der Einsatz von DB-Gateways erforderlich (s. Kap. 11.3.3).

Abschließend sei darauf hingewiesen, daß die Unterscheidung zwischen programmierter Verteilung und Verteilung von DB-Operationen bei Unterstützung von gespeicherten Prozeduren ("stored procedures") durch das DBS weitgehend entfällt. In diesem Fall werden nämlich Anwendungsfunktionen im DBS verwaltet, die mit einer DB-Operation aufgerufen werden können. In Implementierungen wie Sybase (Kap. 19.6) können darüber hinaus innerhalb einer gespeicherten Prozedur Prozeduren anderer DBVS aufgerufen werden[50]. In der Weiterentwicklung des SQL-Standards (SQL3) ist eine Unterstützung gespeicherter Prozeduren (Persistent Storage Modules, PSM) vorgesehen, wobei für diesen Teil bereits 1995 mit einer ISO-Standardisierung zu rechnen ist. Zur Realisierung solcher Prozeduren wurde eine Vielzahl von Programmiersprachenkonstrukten im SQL-Standard aufgenommen. Daneben können jedoch auch in einer anderen Programmiersprache realisierte Prozeduren durch das DBS verwaltet und ausgeführt werden.

[50] Die Unterstützung von gespeicherten Prozeduren, Multi-Tasking sowie Kommunikationsfunktionen im DBS wird gelegentlich auch als "TP-Lite" bezeichnet, wobei das DBS einen Teil der TP-Monitor-Funktionen abdeckt [Gr93].