Está en la página 1de 9

EN QU SITUACIN SE ENCUENTRAN LAS OODBS ACTUALMENTE? Comparativa con los RDB'S, avances y caractersticas a mejorar.

Durante la pasada dcada, la tecnologa orientada a objetos ha encontrado su camino en los lenguajes de programacin, interfaces de usuarios, sistemas operativos... , y la actual tendencia es el ofrecimiento de los productos de base de datos relacionales extendidos con capacidades orientadas a objetos. Pero en realidad no es oro todo lo que reluce, es decir, los sistemas de bases de datos orientados a objetos (OODBs) son susceptibles de mejora y pasar algo de tiempo hasta que se consoliden en el mercado, ya que es necesario unificarlos con sistemas de bases de datos relacionales para cubrir holgadamente el rea de necesidades. En este captulo intentaremos dar una visin general de estos sistemas.

Qu es un objeto? Qu significa orientado a objetos?


Es una combinacin de datos y programa, que representan una entidad en el mundo real. P.ej. Carlos tiene 20 aos y es trabaja en una barra americana. En trminos de objeto sera (nombre: Carlos, edad: 20, trabaja_en: barra americana). La parte de programa puede ser una coleccin de programas que denominaremos mtodos. P.ej Aumenta_edad, Termina_contrato,.. La parte de datos consiste en datos de cualquier tipo y cada uno de ellos es un atributo. Un objeto puede estar encapsulado, es decir, los usuarios no pueden ver el interior del objeto, y la nica manera de obtener informacin es pasarle datos de entrada a sus correspondientes mtodos, para que nos devuelva datos de salida. Sabiendo qu es un objeto podemos definir el trmino de orientado a objetos como la combinacin del objeto encapsulado y la reutilizacin del cdigo, pudiendo un objeto ser definido a partir de otro. Los objetos que comparten la misma parte de datos y la misma parte de programas, constituyen una clase, y con relacin a lo anterior una clase puede heredar los atributos y los mtodos de otra. Es importante el concepto de herencia ya que un usuario puede definir una clase a partir de otra adquiriendo todos sus mtodos y atributos. A la nueva clase (Clase Hija) se le pueden aadir nuevo atributos y mtodos. En general una clase puede depender de una o varias clases y la estructura jerrquica que se obtiene es un grafo dirigido acclico.

Ya que la herencia hace posible que diferentes clases compartan los mismos atributos y los mismos mtodos, el mismo programa funciona para objetos que pertenecen a dichas clases. (Esto es la base del interfaz de usuario orientado a objeto que es proporcionado por los administradores de ventanas y sistemas de presentacin en publicidad.) Debido a la reutilizacin del cdigo, no tendremos que volver a definir algo que ya hemos definido anteriormente, disminuyendo la posibilidad de introducir errores.

OODB
Al ser un sistema de bases de datos debe poseer facilidad para realizar peticiones no procedimentales, optimizar y procesar automticamente las peticiones, cambiar la definicin de las clases y la estructura jerrquica, administrar automticamente los mtodos de acceso, controlar la concurrencia, y mantener sistemas de recuperacin, seguridad, y autorizacin. Cabra destacar que el uso de la tecnologa orientada a objetos reduce la dificultad a la hora de desarrollar y evolucionar en sistemas o diseos complejos; y la reutilizacin del cdigo es la base para crear estos sistemas. La herencia y la encapsulacin eliminan de un plumazo tres de las deficiencias ms importantes de los sistemas de bases de datos relacionales (RDB): - Los procedimientos se pueden almacenar en una RDB, pero no se pueden encapsular con datos, es decir, no estn correlacionados con ninguna relacin o ninguna tupla de una relacin. Adems no se puede reutilizar el cdigo ya que los RDB no permiten la herencia. - Los RDB no estn diseados para permitir que nuevos tipos de datos sean aadidos a la base de conocimiento, y a partir de ellos definir otros datos. - En un RDB los datos se deben representar en trminos de tuplas y mltiples relaciones, implicando operaciones costosas. En el mercado podemos encontrar un buen nmero de OODBs, pero la aceptacin de los mismos est resultando ser un proceso lento, estimndose el volumen de mercado de estos sistemas en la centsima parte del mercado global de sistemas de bases de datos, debido principalmente a su falta de consolidacin.

