Universidad de Castilla-La Mancha

Escuela Superior de Informtica

Bases de Datos Orientadas a Objetos y Bases de Datos Objeto-Relacionales

Rafael Gmez-Cornejo Rubio Adrin Maire Jess Ramn Oviedo Lama

Modelos Avanzados de Bases de Datos 25 de febrero de 2009

-1-

ndice
ndice ................................................................................................................................ 2 1. Bases de Datos Orientadas a Objetos ........................................................................... 2 1.1. Introduccin ........................................................................................................... 2 1.2. Modelo de datos Orientado a Objetos .................................................................... 3 1.2.1. Estructura de los objetos................................................................................. 3 1.2.2. Clases de Objetos ........................................................................................... 3 1.2.3. Herencia.......................................................................................................... 3 1.2.4. Herencia Mltiple. .......................................................................................... 4 1.2.5. Polimorfismo .................................................................................................. 4 1.2.7. Continentes de objetos.................................................................................... 4 1.3. Lenguajes de programacin persistente. ................................................................ 4 1.3.1. Persistencia de los objetos .............................................................................. 4 1.3.2. Identidad de los objetos y punteros a memoria .............................................. 5 1.3.3. Almacenamiento y acceso a los objetos persistentes...................................... 6 1.4. El modelo estndar ODMG (Object Database Management Group)..................... 6 1.4.1. Objetos............................................................................................................ 6 1.4.2. Literales .......................................................................................................... 7 1.4.3. Propiedades..................................................................................................... 7 1.4.4. Lenguaje de definicin de objetos ODL......................................................... 8 1.4.5. Lenguaje de consulta de objetos OQL............................................................ 8 2. Bases de datos objeto-relacionales ............................................................................... 9 2.1. Tipos complejos..................................................................................................... 9 2.1.1. Tipos colecciones ......................................................................................... 10 2.1.2. Tipos Estructurados en SQL1999 o definicin de objetos ........................... 11 2.1.3. Instanciacin de tipos complejos.................................................................. 11 2.2. Herencia............................................................................................................... 12 2.2.1. Herencia de tipo............................................................................................ 12 2.2.2. Herencia de tablas......................................................................................... 13 2.2.3. Solapamiento de subtablas............................................................................ 13 2.3. Tipos de referencia .............................................................................................. 13 2.4. Consultas con tipos complejos ............................................................................ 14 2.5. Funciones y procedimientos ................................................................................ 15 3. Comparacin entre los Modelos. ................................................................................ 17 4. Bibliografa................................................................................................................. 18

1. Bases de Datos Orientadas a Objetos

1.1. Introduccin
Las aplicaciones de bases de datos tradicionales consisten en tareas de procesamiento de datos conceptualmente simples. Los elementos de datos bsicos son registros bastante pequeos y cuyos campos son atmicos, es decir, no contienen estructuras adicionales y en los que se cumple la Primera Forma Normal.

-2-

Pero en los ltimos aos, la demanda ha hecho que esto no sea suficiente y sea necesario abordar los tipos de datos ms complejos.

1.2. Modelo de datos Orientado a Objetos

1.2.1. Estructura de los objetos En general, los objetos se corresponden con las entidades en el paradigma E-R (EntidadInterrelacin). El paradigma orientado a objetos est basado en el encapsulamiento de los datos. Por lo general, cada objeto est asociado con: Un conjunto de variables que contiene los datos del objeto (se corresponden con los atributos del modelo E-R) Un conjunto de mensajes a los que responde (cada mensaje puede tener uno o mas parmetros, o no tener ninguno). Un conjunto de mtodos, que contienen el cdigo que implementa cada mensaje (el mtodo devuelve un valor como respuesta al mensaje).

1.2.2. Clases de Objetos En una base de datos hay muchos objetos similares. Por similar se entiende que responden a los mismos mensajes, utilizan los mismos mtodos y tienen atributos del mismo nombre y tipo. Sera un derroche definir por separado cada uno de estos objetos. Por tanto, los objetos parecidos se agrupan para formar una clase. Cada uno de estos objetos se denomina ejemplar o instancia de su clase. Todos los objetos de una clase comparten una definicin y un comportamiento comn, y se diferencian slo en los valores asignados a sus atributos. El concepto de clase del modelo orientado a objetos se corresponde con el concepto de entidad del modelo E-R. Algunos ejemplos de clases en la base de datos bancaria seran empleados, clientes, cuentas y prstamos.

