Bei den heutigen Datenbank-Management-Systemen (DBMS) kann man sagen, daß Typen, APIs und Funktionalitäten nicht konstant sind. Weil der DBMS-Markt heftig umkämpft ist, müssen die Anbieter ständig neue Versionen mit zusätzlichen Fähigkeiten entwickeln. Der neueste Schub von Aktivitäten um das WorldWideWeb ist ein weiteres Beispiel für den Druck, SQL-Produkten neue Funktionalität zu verleihen. Das Interesse an der Internet-Technologie hat Datenbank-Firmen veranlaßt, sich auf universelle Anbindungsmöglichkeiten und reiche Datentypen zu konzentrieren und HTML an Web-Browser zu liefern. Gut daran ist, daß das Web Verbindungen fördert. Schlecht ist, daß es eine Mentalität des "eine Größe paßt für alle" betont, die nicht sehr realistisch ist, wenn man mit den heutigen Datenbankprodukten programmiert, sogar bei APIs für multiple Datenbanken.
Nehmen Sie die Situation bei SQL-Datenbanken und Stored Procedures, auch als persistente SQL-Module bekannt. Prozeduren sind optimierte SQL-Skripte oder Module, die in der Datenbank gespeichert werden. Sie befinden sich auf dem Server und sind den Clients zugänglich. Obwohl Stored Procedures wahrscheinlich Bestandteil des zukünftigen SQL3-Standards sein werden, sind sie im heutigen SQL-Standard nicht definiert. Dies bedeutet, daß die Unterstützung von Stored Procedures je nach Implementierung des Anbieters Änderungen und Abweichungen erfahren hat, sogar über Generationen des gleichen Produkts hinweg. So waren Stored Procedures kein Bestandteil von Watcom SQL 3.2, aber in den Nachfolgeprodukten Watcom 4.0 und Sybase SQL Anywhere sind sie verfügbar. Wenn Sie Anwendungen haben, die ursprünglich Watcom 3.2 benutzten, haben Sie wohl mindestens einmal Ihren Code für SQL-Prozeduren ändern müssen. Dies werden wahrscheinlich nicht Ihre letzten Änderungen sein; der Wettlauf der SQL-Anbieter, Java als Sprache für Stored Procedures einzusetzen, hat gerade erst begonnen.
Die Black Box und Multi-Datenbank-APIs
Die Veränderlichkeit von DBMS-Produkten und Versionen bedeutet, daß der Entwickler ständig seine Datenbankprogramme anpassen muß, um mit neuen Typen, API-Revisionen und neuen Funktionalitäten Schritt zu halten. Erfahrene Entwickler versuchen oft, den Anteil des Quellcodes möglichst klein zu halten, der von diesen Änderungen betroffen ist, indem sie ihre Programme auf einem Abstraktionsniveau schreiben, das die Datenbank als eine "Black Box" behandelt.
Die ehrwürdige "Black Box" ist eine Lösung, um mit Unstimmigkeiten und Implementierungsunterschieden fertig zu werden. Sie ist eine nützliche Verallgemeinerung, die den Code isoliert, der von Unterschieden in der Implementierung betroffen ist; daher dient sie oft als Lösung für Software, die auf unterschiedlichen Plattformen laufen muß. Der UNIX-Kernel und die Windows NT-Hardware-Abstraktionsschicht (HAL) sind klassische Beispiele für das Black Box-Konzept. Ein hoher Anteil des Codes in diesen Betriebssystemen ist portabel, weil er die hardwarespezifische Logik als eine Black Box behandelt. Virtuelle Maschinen wie die Java VM sind eine Variation zum Thema; daher sind Java-Klassen hardwareunabhängig und portabel. Programmierer benutzen JAVA APIs mit einer virtuellen Maschine, einer Black Box, die ein gleichförmiges Verhalten über die Plattformen hinweg sichert. (Die Implementierungen von Java sind noch nicht vollkommen, aber im Laufe der Zeit wird Java die Black Box-Puristen sicherlich zufriedenstellen.)
Datenbankprogrammierer sehen Open Database Connectivity (ODBC) und Java Database Connectivity (JDBC) oft als APIs für virtuelle Datenbanken. JDBC und ODBC arbeiten mit einer Vielzahl von Datenbanken, und sie sind für eine Vielzahl von Betriebssystemen verfügbar. Aber obwohl ODBC und JDBC Multi-Datenbank-Produkte und Multi-Plattform-Produkte sind, mann man sie in der Art und Weise, in der sie das Black Box-Verhalten implementieren, nicht mit Java gleichsetzen. Der Unterschied zwischen Java und Datenbank-APIs ist, daß ein Datenbankprogrammierer über Server und Engines hinweg kein gleichförmiges Verhalten erwarten sollte.
Die Probleme bei der Verwendung von portablem SQL und beim Erstellen vom Logik, die auf verschiedenen Plattformen funktioniert, sind der aktuellen Lage bei Web-Browsern und HTML nicht unähnlich. Sie müssen abwägen zwischen der Benutzung von Standards mit einem Höchstmaß an Portabilität und der Verwendung von Erweiterungen, die Fähigkeiten auf Kosten der Portabilität liefern. Ein Vorteil von ODBC und JDBC ist, daß sie Multi-Datenbank-APIs sind und so Funktionalität enthalten, die es Ihrem Programm erlaubt, sich an seine Umgebung anzupassen und eine Auswahl der zu benutzenden Funktionalität zu treffen.
Außer bei sehr einfachen Anwendungen sollte ein ODBC- oder JDBC-Programm nicht so geschrieben werden, als ob das DBMS eine Black Box mit definiertem Verhalten wäre. Ladbare Datenbanktreiber erlauben es ODBC- und JDBC-Programmen, Verbindungen zu einer Vielzahl von SQL-Datenbanken aufzubauen, aber keine der beiden APIs garantiert ein konsistentes Verhalten der Treiber, des Netzwerk-Transports oder der Datenbank-Engine. ODBC bietet beispielsweise eine Funktion, die als Verbindungsoption (ODBC 2.0) oder Verbindungsattribut (ODBC 3.0) asynchrone Verarbeitung erlaubt. Asynchrone Verarbeitung bedeutet, daß die Client-Anwendung den Benutzer nicht blockiert und ihm das Weiterarbeiten erlaubt, während er auf die Beendigung einer Abfrage wartet. Wenn Sie diese Option setzen, bedeutet das aber noch nicht, daß Ihr Programm automatisch mit jedem DBMS und jeder Datenbank, zu der es verbunden ist, im asynchronen Modus arbeitet. Einige Netzwerk-Bibliotheken unterstützen keinen asynchronen Modus, und ein Aufruf der ODBC-Funktion ändert nichts an dieser Einschränkung.
Introspektion und Selbstanpassende Programmierung
Ein Mißverständnis, das ich in meinen Seminaren zur Datenbank-Programmierung zu korrigieren versuche, ist daß ODBC und JDBC keine Funktionalität voraussetzen. Die irrige Erwartung einiger Entwickler ist, daß das DBMS einem Programm, welches ODBC oder JDBC benutzt, ein bestimmtes Verhalten garantiert. Zum Beispiel definiert ODBC Konstanten für 19 Datentypen, und manche Entwickler nehmen an, daß sie diese Typen mit jedem ODBC-Treiber und DBMS verwenden können. In Wirklichkeit muß ein ODBC-Treiber nur einen Datentyp 'Character' unterstützen, um die Minimalanforderung der ODBC-Grammatik zu erfüllen.
Statt Funktionalität vorauszusetzen, berichten die ODBC und JDBC APIs, welche Funktionalität vom DBMS und seinem Treiber verfügbar ist. ODBC enthält Funktionen und JDBC Methoden, die Ihrem Programm die Möglichkeit geben, nachdem Sie die Verbindung zur Datenbank hergestellt haben, zu bestimmen, was deren Fähigkeiten sind. Entwickler können Abfragetechniken zur Laufzeit (Introspektion) benutzen, um Programme zu schreiben, die sich an die im Moment verfügbaren SQL-Dialekte, Typen, API-Funktionen und andere Funktionalität anpassen. Weil Ihr Programm dies zur Laufzeit und nicht bei der Übersetzung tut, benötigt es möglicherweise keine Änderungen, um mit neuen DBMS-Versionen zu arbeiten. Es gibt keine Garantie, daß Sie Ihr Programm völlig von Änderungen des DBMS isolieren können, aber für viele Änderungen müssen Sie keinen neuen Code schreiben. Selbstanpassende Programmierung ist auch nützlich für Anwendungen, die mit einer heterogenen Mischung aus Datenbanken und Treibern arbeiten. Crystal Reports und Microsoft Access sind Beispiele für Anwendungen, die selbstanpassende Logik benutzen, um als Client für die verschiedensten SQL-Server funktionieren zu können.
ODBC ist eine Aufruf-Schnittstelle (Call Level Interface), die Introspektion mit Funktionen unterstützt, die über die Funktionalitäten (SQLGetInfo), Typen (SQLGetTypeInfo), Prozeduren (SQLProcedures), die API (SQLGetFunctions) und andere Eigenschaften der Datenbank berichten. JDBC besteht aus einer Schnittstelle und Klassen, mit denen der Entwickler Objekte benutzen kann, während er auf die SQL-Datenbank zugreift. Um mit diesen beiden Schnittstellen auf Daten zuzugreifen, benutzt ein Entwickler SQL-Befehle und arbeitet mit Ergebnismengen. Es dürfte keine Überraschung sein, daß JDBC Objekte wie Verbindungen (java.sql.connection) und Befehle (java.sql.statement) benutzt. ODBC bietet keine derartigen Objekte und Klassen an, aber es benutzt Handles um Verbindungen, Befehle und die dazugehörigen Informationen zu verwalten.
JDBC enthält Klassen, die Metadaten oder Kataloginformationen über die Datenbank und die Abfrageergebnisse liefern. Die Datenbank-Metadaten-Klasse (java.sql.DatabaseMetaData) verkapselt einen Großteil der Daten, die ODBC-Funktionsaufrufe wie SQLGetTypeInfo und SQLGetInfo zurückgeben. Einfach ausgedrückt ist dies die Klasse, die viele Informationen darüber liefert, wie sich ein DBMS vom anderen unterscheidet. JDBC-Metadaten-Methoden können Ganzzahlen, Zeichenketten, Wahrheitswerte und andere Typen zurückgeben. JDBC-Methoden können wie ODBC-Funktionen Metadaten als Ergebnismengen zurückgeben. ODBC- und JDBC-Programme benutzen oft ein ähnliches Programmierungs-Paradigma, um Daten-Anfragen und Metadaten-Anfragen zu verarbeiten.
Datenbank-Metadaten
Entwickler, die Multi-Datenbank-Code schreiben, sollten nicht übersehen, daß Typen nicht konstant sind. Dies ist eine Binsenweisheit, wenn man Produkte oder auch verschiedene Versionen eines Produkts miteinander vergleicht. Wir sehen also, daß unsere Programme veralten können, soweit sie eine fest codierte Typenliste verwenden. Anstatt Programme mit statischen Typenlisten zu schreiben, sollten Sie erwägen, ODBC und JDBC-APIs zu verwenden, die Typ-Informationen zur Laufzeit ermitteln können. Die JDBC-DatabaseMetaData-Klasse liefert Typ-Informationen in ähnlicher Weise wie die ODBC-Funktion SQLGetTypeInfo. Beide APIs geben Typ-Informationen als Ergebnismengen zurück, deren Spalten die verschiedenen Informationen über die Typen darstellen. Eine der wichtigsten Spalten ist der Name des Typs (TYPE_NAME), denn dies ist der Name, den Sie in SQL-Befehlen benutzen müssen. ODBC und JDBC verstehen eine definierte Liste von SQL-Typen, die Zeichenketten, Binärdaten, Datumswerte, Dezimalzahlen, Gleitkommawerte mit einfacher und doppelter Genauigkeit, Ganzzahlen, Uhrzeiten und anderes umfaßt. Die Ergebnismenge gibt an, welche dieser SQL-Datentypen verfügbar ist, nachdem Ihr Programm eine Verbindung zu dem betrachteten Treiber aufgebaut hat. Die Ergebnismenge gibt die maximale Präzision des Datentyps zurück, seine minimale und maximale Skalierung und ob Skalierung für diesen Typ überhaupt anwendbar ist. Sie zeigt auch an, ob der Datentyp einen Nullwert akzeptiert, ob er Groß- und Kleinschreibung beachtet, ob er ein Währungsformat hat, und wie der Typ in SQL WHERE-Sätzen benutzt werden kann. Andere Informationen sagen aus, ob der Typ die Autoincrement-Methode benutzt, ob er ein Vorzeichen enthält oder nicht, oder ob Vorzeichen für diesen Typ gar nicht anwendbar sind.
Das Konzept der Typ-Information durch eine API zur Laufzeit ist klar, aber Sie fragen sich vielleicht, warum es notwendig oder sogar nützlich ist. Es gibt verschiedene Gründe, die unter die Überschriften Flexibilität und Vermeidung von Veralterung fallen. Datenbankprodukte ändern sich, und neue Versionen eines Produkts erweitern oft die reiche Auswahl an Typen. Wenn Sie Konstanten benutzen, um Typen zur Übersetzungszeit zu definieren, werden Sie Ihren Code wahrscheinlich neu übersetzen und linken müssen, wenn eine neue Version des DBMS die Typenauswahl erweitert hat. Ähnlich verhält es sich, wenn Sie Ihren Code mit heterogenen Datenbanken einsetzen wollen, die eine Vielfalt von Typen unterstützen.
En anderes Szenario ist die Notwendigkeit, ein Programm zu schreiben, das Tabellen für verschiedene Datenbanken erzeugt, oder das die Struktur der zu erzeugenden Tabelle vom Benutzer abfragt. Um den SQL TABLE-Befehl aufzubauen, braucht Ihr Programm den Namen, den es für den Typ jeder Spalte in der Tabelle benutzen muß. Der Typ-Name muß für den SQL-Dialekt der Datenbank gültig sein, mit der das Programm verbunden ist. Eine typische Technik ist die Anzeige einer Listbox, die es dem Benutzer erlaubt, für jede Spalte den Typ auszuwählen. Um sicherzustellen, daß diese angezeigte Typenliste auch aktuell ist, sollten Sie diese Liste zur Laufzeit aufbauen statt die Typen in Ihrem Code zu definieren. Bei der dynamischen Erzeugung einer derartigen Typliste ist das Verständnis der ODBC-Funktion SQLGetTypeInfo oder der JDBC-Methode getTypeInfo nützlich.
Beispiel-Programm für JDBC-Typ-Information
Listing 2 ist ein Beispiel-Programm (TYPEINFO.JAVA), das die Benutzung der getTypeInfo-Methode der JDBC DatabaseMetaData-Klasse demonstriert. Weil TYPEINFO ein Java-Programm ist, enthält es eine Hauptklasse. Sie führen TYPEINFO auf einer virtuellen Java-Maschine aus, im Gegensatz zu einem Applet, das ein Browser ausführt. Die Befehlszeile, die ich benutze, um die Java VM zur Ausführung von TYPEINFO aufzurufen, ist :
java -classpath E:\java\jdbc\classes;E:\lib;E:\lib\java\lib\classes.zip; GetTypes
TYPEINFO benutzt die JDBC-ODBC-Brücke, um sich zu ODBC-Datenquellen zu verbinden, und erzeugt dann eine Ergebnismenge für die Metadaten der Datenbank. Es durchläuft dann eine Schleife, in der es zeilenweise Informationen über die Typen holt, die der Treiber unterstützt, mit dem die Verbindung zu dem URL jdbc:odbc:SSPer aufgebaut wurde. Wenn Sie TYPEINFO ausführen, berichtet es die Namen und SQL-Typen, die eine Datenbank bereitstellt. TYPEINFO verbindet zu einer ODBC-Datenquelle (SSPer), die auf meinem Netzwerk so konfiguriert wurde, daß sie eine Microsoft SQL Server-Datenbank benutzt. Wenn Sie TYPEINFO ausführen und zu einem SQL-Server verbinden, werden Sie normalerweise eine längere Liste von Typen sehen als von einem Desktop-Produkt wie dBase. Die Ausführung von TYPEINFO, verbunden zu SQL Server, erzeugt eine Typenliste, die Bit, Image, Timestamp, DateTime und Währung als Datentypen enthält.
Eine unvollkommene Black Box
In einer perfekten Welt funktioniert die Black-Box-Technik wie eine Steckdose. Sie stecken den Stecker rein, und Ihr Programm arbeitet, ohne daß es zusätzliche Intelligenz benötigt. Wenn Sie Lösungen brauchen, um interoperable SQL-Programme zu schreiben, werden Sie finden, daß ODBC und JDBC nützliche Technologien sind. Sie erfüllen nicht hundertprozentig, was die Black Box verspricht, und sie erzeugen keinen Black-Box-Effekt, der sich mit den Java APIs und der Java VM vergleichen ließe. Sie werden jedoch finden, daß ODBC und JDBC Funktionen bzw. Methoden enthalten, die beim Schreiben von portablem Datenbankcode nützlich sind.
Copyright © 1997, Ken North
Übersetzung aus dem Amerikanischen durch Johannes M. Becher
Email-Adresse WWW-Adresse http://problemloeser.de/start.htm
SQLSummit GridSummit
