TIPOS DE BLOQUES EN BASE DE DATOS

Presentado por:

Aled Jefrey Aviles

Didier Andres Castillo Rojas

Camilo Andres Cotacio

Milton Alejandro Salcedo

Cristián Fabián vera vea

Presentado a

Frank Jairo Castillo

Sena

(Servicio Nacional de Aprendizaje)

Centro de diseño y metrología

ADSI

(Análisis y Diseño de Sistemas de Información)

Bogotá DC.

BLOQUEO PESIMISTA

El bloqueo pesimista es la técnica por la cual los datos son bloqueados previos a su modificación para evitar que nadie los modifique. Una vez que los datos a actualizar han sido bloqueados la aplicación puede acometer los cambios, con commit o rollback, en ese caso el bloqueo es automáticamente eliminado. Si alguien intenta adquirir un bloqueo de los mismos datos durante el proceso será obligado a esperar hasta que la primera transacción finalice.

Esta técnica es muy simple pero tiene dos problemas fundamentales:

Ø Bloqueo: un usuario selecciona un registro para actualizar, y entonces abandona la operación. Todos los usuarios que necesitan actualizar ese registro tienen que esperar hasta que se complete la transacción, o hasta que se mate y finalice el bloqueo.

Ø Deadlock: Si los usuarios A y B están ambos actualizando la base de datos a la vez y A bloqueo un registro e intenta adquirir un bloqueo mantenido por B, que a su vez está esperando a adquirir un bloqueo mantenido por A ambas transacciones quedarían en espera indefinidamente, dando lugar a un Deadlock.

En general los Sistemas RDBMS ofrecen cláusulas para este bloqueo. Oracle soporta bloqueo pesimista a nivel de fila. La sentencia estándar para el bloqueo es SELECT FOR UPDATE que hace que todas las sentencias UPDATE o SELECT FOR UPDATE de otras conexiones se bloqueen hasta que un commit, rollback o deadlock se produzca. Se produce un deadlock cuando un usuario que tiene la fila A bloqueada intenta bloquear la fila B, mientras que otro usuario tiene la fila B bloqueada e intenta bloquear la A. En este caso Oracle deshabilita uno de los bloqueos del usuario permitiendo al otro usuario bloquear ambas filas.

Oracle además tiene el bloqueo SELECT FOR UPDATE NO WAIT, de modo que Oracle causará una excepción cuando una fila bloqueada es seleccionada. Esto puede ser útil si no se quiere bloquear un usuario para un tiempo indefinido.

BLOQUEO OPTIMISTA

En la estrategia de bloqueo optimista, se presupone que dos transacciones no pueden intentar actualizar la misma entrada de correlación mientras se ejecutan simultáneamente. Por este motivo, la modalidad de bloqueo no necesita mantenerse para el ciclo de vida de la transacción, porque ya que es improbable que más de una transacción actualice la entrada de correlación simultáneamente. Por lo general, la estrategia de bloqueo optimista se utiliza en las situaciones siguientes:

Cuando BackingMap se configura con o sin un cargador y la información de creación de versiones está disponible.

Cuando BackingMap tiene mayoritariamente transacciones que realizan operaciones de lectura. En BackingMap, las operaciones insert, update o remove no se producen con frecuencia en las entradas de correlaciones.

Cuando una correlación BackingMap se inserta, actualiza o elimina con más frecuencia de lo que se lee, pero las transacciones rara vez colisionan en la misma entrada de correlación.

Al igual que en la estrategia de bloqueo pesimista, los métodos de la interfaz ObjectMap determinan cómo eXtreme Scale intenta automáticamente adquirir una modalidad de bloqueo para una entrada de correlación a la que se accede. No obstante, las diferencias entre las estrategias optimistas y pesimistas son:

Al igual que la estrategia de bloqueo pesimista, los métodos get y getAll adquieren una modalidad de bloqueo S cuando se invoca el método. Sin embargo, con el bloqueo optimista, la modalidad de bloqueo S no se mantiene hasta que finaliza la transacción, sino que se libera antes de que el método vuelva a la aplicación. El propósito de adquirir la modalidad de bloqueo es que eXtreme Scale pueda garantizar que sólo los datos confirmados de otras transacciones sean visibles a la transacción actual. Después de que eXtreme Scale haya comprobado que los datos se han confirmado, la modalidad de bloqueo S se libera. Durante el ciclo de confirmación, se realiza una comprobación de la creación de versiones optimista para garantizar que ninguna otra transacción haya modificado la entrada de correlación después de que la transacción actual haya liberado su modalidad de bloqueo S. Si no se capta una entrada de la correlación antes de que se actualice, invalide o suprima, el tiempo de ejecución de eXtreme Scale capta de forma implícita la entrada de la correlación. Esta operación get implícita se realiza para obtener el valor actual en el momento en que la entrada se solicitó para modificarse.

A diferencia de la estrategia de bloqueo pesimista, los métodos getForUpdate y getAllForUpdate se manejan exactamente igual que los métodos get y getAll cuando se utiliza la estrategia de bloqueo optimista. Es decir, se adquiere una modalidad de bloqueo S al inicio del método y se libera la modalidad de bloqueo S antes de que se devuelva a la aplicación.

Todos los otros métodos ObjectMap se manejan exactamente igual que si se manejaran para la estrategia de bloqueo pesimista. Es decir, cuando se invoca el método commit, se obtiene una modalidad de bloqueo X para cualquier entrada de correlación que se inserte, actualice, elimine, manipule o invalide, y la modalidad de bloqueo X se mantiene hasta que la transacción complete el proceso de confirmación.

En la estrategia de bloqueo optimista, se presupone que ninguna transacción que se ejecute simultáneamente con otra intentará actualizar la misma entrada de correlación. Por este motivo, la modalidad de bloqueo no necesita mantenerse durante toda la vida de la transacción ya que es improbable que más de una transacción actualice la entrada de correlación simultáneamente. Sin embargo, como no se ha mantenido la modalidad de bloqueo, otra transacción simultánea podría actualizar de forma potencial la entrada de la correlación, después de que la transacción actual haya liberado su modalidad de bloqueo S.

Para manejar esta posibilidad, eXtreme Scale obtiene un bloqueo X durante el ciclo de confirmación y realiza una comprobación de la creación de versiones optimista para verificar que ninguna otra transacción haya modificado la entrada de correlación después de que la transacción actual haya leído la entrada de correlación en BackingMap. Si otra transacción ha modificado la entrada de correlación, se produce una anomalía en la comprobación de versiones y se muestra

una excepción OptimisticCollisionException. Esta excepción obliga a la transacción actual retrotraerse y la aplicación debe volver a intentar toda la transacción. La estrategia de bloqueo optimista es muy útil cuando se producen sobre todo lecturas de una correlación y rara vez se producen actualizaciones de la misma entrada de correlación.

BLOQUEO OPTIMISTA CON CONTROL DE CONCURRENCIA

El bloqueo optimista no bloquea los registros que se van a actualizar y asume que los datos que están siendo actualizados no van a cambiar desde que se han leído. Puesto que en nuestro caso no se puede asumir esto es necesario un control de la concurrencia, de esta manera el bloqueo optimista con control de concurrencia asegura que los datos que están siendo escritos son consistentes con los leídos en primera instancia, es decir que ninguna otra transacción ha actualizado los datos después de la lectura. El procedimiento para asegurar la consistencia es muy sencillo: se leerá un valor junto al registro, se actualizará ese valor a la BD cuando el registro es actualizado.

Existen varios mecanismos asegurar el control de la concurrencia, el más común es el uso de un timestamp modificado. Este mecanismo sólo ofrece una resolución de un segundo.

PROCEDOMIENTOS DE ALMACENADO

Conjunto de comandos que pueden ser ejecutados directamente en el servidor, es decir, será ejecutado por el servidor de Base de Datos y no por el programa cliente que lo accede, permitiendo la ejecución de una acción o conjunto de acciones especificas. Los procedimientos almacenados son objetos de base de datos, y sus nombres deben ajustarse a las reglas para identificadores.

Es posible incluir cualquier número y cualquier tipo de instrucción SQL, salvo las instrucciones create. Un procedimiento puede ser tan sencillo como una sola instrucción que enumere los nombres de todos los usuarios de una base de datos:

create procedure name list

as select name from sysusers

Para ejecutar un procedimiento almacenado, emplee la palabra clave Execute y el nombredel procedimiento almacenado, o simplemente especifique el nombre del procedimiento,siempre que se envíe a SQL Server solo o sea la primera instrucción de un lote. Puede ejecutar name list de cualquiera de las siguientes formas:

