BASES DE DATOS AVANZADAS Tema 3, parte b. Univ. Cantabria Fac. de Ciencias

(1)

BASES DE DATOS AVANZADAS

Tema 3, parte b

Modelo de Objetos Modelo de Objetos

Objetos Puro

Univ. Cantabria – Fac. de Ciencias

Francisco Ruiz, Marta Zorrilla

(2)

Objetivos

•

Presentar la tecnología de bases de datos OO.

•

Conocer el estándar ODMG 3.0.

•

Mostrar las diferencias con respecto a la tecnología OR.

•

Matisse: un ejemplo de SGBD-OO

•

Matisse: un ejemplo de SGBD-OO

(3)

Contenido

•

Bases de Datos Orientadas a Objetos Puras

•

^{ODMG 3.0}

Modelo de Objetos

^ODL

^OQL

•

SGBD Objeto-Relacionales vs Orientados a Objetos

(4)

Bibliografía

•

^Básica

Piattini et al. (2006): Tecnología y Diseño de Bases de Datos.

Cap. 19.

Connolly y Begg (2005): Sistemas de Bases de Datos.

Caps. 27.

•

Complementaria

Elmasri y Navathe (2007): Fundamentos de Sistemas de Bases de Datos.

Caps. 21.

(5)

Introducción

•

^SGBD-R

Modelo de datos sencillo. Arquitectura en 3 niveles (programas y datos separados)

Bases teóricas sólidas:

Relaciones n-arias R ⊆D1x D2 x ... x Dn.

Soporte matemático: álgebra y cálculo relacional.

Dependencias funcionales (semántica de la relación).

Tecnología madura:

Optimización de consultas

Indexación

Administración de la concurrencia y de transacciones (ACID).

Seguridad en el funcionamiento: recuperación.

Lenguaje estándar SQL ( SQL 2003)

(6)

Introducción

•

Pero .... sólo adecuados para aplicaciones tradicionales de BD.

•

En la actualidad, hay nuevas necesidades: gestión sistemas

multimedia, sistemas de información médica o sistemas GIS que requieren manipular información más compleja.

•

^Problemas:

1) Convertir objetos y relaciones al modelo relacional supone descomponer los objetos en gran número de tablas → errores, descomponer los objetos en gran número de tablas → errores,

y por otra parte gran número de joins para su recuperación→ rendimiento

Solución: SGBD relacionales de objetos

2) Otro problema es que los modelos de datos y las estructuras de datos de los lenguajes de programación está desacoplados

Solución: SGBDOO y lenguajes OO siguen el mismo paradigma.

Datos + comportamiento. Lenguaje OQL.

(7)

MANIFIESTO DE LOS SGBD-OO

ATKINSON et al. (1989)

Reglas de oro:

1. Objetos complejos: Construcción de objetos complejos aplicando constructores sobre objetos básicos (set, tuple, list, array,…).

2. Identidad de objetos: cada objeto se identifica por su OID, independiente del valor de sus atributos.

BD Orientadas a Objetos Puras

valor de sus atributos.

3. Encapsulación: los programadores solo tienen acceso a la interfaz de los métodos, los datos e implementación están ocultos.

4. Tipos o clases: el esquema de BDOO incluye un conjunto de tipos o de clases, no es imprescindible que el sistema mantenga la extensión del tipo.

5. Herencia de tipos o clases (jerarquías).

6. Vinculación dinámica (sobrecarga de métodos).

7. LMD computacionalmente completo 8. Extensibilidad de tipos de datos

(8)

Reglas de oro:

9. Persistencia:

Los datos deben mantenerse cuando la aplicación que los generó haya finalizado

Los datos deben mantenerse cuando la aplicación que los generó haya finalizado 10. Gestión de BD grandes. Disponer de mecanismos que proporcionen una clara

independencia lógica y física.

11. Usuarios concurrentes

12. Recuperación ante fallos software o hardware

13. Facilidad de consulta “ad hoc”, de alto nivel (razonablemente declarativo), eficiente e independiente de la aplicación. No necesariamente un lenguaje de programación, podría ser un explorador gráfico.

(9)

No menciona nada acerca de:

• Mecanismos de seguridad

• Mecanismos de integridad

• Vistas

• Lenguaje de consultas declarativo

(10)

class myclass2 { int a;

public:

void set_a (int num);

int get_a ();

};

SGBDOO

• (Parsaye et al., 1989) Un SGBDOO es un SGBD que soporta un modelo basado en el paradigma orientado a objetos.

Almacena objetos y su esquema (persistencia)

Lenguaje de consulta de alto nivel con capacidades de optimización

class myclass { int a;

public:

void set_a (int num);

int get_a ();

};

capacidades de optimización

Por ser gestor: incluye mecanismos para

optimizar el acceso (indexación y clustering), el control de concurrencia, seguridad y

gestión de usuarios, facilidad de consulta y recuperación ante fallos.

Por ser OO: características de identidad, encapsulación, herencia, polimorfismo y control de tipos

SGBDOO

(11)

•

Estrategias para el desarrollo de SGBD-OO

Ampliar un lenguaje de programación OO existente con capacidades de BD (caso de GemStone).

