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
1,3

Golobisky, Mara F.

2,3

- Fiszman, Fernando E.

2,3

- Vecchietti, Aldo R.

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

edad ()

LU
Especialidad
Ao_Ingreso
P_Pers REF Persona

PROFESOR
Legajo
Cargo
Fecha_Ingreso
P_Pers REF Persona

aos_estudio ()

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