Namelist

Execute namelist

exec namelist

Para ejecutar un procedimiento almacenado en un SQL Server remoto, debe proporcionar elnombre del servidor. La sintaxis completa de una llamada de procedimiento remoto es:

Execute server_name .[ database_name ].[ owner ].procedure_name

Los siguientes ejemplos ejecutan el procedimiento Namelist en la base de datos pubs2 en el servidor GATEWAY:

execute gateway.pubs2..namelist

gateway.pubs2.dbo.namelist

exec gateway...namelist

El último ejemplo sólo funciona si pubs 2 es la base de datos predeterminada del usuario.El nombre de la base de datos es opcional sólo si el procedimiento almacenado se encuentraen la base de datos predeterminada del usuario. El nombre del propietario es opcional sólo si el propietario de la base de datos (" dbo" ) es el propietario del procedimiento o si el usuario lo posee. Lógicamente, es necesario tener permiso para ejecutar el procedimiento. Un procedimiento puede incluir más de una instrucción.

create procedure showall as

select count(*) from sysusers

select count(*) from sysobjects

select count(*) from syscolumns

Cuando se ejecuta el procedimiento, los resultados de cada comando se muestran en elorden en que la instrucción aparece en el procedimiento.

Sintaxis

Para crear un procedimiento almacenado debemos emplear la sentencia CREATE PROCEDURE.

TRIGGERS

Un trigger (o disparador) en una Base de datos, es un procedimiento que se ejecuta cuando se cumple una condición establecida al realizar una operación. Dependiendo de la base de datos, los triggers pueden ser de inserción (INSERT), actualización (UPDATE) o borrado (DELETE). Algunas bases de datos pueden ejecutar triggers al crear, borrar o editar usuarios, tablas, bases de datos u otros objetos.

Son usados para mejorar la administración de la Base de datos, sin necesidad de contar con que el usuario ejecute la sentencia de SQL. Además, pueden generar valores de columnas, previene errores de datos, sincroniza tablas, modifica valores de una vista, etc. Permite implementar programas basados en paradigma lógico (sistemas expertos, deducción).

La estructura básica de un trigger es:

Llamada de activación: es la sentencia que permite "disparar" el código a ejecutar.

Restricción: es la condición necesaria para realizar el código. Esta restricción puede ser de tipo condicional o de tipo nulidad.

Acción a ejecutar: es la secuencia de instrucciones a ejecutar una vez que se han cumplido las condiciones iniciales.

TRIGGERS MY SQL

La estructura básica de un trigger es:

Llamada de activación: es la sentencia que permite "disparar" el código a ejecutar.

Restricción: es la condición necesaria para realizar el código. Esta restricción puede ser de tipo condicional o de tipo nulidad.

Acción a ejecutar: es la secuencia de instrucciones a ejecutar una vez que se han cumplido las condiciones iniciales.

Como en MySQL las sentencias se ejecutan luego de escribir el signo punto y coma (;), cabe destacar que para crear un disparador en MySQL, antes se escribe la sentencia DELIMITER seguida de un carácter tal como |, la cual asigna la función del punto y coma (;) a otro carácter permitiendo que el disparador sea escrito usando los punto y comas sin que se ejecute mientras se escribe; después de escrito el disparador se escribe nuevamente la sentencia DELIMITER ; para asignar al punto y coma su función habitual.

TRIGGERS POSTGRADESQL

Desde 1997 PostgreSQL soporta el uso de disparadores, estos pueden anexarse a las tablas pero no a las vistas; aunque a las vistas se les pueden crear reglas.

Al igual que en MySQL los disparadores de PostgreSQL se pueden activar luego de sentencias INSERT, UPDATE o DELETE

Cuando hay varios disparadores, se activan en orden alfabético.

Además de permitir el uso de funciones en el lenguaje nativo de PostgreSQL, PL/PgSQL, los disparadores también permiten invocar funciones escritas en otros lenguajes como PL/Perl.

En Postgres un disparador ejecuta una función la cual contiene el código de lo que se requiere, esto difiere del método expuesto anteriormente para MySQL que escribe el código a ejecutarse dentro del mismo disparador.

El siguiente es un ejemplo de disparador creado con su respectiva función:

Fila Trigger Level

Row nivel de disparo se dispara cada fila vez se ve afectada por Insert, Update o el comando Eliminar. Si la declaración no afecta a ninguna fila, ninguna acción de disparo ocurre.

Al definir un disparador, puede especificar el número de veces que la acción de disparo se va a ejecutar:

Una vez por cada fila afectada por la declaración de activación, como un gatillo disparado por una ACTUALIZACIÓN comando que actualice muchas filas

Una vez para la sentencia activadora, no importa cuántas filas afecta

Declaración del nivel de disparo

Este tipo de desencadenador se activa cuando una sentencia SQL afecta a las filas de la tabla. El disparador se activa y lleva a cabo su actividad con independencia del número de filas afectadas debido a la sentencia SQL.

Un gatillo fila se dispara cada vez que la tabla se ve afectada por la declaración de activación. Por ejemplo, si una ACTUALIZACIÓN instrucción actualiza varias filas de una tabla, una fila gatillo se dispara una vez por cada fila afectada por la ACTUALIZACIÓN comunicado. Si una declaración de disparo afecta a ninguna fila, un disparador fila no se ejecuta.

Disparadores de fila son útiles si el código de la acción de disparo depende de los datos proporcionados por la sentencia activadora o filas que se ven afectados. Por ejemplo, la figura 22-3 ilustra un disparador fila que utiliza los valores de cada fila afectada por la declaración de activación.

TRANSACCIONES

Una transacción en un Sistema de Gestión de Bases de Datos (SGBD), es un conjunto de órdenes que se ejecutan formando una unidad de trabajo, es decir, en forma indivisible o atómica.

Un SGBD se dice transaccional, si es capaz de mantener la integridad de los datos, haciendo que estas transacciones no puedan finalizar en un estado intermedio. Cuando por alguna causa el sistema debe cancelar la transacción, empieza a deshacer las órdenes ejecutadas hasta dejar la base de datos en su estado inicial (llamado punto de integridad), como si la orden de la transacción nunca se hubiese realizado. Una transacción debe contar con ACID (un acrónimo inglés) que quiere decir: Atomicidad, Consistencia, Durabilidad y Aislamiento. Entonces para que un Sistema de Gestión de Bases de Datos sea considerado Transaccional, debe cumplir con estos criterios (ACID).

Para esto, el lenguaje de consulta de datos SQL (Structured Query Language), provee los mecanismos para especificar que un conjunto de acciones deben constituir una transacción.

BEGIN TRAN: Especifica que va a empezar una transacción.

Sintaxis

transaction_nameEs el nombre asignado a la transacción. transaction_name debe cumplir las reglas de los identificadores, pero no se admiten identificadores de más de 32

caracteres. Utilice nombres de transacciones solamente en la pareja más externa de instrucciones BEGIN…COMMIT o BEGIN…ROLLBACK anidadas. transaction_name siempre distingue mayúsculas de minúsculas, incluso cuando la instancia de SQL Server no distingue mayúsculas de minúsculas.

@tran_name_variableNombre de una variable definida por el usuario que contiene un nombre de transacción válido. La variable debe declararse con un tipo de datos char, varchar, nchar o nvarchar. Si se pasan más de 32 caracteres a la variable, solo se utilizarán los primeros 32; el resto de caracteres se truncará.

WITH MARK [ 'description' ]Especifica que la transacción está marcada en el registro. description es un valor de tipo string que describe la marca. Un valor de description superior a 128 caracteres se trunca a 128 caracteres antes de almacenarse en la tabla msdb.dbo.logmarkhistory.Si utiliza WITH MARK, debe especificar un nombre de transacción. WITH MARK permite restaurar un registro de transacciones hasta una marca con nombre.

Al anidar transacciones, intentar marcar una transacción ya marcada da lugar a un mensaje de advertencia (no de error):

"BEGIN TRAN T1 WITH MARK ...;"

"UPDATE tabla1 ...;"

"BEGIN TRAN M2 WITH MARK ...;"

"Servidor: mensaje 3920, nivel 16, estado 1, línea 3"

"La opción WITH MARK solo se aplica a la primera instrucción BEGIN TRAN WITH MARK."

"La opción es ignorada."EJEMPLO

COMMIT TRAN: Le indica al motor que puede considerar la transacción completada con éxito.

ROLLBACK TRAN: Indica que se ha alcanzado un fallo y que debe restablecer la base al punto de integridad.

