PDF de programación - Bases de Datos Orientadas a Objetos

Tema 4: Bases de Datos Orientadas a Objetos:
Introducción. Características de los SGBDOO.
Modelo de Datos Orientado a Objetos. Objetos
Complejos. Estándar ODMG del Modelo de
Objetos. Lenguaje de Definición de Objetos ODL.
Lenguaje de Consulta de Objetos OQL. Diseño
Conceptual de Bases de Datos de Objetos.
Estándar CORBA para Objetos Distribuidos.

1

Introducción

Las bases de datos relacionales, la inicio del año 2000 eran las
más utilizadas en la mayoría de los ámbitos de aplicación. La
estructura de datos básica que ofrece, la tabla relacional, es
apropiada para muchas aplicaciones habituales.

Sin embargo, existen casos de uso en los que presenta serios
inconvenientes prácticos, generalmente si se requiere gestionar
datos muy complejos o no convencionales
(imágenes,
documentos...), para los que las estructuras relacionales resultan
muy complejas e ineficientes. Algunos ejemplos de gran
importancia práctica son las bases de datos multimedia, las
bases de datos científicos y los sistemas de apoyo al diseño
industrial (cad/cam).

2

Introducción

Las bases de datos orientadas a objetos intentan dar respuesta a estos

problemas, incorporando las siguientes características:

Adoptan como modelo de datos el de los lenguajes orientados a objetos,
permitiendo así el uso de estructuras de datos tan complejas como sea
necesario y eliminando en gran medida las barreras entre el desarrollo de
aplicaciones y la gestión de datos.

Permiten la extensibilidad con nuevos

tipos de datos complejos,

permitiendo incorporar operaciones arbitrarias sobre ellos.

Estas características han motivado el desarrollo de numerosos sistemas
orientados a objetos. Juntamente al avance vertiginoso de desarrollo de
WebApps que requieren estructuras de datos muy flexibles.

3

Evolución histórica de las bases de datos

4

5

Objetivo propuestos por las BDOO

Proporcionar un modelo de datos mucho más rico y extensible, y así complementar

(aunque no sustituir) a las bases de datos relacionales.

Lograr una equivalencia al de los lenguajes de programación orientados a objetos,
como C++ o Java. Esto tiene la gran ventaja de que, al compartir el modelo de datos, se
pueden integrar las BDOO con el software usado para desarrollar aplicaciones, de
manera directa y casi transparente. (en las BDR es necesario usar dos lenguajes: a) uno
de programación para la aplicación, y b) sql para el acceso a la base de datos, lo que
implica realizar costosas conversiones.

Disponer de nuevas características para el modelado de datos complejos (BDOR.
Las últimas versiones del estándar sql, a partir de sql99, también incluyen muchas de
estas funcionalidades. Entre ellas se incluyen la posibilidad de almacenar en tablas
relacionales grandes objetos binarios (denominados «blobs», por Binary Large
OBjects), como imágenes, sonido o video; las herramientas de gestión de documentos
(índices y operadores específicos para buscar
texto, soporte de xml); y otras
extensiones para soportar datos geográficos).

6

Niveles de soporte de la tecnología OO en BD

A pequeña escala se encuentran las librerías que permiten el almacenamiento
persistente de objetos. Estas están disponibles para cualquier lenguaje de
programación orientado a objetos.

Después están las bases de datos objeto-relacionales, para aplicaciones que
requieren usar algunos tipos de datos complejos en un entorno esencialmente
relacional, y que se basan en extensiones orientadas a objetos de sql.

Finalmente, las bases de datos orientadas a objetos puras proporcionan una
gestión de bases de datos orientadas a objetos a todos los niveles, desde la
definición de datos al lenguaje de consulta.

7

Sistemas de gestión de bases de datos orientados
a objetos (SGBDOO)

El hecho de que las BDOO y LPOO compartan el mismo modelo de datos

permite desarrollar aplicaciones sobre BDOO de manera casi transparente.

Sin embargo, hay que tener en cuenta los siguientes factores:

Desde el lenguaje de programación orientado a objetos es necesario indicar
qué objetos se guardarán en la base de datos (serán persistentes) y cuáles no.

Según los requisitos de la aplicación a desarrollar, se deberá utilizar un
SGBDOO con determinadas características (siguiendo el Manifiesto bdoo,
análogo a las 12 reglas de Codd del modelo relacional).

8

Persistencia de objetos

Persistencia. es qué objetos deberán permanecer en la base de datos una

vez que el programa haya terminado, y cuáles no.

Los objetos transitorios desaparecen una vez que el programa que los
creó termina de ejecutarse, mientras que los objetos persistentes
permanecen almacenados en la base de datos.

Para hacer un objeto persistente hay tres alternativas.

