Avant ODBCEdit
L’introduction de la base de données relationnelle sur mainframe au cours des années 1970 a conduit à une prolifération des méthodes d’accès aux données. Généralement, ces systèmes fonctionnaient conjointement avec un simple processeur de commande qui permettait aux utilisateurs de taper des commandes de type anglais, et de recevoir une sortie. Les exemples les plus connus sont SQL d’IBM et QUEL du projet Ingres. Ces systèmes peuvent ou non permettre à d’autres applications d’accéder directement aux données, et ceux qui le font utilisent une grande variété de méthodologies. L’introduction de SQL visait à résoudre le problème de la standardisation du langage, bien que des différences substantielles dans la mise en œuvre subsistaient.
Puisque le langage SQL n’avait que des fonctionnalités de programmation rudimentaires, les utilisateurs souhaitaient souvent utiliser SQL au sein d’un programme écrit dans un autre langage, disons Fortran ou C. Cela a conduit au concept de SQL embarqué, qui permettait au code SQL d’être intégré dans un autre langage. Par exemple, une instruction SQL telle que SELECT * FROM city pouvait être insérée sous forme de texte dans le code source C, et lors de la compilation, elle était convertie en un format personnalisé qui appelait directement une fonction dans une bibliothèque qui transmettait l’instruction au système SQL. Les résultats renvoyés par les déclarations seraient réinterprétés dans des formats de données C comme char * en utilisant un code de bibliothèque similaire.
L’approche Embedded SQL présentait plusieurs problèmes. Comme les différentes variétés de SQL, les Embedded SQL qui les utilisaient variaient considérablement, non seulement d’une plate-forme à l’autre, mais même entre les langages d’une même plate-forme – un système qui permettait des appels vers DB2 d’IBM aurait une apparence très différente de celui qui appelait vers leur propre SQL/DS. Un autre problème majeur du concept de SQL embarqué était que le code SQL ne pouvait être modifié que dans le code source du programme, de sorte que même de petites modifications de la requête nécessitaient un effort considérable de la part du programmeur. Le marché du SQL appelle cela le SQL statique, par opposition au SQL dynamique qui peut être modifié à tout moment, comme les interfaces de ligne de commande fournies avec presque tous les systèmes SQL, ou une interface de programmation qui laisse le SQL en texte clair jusqu’à ce qu’il soit appelé. Les systèmes SQL dynamiques sont devenus l’un des principaux centres d’intérêt des vendeurs de SQL au cours des années 1980.
Les anciennes bases de données mainframe, et les nouveaux systèmes basés sur les micro-ordinateurs, ne disposaient généralement pas d’un processeur de commande de type SQL entre l’utilisateur et le moteur de la base de données. Au lieu de cela, le programme accédait directement aux données – une bibliothèque de programmation dans le cas des grands systèmes centraux, ou une interface de ligne de commande ou un système de formulaires interactifs dans le cas de dBASE et d’applications similaires. Les données de dBASE ne sont généralement pas accessibles directement par d’autres programmes fonctionnant sur la machine. Ces programmes pouvaient disposer d’un moyen d’accéder à ces données, souvent par le biais de bibliothèques, mais cela ne fonctionnait pas avec un autre moteur de base de données, ni même avec différentes bases de données du même moteur. En effet, tous ces systèmes étaient statiques, ce qui présentait des problèmes considérables.
Premiers effortsEdit
Au milieu des années 1980, l’amélioration rapide des micro-ordinateurs, et surtout l’introduction de l’interface utilisateur graphique et des programmes d’application riches en données comme Lotus 1-2-3 ont suscité un intérêt croissant pour l’utilisation des ordinateurs personnels comme plate-forme côté client de choix dans l’informatique client-serveur. Selon ce modèle, les gros ordinateurs centraux et les mini-ordinateurs serviraient principalement à transmettre des données sur des réseaux locaux à des micro-ordinateurs qui interpréteraient, afficheraient et manipuleraient ces données. Pour que ce modèle fonctionne, il fallait une norme d’accès aux données – dans le domaine des mainframes, il était fort probable que tous les ordinateurs d’un atelier proviennent d’un seul fournisseur et que les clients soient des terminaux informatiques leur parlant directement, mais dans le domaine des micro-ordinateurs, il n’y avait pas une telle normalisation et n’importe quel client pouvait accéder à n’importe quel serveur en utilisant n’importe quel système de réseau.
À la fin des années 1980, plusieurs efforts étaient en cours pour fournir une couche d’abstraction à cette fin. Certains d’entre eux étaient liés aux mainframes, conçus pour permettre aux programmes fonctionnant sur ces machines de traduire entre la variété de SQL et de fournir une interface commune unique qui pourrait ensuite être appelée par d’autres programmes de mainframes ou de micro-ordinateurs. Ces solutions comprenaient l’architecture de base de données relationnelle distribuée (DRDA) d’IBM et le langage d’accès aux données d’Apple Computer. Beaucoup plus courants, cependant, étaient les systèmes qui fonctionnaient entièrement sur des micro-ordinateurs, y compris une pile de protocoles complète qui incluait tout support requis pour la mise en réseau ou la traduction de fichiers.
L’un des premiers exemples d’un tel système était le DataLens de Lotus Development, initialement connu sous le nom de Blueprint. Blueprint, développé pour 1-2-3, supportait une variété de sources de données, notamment SQL/DS, DB2, FOCUS et une variété de systèmes mainframe similaires, ainsi que des systèmes micro-informatiques comme dBase et les premiers efforts de Microsoft/Ashton-Tate qui allaient finalement se développer en Microsoft SQL Server. Contrairement à ODBC, Blueprint était un système purement codé, sans langage de commande comme SQL. Au lieu de cela, les programmeurs utilisaient des structures de données pour stocker les informations relatives aux requêtes, et construisaient une requête en reliant plusieurs de ces structures entre elles. Lotus désignait ces structures composées sous le nom d’arbres de requête.
A peu près au même moment, une équipe industrielle comprenant des membres de Sybase (Tom Haggin), de Tandem Computers (Jim Gray & Rao Yendluri) et de Microsoft (Kyle G) travaillait sur un concept SQL dynamique standardisé. Une grande partie du système était basée sur le système DB-Library de Sybase, avec les sections spécifiques à Sybase supprimées et plusieurs ajouts pour supporter d’autres plateformes. DB-Library a bénéficié de l’évolution de l’industrie, qui est passée de systèmes de bibliothèque étroitement liés à un langage spécifique à des systèmes de bibliothèque fournis par le système d’exploitation et exigeant que les langages de cette plate-forme soient conformes à ses normes. Cela signifiait qu’une seule bibliothèque pouvait être utilisée avec (potentiellement) n’importe quel langage de programmation sur une plate-forme donnée.
La première ébauche de l’API d’accès aux données de Microsoft a été publiée en avril 1989, à peu près en même temps que l’annonce de Blueprint par Lotus. Malgré la grande avance de Blueprint – il fonctionnait alors que MSDA n’était encore qu’un projet sur papier – Lotus a fini par rejoindre les efforts de MSDA lorsqu’il est devenu évident que SQL deviendrait la norme de facto en matière de bases de données. Après une contribution considérable de l’industrie, à l’été 1989, la norme est devenue SQL Connectivity (SQLC).
SAG et CLIEdit
En 1988, plusieurs fournisseurs, principalement issus des communautés Unix et des bases de données, ont formé le SQL Access Group (SAG) dans le but de produire une norme de base unique pour le langage SQL. Lors de la première réunion, il y a eu un débat considérable sur la question de savoir si l’effort devait ou non porter uniquement sur le langage SQL lui-même, ou si l’on devait tenter une normalisation plus large incluant également un système d’intégration dynamique du langage SQL, ce qu’ils appelaient une interface de niveau d’appel (CLI). Alors qu’il assistait à la réunion avec une première version de ce qui était alors encore connu sous le nom de MS Data Access, Kyle Geiger de Microsoft a invité Jeff Balboni et Larry Barnes de Digital Equipment Corporation (DEC) à se joindre également aux réunions de SQLC. SQLC était une solution potentielle à l’appel pour le CLI, qui était mené par DEC.
Le nouveau « gang of four » de SQLC, MS, Tandem, DEC et Sybase, a apporté une version actualisée de SQLC à la réunion suivante du SAG en juin 1990. Le SAG a répondu en ouvrant l’effort standard à toute conception concurrente, mais parmi les nombreuses propositions, seul Oracle Corp avait un système qui présentait une concurrence sérieuse. Finalement, SQLC a remporté les votes et est devenu le projet de norme, mais seulement après que de grandes parties de l’API aient été supprimées – le document de normes a été réduit de 120 pages à 50 pendant cette période. C’est également à cette époque que le nom Call Level Interface a été formellement adopté. En 1995, SQL/CLI est devenu partie intégrante de la norme internationale SQL, ISO/IEC 9075-3. Le SAG lui-même a été repris par le groupe X/Open en 1996 et, au fil du temps, est devenu une partie de l’environnement d’application commun de The Open Group.
MS a continué à travailler avec la norme SQLC originale, en conservant de nombreuses fonctionnalités avancées qui ont été supprimées de la version CLI. Il s’agissait notamment de fonctionnalités telles que les curseurs défilants et les requêtes d’informations sur les métadonnées. Les commandes de l’API ont été divisées en groupes : le groupe de base était identique à la CLI, les extensions de niveau 1 étaient des commandes faciles à mettre en œuvre dans les pilotes, tandis que les commandes de niveau 2 contenaient les fonctions plus avancées comme les curseurs. Une proposition de norme a été publiée en décembre 1991, et les commentaires de l’industrie ont été recueillis et travaillés dans le système jusqu’en 1992, ce qui a entraîné un autre changement de nom en ODBC.
JET et ODBCEdit
Pendant cette période, Microsoft était en plein développement de son système de base de données Jet. Jet combinait trois sous-systèmes primaires ; un moteur de base de données basé sur ISAM (également nommé Jet, ce qui prête à confusion), une interface basée sur C permettant aux applications d’accéder à ces données, et une sélection de bibliothèques de liens dynamiques (DLL) de pilotes qui permettaient à la même interface C de rediriger l’entrée et la sortie vers d’autres bases de données basées sur ISAM, comme Paradox et xBase. Jet permettait d’utiliser un seul ensemble d’appels pour accéder aux bases de données courantes des micro-ordinateurs d’une manière similaire à Blueprint, alors renommé DataLens. Cependant, Jet n’utilisait pas SQL ; comme DataLens, l’interface était en C et se composait de structures de données et d’appels de fonctions.
Les efforts de normalisation du SAG ont présenté une opportunité pour Microsoft d’adapter son système Jet à la nouvelle norme CLI. Cela ferait non seulement de Windows une plateforme de choix pour le développement CLI, mais permettrait également aux utilisateurs d’utiliser SQL pour accéder à la fois à Jet et à d’autres bases de données. Ce qui manquait, c’était un analyseur SQL capable de convertir ces appels de leur forme textuelle à l’interface C utilisée dans Jet. Pour résoudre ce problème, MS s’est associé à PageAhead Software pour utiliser leur processeur de requêtes existant, SIMBA. SIMBA a été utilisé comme un analyseur au-dessus de la bibliothèque C de Jet, transformant Jet en une base de données SQL. Et comme Jet pouvait transmettre ces appels en C à d’autres bases de données, SIMBA pouvait également interroger d’autres systèmes. Microsoft a inclus des pilotes pour Excel afin de transformer ses documents de tableur en tables de base de données accessibles par SQL.
La sortie et la poursuite du développementModification
ODBC 1.0 est sorti en septembre 1992. À l’époque, il y avait peu de support direct pour les bases de données SQL (par rapport à ISAM), et les premiers pilotes étaient notés pour leurs mauvaises performances. Une partie de cela était inévitable en raison du chemin que les appels prenaient à travers la pile basée sur Jet ; les appels ODBC aux bases de données SQL étaient d’abord convertis du dialecte SQL de Simba Technologies au format interne basé sur C de Jet, puis passés à un pilote pour être reconvertis en appels SQL pour la base de données. Digital Equipment et Oracle ont tous deux contracté Simba Technologies pour développer des pilotes pour leurs bases de données également.
Pendant ce temps, l’effort sur la norme CLI a traîné, et ce n’est qu’en mars 1995 que la version définitive a été finalisée. À cette date, Microsoft avait déjà accordé à Visigenic Software une licence de code source pour développer ODBC sur des plates-formes non Windows. Visigenic a porté ODBC sur une grande variété de plates-formes Unix, où ODBC est rapidement devenu la norme de facto. Le « vrai » CLI est rare aujourd’hui. Les deux systèmes restent similaires, et de nombreuses applications peuvent être portées d’ODBC à CLI avec peu ou pas de modifications.
Au fil du temps, les fournisseurs de bases de données ont repris les interfaces des pilotes et fourni des liens directs vers leurs produits. Le fait de sauter les conversions intermédiaires vers et depuis Jet ou des wrappers similaires a souvent permis d’obtenir de meilleures performances. Cependant, à cette époque, Microsoft s’était recentré sur son concept OLE DB (récemment rétabli), qui permettait un accès direct à une plus grande variété de sources de données, des carnets d’adresses aux fichiers texte. Plusieurs nouveaux systèmes ont suivi qui ont encore détourné leur attention d’ODBC, notamment ActiveX Data Objects (ADO) et ADO.net, qui ont plus ou moins interagi avec ODBC au cours de leur vie.
Alors que Microsoft détournait son attention du travail direct sur ODBC, le domaine Unix l’adoptait de plus en plus. Cela a été propulsé par deux changements au sein du marché, l’introduction d’interfaces utilisateur graphiques (GUI) comme GNOME qui ont fourni un besoin d’accéder à ces sources sous une forme non textuelle, et l’émergence de systèmes de base de données en logiciel ouvert comme PostgreSQL et MySQL, initialement sous Unix. L’adoption ultérieure d’ODBC par Apple pour l’utilisation du paquetage standard iODBC côté Unix (Jaguar) (qu’OpenLink Software fournissait indépendamment pour Mac OS X 10.0 et même Mac OS 9 depuis 2001) a encore cimenté ODBC comme norme d’accès aux données multiplateforme.
Sun Microsystems a utilisé le système ODBC comme base de sa propre norme ouverte, Java Database Connectivity (JDBC). À bien des égards, JDBC peut être considéré comme une version d’ODBC pour le langage de programmation Java au lieu de C. Les ponts JDBC-to-ODBC permettent aux programmes basés sur Java d’accéder aux sources de données par le biais de pilotes ODBC sur des plates-formes dépourvues de pilote JDBC natif, bien que ceux-ci soient désormais relativement rares. Inversement, les ponts ODBC-to-JDBC permettent aux programmes basés sur C d’accéder à des sources de données via des pilotes JDBC sur des plates-formes ou à partir de bases de données dépourvues de pilotes ODBC adaptés.
OdBC aujourd’huiModifier
ODBC reste largement utilisé aujourd’hui, avec des pilotes disponibles pour la plupart des plates-formes et des bases de données. Il n’est pas rare de trouver des pilotes ODBC pour des moteurs de bases de données destinés à être intégrés, comme SQLite, afin de permettre aux outils existants d’agir comme des frontaux à ces moteurs pour les tests et le débogage.
Toutefois, l’essor de l’informatique client léger utilisant HTML comme format intermédiaire a réduit le besoin d’ODBC. De nombreuses plateformes de développement web contiennent des liens directs vers des bases de données cibles – MySQL étant très courant. Dans ces scénarios, il n’y a pas d’accès direct côté client ni de systèmes logiciels clients multiples à prendre en charge ; tout passe par l’application HTML fournie par le programmeur. La virtualisation qu’offre ODBC n’est plus une exigence forte, et le développement d’ODBC n’est plus aussi actif qu’auparavant. Mais alors qu’ODBC n’est plus une exigence forte pour la programmation client-serveur, ODBC est maintenant plus important pour l’accès aux données et la virtualisation des données de l’intégration des données dans les scénarios d’analyse des données et de science des données. Ces nouvelles exigences se reflètent dans les nouvelles fonctionnalités d’ODBC 4.0 telles que les données semi-structurées et hiérarchiques, l’authentification web et l’amélioration des performances.
Historique des versionsModifier
Historique des versions:
- 1.0 : publié en septembre 1992
- 2.0 : c. 1994
- 2.5
- 3.0 : c. 1995, John Goodson d’Intersolv et Frank Pellow et Paul Cotton d’IBM ont apporté une contribution importante à ODBC 3.0
- 3.5 : c. 1997
- 3.8 : c. 2009, avec Windows 7
- 4.0 : Développement annoncé en juin 2016 avec la première mise en œuvre avec SQL Server 2017 publiée en septembre 2017 et des pilotes de bureau supplémentaires fin 2018 spécification finale sur Github
.