Programacin Orientada a Objetos

OODB Y ODMG
Mayo, 2003

Bases de Datos Orientadas a Objeto

y el estndar ODMG
Clara Martn Sastre
Enrique Medarde Caballero

Informacin de los autores:

Clara Martn Sastre
Facultad de Ciencias Universidad de Salamanca
claroto11@[Link]
Enrique Medarde Caballero
Facultad de Ciencias Universidad de Salamanca
tengounacasaenelcampo@[Link]

Resumen
En este informe tcnico se aborda de una forma introductoria el tema de las bases de datos
orientadas a objetos, haciendo un recorrido temporal sobre sus predecesoras, y analizando las
caractersticas ms significativas de las mismas. As mismo, se realiza un breve estudio de uno
de los estndares que, por el momento, parece ser ms importante de acuerdo con sus
perspectivas de futuro. Hablamos del estndar ODMG. Se afrontar dicho estndar desde el
punto de vista del lenguaje de programacin C++. El motivo que nos ha decidido a elegir este
tema es, que teniendo en cuenta que el entorno de las bases de datos no nos resulta desconocido
y nos interesa, adquirir cierta informacin acerca de lo que puede llegar a establecerse como el
futuro de las mismas, y ms, enfocndolo desde el punto de vista de C++, nos pareca atrayente.
De ah que este informe se dedique a este tema, aunque su tratamiento no sea demasiado
profundo.

DPTOIA-IT-OODB Y ODMG

Abstract
In this technical report we make an introductory approach to object-oriented databases, a
historical overview about their predecessors and a most-significant characteristics analysis. We
also make a brief study of one of the most important standards, which seems to be one with
great future perspectives. We are talking about the ODMG standard. We will aboard this
standard from the C++ programming language side. We have chosen object-oriented databases
because, as we have some notions of databases, getting some information about their future, and
giving it a C++ focus seemed very important to us.

ii

DPTOIA-IT-OODB Y ODMG

Tabla de Contenidos

1.

Introduccin ________________________________________________ 1

2.

Evolucin de las Bases de Datos Orientadas a Objeto _______________ 2

3.

Caractersticas de las OODB ___________________________________ 4

4.

El Sistema Gestor de OODB____________________________________ 6

4.1

Caractersticas Obligatorias: las reglas de Oro ________________ 6

4.1.1

Complejidad de objetos ________________________________ 6

4.1.2

Identidad de los objetos ________________________________ 7

4.1.3

Encapsulacin _______________________________________ 7

4.1.4

Tipos y clases________________________________________ 7

4.1.5

Ocultacin, sobrecarga y ligadura tarda ___________________ 8

4.1.6

Completitud computacional_____________________________ 8

4.1.7

Extensibilidad _______________________________________ 8

4.1.8

Persistencia _________________________________________ 9

4.1.9

Gestin de almacenamiento secundario____________________ 9

4.1.10 Concurrencia ________________________________________ 9

4.1.11 Recuperacin ________________________________________ 9
4.1.12 Facilidad de consultas ad hoc ___________________________ 9
4.2

4.3

Caractersticas opcionales ________________________________ 10

4.2.1

Herencia Mltiple ___________________________________ 10

4.2.2

Comprobacin de tipos e inferencia de tipos_______________ 10

4.2.3

Distribucin ________________________________________ 10

4.2.4

Diseo de Transacciones ______________________________ 10

4.2.5

Versiones __________________________________________ 10

Opciones abiertas _______________________________________ 11

4.3.1

Paradigma de programacin ___________________________ 11

4.3.2

Sistema de representacin _____________________________ 11

4.3.3

Sistema de tipos _____________________________________ 11

4.3.4

Uniformidad _______________________________________ 11

5.

Diferencias entre RDBMS y OODBMS __________________________ 12

6.

Ventajas e inconvenientes de las OODB _________________________ 13

6.1

Ventajas _______________________________________________ 13

6.2

Inconvenientes __________________________________________ 14

DPTOIA-IT-OODB Y ODMG

iii

7.

El estndar ODMG __________________________________________ 14

7.1

El modelo de objetos _____________________________________ 15

7.2

Objetos ________________________________________________ 15

7.3

Literales _______________________________________________ 16

7.4

Tipos __________________________________________________ 17

7.5

Propiedades ____________________________________________ 18

7.6

Operaciones ____________________________________________ 19

7.7

El Lenguaje de definicin de objetos ODL ___________________ 19

7.8

El Lenguaje de manipulacin de objetos OML _______________ 25

7.9

7.8.1

Borrado de objetos___________________________________ 26

7.8.2

Modificacin de objetos ______________________________ 26

El lenguaje de consulta de objetos OQL _____________________ 26

8. Conclusiones _____________________________________________ 29
9. Bibliografa ______________________________________________ 30

iv

DPTOIA-IT-OODB Y ODMG

Tabla de Figuras
1.

Figura 1____________________________________________________ 3

2.

Figura 2____________________________________________________ 3

3.

Figura 3___________________________________________________ 12

DPTOIA-IT-OODB Y ODMG

1.

Introduccin

En este apartado trataremos de abordar la idea de lo que son las bases de datos orientadas a
objetos (Object-Oriented DataBases, OODB). Para ello, realizaremos un recorrido a lo largo de
la evolucin de los sistemas de almacenamiento y manejo de informacin, puesto que quiz esto
nos ayude a comprender mejor el papel de las OODB en la actualidad.
En un primer momento, los sistemas de manejo de datos se reducan exclusivamente a
realizar operaciones comunes sobre ficheros de todo tipo, independientemente de la informacin
que stos almacenasen. El lenguaje de programacin COBOL introdujo en este mbito un
conjunto de estructuras que distinguan una parte referida a los datos y ficheros que se iban a
utilizar y otra, referida a las acciones que se podan realizar sobre ellos. En el momento que este
sistema se qued pequeo ante las necesidades de modelado de estructuras ms complejas que
requeran tratar datos de diferentes ficheros de forma conjunta, surgi el concepto de base de
datos.
Aparecieron as un lenguaje de descripcin de datos (DDL) y un lenguaje de manipulacin
de datos (DML), que sentaron las bases de los sistemas de bases de datos en red. El modelo de
datos subyacente presentaba la base de datos como una red de nodos constituidos por tipos de
registros y cuyos arcos representaban relaciones uno-a-muchos entre ellos.
Otro modelo, al igual que el de red, de tipo navegante, era el modelo jerrquico. En dicho
modelo slo se permitan dos roles entre los tipos de registros: el de padre de una relacin
uno-a-muchos, y el de hijo. De esta forma, la informacin queda estructurada esta vez en
forma de rbol y no de grafo como en el modelo en red. El hecho de que ambos modelos fueran
de tipo navegante, significaba que un usuario interesado en acceder a un registro de la base de
datos deba partir de un registro antecesor e ir recorriendo, a travs de las relaciones del mismo,
diversos registros hasta llegar al deseado. Es ms, las relaciones que un determinado registro
mantena con otros, eran almacenadas de forma explcita en dicho registro, lo que en definitiva
significaba que no exista independencia fsica y, por tanto, la visin que el usuario tena de la
base de datos reflejaba perfectamente la forma en que los datos estaban almacenados. Esta
caracterstica mermaba notablemente cualidades como la portabilidad, la extensibilidad y el
mantenimiento de la propia base de datos como de las aplicaciones destinadas a la misma.
Ante los problemas que de por s presentaban las bases de datos navegacionales y la
dificultad de manejo de grandes bancos de datos, T. Codd present en 1970 el modelo de bases
de datos relacional. Este modelo, per s, presenta una serie de ventajas respecto a los anteriores,
como por ejemplo que los lenguajes de consulta son ms declarativos, de forma que se puede
especificar a la base de datos lo que se requiere en un lenguaje de alto nivel, en lugar de hacerlo
a travs de los requerimientos de acceso de la misma. Por otra parte, el modelo se fundamenta
en conceptos matemticos, como el lgebra Relacional y el Clculo de Predicados. Adems,
resulta mucho ms elegante, flexible y cmodo que los anteriores, lo que le proporcion gran
popularidad durante los aos 80 y 90.
El origen de las bases de datos orientadas a objetos se encuentra en el hecho de que existen
problemas para representar cierta informacin, puesto que los modelos clsicos permiten
representar gran cantidad de datos, pero las operaciones que permiten realizar sobre ellos son
bastante simples. Por ejemplo, consultas ms complejas donde se especifican relaciones de tipo
recursivo (ser padre de, ser jefe de), no se pueden desarrollar de forma natural en estos sistemas:
requieren estructuras de representacin ms complejas que adems hacen uso de elementos
activos proporcionados por los lenguajes de programacin. Otro de los problemas que dan
origen a este tipo de bases de datos radica en el hecho de que se trate de representar informacin
que no se adapte a los modelos de registro, sino dicha informacin se da mediante reglas lgicas
que responden al conocimiento de un experto.

-1-

Bases de Datos Orientadas a Objetos y el estndar ODMG

