Resumen: B-057

UNIVERSIDAD NACIONAL DEL NORDEST E Comunicaciones Cientficas y Tecnolgicas 2004

Implementacin de Modelos de Generalizacin-Especializacin en Bases de Datos Objeto-Relacionales

Golobisky, Mara F.
1,3

- Fiszman, Fernando E.

2,3

- Vecchietti, Aldo R.

2,3

1. Facultad de Ciencias Exactas y Naturales y Agrimensura (UNNE). 9 de Julio 1449. (3400) Corrientes. Argentina. TE: 03783- 457950. Fax: 03783-473930. E-mail: mfgolo@exa.unne.edu.ar 2. Departamento de Sistemas. Facultad Regional Santa Fe (UTN). Lavaisse 610. (3000) Santa Fe. Argentina. 3. Grupo de Investigacin en Gestin Avanzada de Datos GIGAD. INTRODUCCIN En este trabajo se presentan los resultados obtenidos en el anlisis de transformaciones de relaciones de generalizacinespecializacin a bases de datos objeto-relacionales. El estndar SQL:1999 es el resultado de aos de esfuerzos para plasmar conceptos Orientados a Objetos en la tecnologa de las Bases de Datos Relacionales, dando nacimiento a los Sistemas de Base de Datos Objeto-Relacionales (ORDBMS). La principal motivacin para el desarrollo del estndar fue juntar lo mejor de dos mundos tecnolgicos: por un lado la capacidad de la orientacin a objetos para desarrollar aplicaciones que requieren de modelos complejos, que permita la construccin de grandes sistemas empleando componentes preconfigurados, fciles de mantener, reusar y extender, y por el otro una tecnologa de aceptacin universal, con una gran capacidad para administrar persistencia, independencia de datos, concurrencia, distintos niveles de seguridad, con un lenguaje simple y muy difundido como SQL. Los ORDBMS tienen la capacidad de realizar transformaciones basadas en la tecnologa relacional, empleando mapeos bien conocidos y determinados del modelo de datos en tablas. Las tablas generadas deben estar normalizadas para eliminar redundancia y anomalas en los datos. Adems, los ORDBMS tienen la capacidad de emplear relaciones complejas orientadas a objetos, en donde no existe una manera clara de cmo transformar un modelo OO en un ORDBMS de manera eficiente, ni se cuenta con una base terica como la normalizacin en el caso relacional. Entre estos dos extremos, relacional y objeto-relacional, se pueden proponer transformaciones hbridas del modelo de datos orientado a objetos empleando elementos de ambos conjuntos. Partiendo de un modelo de datos desarrollado en UML se proponen estrategias de diseo para Bases de Datos ObjetoRelacionales, sobre algunos aspectos involucrados en la transformacin de estos modelos, tales como flexibilidad, dificultad para la implementacin, incorporacin de caminos de acceso y restricciones, navegabilidad. RELACIONES DE GENERALIZACIN-ESPECIALIZACIN En una relacin de generalizacin-especializacin existe una jerarqua de tipos en la que se definen sucesivos niveles de subtipos que se especializan de manera incremental, heredando los atributos y el comportamiento de un ancestro comn denominado supertipo, extendiendo su definicin agregando nuevos atributos y mtodos, o redefiniendo los mtodos heredados de sus ancestros. Esta jerarqua de tipos provee un alto nivel de complejidad para un modelo determinado.
PERSONA DNI Nombre Apellido Domicilio Ciudad Fecha_Nac edad ()

ESTUDIANTE LU Especialidad Ao_Ingreso aos_estudio ()

PROFESOR Legajo Cargo Fecha_Ingreso antiguedad ()

Fig. 1: Relacin de Generalizacin-Especializacin

En el ejemplo de la Figura 1 se asume que los conjuntos de Estudiante y Profesor son disjuntos, y que en el universo de informacin que se quiere representar existen objetos de los tres tipos: personas, estudiantes y profesores, para contrastarlo con la posibilidad de que slo existan profesores y estudiantes. TRANSFORMACIONES DEL MODELO A UN ESQUEMA RELACIONAL Existen tres transformaciones posibles para la jerarqua de generalizacin-especializacin propuesta: 1. Modelo Plano. 2. Particin Vertical. 3. Particin Horizontal.

