Introduccin: En una primera aproximacin, se puede decir que una base de datos es un conjunto de informacin relacionada que se encuentra

agrupada o estructurada. Desde el punto de vista informtico, una base de datos es un sistema formado por un conjunto de datos almacenados en discos que permiten el acceso directo a ellos y un conjunto de programas que manipulan ese conjunto de datos. Por su parte, un sistema de Gestin de Bases de datos es un tipo de software muy especfico dedicado a servir de interfaz entre la base de datos, el usuario y las aplicaciones que la utilizan; o lo que es lo mismo, una agrupacin de programas que sirven para definir, construir y manipular una base de datos, permitiendo as almacenar y posteriormente acceder a los datos de forma rpida y estructurada. Una base de datos orientada a objetos es una base de datos en donde los elementos son objetos. Estos pueden ser datos multimedia es decir estar compuestos por videos, imgenes y sonidos, donde es posible aplicar propiedades de la OO como la herencia que nos permita una mejor representacin de la informacin. El objetivo de una base de datos orientada a objetos son los mismos que los de las bases de datos tradicionales, pero con la ventaja de representar los modelos de datos con un marco mucho ms eficiente, manteniendo la integridad y relacin entre ellos. Estas bases tienen las caractersticas de todo lo que es orientado a objeto que son Herencia, Polimorfismo, Abstraccin y Encapsulamiento. Un objeto puede heredar comportamiento de otro tipo de objetos (herencia) y puede adaptarse para responder de diferentes maneras ante la solicitud de una accin (polimorfismo), lo importante es que permite representar

cosas de la vida real con relativa facilidad (abstraccin) y que todo esto se puede implementar de manera que no nos importe el cdigo, sino slo la manera de comunicarnos con estos objetos pensando en ellos como una sola unidad (encapsulamiento). La utilizacin de una BDOO simplifica la conceptualizacin ya que la utilizacin de objetos permite representar de una manera ms natural la informacin que se quiere guardar. Mientras que las bases de datos relacionales (tradicionales), almacenan los datos en forma de tablas renglones y columnas. De tal manera las bases de datos relacionales no son adecuadas para almacenar objetos, ya que pueden contener estructuras complejas de elementos de datos y tambin apuntadores a otros objetos. Adems los objetos incluyen instrucciones ejecutables o mtodos y para hacer persistentes a los objetos tambin deben proporcionar ciertos medios para almacenarlos.

Un poco de Historia: Los orgenes de las bases de datos se remontan a la Antigedad donde ya existan bibliotecas y toda clase de registros. Adems tambin se utilizaban para recoger informacin sobre las cosechas y censos. Sin embargo, su bsqueda era lenta y poco eficaz y no se contaba con la ayuda de mquinas que pudiesen reemplazar el trabajo manual. Posteriormente, el uso de las bases de datos se desarroll a partir de las necesidades de almacenar grandes cantidades de informacin o datos. Sobre todo, desde la aparicin de las primeras computadoras, el concepto de bases de datos ha estado siempre ligado a la informtica. En la dcada de los cincuenta se da origen a las cintas magnticas, para automatizar la informacin y hacer respaldos. Esto sirvi para suplir las necesidades de informacin de las nuevas industrias. Y a travs de este mecanismo se empezaron a automatizar informacin, con la desventaja de que solo se poda hacer de forma secuencial. En la dcada de los 60 se dio inicio a las primeras generaciones de bases de datos de red y las bases de datos jerrquicas, ya que era posible guardar estructuras de datos en listas y arboles. Otro de los principales logros de los aos sesenta fue la alianza de IBM y American Airlines para desarrollar SABRE, un sistema operativo que manejaba las reservas de vuelos, transacciones e informaciones sobre los pasajeros de la compaa American Airlines. Tambien se llevo a cabo el desarrollo del IDS desarrollado por Charles Bachman ( que formaba parte de la CODASYL) supuso la creacin de un nuevo tipo de sistema de bases de datos conocido como

modelo en red, que permiti la creacin de un standard en los sistemas de bases de datos gracias a la creacin de nuevos lenguajes de sistemas de informacin. CODASYL (Conference on Data Systems Languages) era un consorcio de industrias informticas que tenan como objetivo la regularizacin de un lenguaje de programacin estndar que pudiera ser utilizado en multitud de ordenadores. En la dcada de los setenta, Edgar Frank Codd, cientfico informtico ingles conocido por sus aportaciones a la teora de bases de datos relacionales, defini el modelo relacional a la par que public una serie de reglas para los sistemas de datos relacionales a travs de su artculo Un modelo relacional de datos para grandes bancos de datos compartidos. Este hecho dio paso al nacimiento de la segunda generacin de los Sistemas Gestores de Bases de Datos. Como consecuencia de esto, durante la dcada de 1970, Lawrence J. Ellison, ms conocido como Larry Ellison, a partir del trabajo de Edgar F. Codd sobre los sistemas de bases de datos relacionales, desarroll el Relational Software System, lo que actualmente se conoce como Oracle Corporation, desarrollando as un sistema de gestin de bases de datos relacional con el mismo nombre que dicha compaa. Posteriormente en la poca de los ochenta tambin se desarrollar el SQL (Structured Query Language) o lo que es lo mismo un lenguaje de consultas o lenguaje declarativo de acceso a bases de datos relacionales que permite efectuar consultas con el fin de recuperar informacin de inters de una base de datos y hacer cambios sobre la base de datos de forma sencilla; adems de analizar grandes cantidades de informacin y permitir especificar diversos tipos de operaciones frente a la misma informacin, a diferencia de las bases de datos de

los aos ochenta que se disearon para aplicaciones de procesamiento de transacciones. Por su parte, a principios de los aos ochenta comenz el auge de la comercializacin de los sistemas relacionales, y SQL comenz a ser el estndar de la industria, ya que las bases de datos relacionales con su sistema de tablas (compuesta por filas y columnas) pudieron competir con las bases jerrquicas y de red, como consecuencia de que su nivel de programacin era sencillo y su nivel de programacin era relativamente bajo. En la dcada de 1990 la investigacin en bases de datos gir en torno a las bases de datos orientadas a objetos. Las cuales han tenido bastante xito a la hora de gestionar datos complejos en los campos donde las bases de datos relacionales no han podido desarrollarse de forma eficiente. As se desarrollaron herramientas como Excel y Access del paquete de Microsoft Office que marcan el inicio de las bases de datos orientadas a objetos. As se cre la tercera generacin de sistemas gestores de bases de datos. Fue tambin en esta poca cuando se empez a modificar la primera publicacin hecha por ANSI del lenguaje SQL y se empez a agregar nuevas expresiones regulares, consultas recursivas, triggers y algunas caractersticas orientadas a objetos, que posteriormente en el siglo XXI volver a sufrir modificaciones introduciendo caractersticas de XML, cambios en sus funciones, estandarizacin del objeto sequence y de las columnas autonumricas. Y adems, se crear la posibilidad de que SQL se pueda utilizar conjuntamente con XML, y se definir las maneras de cmo importar y guardar datos XML en una base de datos SQL. Dando asi, la posibilidad de proporcionar facilidades que permiten a las aplicaciones integrar el uso de XQuery (lenguaje de consulta XML)

