11.3 Realisierungsaspekte

11.3.3 Datenbank-Gateways

Die überwiegende Mehrzahl derzeitiger DBVS unterstützt die Anfragesprache SQL, wodurch der einheitliche Zugriff auf mehrere LDBS - wie beim Ansatz der Verteilung von DB-Operationen gefordert - bereits erheblich vereinfacht wird. Trotzdem zeigt sich, daß praktisch keine SQL-Schnittstelle mit der anderer Hersteller übereinstimmt und zum Teil beträchtliche Abweichungen zum ISO SQL-Standard vorliegen. Dies geht zum Großteil darauf zurück, daß die ersten SQL-Standardisierungen der ISO (SQL-86, SQL-89) sehr unvollständig waren und viele kritische Punkte wie Behandlung von Integritätsbedingungen, Katalogaufbau oder Fehler-Codes nicht festlegten.

Zur Angleichung dieser Unterschiede, wie sie beim integrierten Zugriff auf DBVS mehrerer Hersteller erforderlich wird, werden DB-Gateways eingesetzt. Das Einsatzprinzip von DB-Gateways ist in Abb. 11-3 veranschaulicht. Dabei soll im Client-Programm (Anwendung oder Tool, z.B. Spreadsheet-Programm) auf SQL-Datenbanken der Hersteller A und B zugegriffen werden. Wenn der Client als Anfragesprache den SQL-Dialekt des Herstellers A (SQL-A genannt) verwendet, ist für den Zugriff auf dessen DBVS keine Konversion erforderlich. Für den Zugriff auf das DBVS des Herstellers B dagegen erfolgt eine Anpassung der SQL-Befehle und Datenformate an die von Hersteller B unterstützte Schnittstelle SQL-B. Umgekehrt transformiert das Gateway Ausgabedaten sowie Fehler-Codes in das Format von Hersteller A, das vom Client erwartet wird.
Ein Gateway kann prinzipiell entweder auf dem Client- oder dem Server-Rechner laufen. Generell führt der Gateway-Einsatz natürlich zu einer Erhöhung der Bearbeitungszeiten im Vergleich zum direkten DBVS-Zugriff. Ferner können Gateways leicht zu Durchsatz-Engpässen werden, insbesondere auf Server-Seite.

Abb. 11-3: Einsatz von DB-Gateways

Ein weiteres Problem beim Einsatz von Gateways besteht darin, daß die Zahl unterschiedlicher Gateways prinzipiell quadratisch mit der Zahl der Hersteller zunimmt, zwischen denen eine Zusammenarbeit unterstützt werden soll. Dies erfordert einen extrem hohen Aufwand zur Realisierung und Wartung dieser Gateways, da diese i.a. bei jeder Versionsänderung einer der beteiligten Produkte anzupassen sind. Dieses Problem könnte natürlich durch die Verwendung eines gemeinsamen SQL-Standards von allen Herstellern umgangen werden, was jedoch schon aus Kompatibilitätsgründen mit früheren Versionen der einzelnen DBVS nicht möglich ist. Eine starke Reduzierung der notwendigen Gateway-Anzahl läßt sich jedoch bereits erreichen, wenn client-seitig eine standardisierte SQL-Version (SQL-API) verwendet wird. In diesem Fall ist nämlich nur noch ein Gateway pro Hersteller erforderlich, um die Abbildung vom SQL-Standard in den lokalen SQL-Dialekt vorzunehmen. Die Festlegung einer solchen portierbaren SQL-Version erfolgte durch die X/Open, wobei der Sprachumfang die in den meisten SQL-Implementierungen vorkommenden Konstrukte umfaßt und auch im ISO-SQL-Standard fehlende Aspekte wie die einheitliche Definition von Fehler-Codes berücksichtigt.

Die Mehrzahl von DB-Gateways unterstützt den Zugriff auf SQL-DBVS, da hier aufgrund der weitgehenden Übereinstimmung in der Funktionalität verschiedener Systeme eine relativ einfache Realisierung möglich wird. Es wird jedoch i.a. lediglich "dynamisches SQL" unterstützt, wobei Anfragen erst zur Ausführungszeit übersetzt und optimiert werden. Dies kann vor allem für vorgeplante Anwendungsfunktionen eine erhebliche Performance-Einbuße bedeuten. Einige Gateway-Anbieter (DBVS-Hersteller) unterstützen SQL-Zugriffe auch auf Dateisysteme sowie nicht-relationale DBVS wie IMS, die selbst kein SQL anbieten. In diesem Fall wird das Gateway um die DBVS-Funktionalität des jeweiligen Herstellersystems erweitert und das nicht-relationale System lediglich als weitere Dateizugriffsschnittstelle aufgefaßt [SB90]. Es läßt sich dabei jedoch i.a. nur ein beschränkter Befehlsumfang von SQL realisieren.