BASES DE DATOS ORIENTADA A OBJETOS

REPORTE DE INVESTIGACION
INSTITUTO TECNOLOGICO DE HERMOSILLO
MARTINEZ BARAJAS FRANCISCO RAFAEL DURAN NUNEZ FRANCISCO JAVIER ARCE HERNANDEZ EVA MARIA
12/03/2012

La siguiente investigacin abarca el tema de las BDOO as como sus ventajas y desventajas, dicho trabajo es parte de la evaluacin de la unidad I de la materia tpicos de base de datos, de la carrera Lic. En informtica.

PALABRAS RESERVADAS POO: Programacin Orientada a Objetos. DBMS: Sistema Manejador de Base de Datos. OODBMS: Sistema Manejador de Base de Datos Orientada a Objetos. BDOO: Base de Datos Orientada a Objetos. ODMG: (Object Database Mangement Group) es el grupo de fabricantes de OODBMS

INTRODUCCION Los modelos de bases de datos tradicionales presentan deficiencias en cuanto a aplicaciones ms complejas o sofisticadas. Adems son difciles de utilizar cuando las aplicaciones que acceden a ellas estn escritas en un lenguaje de programacin orientado a objetos. La orientacin a objetos ofrece flexibilidad, no est limitada por los tipos de datos y los lenguajes de consulta de los sistemas de bases de datos tradicionales. La caracterstica clave es la potencia que proporcionan al diseador al permitirle especificar tanto la estructura de objetos complejos, como las operaciones que se pueden aplicar sobre dichos objetos. Las BDOO se han diseado para que se puedan integrar directamente con aplicaciones desarrolladas con lenguajes orientados a objetos. Tambin estn diseadas para simplificar la POO. Almacenan los objetos en la BD con las mismas estructuras y relaciones que los lenguajes de POO. Una OODBMS es un DBMS que almacena objetos incorporando as todas las ventajas de la POO. Pueden tratar directamente con objetos, no teniendo que hacer la traduccin a tablas o registros. Sus objetos se conservan, pueden ser gestionados aunque su tamao sea grande, pueden ser compartidos entre mltiples usuarios y mantienen su integridad como sus relaciones. ODMG (Object Database Mangement Group) es el grupo de fabricantes de OODBMS que propuso el estndar ODM-93 en 1993; en 1997 evolucion a ODMG-2.0 y en enero de 2000 se public la ltima versin ODMG 3.0. El uso del estndar proporciona portabilidad (que se pueda ejecutar sobre sistemas distintos), interoperabilidad (que la aplicacin pueda acceder a varios sistemas diferentes) y adems permite que los usuarios puedan comparar entre distintos sistemas comerciales. [5]

BASE DE DATOS ORIENTADA A OBJETOS El almacenamiento persistente de objetos creados el lenguajes de programacin como java# y c++, como usted sabe, las bases de datos relacionan las bases de datos en formas 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 de proporcionar ciertos medios para almacenarlos. [2] Los productos DBMS de propsito especial, llamados OODBMS se desarrollaron a principios de la dcada de 1990 para proporcionar un almacenamiento de objetos persistentes. Sin embargo no se han comercializado con xito debido a que necesitan convertir los datos al formato OODBMS. Las organizaciones casi no realizan dicha conversin porque es muy costosa y las ganancias no compensan la inversin. [2] La OOP es una manera de disear y codificar programas, es una nueva forma de pensar las estructuras de programacin. [2] El objetivo de un OODBMS es proporcionar un almacenamiento de objetos persistentes. Un objeto est conformado por datos y mtodos; esto significa que un OODBMS, distinto aun DBMS tradicional, debe almacenar los programas de objetos y tambin los datos. Puesto que cada objeto de una clase especfica tiene el mismo conjunto de mtodos, estos necesitan almacenarse solo una vez por clase; en contraste, Los elementos de los datos deben almacenarse una vez por cada caso de objetos. [2]

