Conectividad de bases de datos abiertas

La introducción de las bases de datos relacionales en mainframes durante la década de 1970 propició una proliferación de métodos de acceso a datos. Generalmente, estos sistemas funcionaban con un procesador de comandos sencillo que permitía a los usuarios escribir comandos en un lenguaje similar al inglés y obtener resultados. Los ejemplos más conocidos son SQL de IBM y QUEL del proyecto Ingres . Estos sistemas podían o no permitir el acceso directo a los datos a otras aplicaciones, y aquellas que sí lo permitían utilizaban una amplia variedad de metodologías. La introducción de SQL buscaba solucionar el problema de la estandarización del lenguaje , aunque persistieron diferencias sustanciales en su implementación.

Dado que el lenguaje SQL solo contaba con funciones de programación rudimentarias, los usuarios a menudo deseaban utilizar SQL dentro de programas escritos en otros lenguajes, como Fortran o C. Esto dio origen al concepto de SQL embebido , que permitía integrar código SQL en otros lenguajes. Por ejemplo, una sentencia SQL como podría insertarse como texto en el código fuente de C, y durante la compilación se convertiría a un formato personalizado que llamaría directamente a una función de una biblioteca que pasaría la sentencia al sistema SQL. Los resultados devueltos por las sentencias se interpretarían nuevamente en formatos de datos de C como o utilizando código de biblioteca similar.SELECT * FROM citychar*char[]

El enfoque de SQL embebido presentaba varios problemas. Al igual que las distintas variantes de SQL, los sistemas SQL embebidos que los utilizaban variaban considerablemente, no solo entre plataformas, sino incluso entre lenguajes dentro de una misma plataforma: un sistema que permitía llamadas a IBM Db2 era muy diferente de uno que llamaba a su propio SQL/DS . Otro problema clave del concepto de SQL embebido era que el código SQL solo podía modificarse en el código fuente del programa, de modo que incluso pequeños cambios en la consulta requerían un esfuerzo considerable por parte del programador. El mercado de SQL se refería a esto como SQL estático , en contraposición al SQL dinámico, que podía modificarse en cualquier momento, como las interfaces de línea de comandos que se incluían con casi todos los sistemas SQL, o una interfaz de programación que dejaba el SQL como texto plano hasta que se ejecutaba. Los sistemas SQL dinámicos se convirtieron en un objetivo principal para los proveedores de SQL durante la década de 1980.

Las bases de datos de mainframes más antiguas, y los sistemas más recientes basados ​​en microcomputadoras que se basaban en ellas, generalmente no contaban con un procesador de comandos tipo SQL entre el usuario y el motor de la base de datos . En cambio, el programa accedía a los datos directamente: una biblioteca de programación en el caso de los grandes sistemas mainframe, o una interfaz de línea de comandos o un sistema de formularios interactivos en el caso de dBASE y aplicaciones similares. Por lo general, otros programas que se ejecutaban en la máquina no podían acceder directamente a los datos de dBASE. Si bien estos programas podían acceder a dichos datos mediante bibliotecas, esto no funcionaría con ningún otro motor de base de datos, ni siquiera con bases de datos diferentes dentro del mismo motor. En efecto, todos estos sistemas eran estáticos, lo que presentaba problemas considerables.

A mediados de la década de 1980, la rápida mejora de los microordenadores, y especialmente la introducción de la interfaz gráfica de usuario y los programas de aplicación con gran cantidad de datos como Lotus 1-2-3, impulsó un creciente interés en el uso de ordenadores personales como plataforma preferida del lado del cliente en la computación cliente-servidor . Bajo este modelo, los grandes mainframes y miniordenadores se utilizarían principalmente para distribuir datos a través de redes de área local a los microordenadores que interpretarían, mostrarían y manipularían dichos datos. Para que este modelo funcionara, era necesario un estándar de acceso a los datos: en el ámbito de los mainframes, era muy probable que todos los ordenadores de una empresa fueran de un mismo proveedor y que los clientes fueran terminales que se comunicaban directamente con ellos, pero en el ámbito de los microordenadores no existía tal estandarización y cualquier cliente podía acceder a cualquier servidor utilizando cualquier sistema de red.

