BASES DE DATOS AVANZADAS - Tema 3, parte b Modelo de Objetos Univ. Cantabria - Fac. de Ciencias
←
→
Transcripción del contenido de la página
Si su navegador no muestra la página correctamente, lea el contenido de la página a continuación
BASES DE DATOS AVANZADAS
Tema 3, parte b
Modelo de Objetos
Objetos Puro
Univ. Cantabria – Fac. de Ciencias
Francisco Ruiz, Marta ZorrillaObjetivos
• 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
Francisco Ruiz, Marta Zorrilla - BDA 3a.2Contenido
• Bases de Datos Orientadas a Objetos Puras
• ODMG 3.0
Modelo de Objetos
ODL
OQL
• SGBD Objeto-Relacionales vs Orientados a Objetos
Francisco Ruiz, Marta Zorrilla - BDA 3a.3Bibliografí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.
Francisco Ruiz, Marta Zorrilla - BDA 3a.4Introducció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)
Francisco Ruiz, Marta Zorrilla - BDA 3a.5Introducció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,
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.
Francisco Ruiz, Marta Zorrilla - BDA 3a.6BD Orientadas a Objetos Puras
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.
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
Francisco Ruiz, Marta Zorrilla - BDA 3a.7BD Orientadas a Objetos Puras
MANIFIESTO DE LOS SGBD-OO
ATKINSON et al. (1989)
Reglas de oro:
9. Persistencia:
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.
Francisco Ruiz, Marta Zorrilla - BDA 3a.8BD Orientadas a Objetos Puras
MANIFIESTO DE LOS SGBD-OO
ATKINSON et al. (1989)
No menciona nada acerca de:
• Mecanismos de seguridad
• Mecanismos de integridad
• Vistas
• Lenguaje de consultas declarativo
Francisco Ruiz, Marta Zorrilla - BDA 3a.9SGBDOO
class myclass2 {
int a;
class myclass {
• (Parsaye et al., 1989) Un SGBDOO es un public:
int a;
SGBD que soporta un modelo basado en el void set_a (int num);
public:
paradigma orientado a objetos. int get_a ();
void set_a (int num);
Almacena objetos y su esquema };
int get_a ();
(persistencia)
};
Lenguaje de consulta de alto nivel con
capacidades de optimización
Por ser gestor: incluye mecanismos para
optimizar el acceso (indexación y clustering),
el control de concurrencia, seguridad y SGBDOO
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
Francisco Ruiz, Marta Zorrilla - BDA 3a.10BD Orientadas a Objetos Puras
• 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
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
Francisco Ruiz, Marta Zorrilla - BDA 3a.11BD 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
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
Francisco Ruiz, Marta Zorrilla - BDA 3a.12BD Orientadas a Objetos Puras
• 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
viceversa. Existen varias estrategias
• La persistencia, los objetos sobrevivan después de
que termine el programa que los creó.
Diferentes estrategias
Francisco Ruiz, Marta Zorrilla - BDA 3a.13Modelo 2 niveles BDR vs 1 nivel BDOO
Tabla de objetos
residentes
Francisco Ruiz, Marta Zorrilla - BDA 3a.14BD 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.
• 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.
Francisco Ruiz, Marta Zorrilla - BDA 3a.15BD Orientadas a Objetos Puras
• Ventajas: • Desventajas:
Capacidades de modelado Falta de un Modelo de Datos
enriquecidas universal
Extensibilidad Falta de experiencia
Eliminación del desajuste de Falta de estándares
impedancia Competencia
Lenguaje de consulta más La optimización de consultas
expresivo hace peligrar la encapsulación
Soporte para la evolución de Bloqueos a nivel de objeto
esquemas pueden perjudicar el
Soporte para transacciones de rendimiento
larga duración Complejidad
Apto para aplicaciones de BD Sin soporte para vistas
avanzadas
Sin soporte para seguridad
Rendimiento mejorado
Francisco Ruiz, Marta Zorrilla - BDA 3a.17BD 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
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.
Francisco Ruiz, Marta Zorrilla - BDA 3a.18BD Orientadas a Objetos Puras: 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
tradicionales de SGBD (OLTP) son mejores los SGBDR.
Francisco Ruiz, Marta Zorrilla - BDA 3a.19BD Orientadas a Objetos Puras: 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
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
Francisco Ruiz, Marta Zorrilla - BDA 3a.20ODMG 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
Francisco Ruiz, Marta Zorrilla - BDA 3a.21ODMG 3.0
Propuesta de Arquitectura Operativa
DECLARACIONES CÓDIGO FUENTE DE
EN ODL O PL ODL LA APLICACIÓN EN PL
Preprocesador de
declaración Compilador PL
CÓDIGO
Runtime BINARIO
SGBDOO APLICACIÓN
metadatos
Enlazador
BD
APLICACIÓN
EN
EJECUCIÓN
Francisco Ruiz, Marta Zorrilla - BDA 3a.22ODMG 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.
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.
Francisco Ruiz, Marta Zorrilla - BDA 3a.23ODMG 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.
Francisco Ruiz, Marta Zorrilla - BDA 3a.24ODMG 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.
Francisco Ruiz, Marta Zorrilla - BDA 3a.25ODMG 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).
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.
Francisco Ruiz, Marta Zorrilla - BDA 3a.26ODMG 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.
Francisco Ruiz, Marta Zorrilla - BDA 3a.27ODMG 3.0
Modelo de Objetos – interfaces y clases
Especificación de tipos
Comportamiento Estado
abstracto abstracto
interfaz clase literal
Francisco Ruiz, Marta Zorrilla - BDA 3a.28ODMG 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
de estado entre tipos de objetos (clases, no literales).
Se hereda tanto el comportamiento como las propiedades.
Francisco Ruiz, Marta Zorrilla - BDA 3a.29ODMG 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.
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).
Francisco Ruiz, Marta Zorrilla - BDA 3a.30ODMG 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: colección ordenada de elementos de tipo t.
SET: colección desordenada de elementos de tipo t que no
admite duplicados.
BAG: colección desordenada de elementos de tipo t que admite
duplicados.
ARRAY: vector de una dimensión y de longitud variable de
elementos de tipo t.
DICTIONARY: secuencia desordenada de pares sin claves duplicadas.
Francisco Ruiz, Marta Zorrilla - BDA 3a.31ODMG 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
Francisco Ruiz, Marta Zorrilla - BDA 3a.32ODMG 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
Francisco Ruiz, Marta Zorrilla - BDA 3a.33Modelo de objetos: Interfaz ODL para los tipos de objetos
definidos por el usuario
Nombre del objeto creado por el usuario
Francisco Ruiz, Marta Zorrilla - BDA 3a.34Modelo 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
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)
Francisco Ruiz, Marta Zorrilla - BDA 3a.35ODMG 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.
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).
Francisco Ruiz, Marta Zorrilla - BDA 3a.36Ejemplo E/R
phones
Francisco Ruiz, Marta Zorrilla - BDA 3a.37Ejemplo UML
Movie
title President
year Studio
1..1 1..1 name
length 0..N 1..1 name
address
filmType address
{color, blackAndWhite}
float lengthInHours() void Star
starNames (out 1..N 1..N
name
Set);
Addr {street, city}
void otherMovies ( in 0..N Phones(set)
Star, out Set)
void enrolled_in (in Star s, Movie m)
void drop_enrolled_in (in Star s,
Movie m)
MurderMystery Cartoon
name
0..N
weapon
address
CartoonMurderMystery
adultsonly
Francisco Ruiz, Marta Zorrilla - BDA 3a.38ODMG: 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 phone;
};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.
• Relaciones
El tipo de una relación (relationship) es o bien una interfaz (clase) o una
colección de interfaz.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 {
attribute string name;
attribute Struct Addr
{string street, string city} address;
attribute set phone;
class Movie { relationship set starredIn
attribute string title; inverse Movie::stars;
attribute integer year; };
attribute integer length;
attribute enum Film {color, blackAndWhite} filmType; N:M
relationship Set stars inverse Star::starredIn;
};ODMG: Relationship (2)
class Studio {
attribute string name;
class Star {
attribute string name;
attribute string address; 1:N
relationship Set owns
attribute Struct Addr
inverse Movie::ownedBy;
{string street, string city} address;
relationship President hasPres
attribute set phone;
inverse President::isPresOf;
relationship Set starredIn
};
inverse Movie::stars;
};
class President { 1:1
attribute string name;
class Movie {
relationship Studio isPresOf
attribute string title;
inverse Studio::hasPres;
attribute integer year;
}
attribute integer length;
attribute Enum Film {color, blackAndWhite} filmType;
relationship Set stars
inverse Star::starredIn;
relationship Studio ownedBy
inverse Studio::owns;
};ODMG: Keys
class Studio (keys(name),(address))
{
attribute string name;
attribute string address;
class Star (key (name)) { relationship Set owns
attribute string name; inverse Movie::ownedBy;
attribute Struct Addr relationship President hasPres
{string street, string city} address; inverse President::isPresOf;
attribute set phone; };
relationship Set starredIn
inverse Movie::stars; class President (key(name)) {
}; attribute string name;
relationship Studio isPresOf
class Movie (key (title, year)) { inverse Studio::hasPres;
attribute string title; }
attribute integer year;
attribute integer length; Atributo o conjunto de atributos que
attribute Enum Film {color, blackAndWhite} filmType; identifica unívocamente cada objeto de
relationship Set stars un tipo. Similar al key del relacional,
inverse Star::starredIn; previene la duplicidad pero admite
relationship Studio ownedBy nulos.
inverse Studio::owns;
};ODMG: Keys (2)
class Studio (keys(name),(address))
{
attribute string name;
attribute string address;
relationship Set owns
inverse Movie::ownedBy;
relationship President hasPres
inverse President::isPresOf;
relationship Set crewsOf
inverse Crew::partOf;
};
class Crew (key(number,partOf)) { Establecer keys para entidades débiles
attribute string number;
relationship Studio partOf No puede haber dos trabajadores con
inverse Studio::crewsOf; el mismo número que trabajen para el
} mismo estudioODMG: Subclasses
• Las subclases heredan los atributos de su superclase.
class Movie (key (title, year)) {
attribute string title;
attribute integer year;
attribute integer length;
attribute Enum Film {color, blackAndWhite} filmType;
relationship Set stars
inverse Star::starredIn;
relationship Studio ownedBy class Star {
inverse Studio::owns; attribute string name;
}; attribute Struct Addr
{string street, string city} address;
class Cartoon extends Movie { relationship Set starredIn
relationship Set voices inverse Movie::stars;
inverse Star::speaksIn; relationship Set speaksIn
} inverse Cartoon::voices
};ODMG: Subclasses (2)
class Movie (key (title, year)) {
attribute string title;
attribute integer year;
attribute integer length;
attribute Enum Film {color, blackAndWhite} filmType;
relationship Set stars
inverse Star::starredIn;
relationship Studio ownedBy
inverse Studio::owns;
};
class Cartoon extends Movie {
relationship Set voices
inverse Star::speaksIn;
}
class MurderMystery extends Movie {
attribute string weapon;
};
class CartoonMurderMystery extends Cartoon : MurderMystery {
attribute integer adultsonly;}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
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.
Francisco Ruiz, Marta Zorrilla - BDA 3a.47ODMG: Methods (2)
class Movie {
attribute string title;
attribute integer year;
attribute integer length;
attribute Enum Film {color, blackAndWhite} filmType;
relationship Set stars
inverse Star::starredIn;
relationship Studio ownedBy
inverse Studio::owns;
float lengthInHours() raises (noLengthFound);
void starNames (out Set);
void otherMovies ( in Star, out Set) raises (noSuchStar);
};
Francisco Ruiz, Marta Zorrilla - BDA 3a.48ODMG: 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)) {
attribute string title;
attribute integer year;
attribute integer length;
attribute Enum Film {color, blackAndWhite} filmType;
relationship Set stars
inverse Star::starredIn;
relationship Studio ownedBy
inverse Studio::owns;
};
Francisco Ruiz, Marta Zorrilla - BDA 3a.49ODMG: 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 (…)
{ …
string getTaxPayerId(…);
void setTaxPayerId(…);
integer calcTotalIncome(…);}
class Person ( … ) { … }
class Company: Business ( … ) { … }
class SelfEmployedPerson extends Person: Business ( … ) { … }
Francisco Ruiz, Marta Zorrilla - BDA 3a.50ODMG 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
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.
Francisco Ruiz, Marta Zorrilla - BDA 3a.51ODMG 3.0
OQL
• El formato del SELECT es similar al de SQL:
SELECT [DISTINCT]
FROM
[WHERE ]
[GROUP BY ]
[HAVING ]
[ORDER BY ]
Donde
::=
{ IN |
IN , |
AS |
AS , }
Francisco Ruiz, Marta Zorrilla - BDA 3a.52ODMG 3.0
OQL - ejemplo
PERSONA
atributo nombre
atributo fech_nac
atributo salario
operacion edad
subordinados
EMPLEADO
operacion antigüedad
Francisco Ruiz, Marta Zorrilla - BDA 3a.53ODMG 3.0
OQL - ejemplo
select distinct x.edad ¿Edades de todas las
from x in personas personas llamadas “Ana”?
where x.nombre=“Ana”
Devuelve un literal del tipo set
select distinct struct (a:x.edad, s:x.salario)
¿Edad y salario de todas las from x in personas
personas llamadas “Ana”?
where x.nombre=“Ana”
Devuelve un literal del tipo set
Francisco Ruiz, Marta Zorrilla - BDA 3a.54ODMG 3.0
OQL - ejemplo
select distinct struct (a:x.nombre, smp:
¿Nombre de cada empleado y (select y
sus subordinados que tienen
un salario mayor de 3000 €? from y in x.subordinados
where y.salario>300000)
from x in empleados
Devuelve un literal del tipo set
Francisco Ruiz, Marta Zorrilla - BDA 3a.55ODMG 3.0
OQL - ejemplo
Utilización del select dentro de la cláusula from:
select struct (a:x.edad, s:x.salario)
¿Edad y salario de todos los
from x in empleados con justo 10 años
(select y de antigüedad?
from y in empleados
where y.antigüedad=10)
Devuelve un literal del tipo bag
Efecto del uso de DISTINCT:
SELECT -----------------------> bag (con repetición)
SELECT DISTINCT --------> set (sin repetición)
Francisco Ruiz, Marta Zorrilla - BDA 3a.56ODMG 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.
Literales (objetos inmutables):
Para construir un objeto sin identificador se utiliza el constructor
struct.
STRUCT (a:10, b:”María”)
Francisco Ruiz, Marta Zorrilla - BDA 3a.57ODMG 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;
type estado attributes
a: integer
b: salario
end_type;
type estados: bag;
bolsaint (select distinct x.edad estados (select estado (a:x.edad, b:x.salario)
from x in personas from x in personas
where nombre=“Pedro”) where nombre=“Pedro”)
Devuelve un objeto mutable de Devuelve un objeto mutable de tipo “estados”
tipo “bolsaint”
Francisco Ruiz, Marta Zorrilla - BDA 3a.58ODMG 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 ¿Conjunto de personas
from x in persona llamadas “Juan”?
where x.nombre=“Juan”;
select distinct x.salario ¿Salarios de las personas
from x in juanes; llamadas “Juan”?
Francisco Ruiz, Marta Zorrilla - BDA 3a.59ODMG 3.0
OQL – operaciones
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
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
Francisco Ruiz, Marta Zorrilla - BDA 3a.60ODMG 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)
Francisco Ruiz, Marta Zorrilla - BDA 3a.61ODMG 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)
Francisco Ruiz, Marta Zorrilla - BDA 3a.62ODMG 3.0
OQL – operaciones
• Se pueden hacer combinaciones (joins) de forma parecida
a SQL:
Select p
from Persons p, Flowers f ¿Conjunto de personas que
where p.nombre = f.nombre; 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”);
Francisco Ruiz, Marta Zorrilla - BDA 3a.63SGBD Objeto-Relacionales vs OO
Comparativa de los Modelos del ODMG y el SQL
MODELO
OMG MODELO
ODMG
MODELO
MODELO OMG OMG
MODELO
SQL:1999 MODELO MODELO
SQL:1999 ODMG
Francisco Ruiz, Marta Zorrilla - BDA 3a.64SGBD Objeto-Relacionales vs OO
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
(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)”
Kim (1994)
Francisco Ruiz, Marta Zorrilla - BDA 3a.65SGBD Objeto-Relacionales vs OO
Comparativa – modelado de datos
Característica Objeto-Relacional (SQL) Orientado a Objetos
Puro (ODMG)
Identidad de objetos Soportada mediante el tipo REF Soportada
(OID)
Encapsulación Soportada a través de UDTs Soportada pero se rompe
para las consultas
Herencia Soportada (jerarquías separadas Soportada
para los UDTs y tablas)
Polimorfismo Soportada Soportada
Objetos complejos Soportada mediante UDTs Soportada
Interrelaciones Soporte completo con Soportada (por ejemplo,
restricciones de integridad usando bibliotecas de
referencial definidas por usuario clases)
Francisco Ruiz, Marta Zorrilla - BDA 3a.66SGBD Objeto-Relacionales vs OO
Comparativa – acceso a los datos
Característica Objeto-Relacional Orientado a Objetos
(SQL) Puro (ODMG)
Creación y acceso a Soportada pero no de forma Soportada, pero el grado
datos persistentes transparente transparencia depende del
producto concreto
Facilidad de consulta SÍ, soportada completamente Soportada a través de
“ad hoc” ODMG
Navegación SÍ (mediante tipo REF) SÍ, soportada
completamente
Restricciones de SÍ, soportada completamente NO soportadas
integridad
Evolución de Soporte limitado Soportado, pero el grado de
Esquemas soporte depende del
producto concreto
Francisco Ruiz, Marta Zorrilla - BDA 3a.67SGBD Objeto-Relacionales vs OO
Comparativa – compartición de datos
Característica Objeto-Relacional Orientado a Objetos
(SQL) 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 NO SÍ, pero el grado de soporte
transacciones depende del producto
avanzados concreto
Seguridad, SÍ, soportada completamente SÍ, pero con limitaciones
integridad y vistas
Francisco Ruiz, Marta Zorrilla - BDA 3a.68Course: name, number, semester
ODMG 3.0 Section: number
ODL – Ejercicio Salary: base,overtime, bonus
Employee: id, name, salary
Professor: rank {full, associate, assistant}
Student-if: student-id, name, dorm_address {college, room_number}
Uno a uno
uno a muchos
SALARY
has_prerequisites
muchos a muchos
ISA COURSE
extends
is_prerequisite_for
has_sections EMPLOYEE
STUDENT-IF TA PROFESSOR
is_section_of assists
teaches
takes
has_TA
STUDENT SECTION
is_taken_by is_taught_by
Francisco Ruiz, Marta Zorrilla - BDA 3a.69Matisse: 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
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/
Francisco Ruiz, Marta Zorrilla - BDA 3a.75Matisse: 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 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.
Francisco Ruiz, Marta Zorrilla - BDA 3a.76Matisse: modelo de objetos • Importa ficheros .odl a una BD Francisco Ruiz, Marta Zorrilla - BDA 3a.77
Matisse: objects.odl
interface PostalAddress : persistent
{
attribute String Nullable City;
attribute String Nullable PostalCode;
};
interface Person : persistent
{
attribute String firstName;
attribute String lastName;
attribute String Nullable comment;
attribute Integer Nullable age;
attribute Date Nullable birthdate; Nota: Ver ejemplo.rar
attribute Integer dependents = 0;
attribute Image Nullable photo = NULL; para clases en java y
relationship PostalAddress Address [0,1]; programa que gestiona
}; estas clases
interface Employee : Person : persistent
{
attribute Date hireDate;
attribute Numeric salary;
};
Francisco Ruiz, Marta Zorrilla - BDA 3a.78También puede leer