Conceptos relacionados con las bases de datos orientadas a objetos En este apartado se explican los conceptos relacionados con las BDOO: Base de datos orientada a objetos (BDOO): una coleccin persistente y compatible de objetos definida por un modelo de datos orientado a objetos. [5] Modelo de datos orientado a objetos: Un modelo de datos que captura la semntica de los objetos soportados en la programacin orientada a objetos. [5] Sistema Gestor de Bases de Datos Orientadas a Objetos (SGBDOO): El gestor de una base de datos orientada a objetos. [5]

Origen de las Bases de Datos Orientadas a Objetos

El origen de las BDOO se encuentra bsicamente en las siguientes razones: La existencia de problemas para representar cierta informacin y modelar ciertos aspectos del mundo real, puesto que los modelos clsicos permiten representar gran cantidad de datos, pero las operaciones y representaciones que se pueden realizar sobre ellos son bastante simples. [5] El paso del modelo de objetos al modelo relacional genera dificultades que en el caso de las BDOO no surgen ya que el modelo es el mismo. Por lo tanto, las bases de datos orientadas a objetos surgen bsicamente para tratar de paliar las deficiencias de los modelos anteriores y para proporcionar eficiencia y sencillez a las aplicaciones. [5]

Visin general El modelo de datos relacional orientado a objetos extiende el modelo de datos relacional ofreciendo un sistema de tipo ms rico que incluye tipos de datos complejos y orientados a objetos. [2] Los sistema de bases de datos relacionales basado en objetos, es decir, los sistemas de bases de datos basados en modelos objeto-relacin, ofrece un medio de migracin cmodo para los usuarios de las bases de datos relacionales que deseen usar caractersticas orientadas a objetos. [2] El termino lenguajes de programacin persistentes hace referencia a las extensiones de los lenguajes de programacin existentes que aaden persistencia y otras caractersticas de las bases de datos usando el sistema de tipo nativo de lenguaje de programacin. El termino sistema de bases de datos orientadas a objetos se usa para hacer referencia a los sistemas de bases de datos que soportan sistemas de tipos orientados a objetos permiten el acceso a directo a los datos desde los lenguajes de programacin orientados a objetos usando el sistema de tipo nativo del lenguaje. [2] Tipos de datos complejos. Con los sistemas de tipos complejos se pueden representar directamente conceptos del modelo ER, como los atributos compuestos, los tributos multivalorados, la generalizacin y la especializacin, sin necesidad de una compleja traduccin al modelo relacional. [2] Considrese, por ejemplo una aplicacin para una biblioteca y supngase que se desea almacenar la informacin siguiente para cada libro: Ttulo del libro Lista de autores Editor Conjunto de palabras clave

Por simplificar se da por supuesto que el ttulo del libro lo identifica de maneta univoca. Se puede representar, entonces, la misma informacin usando el esquema siguiente: Autores (titulo, autor, posicin). Palabra_Clave (titulo, palabra_clave). Libros (titulo, nombre_editor, sucursal_editor).

La posibilidad de usar tipos de datos complejos como los conjuntos y los arrays puede resultar til en muchas aplicaciones, pero se debe usar con cuidado. [2]