Proporcionar bibliotecas de clases con las capacidades tradicionales de las bases de datos (persistencia, transacciones, concurrencia,…)

Ontos, ObjectStore y Versant Ontos, ObjectStore y Versant

Incrustar estructuras de un lenguaje de BD orientado a objetos en un lenguaje host tradicional. Caso de O2, que extiende el C.

Ampliar un lenguaje de BD con capacidades OO, caso del SQL 2003 y Object SQL (OQL, propuesto por ODMG)

Desarrollar un lenguaje/modelo de datos desde cero. Nadie

(12)

BD Orientadas a Objetos Puras ^:Identidad

• Una parte clave de la definición de un objeto es su identidad única. En un SGBD-OO a cada objeto se le asigna un Identificador de Objeto (OID) cuando es creado.

• ^{El OID es}

^Generado por el sistema.

^Único para cada objeto y único en el sistema.

Mecanismo equivalente a la integridad de entidades.

Invariante, es decir, no cambia a lo largo de la vida del objeto.

No será utilizado por ningún otro objeto, incluso después de que el objeto sea

No será utilizado por ningún otro objeto, incluso después de que el objeto sea eliminado.

Independiente del estado (valores de los atributos).

Dos objetos pueden tener el mismo estado pero no el mismo OID.

^Invisible para el usuario (idealmente, no se suele cumplir).

• En los modelos relacionales el OID es por valor de la clave, en OO es la dirección de memoria que ocupa en el proceso, como éste es menor que el espacio físico pues se habla de OID lógicas (independiente del estado y de la ubicación) y físicas.

• El trabajar con OID, es más eficiente (ocupan menos espacio), rápido e independientes del contenido

(13)

•

^{Los SGBDR} tienen un modelo en dos niveles:

páginas en memoria y en disco

•

^{Los SGBDOO} proporcionan la ilusión de un único nivel, tratando de utilizar la misma representación en memoria que en disco

Transformación de OID a punteros de memoria y

Transformación de OID a punteros de memoria y viceversa. Existen varias estrategias

•

La persistencia, los objetos sobrevivan después de que termine el programa que los creó.

Diferentes estrategias

(14)

Modelo 2 niveles BDR vs 1 nivel BDOO

Tabla de objetos residentes

(15)

BD Orientadas a Objetos Puras: persistencia

• Mecanismos para implementar la persistencia en SGBDOO:

Puntos de comprobación (checkpoint).

El sistema copia todo o parte del espacio de direcciones de trabajo a disco. Prob. el punto de control solo lo puede leer el prog. que lo creó

Serialización.

Copiar a disco el cierre de una estructura de datos. Prob. no preserva la identidad del objeto

Paginación explícita.

El programador indica de forma explícita los objetos que quiere que se graben en disco de forma obligatoria e inmediata por el sistema.

disco de forma obligatoria e inmediata por el sistema.

• Persistencia Ortogonal (el mecanismo de persistencia se integre dentro del lenguaje de programación de aplicaciones), basada en tres principios

Independencia: la persistencia de un objeto es independiente de cómo el programa lo manipula y al contrario.

Ortogonalidad respecto a los tipos: Todos los objetos deben poder ser persistentes sin depender de su tipo (persistente o transitorio).

Transitividad: La manera de identificar y proveer persistencia no depende de los tipos de datos del lenguaje.

(16)

•

^Ventajas:

Capacidades de modelado enriquecidas

Extensibilidad

Eliminación del desajuste de impedancia

Lenguaje de consulta más expresivo

•

Desventajas:

Falta de un Modelo de Datos universal

Falta de experiencia

Falta de estándares

Competencia

La optimización de consultas

Lenguaje de consulta más expresivo

Soporte para la evolución de esquemas

Soporte para transacciones de larga duración

Apto para aplicaciones de BD avanzadas

Rendimiento mejorado

La optimización de consultas hace peligrar la encapsulación

Bloqueos a nivel de objeto pueden perjudicar el

rendimiento

Complejidad

Sin soporte para vistas

Sin soporte para seguridad

(17)

BD Orientadas a Objetos Puras:

ventajas

• Capacidades de modelado enriquecidas: el modelo OO permite que el “mundo real”

sea modelado mejor. El objeto, que encapsula el estado y el comportamiento, es una manera más natural y real de representar objetos del “mundo” real.

• Extensibilidad: permiten que se puedan definir nuevos tipos a partir de los tipos existentes.

• Eliminación del desajuste de impedancia: Una sola interfaz entre el LMD y el lenguaje de programación. Esto elimina mucha de las ineficiencias que ocurrían al querer

corresponder un lenguaje declarativo como SQL y un lenguaje de programación como C.

• Lenguaje de consulta más expresivo: el acceso navegacional es más adecuado para

• Lenguaje de consulta más expresivo: el acceso navegacional es más adecuado para manejar consultas recursivas, etc … Sin embargo, se argumenta que la mayoría del los SGBDOO están ligados a un lenguaje de prog., que en general no es demasiado fácil de usar para los usuarios finales. Por ello el estándar ODMG especifica un lenguaje declarativo basado en una versión OO de SQL.

