TIPOS DE DATOS COMPLEJOS Las relaciones anidadas son slo un ejemplo de las extensiones del modelo relacional bsico.

Otros tipos de datos no atmicos, como los registros anidados, tambin se han mostrado tiles. El modelo de datos orientado a objetos ha creado la necesidad de caractersticas como la herencia y las referencias a los objetos. Los sistemas de tipos complejos y la programacin orientada a objetos permiten que los conceptos del modelo E-R, como la identidad de las entidades, los atributos multivariados y la generalizacin y la especializacin, se representen directamente sin que haga falta una compleja traduccin al modelo relacional. En este apartado se describen las extensiones de SQL para que permita los tipos complejos, incluyendo las relaciones anidadas y las caractersticas orientadas a objetos. La presentacin se basa en la norma SQL:1999, pero tambin se describen caractersticas que no estn actualmente en la norma pero que pueden ser introducidas en futuras versiones de la norma SQL. Considrese este fragmento de cdigo. create table libros ( ... lista-palabras-clave setof(varchar(20)) ... ) Esta definicin de tabla es diferente de las definiciones en las bases de datos relacionales normales, ya que permite que los atributos sean conjuntos, permitiendo que los atributos multivalorados de los diagramas E-R se representen directamente. Los conjuntos son ejemplares de los tipos coleccin. Otros ejemplares son los arrays y los multiconjuntos (es decir, colecciones sin orden donde un elemento puede aparecer varias veces). Las siguientes definiciones de atributos ilustran la declaracin de un array: array-autores varchar(20) array [10] array-autores es un array de hasta 10 nombres de autor. Se puede acceder a los elementos del array especificando el ndice del array, por ejemplo, array-autores[1]. Los arrays son el nico tipo coleccin soportado en SQL:1999; la sintaxis usada es como en la declaracin precedente. SQL:1999 no da soporte a conjuntos sin orden o multiconjuntos, aunque es posible que aparezcan en versiones futuras de SQL1. Muchas aplicaciones actuales de bases de datos necesitan almacenar atributos grandes (del orden de varios kilobytes), tales como la fotografa de una persona, o muy grandes (del orden de varios megabytes o incluso gigabytes), tales como imgenes mdicas de alta resolucin o clips de vdeo. SQL:1999 proporciona por tanto nuevos tipos de datos para objetos de gran tamao para datos de caracteres (clob) y binarios (blob). Las letras lob en estos tipos de datos son acrnimos de Large OBject (objeto grande). Por ejemplo, se pueden declarar los siguientes atributos: crtica-libro clob(10KB) imagen blob(10MB)

pelcula blob(2GB) Los objetos grandes se usan normalmente en aplicaciones externas, y tiene poco sentido extraerlos completamente en SQL. En su lugar, una aplicacin conseguira un localizador de un objeto grande y lo usara para manipularlo desde el lenguaje anfitrin. Por ejemplo, JDBC permite al programador extraer un objeto grande en pequeos trozos, en lugar de todo a la vez, de forma muy parecida a la extraccin de datos de un archivo del sistema operativo. 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 tabla2. 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 La variable self se refiere al ejemplar del tipo estructurado sobre el que se invoca el mtodo. El cuerpo del mtodo puede contener instrucciones procedimentales, que se estudiarn en el Apartado 9.6. CREACION DE VALORES DE TIPO COMPLEJOS En SQL:1999 se usan las funciones constructoras para crear valores de tipos estructurados. Una funcin con el mismo nombre que un tipo estructurado es una funcin constructora para el tipo estructurado. Por ejemplo, se podra declarar una constructora para el tipo Editorial como: create function Editorial (n varchar(20), s varchar(20)) returns Editorial begin set nombre = n; set sucursal = s; end Se puede usar entonces Editorial(McGraw-Hill, Nueva York) para crear un valor del tipo Editorial. SQL:1999 tambin soporta otras funciones adems de las constructoras, como se ver en el Apartado 9.6; los nombres de estas funciones deben ser diferentes de cualquier tipo estructurado. Ntese que en SQL:1999, a diferencia de en las bases de datos orientadas a objetos, un constructor crea un valor del tipo, no un objeto del tipo. Es decir, el valor que crea el constructor no tiene identidad de objeto. Los objetos en SQL:1999 se corresponden con tuplas de una relacin, y se crean insertando tuplas en las relaciones. De manera predeterminada, cada tipo estructurado tiene un constructor sin argumentos, que establece los atributos a sus valores predeterminados. Cualquiera otra constructora tiene que crearse explcitamente. Puede haber ms de una constructora para el mismo tipo estructurado; aunque tengan el mismo nombre, tienen que ser distinguibles por el nmero de argumentos y sus tipos. En SQL:1999 se puede crear un array de valores como:

array*Silberschatz, Korth, Sudarsan+ Se puede construir un valor de fila listando sus atributos entre parntesis. Por ejemplo, si se declara un atributo editorial1 como un tipo fila (como en el Apartado 9.2.2), se puede construir el siguiente valor para l: (McGraw-Hill, Nueva York) sin usar una constructora. Los atributos de tipo conjunto, tales como lista-palabras- clave, se crean enumerando sus elementos entre parntesis siguiendo a la palabra clava set. Se pueden crear valores de tipo multiconjunto al igual que con los valores de tipo conjunto, reemplazando set por multiset3. As, se puede crear una tupla del tipo definido por la relacin libros como: (Compiladores,array*Gmez, Santos+, Editorial(McGraw-Hill, Nueva York), set( traduccin, anlisis)) Aqu se ha creado un valor para el atributo Editorial invocando a la funcin constructora de Editorial con argumentos apropiados. Si se desea insertar la tupla anterior en la relacin libros, se podra ejecutar la instruccin: insert into libros values (Compiladores,array*Gmez, Santos+, Editorial(McGraw-Hill, Nueva York), set( traduccin, anlisis)) HERENCIA La herencia puede hallarse en el nivel de los tipos o en el nivel de las tablas. En primer lugar se considerar laherencia 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. Por tanto, puede ser til eliminar la segunda restriccin de consistencia. 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, Jugador- DeFtbol, 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, EstudianteDeLicenciaturaJugadorDeFtbolExtranjero, 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. TIPOS DE ARREGLO MULTICONJUNTO EN SQL SQL soporta dos tipos de conjuntpos arrays y multiconjuntos. Un multiconjunto es un conjunto no ordenado, en el que cada elemento puede aparecer varias veces. Los multiconjuntos son como los conjuntos, salvo que os conjuntos permiten que cada elemento aparezca, como mucho una vez. Supngase que se desea registrar informacin sobre libros, incluido un conjunto de palabras clave para cada libro, adems se desea almacenar el nombre de los autores de un libro en forma de array, a diferencia de los elementos de los multiconjuntos, los elementos de los arrays estn ordenados, de modo que se puede distinguir el primer autor del segundo,etc. Estos se pueden definir como arrays y como multiconjuntos: Crate type Editor as (nombre varchar(20), sucursal varchar(20)) crate type Libro as (titulo varchar(20), array_autores varchar (20) array [10], fecha_publicacion date, editor Editor, conjunto_palabras_clave varchar(20)multiset)

create table libro of Libro la primera instruccion define el tipo denominado Editor, que tiene dos componentes: nombre y sucursal. La segunda instruccin define el tipo estructurado Libro, que contiene titulo, un array_autores, que es un array de hasta de diez nombres de autor, una fecha de publicacin, un editor y un multiconjunto de palabras clave. Finamente se crea la tabla libros, que contiene las tuplas del tipo libro. Creacin y acceso a los valores de conjunto Si se desea insertar una tupla en la relacin en la relacin libros se puede ejecutar: Insert into libros Values (compiladores ,array[Gomez,Santos], New Editor(McGraw Hill,Nueva York), Multiset [analisis sintactico,analisis]) Se puede tener acceso a los elementos del array o actualizarlos especificando el indice del array, por ejemplo, array_autores[1]. IDENTIDAD DE LOS OBJETOS Y TIPOS DE REFERENCIA EN SQL En SQL se puede definir el tipo departamento con el campo nombre y el campo director, que es una referencia al tipo persona, y la tabla departamentos del tipo departamento, de la manera siguiente: Crate type Departamento( Nombre varchar (20), Director ref (Persona) scope personas ) Crate table departamentos of Departamento En este caso la referencia esta restringida a las tuplas de la tabla personas. La restriccin del mbito (scope) de referencia a las tuplas de una tabla es obligatoria es SQL, y hace que las referencias se comporten como como las claves externas. Se puede omitir la declaracin scope personas de la declaracin de tipos y hacer, en su lugar, un aadido a la instruccin create table: Create table departamentos of Departamento (director with options scope personas)

La table a la que se hace referencia debe tener un atributo que guarde el identificador de cada tuple. Ese atributo, denominado atributo autoreferencial (self-referential attribute), se declara aadiendo una clausula ref is a la instruccion crate table: Crate table personas of Persona Ref is id_personal system generated En este caso, id_personal es el nombre de un atributo, no una palabra clave, y la instruccin crate table especifica que la base de datos degenera de manera automtica el identificador. Para inicializar el atributo de referencia hay que obtener el identificador de la tupla a la que se va a hacer referencia: Insert into departamentos values (CS,null) update departamentos set director=(select p.id_personal from personal as p where nombre=Martin) where nombre=CS una alternativa a los identificadores generados por el sistema es permitir que los usuarios generen los identificadores. El tipo del atributo autoreferencial debe especificarse como parte de la definicin de tipos de la tabla a la que se hace referencia, y la definicin de la tabla debe especificar que la referencia esta generada por el usuario(user generated): crate type Persona (nombre varchar(20), direccin varchar(20)) ref using varchar (20) create table personas of Persona ref is id_personal user generated al inserter tuplas en personas hay que proporcionar el valor del identificador: insert into personas (id_personas, nombre, direcion) values (01284567,Martin,Avenida del segura,23) Ninguna otra tupla de personas, ni de sus subtablas puede tener el mismo identificador. Por tanto: Inert into departamentos values (CS,01284567)

incluso es posible usar el valor de una clave primaria ya existente como identificador incluyendo la clausula ref from en la definicin de tipos. Tngase en cuenta que la definicin de la tabla debe especificar que la referencia es derivada, debe seguir especificando el nombre de un atributo autorreferencial. IMPLEMENTACION DE LAS CARACTERISTICAS O-R Los sistemas de bases de datos relacionales orientadas a objetos son bsicamente extensiones de los sistemas de bases de datos relacionales ya existentes. Las modificaciones resultan necesarias en muchos niveles de sistemas de base de datos. Para minimizar las modificaciones en el cdigo del sistema de almacenamiento, los tipos de datos complejos soportados por los sistemas relaciones orientados a objetos se pueden traducir al sistema de tipo mas sencillo de las bases de datos relacionales. Las subtablas se pueden almacenar de manera eficiente, sin replica de todos los campos heredados, de una de estas maneras: Cada tabla almacena la clave primaria y los atributos que se definen localmente. No hace falta almacenar los atributos heredados, se pueden obtener mediante una reunin con la supertabla de acuerdo con la tabla primaria. Cada tabla almacena todos los atributos heredados y definidos localmente. Cuando se inserta una tupla, solo se almacena en la tabla en que se inserta y su presencia se infiere en cada una de las supertablas. El acceso a todos los atributos de las tuplas es mas rpido, ya que no hace falta ninguna reunin.