Bases de datos orientadas a objetos

Bruno Mendvez, Gerardo Reao y Ricardo Vargas Facultad de Ciencias Fsicas y Matemticas Escuela de Ingeniera Informtica Universidad Nacional de Trujillo 28 de mayo de 2012
Resumen Las bases de datos orientadas a objetos surgieron como respuesta a problemas de acoplamiento entre los modelos relacional -el ms popular dentro del diseo de bases de datos- y orientado a objetos -aplicado al entorno de la aplicacin de usuario-. Al ser modelos incompatibles, el desarrollo de aplicaciones dentro de un sistema de base de datos siempre se ha visto ralentizado al dedicar esfuerzos en realizar las operaciones CRUD -create, read, update y delete- de forma transparente. Por ejemplo, haba que dedicar lneas de cdigo extra en crear mtodos que carguen los datos de las las resultado de cierta consulta, en algn objeto dentro del programa. Hay otras formas -igual de vlidas- de afrontar este problema: utilizacin de layers (capas de aplicacin), frameworks o libreras adicionales, etc. Aqu se ir ms lejos y se ver cmo es posible uniformizar el modelamiento de un sistema de base de datos, llevando el paradigma orientado a objetos al modelo de datos.

1.

Introduccin

A medida que el software se haca ms popular, nuevas necesidades surgan a lo largo de los aos. Aplicaciones ms complejas eran desarrolladas y nacan las metodologas orientadas a objetos. Era una visin que reejaba de buena manera la realidad problemtica de un proyecto. No pas mucho tiempo para que estas metodologas consolidaran una moda con muchos casos de xito. Sin embargo, los proyectos de software ms modernos y sosticados creaban aplicaciones que tenan un soporte de datos. La comunicacin entre el software y la base de datos era necesaria y en ese entonces no era muy simple de llevar a cabo. El principal incoveniente era la incompatibilidad de modelos (impedancia de acoplamiento). El modelo relacional trabajaba con tablas y tuplas, mientras que un programa orientado a objetos trabajaba con clases, objetos y paso de mensajes. Haba que hacer un esfuerzo adicional para acoplar los datos persistentes a los objetos y viceversa. Sucede que, las bases de datos tradicionales son difciles de utilizar cuando las aplicaciones que acceden a ellas estn escritas en un lenguaje de programacin orientado a objetos como C++, Smalltalk o Java. Las bases de datos orientadas a objetos se han diseado para que se puedan integrar directamente con aplicaciones desarrolladas con lenguajes orientados a objetos, habiendo adoptado muchos de los conceptos de estos lenguajes. Se trata entonces de homogeneizar el modelado para ganar en facilidad de acceso y transparencia. Durante los ltimos aos se han creado muchos prototipos experimentales de sistemas de bases de datos orientadas a objetos y tambin muchos sistemas comerciales. Conforme stos fueron apareciendo, surgi la necesidad de establecer un modelo estndar y un lenguaje. Para ello, los fabricantes de los SGBD orientadas a objetos formaron un grupo denominado ODMG (Object Database Management Group), que propuso el estndar ODMG93 y que ha ido evolucionando hasta el ODMG 3.0, su ltima versin. En este documento veremos el modelo genrico de datos orientado a objetos. Se asume un conocimiento previo sobre el paradigma clsico orientado a objetos. Se ver tambin el estndar ODMG, su estructura, sus partes constituyentes, los detalles de implementacin de los principales conceptos como objeto, herencia, clases, interfaces, etc. Finalmente se ver el lenguaje de denicin de objetos ODL y el lenguaje de consulta de objetos OQL, partes esenciales del estndar ODMG.

2.

El modelo de datos orientado a objetos

El modelo de datos orientado a objetos es una extensin del paradigma de programacin orientado a objetos. Los objetos entidad que se utilizan en los programas orientados a objetos son anlogos a las entidades que se utilizan en las bases de datos orientadas a objetos puras, pero con una gran diferencia: los objetos del programa desaparecen cuando el programa termina su ejecucin, mientras que los objetos de la base de datos permanecen. A esto se le denomina persistencia.