En tecnologías de base de datos, un rollback es una operación que devuelve a la base de datos a algún estado previo. Los Rollbacks son importantes para la integridad de la base de datos, a causa de que significan que la base de datos puede ser restaurada a una copia limpia incluso después de que se han realizado operaciones erróneas. Son cruciales para la recuperación de crashes de un servidor de base de datos; realizando rollback(devuelto) cualquier transacción que estuviera activa en el tiempo del crash, la base de datos es restaurada a un estado consistente.

En SQL, ROLLBACK es un comando que causa que todos los cambios de datos desde la última sentencia BEGIN WORK, o START TRANSACTION sean descartados por el sistema de gestión de base de datos relacional (RDBMS), para que el estado de los datos sea "rolled back"(devuelto) a la forma en que estaba antes de que aquellos cambios tuvieran lugar.

Una sentencia ROLLBACK también publicará cualquier savepoint existente que puediera estar en uso.

En muchos dialectos de SQL, ROLLBACKs son específicos de la conexión. Esto significa que si se hicieron dos conexiones a la misma base de datos, un ROLLBACK hecho sobre una conexión no afectará a cualesquiera otras conexiones. Esto es vital para el buen funcionamiento de la Concurrencia.

La funcionalidad de rollback está normalmente implementada con un Log de transacciones, pero puede también estar implementada mediante control de concurrencia multiversión.

En un sistema ideal, las transacciones deberían garantizar todas las propiedades ACID; en la práctica, a veces alguna de estas propiedades se simplifica o debilita con vistas a obtener un mejor rendimiento.

Personas que lo han encontrado útil: 1 de 2 - Valorar este tema

Revierte una transacción explícita o implícita hasta el inicio de la transacción o hasta un punto de retorno dentro de la transacción. Puede usar ROLLBACK TRANSACTION para borrar todas las modificaciones de datos realizadas desde el inicio de la transacción o hasta un punto de retorno. También libera los recursos que mantiene la transacción.

SINTAXIS

transaction_name

Es el nombre asignado a la transacción en BEGIN TRANSACTION. transaction_name debe ajustarse a las reglas para los identificadores, pero solo se usan los 32 primeros caracteres del nombre de la transacción. Cuando se anidan transacciones, transaction_name debe ser el nombre de la instrucción BEGIN TRANSACTION más externa. transaction_name siempre distingue mayúsculas de minúsculas, incluso cuando la instancia de SQL Server no distingue mayúsculas de minúsculas.

@ tran_name_variable

Nombre de una variable definida por el usuario que contiene un nombre de transacción válido. La variable se debe declarar con un tipo de datos char, varchar, nchar o nvarchar.

savepoint_name

Es savepoint_name de una instrucción SAVE TRANSACTION. savepoint_name debe ajustarse a las reglas para los identificadores. Utilice savepoint_name cuando una operación de reversión condicional solo deba afectar a parte de la transacción.

@ savepoint_variable

Es el nombre de una variable definida por el usuario que contiene un nombre de punto de retorno válido. La variable debe declararse con un tipo de datos char, varchar, nchar o nvarchar.

EJEMPLO

1. JDBC (Java Database Connectivity)

Java Database Connectivity, más conocida por sus siglas JDBC, es una API que permite la ejecución de operaciones sobre bases de datos desde el lenguaje de programación Java, independientemente del sistema operativo donde se ejecute o de la base de datos a la cual se accede, utilizando el dialecto SQL del modelo de base de datos que se utilice.

El API JDBC se presenta como una colección de interfaces Java y métodos de gestión de manejadores de conexión hacia cada modelo específico de base de datos. Un manejador de conexiones hacia un modelo de base de datos en particular es un conjunto de clases que

implementan las interfaces Java y que utilizan los métodos de registro para declarar los tipos de localizadores a base de datos (URL) que pueden manejar. Para utilizar una base de datos particular, el usuario ejecuta su programa junto con la biblioteca de conexión apropiada al modelo de su base de datos, y accede a ella estableciendo una conexión; para ello provee el localizador a la base de datos y los parámetros de conexión específicos. A partir de allí puede realizar cualquier tipo de tarea con la base de datos a la que tenga permiso: consulta, actualización, creación, modificación y borrado de tablas, ejecución de procedimientos almacenados en la base de datos, etc.

Evidentemente, para muchos, la respuesta a esta pregunta es ya sabida. Sin embargo, nos llegan gran cantidad de cuestiones acerca de este tema, y es por eso que hemos decidido hacer una serie de tutoriales que cubran la mayor parte de los aspectos y características de este estándar definido por SUN. Este primer tutorial es puramente teórico, más adelante haremos otros tutoriales referentes a este tema, donde cubriremos algunos aspectos del API de JDBC menos conocidos, y también uno final donde mostraremos algunas de las últimas novedades incluidas en el API de Java5.

JDBC es un API (Application programming interface) que describe o define una librería estándar para acceso a fuentes de datos, principalmente orientado a Bases de Datos relacionales que usan SQL (Structured Query Language). JDBC no sólo provee un interfaz para acceso a motores de bases de datos, sino que también define una arquitectura estándar, para que los fabricantes puedan crear los drivers que permitan a las aplicaciones java el acceso a los datos.

Sun define JDBC como: “The JDBC API is the industry standard for database-independent connectivity between the Java programming language and a wide range of databases.”

1.1 Filosofía y Objetivos de JDBC

Cuando SUN se puso a trabajar en este tema, decidió seguir una serie de normas a seguir para la definición del interfaz, y que han condicionado en gran manera el resultado final. Algunas de estas características son:

1.1.2 API A NIVEL SQL. JDBC es un API de bajo nivel, es decir, que está orientado a permitir ejecutar comandos SQL directamente, y procesar los resultados obtenidos. Esto supone que será tarea del programador crear APIs de más alto nivel apoyándose directamente sobre JDBC.

1.1.3 COMPATIBLE CON SQL. Cada motor de Base de Datos implementa una amplia variedad de comandos SQL, y muchos de ellos no tienen porque ser compatibles con el resto de motores de Base de Datos. JDBC, para solventar este problema de incompatibilidad, ha tomado la siguiente posición

JDBC permite que cualquier comando SQL pueda ser pasado al driver directamente, con lo que una aplicación Java puede hacer uso de toda la

funcionalidad que provea el motor de Base de Datos, con el riesgo de que esto pueda producir errores o no en función del motor de Base de Datos.

Con el objetivo de conseguir que un driver sea compatible con SQL (SQL compliant), se obliga a que al menos, el driver cumpla el Estándar ANSI SQL 92.

JDBC debe ser utilizable sobre cualquier otro API de acceso a Bases de Datos, o más en particular ODBC (Open Database Connectivity)

JDBC debe proveer un interfaz homogéneo al resto de APIs de Java. JDBC debe ser un API simple, y desde ahí, ir creciendo. JDBC debe ser fuertemente tipado, y siempre que sea posible de manera estática, es

decir, en tiempo de compilación, para evitar errores en tiempo de ejecución. JDBC debe mantener los casos comunes de acceso a Base de Datos lo más sencillo

posible: Mantener la sencillez en los casos más comunes (SELECT, INSERT, DELETE y

UPDATE) Hacer realizables los casos menos comunes: Invocación de procedimientos

almacenados... Crear múltiples métodos para múltiple funcionalidad. JDBC ha preferido incluir gran

cantidad de métodos, en lugar de hacer métodos complejos con gran cantidad de parámetros.

1.1.2 Procedimiento de Conexión y acceso a datos con JDBC.

1.1.2.1 Consideraciones previas.

El proceso de acceso a una Base de Datos a través de JDBC, exige dar una serie de pasos previos antes de crear la conexión al motor de Base de Datos. El primer paso es determinar el entorno en el que el proyecto va a ser instalado, y más en concreto, que parámetros del entorno afectan directamente a JDBC:

Qué motor de Base de Datos vamos a usar

Debemos considerar las características específicas de una base de datos, como por ejemplo, como mapear los tipos de datos SQL a Java.

Qué driver vamos a usar

Es probable encontrarnos varios drivers distintos para la misma fuente de datos. Debemos saber detectar cual es el driver más adecuado para nuestra aplicación, por ejemplo, si elegimos un driver ODBC/JDBC, tendremos más flexibilidad para elegir distintas fuentes de datos, pero si por ejemplo trabajamos con una Base de Datos Oracle, un driver JDBC diseñado específicamente para esta base de datos será mucho más eficiente.

Donde estará localizado el driver

En función de donde se encuentre el driver físicamente, debemos considerar aspectos de rendimiento y seguridad. Por ejemplo, si cargamos el driver desde un servidor remoto tendremos que considerar aspectos sobre seguridad de Java.