La primera es marcarlo explícitamente como persistente.
Hacerlo alcanzable a partir de otro objeto ya marcado como

persistente.

Es añadiéndolos a una colección persistente de su clase.

9

Persistencia de objetos. Marcado explícitamente.

En el ejemplo (en Java se utiliza db4o) se crea un objeto de tipo Empleado,
que a se marca como persistente usando el método store. El objeto contenedor
encapsula el almacenamiento de objetos.

A partir de este momento, todos los cambios que se produzcan en este objeto

se guardarán automáticamente.

Al marcar un objeto como persistente existe la posibilidad de asignarle un
nombre único dentro de la base de datos, a través del cual el SGBDOO permite
a los usuarios y a los programas acceder a él.

Los objetos con nombre único suelen ser pocos y sirven como puntos de

acceso a la base de datos.

10

Persistencia de objetos. Alcanzable a partir de otro objeto

Se dice que un objeto A es alcanzable desde otro B, si hay alguna cadena de referencias

que llevan desde el objeto B hasta el objeto A.

Esta cadena de referencias puede ser muy larga y pasar por muchos objetos. De esta
manera, cuando se hace un objeto persistente, todos los objetos alcanzables a partir de
él se hacen implícitamente persistentes.

11

Persistencia de objetos. Añadiéndolos a una colección persistente
de su clase.



Sobre una clase se pueden definir varias colecciones de objetos persistentes, y para aquellas clases
que vayan a tener instancias almacenadas en la base de datos es imprescindible tener definida al
menos una.
Por ejemplo, en nuestro lenguaje de definición de datos se define por medio de la cláusula extent
una colección persistente para cada clase. De esta manera, para hacer un objeto persistente, solo hay
que añadirlo a una de las colecciones persistentes asociadas a su clase.

12

Características de los SGBDOO

El conjunto de reglas equivalente para los sistemas orientados a objetos se conoce
como el Manifiesto de las bdoo, y fue definido en 1992. Consta de las 13 reglas
obligatorias para considerar que un SGBD es OO y de cinco opciones de
implementación que no son obligatorias.

Herencia múltiple
Verificación e inferencia de tipos
Distribución de los datos
Transacciones
Versionado de objetos

Ninguna base de datos comercial cumple todas las reglas del Manifiesto, por lo que
puede decirse que estas reglas describen un sistema idealizado no disponible en la
realidad. Sin embargo, en la práctica se trata de una lista muy útil para analizar los
SGBDOO y determinar si se ajustan a los requisitos de una aplicación dada.

13

Características de los SGBDOO

BD ORIENTADAS A OBJETOS

14

Ventajas de las SGBDOO


Mayor capacidad de modelado. El modelado de datos orientado a objetos permite modelar el ‘mundo
real’ de una manera mucho más fiel. Esto se debe a: a) o un objeto permite encapsular tanto un estado como
un comportamiento, b) o un objeto puede almacenar todas las relaciones que tenga con otros objetos; c) o los
objetos pueden agruparse para formar objetos complejos (herencia).


Ampliabilidad. Esto se debe a: a) o Se pueden construir nuevos tipos de datos a partir de los ya existentes; b)
o Agrupación de propiedades comunes de diversas clases e incluirlas en una superclase, lo que reduce la
redundancia.; c) o Reusabilidad de clases, lo que repercute en una mayor facilidad de mantenimiento y un
menor tiempo de desarrollo.




Lenguaje de consulta más expresivo. El acceso navegacional desde un objeto al siguiente es la forma más
común de acceso a datos en un SGBDOO. Mientras que SQL utiliza el acceso asociativo. El acceso
navegacional es más adecuado para gestionar operaciones como los despieces, consultas recursivas, etc.


Adecuación a las aplicaciones avanzadas de base de datos. Hay muchas áreas en las que los SGBD
tradicionales no han tenido excesivo éxito como el CAD, CASE, OIS, 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.


Mayores prestaciones. Los SGBDOO proporcionan mejoras significativas de rendimiento con respecto a los
SGBD relacionales. Aunque hay autores que han argumentado que los bancos de prueba usados están dirigidos
a aplicaciones de ingeniería donde los SGBDOO son más adecuados. También 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 línea (OLTP).

15

Inconvenientes de las SGBDOO

Carencia de un modelo de datos universal. No hay ningún modelo de datos que esté
universalmente aceptado para los SGBDOO y la mayoría de los modelos carecen una base
teórica.

Carencia de experiencia. Todavía no se dispone del nivel de experiencia del que se dispone para

los sistemas tradicionales.

Carencia de estándares. Existe una carencia de estándares general para los SGBDOO.

Competencia. Con respecto a los SGBDR y los SGBDOR. Estos productos tienen una
experienc