2.2 Datenbankschnittstelle

	Sign In Sign-Up

2.2 Datenbankschnittstelle

2.2.1 Nativer Datenbankzugriff

Als Standardabfragesprache für relationale Datenbank-Managementsysteme hat sich heute SQL etabliert, wobei die meisten DBMS-Hersteller dieses ANSI-SQL für Ihre Produkte um spezifische Funktionen erweitert haben.

Für die Entwicklung von Client/Server-Anwendungen haben alle Hersteller eigene, proprietäre Programmierschnittstellen und DBMS-Protokolle (für den Datenaustausch zwischen Client-Applikation und Datenbank-Server) entwickelt, so daß ein Web-Datenbank-Gateway für den nativen Zugriff auf das DBMS, d.h. unter Benutzung der DBMS-spezifischen API, an jedes Produkt, welches benutzt werden soll, individuell angepaßt werden muß.

Vorteile

maximale Performance beim Datenbankzugriff
Nutzung aller Datenbank-spezifischen Funktionen möglich

Nachteile

Gateways mit nativem Datenbankzugriff sind an einzelne oder wenige Produkte gebunden
Anwendungen, die proprietäre Datenbankfunktionen nutzen, sind nicht oder nur mit Änderungen auf andere Datenbanksysteme portierbar

2.2.2 ODBC - Open Database Connectivity

ODBC ist ein offener, Hersteller-unabhängiger Standard für den API-Zugriff auf Datenbank-Managementsysteme. Er wurde von Microsoft in Zusammenarbeit mit der SQL Access Group (SAG), X/Open und weiteren Softwareherstellern entwickelt und bietet eine auf ANSI-Standards basierende SQL-Sprache an.

Eine Applikation, die ihre Datenbankzugriffe auf Grundlage der ODBC-API realisiert, kann über DBMS-spezifische ODBC-Treiber mit verschiedensten Datenquellen - auch parallel - zusammenarbeiten. Außerdem wird ein Treiber-Manager benötigt, der zwischen Applikation und Treiber sitzt. Auf Windows-Plattformen sind Treiber und Manger als dynamik-link libraries (DLLs) implementiert. Abbildung 10 zeigt die ODBC-Architektur im Überblick.

Abbildung 10: Die ODBC-Architektur

In [W9] werden unterschiedliche (auch Multiple-Tier) Treiberarchitekturen vorgestellt, wodurch ODBC-fähige Web-Datenbank-Gateways mit einer solchen Treiber-Architektur ohne zusätzliche Programmierung auch mit auf unterschiedlichen Hosts verteilten Datenbanken arbeiten können.

Vorteile

hohe Portabilität: für praktisch jedes verfügbare DBMS existieren ODBC-Treiber oder sind in der Entwicklung
Datenbanken können ohne zusätzlichen Programmieraufwand auf andere Hosts als den des Web-Servers ausgelagert werden

Nachteile

durch Konvertierungs-Overhead niedrigere Performance gegenüber nativen Datenbankzugriffen
DBMS-spezifische Funktionen, die nicht in ODBC enthalten sind, können nicht genutzt werden
teilweise Stabilitätsprobleme mit ODBC-Treibern von Drittanbietern (nicht Microsoft)

2.2.3 JDBC - Java Database Connectivity

JDBC ist, ähnlich wie ODBC, eine Schnittstellendefinition für die Produktunabhängige Kommunikation von Anwendungen mit Datenbanken, allerdings für die Programmiersprache Java. Auf Java wurde in Abschnitt 2.1.7 bereits ausführlicher eingegangen.

JDBC wird von Sun in Koordination mit allen namhaften Datenbankherstellern entwickelt und ist seit der Version 1.1 des Java Development Kit als fester Bestandteil in Java integriert (vgl. [W13]).

Die Programmierschnittstelle definiert Java-Klassen für Datenbankverbindungen, SQL-Befehle, Ergebnismengen, Datenbank-Metadaten usw. und ermöglicht so dem Programmierer das Abschicken von SQL-Statements und die Verarbeitung der Ergebnisdaten.

Implementiert ist das JDBC-API mittels eines Treibermanagers, der mehrere Datenbanktreiber unterstützt. Die wiederum können verschiedene Datenbanksysteme ansprechen. JDBC-Treiber können komplett in Java geschrieben werden, so daß sie als Teil eines Java-Applets über das Web runtergeladen werden können, oder aber mittels nativer Methoden auf existierende Datenbankzugriffsbibliotheken zurückgreifen.

Für Treibertypen, die nativen Code benötigen, muß dieser für jeden Web-Client separat geladen und installiert werden. Deshalb halte ich den Einsatz solcher Treiber nur auf Serverseite für sinnvoll, z.B. für einen in Java programmierten Applikationsserver in einer Three-Tier-Architektur, oder begrenzt für Intranetanwendungen in homogenen Umgebungen.

Es gibt vier Kategorien von JDBC-Treibern ([W13], jdbc.drivers.html):

JDBC-ODBC-Bridge
Die JDBC-ODBC-Bridge ist ebenfalls eine Entwicklung von Sun und ermöglicht die Datenbankanbindung über existierende ODBC-Treiber. Sie benötigt zusätzlichen ODBC-Binärcode und in vielen Fällen Datenbank-Clientcode. Sun selbst empfiehlt, wenn möglich diesen Treiber nicht zu verwenden und statt dessen einen "PureJava"-Treiber (ohne Binärcode) einzusetzen, um Abstürze der Java Virtual Machine durch fehlerhaften nativen Code zu vermeiden ([W13], #The JDBC-ODBC Bridge Driver).
Native-API-partly-Java-Treiber
Diese Treiber wandeln JDBC-Aufrufe in solche für proprietäre Client-APIs wie z.B. von Oracle, Sybase, Informix, DB2 oder anderen Datenbanksystemen. Auch dieser Typ benötigt Binärcode.
Net-Protocol-All-Java-Treiber
Bei dieser wohl flexibelsten Lösung werden JDBC-Aufrufe in ein DBMS-unabhängiges Netzprotokoll übersetzt, das wiederum von einem Server in ein DBMS-Protokoll gewandelt wird. Diese Netzserver-Middleware ist in der Lage, seine komplett in Java geschriebenen Clients an die unterschiedlichsten Datenbanken anzubinden. Das Netzprotokoll zwischen Client und Middleware ist Treiberhersteller-spezifisch.
Native-Protokoll-All-Java-Treiber
JDBC-Treiber dieser Kategorie konvertieren JDBC-Aufrufe direkt in ein DBMS-spezifisches Netzwerkprotokoll. Das erlaubt direkte Aufrufe vom Clientrechner an den Datenbankserver.

Sofern Java die Programmiersprache der Wahl ist, ist es sicher naheliegend, auf die JDBC-API zurückzugreifen, wobei auch hier wie bei ODBC anhand der geplanten Anwendung zwischen Kompatibilität und Performance abgewogen werden muß.