1.2.2 Procedimiento de conexión.

El procedimiento de conexión con el controlador de la base de datos, independientemente de la arquitectura es siempre muy similar.

Cargar el driver. Cualquier driver JDBC, independientemente del tipo debe implementar el interfaz java.sql.Driver. La carga del driver se puede realizar de dos maneras distintas:Definiendo los drivers en la variable sql.driver (variable que mantiene todos las clases de los drivers separados por comas) Cuando la clase DriverManager se inicializa, busca esta propiedad en el sistema.El programador puede forzar la carga de un driver específico, usando el método Class.forName(driver).

Registro del driver. Independientemente de la forma de carga del driver que llevemos a cabo, será responsabilidad de cada driver registrarse a sí mismo, usando el método DriverManager.registerDriver. Esto permite a la clase DriverManager, usar cada driver para crear conexiones con el controlador de Base de Datos. Por motivos de seguridad, la capa que gestiona JDBC, controlará en todo momento que driver es el que se está usando, y cuando se realicen conexiones, sólo se podrán usar drivers que estén en el sistema local de ficheros o que usen el mismo ClassLoader que el código que está intentando crear la conexión.

En el primero de los casos (a través de la propiedad sql.driver), JDBC usará el primer driver que permita conectarse correctamente a la Base de Datos.

Crear una conexión. El objetivo es conseguir un objeto del tipo java.sql.Connection a través del método DriverManager.getConnection(String url). La capa de gestión, cuando este método es invocado, tratará de encontrar un driver adecuado para conectar a la base de datos especificada en la URL, intentándolo por el orden especificado en la variable sql.driver. Cada driver debería examinar si ellos proveen el “subprotocolo” que especifica la URL. (Ver anexo)

1.1.3 Tipos de conectores (drivers) JDBC

Los conectores o drivers JDBC, se pueden dividir en cuatro tipos principalmente:

Tipo 1. JDBC-ODBC bridge más driver ODBC: “BRIDGE”

Permite el acceso a Base de Datos JDBC mediante un driver ODBC. Cada máquina cliente que use el puente, debe tener librerías clientes de ODBC (dll propias del S.O)

Ventajas: Buena forma de aprender JDBC. También puede ser buena idea usarlo, en sistemas donde cada máquina cliente tenga ya instalado los drivers ODBC. También es posible que sea la única forma de acceder a ciertos motores de Bases de Datos.

desventajas: No es buena idea usar esta solución para aplicaciones que exijan un gran rendimiento, ya que la transformación JDBC-ODBC es costosa. Tampoco es buena solución para aplicaciones con alto nivel de escalabilidad.

Tipo 2. Driver Java parciales: “NATIVE”

Traducen las llamadas al API de JDBC Java en llamadas propias del motor de Base de Datos (Oracle, Informix...). Al igual que el tipo anterior, exige en las máquinas clientes código binario propio del cliente de la Base de datos específica y del sistema operativo

Ventajas: Mejor rendimiento que el anterior. Quizá puede ser buena solución para entornos controlados como intranets. Ejemplo OCI oracle.

Inconvenientes: Principalmente la escalabilidad, ya que estos drivers exigen que en la máquina cliente librerías del cliente de la Base de Datos.

Tipo 3. Driver JDBC a través de Middleware: “NETWORK”

Traduce las llamadas al API JDBC en llamadas propias del protocolo específico del broker. Éste se encargará de traducirlas de nuevo en sentencias propias del motor de Base de Datos de cada caso.

Ventajas: Buena solución cuando necesitamos acceder a Bases de Datos distintas y se quiere usar un único driver JDBC para acceder a las mismas. Al residir la traducción en el servidor del middleware, los clientes no necesitan librerías específicas, tan solo el driver.

Inconvenientes: La desventaja principal reside en la configuración del servidor donde se encuentra el middleware. Necesitará librerías específicas para cada motor de base de datos distinto, etc.

Tipo 4: Driver java puro (acceso directo a Base de Datos): “THIN”.

Convierte o traduce las llamadas al API JDBC en llamadas al protocolo de red usado por el motor de bases de datos, lo que en realidad es una invocación directa al motor de bases de datos.

Ventajas: 100 % portable. Buen rendimiento. El cliente sólo necesita el driver. Inconvenientes: Al ser independiente de la plataforma, no aprovecha las

características específicas del S.O

1.1.3 Instalación de JDBC

El proceso de instalación de JDBC se podría dividir en tres partes distintas:

Descargar el API de JDBC: Instalar el driver en la máquina cliente (máquina que crea las conexiones)

La instalación del driver dependerá en gran medida del tipo de driver que hayamos seleccionado.

Para los tipo 1 y 2, además de las librerías del driver, necesitaremos ciertas librerías propias del cliente del motor de base de datos que estemos usando y quizá ficheros de configuración...

Para el tipo 3, en la máquina cliente tan solo necesitaremos el driver. En el servidor donde resida el middleware, necesitaremos drivers específicos de cada motor de base de datos y en su caso, librerías propias del cliente del motor de base de datos.

Para el tipo 4, tan solo necesitaremos el driver.

1.1.3.1 Instalar el controlador o motor de base de datos.

Evidentemente, necesitaremos tener instalado un motor de base de datos. Esta instalación será distinta en función de la Base de Datos y del S.O donde vaya a correr.

1.1.4 Arquitecturas JDBC

La arquitectura básica de JDBC (ya la hemos visto) es simple. Una clase llamada DriverManager provee un mecanismo para controlar un conjunto de drivers JDBC. Esta clase intenta cargar los drivers especificados en la propiedad del sistema jdbc.drivers. También podemos cargar un driver explicitamente usando Class.forName(). Durante la carga, el driver intentará registrarse a si mismo usando el método clase DriverManager.registerDriver(). Cuando se invoque al método DriverManager.getConnection(), ésta buscará el primer driver de los registrados que pueda manejar una conexión como la descrita en la URL y retornará un objeto que implemente el interfaz java.sql.Connection.

Sin embargo, en función de la localización de la base de datos, el driver, la aplicación y el protocolo de comunicación usado, nos podemos encontrar distintos escenarios que accedan a Base de Datos a través de JDBC:

Aplicaciones standalone Applets comunicando con un servidor Web Aplicaciones y applets comunicando con una base de datos a través de un puente

JDBC/ODBC. Aplicaciones accediendo a recursos remotos usando mecanismos como Java RMI etc...

Todos ellos se pueden agrupar en dos tipos distintos de arquitecturas:

Arquitecturas JDBC en dos capas.

La aplicación que accede a la base de datos reside en el mismo lugar que el driver de la base de datos. El driver accederá al servidor donde corra el motor de base de datos.

En este caso, será el driver el encargado de manejar la comunicación a través de la red.

En el ejemplo, una aplicación java corriendo en una máquina cliente que usa el driver también local. Toda la comunicación a través de la red con la base de datos será manejada por el driver de forma transparente a la aplicación Java.

Arquitecturas JDBC en tres capas.

Una aplicación o applet corriendo en una máquina y accediendo a un driver de base de datos situado en otra máquina. Ejemplos de esta situación:

Un applet accediendo al driver a través de un Web Server

Una aplicación accediendo a un servidor remoto que comunica localmente con el driver

Una aplicación comunicando con un servidor de aplicaciones que accede a la base de datos por nosotros.

1.1.6 El Armazón de JDBC

JavaSoft proporciona tres componentes JDBC como la parte de la JDK:

el JDBC driver manager, la JDBC driver test suite el puente JDBC-ODBC.

El JDBC driver manager es el espinazo de la arquitectura de JDBC. Realmente es bastante pequeño y simple; su función primaria es conectar las aplicaciones de Java al chófer de JDBC correcto y entonces salir de la manera.

La JDBC driver test suite proporciona un poco de confianza en que drivers de JDBC ejecutarán su programa. Pueden designarse sólo drivers que pasan la JDBC driver test suite

El Armazón de JDBC

El puente de JDBC-ODBC les permite a los drivers de ODBC ser usado como drivers de JDBC. Y a largo plazo proporcionará una manera de acceder alguno del DBMSs menos popular si no se crean los drivers de JDBC para ellos.

1.1.5 Anexo:

JDBC provee un mecanismo para permitir nombrar las bases de datos, para que los programadores puedan especificar a que base de datos desean conectarse. Este sistema debe tener las siguientes características:

Drivers de diferentes tipos pueden tener diferentes formas de nombrar las bases de datos.

Este sistema de nombrado debe ser capaz de acoger diversos parámetros de configuración de la red.