A finales de la década de 1980, se estaban realizando varios esfuerzos para proporcionar una capa de abstracción para este propósito. Algunos de estos sistemas estaban relacionados con las computadoras centrales (mainframes), diseñados para permitir que los programas que se ejecutaban en ellas tradujeran entre las diversas variantes de SQL y proporcionaran una interfaz común que luego pudiera ser llamada por otros programas de mainframes o microcomputadoras. Estas soluciones incluían la Arquitectura de Base de Datos Relacional Distribuida ( DRDA ) de IBM y el Lenguaje de Acceso a Datos ( DAL) de Apple Computer . Sin embargo, mucho más comunes eran los sistemas que se ejecutaban completamente en microcomputadoras, incluyendo una pila de protocolos completa que abarcaba cualquier soporte de red o traducción de archivos necesario.

Uno de los primeros ejemplos de este tipo de sistema fue DataLens de Lotus Development , inicialmente conocido como Blueprint. Blueprint, desarrollado para 1-2-3, admitía diversas fuentes de datos, incluyendo SQL/DS, DB2, FOCUS y varios sistemas mainframe similares, así como sistemas de microcomputadoras como dBase y los primeros proyectos de Microsoft/Ashton-Tate que eventualmente se convertirían en Microsoft SQL Server . ^{[ 1 ]} A diferencia del posterior ODBC, Blueprint era un sistema puramente basado en código, carente de cualquier lenguaje de comandos similar a SQL. En cambio, los programadores utilizaban estructuras de datos para almacenar la información de la consulta, construyéndola mediante la unión de varias de estas estructuras. Lotus se refería a estas estructuras compuestas como árboles de consulta . ^{[ 2 ]}

Casi al mismo tiempo, un equipo de la industria, que incluía miembros de Sybase (Tom Haggin), Tandem Computers ( Jim Gray y Rao Yendluri) y Microsoft (Kyle Geiger), trabajaba en un concepto estandarizado de SQL dinámico. Gran parte del sistema se basaba en el sistema DB-Library de Sybase, con las secciones específicas de Sybase eliminadas y varias adiciones para admitir otras plataformas. ^{[ 3 ]} DB-Library se benefició de un cambio generalizado en la industria, pasando de sistemas de bibliotecas estrechamente vinculados a un lenguaje específico a sistemas de bibliotecas proporcionados por el sistema operativo , que requerían que los lenguajes de esa plataforma se ajustaran a sus estándares. Esto significaba que una sola biblioteca podía usarse con (potencialmente) cualquier lenguaje de programación en una plataforma determinada.

El primer borrador de la API de acceso a datos de Microsoft se publicó en abril de 1989, casi al mismo tiempo que Lotus anunciaba Blueprint. ^{[ 4 ]} A pesar de la gran ventaja de Blueprint —que ya estaba en marcha cuando MSDA aún era un proyecto en papel— Lotus finalmente se unió a los esfuerzos de MSDA cuando quedó claro que SQL se convertiría en el estándar de base de datos de facto. ^{[ 2 ]} Tras una considerable participación de la industria, en el verano de 1989 el estándar se convirtió en SQL Connectivity ( SQLC ). ^{[ 5 ]}

En 1988, varios proveedores, principalmente de las comunidades Unix y de bases de datos, formaron el Grupo de Acceso SQL (SAG) con el objetivo de crear un estándar básico único para el lenguaje SQL. En la primera reunión, se debatió ampliamente si el esfuerzo debía centrarse únicamente en el lenguaje SQL o intentar una estandarización más amplia que incluyera un sistema de integración dinámica del lenguaje SQL, al que denominaron Interfaz de Nivel de Llamada (CLI). ^{[ 6 ]} Durante la reunión, Kyle Geiger, de Microsoft, invitó a Jeff Balboni y Larry Barnes, de Digital Equipment Corporation (DEC), a unirse también a las reuniones de SQLC. SQLC era una posible solución a la necesidad de la CLI, iniciativa liderada por DEC.