para acceso concurrente a datos ordinarios SQL y documentos XML. Y posteriormente, se dar la posibilidad de usar la clausula order by. Aunque el boom de la dcada de los noventa fue el nacimiento del World Wide Web a finales de la dcada, ya que a travs de este se facilitar la consulta a bases de datos. En la actualidad, las tres grandes compaas que dominan el mercado de las bases de datos son IBM, Microsoft y Oracle. Por su parte, en el campo de internet, la compaa que genera gran cantidad de informacin es Google. Aunque existe una gran variedad de software que permiten crear y manejar bases de datos con gran facilidad, como por ejemplo LINQ, que es un proyecto de Microsoft que agrega consultas nativas semejantes a las de SQL a los lenguajes de la plataforma .NET. El objetivo de este proyecto es permitir que todo el cdigo hecho en Visual Studio sean tambin orientados a objetos; ya que antes de LINQ la manipulacin de datos externos tena un concepto ms estructurado que orientado a objetos; y es por eso que trata de facilitar y estandarizar el acceso a dichos objetos. Cabe destacar que Visual Studio es un entorno de desarrollo integrado para sistemas operativos Windows que soporta varios lenguajes de programacin tales como Visual C++, Visual#, Visual J#, ASP.NET y Visual Basic.NET, aunque se estn desarrollando las extensiones necesarias para otros, cuyo objetivo es permitir crear aplicaciones, sitios y aplicaciones web, as como servicios web a cualquier entorno que soporte la plataforma .Net, creando as aplicaciones que intercomuniquen entre estaciones de trabajo, pginas web y dispositivos mviles.

Concepto Los OODBMS se desarrollaron a principios de los 90, para proporcionar un almacenamiento de objetos persistente. 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.

Manifiesto de los SGBDOO Sistemas Gestores Base de Datos Orientado a Objeto Este manifiesto propone 13 caractersticas obligatorias para los SGBDOO, basado en dos criterios: debe ser un sistema orientado a objetos y debe ser un SGBD (Atkinson et al., 1989). Caractersticas: 1- Debe soportar objetos complejos: Debe ser posible construir objetos complejos aplicando constructores a objetos bsicos. 2- Identidad del objeto: Todos los objetos deben tener un identificador que es independiente de los valores de sus atributos.

3- Encapsulamiento: Los programadores solo tienen acceso a la especificacin de interfaz de los mtodos y los datos e implementacin de estos mtodos estn ocultos en los objetos. 4- Tipos o clases: El esquema de una BDOO contiene un conjunto de clases o tipos. 5- Tipos o clases deben ser capaz de heredar de sus supertipos o superclases: los atributos y mtodos. 6- Sobrecarga debe ser soportada: los mtodos deben poder aplicarse a diferentes tipos. 7- El LMD debe ser completo: El LMD en los SGBDOO debe ser un lenguaje de programacin de propsito general. 8- El conjunto de tipos de datos debe ser extensible: No habr distincin entre tipos definidos por el usuario y tipos definidos por el sistema. 9- Persistencia de datos: Los datos deben mantenerse despus de que la aplicacin que los creo haya finalizado. El usuario no tiene que hacer copia explcitamente. 10- El SGBD debe ser capaz de manejar grandes BD. 11- El SGBD debe soportar Concurrencia: Debe disponer de mecanismos para el control de concurrencia. 12- Recuperacion: El SGBD debe proveer mecanismos de recuperacin de la informacin en caso de fallo del sistema. 13- El SGBD debe proveer una manera fcil de hacer consultas. MANIFIESTO DE STONEBRAKER, 1990: Se considera el manifiesto de definicin de sistemas gestores de bases de datos de tercera generacin siendo:

 SGBD primera generacin: Sistemas Jerrquicos y de Red. SGBD segunda generacin: Sistemas Relacionales. SGBD tercera generacin: siguiente generacin de sistemas de bases de datos cuyos principios bsicos de desarrollo presenta el manifiesto. Las caractersticas se recogen en tres principios bsicos junto con trece proposiciones que indican los requerimientos ms especficos de estos sistemas, las cuales no difieren mucho de las trece caractersticas obligatorias que indicaba el manifiesto de Atkinson. As los tres principios y las proposiciones para conseguirlos son los siguientes: I. PRIMER PRINCIPIO: ADEMS DE LOS SERVICIOS TRADICIONALES DE GESTIN DE DATOS, LOS SGDB DE TERCERA GENERACIN PROPORCIONARN GESTIN DE OBJETOS Y REGLAS MS RICAS Proposiciones: 1.1. Los SGBD de la tercera generacin deben tener un sistema de tipos rico. 1.2. La herencia es aconsejable. 1.3. La reutilizacin y la encapsulacin son aconsejables. 1.4. Se deberan asignar ID para los registros slo si no est disponible una clave primaria.

1.5. Las reglas se convertirn en una caracterstica primordial de los futuros sistemas. Las reglas no deberan asociarse con una funcin especfica.

II. SEGUNDO PRINCIPIO: LOS SGDB DE TERCERA GENERACIN DEBEN INCLUIR A LOS SGBD DE SEGUNDA Proposiciones: 2.1. Un SGBD de la tercera generacin debe tener un lenguaje

de acceso declarativo y de alto nivel. 2.2. Deben existir dos formas de especificar colecciones: por

enumeracin de sus miembros o mediante un lenguaje de consulta. 2.3. Las vistas deben ser actualizables. 2.4. Los indicadores de resultados no deben aparecer en los

datos.

III. TERCER PRINCIPIO: LOS SGDB DE TERCERA GENERACIN DEBEN ESTAR ABIERTOS A OTROS SUBSISTEMAS. Proposiciones: 3.1. Se puede acceder a un SGBD de tercera generacin desde

mltiples lenguajes de alto nivel. 3.2. Debe soportar la persistencia de las variables.

3.3.

El lenguaje SQL es una forma universal de expresin de

datos. 3.4. Las consulta y sus respuestas deben constituir el nivel ms

bajo de comunicacin entre un cliente y un servidor.

TERCER MANIFIESTO El enfoque purista ha sido duramente criticado por expertos de bases de datos relacionales: Los productos relacionales se apoyan en un lenguaje basado en la lgica, que lleva ms de dos mil aos demostrando su validez. Sera una pena desperdiciar ms de veinte aos de investigacin y desarrollo en bases de datos relacionales. El Tercer Manifiesto, DARWEN y DATE, 1995 Reinterpreta el modelo relacional bajo una visin orientada al objeto. Propone un lenguaje D que proporciona algunas ventajas de la orientacin al objeto, como los tipos de datos y la herencia, manteniendo el fundamento terico del modelo relacional. No se trata de una extensin del lenguaje SQL. Segn el manifiesto, tal lenguaje D, debe estar sujeto a una serie de prescripciones, proscripciones y lo que denomina sugerencias muy fuertes las cuales divide en categoras. RM: surgen del Modelo Relacional

OO: no surgen del Modelo relacional Conceptos Aspectos del modelo de datos orientado a objetos: Estructura de los objetos: Los objetos se corresponden con las entidades del modelo E/R. El paradigma orientado a objeto se basa en el encapsulamiento de los datos y del cdigo relacionado con cada objeto en uno solo. Todas las interacciones entre cada objeto y el resto del sistema es realizado mediante el uso de mensajes. La interfaz entre cada objeto y el resto del sistema se define mediante un conjunto de mensajes permitidos. Cada objeto esta asociado con: Un conjunto de variables que contienen los datos del objeto Un conjunto de mensajes a los que responde un conjunto de mtodos, cada uno de los cuales es cdigo que implementa un mensaje; el mtodo devuelve un valor como respuesta al mensaje. El termino mensaje hace referencia al intercambio de solicitudes entre objetos. Dado que la nica interfaz externa presentada por un objeto es el conjunto de mensajes a los que responde, resulta posible modificar las definiciones de los mtodos y de las variables sin afectar al resto del sistema. En el modelo orientado a objetos hay que expresar cada atributo de las entidades como una variable y un par de mensajes del objeto correspondiente: la variable guarda el valor del atributo, uno de los

