UNIDAD 4 Tecnologías de conectividad de bases de datos. 

4.1. ODBC.

INTRODUCCIÓN. 

Es una interfase de programación (API) ampliamente aceptada para el acceso a bases de datos. Está basado en las especificaciones Call-Level Interfase (CLI) de X/Open y ISO/IEC para APIs para bases de datos y usa SQL (Structured Query Language) como lenguaje para el acceso a las mismas.

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.

LOS REQUERIMIENTOS

Los drivers son los componentes que procesan los requerimientos ODBC y retornan los datos a la aplicación. Para usarlos, requieren ser instalados previamente en el computador.

Los data sources son las fuentes de datos que determinan el acceso utilizando un driver a una fuente de datos particular. Se identifican con un nombre y se definen usando el ODBC Data Source Adminitrator. Requieren haber instalado previamente el driver en el computador. Existen tres tipos de data sources: de Usuario, del Sistema y de Archivo.

1. User Data Sources: Los data sources de Usuario, son locales al computador y pueden ser utilizados únicamente por el usuario que lo define. Generan una entrada en el Registro de Windows.

2. System Data Sources: Los data sources de Sistema, son locales al computador y pueden ser utilizados por cualquier usuario con privilegios o por el sistema. Generan una entrada en el Registro de Windows.

3. File Data Sources: Los data sources de Archivo, están basados en un archivo que puede compartirse entre todos los usuarios que tienen instalado el mismo driver para acceder a una base de datos. No están dedicados a un usuario ni a un computador. No generan entradas en el Registro de Windows, sino que se identifican por el nombre de un archivo con la extensión .DSN.

Los data sources de Usuario y de Sistema se conocen en conjunto como Data source de la máquina (Machine Data Source) porque son locales a un computador. Estos eran los únicos data sources soportados hasta esta versión.

¿Cómo se instala el ODBC de Access ?

Si ya tienes instalado Office  en tu máquina con la opción Seleccionar todo, pasa directamente al punto Creando un origen de datos.

Cuando se instala Office  en una máquina Windows, partiremos de un menú de instalación que nos presenta, entre otras, la forma automática y la personalizada, es esta última la que se debe escoger.

Los controladores estan un poco escondidos: En el primer nivel del cuadro de instalación hay una lista donde se deben marcar los distintos paquetes que se desea instalar. No olvidar el correspondiente a Access y después el llamado Acceso a datos. Teniendo éste seleccionado, pulsar el botón Modificar opción que hay a su derecha, tal como puedes ver. De la lista que aparecerá seleccionar la denominada Controladores de bases de datos, pulsar de nuevo el botón Modificar opción, y ya tenemos la lista de controladores. Fíjate que además del controlador de Access hay otros, y como nunca se sabe que extraños inventos acabaremos teniendo que hacer, ya puestos, lo mejor es marcarlos todos.

Este proceso de instalación es válido tanto para el servidor como para la máquina donde vayamos a realizar el desarrollo de las aplicaciones, y por supuesto, también deberá hacerse en todas las máquinas que vayan a trabajar con las aplicaciones de administración de la base de datos. Y ahora procederemos a configurar el controlador para que pueda ser utilizado por el IDC.

Creando un origen de datos

Abrir el panel de control y localizar el icono llamado 32 bit ODBC. Abrirlo.

En el cuadro que aparece seleccionar la etiqueta System DSN, ya que el IDC sólo trabaja con este tipo. Pulsar el botón Add

Seleccionar el controlador de Access en la lista. Pulsar el botón Finalizar