Debería ser capaz de acoger cierto nivel de indirección, para que los nombres pudiesen ser resueltos de alguna manera (DNS...)

URL. Estas características están ya estandarizadas en el concepto de URL. JDBC recomienda la siguiente estructura de nombrado de bases de datos: jdbc:<subprotocol>:<subname>

jdbc: parte fija

subprotocol: mecanismo particular se acceso a base de datos

subname: dependerá del subprotocolo. JDBC recomienda seguir también la convención de nombrado URL: //hostname:port/subsubname

El subprotocolo odbc: Este subprotocolo ha sido reservado para aquellos que quieran seguir la convención ODBC para nombrado de bases de datos:

jdbc: odbc:<data-source-name>[;<attribute-name>=<attribute-value>]

El API JDBC, también provee la posibilidad de pasar una lista de propiedades para crear la conexión: DriverManager.getConnection (String URL, Properties props); Dos propiedades definidas por convención son

user

password

¿Qué es el ODBC?Open Data Base Conectivity

O lo que es lo mismo, conectividad abierta de bases de datos. Si escribimos una aplicación para acceder a las tablas de una DB de Access, ¿qué ocurrirá si después queremos que la misma aplicación, y sin reescribir nada, utilice tablas de SQL Server u otra DB cualquiera? La respuesta es sencilla: no funcionará. Nuestra aplicación, diseñada para un motor concreto, no sabrá dialogar con el otro. Evidentemente, si todas las DB funcionaran igual, no tendríamos este problema.... aunque eso no es probable que ocurra nunca.

Pero si hubiera un elemento que por un lado sea siempre igual, y por el otro sea capaz de dialogar con una DB concreta, solo tendríamos que ir cambiando este elemento, y nuestra aplicación siempre funcionaría sin importar lo que hay al otro lado... algo así como ir cambiando las boquillas de una manguera. A esas piezas intercambiables las llamaremos orígenes de datos de ODBC

Casi todas las DB actuales tienen un ODBC. Debido a que este elemento impone ciertas limitaciones, ya que no todo lo que la DB sabe hacer es compatible con la aplicación, como velocidad de proceso, tiempos de espera, máxima longitud de registro, número máximo de registros, versión de SQL, etc., está cayendo en desuso a cambio de otras técnicas de programación, pero aún le quedan muchos años de buen servicio.

Todo lo referido aquí funciona con Windows NT Server 4.0 con el Service Pack 4 o superior instalado (el último publicado es el 6). El Option Pack 4 para actualizar el IIS y las extensiones ASP. SQL Server 6.5 y Access 97. Por supuesto, también funciona con las versiones modernas de

servidores como 2003 Server, y también XP PRO, que lleva un IIS 5.0 de serie. Igualmente es posible utilizar bases de datos de Access 2000 o 2003.

Esas otras técnicas de programación antes mencionadas, se utilizan ya en el nuevo Windows 2003, Office 2003 y SQL Server 2000, que además de ODBC pueden utilizar.... pero esa es otra historia.

Esta es la idea: por un lado el ODBC provee de unas caracteríisticas siempre homogéneas, y por el otro permite distintos controladores que aseguran la conectividad de la aplicación con diferentes bases de datos.

Ahora que ya sabemos qué es y para lo que sirve, procedamos a su instalación: es un proceso sencillo, pero según la base de datos elegida sea Access o SQL Server, cambian un poco, y como no podía ser menos, hay algunos trucos que conviene conocer.

Open DataBase Connectivity (ODBC) es un estándar de acceso a las bases de datos desarrollado por SQL Access Group en 1992. El objetivo de ODBC es hacer posible el acceder a cualquier dato desde cualquier aplicación, sin importar qué sistema de gestión de bases de datos (DBMS) almacene los datos. ODBC logra esto al insertar una capa intermedia (CLI) denominada nivel de Interfaz de Cliente SQL, entre la aplicación y el DBMS. El propósito de esta capa es traducir las consultas de datos de la aplicación en comandos que el DBMS entienda. Para que esto funcione tanto la aplicación como el DBMS deben ser compatibles con ODBC, esto es que la aplicación debe ser capaz de producir comandos ODBC y el DBMS debe ser capaz de responder a ellos. Desde la versión 2.0 el estándar soporta SAG y SQL.

El software funciona de dos modos, con un software manejador en el cliente, o una filosofía cliente-servidor. En el primer modo, el driver interpreta las conexiones y llamadas SQL y las traduce desde el API ODBC hacia el DBMS. En el segundo modo para conectarse a la base de datos se crea una DSN dentro del ODBC que define los parámetros, ruta y características de la conexión según los datos que solicite el creador o fabricante.

Java Database Connectivity (JDBC) es un derivado inspirado en el mismo, una interfaz de programación de aplicaciones que permite la ejecución de operaciones sobre bases de datos desde el lenguaje de programación Java independientemente del sistema operativo donde se ejecute o de la base de datos a la cual se accede utilizando el dialecto SQL del modelo de base de datos que se utilice.

Orígenes de datos ODBC: ¿Qué es un origen de datos?

A un origen de datos ODBC (origen de datos ODBC: datos e información necesaria para tener acceso a esos datos desde programas y bases de datos que admitan el protocolo ODBC (conectividad abierta de bases de datos).), por ejemplo, una base de datos y el servidor donde reside, se tiene acceso a través de un controlador de Conectividad abierta de base de datos (ODBC (Conectividad abierta de bases de datos): método estándar para compartir datos entre bases de datos y programas. Los controladores ODBC utilizan SQL (Lenguaje de consulta estructurado) para obtener acceso a datos externos.) (ODBC).

Un origen de datos está formado por la procedencia de los datos y la información de conexión necesaria para tener acceso a los mismos. Ejemplos de orígenes de datos son Microsoft Access, Microsoft SQL Server, Oracle RDBMS, una hoja de cálculo y un archivo de texto. Ejemplos de información de conexión son la ubicación del servidor, el nombre de la base de datos, el Id. de inicio de sesión, la contraseña y diversas opciones de controlador ODBC que describen cómo conectarse al origen de datos.

En la arquitectura ODBC, una aplicación (como Access o un programa de Microsoft Visual Basic) se conecta al Administrador de controladores ODBC que, a su vez, utiliza un controlador ODBC específico (por ejemplo, el controlador ODBC de Microsoft SQL) para conectarse a un origen de datos (en este caso, una base de datos de Microsoft SQL Server (base de datos SQL: base de datos basada en el lenguaje SQL, lenguaje de consulta estructurado.)). En Access, los orígenes de datos ODBC se utilizan para conectarse a orígenes de datos externos a Access que no tienen controladores integrados.

Para conectarse a estos orígenes de datos, siga el procedimiento que se indica a continuación:

Instale el controlador ODBC apropiado en el equipo que contenga el origen de datos. Defina un nombre de origen de datos (DSN) utilizando el Administrador de orígenes de

datos ODBC para almacenar la información de conexión en el Registro de Microsoft Windows o en un archivo DSN, o bien una cadena de conexión en código de Visual Basic para pasar la información de conexión directamente al Administrador de controladores ODBC.

Orígenes de datos de equipos

Los orígenes de datos de equipos almacenan información de conexión en el registro de Windows de un determinado equipo con un nombre definido por el usuario. Los orígenes de datos de equipos sólo se pueden utilizar en el equipo en que estén definidos. Hay dos tipos de orígenes de datos de equipos, a saber, del usuario y del sistema. Los orígenes de datos del usuario sólo pueden ser utilizados por el usuario actual y únicamente los puede ver dicho usuario. Los orígenes de datos del sistema pueden ser utilizados por todos los usuarios de un equipo y los pueden ver todos los usuarios del equipo y de los servicios del sistema como, por ejemplo, servicios de Microsoft Windows. Un origen de datos de equipo es especialmente útil cuando se desea proporcionar seguridad adicional, dado que ayuda a garantizar que sólo los usuarios que han iniciado una sesión pueden ver un origen de datos de equipo y un usuario remoto no puede copiar dicho origen de datos a otro equipo.

Orígenes de datos de archivos

Los orígenes de datos de archivos (también denominados archivos DSN) almacenan información de conexión en un archivo de texto, no en el Registro de Windows, y, generalmente, se pueden utilizar con mayor flexibilidad que los orígenes de datos de equipos. Por ejemplo, se puede copiar un origen de datos de archivo a cualquier equipo con el controlador ODBC correcto para que su aplicación pueda basarse en información de conexión coherente y precisa para todos los equipos utilizados. También se puede colocar el origen de datos de archivo en un único servidor, compartirlo entre varios equipos en la red, y mantener fácilmente la información de conexión en una ubicación.

