Tipos estructurados y herencia en SQL

Los esquemas de las bases de datos orientadas a objetos suelen necesitar gran nmero de clases.
Frecuentemente, sin embargo, varias de las clases son parecidas entre s. Son parecidas porque
denen iguales atributos y mtodos. No son idnticas porque cada clase dene, adems atributos
y /o mtodos que no comparte con las dems. Sera conveniente denir una representacin de los
atributos y mtodos comunes en un solo lugar. Esto puede hacerse creando una nueva clase,
que contendr solo las caractersticas comunes, y redeniendo las clases originales como
especializaciones
de
la
nueva
clase.
Las clases especializadas adquieren una dependencia de herencia con respecto a la clase general,
ya que heredan los atributos y mtodos denidos en esta. Aparece por tanto el concepto
de jerarqua de clases, que es parecido al de especializacin del modelo entidad-relacin.
Las relaciones entre una clase ms especfica, o

clase derivada, con respecta a su

clase genrica o superclase, siempre son de especializacin, es decir, si la clase A deriva de una
superclase B, lo que queremos decir es que A es un tipo particular de B.
Como ejemplo de estas relaciones, se podran denir las clases Persona, Empleado y Cajero,
donde un Empleado es un tipo especial de Persona, y Cajero es un tipo especial de Empleado.
Una ventaja importante de la herencia en los sistemas orientados a objetos es el concepto de
posibilidad de sustitucin: cualquier mtodo de una clase dada A puede ser invocado con cualquier
objeto perteneciente a cualquier subclase de A. De igual forma, los atributos denidos en
la superclase son utilizables en cualquiera de sus derivadas. Si la clase Persona dene el atributo
Nombre, las clases Empleado y Cajero tambin las denen implcitamente, por la herencia.

Los tipos estructurados permiten representar directamente los atributos compuestos de los
diagramas E-R. Por ejemplo, se puede definir el siguiente tipo estructurado para representar el
atributo compuesto nombre con los atributos componentes nombre_pila y apellidos:
create type Nombre as
(nombre_pila varchar(20),
apellidos varchar(20))
final
De manera parecida, el tipo estructurado siguiente puede usarse para representar el atributo
compuesto direccin:
create type Direccion as
(calle varchar(20),
ciudad varchar(20),
codigo_postal varchar(9))
not final

En SQL estos tipos se denominan tipos definidos por el usuario. La especificacin final indica que
no se puede crear subtipos de nombre, mientras que la especificacin not final de direccin indica
que se pueden crear subtipos de direccin. Ahora se pueden usar estos tipos para crear atributos
compuestos en las relaciones, con slo declarar que un atributo es de uno de estos tipos. Por
ejemplo,
se
puede
crear
una
tabla
cliente
de
la
siguiente
manera:

create table cliente (

nombre Nombre,
direccion Direccion,
fecha_nacimiento date)
O bien, realizando una estructura ms del tipo Cliente y generar la tabla a partir de ella:
create type TipoCliente as
(nombre Nombre,
direccion Direccion,
fecha_nacimiento date)
not final

create table cliente of TipoCliente

Se puede tener acceso a los componentes de los atributos compuestos usando la notacin punto;
por ejemplo, nombre.nombre_pila devuelve el componente nombre de pila del atributo nombre. El
acceso al atributo nombre devolvera un valor del tipo estructurado Nombre.
La siguiente consulta ilustra la manera de tener acceso a los atributos componentes de los
atributos compuestos. La consulta busca el apellido y la ciudad de cada cliente.

select nombre.apellido, direccion.ciudad

from cliente

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 despus en el nivel de las tablas:
Herencia de tipos: Los tipos derivados heredan los atributos de superclase; los mtodos tambin
se heredan por sus subtipos, al igual que los atributos. Sin embargo, un subtipo puede redefinir el
efecto de un mtodo declarndolo de nuevo, y esto ser lo que se conoce como sobre escritura
(overriding) del mtodo.
Supngase

que

se

tiene

la

siguiente

definicin

de

tipo

para

las

personas:

create type Persona