Por tanto, las bases de datos orientadas a objetos surgen para tratar de paliar las
deficiencias de los modelos anteriores y con el objetivo de proporcionar eficiencia y sencillez.
Las clases utilizadas en un determinado LPOO son las clases que sern utilizadas en una
OODB; esto se debe a la consistencia de los modelos, de tal forma, que no es necesaria una
transformacin del modelo de objetos para que pueda ser utilizado por un gestor de OODB. De
forma contraria, el modelo relacional, requera una abstraccin suficiente como para ser capaces
de confinar objetos del mundo real en tablas.
Por tanto, antes de comenzar con algunos de los conceptos implcitos en el mbito de las
bases de datos orientadas a objeto es necesario que se pongan de manifiesto algunas de las
razones por las cuales se justifica su necesidad. Generalmente, el uso de OODB es ms
ventajoso si se presenta en alguno de los siguientes escenarios:
Un gran nmero de tipos de datos diferentes
Un gran nmero de relaciones entre los objetos
Objetos con comportamientos complejos
Las reas de aplicacin donde existe este tipo de complejidad acerca de tipos de datos,
relaciones entre objetos y comportamiento de los objetos incluyen ingeniera, manufacturacin,
simulaciones, automatizacin de oficina y un elevado nmero de sistemas de informacin. Sin
embrago, stas no son las nicas reas donde las OODB pueden utilizarse, puesto que al ofrecer
la misma funcionalidad que su precursor relacional, esos campos tienen la posibilidad de
aprovechar completamente la potencia que las OODB ofrecen para modelar situaciones del
mundo real.

2.

Evolucin de las Bases de Datos Orientadas a

Objeto

Las bases de datos orientadas a objetos (OODB) datan de los encuentran su origen en la dcada
de los aos 70, aunque no es hasta comienzo de los aos 80 cuando empiezan a adquirir un gran
significado. Es a finales de esta dcada el momento en el que aparecen los primeros productos
comerciales.
Los OODBMS (Object Oriented Data Base Management System) se han establecido
fuertemente en reas como el e-commerce, la ingeniera de gestin de datos, y en bases de datos
de propsito especial, como en seguridad y en medicina.
La fuerza del modelo de objetos radica en aplicaciones donde existe una necesidad
imperante y subyacente de trabajar con relaciones complejas entre los objetos de datos. De esta
manera, las OODB ya no suponen una amenaza para el modelo relacional, ya que el mercado
se ha dividido, de tal manera que el modelo relacional se dedica a datos de poco volumen y no
demasiada complejidad, mientras que el modelo orientado a objetos acoge grandes volmenes y
relaciones complejas entre los datos.

OODB Y ODMG

Clara Martn Sastre y Enrique Medarde Caballero

Figura 1: Evolucin de las Bases de Datos

Se puede observar que el camino que han tomado las bases de datos orientadas a objetos es
muy similar al seguido por las bases de datos relacionales: desde una funcionalidad mnima,
hasta el manejo de grandes volmenes de datos y relaciones de bastante complejidad entre ellos,
pasando por un estadio intermedio que cubre casi todas las caractersticas de las bases de datos
comunes, permitiendo el manejo de volmenes y relaciones razonablemente complejos.

Figura 2: Relacin complejidad funcionalidad en las OODB

OODB Y ODMG

Bases de Datos Orientadas a Objetos y el estndar ODMG

Los productos de la fase media-avanzada, son ya capaces de resolver el desarrollo de

aplicaciones que gestionan datos de cierta complejidad. Los productos de semntica declarativa
poseen la habilidad de reducir los esfuerzos de desarrollo, as como reforzar la uniformidad en
la aplicacin con esta semntica.
Hoy da, los OODBMS se encuentran en la fase media-avanzada. Existen productos que
exhiben semntica declarativa, como restricciones, reglas de integridad referencial y
capacidades de seguridad. El siguiente paso es ms complejo; a medida que se avanza en la
evolucin, la base de datos ha de hacer ms por el usuario, requiriendo menos esfuerzo para el
desarrollo de aplicaciones. Por ejemplo, el desarrollo de interfaces de bajo nivel para optimizar
el acceso a la base de datos.
Una forma general de establecer la madurez de la base de datos es mediante el grado en
que funciones como la optimizacin del acceso, reglas de integridad, esquemas y potabilidad de
la base de datos, archivos, copias de seguridad y operaciones de recuperacin, pueden ser
configuradas por el usuario utilizando comandos de declaracin de alto nivel hacia el
OODBMS. Otro signo de madurez es el establecimiento de grupos industriales para el
establecimiento de estndares en diferentes aspectos de la tecnologa. Hoy se aprecia un
significativo inters en el desarrollo de estndares para las bases de datos orientadas a objetos.
De esta forma, destacan OMG, ODMG, X3H7.
En la actualidad, los vendedores de OODBMS aaden ms caractersticas a sus productos
para proveer la funcionalidad que se podra esperar de un gestor de bases de datos maduro.

3.

Caractersticas de las OODB

La tecnologa utilizada en OODB es la consumacin de la programacin orientada a objetos y la

tecnologa de bases de datos. Muchos de los propsitos de las OODB son los mismos que los de
las bases de datos tradicionales gestin del almacenamiento en memoria secundaria
(indexacin, clustering, buffering, optimizacin), concurrencia y recuperacin-, pero con la
ventaja adicional de poder representar modelos de datos ms complejos en un marco mucho ms
eficiente. Con este objetivo, lo que se ha hecho es aplicar el modelado de objetos a las bases de
datos convencionales. El rasgo ms caracterstico de esta tecnologa quiz sea precisamente su
capacidad para combinar estos dos aspectos anteriormente citados, con el fin principal de
proporcionar un sistema integrado de desarrollo de aplicaciones.
El hecho de incluir la definicin de operaciones, caracterstica propia de la orientacin a
objetos, con la definicin de datos, lleva consigo una serie de ventajas. Una de ellas es que las
operaciones definidas se aplican de forma ubicua y de forma independiente a la aplicacin de
bases de datos particular que se est ejecutando en ese momento.
Otra de las ventajas a las que nos referimos radica en que los tipos de datos pueden ser
extendidos para soportar datos complejos, como multimedia, por ejemplo, definiendo nuevas
clases de objetos que tienen operaciones para soportar dichos nuevos tipos de datos.
Otros puntos fuertes del modelado orientado a objetos ya son bien conocidos. Por ejemplo,
la herencia, permite desarrollar soluciones a problemas complejos de forma incremental,
definiendo nuevos objetos a partir de los ya definidos. Proporciona a las subclases la habilidad
de participar en la transmisin / manipulacin de datos y mtodos de acceso dentro del mbito
de su jerarqua. Mediante la herencia, problemas complejos son representados de una forma ms
fiel e intuitiva que facilita la reutilizacin de cdigo y parte de las especificaciones de
aplicaciones.
El polimorfismo y la ligadura dinmica, permiten definir operaciones para un objeto y
posteriormente compartir esa especificacin con otros objetos. Estos objetos pueden luego

OODB Y ODMG

Clara Martn Sastre y Enrique Medarde Caballero

extender esa operacin para proporcionar comportamientos que son nicos para dichos objetos.
El polimorfismo consta de sobrecarga y ocultamiento, con el objetivo de generar una interfaz,
mltiples mtodos. Concretamente, la sobrecarga posibilita que un simple mtodo sea
implementado de diferentes maneras en diferentes momentos de tiempo, normalmente
diferenciados por los parmetros que cada implementacin requiere. El ocultamiento permite la
redefinicin de implementaciones que tiene lugar con la variacin de los tipos. Junto a estos dos
principios de la orientacin a objeto, aparece la ligadura dinmica que determina, en tiempo de
ejecucin, cual de esas operaciones se ejecuta realmente, dependiendo de la clase del objeto
requerido para llevar a cabo la operacin. Estos tres rasgos constituyen caractersticas poderosas
de la orientacin a objetos, que permiten componer objetos para proporcionar soluciones sin
tener que escribir cdigo especfico para cada objeto. Permiten que el cdigo sea representativo
de un determinado dominio sin quedar reducido al mbito limitado de un objeto determinado.
Otra de las caractersticas bsicas de las bases de datos orientadas a objetos es la
persistencia. Desde el punto de vista de las bases de datos, sobre todo, del de la programacin,
es evidente que el modelo orientado a objetos es bastante extrao. Lo que la persistencia
proporciona principalmente es el hecho de que los datos sobrevivan a la ejecucin del objeto
creado con el fin de ser reutilizados posteriormente en otro proceso. Para aliviar los problemas
que surgen de los sistemas relacionales como son la dificultad para mantener la integridad y la
barrera de comunicacin, la persistencia posibilita que el lenguaje de programacin y la base de
datos posean el mismo modelo y adems, que el programa tenga posibilidad de manipular datos
transitorios y datos persistentes de la misma forma. De esta manera, el problema del aislamiento
entre la aplicacin y la base de datos se elimina directamente, puesto que se posibilita una
interaccin inmediata con la base de datos a travs de la persistencia. Segn Bancilhon, las tres
reglas bsicas de dicha interaccin son las siguientes:

El modelo de base de datos y es lenguaje de programacin del sistema son el

mismo.

Los datos se dividen en datos transitorios y datos persistentes. El modelo de

persistencia permite a los programas manipular datos persistentes y datos
transitorios. Los datos persistentes se actualizan mediante transacciones una vez que
se han comprometido (commit), as como los datos transitorios tienen una existencia
de duracin igual a la del programa.

El programa puede operar de la misma manera tanto con datos transitorios

como con datos persistentes.

En definitiva, el modelo de persistencia unifica la aplicacin y su correspondiente base de

datos insistiendo en operaciones globales que actan indiferentemente sobre todos los datos, un
lenguaje de interfaz comn y una divisin reconocible entre datos transitorios y datos
persistentes.
La identificacin de los objetos es otra de las caractersticas esenciales en una base de
datos orientada a objetos. Los objetos, por s mismos, poseen una identidad independiente de su
estado actual. Por ejemplo, si tenemos un objeto coche y remodelamos dicho coche y
cambiamos su apariencia el motor, la transmisin, las ruedas de forma que parezca
totalmente diferente, todava ser reconocido como el objeto que tenamos originalmente. De
esta forma, dentro de una OODB, siempre se puede realizar la pregunta este es el mismo objeto
que tena previamente?, asumiendo que uno recuerda la identidad del objeto. La identidad del
objeto siempre permite a los objetos estar relacionados y compartidos dentro de una red
distribuida de ordenadores. La identidad de los objetos establece relaciones entre objetos,
adems de una forma de navegar sin la estructura de la base de datos. A esto sigue que dos
objetos pueden ser idnticos o que dos objetos pueden ser iguales. Como resultado, esto da lugar
a dos implicaciones: la comparticin de objetos y la actualizacin de objetos.

OODB Y ODMG

Bases de Datos Orientadas a Objetos y el estndar ODMG

La comparticin de objetos se basa en la idea de que dos objetos pueden compartir un

componente o elemento de datos. En cuanto a la actualizacin de datos, se refiere a todos
aquellos objetos que comparten componentes o elementos de datos, puesto que stos requerirn
una actualizacin consecuente. Las ventajas de mantenimiento en este aspecto se deben a la
identificacin de objetos.
En cuanto a la encapsulacin, propia del paradigma orientado a objetos, podemos decir
que en el mbito de las bases de datos orientadas a objetos, provee de independencia a los datos
donde la implementacin de las clases pude ser alterada sin la necesidad de alterar otros
mtodos.
Adems, es primordial que la base de datos sea extensible. Debe proveer de un soporte para
la definicin de nuevos objetos y mtodos que operen con los objetos ya existentes.
Una diferencia significativa entre las OODB y las bases de datos relacionales es que las
primeras representan las relaciones de forma explcita, soportando ambos modelos de bases de
datos el acceso navegacional y asociativo a la informacin. A medida que la complejidad de las
relaciones entre la informacin se va incrementando, se hacen evidentes las ventajas de
representar las relaciones de forma explcita. Otro beneficio del uso de relaciones explcitas est
en la mejora en la realizacin del acceso a los datos, sobre todo en comparacin con el acceso
que se realiza en el mbito relacional.

4.

El Sistema Gestor de OODB

En este apartado nos dedicaremos a exponer cules son las caractersticas que debe poseer un
Sistema Gestor de Bases de Datos Orientadas a Objetos (OODBMS). Para ello, nos basaremos
en The Object-Oriented Database System Manifesto, propuesto por Malcolm Atkinson. En
dicho manifiesto se hace una distincin de las caractersticas que de debe poseer todo sistema
orientado a objetos, dividindolas en tres grupos: aquellas que el sistema est obligado a
cumplir para ser cualificado como un sistemas de bases de datos orientado a objetos, aquellas
que son opcionales y que pueden ser aadidas con el fin de hacer el sistema ms eficiente y, por
ltimo, las opciones abiertas, en las cuales el diseador puede hacer el nmero de cambios que
desee. Detallaremos los tres grupos a continuacin:

4.1 Caractersticas obligatorias: las reglas de Oro

Todo sistema de bases de datos orientado a objetos debe satisfacer dos criterios: ser un
DBMS y ser un sistema orientado a objetos. El primero de los dos se reduce a cinco
caractersticas: persistencia, gestin de almacenamiento secundario, concurrencia,
recuperacin y facilidad en la realizacin de consultas. El segundo se traduce en las
siguientes caractersticas: objetos complejos, identificacin de objetos, encapsulacin,
tipos o clases, herencia, ocultamiento combinado con ligadura tarda, extensibilidad y
completitud computacional.

4.1.1 Complejidad de objetos

El OODBMS deber soportar objetos complejos. Los objetos complejos se
construyen a partir de los objetos simples como enteros, caracteres, cadenas de
bytes, booleans o coma flotantes, aplicando constructores sobre ellos. Los
constructores mnimos que todo sistema debe tener son conjuntos, listas y
tuplas. Los conjuntos son esenciales porque ellos aportan una manera natural de
representar colecciones del mundo real. Las tuplas son crticas porque

OODB Y ODMG

Clara Martn Sastre y Enrique Medarde Caballero

proporcionan un mtodo natural para presentar propiedades de una entidad. Las

listas o los arrays tienen la ventaja de capturan el orden, como ocurre en
numerosas ocasiones en el mundo real. Los constructores de objetos deben ser
ortogonales: un constructor debe aplicarse a algn objeto. En el modelo
relacional, los constructores no eran ortogonales, puesto que el constructor de
conjuntos slo se poda aplicar a tuplas y el constructor de tuplas slo se
aplicaba a valores atmicos. Se ha de tener en cuenta que el manejo de objetos
complejos requiere el uso de unos operadores adecuados. Dichos operadores
deben propagar de forma transitiva las operaciones que efecten sobre todos los
componentes del objeto.

4.1.2 Identidad de los objetos

Sobre esta caracterstica, ya comentada en apartados anteriores cabe destacar en
esta ocasin que en todo modelo con identificacin de objetos, un objeto tiene
una existencia independiente de su valor. Existen dos nociones a tener en
cuenta: dos objetos pueden se idnticos (son el mismo objeto) o dos objetos
pueden ser iguales (tienen el mismo valor). Esto tiene dos implicaciones que ya
hemos comentado: la comparticin de objetos y la actualizacin de objetos.

4.1.3 Encapsulacin
La idea de encapsulacin tiene su origen en la necesidad de hacer una distincin
clara entre la especificacin y la implementacin de las operaciones y la
necesidad de modularidad. Existen dos puntos de vista de la encapsulacin: el
punto de vista del lenguaje de programacin y la adaptacin de la base de daros
a dicho punto de vista. Desde el punto de vista de los lenguajes de
programacin, un objeto posee una interfaz y una implementacin. La
implementacin tiene una parte de datos, que representa el estado del objeto y
una parte procedural, que describe la implementacin de las operaciones. El
punto de vista de las bases de datos de este principio, mantiene que un objeto
encapsula ambos, programa y datos.
La encapsulacin proporciona independencia lgica de los datos: podemos
cambiar la implementacin de un tipo sin cambiar nada de las aplicaciones que
hacen uso de ese tipo. Podemos decir que hemos alcanzado las posibilidades
que nos ofrece la encapsulacin si slo son visibles las operaciones y su
implementacin y los datos se esconden en los objetos.

4.1.4 Tipos y clases

El OODBMS debe soportar tipos o clases. Un tipo en un sistema orientado a
objetos, hace referencia a un conjunto de objetos con las mismas caractersticas.
Se corresponde con la nocin de tipo abstracto de datos. Se distinguir una
parte de implementacin y una parte de interfaz. En los lenguajes de
programacin, los tipos son herramientas que incrementan la productividad de
la programacin, facilitando su correccin. La tipificacin de la informacin
facilita que los tipos sean chequeados en tiempo de compilacin, y por tanto, la
correccin de los programas.
La nocin de clase es diferente. La especificacin es igual que la de los
tipos, pero aplicada ms en tiempo de ejecucin. Contiene dos aspectos: la clase

OODB Y ODMG

Bases de Datos Orientadas a Objetos y el estndar ODMG

como fbrica de objetos y la clase como almacn. La fbrica de objetos se usa

para crear nuevos objetos y el almacn se refiere a la clase y su extensin, es
decir, el conjunto de objetos que son instancia de la clase. Las clases no se
utilizan para chequear la correccin de los programas, sino para crear y
manipular objetos.
Es evidente que existen fuertes similitudes entre clases y tipos. La cuestin
es cual debe ser la eleccin en un sistema. Lo que s es cierto es que todo
sistema debe ofrecen un mecanismo de soporte para datos estructurados, sean
clases o tipos.

4.1.5 Ocultamiento, sobrecarga y ligadura tarda

El OODBMS no debe permitir una ligadura prematura. Nosotros debemos
poder redefinir la implementacin de una determinada operacin por cada uno
de los tipos que la utilizan. A esto se le denomina ocultamiento. El resultado de
esto es que un mismo nombre puede definir un nmero indefinido de
implementaciones, a lo que se llama sobrecarga. El sistema ser el encargado de
determinar cual es la implementacin apropiada en cada momento. La
caracterstica ms importante es que esta eleccin se realizar en tiempo de
ejecucin. A esto es a lo que se llama ligadura tarda.

4.1.6 Completitud computacional

El OODBMS debe ser computacionalmente completo. Desde el punto de vista
de los lenguajes de programacin, esta propiedad es obvia: simplemente
significa que se pude expresar cualquier funcin computable, usando el DML
del sistema de bases de datos. Desde el punto de vista de las bases de datos es
una novedad, desde que SQL no es completo. No es necesario que los
diseadores de lenguajes diseen nuevos lenguajes; la completitud
computacional se puede introducir a travs de los de una conexin razonable
con los lenguajes de programacin existentes. Debe tenerse en cuenta que no es
lo mismo la completitud en cuanto a recursos se refiere, puesto que esto
significa tener acceso a todos lo recursos del sistema a travs del lenguaje. Un
sistema computacionalmente completo no tiene por qu expresar una aplicacin
completa, sin embargo, si proporciona ms potencia que un sistema que slo
almacena y proporciona datos y permite computaciones simples sobre valores
atmicos.

4.1.7 Extensibilidad
El OOBDMS debe ser extensible. El OODBMS posee una serie de tipos
predefinidos, que pueden ser utilizados por los programadores para crear sus
aplicaciones. Este conjunto de tipos debe ser extensible en los siguientes
aspectos: debe permitir la definicin de nuevos tipos y no debe haber distincin
en el uso de los tipos predefinidos y aquellos definidos por el usuario, por lo
menos desde el punto de vista de las aplicaciones y sus programadores, aunque
el uso que el sistema hace de ellos si que implica ciertas diferencias.

OODB Y ODMG

Clara Martn Sastre y Enrique Medarde Caballero

4.1.8 Persistencia
El sistema debe recordar sus datos. Este requerimiento es evidente desde el
punto de vista de las bases de datos, pero es una novedad desde el punto de
vista de los lenguajes de programacin. Ya se ha comentado anteriormente en
este texto en qu consiste la persistencia, por ello slo aadiremos ciertos
aspectos como los que se citan a continuacin. La persistencia debe ser
ortogonal, esto es, cada objeto, independientemente de su tipo, puede ser
persistente. Adems debe estar implcito el hecho de que el usuario no tiene que
hacer nada para que el dato sea persistente.

4.1.9 Gestin del almacenamiento secundario

El OODBMS debe gestionar extensas bases de datos. La gestin del
almacenamiento en memoria secundaria es una caracterstica clsica de los
sistemas gestores de bases de datos. Esto se consigue a travs de diversos
mecanismos, que incluyen la gestin de ndices, clustering de datos, buffering
de datos, acceso a travs de la seleccin del camino y la optimizacin de
consultas. Ninguno de ellos es visible para el usuario, lo que significa que se
establece una clara independencia entre el nivel lgico y el nivel fsico del
sistema.

4.1.10 Concurrencia
El OODBMS debe aceptar usuarios concurrentes. Ante una situacin en la que
el sistema tenga que gestionar mltiples usuarios interaccionando con l, debe
proporcionar los mismos servicios que los sistemas de bases de datos
concurrentes. Debe aportar una coexistencia armoniosa entre los usuarios que
trabajen simultneamente en la base de datos. El sistema debe soportar la
nocin de atomicidad de una secuencia de operaciones. De este modo la
serializacin de operaciones debe ofrecerse, as como otro tipo de alternativas.

4.1.11 Recuperacin
El OODBMS debe ser capaz de recuperarse de fallos de hardware y software.
El sistema debe proporcionar el mismo nivel de servicios que los sistemas de
bases de datos concurrentes. En caso de fallos de hardware o software, el
sistema debe recuperarse, es decir, volver a un estado coherente de los datos.

4.1.12 Facilidad de consultas ad hoc

El OODBMS debe proporcionar una manera sencilla de consulta de datos. El
problema es proporcionar la funcionalidad de un lenguaje de consultas ad hoc.
No se requiere que las consultas se realicen de la manera que lo hace un
lenguaje de consulta, pero si que se consiga el mismo servicio. Dicho servicio
consiste en permitir al usuario realizar simples consultas a la base de datos. La
cuestin es tomar un nmero de consultas relacionales representativas y
determinar cuales de ellas pueden comenzarse con la misma cantidad de
trabajo. Esta facilidad puede llevarse a cabo mediante DML.
La facilidad de consulta debe satisfacer los tres siguientes criterios: (1)
debe ser de alto nivel, es decir, en pocas palabras debe ser declarativa y
9

OODB Y ODMG

Bases de Datos Orientadas a Objetos y el estndar ODMG

enfatizar el qu se quiere consultar y no el cmo. (2) Debe ser eficiente, lo que

significa que la propia formulacin de la consulta lleve implcita la
optimizacin de la misma. (3) Debe ser independiente de la aplicacin, lo que
significa que debe poder llevarse a cabo en cualquier base de datos.

4.2 Caractersticas opcionales

Las caractersticas que se expondrn a continuacin perfeccionan el sistema, pero no
hacen a un sistema gestor orientado a objetos. Algunas de ellas tienen origen en el
paradigma orientado a objetos y se incluyen en esta categora porque contribuyen a que
un sistema sea ms orientado a objetos. Otras caractersticas son simplemente
caractersticas de las bases de datos que normalmente perfeccionan las funcionalidad
del sistema y estn orientadas a un aspecto ms tecnolgico, como facilitar la creacin
de nuevas aplicaciones tipo CAD / CAM, CASE y automatizacin de oficina.

4.2.1 Herencia Mltiple

Es opcional en los sistemas proporcionar herencia mltiple. Se considera
opcional desde que no existe un acuerdo en la comunidad de la orientacin a
objeto sobre esta caracterstica.

4.2.2 Comprobacin de tipos e inferencia de tipos

El grado de comprobacin de tipos que realiza el sistema en tiempo de
compilacin se deja abierto, pero cuanto ms mejor. La situacin ptima es
aquella en la que un programa que ha sido aceptado por el compilador no
produce errores de ejecucin. En cuanto a la inferencia de tipos, est abierta al
diseador del sistema: la situacin ideal es aquella en la que slo los tipos base
han de ser declarados y el sistema infiere los tipos temporales.

4.2.3 Distribucin
Esta caracterstica es ortogonal a la naturaleza orientada a objetos del sistema.
De ah, que el sistema de bases de datos sea distribuido o no.

4.2.4 Diseo de transacciones

En la mayora de las nuevas aplicaciones, el modelo clsico de transacciones de
negocio para sistemas de bases de datos orientadas a objeto no es satisfactorio,
puesto que las transacciones tienden a ser muy extensas y el criterio de
serializacin actual no es adecuado. Por ello, algunos OODBMS dan soporte al
diseo de transacciones

4.2.5 Versiones
Muchas de las nuevas aplicaciones (CAD / CAM y CASE) se envuelven en una
actividad de diseo y requieren diferentes formas de versionado. Por ello,
muchos OODBMS soportan versiones. De nuevo, proveer al sistema de

OODB Y ODMG

10

Clara Martn Sastre y Enrique Medarde Caballero

mecanismos de versionado no constituye una parte de los requerimientos del

ncleo del sistema.

4.3 Opciones abiertas

Cualquier sistema que satisface las reglas de oro, pude etiquetarse como un sistema
de bases de datos orientado a objetos. A pesar de ello, quedan a la libre eleccin de los
implementadores muchas opciones de diseo. Estas caractersticas se diferencian de las
primeras en el sentido de que no existe un consenso alcanzado por la comunidad
cientfica sobre ellas. Difieren de las caractersticas opcionales en que nosotros no
sabemos cuales de ellas hacen al sistema ms o menos orientado a objetos.

4.3.1 Paradigma de programacin

No existe razn por la cual se deba imponer un paradigma de programacin por
encima de otro: el estilo lgico de programacin, el estilo funcional de
programacin, o el estilo imperativo de programacin pueden elegirse como
paradigmas de programacin. Otra solucin es que el sistema se independiente
del estilo de programacin y soporte mltiples paradigmas. Por supuesto, la
eleccin de la sintaxis es libre, y la gente puede discutir indefinidamente sobre
cual elegir.

4.3.1 Sistema de representacin

El sistema de representacin se define mediante un conjunto de tipos y un
conjunto de constructores. Desde el momento que se tenga un conjunto minimal
de tipos atmicos y constructores (tipos elementales de los lenguajes de
programacin, conjuntos, tuplas y constructores de listas) suficientes para
describir la representacin de objetos, pueden extenderse de diferentes formas.

4.3.2 Sistema de tipos

Existe tambin libertad respecto a la formacin de tipos. La nica facilidad que
se requiere en la formacin de tipos es la encapsulacin. Pueden existir otros
formadores de tipos como los tipos genricos o los generadores de tipos,
restricciones, uniones y flechas (funciones).
Otra opcin es que el sistema de tipos sea de segundo orden. Finalmente,
el sistema de tipos para variables debe ser ms rico que el sistema de tipos para
objetos.

4.3.4

Uniformidad
Hay un debate en pie acerca de la uniformidad que se debe esperar en los
sistemas: es un tipo o es un objeto? O es que estas nociones deben ser
tratadas de forma diferente? Podemos analizar este problema desde tres niveles
diferentes: el nivel de implementacin, el nivel de lenguaje de programacin y
el nivel de interfaz.
En el nivel de implementacin se debe decidir si la informacin debe ser
clasificada como objetos o bien si debe implementarse un sistema ad hoc. La

11

OODB Y ODMG

Bases de Datos Orientadas a Objetos y el estndar ODMG

decisin debe tomarse basndonos en las caractersticas y en la facilidad de la

implementacin, independientemente de la decisin tomada a otros niveles.
Al nivel de lenguaje de programacin, la cuestin es la siguiente: son los
tipos entidades clases segn la semntica del lenguaje? Hay diferentes estilos de
uniformidad (sintctica y semntica). Toda uniformidad a este nivel es
inconsistente con el comprobacin esttica de tipos.
Finalmente, en el nivel de interfaz, se debe tomar otra decisin
independiente. Se puede querer presentar la informacin al usuario con un
punto de vista uniforme de los tipos, los objetos y los mtodos, aunque en la
semntica del lenguaje utilizado, sean nociones de naturaleza diferente. En
consecuencia, se pueden presentar como entidades diferentes, siempre que las
vistas que el lenguaje de programacin tenga sobre ellos sean la misma cosa.
Esta decisin se debe tomar basndonos en el criterio humano.

5.

Diferencias entre RDBMS y OODBMS

Se analizarn a continuacin algunas de las diferencias principales entre los Sistemas Gestores
de Bases de Datos Relacionales (RDBMS) y los Sistemas Gestores de Bases de Datos
Orientadas a Objeto (OODBMS). Para ello, se proceder a realizar un anlisis comparativo de
los puntos clave de los sistemas gestores de bases de datos.

Figura 3: Comparacin modelo OO y modelo ER

Como se puede apreciar en la figura, ambos modelos tratan de representar un estudiante

que recibe clases y tiene un consejero. El modelo orientado a objetos es una clase que contiene
dos atributos, Nombre y Ao. As mismo sirve como contenedor de un objeto Consejero y un
objeto Clases. Frente a esto, el otro modelo, Entidad-relacin, presenta tres entidades,
Estudiante, Consejero y Clases y adems, establece dos relaciones entre tablas para representar
la informacin de forma adecuada. Como se puede apreciar, en el modelo relacional se
necesitan dos entidades ms que en el modelo orientado a objetos para establecer las relaciones
que el segundo por si solo ya sugiere.
Los RDBMS buscan una representacin de los datos independiente de las aplicaciones
destinadas a explotar la base de datos. Mientras, los OODBMS persiguen la equivalencia de los
objetos utilizados en la propia base de datos y los objetos utilizados en las aplicaciones que
tratarn con la misma.

OODB Y ODMG

12

Clara Martn Sastre y Enrique Medarde Caballero

La interfaz para las diferentes arquitecturas de los RDBMS es siempre la misma: SQL. Sin
embargo, los OODBMS requieren una API especfica dependiente del lenguaje de
programacin orientada a objetos utilizado en cada caso.
En cuanto a lo que la representacin se refiere, en los RDBMS, sta se efecta mediante
tablas, previamente normalizadas y que cumplen unas determinadas reglas de integridad. Los
OODBMS permiten el empleo de objetos complejos, capaces de albergar colecciones de objetos
y de establecer referencias y relaciones con otros objetos.
Los RDBMS siguen un esquema conceptual correspondiente a bases de datos
empresariales y sus aplicaciones son explotadas a travs de dicho esquema externo. Los
OODBMS se fundamentan en objetos persistentes, que mantienen la misma estructura que los
objetos transitorios.
Por otra parte, los sistemas fundamentados en el modelo relacional permiten iniciar las
consultas a partir de cualquier relacin derivable de las relaciones representadas por las tablas
de la base de datos. Frente a esta postura, en los sistemas basados en la orientacin a objeto es
estrictamente necesario que las aplicaciones conozcan el punto de entrada a la base de datos.

6.

Ventajas e inconvenientes de las OODB

Los OODBMS aportan grandes beneficios sobre los modelos de bases de datos tradicionales,
pero a pesar de ello, poseen puntos dbiles que deben tenerse en cuenta y no pasar por encima.
Por ello, a continuacin analizaremos las ventajas y los inconvenientes de las bases de datos
orientadas a objetos, as como sus limitaciones.

6.1 Ventajas
Las ventajas que ofrecen los OODBMS adquieren gran importancia debido a que stas
resuelven gran parte de los problemas que los sistemas tradicionales no podan resolver.
En primer lugar, la cantidad de informacin que un OODBMS puede manejar es mucho
mayor y adems el modelado de dicha informacin se convierte en una tarea mucho
ms fcil.
Por otra parte, los OODBMS aportan objetos ms complejos, capaces de soportar la
integracin de base de datos multimedia, CAD y otros tipos especializados.
As mismo, poseen capacidades de modelado orientadas a la extensibilidad. Con un
OODBMS, est permitido aadir capacidades de modelado con el objetivo de modelar
sistemas ms complejos. Esta extensibilidad proporciona una solucin para incorporar y
extender futuras bases de datos en el desarrollo.
Hay que sumar a las ventajas de modelado, las ventajas en cuanto al sistema que los
OODBMS aportan. En un OODBMS, el versionado se posibilita, con el fin de ayudar
en los cambios de modelado que se produzcan en el sistema. Mediante el versionado,
est permitido volver a los juegos de datos previos, y comparar los juegos de datos
actuales con ellos.
Otro de los aspectos ventajosos es la reutilizacin de clases, que juega un papel
esencial en lo que a la rapidez en el desarrollo de aplicaciones y su mantenimiento se
refiere. Las clases genricas cuentan con una mayor potencia, pero lo ms importante es
que pueden ser reutilizadas. Desde que las clases pueden ser reutilizadas, el material
redundante no necesita ser diseado, lo que proporciona, como ya se ha dicho, una
mayor facilidad en el desarrollo de aplicaciones y en el mantenimiento de las mismas.

13

OODB Y ODMG

Bases de Datos Orientadas a Objetos y el estndar ODMG

6.2 Inconvenientes
A pesar de que los OODBMS aportan grandes ventajas, los inconvenientes implcitos
tambin son importantes. Los tradicionales sistemas relacionales, debido al tiempo en
que han estado en uso, estn profundamente arraigados y un cambio puede suponer la
prdida de las ideas ya establecidas. Se requiere que las personas adopten una forma de
pensar diferente y, en algunos casos, los usuarios de modelos relacionales no poseen los
fundamentos necesarios de orientacin a objetos necesarios para trabajar con
OODBMS. Educar a las personas en el paradigma orientado a objetos requiere una
cantidad de tiempo considerable, dinero y otro tipo de recursos.
Otra desventaja es que es estrictamente necesaria una forma de comunicacin y una
forma de trabajo conjunta entre los sistemas tradicionales y los OODBMS. Los sistemas
tradiciones y los OODBMS deben entenderse entre ellos y entender las relaciones que
representan. De nuevo, conseguir este objetivo, requiere un coste temporal, monetario y
de recursos. Actualmente, no existe un sistema de comunicacin y comprensin.
Adems, no existe un lenguaje de consulta especfico como SQL. Es curioso que
realizar consultas complejas a un OODBMS sea ms fcil y a pesar de ello, no existe un
lenguaje de consulta para hacerlo. Adems no hay ningn estndar lo suficientemente
establecido para el diseo y la implementacin. La realidad es que los OODBMS son
capaces de resolver los problemas de los sistemas tradicionales, pero para ello es
necesario el establecimiento de un estndar. Si bien es cierto que ODMG (Object
Database Management Group) ha dado una ventana temporal de 2 aos para establecer
una serie completa de estndares desarrollados con la comunidad CPSC.
Por otra parte, los mtodos definidos sin un sistema de bases de datos orientado a
objetos para el diseo de clases establecen una restriccin lgica sobre cmo pueden ser
accedidos y manipulados los datos actuales, haciendo que las consultas realizadas ad
hoc sean difciles de ejecutar sin la OODB. Para ello, The Object Oriented Database
System Manifiesto propone un browser grfico que proporcione la funcionalidad
necesaria para construir consultas simples para el usuario.
En cuanto a la gestin de transacciones, el problema surge debido a que los mtodos
de las OODB a menudo envuelven a una gran cantidad de datos de gran complejidad y
es imperativo no perderlos a la hora de rechazar transacciones (rollback). Para ello, al
igual que en el modelo relacional, se propone el establecimiento de savepoints en las
transacciones de larga duracin que permitan realizar rollbacks parciales. El problema,
sigue siendo determinar donde ponerlos y cundo.

7.

El estndar ODMG

Con el objetivo de definir estndares para los OODBMS se form el grupo ODMG, compuesto
por varios representantes de la industria de bases de datos. Este grupo propuso un modelo
estndar para la semntica de los objetos de una base de datos. La ltima versin del estndar,
ODMG 3.0, propone los siguientes componentes principales de la arquitectura ODMG para un
OODBMS:
-

Modelo de objetos

Lenguaje de definicin de objetos (ODL)

Lenguaje de consulta de objetos (OQL)

OODB Y ODMG

14

Clara Martn Sastre y Enrique Medarde Caballero

Conexin con los lenguajes C++, Smalltalk y Java (al menos)

7.1 Modelo de Objetos

El modelo de objetos ODMG permite que tanto los diseos como las implementaciones, sean
portables entre los sistemas que lo soportan. Cuenta con las siguientes primitivas de modelado:

Los componentes bsicos de una base de datos orientada a objetos son los objetos y los
literales. Un objeto es una instancia autocontenida de una entidad de inters del mundo
real. Los objetos tienen un identificador nico. Un literal es un valor especfico, como
Eustaquio o 27. 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 especfico
compartido por todos los objetos y literales de ese tipo. Los tipos tambin pueden tener
comportamientos. Cuando un tipo tiene comportamientos, todos los objetos de ese tipo
comparten los mismos comportamientos. En el sentido prctico, un tipo puede ser una
clase de la que se crea un objeto, una interfaz 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 operacin puede requerir datos
de entrada (parmetros de entrada) y puede devolver algn 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 mltiples usuarios y aplicaciones.

La definicin de una base de datos est contenida en un esquema que se ha creado

mediante el lenguaje de definicin de objetos ODL (Object Definition Language) que es
el lenguaje de manejo de datos que se ha definido como parte del estndar propuesto
para las bases de datos orientadas a objetos.

7.2 Objetos
Los tipos de objetos de descomponen en atmicos, colecciones y tipos estructurados. Los tipos
estructurados, que derivan de la clase interfaz Collection, son la propuesta del estndar para las
clases contenedor. Entre los tipos coleccin admitidos por el estndar encontramos los
siguientes:
Set<tipo>,
Bag<tipo>,
Dictionary<clave,valor>.

List<tipo>,

Array<tipo>,

En cuanto a los tipos estructurados encontramos los siguientes:

Date, como fecha del calendario.
Time , como hora (hora, minutos y segundos).
Timestamp ,es una hora de una fecha (con precisin de microsegundos).
Interval ,es un periodo de tiempo.

15

OODB Y ODMG

Bases de Datos Orientadas a Objetos y el estndar ODMG

Los objetos se crean utilizando el mtodo new(). Adems, todos heredarn la interfaz que
se muestra a continuacin:
interface Object {
enum Lock Type{read,write,upgrade};
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();};
Cada objeto tiene un identificador de objeto nico dentro del dominio de almacenamiento
del objeto, que es el ODMS, generado por el SGBD, que no cambia y que no se reutiliza cuando
el objeto se borra. Debe notarse que la nocin de identificador de objeto es diferente de la
nocin de clave primaria en el modelo relacional. Una tupla en el modelo relacional se identifica
de forma nica por el valor de la(s) columna(s) que forma(n) su clave primaria. Si el valor de la
columna (o de alguna de ellas) cambia, la tupla cambia su identidad y se convierte en una tupla
diferente. Los valores literales no tienen identificador, sino que estn embebidos en objetos y no
pueden ser referenciados individualmente.
Los objetos pueden ser transitorios o persistentes. Los objetos transitorios existen mientras
vive el programa de aplicacin que los ha creado. Estos objetos se usan tanto como
almacenamiento temporal como para dar apoyo al programa de aplicacin que se est
ejecutando y en el momento que el proceso termina, su espacio es liberado. Los objetos
persistentes son aquellos que se almacenan en la base de datos y su memoria y almacenamiento
son controlados por el sistema de tiempo de ejecucin del ODMS. Estos objetos continan
existiendo an despus de que el procedimiento o proceso que los cre haya terminado.
Un aspecto importante del tiempo de vida de los objetos es que es independiente del tipo
del objeto. Un objeto de un tipo puede tener instancias con un tiempo de vida transitorio y otras
con un tiempo de vida persistente. En el modelo relacional, cualquier tipo conocido por el
DBMS es persistente, y cualquiera no conocido (ej. Cualquier tipo no definido utilizando SQL)
slo tiene instancias transitorias.

7.3 Literales
Los tipos literales se descomponen en atmicos, colecciones, estructurados o nulos. No tienen
identificadores y adems no pueden aparecer solos como objetos, han de estar inmersos en
objetos y no pueden referenciarse de forma individual. Entre los atmicos encontramos los
siguientes:
boolean : un valor que es verdadero o falso.
short : un entero con signo, normalmente de 8 o 16 bits.
long : un entero con signo, normalmente de 32 o 64 bits.
unsigned short : un entero sin signo, normalmente de 8 o 16 bits.
unsigned long : un entero sin signo, normalmente de 32 o 64 bits.
float : un valor real en coma flotante de simple precisin.
double : un valor real en coma flotante de doble precisin.

OODB Y ODMG

16

Clara Martn Sastre y Enrique Medarde Caballero

octet : un almacn de 8 bits.

char : un carcter ASCII o UNICODE.
string : una cadena de caracteres.
enum : un tipo enumerado donde los valores se especifican explcitamente cuando se
declara el tipo.
Los literales estructurados contienen un nmero fijo de elementos heterogneos. 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
coleccin son: set<tipo>, bag<tipo>, list<tipo>, array<tipo> y
dictionary<clave,valor>.

7.4 Tipos
Entre las caractersticas ms importantes del paradigma orientado a objetos encontramos la
capacidad para distinguir la interfaz pblica de una clase de sus elementos privados, a lo que se
conoce como encapsulacin. El estndar al que nos referimos hace esta distincin hablando de
especificacin externa de un tipo y sus implementaciones.
Una interfaz es una especificacin del comportamiento abstracto de un tipo de objeto y
contiene las signaturas de las operaciones. Aunque puede tener propiedades (atributos y
relaciones) como parte de su especificacin, stas no pueden ser heredadas desde la interfaz. Por
otra parte, una interfaz no es instanciable, por lo que no se pueden crear objetos a partir de ella;
la realidad es que es equivalente a una clase abstracta en la mayora de los lenguajes de
programacin.
Una clase es una especificacin del comportamiento abstracto de un tipo de objeto. Las
clases son instanciables, por lo que a partir de ellas se pueden crear instancias de objetos
individuales. En este caso, es equivalente a una clase concreta en los lenguajes de
programacin.
El estndar de ODMG 3.0 soporta la herencia simple y la herencia mltiple mediante las
interfaces, ya que al no ser instanciables, se pueden utilizar para especificar operaciones
abstractas heredables por otras clases o por otras interfaces. A este hecho se le denomina
herencia de comportamiento. Este tipo de herencia requiere que el supertipo sea una interfaz,
mientras que el subtipo podr ser una interfaz o una clase.
La herencia es una relacin es un:
interface ArticuloVenta ...;
interface Mueble : ArticuloVenta ...;
class Silla : Mueble ...;
class Mesa : Mueble ...;
class Sofa : Mueble ...;
Uno de los beneficios prcticos de la herencia es que se puede hacer referencia a los
subtipos como supertipos. Por ejemplo, un programa de aplicacin puede hacer referencia a los
subtipos como supertipo. Por ejemplo, un programa de aplicacin puede hacer referencia a
sillas, mesas o sofs como muebles o incluso como artculos de venta.

17

OODB Y ODMG

Bases de Datos Orientadas a Objetos y el estndar ODMG

Los subtipos se pueden especializar como sea necesario aadindoles comportamientos, a

lo que se llama herencia de estado. Los subtipos de un subtipo especializado heredan tambin
los comportamientos aadidos. El modelo orientado a objetos utiliza las relacin extiende
(extends) para indicar la herencia de estado y de comportamiento. En este tipo de herencia,
tanto el subtipo como el supertipo deben ser clases. Las clases que extienden a otra clase ganan
acceso a todos lo estados y comportamientos del supertipo, incluyendo cualquier cosa que el
supertipo haya adquirido va herencia de otras interfaces. Una clase puede extender como
mximo a otra clase. Sin embargo, si se construye una jerarqua de extensiones, las clases de
ms debajo de la jerarqua heredan todo lo que sus supertipos heredan de las clases que tienen
por encima.
El modelo permite al diseador que declare una extensin (extend) para cada tipo de
objeto definido como una clase. La extensin de un tipo tiene un nombre e incluye todas las
instancias de objetos persistentes creadas a partir de dicho tipo. Declarar una extensin
denominada empleados para el tipo de objeto Empleado es similar a crear un objeto de tipo
Set<Empleado> denominado empleados. Una extensin se puede indexar para que el
acceso a su contenido sea ms rpido.
Una clase con extensin pude tener una o ms claves (key). Una clave es un identificador
nico. Cuando una clave est formada por una sola propiedad, es una clave simple; si est
formada por una o ms propiedades, es una clave compuesta. A diferencia del modelo
relacional, las claves nicas no son un requisito.
Una representacin de un tipo consta de dos partes: la representacin y los mtodos. La
representacin es una estructura de datos dependiente del lenguaje de programacin que
contiene las propiedades del tipo. Las especificaciones de la implementacin vienen de una
conexin con un lenguaje (lenguaje binding). Esto quiere decir que la representacin interna de
un tipo ser diferente dependiendo del lenguaje de programacin que se utilice y de que un
mismo tipo puede tener ms de una representacin.
Los detalles de las operaciones de un tipo se especifican mediante un conjunto de mtodos.
En la especificacin externa de un tipo debe haber al menos un mtodo. Sin embargo un tipo
puede incluir mtodos que nunca se ven desde fuera del tipo. Estos mtodos son los que realizan
algunas funciones necesarias para otros mtodos del tipo.
Los mtodos se escribirn en el mismo lenguaje de programacin utilizado para representar
el tipo. Si una aplicacin soporta aplicaciones programadas en C++, Java y Smalltalk, entones
ser necesario tener tres implementaciones para cada tipo, una para cada lenguaje, aunque cada
programa utilizar slo la implementacin que corresponda.