mensajes se utiliza para leer el valor del atributo y el otro para actualizar ese valor. Clases de objetos. Los objetos que tienen las mismas propiedades y el mismo comportamiento. Todos se agrupan en clases. Los objetos de una clase (ejemplar de clase) comparten una definicin comn, diferencindose en los valores de las variables. El concepto de clase del modelo orientado a objetos se corresponde con el concepto de tipo de entidad en el modelo E/R. -- Herencia. El uso de Jerarqua de clases permite la definicin de una clase (denominada subclase) a partir de otra clase (denominada subclase). Los atributos de una clase son heredados por todos sus descendientes (ahorro de memoria). La herencia de mtodos permite aumentar la reutilizacin de cdigo. Reduce redundancias y simplifica la correccin de los programas. El concepto de jerarqua de clases es parecido al de especializacin del modelo E/R Herencia mltiple. Existen situaciones que no pueden representarse bien en una jerarqua de clases con estructura de rbol como la que se puede formar con la herencia simple, es decir situaciones en las que se necesita que una clase de objetos herede de ms de una clase. Se puede utilizar la herencia mltiple para modelar el concepto de papeles. Para comprender este concepto considrese una base de datos universitaria que tenga varias subclases de persona, como estudiante,

profesor e investigador. Los objetos pueden pertenecer a varias de las categoras de manera simultnea, y cada una de ellas se denomina papel. Identidad de los objetos. Los objetos de las bases de datos orientadas suelen corresponder a entidades del sistema modelado por la base de datos.Las entidades conservan su identidad aunque algunas de sus propiedades cambien con el tiempo.De manera parecida, los objetos conservan su identidad aunque los valores de las variables o las definiciones de los mtodos cambien total o parcialmente con el tiempo.Este concepto de identidad no se aplica a las tuplas de las bases de datos relacionales, donde las tuplas de una relacin slo se distinguen por los valores que contienen. . En los sistemas orientados a objetos se incluye el concepto de identidad en el modelo de datos o en el leguaje de programacin y no hace falta que el usuario proporcione ningn identificador sino que cada objeto recibe del sistema de manera automtica un identificador en el momento en que se crea, que identifica al objeto de manera unvoca. Continentes de objetos. Los objetos que contienen a otros objetos se denominan objetos complejos o compuestos. Pueden existir varios niveles de continentes pudindose crear jerarquas de continentes. De esta forma se establece una relacin de es parte de entre los objetos que forman parte del continente de objetos y el continente. El concepto de continente de objetos es importante en los sistemas orientados a objetos, porque permite que los diferentes usuarios examinen los datos con diferente detalle.Por ejemplo los diseadores de ruedas

(llanta, radios, neumtico) pueden concentrarse en los elementos de la clase ruedas sin tener que preocuparse de los objetos de las clases cambio o frenos.

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 ha concluido. Las relaciones de las bases de datos y las tuplas de las relaciones son ejemplos de datos persistentes. Por el contrario los nicos datos persistentes con los que los lenguajes de programacin tradicionales trabajan son los archivos. Los lenguajes de programacin persistentes son lenguajes de programacin extendidos con constructoras para el tratamiento de datos persistentes Los objetos que se pueden crear en los leguajes de programacin orientados a objetos son transitorios, es decir, desaparecen en cuanto se termina el programa. Si se desea transformar un lenguaje de programacin orientado a objetos en leguaje para programacin de bases 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 son, por tanto, persistentes de manera predeterminada,

mientras que los objetos de las clases no persistentes son transitorios. Este enfoque no es flexible, dado que suele resultar til disponer en una misma clase tanto de objetos transitorios como persistentes. Persistencia por creacin: En este enfoque se introduce una sintaxis nueva para crear los objetos persistentes mediante la extensin de la sintaxis para la creacin de objetos transitorios. Por tanto los objetos son persistentes o transitorios en funcin de la manera de crearlos. Persistencia por marcas: Es una variante del enfoque anterior que consiste en 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 de manera explcita antes de que ste concluya.En este enfoque a diferencia del anterior, la decisin sobre la persistencia o la transitoriedad se retrasa hasta despus de la creacin del objeto. Persistencia por referencia: En este enfoque uno o varios objetos se declaran persistentes (objetos raz) de manera explicita.Todos los dems objetos sern persistentes si (y slo si) se hace referencia a ellos de manera directa o indirecta desde un objeto persistente (objeto raz).Este esquema tiene la ventaja de que resulta sencillo hacer que sean persistentes estructuras de datos completas con slo declarar como persistente la raz de las mismas.Sin embargo, el sistema de bases de datos sufre la carga de tener que seguir las cadenas de referencias para detectar los objetos que son persistentes, y eso puede resultar costoso. Almacenamiento y acceso a objetos persistentes:

Para guardar un objeto en la base de datos hay que guardar por separado la parte de datos de cada objeto, mientras que la parte de cdigo que implementa los mtodos de las clases debe guardarse en la base de datos como parte del esquema de la misma, junto con las definiciones de tipos de las clases. Hay varios enfoques de hallar los objetos de la base de datos: . Uno de los enfoques consiste en dar nombres a los objetos, igual que se hace con los archivos. Este enfoque resulta til con un nmero de objetos relativamente pequeo, pero no resulta prctico para millones de objetos. . Un segundo enfoque consiste en exponer los identificadores de los objetos o los punteros persistentes de los objetos (un puntero persistente es un tipo de puntero que sigue siendo vlido despus de finalizar un programa a diferencia de los punteros internos de memoria), que pueden guardarse de manera externa. . Un cuarto enfoque es guardar las colecciones de objetos y permitir que los programas iteren sobre las mismas para hallar los objetos deseados. Las colecciones de objetos pueden a su vez modelarse como objetos de tipo coleccin.

Ventajas y Desventajas de los SGBDOO Ventajas: Se reduce la distancia entre el modelo conceptual de datos y el modelo lgico del desarrollo relacional. En el SGBDOO se desarrolla un nico modelo al que acceden directamente las aplicaciones. .Simplifica la conceptualizacin

La utilizacin de objetos permite representar de una forma ms natural los datos que se necesitan guardar. .Mejora la comunicacin entre los usuarios, los diseadores y los analistas Extensibilidad: Los SGBDOO permiten construir nuevos tipos de datos a partir de tipos existentes. Existe una nica interfaz entre el LMD y el lenguaje de programacin lo que elimina lo que elimina el problema de tener incrustar un lenguaje declarativo como SQL en un lenguaje imperativo como C. . Lenguaje de consultas ms expresivo : El lenguaje de consultas es navegacional de un objeto al siguiente, en contraste con el lenguaje declarativo SQL.El acceso navegacional es ms adecuado para manipular despliegue de partes, consultas recursivas, etc. . Soporte a esquema evolutivo : el estrecho acoplamiento entre datos y aplicaciones en un SGBDOO hace ms abordable el esquema evolutivo. Soporte a transacciones largas: necesario para muchas aplicaciones de bases de datos avanzadas. . Aplicabilidad a aplicaciones avanzadas de bases de datos(CASE, CAD, sistemas multimedia...) como ya se ha comentado. Desventajas: Falta de un modelo de datos universal como puede ser el modelo relacional. . Falta de experiencia: en comparacin con los SGBDR, el uso de los SGBDOO es todava relativamente limitado.Esto implica un nivel de experiencia menor en este tipo de sistemas.

. Falta de estndares: No existe un lenguaje de consultas estndar como SQL, aunque est el lenguaje OQL (Object Query Language) de ODMG que se est convirtiendo en un estndar de facto Competencia con los SGBDR con una amplia experiencia, con un leguaje de consultas estndar y un modelo de datos con una slida fundamentacin terica y un mayor soporte de los productos relacionales a herramientas para usuarios finales y desarrolladores. . La optimizacin de consultas compromete la encapsulacin: optimizar consultas requiere conocer la implementacin para acceder a la BD eficientemente. . Los bloqueos a nivel de objeto, utilizados en protocolos de control de concurrencia pueden afectar al rendimiento. Complejidad: el incremento de funcionalidad provisto por un SGBDOO, como un nico nivel de modelo de almacenamiento o soporte a transacciones largas, lo hace ms complejo que un SGBDR. La complejidad conlleva productos mas caros y difciles de usar. Falta de soporte a las vistas: la mayora de SGBDOO no proveen mecanismos de vistas. . Falta de soporte a la seguridad: Actualmente los SGBDOO no proveen un mecanismo adecuado de seguridad. La mayora de mecanismos estn basados en un nivel de granularidad alto y los usuarios no pueden conceder derechos de acceso a objetos o clases individuales. Primer intento de Estandarizacin: ODMG-93