El nuevo grupo de cuatro de SQLC, MS, Tandem, DEC y Sybase, presentó una versión actualizada de SQLC en la siguiente reunión de SAG en junio de 1990. ^{[ 7 ]} SAG respondió abriendo el esfuerzo de estandarización a cualquier diseño competidor, pero de las muchas propuestas, solo Oracle Corp tenía un sistema que presentaba una competencia seria. Al final, SQLC ganó las votaciones y se convirtió en el borrador del estándar, pero solo después de que se eliminaran grandes partes de la API; el documento de estándares se redujo de 120 páginas a 50 durante este tiempo. También fue durante este período que se adoptó formalmente el nombre Call Level Interface. ^{[ 7 ]} En 1995 SQL/CLI pasó a formar parte del estándar internacional SQL, ISO/IEC 9075-3. ^{[ 8 ]} El propio SAG fue absorbido por el grupo X/Open en 1996 y, con el tiempo, pasó a formar parte del Common Application Environment de The Open Group .

MS continuó trabajando con el estándar SQLC original, conservando muchas de las características avanzadas que se eliminaron de la versión CLI. Estas incluían características como cursores desplazables y consultas de información de metadatos . Los comandos de la API se dividieron en grupos; el grupo Core era idéntico al CLI, las extensiones de nivel 1 eran comandos fáciles de implementar en controladores, mientras que los comandos de nivel 2 contenían las características más avanzadas, como los cursores. En diciembre de 1991 se publicó una propuesta de estándar, y se recogieron las aportaciones de la industria, que se incorporaron al sistema durante 1992, lo que dio lugar a otro cambio de nombre a ODBC . ^{[ 9 ]}

Durante este tiempo, Microsoft estaba desarrollando su sistema de base de datos Jet . Jet combinaba tres subsistemas principales: un motor de base de datos basado en ISAM (también llamado Jet , lo que puede generar confusión), una interfaz basada en C que permitía a las aplicaciones acceder a esos datos y una selección de bibliotecas de enlace dinámico (DLL) de controladores que permitían a la misma interfaz en C redirigir la entrada y la salida a otras bases de datos basadas en ISAM, como Paradox y xBase . Jet permitía usar un conjunto de llamadas para acceder a bases de datos comunes de microcomputadoras de forma similar a Blueprint, que para entonces ya se llamaba DataLens. Sin embargo, Jet no usaba SQL; al igual que DataLens, la interfaz estaba escrita en C y consistía en estructuras de datos y llamadas a funciones.

Los esfuerzos de estandarización de SAG brindaron a Microsoft la oportunidad de adaptar su sistema Jet al nuevo estándar CLI. Esto no solo convertiría a Windows en una plataforma líder para el desarrollo de CLI, sino que también permitiría a los usuarios usar SQL para acceder tanto a Jet como a otras bases de datos. Lo que faltaba era un analizador SQL que pudiera convertir esas llamadas de su formato de texto a la interfaz C utilizada en Jet. Para resolver esto, Microsoft se asoció con PageAhead Software para usar su procesador de consultas existente, SIMBA. SIMBA se usó como analizador sobre la biblioteca C de Jet, convirtiendo Jet en una base de datos SQL. Y dado que Jet podía reenviar esas llamadas basadas en C a otras bases de datos, esto también permitió a SIMBA consultar otros sistemas. Microsoft incluyó controladores para Excel para convertir sus documentos de hoja de cálculo en tablas de bases de datos accesibles mediante SQL. ^{[ 10 ]}

ODBC 1.0 se lanzó en septiembre de 1992. ^{[ 11 ]} En ese momento, había poco soporte directo para bases de datos SQL (en comparación con ISAM), y los primeros controladores se caracterizaban por un rendimiento deficiente. Parte de esto era inevitable debido a la ruta que seguían las llamadas a través de la pila basada en Jet; las llamadas ODBC a bases de datos SQL se convertían primero del dialecto SQL de Simba Technologies al formato interno basado en C de Jet, y luego se pasaban a un controlador para su conversión de nuevo en llamadas SQL para la base de datos. Digital Equipment y Oracle también contrataron a Simba Technologies para desarrollar controladores para sus bases de datos. ^{[ 12 ]}