CARACTERSTICAS
Podemos resaltar como funcionalidades generales en la mayora cualquier sistema de administracin de una OODB: - Desglose en posibles caminos a la hora de estudiar cada expresin. - Comparaciones atributo/atributo, atributo/constante. - Explotacin de ndices para acceder a atributos simples y manejar rutas en las expresiones. - Peticiones arbitrarias (sin ndices o referencias) ejecutadas por anlisis secuencial.

No optimizacin de joins (El acceso entre los objetos va atributos que no estn materializados por referencia a objetos explcitos, puede ser considerado equivalente a la operacin de join relacional).

Ya aparece aqu el concepto de navegacin, que resulta de la necesidad de ejecutar peticiones que exploten los caminos entre los objetos basndose en las referencias entre los propios atributos. Sin embargo las peticiones que son formuladas en relaciones no directamente modeladas por referencia, son ejecutadas ineficientemente, y sern procesadas secuencialmente. P.ej:
class documento{ string nombre; persona autor; int n_l; } class persona{ string nombre; ciudad casa; } clase ciudad { string nombre; } Optimizacin de peticiones (Referencias): Seleccionar todos los documentos con autores que viven en Nueva York: set <documento> NY_docs = todos _documentos [autor.casa.nombre==Nueva York]

No obstante cuando las peticiones son formuladas en la direccin no soportada por referencias, como en el caso de ciudad a documento va autor, el sistema no har una optimizacin de la peticin. P. ej:
No Optimizacin: Seleccionar todas las ciudades con ms documentos que los producidos en N. Y.: set <ciudad> Mas: todas _ciudades [(todos_documentos[autor.casa.nombre==nombre).tamao > (todos_documentos [autor.casa.nombre ==New York]).tamao]

Una caracterstica fundamental de estos sistemas es que soportan objetos complejos, aunque la funcionalidad de los mismos no sea totalmente aprovechable. Bsicamente todas las referencias son relativas a objetos independientes y la semntica de relaciones especiales dentro de los objetos complejos est escondida dentro de las operaciones. Por ejemplo, un documento junto con su jerarqua de captulos y prrafos, es un objeto complejo. Se tendra que tener en cuenta que un captulo no debera existir sin su correspondiente documento, es decir, al borrar un documento deberan borrarse todo sus captulos. Lo mismo pasara con las acciones de imprimir las subpartes de un captulo, o copiar en profundidad un documento entero.

Pero en la realidad la mayora de los OODBs no resuelven esta serie de incidencias; algunos de estos sistemas ofrecen la posibilidad de usar relaciones inversas para expresar el hecho de la existencia de una referencia mutua entre dos objetos (relacin binaria). El sistema asegura integridad referencial automticamente, por ejemplo, estableciendo la correspondiente referencia tan pronto como sea creada, e incluso es posible propagar el borrado; aunque otras operaciones no son capaces de diferenciar entre referencias normales e inversas. Otro dato a tener en cuenta es que existe cierta dependencia del lenguaje de programacin orientado a objetos usado, pero esto no debera ser as ya que para aprovechar la funcionalidad total de una base de datos, habra que permitir la implementacin de mtodos en distintos lenguajes debido a que las aplicaciones puede usar diferentes lenguajes de programacin. En cuanto al almacenamiento de los mtodos la mayora de los OODBs guardan en la base de datos estructuras de los objetos (atributos y datos); los mtodos no son tratados por los DBMSs, y son almacenados en ficheros fuera de la base de datos. Esto implica que tienen que ser enlazados al programa de aplicacin y por lo que se pueden generar conflictos a la hora de mantener la consistencia o la encapsulacin. Originalmente la idea era crear un depsito de tipos de datos abstractos pero sera ms lgico considerar la posibilidad de que cada sistema permita el almacenamiento de mtodos, siendo suficiente para el usuario el mero hecho de abrir la base de datos, siendo irrelevante el lenguaje en que se desarrollaron los mtodos ya que la llamada a los mismos sera formalizada.

Limitaciones
Desde hace tiempo se busca la persistencia en las clases y en las instancias de las mismas, es decir, se busca que se puedan almacenar en una memoria secundaria y hacerlas accesibles incluso despus de que los programas que las definieron y las crearon, terminasen. Pero estos sistemas tratan datos persistentes de distinta forma respecto a datos no persistentes, y por lo tanto se requiere que el usuario declare explcitamente si un objeto es persistente o no (considerando como ilegal la accin de asignar a un objeto persistente un OID de un objeto no persistente), y es aqu dnde reside el problema ya que no se puede hacer persistentes ciertos tipos de datos y por consiguiente prohibir sus usos. Otra limitacin es la falta de caractersticas bsicas de un sistema de bases de datos tales como un lenguaje no procedimental de peticiones con ciertas facilidades, vistas, autorizaciones, etc. Adems se echa en falta elementos como los triggers y las restricciones. Pocos sistemas soportan facilidades para trabajar con las peticiones, y los que las poseen utilizan un lenguaje de peticiones no compatible con ANSI-SQL.

Se podra decir que permiten crear al usuario una base de datos flexible y generar muchas instancias sobre las mismas, pero no proporcionan medios suficientes para obtener los objetos de la base de datos. Adems estos sistemas no permiten cambios dinmicos en el esquema de la base de datos, como aadir un nuevo objeto o mtodo a una clase, borrar una superclase de una clase, etc. Otra limitacin importante es que en algunos de los sistemas el usuario debe establecer y quitar explcitamente los bloqueos en el procesamiento de las peticiones; y por ltimo es necesario advertir que las OODBs ofrecen una capacidad limitada para la parametrizacin de las funciones. Debido a lo anteriormente explicado se espera una mejora considerable en estos productos. Para ello, por ejemplo, se ha optado a la extensin de las OODBs con libreras de funciones para su correspondiente lenguaje de programacin OO. Esas funciones deben ser llamadas desde los programas de aplicacin con especificaciones apropiadas de parmetros de entrada y salida. La sintaxis de llamada es consistente, y as podemos facilitar algo el tratamiento de peticiones. El resultado de una peticin debe estar, por tanto, asociado a una estructura de datos y algoritmo correspondiente, pudiendo almacenar un nmero indefinido de objetos. Incluso habr que proporcionar facilidades para especificar subpeticiones anidadas, y operaciones entre peticiones (unin, interseccin, diferencia). Esto supone para el usuario aprender una nueva sintaxis para disfrutar de su potencial, sin olvidar que la sintaxis debe ser consistente con el lenguaje de programacin residente. Sera aconsejable mostrar algunas de los avances que presumiblemente ofrecen las OODBs respecto a los RDB, pero que en la realidad no se aprecian; mostrando la necesidad de unificar ambos sistemas para un mayor rendimiento aunque en un futuro se opte por la tecnologa orientada a objetos: Mayor rapidez: Un objeto X cuyo dominio es otro objeto Y es el objeto identificador (OID) del objeto Y. Partiendo de esta idea, podemos suponer que al trabajar con OIDs, que pueden ser direcciones fsicas pudiendo encontrar el objeto directamente; o lgicas, utilizando tcnicas de hashing para la localizacin del objeto. A primera vista parece que estos tipos de localizaciones parecen ms efectivos que las complejas combinaciones (joins) en las RDB. La mayora de las OODBs convierten los OIDs guardados en un objeto, a punteros a memoria cuando los objetos son cargados en la memoria. As el acceso informacin consiste slo en el manejo de punteros.

El hecho de tener muchos objetos cuyos punteros de memoria apuntan a otros objetos, no sera posible en RDBs ya que no tenemos punteros de tuplas almacenados en una tupla. Sin embargo la mayora de aplicaciones que manejan OIDs tambin tienen requerimientos de acceso y actualizacin reconocidos por los RDBs tales como joins de ms de una clase, creacin de clases individuales, eliminacin de clases individuales, commit de las transacciones, etc.; de modo que la efectividad entre utilizar o no OIDs depende de la implementacin de la mismas y si el optimizador de peticiones est diseado paras explotarlos de manera eficaz y rpida, resultando que en algunas situaciones es aconsejable responder a una peticin de manera relacional, ya que suponiendo que tenemos miles de tuplas si usamos ndices en los atributos sera tan rpido localizar una tupla relacionalmente como usando una tabla de tipo hash, aunque con el direccionamiento fsico se obtendran las tuplas requeridas de manera ms eficiente. Eliminar la necesidad de joins: Las OODBs reducen el uso de joins entre clases (equivalente a joins entre relaciones), pero no del todo. El join relacional es un mecanismo general que enlaza dos relaciones en base a los valores de al pareja correspondiente de atributos. Debido a que dos clases en un OODB pueden tener en general su pareja de atributos correspondiente, es an necesario el join relacional.
PERSONA OID Nombre Edad Trabaja_Para 23 Migue 20 09 65 Ricard 20 08 COMPAA OID Nombre Edad Jefe 09 Don Angelo 45 Conrado 08 La Casita 54 Salvador

Si queremos encontrar toda persona cuya edad sea menor que la edad de la persona para la que trabaja en su compaa, no tenemos ms remedio que hacer un join entre ambas clases. La identidad de los objetos elimina la necesidad de claves: La identidad de los objetos es un modo de representar al objeto y garantizar su unicidad (El OID es generado automticamente por el sistema). Pero cuando se tiene una gran base de datos, es conveniente buscar los objetos usando claves definidas, dependiendo de la implementacin de los OIDs. Las OODBs eliminan la necesidad de un lenguaje no procedimental en la base de datos: Las OODBs ofrecen limitadas capacidades con relacin a las peticiones. Los esfuerzos en el desarrollo de estos sistemas se centran en la navegacin en la base de datos y en hacer objetos persistentes. Los comandos necesarios para invocar las facilidades limitadas de la base de datos han sido presentadas como llamadas a libreras de funciones, y esto no supone ms que el uso un lenguaje procedimental. Pretendiendo acercar las OODBs a sistemas de bases de datos reales, se opta por aadir facilidades respecto a las peticiones similares a las de los

RDB, pero esto necesariamente implica un lenguaje no procedimental, el cul es muy difcil de esconder al usuario. Actualmente se intenta proporcionar lenguajes no procedimentales, etiquetados como Object SQL. El procesamiento de peticiones implica una violacin de la encapsulacin: La encapsulacin tiene como objetivo forzar a los programadores a acceder a los objetos solamente invocando la parte de programas y haciendo que los programadores hagan uso del conocimiento de las estructuras de datos usadas para almacenar los objetos o la implementacin de la parte del programa. En el caso del proceso de una peticin, los sistemas de bases de datos deben leer los contenidos de los objetos, extraer los OIDs que pueden estar guardados en algunos atributos de los objetos, y obtener los objetos que se corresponden a esos OIDs. Esto puede suponer la violacin de la encapsulacin ya que el sistema de base de datos examina el contenido de los objetos. Realmente no es una violacin porque al interior de los objetos no accede un usuario cualquiera, sino ms bien lo podemos considerar como un acto de examinar los valores guardados en los atributos de los objetos como el hecho de invocar al mtodo de lectura asociado implcitamente en cada clase de cada atributo. OODB`s pueden soportar versiones y transacciones de larga duracin: a) La razn de la asociacin de las versiones y transacciones de larga duracin a las OODBs es simplemente que puede suponerse que sus tratamientos son mejoras de las bases de datos que los RDBs no pudieron ofrecer y que se han identificado como requerimientos de estas aplicaciones. Si un objeto es versionado, su correspondiente timestamp y su identificador de versin necesitan ser mantenidos. Esto puede ser implementado creando atributos definidos teniendo en cuenta el timestamp y/o el identificador de la versin, pudiendo realizarse para cada objeto versionado en una clase en una OODB; o para una tupla versionada en una RDB. Adems habra que mantener una historia de las distintas versiones en la base de datos. b)Una transaccin es simplemente una coleccin de lecturas y actualizaciones de datos que son tratados como una nica unidad, proporcionando un mecanismo para asegurar consistencia en presencia de accesos simultneos de mltiples usuarios, y posibles conflictos. Cuando la transacciones son largas las OODBs realmente no ofrecen ninguna ventaja apreciable ya que lo que diferencia a ambas tecnologas es de cmo estn representados y modelados los datos, y por tanto la complejidad de una transaccin es independiente de su tratamiento. OODBs soportan datos multimedia A pesar de flexibilidad respecto a datos multimedia, an no estn resueltos problemas de almacenamiento, actualizacin, etc...; adems de ciertas dificultades con datos de gran tamao, y en consecuencia se puede

deducir que las OODBs se enfrentan a los problemas a los que ya se enfrentaron los RDBs; y por tanto deben resolver exactamente los mismos problemas de ingeniera que los RDBs.

El paso de la tecnologa relacional a la orientada a objetos debe ser progresivo, y se tiende a unificar ambas tecnologas. Un ejemplo de ello lo podemos encontrar en Oracle Corporation, que est actualmente estudiando planes para desarrollar una extensin orientada a objetos a SQL. Como ya hemos dicho anteriormente se antoja necesario unificar ambas tecnologa para conseguir, por ahora, un sistema potente e ir dando los pasos necesarios hasta la consolidacin de los OODBs. La unificacin de ambas tecnologas consta de dos partes: - Proceso de unificacin de las arquitecturas. - Proceso de unificacin de los modelos de datos. Ambos procesos son complejos y requieren de un conocimiento amplio en bases de datos; pero como idea mostramos a continuacin ejemplos de extensiones sucesivas al modelo relacional con lo que se demuestra la interoperabilidad entre ambas tecnologas y el resultado de la unificacin:

Ej.) CREATE TABLE Empleados (Nombre CHAR(20), Oficio CHAR(20), Salario FLOAT, Hobby CHAR(20), Director CHAR(20)); CREATE TABLE Empleados (Nombre CHAR(20), Oficio CHAR(20), Salario FLOAT, Hobby Actividad, Director Empleados); CREATE TABLE Actividad (Nombre CHAR(20), NumHacedores INTEGER , Origen CHAR(20)); CREATE TABLE Empleados (Nombre CHAR(20), Oficio CHAR(20), Salario FLOAT, Hobby Actividad , Director Empleados); CREATE TABLE Actividad (Nombre CHAR(20), NumHacedores INTEGER , Origen CHAR(20)); PROCEDURE RetirarBenecios FLOAT; CREATE TABLE Empleados (Nombre CHAR(20), Oficio CHAR(20), Salario FLOAT, Hobby Actividad , Director Empleados); CREATE TABLE Actividad (Nombre CHAR(20), NumHacedores INTEGER , Origen CHAR(20)); PROCEDURE RetirarBenecios FLOAT AS CHILD OF Persona; CREATE TABLE Person (Nombre CHAR(20), SS CHAR(20),Edad INTEGER);