Unidad 7 actividad 1 VISION GENERAL

En una base de datos orientada a objetos, la informacin se representa mediante objetos como los presentes en la programacin orientada a objetos. Cuando se integra las caractersticas de una base de datos con las de un lenguaje de programacin orientado a objetos, el resultado es un sistema gestor de base de datos orientada a objetos (ODBMS, object database management system). Un ODBMS hace que los objetos de la base de datos aparezcan como objetos de un lenguaje de programacin en uno o ms lenguajes de programacin a los que d soporte. Un ODBMS extiende los lenguajes con datos persistentes de forma transparente, control de concurrencia, recuperacin de datos, consultas asociativas y otras capacidades. Las bases de datos orientadas a objetos se disean para trabajar bien en conjuncin con lenguajes de programacin orientados a objetos como Java, C#, Visual Basic.NET y C++. Los ODBMS usan exactamente el mismo modelo que estos lenguajes de programacin. Los ODBMS son una buena eleccin para aquellos sistemas que necesitan un buen rendimiento en la manipulacin de tipos de dato complejos. Los ODBMS proporcionan los costes de desarrollo ms bajos y el mejor rendimiento cuando se usan objetos gracias a que almacenan objetos en disco y tienen una integracin transparente con el programa escrito en un lenguaje de programacin orientado a objetos, al almacenar exactamente el modelo de objeto usado a nivel aplicativo, lo que reduce los costes de desarrollo y mantenimiento. Los orgenes del trmino orientados a objetos (abreviado OO) se remontan a los lenguajes de programacin orientadas a objetos. Los lenguajes de programacin OO tienen sus races en el lenguaje SIMULA 67, propuesto a finales de la dcada de 1960. En Simula, el concepto de clase agrupa la estructura de datos interna de un objeto en una declaracin de clase, es decir, introduce en el lenguaje Algol los conceptos de objeto y de clase. Como Algol, Simula es un lenguaje fuertemente tipado para entornos compilados. Sin embargo, el primer lenguaje que populariz la aproximacin a objetos fue Smalltalk (1976); este puede considerarse una sntesis de aos del lenguaje Lisp, que ofrece una gran flexibilidad gracias a la interpretacin, y de Simula, aadiendo el concepto de metaclase. Smalltalk ha podido responder a las necesidades de flexibilidad presentadas por el desarrollo de entornos de programacin grficos, favoreciendo la rpida creacin de prototipos de interfaces de usuarios amigables. Fue utilizado con xito en la primera estacin grfica de Xerox.

Con la llegada de las estaciones de trabajo en los aos 80, han crecido numerosos lenguajes orientados a objetos inspirados en Simula o Smalltalk. Entre los lenguajes compilados, los ms celebres son C++, Objective C y Eiffel, debido a la compatibilidad del lenguaje o del cdigo producido con el lenguaje de programacin C. La mayor parte de los lenguajes interpretados son extensiones del Lisp; por ejemplo, Loops y CLOS. Es interesante notar que la mayor parte de los lenguajes populares existentes se encuentran en curso de ampliacin para convertirse en orientados a objetos, incluyendo al Cobol y Ada (ms exactamente Ada 9X, que aporta la herencia). En aos recientes, han aparecido muchos prototipos experimentales y sistemas de bases de datos comerciales orientados a objetos. Entre los primeros se encuentran los sistemas ORION, OpenOODB, IRIS, ODE y el proyecto ENCORE/ObServer. Y entre los sistemas disponibles en el mercado estn: GEMSTONE/OPAL de ServicLogic, ONTOS de Ontologic, Objectivity de Objectivity Inc., Versant de Versant Technologies, ObjecStore de Object Design y O2 de O2 Technology. Esta es solo una lista parcial de los prototipos experimentales y de los sistemas de bases de datos comerciales orientados a objetos. Desafortunadamente, es an demasiado pronto para saber cules sistemas se instalarn como lderes en este campo.

TIPOS DE DATOS COMPLEJOS

Estos son los tipos de datos que soporta el SQL. Los sinnimos son palabras equivalentes al tipo de dato indicado. El tamao indica cunto ocupar una columna del tipo indicado.

Tipo de dato
BINARY

Sinnimos
VARBINARY BINARY VARYING BIT VARYING

Tamao
1 byte por carcter

Descripcin
Se puede almacenar cualquier tipo de datos en un campo de este tipo. Los datos no se traducen (por ejemplo, a texto). La forma en que se introducen los datos en un campo binario indica cmo aparecern al mostrarlos. Valores S y No, y campos que contienen solamente uno de dos valores.

BIT

BOOLEAN LOGICAL LOGICAL1 YESNO INTEGER1 BYTE AUTOINCREMENT

1 byte

TINYINT

1 byte

Un nmero entero entre 0 y 255.

COUNTER

Se utiliza para campos contadores cuyo valor se incrementa automticamente al

MONEY

CURRENCY

8 bytes

DATETIME

DATE TIME GUID

8 bytes

