Vor ODBCEdit
Die Einführung der Mainframe-basierten relationalen Datenbank in den 1970er Jahren führte zu einer Verbreitung von Datenzugriffsmethoden. In der Regel arbeiteten diese Systeme mit einem einfachen Befehlsprozessor, der es dem Benutzer ermöglichte, englischsprachige Befehle einzugeben und eine Ausgabe zu erhalten. Die bekanntesten Beispiele sind SQL von IBM und QUEL aus dem Ingres-Projekt. Diese Systeme erlaubten es anderen Anwendungen, direkt auf die Daten zuzugreifen, oder auch nicht, und diejenigen, die dies taten, verwendeten eine Vielzahl von Methoden. Die Einführung von SQL zielte darauf ab, das Problem der Sprachstandardisierung zu lösen, obwohl erhebliche Unterschiede in der Implementierung bestehen blieben.
Da die SQL-Sprache nur über rudimentäre Programmierfunktionen verfügte, wollten die Anwender SQL oft innerhalb eines Programms verwenden, das in einer anderen Sprache geschrieben war, z. B. Fortran oder C. Dies führte zum Konzept von Embedded SQL, das die Einbettung von SQL-Code in eine andere Sprache ermöglichte. So konnte z. B. eine SQL-Anweisung wie SELECT * FROM city als Text in C-Quellcode eingefügt werden, und beim Kompilieren wurde sie in ein benutzerdefiniertes Format konvertiert, das direkt eine Funktion innerhalb einer Bibliothek aufrief, die die Anweisung an das SQL-System weitergab. Die Ergebnisse, die von den Anweisungen zurückgegeben werden, würden mit ähnlichem Bibliothekscode wieder in C-Datenformate wie char * interpretiert.
Es gab mehrere Probleme mit dem Embedded-SQL-Ansatz. Wie die verschiedenen Varianten von SQL, variierten auch die Embedded SQLs, die sie benutzten, stark, nicht nur von Plattform zu Plattform, sondern sogar zwischen verschiedenen Sprachen auf einer Plattform – ein System, das Aufrufe in IBMs DB2 erlaubte, würde ganz anders aussehen als eines, das in ihr eigenes SQL/DS aufrief. Ein weiteres Hauptproblem des Embedded-SQL-Konzepts war, dass der SQL-Code nur im Quellcode des Programms geändert werden konnte, so dass selbst kleine Änderungen an der Abfrage einen erheblichen Aufwand für den Programmierer bedeuteten. Der SQL-Markt bezeichnete dies als statisches SQL, im Gegensatz zu dynamischem SQL, das jederzeit geändert werden konnte, wie z.B. die Befehlszeilenschnittstellen, die mit fast allen SQL-Systemen geliefert wurden, oder eine Programmierschnittstelle, die das SQL als reinen Text beließ, bis es aufgerufen wurde. Dynamische SQL-Systeme wurden in den 1980er Jahren zu einem Hauptaugenmerk der SQL-Anbieter.
Ältere Mainframe-Datenbanken und die neueren, auf Mikrocomputern basierenden Systeme verfügten in der Regel nicht über einen SQL-ähnlichen Befehlsprozessor zwischen dem Benutzer und der Datenbank-Engine. Stattdessen wurde direkt über das Programm auf die Daten zugegriffen – eine Programmierbibliothek im Fall von großen Mainframe-Systemen oder eine Befehlszeilenschnittstelle oder ein interaktives Formularsystem im Fall von dBASE und ähnlichen Anwendungen. Auf Daten aus dBASE konnte im Allgemeinen nicht direkt von anderen Programmen zugegriffen werden, die auf dem Rechner liefen. Diese Programme konnten zwar eine Möglichkeit erhalten, auf diese Daten zuzugreifen, oft über Bibliotheken, aber das funktionierte nicht mit anderen Datenbank-Engines oder sogar mit verschiedenen Datenbanken in derselben Engine. In der Tat waren alle diese Systeme statisch, was erhebliche Probleme mit sich brachte.
Anfangsbemühungen
Ab Mitte der 1980er Jahre führte die rasche Verbesserung der Mikrocomputer und insbesondere die Einführung der grafischen Benutzeroberfläche und datenreicher Anwendungsprogramme wie Lotus 1-2-3 zu einem zunehmenden Interesse an der Verwendung von Personalcomputern als Client-seitige Plattform der Wahl im Client-Server-Computing. Bei diesem Modell werden große Mainframes und Minicomputer in erster Linie dazu verwendet, Daten über lokale Netzwerke an Mikrocomputer weiterzuleiten, die diese Daten interpretieren, anzeigen und manipulieren. Damit dieses Modell funktionierte, war ein Standard für den Datenzugriff erforderlich – im Mainframe-Bereich war es sehr wahrscheinlich, dass alle Computer in einem Geschäft von einem Anbieter stammten und die Clients Computerterminals waren, die direkt mit ihnen kommunizierten, aber im Mikrobereich gab es keine solche Standardisierung und jeder Client konnte über jedes Netzwerksystem auf jeden Server zugreifen.
In den späten 1980er Jahren gab es mehrere Bemühungen, eine Abstraktionsschicht für diesen Zweck bereitzustellen. Einige davon waren Mainframe-bezogen und sollten es Programmen, die auf diesen Maschinen liefen, ermöglichen, zwischen der Vielfalt der SQLs zu übersetzen und eine einzige gemeinsame Schnittstelle bereitzustellen, die dann von anderen Mainframe- oder Mikrocomputerprogrammen aufgerufen werden konnte. Zu diesen Lösungen gehörten die Distributed Relational Database Architecture (DRDA) von IBM und die Data Access Language von Apple Computer. Viel verbreiteter waren jedoch Systeme, die vollständig auf Mikrocomputern liefen, einschließlich eines kompletten Protokollstapels, der jede erforderliche Netzwerk- oder Datei-Übersetzungsunterstützung enthielt.
Eines der frühen Beispiele für ein solches System war DataLens von Lotus Development, das ursprünglich als Blueprint bekannt war. Blueprint, das für 1-2-3 entwickelt wurde, unterstützte eine Vielzahl von Datenquellen, darunter SQL/DS, DB2, FOCUS und eine Vielzahl ähnlicher Mainframe-Systeme sowie Mikrocomputersysteme wie dBase und die frühen Microsoft/Ashton-Tate-Bestrebungen, die sich schließlich zu Microsoft SQL Server entwickeln sollten. Anders als das spätere ODBC war Blueprint ein rein codebasiertes System, das nicht annähernd eine Befehlssprache wie SQL besaß. Stattdessen verwendeten die Programmierer Datenstrukturen, um die Abfrageinformationen zu speichern, und konstruierten eine Abfrage, indem sie viele dieser Strukturen miteinander verknüpften. Lotus bezeichnete diese zusammengesetzten Strukturen als Abfragebäume.
Zur gleichen Zeit arbeitete ein Industrieteam mit Mitgliedern von Sybase (Tom Haggin), Tandem Computers (Jim Gray & Rao Yendluri) und Microsoft (Kyle G) an einem standardisierten dynamischen SQL-Konzept. Ein Großteil des Systems basierte auf dem DB-Library-System von Sybase, wobei die Sybase-spezifischen Abschnitte entfernt und einige Ergänzungen zur Unterstützung anderer Plattformen vorgenommen wurden. DB-Library wurde durch einen branchenweiten Wechsel von Bibliothekssystemen, die eng an eine bestimmte Sprache gebunden waren, zu Bibliothekssystemen unterstützt, die vom Betriebssystem bereitgestellt wurden und von den Sprachen auf dieser Plattform verlangten, dass sie mit seinen Standards übereinstimmen. Dies bedeutete, dass eine einzige Bibliothek mit (potenziell) jeder Programmiersprache auf einer bestimmten Plattform verwendet werden konnte.
Der erste Entwurf der Microsoft Data Access API wurde im April 1989 veröffentlicht, etwa zur gleichen Zeit, als Lotus Blueprint ankündigte. Trotz des großen Vorsprungs von Blueprint – es lief bereits, als MSDA noch ein Papierprojekt war – schloss sich Lotus schließlich den MSDA-Bemühungen an, als klar wurde, dass SQL der De-facto-Datenbankstandard werden würde. Nach beträchtlichem Input aus der Industrie wurde der Standard im Sommer 1989 zu SQL Connectivity (SQLC).
SAG und CLIEdit
Im Jahr 1988 gründeten mehrere Hersteller, hauptsächlich aus der Unix- und Datenbank-Gemeinschaft, die SQL Access Group (SAG) mit dem Ziel, einen einzigen grundlegenden Standard für die SQL-Sprache zu schaffen. Auf dem ersten Treffen gab es eine beträchtliche Debatte darüber, ob man nur an der SQL-Sprache selbst arbeiten sollte oder ob man eine breitere Standardisierung anstreben sollte, die auch ein dynamisches SQL-Spracheinbettungssystem, ein sogenanntes Call Level Interface (CLI), einschließt. Als Kyle Geiger von Microsoft mit einem frühen Entwurf von dem, was damals noch als MS Data Access bekannt war, an dem Treffen teilnahm, lud er Jeff Balboni und Larry Barnes von der Digital Equipment Corporation (DEC) ein, ebenfalls an den SQLC-Meetings teilzunehmen. SQLC war eine potenzielle Lösung für die Forderung nach der CLI, die von DEC angeführt wurde.
Die neue SQLC-„Viererbande“, MS, Tandem, DEC und Sybase, brachte eine aktualisierte Version von SQLC zum nächsten SAG-Treffen im Juni 1990 mit. Die SAG reagierte, indem sie den Standard für alle konkurrierenden Entwürfe öffnete, aber von den vielen Vorschlägen hatte nur Oracle Corp. ein System, das eine ernsthafte Konkurrenz darstellte. Am Ende gewann SQLC die Abstimmung und wurde zum Standardentwurf, aber erst nachdem große Teile der API entfernt worden waren – das Standarddokument wurde in dieser Zeit von 120 auf 50 Seiten gekürzt. In dieser Zeit wurde auch der Name „Call Level Interface“ formell angenommen. 1995 wurde SQL/CLI Teil des internationalen SQL-Standards, ISO/IEC 9075-3. Die SAG selbst wurde 1996 von der X/Open-Gruppe übernommen und wurde im Laufe der Zeit Teil der Common Application Environment von The Open Group.
MS arbeitete weiter mit dem ursprünglichen SQLC-Standard und behielt viele der erweiterten Funktionen bei, die aus der CLI-Version entfernt wurden. Dazu gehörten Funktionen wie scrollbare Cursor und die Abfrage von Metadateninformationen. Die Befehle in der API wurden in Gruppen aufgeteilt; die Core-Gruppe war identisch mit der CLI, die Level-1-Erweiterungen waren Befehle, die einfach in Treibern zu implementieren waren, während Level-2-Befehle die fortgeschritteneren Funktionen wie Cursor enthielten. Ein vorgeschlagener Standard wurde im Dezember 1991 veröffentlicht, und die Eingaben der Industrie wurden gesammelt und bis 1992 in das System eingearbeitet, was zu einer weiteren Namensänderung in ODBC führte.
JET und ODBC-Edit
Zu dieser Zeit war Microsoft mitten in der Entwicklung seines Datenbanksystems Jet. Jet kombinierte drei primäre Subsysteme: eine ISAM-basierte Datenbank-Engine (verwirrenderweise auch Jet genannt), eine C-basierte Schnittstelle, die es Anwendungen ermöglichte, auf diese Daten zuzugreifen, und eine Auswahl an dynamischen Treiberbibliotheken (DLL), die es der gleichen C-Schnittstelle ermöglichten, Ein- und Ausgaben an andere ISAM-basierte Datenbanken, wie Paradox und xBase, weiterzuleiten. Jet ermöglichte die Verwendung eines Satzes von Aufrufen, um auf gängige Mikrocomputer-Datenbanken zuzugreifen, ähnlich wie Blueprint, inzwischen umbenannt in DataLens. Jet benutzte jedoch kein SQL; wie DataLens war die Schnittstelle in C und bestand aus Datenstrukturen und Funktionsaufrufen.
Die SAG-Standardisierungsbemühungen boten Microsoft die Gelegenheit, ihr Jet-System an den neuen CLI-Standard anzupassen. Dies würde nicht nur Windows zu einer erstklassigen Plattform für die CLI-Entwicklung machen, sondern auch den Anwendern ermöglichen, mit SQL sowohl auf Jet als auch auf andere Datenbanken zuzugreifen. Was fehlte, war der SQL-Parser, der diese Aufrufe von ihrer Textform in die in Jet verwendete C-Schnittstelle konvertieren konnte. Um dieses Problem zu lösen, ging MS eine Partnerschaft mit PageAhead Software ein, um deren bestehenden Abfrageprozessor, SIMBA, zu verwenden. SIMBA wurde als Parser oberhalb der C-Bibliothek von Jet eingesetzt und verwandelte Jet in eine SQL-Datenbank. Und da Jet diese C-basierten Aufrufe an andere Datenbanken weiterleiten konnte, ermöglichte dies SIMBA auch die Abfrage anderer Systeme. Microsoft fügte Treiber für Excel bei, um seine Tabellenkalkulationsdokumente in SQL-zugängliche Datenbanktabellen zu verwandeln.
Veröffentlichung und weitere Entwicklung
ODBC 1.0 wurde im September 1992 veröffentlicht. Zu dieser Zeit gab es kaum direkte Unterstützung für SQL-Datenbanken (im Gegensatz zu ISAM), und die frühen Treiber waren für ihre schlechte Leistung bekannt. Ein Teil davon war unvermeidlich aufgrund des Weges, den die Aufrufe durch den Jet-basierten Stack nahmen; ODBC-Aufrufe an SQL-Datenbanken wurden zunächst vom SQL-Dialekt von Simba Technologies in das interne C-basierte Format von Jet konvertiert und dann an einen Treiber zur Rückkonvertierung in SQL-Aufrufe für die Datenbank weitergegeben. Digital Equipment und Oracle beauftragten Simba Technologies ebenfalls mit der Entwicklung von Treibern für ihre Datenbanken.
In der Zwischenzeit zog sich die Entwicklung des CLI-Standards hin, und erst im März 1995 wurde die endgültige Version fertiggestellt. Zu diesem Zeitpunkt hatte Microsoft Visigenic Software bereits eine Quellcode-Lizenz für die Entwicklung von ODBC auf Nicht-Windows-Plattformen erteilt. Visigenic portierte ODBC auf eine Vielzahl von Unix-Plattformen, wo ODBC schnell zum De-facto-Standard wurde. „Echtes“ CLI ist heute selten. Die beiden Systeme bleiben ähnlich, und viele Anwendungen können mit wenigen oder gar keinen Änderungen von ODBC auf CLI portiert werden.
Mit der Zeit übernahmen die Datenbankhersteller die Treiberschnittstellen und stellten direkte Links zu ihren Produkten zur Verfügung. Das Überspringen der Zwischenkonvertierungen zu und von Jet oder ähnlichen Wrappern führte oft zu einer höheren Performance. Zu diesem Zeitpunkt hatte Microsoft jedoch den Fokus auf sein OLE DB-Konzept (das kürzlich wieder eingeführt wurde) verlagert, das den direkten Zugriff auf eine Vielzahl von Datenquellen von Adressbüchern bis zu Textdateien ermöglichte. Es folgten mehrere neue Systeme, die sich weiter von ODBC abwandten, darunter ActiveX Data Objects (ADO) und ADO.net, die im Laufe ihrer Lebenszeit mehr oder weniger mit ODBC interagierten.
Während sich Microsoft von der direkten Arbeit an ODBC abwandte, wurde es im Unix-Bereich immer beliebter. Dies wurde durch zwei Veränderungen im Markt vorangetrieben: die Einführung von grafischen Benutzeroberflächen (GUIs) wie GNOME, die das Bedürfnis weckten, auf diese Quellen in nicht-textlicher Form zuzugreifen, und das Aufkommen von Open-Software-Datenbanksystemen wie PostgreSQL und MySQL, zunächst unter Unix. Die spätere Übernahme von ODBC durch Apple für die Verwendung des standardmäßigen Unix-seitigen iODBC-Pakets Mac OS X 10.2 (Jaguar) (das OpenLink Software seit 2001 unabhängig für Mac OS X 10.0 und sogar Mac OS 9 bereitgestellt hatte) zementierte ODBC weiter als Standard für den plattformübergreifenden Datenzugriff.
Sun Microsystems nutzte das ODBC-System als Grundlage für ihren eigenen offenen Standard, Java Database Connectivity (JDBC). In vielerlei Hinsicht kann JDBC als eine Version von ODBC für die Programmiersprache Java anstelle von C betrachtet werden. JDBC-zu-ODBC-Bridges ermöglichen es Java-basierten Programmen, über ODBC-Treiber auf Datenquellen auf Plattformen zuzugreifen, für die es keinen nativen JDBC-Treiber gibt, obwohl diese inzwischen relativ selten sind. Umgekehrt ermöglichen ODBC-zu-JDBC-Bridges C-basierten Programmen den Zugriff auf Datenquellen über JDBC-Treiber auf Plattformen oder aus Datenbanken, für die es keine geeigneten ODBC-Treiber gibt.
ODBC heute
ODBC ist auch heute noch weit verbreitet, mit Treibern, die für die meisten Plattformen und die meisten Datenbanken verfügbar sind. Es ist nicht ungewöhnlich, ODBC-Treiber für Datenbank-Engines zu finden, die eingebettet werden sollen, wie z.B. SQLite, um vorhandenen Tools zu ermöglichen, als Frontend für diese Engines zum Testen und Debuggen zu fungieren.
Das Aufkommen von Thin-Client-Computing mit HTML als Zwischenformat hat jedoch den Bedarf an ODBC verringert. Viele Web-Entwicklungsplattformen enthalten direkte Links zu Zieldatenbanken – MySQL ist sehr verbreitet. In diesen Szenarien gibt es weder einen direkten client-seitigen Zugriff noch müssen mehrere Client-Software-Systeme unterstützt werden; alles läuft über die vom Programmierer bereitgestellte HTML-Anwendung. Die Virtualisierung, die ODBC bietet, ist nicht mehr zwingend erforderlich, und die Entwicklung von ODBC ist nicht mehr so aktiv wie früher. Aber wenn ODBC nicht mehr eine starke Anforderung für die Client-Server-Programmierung ist, ist ODBC jetzt wichtiger für den Datenzugriff und die Datenvirtualisierung der Datenintegration in Datenanalyse- und Data-Science-Szenarien. Diese neuen Anforderungen spiegeln sich in den neuen ODBC 4.0-Funktionen wie semi-strukturierte und hierarchische Daten, Web-Authentifizierung und Leistungsverbesserung wider.
VersionsgeschichteBearbeiten
Versionsgeschichte:
- 1.0: veröffentlicht im September 1992
- 2.0: ca. 1994
- 2.5
- 3.0: ca. 1995, John Goodson von Intersolv und Frank Pellow und Paul Cotton von IBM lieferten wesentliche Beiträge zu ODBC 3.0
- 3.5: ca. 1997
- 3.8: ca. 2009, mit Windows 7
- 4.0: Entwicklung angekündigt im Juni 2016, erste Implementierung mit SQL Server 2017 veröffentlicht im September 2017 und zusätzliche Desktop-Treiber Ende 2018, finale Spezifikation auf Github