Aquí es donde vamos a crear realmente el origen de datos de la aplicación. Pulsar el botón Options>> para ver el cuadro entero.Analicemos cada campo: el primero, Data Source Name, nos pide el nombre del origen de datos que vamos a crear, y que será el utilizado por la aplicación. Se puede poner cualquier nombre, sin espacios en blanco ni símbolos, sólo letras y números, como en el ejemplo:prueba2. Este nombre no tiene por qué ser el mismo que el de la base de datos que hay vinculada a él. Al facilitar este nombre al IDC, el ODBC se encargará de que la aplicación "entienda" lo que dice la base de datos. El siguiente campo, Description es un breve comentario del origen de datos, si te es necesario, sino, puedes dejarlo vacio. A continuación hay cuatro botones que sirven para seleccionar, crear, reparar o compactar una base de datos de Access. Como ya debes de saber, coinciden con otras tantas herramientas que tiene el paquete de diseño de Access. Utiliza el de selección y localiza y selecciona una DB que ya tengas preparada para esta prueba. El siguiente recuadro, System Database, contine dos interruptores: None y Database, y un botón: System Database y sirven para definir si la base de datos tiene permisos especiales de usuario o no. Como también se supone que sabes, Access gestiona los permisos de usuario en una base de datos especial llamada system.mdw que habría que definir aquí, pulsando el botón System Database y seleccionando una system.mdw, y a continuación el botón Advanced para definir el usuario y palabra de paso que hay que utilizar para el acceso a la DB. En el caso de que no haya permisos especiales, basta con marcar el interruptor None. NOTA: En los sistemas XP, NT Server o 2003 Server no olvidar que el usuario definido para acceder desde internet, exista y tenga los permisos necesarios para llegar a la base de datos y operar en ella. Una forma simple de asegurarse de que no existan problemas de permisos puede ser poner el fichero de la base de datos en el directorio "Documentos compartidos", que es un área de uso común a todos los usuarios de la máquina. Si los datos son confidenciales esto no debe hacerse, y habrá que definir correctamente el usuario que corresponda y sus permisos. El último recuadro, Driver, contiene campos que permiten controlar el tiempo de espera (Timeout), el tamaño del buffer de datos (una especie de almacén en memoria por donde pasan los registros). Los valores por defecto suelen ser suficientes en general. A la vista del rendimiento en cada caso, se pueden cambiar. Los dos controles finales sirven para definir el modo de acceso. Si es marcado como Exclusive, siginifica que el primer usuario que se conecte a la DB obtiene el control absoluto, y no podrá ser accedida por otro usuario hasta que el primero no la abandone. El siguiente control, Read Only deja la DB en modo de sólo lectura, y nadie podrá escribir ni modificar nada. No suelen utilizarse, ya que es la propia aplicación la que debe decidir qué se puede hacer en cada momento. Ya tenemos listo el ODBC, pulsar el botón OK para guardar lo hecho.

Pulsar el botón Aceptar para cerrar el administrador de orígenes de datos. En el caso de que haya que cambiar alguna cosa, se selecciona el origen de datos que proceda y se pulsa el botón Configure.Como ya debes de saber, Access es un paquete que permite diseñar aplicaciones y que integra un motor de base de datos. Debe quedar claro que al crear un origen de datos para ODBC, estamos creando un acceso sólo a datos, es decir si tenemos una aplicación completa en un fichero de Access, el ODBC solamente conectará las tablas de datos con la aplicación internet, no pudiendo utilizar la parte aplicación para el IDC ni ningún otro recurso del IIS o del PWS. Con la aplicación escrita en Access seguirá siendo posible acceder a las tablas sólo en modo local. Por último, tener presente que el motor de Access es un motor pensado para uso personal, que soporta aceptablemente un número reducido de usuarios. En internet no es fácil saber cuantos usuarios simultáneos se pueden conectar en un momento dado, y el rendimiento puede caer peligrosamente. Es buena idea diseñar las aplicaciones en modo distribuido: es decir, en un fichero se escribe la parte aplicación (formularios, rutinas de control, etc.) y las tablas se utilizan vinculadas a otro fichero que sólo contine los datos. Esto, además de mejorar algo el rendimiento, nos permite trabajar incluso en el diseño de la aplicación local, aunque esten siendo accedidas las tablas desde internet. Si se espera que el número de usuarios pueda ser importante, se debe utilizar un servidor de bases de datos como SQL Server, que puede soportar cientos de usuarios simultáneos.

4.2. ADO.NET. 

Introducción:

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.

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.

ADO.NET es un conjunto de clases que exponen servicios de acceso a datos para el programador de .NET. ADO.NET ofrece abundancia de componentes para la creación de aplicaciones de uso compartido de datos distribuidas. Constituye una parte integral de .NET Framework y proporciona acceso a datos relacionales, XML y de aplicaciones. ADO.NET satisface diversas necesidades de desarrollo, como la creación de clientes de base de datos de aplicaciones para usuario y objetos empresariales de nivel medio que utilizan aplicaciones, herramientas, lenguajes o exploradores de Internet.

ADO.NET proporciona acceso coherente a orígenes de datos como Microsoft SQL Server y XML, así como a orígenes de datos expuestos mediante OLE DB y ODBC. Las aplicaciones para usuarios que comparten datos pueden utilizar ADO.NET para conectar a estos orígenes de datos y recuperar, manipular y actualizar los datos contenidos.

ADO.NET separa el acceso a datos de la manipulación de datos y crea componentes discretos que se pueden utilizar por separado o conjuntamente. ADO.NET incluye proveedores de datos de .NET Framework para conectarse a una base de datos, ejecutar comandos y recuperar resultados. Los resultados se procesan directamente o se colocan en un objeto DataSet de ADO.NET con el fin de exponerlos al usuario para un propósito específico, combinados con datos de varios orígenes, o de utilizarlos de forma remota entre niveles. El objeto DataSet de ADO.NET también puede utilizarse independientemente de un proveedor de datos de .NET Framework para administrar datos que son locales de la aplicación o que proceden de un origen XML.