crear un nuevo registro. Un nmero entero comprendido entre 922.337.203.685.477,5808 y 922.337.203.685.477,5807. Una valor de fecha u hora entre los aos 100 y 9999 Un nmero de identificacin nico utilizado con llamadas a procedimientos remotos. Un tipo de datos numrico exacto con valores comprendidos entre 1028 - 1 y 1028 - 1. Puede definir la precisin (1 28) y la escala (0 - precisin definida). La precisin y la escala predeterminadas son 18 y 0, respectivamente. Un valor de coma flotante de precisin simple con un intervalo comprendido entre 3,402823E38 y 1,401298E-45 para valores negativos, y desde 1,401298E-45 a 3,402823E38 para valores positivos, y 0. Un valor de coma flotante de precisin doble con un intervalo comprendido entre 1,79769313486232E308 y 4,94065645841247E-324 para valores negativos, y desde 4,94065645841247E324 a 1,79769313486232E308 para valores positivos, y 0. Un entero corto entre 32.768 y 32.767. Un entero largo entre 2.147.483.648 y 2.147.483.647.

UNIQUEIDENTIFIER

128 bits

DECIMAL

NUMERIC DEC

17 bytes

REAL

SINGLE FLOAT4 IEEESINGLE

4 bytes

FLOAT

DOUBLE FLOAT8 IEEEDOUBLE NUMBER

8 bytes

SMALLINT

SHORT INTEGER2 LONG INT INTEGER4 LONGBINARY GENERAL OLEOBJECT LONGTEXT LONGCHAR MEMO NOTE NTEXT TEXT(n) ALPHANUMERIC CHARACTER STRING VARCHAR CHARACTER VARYING NCHAR NATIONAL

2 bytes

INTEGER

4 bytes

IMAGE

Lo que se requiera

Desde cero hasta un mximo de 2.14 gigabytes. Se utiliza para objetos OLE. Desde cero hasta un mximo de 2.14 gigabytes.

TEXT

CHAR

2 bytes por carcter. (Consulte las notas). 2 bytes por carcter. (Consulte las notas).

Desde cero a 255 caracteres.

CHARACTER NATIONAL CHAR NATIONAL CHARACTER VARYING NATIONAL CHAR VARYING Un campo LONGTEXT se almacena siempre en el formato de representacin Unicode. Si se utiliza el nombre del tipo de datos TEXT sin especificar la longitud opcional (TEXT(25), por ejemplo), se crea un campo LONGTEXT. Esto permite escribir instrucciones CREATE TABLE que producirn tipos de datos coherentes con Microsoft SQL Server. Un campo CHAR se almacena siempre en el formato de representacin Unicode, que es el equivalente del tipo de datos NATIONAL CHAR del SQL de ANSI. Si se utiliza el nombre del tipo de datos TEXT y se especifica la longitud opcional (TEXT(25), por ejemplo), el tipo de datos del campo es equivalente al tipo de datos CHAR. De ese modo, se mantiene la compatibilidad con versiones anteriores para la mayora de las aplicaciones de Microsoft Jet, a la vez que se habilita el tipo de datos TEXT (sin especificacin de longitud) para la alineacin con Microsoft SQL Server. Los caracteres de los campos definidos como TEXT (tambin conocidos como MEMO) o CHAR (tambin conocidos como TEXT(n) con una longitud especfica) se almacenan en el formato de representacin Unicode. Los caracteres Unicode requieren siempre dos bytes para el almacenamiento de cada carcter. Para las bases de datos de Microsoft Jet ya existentes que contengan principalmente datos de tipo carcter, esto puede significar que el tamao del archivo de base de datos sea casi el doble cuando se convierta al formato Microsoft Jet 4.0. Sin embargo, la representacin Unicode de muchos juegos de caracteres, antes denominados juegos de caracteres de un solo byte (SBCS), puede comprimirse fcilmente a caracteres de un solo byte. Si define una columna CHAR con el atributo COMPRESSION, los datos se comprimirn automticamente a medida que se almacenen y se descomprimirn cuando se recuperen de la columna.

TIPOS ESTRUCTURADOS

Antes de SQL:1999 el sistema de tipos de SQL consista en un conjunto bastante sencillo de tipos predefinidos. SQL:1999 aadi un sistema de tipos extenso a SQL, lo que permite los tipos estructurados y la herencia de tipos.

Los tipos estructurados permiten representar directamente los atributos compuestos de los diagramas E-R. Por ejemplo, se puede definir el siguiente tipo estructurado para representar el atributo compuesto nombre con los atributos componentes nombre_pila y apellidos:

create type Nombre as (nombre_pila varchar(20), apellidos varchar(20)) final De manera parecida, el tipo estructurado siguiente puede usarse para representar el atributo compuesto direccin: create type Direccion as (calle varchar(20), ciudad varchar(20), codigo_postal varchar(9)) not final En SQL estos tipos se denominan tipos definidos por el usuario. Las especificaciones final indica que no se puede crear subtipos de nombre, mientras que la especificacin not final de direccin indica que se pueden crear subtipos de direccin. Ahora se pueden usar estos tipos para crear atributos compuestos en las relaciones, con slo declarar que un atributo es de uno de estos tipos. Por ejemplo, se puede crear una tabla cliente de la siguiente manera. create table cliente ( nombre Nombre, direccion Direccion, fecha_nacimiento date) O bien, realizando una estructura ms del tipo Cliente y generar la tabla a partir de ella: create type TipoCliente as (nombre Nombre, direccion Direccion, fecha_nacimiento date) not final

