UD1 IntroduccionAccesoDatos
UD1 IntroduccionAccesoDatos
UD1 IntroduccionAccesoDatos
1. Introduccin. ............................................................................................................................................2
2. Acceso a datos..........................................................................................................................................3
2.1 Qu estrategia o mtodo de acceso a datos usar.................................................................................4
3. Ficheros....................................................................................................................................................5
3.1 Uso ficheros en la actualidad............................................................................................................6
4. Bases de datos. .........................................................................................................................................7
4.1 Bases de datos relacionales...............................................................................................................8
4.2 Bases de datos orientadas a objetos...................................................................................................9
4.3 Bases de datos orientadas a objetos (II)...........................................................................................10
4.4 Comparativa entre bases de datos relacionales y orientadas a objetos...............................................11
4.4.1 Desventajas de las bases de datos orientadas a objetos frente a las relacionales..........................12
4.5 Bases de datos objeto-relacionales..................................................................................................13
5. Acceso a bases de datos mediante conectores..........................................................................................14
6. Mapeo objeto relacional (ORM)..............................................................................................................15
6.1 Capa de persistencia y framework de mapeo...................................................................................16
7. Bases de datos XML...............................................................................................................................17
8. Desarrollo de componentes.....................................................................................................................18
8.1 Definicin de componente..............................................................................................................19
8.2 JavaBeans......................................................................................................................................20
2
1. Introduccin.
Iniciamos esta primera unidad del mdulo Acceso a datos, en el que veremos la gran variedad de mtodos de
acceso a datos que tenemos en el panorama actual.
Pero, a qu nos referimos cuando hablamos de acceso a datos en una aplicacin informtica?
Podemos afirmar que en la inmensa mayora de aplicaciones informticas se pueden diferenciar, a grandes
rasgos, en dos partes:
Por un lado, el programa propiamente dicho, que realiza las operaciones deseadas con los datos
necesarios.
Por otro lado, los datos con los que opera le programa. Esos datos pueden ser obtenidos por el
programa mediante diversos mtodos: ledos mediante teclado, escaneados, ledos de algn soporte de
almacenamiento secundario, etc.
En la mayora de los casos, cuando programamos, nos interesa que el programa guarde los datos que le hemos
introducido, o los resultados que dicho programa haya obtenido, de manera que si el programa termina su
ejecucin, los datos no se pierdan y puedan ser recuperados posteriormente, es decir, persistan. Una forma
tradicional de hacer esto es mediante la utilizacin de ficheros o de bases de datos que se guardarn en un
dispositivo de memoria no voltil (normalmente un disco).
Te habrs dado cuenta de que el almacenamiento en memoria RAM, mediante variables o vectores, es temporal,
los datos se pierden cuando el programa termina. Quizs te habr pasado alguna vez que, debido a un apagn
elctrico, has perdido el trabajo que estabas haciendo, que todava no habas grabado. Los datos que se guardan
en almacenamiento secundario, como ficheros o bases de datos, se denominan datos persistentes, porque
existen, o persisten ms all de la ejecucin de la aplicacin.
Ese almacenamiento secundario de datos que acabamos de mencionar, habitualmente suele consistir en una base
de datos relacional, si bien, a veces, hay otros mtodos de almacenamiento, y por tanto, mtodos de acceso a
esos datos. De conocer esos tipos de almacenamiento y cmo acceder a ellos es de lo que trata este mdulo.
En esta unidad inicial, vas a ver una panormica de los diversos mtodos de persistencia que encontramos en el
mercado.
AUTOEVALUACIN.
Seala la opcin correcta. Para almacenar datos de manera persistente no utilizaremos:
a) Ficheros de texto.
b) Bases de datos orientadas a objeto.
c) Memoria RAM
.
3
2. Acceso a datos.
Hay diversas estrategias de acceso a datos para gestionar la persistencia de los datos:
Mediante ficheros.
Bases de datos, que pueden ser:
o Relacionales,
o Orientadas a objetos,
o Objeto-relacionales.
Mapeo objeto relacional (ORM).
Bases de datos XML (eXtensible Markup Language).
Componentes.
Al principio, en los primeros tiempos de la informtica, los datos se guardaban en
ficheros convencionales. Con el tiempo, y la experiencia de trabajar con dichos ficheros,
se observaron los inconvenientes de los ficheros, y para intentar solucionar los
inconvenientes que se observaron surgieron las bases de datos, que entre otras ventajas
permitan:
Eliminar el problema de la informacin redundante.
Eliminar informacin inconsistente.
Globalizar o centralizar la informacin.
Garantizar el mantenimiento de la integridad en la informacin. nicamente se
almacena la informacin correcta.
Independencia de datos. La independencia de datos implica una separacin
entre programas y datos, es decir, se pueden hacer cambios en la informacin
que contiene la base de datos, o tener acceso a la base de datos de diferente
manera, sin tener que hacer cambios en las aplicaciones o en los programas.
Verdadero o Falso?
Uno de los objetivos de las bases de datos es que un cambio en los datos implique cambiar el programa de
acceso a los mismos.
4
2.1 Qu estrategia o mtodo de acceso a datos usar.
Posteriormente, con la aparicin y expansin de la programacin orientada a objetos, empezaron a surgir las
Bases de datos orientadas a objetos, y tambin se ampliaron algunas bases de datos relacionales, aadindoles
extensiones de orientacin a objetos.
Entonces qu mtodo de acceso a datos es mejor? Cul deberas utilizar en la prxima aplicacin que
construyas?
Pues, no hay una respuesta fcil para esas preguntas, no se puede afirmar que haya un mtodo que sea el
mejor de manera absoluta. Ms bien, la cuestin es tener claro qu tipo de aplicacin hay que construir y, segn
eso, estudiar qu tipo de sistema de almacenamiento ser mejor usar: si una base de datos orientada a objetos, o
una base de datos XML, etc.
Conociendo el funcionamiento de las diferentes alternativas podemos comparar sus prestaciones al problema de
la persistencia concreto que se nos presente. Cada una de las tecnologas tiene su propio origen y filosofa para
alcanzar el mismo fin y, por esta razn, no es fcil analizar sus ventajas y desventajas frente a las dems
alternativas.
Por poner un ejemplo, lo ms sencillo posible: si voy a crear una base de datos para guardar mi coleccin de
vdeos, probablemente no me va a interesar utilizar una base de datos Oracle, sino un producto mucho ms
barato, y sencillo de instalar y mantener.
AUTOEVALUACIN.
Seala la opcin correcta. La mejor opcin para lograr la persistencia de los datos de una aplicacin es:
a) Utilizar una base de datos relacional.
b) Emplear bases de datos orientadas a objeto.
c) Usar ficheros de bajo nivel.
d) Depender de las alternativas que haya y del sistema de informacin en estudio.
5
3. Ficheros.
En las antiguas aplicaciones informticas, antes de que surgieran las bases de datos, la informacin se guardaba
en ficheros.
As, por ejemplo, una aplicacin que guardaba los datos de personas, almacenaba dichos datos en un fichero
convencional cuyo contenido bien poda ser este:
Ant oni o Pr ez Pr ez 30 C/ Mor al es n 11 Madr i d Madr i d
Fel i ci ano Gmez Sander 25 C/ Ter r er os n 121 Vi t or i a Vi t or i a
Ar t ur o Bueno Her nndez 46 C/ Cocol i so n 43 Mur ci a Mur ci a
Esto tena como efecto, que el programador de las aplicaciones que usaran ese fichero, tuviera que construir el
programa conociendo detalladamente las posiciones de los datos, para saber desde qu posicin hasta qu otra
posicin, se guardaba el nombre y apellidos, etc. Adems, tendra que controlar si se guardan filas de datos
duplicadas, y as un montn de inconvenientes. Por eso, cuando surgieron las bases de datos, se empez a dejar
de usar los ficheros convencionales.
Pero bien es cierto, que an en las ms modernas aplicaciones, a veces necesitamos un simple fichero para
guardar informacin, como por ejemplo un fichero de configuracin, o un fichero log. Es decir, no siempre nos
hace falta una base de datos para almacenar la informacin.
En Java, como en otros lenguajes de programacin, hay diversas clases para el manejo de ficheros, pues, como
hemos dicho, a veces son muy tiles. Para guardar poca informacin, es mejor usarlos que usar otro mtodo.
REFLEXIONA
Antiguamente, en el inicio de la informtica, cuando no existan los discos duros, ni los ficheros, los datos y los
programas se almacenaban en tarjetas perforadas. En esta entrada de blog tienes un ejemplo.
El pasado del almacenamiento de la informacin: Tarjetas perforadas
URL: http://eltamiz.com/elcedazo/2009/03/27/historia-de-un-viejo-informatico-nostalgia-un-programa-cobol-
en-tarjetas-perforadas/
En los aos ochenta, los datos y programas se almacenaban en ficheros y stos, en soportes como las cintas de
casete, las cintas de msica antiguas. Como ancdota, mira el vdeo promocional del ordenador ZX Spectrum+2,
que incorporaba un lector de casetes:
Vdeo sobre computador Spectrum+2
URL: http://www.youtube.com/watch?v=6w5HwefA4J o
6
3.1 Uso ficheros en la actualidad
Hay que tener en cuenta, que los ficheros en s, para grabar la informacin del modo que ponamos como
ejemplo anteriormente, en el ejemplo de las personas, ya no se usan. Pero, s que se usan ficheros que guardan
datos siguiendo un patrn o estructura bien definida, en otros mtodos de almacenamiento, como por ejemplo
en ficheros y en bases de datos XML.
De especial inters y uso cada vez ms extendido, son los ficheros XML. stos son archivos de texto que por
consiguiente no necesitan un software propietario para ser interpretados, como ocurre con la mayora de los
archivos binarios, y tienen normalmente la extensin xml.
Tambin debemos tener en cuenta, que las bases de datos relativamente modernas, como son las bases de datos
XML, guardan sus datos empleando ficheros xml.
Por eso, en muchas ocasiones se recurre a utilizar este tipo de soluciones, el uso de ficheros en vez de bases de
datos, y en particular de ficheros XML cuando se necesita intercambiar informacin a travs de varias
plataformas de hardware o de software, o de varias aplicaciones. A veces se exporta de una base de datos a
ficheros XML para trasladar la informacin a otra base de datos que leer esos ficheros XML.
Por esta razn se emplea XML en tecnologas de comunicacin como, por ejemplo, en WML (lenguaje de
formato inalmbrico) y WAP (protocolo de aplicaciones inalmbricas).
La fcil estructuracin de la informacin en los ficheros XML ha permitido que surjan muchas libreras de
conversin de la informacin almacenada a otros formatos como a PDF, texto, hojas de clculo, etc. Hay
muchos productos propietarios y de cdigo abierto.
AUTOEVALUACIN.
Seala la opcin correcta. Respecto a los ficheros podemos asegurar que:
a) Nunca es bueno utilizarlos.
b) Los ficheros xml ya estn en desuso.
c) Depende de la aplicacin, puede que en algn caso sean de utilidad
d) Fueron reemplazados por el formato pdf.
.
PARA REPASAR
En el siguiente enlace tienes un tutorial de introduccin al lenguaje XML:
Tutorial XML
URL: http://geneura.ugr.es/~jmerelo/xml/
7
4. Bases de datos.
Quizs hayas estudiado ya el mdulo de bases de datos. Tanto si es as como si no, recordamos aqu qu es un
sistema de bases de datos. Es:
Un sistema de informacin orientado hacia los datos, que pretende recuperar y almacenar la
informacin de manera eficiente y cmoda.
Surge en un intento de resolver las dificultades del procesamiento tradicional de datos, teniendo en
cuenta que los datos suelen ser independientes de las aplicaciones.
Las ventajas que aportan los sistemas de bases de datos respecto a los sistemas de archivos convencionales
son:
Independencia de los datos respecto de los procedimientos. El usuario tiene una visin abstracta de
los datos, sin necesidad de ningn conocimiento sobre la implementacin de los ficheros de datos,
ndices, etc. Esto supone un gran ahorro en los costes de programacin, de forma que la modificacin
de la estructura de los datos no suponga un cambio en los programas y viceversa. Sin ella, el
mantenimiento de la base de datos ocupara el 50% de los recursos humanos dedicados al desarrollo de
cualquier aplicacin.
Disminucin de las redundancias y en consecuencia,
Disminucin de la posibilidad de que se produzca inconsistencia de datos.
Mayor integridad de los datos.
Mayor disponibilidad de los datos.
Mayor seguridad de los datos.
Mayor privacidad de los datos.
Mayor eficiencia en la recogida, codificacin y entrada en el sistema.
Comparticin de los datos. Los datos deben poder ser accedidos por varios usuarios simultneamente,
teniendo previstos procedimientos para salvaguardar la integridad de los mismos.
Podemos afirmar generalizando, que se usa un sistema de ficheros convencional cuando la cantidad de datos a
guardar es tan reducida que no justifica las desventajas del uso de los sistemas de bases de datos. Por ejemplo,
para guardar los datos del resultado de la instalacin de un programa, usamos un fichero de texto, no se guardan
los datos en una base de datos.
AUTOEVALUACIN.
Seala la opcin correcta. El uso de bases de datos provoca que el usuario:
a) Deba gestionar las posibles redundancias en los datos.
b) Conozca la estructura de los ficheros ndice de la base de datos.
c) Tenga que implementar los procedimientos de seguridad en la base de datos.
d) Ninguna es correcta.
8
4.1 Bases de datos relacionales.
El modelo de bases de datos relacional fue propuesto en 1969 por Edgar Codd.
El propsito del modelo relacional es proporcionar un mtodo declarativo para especificar datos y
consultas. As, en el diseo de la base de datos establecemos qu informacin contendr dicha base de datos,
luego recuperaremos la informacin que queramos, y dejamos al software del sistema gestor de la base de datos
que se ocupe de: describir las estructuras de datos para almacenarlos, y gestionar los procedimientos de
recuperacin para obtener las consultas deseadas.
Las bases de datos relacionales son adecuadas para manejar grandes cantidades de datos, compartir datos entre
programas, realizar bsquedas rpidas, etc. Pero tienen como desventaja fundamental que no presentan un buen
modelo de las relaciones entre los datos, ya que todo se representa como tablas bidimensionales, o sea, en filas y
columnas.
Podemos decir de las bases de datos relacionales que:
Estn muy extendidas.
Son muy robustas.
Permiten interoperabilidad entre aplicaciones.
Permiten una forma de compartir datos entre aplicaciones.
Son el comn denominador de muchos sistemas y tecnologas. Una base de datos puede ser utilizada en
programas realizados en Java, o en C++, etc.
Otros modelos tradicionales
Cuando se estudian las bases de datos relacionales, se suelen mencionar tambin los modelos jerrquico y en
red. Algunos sistemas antiguos utilizan todava estas arquitecturas, en centros de datos donde se manejan
grandes volmenes de informacin y la complejidad de los sistemas hace prohibitivo el coste que supondra
migrar a sistemas que utilizaran otro modelo como el relacional.
El modelo relacional fue el primer modelo de bases de datos definido de manera formal. Posteriormente, se
formularon modelos informales para describir bases de datos jerrquicas (el modelo jerrquico) y bases de datos
en red (el modelo en red). Ambas, las bases de datos jerrquicas y en red existan antes que las bases de datos
relacionales, pero fueron descritas como modelo despus de que el modelo relacional fuera definido.
9
4.2 Bases de datos orientadas a objetos.
El origen de las Bases de datos orientadas a objetos (en adelante: BDOO) se debe bsicamente a las siguientes
razones:
La existencia de problemas al representar cierta informacin y modelar ciertos aspectos del mundo real.
Los modelos clsicos permiten representar gran cantidad de datos, pero las operaciones y
representaciones que se pueden realizar sobre ellos son bastante simples.
Pasar del modelo de objetos al modelo relacional, para almacenar la informacin, genera dificultades
que en el caso de las BDOO no surgen, ya que el modelo es el mismo. Es decir, los datos de los
programas escritos en lenguaje orientado a objetos se pueden almacenar directamente, sin conversin
alguna, en las BDOO.
Los sistemas de bases de datos orientadas a objetos soportan un modelo de objetos puro, ya que no estn
basados en extensiones de otros modelos ms clsicos como el relacional.
Por ello, una caracterstica general es que el lenguaje de programacin y el esquema de la base de datos
utilizan las mismas definiciones de tipos.
PARA SABER MS
El manifiesto de Malcolm Atkinson indica las caractersticas que debe cumplir un sistema de bases de
datos orientado a objetos. El siguiente es un resumen de las caractersticas que debe cumplir una base de
datos orienta a objetos:
1) Deben soportarse objetos complejos.
2) Debe soportarse la encapsulacin.
3) Deben soportarse tipos y clases.
4) Los tipos o clases deben ser capaces de heredar de sus ancestros.
5) Debe soportarse sobrecarga, sobreescritura y enlace dinmico.
6) El conjunto de todos los tipos de datos debe ser ampliable.
Y el sistema gestor de la base de datos debe cumplir lo siguiente:
7) Debe proporcionarse persistencia a los datos.
8) El SGBD debe ser capaz de gestionar bases de datos de muy gran tamao.
9) El SGBD debe soportar a usuarios concurrentes.
10) El SGBD debe ser capaz de recuperarse de fallos hardware y software.
11) El SGBD debe proporcionar una forma simple de consultar los datos.
10
4.3 Bases de datos orientadas a objetos (II).
El acceso a los datos puede ser ms rpido con las bases de datos orientadas a objetos que con las bases de datos
tradicionales porque no hay necesidad de utilizar las uniones o joins, que si se necesitan en los esquemas
relacionales tabulares. Esto se debe a que un objeto puede recuperarse directamente sin una bsqueda,
simplemente siguiendo punteros.
Cada vez ms, las necesidades de las aplicaciones actuales con respecto a las bases de datos son:
Soporte para objetos complejos y datos multimedia.
Jerarquas de objetos o tipos y herencia.
Gestin de versiones (gestin de los diversos cambios que se realizan sobre los elementos de algn
producto o una configuracin del mismo).
Modelos extensibles mediante tipos de datos definidos por el usuario.
Integracin de los datos con sus procedimientos asociados.
Manipulacin navegacional (en vez de declarativa) y de conjunto de registros.
Interconexin e interoperabilidad (habilidad de dos o ms sistemas o componentes para intercambiar
informacin y utilizar la informacin intercambiada).
Como ejemplos de Sistemas Gestores de Bases de datos Orientados a Objetos podemos sealar:
Db4o
URL: http://www.db4o.com/
Matisse
URL: http://www.matisse.com
Jasmine
URL: http://www.cai.com
ObjectStore
Texto del enlace: Base de datos ObjectStore
URL: http://www.odi.com
GemStone
URL: http://www.gemstone.com
AUTOEVALUACIN.
Seala las opciones correctas. Las bases de datos orientadas a objetos:
a) Presentan conceptos de orientacin a objetos como la herencia
b) Tienen el mismo tipo de problemas que las relacionales.
c) No permiten la manipulacin navegacional.
d) Deben permitir el control de versiones
11
4.4 Comparativa entre bases de datos relacionales y orientadas
a objetos
En numerosos bancos de pruebas realizados para comparar los sistemas de bases de datos orientados a objetos
(ODBMS) y los sistemas de bases de datos relacionales (RDBMS), se ha mostrado que los ODBMS pueden ser
superiores para ciertos tipos de tareas.
La explicacin a esto es que muchas operaciones se realizan utilizando interfaces navegacionales ms que
declarativos, y el acceso a datos navegacional es normalmente implementado muy eficientemente.
Un buen argumento a favor de las bases de datos orientadas a objetos es la transparencia (no ensucia la
construccin de una aplicacin). El desarrollador as se debe preocupar de los objetos de su aplicacin, en lugar
de cmo los debe almacenar y recuperar de un medio fsico.
Podemos decir que las ventajas de un SGBDOO frente a las relacionales son:
Permiten mayor capacidad de modelado. El modelado de datos orientado a objetos permite modelar el
mundo real de una manera mucho ms fiel. Esto se debe a:
o un objeto permite encapsular tanto un estado como un comportamiento
o un objeto puede almacenar todas las relaciones que tenga con otros objetos
o los objetos pueden agruparse para formar objetos complejos (herencia).
Extensibilidad, debido a que:
o Se pueden construir nuevos tipos de datos a partir de los ya existentes.
o Podemos agrupar propiedades comunes de diversas clases e incluirlas en una superclase, lo
que reduce la redundancia.
o Tenemos reusabilidad de clases, lo que repercute en una mayor facilidad de mantenimiento y
un menor tiempo de desarrollo.
Disposicin de un lenguaje de consulta ms expresivo. El acceso navegacional desde un objeto al
siguiente es la forma ms comn de acceso a datos en un sistema gestor orientado a objetos. Mientras
que SQL utiliza el acceso declarativo. El acceso navegacional es ms adecuado para gestionar
operaciones tales como consultas recursivas, etc.
Adaptacin a aplicaciones avanzadas de base de datos. Hay muchas reas en las que las bases de
datos relacionales no han tenido excesivo xito, como es el caso de en sistemas de diseo CAD, CASE,
sistemas multimedia, etc. en los que las capacidades de modelado de los SGBDOO han hecho que esos
sistemas s resulten efectivos para este tipo de aplicaciones.
Prestaciones. Los sistemas gestores de bases de datos orientadas a objetos proporcionan mejoras
significativas de rendimiento con respecto a los SGBD relacionales. Aunque hay autores, que han
argumentado que los bancos de prueba, usados en dichas pruebas, estn dirigidos a aplicaciones de
ingeniera donde los SGBDOO son ms adecuados. Tambin est demostrado, que los SGBDR tienen
un rendimiento mejor que los SGBDOO en las aplicaciones tradicionales de bases de datos como el
procesamiento de transacciones en lnea (OLTP).
Reglas de acceso. En las bases de datos relacionales, a los atributos se accede y se modifican a travs
de operadores relacionales predefinidos. En las orientadas a objetos se procede mediante las interfaces
que se creen a tal efecto de las clases. Desde este punto de vista, los sistemas orientados a objetos dan
independencia a cada objeto que el sistema relacional no permite.
Clave. En el modelo relacional, las claves primarias generalmente tienen una forma representable en
texto, sin embargo los objetos no necesitan una representacin visible del identificador.
12
4.4.1 Desventajas de las bases de datos orientadas a objetos frente a las relacionales.
Como desventajas o puntos dbiles de las BBDDOO respecto a las relacionales podemos mencionar:
La reticencia del mercado, tanto para desarrolladores como usuarios, a este tipo de bases de datos.
Carencia de un modelo de datos universal. No hay ningn modelo de datos que est universalmente
aceptado para los SGBDOO y la mayora de los modelos carecen de una base terica. El modelo de
objetos an no tiene una teora matemtica coherente que le sirva de base.
Carencia de experiencia. Al ser una tecnologa relativamente nueva, todava no se dispone del nivel
de experiencia del que se dispone para los sistemas relacionales.
Panorama actual. Tanto los sistemas gestores de bases de datos como los sistemas gestores de bases
de datos objeto-relacionales estn muy extendidos. SQL es un estndar aprobado y ODBC y JDBC
son estndares de facto. Adems, el modelo relacional tiene una slida base terica y los productos
relacionales disponen de muchas herramientas de soporte que sirven tanto para desarrolladores como
para usuarios finales.
Dificultades en optimizacin. La optimizacin de consultas necesita realizar una compresin de la
implementacin de los objetos, para poder acceder a la base de datos de manera eficiente. Sin embargo,
esto compromete el concepto de encapsulacin.
AUTOEVALUACIN.
Seala la opcin correcta. Las bases de datos orientadas a objetos son ms recomendables que las relacionales:
a) Siempre.
b) Cuando necesitamos la mayor cercana al mundo real, la mayor capacidad de modelado, como en
sistemas CAD/CAM.
c) En aplicaciones de sistemas de control.
d) En programas de control de stock.
13
4.5 Bases de datos objeto-relacionales
Entendemos Base de Datos Objeto Relacional (BDOR), una base de datos que ha evolucionado desde el
modelo relacional a otro extendido que incorpora conceptos del paradigma orientado a objetos. Por tanto,
un Sistema de Gestin Objeto-Relacional (SGBDOR) contiene ambas tecnologas: relacional y de objetos.
En una Base de Datos Objeto Relacional el diseador puede crear sus propios tipos de datos y crear mtodos
para esos tipos de datos.
Por ejemplo, podramos definir un tipo de la siguiente manera:
CREATE TYPE persona_t AS OBJECT (
ni f VARCHAR2( 9) ,
nombr e VARCHAR2( 30) ,
di r ecci on VARCHAR2( 40) ,
t el ef ono VARCHAR2( 15) ,
f echa_nac DATE) ;
Por poner un ejemplo, si consideramos la base de datos Oracle, debido a los requerimientos de las nuevas
aplicaciones, el sistema de gestin de bases de datos relacional desde versin 8i fue extendido con conceptos del
modelo de bases de datos orientadas a objetos. De esta manera, aunque las estructuras de datos que se utilizan
para almacenar la informacin siguen siendo tablas, los diseadores pueden utilizar muchos de los mecanismos
de orientacin a objetos para definir y acceder a los datos. Se reconoce el concepto de objetos, de tal manera que
un objeto tiene un tipo, se almacena en cierta fila de cierta tabla y tiene un identificador nico (OID). Estos
identificadores se pueden utilizar para referenciar a otros objetos y as representar relaciones de asociacin y de
agregacin.
La ventaja de este tipo de base de datos es que los usuarios pueden pasar sus aplicaciones actuales sobre bases
de datos relaciones este nuevo modelo sin tener que reescribirlas. Ms tarde, se pueden ir adaptando las
aplicaciones y bases de datos para que utilicen las funciones orientadas a objetos.
Con las Bases de Datos Objeto-Relacional se ampla el modelo relacional destacando las siguientes
aportaciones:
Se aumentan la variedad en los tipos de datos,
o se pueden crear nuevos tipos de datos que permitan construir aplicaciones complejas con una
gran riqueza de dominios. Se soportan tipos complejos como: registros, conjuntos, referencias,
listas, pilas, colas y vectores.
Hay extensiones en el control de la Semntica de datos Objeto-Relacionales:
o Se pueden crear procedimientos almacenados y funciones que tengan un cdigo en algn
lenguaje de programacin, como por ejemplo: SQL, Java, C, etc.
Se pueden compartir varias libreras de clases ya existentes, esto es lo que conocemos como
reusabilidad.
Como productos comerciales de bases de Datos Objeto-Relacional podemos destacar:
DB2 Universal Database de IBM (International Business Machines).
Universal Server de Informix (ahora de IBM),
INGRES II, de Computer Associates.
ORACLE de Oracle Corporation,
SyBASE
Como productos de cdigo abierto, destacamos PostGreSQL.
14
5. Acceso a bases de datos mediante conectores
Para gestionar la informacin de las bases de datos hay unos estndares que facilitan a los programas
informticos manipular la informacin almacenada en ellas.
En Java existe un API basado en estos estndares que permite al desarrollar aplicaciones, que se pueda acceder a
bases de datos relacionales: JDBC (Java Database Connectivity, conectividad de bases de datos de Java).
La mayora de las aplicaciones importantes de una empresa estn respaldadas por una arquitectura normalizada
y optimizada de bases de datos relacionales. Tradicionalmente, dichas aplicaciones estn basadas en sentencias
SQL con las cuales se gestionan todos los datos que manejan.
Este modelo contina teniendo una gran importancia estratgica y es la base para el continuo crecimiento del
mapeo Objeto-Relacional (O/R) y est asociado a los mecanismos de persistencia.
Un driver JDBC es un componente softwareque posibilita a una aplicacin Java interaccionar con una
base de datos.
El API JDBC define interfaces y clases para escribir aplicaciones de bases de datos en Java realizando
conexiones de base de datos.
Mediante JDBC el programador puede enviar sentencias SQL, y PL/SQL a una base de datos relacional. J DBC
permite embeber SQL dentro de cdigo Java.
La ventaja de usar conectores JDBC es que independiza de la base de datos que utilice.
No obstante hay un trabajo de traduccin para mapear los campos devueltos por cada consulta a la
coleccin de objetos correspondiente. Y hay que trabajar las sentencias de actualizacin, insercin y
eliminacin para cada uno de los campos. Esto constituye una razn para tratar de buscar alternativas menos
costosas en tiempo de desarrollo.
REFLEXIONA
Sabas que.?
El controlador de ODBC (Open Database Connectivity, Conectividad abierta de bases de datos) es la interfaz de
programacin de base de datos que utiliza Microsoft para tener acceso a distintas bases de datos relacionales en
diversas plataformas. Tambin existe un estndar que sirve de puente entre JDBC-ODBC en las versiones
Solaris y Windows de la plataforma Java, para que se pueda utilizar ODBC desde un programa Java.
15
6. Mapeo objeto relacional (ORM)
En los inicios de la programacin, los programas se desarrollaban con la llamada programacin imperativa. De
hecho, y como sabes, la programacin orientada a objetos surgi unos aos despus.
Con la expansin de la programacin orientada a objetos, se da la circunstancia de que las bases de datos
relacionales se siguen utilizando hoy en da de manera masiva, por lo que muchas aplicaciones se desarrollan
con POO pero los datos, no se almacenan en bases de datos orientadas a objetos, sino en las bases de datos
relacionales.
El sistema ms extendido en las empresas hoy en da para guardar la informacin de sus aplicaciones es el
uso de una base de datos relacional. Tradicionalmente, dichas aplicaciones estn basadas en sentencias
SQL con las cuales se gestionan todos los datos que manejan. Este sistema es la base para el continuo
crecimiento del mapeo Objeto-Relacional (O/R) y est asociado a los mecanismos de persistencia.
Cuando se programan sistemas orientados a objetos, utilizando una base de datos relacional, los programadores
invierten gran cantidad de tiempo en desarrollar los objetos persistentes, o sea, convertir los objetos del lenguaje
de programacin a registros de la base de datos. Igualmente, tambin pasan bastante tiempo implementando la
operacin inversa, es decir, convirtiendo los registros en objetos.
El mapeo objeto-relacional (Object-Relational Mapping, o ORM) consisten en una tcnica de programacin
para convertir datos entre el sistema de tipos utilizado en un lenguaje de programacin orientado a objetos y
el sistema utilizado en una base de datos relacional.
Cuando se trabajan con programacin orientada a objetos y con bases de datos relacionales, es fcil observar
que estos son dos paradigmas diferentes. El modelo relacional trata con relaciones y conjuntos, es de
naturaleza matemtica. Por el contrario, el paradigma orientado a objetos trata con objetos, atributos y
asociaciones de unos con otros.
Cuando se requiere almacenar la informacin de los objetos utilizando una base de datos relacional se
comprueba que hay un problema de compatibilidad entre estos dos paradigmas, el llamado desfase objeto-
relacional.
Por ello, para ahorrar trabajo al programador, se puede utilizar un framework que se encargue de realizar estas
tareas de modo transparente, de modo que el programador no tenga por qu usar JDBC ni SQL y la gestin del
acceso a la base de datos est centralizada en un componente nico permitiendo su reutilizacin.
AUTOEVALUACIN.
Seala las opciones correctas:
a) El desfase objeto-relacional se refiere a la incompatibilidad que hay entre el paradigma
relacional y el objeto-relacional
b) La programacin orientada a objetos surgi antes que la programacin imperativa.
c) El modelo de bases de datos relacional todava tiene un gran uso. La persistencia se define como
la conversin de registros a objetos.
16
6.1 Capa de persistencia y framework de mapeo
La capa de persistencia de una aplicacin es la pieza que permite almacenar, recuperar, actualizar y eliminar el
estado de los objetos que necesitan persistir en un sistema gestor de datos.
En el caso del mapeo objeto-relacional, un ORM es una capa que permite relacionar objetos con un modelo de
datos relacional, ocultando todo el mecanismo de conexin al motor de base de datos, y tambin no teniendo
que escribir las sentencias SQL necesarias para la gestin de los datos.
La capa de persistencia traduce entre los dos modelos de datos: desde objetos a registros y desde registros a
objetos. As, si el programa quiere grabar un objeto, entonces llama al motor de persistencia, el motor de
persistencia traduce el objeto a registros y llama a la base de datos para que guarde estos registros.
De este modo el programa slo ve que puede guardar y recuperar objetos, como si estuviera programado para
una base de datos orientada a objetos. Y la base de datos slo ve que guarda y recupera registros como si el
programa estuviera dirigindose a ella de forma relacional.
Dispones de mltiples alternativas como desarrollador en Java cuando pretendas trabajar con mapeadores O/R.
Hay tres comunidades que estn implicadas en el mundo de la persistencia O/R de Java de forma activa:
Organizaciones basadas en el estndar,
Comunidades cdigo abierto (open source) y
Grupos comerciales.
Las comunidades open source incluyen importantes tecnologas, entre ellas Hibernate y el framework Spring.
Las alternativas ms importantes basadas en el estndar, son EJB 3.0 y JDO.
Entre las implementaciones comerciales se puede resaltar TopLink.
Cada uno de los mecanismos de mapeo O/R tiene una dependencia particular en el conector JDBC para poder
comunicarse con la base de datos de una forma eficiente. Si el conector JDBC que participa en la comunicacin
no es ptimo, la posible gran eficiencia de cualquier framework quedar debilitada. Por tanto, seleccionar el
driver JDBC que mejor se adapte a la aplicacin es esencial a la hora de construir un sistema eficiente en el que
intervenga un mecanismo de mapeo O/R.
17
7. Bases de datos XML.
Se define XML como: eXtensible Markup Language (lenguaje de marcado extensible). Es una especificacin
del World Wide Web Consortium (W3C).
Debido a las limitaciones de la tecnologa de bases de datos relacionales estn surgiendo nuevas clases de bases
de datos como son las bases de datos XML.
Estas bases de datos almacenan los datos estructurados como XML sin la necesidad de traducir los datos a
una estructura relacional o de objeto.
Podemos distinguir entre:
Bases de datos nativas XML. Consiste en un modelo lgico para documentos XML. El Sistema
Gestor de Base de Datos correspondiente almacena y recupera documentos de acuerdo a dicho modelo.
o Productos ejemplo de esa filosofa son: eXist, Apache Xindice, Berkeley dbXML.
Bases de datos compatibles con XML (XML-enabled): son bases de datos, generalmente objeto-
relacionales, que admiten entradas de datos en forma de XML y proporcionan salidas en este mismo
formato.
o Podemos citar productos como: Oracle, DB2 (Viper),
Las bases de datos XML nativas permiten trabajar con XQL (eXtensible Query Language), el cul sirve un
propsito similar a SQL en una base de datos relacional.
El trabajo con bases de datos XML nativas involucra dos pasos bsicos:
Describir los datos mediante Definiciones de Tipos de Datos (Document Type Definitions, DTD) o
esquemas XML y
Definir un nuevo esquema de base de datos XML nativa o Mapa de Datos a usar para almacenar y
obtener datos.
AUTOEVALUACIN.
Seala la opcin correcta:
a) XML es lo mismo que SQL pero para bases de datos orientadas a objetos.
b) Oracle es una base de datos nativa XML.
c) Una base de datos XML nativa puede trabajar con XQL.
d) XQL es un lenguaje parecido a SQL, pero para bases de datos nativas XML.
18
8. Desarrollo de componentes
La expansin, en los ltimos aos, de Internet y el comercio electrnico ha llevado a la necesidad de adoptar
nuevas tecnologas y nuevos requisitos de desarrollo en las aplicaciones informticas.
Al principio de la informtica, los ordenadores eran caros y la mano de obra de los programadores asequible.
Con el paso del tiempo los ordenadores son baratos y la mano de obra de los programadores suele ser cara.
Adems, los requisitos de las aplicaciones informticas son cada vez ms complejos. Por ello, aparecieron las
tcnicas orientadas a objetos, para, entre otras cosas, intentar programar de manera que el cdigo que se
desarrolle pueda ser reutilizable.
19
8.1 Definicin de componente
Un componente es una unidad de software que realiza una funcin bien definida y posee una interfaz bien
definida.
Un componente software posee interfaces especificadas contractualmente, pudiendo ser desplegado
independientemente y puede interaccionar con otros componentes para formar un sistema.
Un interfaz es un punto de acceso a los componentes: permite a los clientes acceder a los servicios
proporcionados por un componente.
La idea de dividir u organizar en trozos el software, o sea, dividirlo en componentes surge para reducir la
complejidad del software. As se permite la reutilizacin y se acelera el proceso de ensamblaje del software.
Los creadores de componentes pueden especializarse creando objetos cada vez mas complejos y de mayor
calidad.
La interoperabilidad entre componentes de distintos fabricantes:
Aumenta la competencia,
Reduce los costes y,
Facilita la construccin de estndares.
Por tanto, as el software se hace cada vez ms rpido, de mejor calidad y a menor coste incluso de
mantenimiento.
Un componente software tambin debe especificar sus necesidades para funcionar correctamente, lo que se
denominan las dependencias de contexto:
Interfaces requeridas
Entorno de ejecucin: mquina necesaria, sistema operativo a utilizar, etc.
En el entorno Java, contamos con los JavaBeans.
AUTOEVALUACIN.
Seala la opcin correcta:
a) Un componente software no necesita interfaces.
b) Un componente software no puede interactuar con otro componente software.
c) Quien vaya a usar un componente debe conocer el interface de dicho componente)
d) Todas las afirmaciones anteriores son falsas.
20
8.2 J avaBeans
El origen de los JavaBeans lo podemos encontrar en un par de necesidades que Java tena:
Disponer de una tecnologa de objetos y componentes reutilizables.
Mejorar el proceso para crear interfaces de usuario, acercndose a la facilidad de uso que otros
productos permitan como Visual Basic de Microsoft.
Un JavaBean es un componente software reutilizable basado en la especificacin JavaBean de Sun (ahora
Oracle) que se puede manipular visualmente con una herramienta de desarrollo.
Hay una serie de propiedades que presenta un JavaBean:
Portabilidad: uno de los principales objetivos de los JavaBeans es proporcionar una arquitectura
neutral de componentes, es decir, que los beans puedan utilizarse en otras plataformas y entornos.
Reusabilidad: son componentes reutilizables, la filosofa es que estos componentes pueden usarse
como bloques en la construccin de aplicaciones complejas.
Introspeccin: los IDE reconocen ciertas pautas de diseo, nombres de las funciones miembros o
mtodos y definiciones de las clases, permitiendo a la herramienta de programacin mirar dentro del
bean y conocer sus propiedades y comportamiento.
Personalizacin: en tiempo de diseo, con el IDE que se utilice, se pueden modificar las caractersticas
de apariencia y comportamiento de un bean.
Persistencia: un bean puede guardar su estado y recuperarlo posteriormente. Esta capacidad se logra
mediante la serializacin. Cuando un ejemplar de bean se serializa se convierte en un flujo de datos que
se almacenar en algn sitio, probablemente en un fichero. Cualquier applet, aplicacin o herramienta
que utilice el bean puede restaurarlo mediante la deserializacin.
Comunicacin entre eventos: Los eventos constituyen un mecanismo de notificacin entre objeto
fuente y objeto(s) receptor(es). Las herramientas de desarrollo pueden examinar un bean para
determinar qu eventos puede enviar y cules puede recibir.
AUTOEVALUACIN.
Indica si la siguiente afirmacin es verdadera o falsa:
Los JavaBean slo se pueden usar en plataformas Windows.