2.1.

Relaciones

Las bases de datos orientadas a objetos implementan sus relaciones incluyendo en cada objeto los identicadores de los objetos con los que se relaciona. Un identicador de objeto es un atributo interno que posee cada objeto. Ni los programadores, ni los usuarios que realizan consultas de forma interactiva, ven o manipulan estos identicadores directamente. Los identicadores de los objetos los asigna el SGBD y es l

el nico que los utiliza. El identicador puede ser un valor arbitrario o puede incluir la informacin necesaria para localizar el objeto en el chero donde se almacena la base de datos. Por ejemplo, el identicador puede contener el nmero de la pgina del chero donde se encuentra almacenado el objeto, junto con el desplazamiento desde el principio de la pgina. Hay dos aspectos importantes a destacar sobre este mtodo de representar las relaciones entre datos: Para que el mecanismo funcione, el identicador del objeto no debe cambiar mientras ste forme parte de la base de datos. Las nicas relaciones que se pueden utilizar para consultar la base de datos son aquellas que se han predenido almacenando en atributos los identicadores de los objetos relacionados. Esto supone un acceso navegacional ya que es ms fcil navegar por los identicadores de objeto que combinando tablas (operaciones join) como en el modelo relacional. Para crear una relacin de uno a muchos, se dene un atributo en la parte del uno que ser de la clase del objeto con el que se relaciona. Este atributo contendr el identicador de objeto del padre. La clase del objeto padre contendr un atributo que almacenar un conjunto de valores: los identicadores de los objetos hijo con los que se relaciona (atributo multivaluado). Las relaciones de muchos a muchos se pueden representar directamente en las bases de datos orientadas a objetos, sin necesidad de crear entidades intermedias. Para representar la relacin, cada clase que participa en ella dene un aributo que contendr un conjunto de valores de la otra clase con la que se relacionar. Sin embargo, siempre es recomendable crear entidades intermedias si se quiere almacenar datos en la relacin. Ya que el paradigma orientado a objetos soporta la herencia, una base de datos orientada a objetos tambin puede utilizar la relacin es un entre objetos. Se pueden crear superclases lgicas con clases hijas que describen un comportamiento ms especco e independiente, aunque siempre los atributos genricos se heredarn. En teora, una base de datos orientada a objetos debe soportar dos tipos de herencia: la relacin es un y la relacin extiende. La relacin es un, que tambin se conoce como generalizacinespecializacin, crea una jerarqua donde las subclases son tipos especcos de las superclases. Con la relacin extiende, sin embargo, una clase expande su superclase en lugar de estrecharla en un tipo ms especco. Una de las cosas que es difcil de manejar en las bases de datos relacionales es la idea de las partes de un todo. Sin embargo, una base de datos orientada a objetos puede aprovechar la relacin denominada todoparte en la que los objetos de una clase se relacionan con objetos de otras clases que forman parte de l. En el caso de una base de datos de fabricacin, la clase Producto se relacionar con las clases Pieza y Componente utilizando una relacin todoparte. Este tipo de relacin es una relacin de muchos a muchos con un signicado especial. Un producto puede estar hecho de muchas piezas y muchos componentes. Adems, una misma pieza o un mismo componente se puede utilizar para fabricar distintos productos. El identicar esta relacin como todoparte permite que el diseo sea ms fcil de entender.

2.2.

Integridad de las relaciones

Para que las relaciones funcionen en una base de datos orientada a objetos pura, los identicadores de los objetos deben corresponderse en ambos extremos de la 3