Modelo de objetos propuesto por la ODMG (Object Database Management Group). Es un consorcio industrial de vendedores de SGBDOO.No es una organizacin de estndares acreditada , pero tiene mucha influencia en lo que respecta a estndares de SGBDOO. La mayor limitacin de las bases de datos orientadas a objetos es la carencia de un estndar. ODMG-93 es un punto de partida muy importante para ello .Adopta una arquitectura que consta de un sistema de gestin que soporta un lenguaje de bases de datos orientado a objetos, con una sintaxis similar a un lenguaje de programacin tambin orientado a objetos como puede ser C++ o Smalltalk. El lenguaje de bases de datos es especificado mediante un lenguaje de definicin de datos (ODL), un lenguaje de manipulacin de datos (OML), y un lenguaje de consulta (OQL), siendo todos ellos portables a otros sistemas con el fin de conseguir la portabilidad de la aplicacin completa. En definitiva, ODMG-93 intenta definir un SGBDOO que integre las capacidades de las bases de datos con las capacidades de los lenguajes de programacin, de forma que los objetos de la base de datos aparezcan como objetos del lenguaje de programacin, intentando de esta manera eliminar la falta de correspondencia existente entre los sistemas de tipos de ambos lenguajes .El SGBDOO extiende el lenguaje con persistencia, concurrencia, recuperacin de datos, consultas asociativas, etc

Componentes del estndar Lenguaje de definicin de objetos (ODL). No es un lenguaje de programacin completo

No est ligado a la sintaxis concreta de un Lenguaje de programacin (define tipos que pueden implementarse en varios lenguajes de programacin). Un esquema de datos de objeto especificado en ODL puede ser soportado por cualquier SGBDOO que cumpla el estndar ODMG.Es un lenguaje de especificacion para definir tipos de objetos para sistemas compatibles con ODMG. ODL es el equivalente del DDL (lenguaje de definicin de datos) de los SGBD tradicionales. Define los atributos y las relaciones entre tipos, y especifica la signatura de las operaciones. La sintaxis de ODL extiende el lenguaje de definicion de interfaces (IDL) de la arquitectura CORBA (Common Object Request Broker Architecture). Ejemplo de un esquema ODL de base de datos class Persona (extent personas key dni) { /* Definicion de atributos */ attribute struct Nom Persona {string nombre pila, string apellido1, string apellido2} nombre; attribute string dni; attribute date fecha nacim; attribute enum Genero{F,M} sexo; attribute struct Direccion {string calle, string cp, string ciudad} direccion; /* Definicion de operaciones */ float edad(); } class Profesor extends Persona (extent profesores)

{ /* Definicion de atributos */ attribute string categoria; attribute float salario; attribute string despacho; attributo string telefono; /* Definicion de relaciones */ relationship Departamento trabaja en inverse Departamento::tiene profesores; relationship Set<EstudianteGrad> tutoriza inverse EstudianteGrad::tutor; relationship Set<EstudianteGrad> en comite inverse EstudianteGrad::comite; /* Definicion de operaciones */ void aumentar salario(in float aumento); void promocionar(in string nueva categoria); }

class Estudiante extends Persona (extent estudiantes) { /* Definicion de atributos */ attribute string titulacion; /* Definicion de relaciones */ relationship set<Calificacion> ediciones cursadas inverse Calificacion::estudiante; relationship set<EdicionActual> matriculado inverse EdicionActual::estudiantes matriculados;

/* Definicion de operaciones */ float nota media(); void matricularse(in short num edic) raises(edicion no valida, edicion llena); void calificar(in short num edic; in float nota) raises(edicion no valida, nota no valida); }; class Calificacion (extent calificaciones) { /* Definicion de atributos */ attribute float nota; /* Definicion de relaciones */ relationship Edicion edicion inverse Edicion::estudiantes; relationship Estudiante estudiante inverse Estudiante::ediciones cursadas; }; class EstudianteGrad extends Estudiante (extent estudiantes graduados) { /* Definicion de atributos */ attribute set<Titulo> titulos; /* Definicion de relaciones */ relationship Profesor tutor inverse Profesor::tutoriza; relationship set<Profesor> comite inverse Profesor::en comite;

/* Definicion de operaciones */ void asignar tutor(in string apellido1; in string apellido2) raises(profesorno valido); void asignar miembro comite(in string apellido1; in string apellido2) raises(profesorno valido); }; class Titulo { /* Definicion de atributos */ attribute string escuela; attribute string titulo; attribute string a~no; }; class Departamento (extent departamentos key nombre) { /* Definicion de atributos */ attribute string nombre; attribute string telefono; attribute string despacho; attribute string escuela; attribute Profesor director; /* Definicion de relaciones */ relationship set<Profesor> tiene profesores inverse Profesor::trabaja en; relationship set<Curso> oferta inverse Curso::ofertado por; }; class Curso (extent cursos key num curso) {

/* Definicion de atributos */ attribute string nombre; attribute string num curso; attribute string descripcion; /* Definicion de relaciones */ relationship set<Edicion> tieneediciones inverse Edicion::de curso; relationship Departamento ofertado por inverse Departamento::oferta; }; class Edicion (extent ediciones) { /* Definicion de atributos */ attribute short num edic attribute string a~no; 4.3Lenguaje de consulta de objetos OQL attribute enum Semestre{Primero,Segundo} semestre; /* Definicion de relaciones */ relationship set<Calificacion> estudiantes inverse Calificacion::edicion; relationship Curso de curso inverse Curso::tiene ediciones; }; class EdicionActual extends Edicion (extent ediciones actuales) {

/* Definicion de relaciones */ relationship set<Estudiante> estudiantes matriculados inverse Estudiante::matriculado; /* Definicion de operaciones */ void matricular estudiante(in string dni) raises(estudiante no valido,edicion llena); };

Lenguaje OML El lenguaje de manipulacin es empleado para la elaboracin de programas que permitan crear, modificar y borrar datos que constituyen la base de datos. ODMG-93 sugiere que este lenguaje sea la extensin de un lenguaje de programacin, de forma que se pueden realizar entre otras las siguientes operaciones sobre la base de datos: Creacin, Borrado, Modificacin e Identificacin de un objeto

Lenguaje de Manipulacin de Objetos (OQL). OQL es un lenguaje declarativo del tipo de SQL que permite realizar consultas de modo eficiente sobre bases de datos orientadas a objetos, incluyendo primitivas de alto nivel para conjuntos de objetos y estructuras. Esta basado en SQL-92, proporcionando un superconjunto de la sintaxis de la sentencia SELECT. OQL no posee primitivas para modificar el estado de los objetos ya que las modificaciones se pueden realizar mediante los metodos que estos poseen. La sintaxis basica de OQL es una estructura SELECT...FROM...WHERE..., como en SQL. Por ejemplo, la siguiente expresion obtiene los nombres de los departamentos de la escuela de Ingeniera: SELECT d.nombre

