Von Birgit Demuth*
Fuer Anwendungsprogrammierer stellt sich eine Reihe von Fragen, wenn es darum geht, ein Datenbankprogramm in einem Client-Server- Umfeld zu entwickeln. Schon allein die Transparenz oder Nichttransparenz der Verteilung ist ein Thema fuer sich. Eine aus technischer Sicht einfache Alternative zur verteilten Datenbank stellt die entfernte Datenbank dar, die sich in verschiedenen Auspraegungen realisieren laesst. So kann zum Beispiel die Transaktionslogik auf dem Server liegen - ein Szenario, das etwa von SQL-92 unterstuetzt wird.
Das Schlagwort "Verteilung" ist zum Synonym fuer die verschiedensten heterogenen Software- und Hardware-Architekturen geworden. Es impliziert zunaechst die Frage, was verteilt wird. Betrachten wir im Rahmen von datenbankgestuetzten Applikationen die Verteilung der Anwendungsfunktionalitaet, geht es um eine Client- Server-Architekturvariante. Der historisch gesehen aeltere Gesichtspunkt ist jedoch der der Distribution von Daten. In seiner vollen Auspraegung wird damit die verteilte Datenbank assoziiert. Gegenwaertig ist der Trend zu einer Kombination beider Verteilungsaspekte zu beobachten.
Eine Datenbankanwendung kann als ein System, bestehend aus den Komponenten Praesentation (meist grafische Benutzeroberflaeche), Datenbank (DB) und der eigentlichen Anwendung (Anwendungslogik oder -kern genannt), betrachtet werden. Das Konzept einer Client- Server-Architektur beinhaltet grundsaetzlich die Verwaltung der von vielen Anwendungen genutzten Datenbank auf einem leistungsfaehigen Rechner (Server) und die Praesentation auf einem Arbeitsplatzcomputer (Client).
Entfernte Datenbank und fetter Client
Varianten fuer Client-Server-Architekturen ergeben sich aus der Verteilung der Anwendungslogik sowie der denkbaren Auslagerung von Teilfunktionen der Praesentation beziehungsweise der Datenverwaltung auf den Server oder Client. Ziel ist es, ein den jeweiligen Bedingungen angepasstes, optimales Gleichgewicht zwischen Client und Server zu erreichen. Uebliche Architekturvarianten, die durch die meisten der derzeit kommerziell genutzten Entwicklungswerkzeuge unterstuetzt werden, sind die entfernte Datenbank und die verteilte Anwendung. Dass eine lokale Datenbank auf dem Client verwaltet wird, ist dabei nicht ausgeschlossen.
Im Fall der entfernten DB laufen Praesentation und Anwendungskern vollstaendig auf dem Client (Variante des "fetten" Client). Datenbankzugriffe erfolgen meist in Form von SQL-Anweisungen ueber eine normierte oder proprietaere Schnittstelle. Der Client wird "schlanker", wenn die Anwendungslogik auf Client und Server liegt. Dabei ist es sinnvoll, den ereignisorientierten Teil auf den Client und komplexe Auswertungs- und DB-Zugriffsfunktionen (Geschaeftslogik) auf den Server zu legen.
Der Zugriff auf die Geschaeftslogik der Daten geschieht ueber entfernte Prozeduraufrufe. Da sich die Geschaeftslogik - im objektorientierten Kontext die Methoden der Objekte - bei vielen Applikationen gleicht, sollte das Konzept der Stored Procedures moderner relationaler Datenbank-Management-Systeme (DBMS) genutzt werden, um diesen Teil der Anwendungslogik in die Datenbank zu integrieren.
Nehmen wir im folgenden die Position eines Anwendungsprogrammieres ein, der die Aufgabe hat, eine DB-Anwendung zu entwickeln, deren Praesentation und Anwendungslogik auf einem PC oder einer Workstation liegt. Die Daten muessen jedoch ueber ein Netzwerk aus einer entfernten Rechnerwelt besorgt werden. Aus dieser Sicht sind zwei wesentliche Fragen zu beantworten:
- Ist die Datenverteilung (welche Datenbanken auf welchen Rechnern) zu sehen, oder erscheinen die Daten aus der entfernten Rechnerwelt wuenschenswerter Weise als eine homogene Datenbank?
- Wie erfolgt der Zugriff auf die Daten?
Betrachten wir zunaechst die Transparenz der Datenverteilung. Die seit vielen Jahren propagierte Idee, jedoch bislang schwerfaellig realisierte Technologie, ist die der verteilten Datenbank (VDB): eine Art virtuelle Datenbank, die sich aus der Verbindung von auf mehrere Knoten eines Rechnernetzes verteilten, real existierenden Datenbanken ergibt. Entscheidend daran ist, dass sich die Daten dem Anwendungsprogramm gegenueber so praesentieren, als waeren sie auf nur einem Rechnerknoten gespeichert und wuerden von einem homogenen DBMS verwaltet.
Neben diesem fundamentalen Prinzip formulierte der bekannte Lehrbuchautor Chris Date weitere zwoelf Regeln, die sich jedoch mehr auf die Architektur und die Funktionsweise eines verteilten Datenbanksystems VDBS beziehen. Die Regeln druecken zugleich die technischen Probleme bei der Realisierung einer solchen Loesung aus. Zusammengefasst liegen diese vor allem:
- in der Aufrechterhaltung der Autonomie der lokalen DBMS;
- in der Ueberwindung der Heterogenitaetsbarrieren zwischen den beteiligten lokalen DBMS, den Betriebssystemen, den Netzwerken und Hardware-Architekturen;
- in der Implementierung einer effizienten Anfrageverarbeitung;
- in der Katalogverwaltung (Verwaltung des globalen Schemas, das dem Anwendungsprogrammierer bekannt ist, und der lokalen Schemen, die das VDBS kennen muss);
- in der Unterstuetzung replizierter Daten;
- in der Unterstuetzung partitionierter Tabellen, um eine Tabelle ueber mehrere Rechnerknoten zu verteilen, sowie
- in einem verteilten Commit-Mechanismus, um Aenderungen ueber alle betroffenen Rechnerknoten hinweg synchronisieren zu koennen.
Diese Probleme haben zu der nur zoegerlichen Kommerzialisierung verteilter Datenbank-Management-Systeme (VDBMS) gefuehrt. Inzwischen bieten alle fuehrenden Hersteller relationaler DBMS Produkte zum Aufbau verteilter Datenbanksysteme an. Sie erfuellen im wesentlichen die Forderungen, die an verteilte DBMS gestellt werden. Die Architektur dieser Systeme differiert aber erheblich: Waehrend Oracle 7 die Funktionalitaet eines VDBMS mittels eines Servers realisiert, verteilen Sybase und Ingres diese auf mehrere Produkte.
Die - aus der Sicht der technischen Realisierung - einfache Alternative zur verteilten Datenbank ist die entfernte Datenbank. Dabei sieht der Anwendungsprogrammierer die entfernten Datenbanken und kann auf sie meist auch simultan zugreifen. Es sind verschiedene Szenarien moeglich. Im Sinne der zuvor gewaehlten Client-Server-Architektur wird davon ausgegangen, dass die Transaktionslogik auf dem Server liegt. Die neue Datenbanksprachennorm SQL-92 unterstuetzt das Szenario der entfernten Transaktion. Eine CONNECT-Anweisung initiiert eine Sitzung und gleichzeitig eine Transaktion auf einem DB-Server S1:
CONNECT TO S1 AS C1; <sql-anweisungen>
Weitere Sitzungen beziehungsweise Transaktionen koennen initiiert werden, es ist jedoch stets nur eine aktiv. Die restlichen Verbindungen sind ruhend und lassen sich mit SET CONNECTION wieder aktivieren, etwa:
CONNECT TO S2 AS C2;
<sql-anweisungen>
...
SET CONNECTION C1;
<sql-anweisungen>
...
DISCONNECT ALL;
Die Moeglichkeit, in eine andere Sitzung zu wechseln, bevor die Transaktion der aktuellen Sitzung zu Ende ist, haengt von der Implementierung ab. Der Anwendungsprogrammierer steuert den Zugriff auf die entfernten Datenbanken und verknuepft die Daten von verschiedenen Rechnerknoten in seinem Anwendungsprogramm.
Datenverknuepfung auf dem Server
Der naechste Schritt auf dem Weg zur verteilten Datenbank ist der verteilte Zugriff. Die Anweisungen einer Transaktion auf einem entfernten DB-Server beinhalten den Zugriff auf weitere DB-Server, etwa auf S2:
CONNECT TO S1 AS C1;
SELECT * FROM T1 NATURAL JOIN S2.T2;
DISCONNECT C1;
Im Unterschied zum vorigen Szenario werden die Daten von mehreren Knoten nicht auf dem Client, sondern auf dem DB-Server (S1) verknuepft. Falls nun die Zuordnung der Tabellen T1 und T2 zu den Datenbank-Servern S1 beziehungsweise S2 nicht mehr gesehen wird, ist die Transparenz der Datenverteilung erreicht. Der CONNECT- Befehl kann unter Umstaenden entfallen, je nachdem, welche Komponente des Gesamtsystems die Verteilung steuert.
Die Art des Datenzugriffs fuehrt uns zum gegenwaertig recht strapazierten Begriff der Middleware (oder auch der Connectivity- Software): Sie umfasst die verschiedensten Schnittstellen und deren Realisierungen fuer den Zugriff auf entfernte Daten oder Dienste. Die Client-Anwendung kommuniziert ueber eine solche Schnittstelle mit dem Server. Das Interface wird syntaktisch durch ein Application Programming Interface (API) repraesentiert. Die dahinter versteckte Semantik interpretiert ein Kommunikationsprotokoll. Zusaetzlich wird ein Netzwerkzugriff fuer verschiedene Netzprotokolle benoetigt, um Nachrichten an den physisch entfernten Rechner weiterzuleiten.
Middleware-Umgebungen werden oft mit Begriffen wie DLE, DME, Corba und OLE 3.0 assoziiert. In der hier definierten Umgebung sieht der Anwendungs-programmierer lediglich sein API. Dies kann entweder eine proprietaere oder eine normierte Schnittstelle sein. Typische proprietaere Schnittstellen sind Gateways oder Router.
Angenommen, ein Anwendungsprogramm oder Datenbanksystem X muss auf ein inkompatibles Datenbanksystem Y zugreifen, so wird ein API zur Verfuegung gestellt, das Y wie X "aussehen" laesst. Ein Gateway realisiert die Transformation des Datenzugriffs von System Y auf die Form des Datenzugriffs und -austauschs des Systems X. Es beinhaltet unter anderem die Interpretation von SQL-Anweisungen, Dictionary-Eintraegen, Datentypen, Datenwerten und Rueckkehrcodes.
Mehrere Normen fuer offene Schnittstellen
Diese Form der Implementierung eines APIs kann sehr effizient sein, da die spezifischen Eigenschaften des betreffenden DBMS ausgenutzt werden. Der Nachteil ist, dass man zur Sicherung einer vollen Interoperabilitaet zwischen n Datenbanksystemen n(n-1) Gateways bereitstellen muss. Ausser der expliziten Nutzung von Gateways durch den Anwendungsprogrammierer werden sie auch genutzt, um heterogene verteilte DBS zu implementieren.
Die Alternative zu Gateways stellen offene Schnittstellen dar, da es bereits eine Reihe von Normen beziehungsweise von De-facto- Standards gibt. Es existieren zum einen die Vertreter der Call- Level-Interfaces der SQL Access Group (SAG/CLI) und zum anderen die ISO-Norm RDA sowie die DRDA-Spezifikation von IBM. Das SAG/CLI bietet einem Client die Moeglichkeit, ueber dynamische SQL- Anweisungen, die in Funktionsaufrufe eingebettet sind, mit einem DB-Server zu kommunizieren und die angeforderten Daten ueber diese Schnittstelle zu erhalten. Microsofts Variante von SAG/CLI ist die ODBC-Schnittstelle (Open Database Connectivity), eine C-API- Spezifikation fuer den einfachen Zugriff von Windows-Anwendungen auf verschiedene Datenbanken. Bei der anderen kommerziell bedeutenden SAG/CLI-Implementierung handelt es
sich um die IDAPI-Spezifikation (Integrated Database Application Programming Interface), die insbesondere fuer die Interoperabilitaet von Borland-Produkten entwickelt wurde.
Es sei noch darauf hingewiesen, dass die ISO-SQL92-Norm in Kuerze um ein Addendum SQL/CLI erweitert und die SAG/CLI-Notation damit weitere Bedeutung erlangen wird.
Eine umfassende und komplexe Loesung fuer den Zugriff auf entfernte Datenbanken bietet die ISO-Norm RDA (Remote Database Access). In ihrer SQL-Spezialisierung unterstuetzt sie die Interoperabilitaet zwischen verschiedenen SQL-DBMS. Es werden neben Datenbankoperationen Funktionen zur Verbindungskontrolle und Transaktionsverwaltung angeboten. RDA ist in die Anwendungsschicht des ISO/OSI-Referenzmodells fuer offene Systeme eingeordnet und damit herstellerunabhaengig.
Die DRDA-Spezifikation (Distributed Relational Database Access) fuehrt ein SQL-Interface fuer den Zugriff auf verteilte relationale IBM-Datenbanken ein. Die Idee besteht darin, dass die Middleware die Datenverteilung bereits kennt und den SQL-Befehl des Anwendungsprogramms in mehrere Teilbefehle fuer die einzelnen Datenbanken splittet. Das DRDA- Interface ist mit SAG/CLI und RDA nicht kompatibel.
Unabhaengig davon, welches API fuer den Zugriff auf verteilte Daten benutzt wird, ist sowohl die Realisierung einer Client-Server- Architektur als auch einer entfernten Datenbank oder verteilten Anwendung denkbar.
* Dr. Ing. Birgit Demuth ist wissenschaftliche Assistentin an der Fakultaet fuer Informatik der TU Dresden und beschaeftigt sich dort mit Fragen der Datenbank- und Softwaretechnologie.