Capitulo 9-Bases de Datos Basadas en Objetos

5/16/2018 Capitulo 9-Bases de Datos Basadas en Objetos

1/30

PAR T E 3

Basesde datos orientadas a objetos y XML

Varias areas de aplicaciones para los sistemas de bases de datos se hallan limitadas por las restriccionesdel modelo de datos relacional. En consecuencia, los investigadores han desarrollado varios modelos dedatos basados en enfoques orientados a objetos para tratar con esos dominios de aplicaciones.El modelo relacional orientado a objetos, que se describe en el Capitulo 9,combina caracteristicas delmodelo relacional y del modele orienta do a objetos. Este modelo proporciona el rico sistema de tipos delos lenguajes orientados a objetos combinado con las relaciones como base del almacenamiento de losdatos. Aplica la herencia a las relaciones, no s6lo a los tipos. El modelo de datos relacional orientado aobjetos permite una migraci6n facil desde las bases de datos relacionales, 10 que resulta atractivo paralas diferentes marcas de bases de datos relacionales. En consecuencia, la norma SQL1999 incluye variascaracteristicas orientadas a objetos en su sistema de tipos, mientras que sigue utilizando el modelorelacional como modelo subyacente.El termino base de datos orientada a objetos se utiliza para describir los sistemas de bases de datosque soportan el acceso directo a los datos desde lenguajes de programaci6n orientados a objetos, sinnecesidad de lenguajes de consultas relacionales como interfaz de las bases de datos. El Capitulo 9tarnbien proporciona una breve visi6n general de las bases de-datos orientadas a objetos. .Ellenguaje XMLse disefio inicialmente como un modo de afiadir informaci6n de.marcas a los docu-mentos de texto, pero ha adquirido importancia debido a sus aplicaciones en el intercambio de datos.XMLpermite representar los datos mediante una estructura anidada y, adernas, ofrece una gran flexi-bilidad en su estructuraci6n, 10 que resulta importante para ciertos tipos de datos no tradicionales. E1Capitulo 10 describe ellenguaje XMLy a continuaci6n presenta diferentes formas de expresar las con-sultas sobre datos representados en XML,incluido ellenguaje de consultas XQuery para XML,que estaadquiriendo una gran aceptaci6n.


2/30

QAPfTULO 9

Las aplicaciones tradicionales de las bases de datos consisten en tareas de procesamiento de datos, comola gesti6n bancaria y de nominas, con tipos de datos relativamente sencillos, que se adaptan bien al mo-delo relacional. A medida que los sistemas de bases de datos se fueron aplicando a un rango mas ampliode aplicaciones, como el diserio asistido por computadora y los sistemas de informaci6n geografica, laslimitaciones impuestas por el modele relacional se convirtieron en un obstaculo. La soluci6n fue la in-troducci6n de bases de datos basadas en objetos, que permiten trabajar con tipos de datos complejos.

9.1 Vision generalEl primer obstaculo al que se enfrentan los programadores que usan el modelo relacional de datos esellimitado sistema de tipos soportado por el modele relacional. Los dominios de aplicaci6n complejosnecesitan tipos de datos del mismo nivel de complejidad, como las estructuras de registros anidados,los atributos multivalorados y la herencia, que los lenguajes de programaci6n tradicionales soportan.Lanotaci6n E-Ry las notaciones E-Rextendidas soportan, de heche. estas caracteristicas, pero hay quetrasladarlas a tipos de datos de SQLmas sencillos. El modelo de datos relacional orientado a objetosextiende el modele de datos relacional ofreciendo un sistema de tipos mas rico que incluye tipos dedatos complejos y orientaci6n a objetos. Hay que extender de manera acorde los lenguajes de consultasrelacionales, en especial SQL,para que puedan trabajar con este sistema de tipos mas rico. Estas exten-siones intentan conservar los fundamentos relacionales-en especial, el acceso declarativo a los datos-mientras extienden la potencia de modelado. Los sistemas de bases de datos relacionales basadas enobjetos, es decir, los sistemas de bases de datos basados en elmodelo objeto-relaci6n, ofrecen un mediode migraci6n comedo para los usuarios de las bases de datos relacionales que deseen usar caracteristicasorientadas a objetos.

El segundo obstaculo es la dificultad de acceso a los datos de la base de datos desde los progra-mas escritos en lenguajes de programaci6n como C++ 0Java. La mera extensi6n del sistema de tipossoportado por las bases de datos no resulta suficiente para resolver completamente este problema. Lasdiferencias entre el sistema de tipos de las bases de datos y el de los lenguajes de programaci6n hace mascomplicados el almacenamiento y la recuperad6n de los datos, y se debe minimizar. Tener que expresarel acceso a las bases de datos mediante un lenguaje (SQL)que es diferente dellenguaje de programaci6ntambien hace mas diftcil el trabajo del programador. Es deseable, para muchas aplicaciones, contar conestructuras 0 extensiones dellenguaje de programaci6n que permitan el acceso directo a los datos de labase de datos, sin tener que pasar por tm lenguaje intermedio como SQL.

El termino lenguajes de programaci6n persistentes hace referencia a las extensiones de los lenguajesde programaci6n existentes que afiaden persistencia y otras caracteristicas de las bases de datos usandoel sistema de tipos nativo dellenguaje de programaci6n. El termino sistemas de bases de datos orien-tadas a objetos se usa para hacer referenda a los sistemas de bases de datos que soportan sistemas de

289


3/30

290 Capitulo 9 Bases de datos basadas en objetos

tipos orientados a objetos y perrniten el acceso directo a los datos desde los lenguajes de programaci6norientados a objetos usando el sistema de tipos nativo dellenguaje.

En este capitulo se explicara primero el motive del desarrollo de los tipos de datos complejos. Luegose estudiaran los sistemas de bases de datos relacionales orientados a objetos; el tratamiento se basara enlas extensiones relacionales orientadas a objetos afiadidas a la versi6n SQL:1999 de la norma de SQL. Ldescripci6n se basa en la norma de SQL, concretamente, en el uso de caracteristicas que se introdujeronen SQL:1999 y en SQL:2003. Tengase en cuenta que la mayor parte de los productos de bases de datos610 soportan un subconjunto de las caracteristicas de SQL aqui descritas. Se debe consultar el manua,de usuario del sistema de bases de datos que se utilice para averiguar las caracteristicas que soporta.

Luego se estudian brevemente los sistemas de bases de datos orientados a objetos que afiaden esoporte de la persistencia a los lenguajes de programaci6n orientados a objetos. Finalmente, se describesituaciones en las que el enfoque relacional orientado a objetos es mejor que el enfoque orientadoobjetos, y viceversa, y se mencionan criterios para escoger entre los dos.

9.2 Tipos de datos complejosLas aplicaciones de bases de datos tradicionales consisten en tareas de procesamiento de datos, talescomo la banca y la gesti6n de n6minas. Dichas aplicaciones presentan conceptualmente tipos de datossimples. Los elementos de datos basic os son registros bastante pequefios y cuyos campos son atornicoses decir, no contienen estructuras adicionales y en los que se cumple la primera forma normal (vease eCapitulo 7). Ademas, s610 hay unos pocos tip os de registros.

En los ultimos arios, ha crecido la demanda de formas de abordar tipos de datos mas complejos. Considerense, por ejemplo, las direcciones. Mientras que una direcci6n completa se puede considerar comoun elemento de datos at6mico del tipo cadena de caracteres, esa forma de verlo esconde detalles comola calle, la poblaci6n, la provincia, y el c6digo postal, que pueden ser interesantes para las consultas. Pootra parte, si una direcci6n se representa dividiendola en sus componentes (calle, poblacion, provinciay c6digo postal) la escritura de las consultas seria mas complicada, pues tendrian que mencionar cadacampo. Una alternativa mejor es permitir tipos de datos estructurados, que admiten el tipo direccion conlas subpartes ca l le , pob lac ion , prov inc ia y c6digo_postal.

Como ejemplo adicional, considerense los atributos multivalorados del modelo E-R. Esos atributosresultan naturales, por ejemplo, para la representaci6n de numeros de telefono, ya que las personaspueden tener mas de un telefono, La alternativa de la normalizaci6n mediante la creaci6n de una nuevarelaci6n resulta costosa y artificial para este ejemplo.

Con sistemas de tipos complejos se pueden representar directamente conceptos del modelo E-R,comolos atributos compuestos, los atributos multivalorados, la generalizaci6n y la especializaci6n, sin necesidad de una compleja traducci6n al modelo relacional.

En el Capitulo 7 se defini6 la p rim er a fo rm a n orm al (lFN), (lFN) que exige que todos los atributostengan domini o s a t6m i co s . Recuerdese que un dominic es at6mico si se considera que los elementos dedominio son unidades indivisibles.

La suposici6n de la lFN es natural en los ejemplos bancarios que se han considerado. No obstante, notodas las aplicaciones se modelan mejor mediante re1aciones en 1a lFN. Por ejemplo, en vez de conside-rar la base de datos como un conjunto de registros, los usuarios de ciertas aplicaciones la yen como unconjunto de objetos (0 de entidades). Puede que cada objeto necesite varios registros para su represen-taci6n. Una interfaz sencilla y facil de usar necesita una correspondencia de uno a uno entre el conceptointuitivo de objeto del usuario y el concepto de elemento de datos de la base de datos.Considerese, por ejemplo, una aplicaci6n para una biblioteca y sup6ngase que se desea almacenar linformaci6n siguiente para cada libro:

Titulo dellibro Lista de autorese Editor Conjunto de palabras clave


4/30

9.3 Tipos estructurados y herencia en SQL 291

Es evidente que, si se define una relaci6n para est a informaci6n varios dominios no son at6micos. Autores. Cada libro puede tener una lista de autores, que se pueden representar como array. Pese

a todo, puede que se desee averiguar todos los libros de los que es autor Santos. Por tanto, 10 queinteresa es una subparte del elemento del dominic "autores".

Palabras clave. Si se alinacena un conjunto de palabras clave para cada libro. se espera poderrecuperar todos los libros cuyas palabras clave incluyan uno 0mas terminos dados. Por tanto, seconsidera el dominio del conjunto de palabras clave como no at6mico.

Editor. A diferencia de pa labras c lave y au to r es , e d it o r no tiene un dominio que se evalue en for-ma de conjunto. No obstante, se puede considerar que editor consta de los subcampos nombre ysucursal . Este punto de vista hace que el dominio de editor no sea at6rnico.

La Figura 9.1 muestra una relaci6n de ejemplo, libros.Por simplificar se da por supuesto que el titulo de1libro 10 identifica de manera univocal. Se puede

