Resumen: B-057

UNIVERSIDAD NACIONAL DEL NORDEST E

Comunicaciones Científicas y Tecnológicas 2004

Implementación de Modelos de Generalización-Especialización

en Bases de Datos Objeto-Relacionales
1,3 2,3 2,3
Golobisky, María F. - Fiszman, Fernando E. - 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 Investigación en Gestión Avanzada de Datos GIGAD.

INTRODUCCIÓN
En este trabajo se presentan los resultados obtenidos en el análisis de transformaciones de relaciones de generalización-
especialización a bases de datos objeto-relacionales.
El estándar SQL:1999 es el resultado de años de esfuerzos para plasmar conceptos Orientados a Objetos en la
tecnología de las Bases de Datos Relacionales, dando nacimiento a los Sistemas de Base de Datos Objeto-Relacionales
(ORDBMS). La principal motivación para el desarrollo del estándar fue juntar lo mejor de dos mundos tecnológicos:
por un lado la capacidad de la orientación a objetos para desarrollar aplicaciones que requieren de modelos complejos,
que permita la construcción de grandes sistemas empleando componentes preconfigurados, fáciles de mantener, reusar y
extender, y por el otro una tecnología de aceptación 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 tecnología relacional, empleando mapeos
bien conocidos y determinados del modelo de datos en tablas. Las tablas generadas deben estar normalizadas para
eliminar redundancia y anomalías en los datos. Además, los ORDBMS tienen la capacidad de emplear relaciones
complejas orientadas a objetos, en donde no existe una manera clara de cómo transformar un modelo OO en un
ORDBMS de manera eficiente, ni se cuenta con una base teórica como la normalización en el caso relacional. Entre
estos dos extremos, relacional y objeto-relacional, se pueden proponer transformaciones híbridas 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 diseño para Bases de Datos Objeto-
Relacionales, sobre algunos aspectos involucrados en la transformación de estos modelos, tales como flexibilidad,
dificultad para la implementación, incorporación de caminos de acceso y restricciones, navegabilidad.
RELACIONES DE GENERALIZACIÓN-ESPECIALIZACIÓN
En una relación de generalización-especialización existe una jerarquía 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 común
denominado supertipo, extendiendo su definición agregando nuevos atributos y métodos, o redefiniendo los métodos
heredados de sus ancestros. Esta jerarquía de tipos provee un alto nivel de complejidad para un modelo determinado.
PERSONA
DNI
Nombre
Apellido
Domicilio
Ciudad
Fecha_Nac
edad ()

ESTUDIANTE PROFESOR
LU Legajo
Especialidad Cargo
Año_Ingreso Fecha_Ingreso
años_estudio () antiguedad ()

Fig. 1: Relación de Generalización-Especialización

En el ejemplo de la Figura 1 se asume que los conjuntos de Estudiante y Profesor son disjuntos, y que en el universo de
información que se quiere representar existen objetos de los tres tipos: personas, estudiantes y profesores, para
contrastarlo con la posibilidad de que sólo existan profesores y estudiantes.
TRANSFORMACIONES DEL MODELO A UN ESQUEMA RELACIONAL
Existen tres transformaciones posibles para la jerarquía de generalización-especialización propuesta:
1. Modelo Plano. 2. Partición Vertical. 3. Partición Horizontal.
 Resumen: B-057
UNIVERSIDAD NACIONAL DEL NORDEST E
Comunicaciones Científicas y Tecnológicas 2004

El modelo plano contempla la definición de una sola tabla donde se encontrarán todos los atributos de los distintos
tipos. Aquellos atributos que no correspondan al tipo almacenado en una fila tendrán valor nulo.
DNI Nombre Apellido Domicilio Ciudad Fecha_Nac LU Espec Año_Ingreso Legajo Cargo Fecha_Ingreso
1234 Juan Garcia abc 12 XYZ 11/11/74 212 ISI 1999 null null null
6789 José Perez lmn 56 LPJ 9/4/60 null null null 994 JTP 1/4/1990
4567 Luis Lopez zjk 34 KLO 24/10/65 null null null null null null
Fig. 2: Esquema relacional resultante de la transformación como tabla jerárquica

La partición vertical implica que se generará una tabla para cada uno de los tipos que componen la jerarquía, cada una
con sus atributos. La clave del supertipo se replica como clave foránea en cada uno de los subtipos.
DNI Nombre Apellido Domicilio Ciudad Fecha_Nac
1234 Juan García Abc 12 XYZ 11/11/74
6789 José Perez Lmn 56 LPJ 9/4/60
4567 Luis López Zjk 34 KLO 24/10/65

Restricciones Clave Foránea

DNI LU Espec Año_Ingreso DNI Legajo Cargo Fecha_Ingreso
1234 212 ISI 1999 6789 994 JTP 1/4/1990

Fig. 3: Esquema relacional resultante de la transformación usando partición vertical

La partición horizontal implementa sólo las tablas correspondientes a los subtipos, trasladando a las mismas todos los
atributos del supertipo. El inconveniente principal de esta transformación es que sólo se pueden representar dos tipos de
objetos: estudiantes ó profesores. Los objetos persona no pueden ser representados en este esquema.
DNI Nombre Apellido Domicilio Ciudad Fecha_Nac LU Espec Año_Ingreso
1234 Juan Garcia abc 12 XYZ 11/11/74 212 ISI 1999

DNI Nombre Apellido Domicilio Ciudad Fecha_Nac Legajo Cargo Fecha_Ingreso

6789 José Perez lmn 56 LPJ 9/4/60 994 JTP 1/4/1990

Fig. 4: Esquema relacional resultante de la transformación usando partición horizontal

TRANSFORMACIONES DEL MODELO A UN ESQUEMA OBJETO-RELACIONAL USANDO SQL:1999

SQL:1999 contempla la implementación de relaciones de generalización-especialización por medio de la definición de
tipos y subtipos del siguiente modo:
CREATE TYPE Persona_typ AS OBJECT MEMBER FUNCTION años_estudio RETURN Integer) NOT
(DNI Integer, Nombre CHAR(20), Apellido CHAR(20), Domicilio FINAL;
CHAR(30), Ciudad CHAR(20), Fecha_nac Date,
MEMBER FUNCTION edad RETURN Integer) NOT FINAL; CREATE TYPE Profesor_typ UNDER Persona_typ AS
(Legajo Integer, Cargo CHAR(20), Fecha_Ingreso Date,
CREATE TYPE Estudiante_typ UNDER Persona_typ AS MEMBER FUNCTION antigüedad RETURN Integer) NOT
(LU Integer, Especialidad CHAR(20), Año_Ingreso CHAR(4), 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 definición de una sola tabla para el tipo persona:
CREATE TABLE persona_table OF Persona_typ;
(DNI Primary Key);
Con esta implementación, cualquiera de los tipos definidos puede constituir una fila de la tabla persona_table. La
definición de la clave primaria, como cualquiera de las otras restricciones sobre los atributos, se debe hacer al nivel de
definición de tabla, no en la definición de tipos, de manera de controlar que no se definan filas duplicadas.

La partición vertical requiere que se defina una tabla para cada uno de los tipos, como sigue:
CREATE TABLE Persona_table OF Persona_typ NOT (DNI Primary Key, LU Unique);
SUBSTITUTABLE AT ALL LEVELS
(DNI Primary Key); CREATE TABLE Profesor_table OF Profesor_typ NOT
SUBSTITUTABLE AT ALL LEVELS
CREATE TABLE Estudiante_table OF Estudiante_typ NOT (DNI Primary Key,
SUBSTITUTABLE AT ALL LEVELS Legajo Unique);
En este caso, con la cláusula NOT SUBSTITUTABLE AT ALL LEVELS, propia del ORDBMS Oracle 9i (Gietz,
2001), sólo objetos del tipo definido para cada tabla pueden incluirse en cada una de ellas. Esto hace la implementación
más consistente y diferente de la implementación plana.

La partición horizontal sólo requiere la definición 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 Científicas y Tecnológicas 2004
se quiere implementar, pero no se podrán almacenar objetos persona, aún cuando las tablas sean “sustituibles”, ya que
este concepto se aplica para objetos que se encuentran en niveles por debajo en la jerarquía, no hacia arriba.

TRANSFORMACIONES DEL MODELO A UN ESQUEMA HÍBRIDO

Este esquema está más volcado a la tecnología Objeto-Relacional, porque aprovecha elementos incorporados por el
estándar SQL:1999, la definición de UDT’s y la capacidad de definir referencias (punteros) entre objetos. El esquema
de esta representación se muestra a continuación:
PERSONA
DNI
Nombre
Apellido
Domicilio
Ciudad
Fecha_Nac
P_Est REF Estudiante
P_Prof REF Profesor

edad ()
ESTUDIANTE PROFESOR
LU Legajo
Especialidad Cargo
Año_Ingreso Fecha_Ingreso
P_Pers REF Persona P_Pers REF Persona

años_estudio () antiguedad ()

Fig. 5: Esquema relacional resultante de la transformación usando partición horizontal

En la Figura 5 las flechas con líneas 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 creación de los tipos para este caso se realiza del siguiente modo:
CREATE TYPE Profesor_typ AS OBJECT
CREATE TYPE Estudiante_typ; (Legajo Integer, Cargo CHAR(20), Fecha_Ingreso Date,
P_Pers REF Persona_typ;
CREATE TYPE Profesor_typ; MEMBER FUNCTION antigüedad RETURN Integer) NOT
FINAL;
CREATE TYPE Persona_typ AS OBJECT
(DNI Integer, Nombre CHAR(20), Apellido CHAR(20), Domicilio CREATE TABLE Persona_table OF Persona_typ
CHAR(30), Ciudad CHAR(20), Fecha_nac Date, (DNI Primary Key);
P_Est REF Estudiante_typ,P_Prof REF Profesor_typ,
MEMBER FUNCTION edad RETURN Integer) NOT FINAL; CREATE TABLE Estudiante_table OF Estudiante_typ
(DNI Primary Key,
CREATE TYPE Estudiante_typ AS OBJECT LU Unique);
( LU Integer, Especialidad CHAR(20), Año_Ingreso CHAR(4),
P_Pers REF Persona_typ, CREATE TABLE Profesor_table OF Profesor_typ
MEMBER FUNCTION años_estudio RETURN Integer) NOT (DNI Primary Key,
FINAL; 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 podrían hacer. Este esquema híbrido está más estrechamente relacionado con la
partición vertical de los modelos anteriores, permitiendo definir tanto objetos Persona, como Estudiante y Profesor.

ANÁLISIS DE LAS IMPLEMENTACIONES

Modelo Plano
La implementación plana tiene la dificultad del manejo de valores nulos, pero que los ORDBMS administran hoy con
mucha eficacia. La implementación relacional, en la que se definen explícitamente los atributos de todos los tipos de la
jerarquía, permite la definición de índices y/o restricciones adicionales para cada uno de ellos. Esto no es posible en la
implementación 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
jerarquía. Esto da mucha flexibilidad para cambiar el modelo y la jerarquía de Generalización-Especialización y la
inclusión de nuevas relaciones en el universo que se modela. Para obtener el mismo efecto en una implementación
relacional, se debe recurrir a un modo menos natural y flexible como cláusulas ALTER TABLE....ADD, y el agregado
de restricciones y relaciones de claves foráneas con otras tablas.
Una gran ventaja de la implementación objeto-relacional es la posibilidad de realizar operaciones y cálculos con los
objetos de la jerarquía, por medio de sus funciones miembros. Por ejemplo, es muy fácil calcular la edad de los objetos
de Persona_table, ya que todos los subtipos heredan la función edad() definida en Persona_typ, que calcula la edad de
las personas a partir de la fecha de nacimiento. Además, es posible definir métodos que se pueden redefinir en los
subtipos para dar lugar a una de las propiedades de la orientación a objetos: el polimorfismo. Esto no es posible siquiera
plantearlo en el modelo relacional.
 Resumen: B-057
UNIVERSIDAD NACIONAL DEL NORDEST E
Comunicaciones Científicas y Tecnológicas 2004
Partición Vertical
En este modelo es posible analizar tres tipos de implementaciones: relacional, híbrida y objeto-relacional.
La implementación relacional tiene la dificultad de tener que realizar operaciones de join cuando se quiere recuperar la
información completa de un estudiante y/o profesor. Esto, dependiendo del tamaño de las tablas y la distribución de las
filas en el almacenamiento, puede ser muy costoso. Además tiene definido el mecanismo de integridad referencial para
administrar la integridad de las referencias manejadas por medio de las claves foráneas.
El esquema híbrido 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 número de libreta, y
siguiendo las respectivas referencias recuperar el resto de la información 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 foráneas del modelo relacional. Esto implica que si el objeto apuntado por una variable REF se
elimina, no hay nada definido por el estándar que diga qué hacer ante este caso. Esta implementación permite el manejo
de funciones miembros, aunque no permite la posibilidad de herencia de atributos ni métodos, ni de polimorfismo, que
sí los tiene la relación de generalización especialización definida por el estándar SQL:1999.
La implementación objeto-relacional es la que presenta mayores ventajas porque puede cambiar flexiblemente las
relaciones, hereda atributos y métodos, puede redefinir los métodos en los subtipos, puede definir índices para varios
puntos de acceso a los datos, tiene la capacidad de definir restricciones sobre todos los atributos.
Partición Horizontal
Esta partición es conveniente cuando en el universo a representar sólo 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 implementación relacional con la objeto-relacional, podemos decir que la mayor diferencia entre ambas
es el manejo de comportamiento entre una y otra. La definición de las operaciones sobre los tipos que no es posible
hacer en una implementación relacional, sí se pueden hacer en una objeto-relacional, con todas las ventajas que esto
propone. Esta implementación aventaja a la relacional en las características 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 generalización-especialización 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, partición vertical y partición horizontal, bajo un esquema
relacional y bajo un esquema objeto-relacional que obedece al estándar SQL:1999. Para la partición vertical se incluyó
también un esquema híbrido, utilizando la capacidad de definir referencias de la tecnología relacional. Se tuvieron en
cuenta las siguientes características: facilidad de implementación, 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 transformación que sea universal y que se adapte a los requerimientos de todos los sistemas
que puedan presentarse a quien diseña las aplicaciones. Pero en líneas generales, se puede concluir que, obviamente las
transformaciones que obedecen al estándar SQL:1999 están 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 información en nuestros días.
Sus fortalezas más destacables son la capacidad de definir comportamiento, herencia de atributos y métodos,
polimorfismo, una mayor flexibilidad para introducir cambios en los modelos originales. Por su parte, la tecnología
relacional presenta características 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 recuperación de información, son muy
importantes para algunas aplicaciones. El esquema híbrido 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 Developer’s Guide - Object-Relational Features, Release 1 (9.0.1). Part No. A88878-01.
Golobisky, M.F.; Fiszman, F.E.; Hernández, F.; Rizzoni, V.; Valin, M., Vecchietti, A. y Alvarez, B.B., 2003. Bases de Datos
Objeto-Relacionales y la Tecnología J2EE. Caso Práctico: Gestión del Macrosistema del Iberá. Experiencias durante el diseño y la
implementación. Revista FACENA, 19:33-45.
Golobisky, M.F.; Fiszman, F.E.y Vecchietti, A., 2003. Un análisis acerca de la transformación de un modelo UML en objetos de una
Base de Datos Objeto-Relacional. Caso de estudio: Modelo de la Herpetofauna del Iberá. Comunicaciones Científicas y
Tecnológicas – 2003. Campus Universitario, Universidad Nacional del Nordeste. Corrientes, Octubre de 2003.
Marcos, E.; B. Vela; J.M. Cavero y P. Cáceres, 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