Tipos estructurados y herencias en SQL El sistema de tipos de SQL consista en un conjunto bastante sencillo de tipos predefinidos. Aadi un sistema de tipo extenso a SQL, lo que permite los tipos estructurados y la herencia de tipos. [2] Tipos estructurados Los tipos estructurados permiten representar directamente los atributos compuestos de los diagramas E-R. [2] En SQL estos tipos se dominan tipos definidos por el usuario. Ahora se pueden usar esos tipos para crear atributos compuestos en la relaciones, como solo declarar que un atributo es de uno de estos tipos. [2] Una manera alternativa de definir los atributos compuestos en SQL es usar tipos de filas sin nombre. Sobre los tipos estructurados se pueden definir mtodos. [2] Herencia de tipos Los mtodos de los tipos estructurados se heredan por sus subtipos, igual que los tributos. Sin embargo, cada subtipo puede redefinir el efecto de los mtodos volviendo a declararlos, usando overriding method en lugar de method en la declaracin del mtodo. [2] La norma de SQL tambin exige un campo adicional al final de la definicin de los tipos, cuyo valor es final o not final. La palabra clave final indica que no se pueden crear subtipos a partir del tipo dado, mientras que not final indica que se pueden crear subtipos. Las herencias multiples no en todas las versiones de SQL lo permiten. [2] Herencia de tablas Las subtablas de SQL se corresponden con el concepto de especializacin/ generalizacin de E-R. [2] Existen varios requisitos de consistencia para las subtablas. Antes de definir las retricciones, es necesaria una definicin: se dice que las tuplas de una subtabla se corresponde con las tuplas de la tabla madre si tienen el mismo valor para rodos los atributos heredados. Por tanto, las tuplas correspondientes representan a la misma entidad. [2] Los requisitos de consistencia de las subtablas son: 1.- cada tupla de la supertabla puede corresponderse, como mximo, con una tupla de cada una de sus subtablas inmediatas. [2] 2.- SQL posee una restriccin adicional que hace que todas las tuplas que se corresponden entre si deben proceder de una tupla (insertada en una tabla). [2]

Para finalizar este apartado, hay que tener en cuenta que SQL define un nuevo privilegio denominado under , el cual es necesario para crear subtipos o subtablas bajo otro tipo o tabla. La razn de ser de este privilegio es parecida a la del privilegio references. [2] Tipos array y multiconjunto en SQL Recurdese que un multiconjunto es un conjunto no ordenado, en el que cada elemento puede aparecer varias veces. Los multiconjuntos son como los conjuntos, salvo que los conjuntos, salvo que los conjuntos permiten que cada elemento aparezca, como mucho, una vez. [2] En general, los atributos multivalorados de los esquemas E-R se pueden asignar en SQL a atributos valorados como multiconjuntos; si el orden es imprtate, se pueden usar los arrays de SQL en lugar de los multiconjuntos. [2] 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. [2] Dado que el atributo es un campo que se valora como conjunto, unnest puede usarse en una clausula from en la que se espere una relacin. Tngase en cuenta que la variable tupla es visible para esta expresin, ya que se ha definido en la clausula from. [2] Al desanidar un array la consulta anterior pierde informacin sobre el orden de los elementos del array. Se pueden usar las clausula unnest with ordinality para obtener esta informacin. [2] La clausula with ordinality genera un atributo adicional que registra la posicin del elemento en el array. Se puede usar una consulta parecida, pero sin la clausula with ordinality, para generar la relacin. [2] Anidamiento y desanidamiento. La transformacin de una relacin anidada en una forma con menos atributos de tipo relacin se denomina desanidamiento. [2] El proceso inverso de transformar una relacin en una relacin anidada se denomina anidamiento. El anidamiento puede realizarse mediante una expresin de la agrupacin en SQL. La funcin collect devuelve el multiconjunto de valores; en lugar de crear un solo valor se puede crear una relacin anidada. [2] SQL ofrece gran variedad de operadores para multiconjuntos, incluido la funcin set, que calcula versin libre duplicada del multiconjunto, la operacin agregada intersection, cuyo resultado es la interseccin de todos los multiconjuntos de un grupo, y el predicado submultiset, comprueba si el multiconjunto est contenido en otro multiconjunto. [2]

