Actualmente, las bases de datos relacionales constituyen el sistema de almacenamiento probablemente más extendido, aunque otros sistemas de almacenamiento de la información se estén abriendo paso poco a poco.

Una base de datos relacional se puede definir, de una manera simple, como aquella que presenta la información en tablas con filas y columnas.

Una tabla o relación es una colección de objetos del mismo tipo (filas o tuplas).

En cada tabla de una base de datos se elige una clave primaria para identificar de manera unívoca a cada fila de la misma.

El sistema gestor de bases de datos, en inglés conocido como: Database Management System (DBMS) gestiona el modo en que los datos se almacenan, mantienen y recuperan.

En el caso de una base de datos relacional, el sistema gestor de base de datos se denomina: Relational Database Management System (RDBMS).

Tradicionalmente, la programación de bases de datos ha sido como una torre de Babel: gran cantidad de productos de bases de datos en el mercado y cada uno "hablando" en su lenguaje privado con las aplicaciones.

Java, mediante JDBC (Java Database Connectivity), permite simplificar el acceso a bases de datos relacionales, proporcionando un lenguaje mediante el cual las aplicaciones pueden comunicarse con motores de bases de datos. Sun desarrolló este API para el acceso a bases de datos, con tres objetivos principales en mente:

• Ser un API con soporte de SQL: poder construir sentencias SQL e insertarlas dentro de llamadas al API de Java.
• Aprovechar la experiencia de los API's de bases de datos existentes.
• Ser lo más sencillo posible.

Un conector o driver es un conjunto de clases encargadas de implementar los interfaces del API y acceder a la base de datos.

Para poder conectarse a una base de datos y lanzar consultas, una aplicación necesita tener un driver adecuado. Un conector suele ser un fichero .jar que contiene una implementación de todas las interfaces del API JDBC.

Cuando se construye una aplicación de base de datos, JDBC oculta lo específico de cada base de datos, de modo que el programador se ocupe sólo de su aplicación.

El conector lo proporciona el fabricante de la base de datos o bien un tercero.

El código de nuestra aplicación no depende del driver, puesto que trabajamos mediante los paquetes java.sql y javax.sql.

JDBC ofrece las clases e interfaces para:

• Establecer una conexión a una base de datos.
• Ejecutar una consulta.
• Procesar los resultados.