create table cliente of TipoCliente Se puede tener acceso a los componentes de los atributos compuestos usando la notacin punto; por ejemplo, nombre.nombre_pila devuelve el componente nombre de pila del atributo nombre. El acceso al atributo nombre devolvera un valor del tipo estructurado Nombre. La siguiente consulta ilustra la manera de tener acceso a los atributos componentes de los atributos compuestos. La consulta busca el apellido y la ciudad de cada cliente.

select nombre.apellido, direccion.ciudad from cliente En SQL:1999 se usan funciones constructoras para crear valores de los tipos estructurados. Las funciones con el mismo nombre que un tipo estructurado son funciones constructoras de ese tipo estructurado. Por ejemplo, se puede declarar una funcin constructora para el tipo Nombre de esta manera:

create functionNombre(nombre_pila varchar(20), apellidos varchar(20)) returns Nombre begin set self.nombre_pila = nombre_pila; set self.apellidos = apellidos; end De manera predeterminada, cada tipo estructurado tiene una funcin sin argumentos que configura los atributos con sus valores predeterminados. Cualquier otra funcin constructora hay que crearla de manera especfica. La instruccin siguiente ilustra la manera de crear una nueva tupla de la relacin Cliente. Se da por supuesto que se ha definido una funcin constructora para Direccion, igual que la funcin constructora que se defini para Nombre.

insert into Cliente values (new Nombre(Martn, Gmez), new Direccion(Calle Mayor 20, Madrid, 28045),

date 22-8-1960)

Herencia de tipos Supngase que se tiene la siguiente definicin de tipo para las personas:

create type Persona (nombre varchar(20), direccion varchar(20)) Puede que se desee almacenar en la base de datos informacin adicional sobre las personas que son estudiantes y sobre las que son profesores. Dado que los estudiantes y los profesores tambin son personas, se puede usar la herencia para definir en SQL los tipos estudiante y profesor: create typeEstudiante under Persona (grado varchar(20), departamento varchar(20)) create typeProfesor under Persona (sueldo Integer, departamento varchar(20)) Tanto Estudiante como Profesor heredan los atributos de Personas. Herencia de tablas Las subtablas de SQL se corresponden con el concepto de especializacin / generalizacin de E-R Por ejemplo, supngase que se define la tabla personas de la siguiente manera:

create tablepersonas of Persona

A continuacin se puede definir las tablas estudiantes y profesores como subtablas de personas, de la manera siguiente: create tableestudiantes of Estudiante under personas create tableprofesores of Profesor under personas Los tipos de las subtablas deben ser subtipos del tipo de la tabla madre. Por tanto, todos los atributos presentes en personas tambin estn presentes en las subtablas. Adems, cuando se declaran estudiantes y profesores como subtablas de personas, todas las tuplas presentes en estudiantes y profesores pasan a estar tambin presentes de manera implcita en personas. Por tanto, si una consulta usa la tabla personas, no slo encuentra tuplas directamente insertadas en esa tabla, sino tambin tuplas insertadas en sus subtablas, es decir, estudiantes y profesores. No obstante, esa consulta slo puede tener acceso a los atributos que estn presentes en personas. SQL permite hallar tuplas que se encuentran en personas pero no en sus subtablas usando en las consultas only personas en lugar de personas. La palabra clave only tambin puede usarse en las sentencias delete y update. Sin la palabra clave only, la instruccin delete aplicada a una supertabla, como personas, tambin borra las tuplas que se insertaron originalmente en las subtablas (como estudiantes); por ejemplo, la instruccin:

delete from personas where P Borrar todas las tuplas de la tabla personas, as como de sus subtablas estudiantes y profesores, que satisfagan P. Si se aade la palabra clave only a la instruccin anterior, las tuplas que se insertaron en las subtablas no se ven afectadas, aunque satisfagan las condiciones de la clusula where. SQL soporta dos tipos de conjuntos: arrays y multiconjuntos; los tipos array se aadieron en SQL:1999, mientras que los tipos multiconjuntos se agregaron en SQL:2003. Un multiconjunto es un conjunto no ordenado, en el que cada elemento puede aparecer varias veces. Supngase que se desea registrar informacin sobre libros, incluido un conjunto de palabras clave para cada libro. Supngase tambin que se deseara almacenar almacenar el nombre de los autores de un libro en forma de array; a diferencia de los elementos de los multiconjuntos, los elementos de los arrays estn ordenados, de

