Bloque II. Tema 6. Sistemas de gestión de bases de datos relacionales. Antecedentes históricos. Características y elementos constitutivos. El lenguaje SQL. Estándares de conectividad: ODBC y JDBC

 

Antecedentes históricos

La historia empieza en 1974 con la definición del lenguaje SEQUEL. En 1986 ANSI adoptó SQL como estándar para los lenguajes relacionales y en 1987 se transformó en estándar ISO. Esta versión del estándar tenía el nombre de SQL/86. En 1989, ANSI definió el SQL89, basado en el anterior pero con una serie de mejoras (definición de claves primarias, integridad de los datos, etc.).

Ya en SQL-89 se tienen tres partes:

 

1986

SQL-86 (SQL-87)

El primero formalizado por ANSI

1989

SQL-89 (FIPS 127-1)

Revisión menor

1992

SQL-92

Revisión mayor, ya es ISO 9075

1999

SQL:1999 (SQL-3)

Añade matching por expresiones regulares, consultas recursivas, triggers, etc.

Añade también seguridad por medio de privilegios y roles.

También se le conoce por intentar un “SQL orientado a objetos”

2003

SQL:2003

Introduce funciones relacionadas con XML y columnas con valores auto-generados

2006

SQL:2006

ISO/IEC 9075-14:2006

Formas de guardar XML en bases de datos, formas de integrar el uso de XQuery en el código SQL.

2008

SQL:2008

ORDER BY fuera de definiciones de cursor. Añade triggers INSTEAD OF. Añade la sentencia TRUNCATE -eliminar todos los datos de la tabla, pero no el esquema-

El lenguaje SQL

https://secure.wikimedia.org/wikipedia/en/wiki/SQL

SQL/Schemata

Esquemas de información y definición, parte del estándar SQL definido por ISO/IEC 9075-11:2008. SQL/Schemata define el esquema de información y el esquema de definición, proporcionando un conjunto de herramientas para hacer que las bases de datos SQL y los objetos sean auto-descriptivos. Estas herramientas incluyen el identificador de objeto SQL, restricciones de estructura e integridad. especificaciones de seguridad y autorización, etc.

Lenguaje de Definición de Datos

El término fue introducido por el modelo de bases de datos Codasyl, donde el esquema se escribía en un lenguaje de descripción de datos describiendo los registros, campos y conjuntos. Posteriormente se refirió a un subconjunto de SQL para crear tablas y restricciones. SQL-92 introdujo un lenguaje de manipulación de esquemas y tablas de información sobre esquemas para poder dirigirles consultas. Estas tablas fueron especificadas en SQL/Schemata en SQL:2003.

Sentencias:

Se pueden considerar otras sentencias de DDL las que definen la integridad referencial en las relaciones, normalmente las claves primarias y las foráneas.

Lenguaje de Manipulación de Datos

Son las sentencias donde cambian los datos, que modifican los datos almacenados pero no el esquema ni los objetos de la base de datos. La manipulación de los objetos de la base de datos que sean “persistentes” o no volátiles (las propias tablas o los procedimientos almacenados) se las considera parte del esquema de definición de datos. Las sentencias son:

Lenguaje de Control de Datos

Un lenguaje que incluye una serie de comandos SQL que permiten al administrador controlar el acceso a los datos contenidos. Algunos ejemplos incluyen:

Estándares de conectividad: ODBC y JDBC

JDBC

Las categorías de driver JDBC en Java van desde estar más apegados al sistema operativo hasta ser 100% Java. Las alternativas son:

  1. Tipo 1. Driver JDBC-ODBC. Traduce peticiones JDBC a peticiones ODBC y las librerías encargadas son al final las del sistema operativo.  No es 100% Java. El camino de una instrucción SQL es capa Java, capa ODBC, capa driver SO fabricante.
  2. Tipo 2. Conceptualmente parecido al tipo 1 pero eliminando la capa ODBC para incorporar en nuestro sistema unos binarios que pueden estar programados en cualquier lenguaje. Así, las peticiones van por capa Java, capa ODBC, capa driver SO fabricante.
  3. Tipo 3. Requiere la instalación de un servidor JDBC. Java como cliente se comunicará siempre con el servidor JDBC o proxy JDBC y éste lo traducirá a peticiones al sistema concreto.
  4. Tipo 4. Java puro, el más eficiente, no requiere ni de drivers adicionales ni de middlewares ni proxys. Así es como la mayoría de los fabricantes distribuyen sus drivers.

Clases y métodos

La jerarquía de la api jdbc va por dos ramas:

 

Connection

Es una interfaz y la conexión real depende del driver, por lo tanto se obtiene con DriverManager.getConnection