(nombre varchar(20),
direccion varchar(20))
Puede que se desee almacenar en la base de datos informacin adicional sobre las personas que
son estudiantes y sobre las que son profesores. Dado que los estudiantes y los profesores tambin
son personas, se puede usar la herencia para definir en SQL los tipos estudiante y profesor:

create type Estudiante

under Persona
(grado varchar(20),
departamento varchar(20))

create type Profesor

under Persona
(sueldo Integer,
departamento varchar(20))

_______________________________________________________________________________

9.2.2. Tipos estructurados

Los tipos estructurados se pueden declarar y usar en SQL:1999 como en el siguiente ejemplo:
create type Editorial as
(nombre varchar(20),
sucursal varchar(20))
create type Libro as
(ttulo varchar(20),
array-autores varchar(20) array [10],
fecha-pub date,
editorial Editorial,
lista-palabras-clave setof(varchar(20)))
create table libros of type Libro

La primera instruccin define el tipo Editorial, que tiene dos componentes: un nombre y una
sucursal. La segunda instruccin define el tipo Libro, que contiene ttulo, array-autores, que es un
array de autores, una fecha de publicacin, una editorial (de tipo Editorial) y un conjunto de
palabras clave. (La declaracin de lista-palabrasclave como un conjunto usa la sintaxis extendida y
no est soportada en la norma SQL:1999.) Los tipos ilustrados se denomina tipos estructurados en
SQL:1999. Finalmente, se crea la tabla libros que contiene tuplas del tipo Libro. La tabla es similar
a la relacin anidada libros de la Figura 9.1, excepto en que se ha decidido crear un
array de nombres de autores en lugar de un conjunto. El array permite registrar el orden de los
nombres de autores. Los tipos estructurados permiten la representacin directa de atributos
compuestos de los diagramas E-R.
Tambin se pueden usar tipos fila en SQL:1999 para definir atributos compuestos. Por ejemplo, se
podra haber definido un atributo editorial1 como editorial1 row (nombre varchar(20), sucursal
varchar(29)) en lugar de crear un tipo con nombre Editorial.
Por supuesto se pueden crear tablas sin crear un tipo intermedio para la tabla. Por ejemplo, la tabla
libros se podra tambin definir como:
create table libros
(ttulo varchar(20),
array-autores varchar(20) array [10],
fecha-pub date,
editorial Editorial,
lista-palabras-clave setof(varchar(20)))
Con esta declaracin no hay un tipo explcito para las filas de la tabla 2
Un tipo estructurado puede tener mtodos definidos sobre l. Los mtodos se declaran como parte
de la definicin de tipos de un tipo estructurado.
create type Empleado as (
nombre varchar(20),
sueldo integer)
method incrementar(porcentaje integer)

El cuerpo del mtodo se crea separadamente:

create method incrementar(porcentaje integer)
for Empleado
begin
set selft.sueldo = self.sueldo + (self.sueldo*
porcentaje)/100
end

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 despus en el nivel de las tablas.
Herencia de tipos:
Supngase que se dispone de la siguiente definicin de tipos para las personas:
create type Persona
(nombre varchar(20),
direccin varchar(20))
Puede que se desee guardar en la base de datos ms informacin sobre las personas que sean
estudiantes y sobre las que sean profesores. Dado que los estudiantes y los profesores tambin
son personas, se puede utilizar la herencia para definir los tipos estudiante y profesor en
SQL:1999:
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 direccin.
Estudiante y Profesor se denominan subtipos de Persona y sta, a su vez, es un supertipo de
Estudiante y de Profesor.
Los mtodos de un tipo estructurado se heredan por sus subtipos, al igual que los atributos. Sin
embargo, un subtipo puede redefinir el efecto de un mtodo declarando de nuevo el mtodo,
usando overriding method en lugar de method en la declaracin del mtodo.
Supngase ahora que se desea guardar la informacin sobre los ayudantes, que son
simultneamente estudiantes y profesores, quizs incluso en departamentos diferentes. Esto se
puede hacer usando la herencia mltiple, que se estudi en el Captulo 8. La norma