modo que se puede distinguir el primer autor del segundo autor, etc. El ejemplo siguiente ilustra la manera en que se puede definir en SQL estos atributos como arrays y como multiconjuntos. create type Editor as (nombre varchar(20), sucursal varchar(20)) create type Libro as (titulo varchar(20), array_autores varchar(20) array[10], fecha_publicacion date, editor Editor, conjunto_palabras_clave varchar(20) multiset) create table libros of Libro Creacin y acceso a los valores de los conjuntos En SQL:1999 se puede crear un array de valores de esta manera: array[Silberschartz, Korth, Sudarshan] De manera parecida, se puede crear un multiconjunto de palabras clave de la manera siguiente: multiset[Silberschartz, Korth, Sudarshan] Por lo tanto, se puede crear una tupla definido por la relacin libros como:

insert into libros values (Compiladores, array[Gmez, Santos], new Editor(McGraw-Hill, Nueva York), multiset[anlisis sintctico, anlisis]) Se puede tener acceso a los elementos del array o actualizarlos especificando el ndice del array, por ejemplo, array_autores[1]. Consulta de los atributos valorados como conjuntos Ahora se considerar la forma de manejar los atributos que se valoran como conjuntos. Las expresiones que se valoran como conjuntos pueden aparecer en

cualquier parte en la que pueda aparecer el nombre de una relacin, como las clusulas from. Si se desea averiguar todos los libros que contengan las palabras base de datos entre sus palabras clave, se puede usar la consulta siguiente: select titulo form libros where base de datos in (unnest(conjunto_palabras_clave)) Identidad de los objetos y tipos de referencia en SQL Los lenguajes orientados a objetos ofrecen la posibilidad de hacer referencia a objetos. Los atributos de un tipo dado pueden servir de referencia para los objetos de un tipo concreto. Por ejemplo, en SQL se puede definir el tipo Departamento con el campo nombre y el campo director, que es una referencia al tipo Persona, y la tabla departamentos del tipo Departamento, de la manera siguiente:

create type Departamento( nombre varchar(20), director ref(Persona) scope personas) create table departamentos of Departamento En este caso, la referencia est restringida a las tuplas de la tabla personas. La restriccin del mbito de referencia a las tuplas de una tabla es obligatoria en SQL, y hace que las referencias se comporten como las claves externas. La tabla a la que hace referencia debe tener un atributo que guarde el identificador para cada tupla. Ese atributo, denominado atributo autorreferenciable (self-referential attribute), se declara aadiendo una clusula ref is a la instruccin create table:

create table personas of Persona ref is id_persona system generated En este caso, id_persona es el nombre del atributo, no una palabra clave, y la instruccin system generated especifica que la base de datos genera de manera automtica el identificador.

Para inicializar el atributo de referencia hay que obtener el identificador de la tupla a la que se va a hacer referencia. Se puede conseguir el valor del identificador de la tupla mediante una consulta. Por tanto, para crear una tupla con el valor de referencia, primero se puede crear la tupla con una referencia nula y luego definir la referencia de manera independiente: insert into departamentos values (CS, null) update departamentos set director = (select p.id_persona from persona as p where nombre = Martn) where nombre = CS Una alternativa a los identificadores generados por el sistema es permitir que los usuarios generen los identificadores. El tipo del atributo autoreferencial debe especificarse como parte de la definicin de tipos de la tabla a la que se hace referencia, y la definicin de la tabla debe especificar que la referencia est generada por el usuario (user generated): create type Persona (nombre varchar(20), direccion varchar(20)) ref using varchar(20) create table personas of Persona ref is id_persona user generated Al insertar tuplas en personas hay que proporcionar el valor del identificador: insert intopersonas (id_persona, nombre, direccion) values (01284567, Martn, Av del Segura, 23) Implementacin de las caractersticas O-R Los sistemas de bases de datos relacionales orientadas a objetos son bsicamente extensiones de los sistemas de bases de datos relacionales ya existentes. Las modificaciones resultan claramente necesarias en muchos niveles del sistema de base de datos. Las interfaces de programas de aplicacin como ODBC y JDBC se han extendido para recuperar y almacenar tipos estructurados; por ejemplo, JDBC ofrece el mtodo getObject() que devuelve un objeto Java Struct, a partir del cual se pueden extraer los componentes del tipo estructurado. Tambin es posible asociar clases de Java con

