Unterschiedliche Datenbanksysteme reden miteinander ODBC dient als Kruecke fuer die Schwaechen des SQL-Standards Von Rainer von Ammon*

03.12.1993

Auch ISO-SQL-92 hat das Ziel einer einheitlichen Sprachplattform fuer alle DBMS-Produkte verfehlt. Dynamisches Embedded SQL macht die Anwendungen zwar relativ flexibel. Doch erfordert es nach wie vor grossen Aufwand, Datenbanken aus unterschiedlichen Systemen zu verbinden. Als Problemloeser bietet sich hier - zumindest in der Windows-Welt - die von Microsoft propagierte Open Database Connection (ODBC) an.

Fuer die Einschaetzung von ODBC ist es interessant, die Schnittstellen-Spezifikation vor dem Hintergrund der SQL-Standards zu betrachten, quasi das Call-Level-Interface (CLI) dem statischen Embedded SQL und dem Dynamic SQL gegenueberzustellen.

Die Open Database Connectivity (ODBC) beruht auf einem solchen CLI. Dieses umfasst einen Satz von Funktionen (das ODBC-API), die von den Anwendungen aufgerufen werden koennen. Diese Schnittstelle schirmt eine Applikation von den Eigenheiten der verschiedenen DBMS-Produkte sowie der Netzwerk-Kommunikationsprotokolle ab.

ODBC basiert auf einer von der SQL Access Group (SAG) entwickelten Spezifikation. Es ist kein Microsoft-Produkt im engeren Sinn wie etwa Excel oder Visual Basic; vielmehr wird ODBC als Bestandteil von MS-Windows oder anderen Microsoft-Produkten mitgeliefert.

Viele Microsoft-Applikationen werden kuenftig die ODBC- Schnittstelle verwenden, wenn sie es nicht bereits tun wie zum Beispiel Access, Excel oder Visual Basic. Gleichzeitig bieten zahlreiche DBMS-Hersteller ODBC-Treiber fuer den Zugriff auf ihre Datenbankprodukte an.

Bisher mussten die Programmierer fuer jede Datenbank, auf die die jeweilige Anwendung zugreifen sollte, ein eigenes Modul entwickeln. Bei ODBC schreibt der Entwickler nur noch ein einziges Modul, das dann die Zugriffe auf alle Datenbanktypen erledigt, fuer die ODBC-Treiber existieren. Abbildung 1 zeigt das an einem Beispiel. Zudem muss der Code nicht mehr mit einem DBMS- proprietaeren Precompiler voruebersetzt werden.

Durch die Verwendung der ODBC-Funktionen lassen sich folgende Vorteile erzielen:

- ODBC erlaubt der Applikation den Zugriff auf Daten, die sich an unterschiedlichen Orten befinden (zum Beispiel auf mehreren Servern).

- Ebenfalls erlaubt ist der Zugriff auf Daten, die sich in mehr als einem Typ von Datenbanksystem befinden (zum Beispiel Informix, RDB, DB2, Oracle).

- Fuer Zugriff und Manipulation der Daten unterstuetzt ODBC den Industriestandard SQL.

- Darueber hinaus werden Netzsoftwarestandards wie OSI, RDA und andere unterstuetzt.

- Proprietaere Technologien, zum Beispiel DB2 und Oracle, sind ebenfalls einbezogen.

- ODBC wird sich wohl zu einem Standard fuer Datenbank-Connectivity entwickeln.

- Die existierenden Alternativen zu ODBC sind wesentlich weniger flexibel oder leistungsfaehig. So beschraenkt sich DAL von Apple beispielsweise auf Macintosh-Server. SQL Link und Idapi hingegen werden kuenftig selbst auf ODBC aufsetzen.

Die ODBC-Architektur umfasst vier Komponenten: die Applikation mit den ODBC-API-Aufrufen, den Treiber-Manager, den ODBC-Treiber sowie die Datenquelle (data source).

Die Applikation

- stellt die Verbindung zur Datenquelle her,

- sendet die SQL-Anweisungen an die Datenquelle,

- definiert Speicher und Datenformate ueber die Ergebnisse der SQL- Anweisungen,

- holt die Ergebnisse aus der Datenquelle,

