UNIDAD IV: TECNOLOGIAS DE CONECTIVIDAD DE BASE DE DATOS
4.1 ODBC
4.1 ODBC
INTRODUCCION
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.
SIGNIFICADO
Open Database Connectivity (ODBC) es la interfaz estratégica de Microsoft para obtener acceso a datos en un entorno heterogéneo de relacionales y no - relacionales sistemas de administración de la base de datos. Basado en la especificación de interfaz de nivel de llamada del grupo de acceso de SQL, ODBC proporciona una forma abierta, independiente del proveedor de acceso a datos almacenados en una gran variedad de propietario equipo personal, minicomputadoras y las bases de datos de mainframe.
ODBC alivia la necesidad de aprender múltiples interfaces de programación de aplicaciones para los programadores corporativos y fabricantes independientes de software. ODBC proporciona ahora una interfaz de acceso de datos universal. Con ODBC, los desarrolladores de aplicaciones pueden permitir que una aplicación al mismo tiempo tener acceso, ver y modificar los datos procedentes de múltiples bases de datos diferentes.
ODBC es un componente básico de la arquitectura de servicios abiertos de Microsoft Windows. Apple ha respaldado ODBC como una clave de habilitación de la tecnología de anuncio de soporte en System 7 en el futuro. Con soporte de la industria cada vez más, ODBC está rápidamente emergiendo como un sector importante estándar para el acceso a datos para las aplicaciones de Windows y Macintosh.
ODBC alivia la necesidad de aprender múltiples interfaces de programación de aplicaciones para los programadores corporativos y fabricantes independientes de software. ODBC proporciona ahora una interfaz de acceso de datos universal. Con ODBC, los desarrolladores de aplicaciones pueden permitir que una aplicación al mismo tiempo tener acceso, ver y modificar los datos procedentes de múltiples bases de datos diferentes.
ODBC es un componente básico de la arquitectura de servicios abiertos de Microsoft Windows. Apple ha respaldado ODBC como una clave de habilitación de la tecnología de anuncio de soporte en System 7 en el futuro. Con soporte de la industria cada vez más, ODBC está rápidamente emergiendo como un sector importante estándar para el acceso a datos para las aplicaciones de Windows y Macintosh.
REQUERIMIENTOS
Para utilizar ODBC, se requieren los tres componentes siguientes:
Ejemplos de cliente - un ODBC front-end (también llamado ODBC cliente habilitado) - ODBC: Microsoft Access, una aplicación creada con Access, una aplicación creada con Microsoft Visual Basic, una aplicación creada con C + Win SDK + ODBC SDK o las aplicaciones basadas en ODBC de otros proveedores (como Lotus).
CONTROLADOR ODBC - un controlador ODBC para el servidor ODBC. El catálogo de controladores ODBC contiene una lista extensa de los controladores ODBC. Por ejemplo, Microsoft ODBC Driver Pack es una colección de los siete controladores ODBC listo para su uso o se incluye con los clientes ODBC. Un controlador de ODBC de SQL Server se incluye con Access y Informix está trabajando en un controlador ODBC para Informix.
Ejemplos de cliente - un ODBC front-end (también llamado ODBC cliente habilitado) - ODBC: Microsoft Access, una aplicación creada con Access, una aplicación creada con Microsoft Visual Basic, una aplicación creada con C + Win SDK + ODBC SDK o las aplicaciones basadas en ODBC de otros proveedores (como Lotus).
CONTROLADOR ODBC - un controlador ODBC para el servidor ODBC. El catálogo de controladores ODBC contiene una lista extensa de los controladores ODBC. Por ejemplo, Microsoft ODBC Driver Pack es una colección de los siete controladores ODBC listo para su uso o se incluye con los clientes ODBC. Un controlador de ODBC de SQL Server se incluye con Access y Informix está trabajando en un controlador ODBC para Informix.
EJEMPLOS:
4.2 ADO.NET
INTRODUCCION
ADO .NET es la nueva versión del modelo de objetos
ADO (ActiveX Data Objects), es decir, la estrategia que ofrece Microsoft para el acceso a datos. ADO .NET ha sido ampliado para
cubrir todas las necesidades que ADO no ofrecía, ADO .NET está diseñado para
trabajar con conjuntos de datos desconectados, lo que permite reducir
el tráfico de red. ADO .NET utiliza XML como
formato universal de transmisión de los datos.
ADO .NET posee una serie de objetos
que son los mismos que aparecen en la versión anterior de ADO, como pueden ser
el objeto Connection o Command, e introduce nuevos objetos tales como el objeto
DataReader, DataSet o DataView.
ADO .NET se puede definir como:
Un conjunto de interfaces, clases, estructuras y enumeraciones
Que permiten el acceso a los datos
desde la plataforma .NET de Microsoft
Que permite un modo de acceso
desconectado a los datos que pueden provenir de múltiples fuente de datos
de diferente arquitectura de almacenamiento.
SIGNIFICADO
ADO.NET es un
conjunto de componentes del software que pueden ser usados por
los programadores para acceder a datos y a servicios de datos. Es una parte de
la biblioteca de clases base que están incluidas en el Microsoft .NET Framework. Es comúnmente
usado por los programadores para acceder y para modificar los datos almacenados
en un Sistema Gestor de Bases de Datos Relacionales, aunque también
puede ser usado para acceder a datos en fuentes no relacionales. ADO.NET es a
veces considerado como una evolución de la tecnología ActiveX Data Objects (ADO), pero fue cambiado tan
extensivamente que puede ser concebido como un producto enteramente nuevo.
Componentes de
ADO.NET
Existen dos
componentes de ADO.NET que se pueden utilizar para obtener acceso a datos y
manipularlos:
- Proveedores de datos de .NET Framework
- El DataSet
Proveedores de datos de .NET Framework
Los proveedores de datos de .NET
Framework son componentes diseñados explícitamente para la manipulación de
datos y el acceso rápido a datos de sólo lectura y sólo avance. El objeto Connection proporciona
conectividad a un origen de datos. El objeto Command permite
tener acceso a comandos de base de datos para devolver datos, modificar datos,
ejecutar procedimientos almacenados y enviar o recuperar información sobre
parámetros. El objetoDataReader proporciona una secuencia de datos
de alto rendimiento desde el origen de datos. Por último, el objeto DataAdapter proporciona el puente entre
el objeto DataSet y el origen de datos. El DataAdapter utiliza
objetos Command para ejecutar comandos SQL en el origen de
datos tanto para cargar el DataSet con datos como para
reconciliar en el origen de datos los cambios aplicados a los datos incluidos
en el DataSet.
DataSet
El DataSet de ADO.NET está expresamente
diseñado para el acceso a datos independientemente del origen de datos. Como
resultado, se puede utilizar con múltiples y distintos orígenes de datos, con
datos XML o para administrar datos locales de la aplicación. El DataSet contiene
una colección de uno o más objetos DataTable formados por filas y columnas
de datos, así como información sobre claves principales, claves externas,
restricciones y relaciones relativa a los datos incluidos en los objetos DataTable.
ARQUITECTURA ADO.NET
REQUERIMIENTOS
Al trabajar con ADO.NET no se utiliza la
dll de acceso ODBC de GX (gxdata.dll), sino que toda la lógica se encuentra en
la gxclasses.dll.
En el caso de los DBMSs, cada uno utiliza
un Data Provider para acceder a la base de datos, cada DBMS tiene su propio Data
Provider para acceso ADO.NET.
Por el momento los DBMSs que soportan el
acceso ADO.NET son:
SQL Server
Oracle
- DB2 Universal Database
- DB2 UDB for iSeries
Los requerimientos necesarios en cada caso son:
SQL Server
ADO.NET utiliza el Data Provider de
Microsoft para SQL Server (el cual se instala con el framework).
Oracle
Se debe
tener el Cliente de Oracle versión 8.1.7 o superior, de esta forma se instala
el Data Provider correspondiente.
El
valor “Server Name” de las Dbms option hace referencia al Service Name definido
en la instancia del Oracle.
La
implementación utiliza el Data provider de Microsoft para Oracle
(System.Data.OracleClient)
DB2 UDB for iSeries
Se necesita la V5R3 del iSeries Access,
que es una versión beta y está solo en inglés.
Además cuando se crea un modelo se debe
copiar la dll IBM.Data.DB2.iSeries.dll al directorio gxnet/bin si la aplicación
es web o gxnetwin/bin win.
La versión V5R3 del iSeries Access se
puede obtener de la URL: http://www-1.ibm.com/servers/eserver/iseries/access/windows/beta.html.
Nota:
- El Data provider para DB2 UDB for iSeries
no soporta BLOBs por ahora.
- Una limitación del driver client acces V5
R3 no permite el llamado objetos remotos en el Iseries (RPC). Esto implica
store procedures (programas RPG o Cobol) u objetos externos en el Iseries
(programas CL)
DB2 Universal Database
Se necesita tener instalada la versión
8.1.3 o superior.
La dll es IBM.Data.DB2.dll, también se
debe copiar a los directorios gxnet/bin si la aplicación es web o gxnetwin/bin
win.
4.3 JDBC
INTRODUCCIÓN
Java proporciona una plataforma completa, flexible y segura para el desarrollo de aplicaciones, incluyendo la conectividad con una base de datos. Esta conectividad o acceso a base de datos relacionales con Java es posible gracias a la API JDBC (Java DataBase Connectivity).
Este API es parte de la plataforma Java desde la versión 1.0 de JDK. Con el paso del tiempo se ha ido mejorando y aumentando su funcionalidad.
JDBC es ODBC extendido para toda la plataforma Java. Mientras que ODBC es una interfaz escrita en lenguaje C, que tiene que ser instalado manualmente en cada maquina, JDBC, al estar escrito en Java, posee todas las propiedades y ventajas del mismo.
ODBC es un estandar para las plataformas MS Windows. JDBC es capaz de trabajar con MS Windows y otras plataformas.
El API JDBC puede definirse como un conjunto de clases, métodos e interfaces escritos en lenguaje Java, que permiten el acceso a sistemas de bases de datos relacionales utilizando instrucciones SQL.
¿ que necesitamos ?
- El API JDBC con dos paquetes principale, java.sql y javax.sql
- Un controlador de acceso a una base de datos
El controlador servirá para conectar la aplicación con la API JDBC, proporcionando comunicación con la base de datos.
En definitiva, lo que el estándar JDBC hace posible es:
- Establecer una conexión.
- Lanzar sentencias SQL.
- Capturar conjuntos resultado (resulset) de las consultas.
- Capturar información de la base de datos.
- Manipular los datos.
Puesto que JDBC está implementado en Java, posee la ventaja de serindependiente de la plataforma e independiente de la base de datos. En esencia, podrá ejecutarse en cualquier sistema que posea una Máquina Virtual de Java.
SIGNIFICADO
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.
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:
- 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.
- 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.
REQUERIMIENTOS
Para tener acceso a los datos desde una base de datos de SQL Server mediante el controlador JDBC de Microsoft SQL Server, debe tener los siguientes componentes instalados en el equipo:
- Controlador de JDBC de Microsoft SQL Server
- Java Runtime Environment
- Procedimiento de Conexión y acceso a datos con JDBC.
- 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:
Debemos considerar las características específicas de una base de datos, como por ejemplo, como mapear los tipos de datos SQL a Java.
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.
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.
- Procedimiento de conexión.
- 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.
- 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)
- Tipos de conectores (drivers) JDBC
- Tipo 1. JDBC-ODBC bridge más driver ODBC: “BRIDGE” 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. Inconvenientes: 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” 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” 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”. 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
- Arquitecturas 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
El procedimiento de conexión con el controlador de la base de datos, independientemente de la arquitectura es siempre muy similar.
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.
Los conectores o drivers JDBC, se pueden dividir en cuatro tipos principalmente:
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)
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
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.
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.
S.O donde vaya a correr.
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:
Todos ellos se pueden agrupar en dos tipos distintos de arquitecturas:
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.
REFERENCIAS:
