1

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

Introducción

� Las bases de datos relacionales, la inicio del año 2000 eran lasmás utilizadas en la mayoría de los ámbitos de aplicación. Laestructura de datos básica que ofrece, la tabla relacional, esapropiada para muchas aplicaciones habituales.

� Sin embargo, existen casos de uso en los que presenta seriosinconvenientes prácticos, generalmente si se requiere gestionardatos muy complejos o no convencionales (imágenes,documentos...), para los que las estructuras relacionales resultanmuy complejas e ineficientes. Algunos ejemplos de granimportancia práctica son las bases de datos multimedia, lasbases de datos científicos y los sistemas de apoyo al diseñoindustrial (cad/cam).

2

Introducción

Las bases de datos orientadas a objetos intentan dar respuesta a estosproblemas, 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 seanecesario y eliminando en gran medida las barreras entre el desarrollo deaplicaciones 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 sistemasorientados a objetos. Juntamente al avance vertiginoso de desarrollo deWebApps 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, sepueden integrar las BDOO con el software usado para desarrollar aplicaciones, demanera directa y casi transparente. (en las BDR es necesario usar dos lenguajes: a) unode programación para la aplicación, y b) sql para el acceso a la base de datos, lo queimplica 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 deestas funcionalidades. Entre ellas se incluyen la posibilidad de almacenar en tablasrelacionales 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 otrasextensiones 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 almacenamientopersistente de objetos. Estas están disponibles para cualquier lenguaje deprogramación orientado a objetos.

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

� Finalmente, las bases de datos orientadas a objetos puras proporcionan unagestión de bases de datos orientadas a objetos a todos los niveles, desde ladefinición de datos al lenguaje de consulta.

7

Sistemas de gestión de bases de datos orientadosa objetos (SGBDOO)

El hecho de que las BDOO y LPOO compartan el mismo modelo de datospermite 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 indicarqué 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 unSGBDOO 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 unavez que el programa haya terminado, y cuáles no.

� Los objetos transitorios desaparecen una vez que el programa que loscreó 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 comopersistente.

� 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 contenedorencapsula el almacenamiento de objetos.

� A partir de este momento, todos los cambios que se produzcan en este objetose guardarán automáticamente.

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

� Los objetos con nombre único suelen ser pocos y sirven como puntos deacceso 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 referenciasque llevan desde el objeto B hasta el objeto A.

� Esta cadena de referencias puede ser muy larga y pasar por muchos objetos. De estamanera, 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 clasesque vayan a tener instancias almacenadas en la base de datos es imprescindible tener definida almenos 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 hayque 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 conocecomo el Manifiesto de las bdoo, y fue definido en 1992. Consta de las 13 reglasobligatorias para considerar que un SGBD es OO y de cinco opciones deimplementació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 quepuede decirse que estas reglas describen un sistema idealizado no disponible en larealidad. Sin embargo, en la práctica se trata de una lista muy útil para analizar losSGBDOO 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 ‘mundoreal’ de una manera mucho más fiel. Esto se debe a: a) o un objeto permite encapsular tanto un estado comoun comportamiento, b) o un objeto puede almacenar todas las relaciones que tenga con otros objetos; c) o losobjetos 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 laredundancia.; c) o Reusabilidad de clases, lo que repercute en una mayor facilidad de mantenimiento y unmenor tiempo de desarrollo.

� Lenguaje de consulta más expresivo. El acceso navegacional desde un objeto al siguiente es la forma máscomún de acceso a datos en un SGBDOO. Mientras que SQL utiliza el acceso asociativo. El accesonavegacional 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 SGBDtradicionales no han tenido excesivo éxito como el CAD, CASE, OIS, sistemas multimedia, etc. en los que lascapacidades de modelado de los SGBDOO han hecho que esos sistemas sí resulten efectivos para este tipo deaplicaciones.

� Mayores prestaciones. Los SGBDOO proporcionan mejoras significativas de rendimiento con respecto a losSGBD relacionales. Aunque hay autores que han argumentado que los bancos de prueba usados están dirigidosa aplicaciones de ingeniería donde los SGBDOO son más adecuados. También está demostrado que losSGBDR tienen un rendimiento mejor que los SGBDOO en las aplicaciones tradicionales de bases de datoscomo 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 baseteórica.

� Carencia de experiencia. Todavía no se dispone del nivel de experiencia del que se dispone paralos 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 unaexperiencia de uso considerable. SQL es un estándar aprobado y ODBC es un estándar de facto.Además, el modelo relacional tiene una sólida base teórica y los productos relacionales disponende muchas herramientas de soporte que sirven tanto para desarrolladores como para usuariosfinales.

� La optimización de consultas compromete la encapsulacion. La optimización de consultasrequiere una compresión de la implementación de los objetos, para poder acceder a la base dedatos de manera eficiente. Sin embargo, esto compromete el concepto de encapsulación.

� El modelo de objetos aún no tiene una teoría matemática coherente que le sirva de base.

16

Objetos complejos

� Una de las motivaciones para el desarrollo de sistemas OO fueel deseo de representar objetos complejos.

� Hay objetos complejos de dos tipos: estructurados y noestructurados.

� Un objeto complejo estructurado está constituido porcomponentes y se define aplicando recurrentemente, endiversos niveles, los constructores de tipos disponibles.

� Uno no estructurado casi siempre es un tipo de datos querequiere una gran cantidad de almacenamiento, como porejemplo un tipo de datos que representa una imagen.

17

Objetos complejos

Objetos complejos no estructurados y extensibilidad de tipos

� Un recurso para objetos complejos no estructurados permite el almacenamiento y recuperación deobjetos de gran tamaño. (Ej.: las imágenes de mapas de bits y las cadenas de texto largas).

� También se conocen como objetos binarios extensos, o BLOB (binary large object). Estos objetosson no estructurados en el sentido de que el SGBD no sabe qué estructura tienen. Sólo la aplicaciónque los usa sabe cómo interpretarlos. Se consideran complejos porque necesitan un área dealmacenamiento sustancial y no forman parte de los tipos de datos estándar que suelen ofrecer losSGBD. Como el tamaño de los objetos es considerable, un SGBD podría obtener una porción delobjeto y proporcionarla al programa antes de obtener todo el objeto. También podría usar técnicasde búferes y de almacenamiento en memoria cache para obtener por anticipado porciones delobjeto, antes de que el programa las necesite.

� El software de SGBD no tiene capacidad de procesar directamente las condiciones de selección niotras basadas en valores de estos objetos, a menos que la aplicación proporcione el código necesariopara realizar las operaciones de comparación (en el caso de la selección). En un SGBDOO, esto sepuede conseguir definiendo un nuevo tipo de datos abstracto para los objetos no interpretados ysuministrando los métodos para seleccionar, comparar y mostrar esos objetos.

� Como un SGBDOO permite a los usuarios crear nuevos tipos, y como un tipo incluye tantoestructura como operaciones, podemos considerar que un SGBDOO tiene un sistema de tiposextensibles. Se pueden crear bibliotecas de nuevos tipos definiendo estructura y operaciones. Otrasaplicaciones pueden utilizar estos tipos, e incluso modificarlos (creando subtipos de los tiposprovistos en las bibliotecas).

18

Objetos complejos

Objetos complejos estructurados

� La diferencia entre objeto complejo no estructurado y objeto complejo estructurado consiste en que laestructura del objeto se define por la aplicación repetida de los constructores de tipos proporcionados por elSGBDOO. Así, la estructura está definida, y además, el SGBDOO la conoce.

� Existen dos tipos de semántica para la referencia entre un objeto complejo y sus componentes en cada nivel.

� Semántica de propiedad, se aplica cuando los subobjetos de un objeto complejo están encapsulados dentrode éste, y por ello se los considera parte de él.

� Semántica de referencia, se aplica cuando los componentes del objeto complejo son ellos mismos objetosindependientes, pero pueden ser referenciados desde el objeto complejo.

� El primer tipo también es conocido como la relación es-parte-de o componente-de; y el segundo tipo comoestá-asociado-a. La relación es-parte-de tiene la característica de que los objetos están encapsulados dentro delobjeto complejo y se consideran parte del estado interno del objeto. No necesitan identificadores del objeto ysólo acceden a ellos los métodos de ese objeto. Además, desaparecen junto con el objeto complejo aleliminarlo. Por otra parte, un objeto complejo con componentes referenciados se considera formado por objetosindependientes con identidad y métodos propios. Cuando un objeto complejo necesita acceder a loscomponentes referenciados, debe hacerlo utilizando los métodos apropiados de los componentes. Además,como más de un objeto complejo puede hacer referencia a un mismo componente, este último no desaparececuando se elimina el objeto complejo.

� Los SGBDOO deben ofrecer opciones de almacenamiento para agrupar los objetos componentes de un objetocomplejo en el almacenamiento secundario, para aumentar la eficiencia de las operaciones que accedan a ellos.En muchos casos la estructura del objeto se almacena sin ser interpretado en páginas del disco. Cuando serecupera una página que incluye un objeto, el SGBDOO puede construir el objeto complejo a partir de lainformación contenida en las páginas del disco, las cuales pueden hacer referencia a páginas de discoadicionales. Eso se conoce como ensamblaje de objetos complejos. 19

ODMG: el estándar de facto para modelos de objetos

ODMG es un grupo de representantes de la industria de bases de datos el cual fue concebidoen el verano de 1991 con el objetivo de definir estándares para los SGBDOO.

Uno de sus estándares, el cual lleva el mismo nombre del grupo (ODMG), es el del modelopara la semántica de los objetos de una base de datos.

El modelo de objetos ODMG es un super conjunto del modelo de objetos de OMG, quepermite portar tanto los diseños como las implementaciones entre diversos sistemascompatibles.

20

ODMG: el estándar de facto para modelos de objetos

ODMG 3.0, propone los siguientes componentes principales de la arquitecturaODMG para un SGBDOO:

� Modelo de objetos

� Lenguaje de definición de objetos (ODL, Object Definition Language)

� Lenguaje de consulta de objetos (OQL, Object Query Language)

� Conexión con los lenguajes C++, Smalltalk y Java (al menos)

21

ODMG: el estándar de facto para modelos de objetos

Modelo de objetos

El modelo de objetos ODMG permite que tanto los diseños, como las implementaciones, sean portables entre los sistemasque lo soportan. Dispone de las siguientes primitivas de modelado:

� Los componentes básicos de una base de datos orientada a objetos son los objetos y los literales. Un objeto es unainstancia autocontenida de una entidad de interés del mundo real. Los objetos tienen algún tipo de identificador único.Un literal es un valor específico, como “Amparo” o 36. Los literales no tienen identificadores. Un literal no tiene queser necesariamente un solo valor, puede ser una estructura o un conjunto de valores relacionados que se guardan bajoun solo nombre.

� Los objetos y los literales se categorizan en tipos. Cada tipo tiene un dominio específico compartido por todos losobjetos y literales de ese tipo. Los tipos también pueden tener comportamientos. Cuando un tipo tienecomportamientos, todos los objetos de ese tipo comparten los mismos comportamientos. En el sentido práctico, untipo puede ser una clase de la que se crea un objeto, una interface o un tipo de datos para un literal (por ejemplo,integer). Un objeto se puede pensar como una instancia de un tipo.

� Lo que un objeto sabe hacer son sus operaciones. Cada operación puede requerir datos de entrada (parámetros deentrada) y puede devolver algún valor de un tipo conocido.

� Los objetos tienen propiedades, que incluyen sus atributos y las relaciones que tienen con otros objetos. El estadoactual de un objeto viene dado por los valores actuales de sus propiedades.

� Una base de datos es un conjunto de objetos almacenados que se gestionan de modo que puedan ser accedidos pormúltiples usuarios y aplicaciones.

� La definición de una base de datos está contenida en un esquema que se ha creado mediante el lenguaje de definiciónde objetos ODL (Object Definition Language) que es el lenguaje de manejo de datos que se ha definído como partedel estándar propuesto para las bases de datos orientadas a objetos.

22

ODMG: el estándar de facto para modelos de objetos

Elementos que componen un objeto

� Identidad de los objetos

� Constructores de tipos y objetos

� Referencia entre objetos

� Estado de los objetos

� Comportamiento de los objetos

� Clasificación e instanciación de objetos

23

ODMG: el estándar de facto para modelos de objetos

Objetos

� En las BDOO todos los elementos que se manejan son objetos.

� Cada objeto se corresponde con una entidad de la realidad, ydefine sus propiedades y comportamiento.

� Definición: un objeto es una representación abstracta de una

entidad del mundo real que tiene una identidad única dentro de

la base de datos, unas propiedades incorporadas en sí mismo, yun comportamiento que le proporciona la capacidad deinteraccionar con otros objetos y consigo mismo.

� Los objetos que comparten propiedades y comportamientoforman clases.

24

Los objetos, al igual que las filas de las bases de datos relacionales, expresan las propiedades de los elementos de la realidad. Sin embargo, los objetos, al contrario que las tuplas, tienen identidad y son elementos activos, de tal forma que poseen un comportamiento y pueden interaccionar entre sí.

ODMG: el estándar de facto para modelos de objetos

Identidad (oid)

� La identidad de cada objeto se representa por medio de un oid (Object Identifier), el cual esúnico para ese objeto.

� Es asignado por el sistema en el momento en que el objeto es creado y no puede ser alteradobajo ninguna circunstancia.

� No es visible para el usuario externo, sino que el sistema lo utiliza internamente para identificaral objeto, y para referenciarlo desde otros objetos.

� La diferencia entre un oid y una clave primaria está en que la clave primaria se basa en losvalores dados por los usuarios para ciertos atributos, los cuales pueden ser alterados en cualquiermomento. Sin embargo, el oid es asignado por el sistema, debe ser independiente del valor decualquier atributo, y no puede ser alterado.

� Solo puede desaparecer cuando su objeto lo haga, y en ese caso nunca puede volver a serutilizado.

� Tampoco puede referirse a ninguna dirección de memoria.

Así se consigue que la manera en que se representan los objetos y sus relaciones sea independientedel formato de almacenamiento físico de los datos.

25

Identidad (oid)

Dos objetos con el mismo oid se consideran idénticos: se trata a todos los efectos

del mismo objeto.

Es importante remarcar que dos objetos que no sean idénticos pueden ser iguales si

sus valores también lo son.

Se trata de dos conceptos de igualdad diferentes, que tanto los lenguajes como lasbases de datos orientadas a objetos diferencian claramente.

26Por ejemplo, en el lenguaje Java se usa el operador == para comprobar si dos objetos son idénticos, y el método equals() para comprobar si sus valores son iguales.

ODMG: el estándar de facto para modelos de objetos

Propiedades de los objetos

� Cada objeto de una base de datos tiene asignado un valor que expresa sus propiedades y que puedeser actualizado a lo largo del tiempo.

� El valor de un objeto se ajusta a una estructura de datos que puede ser tan compleja como seanecesario.

� Esta estructura de datos se construye a partir de unos tipos de datos básicos por medio de unosconstructores de tipos de datos y de tipos de objetos, que se pueden combinar arbitrariamente.

� Entre los tipos de datos básicos que proporcione un SGBDOO también pueden aparecer tipos dedatos multimedia y texto. En este caso, el sistema también debe proveer las operacionesnecesarias para manipular los valores multimedia y textuales.

� Los SGBDOO más avanzados permiten al usuario definir sus propios tipos de datos básicos consus propias operaciones. Esto hace al sistema muy flexible y capaz de soportar los datos decualquier aplicación.

Constructores de objetos

Referencias entre objetos

Estado de los objetos

27

ODMG: el estándar de facto para modelos de objetosObjetos

Los tipos de objetos se descomponen en en atómicos, colecciones y tipos estructurados.

28

� Constructores de átomos (elementos de los dominios básicos: enteros, reales, cadenas,etc.);