Resumen: B-057

UNIVERSIDAD NACIONAL DEL NORDEST E Comunicaciones Cientficas y Tecnolgicas 2004 El modelo plano contempla la definicin de una sola tabla donde se encontrarn todos los atributos de los distintos tipos. Aquellos atributos que no correspondan al tipo almacenado en una fila tendrn valor nulo.
DNI 1234 6789 4567 Nombre Juan Jos Luis Apellido Garcia Perez Lopez Domicilio abc 12 lmn 56 zjk 34 Ciudad XYZ LPJ KLO Fecha_Nac 11/11/74 9/4/60 24/10/65 LU 212 null null Espec ISI null null Ao_Ingreso 1999 null null Legajo null 994 null Cargo null JTP null Fecha_Ingreso null 1/4/1990 null

Fig. 2: Esquema relacional resultante de la transformacin como tabla jerrquica

La particin vertical implica que se generar una tabla para cada uno de los tipos que componen la jerarqua, cada una con sus atributos. La clave del supertipo se replica como clave fornea en cada uno de los subtipos.
DNI 1234 6789 4567 Nombre Juan Jos Luis Apellido Garca Perez Lpez Domicilio Abc 12 Lmn 56 Zjk 34 Ciudad XYZ LPJ KLO Fecha_Nac 11/11/74 9/4/60 24/10/65

Restricciones Clave Fornea DNI 1234 LU 212 Espec ISI Ao_Ingreso 1999 DNI 6789 Legajo 994 Cargo JTP Fecha_Ingreso 1/4/1990

Fig. 3: Esquema relacional resultante de la transformacin usando particin vertical

La particin horizontal implementa slo las tablas correspondientes a los subtipos, trasladando a las mismas todos los atributos del supertipo. El inconveniente principal de esta transformacin es que slo se pueden representar dos tipos de objetos: estudiantes profesores. Los objetos persona no pueden ser representados en este esquema.
DNI 1234 DNI 6789 Nombre Juan Nombre Jos Apellido Garcia Apellido Perez Domicilio abc 12 Domicilio lmn 56 Ciudad XYZ Ciudad LPJ Fecha_Nac 11/11/74 Fecha_Nac 9/4/60 LU 212 Legajo 994 Espec ISI Cargo JTP Ao_Ingreso 1999 Fecha_Ingreso 1/4/1990

Fig. 4: Esquema relacional resultante de la transformacin usando particin horizontal

TRANSFORMACIONES DEL MODELO A UN ESQUEMA OBJETO-RELACIONAL USANDO SQL:1999 SQL:1999 contempla la implementacin de relaciones de generalizacin-especializacin por medio de la definicin de tipos y subtipos del siguiente modo:
CREATE TYPE Persona_typ AS OBJECT (DNI Integer, Nombre CHAR(20), Apellido CHAR(20), Domicilio CHAR(30), Ciudad CHAR(20), Fecha_nac Date, MEMBER FUNCTION edad RETURN Integer) NOT FINAL; CREATE TYPE Estudiante_typ UNDER Persona_typ AS (LU Integer, Especialidad CHAR(20), Ao_Ingreso CHAR(4), MEMBER FUNCTION aos_estudio RETURN Integer) NOT FINAL; CREATE TYPE Profesor_typ UNDER Persona_typ AS (Legajo Integer, Cargo CHAR(20), Fecha_Ingreso Date, MEMBER FUNCTION antigedad RETURN Integer) NOT FINAL;

Estas tres entradas crean los tipos que corresponden a los del modelo de la Figura 1. Tres implementaciones posibles se pueden realizar a partir de los tipos definidos previamente, similares a las definidas para el modelo relacional: El modelo plano requiere la definicin de una sola tabla para el tipo persona:
CREATE TABLE persona_table OF Persona_typ; (DNI Primary Key);

