Tipos estructurados y herencia en SQL

Los esquemas de las bases de datos orientadas a objetos suelen necesitargran nmero de clases. Frecuentemente, sin embargo, varias de las clasesson parecidas entres. Son parecidas porque denen iguales atributos ymtodos. No sonidnticasporque cada clase dene, adems atributos y /omtodosque no comparte con lasdems. Seraconveniente denir unarepresentacinde los atributos ymtodoscomunes en un solo lugar. Esto puede hacerse creando una nueva clase, quecontendrsolo lascaractersticas comunes, y redeniendo las clasesoriginales como especializaciones de la nueva clase.

Las clases especializadas adquieren una dependencia de herencia conrespecto a la clase general, ya que heredan los atributos ymtodosdenidosen esta. Aparece por tanto el concepto dejerarquade clases, que es parecidoal deespecializacindel modelo entidad-relacin.Las relaciones entre una clase ms especfica, o clase derivada, con respecta a su clasegenricao superclase, siempre son deespecializacin, es decir,si la clase A deriva de una superclase B, lo que queremos decir es que A esun tipo particular de B.Como ejemplo de estas relaciones, sepodrandenir las clases Persona,Empleado y Cajero, donde un Empleado es un tipo especial de Persona, yCajero es un tipo especial de Empleado.Una ventaja importante de la herencia en los sistemas orientados aobjetos es el concepto de posibilidad desustitucin: cualquiermtododeuna clase dada A puede ser invocado con cualquier objeto pertenecientea cualquier subclase de A. De igual forma, los atributos denidos en lasuperclase son utilizables en cualquiera de sus derivadas. Si la clase Personadene el atributo Nombre, las clases Empleado y Cajerotambinlas denenimplcitamente, 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 typeNombreas(nombre_pilavarchar(20),apellidosvarchar(20))final

De manera parecida, el tipo estructurado siguiente puede usarse para representar el atributo compuesto direccin:

create typeDireccionas(callevarchar(20),ciudadvarchar(20),codigo_postalvarchar(9))not final

En SQL estos tipos se denominan tipos definidos por el usuario. La especificacinfinalindica que no se puede crear subtipos de nombre, mientras que la especificacinnot finalde 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 tablecliente (nombreNombre,direccionDireccion,fecha_nacimientodate)

O bien, realizando una estructura ms del tipo Cliente y generar la tabla a partir de ella:

create typeTipoClienteas(nombreNombre,direccionDireccion,fecha_nacimientodate)not final

create tableclienteofTipoCliente

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 estructuradoNombre.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.

selectnombre.apellido, direccion.ciudadfromcliente

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 typePersona(nombrevarchar(20),direccionvarchar(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 typeEstudianteunderPersona(gradovarchar(20),departamentovarchar(20))

create typeProfesorunderPersona(sueldoInteger,departamentovarchar(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 unarray 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 Empleadobeginset selft.sueldo = self.sueldo + (self.sueldo*porcentaje)/100end

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 Estudianteunder Persona(curso varchar(20),departamento varchar(20))create type Profesorunder 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 normaSQL: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 Ayudanteunder 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 evitarun 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 Ayudanteunder Estudiante with (departamento asdep-estudiante)Profesor with (departamento asdep-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 Estudianteunder personacreate table profesores of Profesorunder 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 ayudantesof Ayudanteunder 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 ayudantesLas 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 ypueden 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 Apartado9.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 estudiantesy profesores estn representados tambin en la tabla persona.

BIBLIOGRAFIA:

FUNDAMENTOS DE BASES DE DATOSCuarta edicinAbraham SilberschatzBell LaboratoriesHenry F. KorthBell LaboratoriesS. SudarshanInstituto Indio de Tecnologa, Bombay