FROM d in departamentos WHERE d.escuela = Ingeniera; En las consultas se necesita un punto de entrada, que suele ser el nombre de un objeto persistente. Para muchas consultas, el punto de entrada es la extension de una clase. En el ejemplo anterior, el punto de entrada es la extension departamentos, que es un objeto coleccion de tipo set<Departamento>. Cuando se utiliza una extension como punto de entrada es necesario utilizar una variable iteradora que vaya tomando valores en los objetos de la coleccion. Para cada objeto de la coleccion (solo la forman objetos persistentes) que cumple la condicion (que es de la escuela de Ingeniera), se muestra el valor del atributo nombre. El resultado es de tipo bag<string>. Cuando se utiliza SELECT DISTINCT... el resultado es de tipo set ya que se eliminan los duplicados. Las variables iterador se pueden especificar de tres formas distintas: d in departamentos departamentos d departamentos as d El resultado de una consulta puede ser de cualquier tipo soportado por el modelo. Una consulta no debe seguir la estructura SELECT ya que el nombre de cualquier objeto persistente es una consulta de por s. Por ejemplo, la consulta: departamentos; devuelve una referencia a la coleccion de todos los objetos Departamento persistentes. Del mismo modo, si se da nombre a un objeto concreto, por ejemplo a un departamento se le llama departamentoinf (el departamento de informatica), la siguiente consulta: departamentoinf; devuelve una referencia a ese objeto individual de tipo Departamento. Una vez se establece un punto de entrada, se pueden utilizar expresiones de caminos para especificar

un camino a atributos y objetos relacionados. Una expresion de camino empieza normalmente con un nombre de objeto persistente o una variable iterador, seguida de ninguno o varios nombres de relaciones o de atributos conectados mediante un punto. Por ejemplo: departamentoinf.director; departamentoinf.director.categoria; departamentoinf.tiene profesores; La primera expresion devuelve una referencia a un objeto Profesor, aquel que dirige el departamento de informatica. La segunda expresion obtiene la categora del profesor que dirige este departamento (el resultado es de tipo string). La tercera expresion devuelve un objeto de tipo set<Profesor>. Esta coleccion contiene referencias a todos los objetos Profesor que se relacionan con el objeto cuyo nombre es departamentoinf. Si se quiere obtener la categora de todos estos profesores, no podemos escribir la expresion: departamentoinf.tiene profesores.categoria;

El no poder escribir la expresion de este modo es porque no esta claro si el objeto que se devuelve es de tipo set<string> o bag<string>. Debido a este problema de ambiguedad, OQL no permite expresiones de este tipo. En su lugar, es preciso utilizar variables iterador: SELECT p.categoria FROM p in departamentoinf.tiene profesores; SELECT DISTINCT p.categoria FROM p in departamentoinf.tiene profesores;