1.2.3. Herencia En ocasiones se necesita trabajar con clases que son similares pero no idnticas. Para ello es muy til una de las caractersticas del paradigma orientado a objetos: la herencia. Una clase puede tener varias subclases que representan ocurrencias ms especficas de la superclase. Aparece por tanto el concepto de jerarqua de clases, que es parecido al de especializacin del modelo entidad-relacin. La herencia propicia as la reutilizacin del cdigo, dado que no hace falta volver a escribir los mensajes, mtodos y funciones para los objetos de las clases derivadas.

-3-

1.2.4. Herencia Mltiple. La herencia mltiple permite a las clases heredar variables y mtodos de mltiples superclases. Cuando se utiliza la herencia mltiple existe una posible ambigedad, ya que se puede heredar la misma variable o el mismo mtodo de ms de una superclase. Existen varias formas de evitar esta ambigedad y las diferentes implementaciones han elegido una de ellas, aunque hay lenguajes que, para evitar este problema no permiten el uso de herencia mltiple, como Java.

1.2.5. Polimorfismo En programacin orientada a objetos se denomina polimorfismo a la capacidad del cdigo de un programa para ser utilizado con diferentes tipos de datos u objetos. Tambin se puede aplicar a la propiedad que poseen algunas operaciones de tener un comportamiento diferente dependiendo del objeto (o tipo de dato) sobre el que se aplican.

1.2.7. Continentes de objetos Se pueden utilizar las referencias entre objetos para modelar diferentes conceptos del mundo real. Uno de estos objetos es el de continentes de objetos, que consiste en crear objetos compuestos o complejos, constituidos por objetos ms simples. Puede haber varios niveles de continentes. Esta situacin crea entre los objetos una jerarqua de continentes.

1.3. Lenguajes de programacin persistente.

Los lenguajes de programacin persistente son lenguajes de programacin extendidos para el tratamiento de datos persistentes. Sin embargo, los lenguajes de programacin persistentes presentan ciertos inconvenientes. Dado que los lenguajes de programacin suelen ser potentes resulta relativamente sencillo cometer errores de programacin que daen las bases de datos. Adems, la complejidad de los lenguajes hace que la optimizacin automtica de alto nivel, como la reduccin de E/S de disco, resulte ms difcil.

1.3.1. Persistencia de los objetos Si se desea transformar uno de estos lenguajes en un lenguaje para la programacin de bases de datos, el primer paso consiste en proporcionar una manera de hacer persistentes a los objetos. Se han propuesto varios enfoques. Persistencia por clases: El enfoque mas sencillo, pero el menos conveniente, consiste en declarar que una clase es persistente. Todos los objetos de la clase son, por tanto, persistentes de manera predeterminada. Todos los objetos de las clases no persistentes son transitorios.

-4-

 Persistencia por creacin: En este enfoque se introduce una sintaxis nueva para crear los objetos persistentes mediante la extensin de la sintaxis para la creacin de los objetos transitorios. Por tanto, los objetos son persistentes o transitorios en funcin de la manera de crearlos. Persistencia por marcas: Una variante del enfoque anterior es marcar los objetos como persistentes despus de haberlos creado. Todos los objetos se crean como transitorios, pero, si un objeto tiene que persistir mas all de la ejecucin del programa, se le marca de manera explcita. A diferencia del enfoque anterior, la decisin sobre la persistencia o la transitoriedad se retrasa hasta despus de la creacin del objeto. Persistencia por alcance: Uno o varios objetos se declaran objetos persistentes (objetos raz) de manera explcita. Todos los dems objetos sern persistentes si (y slo si) son alcanzables desde el objeto raz mediante una secuencia de una o mas referencias.

1.3.2. Identidad de los objetos y punteros a memoria El concepto de la identidad de los objetos tiene una relacin interesante con los punteros de los lenguajes de programacin. Una manera sencilla de conseguir una identidad intrnseca es utilizar los punteros a las ubicaciones fsicas de almacenamiento. En concreto, en muchos lenguajes orientados a objetos como C++, los identificadores de los objetos son en realidad punteros internos de la memoria. Sin embargo, la asociacin de los objetos con ubicaciones fsicas de almacenamiento puede variar con el tiempo. Hay varios grados de permanencia de las identidades: Dentro de los procedimientos: La identidad slo persiste durante la ejecucin de un nico procedimiento. Un ejemplo de la identidad dentro de los procedimientos son las variables locales del interior de los procedimientos. Dentro de los programas: La identidad slo persiste durante la ejecucin de un nico programa o una nica consulta. Un ejemplo de la identidad dentro de los programas son las variables globales de los lenguajes de programacin. Los punteros de la memoria principal o de la memoria virtual slo ofrecen identidad dentro de los programas. Entre programas: La identidad persiste de una ejecucin del programa a otra. Los punteros a los datos del sistema de archivos del disco ofrecen identidad entre los programas, pero pueden cambiar si se modifica la manera en que los datos se guardan en el sistema de archivos. Persistente: La identidad no slo persiste entre las ejecuciones del programa sino tambin entre las reorganizaciones estructurales de los datos. Es la forma persistente de la identidad necesaria para los sistemas orientados a objetos.

-5-

1.3.3. Almacenamiento y acceso a los objetos persistentes Hay varias maneras de hallar los objetos de la base de datos. Uno de los enfoques consiste en dar nombres a los objetos, igual que se hace con los archivos. Este enfoque resulta til con un nmero de objetos relativamente pequeo, pero no resulta prctico para millones de objetos. Un segundo enfoque consiste en exponer los identificadores de los objetos o los punteros persistentes de los objetos, que pueden guardarse de manera externa. A diferencia de los nombres, estos punteros no tienen por qu ser fciles de recordar y pueden ser incluso punteros fsicos dentro de la base de datos. Un tercer enfoque es guardar las colecciones de objetos y permitir que los programas iteren sobre las mismas para hallar los objetos deseados. Las colecciones de objetos pueden a su vez modelarse como objetos de un tipo coleccin. Los tipos de colecciones incluyen los conjuntos, los multiconjuntos, listas, etctera. Un caso especial de coleccin son las extensiones de clases, que son la coleccin de todos los objetos pertenecientes a una clase. La mayor parte de los sistemas de bases de datos orientados a objetos permiten las tres maneras de acceso a los objetos persistentes. Todos los objetos tienen identificadores. Generalmente slo se da nombre a las extensiones de las clases y a otros objetos de tipo coleccin y, quizs, a determinados objetos seleccionados, pero normalmente no se nominan la mayora de los objetos.

1.4. El modelo estndar ODMG (Object Database Management Group)

Un grupo de representantes de la industria de las bases de datos formaron el ODMG con el propsito de definir estndares para los SGBD orientados a objetos. Este grupo propuso un modelo estndar para la semntica de los objetos de una base de datos.

1.4.1. Objetos Los tipos de objetos se descomponen en atmicos, colecciones y tipos estructurados. Los tipos coleccin, que se derivan de la interface Collection, son la propuesta del estndar para las clases contenedor. Los objetos coleccin identificados por el estndar son los siguientes: Set<tipo> : es un grupo desordenado de objetos del mismo tipo. No se permiten duplicados. Bag<tipo> : es un grupo desordenado de objetos del mismo tipo. Se permiten duplicados. List<tipo> : es un grupo ordenado de objetos del mismo tipo. Se permiten duplicados. Array<tipo> : es un grupo ordenado de objetos del mismo tipo que se pueden acceder por su posicin. Su tamao es dinmico y los elementos se pueden insertar y borrar de cualquier posicin. Dictionary<clave,valor> : es como un ndice. Esta formado por claves ordenadas, cada una de ellas emparejada con un solo valor.

-6-

Los tipos estructurados son los siguientes: Date : es una fecha del calendario (da, mes y ao). Time : es una hora (hora, minutos y segundos). Timestamp : es una hora de una fecha (con precisin de microsegundos). Interval : es un perodo de tiempo. Estos tipos tienen la misma definicin que los tipos con el mismo nombre del estndar de SLQ. Los objetos se crean utilizando el mtodo new( ). Adems, todos heredan la interface que se muestra a continuacin: interface Object{ enum void boolean boolean Object void }; Cada objeto tiene un identificador de objeto nico generado por el SGBD, que no cambia y que no se reutiliza cuando el objeto se borra. Cada SGBD genera los identificadores siguiendo sus propios criterios. Lock Type {read, write, upgrade}; lock(in Lock_Type mode) raises(LockNotGranted); try_lock(in Lock_Type mode); same_as(in Object anObject); copy( ); delete( );

1.4.2. Literales Los tipos literales se descomponen en atmicos, colecciones y estructurados. Los literales no tienen identificadores y no pueden aparecer solos como objetos, sino que estn embebidos en objetos y no pueden referenciarse de modo individual. Los literales atmicos son los siguientes: bolean, short, long, flota, double, octet, char, string y enum. Los literales estructurados contienen un nmero fijo de elementos heterogneos. Cada elemento es un par <nombre, valor> donde valor puede ser cualquier tipo literal. Los tipos estructurados son: date, time, timestamp, interval y struct. Y los tipos coleccin son: set<tipo>, bag<tipo>, list<tipo>, array<tipo> y

dictionary<clave,valor>.

1.4.3. Propiedades El modelo de objetos ODMG define dos tipos de propiedades: atributos y relaciones. Un atributo se define del tipo de un objeto. Un atributo no es un objeto de primera clase, por lo tanto no tiene identificador, pero toma como valor un literal o el identificador de un objeto.

-7-

Las relaciones se definen entre tipos. El modelo actual slo soporta relaciones binarias con cardinalidad 1:1, 1:n y n:m. Una relacin no tiene nombre y tampoco es un objeto de primera clase, pero define caminos transversales en la interface de cada direccin. En el lado del muchos de la relacin, los objetos pueden estar desordenados (set o bag) u ordenados (list). La integridad de las relaciones la mantiene automticamente el SGBD y se genera una excepcin cuando se intenta atravesar una relacin en la que uno de los objetos participantes se ha borrado. El modelo aporta operaciones para formar (form) y eliminar (drop) miembros de una relacin.

1.4.4. Lenguaje de definicin de objetos ODL ODL es un lenguaje de especificacin para definir tipos de objetos para sistemas compatibles con ODMG. ODL es el equivalente del DDL (lenguaje de definicin de datos) de los SGBD tradicionales. Define los atributos y las relaciones entre tipos, y especifica la signatura de las operaciones. Ejemplo: class Profesor extends Persona (extent profesores) {/* Definicin de atributos */ attribute string categoria; attribute float salario; attribute string despacho; attributo string telefono; /* Definicin de relaciones */ relationship Departamento trabaja_en inverse Departamento :: tiene_profesores; relationship Set<EstudianteGrad> tutoriza inverse EstudianteGrad :: tutor; relationship Set<EstudianteGrad> en comit; inverse EstudianteGrad :: comite; /* Definicin de operaciones */ void aumentar salario(in float aumento); void promocionar(in string nueva_categoria); }

1.4.5. Lenguaje de consulta de objetos OQL OQL es un lenguaje declarativo del tipo de SQL que permite realizar consultas de modo eficiente sobre bases de datos orientadas a objetos, incluyendo primitivas de alto nivel para conjuntos de objetos y estructuras. OQL no posee primitivas para modificar el estado de los objetos ya que las modificaciones se pueden realizar mediante los mtodos que stos poseen. La sintaxis bsica de OQL es una estructura SELECT...FROM...WHERE..., como en SQL. Por ejemplo, la siguiente expresin obtiene los nombres de los departamentos de la escuela ESI: SELECT d.nombre FROM d in departamentos

-8-

WHERE d.escuela = `ESI'; En las consultas se necesita un punto de entrada, que suele ser el nombre de un objeto persistente. En el ejemplo anterior, el punto de entrada es la extensin departamentos, que es un objeto coleccin de tipo set<Departamento>. Cuando se utiliza una extensin como punto de entrada es necesario utilizar una variable iteradora que vaya tomando valores en los objetos de la coleccin. Para cada objeto de la coleccin (slo la forman objetos persistentes) que cumple la condicin, se muestra el valor del atributo nombre. El resultado es de tipo bag<string. El resultado de una consulta puede ser de cualquier tipo soportado por el modelo. El nombre de cualquier objeto persistente es una consulta de por s. Por ejemplo, la consulta: departamentos; devuelve una referencia a la coleccin de todos los objetos Departamento persistentes. Una expresin de camino empieza normalmente con un nombre de objeto persistente o una variable iterador, seguida de ninguno o varios nombres de relaciones o de atributos conectados mediante un punto. Por ejemplo: departamentoinf.director; // referencia a un objeto Profesor (el director del departamento) departamentoinf.director.categoria; // categora (string) del director del departamento departamentoinf.tiene_profesores; // objeto de tipo set<Profesor>. Esta coleccin contiene referencias a todos los objetos Profesor que se relacionan con el objeto cuyo nombre es departamentoinf.

OQL tiene adems otras carctersticas que no se han comentado: Especificacin de vistas dando nombres a consultas. Obtencin como resultado de un solo elemento (hasta ahora hemos visto que se devuelven colecciones: set, bag, list). Uso de operadores de colecciones: funciones de agregacin (max, min, count, sum, avg) y cuantificadores (for all, exists). Uso de group by.

2. Bases de datos objeto-relacionales

Los sistemas de bases de datos relacionales orientadas a objetos son sistemas basados en el modelo relacional que adems proporcionan las ventajas del paradigma orientado a objeto para tratar los datos. Las principales metas de este nuevo modelo es mejorar la representacin de los datos mediante la orientacin a objetos y simplificar el acceso a datos, manteniendo el sistema relacional.

2.1. Tipos complejos

-9-

El modelo de datos orientado a objetos ha generado la necesidad de nuevas caractersticas como:

La herencia: permite generalizar/ especializar datos a partir de un tipo mas amplio a otros subtipos, es decir, si tenemos un supertipo Persona, podemos mediante la herencia crear nuevos tipos como Alumno y Profesor que hereden de las caractersticas de Persona, pero aadiendo las especficas propias.

Referencia/ Polimorfismo: Podemos referenciar cualquier subtipo a partir de una referencia destinada al supertipo. Desde dicha referencia no se pueden acceder las caractersticas del subtipo referenciado, pero si las del supertipo.

Mtodos: es una lgica que permite tratar y asegurar la integridad de los datos del tipo, estos incluyen un constructor para generar una nueva instancia del tipo.

2.1.1. Tipos colecciones Nota: En este artculo trataremos sobre todo como ejemplo la norma SQL1999. Una coleccin de dato es un atributo multi-valuado en una estructura. Estas pueden ser de 3 tipos:

lista: una simple lista de elementos posiblemente repetidos y con el orden establecido. multi-conjuntos: una lista de elementos posiblemente repetidos y sin orden establecido. conjuntos: una lista de elementos no repetidos y sin orden establecido.

En SQL 1999 solo la lista es soportada, los dems tipos de colecciones podran aparecer en nuevas versiones de la norma. La forma de especificar un array en SQL1999 es el siguiente: <nombre> <tipo> array[<tamao>] ejemplo: autores varchar(50) array[10] Segn los bocetos de SQL, podramos crear conjuntos mediante: <nombre> setof(<tipo>) ejemplo: autores setof( varchar(50)) La principal diferencia entre esta forma de guardar datos multi-valuados y la de las tpicas bases de datos relacionales es que en una relacional habra que generar una tabla aparte con clave externa para guardar la lista, lo que representa una complejidad extra para acceder/ modificar/ crear los datos adems de dificultar la tarea de mantener la integridad de los datos. De esta forma, con las colecciones, mantenemos una relacin uno a uno entre el modelo de realidad que deseamos representar y la tupla que almacena el dato.

- 10 -

2.1.2. Tipos Estructurados en SQL1999 o definicin de objetos La definicin de un objeto consta de los siguientes elementos:

Lista de atributos, son los datos del objetos, sus caractersticas Lista de mtodos: son las operaciones realizables sobre ese objetos, incluido su creacin.

En SQL1999, los tipos estructurados se definen mediante create type , veamos un ejemplo: create type Persona as ( DNI varchar(9), Nombre varchar(50), Apellidos varchar(100)) method Persona(DNI as varchar(9)); Por supuesto los atributos pueden ser colecciones de las que hemos hablado anteriormente. Para crear una tabla de tipo Persona, podemos simplemente hacerlo de la siguiente forma: create table Usuarios of type Persona;

El cuerpo de los mtodos de los tipos estructurados se define separadamente, y puede constar una lgica imperativa definida en SQL o hacer uso de otros lenguajes externos para implementar su funcionalidad, tema que trataremos mas adelante.

En SQL 1999 podemos crear un cuerpo de mtodo de la siguiente forma: create method Persona( DNI as varchar(9)) for Persona begin set self.DNI = DNI end Este ejemplo introduce varios conceptos nuevos: Primero la palabra clave self, equivalente al conocido this de C++ o Java, que sirve para hacer referencia a la tupla sobre la que estamos trabajando. Por otro lado, el cuerpo begin-end, que como veremos mas adelante, es una instruccin compuesta. 2.1.3. Instanciacin de tipos complejos Para generar un nuevo valor de un tipo complejo, usamos su constructor, como es de esperar en un modelo orientado a objetos. El constructor es un mtodo tpico del tipo con la peculiaridad que tiene el mismo nombre que el tipo. Su propsito suele ser el de inicializar los valores iniciales del objeto.

- 11 -

Al definir cualquier tipo, se genera por defecto un constructor que inicializa sus propiedades a sus valores por defecto, pero podemos sobrescribir dicho mtodo para definir el constructor que queramos. Adems, podemos definir tantos constructores como sea necesario, con la restriccin de que deben tener tipos de argumentos o nmero de argumentos distintos. Una de las grandes diferencias entre las bases de datos orientadas a objetos de las relacionales orientadas a objetos, es que el constructor no genera un objeto propiamente dicho, es decir, el constructor no crea una tupla, sino que genera un valor del tipo en cuestin que hay que insertar posteriormente en la tabla.

Finalmente es necesario una forma para asignar un valor a colecciones, y para eso se hace uso de array: ejemplo: insert into Libro values ( titulo, array[autor1, autor2])

Notese el uso de array.

2.2. Herencia
La herencia es una herramienta muy potente para estructurar datos relacionados mediante generalizacin y para evitar repetir cdigo y datos. En SQL 1999 hay 2 tipos de herencia:

A nivel de tipo A nivel de tabla

2.2.1. Herencia de tipo Para especificar una herencia a nivel de tipo, se usa la palabra clave under en la definicin del tipo derivado. Ejemplo: create type Persona.... create type Estudiante under Persona ... Los mtodos tambin se heredan, pero se pueden sobreescribir mediante overriding method en vez de method.

- 12 -

En SQL 1999, la herencia mltiple no es soportada, por lo que estructuras que contengan herencia mltiple se deben subdividir en varios subtipos o usar otras tcnicas como veremos a continuacin.

2.2.2. Herencia de tablas La herencia de tablas en SQL1999 corresponde con el concepto de generalizacin del modelo E/R. Requerimientos de consistencia en SQL1999: Para que se considere que hay consistencia, en una herencia por tablas, se deben cumplir las siguientes restricciones:

Cada tupla de la supertabla puede corresponder a lo sumo a una tupla de cada una de sus tablas inmediatas

Una tupla de una subtabla no puede corresponder a la misma tupla de la supertabla que otra tupla de otra subtabla.

Las subtablas pueden implementarse de 2 formas distintas, cada una con sus ventajas y desventajas:

Cada subtabla almacena la clave primaria de la tupla padre y los atributos derivados, de esta forma, para acceder a los datos de un objeto, se debe consultar la subclase y la clase padre correspondiente.

Cada subtabla almacena todos sus atributos heredados y definidos localmente. Cuando se inserta una tupla se almacena solo en la tabla a la que pertenece y su presencia se infiere a las supertablas.

2.2.3. Solapamiento de subtablas Cuando una entidad puede pertenecer a varios subtipos, si se realiza la herencia por tipos habra que generar un subtipo por cada combinacin posible. Este problema se puede solucionar con herencia por tablas, de esta forma, se guarda la tupla en la super tabla y se generan tantas tuplas relacionadas en las subtablas como a subtipos pertenezca. Esta solucin no cumple la segunda restriccin de consistencia, por lo que debe usarse con sumo cuidado para no generar datos repetidos o inconsistencias.

2.3. Tipos de referencia

La referencia como ya hemos explicado permite guardar como atributo una referencia a otro objeto. La forma de definir una referencia en SQL1999 es la siguiente

- 13 -

<nombre> ref(<tabla>) scope <tipo> Ejemplo: director ref( Persona ) scope Persona Para inicializar un atributo de tipo referencia es necesario obtener el identificador de la tupla a la que se va a referenciar o bien guardar NULL Ejemplo: insert into Departamento values ( 'Informtica', null) update Departamente set director = (select 'Juan' ) where nombre = 'Informatica' El atributo de referencia se llama autoreferencial y puede generarse automaticamente o bien ser especificado manualmente por el usuario. Ejemplo de automtico create table persona of Persona ref is nombre_referencia system generated ref(p) from Persona as p where nombre =

Ejemplo de especificado por el usuario create table persona of Persona ref is nombre_referencia user generated

Como se puede apreciar, la diferencia esta en usar system o user a la hora de especificar la referencia. Tambin se puede usar un atributo ya definido en el tipo como referencia: create type Persona( DNI varchar(9)) ref from DNI create table persona of Persona ref is nombre_referencia derived

2.4. Consultas con tipos complejos

Debido a la naturaleza de la estructura basada en tipos y colecciones, es necesario el uso de nuevas expresiones para adquirir informacin de la base de datos.

- 14 -

Acceso a la informacin apuntada por referencias: Para este propsito se define la expresin ruta -> que permite acceder al elemento referenciado. Ejemplo: Select director->nombre, director->DNI from departamento Suponiendo que director sea una referencia a un objeto de tipo Persona, esta consulta devuelve el nombre y el dni de dicha persona referenciada.

Atributos de tipo coleccin: Para acceder la informacin de colecciones, se debe poder desanidar la informacin y realizar bsquedas dentro de dichas listas. Para desanidar una coleccin se define la palabra clave unnest , por ejemplo la siguiente sentencia busca los libros que tengan el autor dado en su array de autores. Select titulo from libros where Cervantes in (unnest(autores)) Cuando se trata de un array, se puede acceder una posicin dada de la lista de la siguiente forma: Autores[<index>] Otra forma de acceder los distintos elementos de una coleccin es usando un select interno, el cual complica bastante la sentencia pero tiene la ventaja de permitir el uso de Order By: Select titulo,

( Select autor from libros as M where M.titulo = O.titulo ) as lista_autores, from libros as O

2.5. Funciones y procedimientos

SQL1999 permite la definicin de funciones y procedimientos mediante el lenguaje SQL o mediante lenguajes externos. Hay que indicar tambin que algunos sistemas gestores de bases de datos proporcionan lenguajes propios como TransactSQL en SQL server de Microsoft o PL/SQL en Oracle, de los que no hablaremos aqu.

Un mtodo o procedimiento consta de una declaracin del mtodo y un cuerpo encerrado entre begin y end. Ejemplo de mtodo: create function Recuento( titulo varchar(50)) return integer

- 15 -

begin declare recuento-a integer; set recuento-a = 5; return recuento-a; end Ejemplo de procedimiento: create procedure Recuento( titulo varchar(50)) begin declare recuento-a integer; set recuento-a = 5; end

Algunas capacidades del lenguaje: Declarar variables, de mbito local dentro del bloque begin-end: declare <nombre> <tipo>; Llamar mtodos y procedimientos: call <mtodo>(<lista_argumentos>);

Estructuras de control: while n < 10 do set n = n +1; end while for r as select principito do set n = n+1; end for if r.saldo < 1000 then set p = p + r.saldo; elseif r.saldo < 5000 then autor from libro where titulo = El

set m = m + r.saldo; else set g = g + r.saldo; end if Etc.

- 16 -

Como se ha indicado, se puede implementar la funcionalidad de mtodos en otros lenguajes, permitiendo as un mayor control o eficiencia de operaciones. Sin embargo, para hay que tener en cuanta varios factores para no deteriorar los datos en casos de errores, los cuales no indicaremos aqu. Ejemplo: create procedure Recuento ( in titulo varchar(50), out

recuento integer) language C external name /usr/avi/proc_recuento

3. Comparacin entre los Modelos.

Para terminar vamos a comparar los dos tipos de Base de Datos de los cuales hemos estado hablando: las Bases de Datos Orientadas Objetos (Programacin Persistente) y las Bases de Datos Objeto-Relacionales (Sistemas Relacionales Orientadas a Objetos). Ambos modelos persiguen facilitar el almacenamiento de objetos en la base de datos, pero presentan algunas diferencias.

Las base de datos orientados a objetos obtienen un mejor rendimiento cuando se usan objetos, ya que estos objetos se almacenan en disco de forma tranparente para el lenguaje de programacin (lenguaje orientado a objetos), ya que no se utiliza ningn tipo de lenguaje para trabajar con los datos como puede ser SQL, por tanto no es necesario hacer tipos de conversiones entre datos como ocurre con las base de datos objeto-relacionales esto puede provocar errores ya que es el programador el encargado de realizar esas conversiones y un aumento en el nmero de lneas de cdigo para la conversin de los tipos de datos as como la carga o descarga de objetos en la base de datos, as como el cdigo propio para realizar consultas o modificaciones en la base de datos. Por todo ello hace que este tipo de base de datos sean ms fcil de desarrollar y mantener lo que implica un coste menor. En cambio al no tener ningn lenguaje para trabajar con los datos (transparente) sino que es el propio lenguaje de programacin quien trabaja con ellos pueden ocurrir, que debido a la gran potencia del lenguaje permita realizar acciones que daen la base de datos, problema que no ocurre con las bases de datos

Por otro lado las bases de dato objeto relacionales siguen utilizando lenguaje de tratamiento de datos para trabajar con los objetos para ello lo han hecho extendindolo por lo tanto tienen la mismas caractersticas que el modelo relacional como es una gran proteccin.

- 17 -

Otra ventaja de este modelo es que permite realizar consultas ad-hoc este tipo de consultas son unas de las causas por la que las bases de datos relacionales se extendieron tan rpidamente y permiten realizar consultas por el usuario sin que estuvieran planificadas cuando se diseo la aplicacin. Presentan un menor rendimiento y por tanto un mayor coste de desarrollo y mantenimiento pero debido a su gran implantacin de las bases de datos relacionales ha sido ms fcil extender el modelo que disear de nuevo los sistemas para cambiar a bases de datos orientados a objetos.

4. Bibliografa
Tecnologa y Diseo de Bases de Datos, PIATTINI VELTHUIS, MARIO G / MARCOS MARTINEZ, ESPERANZA / CALERO MUOZ, CORAL / VELA SNCHEZ, BELN Fundamentos de Sistemas de Bases de Datos, Elmasri, Ramez ; Navathe, Shamkant (Pearson Addison-Wesley) Fundamentos De Bases De Datos, 5 Edc., Sudarshan S.; Korth Henry; Silberschatz Abraham (McGRAW-HILL/INTERAMERICANA DE ESPAA, S.A.U.) http://www.mitecnologico.com/ http://www.softwarelibre.net/ http://informatica.uv.es/iiguia/DBD/Practicas/boletin_1.pdf

- 18 -