MHProject v2.0

Persistencia de Objetos Java utilizando db4o

Autor: Jim Paterson
Traductor: Juan Antonio Palos (Ozito)

1 . Introducción
2 . Bases de Datos Embebidas
3 . ¿Para qué es bueno db4o?
4 . Mismo API, Diferente Almacenamiento
5 . Un Ejemplo
6 . Almacenar los Datos
7 . Consulta Simple: QBE
8 . Actualizar y Borrar
9 . Un soporte de Consultas más poderoso
10 . ¿Qué más puede hacer S.O.D.A.?
11 . Conclusión

[Mas:]

Introducción 

Muchas aplicaciones Java necesitan tratar con datos persistentes. En la
mayoría de los casos, esto significa encararse con una base de datos
relacional, posiblemente un base de datos obsoleta (o antigua) o un
Sistema de Manejo de Bases de Datos (DBMS) estándar industrial. El API
JDBC y los drivers para la mayoría de los sistemas de bases de datos
proporcionan una forma estándar de utilizar SQL para ejecutar consultas
a la base de datos. Sin embargo, el interface se complica por la
"diferencia de impedancia" entre el modelo de objetos de dominio de la
aplicación y el modelo relacional de la base de datos. El modelo de
objetos está basado en principios de ingeniería de software y modela
los objetos en el dominio del problema, mientras que el modelo
relacional está basado en principios matemáticos y organiza los datos
para una almacenamiento y recuperación eficientes. Ninguno de estos
modelos es particularmente mejor que el otro, pero el problema es que son diferentes y no siempre se acoplan de forma confortable en la misma aplicación.

Algunas soluciones a este problema, como Hibernate y Java Data Objects, están diseñados para proporcionar al desarrallodor la persistencia transparente:
la aplicación trata con objetos persistentes utilizano un API orientado
a objetos sin la necesidad de código SQL embebido en el código Java. La
Persistencia Manejada por el Contenedor (CMP) hace un trabajo similar
para contenedores EJB, pero no hay una facilidad de persistencia
general para la plataforma Java. En cualquiera de estas soluciones, los
objetos son mapeados a tablas en una Base de Datos Relacional (RDBMS)
por el marco de trabajo subyacente, que genera el SQL requerido para
almacenar atributos de objetos. Cuanto más complejo sea modelo de
objetos más díficil será el mapeo. Se necesita crear Descriptores,
normalmente ficheros XML, para definir estos mapeos. La herencia y las
relaciones muchos-a-muchos en particular, añaden complejidad ya que
estas relaciones no se pueden representar directamente en el modelo
relacional. Los árboles de herencia pueden mapearse a un conjunto de
tablas de varias formas, la elección resulta de un balance entre la
eficiencia de almacenamiento y la complejidad de las consultas, ya que
se requiere una unión de tablas separadas para implementar relaciones
muchos-a-muchos.

Almacenar objetos en una base de datos, que a su vez utiliza su
propio modelo de objetos, ofrece otra solución. Durante los años 90 se
ha desarrollado una gran variedad de Bases de Datos Orientadas a
Objetos (OODBMS), pero dichas herramientas pueden ser complejas de
configurar y pueden requerir el uso de un lenguaje de definición de
objetos. Los objetos se almacenan como objetos, pero no son nativos al
lenguaje de la aplicación. Estos productos no han tenido un fuerte
impacto en el mercado más allá de sus áreas "nicho", y el esfuerco
parece concentrarse principalmente en los APIs orientados a objetos
para bases de datos relacionales así como bases de datos híbridas
objeto-relacional.

Páginas: 1 2 3 4 5 6 7 8 9