• Soporte para la evolución de esquemas: El estrecho acoplamiento entre aplicaciones y datos permite que la evolución de esquemas sea más viable. La generalización y la herencia permiten que los esquemas estén mejor estructurados, que sean más intuitivos, y que

capturen más la semántica de la aplicación.

(18)

ventajas

• Soporte para transacciones de larga duración: los SGBD actuales obligan la

serializabilidad de transacciones concurrentes, para mantener la consistencia. Eso no es útil para transacciones de larga duración, por ello algunos SGBDOO usan otros protocolos para manejar transacciones de larga duración (bloqueos de jerarquías de objetos).

• Apto para aplicaciones de BD avanzadas: La capacidades de modelado enriquecida en los SGBDOO, hacen que sean adecuados para aplicaciones como CAD, CASE, multimedia, OIS, etc.

• Rendimiento mejorado: existen varios estudios que manifiestan la mejora en

rendimiento con respecto a los SGBDR. Aunque algunos argumentan que tienen mejor rendimiento para aplicaciones más adecuadas a la OO, pero que en aplicaciones

rendimiento para aplicaciones más adecuadas a la OO, pero que en aplicaciones tradicionales de SGBD (OLTP) son mejores los SGBDR.

(19)

desventajas

• Falta de un Modelo de Datos universal: no existe un modelo de datos universal y la mayoría carece de fundamentos teóricos. Aunque ODMG ha propuesto un modelo de objetos que se ha convertido en el estándar de facto en los SGBDO

• Falta de experiencia: en comparación con los SGBDR el uso de los SGBOO es todavía limitado. Por ello, no se tiene demasiada experiencia en ellos.

• Falta de estándares: como no existe un modelo de datos estándar, tampoco existe un lenguaje de consulta estándar. Aunque ODMG ha propuesto un lenguaje de consultas OO, que se ha convertido en de facto.

• Competencia: los SGBR y los SGBDOR están más difundidos y existen muchas más herramientas desarrolladas para ayudar a los usuarios finales.

• La optimización de consultas hace peligrar la encapsulación: la optimización de consultas requiere un entendimiento de la implementación subyacente para acceder a la

• La optimización de consultas hace peligrar la encapsulación: la optimización de consultas requiere un entendimiento de la implementación subyacente para acceder a la BD eficientemente, eso puede comprometer el concepto de encapsulación.

• Bloqueos a nivel de objeto pueden perjudicar el rendimiento: muchos SGBDOO usan el bloqueo como la base de los protocolos de concurrencia. Sin embargo, si el bloqueo se aplica a nivel de objeto, el bloqueo de una jerarquía de herencia puede ser problemática, como así también su rendimiento.

• Complejidad: la gran funcionalidad que proveen los SGBDOO, hace que sean más complejos, y esto lleva a productos más difíciles de usar y más caros.

• Sin soporte para vistas y restricciones declarativas: dependen de los métodos definidos

• Sin soporte para seguridad: actualmente los SGBDOO no proporcionan mecanismos adecuados de seguridad, no pueden conceder derechos de acceso a objetos o clases por usuario

(20)

ODMG 3.0

• Object Database Management Group: Grupo de desarrollo de SGBD

orientados a objetos, ligado a OMG (Object Management Group): Object Design, Sun Microsystems, ONTOS, O2, Technology / Ardent Soft., Objectivity, Versant, Gemstone, Computer Associates, ObjectStore, InterSystems CACHE, etc.

• Creado a mediados de 1991, a propuesta de Catell, para definir los estándares de las BD orientadas a objetos

Asegurar una portabilidad sobre los diferentes productos de estas compañías

Normalizar el modelo de datos a objetos y los lenguajes

• Aparición de “The ODMG-93 Standard”. Revisiones ODMG 95, 97, 99 (ODMG 3.0 + Java). De Facto

Object Model

Object Data Definition Language (ODL)

Object Query Language (OQL)

Interfaces con C++, Smalltalk, Java

(21)

Preprocesador de declaración

DECLARACIONES EN ODL O PL ODL

CÓDIGO FUENTE DE LA APLICACIÓN EN PL

Compilador PL

ODMG 3.0

Propuesta de Arquitectura Operativa

Enlazador

metadatos

BD

Runtime SGBDOO

CÓDIGO BINARIO APLICACIÓN

APLICACIÓN EN

EJECUCIÓN

(22)

ODMG 3.0

Modelo de Objetos

•

Resumen de Características

Los primitivas básicas de modelado son los objetos y los literales. Sólo los objetos tienen OID.

Objetos y literales están organizados en tipos.

Todos los objetos y literales de un mismo tipo tienen un comportamiento y estado común.

comportamiento y estado común.

Un tipo también es un objeto en sí mismo.

Un objeto es una instancia de su tipo.

El comportamiento está definido por un conjunto de operaciones que se pueden realizar sobre o por el objeto.

Las operaciones pueden tener una lista de parámetros de E/S tipados y pueden retornar un resultado tipado.

(23)

ODMG 3.0

Modelo de Objetos

•

Resumen de Características

^{El estado} está definido por los valores que el objeto toma para un conjunto de propiedades.

Una propiedad puede ser:

• Un atributo del objeto.

• Una interrelación entre el objeto y otro u otros objetos.

Los valores de las propiedades suelen cambiar con el tiempo.

