Acceso a las Bases de Datos

Realizado por José Manuel Rodríguez (JMR)

 

Como acceden los programas a las bases de datos

Circunscribiéndonos al mundo del PC, en un principio el acceso a las bases de datos desde los 
programas era una situación bastante caótica, en que cada motor tenía su propia idiosincrasia, 
por un lado a las bases de datos locales se accedía bien usando una sintaxis específica del 
fabricante, ya que normalmente cada formato iba unido a un RDBMS o entorno de programación 
concreto del mismo fabricante, bien usando un conjunto de funciones de librerías específicas 
cuando se accedía desde un lenguaje 3D; y por otro lado, a los grandes servidores de bases de 
datos relacionales había que acceder empleando su propio API.
Hubo algunos intentos de estandarizar el acceso a las bases de datos locales mediante el empleo 
de Replazable Data Drivers (RDDs) que ocultaban hasta cierto punto las diferencias entre los 
distintos formatos manejados por los dialectos XBase y que tuvieron cierto éxito, pero que se 
limitaban a una plataforma (DOS) y lenguaje (Clipper 5.x), muy concretos. Por esa época Windows 
empezaba a imponerse como Sistema Operativo en el entorno PC, y Microsoft lanzó el estándar que 
ha perdurado hasta nuestros días y que fue el primero en ofrecer de verdad un acceso uniforme a
las fuentes de datos independiente del lenguaje empleado, plataforma o formato de los datos: el 
Open DataBase Connectivity (ODBC). El ODBC está basado en el estándar X/Open de acceso a bases 
de datos y la norma ISO/IEC Call Level Interface (CLI) de definición de un API para acceso a las 
bases de datos, y permite realizar consultas SQL a cualquier base de datos que disponga un Driver 
OBCD. Cuando se lanzó, Microsoft ya estaba en colabaración con varios fabricantes de Bases de 
Datos, y dada su posición de fuerza en el mercado, la práctica totalidad les siguió, por lo que 
pronto hubo Drivers ODBC para cualquier Base de Datos presente en el mercado que se preciase de 
tal, ya fuese realizada por Microsoft o bien por el propio fabricante siguiendo las especifica-
ciones (abiertas) de Microsoft, y esto incluía, además de todos los formatos de Bases de Datos 
locales y Servidores de Datos, cosas tan dispares como Drivers OBCD para ficheros de texto u 
hojas de cálculo Excel. Por fin, en principio, el desarrollador de la aplicación se limitaba a 
hacer una aplicación orientada a ODBC y no importaba a que Drivers ODBC estuviese realmente 
conectada, incluso a varios de ellos trabajando con fuentes de datos hetereogeneas. Esto no era 
totalmente así ya que las especificaciones de Microsoft dejaban ciertas libertades en el diseño 
de los Drivers, por lo que había capacidades que podína estar presentes o no y que por su puesto 
había un precio a pagar (y no me refiero al meramente crematístico) por el uso de ODBC, este 
precio consistía por un lado en que el uso del ODBC implicaba la renuncia a las características 
avanzadas (y por tanto exclusivas) de muchos motores y servidores de datos, y por otro lado, en 
que se estaba añadiendo una capa más de indirección al tráfico entre la aplicación y los datos: 
en vez de comunicarse directamente entre sí, debían hacerlo mediante el Driver ODBC lo que en 
todos los casos penalizaba los tiempos de acceso, y en algunas situaciones los hacia ciertamente 
inviables. Esto último dependía enteramente del Driver, mientas que el Driver ODBC para el MS-SQL 
Server literalmente volaba (no olvidemos que son del mismo fabricante y prácticamente las 
llamadas al Driver ODBC para MS-SQL se traducen en llamadas directas al MS-SQL Server), el Driver 
ODBC para Oracle era bastante penoso. Otra cosa a tener en cuenta es la propia naturaleza del 
ODBC: es capaz de manejar sentencias SQL, pero por ejemplo, un fichero DBF o un fichero de texto 
con los campos separados por comas y los registros por retornos de carro no saben nada de SQL, 
por lo que el propio Driver ODBC para DBF o ficheros ASCII debe además de contener toda la lógica 
necesaria para comprender e interpretar el SQL necesario, lo que los hace grandes en tamaño, 
hambrientos de memoria y evidentemente lentos, aunque funcionar, lo que se dice funcionar, fun-
cionan, de hecho no han dejado de experimentar mejoras con cada aparición de nuevas versiones, 
y ahora en su versión 3.0 son una opción bastante viable para prácticamente cualquier fuente de 
datos.
Tras la aparición del ODBC, Borland contraatacó sacando al mercado lo que brevemente se llamó 
Open Database Application Program Interface (ODAPI) y luego definitivamente Independent Database 
Application Program Interface (IDAPI). Básicamente su finalidad era exactamente la misma que la 
del ODBC, aunque era un producto a la vez más versatil y notablemente menos potente en principio, 
ya que delegaba amplios poderes para sus Drivers. Desde un principio se vió que la competencia 
era imposible y que la parte del león caía enteramente en las manos de Microsoft, así que Borland 
desde un principio se dedicó a afirmar que su producto no le hacía la competencia al de Micro-
soft, sino que se complementaban. Finalmente estas afirmaciones pasaron a ser una realidad y Bor-
land retiró el nombre de IDAPI como especificación abierta para acceso a Bases de Datos, convir-
tiéndose en el Borland Data Engine (BDE), el conjunto de funciones con un interfaz común para 
acceso a Bases de Datos que acompañaría a los productos de Borland/INPRISE, manteniéndose el 
nombre de IDAPI para este interfaz, o sea el API del BDE, y por último, los Drivers para acceso 
a Servidores de Datos Remotos pasaron a ser los SQL-Links. Uno de estos SQL-Links era especial, 
en tanto que era un Driver IDAPI para ODBC, y al contrario del resto, que había que conseguir de 
forma separada, pasó a formar parte de la distribución estándar del BDE, de esta forma se garan-
tizaba el acceso a cualquier fuente de datos para la que se dispusiese de un controlador ODBC 
(que ya gozaban de muy amplia difusión y eran muy asequibles) y el BDE pasaba realmente a tra-
bajar en estrecha colaboración con el ODBC en el acceso a los datos, aunque el resultado de 
meter dos capas de indirección entre la aplicación y los datos se traducía por regla general en 
tiempos de espera casi inaceptables (como siempre esto dependía del tipo de aplicación y de los 
Drivers concretos empleados).
Recientemente, con la consolidación de la tecnología OLE y el auge de las aplicaciones 
multidistribuidas (en dos capas, como la clásica arquitectura Cliente/Servidor, pero también en 
tres o más capas), ha hecho su aparición el ActiveX Database Object (ADO), que basándose en la 
tecnología OLE de Microsoft presenta dos vertientes: sirve tanto para acceder a bases de datos 
locales como remotas. Un objeto ADO es un objeto ActiveX que se comunica mediante (D)COM con un 
OLE DB Provider, otro objeto ActiveX que puede estar situado en la misma máquina o en otra 
cualquiera de la red y que satisface de forma transparente las peticiones que le hace el ADO, 
pasándoselas a su vez al orígen (u orígenes) de los datos, que a su vez pueden estar distribuidas 
por toda la red. Esto implica que nuestras aplicaciones deben variar su estrategia, en vez de 
comunicarnos mediante grupos de funciones individuales que conforman un API, nos comunicamos con 
el ADO a través de los interfaces COM que expone. Ya que es un control ActiveX, normalmente se 
usa el interfaz IDispatch, tratando al ADO como un servidor in-process de automatizaciones OLE. 
A diferencia del ODBC que implicaba soporte de SQL, los requerimientos de OLE DB son mucho menos 
draconianos, simplemente requiere que la fuente de datos le sea capaz de satisfacer sus peticiones 
devolviéndole o aceptando los valores en forma de filas y columnas. Por tanto, deja una huella 
mucho más ligera en las aplicaciones. Actualmente hay ya OLE DB Providers para ODBC (es decir el 
OLE DB en vez de hablar directamente con la fuente de datos habla con los Drivers ODBC que a su 
vez hablan con el orígen de los datos, lo cual añade un nivel más de indirección, pero a cambio 
proporciona soporte para aplicaciones multidistribuidas) y para MS-SQL Server, por lo que parece 
con excelentes prestaciones, amen, que debido a sus bajos requerimientos, los clásicos para acceso 
a ficheros ASCII y hojas de cálculo de Excel, etc. como si de tablas se tratase, y dada la 
posición en el mercado de Microsoft y su empeño en poner "OLE en todas partes", es de esperar 
que sigan apareciendo a buen ritmo.
   
 

 

 

Página Diseñada por, José Enrique Martínez García.
San Pedro del Pinatar ( Murcia ). Todos los derechos reservados.
Ksoft © Copyright 1998/1999, enriqu@larural.es
 Todos los contenidos de este Web son propiedad de sus respectivos autores.