Alrededor de 1993, OpenLink Software lanzó uno de los primeros controladores ODBC de terceros desarrollados de forma independiente para el sistema de gestión de bases de datos PROGRESS , ^{[ 13 ]} y poco después lanzó su SDK UDBC (una API multiplataforma equivalente a ODBC y SAG/CLI) y controladores asociados para PROGRESS , Sybase, Oracle y otros sistemas de gestión de bases de datos, para su uso en sistemas operativos tipo Unix ( AIX , HP-UX , Solaris , Linux , etc.), VMS , Windows NT , OS/2 y otros sistemas operativos. ^{[ 14 ]}

Mientras tanto, el esfuerzo por estandarizar la CLI se prolongó, y no fue hasta marzo de 1995 que se finalizó la versión definitiva. Para entonces, Microsoft ya había otorgado a Visigenic Software una licencia de código fuente para desarrollar ODBC en plataformas que no fueran Windows. Visigenic adaptó ODBC al Mac OS clásico y a una amplia variedad de plataformas Unix, donde ODBC se convirtió rápidamente en el estándar de facto. ^{[ 15 ]} La CLI "real" es poco común hoy en día. Los dos sistemas siguen siendo similares, y muchas aplicaciones pueden adaptarse de ODBC a CLI con pocos o ningún cambio. ^{[ 16 ]}

Con el tiempo, los proveedores de bases de datos se hicieron cargo de las interfaces de los controladores y proporcionaron enlaces directos a sus productos. Omitir las conversiones intermedias hacia y desde Jet o adaptadores similares a menudo resultaba en un mayor rendimiento. Sin embargo, para entonces Microsoft había cambiado su enfoque hacia su concepto OLE DB ^{[ 17 ]} (recientemente restablecido ^{[ 18 ]} ), que proporcionaba acceso directo a una mayor variedad de fuentes de datos, desde libretas de direcciones hasta archivos de texto. Varios sistemas nuevos siguieron y desviaron aún más su atención de ODBC, incluidos ActiveX Data Objects (ADO) y ADO.net , que interactuaron más o menos con ODBC a lo largo de su existencia.

A medida que Microsoft dejaba de trabajar directamente en ODBC, el campo Unix lo adoptaba cada vez más. Esto fue impulsado por dos cambios en el mercado: la introducción de interfaces gráficas de usuario (GUI) como GNOME , que generaron la necesidad de acceder a estas fuentes en formato no textual, y el surgimiento de sistemas de bases de datos de software libre como PostgreSQL y MySQL , inicialmente en Unix. La posterior adopción de ODBC por parte de Apple para usar el paquete iODBC estándar del lado de Unix Mac OS X 10.2 (Jaguar) ^{[ 19 ]} (que OpenLink Software había estado proporcionando de forma independiente para Mac OS X 10.0 e incluso Mac OS 9 desde 2001 ^{[ 20 ]} ) consolidó aún más a ODBC como el estándar para el acceso a datos multiplataforma.

Sun Microsystems utilizó el sistema ODBC como base para su propio estándar abierto, Java Database Connectivity (JDBC). En muchos aspectos, JDBC puede considerarse una versión de ODBC para el lenguaje de programación Java en lugar de C. Los puentes JDBC-to-ODBC permiten que los programas basados ​​en Java accedan a fuentes de datos a través de controladores ODBC en plataformas que carecen de un controlador JDBC nativo, aunque estos son relativamente raros hoy en día. A la inversa, los puentes ODBC-to-JDBC permiten que los programas basados ​​en C accedan a fuentes de datos a través de controladores JDBC en plataformas o bases de datos que carecen de controladores ODBC adecuados.

ODBC sigue siendo ampliamente utilizado hoy en día, con controladores disponibles para la mayoría de las plataformas y bases de datos. No es raro encontrar controladores ODBC para motores de bases de datos diseñados para ser integrados, como SQLite , como una forma de permitir que las herramientas existentes actúen como interfaces para estos motores para pruebas y depuración. ^{[ 21 ]}