tipos estructurados de SQL, y JDCB puede realizar conversiones entre los tipos. Lenguajes de programacin persistentes Los lenguajes de las bases de datos se diferencian de los lenguajes de programacin tradicionales en que trabajan directamente con datos que son persistentes; es decir, los datos siguen existiendo una vez que el programa que los cre haya concluido. Las relaciones de las bases de datos y las tuplas de las relaciones son ejemplos de datos persistentes. El acceso a las bases de datos es slo un componente de las aplicaciones del mundo real. Mientras que los lenguajes para el tratamiento de datos como SQL son bastante efectivos en el acceso a los datos, se necesita un lenguaje de programacin para implementar otros componentes de las aplicaciones como las interfaces de usuario o la comunicacin con otras computadoras. La manera tradicional de realizar las interfaces de las bases de datos con los lenguajes de programacin es incorporar SQL dentro del lenguaje de programacin. Los lenguajes de programacin persistentes son lenguajes de programacin extendidos con estructuras para el tratamiento de los datos persistentes. Los lenguajes de programacin persistentes pueden distinguirse de los lenguajes con SQL incorporado, al menos, de dos maneras: En los lenguajes incorporados el sistema de tipos del lenguaje anfitrin suele ser diferente del sistema de tipos del lenguaje para el tratamiento de los datos. Los programadores son responsables de las conversiones de tipo entre el lenguaje anfitrin y SQL. Hacer que los programadores lleven a cabo esta tarea presenta varios inconvenientes: El cdigo para la conversin entre objetos y tuplas opera fuera del sistema de tipos orientado a objetos y, por lo tanto, tiene ms posibilidades de presentar errores no detectados. La conversin en la base de datos entre el formato orientado a objetos y el formato relacional de las tuplas necesita gran cantidad de cdigo. El cdigo para la conversin de formatos, junto con el cdigo para cargar y descargar datos de la base de datos, puede suponer un porcentaje significativo del cdigo total necesario para la aplicacin. Por el contrario, en los lenguajes de programacin persistentes, el lenguaje de consultas se halla totalmente integrado con el lenguaje anfitrin y ambos comparten el mismo sistema de tipos. Los objetos se pueden crear y guardar en la base de datos sin ninguna modificacin explcita del tipo o del formato; los cambios de formato necesarios se realizan de manera transparente.

Los programadores que usan lenguajes de consultas incorporados son responsables de la escritura de cdigo explcito para la bsqueda en la memoria de los datos de la base de datos. Si se realizan actualizaciones, los programadores deben escribir explcitamente cdigo para volver a guardar los datos actualizados en la base de datos. Por el contrario, en los lenguajes de programacin persistentes, los programadores pueden trabajar con datos persistentes sin tener que escribir explcitamente cdigo para buscarlos en la memoria o volver a guardarlos en el disco. Sin embargo, los lenguajes de programacin persistentes presentan ciertos inconvenientes que hay que tener presentes al decidir su conviene usarlos. Dado que los lenguajes de programacin suelen ser potentes, resulta relativamente sencillo cometer errores de programacin que daen las bases de datos. La complejidad de los lenguajes hace que la optimizacin automtica de alto nivel, como la reduccin de E/S de disco, resulte ms difcil. En muchas aplicaciones el soporte de las consultas declarativas resulta de gran importancia, pero los lenguajes de programacin persistentes no soportan bien actualmente las consultas declarativas (SQL es un ejemplo). Persistencia de objetos Los lenguajes de programacin orientados a objetos ya poseen un concepto de objeto, un sistema de tipos para definir los tipos de los objetos y constructores para crearlos. Sin embargo, esos objetos son transitorios; desaparecen en cuanto finaliza el programa, igual que ocurre con las variables de los programas en C o Pascal. Si se desea transformar uno de estos lenguajes en un lenguaje para la programacin de base de datos, el primer paso consiste en proporcionar una manera de hacer persistentes los objetos. Se han propuesto varios enfoques. Persistencia por clases. El enfoque ms sencillo, pero el menos conveniente, consiste en declarar que una clase es persistente. Todos los objetos de la clase lo son, por tanto, persistentes de manera predeterminada. Persistencia por creacin. En este enfoque se introducen una sintaxis nueva para crear los objetos persistentes mediante la extensin de la sintaxis nueva para la creacin de los objetos transitorios. Por tanto, los objetos son persistentes o transitorios en funcin de la forma de crearlos. Varios sistemas de bases de datos orientados a objetos siguen este enfoque. Persistencia por marcas. Una variante del enfoque anterior es marcar los objetos como persistentes despus de haberlos creado. Todos los objetos se crean como transitorios pero, si un objeto tiene que persistir ms all de la ejecucin del programa, hay que marcarlo como persistente de manera explcita antes de que ste concluya.

Persistencia por alcance. Uno o varios objetos se declaran objetos persistentes (objetos raz) de manera explcita. Todos los dems objetos sern persistentes si (y slo s) se pueden alcanzar desde algn objeto raz mediante una secuencia de una o varias referencias. Por tanto, todos los objetos a los que se haga referencia desde (es decir, cuyos identificadores de objetos se guarden en) los objetos persistentes raz sern persistentes. Pero tambin lo sern todos los objetos a los que se haga referencia desde ellos, y los objetos a los que stos ltimos hagan referencia sern tambin persistentes, etc. Una ventaja de este esquema es que resulta sencillo hacer que sean persistentes estructuras de datos complejas con slo declarar como persistente su raz. Sin embargo, el sistema de base de datos sufre la carga de tener que seguir las cadenas de referencias para detectar los objetos que son persistentes, y eso puede resultar costoso.

