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. polimorfismo . . . . . . . 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 3 4 6 6 6 7 8 9 9

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

10 11 12 13

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

13 13 14 14 14 14 14 15 15 15

1

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

´ 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

1

´ A OBJETOS ORIENTACION

1.

3

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 refinados 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 modificar “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 clasificacion. ´ 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 modificacion ´ por quien no tenga derecho a acceder a ellos, eliminando efectos secundarios e interacciones. Polimorfismo 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-

1

´ A OBJETOS ORIENTACION

4

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 define 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. ´ Se utiliza a veces la expresion ´ invocar a un m´etodo 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 modificar la definicion ´ 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 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 definicion ´ y un comportamiento comun, ´ y se diferencian solo ´ en los valores asignados a sus atributos.

1

´ A OBJETOS ORIENTACION

5

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 define 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 ´ en UML de esta clase ser´ıa 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 definicion ´ 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 define tras mensajes: ¨ sueldo-anual, nombre-completo y antiguedad. Obs´ervese que el mensaje ´ utiliza un par´ametro que especifica el nuevo valor de direcset-direccion cion. ´

1

´ A OBJETOS ORIENTACION

1.3.

6

polimorfismo

En programacion ´ orientada a objetos se denomina polimorfismo 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 ´ permiten un tipo especial de m´etodos 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 redefinen 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 defini´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, redefinir´ıamos el operador + para nuestra clase de complejos, y el codigo final 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 definen iguales atributos y m´etodos. No son id´enticas porque cada clase define, adem´as, atributos y/o m´etodos que no comparte con las dem´as. Ser´ıa conveniente definir una representacion ´ de los atributos y m´etodos comunes en un solo lugar. Esto puede hacerse creando una nueva clase, que contendr´a solo las caracter´ısticas comunes, y redefiniendo las clases originales como especializaciones de la nueva clase.

1

´ A OBJETOS ORIENTACION

7

Las clases especializadas adquieren una dependencia de herencia con respecto a la clase general, ya que heredan los atributos y m´etodos definidos 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 especifica, 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 definir 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´etodo de una clase dada A puede ser invocado con cualquier objeto perteneciente a cualquier subclase de A. De igual forma, los atributos definidos en la superclase son utilizables en cualquiera de sus derivadas. Si la clase Persona define el atributo Nombre, las clases Empleado y Cajero tambi´en las definen 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 identifica el departamento del estudiante y la clase profesor puede tener an´alogamente una variable dept que identifica el departamento de profesor. La clase ayudante-profesor heredar´ıa ambas definiciones. 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.

1

´ A OBJETOS ORIENTACION

8

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 como en ´ aun m´as dr´astica es impedir la herencia multiple, ´ 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 definiciones 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 ´ identificador. Esta forma de identidad se utiliza en los sistemas orientados a objetos. Cada objeto recibe del sistema de manera autom´atica un identificador en el momento en que se crea. Los identificadores de los objetos son unicos; es decir, cada objeto tiene ´ un solo identificador y no hay dos objetos que tengan el mismo identificador. Los identificadores 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 identificador 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 identificador de un objeto como atributo de otro se denomina referenciar un objeto.

2

LENGUAJES ORIENTADOS A OBJETOS

1.8.

9

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 codifican, 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.

3

3.

´ PERSISTENTES LENGUAJES DE PROGRAMACION

10

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 anfitrion ´ 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 anfitrion ´ 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 significativo 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 anfitrion ´ y ambos comparten el mismo sistema de tipos. Los objetos se pueden crear y guardar en la base de datos sin ningun ´ tipo expl´ıcito 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

3

´ 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 ˜ las bases de datos. Adem´as, la complejidad de los lenguajes hace que la optimizacion ´ autom´atica de alto nivel, como la reduccion ´ 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 flexible, 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 ´ del programa, se le marca de manera expl´ıcita.

3

´ 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 ´ si) son alcanzables desde el objeto ra´ız 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 identificadores de los objetos son en realidad punteros internos de la memoria. Sin embargo, la asociacion ´ de los objetos con ubicaciones f´ısicas de almacenamiento 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 modifica 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.

4

BASES DE DATOS RELACIONALES ORIENTADAS A OBJETOS

3.3.

13

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, ˜ pero no resulta pr´actico 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´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 ´ de clase de manera autom´atica, y siempre que se borre un objeto, e´ ste se eliminar´a de la extension ´ 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 identificadores. Generalmente solo ´ se da nombre a las extensiones de las clases y a otros objetos de tipo coleccion ´ y, quiz´as, a 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. ´

4

BASES DE DATOS RELACIONALES ORIENTADAS A OBJETOS

4.2. 4.2.1.

14

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 definiciones 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 especificando 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 ´ o clips de v´ıdeo. SQL:1999 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 ´ conseguir´ıa un “localizador” de un objeto grande y lo usar´ıa para manipularlo desde el lenguaje anfitrion. ´ 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 definidos sobre e´ l. Los m´etodos se declaran como parte de la definicion ´ de tipos de un tipo estructurado. 4.2.4.

Constructores

Hay que definir 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 predefinidos. Cualquiera otra funcion ´ constructora tiene que crearse expl´ıcitamente. Puede haber m´as de una constructora para el mismo tipo estructurado;

4

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 redefinir 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 eficiente –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 definidos 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 definidos localmente. Cuando se inserta una tupla se almacena solo ´ en la subtabla en la que se inserta y su presencia se infiere 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

4

BASES DE DATOS RELACIONALES ORIENTADAS A OBJETOS

16

un objeto de un tipo especificado. 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 ´ como “director->nombre” se denomina una expresi´on de 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´ausula from, como ilustran los siguientes ejemplos (Se usa la tabla Libros definida 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:

4

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 ´ en la que SQL sin relaciones anidadas habr´ıa 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 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 definicion ´ de funciones, procedimientos y m´etodos. Se pueden definir 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 definir ´ 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:

4

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 difieran al menos en el tipo de un ´ argumento. El nombre, junto con el numero y tipo de los argumentos, se ´ usa para identificar el procedimiento.