Las clases de ADO.NET se encuentran en el archivo System.Data.dll y están integradas con las clases de XML que se encuentran en el archivo System.Xml.dll. Cuando se compila un código que utiliza el espacio de nombres System.Data, es necesario hacer referencia a los archivos System.Data.dll y System.Xml.dll. Para obtener un ejemplo de una aplicación de ADO.NET que se conecta a una base de datos, recupera datos de ésta y, a continuación, los muestra en el símbolo del sistema, vea (Aplicación de ejemplo de ADO.NET.)

ADO.NET proporciona funcionalidad a los programadores que escriben código administrado similar a la funcionalidad que los objetos ADO (ActiveX Data Objects) proporcionan a los programadores de modelo de objetos componentes (COM) nativo. 

El objeto DataSet es esencial para la compatibilidad con situaciones de datos distribuidos desconectados con ADO.NET. El DataSet es una representación de datos residente en memoria que proporciona un modelo de programación relacional coherente con independencia del origen de datos. Se puede utilizar con muchos y distintos orígenes de datos, con datos XML o para administrar datos locales de la aplicación. El DataSet representa un conjunto completo de datos que incluye tablas relacionadas y restricciones, así como relaciones entre las tablas. En la siguiente ilustración se muestra el modelo de objetos DataSet.

Modelo de objetos DataSet

Los métodos y objetos de un DataSet concuerdan con los del modelo de base de datos relacional.

El DataSet también puede mantener y recargar su contenido como XML y su esquema como esquema de lenguaje de definición de esquemas XML (XSD). Para obtener más información, vea Utilizar XML en un DataSet.

DataTableCollection

Un DataSet de ADO.NET contiene una colección de cero o más tablas representadas por objetos DataTable. La DataTableCollection contiene todos los objetos DataTable de un DataSet.

La DataTable se define en el espacio de nombres System.Data y representa una única tabla de datos residentes en memoria. Contiene una colección de columnas representadas por una DataColumnCollection, así como restricciones representadas por una ConstraintCollection, que juntas definen el esquema de la tabla. Una DataTable también contiene una colección de filas representadas por la DataRowCollection, que contiene los datos de la tabla. UnaDataRow conserva, junto con su estado actual, sus versiones actual y original para identificar los cambios en los valores almacenados en la fila.

DataRelationCollection

Un DataSet contiene relaciones en su objeto DataRelationCollection. Una relación, representada por el objeto DataRelation, asocia las filas de unaDataTable con las filas de otra DataTable. Las relaciones son análogas a las rutas de acceso de unión que podrían existir entre columnas de claves principales y externas en una base de datos relacional. Una DataRelation identifica las columnas coincidentes en dos tablas de un DataSet.

Las relaciones permiten el desplazamiento entre tablas de un DataSet. Los elementos esenciales de una DataRelation son el nombre de la relación, el nombre de las tablas que se relacionan y las columnas relacionadas de cada tabla. Es posible crear relaciones con más de una columna por tabla si se especifica una matriz de objetos DataColumn como columnas de claves. Cuando agrega una relación al DataRelationCollection, puede agregar opcionalmente una UniqueKeyConstraint y una ForeignKeyConstraint para imponer restricciones de integridad cuando se realizan cambios en valores de columna relacionados.

ExtendedProperties

DataSet, DataTable y DataColumn tienen todos una propiedad ExtendedProperties. ExtendedProperties es una PropertyCollection en la que puede colocar información personalizada, como la instrucción SELECT que se ha utilizado para generar el conjunto de resultados o la hora en que se generaron los datos. La colección ExtendedProperties se mantiene con la información de esquema del DataSet.

Para obtener más información sobre las diferencias entre ADO y ADO.NET, vea ADO.NET for the ADO Programmer en MSDN.

4.3. JDBC.

El Java Database Connectivity (JDBC) API es el estándar de la industria para la conectividad de base de datos independiente entre el lenguaje de programación Java y una amplia gama de bases de datos - bases de datos SQL y otras fuentes de datos tabulares, como hojas de cálculo o archivos planos. El API JDBC proporciona una API de nivel de llamada para el acceso de base de datos basada en SQL.

Tecnología JDBC le permite utilizar el lenguaje de programación Java para explotar "escribir una vez, ejecutar en cualquier lugar" capacidades para aplicaciones que requieren acceso a los datos empresariales. Con un controlador habilitado para la tecnología JDBC, puede conectar todos los datos de la empresa, incluso en un entorno heterogéneo.