 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.
 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. 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 subcampos nombre y sucursal. Esta manera
de considerarlo hace que el dominio de editorial no
sea 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 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:

create type Persona

(nombre varchar(20),
dirección varchar(20))
 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.

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 herencia
múltiple, se puede definir un tipo para los ayudantes de
la manera siguiente:

create type Ayudante

under Estudiante, 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.
 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 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.
 Por ejemplo, supóngase que se define la
tabla personas de la manera siguiente:

create table persona of Persona

 Se pueden definir entonces las tablas

estudiantes y profesores como subtablas de
persona:

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 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 subtablas estudiantes y profesores. Sin
embargo, sólo se puede acceder a los atributos que
están presentes en persona.

create table ayudantes

of Ayudante
under estudiantes, profesores
 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.

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 la

declaració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, se
declara añadiendo la cláusula ref is a la instrucción
create 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 de
select ref(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 (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 para

el 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 como
identificador, incluyendo la cláusula ref from en la definición de
tipos:

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 la

referencia es derivada y aún debe especificar un nombre de
atributo autorreferencial. Al insertar una tupla en
departamentos, se puede usar:

insert into departamentos

values (‘Informática’, ‘Juan’)
 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:

select título, editorial.nombre

from libros

 Obsérvese que se hace referencia al campo nombre del

atributo compuesto editorial utilizando una notación con
un punto.
 Se puede usar la siguiente consulta para hallar los nombres y
direcciones de los directores de todos los departamentos.

select director–>nombre, director–>dirección

from departamentos

 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.
 Ahora se considera la forma de manejar los atributos de tipo colección. Los
arrays son 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:

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 en

la 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. 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:

select título, A as autor, editorial.nombre

as nombre-edit, editorial.sucursal
as sucursal.edit,
K as palabra-clave
from 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 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.
 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:

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

as editorial, set(palabra-clave)
as lista-palabras-clave
from 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 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.
 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.