Un Sistema de Gestión de Datos Objeto (SGDO / ODMS) almacena objetos de forma que pueden compartirse por usuarios y aplicaciones.

Un SGDO está basado en un esquema que está definido en el Lenguaje de Definición de Objetos (ODL).

Un SGDO contiene instancias de los tipos definidos por su esquema.

(24)

ODMG 3.0

Modelo de Objetos – objetos y literales

•

La primitiva fundamental es el objeto:

En ODMG todo son objetos

•

Distingue entre objetos mutables e inmutables (literales).

•

Los literales son objetos cuyo valor es constante.

Pueden tener estructura compleja.

No tienen OID.

No pueden ser referenciados de forma individual, sino que siempre se manejan dentro de objetos.

•

Un objeto está descrito por cuatro características:

Estructura. Atómicos, Colecciones, Estructurados

Identificador. Único para la BD.

Nombre. También permite identificar al objeto en la BD.

Tiempo de vida (lifetime). Transitorio / Persistente.

(25)

ODMG 3.0

Modelo de Objetos - tipos

•

Los objetos se clasifican en tipos:

Todos los objetos de un mismo tipo tienen unas propiedades y un comportamiento común:

Comportamiento: conjunto de operaciones que se pueden ejecutar sobre un objeto.

Estado: valores que toman sus propiedades (atributos y relaciones).

relaciones).

Un tipo tiene una especificación externa y una o más implementaciones.

La especificación externa es una descripción abstracta,

independiente de la implementación, de los aspectos visibles del tipo: propiedades, operaciones y excepciones.

La implementación define los aspectos internos: la

implementación de las operaciones y algunos otros detalles.

(26)

ODMG 3.0

Modelo de Objetos – interfaces y clases

•

En ODMG hay dos maneras de especificar tipos de objetos:

Un interfaz es una especificación que describe sólo el

comportamiento abstracto de un tipo de objeto (usando signaturas de operaciones).

Los interfaces pueden ser heredados por otros interfaces y clases. Aunque una interfaz pueda incluir propiedades, estas no pueden ser heredadas a partir de la interfaz.

Un interfaz no es instanciable (como las clases abstractas).

Se usan para especificar operaciones abstractas.

^{Una clase} es una especificación que define el comportamiento abstracto y el estado abstracto de un tipo de objeto.

Son instanciables.

La herencia simple se especifica mediante extends

La herencia múltiple no se permite mediante extends, se puede mediante herencia de comportamiento.

Extent define la extensión (conjunto de todas las instancias).

Key permite establecer la clave para identificar las instancias.

(27)

Comportamiento abstracto

Estado abstracto

Especificación de tipos Especificación de tipos

ODMG 3.0

Modelo de Objetos – interfaces y clases

interfaz clase literal

(28)

ODMG 3.0

Modelo de Objetos – herencia

•

Se puede hacer herencia del comportamiento o del estado:

Relación ISA (:), define la herencia simple o múltiple de comportamiento entre tipos de objetos (interfaces o clases). También denominada generalización

Relación EXTENDS (extend), define la herencia simple

Relación EXTENDS (extend), define la herencia simple de estado entre tipos de objetos (clases, no literales).

Se hereda tanto el comportamiento como las propiedades.

(29)

ODMG 3.0

Modelo de Objetos – supertipos y subtipos

•

En función de lo anterior, los tipos de objetos pueden organizarse formando jerarquías de supertipos y subtipos, de forma que:

Un subtipo hereda propiedades (estado) y operaciones (comportamiento) del supertipo.

Un subtipo puede añadir propiedades (estado) y operaciones (comportamiento) propias.

(comportamiento) propias.

Un subtipo puede redefinir propiedades (estado) y operaciones (comportamiento) del supertipo.

Sobrecarga.

Se soporta herencia múltiple (sólo en comportamiento, sólo en operaciones).

(30)

ODMG 3.0

Modelo de Objetos – Tipos predefinidos: colecciones

•

Colecciones

Número variable de elementos.

Los elementos pueden ser objetos o literales.

Todos los elementos son del mismo tipo.

•

Tipos de colecciones:

LIST<t>: colección ordenada de elementos de tipo t.

SET<t>: colección desordenada de elementos de tipo t que no admite duplicados.

BAG<t>: colección desordenada de elementos de tipo t que admite duplicados.

ARRAY<t>: vector de una dimensión y de longitud variable de elementos de tipo t.

DICTIONARY<t,v>: secuencia desordenada de pares <clave, valor> sin claves duplicadas.

(31)

ODMG 3.0

Modelo de Objetos – Tipos predefinidos: estructuras

•

Estructuras

Número fijo de elementos.

Pueden ser de distinto tipo.

•

Tipos de estructuras:

DATE. Fecha

INTERVAL. Intervalo de tiempo

^{TIME. Hora}

TIMESTAMP. Fecha y hora

(32)

ODMG 3.0

Modelo de Objetos – Tipos predefinidos: literales

•

Tipos de literales:

Literales atómicos:

LONG, SHORT, UNSIGNED LONG, UNSIGNED SHORT, FLOAT, DOUBLE, BOOLEAN, OCTET, CHAR, STRING, ENUM

Literales colecciones:

SET, BAG, LIST, ARRAY, DICTIONARY

Literales estructuras:

DATE, INTERVAL, TIME, TIMESTAMP

Literales NULL

(33)

Modelo de objetos: Interfaz ODL para los tipos de objetos definidos por el usuario

Nombre del objeto creado por el usuario

(34)

Modelo de objetos:

•

Excepciones:

El modelo soporta rutinas para el tratamiento de errores

•

^Metadatos:

El modelo define un meta-data pero muchos gestores existentes no tratan a los metadatos como objetos en sí mismos

•

Transacciones:

El modelo soporta el concepto de transacción como secuencia lineal de tareas que se ejecutan dentro de una hebra de control

de tareas que se ejecutan dentro de una hebra de control

La concurrencia está basada en bloqueos (pesimista)

No soporta transacciones distribuidas

•

Base de datos:

Área de almacenamiento para objetos persistentes de un conjunto de tipos determinado. Cada BD es una instancia de tipo Database con operaciones open(), close(), lookup() para buscar un objeto.

•

^Módulos:

Agrupan información relacionada (símil a schemas)

(35)

ODMG 3.0

ODL

•

Object Definition Language

Lenguaje para definir las especificaciones de los tipos de objetos para SGDO.

Equivale al DDL en sistemas relacionales.

Su principal objetivo es facilitar la portabilidad de esquemas.

Define los atributos e interrelaciones de los tipos y especifica la signatura de las operaciones.

signatura de las operaciones.

No es computacionalmente completo: no incluye la implementación de las operaciones, que se deja para lenguajes de programación OO

como C++ o Java.

La sintaxis está basada en el IDL (Interface Definition Language) de CORBA.

Es extensible (nuevas funcionalidades, optimizaciones físicas).

(36)

Ejemplo E/R

phones phones phones phones

(37)

Ejemplo UML

Movie title

year length filmType

{color, blackAndWhite}

Star name

Addr {street, city}

Studio name

address

President name

address

1..N 1..N

1..1

1..1 1..1 0..N

float lengthInHours() void starNames (out

Set<String>);