relacin. Por ejemplo si consideramos en algn modelado que un maestro de obra supervisa una obra, hay que asegurarse que, cuando un identicador de un objeto Obra se incluye en un objeto Maestro, el identicador de este mismo objeto Maestro se debe incluir en el objeto Obra anterior. Este tipo de integridad de relaciones, que es de algn modo anlogo a la integridad referencial en las bases de datos relacionales, se gestiona especicando relaciones inversas. Supongamos que la clase Maestro tiene un atributo multivaluado de tipo conjunto (set) llamado supervisa. Este atributo ser un conjunto de indenticadores de objetos tipo Obra -ya que un maestro puede supervisar muchas obras-; del mismo modo, en la clase Obra existir un atributo simple -de un slo valor- llamado es_supervisada que ser un identicador de objeto tipo Maestro. Las relaciones inversas que aseguran la integridad se denen:

relationship set<Obra> supervisa inverse Obra::es_supervisada relationship Maestro es_supervisada inverse Maestro::supervisa
El primer comando es parte de la especicacin de la clase Maestro y el segundo de la clase Obra. Entonces, siempre que un usuario o un programa de aplicacin inserta o elimina un identicador de objeto de la relacin supervisa en un objeto Maestro, el SGBD actualizar automticamente la relacin es supervisada en el objeto Obra relacionado. Cuando se hace una modicacin en el objeto Obra, el SGBD lo propagar automticamente al objeto Maestro. Del mismo modo que en las bases de datos relacionales es el diseador de la base de datos el que debe especicar las reglas de integridad referencial, en las bases de datos orientadas a objetos es tambin el diseador el que debe especicar las relaciones inversas cuando crea el esquema de la base de datos.

3.

El modelo estndar ODMG

Un grupo de representantes de la industria de las bases de datos formaron el ODMG (Object Database Management Group) con el propsito de denir estndares para los SGBD orientados a objetos. Este grupo propuso un modelo estndar para la semntica de los objetos de una base de datos. Su ltima versin, ODMG 3.0, apareci 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 denicin de objetos (ODL). Lenguaje de consulta de objetos (OQL). Conexin con los principales lenguajes orientados a objetos.

3.1.

Modelo de objetos

El modelo dispone de las siguientes primitivas de modelado: Los componentes bsicos de una base de datos orientada a objetos son los objetos y los literales. Los objetos tienen algn tipo de identicador nico. Un literal es un valor especco, como Melissa o 36. Los literales no tienen identicadores. 4

Los objetos y los literales se categorizan en tipos. Cada tipo tiene un dominio especco 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 denicin de una base de datos est contenida en un esquema que se ha creado mediante el lenguaje de denicin de objetos ODL (Object Denition Language) que es el lenguaje de manejo de datos que se ha denido como parte del estndar propuesto para las bases de datos orientadas a objetos. 3.1.1. Objetos

Los tipos de objetos son: atmicos, colecciones y tipos estructurados. Los objetos atmicos representan slo uno, las objetos coleccin pueden ser:

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 posicin. Su tamao es dinmico y los elementos se pueden insertar y borrar de cualquier posicin. Dictionary<clave, valor>: es como un ndice. Esta formado por claves ordenadas, cada una de ellas emparejada con un solo valor.
Los objetos estructurados son Date, Time, Timestamp e Interval. Estos son especiales y se pueden descomponer en datos especcos como ao, hora, da, minuto, etc. (por eso son estructurados). Tambin, todo objeto se crea usando el mtodo new(). Cada objeto tiene un identicador de objeto nico generado por el SGBD, que no cambia y que no se reutiliza cuando el objeto se borra. Cada SGBD genera los identicadores siguiendo sus propios criterios.

3.1.2.

Literales

Al igual que los objetos, los literales pueden ser atmicos, colecciones o estructurados. Los literales no tienen identicadores y no pueden aparecer solos como objetos, sino que estn embebidos en objetos y no pueden referenciarse de modo individual. Los literales atmicos son los siguientes: boolean, short, long, unsigned short, unsigned long, float, double, octet, char, string, enum. Los literales estructurados contienen un nmero jo 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>. 3.1.3. Tipos