Con esta implementacin, cualquiera de los tipos definidos puede constituir una fila de la tabla persona_table. La definicin de la clave primaria, como cualquiera de las otras restricciones sobre los atributos, se debe hacer al nivel de definicin de tabla, no en la definicin de tipos, de manera de controlar que no se definan filas duplicadas. La particin vertical requiere que se defina una tabla para cada uno de los tipos, como sigue:
CREATE TABLE Persona_table OF Persona_typ NOT SUBSTITUTABLE AT ALL LEVELS (DNI Primary Key); CREATE TABLE Estudiante_table OF Estudiante_typ NOT SUBSTITUTABLE AT ALL LEVELS (DNI Primary Key, LU Unique); CREATE TABLE Profesor_table OF Profesor_typ NOT SUBSTITUTABLE AT ALL LEVELS (DNI Primary Key, Legajo Unique);

En este caso, con la clusula NOT SUBSTITUTABLE AT ALL LEVELS, propia del ORDBMS Oracle 9i (Gietz, 2001), slo objetos del tipo definido para cada tabla pueden incluirse en cada una de ellas. Esto hace la implementacin ms consistente y diferente de la implementacin plana. La particin horizontal slo requiere la definicin de las tablas Estudiante_table y Profesor_table definidas anteriormente. Se debe definir si las tablas son sustituibles o no, dependiendo de los requerimientos del modelo que

Resumen: B-057

UNIVERSIDAD NACIONAL DEL NORDEST E Comunicaciones Cientficas y Tecnolgicas 2004 se quiere implementar, pero no se podrn almacenar objetos persona, an cuando las tablas sean sustituibles, ya que este concepto se aplica para objetos que se encuentran en niveles por debajo en la jerarqua, no hacia arriba. TRANSFORMACIONES DEL MODELO A UN ESQUEMA HBRIDO Este esquema est ms volcado a la tecnologa Objeto-Relacional, porque aprovecha elementos incorporados por el estndar SQL:1999, la definicin de UDTs y la capacidad de definir referencias (punteros) entre objetos. El esquema de esta representacin se muestra a continuacin:
PERSONA DNI Nombre Apellido Domicilio Ciudad Fecha_Nac P_Est REF Estudiante P_Prof REF Profesor ESTUDIANTE LU Especialidad Ao_Ingreso P_Pers REF Persona aos_estudio () edad () PROFESOR Legajo Cargo Fecha_Ingreso P_Pers REF Persona antiguedad ()

Fig. 5: Esquema relacional resultante de la transformacin usando particin horizontal

En la Figura 5 las flechas con lneas de punto significa que se han definido referencias (punteros) entre los objetos. Estas referencias emplean los Identificadores de Objetos Unicos (OID) para el manejo de estos punteros. La creacin de los tipos para este caso se realiza del siguiente modo:
CREATE TYPE Estudiante_typ; CREATE TYPE Profesor_typ; CREATE TYPE Persona_typ AS OBJECT (DNI Integer, Nombre CHAR(20), Apellido CHAR(20), Domicilio CHAR(30), Ciudad CHAR(20), Fecha_nac Date, P_Est REF Estudiante_typ,P_Prof REF Profesor_typ, MEMBER FUNCTION edad RETURN Integer) NOT FINAL; CREATE TYPE Estudiante_typ AS OBJECT ( LU Integer, Especialidad CHAR(20), Ao_Ingreso CHAR(4), P_Pers REF Persona_typ, MEMBER FUNCTION aos_estudio RETURN Integer) NOT FINAL; CREATE TYPE Profesor_typ AS OBJECT (Legajo Integer, Cargo CHAR(20), Fecha_Ingreso Date, P_Pers REF Persona_typ; MEMBER FUNCTION antigedad RETURN Integer) NOT FINAL; CREATE TABLE Persona_table OF Persona_typ (DNI Primary Key); CREATE TABLE Estudiante_table OF Estudiante_typ (DNI Primary Key, LU Unique); CREATE TABLE Profesor_table OF Profesor_typ (DNI Primary Key, Legajo Unique);

