Tema 8. Bases de datos orientadas a objetos.

Juan Ignacio Rodr guez 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 persistentes. 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

A OBJETOS ORIENTACION

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 as tarde en Smalltalk, que fue desarrollado en Simula en el Xerox PARC, pero disenado para ser un sistema completamente din amico en el cual los objetos se podr an crear y modicar en marcha en lugar de tener un sistema basado en programas est aticos. La programacion orientada a objetos introduce nuevos conceptos, que a veces no son m as que nombres nuevos aplicados a conceptos antiguos, ya conocidos. Entre ellos destacan los siguientes: Objetos entidades complejas provistas de datos (propiedades, atributos) y comportamiento (funcionalidad, programas, m etodos). Corresponden a los objetos reales del mundo que nos rodea. Clases conjuntos de objetos que comparten propiedades y comportamiento. M etodo es un codigo ejecutable asociado a un objeto (o a una clase de objetos), cuya ejecucion se desencadena mediante un mensaje. Mensaje una comunicacion dirigida a un objeto, que le ordena que ejecute uno de sus m etodos con ciertos par ametros. Propiedad, atributo o variable datos asociados a un objeto o a una clase de objetos. Herencia las clases no est an aisladas, sino que se relacionan entre s , formando una jerarqu a de clasicacion. Los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen. Encapsulamiento cada objeto est a aislado del exterior, es un modulo nat 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 etodos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre, aunque el comportamiento del m etodo var e 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 a basado en el encapsu-

A OBJETOS ORIENTACION

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 a asociado con: 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 ametros, tener uno o varios. Un conjunto de m etodos, cada uno de los cuales es codigo que im plementa un mensaje; el m etodo devuelve un valor como respuesta al mensaje. El t ermino mensaje en un entorno orientado a objetos no implica el uso de mensajes f sicos; por el contrario, hace referencia al intercambio de solicitudes entre los objetos, independientemente de los detalles concretos de su implementacion. etodo Se utiliza a veces la expresion invocar a un m para denotar el hecho de enviar un mensaje a un objeto y la ejecucion del m etodo correspondiente. 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 etodo 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 etodos y tienen atributos del mismo nombre y tipo. Ser a 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 comportamiento comun, y se diferencian solo en los valores asignados a sus atributos.

A OBJETOS ORIENTACION

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 ser an empleados, clientes, cuentas y pr estamos. El siguiente listado dene una clase Empleado, en pseudo-codigo. clase Empleado: string nombre string apellidos string direcci on date fecha-alta int sueldo def sueldo-anual(self): return self.sueldo * 14 def nombre-completo(self): return self.nombre + + self.apellidos def antig uedad(self): return hoy() - self.fecha_alta def set-direcci on(self, newdir): self.direcci on = newdir La representacion a as : en UML de esta clase ser 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 responden los objetos de la clase. Cada objeto de la clase empleado contiene los , todas cadenas de caracteres; fechaAtributos nombre, apellidos y direccion alta, que es una fecha, y sueldo, que es un entero. Se dene tras mensajes: sueldo-anual, nombre-completo y antiguedad . Obs ervese que el mensaje utiliza un par set-direccion ametro que especica el nuevo valor de direccion.

A OBJETOS ORIENTACION

1.3.

polimorsmo

En programacion orientada a objetos se denomina polimorsmo a la capacidad del codigo de un programa para ser utilizado con diferentes tipos de datos u objetos. Tambi en 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.4.

sobrecarga de operadores

Algunos lenguajes de programacion eto permiten un tipo especial de m dos que permiten la sobrecarga de operadores. Estos m etodos otorgan la 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 ecnica podemos sumar dos objetos creados por nosotros, o un objeto y un entero, en vez de limitarnos a sumar numeros enteros o reales. Por ejemplo, si deni eramos una clase complex para trabajar con numeros complejos en un lenguaje que no soporta sobrecarga de operadores, tendr amos que implementar un m etodo suma, y el codigo que implementa la suma quedar a as : a = complex(1, 3.4) b = complex(-2, 0.54) a.suma(b) Sin embargo, en un lenguaje con sobrecarga de operadores, redenir amos el operador + para nuestra clase de complejos, y el codigo nal quedar a: 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 etodos. No son id enticas porque cada clase dene, adem as, atributos y/o m etodos que no comparte con las dem as. Ser a conveniente denir una representacion etodos de los atributos y m comunes en un solo lugar. Esto puede hacerse creando una nueva clase, que contendr a solo las caracter sticas comunes, y redeniendo las clases originales como especializaciones de la nueva clase.

A OBJETOS ORIENTACION

Las clases especializadas adquieren una dependencia de herencia con respecto a la clase general, ya que heredan los atributos y m etodos denidos en esta. Aparece por tanto el concepto de jerarqu a de clases, que es parecido al de especializacion del modelo entidad-relacion. Las relaciones entre una clase m as especica, o clase derivada, con respecta a su clase gen erica o superclase, siempre son de especializacion, es decir , si la clase A deriva de una superclase B, lo que queremos decir es que A es un tipo particular de B. Como ejemplo de estas relaciones, se podr an 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: etodo de cualquier m 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 en las denen impl citamente, por la herencia. La herencia propicia as la reutilizacion dado que no hace del codigo, falta volver a escribir los mensajes, m etodos y funciones para los objetos de las clases derivadas.

1.6.

Herencia multiple

En la mayor parte de los casos una organizacion de clases con estructura de a rbol resulta adecuada para describir las aplicaciones; en la organizacion con estructura de a rbol, cada clase puede tener a lo sumo una superclase. Sin embargo, hay situaciones que no pueden representarse bien en una jerarqu a de clases con estructura de a rbol. La herencia multiple permite a las clases heredar variables y m etodos de multiples superclases. La relacion entre clases y subclases se representa mediante un grafo ac clico dirigido en vez de un a rbol. Cuando se utiliza la herencia multiple existe una posible ambiguedad, ya que se puede heredar la misma variable o el mismo m etodo de m as de 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 alogamente una variable dept que identica el departamento de profesor. La clase ayudante-profesor heredar a ambas deniciones. Existen varias formas de evitar esta ambiguedad: Incluir las dos variables, d andoles nombres diferentes para distinguirlas Escoger solo una, segun el orden en que se declararon las clases.

A OBJETOS ORIENTACION

Obligar al usuario a seleccionar de manera expl cita una de las opciones Considerar esta situacion como un error. Diferentes implementaciones han elegido cada una de estas opciones. Una solucion as dr astica es impedir la herencia multiple, como en aun m 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 etodos cambien 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 as potente 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 proporcione ningun identicador. Esta forma de identidad se utiliza en los sistemas orientados a objetos. Cada objeto recibe del sistema de manera autom atica un identicador en el momento en que se crea. 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 e estar en una forma con 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 as importante que tener un nombre que resulte f acil de recordar. Utilizar un identicador de un objeto 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 as simples. Puede haber varios niveles de continentes. Esta situacion crea entre los objetos una jerarqu a 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 jerarqu a 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 asicos de la programacion orientada a objetos en un nivel abstracto. Para poder utilizarlos en la pr actica en un sistema de bases de datos hay que concretarlos en algun 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 ejemplo, 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 as caracter sti 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 on persistente. Estudiaremos estas dos opciones en el resto de este tema.

PERSISTENTES LENGUAJES DE PROGRAMACION

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 programacion 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 as posibilidades de presentar errores no detectados. b) La conversion entre el formato orientado a objetos y el formato relacional de las tuplas necesita gran cantidad de codigo. El codigo de conversion, para cargar y descar junto con el codigo 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 cito tipo expl 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 expl cito 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 expl cita 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

PERSISTENTES LENGUAJES DE PROGRAMACION

11

escribir de manera expl cita codigo para buscarlos en la memoria o para volver a guardarlos en el disco. Se han propuesto versiones persistentes de los lenguajes de programacion anos como Pascal. En los ultimos 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 ciertos inconvenientes. Dado que los lenguajes de programacion suelen ser potentes resulta relativamente sencillo cometer errores de programacion que danen as, la complejidad de los lenguajes hace que las bases de datos. Adem la optimizacion atica de alto nivel, como la reduccion autom de E/S de disco, resulte m as dif cil. 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 transitorios, 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 as 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. 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 es de haberlos creado. Todos los objetos se crean como transitorios, pero, si un objeto tiene que persistir m as all a de la ejecucion cita. del programa, se le marca de manera expl

PERSISTENTES LENGUAJES DE PROGRAMACION

12

A diferencia del enfoque anterior, la decision sobre la persistencia o la transitoriedad se retrasa hasta despu es de la creacion del objeto. Persistencia por alcance Uno o varios objetos se declaran objetos persistentes (objetos ra z) de manera expl cita. Todos los dem as objetos ser an persistentes si (y solo z si) son alcanzables desde el objeto ra mediante una secuencia de una o m as referencias. Este esquema tiene la ventaja de que resulta sencillo hacer que sean persistentes estructuras de datos completas con solo declarar como persistente la ra z 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 intr nseca es utilizar los punteros a las ubicaciones f sicas 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 sicas de alma de los objetos con ubicaciones f cenamiento puede variar con el tiempo. Hay varios grados de permanencia de las identidades: Dentro de los procedimientos La identidad solo persiste durante la ejecucion procedimiento. Un ejemplo de la identidad dentro de un unico 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 en entre las reorganizaciones estructurales de los datos. 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 de objetos relativamente con un numero pequeno, actico para millones de objetos. pero no resulta pr 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 e ser f aciles de recordar y pueden ser incluso punteros f sicos 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 coleccion. Los tipos de colecciones incluyen los conjuntos, los multiconjuntos, listas, etc etera. Un caso especial de coleccion son las extensiones de 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 atica, y siempre de clase de manera autom que se borre un objeto, e a de la extension ste se eliminar de 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 identicadores. Generalmente solo se da nombre a las extensiones de las clases y a otros objetos de tipo coleccion as, a y, quiz determinados objetos seleccionados, pero normalmente no se nominan la mayor a 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 as ricos y complejos y anadiendo la programacion orientada a objetos. Los lenguajes de consulta relacionales como SQL tambi en necesitan ser 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 fotograf a de una persona, o muy grandes (del orden de varios Mbytes o incluso Gbytes), tales como im agenes m edicas de alta resolucion deo. SQL:1999 o clips de v 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 a un localizador de un objeto grande y lo usar a conseguir 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 etodos denidos sobre e eto l. Los m 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 citamente. constructora tiene que crearse expl Puede haber m as de una constructora para el mismo tipo estructurado;

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 a la herencia de los tipos y despu es en el nivel de las tablas. 4.3.1. Herencia de tipos

Los tipos derivados heredan los atributos de superclase. Los m etodos tambi en se heredan por sus subtipos, al igual que los atributos. Sin embargo, un subtipo puede redenir el efecto de un m etodo declar andolo de nuevo. Esto se conoce como sobreescritura (overriding) del m etodo. 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 en presente en las subtablas. Adem as, cuando se declaran subtablas derivadas de una supertabla, cada tupla presente en una subtabla tambi en est a presentes en la supertabla. En principio, ser a 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 eplica 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 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 as r apido, dado que no 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 a mejor con un ejemplo sencillo: averiguar el t tulo y el nombre de la editorial de cada documento. La consulta siguiente lleva a cabo esa tarea: select t tulo, editorial.nombre from libros Obs ervese que se hace referencia al campo nombre del atributo compuesto editorial. 4.5.2. Expresiones de ruta

Las referencias se desreferencian en SQL:1999 con el s mbolo ->. Consid erese otra vez la tabla departamentos. Se puede usar la siguiente consulta para hallar los nombres y direcciones de los directores de todos los departamentos. select director-$>$nombre, director-$>$direcci on \\ from departamentos Una expresion on de como director->nombre se denomina una expresi 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, ausula from, como tal como en la cl 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 t tulo from libros where base de datos in (unnest(lista-palabras-clave)) Obs ervese que se ha usado el operador unnest(lista-palabras-clave) en una posicion a exigido una en la que SQL sin relaciones anidadas habr 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 inverso de transformar una relacion 1FN en una relacion anidada se denomina anidamiento. Si se sabe que un libro en particular tiene tres autores, se podr a escribir: select array-autores[1], array-autores[2], array-autores[3] from libros where t tulo= Fundamentos de bases de datos

4.6.

Funciones y procedimientos

SQL:1999 permite la denicion etodos. de funciones, procedimientos y m 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 antica 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(t tulo varchar(20)) returns integer begin declare recuento-a integer; select count(autor) into recuento-a from autores where autores.t tulo = t tulo return recuento-a; end La funcion anterior se puede utilizar en una consulta que devuelva los t tulos de todos los libros que tengan m as de un autor:

BASES DE DATOS RELACIONALES ORIENTADAS A OBJETOS

18

select t tulo from libros where recuento-autores(t tulo) > 1 Las funciones son particularmente utiles con tipos de datos especializa dos tales como las im agenes y los objetos geom etricos. Las funciones se pueden escribir en un lenguaje externo, como C o Java. Algunos sistemas de bases de datos tambi en soportan funciones que devuelven relaciones, es decir, multiconjuntos de tuplas, aunque tales funciones no se soportan en SQL:1999. Los m etodos se pueden ver como funciones asociadas a tipos estructurados. Tienen un primer par ametro impl cito denominado self, que se establece al valor del tipo estructurado sobre el que se invoca el m etodo. As , el cuerpo del m etodo puede referirse a un atributo a del valor usando self.a. El m etodo tambi en puede actualizar estos atributos. SQL:1999 tambi en soporta procedimientos. Los procedimientos se pueden invocar desde un procedimiento SQL o desde SQL embebido con la instruccion call: SQL:1999 permite que m as de un procedimiento o funcion compartan 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.