void otherMovies ( in Addr {street, city}

Phones(set)

0..N

Cartoon name

address MurderMystery

weapon

CartoonMurderMystery adultsonly

0..N

void otherMovies ( in Star, out Set<Movie>)

void enrolled_in (in Star s, Movie m) void drop_enrolled_in (in Star s, Movie m)

(38)

ODMG: Classes

Una clase se especifica por : - los atributos (abstractos).

- las relaciones con otros tipos de objetos - las operaciones

class Movie {

attribute string title;

attribute integer year;

attribute integer length;

attribute enum Film {color, blackAndWhite} filmType;

} ;

class Star {

attribute string name;

attribute struct Addr

{string street, string city} address;

attribute set <string> phone;

(39)

ODMG:

Types

• ^Atributos

Tipo estructurado es un tipo con un número fijo de elementos que pueden ser de diferente tipo.

Tipos atómicos: integer, float, character, string, boolean and enumerations;

Tipos predefinidos: date, time, interval, timestamp

Colección: conjunto de elementos del mismo tipo (set, bag, list, array, dictionary, table). Pueden ser de tipo básico o estructurado.

dictionary, table). Pueden ser de tipo básico o estructurado.

• ^Relaciones

El tipo de una relación (relationship) es o bien una interfaz (clase) o una colección de interfaz.

(40)

ODMG: Relationship

• Un objeto puede relacionarse con otros objetos a través de relationship

• Relaciones binarias y bi-direccionales 1-1, 1-N, N-M

• Establecer inverse para conexión bidireccional en ambas interfaces.

• En ODL no se puede expresar la integridad referencial

• Relaciones n-arias: se crean las relaciones binarias necesarias para su implementación

class Star {

class Movie {

attribute string title;

attribute integer year;

attribute integer length;

attribute enum Film {color, blackAndWhite} filmType;

relationship Set <Star> stars inverse Star::starredIn;

} ;

class Star {

attribute string name;

attribute Struct Addr

{string street, string city} address;

attribute set <string> phone;

relationship set <Movie> starredIn inverse Movie::stars;

} ;

N:M

(41)

ODMG: Relationship (2)

class Star {

relationship Set <Movie> starredIn inverse Movie::stars;

class Studio {

attribute string address;

relationship Set <Movie> owns inverse Movie::ownedBy;

relationship President hasPres inverse President::isPresOf;

} ;

1:N

inverse Movie::stars;

} ;

class Movie {

attribute Enum Film {color, blackAndWhite} filmType;

relationship Set <Star> stars inverse Star::starredIn;

relationship Studio ownedBy inverse Studio::owns;

class President {

relationship Studio isPresOf inverse Studio::hasPres;

}

1:1

(42)

ODMG: Keys

class Star (key (name)) { attribute string name;

class Studio (keys(name),(address)) {

relationship Set <Movie> owns inverse Movie::ownedBy;

relationship President hasPres inverse President::isPresOf;

} ;

class President (key(name)) { inverse Movie::stars;

} ;

class Movie (key (title, year)) { attribute string title;

relationship Studio ownedBy inverse Studio::owns;

class President (key(name)) { attribute string name;

relationship Studio isPresOf inverse Studio::hasPres;

}

Atributo o conjunto de atributos que identifica unívocamente cada objeto de un tipo. Similar al key del relacional, previene la duplicidad pero admite nulos.

(43)

ODMG: Keys (2)

class Studio (keys(name),(address)) {

relationship Set <Movie> owns inverse Movie::ownedBy;

relationship President hasPres inverse President::isPresOf;

relationship Set <Crew> crewsOf relationship Set <Crew> crewsOf

inverse Crew::partOf;

} ;

class Crew (key(number,partOf)) { attribute string number;

relationship Studio partOf inverse Studio::crewsOf;

}

Establecer keys para entidades débiles

No puede haber dos trabajadores con el mismo número que trabajen para el mismo estudio

(44)

ODMG: Subclasses

class Movie (key (title, year)) { attribute string title;

relationship Set <Star> stars

• Las subclases heredan los atributos de su superclase.

} ;

class Cartoon extends Movie { relationship Set<Star> voices

inverse Star::speaksIn;

}

class Star {

relationship Set<Cartoon> speaksIn inverse Cartoon::voices

} ;

(45)

ODMG: Subclasses (2)

class Movie (key (title, year)) { attribute string title;

relationship Studio ownedBy relationship Studio ownedBy

inverse Studio::owns;

} ;

class Cartoon extends Movie { relationship Set<Star> voices

inverse Star::speaksIn;

}

class MurderMystery extends Movie { attribute string weapon;

};

class CartoonMurderMystery extends Cartoon : MurderMystery {

(46)

ODMG: Methods

• En ODL un método es una función asociada a una clase

• Los métodos se declaran mediante el concepto de signature que no es más que el nombre de dicho método junto con los tipos de sus

argumentos de entrada y el tipo de salida.

• El código de un método no forma parte de la declaración y se supone que se escribirá en el lenguaje de implementación

• La sintaxis de la declaración es similar a la de funciones en C con dos

• La sintaxis de la declaración es similar a la de funciones en C con dos importantes añadidos:

1. Los parámetros de la función se pueden especificar como in, out, inout según sea de entrada, salida o de entrada/salida.

2. Las funciones pueden manejar excepciones que son respuestas

especiales. Una excepción indica habitualmente una condición anormal que a su vez se tratará mediante otro método. En ODL una declaración de

función puede ser seguida por la palabra raises, seguida por una lista de una o más excepciones que la función puede tratar.

(47)

ODMG: Methods (2)

class Movie {

relationship Set <Star> stars

inverse Star::starredIn;

float lengthInHours() raises (noLengthFound);

void starNames (out Set<String>);

void otherMovies ( in Star, out Set<Movie>) raises (noSuchStar);

} ;

(48)

ODMG: Extents

• Cuando se define una clase se hace necesario diferenciar su definición, del conjunto de objetos que existe de esa clase en la base de datos.

• En ODL, esta distinción se realiza de forma explícita dando a la clase y a su extent distintos nombres.

• En general la clase recibe el nombre en singular y el extent en plural.

class Movie (extent Movies key (title, year)) { class Movie (extent Movies key (title, year)) {

} ;

(49)

ODMG: Interfaces

• Las interfaces son básicamente definiciones de clases que no tienen extent asociados (es decir, sin objetos).

• Son útiles si se necesitan mantener en la base de datos varios conjuntos de objetos que tienen el mismo tipo (interfaz) pero pertenecen a distinta clase.

interface Business (…) interface Business (…)

{ …

string getTaxPayerId(…);

void setTaxPayerId(…);

integer calcTotalIncome(…);}

class Person ( … ) { … }

class Company: Business ( … ) { … }

class SelfEmployedPerson extends Person: Business ( … ) { … }

(50)

ODMG 3.0

OQL

•

Object Query Language

Provee acceso declarativo a una BD de objetos mediante una sintaxis similar a SQL.

No provee operadores de modificación explícitos porque esta funcionalidad se deja para las operaciones definidas sobre los objetos.

Puede ser usado como un lenguaje autónomo o embebido

Puede ser usado como un lenguaje autónomo o embebido dentro de otros lenguajes (C++, Smalltalk, Java).

Desde OQL se pueden invocar operaciones escritas en estos lenguajes.

Permite acceso tanto asociativo como navegacional:

Una consulta asociativa devuelve una colección de objetos.

Una consulta navegacional accede a objetos individuales y las interrelaciones entre objetos sirven para navegar entre objetos.

(51)

ODMG 3.0

OQL

•

El formato del SELECT es similar al de SQL:

SELECT [DISTINCT] <expresión>

FROM <lista from>

[WHERE <expresión> ]

[GROUP BY <atributo1:expresión1, ....>]

[HAVING <predicado>]

[ORDER BY <expresión>]

Donde

<lista from> ::=

{ <nombre de variable> IN <expresión> |

<nombre de variable> IN <expresión> , <lista from> |

<expresión> AS <nombre de variable> |

<expresión> AS <nombre de variable> , <lista from> }

(52)

PERSONA

atributo nombre atributo fech_nac atributo salario operacion edad

ODMG 3.0

OQL - ejemplo

subordinados

EMPLEADO

operacion antigüedad

(53)

select distinct x.edad from x in personas

where x.nombre=“Ana”

Devuelve un literal del tipo set <integer>

ODMG 3.0

OQL - ejemplo

¿Edades de todas las personas llamadas “Ana”?

select distinct struct (a:x.edad, s:x.salario) from x in personas

where x.nombre=“Ana”

Devuelve un literal del tipo set <struct (a:integer, s:integer)>

¿Edad y salario de todas las personas llamadas “Ana”?

(54)

select distinct struct (a:x.nombre, smp:

(select y

from y in x.subordinados where y.salario>300000) ODMG 3.0

OQL - ejemplo

¿Nombre de cada empleado y sus subordinados que tienen un salario mayor de 3000 €?

where y.salario>300000) from x in empleados

Devuelve un literal del tipo set <struct (nombre:string, smp:bag<empleado>)>

(55)

select struct (a:x.edad, s:x.salario) from x in

(select y

from y in empleados

Utilización del select dentro de la cláusula from:

ODMG 3.0

OQL - ejemplo

¿Edad y salario de todos los empleados con justo 10 años de antigüedad?

where y.antigüedad=10)

Devuelve un literal del tipo bag <struct (a:integer, s:integer)>

Efecto del uso de DISTINCT:

SELECT ---> bag (con repetición) SELECT DISTINCT ---> set (sin repetición)

(56)

ODMG 3.0

OQL – creación de objetos

•

Creación de Objetos:

Objetos mutables:

Para crear un objeto con identificador se debe utilizar un tipo constructor.

Persona (nombre: “María”, fech_nac:”11/2/69”, salario:1000)

Si no se inicializa alguna de sus propiedades, se les asignará automáticamente un valor por defecto.

automáticamente un valor por defecto.

Literales (objetos inmutables):

Para construir un objeto sin identificador se utiliza el constructor struct.

STRUCT (a:10, b:”María”)

(57)

ODMG 3.0

OQL – creación de objetos

•

También es posible crear objetos mutables (no literales) formados por el resultado de una consulta.

type bolsaint: bag<integer>;

type estado attributes a: integer

b: salario end_type;

type estados: bag<estado>;

bolsaint (select distinct x.edad from x in personas

where nombre=“Pedro”)

estados (select estado (a:x.edad, b:x.salario) from x in personas

where nombre=“Pedro”) Devuelve un objeto mutable de

tipo “bolsaint”

Devuelve un objeto mutable de tipo “estados”

(58)

ODMG 3.0

OQL – definición de vistas

•

Es posible dar nombre al resultado de una consulta y utilizarlo en otras consultas posteriores.

define juanes as select distinct x

from x in persona

where x.nombre=“Juan”;

¿Conjunto de personas llamadas “Juan”?

select distinct x.salario from x in juanes;

¿Salarios de las personas llamadas “Juan”?

(59)

OPERADORES DE ACCCESO:

“.^{” / “}->” (aplicados a un atributo, una operación o una relación) FIRST / LAST (primero / último elemento de una lista o un vector) Ejemplo:

personas.nombre ODMG 3.0

OQL – operaciones

personas.nombre

personas->nombre nombre de todas las personas juan.subordinado.nombre

juan->subordinado->nombre nombre de los subordinados de Juan juan.edad

juan->edad edad de juan

(60)

ODMG 3.0

OQL – operaciones

•

EXPRESIONES CON COLECCIONES:

COUNT , SUM , MIN , MAX , AVG (funciones de agrupamiento) GROUP...IN...BY...WHERE

SORT...IN...BY FOR...ALL...IN EXIST...IN IN

SELECT...FROM...WHERE

^Ejemplos:

COUNT(personas)

FOR ALL e IN empleados:e.salario>3000

•

EXPRESIONES ARITMÉTICAS:

+ , - , * , / , - (unario) , MOD , ABS

^Ejemplo:

COUNT(personas) – COUNT(empleados)

(61)

ODMG 3.0

OQL – operaciones

•

OPERADORES DE COMPARACIÓN:

= , != , < , <= , > , >=

•

OPERADORES LÓGICOS:

NOT , AND , OR

^Ejemplo:

NOT(true)

•

EXPRESIONES SOBRE COLECCIONES:

INTERSEC , UNION , EXCEPT

^Ejemplo:

bag(2,2,3,3,3) EXCEPT bag(2,3,3,3) el resultado es bag(2)

(62)

ODMG 3.0

OQL – operaciones

•

Se pueden hacer combinaciones (joins) de forma parecida a SQL:

Select p

from Persons p, Flowers f where p.nombre = f.nombre;

¿Conjunto de personas que tienen nombre de flor?

•

Conversores de Tipos:

LISTTOSET , ELEMENT , FLATTEN

^Ejemplo:

define juan as element(

select distinct x from x in empleado

where x.nombre=“Juan”);

(63)

MODELO ODMG

SGBD Objeto-Relacionales vs OO

Comparativa de los Modelos del ODMG y el SQL

MODELO OMG

MODELO SQL:1999

MODELO OMG

MODELO ODMG MODELO

SQL:1999

MODELO ODMG

(64)

Principal Inconveniente Práctico del ODMG

“LOS PRINCIPALES PROBLEMAS Y DEFICIENCIAS EN EL LENGUAJE DE BASES DE DATOS DEL ODMG SE DEBEN AL

HECHO DE QUE NO INCLUYE LAS FACILIDADES DEL SQL

Kim (1994)

(A PESAR DEL HECHO DE QUE EL MODELO DE DATOS DEL ODMG ESTÁ BASADO EN EL MODELO BÁSICO DEL

OMG, QUE SÍ INCLUYE TOTALMENTE EL MODELO RELACIONAL)”

(65)

Comparativa – modelado de datos

Característica Objeto-Relacional (SQL) Orientado a Objetos Puro (ODMG)

Identidad de objetos (OID)

Soportada mediante el tipo REF Soportada

Encapsulación Soportada a través de UDTs Soportada pero se rompe para las consultas

Herencia Soportada (jerarquías separadas Soportada Herencia Soportada (jerarquías separadas

para los UDTs y tablas)

Soportada

Polimorfismo Soportada Soportada

Objetos complejos Soportada mediante UDTs Soportada Interrelaciones Soporte completo con

restricciones de integridad

referencial definidas por usuario

Soportada (por ejemplo, usando bibliotecas de clases)

(66)

Comparativa – acceso a los datos

Característica Objeto-Relacional (SQL)

Orientado a Objetos Puro (ODMG)

Creación y acceso a datos persistentes

Soportada pero no de forma transparente

Soportada, pero el grado transparencia depende del producto concreto

Facilidad de consulta

“ad hoc”

SÍ, soportada completamente Soportada a través de ODMG

“ad hoc” ODMG

Navegación SÍ (mediante tipo REF) SÍ, soportada completamente Restricciones de

integridad

SÍ, soportada completamente NO soportadas Evolución de

Esquemas

Soporte limitado Soportado, pero el grado de soporte depende del

producto concreto

(67)

Comparativa – compartición de datos

Característica Objeto-Relacional (SQL)

Orientado a Objetos Puro (ODMG)

Transacciones ACID SÍ, soportada completamente SÍ

Recuperación SÍ, soportada completamente SÍ, pero el grado de soporte depende del producto

concreto Modelos de

transacciones avanzados

NO SÍ, pero el grado de soporte

depende del producto concreto

Seguridad,

integridad y vistas

SÍ, soportada completamente SÍ, pero con limitaciones

(68)

COURSE

SALARY

EMPLOYEE

has_prerequisites

is_prerequisite_for Uno a uno

uno a muchos

muchos a muchos

ISA extends

ODMG 3.0

ODL – Ejercicio

Course: name, number, semester Section: number

Salary: base,overtime, bonus Employee: id, name, salary

Professor: rank {full, associate, assistant}

Student-if: student-id, name, dorm_address {college, room_number}

EMPLOYEE

TA PROFESSOR

SECTION STUDENT

STUDENT-IF

has_sections

is_section_of

has_TA assists

teaches takes

(69)

Matisse: ejemplo de SGBD-OO

•

Matisse, de ADB Inc., es un SGBDOO con soporte para C, C++, Eiffel y Java

•

Está especialmente orientado a grandes bases de datos con una rica estructura semántica, y puede manipular objetos muy grandes como imágenes películas y sonidos

•

Aunque admite los conceptos básicos de la orientación a

•

Aunque admite los conceptos básicos de la orientación a

objetos, tales como la herencia múltiple, Matisse se abstiene de imponer demasiadas restricciones como lo referente al modelo de datos y sirve en su lugar como un potente motor de base de datos orientadas a objetos.

http://matisse.com/developers/downloads/

(70)

Matisse: ejemplo de SGBD-OO

•

Algunas de las ventajas principales:

Una técnica de representación original que hace posible fragmentar un objeto, especialmente un objeto grande, en varios discos, para optimizar así el tiempo de acceso.

Una ubicación optimizada de los objetos en los discos.

Un mecanismo automático de duplicación que proporciona una

solución software a los fallos de tolerancia del hardware: los objetos (en lugar de los discos en sí) se pueden duplicar espectacularmente (en lugar de los discos en sí) se pueden duplicar espectacularmente en varios discos, con recuperación automática en caso de fallo del disco.

Un mecanismo de versiones de objetos incorporado.

Soporte para las transacciones.

Soporte para una arquitectura cliente-servidor en la cual un servidor central gestiona los datos para un número posiblemente elevado de clientes, que mantienen una “reserva” de objetos a los que se haya accedido recientemente.

(71)

Matisse: modelo de objetos

•

Importa ficheros .odl a una BD

(72)

Matisse: objects.odl

interface PostalAddress : persistent {

attribute String Nullable City;

attribute String<16> Nullable PostalCode;

};

interface Person : persistent {

attribute String firstName;

attribute String lastName;

attribute String Nullable comment;

attribute Integer Nullable age;

attribute Date Nullable birthdate;

attribute Integer dependents = 0;

attribute Image Nullable photo = NULL;

relationship PostalAddress Address [0,1];

};

interface Employee : Person : persistent {

attribute Date hireDate;

attribute Numeric salary;

};

Nota: Ver ejemplo.rar para clases en java y programa que gestiona estas clases