También es posible que un origen de datos no se pueda compartir. Un origen de datos de archivo que no se puede compartir reside en un único equipo y apunta a un origen de datos de equipo. Es posible utilizar orígenes de datos de archivos que no se pueden compartir para obtener acceso a orígenes de datos de equipos existentes desde orígenes de datos de archivos.

Cadenas de conexión

Si es programador, puede definir una cadena de conexión con formato en su código de Microsoft Visual Basic que especifique la información de conexión. La utilización de una cadena de conexión evita la definición de un equipo o un archivo DSN y pasa la información de conexión directamente al Administrador de controladores ODBC. Esto es útil, por ejemplo, cuando se desea evitar que los administradores de sistemas o los usuarios tengan que crear primero un DSN, o para simplificar la instalación de su aplicación. Para mantener la seguridad de la información de cadena de conexión de su código, ayude a proteger el código creando un archivo MDE o mediante una contraseña.

Nota de seguridad Utilice contraseñas fuertes que combinen letras en mayúsculas y minúsculas, números y símbolos. Las contraseñas débiles son aquellas que no mezclan dichos elementos. Un ejemplo de contraseña fuerte sería Y6dh!et5, y de débil, Casa27. Utilice una contraseña fuerte que pueda recordar para no tener que anotarla en ningún sitio.

En computación, ODBC (Open Database Connectivity) es un estándar de lenguaje de programación middleware API para acceder a los sistemas de gestión de bases de datos (DBMS). Los diseñadores de ODBC objeto hacer independiente de los sistemas de bases de datos y sistemas operativos. Una aplicación escrita utilizando ODBC puede ser portado a otras plataformas, tanto en el lado del cliente y del servidor, con pocos cambios en el código de acceso a datos.

ODBC logra la independencia DBMS utilizando un controlador ODBC como una capa de traducción entre la aplicación y el DBMS. La aplicación utiliza funciones ODBC a través de un gestor de controladores ODBC con la que está vinculado, y el conductor pasa la consulta a los DBMS. Un controlador ODBC se puede considerar como algo análogo a una impresora u otro conductor, proporcionando un conjunto estándar de funciones para la aplicación a utilizar, y la implementación de funcionalidad específicas de DBMS. Una aplicación que puede utilizar ODBC se conoce como "compatibles con ODBC". Cualquier aplicación compatible con ODBC puede acceder a cualquier DBMS para el que se instala un controlador. Existen controladores para todos los principales DBMS, muchas otras fuentes de datos, como la libreta de direcciones sistemas y Microsoft Excel, e incluso para el texto o CSV archivos.

ODBC fue desarrollado originalmente por Microsoft a principios del decenio de 1990, y se convirtió en la base para la interfaz de nivel de llamada (CLI) estandarizada por SQL Access Group en el Unix y mainframe de mundo. ODBC conservó una serie de características que se han eliminado como parte del esfuerzo de la CLI. ODBC completa tarde 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, las aplicaciones y puede ser portado de una plataforma a la otra con pocos cambios.

Antes de ODBC

La introducción de la computadora central -basada base de datos relacional en la década de 1970 condujo a una proliferación de métodos de acceso a datos. En general, estos sistemas funcionan mano a mano con un procesador de comandos simple que permite al usuario escribir en los comandos de Inglés-como, y recibir de salida. Los ejemplos más conocidos son los de SQL de IBM y QUEL del Ingres proyecto. Estos sistemas pueden o no permitir que otras aplicaciones tengan acceso a los datos directamente, y aquellos que no utiliza una amplia variedad de metodologías. La introducción de SQL dirigido a resolver el problema de la lengua normalización, aunque las diferencias sustanciales en la aplicación se mantuvieron.

Además, ya que el lenguaje SQL sólo tenía funciones de programación rudimentarios, a menudo se desea utilizar SQL dentro de un programa escrito en otro idioma, por ejemplo Fortran o C . Esto llevó al concepto de SQL incorporado, que permite código SQL a ser "incrustados" dentro de otro idioma. Por ejemplo, una sentencia SQL como SELECT * FROM ciudad podría insertarse como texto en el código fuente de C, y durante la compilación que se convertiría en un formato personalizado que llama directamente a una función dentro de una biblioteca que pasaría la declaración en el sistema SQL. Resultados de volver de las declaraciones se interpretarían de nuevo en los formatos de datos C como char * utilizando código de la biblioteca similar.

Hubo una serie de problemas con el enfoque de SQL incorporado. Al igual que las diferentes variedades de SQL, de que usan ellos variaron ampliamente, no sólo desde una plataforma a otra, sino incluso a través de las lenguas en una sola plataforma el SQL incorporado - un sistema que permite llamadas en IBM 's DB2 se vería totalmente diferente de una que llama en sus propios SQL / DS [ dudoso - discutir ] . Otro problema clave para el concepto de Embedded SQL fue que el

código SQL sólo se podría cambiar en el código fuente del programa, por lo que incluso los pequeños cambios en la consulta requiere un esfuerzo considerable programador modificar. El mercado de SQL refirió a esto como "SQL estático", en lugar de "SQL dinámico" que podría cambiar en cualquier momento - como las interfaces de línea de comandos que se entregan con casi todos los sistemas SQL, o una interfaz de programación que dejó el SQL como texto plano hasta que fue llamado. Sistemas de SQL dinámico se convirtió en un foco importante para los proveedores de SQL durante la década de 1980.

Bases de datos de mainframe de edad avanzada, y los nuevos microordenadores sistemas basados en que se basaron en ellos, por lo general no tienen un procesador de comandos SQL-como entre el usuario y el motor de base de datos. En su lugar, los datos se accede directamente por el programa - una biblioteca de programación en el caso de los sistemas mainframe grandes, o una interfaz de línea de comandos del sistema o formularios interactivos en el caso de dBASE y aplicaciones similares. Los datos de dBASE no podían en general puede acceder directamente por otros programas que se ejecutan en la máquina. Esos programas pueden dar una forma de acceder a estos datos, a menudo a través de las bibliotecas, pero no iba a funcionar con cualquier otro motor de base de datos, o incluso diferentes bases de datos en el mismo motor. En efecto, todos estos sistemas eran estáticos, que presenta problemas considerables.

Los primeros esfuerzos

A mediados de la década de 1980 la rápida mejora en microcomputadoras, y sobre todo la introducción de las interfaces de usuario gráficas y ricas en datos de programas de aplicación como Lotus 1-2-3 llevado a un creciente interés en el uso de ordenadores personales como la plataforma del lado del cliente de elección en cliente-servidor de la informática. Bajo este modelo, los grandes mainframes y minicomputadoras se utilizan sobre todo para servir datos a través de redes de área local de microcomputadoras que interpretar, mostrar y manipular los datos. Para que este modelo funcione, una norma de acceso a los datos era un requisito - en el mundo del mainframe que era muy probable que todos los equipos en una tienda eran de un solo proveedor y los clientes eran terminales de ordenador que hablan directamente a ellos, pero en el mundo micro no había tal estandarización y cualquier cliente puede acceder a cualquier servidor usando cualquier sistema de red.

A fines de 1980 hubo una serie de esfuerzos en curso para proporcionar una capa de abstracción para este propósito. Algunos de ellos fueron relacionados mainframe, diseñado para permitir que los programas que se ejecutan en las máquinas de traducir entre la variedad de SQL y de proporcionar una sola interfaz común que podría entonces ser llamado por otros programas de mainframe o microcomputadoras. Estas soluciones incluyen IBM Distributed Relational Database Architecture (DRDA) y Apple Computer 's Data Access Language. Mucho más común, sin embargo, fueron los sistemas que funcionaron enteramente en microcomputadoras, incluyendo una completa pila de protocolos que incluye cualquier red o archivo de apoyo a la traducción requerida.

Uno de los primeros ejemplos de un sistema tal fue Lotus Development 's DataLens , inicialmente conocido como Blueprint. Blueprint, desarrollado para 1-2-3, apoya una variedad de fuentes de

datos, incluyendo SQL / DS, DB2, FOCO y una variedad de sistemas mainframe similares, así como sistemas de microcomputadoras como dBase y los primeros esfuerzos de Microsoft / Ashton-Tate que con el tiempo se convertirá en Microsoft SQL Server. A diferencia de la tarde ODBC, Blueprint fue un sistema puramente código-basado, que les falte nada se aproxima a un lenguaje de comandos como SQL. En lugar de ello, los programadores utilizan estructuras de datos para almacenar la información de consulta, la construcción de una consulta mediante la vinculación de muchas de estas estructuras juntos. Lotus se refirió a estas estructuras compuestas como "árboles de consulta".

