Tema 8. Bases de datos orientadas a objetos.

Juan Ignacio Rodrguez de Leon

Resumen El paradigma de la programacion orientada a objetos. Necesidad de tipos complejos de datos. El modelo de datos orientado a objetos. Lenguajes orientados a objetos. Lenguajes de programacion persis tentes. Sistemas C++ persistentes, sistemas Java persistentes

Indice
1. Orientacion a objetos 1.1. Los objetos . . . . . . . . . 1.2. Clases de objetos . . . . . 1.3. polimorsmo . . . . . . . 1.4. sobrecarga de operadores 1.5. Herencia . . . . . . . . . . 1.6. Herencia multiple . . . . . 1.7. Identidad de los objetos . 1.8. Continentes de objetos . . 2. Lenguajes orientados a objetos 3. Lenguajes de programacion persistentes 3.1. Persistencia de los objetos . . . . . . . . . . . . . . . . . . . . 3.2. Identidad de los objetos y punteros a memoria . . . . . . . . 3.3. Almacenamiento y acceso a los objetos persistentes . . . . . 4. Bases de datos relacionales orientadas a objetos 4.1. Relaciones anidadas . . . . . . . . . . . . . 4.2. Tipos de datos complejos . . . . . . . . . . . 4.2.1. Colecciones . . . . . . . . . . . . . . 4.2.2. Objetos de gran tamano (LOB) . . . 4.2.3. Tipos estructurados . . . . . . . . . . 4.2.4. Constructores . . . . . . . . . . . . . 4.3. Herencia . . . . . . . . . . . . . . . . . . . . 4.3.1. Herencia de tipos . . . . . . . . . . . 4.3.2. Herencia de tablas . . . . . . . . . . 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 4 6 6 6 7 8 9 9 10 11 12 13 13 13 14 14 14 14 14 15 15 15

 INDICE 4.4. Referencias . . . . . . . . . . . . . . . . . . . 4.5. Consultas con tipos complejos . . . . . . . . 4.5.1. Acceso a datos estructurados . . . . 4.5.2. Expresiones de ruta . . . . . . . . . . 4.5.3. Atributos de tipo coleccion . . . . . 4.6. Funciones y procedimientos . . . . . . . . . 4.6.1. Funciones y procedimientos en SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 15 16 16 16 16 17 17

ORIENTACION A OBJETOS

1.

Orientacion a objetos

Los conceptos de la programacion orientada a objetos tienen origen en Simula 67, un lenguaje disenado para hacer simulaciones, creado por Ole Johan Dahl y Kristen Nygaard del Centro de Computo Noruego en Oslo. Fueron renados m s tarde en Smalltalk, que fue desarrollado en Simula en a el Xerox PARC, pero disenado para ser un sistema completamente din mico a en el cual los objetos se podran crear y modicar en marcha en lugar de tener un sistema basado en programas est ticos. a La programacion orientada a objetos introduce nuevos conceptos, que a veces no son m s que nombres nuevos aplicados a conceptos antiguos, ya a conocidos. Entre ellos destacan los siguientes: Objetos entidades complejas provistas de datos (propiedades, atributos) y comportamiento (funcionalidad, programas, m todos). Correspone den a los objetos reales del mundo que nos rodea. Clases conjuntos de objetos que comparten propiedades y comportamiento. M todo es un codigo ejecutable asociado a un objeto (o a una clase de e objetos), cuya ejecucion se desencadena mediante un mensaje. Mensaje una comunicacion dirigida a un objeto, que le ordena que ejecute uno de sus m todos con ciertos par metros. e a Propiedad, atributo o variable datos asociados a un objeto o a una clase de objetos. Herencia las clases no est n aisladas, sino que se relacionan entre s, fora mando una jerarqua de clasicacion. Los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen. Encapsulamiento cada objeto est aislado del exterior, es un modulo nata ural, y la aplicacion entera se reduce a una agregacion de objetos. El aislamiento protege a los datos asociados a un objeto de su modicacion por quien no tenga derecho a acceder a ellos, eliminando efectos secundarios e interacciones. Polimorsmo m todos diferentes, asociados a objetos distintos, pueden e compartir el mismo nombre, aunque el comportamiento del m todo e vare segun el objeto al que se aplica.

1.1.

Los objetos

Hablando en general, los objetos se corresponden con las entidades del modelo E-R. El paradigma orientado a objetos est basado en el encapsua

ORIENTACION A OBJETOS

lamiento de los datos y del codigo relacionados con cada objeto en una sola unidad cuyo contenido no es visible desde el exterior. Conceptualmente, todas las interacciones entre cada objeto y el resto del sistema se realizan mediante mensajes. Por tanto, la interfaz entre cada objeto y el resto del sistema se dene mediante un conjunto de mensajes permitidos. En general, cada objeto est asociado con: a Un conjunto de variables o atributos que contiene los datos del objeto; las variables se corresponden con los atributos del modelo E-R. Un conjunto de mensajes a los que responde; cada mensaje puede no tener par metros, tener uno o varios. a Un conjunto de m todos, cada uno de los cuales es codigo que ime plementa un mensaje; el m todo devuelve un valor como respuesta e al mensaje. El t rmino mensaje en un entorno orientado a objetos no implica el e uso de mensajes fsicos; por el contrario, hace referencia al intercambio de solicitudes entre los objetos, independientemente de los detalles concretos de su implementacion. Se utiliza a veces la expresion invocar a un mtodo e para denotar el hecho de enviar un mensaje a un objeto y la ejecucion del m todo correspondiente. e La principal razon de diferenciar las dos acciones es obtener la capacidad de modicar la denicion de un objeto, sin afectar al resto del sistema. Esta es una de las mayores ventajas de la programacion orientada a objetos Los atributos derivados de las entidades del modelo E-R pueden expresarse en el modelo orientado a objetos como mensajes solo de lectura. Por ejemplo, el atributo derivado antiguedad de una entidad empleado puede expresarse como el mensaje antiguedad de un objeto empleado. El m todo e que implemente los mensajes, puede determinar la antiguedad restando la fecha-alta del empleado de la fecha actual.

1.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 m todos e y tienen atributos del mismo nombre y tipo. Sera un derroche denir 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 denicion y un com portamiento comun, y se diferencian solo en los valores asignados a sus atributos.

ORIENTACION A OBJETOS

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 pr stamos. e El siguiente listado dene una clase Empleado, en pseudo-codigo. clase Empleado: string nombre string apellidos string direccin o date fecha-alta int sueldo def sueldo-anual(self): return self.sueldo * 14 def nombre-completo(self): return self.nombre + + self.apellidos def antigedad(self): u return hoy() - self.fecha_alta def set-direccin(self, newdir): o self.direccin = newdir o La representacion en UML de esta clase sera as: Empleado string nombre string apellidos string direccion date fecha-alta int sueldo int sueldo-anual() string nombre-completo() date antiguedad() set-direccion(string) La denicion muestra las variables y los mensajes a los que respon den los objetos de la clase. Cada objeto de la clase empleado contiene los Atributos nombre, apellidos y direccion, todas cadenas de caracteres; fechaalta, que es una fecha, y sueldo, que es un entero. Se dene tras mensajes: sueldo-anual, nombre-completo y antiguedad. Obs rvese que el mensaje e set-direccion utiliza un par metro que especica el nuevo valor de direca cion.

ORIENTACION A OBJETOS

1.3.

polimorsmo

En programacion orientada a objetos se denomina polimorsmo a la ca pacidad del codigo de un programa para ser utilizado con diferentes tipos de datos u objetos. Tambi n se puede aplicar a la propiedad que poseen e algunas operaciones de tener un comportamiento diferente dependiendo del objeto (o tipo de dato) sobre el que se aplican.

1.4.

sobrecarga de operadores

Algunos lenguajes de programacion permiten un tipo especial de m toe dos que permiten la sobrecarga de operadores. Estos m todos otorgan la e capacidad de transformar los operadores de un lenguaje como por ejemplo los operadores +, -, *, /, etc de forma que se redenen para poder ser utilizados con los objetos de nuestra clase. Mediante esta t cnica podemos sumar dos objetos creados por nosotros, e o un objeto y un entero, en vez de limitarnos a sumar numeros enteros o reales. Por ejemplo, si deni ramos una clase complex para trabajar con numeros e complejos en un lenguaje que no soporta sobrecarga de operadores, tendramos que implementar un m todo suma, y el codigo que implementa la e suma quedara as: a = complex(1, 3.4) b = complex(-2, 0.54) a.suma(b) Sin embargo, en un lenguaje con sobrecarga de operadores, redeniramos el operador + para nuestra clase de complejos, y el codigo nal quedara: a = complex(1, 3.4) b = complex(-2, 0.54) a = a + b

1.5.

Herencia

Los esquemas de las bases de datos orientadas a objetos suelen necesitar gran numero de clases. Frecuentemente, sin embargo, varias de las clases son parecidas entre s. Son parecidas porque denen iguales atributos y m todos. No son id nticas porque cada clase dene, adem s, atributos y/o e e a m todos que no comparte con las dem s. e a Sera conveniente denir una representacion de los atributos y m todos e comunes en un solo lugar. Esto puede hacerse creando una nueva clase, que contendr solo las caractersticas comunes, y redeniendo las clases a originales como especializaciones de la nueva clase.

ORIENTACION A OBJETOS

Las clases especializadas adquieren una dependencia de herencia con respecto a la clase general, ya que heredan los atributos y m todos denidos e en esta. Aparece por tanto el concepto de jerarqua de clases, que es parecido al de especializacion del modelo entidad-relacion. Las relaciones entre una clase m s especica, o clase derivada, con respeca ta a su clase gen rica o superclase, siempre son de especializacion, es decir , e 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 sustitucion: cualquier m todo de e 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 tambi n las denen e implcitamente, por la herencia. La herencia propicia as la reutilizacion del codigo, dado que no hace falta volver a escribir los mensajes, m todos y funciones para los objetos de e las clases derivadas.

1.6.

Herencia multiple

En la mayor parte de los casos una organizacion de clases con estructura de arbol resulta adecuada para describir las aplicaciones; en la organizacion con estructura de arbol, cada clase puede tener a lo sumo una superclase. Sin embargo, hay situaciones que no pueden representarse bien en una jerarqua de clases con estructura de arbol. La herencia multiple permite a las clases heredar variables y m todos e de multiples superclases. La relacion entre clases y subclases se representa mediante un grafo acclico dirigido en vez de un arbol. Cuando se utiliza la herencia multiple existe una posible ambiguedad, ya que se puede heredar la misma variable o el mismo m todo de m s de e a una superclase. Por ejemplo, la clase estudiante puede tener un variable dept que identica el departamento del estudiante y la clase profesor puede tener an logamente una variable dept que identica el departamento de a profesor. La clase ayudante-profesor heredara ambas deniciones. Existen varias formas de evitar esta ambiguedad: Incluir las dos variables, d ndoles nombres diferentes para distinguira las Escoger solo una, segun el orden en que se declararon las clases.

ORIENTACION A OBJETOS

Obligar al usuario a seleccionar de manera explcita una de las op ciones Considerar esta situacion como un error. Diferentes implementaciones han elegido cada una de estas opciones. Una solucion aun m s dr stica es impedir la herencia multiple, como en a a Java.

1.7.

Identidad de los objetos

Los objetos de las bases de datos orientadas a objetos suelen corresponder a entidades del sistema modelado por la base de datos. Las entidades conservan su identidad aunque algunas de sus propiedades cambien con el tiempo. De manera parecida, los objetos deben conservar su identidad aunque los valores de las variables o las deniciones de los m todos came bien total o parcialmente con el tiempo. Este concepto de identidad no se aplica a las tuplas de las bases de datos relacionales. En los sistemas relacionales las tuplas de una relacion solo se distinguen por los valores que contienen. La identidad de los objetos es un concepto de identidad m s potente a que el que suele hallarse en los lenguajes de programacion o en los modelos de datos no orientados a objetos. A continuacion se ilustran varios ejemplos de identidad. Valor Se utiliza un valor de datos como identidad. Esta forma de identidad se utiliza en los sistemas relacionales. Nombre Se utiliza como identidad un nombre proporcionado por el usuario. Esta forma de identidad suele utilizarse para los archivos en los sistemas de archivos. Incorporada Se incluye el concepto de identidad en el modelo de datos o en el lenguaje de programacion y no hace falta que el usuario pro porcione ningun identicador. Esta forma de identidad se utiliza en los sistemas orientados a objetos. Cada objeto recibe del sistema de manera autom tica un identicador en el momento en que se crea. a Los identicadores de los objetos son unicos; es decir, cada objeto tiene un solo identicador y no hay dos objetos que tengan el mismo identicador. Los identicadores de los objetos no tienen por qu estar en una forma con e la que los seres humanos se encuentren comodos; pueden ser numeros grandes, por ejemplo. La posibilidad de guardar el identicador de un objeto como un campo de otro objeto es m s importante que tener un a nombre que resulte f cil de recordar. Utilizar un identicador de un objeto a como atributo de otro se denomina referenciar un objeto.

LENGUAJES ORIENTADOS A OBJETOS

1.8.

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 m s simples. a Puede haber varios niveles de continentes. Esta situacion crea entre los objetos una jerarqua de continentes. Los enlaces entre las clases deben interpretarse en esta estructura como es parte de en lugar de la interpretacion es una especializacion de de los enlaces de una jerarqua de herencias. En ciertas aplicaciones un objeto puede estar incluido en varios objetos. En esos casos la relacion de continentes se representa mediante un grafo.

2.

Lenguajes orientados a objetos

Hasta el momento se han explicado los conceptos b sicos de la prograa macion orientada a objetos en un nivel abstracto. Para poder utilizarlos en la pr ctica en un sistema de bases de datos hay que concretarlos en algun a lenguaje. Esto puede realizarse de dos maneras: 1. Los conceptos de la programacion orientada a objetos se utilizan unicamente como herramientas de diseno y se codican, por ejem plo, en una base de datos relacional. Se sigue este enfoque cuando se utilizan los diagramas entidad-relacion para modelar los datos y luego se convierten de manera manual en un conjunto de relaciones. 2. Los conceptos de la programacion orientada a objetos se incorporan en un lenguaje que se utiliza para trabajar con la base de datos. Con este enfoque hay varios lenguajes posibles en los que se pueden integrar los conceptos: Una opcion es extender un lenguaje para el tratamiento de datos, como SQL, anadiendo tipos complejos y las dem s caracterstia cas de la programacion orientada a objetos. Los sistemas que proporcionan extensiones orientadas a objetos a los sistemas relacionales se denominan sistemas relacionales orientados a objetos. Otra opcion es tomar un lenguaje de programacion orientado a objetos y extenderlo para que trabaje con las bases de datos. Estos lenguajes se denominan lenguajes de programaci n persistente. o Estudiaremos estas dos opciones en el resto de este tema.

LENGUAJES DE PROGRAMACION PERSISTENTES

10

3.

Lenguajes de programacion persistentes

Los lenguajes de las bases de datos trabajan directamente con datos que son persistentes, es decir, los datos siguen existiendo una vez que el programa que los creo ha concluido. Las relaciones de las bases de datos y las tuplas de las relaciones son ejemplos de datos persistentes. Por el contrario, los unicos datos persistentes con los que los lenguajes de programacion tradicionales trabajan directamente son los archivos. La manera tradicional de realizar las interfaces de las bases de datos con los lenguajes de programacion tradicionales consiste en incorporar o embeber el codigo SQL dentro del lenguaje de programacion. Los lenguajes de programacion persistente son lenguajes de progra macion extendidos para el tratamiento de datos persistentes. Los lenguajes de programacion persistente pueden distinguirse de los lenguajes con SQL embebido de al menos dos maneras: 1. En los lenguajes incorporados el sistema de tipos del lenguaje antrion suele ser diferente del sistema de tipos del lenguaje para el tratamiento de los datos. Los programadores son responsables de las conversiones de tipos entre el lenguaje antrion y SQL. Exigir que los programadores ejecuten esta tarea presenta varios inconvenientes: a) El codigo para la conversion entre objetos y tuplas opera fuera del sistema de tipos orientado a objetos y, por tanto, tiene m s a posibilidades de presentar errores no detectados. b) La conversion entre el formato orientado a objetos y el forma to relacional de las tuplas necesita gran cantidad de codigo. El codigo de conversion, junto con el codigo para cargar y descar gar los datos de la base de datos puede suponer un porcentaje signicativo del total necesario para la aplicacion Por el contrario, en los lenguajes de programacion persistente, el lenguaje de consulta se halla totalmente integrado con el lenguaje antrion y ambos comparten el mismo sistema de tipos. Los objetos se pueden crear y guardar en la base de datos sin ningun tipo explcito ni cambios de formato; los cambios necesarios se realizan de manera transparente. 2. Los programadores que utilizan lenguajes de consulta incorporados son responsables de la escritura de codigo explcito para la busqueda de los datos de la base de datos en la memoria. Si se realizan actualizaciones, los programadores deben escribir codigo de manera explcita para volver a guardar los datos actualizados en la base de datos. Por el contrario, en los lenguajes de programacion persistentes los programadores pueden trabajar con datos persistentes sin tener que

LENGUAJES DE PROGRAMACION PERSISTENTES

11

escribir de manera explcita codigo para buscarlos en la memoria o para volver a guardarlos en el disco. Se han propuesto versiones persistentes de los lenguajes de programacion como Pascal. En los ultimos anos han recibido mucha atencion las versiones persistentes de los lenguajes orientados a objetos como C++, Java y Smalltalk. Sin embargo, los lenguajes de programacion persistentes presentan cier tos inconvenientes. Dado que los lenguajes de programacion suelen ser po tentes resulta relativamente sencillo cometer errores de programacion que danen las bases de datos. Adem s, la complejidad de los lenguajes hace que a la optimizacion autom tica de alto nivel, como la reduccion de E/S de disco, a resulte m s difcil. a A continuacion se describen varios aspectos que cualquier lenguaje de programacion persistente debe abordar.

3.1.

Persistencia de los objetos

En los lenguajes de programacion orientados a objetos estos son transi torios, desaparecen cuando se termina el programa, Si se desea transformar uno de estos lenguajes en un lenguaje para la programacion 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 m s sencillo, pero el menos conveniente, a 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. Este enfoque no es exible, porque no permite disponer en una misma clase tanto de objetos transitorios como de objetos persistentes. En muchos sistemas de bases de datos orientados a objetos, la declaracion de que una clase es persistente se debe interpretar mejor como que pueden ser persistentes. Persistencia por creacion En este enfoque se introduce una sintaxis nueva para crear los objetos persistentes mediante la extension de la sintaxis para la creacion de los objetos transitorios. Por tanto, los objetos son persistentes o transitorios en funcion de la manera de crearlos. Este enfoque se sigue en varios sistemas de bases de datos orientados a objetos. Persistencia por marcas Una variante del enfoque anterior es marcar los objetos como persistentes despu s de haberlos creado. Todos los obe jetos se crean como transitorios, pero, si un objeto tiene que persistir m s all de la ejecucion del programa, se le marca de manera explcita. a a

LENGUAJES DE PROGRAMACION PERSISTENTES

12

A diferencia del enfoque anterior, la decision sobre la persistencia o la transitoriedad se retrasa hasta despu s de la creacion del objeto. e Persistencia por alcance Uno o varios objetos se declaran objetos persistentes (objetos raz) de manera explcita. Todos los dem s objetos a ser n persistentes si (y solo si) son alcanzables desde el objeto raz a mediante una secuencia de una o m s referencias. a Este esquema tiene la ventaja de que resulta sencillo hacer que sean persistentes estructuras de datos completas con solo declarar como persistente la raz de las mismas. Sin embargo, el sistema de bases de datos sufre la carga de tener que seguir las cadenas de referencias para detectar los objetos que son persistentes, lo que puede resultar costoso.

3.2.

Identidad de los objetos y punteros a memoria

El concepto de la identidad de los objetos tiene una relacion interesante con los punteros de los lenguajes de programacion. 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 identicadores de los objetos son en realidad punteros internos de la memoria. Sin embargo, la asociacion de los objetos con ubicaciones fsicas de alma cenamiento puede variar con el tiempo. Hay varios grados de permanencia de las identidades: Dentro de los procedimientos La identidad solo persiste durante la ejecu cion de un unico 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 solo persiste durante la ejecucion de un unico programa o una unica consulta. Un ejemplo de la identi dad dentro de los programas son las variables globales de los lenguajes de programacion. Los punteros de la memoria principal o de la memoria virtual solo ofrecen identidad dentro de los programas. Entre programas La identidad persiste de una ejecucion 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 modica la manera en que los datos se guardan en el sistema de archivos. Persistente La identidad no solo persiste entre las ejecuciones del programa sino tambi n entre las reorganizaciones estructurales de los datos. e Es la forma persistente de la identidad necesaria para los sistemas orientados a objetos.

BASES DE DATOS RELACIONALES ORIENTADAS A OBJETOS

13

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 util con un numero de objetos relativamente pequeno, pero no resulta pr ctico para millones de objetos. a Un segundo enfoque consiste en exponer los identicadores 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 f ciles de recordar y pueden ser incluso punteros fsicos dentro de e a 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 coleccion. Los tipos de colecciones incluyen los conjuntos, los multiconjun tos, listas, etc tera. Un caso especial de coleccion son las extensiones de e clases, que son la coleccion de todos los objetos pertenecientes a una clase. Si hay una extension de clase, siempre que se cree un objeto de la clase, el mismo se inserta en la extension de clase de manera autom tica, y siempre a que se borre un objeto, este se eliminar de la extension de clase. a 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 identicadores. Generalmente solo se da nombre a las extensiones de las clases y a otros objetos de tipo coleccion y, quiz s, a a determinados objetos seleccionados, pero normalmente no se nominan la mayora de los objetos.

4.

Bases de datos relacionales orientadas a objetos

Los modelos de datos relacionales orientados a objetos extienden el modelo de datos relacional proporcionando un sistema de tipos m s ricos a y complejos y anadiendo la programacion orientada a objetos. Los lenguajes de consulta relacionales como SQL tambi n necesitan ser e extendidos para trabajar con el sistema de tipos enriquecido.

4.1.

Relaciones anidadas

El modelo relacional anidado es una extension del modelo relacional en la que los dominios pueden ser atomicos o de relacion. Por tanto, el valor de las tuplas de los atributos puede ser una relacion, y las relaciones pueden guardarse en otras relaciones. Los objetos complejos, por tanto, pueden representarse mediante una unica tupla de las relaciones anidadas.

BASES DE DATOS RELACIONALES ORIENTADAS A OBJETOS

14

4.2.
4.2.1.

Tipos de datos complejos

Colecciones

Los conjuntos son ejemplares de los tipos coleccion. Otros ejemplares son los arrays y los multiconjuntos (es decir, colecciones sin orden donde un elemento puede aparecer varias veces). Las siguientes deniciones de atributos ilustran la declaracion 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 especicando el ndice del array, por ejemplo, array-autores[1]. 4.2.2. Objetos de gran tamano (LOB)

Muchas aplicaciones actuales de bases de datos necesitan almacenar atributos grandes (del orden de varios Kbytes), tales como la fotografa de una persona, o muy grandes (del orden de varios Mbytes o incluso Gbytes), tales como im genes m dicas de alta resolucion o clips de vdeo. SQL:1999 a e proporciona por tanto nuevos tipos de datos para objetos de gran tamano para datos de caracteres (clob) y binarios (blob). Las letras lob en estos tipos de datos son acronimos de Large OBject (objeto grande). Los objetos grandes se usan normalmente en aplicaciones externas, y tiene poco sentido extraerlos completamente en SQL. En su lugar, una aplicacion conseguira un localizador de un objeto grande y lo usara para manipularlo desde el lenguaje antrion. 4.2.3. Tipos estructurados

Los tipos estructurados permiten la representacion directa de atributos compuestos de los diagramas E-R. Un tipo estructurado puede tener m todos denidos sobre el. Los m toe e dos se declaran como parte de la denicion de tipos de un tipo estructurado. 4.2.4. Constructores

Hay que denir funciones constructoras para crear valores de tipos estructurados. En SQL-1999 y en muchos otros lenguajes se utiliza una funcion con el mismo nombre que un tipo estructurado como funcion constructora. De manera predeterminada, cada tipo estructurado tiene un constructor sin argumentos, que establece los atributos a sus valores predenidos. Cualquiera otra funcion constructora tiene que crearse explcitamente. Puede haber m s de una constructora para el mismo tipo estructurado; a

BASES DE DATOS RELACIONALES ORIENTADAS A OBJETOS

15

aunque tengan el mismo nombre, solo tienen que ser distinguibles por el numero de argumentos y sus tipos.

4.3.

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 despu s en a e el nivel de las tablas. 4.3.1. Herencia de tipos

Los tipos derivados heredan los atributos de superclase. Los m todos e tambi n se heredan por sus subtipos, al igual que los atributos. Sin embargo, e un subtipo puede redenir el efecto de un m todo declar ndolo de nuevo. e a Esto se conoce como sobreescritura (overriding) del m todo. e 4.3.2. Herencia de tablas

Las subtablas en SQL:1999 se corresponden con la nocion del modelo E-R de la especializacion y la generalizacion. Por tanto, cada atributo presente en una supertabla debe estar tambi n e presente en las subtablas. Adem s, cuando se declaran subtablas derivadas de una supertabla, a cada tupla presente en una subtabla tambi n est presentes en la supertabla. e a En principio, sera posible la herencia multiple tanto en tipos como en tablas, pero ANSI SQL:1999 no lo soporta Las subtablas pueden guardarse de manera eciente sin r plica de e 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 denidos localmente. Los atributos heredados (aparte de la clave primaria) no hace falta guardarlos y pueden obtenerse mediante una reunion con la supertabla basada en la clave primaria. Cada tabla almacena todos los atributos heredados y denidos localmente. Cuando se inserta una tupla se almacena solo en la subtabla en la que se inserta y su presencia se inere en cada supertabla. El acceso a todos los atributos de una tupla es m s r pido, dado que no a a se requiere una reunion.

4.4.

Referencias

Los lenguajes orientados a objetos proporcionan la posibilidad de hacer referencia a los objetos. El atributo de un tipo puede ser una referencia a

BASES DE DATOS RELACIONALES ORIENTADAS A OBJETOS

16

un objeto de un tipo especicado. Este concepto es equivalente al de clave externa.

4.5.

Consultas con tipos complejos

En este apartado se presenta una extension del lenguaje de consulta SQL para trabajar con los tipos complejos. 4.5.1. Acceso a datos estructurados

Se hace referencia al nombre del atributo compuesto utilizando una notacion con un punto. Se ver mejor con un ejemplo sencillo: averiguar el ttulo y el nombre de a la editorial de cada documento. La consulta siguiente lleva a cabo esa tarea: select ttulo, editorial.nombre from libros Obs rvese que se hace referencia al campo nombre del atributo come puesto editorial. 4.5.2. Expresiones de ruta

Las referencias se desreferencian en SQL:1999 con el smbolo ->. Con sid rese otra vez la tabla departamentos. Se puede usar la siguiente consulta e para hallar los nombres y direcciones de los directores de todos los departamentos. select director-$>$nombre, director-$>$direccin \\ o from departamentos Una expresion como director->nombre se denomina una expresi n de o ruta. Dado que directores una referencia a una tupla de la tabla persona, el atributo nombre en la consulta anterior es el atributo nombre de la tupla de la tabla persona. 4.5.3. Atributos de tipo coleccion

Los arrays son el unico tipo coleccion soportado por SQL:1999 Una expresion que se evalue a una coleccion puede aparecer en cualquier lugar en que aparezca un nombre de relacion, tal como en la cl usula from, como a ilustran los siguientes ejemplos (Se usa la tabla Libros denida en el libro) Si se desea hallar todos los documentos que tienen las palabras base de datos entre sus palabras clave se puede utilizar la consulta siguiente:

BASES DE DATOS RELACIONALES ORIENTADAS A OBJETOS

17

select ttulo from libros where base de datos in (unnest(lista-palabras-clave)) Obs rvese que se ha usado el operador unnest(lista-palabras-clave) en e una posicion en la que SQL sin relaciones anidadas habra exigido una subexpresion select-from-where. La transformacion de una relacion anidada en una forma con menos (o sin) atributos de tipo relacion se denomina desanidamiento. El proceso inver so de transformar una relacion 1FN en una relacion anidada se denomina anidamiento. Si se sabe que un libro en particular tiene tres autores, se podra escribir: select array-autores[1], array-autores[2], array-autores[3] from libros where ttulo= Fundamentos de bases de datos

4.6.

Funciones y procedimientos

SQL:1999 permite la denicion de funciones, procedimientos y m todos. e Se pueden denir mediante el componente procedimental de SQL:1999 o mediante un lenguaje de programacion como Java, C o C++. Algunos sistemas de bases de datos soportan sus propios lenguajes procedimentales, tales como PL/SQL en Oracle y TransactSQL en SQLServer de Microsoft. Estos incorporan una parte procedimental parecida a SQL:1999, pero hay diferencias tanto en la sintaxis como en la sem ntica a 4.6.1. Funciones y procedimientos en SQL

Supongase que se desea una funcion que, dado un libro, devuelva el recuento del numero de autores usando el esquema 4FN. Se puede denir la funcion as: create function recuento-autores(ttulo varchar(20)) returns integer begin declare recuento-a integer; select count(autor) into recuento-a from autores where autores.ttulo = ttulo return recuento-a; end La funcion anterior se puede utilizar en una consulta que devuelva los ttulos de todos los libros que tengan m s de un autor: a

BASES DE DATOS RELACIONALES ORIENTADAS A OBJETOS

18

select ttulo from libros where recuento-autores(ttulo) > 1 Las funciones son particularmente utiles con tipos de datos especializa dos tales como las im genes y los objetos geom tricos. a e Las funciones se pueden escribir en un lenguaje externo, como C o Java. Algunos sistemas de bases de datos tambi n soportan funciones que e devuelven relaciones, es decir, multiconjuntos de tuplas, aunque tales funciones no se soportan en SQL:1999. Los m todos se pueden ver como funciones asociadas a tipos estruce turados. Tienen un primer par metro implcito denominado self, que se a establece al valor del tipo estructurado sobre el que se invoca el m todo. e As, el cuerpo del m todo puede referirse a un atributo a del valor usando e self.a. El m todo tambi n puede actualizar estos atributos. e e SQL:1999 tambi n soporta procedimientos. Los procedimientos se pueden e invocar desde un procedimiento SQL o desde SQL embebido con la instruccion call: SQL:1999 permite que m s de un procedimiento o funcion compartan a el mismo nombre, siempre que el numero de los argumentos sea diferente, o que las que tengan el mismo numero dieran al menos en el tipo de un argumento. El nombre, junto con el numero y tipo de los argumentos, se usa para identicar el procedimiento.