(Object Database Management Group) con el prop´osito de definir est´andares para los SGBD
orientados a objetos. Este grupo propuso un modelo est´andar para la sem´antica de los objetos
de una base de datos. Su ´ultima versi´on, ODMG 3.0, apareci´o en enero de 2000. Los
principales componentes de la arquitectura ODMG para un SGBD orientado a objetos son
los siguientes:
- Modelo de objetos.
- Lenguaje de definici´on de objetos (ODL).
- Lenguaje de consulta de objetos (OQL).
- Conexi´on con los lenguajes C++, Smalltalk y Java
Modelo de objetos
El modelo de objetos ODMG permite que tanto los dise˜nos, como las implementaciones,
sean portables entre los sistemas que lo soportan. Dispone de las siguientes primitivas de
modelado:
Los componentes b´asicos de una base de datos orientada a objetos son los objetos y
los literales. Un objeto es una instancia autocontenida de una entidad de inter´es del
mundo real. Los objetos tienen alg´un tipo de identificador ´unico. Un literal es un valor
espec´ıfico, como “Amparo” o 36. Los literales no tienen identificadores. Un literal no
tiene que ser necesariamente un solo valor, puede ser una estructura o un conjunto de
valores relacionados que se guardan bajo un solo nombre.
Los objetos y los literales se categorizan en tipos. Cada tipo tiene un dominio espec´ıfico
compartido por todos los objetos y literales de ese tipo. Los tipos tambi´en pueden tener
comportamientos. Cuando un tipo tiene comportamientos, todos los objetos de ese tipo
comparten los mismos comportamientos. En el sentido pr´actico, un tipo 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´on puede requerir datos
de entrada (par´ametros de entrada) y puede devolver alg´un valor de un tipo conocido.
Los objetos tienen propiedades, que incluyen sus atributos y las relaciones que tienen
con otros objetos. El estado actual 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 por m´ultiples usuarios y aplicaciones.
La definici´on de una base de datos est´a contenida en un esquema que se ha creado
mediante el lenguaje de definici´on de objetos ODL (Object Definition Language) que
es el lenguaje de manejo de datos que se ha definido como parte del est´andar propuesto
para las bases de datos orientadas a objetos.
4.1.1. Objetos
Los tipos de objetos se descomponenen en at´omicos, colecciones y tipos estructurados.
Los tipos colecci´on, que se derivan de la interface Collection, son la propuesta del est´andar
para las clases contenedor. Los objetos colecci´on identificados por el est´andar son los siguientes:
Set<tipo> : es un grupo desordenado de objetos del mismo tipo. No se permiten duplicados.
Bag<tipo> : es un grupo desordenado de objetos del mismo tipo. Se permiten duplicados.
List<tipo> : es un grupo ordenado de objetos del mismo tipo. Se permiten duplicados.
Array<tipo> : es un grupo ordenado de objetos del mismo tipo que se pueden acceder por
su posici´on. Su tama˜no es din´amico y los elementos se pueden insertar y borrar de
cualquier posici´on.
Dictionary<clave,valor> : es como un ´ındice. Esta formado por claves ordenadas, cada
una de ellas emparejada con un solo valor.
Los tipos estructurados son los siguientes:
Date : es una fecha del calendario (d´ıa, mes y a˜no).
12 4 El modelo est´andar ODMG
Time : es una hora (hora, minutos y segundos).
Timestamp : es una hora de una fecha (con precisi´on de microsegundos).
Interval : es un per´ıodo de tiempo.
Estos tipos tienen la misma definici´on que los tipos con el mismo nombre del est´andar de
SLQ.
Los objetos se crean utilizando el m´etodo new(). Adem´as, todos heredan la interface
que se muestra a continuaci´on:
interface Object f
enum Lock Typefread,write,upgradeg;
void lock(in Lock Type mode) raises(LockNotGranted);
boolean try lock(in Lock Type mode);
boolean same as(in Object anObject);
Object copy();
void delete();
g;
Cada objeto tiene un identificador de objeto ´unico generado por el SGBD, que no cambia
y que no se reutiliza cuando el objeto se borra. Cada SGBD genera los identificadores
siguiendo sus propios criterios.
Los objetos pueden ser transitorios o persistentes. Los objetos transitorios existen mientras
vive el programa de aplicaci´on que los ha creado. Estos objetos se usan tanto como
almacenamiento temporal como para dar apoyo al programa de aplicaci´on que se est´a ejecutando.
Los objetos persistentes son aquellos que se almacenan en la base de datos.
4.1.2. Literales
Los tipos literales se descomponen en at´omicos, colecciones, estructurados o nulos. Los
literales no tienen identificadores y no pueden aparecer solos como objetos, sino que est´an
embebidos en objetos y no pueden referenciarse de modo individual. Los literales at´omicos
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.
4.1 Modelo de objetos 13
unsigned long : un entero sin signo, normalmente de 32 o 64 bits.
float : un valor real en coma flotante de simple precisi´on.
double : un valor real en coma flotante de doble precisi´on.
octet : un almac´en de 8 bits.
char : un car´acter 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´umero fijo de elementos heterog´eneos. 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> y dictionary<clave,valor>.
4.1.3. Tipos
Una de las caracter´ısticas m´as importantes del paradigma orientado a objetos es la
distinci´on entre la interface p´ublica de una clase y sus elementos privados (encapsulaci´on).
El est´andar propuesto hace esta distinci´on hablando de la especificaci´on externa de un tipo
y de sus implementaciones.
Una interface es una especificaci´on del comportamiento abstracto de un tipo de objeto
y contiene las signaturas de las operaciones. Aunque una interface puede tener propiedades
(atributos y relaciones) como parte de su especificaci´on, ´estas no pueden ser heredadas desde
la interface. Adem´as, una interface no es instanciable por lo 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´on).
Una clase es una especificaci´on del comportamiento abstracto y del estado abstracto de
un tipo de objeto. Las clases son instanciables, por lo que a partir de ellas se pueden crear
instancias de objetos individuales (es el equivalente a una clase concreta en los lenguajes de
programaci´on).
El est´andar propuesto soporta la herencia simple y la herencia m´ultiple mediante las
interfaces. Ya que las interfaces no son instanciables, se suelen utilizar para especificar operaciones
abstractas que pueden ser heredadas 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´upertipo sea una interface, mientras que el subtipo puede
ser una clase o una interface.
La herencia es una relaci´on “es un”:
14 4 El modelo est´andar ODMG
interface ArticuloVenta ...;
interface Mueble : ArticuloVenta ...;
class Silla : Mueble ...;
class Mesa : Mueble ...;
class Sof¶a : Mueble ...;
La interface o clase m´as baja de la jerarqu´ıa es el tipo m´as espec´ıfico. Ya que hereda los
comportamientos de todos los tipos que tiene por encima en la jerarqu´ıa, es la interface o
clase m´as completa. En el ejemplo anterior, los tipos m´as espec´ıficos son Silla, Mesa y Sof¶a.
Uno de los beneficios pr´acticos de la herencia es que se puede hacer referencia a los
subtipos como su s´upertipo. Por ejemplo, un programa de aplicaci´on puede hacer referencia
a sillas, mesas y sof´as como muebles o incluso como art´ıculos de venta. Esto hace que sea
m´as sencillo tratar los subtipos como un grupo cuando sea necesario.
Los subtipos se pueden especializar como sea necesario a˜nadi´endoles comportamientos.
Los subtipos de un subtipo especializado heredan tambi´en los comportamientos a˜nadidos.
El modelo orientado a objetos utiliza la relaci´on extiende (extends) para indicar la
herencia de estado y de comportamiento. En este tipo de herencia tanto el subtipo como el
s´upertipo deben ser clases. Las clases que extienden a otra clase ganan acceso a todos los
estados y comportamientos del s´upertipo, incluyendo cualquier cosa que el s´upertipo haya
adquirido a trav´es de la herencia de otras interfaces.
Una clase puede extender, como m´aximo, a otra clase. Sin embargo, si se construye una
jerarqu´ıa de extensiones, las clases de m´as abajo en la jerarqu´ıa heredan todo lo que sus
s´upertipos heredan de las clases que tienen por encima.
El modelo permite al dise˜nador que declare una extensi´on (extent) para cada tipo de
objeto definido como una clase. La extensi´on de un tipo tiene un nombre e incluye todas
las instancias de objetos persistentes creadas a partir de dicho tipo. Declarar una extensi´on
denominada empleados para el tipo de objeto Empleado es similar a crear un objeto de tipo
Set<Empleado> denominado empleados. Una extensi´on se puede indexar para que el acceso
a su contenido sea m´as r´apido.
Una clase con una extensi´on puede tener una o m´as claves (key). Una clave es un
identificador ´unico. Cuando una clave est´a formada por una sola propiedad, es una clave
simple; si est´a formada por varias propiedades, es una clave compuesta. A diferencia del
modelo relacional, las claves ´unicas no son un requisito.
Una implementaci´on de un tipo consta de dos partes: la representaci´on y los m´etodos.
La representaci´on es una estructura de datos dependiente de un lenguaje de programaci´on
que contiene las propiedades del tipo. Las especificaciones de la implementaci´on vienen de
una conexi´on con un lenguaje (language binding). Esto quiere decir que la representaci´on
interna de un tipo ser´a diferente dependiendo del lenguaje de programaci´on que se utilice y
4.1 Modelo de objetos 15
que un mismo tipo puede tener m´as de una representaci´on.
Los detalles de las operaciones de un tipo se especifican mediante un conjunto de m´etodos.
En la especificaci´on externa de cada operaci´on debe haber al menos un m´etodo. Sin
embargo, un tipo puede incluir m´etodos que nunca se ven desde fuera del tipo. Estos m´etodos
son los que realizan algunas funciones necesarias para otros m´etodos del tipo.
Los m´etodos se escribir´an en el mismo lenguaje de programaci´on utilizado para expresar
la representaci´on del tipo. Si una base de datos soporta aplicaciones programadas en C++,
Java y Smalltalk, entonces ser´a necesario tener tres implementaciones para cada tipo, una
para cada lenguaje, aunque cada programa de aplicaci´on utilizar´a s´olo la implementaci´on
que le corresponda.
4.1.4. 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 lo tanto 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´olo soporta relaciones binarias
con cardinalidad 1:1, 1:n y n:m. Una relaci´on no tiene nombre y tampoco es un objeto
de “primera clase”, pero define caminos transversales en la interface de cada direcci´on. En
el lado del muchos de la relaci´on, los objetos pueden estar desordenados (set o bag) u
ordenados (list). La integridad de las relaciones la mantiene autom´aticamente el SGBD y
se genera una excepci´on cuando se intenta atravesar una relaci´on en la que uno de los objetos
participantes se ha borrado. El modelo aporta operaciones para formar (form) y eliminar
(drop) miembros de una relaci´on.
4.1.5. Transacciones
El modelo est´andar soporta el concepto de transacciones, que son unidades l´ogicas de
trabajo que llevan a la base de datos de un estado consistente a otro estado consistente. El
modelo asume una secuencia lineal de transacciones que se ejecutan de modo controlado. La
concurrencia se basa en bloqueos est´andar de lectura/escritura con un protcolo pesimista
de control de concurrencia. Todos los accesos, creaci´on, modificaci´on y borrado de objetos
persistentes se deben realizar dentro de una transacci´on. El modelo especifica operaciones
para iniciar, terminar (commit) y abortar transacciones, as´ı como la operaci´on de checkpoint.
Esta ´ultima operaci´on hace permanentes los cambios realizados por la transacci´on en curso
sin liberar ninguno de los bloqueos adquiridos.
16 4 El modelo est´andar ODMG
4.2. Lenguaje de definici´on de objetos ODL
ODL es un lenguaje de especificaci´on para definir tipos de objetos para sistemas compatibles
con ODMG. ODL es el equivalente del DDL (lenguaje de definici´on de datos) de los
SGBD tradicionales. Define los atributos y las relaciones entre tipos, y especifica la signatura
de las operaciones. La sintaxis de ODL extiende el lenguaje de definici´on de interfaces (IDL)
de la arquitectura CORBA (Common Object Request Broker Architecture). El uso de ODL
se muestra mediante un ejemplo:
class Persona
(extent personas key dni)
f
/* Definici¶on de atributos */
attribute struct Nom Persona fstring nombre pila, string apellido1,
string apellido2g nombre;
attribute string dni;
attribute date fecha nacim;
attribute enum GenerofF,Mg sexo;
attribute struct Direccion fstring calle, string cp, string ciudadg
direccion;
/* Definici¶on de operaciones */
float edad();
g
class Profesor extends Persona
(extent profesores)
f
/* Definici¶on de atributos */
attribute string categoria;
attribute float salario;
attribute string despacho;
attributo string telefono;
/* Definici¶on de relaciones */
relationship Departamento trabaja en
inverse Departamento::tiene profesores;
relationship Set<EstudianteGrad> tutoriza
inverse EstudianteGrad::tutor;
relationship Set<EstudianteGrad> en comite
inverse EstudianteGrad::comite;
/* Definici¶on de operaciones */
void aumentar salario(in float aumento);
void promocionar(in string nueva categoria);
g
4.2 Lenguaje de definici´on de objetos ODL 17
class Estudiante extends Persona
(extent estudiantes)
f
/* Definici¶on de atributos */
attribute string titulacion;
/* Definici¶on de relaciones */
relationship set<Calificacion> ediciones cursadas
inverse Calificacion::estudiante;
relationship set<EdicionActual> matriculado
inverse EdicionActual::estudiantes matriculados;
/* Definici¶on de operaciones */
float nota media();
void matricularse(in short num edic) raises(edicion no valida, edicion llena);
void calificar(in short num edic; in float nota)
raises(edicion no valida, nota no valida);
g;
class Calificacion
(extent calificaciones)
f
/* Definici¶on de atributos */
attribute float nota;
/* Definici¶on de relaciones */
relationship Edicion edicion inverse Edicion::estudiantes;
relationship Estudiante estudiante
inverse Estudiante::ediciones cursadas;
g;
class EstudianteGrad extends Estudiante
(extent estudiantes graduados)
f
/* Definici¶on de atributos */
attribute set<Titulo> titulos;
/* Definici¶on de relaciones */
relationship Profesor tutor inverse Profesor::tutoriza;
relationship set<Profesor> comite inverse Profesor::en comite;
/* Definici¶on de operaciones */
void asignar tutor(in string apellido1; in string apellido2)
raises(profesor no valido);
void asignar miembro comite(in string apellido1; in string apellido2)
raises(profesor no valido);
g;
18 4 El modelo est´andar ODMG
class Titulo
f
/* Definici¶on de atributos */
attribute string escuela;
attribute string titulo;
attribute string a~no;
g;
class Departamento
(extent departamentos key nombre)
f
/* Definici¶on de atributos */
attribute string nombre;
attribute string telefono;
attribute string despacho;
attribute string escuela;
attribute Profesor director;
/* Definici¶on de relaciones */
relationship set<Profesor> tiene profesores
inverse Profesor::trabaja en;
relationship set<Curso> oferta
inverse Curso::ofertado por;
g;
class Curso
(extent cursos key num curso)
f
/* Definici¶on de atributos */
attribute string nombre;
attribute string num curso;
attribute string descripcion;
/* Definici¶on de relaciones */
relationship set<Edicion> tiene ediciones
inverse Edicion::de curso;
relationship Departamento ofertado por inverse Departamento::oferta;
g;
class Edicion
(extent ediciones)
f
/* Definici¶on de atributos */
attribute short num edic
attribute string a~no;
4.3 Lenguaje de consulta de objetos OQL 19
attribute enum SemestrefPrimero,Segundog semestre;
/* Definici¶on de relaciones */
relationship set<Calificacion> estudiantes
inverse Calificacion::edicion;
relationship Curso de curso inverse Curso::tiene ediciones;
g;
class EdicionActual extends Edicion
(extent ediciones actuales)
f
/* Definici¶on de relaciones */
relationship set<Estudiante> estudiantes matriculados
inverse Estudiante::matriculado;
/* Definici¶on de operaciones */
void matricular estudiante(in string dni)
raises(estudiante no valido,edicion llena);
g;
4.3. Lenguaje de consulta de objetos OQL
OQL es un lenguaje declarativo del tipo de SQL que permite realizar consultas de modo
eficiente sobre bases de datos orientadas a objetos, incluyendo primitivas de alto nivel para
conjuntos de objetos y estructuras. Est´a basado en SQL-92, proporcionando un s´uperconjunto
de la sintaxis de la sentencia SELECT.
OQL no posee primitivas para modificar el estado de los objetos ya que las modificaciones
se pueden realizar mediante los m´etodos que ´estos poseen.
La sintaxis b´asica de OQL es una estructura SELECT...FROM...WHERE..., como en SQL.
Por ejemplo, la siguiente expresi´on obtiene los nombres de los departamentos de la escuela
de ‘Ingenier´ıa’:
SELECT d.nombre
FROM d in departamentos
WHERE d.escuela = `Ingenier¶³a';
En las consultas se necesita un punto de entrada, que suele ser el nombre de un objeto
persistente. Para muchas consultas, el punto de entrada es la extensi´on de una clase. En el
ejemplo anterior, el punto de entrada es la extensi´on departamentos, que es un objeto colecci
´on de tipo set<Departamento>. Cuando se utiliza una extensi´on como punto de entrada
es necesario utilizar una variable iteradora que vaya tomando valores en los objetos de la
20 4 El modelo est´andar ODMG
colecci´on. Para cada objeto de la colecci´on (s´olo la forman objetos persistentes) que cumple
la condici´on (que es de la escuela de ‘Ingenier´ıa’), se muestra el valor del atributo nombre.
El resultado es de tipo bag<string>. Cuando se utiliza SELECT DISTINCT... el resultado
es de tipo set ya que se eliminan los duplicados.
Las variables iterador se pueden especificar de tres formas distintas:
d in departamentos
departamentos d
departamentos as d
El resultado de una consulta puede ser de cualquier tipo soportado por el modelo. Una
consulta no debe seguir la estructura SELECT ya que el nombre de cualquier objeto persistente
es una consulta de por s´ı. Por ejemplo, la consulta:
departamentos;
devuelve una referencia a la colecci´on de todos los objetos Departamento persistentes. Del
mismo modo, si se da nombre a un objeto concreto, por ejemplo a un departamento se le
llama departamentoinf (el departamento de inform´atica), la siguiente consulta:
departamentoinf;
devuelve una referencia a ese objeto individual de tipo Departamento. Una vez se establece
un punto de entrada, se pueden utilizar expresiones de camninos para especificar un camino
a atributos y objetos relacionados. Una expresi´on de camino empieza normalmente con un
nombre de objeto persistente o una variable iterador, seguida de ninguno o varios nombres
de relaciones o de atributos conectados mediante un punto. Por ejemplo:
departamentoinf.director;
departamentoinf.director.categoria;
departamentoinf.tiene profesores;
La primera expresi´on devuelve una referencia a un objeto Profesor, aquel que dirige el
departamento de inform´atica. La segunda expresi´on obtiene la categor´ıa del profesor que
dirige este departamento (el resultado es de tipo string). La tercera expresi´on devuelve
un objeto de tipo set<Profesor>. Esta colecci´on contiene referencias a todos los objetos
Profesor que se relacionan con el objeto cuyo nombre es departamentoinf. Si se quiere
obtener la categor´ıa de todos estos profesores, no podemos escribir la expresi´on:
4.3 Lenguaje de consulta de objetos OQL 21
departamentoinf.tiene profesores.categoria;
El no poder escribir la expresi´on de este modo es porque no est´a claro si el objeto que se
devuelve es de tipo set<string> o bag<string>. Debido a este problema de ambig¨uedad,
OQL no permite expresiones de este tipo. En su lugar, es preciso utilizar variables iterador:
SELECT p.categoria
FROM p in departamentoinf.tiene profesores;
SELECT DISTINCT p.categoria
FROM p in departamentoinf.tiene profesores;
En general, una consulta OQL puede devolver un resultado con una estructura compleja
especificada en la misma consulta utilizando struct. La siguiente expresi´on:
departamentoinf.director.tutoriza;
devuelve un objeto de tipo set<EstudianteGrad>: una colecci´on que contiene los estudiantes
graduados que son tutorizados por el director del departamento de inform´atica. Si lo que se
necesita son los nombres y apellidos de estos estudiantes y los t´ıtulos que tiene cada uno, se
puede escribir la siguiente consulta:
SELECT struct(nombre:struct(ape1: e.nombre.apellido1,
ape2: e.nombre.apellido2,
nom: e.nombre.nombre pila),
titulos:(SELECT struct(tit: t.titulo,
a~no: t.a~no,
esc: t.escuela)
FROM t in e.titulos)
FROM e in departamentoinf.director.tutoriza;
OQL es ortogonal respecto a la especificaci´on de expresiones de caminos: atributos,
relaciones y operaciones (m´etodos) pueden ser utilizados en estas expresiones, siempre que
el sistema de tipos de OQL no se vea comprometido. Por ejemplo, para obtener los nombres
y apellidos de los estudiantes que tutoriza la profesora ‘Gloria Mart´ınez’, ordenados por su
nota media, se podr´ıa utilizar la siguiente consulta (el resultado, por estar ordenado, ser´a de
tipo list):
22 5 Sistemas objeto–relacionales
SELECT struct(ape1: e.nombre.apellido1,
ape2: e.nombre.apellido2,
nom: e.nombre.nombre pila,
media: e.nota media)
FROM e in estudiantes graduados
WHERE e.tutor.nombre pila=`Gloria'
AND e.tutor.apellido1=`Mart¶³nez'
ORDER BY media DESC, ape1 ASC, ape2 ASC;
OQL tiene adem´as otras caracter´ısticas que no se van a presentar aqu´ı:
Especificaci´on de vistas dando nombres a consultas.
Obtenci´on como resultado de un solo elemento (hasta ahora hemos visto que se devuelven
colecciones: set, bag, list).
Uso de operadores de colecciones: funciones de agregados (max, min, count, sum, avg)
y cuantificadores (for all, exists).
Uso de group by.
No hay comentarios:
Publicar un comentario