En los últimos años, ODBC también se ha adoptado para la conexión a fuentes de datos en la nube y plataformas SaaS como Salesforce , Google BigQuery y Snowflake. La disponibilidad de controladores multiplataforma (para Windows, macOS y Linux) ha permitido la integración con herramientas modernas de análisis e inteligencia empresarial como Power BI, Tableau y RStudio. Esto ha extendido la relevancia de ODBC más allá de las bases de datos relacionales tradicionales, abarcando el almacenamiento de datos en la nube y los flujos de trabajo de ciencia de datos.

ODBC se basa en el modelo de controlador de dispositivo , donde el controlador encapsula la lógica necesaria para convertir un conjunto estándar de comandos y funciones en las llamadas específicas que requiere el sistema subyacente. Por ejemplo, un controlador de impresora presenta un conjunto estándar de comandos de impresión, la API, a las aplicaciones que utilizan el sistema de impresión. Las llamadas realizadas a esas API son convertidas por el controlador al formato utilizado por el hardware, como PostScript o PCL .

En el caso de ODBC, los controladores encapsulan numerosas funciones que se pueden dividir en varias categorías generales. Un conjunto de funciones se centra principalmente en la búsqueda, conexión y desconexión con el sistema de gestión de bases de datos (DBMS) con el que se comunica el controlador. Un segundo conjunto se utiliza para enviar comandos SQL desde el sistema ODBC al DBMS, convirtiendo o interpretando aquellos comandos que no son compatibles internamente. Por ejemplo, un DBMS que no admite cursores puede emular esta funcionalidad en el controlador. Finalmente, otro conjunto de comandos, utilizado principalmente de forma interna, se emplea para convertir datos de los formatos internos del DBMS a un conjunto de formatos ODBC estandarizados, basados ​​en los formatos del lenguaje C.

Un controlador ODBC permite que una aplicación compatible con ODBC utilice una fuente de datos , normalmente un sistema de gestión de bases de datos (DBMS). Existen algunos controladores que no son DBMS, para fuentes de datos como archivos CSV , mediante la implementación de un pequeño DBMS dentro del propio controlador. Existen controladores ODBC para la mayoría de los DBMS, incluidos Oracle , PostgreSQL , MySQL , Microsoft SQL Server (pero no para la edición Compact, también conocida como CE ), Mimer SQL , Sybase ASE , SAP HANA ^{[ 28 ] [ 29 ]} e IBM Db2 . Debido a que las diferentes tecnologías tienen capacidades diferentes, la mayoría de los controladores ODBC no implementan toda la funcionalidad definida en el estándar ODBC. Algunos controladores ofrecen funcionalidad adicional no definida por el estándar.

Los controladores de dispositivos suelen ser enumerados, configurados y administrados por una capa de administración independiente, que puede proporcionar funcionalidades adicionales. Por ejemplo, los sistemas de impresión a menudo incluyen la función de cola de impresión , además de los controladores, lo que permite gestionar la impresión en cola para cualquier impresora compatible.

En ODBC, el Administrador de controladores (DM) proporciona estas características. ^{[ 30 ]} El DM puede enumerar los controladores instalados y presentarlos como una lista, a menudo en un formato basado en GUI.

Pero, aún más importante para el funcionamiento del sistema ODBC, es el concepto de Nombre de Origen de Datos (DSN) del Administrador de Depósitos (DM). Los DSN recopilan información adicional necesaria para conectarse a un origen de datos específico , distinta de la que proporciona el propio Sistema de Gestión de Bases de Datos (DBMS). Por ejemplo, el mismo controlador MySQL puede utilizarse para conectarse a cualquier servidor MySQL, pero la información de conexión para conectarse a un servidor privado local es diferente de la necesaria para conectarse a un servidor público alojado en internet. El DSN almacena esta información en un formato estandarizado, y el DM se la proporciona al controlador durante las solicitudes de conexión. El DM también incluye la funcionalidad para presentar una lista de DSN con nombres legibles y para seleccionarlos en tiempo de ejecución para conectarse a diferentes recursos.