� Constructores de colecciones, que suelen ser tuplas ([…]), conjuntos ({…}) y listas(//…//, set, bag, Array, Dictionary).

� Tipos estructurados (date, time, timestamp, interval, etc.

Las tuplas tienen varios componentes llamados atributos con un nombre y un tipo.

Los conjuntos son un número de 0 o más elementos del mismo tipo y que no se repiten.

Las listas son como los conjuntos pero conservando el orden de inserción.

Los set son un grupo desordenado de objetos del mismo tipo. No se permiten duplicados.

Los bag son un grupo desordenado de objetos del mismo tipo. Se permiten duplicados

Array es un grupo ordenado de objetos del mismo tipo que se pueden acceder por su posición.Su tamaño no es dinámico y los elementos se pueden insertar y borrar de cualquierposición.

Dictionary es como un incidec. Esta formado por claves ordenadas, cada una de ellasemparejadas con un solo valor.

Los objetos se crean utilizando el método new().Los BDOO, como los lenguajes de POO, pueden proporcionar otros tipos de colecciones.

Constructores de objetos

� Los valores de los objetos se construyen a partir de los átomos (valores reales, enteros,cadenas, etc.) y también a partir del conjunto de oid de todos los objetos existentes enla base de datos.

� A la hora de construir los valores, los constructores pueden ser anidados dando lugar avalores con estructuras complejas.

� Por ejemplo …

29

� Los lenguajes de definición de datos orientados a objetos permiten definir lostipos de los datos y los tipos de objetos necesarios para construir los objetos deuna aplicación concreta.

� En los ejemplos utilizaremos lenguaje O2C del SGBDOO O2, donde laspalabras reservadas tuple, set y list permiten definir los tipos tupla, conjunto ylista respectivamente, y para los tipos atómicos asumiremos que estándisponibles los tipos de datos básicos más habituales (integer, string, real...)

30

ODMG: el estándar de facto para modelos de objetos

Literales

� Los tipos literales se descomponen en atómicos, colecciones, estructurados o nulos. Los literales no tienenidentificadores y no pueden aparecer solos como objetos, sino que están embebidos en objetos y no puedenreferenciarse de modo individual. Los literales atómicos son los siguientes:

� boolean : un valor que es verdadero o falso.

� short : un entero con signo, normalmente de 8 o 16 bits.

� long : un entero con signo, normalmente de 32 o 64 bits.

� unsigned short : un entero sin signo, normalmente de 8 o 16 bits.

� unsigned long : un entero sin signo, normalmente de 32 o 64 bits.

� float : un valor real en coma flotante de simple precisión.

� double : un valor real en coma flotante de doble precisión.

� octet : un almac´en de 8 bits.

� char : un carácter ASCII o UNICODE.

� string : una cadena de caracteres.

� enum : un tipo enumerado donde los valores se especifican explícitamente cuando se declara el tipo.

� Los literales estructurados contienen un número fijo de elementos heterogéneos. Cada elemento es un par<nombre, valor> donde valor puede ser cualquier tipo literal. Los tipos estructurados son: date, time,timestamp, interval y struct. Y los tipos colecci´on son: set<tipo>, bag<tipo>, list<tipo>, array<tipo> ydictionary<clave,valor>.

31

ODMG: el estándar de facto para modelos de objetos

Tipos

� Una de las características más importantes del paradigma orientado a objetos es la distinción entre la interfacepública de una clase y sus elementos privados (encapsulación).

� El estándar propuesto hace esta distinción hablando de la especificación externa de un tipo y de susimplementaciones.

� Una interface es una especificación del comportamiento abstracto de un tipo de objeto y contiene las signaturasde las operaciones. Aunque una interface puede tener propiedades (atributos y relaciones) como parte de suespecificación, ´estas no pueden ser heredadas desde la interface. Además, una interface no es instanciable porlo que no se pueden crear objetos a partir de ella (es el equivalente de una clase abstracta en la mayoría de los

lenguajes de programación).

� Una clase es una especificación del comportamiento abstracto y del estado abstracto de un tipo de objeto. Lasclases son instanciables, por lo que a partir de ellas se pueden crea instancias de objetos individuales (es elequivalente a una clase concreta en los lenguajes de programación).

� El estándar propuesto soporta la herencia simple y la herencia múltiple mediante las interfaces. Ya que lasinterfaces no son instanciables, se suelen utilizar para especificar operaciones abstractas que pueden serheredadas por clases o por otras interfaces. A esto se le denomina herencia de comportamiento y se especifica

mediante el símbolo “:”. La herencia de comportamiento requiere que el súpertipo sea una interface, mientrasque el subtipo puede ser una clase o una interface.

32

ODMG: el estándar de facto para modelos de objetos

� La herencia es una relación “es un”:

33

La interface o clase mas baja de la jerarquía es el tipo más específico. Ya que hereda los

comportamientos de todos los tipos que tiene por encima en la jerarquía, es la interface o clasemás completa. (En el ej.: los tipos más específicos son Silla, Mesa y Sofás).Uno de los beneficios prácticos de la herencia es que se puede hacer referencia a los subtiposcomo su supertipo. (Ej.: un programa de aplicación puede hacer referencia a sillas, mesas y sofáscomo muebles o incluso como artículos de venta).Los subtipos se pueden especializar como sea necesario añadiéndoles comportamientos.Los subtipos de un subtipo especializado heredan también los comportamientos añadidos.

El modelo orientado a objetos utiliza la relación extiende (extends) para indicar la herencia deestado y de comportamiento. En este tipo de herencia tanto el subtipo como el súpertipo debenser clases. Las clases que extienden a otra clase ganan acceso a todos lo estados ycomportamientos del súpertipo, incluyendo cualquier cosa que el súpertipo haya adquirido através de la herencia de otras interfaces.Una clase puede extender, como máximo, a otra clase. Sin embargo, si se construye una jerarquíade extensiones, las clases de más abajo en la jerarquía heredan todo lo que sus supertiposheredan de las clases que tienen por encima.

ODMG: el estándar de facto para modelos de objetos

� El modelo permite al diseñador que declare una extensión (extent) para cada tipo de objeto definido como unaclase. La extensión de un tipo tiene un nombre e incluye todas las instancias de objetos persistentes creadas apartir de dicho tipo.

� Una extensión se puede indexar para que el acceso a su contenido sea más rápido.

� Una clase con una extensión puede tener una o más claves (key). Una clave es un identificador único. Cuando unaclave está formada por una sola propiedad, es una clave simple; si está formada por varias propiedades, es una

clave compuesta. A diferencia del modelo relacional, las claves únicas no son un requisito.

� Una implementación de un tipo consta de dos partes: la representación y los métodos.

� La representación es una estructura de datos dependiente de un lenguaje de programación que contiene laspropiedades del tipo. Las especificaciones de la implementación vienen de una conexión con un lenguaje(language binding). Esto quiere decir que la representación interna de un tipo será diferente dependiendo dellenguaje de programación que se utilice y que un mismo tipo puede tener más de una representación.

� Los detalles de las operaciones de un tipo se especifican mediante un conjunto de métodos.

� En la especificación externa de cada operación debe haber al menos un método. Sin embargo, un tipo puedeincluir métodos que nunca se ven desde fuera del tipo. Estos métodos son los que realizan algunas funcionesnecesarias para otros métodos del tipo.

� Los métodos se escribirán en el mismo lenguaje de programación utilizado para expresar la representación deltipo. Si una base de datos soporta aplicaciones programadas en C++, Java y Smalltalk, entonces será necesariotener tres implementaciones para cada tipo, una para cada lenguaje, aunque cada programa de aplicación utilizarásólo la implementación que le corresponda.

34

ODMG: el estándar de facto para modelos de objetos

Propiedades

� El modelo de objetos ODMG define dos tipos de propiedades: atributos y relaciones.

� Un atributo se define del tipo de un objeto. Un atributo no es un objeto de “primera clase”, por lotanto no tiene identificador, pero toma como valor un literal o el identificador de un objeto.

� Las relaciones se definen entre tipos. El modelo actual sólo soporta relaciones binarias concardinalidad 1:1, 1:n y n:m. Una relación no tiene nombre y tampoco es un objeto de “primeraclase”, pero define caminos transversales en la interface de cada dirección. En el lado del muchosde la relación, los objetos pueden estar desordenados (set o bag) u ordenados (list). La integridadde las relaciones la mantiene automáticamente el SGBD y se genera una excepción cuando seintenta atravesar una relación en la que uno de los objetos participantes se ha borrado. El modeloaporta operaciones para formar (form) y eliminar (drop) miembros de una relación.

35

Referencias entre objetos

� Todo atributo de un tipo tiene un dominio asignado, que puede ser un tipo de datos o un tipo deobjetos previamente definidos.

� Como puede verse en el ejemplo anterior, cuando el valor de un atributo es de un tipo de objetos(p.ej. depto), en lugar de asignar al atributo todo el valor, se le asigna el oid del objeto. En ningúncaso se copia el valor del objeto destino (salvo que así se decidiera explícitamente), sino que se usael oid.

� Así, los atributos cuyo dominio sea un tipo de objetos en realidad se implementan como referencias

usando el oid, y representan relaciones entre los objetos. Una relación binaria entre dos objetos sepuede representar en una sola dirección o en ambas direcciones (referencia inversa). Esta última

representación hace más fácil recorrer la relación en ambas direcciones.

36

Estado de los objetos

� El estado de un objeto es el valor que tiene asignado dicho objeto en un momento

determinado.

� Esto significa que cuando las propiedades de un objeto cambian, su valor debe seractualizado en la base de datos, haciendo pasar el objeto a un nuevo estado.

� Como se ha indicado anteriormente, es posible que en algún momento dos objetos noidénticos (con distinto oid) sean iguales (tengan el mismo valor). Es posible definirdistintos conceptos de igualdad entre valores, como veremos con un ejemplo.

37

�La igualdad superficial, que se comprueba comparando los valores del estado, sin seguir referencias.

�La igualdad profunda, que se comprueba comparando los valores del estado, y (recursivamente) los valores de los objetos referenciados.

Comportamiento de los objetos. Retomamos …

� El comportamiento de los objetos se representa por medio de operaciones que seejecutan sobre ellos.

� Toda operación que deba realizarse sobre un objeto tiene que estar previamenteimplementada.

� Las operaciones se usan para crear y eliminar objetos, para cambiar los valores de losatributos de los objetos, para conocer su valor, o para realizar operaciones mucho máscomplejas que pueden involucrar a muchos objetos. (en general, representan lasacciones del mundo real, es decir, representan el comportamiento de los objetos).

� Cada operación tiene una signatura y un método:

� La signatura es la parte pública de la operación;

� el método es un procedimiento implementado en algún lenguaje de programación yque permanece oculto para los usuarios.

� Los métodos que se asocian a cierto objeto pueden acceder directamente a sus atributosy hacer estos contenidos visibles al exterior, pudiendo realizar alguna computaciónprevia sobre ellos.

38

� La ejecución de una operación se conceptualiza como el envío de un mensaje a unobjeto: un mensaje se envía a un determinado objeto, y contiene el nombre de laoperación y los parámetros necesarios para que el método asociado se ejecute.

� El método se ejecuta sobre el objeto que recibe el mensaje.

� Es importante saber que la estructura interna de los objetos (o sea, su valor) puedeocultarse, lo que impide que pueda ser accedida directamente si no es por medio de unmétodo.

� Esta habilidad de esconder los detalles internos de los objetos se denominaencapsulación, y es una de las ventajas más importantes del modelo orientado aobjetos, ya que facilita la manipulación de los objetos desde las aplicaciones, altiempo que asegura su integridad.

39

Clasificación e instanciación de objetos

� Las bases de datos orientadasa objetos clasifican los objetosde acuerdo a sus similitudes.

� Una clase es un conjunto de

objetos que comparten unas

propiedades (tipo de objetos)y un comportamiento(operaciones).

� La instanciación es el proceso

inverso al de la clasificación yconsiste en generar los objetosde una clase.

40

� Cada objeto de la base de datos es instancia de una clase.

� El conjunto de instancias de una clase se denomina su extensión, a la que se

da un nombre explícito mediante la cláusula extent.

� Para crear y eliminar las instancias, toda clase debe disponer de un método decreación (constructor) y otro de eliminación de instancias (destructor).

� El conjunto de operaciones de una clase constituye su aspecto público y sedenomina interfaz o protocolo de acceso. Los cuerpos de los métodos se

implementan aparte utilizando alguno de los lenguajes de programacióndisponibles en el SGBDOO que se esté utilizando.

� Normalmente el SGBDOO está acoplado a un lenguaje de programaciónorientado a objetos para implementar las operaciones de los objetos y lasaplicaciones de las bases de datos.

41

Clasificación e instanciación de objetos

ODMG: el estándar de facto para modelos de objetos

Transacciones

� El modelo estándar soporta el concepto de transacciones, que son unidadeslógicas de trabajo que llevan a la base de datos de un estado consistente a otroestado consistente. El modelo asume una secuencia lineal de transacciones quese ejecutan de modo controlado. La concurrencia se basa en bloqueos estándarde lectura/escritura con un protocolo pesimista de control de concurrencia.Todos los accesos, creación, modificación y borrado de objetos persistentes sedeben realizar dentro de una transacción. El modelo especifica operacionespara iniciar, terminar (commit) y abortar transacciones, así como la operación

de checkpoint. Esta ´ultima operación hace permanentes los cambios realizadospor la transacción en curso sin liberar ninguno de los bloqueos adquiridos.

42

Resumen de conceptos básicos del modelo orientado a objetos

43

Lenguaje de definicion de objetos ODL

ODL es un lenguaje de especificación para definír tipos de objetos para sistemas compatibles conODMG. ODL es el equivalente del DDL (lenguaje de definición de datos) de los SGBD tradicionales.Deíne los atributos y las relaciones entre tipos, y especifíca la signatura de las operaciones. La sintaxisde ODL extiende el lenguaje de definición de interfaces (IDL) de la arquitectura CORBA (CommonObject Request Broker Architecture). El uso de ODL se muestra mediante un ejemplo:

BD ORIENTADAS A OBJETOS 44

Lenguaje de consulta de objetos OQL

� OQL es un lenguaje declarativo del tipo de SQL que permite realizar consultas de modo eficientesobre bases de datos orientadas a objetos, incluyendo primitivas de alto nivel para conjuntos deobjetos y estructuras. Está basado en SQL-92, proporcionando un super conjunto de la sintaxis dela sentencia SELECT.

� OQL no posee primitivas para modificar el estado de los objetos ya que las modificaciones sepueden realizar mediante los métodos que éstos poseen.

� La sintaxis básica de OQL es una estructura SELECT...FROM...WHERE..., como en SQL.

� Por ejemplo, la siguiente expresión obtiene los nombres de los departamentos de la escuela de‘Ingeniería’:

45

Diseño lógico de bases de datos orientadas a objetos

� Para diseñar BDOO hay que identificar las clases de objetos quese necesitan, así como el tipo y las operaciones de cada clase.

� Para definir el tipo de los objetos de una clase, primero hay queidentificar qué relaciones se dan entre las clases.

� Agregación y asociación

� Generalización, especialización y herencia

� Polimorfismo de métodos

� Diseño lógico de una BDOO

46

Agregación y asociación

� Los objetos agregados son aquellos que se componen de otros objetos.

� La agregación es un tipo de relación que permite relacionar objetos agregados con susobjetos componentes (relación todo/parte).

� Representar al objeto agregado puede ser especialmente útil cuando el propio objetoagregado se debe relacionar con otros objetos, o viceversa, cuando alguno de losobjetos componentes se debe relacionar con otro objeto.

� En los esquemas conceptuales de la base de datos, la relación entre un objeto y suscomponentes siempre se denota con se_compone_de y dibujaremos flechas que vayandesde el objeto agregado hacia los componentes.

� En una jerarquía de agregación un objeto agregado se puede componer de variosobjetos componentes, pero un objeto componente solo puede formar parte de un objetoagregado.

47

48

Agregación y asociación

� La relación de asociación sirve para relacionar objetos de varias clases

independientes.

� En el esquema conceptual de la base de datos a este tipo de relaciones se

� las denomina con un nombre y una cardinalidad que reflejen su significado.

49

Agregación y asociación

� En cierta manera la agregación es un tipo especial de asociación.

� La diferencia principal entre ellas es que cuando se elimina un objeto que participa enuna relación de asociación, los otros objetos relacionados siguen existiendo. Sinembargo, en el caso de la agregación, la inserción/eliminación del objeto agregadoequivale a insertar/eliminar sus objetos componentes. Similarmente, un objeto queforma parte de otro no puede ser insertado ni eliminado de la base de datosindividualmente.

� Lógicamente, un objeto componente nada más puede formar parte de un objetocompuesto.

� Al realizar el diseño lógico de una BDOO, cuando se definen los tipos de los objetos deuna clase, las relaciones de asociación y de agregación se representan por medio dereferencias en una o ambas direcciones, y de acuerdo a su carnalidad asociada. Enalgunos SGBDOO es posible diferenciar en el esquema las relaciones de agregación delas de asociación. En nuestro caso, las representamos de la misma forma.

50

Generalización, especialización y herencia

� Una clase sirve para organizar un conjunto de objetos similares.

� Sin embargo, en muchas ocasiones los objetos de una clase pueden reorganizarse, formandovarios grupos que también pueden tener interés para la base de datos.

� Los objetos de la clase empleado pueden clasificarse en distintos tipos (Ej.: secretarios,ingenieros, gerentes y técnicos).

� Cada una de estas agrupaciones es una subclase de la clase empleado, y empleado es unasuperclase de las otras cuatro clases.

� Este tipo de relación se denomina generalización, o especialización a la inversa, y en elesquema conceptual se representa con una relación denominada es_un y unas flechas que vandesde las subclases hacia las superclase.

51

52

El resultado de ejecutar este código es el siguiente:

truetrue

mostrando que los secretarios y los gerentes están incluidos en la extensión de los empleados.

� Cuando el mecanismo de especialización se aplica sucesivamente en varios niveles de clases se crea una jerarquía de

especialización .

� Una importante característica de las jerarquías de especialización es el de la herencia de tipos y operaciones desde las superclaseshacia las subclases.

� Por esta razón, a la hora de hacer el diseño lógico, la definición del tipo y de las operaciones de una subclase incluye de maneraimplícita a todas las definiciones hechas para la superclase más aquellas nuevas definiciones (nuevos atributos y nuevasoperaciones) explícitas que quieran hacerse.

� Existen dos tipos de herencia: simple y múltiple:

� La herencia simple ocurre cuando cada clase en una jerarquía tiene una sola superclase inmediata. Si se envía un mensaje aun objeto de una clase en una jerarquía con herencia simple, el método asociado se busca primero en la clase y luego en susuperclase inmediata, y así sucesivamente hacia arriba en la jerarquía.

� La herencia múltiple ocurre cuando una subclase tiene varias superclases inmediatas. En este caso se heredan los tipos y lasoperaciones de todas las superclases, por lo que pueden surgir colisiones con los nombres de los atributos y de los mensajes.En ese caso se produciría un error.

53

Polimorfismo de métodos

� Otra característica de las BDOO es que hacen posible el polimorfismo de los

métodos.

� Este concepto permite asignar a una misma operación dos o más implementacionesdiferentes, con el propósito de que en cada caso se ejecute una de ellas, dependiendode la clase de los objetos a los que se aplique.

� Aunque no siempre es un requerimiento necesario, lo normal es que las distintasclases formen parte de una jerarquía de especialización a través de la cual se heredael método que va a ser redefinido.

54

define object type Objeto_Geometrico

type

forma: string

operations

area(): real;

define object type Rectangulo inherit Objeto_Geometrico

Type

tuple [ ancho: real,

alto: real]

operations

es_cuadrado?(): bool;

define object type Triangulo inherit Objeto_Geometrico

type

tuple [ lado_1: real,

lado_2: real,

angulo: real]

operations

es_equilatero?(): bool;

define object type Circulo inherit Objeto_Geometrico

type

radio: real;

55

Diseño lógico de una BDOO

� Paso 1: Crear una clase de objetos para cada entidad del esquema.

� El tipo de objetos de la clase deberá agrupar todos los atributos de laentidad por medio de un constructor de tupla.

� Los atributos multivaluados se declaran a través de un constructor detipo conjunto, o lista si están ordenados.

� Los atributos complejos se declaran por medio de un constructor detupla.

� Todos los tipos y, sobre todo, aquellos tipos de datos que se utilicen envarias clases se pueden definir como tipos de datos aparte.

� Todas las clases deben tener una extensión (cláusula extent) definida.

56

Diseño lógico de una BDOO

� Paso 2: Aquellas clases que son subclases de otras deberán tener unacláusula inherit para indicarlo.

Cada subclase hereda de forma automática el tipo y las operaciones de susuperclase inmediata. Solo hay que especificar los atributos y operacionesespecíficos de la subclase.

57

Diseño lógico de una BDOO

� Paso 3: Para cada relación de asociación y agregación en las que participe unaclase:

� Añadir atributos para referenciar las clases que participen en la relación.

� Las referencias pueden definirse en una dirección o en ambas, aunque suele sermás eficiente definirlas en ambas.

� Normalmente se añade atributos con referencias a las dos clases relacionadas,excepto en las relaciones de cardinalidad (0,1) que dependerá de cada caso aanalizar.

� Los atributos serán monovaluados para las relaciones de cardinalidad (1,1), ymultivaluados (atributos de tipo conjunto o lista) para los de cardinalidad (1,n).

� Si una relación se representa con referencias en ambas direcciones se debedeclarar que cada referencia es la inversa de la otra (cláusula inverse).

� Si hay alguna relación con atributos, hay que usar un constructor de tupla pararepresentarlo de la siguiente manera

tuple[referencia con cláusula inverse, atributos de la relación]

� Esta tupla se incluye en el atributo de referencia.

58

Diseño lógico de una BDOO

� Paso 4: Incluir métodos apropiados para cada clase.

� Estos no estarán disponibles en el esquema conceptual y se deberánagregar al diseño de la base de datos según se necesiten.

� Al final, toda clase debe incluir un método constructor y otrodestructor para sus instancias.

59

Consultas en bases de datos orientadas a objetos

� Se han propuesto diferentes lenguajes más o menos expresivos y fáciles deutilizar.

� No existe ningún lenguaje estándar oficial.

� EL Object Query Language (OQL) ha sido diseñado por un consorcio decompañías de software denominado odmg (Object Data Management Group).

� Hoy día, el estándar está mantenido por la organización omg, dedicada a laestandarización de las tecnologías orientadas a objetos.

� El lenguaje oql cuenta con una estructura select...from...where... similar a lade sql.

60

Puntos de acceso y variables iterador

� La cláusula from de cada consulta debe incluir un punto de acceso a la base de datos que puede sercualquier objeto persistente con nombre específico. Normalmente, el punto de acceso será el nombre de lacolección persistente asociada a una de las clases involucradas en la consulta.

� Hay que considerar que el nombre de una colección (cláusula extent) se corresponde con el nombre de unobjeto persistente cuyo tipo es un conjunto de objetos de una clase. Por esta razón al escoger el nombre deuna colección como punto de acceso a la base de datos estamos haciendo referencia a un conjunto deobjetos persistentes que pueden ser recuperados si cumplen las condiciones de la consulta.

� Lo más recomendable es acceder a la base de datos por la colección de aquella clase sobre la que lascondiciones de la consulta (claúsula where) establezcan condiciones más restrictivas. De esta manera elresto de condiciones de la consulta se tienen que evaluar para un menor número de objetos, y la consulta seejecuta mucho más eficientemente.

� Dentro de claúsula from de una consulta siempre que se haga referencia a un conjunto (o lista) de objetoses necesario definir una variable iterador que toma un valor por cada objeto de la colección (en el ejemploanterior d es la variable iterador). Esta variable se puede utilizar para poner condiciones sobre los objetos ypara acceder a otros objetos de la base de datos como veremos en la siguiente sección.

� El resultado de una consulta siempre es un conjunto de objetos que, a menos que se utilice la cláusuladistinct, podrá contener elementos repetidos. El tipo de estos elementos se deduce de lo que se especifiqueen la cláusula select. En general, el resultado de una consulta puede ser de cualquiera de los tipos quepodamos definir con los constructores de tipos disponibles. En el ejemplo anterior, dado que el atributonombre de la clase departamento es de tipo string, el resultado de la consulta será de tipo set(string).

61

Caminos de acceso

� Los caminos de acceso o trayectorias además de permitir referirse a los

componentes de los objetos complejos, pueden ser utilizados para navegarentre los objetos a través de sus relaciones de agregación y asociación. Deesta manera, si obj es un objeto que tiene el atributo att, entonces obj.att

denota el valor del atributo para ese objeto concreto.

� Alternativamente, si meth es un método de la clase a la que obj pertenece,entonces obj.meth() denota el valor resultante de aplicar al objeto obj elmétodo dado. Esta manera de especificar los caminos de acceso se denominanotación de punto.

� Ej.: e.estudia.nombre donde e es un objeto de la clase Estudiante, primerose localiza al departamento relacionado con el estudiante e a través de suatributo estudia y luego se recupera el atributo nombre de dichodepartamento.

62

Caminos de acceso

� Las variables iterador que aparecen después de los caminos de acceso denotan losvalores que se almacenan en los atributos donde estas terminan.

� Sin embargo, hay que tener en cuenta que cuando una referencia es multivaluada nose puede usar la notación de punto directamente. En este caso es preciso intercalaruna nueva variable iterador, como se ha hecho en los siguientes caminos de accesoque empiezan en la clase Profesor:

63

Otros ejemplos de caminos de acceso sobre las clases Persona y Estudiante de la base de datos anterior son las siguientes:

Dado que las referencias se implementan almacenando el oid de los objetos relacionados, se puede decir que los caminos de acceso sustituyen a los joins de las BDR.

En resumen… al consultar una BDOO no se deben especificar relaciones de join entre sus clases, sino que se deben

utilizar variables iterador y caminos de acceso como las que se muestran en los ejemplos anteriores.

Lenguaje de consulta

� La estructura básica de oql es select...from...where..., similar a la de sql, perocon la diferencia de que es posible usar caminos de acceso dentro de laconsulta para referirse a los componentes de los objetos complejos y parapasar de unos objetos a otros relacionados.

� En una consulta, la cláusula select define los datos que se desean conocer yel tipo de los datos del resultado de la consulta.

� La cláusula from especifica las extensiones de objetos por los que se accedea la base de datos y proporciona las variables iterador que toman comovalores los objetos de dichas colecciones. Estas variables pueden utilizarseen el resto de cláusulas de la consulta.

� La cláusula where especifica las condiciones para seleccionar los objetosindividuales que intervienen en el resultado de la consulta.

64

Lenguaje de consulta

Algunos ejemplos de consultas sobre la base de datos anterior:

� Para conocer los distintos salarios que tienen los profesores de la base de

datos. Se obtendrá un conjunto de números reales diferentes.

� Para conocer los distintos salarios que hay para cada sexo. En este casose obtiene como resultado un conjunto de tuplas diferentes entre sí, dondecada tupla se compone del salario y sexo de un profesor de la extensiónProfesores. Es decir, el resultado de la consulta será un valor del tiposet(tuple[salario:real, sexo:char]).

� Las colecciones de la cláusula from también pueden especificarse por

medio de caminos de acceso. Por ejemplo, para conocer el nombre de lasasignaturas del año 2010 de que cada estudiante se ha examinado se puedeescribir una de las dos consultas siguientes.

La diferencia entre las dos consultas es su punto de acceso a la base dedatos, siendo más rápida la segunda versión ya que accede a la base dedatos por la misma clase por la que se ponen las condiciones del where,además de que en la base de datos hay muchos más estudiantes queasignaturas.

65

Lenguaje de consulta

� Veamos esto por medio de otro ejemplo. Supongamos que se deseanconocer los números del dni de aquellos estudiantes matriculados enalguna asignatura impartida por un profesor de Rosario.

Para evaluar esta consulta podríamos elegir entre las dos opcionessiguientes:

66

select distinct e.dnifrom Estudiantes e, e.examinado_de a, a.asignatura.profesor pwhere p.direccion.ciudad = ’Rosario’

select distinct e.estudiante.dnifrom Profesores p, p.imparte a, a.examinados ewhere p.direccion.ciudad = ’Rosario’

La diferencia entre cada una de las opciones es su tiempo de ejecución.

Accediendo a la base de datos por la extensión Estudiantes, los dos caminos de acceso del fromse tendrán que evaluar para cada estudiante de la base de datos, ya que sobre los estudiantes no sepone ninguna restricción.Sin embargo accediendo por la extensión de Profesores, los dos caminos de acceso se tienen queevaluar para un menor número de objetos, ya que lo normal es que en la base de datos hayamuchos menos profesores de Sagunto que estudiantes. Por lo tanto, la segunda opción seevaluará mucho más rápidamente que la primera.

Lenguaje de consulta

� En la cláusula where se puede especificar cualquier condición sobre los objetosdenotados por las variables de la cláusula from.

� Por ejemplo, si solamente se está interesado en aquellos estudiantes que cursen sucarrera en el departamento de informática y que estén examinados en más de 5ocasiones …

67

Esta consulta devolverá un conjunto de objetos de la clase estudiante.Muestra cómo se puede utilizar la función count para saber cuántos valores sealmacenan en el atributo examinado_de.Esta misma función se puede utilizar para saber cuántos oid se almacenan en unatributo que representa una referencia 1:N.

Lenguaje de consulta

� En la especificación de condiciones también se pueden invocar métodos para conocerlas propiedades de los objetos a recuperar.

� Por ejemplo, la siguiente consulta recupera los estudiantes cuya media de notas hastael momento supere el 7.

68

�También se pueden definir condiciones entre los atributos siempre que sean del mismotipo. Por ejemplo, podemos buscar parejas estudiante/profesor que cumplan años elmismo día:

Lenguaje de consulta

� Para obtener los resultados ordenados existe la cláusula order by. Por ejemplo, sepueden recuperar los profesores ordenados por su sueldo y por su primer apellido.

69

� También se pueden agrupar los resultados de una consulta según algún criterio de losobjetos recuperados. Por ejemplo, la siguiente consulta cuenta los profesores quepertenecen al departamento de informática agrupados según la ciudad donde viven.

� Como siempre accedemos a la base de datos por la clase sobre la que se ponen lascondiciones del where. La palabra clave partition sirve para denotar cada uno de losgrupos que se forman al procesar la consulta. En este caso la función count cuentacuantos elementos hay en cada partición, o sea en cada grupo formado por el criteriop.direccion.ciudad.

Lenguaje de consulta

� Algunos atributos almacenan conjuntos o listas de valores u objetos diferentes entresí. Se puede comprobar si todos los valores almacenados en un atributo de un objetocumplen una condición, o si solamente alguno de ellos lo hace.

70

� La primera consulta recupera los cursos con todas sus asignaturas en el año 2010, y lasegunda, los estudiantes con alguna matrícula de honor entre sus notas. Esta últimaconsulta sería equivalente a:

Lenguaje de consulta

� También están disponibles las funciones de agregación similares a las de sql: avg,count, sum, min y max. Por ejemplo, para conocer la media de edad de todos losestudiantes se puede ejecutar la sentencia siguiente:

71

� El resultado de una consulta puede ser asignado a un identificador para poder ser utilizado enotras consultas. Por ejemplo, se puede crear una colección de objetos de la clase Profesor queincluye a los mejor pagados utilizando la siguiente consulta:

Ahora es posible conocer el rango de salarios de los profesores mejor pagados de la siguienteforma:

Lenguaje de consulta

� Si se deseara conocer el nombre de los profesores con mayor salario tendríamos queutilizar una subconsulta de la siguiente forma:

72

� Otro ejemplo de consulta es la siguiente, que devuelve un conjunto de tuplas con los detalles de lasnotas de cada estudiante del grupo ig2:

Diseño físico de bases de datos orientadas a objetos

Al igual que en las BDR, el modelo lógico de datos de las BDOO esindependiente de la localización física de los datos. Los datos tambiénse almacenan en ficheros emplazados en diferentes dispositivos físicosque el administrador de la base de datos tiene que gestionar.

Muchos de los conceptos de diseño físico de BDR se pueden aplicar paralas BDOO. Sin embargo, hay ciertos cambios en la forma en que serealizan los agrupamientos y los índices de acceso a los datos, quedeben ser estudiados.

73

Índices

Los principales tipos de estructuras de indexación que podemos encontrar en las BDOO son:

� Índices de atributos. Se usan para indexar los objetos de una clase según alguno de sus atributos.De esta manera se pueden recuperar rápidamente los objetos de una clase que cumplen ciertapropiedad sobre el atributo indexado. (Ej.: indexar los objetos de la clase Empleados por suatributo dni).

� Índices de objetos. Se usan para indexar los objetos de una clase según su oid. Este índicecontiene una entrada con el oid de cada objeto de la clase, y un puntero a su dirección dememoria. Esta alternativa resulta muy útil para navegar por los objetos ya que para pasar de unobjeto de una clase a otro que referencia desde alguno de sus atributos se utiliza el índice.

� Índices de trayectoria. En este caso el índice para una trayectoria dada consiste en una tabla contantas columnas como componentes haya en la trayectoria o camino de acceso. La tabla contieneuna fila por cada combinación de oid que determinen una ocurrencia de dicho camino dentro de labase de datos.

� Por ejemplo, supongamos la siguiente trayectoria…

• p.imparte a, a.examinados e, e.estudiante.estudia d

que indica los departamentos (d) en los que estudian los estudiantes (e) examinados de lasasignaturas (a) de cada profesor

(p). Supongamos también que esta trayectoria es muy importante y que tiene que ejecutarse lomás rápidamente posible.

74

Índices

� Definiendo un índice sobre este camino de acceso, podríamos tener la tabla derelaciones entre los profesores, las asignaturas, los estudiantes y losdepartamentos almacenados en la base de datos.

75

Para ejecutar la trayectoria desde una consulta, no será necesario acceder a la base de datos yrecuperar el gran número de objetos por los que pasa.Por ejemplo, para conocer el departamento de los estudiantes a los que da clase el profesorcon oid oid.P4, leyendo las filas de este índice se puede saber que solamente hay querecuperar los departamentos con oid oid.D1 y oid.D5.

Agrupamientos

Las técnicas de agrupamiento se utilizan para posicionar los objetos en memoria secundaria enposiciones contiguas, de forma que el proceso de recuperación se acelere. Generalmente, en bdoose pueden utilizar los siguientes tipos de agrupamientos:

76

Por clases. Este suele ser el modo de posicionamiento por defecto. Todos los objetos de una clasese almacenan contiguos. Estos pueden incluir a los objetos de otras clases que seanespecializaciones suyas (subclases). De esta manera, cuando se tiene una jerarquía deespecialización simple expresada en forma de árbol cuyos nodos son las clases de la jerarquía, losobjetos de las diferentes clases se almacenan según el orden definido por el recorrido en preordende los nodos del árbol.Por valores de los atributos. Los objetos de una clase se agrupan por el valor de alguno de susatributos. Por ejemplo, los objetos de la clase estudiante se pueden almacenar ordenados porapellidos. Si se combina este método con un índice sobre el mismo atributo, entonces laevaluación de las consultas que involucren a dicho atributo se puede ver muy favorecida.Por relaciones de asociación. Aquellos objetos que se relacionen con otros referenciándolosdesde alguno de sus atributos, se almacenan de forma contigua en el mismo bloque de memoria,por lo que ambos objetos se recuperan al mismo tiempo. De esta manera, la recuperación deobjetos que se relacionan con otros objetos se acelera mucho, ya que todos ellos se recuperan enunas pocas operaciones de lectura. Por ejemplo, se puede recuperar rápidamente el objeto de undepartamento junto con los objetos de todos sus profesores.Por relaciones de agregación. Aquellos objetos que se componen de otros objetos se puedenalmacenar de manera que los componentes se agrupan incrustados en los compuestos. De estaforma, con pocos accesos al disco es fácil recuperar un objeto junto con sus componentes.

Ejemplo de diseño de una BDOO

77

78

79

Vamos a terminar el ejemplo de base de datos con una propuesta de implementación para el método edad() de la clase Persona.

80

ESTÁNDAR CORBA PARA OBJETOSDISTRIBUIDOS

81

ESTÁNDAR CORBA PARA OBJETOSDISTRIBUIDOS� ¿QUÉ ES CORBA?

� CORBA: COMMON OBJECT REQUEST BROKER ARCHITECTURE.

� ES UNA HERRAMIENTA QUE FACILITA EL DESARROLLO DEAPLICACIONES DISTRIBUIDAS EN ENTORNOSHETEROGÉNEOS (HW Y SW).

� DISTINTOS SISTEMAS OPERATIVOS (UNIX, WINDOWS,MACOS, OS/2).

� DISTINTOS PROTOCOLOS DE COMUNICACIÓN (TCP/IP,IPX, …).

� DISTINTOS LENGUAJES DE PROGRAMACIÓN (JAVA, C,C++, …).

� DEFINE LA INFRAESTRUCTURA PARA LA ARQUITECTURAOMA (OBJECT MANAGEMENT ARCHITECTURE):

� ESPECIFICA LOS ENTÁNDARES NECESARIOS PARA LAINVOCACIÓN DE MÉTODOS SOBRE OBJETOS EN ENTORNOSHETEROGÉNEOS.

82

ESTÁNDAR CORBA PARA OBJETOSDISTRIBUIDOS� ¿PARA QUÉ SIRVE?

� PERMITIR INVOCACIÓN DE MÉTODOS DE UN OBJETO POROBJETOS QUE RESIDEN EN DIFERENTES MÁQUINAS ENENTORNOS HETEROGÉNEOS:

� LOS OBJETOS PUEDEN ESTAR DESARROLLADOS ENDIFERENTES LENGUAJES.

� LOS EQUIPOS PUEDEN TENER DIFERENTE:

� HARDWARE.

� SISTEMA OPERATIVO.

� LOS EQUIPOS PUEDEN ESTAR CONECTADOS ENTRE SÍUSANDO DISTINTOS PROTOCOLOS DE COMUNICACIÓN.

� FACILITAR EL DESARROLLO DE APLICACIONES DISTRIBUIDAS.

83

ESTÁNDAR CORBA PARA OBJETOSDISTRIBUIDOS� HISTORIA

� OMG (OBJECT MANAGEMENT GROUP):

� CONSORCIO CREADO EN 1989, PRIMER “PRODUCTO”: CORBA.

� INICIALMENTE 8 EMPRESAS (SUN, HP, 3COM,...):

� HOY: MÁS DE 800 SOCIOS:

• PROVEEDORES DE SW Y EQUIPOS, OPERADORES DETELECOMUNICACIONES, EMPRESAS,UNIVERSIDADES,...

� HTTP://WWW.OMG.ORG/

� OMA (OBJECT MANAGEMENT ARCHICTECTURE):

� INICIAL: 1990.

� CORBA (COMMON OBJECT REQUEST BROKERARQUITECTURE):

� CORBA 1: 1991.

� CORBA 2: 1995.

� CORBA 3: 2002.

84

ESTÁNDAR CORBA PARA OBJETOSDISTRIBUIDOS� CARACTERÍSTICAS

� ORIENTADO A OBJETOS:

� ENCAPSULACIÓN.

� HERENCIA.

� LATE BINDING & POLIMORFISMO.

85

ESTÁNDAR CORBA PARA OBJETOSDISTRIBUIDOS� COMUNICACIÓN POR INVOCACIÓN DE MÉTODOS REMOTOS:

� MÁS FÁCIL DE PROGRAMAR QUE IPC, SOCKETS, RPC, ETC.

� STUB:

� REPRESENTANTE LOCAL DEL OBJETO REMOTO.

� ENCARGADO DE LA COMUNICACIÓN CON EL OBJETOREMOTO.

� SKELETON:

� ENCARGADO DE LA COMUNICACIÓN CON EL CLIENTE.

� CLIENTE-SERVIDOR DE GRANO FINO:

� INTERACCIONES SON DE TIPO CLIENTE-SERVIDOR.

� PAPELES: MISMA ENTIDAD PUEDE ACTUAR COMOCLIENTE O SERVIDOR.

86

ESTÁNDAR CORBA PARA OBJETOSDISTRIBUIDOS

� SEPARACIÓN INTERFAZ-IMPLEMENTACIÓN:

� LA INTERFAZ DEFINE UN CONTRATO.

� CORBA IDL (INTERFACE DEFINITION LANGUAGE)

� MULTI-LENGUAJE: MAPEO IDL → LENGUAJES DEPROGRAMACIÓN.

� REFERENCIA DE OBJETO: IDENTIFICADOR ÚNICO DE UNOBJETO:

� COMO UN PUNTERO:

• PUEDE SER NIL: NO APUNTA A NINGÚN OBJETO.

• PUEDE ESTAR COLGANDO: APUNTA A UN OBJETOINALCANZABLE O QUE NO EXISTE.

� PUEDE SER TRANSIENT O PERSISTENT.

� PUEDE CONVERTIRSE ENTRE FORMA INTERNAY FORMACADENA.

� CORBA 2 IOR (INTEROPERABLE OBJECT REFERENCE):

� PARA EVITAR CONFLICTOS ENTRE IMPLEMENTACIONESDE DIFERENTES VENDEDORES.

87

ESTÁNDAR CORBA PARA OBJETOSDISTRIBUIDOS

� PROTOCOLO ESTÁNDAR:

� IIOP: INTERNET INTER-ORB PROTOCOL(IMPLEMENTACIÓN DEL GIOP).

� IMPLEMENTADO ENCIMA DE TCP/IP.

� MODOS DE COMUNICACIÓN:

� SÍNCRONA:

• INVOCACIÓN DE MÉTODOS REMOTOS NORMAL.

• REPUESTA PUEDE SER DE TIPO VOID.

� ASÍNCRONA:

• INVOCACIÓN DE MÉTODOS DEFINIDOS COMOONEWAY.

• CORBA 3: AÑADE SERVICIO DE MENSAJERÍA (PATRÓNPUBLISHER-SUBSCRIBER).

� USO DE ENVOLTURAS (WRAPPERS):

� PERMITE INTEGRAR LOS SISTEMAS HEREDADOS.

� NORMALMENTE, UNA SOLA INSTANCIA DE CADA CLASE.

88

ESTÁNDAR CORBA PARA OBJETOSDISTRIBUIDOS

� ORB (OBJECT REQUEST BROKER):

� NÚCLEO DE CORBA: UN BUS DE SOFTWARE.

� OCULTA LA HETEROGENEIDAD A LAS DOS PARTES.

� OCULTA LOS DETALLES DE LA COMUNICACIÓN A LASDOS PARTES.

� PROPORCIONA TRANSPARENCIA DE LOCALIZACIÓN VIAREFERENCIAS DE OBJETO:

• INTERPRETA LAS REFERENCIAS DE OBJETO.

• CANALIZA LAS INVOCACIONES DEL CLIENTE ALOBJETO REMOTO CORRECTO.

• CANALIZA LAS RESPUESTAS DEL OBJETO REMOTO ALCLIENTE.

89

ESTÁNDAR CORBA PARA OBJETOSDISTRIBUIDOS

� PROPORCIONA TRANSPARENCIA DE DISTRIBUCIÓN:

• COMPORTAMIENTO IGUAL EN CENTRALIZADO ODISTRIBUIDO.

� SE OCUPA DE LA ACTIVACIÓN Y DESACTIVACIÓN DEOBJETOS.

� PROPORCIONA SERVICIOS PARA CONSTRUIR PETICIONESDINÁMICAMENTE.

90

ESTÁNDAR CORBA PARA OBJETOSDISTRIBUIDOS� ¿CÓMO FUNCIONA?

� EL SERVIDOR:

� CREA OBJETOS REMOTOS.

� HACE ACCESIBLES REFERENCIAS A OBJETOS REMOTOS.

� ESPERA A QUE LOS CLIENTES INVOQUEN A ESTOSOBJETOS REMOTOS O A SUS MÉTODOS.

� EL CLIENTE:

� OBTIENE UNA REFERENCIA DE UNO O MÁS OBJETOSREMOTOS EN EL SERVIDOR.

� INVOCA A SUS MÉTODOS.

BD ORIENTADAS A OBJETOS 91

ESTÁNDAR CORBA PARA OBJETOSDISTRIBUIDOS� ELEMENTOS DE LA ARQUITECTURA

BD ORIENTADAS A OBJETOS 92

ESTÁNDAR CORBA PARA OBJETOSDISTRIBUIDOS� ¿CÓMO SE REALIZA LA INVOCACIÓN?

BD ORIENTADAS A OBJETOS 93

ESTÁNDAR CORBA PARA OBJETOSDISTRIBUIDOS� ¿CÓMO SE RECIBE LA PETICIÓN?

BD ORIENTADAS A OBJETOS 94

ESTÁNDAR CORBA PARA OBJETOSDISTRIBUIDOS� ¿CÓMO SE USA?

cliente

95

ESTÁNDAR CORBA PARA OBJETOSDISTRIBUIDOS� OBJECT MANAGEMENT ARCHITECTURE

� MODELO DE OBJETOS

� UN SISTEMA DE OBJETOS DE SERVICIOS A CLIENTES:

� CLIENTE: ENTIDAD CAPAZ DE HACER PETICIÓNDE UNSERVICIO (A UN OBJETO).

� OBJETO: ENTIDAD IDENTIFICABLE Y ENCAPSULABLEQUE DASERVICIOS.

� PETICIÓN: EVENTO QUE TIENE ASOCIADO OPERACIÓN,PARÁMETROS, TARGET OBJECT, CONTEXTO:

� FORMATO DE UNA PETICIÓN SE DEFINE POR:

• UN LENGUAJE DE “BINDING”.

• POR UNA LLAMADA DE INVOCACIÓN DINÁMICA.

� REFERENCIA DE UN OBJETO: NOMBRE QUE DENOTA A UNOBJETO EN PARTICULAR.

� PARÁMETROS: IDENTIFICADOS POR POSICIÓN (PUEDEN SERDE TIPO ENTRADA, SALIDA O ENTRADA-SALIDA).

96

ESTÁNDAR CORBA PARA OBJETOSDISTRIBUIDOS� OBJECT MANAGEMENT ARCHITECTURE

� ARQUITECTURA DEL MODELO DE REFERENCIA:

97

ESTÁNDAR CORBA PARA OBJETOSDISTRIBUIDOS� ARQUITECTURA CORBA

98

ESTÁNDAR CORBA PARA OBJETOSDISTRIBUIDOS� ADAPTADORES DE OBJETOS ESTANDARIZADOS

� BASIC OBJECT ADAPTER (BOA, 1990):

� SUB-ESPECIFICADO ⇒ EL API OFRECIDO DEPENDE DELVENDEDOR DEL ORB.

� PORTABLE OBJECT ADAPTER (POA, 1998):

� PROPÓSITO PRINCIPAL: PORTABILIDAD:

• CÓDIGO DEL SERVIDOR INDEPENDIENTE DE LAIMPLEMENTACIÓN DEL ORB.

� ESTÁNDARIZA UN CONTROL MÁS FINO DEL ENTORNO DEEJECUCIÓN DEL SERVIDOR:

• ACERCAR EL ADAPTADOR DE OBJETOS A LA NOCIÓNDE CONTENEDOR.

Bibliografía

� A. De Miguel, M. Piattini. Fundamentos y Modelos de las Bases de Datos. 2ªedición. Madrid. Editorial Ra-Ma/México y Colombia, AlfaOmega GrupoEditor. 1999. ISBN 978-84-78-97361-3.

� Maria Jose Aramburu Cabo. Bases de Datos Avanzada. Universitat Jaumi.ISBN: 978-84-695-6769-2.

� Atkinson, M. et al. (1989): The Object-Oriented Database System Manifesto,

Proceedings of 1st International Conference on Deductive and Object-OrientedDatabases.

� Cattell, R. et al. (2000): The Object Data Standard: odmg 3.0, Morgan

Kaufmann.

� Harrington, J. (2000): Object Oriented Database Design Clearly Explained,

� Morgan Kaufmann. Silberschatz, A., Korth, H., Sudarshan, S. (2002):Fundamentos de Bases de Datos, (4.a edición), McGraw Hill.

99

Links

� https://www.youtube.com/watch?v=137ZK8_VU5k

� https://www.youtube.com/watch?v=yTI1TEiCJyI

� https://www.youtube.com/watch?v=J1nZRoYCkJc

� https://www.youtube.com/watch?v=VJTcfe9S2Yg

� https://es.slideshare.net/miriammeza1/db4objects

100