En informática , Open Database Connectivity ( ODBC ) es una interfaz de programación de aplicaciones (API) estándar para acceder a los sistemas de administración de bases de datos (DBMS). Los diseñadores de ODBC tenían como objetivo hacerlo independiente de los sistemas operativos y de bases de datos . [ cita requerida ] Una aplicación escrita usando ODBC se puede portar a otras plataformas, tanto del lado del cliente como del servidor, con pocos cambios en el código de acceso a los datos.
ODBC logra la independencia de DBMS mediante el uso de un controlador ODBC como capa de traducción entre la aplicación y el DBMS. La aplicación utiliza funciones ODBC a través de un administrador de controladores ODBC con el que está vinculada, y el controlador pasa la consulta al DBMS. Un controlador ODBC puede considerarse análogo a un controlador de impresora u otro controlador, proporcionando un conjunto estándar de funciones para que las utilice la aplicación e implementando funciones específicas de DBMS. Una aplicación que puede utilizar ODBC se denomina "compatible con ODBC". Cualquier aplicación compatible con ODBC puede acceder a cualquier DBMS para el que esté instalado un controlador. Existen controladores para todos los principales DBMS, muchas otras fuentes de datos como sistemas de libretas de direcciones y Microsoft Excele incluso para archivos de texto o valores separados por comas (CSV).
ODBC fue desarrollado originalmente por Microsoft y Simba Technologies a principios de la década de 1990, y se convirtió en la base de la interfaz de nivel de llamada (CLI) estandarizada por SQL Access Group en el campo de Unix y mainframe . ODBC retuvo varias características que se eliminaron como parte del esfuerzo de CLI. Más tarde, ODBC completo fue portado de nuevo a esas plataformas y se convirtió en un estándar de facto considerablemente más conocido que CLI. La CLI sigue siendo similar a ODBC y las aplicaciones se pueden migrar de una plataforma a otra con pocos cambios.
La introducción de la base de datos relacional basada en mainframe durante la década de 1970 llevó a una proliferación de métodos de acceso a datos. Por lo general, estos sistemas funcionaban junto con un procesador de comandos simple que permitía a los usuarios escribir comandos en inglés y recibir resultados. Los ejemplos más conocidos son SQL de IBM y QUEL del proyecto Ingres . Estos sistemas pueden o no permitir que otras aplicaciones accedan a los datos directamente, y aquellas que sí utilizaron una amplia variedad de metodologías. La introducción de SQL tuvo como objetivo resolver el problema de la estandarización del lenguaje , aunque persistieron diferencias sustanciales en la implementación.
Dado que el lenguaje SQL tenía solo características de programación rudimentarias, los usuarios a menudo querían usar SQL dentro de un programa escrito en otro lenguaje, digamos Fortran o C. Esto llevó al concepto de Embedded SQL , que permitió que el código SQL se incrustara en otro idioma. Por ejemplo, una declaración SQL como SELECT * FROM citypodría insertarse como texto dentro del código fuente de C, y durante la compilación se convertiría a un formato personalizado que llamaba directamente a una función dentro de una biblioteca que pasaría la declaración al sistema SQL. Los resultados devueltos de las declaraciones se volverían a interpretar en formatos de datos C, como char *usar un código de biblioteca similar.
Hubo varios problemas con el enfoque de SQL incorporado. Al igual que las diferentes variedades de SQL, los SQL integrados que los usaban variaban ampliamente, no solo de una plataforma a otra, sino incluso entre idiomas en una plataforma: un sistema que permitiera llamadas a DB2 de IBM se vería muy diferente de uno que llamaba a su propio SQL / DS . [ dudoso ] Otro problema clave del concepto de SQL incrustado era que el código SQL solo podía cambiarse en el código fuente del programa, por lo que incluso pequeños cambios en la consulta requerían un esfuerzo considerable del programador para modificarlo. El mercado de SQL se refirió a esto como SQL estático , versus SQL dinámico que se podía cambiar en cualquier momento, como las interfaces de línea de comandos que se incluían en casi todos los sistemas SQL, o una interfaz de programación que dejaba SQL como texto sin formato hasta que se llamaba. Los sistemas de SQL dinámico se convirtieron en un foco importante para los proveedores de SQL durante la década de 1980.