Sistemas Java persistentes En aos recientes el lenguaje Java ha visto un enorme crecimiento en su uso. La demanda de soporte de la persistencia de los datos en los programas de Java se incrementado de manera acorde. Los primeros intentos de creacin de una norma para la persistencia en Java fueron liderados por el consorcio ODMG; posteriormente, el consorcio concluy su esfuerzo, pero transfiri su diseo al proyecto Java Database Object (JDO), que coordibaba Sun Microsystems. Entre sus caractersticas se hallan: Persistencia por alcance. Los objetos no se crean explcitamente en la base de datos. El registro explcito de un objeto como persistencia hace que el objeto sea persistente. Adems, cualquier objeto alcanzable desde un objeto persistente pasa a ser persistente. Mejora del cdigo de bytes. En lugar de declarar en el cdigo Java que una clase es persistente, se especifica en un archivo de configuracin (con terminacin .jdo) las clases cuyos objetos se pueden hacer persistentes. Se ejecuta un programa mejorador especfico de la implementacin que lee el archivo de configuracin y lleva a cabo dos tareas. En primer lugar, puede crear estructuras en la base de datos para almacenar objetos de esa clase. En segundo lugar, modifica el cdigo de bytes (generado al compilar el cdigo Java) para que maneje tareas relacionadas con la persistencia. Asignacin de base de datos. JDO no define la manera en que se almacenan los datos en la base de da datos subyacente. Por ejemplo, una situacin frecuente es que los objetos se almacenen en una base de datos relacional. Por ejemplo, una situacin

frecuente es que los objetos se almacenen en una base de datos relacional. El programa mejorador puede crear en la base de datos un esquema adecuado para almacenar los objetos de las clases. La manera exacta en que lo hace depende de la implementacin y no est definida por JDO. Se puede asignar algunos atributos a los atributos relacionales, mientras que otros se pueden almacenar de forma serializada, que la base de datos trata como si fuera un objeto binario. Las implementaciones de JDO pueden permitir que los datos relacionales existentes se vean como objetos mediante la definicin de la asignacin correspondiente. Extensiones de clase. Las extensiones de clase se crear y se conservan de manera automtica para cada clase declarada como persistente. Todos los objetos que se hacen persistentes se aaden de manera automtica a la extensin de clase correspondiente a su clase. Los programas de JDO pueden tener acceso a las extensiones de clase e iterar sobre los miembros seleccionados. La interfaz iteradora ofrecida por Java se puede usar para crear iteradores sobre las extensiones de clase y avanzar por los miembros de cada extensin de clase. JDO tambin permiten que se especifiquen selecciones cuando se crea una extensin de clase y que slo se capturen los objetos que satisfagan la seleccin. La norma JDO se halla todava en una etapa preliminar y sometida a revisin. Varias empresas ofrecen implementaciones de JDO. Sistemas orientados a objetos y sistemas relacionales orientados a objetos Las extensiones persistentes de los lenguajes de programacin y los sistemas relacionales orientados a objetos se dirigen a mercados diferentes. La naturaleza declarativa y limitada potencia (comparada con la de los lenguajes de programacin) del lenguaje SQL proporcionan una buena proteccin de los datos respecto de los errores de programacin y hacen que las optimizaciones de alto nivel, como la reduccin E/S resulte relativamente sencilla. Los sistemas relacionales orientados a objetos se dirigen a simplificar la realizacin de los modelos de datos y de las consultas mediante el uso de tipos de datos complejos. Entre las aplicaciones habituales estn el almacenamiento y la consulta de datos complejos, incluidos los datos multimedia. Los lenguajes declarativos como SQL, sin embargo, imponen una reduccin significativa del rendimiento a ciertos tipos de aplicaciones que se ejecutan principalmente en memoria principal y realizan gran nmero de accesos a la base de datos. Los lenguajes de programacin persistentes se dirigen a las aplicaciones de este tipo que tienen necesidad de un rendimiento elevado. Proporcionan acceso a los datos persistentes con poca sobrecarga y eliminan la necesidad de traducir los datos si hay que tratarlos con un lenguaje de programacin. Sin embargo, son ms susceptibles a deteriorar los datos debido a los errores de programacin y no suelen disponer de gran

capacidad de consulta. Entre las aplicaciones habituales estn las bases de datos de CAD (Diseo asistido por computadora). Los puntos fuertes de los diversos tipos de sistemas de bases de datos pueden resumirse de la manera siguiente: Sistemas relacionales: tipos de datos sencillos, lenguajes de consultas potentes, proteccin elevada. Bases de datos orientadas a objetos basadas en lenguajes de programacin persistentes: tipos de datos complejos, integracin con los lenguajes de programacin, elevado rendimiento. Sistemas relacionales orientados a objetos: tipos de datos complejos, lenguajes de consultas potentes, proteccin elevada.

Estas descripciones son vlidas en general, pero hay que tener en cuenta que algunos sistemas de bases de datos no respetan estas fronteras. Por ejemplo, algunos sistemas de base de datos orientados a objetos construidos alrededor de lenguajes de programacin persistentes se pueden implementar sobre sistemas de bases de datos relacionales o sobre sistemas de bases de datos relacionales orientados a objetos. Puede que estos sistemas proporcionen menor rendimiento que los sistemas de bases de datos orientados a objetos construidos directamente sobre los sistemas de almacenamiento, pero proporcionan parte de las garantas de proteccin ms estrictas propias de los sistemas relacionales.

HERENCIA DE TABLAS
Herencia La herencia puede hallarse en el nivel de los tipos o en el nivel de las tablas. En primer lugar se considerara la herencia de los tipos y despus en el nivel de las tablas.