Identidad de los objetos y tipos de referencia 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. [2] Se pueden omitir la declaracin scope de la declaracin de tipos y hacer, en su lugar, un aadido a la intruccion create table. [2] La tabla a la que se hace referencia debe tener un atributo que guarde el identificador de cada tupla. Ese atributo, denominado atributo autorreferencial, se declara aadiendo una clausula re fis a la instruccin create table. [2] El tipo del atrivito referencial debe espesificarce como parte de la definicin de tipo de la tabla a la que se hace referencia, y la definicin de la tabla debe espesificar que la referencia esta generada por el usuario (user generated). [2] Incluso es posible el valor de un clave primario ya existente como identificador, icluyendo la clausula ref from en la definicin de tipos. [2]

Implementacin de las caractersticas O-R Las modificaciones resultan claramente necesarias en muchos niveles del sistema de bases de datos. Sin embargo, para minimizar las modificaciones en el cdigo del sistema de almacenamiento (almacenamiento de relaciones, ndices, etc.). Los tipos de datos complejos soportados por los sistemas relacionales orientados a objetos se pueden traducir al sistema de tipos ms cansillos de las bases de datos relacionales. [2] Las subtablas se pueden almacenar de manera eficiente, sin rplica de todos los campos heredados, de una de esta manera: Cada tabla almacena la clave primaria (que puede a ver heredado de una tabla madre) y los atributos que se definen de localmente. No hace falta almacenar los atributos heredados ( que no sea la clave primaria), se pueden obtener mediante una reunin con la supertabla, de acuerdo con la clave primaria. [2] Cada tabla almacena todos los atributos heredados y definidos localmente cuando se inserta una tupla solo se almacena en la tabla en la que se inserta en su presencia que se infiere en cada una de las supertablas. El acceso de todos los atributos es ms rpido, ya que no hace falta ninguna reunin. [2]

Lenguajes de programacin persistentes Los lenguajes de las bases de datos se diferencian de los lenguajes de programacin tradicionales que trabajan directamente con datos que son persistentes; es decir, los datos siguen existiendo una vez el programa que los creo all concluido. [2] Los lenguajes de programacin persistentes son lenguajes de programacin extendidos con estructuras para el tratamiento de los datos persistentes. Los lenguajes de programacin persistente pueden distinguirse con los lenguajes SQL incorporando, al menos, de dos maneras: 1.- En los lenguajes incorporados el sistema de tipos de lenguaje anfitrin suele ser diferente del sistema de tipos de lenguajes por el tratamiento de los datos. [2] 2.- Los programadores que usan lenguajes de consultas incorporados son responsables de la escritura de cdigo explicito para la bsqueda en la memoria de los datos de la base de datos. [2]

Persistencia de los objetos Persistencia por clases. El enfoque ms sencillo pero el menos conveniente, consisten en declarar que una clases es persistente. Todos los objetos de la clase son, por tanto, persistentes de manera predeterminada. Todos los objetos de las clases no persistentes son transitorios. [2] Persistencia por creacin. En este enfoque se introduce una sintaxis nueva para crear los objetos persistentes mediante la extensin de la sintaxis. [5] 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 mas all de la ejecucin del programa, hay que marcarlo como persistente de manera explcita antes de que este concluya. [2] Persistencia por alcance. Uno o varios objetos declaran objetos persistentes (objetos de raz) de manera explcita. Todos los dems objetos sern persistencia si (y solo si) se puede alcanzar mediante un objeto raz mediante una secuencia mediante una secuencia de una o varias referencias. [2]

Identidad de los objetos y punteros Dentro de los procedimientos. La identidad solo persiste durante la ejecucin de un nico procedimiento. Un ejemplo de identidad dentro de los programas son las variables locales de los procedimientos. [2] Dentro de los programas. La identidad solo persiste durante la ejecucin de un nico programa o de una nica consulta. [2] Entre programas. La entidad persiste de una ejecucin del programa a otra. Los punteros a los datos del sistema de archivos del disco ofrecen identidad entre

programa a otra. Los punteros a los datos del sistema de archivos del disco ofrecen identidad entre los programas, pero pueden cambiar si se modifica la manera en que los datos se guardan en el sistema de archivos. [2] Persistente. La identidad no solo persiste entre las ejecuciones del programa sino tambin entre reorganizaciones estructurales de los datos. Es la forma persistente de identidad necesaria para los sistemas orientados a objetos. [2]