Ejemplo:

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
public class ConsultaSencilla {
public static void main(String[] args) {
Connection conexion;
try {
      String urljdbc = "jdbc:oracle:thin:@localhost:1521:XE";
      //la base de datos esta en local y el servicio Oracle es XE 
      //se utiliza thin driver 
      conexion = DriverManager.getConnection(urljdbc, "ejemplo", ejemplo"); 
      Statement smt = conexion.createStatement();
      ResultSet rset = smt.executeQuery("select  empno, ename , job from emp order by 1");
      while (rset.next())
            System.out.println("empleado numero " + rset.getString(1) + " nombre " + rset.getString(2) + " oficio " + rset.getString(3));
      conexion.close();
      } catch (SQLException e) {
      e.printStackTrace();
      }
    }
}

En principio, todos los conectores deben ser compatibles con ANSI SQL-2 Entry Level (ANSI SQL-2 se refiere a los estándares adoptados por el American National Standards Institute en 1992. Entry Level se refiere a una lista específica de capacidades de SQL.) Los desarrolladores de drivers pueden establecer que sus conectores conocen estos estándares.

Hay cuatro tipos de drivers JDBC: Tipo 1, Tipo 2, Tipo 3 y Tipo 4, que veremos en apartados posteriores.

En el modelo de dos capas, una aplicación se comunica directamente a la fuente de datos. Esto necesita un conector JDBC que pueda comunicar con la fuente de datos específica a la que acceder.

Los comandos o instrucciones del usuario se envían a la base de datos y los resultados se devuelven al usuario. La fuente de datos puede estar ubicada en otra máquina a la que el usuario se conecte por red. A esto se denomina configuración cliente/servidor, con la máquina del usuario como cliente y la máquina que aloja los datos como servidor.

En el modelo de tres capas, los comandos se envían a una capa intermedia de servicios, la cual envía los comandos a la fuente de datos. La fuente de datos procesa los comandos y envía los resultados de vuelta la capa intermedia, desde la que luego se le envían al usuario.

Hoy en día, hay cinco tipos de controladores JDBC en uso:

• Tipo 1: puente JDBC-ODBC
• Tipo 2: controlador parcial de Java
• Tipo 3: controlador Java puro para middleware de base de datos
• Tipo 4: controlador Java puro para directo a base de datos
• Tipo 5: controladores altamente funcionales con un rendimiento superior

Los conectores tipo 1 se denominan también JDBC-ODBC Bridge (puente JDBC-ODBC).

Proporcionan un puente entre el API JDBC y el API ODBC. El driver JDBC-ODBC Bridge traduce las llamadas JDBC a llamadas ODBC y las envía a la fuente de datos ODBC.

Como ventajas destacar:

• No se necesita un driver específico de cada base de datos de tipo ODBC.
• Está soportado por muchos fabricantes, por lo que tenemos acceso a muchas Bases de Datos.

Como desventajas señalar:

• Hay plataformas que no lo tienen implementado.
• El rendimiento no es óptimo ya que la llamada JDBC se realiza a través del puente hasta el conector ODBC y de ahí al interface de conectividad de la base de datos. El resultado recorre el camino inverso.
• Se tiene que registrar manualmente en el gestor de ODBC teniendo que configurar el DSN (Data Source Names, Nombres de fuentes de datos).

Este tipo de driver va incluido en el JDK.

Los conectores tipo 2 se conocen también como: API nativa

Convierten las llamadas JDBC a llamadas específicas de la base de datos para bases de datos como SQL Server, Informix, Oracle, o Sybase.

El conector tipo 2 se comunica directamente con el servidor de bases de datos, por lo que es necesario que haya código en la máquina cliente.

Como ventaja, este conector destaca por ofrecer un rendimiento notablemente mejor que el JDBC-ODBC Bridge.

Como inconveniente, señalar que la librería de la bases de datos del vendedor necesita cargarse en cada máquina cliente. Por esta razón los drivers tipo 2 no pueden usarse para Internet.

Los drivers Tipo 1 y 2 utilizan código nativo vía JNI, por lo que son más eficientes.

Tipo 3: JDBC-Net pure Java driver.

Tiene una aproximación de tres capas. Las peticiones JDBC a la base de datos se pasan a través de la red al servidor de la capa intermedia (middleware). Este servidor traduce este protocolo independiente del sistema gestor a protocolo específico del sistema gestor y se envía a la base de datos. Los resultados se mandan de vuelta al middleware y se enrutan al cliente.

Es útil para aplicaciones en Internet.

Este driver está basado en servidor, por lo que no se necesita ninguna librería de base de datos en las máquinas clientes.
Normalmente, un driver de tipo 3 proporciona soporte para balanceo de carga, funciones avanzadas de administrador de sistemas tales como auditoría, etc.

Tipo 4: Protocolo nativo.

En este caso se trata de conectores que convierten directamente las llamadas JDBC al protocolo de red usando por el sistema gestor de la base de datos. Esto permite una llamada directa desde la máquina cliente al servidor del sistema gestor de base de datos y es una solución excelente para acceso en intranets.

Como ventaja se tiene que no es necesaria traducción adicional o capa middleware, lo que mejora el rendimiento, siendo éste mejor que en el caso de los tipos 1 y 2.

Además, no se necesita instalar ningún software especial en el cliente o en el servidor.

Como inconveniente, de este tipo de conectores, el usuario necesita un driver diferente para cada base de datos.

Un ejemplo de este tipo de conector es Oracle Thin.

Para acceder a una base de datos y así poder operar con ella, lo primero que hay que hacer es conectarse a dicha base de datos.

En Java, para establecer una conexión con una base de datos podemos utilizar el método getConnection() de la clase DriverManager. Este método recibe como parámetro la URL de JDBC que identifica a la base de datos con la que queremos realizar la conexión.

La ejecución de este método devuelve un objeto Connection que representa la conexión con la base de datos.

Cuando se presenta con una URL específica, DriverManager itera sobre la colección de drivers registrados hasta que uno de ellos reconoce la URL especificada. Si no se encuentra ningún conector adecuado, se lanza una SQLException

Veamos un ejemplo con comentarios, para conectarnos a una base de datos MySQL:

Juan le explica a Antonio, que una base de datos puede crearse utilizando las herramientas proporcionadas por el fabricante de la base de datos, o por medio de sentencias SQL desde un programa Java. Pero normalmente es el administrador de la base de datos, a través de las herramientas que proporcionan el sistema gestor, el que creará la base de datos. No todos los conectores JDBC soportan la creación de la base de datos mediante el lenguaje de definición de datos (DDL). Es decir, la sentencia CREATE DATABASE no es parte del estándar SQL, sino que es dependiente del sistema gestor de la base de datos.

Así pues, mediante JDBC podemos conectarnos y manipular bases de datos: crear tablas, modificarlas, borrarlas, añadir datos en las tablas, etc. Pero la creación en sí de la base de datos la hacemos con la herramienta específica para ello.

Normalmente, cualquier sistema gestor de bases de datos incluye asistentes gráficos para crear la base de datos, sus tablas, claves, y todo lo necesario.

También, como en el caso de MySQL, o de Oracle, y la mayoría de sistemas gestores de bases de datos, se puede crear la base de datos, desde la línea de comandos de MySQL o de Oracle, con las sentencias SQL apropiadas.

Para operar con una base de datos,  ejecutando las consultas necesarias, nuestra aplicación deberá:

1. Cargar el driver necesario para comprender el protocolo que usa la base de datos en cuestión.
2. Establecer una conexión con la base de datos.
3. Enviar consultas SQL y procesar el resultado.
4. Liberar los recursos al terminar.
5. Gestionar los errores que se puedan producir.

Para hacer consultas en la base de datos tendremos que crear un objeto de tipo Statement, ejecutar la consulta con el método executeQuery(sql) y recorrer el ResultSet que devuelve este método.

Ejemplo 1:

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
public class PrimeraConsulta {
public static void main(String[] args) {
try {
    // Establecemos la conexion con la BD
    Connection conexion = DriverManager.getConnection("jdbc:mysql://localhost/ejemplo", "root", "system");
    // creamos el objeto Statement
    Statement sentencia = conexion.createStatement();
    //ejecutamos la consulta
    String sql = "SELECT * FROM dept";
    ResultSet resul = sentencia.executeQuery(sql);
    // Recorremos el resultado para visualizar cada fila 
    // Se hace un bucle mientras haya registros y se van visualizando while
    (resul.next()) {
    System.out.printf("%d, %s, %s %n", resul.getInt(1), resul.getString(2), resul.getString(3));
}
resul.close(); // Cerrar ResultSet
sentencia.close(); // Cerrar Statement
conexion.close(); // Cerrar conexión
} catch (SQLException cn) {
cn.printStackTrace();
} 
}
}

El API JDBC distingue dos tipos de sentencias SQL:

• Consultas: SELECT devuelven de ninguna o varias filas.  
• Actualizaciones: INSERT, UPDATE, DELETE, sentencias DDL. 

Veamos en primer lugar consultas que devuelven datos (SELECT)

Los datos se devuelven utilizando un objeto ResultSet. Se accede a los datos a través de un cursor. Este cursor es un puntero que apunta a una fila de datos en el  objeto ResultSet. Inicialmente, el cursor se coloca antes de la primera fila. Accedemos a todas las filas de una a una llamando el método next, ya que cada invocación next avanzará a la siguiente fila.

Ejemplo 2: 

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
public class ConsultaSencilla {
	public static void main(String[] args) {
		Connection conexion;
		try {
			String urljdbc = "jdbc:oracle:thin:ejemplo/ejemplo@localhost:1521:XE";
			conexion = DriverManager.getConnection(urljdbc, "ejemplo", "ejemplo");
			Statement smt = conexion.createStatement();
			ResultSet rset =
                                 smt.executeQuery("select  empno, ename , job from emp order by 1");
			while (rset.next())
				System.out.println("empleado numero " + rset.getString(1) +
                                " nombre " + rset.getString(2) + " oficio "+ rset.getString(3));
			        resul.close(); // Cerrar ResultSet
                                smt.close(); // Cerrar Statement
                                conexion.close(); // Cerrar conexión

		} catch (SQLException e) {
			e.printStackTrace();
		}
	}
}

Veamos como ejecutar sentencias DML (UPDATE, DELETE, INSERT)

Pese a que se trata de sentencias muy dispares, desde el punto de vista de la comunicación con el SGBD se comportan de manera muy similar, siguiendo el siguiente patrón:

1.  A partir de una conexión activa, instanciaciamos un objeto Statement.
2. Ejecutamos la sentencia SQL, método executeUpdate.
3. Cerramos del objeto Statement instanciado.
4. Cerramos la conexión activa. 

El método executeUpdate devuelve un número entero que representa el número de filas afectadas por la instrucción SQL.

Veamos el ejemplo siguiente, insertamos una línea y luego borramos todas las filas de la tabla jobs

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.sql.Statement;

public class Actualizacion {