Las primeras declaraciones de los tipos Estudiante_typ y Profesor_typ son necesarias para poder definir las referencias a Persona_typ, que de otro modo no se podran hacer. Este esquema hbrido est ms estrechamente relacionado con la particin vertical de los modelos anteriores, permitiendo definir tanto objetos Persona, como Estudiante y Profesor. ANLISIS DE LAS IMPLEMENTACIONES Modelo Plano La implementacin plana tiene la dificultad del manejo de valores nulos, pero que los ORDBMS administran hoy con mucha eficacia. La implementacin relacional, en la que se definen explcitamente los atributos de todos los tipos de la jerarqua, permite la definicin de ndices y/o restricciones adicionales para cada uno de ellos. Esto no es posible en la implementacin objeto-relacional, ya que no se pueden definir restricciones en Persona_table para los atributos que no pertenecen al tipo para el cual se define la tabla. Por otra parte para hacer persistentes objetos de tipos nuevos en Persona_table bastar con definir nuevos tipos en la jerarqua. Esto da mucha flexibilidad para cambiar el modelo y la jerarqua de Generalizacin-Especializacin y la inclusin de nuevas relaciones en el universo que se modela. Para obtener el mismo efecto en una implementacin relacional, se debe recurrir a un modo menos natural y flexible como clusulas ALTER TABLE....ADD, y el agregado de restricciones y relaciones de claves forneas con otras tablas. Una gran ventaja de la implementacin objeto-relacional es la posibilidad de realizar operaciones y clculos con los objetos de la jerarqua, por medio de sus funciones miembros. Por ejemplo, es muy fcil calcular la edad de los objetos de Persona_table, ya que todos los subtipos heredan la funcin edad() definida en Persona_typ, que calcula la edad de las personas a partir de la fecha de nacimiento. Adems, es posible definir mtodos que se pueden redefinir en los subtipos para dar lugar a una de las propiedades de la orientacin a objetos: el polimorfismo. Esto no es posible siquiera plantearlo en el modelo relacional.

Resumen: B-057

UNIVERSIDAD NACIONAL DEL NORDEST E Comunicaciones Cientficas y Tecnolgicas 2004 Particin Vertical En este modelo es posible analizar tres tipos de implementaciones: relacional, hbrida y objeto-relacional. La implementacin relacional tiene la dificultad de tener que realizar operaciones de join cuando se quiere recuperar la informacin completa de un estudiante y/o profesor. Esto, dependiendo del tamao de las tablas y la distribucin de las filas en el almacenamiento, puede ser muy costoso. Adems tiene definido el mecanismo de integridad referencial para administrar la integridad de las referencias manejadas por medio de las claves forneas. El esquema hbrido tiene una gran flexibilidad al momento de navegar por los datos. Definido de modo bi-direccional, es posible, por ejemplo acceder a un estudiante por medio de su documento de identidad, o su nmero de libreta, y siguiendo las respectivas referencias recuperar el resto de la informacin accediendo a la tabla de estudiante y luego a sus datos personales. En este esquema no existe un mecanismo que mantenga la integridad de las referencias como en el caso de las claves forneas del modelo relacional. Esto implica que si el objeto apuntado por una variable REF se elimina, no hay nada definido por el estndar que diga qu hacer ante este caso. Esta implementacin permite el manejo de funciones miembros, aunque no permite la posibilidad de herencia de atributos ni mtodos, ni de polimorfismo, que s los tiene la relacin de generalizacin especializacin definida por el estndar SQL:1999. La implementacin objeto-relacional es la que presenta mayores ventajas porque puede cambiar flexiblemente las relaciones, hereda atributos y mtodos, puede redefinir los mtodos en los subtipos, puede definir ndices para varios puntos de acceso a los datos, tiene la capacidad de definir restricciones sobre todos los atributos. Particin Horizontal Esta particin es conveniente cuando en el universo a representar slo existen objetos que pertenecen a los subtipos, por lo tanto no existen objetos a nivel de supertipos y no es necesario mantener una tabla para ellos. Comparando la implementacin relacional con la objeto-relacional, podemos decir que la mayor diferencia entre ambas es el manejo de comportamiento entre una y otra. La definicin de las operaciones sobre los tipos que no es posible hacer en una implementacin relacional, s se pueden hacer en una objeto-relacional, con todas las ventajas que esto propone. Esta implementacin aventaja a la relacional en las caractersticas de flexibilidad, herencia, polimorfismo. Son equivalentes en aspectos relacionados con el acceso a los datos y restricciones de integridad para los atributos. CONCLUSIONES Se han mostrado diversas implementaciones de relaciones de generalizacin-especializacin sobre un ORDBMS. Las implementaciones se estudiaron sobre un modelo relativamente simple que no por ello pierde generalidad. Las experiencias se realizaron sobre una base de datos objeto-relacional Oracle 9.0.1. Se analizaron tres posibles transformaciones: modelo plano, particin vertical y particin horizontal, bajo un esquema relacional y bajo un esquema objeto-relacional que obedece al estndar SQL:1999. Para la particin vertical se incluy tambin un esquema hbrido, utilizando la capacidad de definir referencias de la tecnologa relacional. Se tuvieron en cuenta las siguientes caractersticas: facilidad de implementacin, flexibilidad para incorporar nuevos objetos a las estructuras de almacenamiento, mecanismos de acceso y restricciones, posibilidad de manejar comportamiento de los objetos (funciones miembros de los objetos) y facilidad para navegar por los datos. En principio, no existe una transformacin que sea universal y que se adapte a los requerimientos de todos los sistemas que puedan presentarse a quien disea las aplicaciones. Pero en lneas generales, se puede concluir que, obviamente las transformaciones que obedecen al estndar SQL:1999 estn basadas en conceptos orientados a objetos, que intentan dar una respuesta a la complejidad de las relaciones que se deben abordar en los sistemas de informacin en nuestros das. Sus fortalezas ms destacables son la capacidad de definir comportamiento, herencia de atributos y mtodos, polimorfismo, una mayor flexibilidad para introducir cambios en los modelos originales. Por su parte, la tecnologa relacional presenta caractersticas muy arraigadas, que no se pueden considerar obsoletas. El manejo de restricciones sobre los atributos, la capacidad para definir caminos de acceso que aceleren la recuperacin de informacin, son muy importantes para algunas aplicaciones. El esquema hbrido presentado se destaca por la facilidad de navegar por los datos en varias direcciones, facilitando el acceso a los mismos. Su debilidad es la falta de mecanismos que ayuden a mantener la integridad de las referencias.
BIBLIOGRAFIA Elmasri, R. y S. Navathe, 2000. Fundamentals of Database Systems. Addison Wesley. 956 p. Gietz, B., 2001. Oracle 9i Application Developers Guide - Object-Relational Features, Release 1 (9.0.1). Part No. A88878-01. Golobisky, M.F.; Fiszman, F.E.; Hernndez, F.; Rizzoni, V.; Valin, M., Vecchietti, A. y Alvarez, B.B., 2003. Bases de Datos Objeto-Relacionales y la Tecnologa J2EE. Caso Prctico: Gestin del Macrosistema del Iber. Experiencias durante el diseo y la implementacin. Revista FACENA, 19:33-45. Golobisky, M.F.; Fiszman, F.E.y Vecchietti, A., 2003. Un anlisis acerca de la transformacin de un modelo UML en objetos de una Base de Datos Objeto-Relacional. Caso de estudio: Modelo de la Herpetofauna del Iber. Comunicaciones Cientficas y Tecnolgicas 2003. Campus Universitario, Universidad Nacional del Nordeste. Corrientes, Octubre de 2003. Marcos, E.; B. Vela; J.M. Cavero y P. Cceres, 2001. Aggregation and Composition in Object-Relational Databse Design. Advances in Databases and Information Systems. 5th East-european Conference, ADBIS 2001. Research Communications. Vol 1. Melton, J.; A.R. Simon y J. Gray, 2001. SQL: 1999 - Understanding Relational Language Components. Morgan Kaufmann Publishers; 1st edition. May 23, 2001. 928 p. Zhang, W. y N. Ritter, 2001. The Real Benefits of Object-Relational DB-Technology for Object-Oriented Software Development. Proc. 18 th British National Conference on Databases, Oxford. Advances in Databases, Read, B. (Ed.), LNCS 2097, Springer, 89-104