Un objeto es una instancia de cierto tipo. En la prctica, se dice que un objeto es una instancia de una clase ya que stas son instanciables, cosa que no ocurre con las interfaz. Vamos a denir brevemente estos conceptos, aclarando que la jerarqua es interfaz-clase-objeto. Una interfaz es una especicacin del comportamiento abstracto de un tipo de objeto y contiene las signaturas de las operaciones. Aunque una interfaz puede tener propiedades (atributos y relaciones) como parte de su especicacin, stas no pueden ser heredadas desde la interfaz. Adems, una interfaz no es instanciable por lo que no se pueden crear objetos a partir de ella (es el equivalente de una clase abstracta en la mayora de los lenguajes de programacin OO). Una clase es una especicacin 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 programacin). El estndar propuesto soporta la herencia simple y la herencia mltiple mediante las interfaces. Ya que las interfaces no son instanciables, se suelen utilizar para especicar operaciones abstractas que pueden ser heredadas por clases o por otras interfaces. A esto se le denomina herencia de comportamiento y se especica mediante el smbolo :. La herencia de comportamiento requiere que el supertipo sea siempre una interfaz, mientras que el subtipo puede ser una clase o una interface, de acuerdo a la jerarqua denida antes. Ejemplo:

interface ArticuloVenta ...; interface Mueble : ArticuloVenta ...; class Silla : Mueble ...; class Mesa : Mueble ...; class Sof : Mueble ...;
3.1.4. Propiedades

El modelo de objetos ODMG dene dos tipos de propiedades: atributos y relaciones. Un atributo se dene del tipo de un objeto. Un atributo no es un objeto de primera clase, por lo tanto no tiene identicador, pero toma como valor un literal o el identicador de un objeto. Las relaciones se denen 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 dene 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 6

relacin en la que uno de los objetos participantes se ha borrado. El modelo aporta operaciones para formar (form) y eliminar (drop) miembros de una relacin. 3.1.5. 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 protcolo pesimista de control de concurrencia. Todos los accesos, creacin, modicacin y borrado de objetos persistentes se deben realizar dentro de una transaccin. El modelo especica operaciones para iniciar, terminar (commit) y abortar transacciones, as como la operacin de checkpoint. Esta ltima operacin hace permanentes los cambios realizados por la transaccin en curso sin liberar ninguno de los bloqueos adquiridos.

3.2.

Lenguaje de denicin de objetos ODL

ODL es un lenguaje de especicacin para denir tipos de objetos para sistemas compatibles con ODMG. ODL es el equivalente del DDL (lenguaje de denicin de datos) de los SGBD tradicionales. Dene los atributos y las relaciones entre tipos, y especica la signatura de las operaciones.

3.3.

Lenguaje de consulta de objetos OQL

OQL es un lenguaje declarativo del tipo de SQL que permite realizar consultas de modo eciente 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 sintaxis de la sentencia SELECT. OQL no posee primitivas para modicar el estado de los objetos ya que las modicaciones se pueden realizar mediante los mtodos que stos poseen. La sintaxis bsica de OQL es una estructura SELECT...FROM...WHERE..., como en SQL.

4.

Conclusiones

Las bases de datos orientadas a objetos surgieron en respuesta al inevitable cambio del software. Aplicaciones ms sosticadas requeran menos esfuerzo en la comunicacin con los orgenes de datos, y en buena cuenta, una homogeneizacin de modelos es una solucin acertada. Un modelo de datos orientado a objetos aporta concordancia con la aplicacin; los procesos de carga de datos y mantenimiento son ms intuitivos y los objetos pueden uir sin muchas complicaciones entre la aplicacin y la base de datos.

Referencias
[1] R.G.G. Cattell, Douglas K. Barry y otros. The Object Data Standard: ODMG 3.0. Morgan Kaufmann Publishers, San Francisco, California.