Cada tabla almacena todos los atributos heredados y denidos localmente. Cuando se inserta una tupla se almacena solo en la subtabla en la que se inserta y su presencia se inere en cada supertabla. El acceso a todos los atributos de una tupla es ms rpido, dado que no Ejemplo de herencia Supngase que se tiene la siguiente definicin de tipo para las personas: create type Persona (nombre varchar(20), direccion varchar(20)) Puede que se desee almacenar en la base de datos informacin adicional sobre las personas que son estudiantes y sobre las que son profesores. Dado que los estudiantes y los profesores tambin son personas, se puede usar la herencia para definir en SQL los tipos estudiante y profesor: create type Estudiante under Persona (grado varchar(20), departamento varchar(20)) create type Profesor under Persona (sueldo Integer, departamento varchar(20)) se requiere una reunin.

Otro ejemplo Primer Mtodo: Herencia de Tabla nica (Single Table Inheritance) Una Tabla guarda todos los datos y se define una variable de Tipo.

Segundo Mtodo: Herencia de Tablas Concretas (Concrete Table Inheritance) Cada Clase utilizable se define en una tabla independiente con todas sus propiedades heredadas. Tercer Mtodo: Herencia de Tablas de Clases (Class Table Inheritance) Se define una tabla para cada clase y no se incluyen sus propiedades heredadas. Conclusin A lo que se refiere a la herencia de registros atreves de tablas tenemos que tener una tabla que se le denomina type (tipos) al que se le van a pasar los registros de otras tablas o subtablas. Para comprender ste concepto muy interesante y til para muchos casos veremos un ejemplo bastante sencillo. Crearemos una tabla llamada ciudades y otras capitales. Las capitales son tambin ciudades pero supongamos que necesitamos recuperar rpidamente los datos de las ciudades, sin pasar por un ndice de tabla que contiene miles o millones de registros. Esa es la mayor virtud a mi punto de vista de las tablas heredades, si la usamos en los contextos correctos podramos mejorar el rendimiento de una BD altamente concurrida que comience importantes en el tiempo de lectura/escritura. Comenzaremos creando la tabla padre con 3 campos CREATE TABLE ciudades ( nombre poblacion altura ); Ya tenemos el padre, podemos crear un hijo a partir de l. Adems le agregaremos 1 columna ms que nos dir a que departamento o estado pertenece sa capital. CREATE TABLE capitales ( departamento ) INHERITS (ciudades); Procedemos a insertar los datos en las respectivas tablas insert into ciudades values ('Fernando de la Mora', 24522, 25); insert into ciudades values ('Lambar', 34500, 135); insert into ciudades values ('San Lorenzo', 16852, 120); insert into capitales values ('Asuncion', 450000, 136, 'CN'); insert char(2) text, float, int a sufrir de bloqueos y retrasos

into capitales values ('Encarnacion', 128000, 120, 'EN'); Seleccionando las tablas veremos los resultados y el comportamiento obtenido. El primer query retornar el siguiente conjunto de resultados. "Fernando de la Mora";24522;25 "Lambar";34500;135 "San Lorenzo";16852;120 "Asuncion";450000;136 "Encarnacion";128000;120 Obteniendo los siguiente con el segundo query "Asuncion";450000;136;"CN" "Encarnacion";128000;120;"EN" Con esto obtenemos una reduccin en la construccin del ndice y ganaremos velocidad con ello adems de un mejor orden conceptual de nuestras tablas. No slo se puede heredar de un padre, es posible heredar de varias tablas, as teniendo la tabla hija todas las columnas de sus padres, y en caso que 2 o ms padres tengan un columna con el mismo nombre stas se fusionarn en la hija siempre y cuando sean del mismo tipo de dato. Al utilizar sta poderosa caracterstica existen algunas consideraciones que hay que tener en cuenta para evitarnos sorpresas desagradables e inesperadas. Al crear tablas heredadas, no todas las caractersticas de la tabla se heredan. Por ejemplo, las claves primarias, forneas, indices nicos. Segn el roadmap se ver para implementarlo a futuro pero no es de prioridad alta por eso que viene retrasndose su implementacin desde versiones antiguas.

TIPOS DE ARREGLOS

SQL soporta dos tipos de conjuntos: arrays y multiconjuntos. Multiconjuntos es un conjunto no ordenado, en el que cada elemento puede aparecer varias veces. A diferencia de los elementos de los multiconjuntos, los elementos de los arrays estn ordenados Por ejemplo se ilustra la manera en que se pueden definir en SQL, estos atributos valorados con arrays y multiconjuntos. create type Editor as (nombre varchar(20) sucursal vachar(20) create type Libro as (titulo vachar (20), array_autores vachar (20) array[10], fecha_publicacion date, editor Editor, conjunto_palabras_clave

varchar(20) multiset) create table Los atributos multivalorados de los esquemas E-R se pueden asignar en SQL atributos valorados como multiconjuntos si el orden es importante se pueden usar los arrays de SQL en lugar de los multiconjuntos. Creacin y acceso a los valores de los conjuntos 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] Consulta de los atributos valorados como conjuntos Ahora se considerara la forma de manejar los atributos que se valoran como conjuntos. Las expresiones que se valoran como conjuntos pueden aparecer en cualquier parte en la que pueda aparecer el nombre de una relacin, como las clausulas FROM. Al desanidar un arrays la consulta anterior pierde informacin sobre el orden de los elementos de consulta. Se pueden usar las clausulas UNESTED WITH ORDINALITY para obtener esta informacin. La clausulas WITH ORDINALITY genera un atributo adicional que se registra la posicin del elemento en el arrays. Se puede usra una consulta parecida. Pero sin la clausula WITH ORDINALITY, para generar la relacin. Anidamiento y desanidamiento La transformacin de una relacin anidada en una forma con menos atributos de tipos relacin (o sin ellos) se denomina desanidamiento.