- ist fuer die Fehlerbehandlung zustaendig sowie

- fuer den Dialog mit dem Benutzer,

- verwaltet die Commit- und Rollback-Operationen fuer die Transaktionskontrolle und

- beendet die Verbindung zur Datenquelle.

Der Treiber-Manager wird von Microsoft als Dynamic Link Library (DLL) unter dem Namen ODBC.DLL zur Verfuegung gestellt. Er

- laedt die entsprechenden Datenbanktreiber,

- ist fuer die ODBC-Initialisierungsaufrufe zustaendig,

- liefert fuer die Treiber die Einsprungspunkte in die ODBC- Funktionen und

- ueberprueft Gueltigkeit sowie Reihenfolge der Parameter bei ODBC- Aufrufen.

Der ODBC-Treiber ist ebenfalls eine DLL, die vom Treiber-Manager geladen wird, wenn die Applikation die Verbindung zur Datenquelle aufbaut. Sie

- stellt die Verbindung zur Datenquelle her,

- erledigt die Datenbankzugriffe,

- konvertiert die Datenformate zwischen Applikation und Datenbank,

- liefert die Zugriffsergebnisse an die Applikation,

- formatiert Fehler in Standardfehlercodes und uebergibt sie an die Applikation,

- deklariert und verwaltet Cursor, falls das noetig sein sollte - eine Operation, die fuer die Applikation nur dann sichtbar ist, wenn der Zugriff auf einen Cursor-Namen angefordert wird - und

- initiiert die Transaktionen, falls die Datenbank explizit welche verlangt (fuer die Applikation ebenfalls nicht sichtbar).

Unter dem Begriff Datenquelle ist bei ODBC nicht nur eine bestimmte Datenbank zu verstehen, sondern eine Kombination aus einem DBMS, dem Betriebssystem des Datenbank-Servers und gegebenenfalls einem bestimmten Netzwerk. Eine Datenquelle ist also zum Beispiel eine Oracle-Datenbank unter dem Betriebssystem OS/2 mit Zugriff ueber Novell Netware.

Um die Programmierung mit den Funktionen des ODBC-API einschaetzen zu koennen, ist es sinnvoll, dessen Eigenschaften vor dem Hintergrund der SQL-Standards zu eroertern und das CLI dem statischen Embedded SQL und Dynamic SQL gegenueberzustellen.

Der aktuelle ANSI-Standard datiert von 1989. Er definiert vor allem drei Programmier-Schnittstellen zu SQL:

Mit der Modulsprache koennen Prozeduren innerhalb von Programmen (Modulen) definiert werden. Diese Prozeduren werden dann aus traditionellen Programmiersprachen heraus aufgerufen. Die Modulsprache verwendet Parameter, um Werte an das aufrufende Programm zurueckzugeben. Ueber Embedded SQL (ESQL) hingegen koennen SQL-Anweisungen in ein Programm eingebettet werden. Fuer die Unabhaengigkeit von der Implementierung schliesslich ist der direkte Aufruf konzipiert.

Zur populaersten dieser drei Programmier-Schnittstellen entwickelte sich ESQL. Damit koennen SQL-Anweisungen in ein Programm eingefuegt werden, das in einer Standard-Programmiersprache, der sogenannten Host-Sprache, geschrieben ist. Ein solches Programm enthaelt damit Sourcecode aus zwei Sprachen, naemlich aus SQL und der Host- Sprache. Deshalb muessen die SQL-Anweisungen zunaechst von einem Precompiler in den aequivalenten Sourcecode der Host-Sprache uebersetzt werden.

Bei ESQL wird zwischen statischem und dynamischem SQL unterschieden. Statisches ESQL gehoert bereits zum ANSI-Standard 1989. Dabei muessen die Ergebnistabellen und ihre Spalten sowie die Datentypen vor dem Kompilieren spezifiziert sein. Es gibt bereits Host-Variablen, auf die sowohl die SQL-Anweisungen als auch die Host-Sprache zugreifen kann. Falls die SQL-Anweisung mehr als eine Tabellenzeile liefert, werden die Cursors eingefuehrt, die genau auf eine Zeile der Ergebnismenge zeigen und mit denen sich die Ergebnismenge durchlaufen laesst. Die Tabellen- und Spaltennamen koennen in einem kompilierten Programm nicht mehr dynamisch variiert werden. Nach dem Compilieren, eigentlich schon nach dem Precompiling, ist die Applikation an ein bestimmtes DBMS gebunden, dessen Precompiler verwendet wurde.