Una  vez que la tenemos podemos hacer:

* createStatement

* prepareStatement

* prepareCall

 

Permite hacer commit, rollbacks y savepoints.

Statement

st = connection.createStatement(...)

Con una sentencia -sin preparar- hacemos:

* execute

* executeQuery

* executeUpdate

Igual que la preparada pero sin los métodos set<Tipo>

CallableStatement

La interfaz que se usa para ejecutar procedimientos almancenados SQL, visto al más alto nivel, ya que es la super-interfaz de Statement y de PreparedStatement.

Se puede obtener con:

cs = connection.prepareCall(...)

Super-interfaz de Statement, PreparedStatement. Con una sentencia llamable hacemos:

* set<Tipo>

* get<Tipo> para obtener los valores devueltos por el procedimiento

* registerOutParameter

Y luego como hereda de Statement tiene los executeXXX

PreparedStatement

Un objeto que representa una sentencia de SQL pre-compilada. Se puede obtener con:

ps = connection.prepareStatement(...)

* execute que admite cualquier tipo de sentencia y devuelve booleano

* executeQuery que devuelve el ResultSet para sentencias de selección

* executeUpdate que devuelve un entero, para consultas de modificación

* set<Tipo> establece un valor de parámetro del tipo que sea y devuelve void.

Permite hacer commits, rollbacks y savepoints

DriverManager

El servicio básico para manejar un juego de drivers JDBC. Atención! a partir de JDBC 2.0 el método preferido de conectarse con JDBC es la interfaz DataSource

* getConnection (url)

* getConnection (url, properties)

* getConnection (url, user, pass)

DataSource

En javax.sql

Factoría de conexiones alternativa y preferida a ConnectionManager. Un objeto que implementa esta interfaz será registrado normalmente con el servicio de nombres JNDI.

* getConnection()

* getConnection(user, pass)

 

 

 

javax.DataSource

Esta interfaz la implementa el desarrollador del driver. Hay tres tipos de implementación:

  1. Básica. Produce un objeto Connection estándar.
  2. Pool de conexiones. Produce un objeto Connection que participa automáticamente en un pool de conexiones.
  3. Transacciones distribuidas. Produce un Connection que se puede usar para transacciones distribuidas y que casi siempre participa de un pool.

Pool de conexiones

El contenedor de aplicaciones web se encarga de gestionarlo. Hay que definir un DataSource (ver apartado anterior) dentro de la definición del contexto de la aplicación de EE. Si no está creado, se crea el context.xml dentro del directorio META-INF.

     

<Context path="/cursoJDBCWeb" docBase="cursoJDBCWeb"

debug="5" reloadable="true" crossContext="true">

<Resource name="jdbc/mysqlDS" auth="Container"

type="javax.sql.DataSource"

maxActive="100" maxIdle="30" maxWait="10000"

username="root" password="password"

driverClassName="com.mysql.jdbc.Driver"

url="jdbc:mysql://localhost/jdbcdbjava"/>

</Context>

Luego ese recurso hay que buscarlo por nombre usando JNDI, tal y como se decía en el apartado anterior para los DataSource.

JDO

Java Data Objects. Un modelo de abstracción de persistencia basado en interfaces. La tecnología JDO es un modelo que tiene varias implementaciones.

JDBC y Oracle

     

Class.forName("oracle.jdbc.driver.OracleDriver");

Connection c = DriverManager.getConnection("jdbc:oracle:thin:@192.168.2.103:1521:GLOBAL2", "SYSTEM", "manager");

Call Level Interface

Es un estándar de software definido en ISO/IEC 9075-3:2003. Define como un programa debería enviar consultas SQL al DBMS y como los conjuntos de datos devueltos deberían ser manejados por la aplicación de una manera consistente.

El uso más extendido de CLI forma la base de la especificación ODBC. La versión actual, la 3.52 incorpora funcionalidades tanto de ISO como de los estándares X/Open aka The Open Group.

ODBC

Los creadores intentaron hacer una capa independiente de lenguajes de programación, sistemas de bases de datos y sistemas operativos. Fue desarrollado por el SQL Access Group en 1992.

La última versión fue desarrollado para Windows 7 y es la ODBC 3.8, en la que Microsoft decidió alinear ODBC con la especificación CLI para cumplir con The Open Group e ISO.

iODBC ofrece una alternativa open source, independiente de la plataforma para las especificaciones tanto ODBC como X/Open.

En Windows tenemos DSN de usuario o DSN de sistema. El de usuario permite crearlos para un usuario específico y el de sistema estará disponible para todos los usuarios.