Sistemas orientados a objetos y sistemas relacionales orientados a objetos Ya se han estudiado las bases de datos relacionales orientadas a objetos, que son bases de datos orientadas a objetos construidos sobre el modelo relacional, asi como las bases de datos orientados a objetos, que se crean alrededor de los lenguajes de programacin persistentes. [2] 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, 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. [2] Sistemas relacionales orientados a objetos: Tipos de datos complejos, lenguajes de consultas potentes, proteccin elevada.[2]

Caractersticas de las Bases de Datos Orientadas a Objetos y diferencias de stas con respecto a las relacionales.
Mientras que en una BDR los datos a almacenar se almacenan representados en tablas en un BDOO los datos se almacenan como objetos. Un objeto en BDOO como en POO es una entidad identificable unvocamente que describe tanto el estado como el comportamiento de una entidad del mundo real. El estado de un objeto es descrito mediante atributos mientras que su comportamiento es definido mediante mtodos. [5] Las caractersticas asociadas a las BDOO son: Objetos: cada entidad del mundo real se modela como un objeto. [5] La forma de identificar objetos es mediante un identificador de objetos (OID, Object Identifier), nico para cada objeto. Generalmente este identificador no es accesible ni modificable para el usuario (modo de aumentar la integridad de entidades y la integridad referencial). Los OID son independientes del contenido. Es decir, si un objeto cambia los valores de atributos, sigue siendo el mismo objeto con el mismo OID. Si dos objetos tienen el mismo estado pero diferentes OID, son equivalentes pero tienen identidades diferentes. [5] Encapsulamiento: cada objeto contiene y define procedimientos (mtodos) y la interfaz mediante la cual se puede acceder a l y otros objetos pueden manipularlo. La mayora de los SGBDOO permite el acceso directo a los atributos incluyendo operaciones definidas por el propio SGBDOO las cuales leen y modifican los atributos para evitar que el usuario tenga que implementar una cantidad considerable de mtodos cuyo nico propsito sea el de leer y escribir los atributos de un objeto. Generalmente, los SGBDOO permiten al usuario especificar qu atributos y mtodos son visibles en la interfaz del objeto y pueden invocarse desde afuera. [5]

Ventajas Y Desventajas
Las ventajas de un SGBDOO son: Mayor capacidad de modelado: Un objeto permite encapsular tanto un estado como un comportamiento. Un objeto puede almacenar todas las relaciones que tenga con otros objetos. Los objetos pueden agruparse para formar objetos complejos (herencia). [5] Ampliabilidad: Se pueden construir nuevos tipos de datos a partir de los ya existentes Agrupar propiedades comunes de diversas clases e incluirlas en una superclase, lo que reduce la redundancia. Reusabilidad de clases, lo que repercute en una mayor facilidad de mantenimiento y un menor tiempo de desarrollo. [5] Lenguaje de consulta ms expresivo. El acceso navegacional desde un objeto al siguiente es la forma ms comn de acceso a datos en un SGBDOO. Mientras que SQL utiliza el acceso asociativo. [5] El acceso navegacional es ms adecuado para gestionar operaciones como los despieces, consultas recursivas, etc. [5] Adecuacin a las aplicaciones avanzadas de base de datos. Hay muchas reas en las que los SGBD tradicionales no han tenido excesivo xito como el CAD, CASE, OIS, sistemas multimedia, etc. en los que las capacidades de modelado de los SGBDOO han hecho que esos sistemas s resulten efectivos para este tipo de aplicaciones. [5] Mayores prestaciones. Los SGBDOO proporcionan mejoras significativas de rendimiento con respecto a los SGBD relacionales. [5] Las Desventajas de un SGBDOO son: Carencia de un modelo de datos universal. No hay ningn modelo de datos que est universalmente aceptado para los SGBDOO y la mayora de los modelos carecen una base terica. [5] Carencia de experiencia. Todava no se dispone del nivel de experiencia del que se dispone para los sistemas tradicionales. [5] Carencia de estndares. Existe una carencia de estndares general para los SGBDOO. [5] Competencia. Con respecto a los SGBDR y los SGBDOR. Estos productos tienen una experiencia de uso considerable. SQL es un estndar aprobado y ODBC es un estndar de facto. Adems, el modelo relacional tiene una slida base terica y los