representar, entonces, la rnisma informaci6n usando el esquema siguiente: a u io r es itii ulo , a u io r , posici6n) pa labra s_ c la ve ( ti tu lo , pa lab ra_clav e) l ib ro s 4( ti tu lo , nombre_ed it or , sucursalediiori

El esquema anterior satisface la 4NF. La Figura 9.2 muestra Ia representaci6n normalizada de los datosde la Figura 9.1.

Aunque 1abase de datos de libros de ejemplo puede expresarse de manera adecuada sin necesidadde usar re1aciones anidadas, su uso lleva a un modele mas facil de comprender. El usuario tipico 0 e1programador de sistemas de recuperaci6n de 1a informaci6n piensa en la base de datos en terminos delibros que tienen conjuntos de autores, como los modelos de disefto que no se hallan en la 1FN. El disefiode la 4FN exige consultas que reunan varias relaciones, rnientras que los disenos que no se hallan en 1a1FN hacen mas faciles muchos tipos de consultas.

Por otro lado, en otras situaciones puede resultar mas conveniente usar una representaci6n en laprimera forma normal en lugar de conjuntos. Por ejemplo, considerese la relaci6n impositor del ejemplobancario. La relaci6n es de varios a varios entre cl ienies y cuentas . Te6ricamente, se podrfa alrnacenar unconjunto de cuentas con cada cliente, 0 un conjunto de clientes con cada cuenta, 0 ambas cosas. Si sealmacenaran ambas cosas, se tendrfa redundancia de los datos (la re1aci6n de un c1iente concreto canuna cuenta dada se almacenaria dos veces).

La posibi1idad de usar tipos de datos complejos como los conjuntos y los arrays puede resultar utilen muchas aplicaciones, pero se debe usar con cuidado.

9.3 Tipos estructurados y herencia en SQLAntes de SQL:1999e1s istema de tipos de SQL consistia en un conjunto bastante sencillo de tipos pre de-finidos. SQL:1999afiadio un sistema de tipos extenso a SQL, 10 que permite los tip as estructurados y laherencia de tipos.1. Esta suposicion no se cumple en el mundo real. Los libros se suelen identificar por un numero de ISBN de diez cifras queidentifica de manera univoca cada libro publicado.

titulo array_autores ed itor con junto_palabms_clave(nombre, sucursal)

CompiladoresRedes

[G6mez, Santos][Santos, Escudero J (McGraw-Hill, Nueva York)(Oxford, Londres) [analisis sintactico, analisis]{Internet, Web}Figura 9.1 Relaci6n de 1ibros que no esta en la IFN, l ibros.


5/30


titulo autor I posicion ICompiladores G6mez 1Compiladores Santos 2Redes Santos 1Redes Escudero 2

auiorestitu lo palabra claue

CompiladoresCompiladoresRedesRedes

analisis sintacticoanalisisInternetWebp ala br as c la oe

titulo n o m br e e d i i o r I s u c u r s a l e d i i o r ICompiladoresRedes McGraw-Hill Nueva YorkOxford Londres

libros4Figura 9.2 Versi6n en la 4FN de la relaci6n libros.

9.3.1 Tipos estructuradosLos tipos estructurados permiten representar directamente los atributos compuestos de los diagramE-R. Por ejemplo, se puede definir el siguiente tipo estructurado para representar el atributo compuesnombre can los atributos componentes nombredepi la yape ll idos :

create type Nombre astnombredepi la varchar(20),apellidos varchar(20))final

De manera parecida, el tipo estructurado siguiente puede usarse para representar el atributo compuesdireccion:

create type Direccion as.(calle varchar(20),ciudad varchar(20),c6digopostal varchar(9))not final

En SQLestos tipos se denominan tipos definidos .por el usuario. La definici6n anterior correspondediagrama E-R de la Figura 6.4. Las especificaciones final y not final estan relacionadas con la subtipificci6n, que se describira mas adelante, en el Apartado 9.3.222 Ahora se pueden usar esos tipos para cratributos compuestos en las relaciones, can s6lo declarar que un atributo es de uno de estos tipos. Pejemplo, se puede crear la tabla clienie de la manera siguiente:

create table c lie nte (nombre Nombre,d i recc ion D i recc i on ,jechaDeNacimiento date)

2. La especificacion final de Nombre indica que no se pueden crear subtipos de l1ombre, mientras que la especificaci6n not fde Direccion indica que se pueden crear subtipos de direccion.


6/30


Se puede tener acceso a los componentes de los atributos compuestos usando la notaci6n "punto'por ejemplo, nombre.nombredepila devuelve el componente nombre de pila del atributo nombre. Elaccescal atributo nombre devolveria un valor del tipo estructurado Nombre .

Tambien se puede crear una tabla cuyas filas sean de un tipo definido por el usuario. Por ejernplo. '02puede definir el tipo TipoCliente y crear la tabla cliente de la manera siguiente:

create type TipoCliente as (n omb re Nombr e,d i recc ion Direcci6n ,jechaDeNacimiento date)not final

create table cliente of TipoClienteUna manera alternativa de definir los atributos compuestos en SQLes usar tipos de fila sin nombre.

Por ejemplo, la relaci6n que representa la informaci6n del cliente se podria haber creado usando ti" osde fila de la manera siguiente:

create table c lie nte (nombre row (nombredepila varchar(20),apellidos varchar(20)),direcci6n row (calle varchar(20),

ciudad varchar(20),c6digopostaZ varchar(9)),jechaDeNacimiento date)Esta definici6n es equivalente a la anterior definici6n de la tabla, salvo en que los atributos nornbre ::direcci6n tienen tipos sin nombre y las filas de la tabla tambien tienen un tipo sin nombre.

La consulta siguiente ilustra la manera de tener acceso a los atributos componentes de los atributoscompuestos. La consulta busca el apellido y la ciudad de cada cliente.

select nombre .ape ll idos , d i recc i6n .c iudadfrom clienie

Sobre los tipos estructurados se pueden definir metodos, Los metodos se declaran como parte de : 2 .definici6n de los tipos de los tipos estructurados:

create type TipoCliente as (n omb re Nombr e,d ir e cc ion D i r ec cum ,jechaDeNacimiento date)not final

method edadAFecha(aFecha date)returns interval year

El cuerpo del metodo se crea por separado:create instance method edadAFecha (aFecha date)

returns interval yearfor TipoCliente

beginreturn aFecha - s el fj ec haDeNac im i en to;

endTengase en cuenta que la clausula for indica el tipo al que se aplica el metodo, mientras que la palabraclave instance indica que el metodo se ejecuta sobre un ejemplar del tipo Cliente. La variable self ha-creferenda al ejemplar de Cliente sobre el que se invoca el metodo, El cuerpo del metodo puede conte e- :


7/30


instrucciones procedimentales, que ya se han visto en el Apartado 4.6. Los metodos pueden actualizarlos atributos del ejemplar sobre el que se ejecutan.

Los metodos se pueden invocar sobre los ejemplares de los tipos. Si se hubiera creado la tabla cliendel tipo TipoCliente, se podrfa invocar el metodo edadAFecha 0 como se ilustra a continuaci6n, paraveriguar la edad de cada cliente.

select nombre .ape ll idos , edadAFecha(curren t_date )from cliente

En SQL:l999 se usan funciones constructoras para crear valores de los tipos estructurados. Las funcines con el mismo nombre que un tipo estructurado son funciones constructoras de ese tipo estructurado.Por ejemplo, se puede declarar una funcion constructora para el tipo Nombre de esta manera:

create function Nombre inombredep il a varchar(20), apellidos varchar(20))returns Nombrebegin

set sesi.nombredepila = notnbredepila;set self.apellidos = apellidos;