IDENTIDAD DE LOS OBJETOS

Los lenguajes orientados a objetos ofrecen la posibilidad de hacer referencia a objetos. Los atributos de un tipo dado pueden servir de referencia para los objetos de un tipo concreto. Por ejemplo, en SQL se puede definir el tipo Departamento con el campo nombre y el campo director, que es una referencia al tipo Persona, y la tabla departamentos del tipo Departamento, de la manera siguiente: create type Departamento( nombre varchar(20), director ref(Persona) scope personas) create table departamentos of Departamento En este caso, la referencia est restringida a las tuplas de la tabla personas. La restriccin del mbito de referencia a las tuplas de una tabla es obligatoria en SQL, y hace que las referencias se comporten como las claves externas. La tabla a la que hace referencia debe tener un atributo que guarde el identificador para cada tupla. Ese atributo, denominado atributo autorreferenciable (self-referential attribute), se declara aadiendo una clusula ref is a la instruccin create table:

create table personas of Persona ref is id_persona system generated En este caso, id_persona es el nombre del atributo, no una palabra clave, y la instruccin system generated especifica que la base de datos genera de manera automtica el identificador. Para inicializar el atributo de referencia hay que obtener el identificador de la tupla a la que se va a hacer referencia. Se puede conseguir el valor del identificador de la tupla mediante una consulta. Por tanto, para crear una tupla con el valor de referencia, primero se puede crear la tupla con una referencia nula y luego definir la referencia de manera independiente: insert into departamentos values (CS, null) update departamentos set director = (select p.id_persona from persona as p where nombre = Martn) where nombre = CS Una alternativa a los identificadores generados por el sistema es permitir que los usuarios generen los identificadores. El tipo del atributo autoreferencial debe especificarse como parte de la definicin de tipos de la tabla a la que se hace referencia, y la definicin de la tabla debe especificar que la referencia est generada por el usuario (user generated): create type Persona (nombre varchar(20), direccion varchar(20)) ref using varchar(20) create table personas of Persona ref is id_persona user generated Al insertar tuplas en personas hay que proporcionar el valor del identificador: insert into personas (id_persona, nombre, direccion) values (01284567, Martn, Av del Segura, 23)

IMPLEMENTACION DE LAS CARACTWEISTICAS

Los sistemas de bases de datos relacionales orientadas a objetos son bsicamente extensiones de los sistemas de bases de datos relacionales ya existentes. Las modificaciones resultan claramente necesarias en muchos niveles del sistema de base de datos. Las interfaces de programas de aplicacin como ODBC y JDBC se han extendido para recuperar y almacenar tipos estructurados; por ejemplo, JDBC ofrece el mtodo getObject() que devuelve un objeto Java Struct, a partir del cual se pueden extraer los componentes del tipo estructurado. Tambin es posible asociar clases de Java con tipos estructurados de SQL, y JDCB puede realizar conversiones entre los tipos. La orientacin a objetos constituye una nueva forma de pensar acerca de problemas empleando modelos que se han organizado tomando como base conceptos del mundo real. Los modelos orientados a objetos son tiles para comprender problemas, comunicarse con expertos en esa aplicacin, modelar empresas, preparar documentacin y disear programas y bases de datos. El beneficio principal no es un tiempo de desarrollo ms reducido, el desarrollo orientado a objetos puede requerir ms tiempo que el desarrollo convencional porque se pretende que promueva la reutilizacin futura y la reduccin de los posteriores errores y el futuro mantenimiento. Las bases de datos orientadas a objetos unen dos tecnologas: La de las bases de datos y la de los lenguajes orientados a objetos. Los LPOO aportan gran capacidad en la manipulacin de datos, pero no implementan el almacenamiento y consulta de grandes volmenes de datos. Por el contrario, las bases de datos convencionales aportan un dominio de las tcnicas de almacenamiento y consulta de grandes volmenes de datos, aunque su capacidad de manipulacin es limitada. Las bases de datos orientadas a objetos pretenden unir la capacidad de manipulacin de datos de los LPOO con la capacidad de almacenamiento y consulta de los SGBD.

Desventajas de la BDOO La inmadurez del mercado de BDOO constituye una posible fuente de problemas por lo que debe analizarse con detalle la presencia en el mercado del proveedor para adoptar una lnea de produccin sustantiva. Es la falta de estndar en la industria orientado a objetos.