Este documento describe las relaciones anidadas y la herencia en bases de datos orientadas a objetos. Las relaciones anidadas permiten que los valores de los atributos de las tuplas sean relaciones, lo que permite representar objetos complejos con una sola tupla. La herencia permite que los tipos y tablas tengan subtipos y subtablas, respectivamente, heredando sus atributos y métodos. También se discuten consultas con tipos complejos, anidamiento y desanidamiento de relaciones, y comparaciones entre bases de datos orientadas a objetos y relacional

1. RELACIONES ANIDADAS BARRIENTOS TERÁN JOSÉ LUIS CAYETANO CALIXTO FIDEL CONTRERAS MARTÍNEZ VICTORIA GARCÍA SOTO ELIZABETH MÉNDEZ MARTÍNEZ ORCAR YAIR

2. RELACIONES ANIDADAS. El modelo relacional anidado es una extensión del modelo relacional en la que los dominios pueden ser atómicos o de relación. Por tanto, el valor de las tuplas de los atributos puede ser una relación, y las relaciones pueden guardarse en otras relaciones. Los objetos complejos, por tanto, pueden representarse mediante una única tupla de las relaciones anidadas. Si se consideran las tuplas de las relaciones anidadas como elementos de datos, se tiene una correspondencia uno a uno entre los elementos de datos y los objetos de la vista de la base de datos del usuario. Un dominio es atómico si los elementos del mismo se consideran unidades indivisibles.

3. Las relaciones anidadas se ilustran mediante Un ejemplo extraído de una biblioteca. Considérese que para cada libro se almacena la información siguiente: Título del libro Lista de autores Editorial Lista de palabras clave Puede verse que, si se define una relación para la información anterior, varios de los dominios serán no atómicos.

4. Autores. Un libro puede tener varios autores. No obstante, puede que se desee hallar todos los documentos entre cuyos autores estuviera Santos. Por tanto, hay interés en una parte del elemento del dominio «conjunto de autores». Palabras clave. Si se guarda un conjunto de palabras clave de cada documento se espera poder recuperar todos los documentos cuyas claves incluyan una o varias de las palabras clave especificadas. Por tanto, se considera que el dominio de la lista de palabras clave no es atómico. Editorial. A diferencia de palabras clave y autores, editorial no tiene un dominio de tipo conjunto. Sin embargo, se puede considerar que editorial consiste en los subcamposnombre y sucursal. Esta manera de considerarlo hace que el dominio de editorial no sea atómico.

5. TIPOS COMPLEJOS Las relaciones anidadas son sólo un ejemplo de las extensiones del modelo relacional básico. Otros tipos de datos no atómicos, como los registros anidados, también se han mostrado útiles. El modelo de datos orientado a objetos ha creado la necesidad de características como la herencia y las referencias a los objetos.

6. Los sistemas de tipos complejos y la programación orientada a objetos permiten que los conceptos del modelo E-R, como la identidad de las entidades, los atributos multivalorados y la generalización y la especialización, se representen directamente sin que haga falta una compleja traducción al modelo relacional.

7. HERENCIA La herencia puede hallarse en el nivel de los tipos o en el nivel de las tablas. En primer lugar se considerará la herencia de los tipos y después en el nivel de las tablas. HERENCIA DE TIPOS Supóngase que se dispone de la siguiente definición de tipos para las personas: createtypePersona (nombre varchar(20), dirección varchar(20))

8. Puede que se desee guardar en la base de datos más información sobre las personas que sean estudiantes y sobre las que sean profesores. Dado que los estudiantes y los profesores también son personas, se puede utilizar la herencia para definir los tipos estudiante y profesor. createtypeEstudiante underPersona (curso varchar(20), departamento varchar(20)) createtypeProfesor underPersona (sueldo integer, departamento varchar(20))

9. Tanto Estudiante como Profesor heredan los atributos de Persona, es decir, nombre y dirección. Estudiante y Profesor se denominan subtipos de Persona y ésta, a su vez, es un supertipo de Estudiante y de Profesor. Los métodos de un tipo estructurado se heredan por sus subtipos, al igual que los atributos. Sin embargo, un subtipo puede redefinir el efecto de un método declarando de nuevo el método, usando overridingmethoden lugar de methoden la declaración del método. Supóngase ahora que se desea guardar la información sobre los ayudantes, que son simultáneamente estudiantes y profesores, quizás incluso en departamentos diferentes.

10. Por ejemplo, si el sistema de tipos permite la herencia múltiple, se puede definir un tipo para los ayudantes de la manera siguiente: createtypeAyudante underEstudiante, Profesor Ayudante heredaría todos los atributos de Estudiante y de Profesor. Surge un problema, sin embargo, dado que los atributos nombre, dirección y departamento se hallan presentes en Estudiante y en Profesor. Los atributos nombre y dirección se heredan en realidad de un origen común, Persona. Así que no se provoca ningún conflicto al heredarlos de Estudiante y de Profesor. Sin embargo, el atributo departamento se define de manera separada en Estudiante y en Profesor.

11. De hecho, los ayudantes pueden ser estudiantes de un departamento y profesores de otro. Para evitar un conflicto entre los dos ejemplares de departamento se les puede cambiar el nombre utilizando una instrucción as como se muestra en la siguiente definición del tipo Ayudante: createtypeAyudante underEstudiante with(departamento as dep-estudiante) Profesor with(departamento as dep-profesor)

12. En SQL, como en la mayor parte de los lenguajes de programación, las entidades deben tener exactamente un tipo más específico. Es decir, cada valor debe estar asociado con un tipo específico, denominado tipo más específico, cuando se crea. Mediante la herencia también se asocia con cada uno de los supertipos de su tipo más específico. Por ejemplo, supóngase que una entidad tiene el tipo Persona y el tipo Estudiante. Por tanto, el tipo más específico de la entidad es Estudiante, dado que Estudiante es un subtipo de Persona. Sin embargo, una entidad no puede tener los tipos Estudiante y Profesor, a menos que tenga un tipo, como Ayudante, que sea un subtipo de Profesor y de Estudiante.

13. HERENCIA DE TABLAS Por ejemplo, supóngase que se define la tabla personas de la manera siguiente: createtablepersona of Persona Se pueden definir entonces las tablas estudiantes y profesores como subtablasde persona: createtableestudiantes of Estudiante under persona create table profesoresof Profesor underpersona

14. Los tipos de las subtablas deben ser subtipos del tipo de la tabla padre. Por tanto, cada atributo presente en persona debe estar también presente en las subtablas. Además, cuando se declaran estudiantes y profesores como subtablas de persona, cada tupla presente en estudiantes o profesores también están presentes implícitamente en persona. Así, si una consulta usa la tabla persona, encontrará no sólo las tuplas insertadas directamente en la tabla, sino también las tuplas insertadas en sus subtablasestudiantes y profesores. Sin embargo, sólo se puede acceder a los atributos que están presentes en persona. createtableayudantes of Ayudante underestudiantes, profesores

15. TIPOS DE REFERENCIA Los lenguajes orientados a objetos proporcionan la posibilidad de hacer referencia a los objetos. El atributo de un tipo puede ser una referencia a un objeto de un tipo especificado. createtypeDepartamento( nombre varchar(20), director ref(Persona) scopepersona ) createtabledepartamentos of Departamento Se puede omitir la declaración scopepersona de la declaración de tipos y en su lugar añadirla a la instrucción create table. create table departamentosof Departamento (director with options scope persona)

16. Para inicializar un atributo referencia es necesario obtener el identificador de la tupla a la que se va a hacer referencia. Se puede obtener el valor del identificador de una tupla mediante una consulta. Así, para crear una tupla con el valor referencia, se puede crear en primer lugar la tupla con una referencia nula y después establecer la referencia: insertintodepartamentos values(‘Informática’, null) updatedepartamentos set director = (select ref(p) from persona as p where nombre= ‘Juan’) wherenombre = ‘Informática’ Esta sintaxis para acceder al identificador de una tupla está basada en la sintaxis de Oracle.

17. Este atributo, denominado atributo autorreferencial, se declara añadiendo la cláusula refisa la instrucción createtable. create table persona of Persona ref is idosystem generated Donde ido es un nombre de atributo, no una palabra clave. La subconsulta anterior podría usar selectp.ido en lugar de selectref(p). Una alternativa a los identificadores generados por el sistema es permitir a los usuarios generar identificadores. El tipo del atributo autorreferencial se debe especificar como parte de la definición de tipos de la tabla referenciada, y la definición de tabla debe especificar que la referencia la genera el usuario (usergenerated).

18. createtypePersona (nombre varchar(20), dirección varchar(20)) ref using varchar(20) create table persona of Persona refisido usergenerated Al insertar una tupla en persona se debe proporcionar un valor para el identificador: insertintopersona values (‘01284567’, ‘Juan’, ‘Plaza Mayor, 1’) Ninguna otra tupla de persona o sus supertablas pueden tener el mismo identificador. Se puede entonces usar el valor del identificador al insertar una tupla en departamentos, sin necesitar una consulta separada para obtener el identificador. insertintodepartamentos values(‘Informática’, ‘01284567’)

19. Es posible incluso usar un valor existente de clave primaria como identificador, incluyendo la cláusula reffromen la definición de tipos: createtypePersona (nombre varchar(20) primarykey, dirección varchar(20)) ref from nombre create table persona of Persona refisido derived Nótese que la definición de tabla debe especificar que la referencia es derivada y aún debe especificar un nombre de atributo autorreferencial. Al insertar una tupla en departamentos, se puede usar: insertintodepartamentos values(‘Informática’, ‘Juan’)

20. CONSULTAS CON TIPOS COMPLEJOS En este apartado se presenta una extensión del lenguaje de consulta SQL para trabajar con los tipos complejos. Se puede comenzar por un ejemplo sencillo: averiguar el título y el nombre de la editorial de cada documento. La consulta siguiente lleva a cabo esa tarea: selecttítulo, editorial.nombre fromlibros Obsérvese que se hace referencia al campo nombre del atributo compuesto editorial utilizando una notación con un punto.

21. Expresiones de ruta Se puede usar la siguiente consulta para hallar los nombres y direcciones de los directores de todos los departamentos. selectdirector–>nombre, director–>dirección fromdepartamentos Una expresión como «director–>nombre» se denomina una expresión de ruta. Dado que director es una referencia a una tupla de la tabla persona, el atributo nombre en la consulta anterior es el atributo nombre de la tupla de la tabla persona. Se pueden usar las referencias para ocultar las operaciones reunión; en el ejemplo anterior, sin las referencias, el campo director de departamento se declararía como clave externa de la tabla persona. Para encontrar el nombre y dirección del director de un departamento se necesitaría una reunión explícita de las relaciones departamentos y persona. El uso de referencias simplifica considerablemente la consulta.

22. Atributos de tipo colección Ahora se considera la forma de manejar los atributos de tipo colección. Los arraysson el único tipo colección soportado por SQL:1999, pero también se usa la misma sintaxis para los atributos de tipo relación. Una expresión que se evalúe a una colección puede aparecer en cualquier lugar en que aparezca un nombre de relación, tal como en la cláusula from, como ilustran los siguientes párrafos. Se usa la tabla libros que se definió anteriormente. Si se desea hallar todos los documentos que tienen las palabras «base de datos» entre sus palabras clave se puede utilizar la consulta siguiente: selecttítulo fromlibros where«base de datos» in (unnest(lista-palabrasclave)) Obsérvese que se ha usado unnest(lista-palabras-clave) en una posición en la que SQL sin relaciones anidadas habría exigido una subexpresiónselect-fromwhere. Si se sabe que un libro en particular tiene tres autores, se podría escribir: select array-autores[1], array-autores[2], array-autores[3] fromlibros wheretítulo = ‘Fundamentos de bases de datos’

23. ANIDAMIENTO Y DESANIDAMIENTO La transformación de una relación anidada en una forma con menos (o sin) atributos de tipo relación se denomina desanidamiento. La relación libros tiene dos atributos, array-autores y lista-palabras-clave, que son colecciones, y otros dos, título y editorial, que no lo son. Supóngase que se desea convertir la relación en una sola relación plana, sin relaciones anidadas ni tipos estructurados como atributos. Se puede utilizar la siguiente consulta para llevar a cabo la tarea: selecttítulo, A as autor, editorial.nombre as nombre-edit, editorial.sucursal as sucursal.edit, K as palabra-clave from librosas B, unnest(B.array-autores) as A, unnest(B.lista-palabras-clave) as K La variable B de la cláusula fromse declara para que tome valores de libros. La variable A se declara para que tome valores de los autores en array-autores para el documento B y K se declara para que tome valores de las palabras clave de la lista-palabras-clave del mismo.

24. El proceso inverso de transformar una relación 1FN en una relación anidada se denomina anidamiento. El anidamiento puede realizarse mediante una extensión de la agrupación en SQL. En el uso normal de la agrupación en SQL se crea (lógicamente) una relación multiconjunto temporal para cada grupo y se aplica una función de agregación a esa relación temporal. Devolviendo el multiconjunto en lugar de aplicar la función de agregación se puede crear una relación anidada. La consulta siguiente anida la relación en el atributo palabra-clave: selecttítulo, autor, Editorial(nombre-edit, sucursal-edit) as editorial, set(palabra-clave) as lista-palabras-clave fromlibros-planos groupbytítulo, autor, editorial

25. Si se desea anidar también el atributo autor y volver a convertir, por tanto, la tabla libros-planos, en 1FN, en la tabla anidada libros mostrada en la Figura 9.1 se puede utilizar la consulta siguiente: selecttítulo, set(autor) as array-autores, Editorial (nombre-edit, sucursal-edit) as editorial, set(palabra-clave) as lista-palabras-clave fromlibros-planos groupbytítulo, editoria

26. COMPARACIÓN ENTRE LAS BASES DE DATOS ORIENTADAS A OBJETOSY LAS BASES DE DATOS RELACIONALES ORIENTADAS A OBJETOS Las extensiones persistentes de los lenguajes de programación y los sistemas relacionales orientados a objetos se han dirigido a mercados diferentes. La naturaleza declarativa y la limitada potencia (comparada con la de los lenguajes de programación) del lenguaje SQL proporcionan una buena protección de los datos respecto de los errores de programación y hace que las optimizaciones de alto nivel, como la reducción de E/S, resulten relativamente sencillas.

27. Los sistemas relacionales orientados a objetos se dirigen a la simplificación de la realización de los modelos de datos y de las consultas mediante el uso de tipos de datos complejos. Las aplicaciones típicas incluyen el almacenamiento y la consulta de datos complejos, incluyendo los datos multimedia. Los lenguajes declarativos como SQL, sin embargo, imponen una reducción significativa del rendimiento a ciertos tipos de aplicaciones que se ejecutan principalmente en la memoria principal y realizan gran número de accesos a la base de datos. Los lenguajes de programación persistentes se dirigen a las aplicaciones de este tipo que tienen necesidad de elevados rendimientos.

28. Los puntos fuertes de los varios tipos de sistemas de bases de datos pueden resumirse de la manera siguiente: • Sistemas relacionales: tipos de datos sencillos, lenguajes de consulta potentes, protección elevada. • Bases de datos orientadas a objetos basadas en lenguajes de programación persistentes: tipos de datos complejos, integración con los lenguajes de programación, elevado rendimiento. • Sistemas relacionales orientados a objetos: tipos de datos complejos, lenguajes de consulta potentes, protección elevada.