7.5 Propiedades
El modelo de objetos ODMG define dos tipos de propiedades: atributos y relaciones. Un
atributo se define del tipo de un objeto, define el estado abstracto de sus instancias. Si un objeto
participante en una relacin es borrado, tambin deben borrarse todos los caminos transversales
a ese 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 slo soporta relaciones binarias con
cardinalidad 1:1, 1:n y n:m. Una relacin no tiene nombre y tampoco es un objeto de primera
clase, pero define caminos transversales en la interfaz de cada direccin. En el lado del muchos
de la relacin, los objetos pueden estar desordenados (set o bag) u ordenados (list). La
integridad de las relaciones la mantiene automticamente el SGBD y se genera una excepcin
cuando se intenta atravesar una relacin en la que uno de los objetos participantes se ha borrado.

OODB Y ODMG

18

Clara Martn Sastre y Enrique Medarde Caballero

Es importante notar que el concepto de camino transversal de una relacin no equivale al

concepto de puntero en los lenguajes de programacin, ya que este ltimo no implica la
connotacin de que haya otro camino transversal inverso como en una relacin. El modelo
aporta operaciones para formar (form) y eliminar (drop) miembros de una relacin.
Transacciones
El modelo estndar soporta el concepto de transacciones, que son unidades lgicas 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 estndar de lectura /escritura con un protocolo pesimista de
control de concurrencia. Todos los accesos, creacin, modificacin y borrado de objetos
persistentes se deben hacer dentro de una transaccin. El modelo especifica operaciones para
iniciar, terminar (commit) y abortar transacciones, as como la operacin checkpoint. Esta ltima
operacin hace permanentes los cambios realizados por la transaccin en curso sin liberar
ninguno de los bloqueos adquiridos.

7.6 Operaciones
Junto con los atributos y las propiedades de las relaciones, la otra caracterstica de un tipo es su
comportamiento, que se especifica mediante una serie de prototipos de operaciones. Cada uno
de estos prototipos define el nombre de una operacin, el nombre y tipo de cada uno de sus
argumentos, el tipo de los valores devueltos y los nombres de cualquier excepcin (condiciones
de error) que la operacin puede producir.
Una operacin se define en un nico tipo. No hay nocin en el modelo de objeto de que
una operacin pueda existir fuera de un tipo o que una operacin est definida en dos o mas
tipos. De esa forma, tipos diferentes pueden tener operaciones diferentes definidas con el mismo
nombre (nombres sobrecargados). Cuando se invoca una operacin utilizando un nombre
sobrecargado debe especificarse una operacin concreta para la ejecucin, a esto se le llama
resolucin de nombre de operacin.

7.7 El lenguaje de definicin de objetos ODL

ODL es un lenguaje de especificacin para definir tipos de objetos para sistemas complejos
compatibles con ODMG. Es el equivalente de DDL (Data Definition Languaje o lenguaje de
definicin de datos) de los DBMS tradicionales. Define los atributos y las relaciones entre tipos
y especifica la signatura de las operaciones. La sintaxis de ODL extiende el lenguaje de
definicin de interfaces (IDL) de la arquitectura CORBA (Common Object Request Broker
Architecture).
En concreto. C++ ODL proporciona una descripcin del schema de la base de datos como
un conjunto de clases de objetos incluyendo sus atributos, relaciones y operaciones en un
estilo sintctico que es consistente con la parte de declaracin de un programa en C++. Las
instancias de las clases pueden ser manejadas mediante C++ OML.
Las declaraciones de atributos son sintcticamente idnticas a las declaraciones de
miembros de datos en C++.
Se soportan la sintaxis y la semntica de C++. Sin embargo, las implementaciones no
necesitan soportar los siguientes tipos de datos dentro de las clases persistentes como miembros:

19

Uniones

Campos de bits

OODB Y ODMG

Bases de Datos Orientadas a Objetos y el estndar ODMG

Referencias(&)

Las uniones y los campos de bits dan problemas al soportar diferentes entornos. La
semntica de las referencias es que son inicializadas una vez en su creacin, todas las
operaciones siguientes se dirigen al objeto referenciado. Las referencias a los objetos
persistentes no pueden reinicializarse al llevarlos de la base de datos a la memoria, y su valor de
inicializacin no ser, en general, vlido fuera de los lmites del proceso.
Se muestra el uso de ODL mediante un ejemplo:
class City;
struct Address
{
d_UShort

number;

d_String

street;

d_Ref_<City>

city;

Address();
Address(d_UShort, const char*,const d_Ref<City>&);
};
extern const char _spouse[], _parents[], _children[];
class Person: public d_Object
{
public:
d_String

name;

Address

address;

d_Rel_Ref<Person, _spouse> spouse;

d_Rel_List<Person, _parents> children;
d_Rel_List<Person, _children> parents;
Person(const char *pname);
void birth(const d_Ref<Person> &child);
void marriage(const d_Ref<Person> &to_whom);
d_Ref<d_Set<d_Ref<Person>>> ancestors() const;
void move(const Address &);
static d_Ref<d_Set<d_Ref<Person>>> people;
static cohnst char * const extent_name;
};

OODB Y ODMG

20

Clara Martn Sastre y Enrique Medarde Caballero

class City: public d_Object

{
public:
d_Ulong

city_code;

d_String

name;

d_Ref<d_Set<d_Ref<Person>>>

population;

City(int, const char*);

static d_Ref<d_Set<d_Ref<City>>> cities;
static const char * const

extent_name;

};
//Implementacin del esquema
//Implementacin de las clases en C++
#[Link]
const char _spouse[]=spouse;
const char _parents[]=parents;
const char _children[]=children;
Address::Address(d_UShort pnum, const char *pstreet, const
d_Ref<City> &pcity):
number(pnumber),
street(pstreet);
city(pcity)
{}
Address::Address():

number(0),

street(0),
city(0)
{}
const char * const Person::extent_name=people;
Person::Person(const char * pname): name(pname)
{

21

OODB Y ODMG

Bases de Datos Orientadas a Objetos y el estndar ODMG

people->insert_element(this);
}
void Person::birth(const d_Ref<Person> &child)
{
children.insert_element_last(child);
if(spouse)
spouse->children.insert_element_last(child);
}
void Person::marriage(const d_Ref<Person> &to_whom)
{
spouse=with;
}
d_Ref<d_Set<d_Ref<Person>>> Person::ancestors()
{
d_Ref<d_Set<d_Ref<Person>>> the_ancestors =
new d_Set<d_Ref<Person>>;
int i;
for(i=0;i<2;i++)
if(parents[i])
{
the_ancestors->insert_element(parents[i]);
d_Ref<d_Set<d_Ref<Person>>> grand_parents =
parents[i]->ancestors();
the_ancestors->union_with(*grand_parents);
grand_parents.delete_object();
}
return the_ancestors;
}
void Person::move(const Address &new_address)
{
if([Link])
[Link]->population->remove_element(this);

OODB Y ODMG

22

Clara Martn Sastre y Enrique Medarde Caballero

new_address.city->population->insert_element(this);
mark_modified();
address=new_address;
}
const char * const City::extent_name=cities;
City::City(d_ULong code, const char *cname): city_code(code),
name(cname)
{
cities->insert_element(this);
}
//Una aplicacin
#include<iostream.h>
#[Link]
static d_Database dbobj;
static d_Database * database=&dbobj;
void Load()
{
d_Transaction load;
[Link]();
Person::people=new(database) d_Set<d_Ref<Person>>;
City::cities=new(database) d_Set<d_Ref<City>>;
Database->set_object_name(Person::people,
Person::extent_name);
d_Ref<Person> God, Adam, Eve;
God = new(database,Person)Person(God);
Adam = new(database,Person)Person(Adam);
Eve = new(database,Person)Person(Eve);
Address Paradise(7,Apple,
new(database,City)City(0,Garden));
Adam->move(Paradise);

23

OODB Y ODMG

Bases de Datos Orientadas a Objetos y el estndar ODMG

Eve->move(Paradise);
God->birth(Adam);
Adam->marriage(Eve);
Adam->birth(new(database,Person)Person(Cain));
Adam->birth(new(database,Person)Person(Abel));
[Link]();
}
static void print_persons(const d_Collection<d_Ref<Person>>
&s);
{
d_Ref<Person> p;
d_Iterator<d_Ref<Person>> it = s.create_iterator();
while([Link](p))
{
cout<<---<<p->name<<lives in;
if(p->[Link])
cout<<p->[Link]->name;
else
cout<<Unknown;
cout<<endl;
}
}
void Consult()
{
d_Transaction

consult;

d_List<d_Ref<Person>>

list;

d_Bag<d_Ref<Person>>

bag;

[Link]();
Person::people = database
->lookup_object(Person::extent_name);
City::cities = database
->lookup_object(City::extent_name);
cout<<All the people:<<endl;
print_persons(*Person::people);
OODB Y ODMG

24

Clara Martn Sastre y Enrique Medarde Caballero

cout<<All the people sorted by name:<<endl;

d_oql_execute(select p from people order by name,
list);
print_persons(list);
cout<<People having 2 children and living in
Paradise:<<endl;
d_oql_execute(list, select p from p in people
where [Link] = Garden
and count([Link]) = 2,bag);
print_persons(bag);
Address Earth(13,Macadam,
new(database,City)City(1,[Link]));
d_Ref<Person> Adam;
d_oql_execute(element(select p from p in people
where [Link] = Adam),Adam);
Adam->move(Earth);
Adam->spouse->move(Earth);
Cout<<Cains ancestors:<<endl;
d_Ref<Person> Cain = Adam>children.retrieve_element_at(0);
print_persons(*(Cain->ancestors()));
[Link]();
}
void main(void)
{
database->open(family);
Load();
Consult();
Database->close();
}