Statisches ESQL erlaubt zwar effiziente Datenbankzugriffe, da es in die Host-Sprache uebersetzt wird. Fuer Client-Server- Konfigurationen und Ad-hoc-Anfragen an Datenbanken ist es jedoch nicht geeignet.

Dynamisches ESQL gehoert zur neuesten ANSI-Spezifikation SQL2, die sich derzeit zum internationalen Standard entwickelt. Es sorgt dafuer, dass eine Applikation zur Laufzeit SQL-Anweisungen erzeugen und ausfuehren kann. Zudem sind in dynamischen ESQL-Anweisungen auch Parameter verwendbar, denen sich vor der Ausfuehrung aus dem Programm der Host-Sprache oder aus der Benutzer-Schnittstelle Werte zuweisen lassen. Im Unterschied zum statischen ESQL benoetigen diese Parameter keine Angaben ueber Datentypen und Datenlaengen. Ausserdem kann zur Laufzeit auf eine andere Datenbank zugegriffen werden, die allerdings vom selben DBMS-Typ sein muss.

Damit hat eine Applikation, die dynamisches ESQL verwendet, bereits einen hohen Grad an Flexibilitaet erreicht. Grosser Aufwand entsteht erst, wenn mehrere Datenbanken unter verschiedenen DBMS- Produkten zum Einsatz kommen sollen. Ausserdem wurde inzwischen festgestellt, dass der 1992 verabschiedete neue SQL-Standard ISO- SQL-92 die Aufgabe einer einheitlichen Sprachplattform keineswegs loest; vielmehr werden die Entwickler mehr als zuvor durch funktionale Erweiterungen, die ISO-SQL-92 nicht abgedeckt, an die DBMS-Hersteller gebunden.

Diese Ausfuehrungen ueber SQL sollen den Hintergrund fuer die Einschaetzung der Leistungen von ODBC liefern:

- Das ODBC-Interface oder API - die Programmier-Schnittstelle zur Host-Sprache - ist ein CLI. Ein solches CLI fuer SQL besteht aus einer Bibliothek von Funktionsaufrufen, die SQL-Anweisungen unterstuetzen.

- Ein CLI wird typischerweise fuer dynamische Datenbankzugriffe verwendet. So ist das CLI, das von X/Open und der SQL-Access-Group definiert wird, der dynamischen ESQL-Version sehr aehnlich. Daran orientiert sich auch das ODBC-CLI.

- Das ODBC-Interface wurde so gestaltet, dass es sich fuer die direkte Verwendung durch einen Applikationsprogrammierer eignet. Ein Praeprozessor fuer ESQL ist folglich nicht notwendig.

- Eine SQL-Anweisung wird einfach einem Textpuffer zugewiesen und dieser dann dem entsprechenden ODBC-API-Aufruf uebergeben.

- Ein CLI unterstuetzt das spaete Binden von Variablen. Damit kann die Spezifikation des Speichers fuer die Resultate von SQL- Anweisungen sowohl vor als auch nach der Verfuegbarkeit der Zugriffsergebnisse erfolgen. Damit muss die Applikation keine bestimmte oder maximale Speichergroesse fuer eine Menge von Datenstrukturen bereitstellen, die vor dem Zugriffsergebnis gar nicht bestimmt werden kann.

Interoperabilitaet bei einem CLI bedeutet entweder, dass sich alle Clients und Datenquellen auf ein Standard-Interface beziehen, oder dass alle Clients auf ein Standard-Interface zugreifen. Im letzteren Fall interpretieren die Treiberprogramme die Anweisungen fuer eine bestimmte Datenquelle.

Zudem koennen die Treiber die Clients von den Unterschieden bezueglich Datenbankfunktionalitaet und -protokollen beziehungsweise Netzunterschieden abschirmen. Diesen zuletzt beschriebenen Ansatz verfolgt ODBC.

* Rainer von Ammon ist Geschaeftsfuehrer der C-CASE Software GmbH, Regensburg.