endSe puede usar new Nombre (,Martin', 'G6mez') para crear un valor del tipo Nombre .

Se puede crear un valor de fila haciendo una relaci6n de sus atributos entre parentesis. Por ejemplosi se declara el atributo nombre como tipo de fila con los componentes nombredepila y apellidos, se puedecrear para el este valor:

('Ted', 'Codd')sin necesidad de funci6n constructora.

De manera predeterminada, cada tipo estructurado tiene una funci6n constructora sin argumentos,que configura los atributos con sus val ores predeterminados. Cualquier otra funcion constructora haque crearla de manera explicita. Puede haber mas de una funcion constructora para el mismo tipo etructurado; aunque tengan el mismo nombre, deben poder distinguirse por el nurnero y tipo de suargumentos.

La instruccion siguiente ilustra la manera de crear una nueva tupla de la relacion Clienie. Se da posupuesto que se ha definido una funci6n constructora para Direccicn, igual que la funcion constructoraque se defini6 para Nombre .

insert into Clientevalues

(new Nombre('Martin', 'Gomez'),new Direccion(,Calle May01~ 20', 'Madrid', '28045'),date '22-8-1960')

9.3.2 Herencia de tiposSupongase que se tiene la siguiente definici6n de tipo para las personas:

create type Personainombre varchar(20),direccion varchar(20))

Puede que se desee almacenar en la base de datos informacion adicional sobre las personas que son estudiantes y sobre las que son profesores. Dado que los estudiantes y los profesores tambien son personase puede usar la herencia para definir en SQL los tipos estudiante y profesor:


8/30


create type Estudianteunder Persona(grado varchar(20),departmento varchar(20))

create type Profesorunder Persona(sueldo integer,departmento varchar(20))

Tanto Estudiante como Prcfesor here dan los atributos de Persona -es decir, nombre y direcci6n. Se dice queEstudiante y Profesor son subtipos de Persona, y Persona es un supertipo de Estudiante y de Profesor.

Los metodos de los tipos estructurados se heredan por sus subtipos, igual que los atributos. Sin em-bargo, cada subtipo puede redefinir el efecto de los metodos volviendo a declararlos, usando overridingmethod en lugar de method en la declaracion del metodo.

La norma de SQL tarnbien exige un campo adicional al final de la definicion de los tipos, cuyo valores final 0not final. La palabra clave final indica que no se pueden crear subtipos a partir del tipo dado,mientras que not final indica que se pueden crear subtipos. Ahora, supongase que se desea almacenarinformaci6n sabre los profesores ayudantes, que son a la vez estudiantes y profesores, quizas incluso endepartamentos diferentes. Esto se puede hacer si el sistema de tipos soporta herencia multiple, por laque se pueden declarar los tipos como subtipos de varios tipos. Tengase en cuenta que la norma de SQL(hasta las versiones SQL:1999y SQL:2003,al menos) no soporta la herencia multiple, aunque puede queS 1 que la soporten versiones futuras.

Por ejemplo, si el sistema de tipos soporta la herencia multiple, se puede definir el tipo para losprofesores ayudantes de la manera siguiente:create type Pro fesor Ayudan te

under E si ud ia nte , P ro fe so rProfesorAyudante heredara todos los atributos de Esiudianie y de Prcfeeor . No obstante, hay un problema,ya que los atributos n omb re , d ir ec c io n y departamento estan presentes tanto en Estudiante como en Profesor.Los atributos nombre y direccion se heredan realmente de una fuente comun, Persona. Por tanto, nohay ningun conflicto causado por heredarlos de Estudianie y de Profesor. Sin embargo, el atributo depar-tamento se define por separado en Estudiante y en Profesor. De hecho, cada profesor ayudante puede serestudiante en un departamento y profesor en otro. Para evitar conflictos entre las dos apariciones dedepartamento, se pueden rebautizar usando una clausula as, como en la definicion del tipo ProfesorAyu-dante:

create type Profeeor /wudanteunder Estudiante with (departmento as departamenioestudiante) ,

Profesor with (departmento as depa r tament o p ro je sor r

Hay que tener en cuenta nuevamente que SQL solo soporta la herencia simple-es decir, cada tiposolo se puede heredar de un unico tipo, la sintaxis usada es como la de los ejemplos anteriores. Laherencia multiple, como en el ejemplo de P ro fe so l'A yu da nte , n o esta soportada en SQL.En SQL, como en la mayor parte del res to de los lenguajes, el valor de un tipo estructurado debetener exactamente un "tipo mas concreto". Es decir, cada valor debe asociarse, al crearlo, con un tipo

concreto, denominado su tipo mas concreto. Mediante la herencia tarnbien se asocia con cada uno delos supertipos de su tipo mas concreto. Por ejemplo, supongase que una entidad es tanto del tipo Personacomo del tipo Estudianie. Entonces, el tipo mas concreto de la entidad es Esiudianie, ya que Estudiantees un subtipo de Persona. Sin embargo, una entidad no puede ser de los tipos Estudiante y Profesor, amenos que tenga un tipo, como P1'OfesorAyudante, que sea subtipo de Profesor y de Estudiante (1 0 cual noes posible en SQL,ya que SQLno soporta la herencia multiple).


9/30


9.4 Herencia de tablasLas subtablas de SQL se corresponden con el concepto de especializacion/ generalizaci6n de E-R. Porejemplo, sup6ngase que se define la tabla personas de la manera siguiente:

create table personas of PersonaA continuaci6n se pueden definir las tablas estudiantes y profesores como subtablas de personas, de lamanera siguiente:

create table estudiantes of Estudianteunder personascreate table profesores of Profesorunder personas

Los tipos de las subtablas deben ser subtipos del tipo de la tabla madre. Por tanto, todos los atributopresentes en personas tarnbien estan presentes en las sub tablas.Ademas, cuando se declaran estudiantes y profesores como subtablas de personas, todas las tuplas pre-sentes en estudiantes 0 en profesores pasan a estar tambien presentes de manera implicita en personas.

Por tanto, si una consulta usa la tabla personas, no s610 encuentra tuplas directamente insertadas en esatabla, sino tambien tuplas insertadas en sus subtablas, es decir, estudiantes y profesores. No obstante, esaconsulta s6lo puede tener acceso a los atributos que estan presentes en personas.SQL permite hallar tuplas que se encuentran en personas pero no en sus subtablas usando en las con-sultas "only personas" en lugar de personas. La palabra clave only tambien puede usarse en las sentenciasdelete y update. Sin la palabra clave only, la instrucci6n delete aplicada a una supertabla, como perso-

nas, tarnbien borra las tuplas que se insertaron originalmente en las subtablas (como estudiantes); porejemplo, la instrucci6n

delete from personas where Pborrara todas las tuplas de la tabla personas, as! como de sus subtablas estudiantes y profesores, que satis-fagan P. Si se afiade la palabra clave only a la instrucci6n anterior, las tuplas que se insertaron en lassubtablas no se ven afectadas, aunque satisfagan las condiciones de la clausula where. Las consulrasposteriores a la supertabla seguiran encontrando esas tuplas.Teoricamente, la herencia multiple es posible con las tablas, igual que con los tipos. Por ejemplo, sepuede crear una tabla del tipo ProfesorAyudante:

create table profesores_ayudantesof Profesor Ayudanteunder e st ud ia nt es , p ro fe so r es

Como consecuencia de la declaracion, todas las tuplas presentes en la tabla profesores_ayudantes tambiensehallan presentes de manera implicita en las tablas profesores y estudiantes y,a su vez, en la tabla personas.Hay que tener en cuenta, no obstante, que SQL no soporta la herencia multiple de tablas.Existen varios requisitos de consistencia para las subtablas. Antes de definir las restricciones, es ne-cesaria una definicion: se dice que las tuplas de una subtabla se corresponden con las tuplas de la tablamadre si tienen el mismo valor para todos los atributos heredados. Por tanto, las tuplas correspondientesrepresentan a la misma entidad.

Los requisitos de consistencia de las subtablas son:1. Cada tupla de la supertabla puede corresponderse, como maximo, con una tupla de cada una de

sus subtablas inmediatas.2. SQL posee una restricci6n adicional que hace que todas las tuplas que se corresponden entre

deben proceder de una tupla (insertada en una tabla).


10/30


create type Editor as(nombre varchar(20),sucursal varchar(20))

create type Libra as(tftulo varchar(20),array_autores varchar(20) array [10],fecha_publicaci6n date,ed it o r Ed i to r ,conjunto_palabras_clave varchar(20) multiset)

create table Librasof LibraLaprimera instrucci6n define el tipo denominado Editor, que tiene dos componentes: nombre y sucursaLLa segunda instrucci6n define el tipo estructurado Libra, que contiene un titulo, un array_autores, que esun array de hasta diez nombres de autor, una fecha de publicaci6n, un editor (del tipo Editor) , y unmulticonjunto de palabras clave. Finalmente, se crea la tabla l ibros, que contiene las tuplas del tipo Libra.

Tengase en cuenta que se ha usado un array, en lugar de un multiconjunto, para almacenar el nombrede los autores, ya que el orden de los autores sueletener cierta importancia, rnientras que se consideraque el orden de las palabras asociadas con ellibro no es significativo.

En general, los atributos multivalorados de los esquemas E-Rse pueden asignar en SQL a atributosvalorados como multiconjuntos; si el orden es importante, se pueden usar los arrays de SQL en lugar delos multiconjuntos.

9.5.1 Creaci6n y acceso a los valores de los conjuntosEn SQL:1999 se puede crear un array de valores de esta manera:

array['Silberschatz', 'Korth', 'Sudarshan']De manera parecida, se puede crear un multiconjunto de palabras clave de la manera siguiente:

multiset['computadora', 'base de datos', 'SQL']Por tanto, se puede crear una tupla del tipo definido por la relaci6n l ibros como:

('Compiladores', array['G6mez', 'Santos']' new Editor( 'McGraw-HilL 'Nueva York'),multiset[' analisis sintactico, ,analisis'[)

En este ejemplo se ha creado un valor para el atributo Editor mediante la invocaci6n a una funci6nconstructora para Editor con los argumentos correspondientes. Tengase en cuenta que esta constructorapara Editor se debe crear de manera explicita y no sehalla presente de manera predeterminada; se puededeclarar como la constructora para Nombre, que ya se ha visto en el Apartado 9.3.

Si se desea insertar la tupla anterior en la relaci6n libras, se puede ejecutar la instrucci6n:insert into l ibrosvalues(,Compiladores', array['G6mez', 'Santos']'

new Editor('McGraw-Hill', 'Nueva York'),multiset[' analisis sintactico', ,analisis'[)

Se puede tener acceso a los elementos del array 0 actualizarlos especificando el indice del array, porejemplo, array_au to re s [ 1 ].9.5.2 Consulta de los atributos valorados como conjuntosAhora se considerara la forma de manejar los atributos que se valoran como conjuntos. Las expresionesque se valoran como conjuntos pueden aparecer en cualquier parte en la que pueda aparecer el nombre


11/30

9.5 Tipos array y multiconjunto en SQL 299

de una relacion, como las clausulas from, como ilustran los siguientes parrafos. Se usara la tabla Librasque ya se habia definido anteriormente.Si se desea averiguar todos los libros que tienen las palabras "base de datos" entre sus palabras clavese puede usar la consulta siguiente:

select titulofrom l ibroswhere 'base de datos' in (unnest(conjunto_palabras_clave))Observese que se ha usado unnest(conjunto_palabras_clave) en una posicion en la que SQLsin las relacio-nes anidadas habria exigido una subexpresi6n select-from-where.Si se sabe que un libro concreto tiene tres autores, se puede escribir:

select a r ra y_a u to r es [l ], a r ra y_a u to r es [2 l, a r ra y_a u to r es [3 ]from l ibroswhere titulo = 'Fundamentos de bases de datos'Ahora sup6ngase que se desea una relaci6n que contenga parejas de la forma "titulo, nombre_autor"

para cada libro y para cada uno de sus autores. Se puede usar esta consulta:select L .i ii ul o, A a ut or e sfrom l ibros as L, unnest (L .array_autores) as A(autores)

Dado que el atributo array_autores de Libras es un campo que se valera como conjunto, unnest(L.array_autores) puede usarse en una clausula from en la que se espere 1ma relaci6n. Tengase en cuenta que lavariable tupla Bes visible para esta expresion, ya que se ha definido anieriormente en la clausula from.Al desanidar un array la consulta anterior pierde informaci6n sobre el orden de los elementos delarray. Se puede usar la clausula unnest with ordinality para obtener esta informacion, como ilustra laconsulta siguiente. Esta consulta se puede usar para generar la relaci6n auiores, que se ha visto anterior-mente, a partir de la relaci6n l ibras.

select titulo, Aautores, Aposicionfrom l ibros as L,unnest(L.array_autores) with ordinality as A (au to r es , p o si ci 6n )

La clausula with ordinality genera un atributo adicional que registra la posici6n del elemento en elarray. Se puede usar una consulta parecida, pero sin la clausula with ordinality, para generar la relacionpaLabras_clave.9.5.3 Anidamiento y desanidamientoLa transformaci6n de una re1aci6n anidada en una forma con menos atributos de tipo relaci6n (0 sinellos) se denomina desanidamiento. La relaci6n l ibros tiene dos atributos, array_autores y coniuniopala-b ra s c la ue , que son conjuntos, y otros des, titulo y editor, que no 10 son. Sup6ngase que se desea convertirla relaci6n en una sola relaci6n plana, sin relaciones anidadas ni tipos estructurados como atributos. Sepuede usar la siguiente consulta para llevar a cabo la tarea:

select ti tu lo , A au io r, e di io r. no rn br e as n ombre ed it or , e d ii o r. su c ur s alas sucursal editor, P.paLabras_clavefrom l ibros as L, unnest(L.array_autores) as A(autores),unnest (L.conjunto_palabras_clave) as P(palabras_clave)La variable L de la clausula from se declara para que tome valores de l ibros. La variable A se declarapara que tome valores de los autores de array_autores para ellibro Ly P se declara para que tome valoresde las palabras clave del conjunto_palabras_clave dellibro L. La Figura 9.1 muestra un ejemplar de lare1aci6n l ibros y la Figura 9.3 muestra 1arelacion, denominada l ibrosplana, que es resultado de la consulta


12/30


titu lo au io r I n omb re e d ito r I s u cu r sa l e d ito r I c on ju n to p ala br ae c la ve I_ _ _Compiladores G6mez McGraw-Hill Nueva York analisis sintacticoCompiladores Santos McGraw-Hill Nueva York analisis sintacticoCompi1adores G6mez McGraw-Hill Nueva York analisisCompi1adores Santos McGraw-Hill ueva York analisisRedes Santos Oxford Londres InternetRedes Escudero Oxford Londres InternetRedes Santos Oxford Londres WebRedes Escudero Oxford Londres Web

Figura 9.3 l ibroeplana: resultado del desanidamiento de los atributos array_autores y coniuniopalabra_clave de la relacion l ibros.

anterior. Tengase en cuenta que la relacion tibroeplana se halla en IFN, ya que todos sus atributos sat6micos.

E1proceso inverso de transformar una relacion en la IFN en una relaci6n anidada se denomina anidmiento. El anidamiento puede realizarse mediante una extensi6n de la agrupaci6n en SQL. En e1 unormal de 1a agrupaci6n en SQL se crea (l6gicamente) una relacion multiconjunto temporal para cagrupo y se aplica una funci6n de agregaci6n a esa re1aci6n temporal para obtener un valor unico (amico). La funcion collect devuelve e1multiconjunto de valores; en lugar de crear un solo valor se puedcrear una relaci6n anidada. Suporigase que se tiene la relaci6n en IFN librosplana, tal y como se muestren la Figura 9.3. La consu1ta siguiente anida la relaci6n en el atributo palabras curoe:

select t it u lo , au iore s, Ed i to r inombre ediior, sucursaLeditor) as editor,col lect(palabras_clave) as conjunto_palabras_clavefrom librosplanagroup by ti tu lo , a u io r , e d ito r

El resultado de la consulta a la relaci6n Hbrosplana de la Figura 9.3 aparece en la Figura 9.4.Si se desea anidar tarnbien e1a tributo autores en un multiconjunto, se puede usar la consu1ta:

select t it u lo , col lec t (autores) as conjunio putores,Ediiortncmbreeditor, sucursaLeditor) as editor,col lect(palabra_clave) as coniunto paiabras ciaue

from li br os p la nagroup by t it u lo , ed i to r

Otro enfoque de la creaci6n de relaciones anidadas es usar subconsultas en 1a clausula select. Uventaja del enfoque de las subconsultas es que se puede usar de manera opcional en la subconsulta uclausula order by para generar los resultados en el orden deseado, 10que puede aprovecharse para creun array. La siguiente consulta ilustra este enfoque; las palabras clave array y multiset especifican qse van a crear un array y un multiconjunto (respectivamente) a partir del result ado de las subconsu1tas

titulo auior editor con iun io pa labraeclaoeinombre editor, sucursaleditor) I

Compiladores G6mez (McGraw-Hill, Nueva York) [analisis sintactico, analisis]Compiladores Santos (McGraw-Hill, Nueva York) [analisis sintactico, analisis]Redes Santos (Oxford, Londres) {Internet, Web)Redes Escudero (Oxford, Londres) {Internet, Web}

Figura 9.4 Una versi6n parcialmente anidada de la relaci6n librosplana.


13/30

9.6 Identidad de los objetos y tipos de referencia en SQL 301

select titulo,array( select auioresfrom autores as Awhere A. t itu lo = L.tituloorder by A.posicion) as array_autores,

Ed it or (n ombr e_ e di to r , s uc u rs al _e d it or ) as editor,multiset( select palabra_clavefrom palabras c iaoe as Pwhere P.titulo = L. titulo) as conjunto_palabras_clave,

from libros4 as LEl sistema ejecuta las subconsultas anidadas de la clausula select para cada tupla generada por lasclausulas from and where de la consulta externa. Observese que el atributo L.tftulo de la consulta externase usa en las consultas anidadas para garantizar que s610se generen los conjuntos correctos de autoresy de palabras clave para cada titulo.

SQL:2003 ofrece gran variedad de operadores para multiconjuntos. incluida la funcion set(M), quecalcula una version libre duplicada del multiconjunto 1 \ 1 [ , la operaci6n agregada intersection, cuyo re-sultado es la intersecci6n de todos los multiconjuntos de un grupo, la operaci6n agregada fusion, quedevuelve launi6n de todos los multiconjuntos de un grupo, y elpredicado submultiset, que compruebasi el multiconjunto esta contenido en otro multiconjunto.

La norma de SQL no proporciona ningun media para actualizar los atributos de los multiconjuntos,salvo asignarles valores nuevos. Por ejemplo, para borrar el valor v del atributo de multiconjunto A hayque definirlo como (A except all multiset[v]).

9.6 Identidad de los objetos y tipos de referenda en SQLLos lenguajes orientados a objetos ofrecen la posibilidad de hacer referencia a objetos. Los atributos deun tipo dado pueden servir de referencia para los objetos de un tipo concreto. Por ejemplo. en SQL sepuede definir el tipo Departamento con el campo nombre y el campo director, que es una referencia al tipoPersona, y la tabla departamentos del tipo Departamento, de la manera siguiente:

create type D epartmento (nombre varchar(20),d i re c tor re f(Per sona ) scope personas

create table departamentos of DeparimenioEn este caso, la referencia esta restringida a las tuplas de la tabla personas. Larestricci6n del ambito (sco-pe) de referencia a las tuplas de una tabla es obligatoria en SQL, y hace que las referencias se comportencomo las claves externas.

Se puede ornitir la declaraci6n scope personas de la declaraci6n de tipos y hacer, en su lugar, unafiadido a la instrucci6n create table:

create table depariamenios of Deparimento(director with options scope personas)

La tabla a la que se hace referencia debe tener un atributo que guarde el identificador de cada tupla.Ese atributo, denominado atributo autorreferencial (self-referential attribute), se declara ariadiendo unaclausula ref is a la instrucci6n create table:

create table personas of Personaref is id_personal system generated

En este caso, id_personal es el nombre de un atributo, no una palabra clave, y la instrucci6n create tableespecifica que labase de datos genera de manera automatica el identificador.


14/30


Para inicializar el atributo de referencia hay que obtener el identificador de la tupla a la que se vahacer referencia. Se puede conseguir el valor del identificador de la tupla mediante una consulta. Ptanto, para crear una tupla con el valor de referencia, primero se puede crear la tupla con una referencinula y luego definir la referencia de manera independiente:

insert into departameniosvalues ('CS', null)

update departamenioeset director = (select p.id personal

from personal as pwhere nombre = 'Martin')

where nombre = 'CS'Una alternativa a los identificadores generados por el sistema es permitir que los usuarios genere

los identificadores. El tipo del atributo autorreferencial debe especificarse como parte de la definici6n dtipos de la tabla a la que se hace referencia, y la definici6n de la tabla debe especificar que la referenciesta generada por el usuario (user generated):

create type Persona(nombre varchar(20),direccion varcharizu)ref using varchar(20)create table personas of Personaref is id_personal user generated

Al insertar tuplas en personas hay que proporcionar el valor del identificador:insert into personas ( id_per sonal , nombre , d ir ecc i6n ) values

(,01284567', 'Martin', 'Avenida del Segura, 23')Ninguna otra tupla de personas, de sus supertablas ni de sus subtablas puede tener el mismo identifiesdor. Por tanto, se puede usar el valor del identificador al insertar tuplas en departamenios, sin necesidade mas consultas para recuperarlo:

insert into departamentosvalues ('CS', '01284567')

Incluso es posible usar el valor de una clave prima ria ya existente como identificador, incluyendoclausula ref from en la definici6n de tipos:

create type Persona(nombre varchar(20) primary key,direcci6n varcharizu)ref from(nombre)

create table personas of Personaref is id_personal derived

Tengase en cuenta que la definici6n de la tabla debe especificar que las referencia es derivada, y debseguir especificando el nombre de W1atributo autorreferencial. Al insertar una tupla de departameniospuede usar

insert into depariameniosvalues ('CS', 'Martin')

En SQL:1999las referencias se desvinculan mediante el simbolo - .Considerese la tabla departamentoque se ha definido anteriormente. Se puede usar esta consulta para averiguar el nombre y la direcci6de los directores de todos los departamentos:


15/30

9.7 Implementaci6n de las caracterfsticas O-R 303

select d ire cto r- no mbr e. d ire cto r- dir ec cio nfrom departamentos

Las expresiones como " di re ct or - nom br e" se denominan expresiones de camino.Dado que director es una referencia a una tupla de la tabla personas, el atributo nombre de la consultaanterior es el atributo nornbre de la tupla de la tabla personas. Sepueden usar las referencias para ocultar

las operaciones de reuni6n; en el ejemplo anterior, sin las referencias, el campo director de departamentose declararfa como clave externa de la tabla personas. Para averiguar el nombre y la direcci6n del directorde un departamento, hace falta una reuni6n explicita de las relaciones departamentos y personas. EIusode referencias simplifica considerablemente la consulta.

Se puede usar la operaci6n deref para devolver la tupia a la que senala una referencia y luego teneracceso a sus atributos, como se muestra a continuaci6n.

select deref(director).nombrefrom departamentos

9.7 trnplementaclon de las caracteristicas O-RLos sistemas de bases de datos relacionales orientadas a objetos son basicamente extensiones de lossistemas de bases de datos relacionales ya existentes. Las modificaciones resultan claramente necesariasen muchos niveles del sistema de bases de datos. Sin embargo, para minimizar las modificaciones en elcodigo del sistema de almacenamiento (almacenamiento de relaciones, indices, etc.), los tipos de datoscomplejos soportados por los sistemas relacionales orientados a objetos se pueden traducir al sistemade tipos mas sencillo de las bases de datos relacionales.

Para comprender la manera de hacer esta traduccion, s6lo hace falta mirar al modo en que algunascaracteristicas del modelo E-Rse traducen en relaciones. Por ejemplo, los atributos multivalorados delmodelo E-Rse corresponden con los atributos valorados como multiconjuntos del modele relacionalorientado a objetos. Los atributos compuestos se corresponden grosso modo con los tipos estructura-dos. Las jerarqufas ESdel modelo E-Rse corresponden con la herencia de tablas del modelo relacionalorienta do a objetos.

Las tecnicas para convertir las caractensticas del modelo E-Ren tablas, que se estudiaron en elAparta-do 6.9, se pueden usar, con algunas extensiones, para traducir los datos relacionales orientados a objetosa datos relacionales en el nivel de almacenamiento.Las subtablas se pueden almacenar de manera eficiente, sin replica de todos los campos heredados,de una de estas maneras:

Cada tabla almacena la clave primaria (que puede haber heredado de una tabla madre) y losatributos que se definen de localmente. No hace falta almacenar los atributos heredados (que nosean la clave prima ria), se pueden obtener mediante una reuni6n con la supertabla, de acuerdocon la clave primaria .

Cada tabla almacena todos los atributos heredados y definidos localmente. Cuando se insertauna tupla, solo se almacena en la tabla en la que se inserta, y su presencia se infiere en cada unade las supertablas. El acceso a todos los atributos de las tuplas es mas rapido, ya que no hace faltaninguna reunion.

No obstante, en caso de que el sistema de tipos permita que cada entidad se represente en dossubtablas sin estar presente en una subtabla comun a ambas, esta representacion puede dar lugara la replica de informaci6n. Ademas, resulta diftcil traducir las claves externas que hacen referen-cia a una supertabla en restricciones de las subtablas; para implementar de manera eficiente esasclaves externas hay que definir la supertabla como vista, y el sistema de bases de datos tiene quesoportar las claves externas en las vistas.

Las implementaciones pueden decidir representar los tipos arrays y multiconjuntos directamente 0usar internamente una representacion normalizada. Las representaciones normalizadas tienden a ocu-par mas espacio y exigen un coste adicional en reuniones 0 agrupamientos para reunir los datos en


16/30

304 Capitulo 9 Bases de datos basad as en objetos

arrays 0 en multiconjuntos. Sin embargo, puede que las representaciones normalizadas resulten massencillas de implementar. .

Las interfaces de programas de aplicaci6n ODBC y JDBC se han extendido para recuperar y almacenartipos estructurados; por ejemplo, JDBC ofrece el metodo getObjectO, que es parecido a getStringO perodevuelve un objeto Java Struct, a partir del cual se pueden extraer los componentes del tipo estructura-do. Tambien es posible asociar clases de Java con tipos estructurados de SQL,y JDBC puede realizar laconversi6n entre los tipos. Vease el manual de referencia de ODBC 0 de JDBC para obtener mas detalle .

9.8 Lenguajes de proqramaclon persistentesLos lenguajes de las bases de datos se diferencian de los lenguajes de programaci6n tradicionales errque trabajan directamente con datos que son persistentes; es decir, los datos siguen existiendo una vezque el programa que los cre6 haya concluido. Las relaciones de las bases de datos y las tuplas de lasrelaciones son ejemplos de datos persistentes. Por el contrario, los iinicos datos persistentes con los qUElos lenguajes de programaci6n tradicionales trabajan directamente son los archivos.

El acceso a las bases de datos es s610 un componente de las aplicaciones del mundo real. Mientrasque los lenguajes para el tratamiento de datos como SQLson bastante efectivos en el acceso a los datosse necesita un lenguaje de programaci6n para implementar otros componentes de las aplicaciones comelas interfaces de usuario 0 la comunicaci6n con otras computadoras. La manera tradicional de realiza;las interfaces de las bases de datos con los lenguajes de programaci6n es incorporar SQL dentro de;lenguaje de programaci6n.

Los 1enguajes de programacion persistentes son lenguajes de programaci6n extendidos con estruc-turas para el tratamiento de los datos persistentes. Los lenguajes de programaci6n persistentes puedezdistinguirse de los lenguajes con SQLincorporado, al menos, de dos maneras:

1. En los lenguajes incorporados el sistema de tipos dellenguaje anfitri6n suele ser diferente d .sistema de tipos dellenguaje para el tratamiento de los datos. Los programadores son response-bles de las conversiones de tipos entre ellenguaje anfitri6n y SQL.Hacer que los programadoreslleven a cabo esta tarea presenta varios inconvenientes:

El c6digo para la conversion entre objetos y tuplas opera fuera del sistema de tipos orientadca objetos y, por tanto, tiene mas posibilidades de presentar errores no detectados .

La conversi6n en la base de datos entre el formato orientado a objetos y el formato relaciona,de las tuplas necesita gran cantidad de c6digo. El c6digo para la conversi6n de format =junto con el c6digo para cargar y descargar los datos de la base de datos, puede Buponer I.Lporcentaje significativo del c6digo total necesario para la aplicaci6n.

Por el contrario, en los lenguajes de programaci6n persistentes, ellenguaje de consultas seha-11atotalmente integrado con ellenguaje anfitri6n y ambos comparten el rnismo sistema de tip :Los objetos se pueden crear y guardar en la base de datos sin ninguna modificaci6n explicita d .tipo 0 del formato; los cambios de formato necesarios se realizan de manera transparente.

2. Los programadores que usan lenguajes de consultas incorporados son responsables de la escn-tura de c6digo explicito para la busqueda en la memoria de los datos de la base de datos. Si -realizan actualizaciones, los programadores deben escribir explfcitamente c6digo para volver :;guardar los datos actualizados en la base de datos.

Por el contrario, en los lenguajes de programaci6n persistentes, los programadores puedertrabajar con datos persistentes sin tener que escribir explicitamente c6digo para buscarlos en 2 -memoria a volver a guardarlos en el disco.

En este apartado se describe la manera en que se pueden extender los lenguajes de programaci6:-orientados aobjetos, como C++ y Java, para hacerlos lenguajes de programaci6n persistentes. Las -_racterfsticas de estos lenguajes permiten que los programadores trabajen con los datos directamentedesde el lenguaje de programaci6n, sin tener que recurrir a lenguajes de tratamiento de datos com-SQL.Por tanto, ofrecen una integraci6n mas estrecha de los lenguajes de programaci6n con las bases ._datos que, por ejemplo, SQLincorporado.


17/30

9.8 Lenguajes de programaci6n persistentes 305

Sin embargo, los lenguajes de programaci6n persistentes presentan ciertos inconvenientes que hayque tener presentes al decidir si conviene usarlos. Dado que los lenguajes de programaci6n suelen serpotentes, resulta relativamente sencillo cometer errores de programaci6n que darien las bases de datos.La complejidad de los lenguajes hace que la optimizaci6n automatica de alto nivel, como la reducci6n deE/S de disco, resulte mas dificil, En muchas aplicaciones el soporte de las consultas declarativas resultade gran importancia, pero los lenguajes de programaci6n persistentes no soportan bien actualmente lasconsultas declarativas.En este capitulo se describen varios problemas te6ricos que hay que abordar a la hora de afiadir lapersistencia a los lenguajes de programaci6n ya existentes, En primer lugar se abordan los problemasindependientes de los lenguajes y,en apartados posteriores, se tratan problemas que son especificos delos lenguajes C++ y Java. No obstante, no se tratan los detalles de las extensiones de los lenguajes; aun-que se han propuesto varias normas, ninguna ha tenido una aceptaci6n universal. Veanse las referenciasde las notas bibliograficas para saber mas sobre extensiones de lenguajes concretas y mas detalles de susimplementaciones.9.8.1 Persistenciade los objetosLos lenguajes de programaci6n orientados a objetos ya pose en un concepto de objeto, un sistema de tipospara definir los tipos de los objetos y constructores para crearlos. Sin embargo, esos objetos son iransiio-rios; desaparecen en cuanto finaliza el programa, igual que ocurre con las variables de los programas enPascal 0 en C. Si se desea transformar uno de estes lenguajes en un lenguaje para la programaci6n debases de datos, el primer paso consiste en proporcionar una manera de hacer persistentes a los objetos.Sehan propuesto varios enfoques.

Persistencia por clases. El enfoque mas sencillo, pero el menos conveniente, consiste en declararque una clase es persistente. Todos los objetos de la c1aseson, por tanto, persistentes de manerapredeterminada. Todos los objetos de las clases no persistentes son transitorios.Este enfoque no es flexible, dado que suele resu1tar util disponer en una misma clase tantode objetos transitorios como de objetos persistentes. Muchos sistemas de bases de datos orienta-dos a objetos interpretan la declaraci6n de que una clase es persistente como si se afirmara quelos objetos de la clase pueden hacerse persistentes, en vez de que todos los objetos de la claseson persistentes. Estas clases se pueden denominar con mas propiedad clases "que pueden serpersistentes" .

Persistencia por creaci6n. En este enfoque se introduce una sintaxis nueva para crear los obje-tos persistentes mediante la extensi6n de la sintaxis para 1a creaci6n de los objetos transitorios,Por tanto, los objetos son persistentes 0 transitorios en funci6n de 1aforma de crearlos. Variossistemas de bases de datos orientados a objetos siguen este enfoque. Persistencia por marcas. Una variante del enfoque anterior es marcar los objetos como persis-tentes despues de haberlos creado. Todos los objetos se crean como transitorios pero, si un objetotiene que persistir mas alla de la ejecuci6n del programa, hay que marcarlo como persistente demanera explicita antes de que este concluya. Este enfoque, a diferencia del anterior, pospone ladecisi6n sobre la persistencia 0 la transitoriedad hasta despues de 1acreacion del objeto. Persistencia por a1cance. Uno 0varios objetos se declaran objetos persistentes (objetos raiz) de

manera explicita. Todos los demas objetos seran persistentes si (y s610 si) se pueden alcanzardes de algun objeto raiz mediante una secuencia de una 0 varias referencias.Por tanto, todos los objetos a los que se haga referencia desde (es decir, cuyos identificadoresde objetos se guarden en) los objetos persistentes rafz seran persistentes. Pero tambien 10serantodos los objetos a los que se haga referencia desde enos, y los objetos a los que estes ultimoshagan referencia seran tambien persistentes, etc.Una ventaja de este esquema es que resulta sencillo hacer que sean persistentes estructuras dedatos completas con 5610declarar como persistente su raiz. Sin embargo, el sistema de bases dedatos sufre la carga de tener que seguir las cadenas de referencias para detectar los objetos queson persistentes, y eso puede resultar eostoso.


18/30

306 Capitulo 9 Basesde datos basadas enobjetos

9.8.2 Identidad de los objetos y punterosEn los lenguajes de programaci6n orientados a objetos que no se han extendido para tratar la persistecia, cuando se crea un objeto el sistema devuelve un identificador del objeto transitorio. Los identifies-dores de objetos transitorios s6lo son validos mientras se ejecuta el programa que los ha creado; despuesde que concluya ese programa, el objeto se borra y el identificador pierde su sentido. Cuando se crea lLobjeto persistente se Ie asigna un identificador de objeto persistente.

El concepto de identidad de los objetos tiene una relaci6n interesante con los punteros de los lenguajesde programaci6n. Una manera sencilla de conseguir una identidad intrinseca es usar los punteros a 10ubicaciones fisicas de almacenamiento. En concreto, en much os lenguajes orientados a objetos comC++, los identificadores de los objetos son en realidad punteros internos de la memoria.

Sin embargo, la asociaci6n de los objetos con ubicaciones fisicas de almacenamiento puede variar coel tiempo. Hay varios grados de permanencia de las identidades:

Dentro de los procedimientos. La identidad 5610persiste durante la ejecuci6n de un unico procedimiento. Un ejemplo de identidad dentro de los program as son las variables locales de 10procedimientos .

.. Dentro de los programas. La identidad s6lo persiste durante la ejecuci6n de un unico program;o de una unica consulta. Un ejemplo de identidad dentro de los programas son las variablesglob ales de los lenguajes de programaci6n. Los punteros de la memoria principal 0 de la memoriavirtual s610 ofrecen identidad dentro de los programas .

.. Entre programas. La ideritidad persiste de una ejecuci6n del programa a otra, Los punteroslos datos del sistema de archivos del disco ofrecen identidad entre los programas, pero puedercambiar si se modifica la manera en que los datos se guardan en el sistema de archivos .

.. Persistente. La identidad no 5610persiste entre las ejecuciones del programa sino tambien entrereorganizaciones estructurales de los datos. Es la forma persistente de identidad necesaria paralos sistemas orientados a objetos.

En las extensiones persistentes de los lenguajes como C++, los identificadores de objetos de los objetos persistentes se implementan como "punteros persistentes". Un punter o p e rs is te n te es un tipo 'puntero que, a diferencia de los punteros internos de la memoria, sigue siendo valido despues del finade la ejecuci6n del programa y despues de algunas modalidades de reorganizaci6n de los datos. Loprogramadores pueden usar los punteros persistentes del mismo modo que usan los punteros internesde la memoria en los lenguajes de programaci6n. Conceptualmente los punteros persistentes se puederconsiderar como punteros a objetos de la base de datos.9.8.3 Almacenamiento y acceso a los objetos persistentes2,Quesignifica guardar un objeto en una base de datos? Evidentemente, hay que guardar por separadcla parte de datos de cada objeto. L6gicamente, el c6digo que implementa los metodos de las clases debguardarse en la base de datos como parte de su esquema, junto con las definiciones de tipos de las clasesSin embargo, muchas implementaciones se limitan a guardar el c6digo en archivos externos a la base ddatos para evitar tener que integrar el software del sistema, como los compiladores, con el sistema dbases de datos.

Hay varias maneras de hallar los objetos de la base de datos. Una manera es dar nombres a los objetos, igual que se hace con los archivos. Este enfoque funciona con un numero de objetos relativamentepequeno, pero no result a practice para millones de objetos. Una segunda manera es exponer los identificadores de los objetos 0 los punteros persistentes a los objetos, que pueden guardarse en el exterior. _diferencia de los nombres, los punteros no tienen por que ser faciles de recordar y pueden ser, inclupunteros fisicos intern os de 10.base de datos.

Una tercera manera es guardar conjuntos de objetos y permitir que los programas iteren sobre eHOpara buscar los objetos deseados, Los conjuntos de objetos pueden a su vez modelarse como objetos dun t ip o conjunto . Entre los tipos de conjuntos estan los conjuntos, los multiconjuntos (es decir, conjuntoscon varias apariciones posibles de un mismo valor), las listas, etc. Un caso especial de conjunto so


19/30


las e xte ns io ne s d e c la se s, que son el conjunto de todos los objetos pertenecientes a una clase. Si hay unaextension de c1ase para Lmaclase dada, siempre que se crea un objeto de la clase ese objeto se insertaen la extension de clase de manera automatica: y, siempre que se borra un objeto, este se elimina dela extension de clase. Las extensiones de clases permiten que las clases se traten como relaciones en elsentido de que es posible examinar todos los objetos de una clase, igual que se pueden examinar todaslas tuplas de una relacion,

La mayor parte de los sistemas de bases de datos orientados a objetos soportan las tres maneras deacceso a los objetos persistentes. Dan identificadores a todos los objetos. Generalmente solo dan nombrea las extensiones de las clases y a otros objetos de tipo conjunto y, quizas, a otros objetos seleccionados,pero no a la mayor parte de los objetos. Las extensiones de las c1ases suelen conservarse para todas lasclases que puedan tener objetos persistentes pero, en muchas de las implementaciones, las extensionesde las clases solo contienen los objetos persistentes de cada clase.

9.8.4 Sistemas persistentes de c++En los ultimos afios han aparecido varias bases de datos orientadas a objetos basadas en las extensio-nes persistentes de C++ (veanse las notas bibliograficas). Hay diferencias entre ellas en terminos de laarquitectura de los sistemas pero tienen muchas caracteristicas comunes en terminos dellenguaje deprogramaci6n.

Varias de las caracterfsticas orientadas a objetos dellenguaje C++ ayudan a proporcionar un buensoporte para la persistencia sin modificar el propio lenguaje. Por ejemplo, se puede declarar una clasedenominada Persistent_Object (objeto persistente) con los atributos y los metodos para dar soportela persistencia; cualquier otra clase que deba ser persistente puede hacerse subclase de esta clase yheredara, por tanto, el soporte de la persistencia. Ellenguaje C++ (igual que otros lenguajes modernosde programacion) permite tambien redefinir los nombres de las funciones y los operadores estandar->-como +, -, el operador de desvinculacion de los punteros ->,etc.-en funcion del tipo de operandosa los que se aplican. Esta posibilidad se denomina sobrecarga; se usa para redefinir los operadores paraque se comporten de la manera deseada cuando operan con objetos persistentes.

Proporcionar apoyo a la persistencia mediante las bibliotecas de clases presenta la ventaja de quesolo se realizan cambios minimos en C++; ademas, resulta relativamente facil de implementar. Sin em-bargo, presenta el inconveniente de que los programadores tienen que usar mucho mas tiempo paraescribir los programas que trabajan con objetos persistentes y de que no les resulta sencillo especificarlas restricciones de integridad del esquema ni ofrecer soporte para las consultas declarativas. Algunasimplementaciones persistentes de C++ soportan extensiones de la sintaxis de C++ para facilitar estastareas.

Es necesario abordar los siguientes problemas a la hora de anadir soporte ala persistencia a C++ (ya otros lenguajes):

Punt eros persistentes. Se debe definir un nuevo tipo de datos para que represente los punterospersistentes. Por ejemplo, la norma ODMG de C++ define la clase de plantillas d_Rek T >para que represente los punteros persistentes a la clase T.El operador de desvinculacion paraesta clase se vuelve a definir para que capture el objeto del disco (si no se halla ya presente en lamemoria) y devuelva un puntero de la memoria al biller en el que se ha capturado el objeto. Portanto, si pes un puntero persistente a la clase T,se puede usar la sintaxis estandar como p->A 0p->f(v) para tener acceso al atributo A de la clase T 0 para invocar al metodo f de la clase T.El sistema de bases de datos ObjectStore usa un enfoque diferente de los punteros persistentes.Utiliza los tipos normales de punteros para almacenar los punteros persistentes. Esto plantea dosproblemas: (1) el tamafio de los punteros de la memoria solo puede ser de 4 bytes, demasiadopequeno para las bases de datos mayores de 4 gigabytes, y (2) cuando se pasa algun objeto aldisco los punteros de la memoria que sefialan a su antigua ubicacion ffsica carecen de significa-do. ObjectStore usa una tecnica denominada "rescate hardware" para abordar ambos problemas;precaptura los objetos de la base de datos en la memoria y sustituye los punteros persistentes porpunteros de memoria y, cuando se vuelven a almacenar los datos en el disco, los punteros de me-moria se sustituyen por punteros persistentes. Cuando se hallan en el disco, el valor almacenado


20/30

9. 8 Lenguajes de programaci6n persistentes 307

las e x ie ns io n es d e c la se s, que son el conjunto de todos los objetos pertenecientes a una clase. Si hay unaextensi6n de clase para una clase dada, siempre que se erea un objeto de la clase ese objeto se insertaen la extensi6n de clase de manera automatica: y, siempre que se borra un objeto, este se elimina dela extensi6n de clase. Las extensiones de clases permiten que las clases se traten como relaciones en elsentido de que es posible examinar todos los objetos de una clase, igual que se pueden examinar todaslas tuplas de una relaci6n.La mayor parte de los sistemas de bases de datos orientados a objetos soportan las tres maneras deacceso a los objetos persistentes. Dan identificadores a todos los objetos. Generalmente solo dan nombrea las extensiones de las clases y a otros objetos de tipo conjunto y, quizas, a otros objetos seleccionados,pero no a la mayor parte de los objetos. Las extensiones de las clases suelen conservarse para todas lasclases que puedan tener objetos persistentes pero, en muchas de las implementaciones, las extensionesde las clases s6lo contienen los objetos persistentes de cada clase.

9.8.4 Sistemas persistentes de c++En los ultimos afios han aparecido varias bases de datos orientadas a objetos basadas en las extensio-nes persistentes de C++ (veanse las notas bibliograficas), Hay diferencias entre ellas en terminos de laarquitectura de los sistemas pero tienen muchas caractertsticas comunes en terminos del lenguaje deprogramaci6n.Varias de las caractensticas orientadas a objetos dellenguaje C++ ayudan a proporcionar un buensoporte para la persistencia sin modificar el propio lenguaje. Por ejemplo, se puede declarar una clasedenominada Persistent_Object (objeto persistente) con los atributos y los metodos para dar soportela persistencia; cualquier otra clase que deba ser persistente puede hacerse subclase de esta clase yheredara, por tanto, el soporte de la persistencia. Ellenguaje C++ (igual que otros lenguajes modernosde programaci6n) permite tarnbien redefinir los nombres de las funciones y los operadores estandar-v-como +. -, el operador de desvinculaci6n de los punteros ->,etc.-en funci6n del tipo de operandosa los que se aplican. Esta posibilidad se denornina sobrecarga; se usa para redefinir los operadores paraque se comporten de la manera deseada cuando operan con objetos persistentes.

Proporcionar apoyo a la persistencia mediante las bibliotecas de clases presenta la ventaja de ques610 se realizan cambios minimos en C++; ademas, result a relativamente facil de implementar. Sin em-bargo, presenta el inconveniente de que los programadores tienen que usar mucho mas tiempo paraescribir los programas que trabajan con objetos persistentes y de que no les resulta sencillo especificarlas restricciones de integridad del esquema ni ofrecer soporte para las consultas declarativas. Algunasimplementaciones persistentes de C++ soportan extensiones de la sintaxis de C++ para facilitar estastareas.

Es necesario abordar los siguientes problemas a la hora de afiadir soporte a la persistencia a C++ (ya otros lenguajes):

Punteros persistentes. Se debe definir un nuevo tipo de datos para que represente los punterospersistentes. Por ejemplo, la norma ODMG de C++ define la clase de plantillas d_Rek T >para que represente los punteros persistentes a la clase T. El operador de desvinculaci6n paraesta clase se vuelve a definir para que capture el objeto del disco (si no se halla ya presente en lamemoria) y devuelva un puntero de la memoria al bufer en el que se ha capturado el objeto. Portanto, sip es un puntero persistente a la clase T,se puede usar 1asintaxis estandar como p->A 0p->f(v) para tener acceso al atributo A de la clase T 0para invocar al metodo f de la clase T.

El sistema de bases de datos ObjectStore usa un enfoque diferente de los punteros persistentes.Utiliza los tipos normales de punteros para almacenar los punteros persistentes. Esto plantea dosproblemas: ( 1 ) el tamafio de los punteros de la memoria solo puede ser de 4 bytes, demasiadopequeno para las bases de datos mayores de 4 gigabytes, y (2) cuando se pasa algun objeto aldisco los punteros de la memoria que sefialan a su antigua ubicaci6n ftsica carecen de significa-do. ObjectStore usa una tecnica denominada "rescate hardware" para abordar ambos problemas;precaptura los objetos de la base de datos en la memoria y sustituye los punteros persistentes porpunteros de memoria y, cuando se vuelven a almacenar los datos en el disco, los punteros de me-moria se sustituyen por punteros persistentes. Cuando se hallan en el disco, el valor almacenado


21/30


las e xt en si on e s d e c la se s, que son el conjunto de todos los objetos pertenecientes a una clase. Si hay unaextensi6n de clase para una clase dada, siempre que se crea un objeto de la clase ese objeto se insertaen la extensi6n de clase de manera automatica: y, siempre que se borra un objeto, este se elimina dela extensi6n de clase. Las extensiones de clases permiten que las clases se traten como relaciones en elsentido de que es posible examinar todos los objetos de una clase, igual que se pueden examinar todaslas tuplas de una relaci6n.

La mayor parte de los sistemas de bases de datos orientados a objetos soportan las tres maneras deacceso a los objetos persistentes. Dan identificadores a todos los objetos. Generalmente solo dan nombrea las extensiones de las clases y a otros objetos de tipo conjunto y, quizas, a otros objetos seleccionados,pero no a la mayor parte de los objetos. Las extensiones de las clases suelen conservarse para todas lasclases que puedan tener objetos persistentes pero, en muchas de las implementaciones, las extensionesde las clases s6lo contienen los objetos persistentes de cada clase.

9.8.4 Sistemas persistentes de c++En los ultimos afios han aparecido varias bases de datos orientadas a objetos basadas en las extensio-nes persistentes de C++ (veanse las notas bibliograficas). Hay diferencias entre ellas en terminos de laarquitectura de los sistemas pero tienen muchas caracteristicas comunes en terminos de1lenguaje deprogramaci6n.

Varias de las caracteristicas orientadas a objetos dellenguaje C++ ayudan a proporcionar un buensoporte para la persistencia sin modificar el propio lenguaje. Por ejemplo, se puede declarar una clasedenominada Persistent_Object (objeto persistente) con los atributos y los metodos para dar soportela persistencia; cualquier otra clase que deba ser persistente puede hacerse subclase de esta clase yheredara, por tanto, el soporte de la persistencia. E1lenguaje C++ (igua1que otros 1enguajes modernosde programaci6n) permite tambien redefinir los nombres de las funciones y los operadores estandar->como +, -, el operador de desvinculaci6n de los punteros ->,etc.-en funci6n del tipo de operandosa los que se aplican. Esta posibilidad se denomina sobrecarga; se usa para redefinir los operadores paraque se comporten de la manera deseada cuando operan con objetos persistentes.

Proporcionar apoyo a 1apersistencia mediante las bibliotecas de clases presenta 1a ventaja de ques6lo se realizan cambios mmimos en C++; ademas, resulta relativamente facil de implementar. Sin em-bargo, presenta e1inconveniente de que los programadores tienen que usar mucho mas tiempo paraescribir los programas que trabajan con objetos persistentes y de que no les resulta sencillo especificarlas restricciones de integridad del esquema ni ofrecer soporte para las consultas declarativas. A1gunasimplementaciones persistentes de C++ soportan extensiones de 1asintaxis de C++ para facilitar estastareas.

Es necesario abordar los siguientes problemas a la hora de anadir soporte a la persistencia a C++ (ya otros lenguajes):

Punteros persistentes. Se debe definir un nuevo tipo de datos para que represente los punterospersistentes. Por ejemplo, 1a norma ODMG de C++ define la clase de plantillas d_Rek T >para que represente los punteros persistentes a 1a clase T. EI operador de desvincu1aci6n paraesta clase se vuelve a definir para que capture el objeto del disco (si no se halla ya presente en lamemoria) y devuelva un puntero de la memoria al bufer en el que se ha capturado el objeto. Portanto, sip es un puntero persistente a la clase T,se puede usar la sintaxis estandar como p->A 0p->f(v) para tener acceso al atributo A de la clase T 0para invocar al metodo f de la clase T.El sistema de bases de datos ObjectStore usa un enfoque diferente de los punteros persistentes.Utiliza los tipos normales de punteros para almacenar los punteros persistentes. Esto p1antea dosproblemas: (1) e1tamafio de los punteros de la memoria s610 puede ser de 4 bytes, demasiadopequeno para las bases de datos mayores de 4 gigabytes, y (2) cuando se pasa algun objeto a1disco los punteros de la memoria que sefialan a su antigua ubicaci6n fisica carecen de significa-do. ObjectStore usa una tecnica denominada "rescate hardware" para abordar ambos problemas;precaptura los objetos de la base de datos en la memoria y sustituye los punteros persistentes porpunteros de memoria y, cuando se vuelven a almacenar los datos en el disco, los punteros de me-moria se sustituyen par punteros persistentes. Cuando se hallan en el disco, el valor a1macenado


22/30


en el campo de los punteros de memoria no es el puntero persistente real; en vez de eso, se buscael valor en una tabla para averiguar el valor completo del puntero persistente.

Creaci6n de objetos persistentes.El operador new de C++ se usa para crear objetos persistentesmediante la definici6n de una versi6n "sobrecargada" del operador que usa argumentos adicio-nales especificando que deben crearse en la base de datos. Por tanto, en lugar de new T O , hayque Hamar a new (bd) T O para crear un objeto persistente, donde bd identifica a la base de datos.

Extensiones de las dases. Las extensiones de las clases se crean y se mantienen de manera auto-rnatica para cada clase. La norma ODMG de C++ exige que el nombre de la clase se pase comoparametro adicional ala operacion new. Esto tarnbien permite mantener varias extensiones paracada clase, pasando diferentes nombres.

Re1aciones. Las relaciones entre las clases se suelen representar almacenando punteros de cadaobjeto a los objetos con los que esta relacionado. Los objetos relacionados con varios objetos deuna clase dada almacenan un conjunto de punteros. Por tanto, si un par de objetos se halla en unarelaci6n, cada uno de ellos debe almacenar un puntero al otro. Los sistemas persistentes de C+_ofrecen una manera de especificar esas restricciones de integridad y de hacer que se cumplanmediante la creaci6n y borrado automatico de los punteros. Por ejemplo, si se crea un puntero deun objeto a a un objeto b, se afiade de manera automatics un puntero a a al objeto b.

Interfaz iteradora. Dado que los programas tienen que iterar sobre los miembros de las dases,hace falta una interfaz para iterar sobre los miembros de las extensiones de las dases. La interfaziteradora tambien permite especificar selecciones, de modo que s6lo hay que capturar los objetosque satisfagan el predicado de selecci6n.

Transacciones. Los sistemas persistentes de C++ ofrecen soporte para comenzar las transaccio-nes y para comprometerlas 0provocar su retroceso.

Actualizaciones. Uno de los objetivos de ofrecer soporte a la persistencia a los lenguajes de pro-gramaci6n es permitir la persistencia transparente. Es decir, una funci6n que opere sobre unobjeto no debe necesitar saber que el objeto es persistente; por tanto, se pueden usar las mismasfunciones sobre los objetos independientemente de que sean persistentes 0no.

Sin embargo, surge el problema de que resulta dificil detectar cuando se ha actualizado unobjeto. Algunas extensiones persistentes de C++ exigian que el programador especificara demanera explfcita que se ha modificado el objeto llamando ala funci6n markrnodifiedf). Ademasde incrementar el esfuerzo del programador, este enfoque aumenta la posibilidad de que se pro-duzcan errores de programaci6n que den lugar a una base de datos corrupta. Si un programadoromite la llamada a rnark rnodltledt), es posible que nunca se propague a la base de datos la ac-tualizaci6n llevada a cabo por una transacci6n, mientras que otra actualizaci6n realizada por lamisma transacci6n S 1 se propaga, 10que viola la atomicidad de las transacciones.

Otros sistemas, como ObjectStore, usan soporte a la protecci6n de la memoria proporcionadapor el sistema operative 0por el hardware para detectar las operaciones de escritura en los blo-ques de memoria y marcar como sucios los bloques que se deban escribir posteriormente en eldisco.

Lenguaje de consultas. Los iteradores ofrecen soporte para consultas de selecci6n sencillas. Pa-ra soportar consultas mas complejas los sistemas persistentes de C++ definen un lenguaje deconsultas.

Gran numero de sistemas de bases de datos orientados a objetos basados en C++ se desarrollarona finales de los afios ochenta y principios de los noventa del siglo veinte. Sin embargo, el mercadopara esas bases de datos result6 mucho mas pequeno de 10 esperado, ya que la mayor parte de losrequisites de las aplicaciones se cumplen de sobra usando SQLmediante interfaces como onBC 0JDBC.En consecuencia, la mayor parte de los sistemas de bases de datos orientados a objetos desarrollados enese periodo ya no existen. En los anos noventa el Grupo de Gesti6n de Datos de Objetos (Object DataManagement Group, ODMG) defini6las normas para agregar persistencia a C++ y a Java. No obstante


23/30


el grupo concluyo sus actividades alrededor de 2002. ObjectStore y Versant son de los pocos sistemas debases de datos orientados a objetos originales que siguen existiendo.

Aunque los sistemas de bases de datos orientados a objetos no encontraron el exito comercial queesperaban, la razon de afiadir persistencia a los lenguajes de programacion sigue siendo valida, Hayvarias aplicaciones con grandes exigencias de rendimiento que se ejecutan en sistemas de bases de datosorientados a objetos; el uso de SQLimpondria W1asobrecarga de rendimiento excesiva para muchos deesos sistemas. Con los sistemas de bases de datos relacionales orientados a objetos que proporcionansoporte para los tipos de datos complejos, incluidas las referencias, resulta mas sencillo a1macenar losobjetos de los lenguajes de programacion en bases de datos de SQL. Todavta puede emerger una nuevagenera cion de sistemas de bases de datos orientadas a objetos que utilicen bases de datos re1aciona1esorientadas a objetos como sustrato.9.8.5 Sistemas Java persistentesEn aries recientes ellenguaje Java ha visto un enorme crecimiento en su uso. La demanda de soporte deJapersistencia de los datos en los programas de Java se ha incrementado de manera acorde. Los primerosintentos de creacion de una norma para la persistencia en Java fueron liderados por el consorcio ODMG;posteriormente, el consorcio concluyo sus esfuerzos, pero transfiri6 su disefio a1proyecto Objetos debases de datos de Java (Java Database Objects, JOO), que coord ina Sun Microsystems.

El modele JDO para 1apersistencia de los objetos en los programas de Java es diferente del modelo desoporte de la persistencia en los programas de C++. Entre sus caracteristicas se hallan:

Persistencia por alcance. Los objetos no se crean exp1icitamente en 1abase de datos. E1registroexplfcito de un objeto como persistente (usando el metodo makePersistentO de 1a clase Persis-tenceManager) hace que el objeto sea persistente. Ademas, cua1quier objeto alcanzab1e desde unobjeto persistente pasa a ser persistente.

Mejora del codigo de bytes. En 1ugar de dec1arar en e1codigo de Java que una clase es persisten-te, se especifican en un archivo de configuraci6n (con 1aextension .jdo) las clases cuyos objetos sepueden hacer persistentes. Se ejecuta un programa mejorador especffico de 1aimplementaci6n quelee e1archivo de configura cion y lleva a cabo dos tareas. En primer lugar, puede crear estructurasen la base de datos para almacenar objetos de esa clase. En segundo lugar, modifica e1codigode bytes (genera do a1compi1ar el programa de Java) para que maneje tareas relacionadas con Iapersistencia. A continua cion se ofrecen algunos ejemplos de modificaciones de este tipo.D Se puede modificar cualquier codigo que tenga acceso a un objeto para que compruebe pri-

mere si e1objeto se halla en la memoria y, si no esta, de los pasos necesarios para ponerlo enla memoria.o Cualquier c6digo que modifique un objeto se .modifica para que tambien registre el objetocomo modificado y, quizas, para que guarde un valor previo a Ia actualizaci6n que se usa encaso de que haga falta deshacerla (es decir, si se retrocede la transacci6n).

Tambien se pueden llevar a cabo otras modificaciones del c6digo de bytes. Esas modificacionesdel c6digo de bytes son posibles porque el c6digo de bytes es estandar en todas las plataformase inc1uye mucha mas informaci6n que el c6digo objeto compilado.

Asignacion de bases de datos. JDO no define la manera en que se almacenan los datos en labase de datos subyacente. Por ejemplo, una situaci6n frecuente es que los objetos se almacenenen una base de datos relacional. El programa mejorador puede crear en la base de datos unesquema adecuado para almacenar los objetos de las clases, La manera exacta en que 10 hacedepende de la imp1ementaci6n y no esta definida por JDO. Se pueden asignar algunos atributosa los atributos relacionales, mientras que otros se pueden almacenar de forma serializada, quela base de datos trata como si fuera un objeto binario. Las implementaciones de JDO puedenpermitir que los datos relacionales existentes se vean como objetos mediante la definicion de 1aasignacion correspondiente.

Extensiones de clase. Las extensiones de clase se crean y se conservan de manera automatica paracada clase declarada como persistente. Todos los objetos que se hacen persistentes se ana den


24/30


de manera automatica a la extensi6n de c1ase correspondiente a a su c1ase. Los program as deJDO pueden tener acceso a las extensiones de c1ase e iterar sobre los miembros seleccionados.La interfaz Iteradora ofrecida por Java se puede usar para crear iteradores sobre las extensionesde c1ase y avanzar por los miembros de cada extensi6n de c1ase. JDO tarnbien permite que seespecifiquen se1ecciones cuando se crea una extensi6n de c1ase y que s6lo se capturen los objetosque satisfagan la selecci6n .

Tipo de referencia unico. No hay diferencia de tipos entre las referencias a los objetos transitoriosy las referencias a los objetos persistentes.

Un enfoque para conseguir esta unificaci6n de los tipos de puntero es cargar toda la base dedatos en la memoria, 10que sustituye todos los punteros persistentes por punteros de memoria.Una vez llevadas a cabo las actualizaciones, el proceso se invierte y se vuelven a almacenar enel disco los objetos actualizados. Este enfoque es muy ineficiente para bases de datos de grantamafio.

A continuaci6n se describira un enfoque alternative, que permite que los objetos persistentesse capturen en memoria de manera automatica cuando hace falta, mientras que permite que todaslas referencias contenidas en objetos de la memoria sean referencias de la memoria. Cuando secaptura el objeto A, se crea un objeto hue co para cada objeto B, al que haga referencia, y la copiade la memoria de A tiene referencias al objeto hueco correspondiente para cada Bi, Por supuesto,el sistema tiene que asegurar que, si ya se ha capturado el objeto Bs, la referencia apunta al objetoya capturado en lugar de crear un nuevo objeto hueco. De manera parecida, si no se ha capturadoel objeto Bs, pero otro objeto ya capturado hace referencia a el, ya tiene un objeto hueco creadopara el: la referencia al objeto hueco ya existente se vuelve a usar, en lugar de crear un objetohueco nuevo.

Por tanto, para cada objeto O, que se haya capturado, cada referencia de O, es a un objetoya capturado 0 a un objeto hueco. Los objetos hue cos forman un borde que rodea los objetoscapturados.Siempre que el programa tiene acceso real al objeto hueco 0, el c6digo de bytes mejorado 10detecta y captura el objeto en la base de datos. Cuando se captura este objeto, se lleva a cabo elmismo proceso de creaci6n de objetos hue cos para todos los objetos a los que hace referencia.Tras esto, se permite que se lleve a cabo el acceso al objeto".

Para implementar este esquema hace falta una estructura de indices en la memoria que asignelos punteros persistentes a las referencias de la memoria. Cuando se vuelven a escribir los objetosen el disco se usa ese indice para sustituir las referencias de la memoria por punteros persistentesen la copia que se escribe en el disco.

La norma JDO se ha11atodavia en una etapa preliminar y sometida a revisi6n. Varias empresas ofrecenimplementaciones de JDO. No obstante, queda por ver si JDO se usara mucho, a diferencia de C++ deODMG.

9.9 Sistemas orientados a objetos y sistemasrelacionales orientados a objetos

Ya se han estudiado las bases de datos relacionales orientadas a objetos, que son bases de datos orien-tadas a objetos construidas sobre el mode1o relacional, asi como las bases de datos orientadas a objetos,que se crean alrededor de los lenguajes de programaci6n persistentes.3. La tecnica que usa objetos huecos descr ita anter iormente se halla estrechamente relacionada con la tecnica de rescate hardware(ya mencionada en el Apartado 9.8.4). El rescate hardware la usan algunas implernentaciones persistentes de C++ para ofrecerun solo t ipo de puntero para los punteros persistentes y los de memoria. EI rescate hardware utiliza tecnicas de proteccion de lamemor ia virtual proporcionadas por el sistema operativo para detectar el acceso a las paginas y captura las paginas de la base dedatos cuando es necesario. Por el contrario, la versi6n de Java modifica el c6digo de bytes para que compruebe la existencia deobjetos huecos en Jugar de usaf la protecci6n de la memoria y captura los objetos cuando hace falta, en vez de capturar paginasenteras de la base de da tos.


25/30

9.10 Resumen

Las exrerrsrortes persrsrenres de IosIenguajes de programaci6n y ros sistemas relacionales orientadosa objetos se dirigen a mercados diferentes. La naturaleza declarativa y la limitada potencia (compara .2.con la de los lenguajes de programaci6n) dellenguaje SQL proporcionan una buena protecci6n de 100.datos respecto de los errores de programaci6n y hacen que las optimizaciones de alto nivel, como .areducci6n de E/S, resulten relativamente sencillas. Los sistemas relacionales orientados a objetos 5 -Edirigen a simplificar la realizaci6n de los modelos de datos y de las consultas mediante el uso de tip sde datos complejos. Entre las aplicaciones habituales estan el almacenamiento y la consulta de datoscomplejos, incluidos los datos multimedia.

Los lenguajes declarativos como SQL, sin embargo, imponen una reducci6n significativa del rendi-rniento a ciertos tipos de aplicaciones que se ejecutan principalmente en la memoria principal y realizargran numero de accesos a la base de datos. Los lenguajes de programaci6n persistentes se dirigen a lasaplicaciones de este tipo que tienen necesidad de un rendimiento elevado. Proporcionan acceso a 105datos persistentes con poca sobrecarga y eliminan 1anecesidad de traducir los datos si hay que tratarloscon un lenguaje de programaci6n. Sin embargo, son mas susceptibles de deteriorar los datos debido alos errores de programad6n y no sue1en disponer de gran cap acid ad de consulta. Entre las aplicacioneshabituales estan las bases de datos de CAD.

Los puntos fuertes de los diversos tipos de siste

Documents

Capitulo 9-Bases de Datos Basadas en Objetos