productos relacionales disponen de muchas herramientas de soporte que sirven tanto para desarrolladores como para usuarios finales. [5] La optimizacin de consultas compromete la encapsulacin. La optimizacin de consultas requiere una compresin de la implementacin de los objetos, para poder acceder a la base de datos de manera eficiente. Sin embargo, esto compromete el concepto de encapsulacin. [5] El modelo de objetos an no tiene una teora matemtica coherente que le sirva de base. [5]

MANIFIESTOS ACERCA DE LAS SGBDOO

En 1989 se hizo el Manifiesto de los sistemas de base de datos orientados a objetos el cual propuso trece caractersticas obligatorias para un SGBDOO y cuatro opcionales. Las trece caractersticas obligatorias estaban basadas en dos criterios: deba tratarse de un sistema orientado a objetos y un SGBD. [5] Caractersticas obligatorias de orientacin a objetos: 1) Deben soportarse objetos complejos 2) Deben soportarse mecanismos de identidad de los objetos 3) Debe soportarse la encapsulacin 4) Deben soportarse los tipos o clases 5) Los tipos o clases deben ser capaces de heredar de sus ancestros 6) Debe soportarse el enlace dinmico 7) El DML debe ser computacionalmente complejo 8) El conjunto de todos los tipos de datos debe ser ampliable Caractersticas obligatorias de SGBD: 9) Debe proporcionarse persistencia a los datos 10) El SGBD debe ser capaz de gestionar bases de datos de muy gran tamao 11) El SGBD debe soportar a usuarios concurrentes 12) El SGBD debe ser capaz de recuperarse de fallos hardware y software 13) El SGBD debe proporcionar una forma simple de consultar los datos. [5]

Manifiesto de los SBD de Tercera Generacin, STONEBRAKER, 1990: SGBD Relacionales extendidos que sean capaces de soportar los conceptos de orientacin al objeto. Postura que propugnan los principales vendedores de productos relacionales. [5] Tercer manifiesto, DARWEN y DATE 1995: Reinterpretan el modelo relacional bajo la visin orientada al objeto. [5]

Conclusin
La BDOO permite el desarrollo y mantenimiento de aplicaciones complejas con un costo bajo. Permitiendo al modelo conceptual aplicarse al anlisis, diseo, programacin, definicin, acceso a la BD. La BDOO ofrece un mayor rendimiento de la maquina, que las bases de datos por relacin, para aplicaciones o clases con estructuras complejas de datos.

Bibliografa [2] Silberschatz, A., Korth, H.F. y Sudarshan, S., (2007) Fundamentos de bases de dato, McGrawHill,S.A.,Espana. [2]M, Kroenke, David, (2003), Procesamiento de Base de Datos Orientada a Objetos en Procesamiento de Base de Dato, Pearson Educacin (Mxico) p.555, 556,557. [5] Manzaneque, Alberca, Alejandro y Daz-Tendero Glvez Jess (Modelos Avanzados de Bases de Datos) http://basededatos2010.wikispaces.com/file/view/BD+O-O+ventajas+y+desventajas.pdf (visitado el 10/03/2012) [5] Torres, Piqueres, Jos (Bases de Datos Orientadas a Objetos) http://www.iessanvicente.com/colaboraciones/bdOO.pdf (visitado el 10/03/2012)