El controlador también permite guardar DSN parcialmente completos, con código y lógica para solicitar al usuario la información faltante durante la ejecución. Por ejemplo, se puede crear un DSN sin contraseña. Cuando una aplicación ODBC intenta conectarse al sistema de gestión de bases de datos (DBMS) mediante este DSN, el sistema se detiene y solicita al usuario la contraseña antes de continuar. Esto libera al desarrollador de la aplicación de la necesidad de crear este tipo de código y de saber qué preguntas formular. Todo esto está incluido en el controlador y en los DSN.

Un puente ODBC-JDBC consta de un controlador ODBC que utiliza los servicios de un controlador JDBC para conectarse a una base de datos. Este controlador traduce las llamadas a funciones ODBC en llamadas a métodos JDBC. Los programadores suelen usar este tipo de puente cuando carecen de un controlador ODBC para alguna base de datos, pero tienen acceso a un controlador JDBC. Ejemplos: OpenLink ODBC-JDBC Bridge , SequeLink ODBC-JDBC Bridge .

Un puente JDBC-ODBC consta de un controlador JDBC que emplea un controlador ODBC para conectarse a una base de datos de destino. Este controlador traduce las llamadas a métodos JDBC en llamadas a funciones ODBC. Los programadores suelen utilizar este tipo de puente cuando una base de datos carece de un controlador JDBC, pero es accesible mediante un controlador ODBC. Sun Microsystems incluyó uno de estos puentes en la JVM , pero lo consideró una solución provisional mientras existían pocos controladores JDBC (el puente JDBC-ODBC integrado se eliminó de la JVM en Java 8 ^{[ 31 ]} ). Sun nunca concibió su puente para entornos de producción y, en general, desaconsejó su uso. A partir de 2008Los proveedores independientes de acceso a datos ofrecen puentes JDBC-ODBC que admiten los estándares actuales para ambos mecanismos y que superan con creces el rendimiento de la función integrada de la JVM. Ejemplos: OpenLink JDBC-ODBC Bridge , SequeLink JDBC-ODBC Bridge , ZappySys JDBC-ODBC Bridge .

Un puente OLE DB-ODBC consta de un proveedor OLE DB que utiliza los servicios de un controlador ODBC para conectarse a una base de datos de destino. Este proveedor traduce las llamadas a métodos OLE DB en llamadas a funciones ODBC. Los programadores suelen usar este tipo de puente cuando una base de datos carece de un proveedor OLE DB, pero es accesible a través de un controlador ODBC. Microsoft incluye uno, MSDASQL.DLL, como parte del paquete de componentes del sistema MDAC , junto con otros controladores de bases de datos, para simplificar el desarrollo en lenguajes compatibles con COM (por ejemplo, Visual Basic ). Otros desarrolladores también han creado puentes similares, en particular OpenLink Software, cuyo proveedor OLE DB de 64 bits para orígenes de datos ODBC cubrió la necesidad cuando Microsoft inicialmente dejó de dar soporte a este puente para su sistema operativo de 64 bits. ^{[ 32 ]} (Microsoft cedió posteriormente, y Windows de 64 bits a partir de Windows Server 2008 y Windows Vista SP1 se distribuyeron con una versión de 64 bits de MSDASQL). Ejemplos: OpenLink OLEDB-ODBC Bridge Archivado el 27/03/2017 en Wayback Machine , SequeLink OLEDB-ODBC Bridge .

Un puente ADO.NET-ODBC consta de un proveedor ADO.NET que utiliza los servicios de un controlador ODBC para conectarse a una base de datos de destino. Este proveedor traduce las llamadas a métodos ADO.NET en llamadas a funciones ODBC. Los programadores suelen usar este tipo de puente cuando una base de datos carece de un proveedor ADO.NET, pero es accesible mediante un controlador ODBC. Microsoft incluye uno como parte del paquete de componentes del sistema MDAC , junto con otros controladores de bases de datos, para simplificar el desarrollo en C# . También existen puentes de terceros. Ejemplos: OpenLink ADO.NET-ODBC Bridge , SequeLink ADO.NET-ODBC Bridge .