SQL:1999 no soporta herencia mltiple. Sin embargo,los borradores de la norma s lo hacan, y

aunque la norma final la omiti, versiones futuras de la norma SQL pueden introducirla. Lo que se
expone a continuacin se basa en los borradores de la norma.
Por ejemplo, si el sistema de tipos permite la herencia mltiple, se puede definir un tipo para los
ayudantes de la manera siguiente:

create type Ayudante

under Estudiante, Profesor
Ayudante heredara todos los atributos de Estudiante y de Profesor. Surge un problema, sin
embargo, dado que los atributos nombre, direccin y departamento se hallan presentes en
Estudiante y en Profesor.
Los atributos nombre y direccin se heredan en realidad de un origen comn, Persona. As que no
se provoca ningn 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 instruccin as como se muestra en la siguiente definicin del tipo Ayudante:
create type Ayudante
under Estudiante with (departamento as
dep-estudiante)
Profesor with (departamento as
dep-profesor)
SQL:1999 slo soporta herencia nica, es decir, un tipo puede heredar de slo un tipo nico; la
sintaxis usadas es como en los ejemplos anteriores. La herencia mltiple como en el ejemplo
Ayudante no est soportada en SQL:1999. La norma SQL:1999 tambin requiere un campo extra
al final de la definicin de tipos, cuyo valor es final o not final. La palabra clave final dice que los
subtipos no se pueden crear desde el tipo dado, mientras que not final dice que se pueden crear.
En SQL, como en la mayor parte de los lenguajes de programacin, las entidades deben tener
exactamente un tipo ms especfico. Es decir, cada valor debe estar asociado con un tipo
especfico, denominado tipo ms especfico, cuando se crea. Mediante la herencia tambin se
asocia con cada uno de los supertipos de su tipo ms especfico. Por ejemplo, supngase que una
entidad tiene el tipo Persona y el tipo Estudiante. Por tanto, el tipo ms especfico 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.
Herencia de tablas:
Las subtablas en SQL:1999 se corresponden con la nocin del modelo E-R de la especializacin y
la generalizacin. Por ejemplo, supngase 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 tambin presente en las subtablas.
Adems, cuando se declaran estudiantes y profesores como subtablas de persona, cada tupla
presente en estudiantes o profesores tambin estn presentes implcitamente en persona. As, si
una consulta usa la tabla persona, encontrar no slo las tuplas insertadas directamente en la
tabla, sino tambin las tuplas insertadas en sus subtablas estudiantes y profesores. Sin embargo,
slo se puede acceder a los atributos que estn presentes en persona.
Es posible la herencia mltiple con las tablas, como con los tipos. (Ntese, sin embargo, que la
herencia mltiple de tablas no se soporta en SQL:1999.) Por ejemplo, se puede crear una tabla del
tipo Ayudante:
create table ayudantes
of Ayudante
under estudiantes, profesores
Como resultado de la declaracin, cada tupla presente en la tabla ayudantes tambin est presente
implcitamente en las tablas profesores y estudiantes, y a su vez en la tabla persona.
SQL:1999 permite buscar tuplas que estn en persona pero no en sus subtablas usando only
persona en lugar de persona en la consulta.
Hay algunos requisitos de consistencia para las subtablas. Antes de indicar las restricciones es
necesaria una definicin: se dice que las tuplas de una subtabla corresponden a las tuplas de una
tabla padre si tienen los mismo valores para todos los atributos heredados.
As, las tuplas correspondientes representan la misma entidad.
Los requisitos de consistencia para las subtablas son:
1. Cada tupla de la supertabla puede corresponder a lo sumo con una tupla de cada una de sus
tablas inmediatas.
2. SQL:1999 tiene una restriccin adicional que establece que todas las tuplas que se
correspondan se deben derivar de una tupla (insertada en una tabla).
Por ejemplo, sin la primera condicin se podran tener dos tuplas en estudiantes (o en profesores)
correspondiente a la misma persona.
La segunda condicin descarta una tupla en persona correspondiente a tuplas de estudiantes
estudiantes.
y profesores, a menos que esas tuplas estn presentes implcitamente porque se insert una tupla
en la tabla ayudantes, que es una subtabla de profesores y estudiantes.
Dado que SQL:1999 no soporta herencia mltiple,la segunda condicin realmente impide que una
persona sea tanto profesor como estudiante. El mismo problema surgira si no existiese la subtabla
ayudantes, incluso si hubiese herencia mltiple. Obviamente sera til modelar una situacin donde
una persona pueda ser profesor y estudiante, incluso si no est presente la subtabla comn
ayudantes

Las subtablas pueden guardarse de manera eficiente sin rplica de todos los campos heredados
de una de las dos siguientes formas:
Cada tabla almacena la clave primaria (que se puede heredar de una tabla padre) y los atributos
definidos localmente. Los atributos heredados (aparte de la clave primaria) no hace falta guardarlos
y
pueden obtenerse mediante una reunin con la supertabla basada en la clave primaria.
Cada tabla almacena todos los atributos heredados y definidos localmente. Cuando se inserta
una tupla se almacena slo en la tabla en la que se inserta y su presencia se infiere en cada
supertabla. El acceso a todos los atributos de una tupla es ms rpido, dado que no se requiere
una reunin. Sin embargo, en el caso de que no se considere la segunda restriccin de integridad
es decir, una entidad se puede representar en dos subtablas sin estar presente en una subtabla
comn de ambas esta representacin puede resultar en duplicacin de informacin.
9.3.3. Solapamiento de subtablas.
La herencia de tipos debe utilizarse con precaucin. Una base de datos universitaria puede tener
muchos subtipos de Persona, como Estudiante, Profesor, JugadorDeFtbol,CiudadanoExtranjero,
etctera.
Estudiante puede a su vez tener subtipos como EstudianteDeDiplomatura,
EstudianteDeLicenciatura y EstudianteATiempoParcial. Evidentemente, una persona puede
pertenecer a varias de estas categoras simultneamente.
Como se mencion en el Captulo 8, a veces se denomina papel a cada una de estas categoras.
Para que cada entidad tenga exactamente un tipo ms especfico habra que crear un subtipo para
cada combinacin posible de los supertipos. En el ejemplo anterior habra subtipos como
EstudianteDeDiplomaturaExtranjero,
Estudiante DeLicenciaturaJugadorDeFtbolExtranjero,
etctera. Lamentablemente, se acabara con un nmero enorme de subtipos de Persona.
Un enfoque mejor en el contexto de los sistemas de bases de datos es permitir que un objeto tenga
varios tipos, sin que tenga un tipo ms especfico. Los sistemas relacionales orientados a objetos
pueden modelar esta caracterstica utilizando la herencia en el nivel de las tablas, en vez de en el
nivel de los tipos, y permitiendo que las entidades estn en ms de una tabla simultneamente.
Por ejemplo, supngase de nuevo que se tiene el tipo Persona con los subtipos Estudiante y
Profesor, y la tabla correspondiente persona, con subtablas profesores y estudiantes. Se puede
entonces tener una tupla en profesores y otra en estudiantes que correspondan a la misma tupla
en persona.
No hay necesidad de tener un tipo Ayudante como subtipo de Estudiante y Profesor. No es
necesario crear el tipo Ayudante a menos que se desee almacenar atributos extra o redefinir
mtodos de especficamente para las personas que sean estudiantes y profesores.
Sin embargo, SQL:1999 prohbe esta situacin debido al requisito de consistencia 2 del Apartado
9.3.2. Dado que SQL:1999 no soporta herencia mltiple, no se puede usar la herencia para
modelar una situacin donde una persona pueda ser estudiante y profesor. Por supuesto se
pueden crear tablas separadas para representar la informacin sin usar la herencia. Habra que
aadir restricciones de integridad referencial apropiadas para asegurar que los estudiantes
y profesores estn representados tambin en la tabla persona.

BIBLIOGRAFIA:
FUNDAMENTOS DE BASES DE DATOS
Cuarta edicin
Abraham Silberschatz
Bell Laboratories
Henry F. Korth
Bell Laboratories
S. Sudarshan
Instituto Indio de Tecnologa, Bombay