En general, una consulta OQL puede devolver un resultado con una estructura compleja especificada en la misma consulta utilizando struct. La siguiente expresion: departamentoinf.director.tutoriza; devuelve un objeto de tipo set<EstudianteGrad>: una coleccion que contiene los estudiantes graduados que son tutorizados por el director del departamento de informatica. Si lo que se necesita son los nombres y apellidos de estos estudiantes y los ttulos que tiene cada uno, se puede escribir la siguiente consulta: SELECT struct(nombre:struct(ape1: e.nombre.apellido1, ape2: e.nombre.apellido2, nom: e.nombre.nombre pila), titulos:(SELECT struct(tit: t.titulo, ano: t.ano, esc: t.escuela) FROM t in e.titulos) FROM e in departamentoinf.director.tutoriza; OQL es ortogonal respecto a la especificacion de expresiones de caminos: atributos, relaciones y operaciones (metodos) pueden ser utilizados en estas expresiones, siempre que el sistema de tipos de OQL no se vea comprometido. Por ejemplo, para obtener los nombres y apellidos de los estudiantes que tutoriza la profesora Gloria Martnez, ordenados por su nota media, se podra utilizar la siguiente consulta (el resultado, por estar ordenado, sera de tipo list): SELECT struct(ape1: e.nombre.apellido1, ape2: e.nombre.apellido2,

nom: e.nombre.nombre pila, media: e.nota media) FROM e in estudiantes graduados WHERE e.tutor.nombre pila=Gloria AND e.tutor.apellido1=Martnez ORDER BY media DESC, ape1 ASC, ape2 ASC; OQL tiene ademas otras caractersticas: Especificacion de vistas dando nombres a consultas. Obtencion como resultado de un solo elemento (hasta ahora hemos visto que se devuelven colecciones: set, bag, list). Uso de operadores de colecciones: funciones de agregados (max, min, count, sum, avg) y cuantificadores (for all, exists). Uso de group by.

Extensiones para C++, Java y Smalltalk. Extienden el lenguaje de programacin para soportar objetos persistentes.

Comparacion entre BDOO y las BDROO Ambos tipos se encuentran en el mercado, y los diseadores de bases de datos deben escoger el tipo de sistemas que resulte ms adecuado para las necesidades de la aplicacin. Ambos tipos se encuentran en el mercado, y los diseadores de bases de datos deben escoger el tipo de sistemas que resulte ms adecuado para las necesidades de la aplicacin.

La naturaleza declarativa y la limitada potencia (comparada con la de los lenguajes de programacin) del lenguaje SQL proporciona una buena proteccin de los datos respecto de los errores de programacin y hace que las optimizaciones de alto nivel, como la reduccin de E/S, resulten sencilla. Comparacin entre BDOO y BDOR Los Sistemas Relacionales Orientados a Objetos (SROO) se dirigen a la simplificacin de la realizacin de los modelos de datos y de las consultas mediante el uso de tipos de datos complejos. Las aplicaciones tpicas incluyen el almacenamiento y la consulta de datos complejos, incluyendo los datos multimedia. Los lenguajes declarativos como SQL, imponen una reduccin significativa del rendimiento a ciertos tipos de aplicaciones que se ejecutan en la memoria principal y realizan gran nmero de accesos a la base de datos. Los lenguajes de programacin persistentes se dirigen a las aplicaciones que se ejecutan en memoria principal y que realizan un gran nmero de accesos a la BD, y que requieren elevados rendimientos. Proporcionan acceso a los datos persistentes con poca sobrecarga y eliminan la necesidad de la traduccin de los datos si hay que tratarlos utilizando un lenguaje de programacin. En cambio son mas susceptibles de deteriorar los datos debido a los errores de programacin y no suelen disponer de grandes posibilidades de consulta.

Los puntos fuertes de los distintos tipos de sistemas de bases de datos pueden resumirse de la manera siguiente:

Sistemas relacionales: Tipos de datos sencillos, lenguajes de consulta 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 consulta potentes, proteccin elevada

Ventajas Est su flexibilidad, y soporte para el manejo de tipos de datos complejos. Por ejemplo, en una base de datos convencional, si una empresa adquiere varios clientes por referencia de clientes servicio, pero la base de datos existente, que mantiene la informacin de clientes y sus compras, no tiene un campo para registrar quin proporcion la referencia, de qu manera fue dicho contacto, o si debe compensarse con una comisin, sera necesario reestructurar la base de datos para aadir este tipo de modificaciones. Por el contrario, en una BDOO, el usuario puede aadir una "subclase" de la clase de clientes para manejar las modificaciones que representan los clientes por referencia. La subclase heredar todos los atributos, caractersticas de la definicin original, adems se especializar en especificar los nuevos campos que se requieren as como los mtodos para manipular solamente estos campos. Naturalmente se generan los espacios para almacenar la informacin adicional de los nuevos campos. Esto presenta la ventaja adicional que una BDOO puede ajustarse a usar

siempre el espacio de los campos que son necesarios, eliminando espacio desperdiciado en registros con campos que nunca usan. La segunda ventaja de una BDOO, es que manipula datos complejos en forma rpida y gilmente. La estructura de la base de datos est dada por referencias (o apuntadores lgicos) entre objetos

Rendimiento: Las BDOO permiten que los objetos hagan referencia directamente a otro mediante apuntadores suaves. Esto hace que las BDOO pasen ms rpido del objeto A al objeto B que las BDR, las cuales deben utilizar comandos JOIN para lograr esto. Incluso el JOIN optimizado es ms lento que un recorrido de los objetos. As, incluso sin alguna afinacin especial, una BDOO es en general ms rpida en estamecnica de caza-apuntadores. * Las BDOO hacen que el agrupamiento sea ms eficiente. La mayora de los sistemas de bases de datos permiten que el operador coloque cerca las estructuras relacionadas entre s, en el espacio de almacenamiento en disco. Esto reduce en forma radical el tiempo de recuperacin de los datos relacionados, puesto que todos los datos se leen con una lectura de disco en vez de varias. Sin embargo, en una BDR, los objetos de la implantacin se traducen en representaciones tabulares que generalmente se dispersan en varias tablas. As, en una BDR, estos renglones relacionados deben quedar agrupados, de modo que todo el objeto se pueda recuperar mediante una nica lectura del disco. Esto es automtico en una BDOO. Adems, el agrupamiento de los datos relacionados, como todas las subpartes de un ensamble, puede afectar radicalmente el rendimiento general de una aplicacin. Esto es relativamente

directo en una BDOO, puesto que representa el primer nivel de agrupamiento. Por el contrario, el agrupamiento fsico es imposible en una BDR, puesto que esto requiere un segundo nivel de agrupamiento: un nivel para agrupar las hileras que representan a los objetos individuales y un segundo para los grupos de hileras que representan a los objetos relacionado

A continuacin describiremos a modo de ejemplo y a grandes rasgos una base orientada a objeto, para comprender mejor su funcionamiento: db4o tiene algunas caractersticas interesantes:

No hay diferencia de impedancia: los objetos se almacenan tal y como son. Manejo automtico del esquema de base de datos. No hay que cambiar las clases para poder almacenarlas. Sin junturas en la unin con el lenguaje Java (o .NET). Uniones de datos automatizadas. Se instala aadiendo un nico fichero de librera de 250Kb (jar para Java o DLL para .NET).

Un nico fichero de base de datos. Versionado del esquema automtico. Consultas-por-ejemplo (Query-By-Example). S.O.D.A. (Simple Object Database Access), un API de consultas open source.

Para qu es bueno db4o? db4o ha sido elegida para aplicaciones en sistemas embebidos en los que las caractersticas crticas son cero administracin, eficiencia, y pequeo tamao. En Alemania, el departamento de IT de BMW, por ejemplo, lo utliza en prototipos de coches electrnicos. Die Mobilanten, tambin el Alemania, utiliza db4o en una solucin basada en PDA para utilidades de tamao medio. En los U.S.A. el sistema de imagen retinal de Massie Systems para el diagnstico de ojos infantiles utiliza db4o para almacenar las imgenes de sus clientes. La completa simplicidad de la forma en que se almacenan objetos con db4o tambin es atractiva para propsitos de enseanza. La universidad de Essex y Texas A&M University utilizan db4o para enseanza e investigacin. La necesidad de interactuar con una base de datos relacional puede tener una influencia negativa en su aproximacin al diseo de sus modelos de dominio. Utilizar db4o permite trabajar con datos persistentes sin la distraccin de los modelos de datos conflictivos y sin la necesidad de emplear una significante cantidad de tiempo en aprender a utilizar herramientas como Hibernate o una compleja OODBMS. Adems, aprender los conceptos de una API de consultas orientado a objetos podra resultar muy til en el futuro

DB40 es una Base de Datos Orientada a Objetos de alto rendimiento. En algunos Benchmark realizados, DB4O muestra un rendimiento superior o similar a las Bases de Datos Relacionales, en el caso de Java, utilizando JDBC o algn Framework como Hibernate!. Hibernate es una herramienta para Java (NHibernate es la versin para .NET) que nos permite poder conjuntar sin ningn problema al modelo Orientado a

Objetos con el Relacional. El hecho de enviar sentencias SQL a algn manejador de BD Relacional, no significa que sean compatibles. Persona ximena = new Persona("Ximena", "Rodriguez", 'F'); JDBC.save(ximena); Si Java fuera compatible con MySQL/PostgreSQL/etc., el cdigo anterior, indudablemente debera funcionar, es decir, debera poder guardarse objetos! En lugar de eso, necesitamos utilizar variables escalares que contienen los valores que deseamos guardar, concatenarlas a otra cadena que tiene la sentencia SQL y finalmente enviarlas al manejador de Base de Datos mediante una alguna interfaz que comunique Java con MySQL/PostgreSQL/etc., como lo es JDBC. public void guardar(String nombre, String aPaterno, char sexo){ stmt.executeUpdate( "INSERT INTO persona("nombre, paterno, sexo )" + "VALUES(' "+nombre+', ' "+aPaterno+" ', ' "+sexo+" ')"); } Y para recuperar datos, es lo mismo, debemos enviar una consulta SELECT * FROM y con el resultado que nos devuelve la BD, ir iterando sobre cada registro para guardar el valor en variables o en Listas. Finalmente podemos ver el esfuerzo requerido para conectar los dos mundos; import java.sql.*;

public class Jdbc10 { public static void main(String args[]){ System.out.println( "Copyright 2004, R.G.Baldwin");

try { Statement stmt; ResultSet rs;

//Register the JDBC driver for MySQL. Class.forName("com.mysql.jdbc.Driver");

//Define URL of database server for // database named JunkDB on the localhost // with the default port number 3306. String url = "jdbc:mysql://localhost:3306/JunkDB";

//Get a connection to the database for a // user named auser with the password // drowssap, which is password spelled // backwards. Connection con = DriverManager.getConnection( url,"auser", "drowssap");

//Display URL and connection information System.out.println("URL: " + url); System.out.println("Connection: " + con);

//Get a Statement object stmt = con.createStatement();

//As a precaution, delete myTable if it // already exists as residue from a // previous run. Otherwise, if the table // already exists and an attempt is made // to create it, an exception will be // thrown. try{ stmt.executeUpdate("DROP TABLE myTable"); }catch(Exception e){ System.out.print(e); System.out.println( "No existing table to delete"); }//end catch

//Create a table in the database named // myTable. stmt.executeUpdate( "CREATE TABLE myTable(test_id int," + "test_val char(15) not null)");

//Insert some values into the table stmt.executeUpdate(

"INSERT INTO myTable(test_id, " + "test_val) VALUES(1,'One')"); stmt.executeUpdate( "INSERT INTO myTable(test_id, " + "test_val) VALUES(2,'Two')"); stmt.executeUpdate( "INSERT INTO myTable(test_id, " + "test_val) VALUES(3,'Three')"); stmt.executeUpdate( "INSERT INTO myTable(test_id, " + "test_val) VALUES(4,'Four')"); stmt.executeUpdate( "INSERT INTO myTable(test_id, " + "test_val) VALUES(5,'Five')");

//Get another statement object initialized // as shown. stmt = con.createStatement( ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY);

//Query the database, storing the result // in an object of type ResultSet rs = stmt.executeQuery("SELECT * " + "from myTable ORDER BY test_id");

//Use the methods of class ResultSet in a // loop to display all of the data in the // database. System.out.println("Display all results:"); while(rs.next()){ int theInt= rs.getInt("test_id"); String str = rs.getString("test_val"); System.out.println("\ttest_id= " + theInt + "\tstr = " + str); }//end while loop

//Display the data in a specific row using // the rs.absolute method. System.out.println( "Display row number 2:"); if( rs.absolute(2) ){ int theInt= rs.getInt("test_id"); String str = rs.getString("test_val"); System.out.println("\ttest_id= " + theInt + "\tstr = " + str); }//end if

//Delete the table and close the connection // to the database

stmt.executeUpdate("DROP TABLE myTable"); con.close(); }catch( Exception e ) { e.printStackTrace(); }//end catch }//end main }//end class Jdbc10

Un Ejemplo trabajando con la base orientada a objetos Este ejemplo demuestra la simple que es crear una base de datos y almacenar objetos. Tambin ilustra dos mtodos de consulta: Query-By-Example (QBE) y el ms flexible S.O.D.A. Las dos clases del ejemplo representan un Team y un Player de Baseball. Para hacer las cosas ms interesantes tambin tenemos una clase Pitcher. La clase Pitcher es una subclase dePlayer y aade un campo extra sobre los heredados. Team tiene un atributo que es una lista de objetos Player, que puede, por supuesto, incluir objetos Pitcher. Los objetos Team,Player, y Pitcher son objetos "normales" de Java, sin cdigo de persistencia. No se requieren atributos de clave nica, porque la base de datos de objetos almacena automticamente los objetos con un identificador de objeto nico (OID). La clase Player public class Player {

protected String name; protected int squadNumber;

protected float battingAverage; protected Team team;

public Player(String name, int squadNumber, float battingAverage){ this.name = name; this.squadNumber = squadNumber; this.battingAverage = battingAverage; }

public void setName(String n){this.name = n;} public String getName(){return this.name;}

public void setSquadNumber(int s){this.squadNumber = s;} public int getSquadNumber(){return this.squadNumber;}

public void setBattingAverage(final float b) { this.battingAverage = b; } public float getBattingAverage(){ return this.battingAverage;}

public void setTeam(Team t) {this.team = t;} public Team getTeam() {return this.team;}

public String toString() {

return name + ":" + battingAverage; } } La clase Pitcher public class Pitcher extends Player{ private int wins;

public Pitcher(String name, int squadNumber, float battingAverage, int wins) { super(name,squadNumber,battingAverage); this.wins = wins; }

public void setWins(final int w){this.wins = w;} public int getWins() {return this.wins;}

public String toString() { return name + ":" + battingAverage + ", " + wins; } } La clase Team import java.util.List; import java.util.ArrayList;

public class Team {

private String name; private String city; private int won; private int lost; private List players;

public Team(String name, String city, int won, int lost){ this.name = name; this.city = city; this.won = won; this.lost = lost; this.players = new ArrayList(); }

public void addPlayer(Player p) { players.add(p); }

public void setName(String n){this.name = n;} public String getName(){return this.name;}

public void setStadium(String c){this.city = c;} public String getCity(){return this.city;}

public void setPlayers(List p){players = p;} public List getPlayers(){return players;}

public void setWon(int w) {this.won = w;} public int getWon(){return this.won;}

public void setLost(int l) {this.lost = l;} public int getLost() {return this.lost;}

public String toString() { return name; } } Primero, creamos algunos datos de prueba con los que trabajar: // Create Players Player p1 = new Player("Barry Bonds", 25, 0.362f); Player p2 = new Player("Marquis Grissom", 9, 0.279f); Player p3 = new Player("Ray Durham", 5, 0.282f); Player p4 = new Player("Adrian Beltre", 29, 0.334f); Player p5 = new Player("Cesar Izturis", 3, 0.288f); Player p6 = new Player("Shawn Green", 15, 0.266f);

// Create Pitchers Player p7 = new Pitcher("Kirk Rueter",46, 0.131f, 9);

Player p8 = new Pitcher("Kazuhisa Ishii",17, 0.127f, 13);

// Create Teams Team t1 = new Team("Giants", "San Francisco", 91, 71); Team t2 = new Team("Dodgers", "Los Angeles", 93, 69);

// Add Players to Teams t1.addPlayer(p1); p1.setTeam(t1); t1.addPlayer(p2); p2.setTeam(t1); t1.addPlayer(p3); p3.setTeam(t1); t2.addPlayer(p4); p4.setTeam(t2); t2.addPlayer(p5); p5.setTeam(t2); t2.addPlayer(p6); p6.setTeam(t2);

// Add Pitchers to Teams t1.addPlayer(p7); p7.setTeam(t1); t2.addPlayer(p8); p8.setTeam(t2);

Almacenar los Datos Un objeto Team se puede almacenar con una sla lnea de cdigo: db.set(t1); Donde db es una referencia a un objeto ObjectContainer, que se haya creado abriendo un fichero de base de datos, de esta forma: ObjectContainer db = Db4o.openFile(filename);

Una base de datos db4o es un nico fichero con una extensin .yap, y se utiliza su mtodoset para almacenar objetos. Observe que est linea almacena el objeto Team y su coleccin de objetos Player. Se puede probar esto recuperando uno de esos objetos Player. La forma ms simple de hacer esto es utilizando QBE.

Consulta Simple: QBE El siguiente cdigo lista todos los objetos Player que sean iguales al objeto de ejemplo; slo debera haber un resultado. Los resultados se obtienen como un ObjectSet llamando al mtodo get de ObjectContainer. Player examplePlayer = new Player("Barry Bonds",0,0f); ObjectSet result=db.get(examplePlayer);

System.out.println(result.size()); while(result.hasNext()) { System.out.println(result.next()); } Se pueden obtener todos los objetos Player que se hayan almacenado creando un objeto de ejemplo vaco (todos son campos son null o 0), de esta forma: Player examplePlayer = new Player(null,0,0f); ObjectSet result=db.get(examplePlayer);

System.out.println(result.size()); while(result.hasNext()) { System.out.println(result.next());

} La salida se parecera a esto: 8 Kazuhisa Ishii:0.127, 13 Shawn Green:0.266 Cesar Izturis:0.288 Adrian Beltre:0.334 Kirk Rueter:0.131, 9 Ray Durham:0.282 Marquis Grissom:0.279 Barry Bonds:0.362 Observe que se pueden recuperar todos los objetos de la clase Player y de todas sus subclases (como Pitcher en este ejemplo) sin ningn exfuerzo extra. Los objetos Pitchermuestran en la salida un atributo ms: wins. Con una base de datos relacional tendramos que decidir cmo mapear el rbol de herencia a tablas y posiblemente hubieramos tenido que unir tablas para recuperar todos los atributos de todos lo objetos.

Actualizar y Borrar La actualizacin de objetos se pude consegir utilizando una combinacin de las tcnicas anteriores. El siguiente cdigo asume que slo se ha encontrado una correspondencia, y el objeto encontrado se fuerza a Player para poder modificar sus atributos: Player examplePlayer = new Player("Shawn Green",0,0f); ObjectSet result = db.get(examplePlayer);

Player p = (Player) result.next(); p.setBattingAverage(0.299f); db.set(p); De forma similar se pueden borrar objetos de la base de datos: Player examplePlayer = new Player("Ray Durham",0,0f); ObjectSet result = db.get(examplePlayer); Player p = (Player) result.next(); db.delete(p);

Un soporte de Consultas ms poderoso Una de las mayores desventajas de versiones anteriores de db4o era que QBE proporcionaba una capacidad de consulta bastante limitada. Por ejemplo, no se podia ejecutar una consulta como "todos los jugadores con un promedio de bateo superior a .300". Ahora db4o incluye el API S.O.D.A. para proporcionar consultas que se acercan mucho ms al poder de SQL. Un ejemplar de la clase Query representa un nodo en un grfico de criterios de consulta a los que se pueden aplicar restricciones. Un nodo puede representar una clase, mltiples clases o un atributo de una clase. El siguiente cdigo demuestra cmo crear la consulta descrita en el prrafo anterior. Definimos un nodo de consulta y lo restringiremos a la clase Player. Esto significa que la consulta slo devolver objetos Player. Luego descendemos la rama para encontrar un nodo que representa un atributo llamado battingAverage y lo restringimos a los mayores de 0.3. Finalmente se ejecuta la consulta para que devuelva todos los objetos de la base de datos que cumplen las restricciones.

Query q = db.query(); q.constrain(Player.class); q.descend("battingAverage").constrain(new Float(0.3f)).greater(); ObjectSet result = q.execute(); A primera vista, esto realiza una consulta similar al SQL: SELECT * FROM players WHERE battingAverage > 0.3 Sin embargo, el diseo de la clase Player permite crear relaciones inversas entre objetos Teamy Player, como se vi en los datos de prueba. Un Team tiene una lista de objetos Player, mientras que cada objeto Player tiene una referencia a un Team. Esto significa que el resultado de una consulta contiene objetos Player y Team. El siguiente cdigo demuestra esto: System.out.println(result.size()); while(result.hasNext()) { // Print Player Player p = (Player) result.next(); System.out.println(p); // Getting Player also gets Team - print Team Team t = p.getTeam(); System.out.println(t); } Salida : 2 Adrian Beltre:0.334 Dodgers Barry Bonds:0.362

Giants Ahora la consulta sera similar a este SQL: SELECT teams.name, players.name, players.battingAverage FROM teams, players WHERE teams.teamID = players.playerID AND battingAverage > 0.3 Esto a funcionado debido a que la relacin inversa se dise dentro del modelo de objetos. Las bases de datos de objetos son navegables: slo se pueden recuperar los datos siguiendo la direccin de las relaciones predefinidas. Por otro lado, las bases de datos relacionales, no tienen direccionalidad en sus uniones de tablas y por lo tanto, permiten ms flexibilidad para consultas personalizadas. Sin embargo, dando unas relaciones de objetos correctas, los objetos relacionados se pueden recuperar de la base de datos de objetos con muy poco esfuerzo de programacin. Los modelos de la base de datos y los modelos de objetos de la aplicacin son idnticos, por eso el programador no tiene que pensar de forma diferente en los datos. Si se pude obtener el Team de un Player dado cuando estn en memoria, se puede hacer lo mismo desde la base de datos. Qu ms puede hacer S.O.D.A.? SQL permite ordenar los resultados; S.O.D.A. tambin. Este ejemplo muestra cmo los objetosPlayer almacenados se pueden recuperar ordenndolos por battingAverage. (Ahora es bastante obvio quienes son los pitchers!) Query q = db.query(); q.constrain(Player.class); q.descend("battingAverage").orderAscending(); ObjectSet result = q.execute();

Salida: 7 Kazuhisa Ishii:0.127, 13 Kirk Rueter:0.131, 9 Marquis Grissom:0.279 Cesar Izturis:0.288 Shawn Green:0.299 Adrian Beltre:0.334 Barry Bonds:0.362 S.O.D.A. permite definir consultas ms complejas utilizando cdigo que es bastante simple una vez que se evita la tentacin de pensar de forma 'relacional'. Para configurar las restricciones slo hay que navegar por el grfico de consulta para encontrar las clases o atributos a los que se quieren poner condiciones. El grfico de consulta est muy relacionado con el modelo de objetos de dominio, que todos los desarrolladores deberan entender. Por otro lado, para conseguir un resultado similar con SQL se necesita tener en cuentra cmo se han mapeado los objetos de dominio en las tablas relacionales. Este ejemplo muestra cmo seleccionar condiciones a dos atributos de la clase Player para encontrar "jugadores con un promedio de bateo por encima de .130 que sean pitchers con ms de 5 wins". De nuevo, definimos un nodo de consulta y lo restringimos a la clasePlayer. Descendemos el grfico para encontrar un nodo que represente el atributo llamadobattingAverage y lo restringimos a los mayores de 0.13. El resultado es un objetoConstraint. Para selecconar la siguiente restriccin, descendemos para encontrar el nodo que representa el atributo "wins"; esto en s mismo significa que la consulta slo

encontrar objetosPitcher. Este nodo est restringido a ser mayor que 5, y esto se combina utilizando un "AND" lgico con el primer objeto Constraint. Query q = db.query(); q.constrain(Player.class); Constraint constr = q.descend("battingAverage").constrain(new Float(0.13f)).greater(); q.descend("wins").constrain(new Integer(5)).greater().and(constr); result = q.execute(); Salida: 1 Kirk Rueter:0.131, 9 Giants El ltimo ejemplo muestra cmo combinar condiciones de atibutos de diferentes clases para encontrar "jugadores con promedio de bateo superior a .300 que estn en un equipo con menos de 92 wins". La forma ms fcil de hacer esto es empezar con Player, y luego navegar a Team. Descendemos para encontrar el nodo "battingAverage" igual que antes y seleccionamos una Constraint. Luego descendemos para encontrar el atributo "team". Como este atributo es del tipo Team, el nodo representa la clase Team, podemos descender de nuevo al nodo que representa el atributo "won" del Team y configurar una restriccin para l. Finalmente, combinamos esto con la primera Constraint. Query q = db.query(); q.constrain(Player.class); Constraint constr = q.descend("battingAverage").constrain(new Float(0.3f)).greater();

q.descend("team").descend("won").constrain(new Integer(92)).smaller().and(constr); result = q.execute(); Salida: 1 Barry Bonds:0.362 Giants

db4o ahora es una base de datos Open Source que ofrece muchas caractersticas atractivas y soporta tanto Java como .NET. La simplicidad de instalacin y utilizacin as como la ausencia de la diferencia de impedancia entre los modelos de objetos y de datos hace que db4o sea muy til en un amplio rango de aplicaciones de negocio y educativas. Existe abundante documentacin en ingles y en espaol sobre el uso de DB4O con Java y C#, al bajar DB4O de la pgina oficial, encontraremos en dicha carpeta, un completo tutorial en espaol sobre su uso, adems de una gua de referencia. Hibernate utiliza archivos XML para mapear clases Java con columnas de una Tabla Relacional y mediante este mapeo, es posible hacer algo similar al cdigo que vimos para guardar objetos en DB4O, pero la diferencia es que Hibernate internamente se encargar de hacer dicho mapeo por nosotros e insertar en las columnas de la Tabla Relacional. A cambio de esta comodidad de utilizar Java y MYSQL/SQL Server/etc., Hibernate disminuye el rendimiento de la aplicacin! Existe mucha polmica en si DB4O es o no es la opcin idnea para aplicaciones empresariales de gran porte, por lo mismo que las Bases de Datos Orientadas a

Objetos no tienen un fuerte sustento matemtico como si lo tienen las Relacionales, por eso su penetracin no ha sido tan fuerte! Por lo anterior, la industria del Software no ha querido experimentar en ambientes reales de gran escala la potencia de DB4O.

Conclusion

Bibliografia

Bertino, E., Martino, L. Sistemas de bases de datos orientadas a objetos. Concepto y arquitecturas.. Addison-Wesley/ Diaz de Santos 1995. USA http://histinf.blogs.upv.es/2011/01/04/historia-de-las-bases-de-datos/ http://www.slideshare.net/guestf9c5f7/base-de-datos-orientada-a-objetos http://miriammeza.wordpress.com/2011/02/04/ejemplo-de-aplicacion-debdoo-en-la-industria/ . http://basesdatos.uc3m.es/fileadmin/Docencia/BDAII/BBDDobjetos30.pdf http://www.infoseek.com 26/Dic/99 Manifesto de Atkinson . "Sistemas manejadores de bases de datos OO" http://www.db4o.com/espanol/ http://www.programacion.com/articulo/persistencia_de_objetos_java_utiliza ndo_db4o_308

Database Systems. Thomas Connolly, Carolyn Begg. Addison Wesley.

http://www.articulo.org/articulo/3041/bases_de_datos_orientadas_a_objetos__una _opcion _de_desarrollo_viable.html Los captulos 11 y 12 del texto de Elmasri y Navathe