Comparteix via


Otras arquitecturas de controladores

Algunos controladores ODBC no se ajustan estrictamente a la arquitectura descrita anteriormente. Esto puede deberse a que los controladores realizan tareas distintas de las de un controlador ODBC tradicional o no son controladores en el sentido normal.

Controlador como componente intermedio

El controlador ODBC puede residir entre el Administrador de controladores y uno o varios otros controladores ODBC. Cuando el controlador en el medio es capaz de trabajar con varios orígenes de datos, actúa como distribuidor de llamadas ODBC (o llamadas traducidas adecuadamente) a otros módulos que realmente acceden a los orígenes de datos. En esta arquitectura, el controlador en el medio está adoptando parte del rol de administrador de controladores.

Otro ejemplo de este tipo de controlador es un programa espía para ODBC, que intercepta y copia las funciones ODBC que se envían entre el Administrador de controladores y el controlador. Esta capa se puede usar para emular un controlador o una aplicación. Para el Gestor de Controladores, la capa parece ser el controlador; para el controlador, la capa parece ser el Gestor de Controladores.

Motores de unión heterogéneos

Algunos controladores ODBC se basan en un motor de consultas para realizar combinaciones heterogéneas. En una arquitectura de un motor de combinación heterogéneo (vea la siguiente ilustración), el controlador aparece en la aplicación como controlador, pero aparece en otra instancia del Administrador de controladores como una aplicación. Este controlador procesa una combinación heterogénea de la aplicación llamando a instrucciones SQL separadas en controladores para cada base de datos unida.

Arquitectura de un motor de unión heterogéneo

Esta arquitectura proporciona una interfaz común para que la aplicación acceda a datos de diferentes bases de datos. Puede usar una manera común de recuperar metadatos, como información sobre columnas especiales (identificadores de fila) y puede llamar a funciones de catálogo comunes para recuperar información del diccionario de datos. Al llamar a la función ODBC SQLStatistics, por ejemplo, la aplicación puede recuperar información sobre los índices de las tablas que se van a combinar, incluso si las tablas están en dos bases de datos independientes. El procesador de consultas no tiene que preocuparse de cómo las bases de datos almacenan los metadatos.

La aplicación también tiene acceso estándar a los tipos de datos. ODBC define tipos de datos SQL comunes a los que se asignan los tipos de datos específicos de DBMS. Una aplicación puede llamar a SQLGetTypeInfo para recuperar información sobre los tipos de datos en distintas bases de datos.

Cuando la aplicación genera una instrucción de combinación heterogénea, el procesador de consultas de esta arquitectura analiza la instrucción SQL y, a continuación, genera instrucciones SQL independientes para que cada base de datos se combine. Mediante el uso de metadatos sobre cada controlador, el procesador de consultas puede determinar la combinación inteligente más eficaz. Por ejemplo, si la instrucción combina dos tablas en una base de datos con una tabla en otra base de datos, el procesador de consultas puede combinar las dos tablas de una base de datos antes de combinar el resultado con la tabla de la otra base de datos.

ODBC en el servidor

Los controladores ODBC se pueden instalar en un servidor para que las aplicaciones puedan usarlas en cualquiera de una serie de máquinas cliente. En esta arquitectura (vea la siguiente ilustración), se instala un administrador de controladores y un único controlador ODBC en cada cliente y otro administrador de controladores y una serie de controladores ODBC en el servidor. Esto permite que cada cliente acceda a una variedad de controladores usados y mantenidos en el servidor.

Arquitectura de controladores ODBC en un servidor

Una ventaja de esta arquitectura es un mantenimiento y configuración de software eficientes. Los controladores solo deben actualizarse en un solo lugar: en el servidor. Mediante el uso de orígenes de datos del sistema, los orígenes de datos pueden definirse en el servidor para el uso de todos los clientes. Los orígenes de datos no se deben definir en el cliente. La agrupación de conexiones se puede usar para simplificar el proceso por el que los clientes se conectan a orígenes de datos.

El controlador del cliente suele ser un controlador muy pequeño que transfiere la llamada del Administrador de controladores al servidor. Su huella puede ser significativamente menor que la de los controladores ODBC totalmente funcionales en el servidor. En esta arquitectura, los recursos de cliente se pueden liberar si el servidor tiene más potencia informática. Además, la eficiencia y la seguridad de todo el sistema se pueden mejorar instalando servidores de copia de seguridad y realizando el equilibrio de carga para optimizar el uso del servidor.