Casi al mismo tiempo, un equipo de la industria, incluidos los miembros de Sybase , Tandem Computers y Microsoft estaban trabajando en un concepto dinámico SQL estandarizado. Gran parte del sistema se basó en el sistema-DB Biblioteca de Sybase, con las secciones específicas de Sybase retirados y varias adiciones para apoyar otras plataformas. DB-Library se vio favorecido por un movimiento de toda la industria de los sistemas bibliotecarios que fueron estrechamente vinculada a un idioma en particular, a los sistemas bibliotecarios que fueron proporcionados por el sistema operativo y requiere los idiomas que la plataforma para cumplir con sus normas. Esto significaba que una sola biblioteca podría ser utilizado con (potencialmente) cualquier lenguaje de programación en una plataforma determinada.

El primer borrador de la API Microsoft Data Access se publicó en abril de 1989, casi al mismo tiempo que el anuncio de Lotus de Blueprint. [A pesar de la gran ventaja de Blueprint - se estaba ejecutando cuando MSDA era todavía un proyecto de papel - Lotus eventualmente se unió a los esfuerzos MSDA como se hizo evidente que SQL se convertiría en el estándar de facto de base de datos. Después de una considerable participación de la industria, en el verano de 1989 se convirtieron en el estándar de conectividad de SQL , o SQLC para abreviar ,.

SAG y CLI

En 1988 un número de vendedores, la mayoría de los Unix comunidades y bases de datos, formó el Grupo de acceso SQL (SAG), en un esfuerzo para producir una sola norma básica para el lenguaje SQL. En la primera reunión hubo un considerable debate sobre si es o no el esfuerzo debe trabajar solamente en el lenguaje SQL, o intentar una normalización más amplia que incluía un sistema dinámico de idioma-incrustación de SQL, así, lo que llamaron una interfaz de nivel de llamada (CLI) . Mientras asistía a la reunión con un primer borrador de lo que entonces era todavía conocida como MS Access Data, Kyle Geiger de Microsoft invitó a Jeff Balboni y Larry Barnes de Digital Equipment Corporation (DEC) para unirse a las reuniones SQLC también. SQLC era una posible solución a la convocatoria de la CLI, que estaba siendo dirigido por diciembre

El nuevo SQLC "banda de los cuatro", MS, Lotus, DEC y Sybase, trajo una versión actualizada de SQLC a la próxima reunión del SAG en junio de 1990. El SAG respondió abriendo el esfuerzo estándar a cualquier diseño que compiten, sino de las muchas propuestas, sólo Oracle Corp tenían un sistema que presenta una seria competencia. Al final, SQLC ganó los votos y se convirtió en el proyecto de norma, pero sólo después de que se eliminaron gran parte de la API - el documento de estándares fue recortado de 120 páginas a 50 durante este tiempo. Fue también durante este período que el nombre Call Level Interface fue adoptada formalmente. En 1995, SQL / CLI se convirtió en parte del estándar SQL internacional, ISO / IEC 9075-3. El SAG misma fue asumida por

el X / Open grupo en 1996, y, con el tiempo, se convirtió en parte de The Open Group 's Entorno de aplicación común.

MS continuó trabajando con el estándar SQLC original, conservando muchas de las características avanzadas que se han eliminado de la versión CLI. Estos incluyen características como cursores desplazables y metadatos consultas de información. Los comandos de la API se dividieron en grupos; El grupo central era idéntica a la CLI, el Nivel 1 extensiones eran órdenes que serían fáciles de implementar en los conductores, mientras que el Nivel 2 comandos contenían las funciones más avanzadas como cursores. Una norma propuesta fue lanzado en diciembre de 1991, y la entrada de la industria se reunieron y trabajaron en el sistema a través de 1992, dando lugar a un nuevo cambio de nombre por el de ODBC.

JET y ODBC

Durante este tiempo, Microsoft se encontraba en medio de desarrollar su Jet sistema de base de datos. Jet combina tres subsistemas primarios; un ISAM motor de base de datos basado en (también conocido como "Jet", confusamente), una interfaz basada en C que permite que las aplicaciones accedan a los datos, y una selección de controladores DLLs que permitió que la misma interfaz C para redirigir la entrada y salida a otra ISAM- bases de datos basadas, como Paradox y xBase. Jet permitido a los programadores utilizar un único conjunto de llamadas para acceder a bases de datos de microordenador comunes de una manera similar a Blueprint (por este punto conocido como DataLens). Sin embargo, Jet no utilizó SQL; como DataLens, la interfaz estaba en C y consistía en estructuras de datos y llamadas a funciones.

Los esfuerzos de normalización SAG presentan una oportunidad para Microsoft para adaptar su sistema de Jet para el nuevo estándar CLI. Esto no sólo hacer que Windows una plataforma principal de desarrollo CLI, sino que también permiten a los usuarios utilizar SQL para acceder tanto Jet y otras bases de datos también. Lo que faltaba era el intérprete de SQL que podría convertir las llamadas de su forma de texto en la interfaz de C utilizado en Jet. Para solucionar esto, MS se asoció con PageAhead Software para usar su procesador de consultas existente, "SIMBA". SIMBA se utilizó como un analizador por encima de la biblioteca de Jet C, convirtiendo Jet en una base de datos SQL. Y porque Jet podría reenviar las llamadas C-basado a otras bases de datos, esto también permitió SIMBA para consultar otros sistemas. Microsoft incluye controladores para Excel para convertir sus documentos de hoja de cálculo en tablas de bases de datos en SQL accesible.

Lanzamiento y desarrollo continuo

ODBC 1.0 fue lanzado en septiembre de 1992. [En ese momento, hubo poco apoyo directo a las bases de datos SQL (en oposición a ISAM), y no se observaron los primeros conductores de los malos resultados. Algo de esto fue inevitable debido a la ruta que tomaron las llamadas a través de la pila a base de Jet; Llamadas ODBC para bases de datos SQL primero fueron convertidas de SQL dialecto de SIMBA al formato basado en C interno de Jet, a continuación, se pasa a un controlador para la conversión de nuevo en SQL pide la base de datos. Digital Equipment y Oracle se contrajeron Simba para desarrollar drivers para sus bases de datos, así.

Circa 1993, OpenLink Software enviado uno de los primeros controladores ODBC de terceros desarrolladas de forma independiente, para el PROGRESO DBMS , [ 13 ] y pronto siguió con su

UDBC (una cruz-plataforma equivalente API de ODBC y el SAG / CLI) SDK y asociado controladores para PROGRESS , Sybase, Oracle y otros DBMS, para su uso en Unix OS ( AIX , HP-UX , Solaris , Linux , etc), VMS , de Windows NT , OS / 2 , y otros sistemas operativos.

Mientras tanto, el esfuerzo estándar CLI se prolongó, y no fue hasta marzo de 1995 que la versión definitiva se terminó. Por este tiempo Microsoft ya había concedido Visigenic Software un código fuente licencia para desarrollar ODBC en plataformas que no sean Windows. Visigenic portado ODBC a una amplia variedad de plataformas Unix, donde ODBC convirtió rápidamente en el estándar de facto. "Real" CLI es raro hoy en día. Los dos sistemas siguen siendo similares, y muchas aplicaciones se pueden trasladar de ODBC para CLI con pocos o ningún cambio.

Con el tiempo, los proveedores de bases de datos se hizo cargo de las interfaces de controlador y proporcionan enlaces directos a sus productos. Saltarse las conversiones intermedias hacia y desde Jet o similares envoltorios menudo resultó en un mayor rendimiento. Sin embargo, por esta vez Microsoft ha cambiado el enfoque de su OLE DB concepto, que proporciona acceso directo a una amplia variedad de fuentes de datos de las libretas de direcciones en archivos de texto. Varios sistemas nuevos seguidos que resultó aún más su atención de ODBC, incluyendo DAO , ADO y ADO.net , que interactuó más o menos con ODBC largo de su vida.

Como Microsoft centró su atención lejos de trabajar directamente en ODBC, el mundo Unix fue cada vez más abrazando. Esto fue impulsado por dos cambios en el mercado, la introducción de interfaces gráficas de usuario como GNOME que proporcionaron la necesidad de acceso a estas fuentes en forma no textual, y la aparición de software abierto sistemas de bases de datos como PostgreSQL y MySQL , inicialmente bajo Unix. La adopción posterior de ODBC por Apple para utilizar el lado Unix estándar iODBC paquete Mac OS X 10.2 (Jaguar) (que OpenLink Software ha estado proporcionando de forma independiente para Mac OS X 10.0 e incluso Mac OS 9 desde el año 2001) cimentado aún más ODBC como el estándar para el acceso de datos multiplataforma.

Sun Microsystems utiliza el sistema de ODBC como base para su propio estándar abierto, JDBC. En la mayoría de las formas, JDBC se puede considerar una versión de ODBC para el lenguaje de programación Java en lugar de C. JDBC-a-ODBC "puentes" permitir que los programas de acceso a fuentes de datos a través de controladores ODBC en plataformas que carecen de un controlador JDBC nativo Java-basados, aunque éstos son ahora relativamente rara. Inversamente, ODBC-a-JDBC "puentes" permiten que los programas basados en C para acceder a fuentes de datos a través de JDBC en plataformas o bases de datos que carecen de controladores ODBC adecuados.

ODBC hoy

ODBC permanece en gran medida universal para hoy, con los controladores disponibles para la mayoría de las plataformas y la mayoría de las bases de datos. No es raro encontrar controladores ODBC para los motores de bases de datos que están destinados a ser incorporados, como SQLite , como una manera de permitir que las herramientas existentes para actuar como front-ends a estos motores para pruebas y depuración.

Sin embargo, el aumento de thin client computing utilizando HTML como formato intermedio ha reducido la necesidad de ODBC. Muchas plataformas de desarrollo web contienen enlaces directos

para orientar las bases de datos - MySQL es particularmente común. En estos escenarios, no hay acceso de cliente directo ni varios sistemas de software de cliente para apoyar; todo pasa por la aplicación HTML programador suministrado. La virtualización que ofrece ODBC ya no es un requisito fuerte, y el desarrollo de ODBC ya no es tan activo como lo era antes.

Historia de versiones

1.0: publicada en septiembre de 1992

Ca 1994: 2.0

2.5

3.0: ca 1995, John Goodson de Intersolv y Frank Pellow y Paul Cotton de IBM aportaron datos importantes para ODBC 3.0

3.5: ca 1997

3.8: ca 2009, con Windows 7

Drivers y Gerentes

Drivers

ODBC se basa en el controlador de dispositivo modelo, donde el conductor encapsula la lógica necesaria para convertir un conjunto estándar de comandos y funciones en las convocatorias específicas requeridas por el sistema subyacente. Por ejemplo, un controlador de la 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 a las API son convertidos por el conductor en el formato utilizado por el hardware real, decir PostScript o PCL.

En el caso de ODBC, los conductores encapsulan una serie de funciones que pueden dividirse en varias categorías amplias. Un conjunto de funciones se refiere principalmente a la búsqueda, la conexión y desconexión del DBMS que las conversaciones de conducir a. Un segundo grupo se utiliza para enviar comandos SQL del sistema de ODBC para el DBMS, convertir o interpretar ningún comando que no se admiten internamente. Por ejemplo, un DBMS que no admite cursores puede emular esta funcionalidad en el conductor. Por último, otro grupo de comandos, en su mayoría de uso interno, se utiliza para convertir los datos de formatos internos del DBMS a un conjunto de formatos estandarizados ODBC, que se basan en los formatos del lenguaje C.

Un controlador ODBC permite a una aplicación compatible con ODBC para utilizar una fuente de datos, normalmente un DBMS. Existen algunos conductores no DBMS, por tales fuentes como CSV archivos, mediante la aplicación de una pequeña DBMS en el interior del propio controlador. Existen controladores ODBC para la mayoría de los DBMS, incluyendo Oracle, PostgreSQL, MySQL , Microsoft SQL Server (pero no para la edición compacta alias CE ), Sybase ASE , y DB2 . Debido a que diferentes tecnologías tienen diferentes capacidades, la mayoría de los controladores ODBC no implementar todas las funciones definidas en el estándar ODBC. Algunos conductores ofrecen una funcionalidad extra que no se define en la norma.

Administrador de controladores

Controladores de dispositivo suelen enumerarse, configurar y administrar mediante una capa Gerente separada, que puede proporcionar una funcionalidad adicional. Por ejemplo, los sistemas de impresión incluyen a menudo para proporcionar la funcionalidad de la cola de impresión funcionalidad en la parte superior de los conductores, proporcionando cola de impresión para cualquier impresora soportada.

En ODBC Driver Manager (DM) ofrece estas características. El DM puede enumerar los controladores instalados y presentar esto como una lista, a menudo en una forma basada en GUI.

Pero más importante para el funcionamiento del sistema de ODBC es el concepto de la DM de origen de datos Nombre s, o DSN. DSN recogen información adicional necesaria para conectarse a una determinada fuente de datos, en contraposición a la propia DBMS. Por ejemplo, el mismo MySQL driver puede ser utilizado para conectarse a cualquier servidor MySQL, pero la información de conexión para conectarse a un servidor privado local es diferente de la información necesaria para conectarse a un servidor público a Internet-organizada. Las tiendas de DSN esta información en un formato estandarizado, y la DM ofrece esto al conductor durante las solicitudes de conexión. El DM también incluye funcionalidad para presentar una lista de los DSN que utilizan nombres legibles, y para seleccionarlos en tiempo de ejecución para conectarse a diferentes recursos.

El DM también incluye la posibilidad de guardar de DSN parcialmente completa, con código y la lógica para pedir al usuario la información que falta en tiempo de ejecución. Por ejemplo, un DSN puede ser creado sin una contraseña requerida. Cuando una aplicación ODBC intenta conectarse al DBMS utilizando este DSN, el sistema hará una pausa y pedir al usuario que proporcione la contraseña antes de continuar. Esto libera al desarrollador de aplicaciones de tener que crear este tipo de código, así como tener que saber qué preguntas hacer. Todo esto está incluido en el conductor y los DSN.

Configuraciones de puente

Un puente es un tipo especial de conducir: un controlador que utiliza otra tecnología basada en controladores.

Puentes ODBC-a-JDBC (o simplemente ODBC-JDBC)

Un puente ODBC-JDBC consta de un ODBC controlador que utiliza los servicios de un driver JDBC para conectarse a una base de datos. Este controlador traduce la función-llamadas ODBC en JDBC método-llamadas. Los programadores suelen usar ese puente cuando carecen de un controlador ODBC para una base de datos particular, pero tienen acceso a un controlador JDBC.

Puentes JDBC-a-ODBC (o simplemente JDBC-ODBC)

Un puente JDBC-ODBC consiste en un driver JDBC que utiliza un controlador ODBC para conectarse a una base de datos de destino. Este controlador traduce JDBC método pone en llamadas a funciones ODBC. Los programadores suelen utilizar ese puente cuando una base de datos particular, carece de un controlador JDBC. Sun Microsystems incluido un tal puente en la JVM, pero lo vieron como una medida provisional mientras existían pocos controladores JDBC. Sun

nunca tuvo la intención de su puente para entornos de producción, y en general se recomienda en contra de su uso. A partir de 2008 los proveedores de acceso a datos independiente entregar puentes JDBC-ODBC que soportan los estándares actuales para ambos mecanismos, y que superan ampliamente las de JVM incorporado.

OLE-DB-a ODBC puentes

Un puente de OLE DB para ODBC consiste en un OLE DB Provider que utiliza los servicios de un controlador ODBC para conectarse a una base de datos de destino. Este proveedor OLE DB traduce método pone en llamadas a funciones ODBC. Los programadores suelen utilizar ese puente cuando una base de datos particular, carece de un proveedor de OLE DB. Microsoft incluye uno, MSDASQL.DLL, como parte de la MDAC paquete componente del sistema, junto con otros controladores de base, para simplificar el desarrollo de las lenguas-COM consciente (por ejemplo, Visual Basic). Los terceros también han desarrollado este tipo, sobre todo Software OpenLink cuyos 64 bits del proveedor OLE DB para ODBC Data Sources llenado el vacío cuando Microsoft obsoleto inicialmente este puente para su sistema operativo de 64 bits. (Microsoft más tarde cedió, y 64 bits de Windows comenzando con Windows Server 2008 y Windows Vista SP1 ha enviado con una versión de 64 bits de MSDASQL.)

-ADO.NET-a ODBC puentes

Un puente de ADO.NET-ODBC consiste en un proveedor de ADO.NET que utiliza los servicios de un controlador ODBC para conectarse a una base de datos de destino. Este proveedor traduce ADO.NET método pone en llamadas a funciones ODBC. Los programadores suelen utilizar ese puente cuando una base de datos particular, carece de un proveedor de ADO.NET. Barcos uno como parte del Microsoft MDAC paquete componente del sistema, junto con otros controladores de base, para simplificar el desarrollo en C #. Los terceros también han desarrollado tales.