	public static void main(String[] args) {
		// establecemos la conexion
		Connection conexion;
		try {
			String urljdbc = "jdbc:oracle:thin:ejemplo/ejemplo@localhost:1521:XE";
			conexion = DriverManager.getConnection(urljdbc, "scott", "tiger");
			// crea la sentencia
			Statement stm = conexion.createStatement();
			// ejecuta la actualizacion la ejecucion devuelve 1, numero de filas afectadas
			System.out.println(stm.executeUpdate("insert into jobs values ('ID TEACH', 'PROFESOR IT', 2500, 5000)"));
			// valida los datos
			// ejecuta el borrado, la ejecucion devuelve 19, numero de filas afectadas
			System.out.println(stm.executeUpdate("delete from jobs "));
			stm.close(); // Cerrar Statement
                        // cierra la conexion                       
			conexion.close();
		} catch (SQLException e) {
			e.printStackTrace();
		}

	}

}

Un procedimiento almacenado es un procedimiento o subprograma que está almacenado en la base de datos.

Muchos sistemas gestores de bases de datos los soportan, por ejemplo: MySQL, Oracle, etc.

Además, estos procedimientos suelen ser de dos clases:

• Procedimientos almacenados.
• Funciones, las cuales devuelven un valor que se puede emplear en otras sentencias SQL.

Un procedimiento almacenado típico tiene:

• Un nombre.
• Una lista de parámetros.
• Unas sentencias SQL.

Veamos un ejemplo de sentencia para crear un procedimiento almacenado sencillo para MySQL, aunque sería similar en otros sistemas gestores:

Como se ve en los comentarios, este procedimiento admite un parámetro, llamado par1. También se declara una variable a la que llamamos var1 y es de tipo carácter y longitud 13. Si el valor que le llega de parámetro es igual a 24, entonces se asigna a la variable var1, la cadena 'perro rabioso' y en caso contrario se le asignará la cadena: 'gato persa'. Finalmente, se inserta en la tabla “Animales” el valor que se asignó a la variable var1.

A continuación, vamos a realizar un procedimiento almacenado en MySQL, que simplemente insertará datos en la tabla clientes. Desde el programa Java que realizamos, llamaremos para ejecutar a ese procedimiento almacenado. Por tanto, ¿cuál sería la secuencia que seguiríamos para realizar esto?

• Si no tenemos creada la tabla de clientes, la creamos. Por simplicidad, en este ejemplo, trabajamos sobre la base de datos que viene por defecto en MySQL, el esquema denominado: test. Para crear la tabla de clientes, el script correspondiente es:
  Crear tabla en MySQL. (1 KB)
• Creamos el procedimiento almacenado en la base de datos. Sería tan fácil como lo que ves en el siguiente enlace:
  DDL rutina insertar cliente. (1 KB)
• Crear la clase Java para desde aquí, llamar al procedimiento almacenado:
  Llamar al procedimiento almacenado. (1 KB)

Si hemos definido la tabla correctamente, con su clave primaria, y ejecutamos el programa, intentando insertar una fila igual que otra insertada, o sea, con la misma clave primaria, obtendremos un mensaje al capturar la excepción de este tipo:

SQL Exception: 
com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: 
Duplicate entry '765' for key 'PRIMARY' 

Cuando tenemos una serie de consultas SQL que deben ejecutarse en conjunto, con el uso de transacciones podemos asegurarnos de que nunca nos quedaremos a medio camino de su ejecución.

Las transacciones tienen la característica de poder “deshacer” los cambios efectuados en las tablas, de una transacción dada, si no se han podido realizar todas las operaciones que forman parte de dicha transacción.

Por eso, las bases de datos que soportan transacciones son mucho más seguras y fáciles de recuperar si se produce algún fallo en el servidor que almacena la base de datos, ya que las consultas se ejecutan o no en su totalidad.

Al ejecutar una transacción, el motor de base de datos garantiza: atomicidad, consistencia, aislamiento y durabilidad (ACID) de la transacción (o conjunto de comandos) que se utilice.

El ejemplo típico que se pone para hacer más clara la necesidad de transacciones en algunos casos es el de una transacción bancaria. Por ejemplo, si una cantidad de dinero es transferida de la cuenta de Antonio a la cuenta de Pedro, se necesitarían dos consultas:

• En la cuenta de Antonio para quitar de su cuenta ese dinero:

UPDATE cuentas SET saldo = saldo - cantidad WHERE cliente = “Antonio”;

• En la cuenta de Pedro para añadir ese dinero a su cuenta:

UPDATE cuentas SET saldo = saldo + cantidad WHERE cliente = “Pedro”;

Pero, ¿qué ocurre si por algún imprevisto (un apagón de luz, etc.), el sistema “cae” después de que se ejecute la primera consulta, y antes de que se ejecute la segunda? Antonio tendrá una cantidad de dinero menos en su cuenta y creerá que ha realizado la transferencia. Pedro, sin embargo, creerá que todavía no le han realizado la transferencia.

Acabamos de ver cómo se realiza una conexión a una base de datos. En ocasiones, sobre todo cuando se trabaja en el ámbito de las aplicaciones distribuidas, en entornos web, es recomendable gestionar las conexiones de otro modo.

Antes de ver en que consiste , veamos como funciona la creación de conexiones en una aplicación clásica de escritorio cliente-servidor y luego veamos los problemas se seguir con dicha estructura en una aplicación web.

Problemas en la creación de conexiones

Consecuencia de los anterior al tener tantas conexiones a la base de datos se acabaría cayendo el servidor de base de datos debido a los recursos consumidos por todas las conexiones.

Podemos pensar que nuestro servidor puede aguantar todas esas conexiones ya que podemos tener pocos usuarios pero no suele ser así debido a:

• Si no se cierran las conexiones aun teniendo pocos usuarios es probable que acabemos saturando al servidor de conexiones sin usar.
• Las aplicaciones Web pueden tener picos de mucho tráfico, donde sería normal que se excediera la capacidad de nuestro servidor.
• Sería muy sencillo hacernos un ataque de denegación de servicio y saturando el servidor haciendo que se crearan gran cantidad de conexiones que no se usen.

Una solución  que nos evitaría las conexiones sin usar sería que se creara la conexión al iniciar cada petición web y se cerrara al finalizar dicha petición web. ¿El problema de eso? Crear y cerrar una conexión es muy costoso. Lo que tendríamos es una aplicación lentísima.

Pool de conexiones

El concepto de Pool de conexiones se ha estandarizado desde la versión 3.0 de JDBC.

La solución del pool de conexiones tiene que solucionar los siguientes problemas:

• No tener tantas conexiones como usuarios ya que el número de usuarios es demasiado elevado.
• Cerrar la conexión.

Veamos como funciona:

El servidor web tiene “n” conexiones ya creadas y conectadas a la base de datos (Se llaman conexiones esperando).

• Cuando llegan “m” peticiones web , la aplicación pide “m” conexiones al pool de conexiones, quedando esperando en el pool “n-m” conexiones. Esta operación es muy rápida ya que la conexión ya está creada y solo hay que marcarla como que alguien la está usando. Ahora hay “m” conexiones activas que está usando la aplicación.
• Cuando las peticiones web finalizan, las conexiones no se cierran sino que se devuelven al pool indicándole que ya se han acabado de usar las conexiones. Ahora vuelve a quedar “n” conexiones esperando en el pool. Esta operación también es muy rápida ya que realmente no se cierra ninguna conexión sino que simplemente se marcan como que ya no las están usando nadie.

Si se piden más conexiones de las que hay esperando en el pool se crearán en ese instante nuevas conexiones hasta el máximo de conexiones que permita el pool.

Al devolver una conexión al pool , ésta se queda esperando para que otra petición la pueda usar. Si hay ya demasiadas conexiones esperando a ser usadas se cerrarán para ahorrar recursos en el servidor de base de datos.

¿Qué hemos conseguido con el pool?

• • • Ahora las conexiones ya no se quedarán abiertas cuando el usuario se marcha del portal ya que cada conexión se pseudo-abre y pseudo-cierra con cada petición.
    • No tenemos tantas conexiones como usuarios usan la aplicación ya que solo se necesitan tantas como usuarios hay haciendo una petición en ese instante. Pensemos por un momento en facebook. ¿cuandos usuarios están conectados a facebook? Supongamos “x”. Pero ¿cuantos están realmente haciendo una petición y no viendo los datos que se han servido? Supongamos “y”. Obviamente “y” es mucho menor que “x”. Con lo que nos hemos ahorrado “x-y” conexiones.
    • Al iniciar un servidor Java EE, automáticamente el pool de conexiones crea un número de conexiones físicas iniciales.

Cuando un objeto Java del servidor J2EE necesita una conexión, la solicita  a través del método dataSource.getConnection(), la fuente de datos javax.sql.DataSource habla con el pool de conexiones y éste le entrega una conexión lógica java.sql.Connection. Esta conexión lógica la recibe por último, el objeto Java.

Cuando un objeto Java del servidor Java EE desea cerrar una conexión a través del método connection.close(), la fuente de datos javax.sql.DataSource habla con el pool de conexiones y le devuelve la conexión lógica en cuestión.

Si hay un pico en la demanda de conexiones a la base de datos, el pool de conexiones de forma transparente crea más conexiones físicas de objetos tipo Connection. Si por el contrario las conexiones a la base de datos disminuyen, el pool de conexiones, también de forma transparente elimina conexiones físicas de objetos de tipo Connection.

El objetivo del proyecto siguiente es crear una aplicacion grafica que permita consultar datos almacenados en una Base de Datos.
Utiliza el modelo vista controlador, la vista se crea con JSP, el modelo establece la conexión a una base de datos Mysql y la parte lógica se desarrolla con Servlets.

Para aprender a realizar un pool de conexiones con MySQL, se aporta el siguiente vídeo explicativo:

Vídeo explicativo realización de un pool de conexiones.

Para operar con una base de datos, ejecutando las consultas necesarias, nuestra aplicación deberá hacer:

• Cargar el driver necesario para comprender el protocolo que usa la base de datos en cuestión.
• Establecer una conexión con la base de datos.
• Enviar consultas SQL y procesar el resultado.
• Liberar los recursos al terminar.
• Gestionar los errores que se puedan producir.

Podemos utilizar los siguientes tipos de sentencias:

• Statement: para sentencias sencillas en SQL.
• PreparedStatement: para consultas preparadas, como por ejemplo las que tienen parámetros.
• CallableStatement: para ejecutar procedimientos almacenados en la base de datos.

El API JDBC distingue dos tipos de consultas:

• Consultas: SELECT
• Actualizaciones: INSERT, UPDATE, DELETE, sentencias DDL.

Veamos a continuación cómo realizar una consulta en la base de datos que creamos en el apartado anterior, la base de datos farmacia.mdb.

En este caso utilizaremos un acceso mediante puente JDBC-ODBC. Dicho puente da acceso a bases de datos ODBC.

Este driver está incorporado dentro de la distribución de Java, por lo que no es necesario incorporarlo explícitamente en el classpath de una aplicación Java.

Debemos tener en cuenta siempre que las conexiones con una base de datos consumen muchos recursos en el sistema gestor, y por lo tanto en el sistema informático en general. Por ello, conviene cerrarlas con el método close siempre que vayan a dejar de ser utilizadas, en lugar de esperar a que el garbage collector de Java las elimine.

También conviene cerrar las consultas (Statement y PreparedStatement) y los resultados (ResultSet) para liberar los recursos.

Una excepción es una situación que no se puede resolver y que provoca la detención del programa de manera abrupta. Se produce por una condición de error en tiempo de ejecución.

En Java hay muchos tipos de excepciones, el paquete java.lang.Exception es el que contiene los tipos de excepciones.

Cuando se produce un error durante la ejecución de un programa, se genera un objeto asociado a esa excepción. Ese objeto es de la clase Exception o de alguna de sus subclases. Este objeto se pasa entonces al código que se ha definido para gestionar la excepción.

En una porción de programa donde se trabajara con ficheros, y con bases de datos podríamos tener esta estructura para capturar las posibles excepciones.

El bloque de instrucciones del try es el que se ejecuta, y si en él ocurre un error que dispara una excepción, entonces se mira si es de tipo fichero no encontrado; si es así, se ejecutarían las instrucciones del bloque del fichero no encontrado. Si no era de ese tipo la excepción, se mira si es del siguiente tipo, o sea, de entrada salida, y así sucesivamente.

Las instrucciones que hay en el bloque del finally, se ejecutarán siempre, se haya producido una excepción o no, ahí suelen ponerse instrucciones de limpieza, de cierre de conexiones, etc.

Las acciones que se realizan sobre una base de datos pueden lanzar la excepción SQLException. Este tipo de excepción proporciona entre otra información:

• Una cadena de caracteres describiendo el error. Se obtiene con el método getMesage.
• Un código entero de error que especifica al fabricante de la base de datos.

Como ya hemos dicho, al trabajar con bases de datos, se consumen muchos recursos por parte del sistema gestor, así como del resto de la aplicación.

Por esta razón, resulta totalmente conveniente cerrarlas con el método close cuando ya no se utilizan.

Podríamos por tanto tener un ejemplo de cómo hacer esto: