El modelo relacional anidado es una extensión delmodelo relacional en la que los dominios pueden seratómicos o de relación. Por tanto, el valor de lastuplas de los atributos puede ser una relación, y lasrelaciones pueden guardarse en otras relaciones. Losobjetos complejos, por tanto, pueden representarsemediante una única tupla de las relacionesanidadas. Si se consideran las tuplas de lasrelaciones anidadas como elementos de datos, setiene una correspondencia uno a uno entre loselementos de datos y los objetos de la vista de labase de datos del usuario.

Un dominio es atómico si los elementos del mismo seconsideran unidades indivisibles.

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.

Autores. Un libro puede tener varios autores. Noobstante, puede que se desee hallar todos losdocumentos entre cuyos autores estuviera Santos.Por tanto, hay interés en una parte del elemento deldominio «conjunto de autores».

Palabras clave. Si se guarda un conjunto de palabrasclave de cada documento se espera poderrecuperar todos los documentos cuyas clavesincluyan una o varias de las palabras claveespecificadas. Por tanto, se considera que eldominio 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. Sinembargo, se puede considerar que editorial consisteen los subcampos nombre y sucursal. Esta manerade considerarlo hace que el dominio de editorial nosea atómico.

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.

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.

La herencia puede hallarse en el nivel delos tipos o en el nivel de las tablas. En primerlugar se considerará la herencia de los tiposy después en el nivel de las tablas.

HERENCIA DE TIPOS

Supóngase que se dispone de la siguientedefinición de tipos para las personas:

create type Persona

(nombre varchar(20),

dirección varchar(20))

Puede que se desee guardar en la base de datosmás información sobre las personas que seanestudiantes y sobre las que sean profesores. Dadoque los estudiantes y los profesores también sonpersonas, se puede utilizar la herencia para definir lostipos estudiante y profesor.

create type Estudiante

under Persona

(curso varchar(20),

departamento varchar(20))

create type Profesor

under Persona

(sueldo integer,

departamento varchar(20))

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 overriding method en lugar de

method en 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.

Por ejemplo, si el sistema de tipos permite la herenciamúltiple, se puede definir un tipo para los ayudantes dela manera siguiente:

create type Ayudante

under Estudiante, Profesor

Ayudante heredaría todos los atributos de Estudiante yde Profesor. Surge un problema, sin embargo, dadoque los atributos nombre, dirección y departamento sehallan presentes en Estudiante y en Profesor.

Los atributos nombre y dirección se heredan enrealidad de un origen común, Persona. Así que no seprovoca ningún conflicto al heredarlos de Estudiante yde Profesor. Sin embargo, el atributo departamento sedefine de manera separada en Estudiante y enProfesor.

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:

create type Ayudante

under Estudiante with (departamento as

dep-estudiante)

Profesor with (departamento as

dep-profesor)

En SQL, como en la mayor parte de los lenguajesde programación, las entidades deben tenerexactamente un tipo más específico. Es decir,cada valor debe estar asociado con un tipoespecífico, denominado tipo más específico,cuando se crea. Mediante la herencia también seasocia con cada uno de los supertipos de su tipomás específico.

Por ejemplo, supóngase que una entidad tiene eltipo Persona y el tipo Estudiante. Por tanto, el tipomás específico de la entidad es Estudiante, dadoque Estudiante es un subtipo de Persona. Sinembargo, una entidad no puede tener los tiposEstudiante y Profesor, a menos que tenga un tipo,como Ayudante, que sea un subtipo de Profesor yde Estudiante.

Por ejemplo, supóngase que se define latabla personas de la manera siguiente:

create table persona of Persona

Se pueden definir entonces las tablasestudiantes y profesores como subtablas depersona:

create table estudiantes of Estudiante

under persona

create table profesores of Profesor

under persona

Los tipos de las subtablas deben ser subtipos del tipo de latabla padre. Por tanto, cada atributo presente enpersona debe estar también presente en las subtablas.

Además, cuando se declaran estudiantes y profesorescomo subtablas de persona, cada tupla presente enestudiantes o profesores también están presentesimplícitamente en persona. Así, si una consulta usa latabla persona, encontrará no sólo las tuplas insertadasdirectamente en la tabla, sino también las tuplasinsertadas en sus subtablas estudiantes y profesores. Sinembargo, sólo se puede acceder a los atributos queestán presentes en persona.

create table ayudantes

of Ayudante

under estudiantes, profesores

Los lenguajes orientados a objetos proporcionan laposibilidad de hacer referencia a los objetos. El atributo deun tipo puede ser una referencia a un objeto de un tipoespecificado.

create type Departamento(

nombre varchar(20),director ref(Persona) scope persona

)

create table departamentos of Departamento

Se puede omitir la declaración scope persona de ladeclaración de tipos y en su lugar añadirla a la instrucción

create table.

create table departamentos of Departamento

(director with options scope persona)

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:

insert into departamentos

values (‘Informática’, null)

update departamentos

set director = (select ref(p)

from persona as p

where nombre = ‘Juan’)

where nombre = ‘Informática’

Esta sintaxis para acceder al identificador de una tupla está basada en

la sintaxis de Oracle.

Este atributo, denominado atributo autorreferencial, sedeclara añadiendo la cláusula ref is a la instruccióncreate table.

create table persona of Persona

ref is ido system generated

Donde ido es un nombre de atributo, no una palabra clave.

La subconsulta anterior podría usar select p.ido en lugar deselect ref(p).

Una alternativa a los identificadores generados por elsistema es permitir a los usuarios generar identificadores.

El tipo del atributo autorreferencial se debe especificarcomo parte de la definición de tipos de la tablareferenciada, y la definición de tabla debe especificarque la referencia la genera el usuario (user generated).

create type Persona

(nombre varchar(20),

dirección varchar(20))

ref using varchar(20)

create table persona of Persona

ref is ido user generated

Al insertar una tupla en persona se debe proporcionar un valor parael identificador:

insert into persona 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.

insert into departamentos

values (‘Informática’, ‘01284567’)

Es posible incluso usar un valor existente de clave primaria comoidentificador, incluyendo la cláusula ref from en la definición detipos:

create type Persona

(nombre varchar(20) primary key,

dirección varchar(20))

ref from nombre

create table persona of Persona

ref is ido derived

Nótese que la definición de tabla debe especificar que lareferencia es derivada y aún debe especificar un nombre deatributo autorreferencial. Al insertar una tupla endepartamentos, se puede usar:

insert into departamentos

values (‘Informática’, ‘Juan’)

En este apartado se presenta una extensión del lenguajede 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 cadadocumento. La consulta siguiente lleva a cabo esa

tarea:

select título, editorial.nombre

from libros

Obsérvese que se hace referencia al campo nombre delatributo compuesto editorial utilizando una notación conun punto.

Se puede usar la siguiente consulta para hallar los nombres ydirecciones de los directores de todos los departamentos.

select director–>nombre, director–>direcciónfrom departamentos

Una expresión como «director–>nombre» se denomina una expresiónde ruta.

Dado que director es una referencia a una tupla de la tabla persona, elatributo nombre en la consulta anterior es el atributo nombre de latupla de la tabla persona.

Se pueden usar las referencias para ocultar las operaciones reunión; enel ejemplo anterior, sin las referencias, el campo director dedepartamento se declararía como clave externa de la tabla persona.Para encontrar el nombre y dirección del director de un departamentose necesitaría una reunión explícita de las relaciones departamentos ypersona. El uso de referencias simplifica considerablemente la consulta.

Ahora se considera la forma de manejar los atributos de tipo colección. Losarrays son el único tipo colección soportado por SQL:1999, pero también seusa la misma sintaxis para los atributos de tipo relación. Una expresión que seevalúe a una colección puede aparecer en cualquier lugar en queaparezca un nombre de relación, tal como en la cláusula from, comoilustran 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 dedatos» entre sus palabras clave se puede utilizar la consulta siguiente:

select título

from libros

where «base de datos» in (unnest(lista-palabrasclave))

Obsérvese que se ha usado unnest(lista-palabras-clave) en una posición enla que SQL sin relaciones anidadas habría exigido una subexpresión select-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]

from libros

where título = ‘Fundamentos de bases de datos’

La transformación de una relación anidada en una forma con menos(o sin) atributos de tipo relación se denomina desanidamiento. Larelació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ónplana, sin relaciones anidadas ni tipos estructurados como atributos. Sepuede utilizar la siguiente consulta para llevar a cabo la tarea:

select título, A as autor, editorial.nombreas nombre-edit, editorial.sucursalas sucursal.edit,

K as palabra-clavefrom libros as B, unnest(B.array-autores)as A, unnest(B.lista-palabras-clave) as K

La variable B de la cláusula from se declara para que tome valores delibros. La variable A se declara para que tome valores de los autores enarray-autores para el documento B y K se declara para que tomevalores de las palabras clave de la lista-palabras-clave del mismo.

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 multiconjuntotemporal 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:

select título, autor, Editorial(nombre-edit, sucursal-edit)

as editorial, set(palabra-clave)

as lista-palabras-clavefrom libros-planos

groupby título, autor, editorial

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:

select título, set(autor) as array-autores, Editorial

(nombre-edit, sucursal-edit) as editorial,

set(palabra-clave) as lista-palabras-clave

from libros-planos

groupby título, editoria

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.

Los sistemas relacionales orientados a objetos sedirigen a la simplificación de la realización de losmodelos de datos y de las consultas mediante el usode tipos de datos complejos. Las aplicaciones típicasincluyen el almacenamiento y la consulta de datoscomplejos, incluyendo los datos multimedia.

Los lenguajes declarativos como SQL, sin embargo,imponen una reducción significativa del rendimientoa ciertos tipos de aplicaciones que se ejecutanprincipalmente en la memoria principal y realizangran número de accesos a la base de datos. Loslenguajes de programación persistentes se dirigen alas aplicaciones de este tipo que tienen necesidadde elevados rendimientos.

Los puntos fuertes de los varios tipos de sistemas de basesde datos pueden resumirse de la manera siguiente:

• Sistemas relacionales: tipos de datos sencillos, lenguajes deconsulta potentes, protección elevada.

• Bases de datos orientadas a objetos basadas en lenguajesde programación persistentes: tipos de datos complejos,integración con los lenguajes de programación, elevadorendimiento.

• Sistemas relacionales orientados a objetos: tipos de datoscomplejos, lenguajes de consulta potentes, protecciónelevada.