Francisco Javier Martínez Páez

Consultor tecnológico de desarrollo de proyectos informáticos.

 Ingeniero Técnico en Telecomunicaciones

Puedes encontrarme en Autentia: Ofrecemos servicios de soporte a desarrollo, factoría y formación

Somos expertos en Java/J2EE

Ver todos los tutoriales del autor

Fecha de publicación del tutorial: 2006-05-04

Tutorial visitado 32.917 veces Descargar en PDF
  1. ¿ Qué es JDBC ?


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.


Bueno...pues como diría un anglosajón "Let`s get down to work" o manos a la obra:


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. 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.

  1. 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:

¿ 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.



  • 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.

  1. 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).

  1. 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.

  1. 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. 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.

  • 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”

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. Instalación de JDBC


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


  • Descargar el API de JDBC:

JDBC viene incluido en el corazón de la plataforma Java, tanto en la J2SE como en la J2EE.

http://java.sun.com/products/jdbc/download.html

Versión actual JDBC 1.3 (incluida en J2SE 1.4)

Versión en borrador JDBC 1.4



  • 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.



  • 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. 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:


  1. Aplicaciones standalone

  2. Applets comunicando con un servidor Web

  3. Aplicaciones y applets comunicando con una base de datos a través de un puente JDBC/ODBC.

  4. Aplicaciones accediendo a recursos remotos usando mecanismos como Java RMI

  5. 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:

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

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

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

  1. 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



A continuación puedes evaluarlo:

Regístrate para evaluarlo

Por favor, vota +1 o compártelo si te pareció interesante

Share |
Anímate y coméntanos lo que pienses sobre este TUTORIAL: