Bases de Datos Orientadas a Objetos

Tema 8. Bases de datos orientadas a objetos.

Juan Ignacio Rodrıguez de Leon

Resumen

El paradigma de la programacion orientada a objetos. Necesidadde 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 31.1. Los objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2. Clases de objetos . . . . . . . . . . . . . . . . . . . . . . . . . 41.3. polimorfismo . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.4. sobrecarga de operadores . . . . . . . . . . . . . . . . . . . . 61.5. Herencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.6. Herencia multiple . . . . . . . . . . . . . . . . . . . . . . . . . 71.7. Identidad de los objetos . . . . . . . . . . . . . . . . . . . . . 81.8. Continentes de objetos . . . . . . . . . . . . . . . . . . . . . . 9

2. Lenguajes orientados a objetos 9

3. Lenguajes de programacion persistentes 103.1. Persistencia de los objetos . . . . . . . . . . . . . . . . . . . . 113.2. Identidad de los objetos y punteros a memoria . . . . . . . . 123.3. Almacenamiento y acceso a los objetos persistentes . . . . . 13

4. Bases de datos relacionales orientadas a objetos 134.1. Relaciones anidadas . . . . . . . . . . . . . . . . . . . . . . . 134.2. Tipos de datos complejos . . . . . . . . . . . . . . . . . . . . . 14

4.2.1. Colecciones . . . . . . . . . . . . . . . . . . . . . . . . 144.2.2. Objetos de gran tamano (LOB) . . . . . . . . . . . . . 144.2.3. Tipos estructurados . . . . . . . . . . . . . . . . . . . . 144.2.4. Constructores . . . . . . . . . . . . . . . . . . . . . . . 14

4.3. Herencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.3.1. Herencia de tipos . . . . . . . . . . . . . . . . . . . . . 154.3.2. Herencia de tablas . . . . . . . . . . . . . . . . . . . . 15

1

INDICE 2

4.4. Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.5. Consultas con tipos complejos . . . . . . . . . . . . . . . . . . 16

4.5.1. Acceso a datos estructurados . . . . . . . . . . . . . . 164.5.2. Expresiones de ruta . . . . . . . . . . . . . . . . . . . . 164.5.3. Atributos de tipo coleccion . . . . . . . . . . . . . . . 16

4.6. Funciones y procedimientos . . . . . . . . . . . . . . . . . . . 174.6.1. Funciones y procedimientos en SQL . . . . . . . . . . 17

1 ORIENTACION A OBJETOS 3

1. Orientacion a objetos

Los conceptos de la programacion orientada a objetos tienen origen enSimula 67, un lenguaje disenado para hacer simulaciones, creado por Ole-Johan Dahl y Kristen Nygaard del Centro de Computo Noruego en Oslo.Fueron refinados mas tarde en Smalltalk, que fue desarrollado en Simula enel Xerox PARC, pero disenado para ser un sistema completamente dinamicoen el cual los objetos se podrıan crear y modificar “en marcha” en lugar detener un sistema basado en programas estaticos.

La programacion orientada a objetos introduce nuevos conceptos, que aveces no son mas que nombres nuevos aplicados a conceptos antiguos, yaconocidos. Entre ellos destacan los siguientes:

Objetos entidades complejas provistas de datos (propiedades, atributos)y comportamiento (funcionalidad, programas, metodos). Correspon-den a los objetos reales del mundo que nos rodea.

Clases conjuntos de objetos que comparten propiedades y comportamien-to.

Metodo es un codigo ejecutable asociado a un objeto (o a una clase deobjetos), cuya ejecucion se desencadena mediante un ”mensaje”.

Mensaje una comunicacion dirigida a un objeto, que le ordena que ejecuteuno de sus metodos con ciertos parametros.

Propiedad, atributo o variable datos asociados a un objeto o a una clasede objetos.

Herencia las clases no estan aisladas, sino que se relacionan entre sı, for-mando una jerarquıa de clasificacion. Los objetos heredan las propiedadesy el comportamiento de todas las clases a las que pertenecen.

Encapsulamiento cada objeto esta 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 mod-ificacion por quien no tenga derecho a acceder a ellos, eliminandoefectos secundarios e interacciones.

Polimorfismo metodos diferentes, asociados a objetos distintos, puedencompartir el mismo nombre, aunque el comportamiento del metodovarıe segun el objeto al que se aplica.

1.1. Los objetos

Hablando en general, los objetos se corresponden con las entidades delmodelo E-R. El paradigma orientado a objetos esta basado en el encapsu-


lamiento de los datos y del codigo relacionados con cada objeto en una solaunidad cuyo contenido no es visible desde el exterior.

Conceptualmente, todas las interacciones entre cada objeto y el restodel sistema se realizan mediante mensajes. Por tanto, la interfaz entre cadaobjeto y el resto del sistema se define mediante un conjunto de mensajespermitidos.

En general, cada objeto esta 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 notener parametros, tener uno o varios.

Un conjunto de metodos, cada uno de los cuales es codigo que im-plementa un mensaje; el metodo devuelve un valor como respuestaal mensaje.

El termino mensaje en un entorno orientado a objetos no implica eluso de mensajes fısicos; por el contrario, hace referencia al intercambio desolicitudes entre los objetos, independientemente de los detalles concretosde su implementacion. Se utiliza a veces la expresion invocar a un metodopara denotar el hecho de enviar un mensaje a un objeto y la ejecucion delmetodo correspondiente.

La principal razon de diferenciar las dos acciones es obtener la capacidadde modificar la definicion de un objeto, sin afectar al resto del sistema. Estaes una de las mayores ventajas de la programacion orientada a objetos

Los atributos derivados de las entidades del modelo E-R pueden expre-sarse en el modelo orientado a objetos como mensajes solo de lectura. Porejemplo, el atributo derivado antiguedad de una entidad empleado puedeexpresarse como el mensaje antiguedad de un objeto empleado. El metodoque implemente los mensajes, puede determinar la antiguedad restando lafecha-alta del empleado de la fecha actual.

1.2. Clases de objetos

En una base de datos hay muchos objetos similares. Por similar se en-tiende que responden a los mismos mensajes, utilizan los mismos metodosy tienen atributos del mismo nombre y tipo. Serıa un derroche definir porseparado cada uno de estos objetos. Por tanto, los objetos parecidos se agru-pan para formar una clase. Cada uno de estos objetos se denomina ejemplaro instancia de su clase.

Todos los objetos de una clase comparten una definicion y un com-portamiento comun, y se diferencian solo en los valores asignados a susatributos.


El concepto de clase del modelo orientado a objetos se corresponde conel concepto de entidad del modelo E-R. Algunos ejemplos de clases en labase de datos bancaria serıan empleados, clientes, cuentas y prestamos.

El siguiente listado define una clase Empleado, en pseudo-codigo.

clase Empleado:

string nombre

string apellidos

string direccion

date fecha-alta

int sueldo

def sueldo-anual(self):

return self.sueldo * 14

def nombre-completo(self):

return self.nombre + ’ ’ + self.apellidos

def antiguedad(self):

return hoy() - self.fecha_alta

def set-direccion(self, newdir):

self.direccion = newdir

La representacion en UML de esta clase serıa ası:

Empleadostring nombrestring apellidosstring direcciondate fecha-altaint sueldoint sueldo-anual()string nombre-completo()date antiguedad()set-direccion(string)

La definicion muestra las variables y los mensajes a los que respon-den los objetos de la clase. Cada objeto de la clase empleado contiene losAtributos nombre, apellidos y direccion, todas cadenas de caracteres; fecha-alta, que es una fecha, y sueldo, que es un entero. Se define tras mensajes:sueldo-anual, nombre-completo y antiguedad. Observese que el mensajeset-direccion utiliza un parametro que especifica el nuevo valor de direc-cion.


1.3. polimorfismo

En programacion orientada a objetos se denomina polimorfismo a la ca-pacidad del codigo de un programa para ser utilizado con diferentes tiposde datos u objetos. Tambien se puede aplicar a la propiedad que poseenalgunas operaciones de tener un comportamiento diferente dependiendodel objeto (o tipo de dato) sobre el que se aplican.

1.4. sobrecarga de operadores

Algunos lenguajes de programacion permiten un tipo especial de meto-dos que permiten la sobrecarga de operadores. Estos metodos otorgan lacapacidad de transformar los operadores de un lenguaje como por ejem-plo los operadores +, -, *, /, etc de forma que se redefinen para poder serutilizados con los objetos de nuestra clase.

Mediante esta tecnica podemos sumar dos objetos creados por nosotros,o un objeto y un entero, en vez de limitarnos a sumar numeros enteros oreales.

Por ejemplo, si definieramos una clase complex para trabajar con numeroscomplejos en un lenguaje que no soporta sobrecarga de operadores, ten-drıamos que implementar un metodo suma, y el codigo que implementa lasuma 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ıamosel 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 necesitargran numero de clases. Frecuentemente, sin embargo, varias de las clasesson parecidas entre sı. Son parecidas porque definen iguales atributos ymetodos. No son identicas porque cada clase define, ademas, atributos y/ometodos que no comparte con las demas.

Serıa conveniente definir una representacion de los atributos y metodoscomunes en un solo lugar. Esto puede hacerse creando una nueva clase,que contendra solo las caracterısticas comunes, y redefiniendo las clasesoriginales como especializaciones de la nueva clase.


Las clases especializadas adquieren una dependencia de herencia conrespecto a la clase general, ya que heredan los atributos y metodos definidosen esta. Aparece por tanto el concepto de jerarquıa de clases, que es parecidoal de especializacion del modelo entidad-relacion.

Las relaciones entre una clase mas especifica, o clase derivada, con respec-ta a su clase generica o superclase, siempre son de especializacion, es decir ,si la clase A deriva de una superclase B, lo que queremos decir es que A esun 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, yCajero es un tipo especial de Empleado.

Una ventaja importante de la herencia en los sistemas orientados aobjetos es el concepto de posibilidad de sustitucion: cualquier metodo deuna clase dada A puede ser invocado con cualquier objeto pertenecientea cualquier subclase de A. De igual forma, los atributos definidos en lasuperclase son utilizables en cualquiera de sus derivadas. Si la clase Personadefine el atributo Nombre, las clases Empleado y Cajero tambien las definenimplıcitamente, por la herencia.

La herencia propicia ası la reutilizacion del codigo, dado que no hacefalta volver a escribir los mensajes, metodos y funciones para los objetos delas clases derivadas.

1.6. Herencia multiple

En la mayor parte de los casos una organizacion de clases con estructurade arbol resulta adecuada para describir las aplicaciones; en la organizacioncon estructura de arbol, cada clase puede tener a lo sumo una superclase.Sin embargo, hay situaciones que no pueden representarse bien en unajerarquıa de clases con estructura de arbol.

La herencia multiple permite a las clases heredar variables y metodosde multiples superclases. La relacion entre clases y subclases se representamediante un grafo acıclico 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 metodo de mas deuna superclase. Por ejemplo, la clase estudiante puede tener un variabledept que identifica el departamento del estudiante y la clase profesor puedetener analogamente una variable dept que identifica el departamento deprofesor. La clase ayudante-profesor heredarıa ambas definiciones.

Existen varias formas de evitar esta ambiguedad:

Incluir las dos variables, dandoles nombres diferentes para distinguir-las

Escoger solo una, segun el orden en que se declararon las clases.


Obligar al usuario a seleccionar de manera explıcita una de las op-ciones

Considerar esta situacion como un error.

Diferentes implementaciones han elegido cada una de estas opciones.Una solucion aun mas drastica es impedir la herencia multiple, como enJava.

1.7. Identidad de los objetos

Los objetos de las bases de datos orientadas a objetos suelen correspon-der a entidades del sistema modelado por la base de datos. Las entidadesconservan su identidad aunque algunas de sus propiedades cambien conel tiempo. De manera parecida, los objetos deben conservar su identidadaunque los valores de las variables o las definiciones de los metodos cam-bien total o parcialmente con el tiempo.

Este concepto de identidad no se aplica a las tuplas de las bases de datosrelacionales. En los sistemas relacionales las tuplas de una relacion solo sedistinguen por los valores que contienen.

La identidad de los objetos es un concepto de identidad mas potenteque el que suele hallarse en los lenguajes de programacion o en los modelosde datos no orientados a objetos. A continuacion se ilustran varios ejemplosde identidad.

Valor Se utiliza un valor de datos como identidad. Esta forma de identidadse 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 sis-temas de archivos.

Incorporada Se incluye el concepto de identidad en el modelo de datos oen el lenguaje de programacion y no hace falta que el usuario pro-porcione ningun identificador. Esta forma de identidad se utiliza enlos sistemas orientados a objetos. Cada objeto recibe del sistema demanera automatica un identificador en el momento en que se crea.

Los identificadores de los objetos son unicos; es decir, cada objeto tieneun solo identificador y no hay dos objetos que tengan el mismo identificador.Los identificadores de los objetos no tienen por que estar en una forma conla que los seres humanos se encuentren comodos; pueden ser numerosgrandes, por ejemplo. La posibilidad de guardar el identificador de unobjeto como un campo de otro objeto es mas importante que tener unnombre que resulte facil de recordar. Utilizar un identificador de un objetocomo atributo de otro se denomina referenciar un objeto.

2 LENGUAJES ORIENTADOS A OBJETOS 9

1.8. Continentes de objetos

Se pueden utilizar las referencias entre objetos para modelar diferentesconceptos del mundo real. Uno de estos objetos es el de continentes deobjetos, que consiste en crear objetos compuestos o complejos, constituidos porobjetos mas simples.

Puede haber varios niveles de continentes. Esta situacion crea entre losobjetos 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” delos 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 basicos de la progra-macion orientada a objetos en un nivel abstracto. Para poder utilizarlos enla practica en un sistema de bases de datos hay que concretarlos en algunlenguaje. Esto puede realizarse de dos maneras:

1. Los conceptos de la programacion orientada a objetos se utilizanunicamente como herramientas de diseno y se codifican, por ejem-plo, en una base de datos relacional. Se sigue este enfoque cuandose utilizan los diagramas entidad-relacion para modelar los datos yluego se convierten de manera manual en un conjunto de relaciones.

2. Los conceptos de la programacion orientada a objetos se incorporan enun lenguaje que se utiliza para trabajar con la base de datos. Con esteenfoque hay varios lenguajes posibles en los que se pueden integrarlos conceptos:

Una opcion es extender un lenguaje para el tratamiento de datos,como SQL, anadiendo tipos complejos y las demas caracterısti-cas de la programacion orientada a objetos. Los sistemas queproporcionan extensiones orientadas a objetos a los sistemas rela-cionales se denominan sistemas relacionales orientados a objetos.

Otra opcion es tomar un lenguaje de programacion orientado aobjetos y extenderlo para que trabaje con las bases de datos. Estoslenguajes se denominan lenguajes de programacion persistente.

Estudiaremos estas dos opciones en el resto de este tema.

3 LENGUAJES DE PROGRAMACION PERSISTENTES 10

3. Lenguajes de programacion persistentes

Los lenguajes de las bases de datos trabajan directamente con datosque son persistentes, es decir, los datos siguen existiendo una vez que elprograma que los creo ha concluido. Las relaciones de las bases de datos y lastuplas de las relaciones son ejemplos de datos persistentes. Por el contrario,los unicos datos persistentes con los que los lenguajes de programaciontradicionales trabajan directamente son los archivos.

La manera tradicional de realizar las interfaces de las bases de datoscon los lenguajes de programacion tradicionales consiste en incorporar oembeber 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 lenguajesde programacion persistente pueden distinguirse de los lenguajes con SQLembebido de al menos dos maneras:

1. En los lenguajes incorporados el sistema de tipos del lenguaje an-fitrion suele ser diferente del sistema de tipos del lenguaje para eltratamiento de los datos. Los programadores son responsables de lasconversiones de tipos entre el lenguaje anfitrion y SQL. Exigir que losprogramadores ejecuten esta tarea presenta varios inconvenientes:

a) El codigo para la conversion entre objetos y tuplas opera fueradel sistema de tipos orientado a objetos y, por tanto, tiene masposibilidades 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. Elcodigo de conversion, junto con el codigo para cargar y descar-gar los datos de la base de datos puede suponer un porcentajesignificativo del total necesario para la aplicacion

Por el contrario, en los lenguajes de programacion persistente, ellenguaje de consulta se halla totalmente integrado con el lenguajeanfitrion y ambos comparten el mismo sistema de tipos. Los objetosse pueden crear y guardar en la base de datos sin ningun tipo explıcitoni cambios de formato; los cambios necesarios se realizan de maneratransparente.

2. Los programadores que utilizan lenguajes de consulta incorporadosson responsables de la escritura de codigo explıcito para la busquedade los datos de la base de datos en la memoria. Si se realizan actualiza-ciones, los programadores deben escribir codigo de manera explıcitapara volver a guardar los datos actualizados en la base de datos.

Por el contrario, en los lenguajes de programacion persistentes losprogramadores pueden trabajar con datos persistentes sin tener que


escribir de manera explıcita codigo para buscarlos en la memoria opara volver a guardarlos en el disco.

Se han propuesto versiones persistentes de los lenguajes de progra-macion como Pascal. En los ultimos anos han recibido mucha atencion lasversiones persistentes de los lenguajes orientados a objetos como C++, Javay 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 quedanen las bases de datos. Ademas, la complejidad de los lenguajes hace quela optimizacion automatica de alto nivel, como la reduccion de E/S de disco,resulte mas difıcil.

A continuacion se describen varios aspectos que cualquier lenguaje deprogramacion 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 transformaruno de estos lenguajes en un lenguaje para la programacion de bases dedatos, el primer paso consiste en proporcionar una manera de hacer persis-tentes a los objetos. Se han propuesto varios enfoques.

Persistencia por clases El enfoque mas sencillo, pero el menos conveniente,consiste en declarar que una clase es persistente. Todos los objetos dela clase son, por tanto, persistentes de manera predeterminada. Todoslos objetos de las clases no persistentes son transitorios. Este enfoqueno es flexible, porque no permite disponer en una misma clase tantode objetos transitorios como de objetos persistentes.

En muchos sistemas de bases de datos orientados a objetos, la declaracionde que una clase es persistente se debe interpretar mejor como “quepueden ser persistentes”.

Persistencia por creacion En este enfoque se introduce una sintaxis nuevapara crear los objetos persistentes mediante la extension de la sintaxispara la creacion de los objetos transitorios. Por tanto, los objetos sonpersistentes o transitorios en funcion de la manera de crearlos. Esteenfoque se sigue en varios sistemas de bases de datos orientados aobjetos.

Persistencia por marcas Una variante del enfoque anterior es marcar losobjetos como persistentes despues de haberlos creado. Todos los ob-jetos se crean como transitorios, pero, si un objeto tiene que persistirmas alla de la ejecucion del programa, se le marca de manera explıcita.


A diferencia del enfoque anterior, la decision sobre la persistencia ola transitoriedad se retrasa hasta despues de la creacion del objeto.

Persistencia por alcance Uno o varios objetos se declaran objetos persis-tentes (objetos raız) de manera explıcita. Todos los demas objetosseran persistentes si (y solo si) son alcanzables desde el objeto raızmediante una secuencia de una o mas referencias.

Este esquema tiene la ventaja de que resulta sencillo hacer que seanpersistentes estructuras de datos completas con solo declarar comopersistente la raız de las mismas. Sin embargo, el sistema de basesde datos sufre la carga de tener que seguir las cadenas de referenciaspara detectar los objetos que son persistentes, lo que puede resultarcostoso.

3.2. Identidad de los objetos y punteros a memoria

El concepto de la identidad de los objetos tiene una relacion interesantecon los punteros de los lenguajes de programacion. Una manera sencilla deconseguir una identidad intrınseca es utilizar los punteros a las ubicacionesfısicas de almacenamiento. En concreto, en muchos lenguajes orientados aobjetos como C++, los identificadores de los objetos son en realidad pun-teros internos de la memoria.

Sin embargo, la asociacion de los objetos con ubicaciones fısicas de alma-cenamiento puede variar con el tiempo. Hay varios grados de permanenciade las identidades:

Dentro de los procedimientos La identidad solo persiste durante la ejecu-cion de un unico procedimiento. Un ejemplo de la identidad dentrode los procedimientos son las variables locales del interior de los pro-cedimientos.

Dentro de los programas La identidad solo persiste durante la ejecucionde un unico programa o una unica consulta. Un ejemplo de la identi-dad dentro de los programas son las variables globales de los lengua-jes de programacion. Los punteros de la memoria principal o de lamemoria virtual solo ofrecen identidad dentro de los programas.

Entre programas La identidad persiste de una ejecucion del programa aotra. Los punteros a los datos del sistema de archivos del disco ofrecenidentidad entre los programas, pero pueden cambiar si se modifica lamanera en que los datos se guardan en el sistema de archivos.

Persistente La identidad no solo persiste entre las ejecuciones del programasino tambien entre las reorganizaciones estructurales de los datos.Es la forma persistente de la identidad necesaria para los sistemasorientados a objetos.

4 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 losenfoques consiste en dar nombres a los objetos, igual que se hace con losarchivos. Este enfoque resulta util con un numero de objetos relativamentepequeno, pero no resulta practico para millones de objetos.

Un segundo enfoque consiste en exponer los identificadores de los ob-jetos o los punteros persistentes de los objetos, que pueden guardarse demanera externa. A diferencia de los nombres, estos punteros no tienen porque ser faciles de recordar y pueden ser incluso punteros fısicos dentro dela base de datos.

Un tercer enfoque es guardar las colecciones de objetos y permitir quelos programas iteren sobre las mismas para hallar los objetos deseados. Lascolecciones de objetos pueden a su vez modelarse como objetos de un tipocoleccion. Los tipos de colecciones incluyen los conjuntos, los multiconjun-tos, listas, etcetera. Un caso especial de coleccion son las extensiones declases, 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, elmismo se inserta en la extension de clase de manera automatica, y siempreque se borre un objeto, este se eliminara de la extension de clase.

La mayor parte de los sistemas de bases de datos orientados a obje-tos permiten las tres maneras de acceso a los objetos persistentes. Todoslos objetos tienen identificadores. Generalmente solo se da nombre a lasextensiones de las clases y a otros objetos de tipo coleccion y, quizas, adeterminados objetos seleccionados, pero normalmente no se nominan lamayorıa de los objetos.

4. Bases de datos relacionales orientadas a objetos

Los modelos de datos relacionales orientados a objetos extienden elmodelo de datos relacional proporcionando un sistema de tipos mas ricosy complejos y anadiendo la programacion orientada a objetos.

Los lenguajes de consulta relacionales como SQL tambien necesitan serextendidos para trabajar con el sistema de tipos enriquecido.

4.1. Relaciones anidadas

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


4.2. Tipos de datos complejos

4.2.1. Colecciones

Los conjuntos son ejemplares de los tipos coleccion. Otros ejemplaresson los arrays y los multiconjuntos (es decir, colecciones sin orden dondeun elemento puede aparecer varias veces). Las siguientes definiciones deatributos 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 accedera 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 almacenaratributos grandes (del orden de varios Kbytes), tales como la fotografıa deuna persona, o muy grandes (del orden de varios Mbytes o incluso Gbytes),tales como imagenes medicas de alta resolucion o clips de vıdeo. SQL:1999proporciona por tanto nuevos tipos de datos para objetos de gran tamanopara datos de caracteres (clob) y binarios (blob). Las letras “lob” en estostipos de datos son acronimos de “Large OBject” (objeto grande).

Los objetos grandes se usan normalmente en aplicaciones externas, ytiene poco sentido extraerlos completamente en SQL. En su lugar, unaaplicacion conseguirıa un “localizador” de un objeto grande y lo usarıapara manipularlo desde el lenguaje anfitrion.

4.2.3. Tipos estructurados

Los tipos estructurados permiten la representacion directa de atributoscompuestos de los diagramas E-R.

Un tipo estructurado puede tener metodos definidos sobre el. Los meto-dos 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 es-tructurados. En SQL-1999 y en muchos otros lenguajes se utiliza una funcioncon el mismo nombre que un tipo estructurado como funcion constructora.

De manera predeterminada, cada tipo estructurado tiene un constructorsin argumentos, que establece los atributos a sus valores predefinidos.

Cualquiera otra funcion constructora tiene que crearse explıcitamente.Puede haber mas de una constructora para el mismo tipo estructurado;


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

4.3. Herencia

La herencia puede hallarse en el nivel de los tipos o en el nivel de lastablas. En primer lugar se considerara la herencia de los tipos y despues enel nivel de las tablas.

4.3.1. Herencia de tipos

Los tipos derivados heredan los atributos de superclase. Los metodostambien se heredan por sus subtipos, al igual que los atributos. Sin embargo,un subtipo puede redefinir el efecto de un metodo declarandolo de nuevo.Esto se conoce como sobreescritura (overriding) del metodo.

4.3.2. Herencia de tablas

Las subtablas en SQL:1999 se corresponden con la nocion del modeloE-R de la especializacion y la generalizacion.

Por tanto, cada atributo presente en una supertabla debe estar tambienpresente en las subtablas.

Ademas, cuando se declaran subtablas derivadas de una supertabla,cada tupla presente en una subtabla tambien esta presentes en la supertabla.

En principio, serıa posible la herencia multiple tanto en tipos como entablas, pero ANSI SQL:1999 no lo soporta

Las subtablas pueden guardarse de manera eficiente –sin replica detodos los campos heredados– de una de las dos siguientes formas:

Cada tabla almacena la clave primaria (que se puede heredar de unatabla padre) y los atributos definidos localmente. Los atributos hereda-dos (aparte de la clave primaria) no hace falta guardarlos y puedenobtenerse mediante una reunion con la supertabla basada en la claveprimaria.

Cada tabla almacena todos los atributos heredados y definidos local-mente. Cuando se inserta una tupla se almacena solo en la subtablaen la que se inserta y su presencia se infiere en cada supertabla. Elacceso a todos los atributos de una tupla es mas rapido, dado que nose requiere una reunion.

4.4. Referencias

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


un objeto de un tipo especificado. Este concepto es equivalente al de claveexterna.

4.5. Consultas con tipos complejos

En este apartado se presenta una extension del lenguaje de consulta SQLpara trabajar con los tipos complejos.

4.5.1. Acceso a datos estructurados

Se hace referencia al nombre del atributo compuesto utilizando unanotacion con un punto.

Se vera mejor con un ejemplo sencillo: averiguar el tıtulo y el nombre dela editorial de cada documento. La consulta siguiente lleva a cabo esa tarea:

select tıtulo, editorial.nombre

from libros

Observese que se hace referencia al campo nombre del atributo com-puesto editorial.

4.5.2. Expresiones de ruta

Las referencias se desreferencian en SQL:1999 con el sımbolo ->. Con-siderese otra vez la tabla departamentos. Se puede usar la siguiente consultapara hallar los nombres y direcciones de los directores de todos los depar-tamentos.

select director-$>$nombre, director-$>$direccion \\

from departamentos

Una expresion como “director->nombre” se denomina una expresion deruta.

Dado que directores una referencia a una tupla de la tabla persona, elatributo nombre en la consulta anterior es el atributo nombre de la tupla dela tabla persona.

4.5.3. Atributos de tipo coleccion

Los arrays son el unico tipo coleccion soportado por SQL:1999 Unaexpresion que se evalue a una coleccion puede aparecer en cualquier lugaren que aparezca un nombre de relacion, tal como en la clausula from, comoilustran los siguientes ejemplos (Se usa la tabla Libros definida en el libro)

Si se desea hallar todos los documentos que tienen las palabras “basede datos” entre sus palabras clave se puede utilizar la consulta siguiente:


select tıtulo

from libros

where ’base de datos’ in (unnest(lista-palabras-clave))

Observese que se ha usado el operador unnest(lista-palabras-clave) enuna posicion en la que SQL sin relaciones anidadas habrıa exigido unasubexpresion select-from-where.

La transformacion de una relacion anidada en una forma con menos (osin) atributos de tipo relacion se denomina desanidamiento. El proceso inver-so de transformar una relacion 1FN en una relacion anidada se denominaanidamiento.

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 metodos.Se pueden definir mediante el componente procedimental de SQL:1999o mediante un lenguaje de programacion como Java, C o C++. Algunossistemas 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 haydiferencias tanto en la sintaxis como en la semantica

4.6.1. Funciones y procedimientos en SQL

Supongase que se desea una funcion que, dado un libro, devuelva elrecuento del numero de autores usando el esquema 4FN. Se puede definirla 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 lostıtulos de todos los libros que tengan mas de un autor:


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 imagenes y los objetos geometricos.

Las funciones se pueden escribir en un lenguaje externo, como C o Ja-va. Algunos sistemas de bases de datos tambien soportan funciones quedevuelven relaciones, es decir, multiconjuntos de tuplas, aunque tales fun-ciones no se soportan en SQL:1999.

Los metodos se pueden ver como funciones asociadas a tipos estruc-turados. Tienen un primer parametro implıcito denominado self, que seestablece al valor del tipo estructurado sobre el que se invoca el metodo.Ası, el cuerpo del metodo puede referirse a un atributo a del valor usandoself.a. El metodo tambien puede actualizar estos atributos.

SQL:1999 tambien soporta procedimientos. Los procedimientos se puedeninvocar desde un procedimiento SQL o desde SQL embebido con la instruc-cion call:

SQL:1999 permite que mas de un procedimiento o funcion compartanel 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 unargumento. El nombre, junto con el numero y tipo de los argumentos, seusa para identificar el procedimiento.

Bases de Datos Orientadas a Objetos

Documents

Transcript of Bases de Datos Orientadas a Objetos