7.8 El lenguaje de manipulacin de objetos OML

Un principio bsico para el diseo de OML es que la sintaxis utilizada para crear, borrar,
identificar, referenciar, obtener / modificar los valores de las propiedades e invocar operaciones
sobre objetos persistentes debe ser no muy diferente de la utilizada para los objetos con periodos
de vida ms cortos. Una nica expresin debe poder mezclar libremente referencias a objetos

25

OODB Y ODMG

Bases de Datos Orientadas a Objetos y el estndar ODMG

transitorios y persistentes. Sin embargo, en este estndar, las colas y la consistencia de

transacciones se aplican slo a los objetos persistentes.
Los objetos pueden ser creados, borrados y modificados. Los objetos se crean en OML
utilizando el operador new(), que est sobrecargado para aceptar parmetros adicionales
indicando el periodo de vida del objeto.
(1) void *operator new(size_t size);
(2) void *operator new(size_t size, const
d_Ref_Any&clustering, const char* typename);
(3) void *operator new(size_t size, d_Database *database,
const char* typename);
(1) se utiliza para la creacin de objetos transitorios derivados de d_Object. (2) y (3) crean
objetos persistentes.

7.8.1 Borrado de Objetos

Los objetos, una vez creados, pueden borrarse en OML para C++ utilizando la funcin miembro
d_Ref::delete_object();
La utilizacin del operador delete() sobre un puntero a un objeto persistente tambin
borrar el objeto, al igual que en C++. El borrado de un objeto es permanente. El objeto se quita
de la memoria, y si es un objeto persistente, tambin se elimina de la base de datos.

7.8.2 Modificacin de Objetos

El estado de un objeto se modifica actualizando sus propiedades o invocando operaciones sobre
l. Las actualizaciones realizadas a los objetos persistentes se hacen visibles al resto de usuarios
de la base de datos cuando la transaccin conteniendo la modificacin se comete. El cambio en
el objeto se comunica invocando la funcin miembro
d_Object::mark_modified();
De todas formas, cada vez que un objeto persistente es modificado por una funcin
miembro de actualizacin proporcionada explcitamente por las clases de ODMG, la llamada a
mark_modified() no es necesaria, ya que se hace automticamente.

7.9 El 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 basado en SQL-92, proporcionando un superconjunto
de la sentencia SELECT.
OQL no posee primitivas para modificar el estado de los objetos, ya que stas se deber
realizar a travs de los mtodos que dichos objetos poseen.
La sintaxis bsica de OQL es una estructura SELECT...FROM...WHERE..., como en SQL.
Por ejemplo, la siguiente expresin obtiene los nombres de los departamentos de la escuela de
Ingeniera:

OODB Y ODMG

26

Clara Martn Sastre y Enrique Medarde Caballero

SELECT [Link]
FROM d in departamentos
WHERE [Link] = `Ingeniera';
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 extensin de una clase. En el
ejemplo anterior, el punto de entrada es la extensin departamentos, que es un objeto coleccin
del tipo set<Departamento>. Cuando se utiliza una extensin como punto de entrada es
necesario utilizar una variable iteradora que vaya tomando valores en los objetos de la
coleccin. Este tipo de variables 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 coleccin 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 Informtica), 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 caminos para especificar un camino a
atributos y objetos relacionados. Una expresin 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:
[Link];
[Link];
[Link] profesores;
La primera expresin devuelve una referencia a un objeto Profesor, aquel que dirige el
departamento de informtica. La segunda expresin obtiene la categora del profesor que dirige
este departamento (el resultado es de tipo string). La tercera expresin devuelve un objeto de
tipo set<Profesor>. Esta coleccin contiene referencias a todos los objetos
Profesor que se relacionan con el objeto cuyo nombre es departamentoinf. Si se quiere
obtener la categora de todos estos profesores, no podemos escribir la expresin:
[Link] [Link];
El no poder escribir la expresin de este modo es porque no est claro si el objeto que se
devuelve es de tipo set<string> o bag<string>. Debido a este problema de
ambigedad, OQL no permite expresiones de este tipo. En su lugar, es preciso utilizar variables
iterador:
SELECT [Link]
FROM p in [Link] profesores;
SELECT DISTINCT [Link]

27

OODB Y ODMG

Bases de Datos Orientadas a Objetos y el estndar ODMG

FROM p in [Link] profesores;

En general, una consulta OQL puede devolver un resultado con una estructura compleja
especificada en la misma consulta utilizando struct. La siguiente expresin:
[Link];
devuelve un objeto de tipo set<EstudianteGrad>: una coleccin que contiene los
estudiantes graduados que son tutorizados por el director del departamento de informtica. Si lo
que se necesita son los nombres y apellidos de estos estudiantes y los ttulos que tiene cada uno,
se puede escribir la siguiente consulta:
SELECT struct(nombre:struct(ape1: [Link].apellido1,
ape2: [Link].apellido2,
nom: [Link] pila),
titulos:(SELECT struct(tit: [Link],
agno: [Link],
esc: [Link])
FROM t in [Link])
FROM e in [Link];
OQL es ortogonal respecto a la especificacin de expresiones de caminos: atributos,
relaciones y operaciones (mtodos) 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 Martnez, ordenados por su nota
media, se podra utilizar la siguiente consulta (el resultado, por estar ordenado, ser de tipo
list):
SELECT struct(ape1: [Link].apellido1,
ape2: [Link].apellido2,
nom: [Link] pila,
media: [Link] media)
FROM e in estudiantes graduados
WHERE [Link] pila=`Gloria
AND [Link].apellido1=`Martnez
ORDER BY media DESC, ape1 ASC, ape2 ASC;
OQL tiene adems otras caractersticas que no se van a presentar aqu:

Especificacin de vistas dando nombres a consultas.

Obtencin 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.

OODB Y ODMG

28

Clara Martn Sastre y Enrique Medarde Caballero

8.

Conclusiones

Tras el periodo de investigacin y la elaboracin del presente informe, en primer lugar, hemos
podido comprobar que la informacin acerca del tema que se trata, no est al alcance de todo el
mundo. La bibliografa existente no es fcil de conseguir y la fuente que constituye INTERNET
tampoco es demasiado aceptable, bajo nuestro punto de vista. Esto nos hace recapacitar y pensar
que el motivo, como ya sabemos, es que las OODB no estn todava lo suficientemente
arraigadas en el entorno de la informtica y la computacin. Este hecho se ve confirmado por la
falta de un estndar capaz de sobrellevar todo el peso de este tipo de bases de datos. En este
informe, nos hemos tratado de acercar al estndar ODMG, puesto que ste parece ser uno de los
que pueden tener unas perspectivas de futuro ms fiable. A pesar de ello, existen otros
estndares que tratan de abordar la estandarizacin de este tema, por ello, no queremos restringir
este campo al estndar que hemos presentado.
En definitiva, la conclusin a la que hemos podido llegar, es que el mundo de las OODB es
un mundo todava en pleno desarrollo, pero que teniendo en cuenta las ventajas que ofrece
respecto a otros modelos anteriores, constituye el futuro de las bases de datos.

29

OODB Y ODMG

Bases de Datos Orientadas a Objetos y el estndar ODMG

9.

Bibliografa

[1] R. G. G. Cattell et al. The Object Data Standard: ODMG 3.0. Morgan Kauffmann
Publishers, 2000.
[2] David Jordan. C++ Object Databases: Programming With the ODMG Standard (Object
Technology Series). Prentice Hall, 2002.
[3] Mario Piatinni Velthuis, Bases de Datos Orientadas a Objetos.
Web site: [Link] [Link]
[4] Web site: [Link]
[5] Web site: [Link]
[6] Web site:
[Link]
[7] Manifesto de Atkinson, Sistemas Manejadores de Bases de Datos Orientadas a
Objetos. Web site:
[Link]
[8] Web site: [Link]
[9] Web site: [Link]
[10] Web site: [Link]
[11] Web site:
[Link]
se_Management_Systems.ppt

OODB Y ODMG

30