por Todd R. Manion
traducido por Pablo J. Rogina
La metodología y programación orientada a objetos (OOP por sus iniciales en inglés - Object Oriented Programming) han alterado radicalmente la forma en que programamos. Muchas clases iniciales de Ciencias de la Computación se enseñan ahora en un lenguaje orientado a objetos, tales como Java o C++. Las ideas de orientación a objetos están influenciando no sólo como programamos, sino como pensamos acerca de otros conceptos tales como bases de datos. Rob y Coronel [3] ven las bases de datos orientadas a objetos (OODB por sus iniciales en inglés - Object Oriented Database) en forma histórica, como la unión de dos corrientes de pensamiento: programación orientada a objetos y sistemas de administración de bases de datos. La unión de estas dos tecnologías es el resultado directo de la tareas cada vez más dificultosa de trabajar con complejos requisitos de datos y los temas de modelar datos del mundo real con tecnología de bases de datos relacionales. Temas como el uso cada vez mayor de multimedia en las bases de datos, el tamaño de las bases de datos, y la complejidad de las actuales bases de datos, requiere soluciones más allá de las bases de datos relacionales. Los Sistemas de Administración de Bases de Datos Orientadas a Objetos (OODBMS por sus iniciales en inglés - Object Oriented Database Management Systems) son un resultado directo de las tecnologías de bases de datos emergentes desde la reorganización de los sistemas de información ya en uso y existencia [3].
El propósito de este artículo es describir las características de una base de datos orientada a objetos (OODB) y como se relaciona con el modelo de datos orientado a objetos (OODM por sus iniciales en inglés - Object Oriented Data Model) y un sistema de administración de bases de datos orientadas a objetos (OODBMS). Este artículo es un resumen de los conceptos e ideas vertidos en en el libro de Peter Rob y Carlos Coronel titulado Database Systems: Design, Implementation, and Management. Las ideas subyacentes propias de lenguajes de programación orientados a objetos se discutirán y aclararán para mantener congruencia a través de esta revisión. Los aspectos generales de bases de datos orientada a objetos se discutirán en relación al modelo tradicional Entidad-Relación de una base de datos. Además, los sistemas de administración de bases de datos orientadas a objetos serán vistas en relación a las bases de datos orientadas a objetos y las normas aprobadas en la Primera Conferencia Internacional sobre Bases de Datos Deductivas y Orientadas a Objetos en Kyoto, Japón. Finalmente, se evaluarán los pros y contras de las bases de datos orientadas a objetos y los sistemas de administración de bases de datos orientadas a objetos conduciendo a conclusiones e ideas sugeridas para investigación y desarrollo futuro.
El modelo tradicional de bases de datos es el modelo Entidad-Relación (ER por sus iniciales en inglés - Entity-Relationship). En este modelo, los datos se organizan en filas (tuplas) y columnas (campos). A su vez, las tuplas se organizan en tablas. Las filas son instancias específicas de una entidad. Las columnas son características de esa entidad. Una tabla separada modelaría la relación entre dos entidades. En esta tabla, cada fila sería una relación, y cada columna sería el identificador único (Unique ID) de las dos entidades en la relación. Usando un Lenguaje de Consulta Estructurado (SQL por sus iniciales en inglés - Structured Query Language) las dos entidades podrían referenciarse en cruzado a través de la tabla relación. La unión, a través de la tabla, provee una relación entre las dos entidades.
Para entender totalmente las OODB y como difieren de los modelos relacionales, uno debe entender algunos t;érminos, los cuales fijan las restricciones impuestas por el OODM subyacente, a saber qué es un objeto. Las sutiles diferencias que se aplican a los conceptos de bases de datos y que permiten que la OODB sea una técnica de modelado mucho más fuerte que otras, y en algunos casos más fuerte que el modelo relacional, son importantes. Así, uno necesita un nivel inicial sobre el cual pueda construir la OODB sobre el OODM. Al nivel de abstracción más alto, de acuerdo con Rob y Coronel, un objeto está modelando una situación o entidad del mundo real al tener una identificación única, propiedades específicas a sí misma, y la habilidad de trabajar en conjunto con objetos tanto de la misma o distinta especificación [3]. Una entidad en un modelo ER no brinda este comportamiento.
La Identidad del Objeto (OID por sus siglas en inglés - Object IDentity ) provee el primer aspecto de un objeto, una identidad única. El sistema asigna una OID, y no es capaz de ser cambiado. De esta forma, dos objetos no pueden ser creados con la misma OID. Esta idea no debería confundirse con una clave primaria, ya que una clave primaria está compuesta de valor ingresados por el usuario, mientras una OID está asignada por el sistema. Al quitar un objeto del sistema, quita una OID del sistema y por definición el sistema nunca asignará a otro objeto esa misma OID [3].
Un objeto está definido por los atributos que describen la entidad del mundo real que está modelando. La terminología orientada a objetos usualmente se refiere a estos atributos como variables de instancia. Los atributos pueden ser de cualquiera de los tipos base soportados por un lenguaje de programación. Además de atributos de datos, los objetos usan atributos funcionales o métodos para cumplir con una restricción adicional impuesta por el OODM: interacción [3]. Los métodos permiten que los datos dentro del objeto sean accedidos y permiten acceder a estados o atributos de otros objetos.
Además de la definición anterior de un objeto, Rob y Coronel dicen que un OODM debe soportar como mínimo las siguientes características [3]:
La idea del OODM de una clase se asemeja a la idea de entidad de un conjunto de entidades o tabla del modelo ER. Como un objeto, las clases del OODM son más potentes que la idea de conjunto de entidades o tabla del modelo ER. Una clase no solo describe la estructura de datos, sino que describe el comportamiento de los objetos de esa clase. Características tales como métodos, los cuales permiten la descripción del comportamiento de los objetos, dan a una OODB capacidades completas para Tipos de Datos Abstractos (ADT por sus iniciales en inglés - Abstract Data Type) permitiendo un incremento en la semántica del objeto que se está modelando. Esta capacidad ADT completa también permite soporte de encapsulación y herencia. Estas capacidades proveen mecanismos para triggers (restricciones de tipo) en las bases de datos, los cuales sólo soportan unas pocas bases de datos SQL [3].
Como cualquier modelo de datos, una propiedad importante es como representa las relaciones entre los diferentes componentes de datos. La OODB tiene dos tipos: inter-clase (como se muestra en la Figura 1) o jerarquía de clases. Esto se contrasta con las relaciones basadas en valores del ER. Las relaciones basadas en valores se establecen sobre planos iguales o tipos de datos iguales entre dos tablas. En contraste, las relaciones en la OODB se basan en OID. Esto permite independencia entre el estado del objeto y la relación [3].
Otra diferencia entre bases de datos tradicionales y basadas en E-R es el soporte de versiones de las OODBs. Así como un documento puede tener múltiples versiones también puede tenerlas una base de datos. Este es especialmente un rasgo característico deseado para un sistema tal como CAD o CASE. Uno es capaz de cargar un sistema y cambiar aspectos para determinar como ésto afectaría al sistema en general. Luego el sistema original puede ser cargado nuevamente intacto [3].
Tradicionalmente, el acceso de datos puede verse como un modelo de almacenamiento de dos niveles [2]. Se necesita un vínculo entre la memoria virtual/principal de la computadora y el dispositivo de almacenamiento secundario para acceder a los datos contenidos en la base de datos. El usuario necesita los datos para analizarlos y usarlos. Para obtener los datos, el usuario realiza una consulta mediante SQL. SQL accede a los datos en un medio de almacenamiento secundario. Luego transforma y controla los tipos de los datos antes de transferirlos al usuario (ver Figura 2).
La OODB elimina la vista de almacenamiento de dos niveles y brinda una vista de un solo nivel. Una OODB no necesita SQL o una fase de transformación/control de tipos para traer los datos desde el almacenamiento secundario a la memoria. El usuario entonces instancia un objeto. Este objeto es el vínculo desde la memoria a la información en el almacenamiento secundario. Luego el usuario interactúa con el objeto el cual está en memoria para recibir los datos desde el almacenamiento secundario (ver Figura 3).
Otro aspecto del acceso de datos que uno debe abordar es el tema de vinculación temprana versus tardía (late versus early binding). En un modelo ER tradicional, el tipo de los datos se vincula tempranamente o en la definición de la estructura de la tabla [2]. En contraste, una OODB permite vinculación tardía de los tipos de datos o vinculación de los tipos de datos en tiempo de ejecución. En tal entorno, el tipo de una variable de instancia de un objeto no se conoce hasta que se utilice realmente, permitiendo así que se asigne cualquier tipo de datos [3]. En otras palabras, si uno tiene dos objetos de estudiantes diferentes (como se muestra en la Figura 1), el atributo Año puede usarse como un valor de carácter o un valor numérico. Uno no tiene que estar con el tipo de datos prescripto como en el modelo tradicional. La vinculación tardía además de los tipos de datos, provee una aspecto necesario para permitir polimorfismo o la elección de la implementación de un método de un objeto en tiempo de ejecución [3].
Una debilidad del OODM es la ausencia de acceso ad hoc a datos que SQL provee. Una propuesta está en camino, pero no hay realización en este punto [3].
Como se dijo en la introducción, el punto de este artículo es simplemente brindar una revisión de las características y aspectos de las características de una OODB y como se relaciona con los modelos ER tradicionales. Por otra parte, uno no puede abordar el tema de OODB sin brindar una solución de administración, la cual es un sistema de administración de bases de datos orientadas a objetos (OODBMS). Un OODBMS administra realmente el acceso a los datos y la consulta de los datos desde las bases de datos. Administra múltiples usuarios tratando de acceder a los datos al mismo tiempo, brinda servicio de recuperación de desastres, y administra todas las bases de datos en el sistema. Un OODBMS es un componente importante, ya que provee y administra las restricciones de las bases de datos.
Características como persistencia, control de concurrencia y transacciones y seguridad/administración todavía no están en un estándar establecido [2]. Para responder a este dilema se presentó el "Manifiesto de Sistemas Orientados a Objetos" en la Primera Conferencia Internacional sobre Bases de Datos Deductivas y Orientadas a Objetos en Kyoto, Japón. Brinda los siguientes "debería" para un OODBMS [1] (Nota: Clarificación se brinda desde [3]):
El Manifiesto es el primer intento de describir una norma en la cual deberían basarse los OODBMS. Es un primer paso importante hacia el acuerdo de los requisitos mínimos que un OODBMS debería soportar. Una vez que una norma esté en uso, los OODBMS y OODB se convertirán en corriente dominante mayor. Además, ya que es la lista de requisitos más significativa a ser compilada, la mayoría de los OODBMS se medirán contra ella.
De acuerdo a Rob y Coronel, los OODBMS brindan muchos beneficios más allá de los modelos tradicionales de bases de datos [3]. Pero hay debilidades que los OODBMS también tienen y no debieran ser pasadas por alto.
Los OODBMS proveen muchas ventajas. Estas ventajas son importantes porque resuelven muchos de los problemas que los sistemas tradicionales no pueden. Primero, la cantidad de información que puede modelarse con un OODBMS se incrementa, y también es más fácil modelar esta información. Aún más, los OODBMS brindan objetos complejos que permiten fácil integración de multimedia, CAD, y otras bases de datos especializadas. Los OODBMS también son capaces de tener mayores capacidades de modelado por medio de la extensibilidad. Con un OODBMS, uno sería capaz de agregar más capacidades de modelado, permitiendo de este modo modelar sistemas aún más complejos. Esta extensibilidad brinda una solución para incorporar bases de datos existentes y futuras en un solo entorno.
Además de ventajas de modelado, OODBMS un también tienen ventajas de sistema. En un OODBMS, el manejo de versiones está disponible para ayudar a modelar cambios diversos a los sistemas. Con el manejo de versiones, uno sería capaz de volver a conjuntos de datos previos, y comparar los conjuntos actuales con los anteriores.
La reutilización de clases juega un rol vital en el desarrollo y mantenimiento más rápido de aplicaciones. Las clases genéricas son potentes, pero más importante es que ellas pueden ser usadas nuevamente. Ya que las clases pueden reutilizarse, no se necesita diseñar material redundante. Esto lleva a la más rápida producción de aplicaciones y más fácil mantenimiento de dichas aplicaciones y bases de datos [3].
Mientras hay muchas ventajas para los OODBMS, también hay muchas desventajas. Los sistemas ER tradicionales han estado en el mercado por un largo tiempo y un cambio se apartaría de las ideas establecidas. Requeriría que la gente piense diferente, y en algunos casos los usuarios relacionales no tendrían la base de OO necesarias para trabajar con OODBMS. La educación de la gente en las bases de OO es un proceso muy minucioso. Requeriría gran cantidad de tiempo, dinero y otros recursos. También, y con motivo del cambio, se requeriría más tiempo para mover los datos a los nuevos OODBMS.
Otra desventaja es que habrá necesidad de haya una forma de que los sistemas tradicionales y los OODBMS se comuniquen y trabajen juntos. Los sistemas tradicionales y los OODBMS deben entenderse cada uno y las relaciones que representan. Al momento no hay tal sistema de comunicación y entendimiento.
Además, no existe un lenguaje de consulta ad hoc como SQL. Mientras es más fácil realizar consultas complejas con OODBMSs, no existe un lenguaje de consulta. Aún más, no hay actualmente normas para el diseño e implementación y ninguna parece probable en un futuro cercano. Los OODBMS podrían resolver problemas de los sistemas tradicionales, pero se necesita acordar una norma [3].
Los desarrollos futuros para las OODB deben incluir un lenguaje de consulta ad hoc para el usuario promedio. Este lenguaje debería proveer a las OODB lo que el SQL provee a las bases de datos tradicionales también, debe acordarse una norma para el diseño, la notación y la implementación. Los desarrollos futuros para las OODB podrían incluir un método más fácil de acceder desde Internet y la integración de ideas tales como XML o algo similar. Una iniciativa en este sentido es W3QL (por sus siglas en inglés - World Wide Web Query Language) [4]. Esta iniciativa permitiría que uno consulte la web como si fuera una base de datos. Por las enormes cantidades de información, la aproximación orientada a objetos podría resultar útil.
No hay duda que las ideas orientadas a objetos llegaron para quedarse y han influenciado los modelos relacionales tradicionales. La unión de estos dos pensamientos, programación orientada a objetos y sistemas de administración de bases de datos, brindan las bases para las bases de datos orientadas a objetos. El ser capaces de representar datos y relaciones, manejo de versiones, simplificación del acceso a datos son algunas de las características principales de las OODB. Los OODBMS deben incluir las trece características principales delineadas en el "Manifiesto de Sistemas Orientados a Objetos". Mientras hay muchos pros y contras para los OODBMS, están brindando formas para solucionar problemas y mecanismos por los cuales soluciones tradicionales pueden incorporarse en soluciones futuras. El desarrollo futuro es un campo abierto ya que todavía debe establecerse una norma para las OODB. Una vez que una norma se haya establecido para los OODBMS, podría convertirse en una norma de bases de datos. Como con todo cambio, no vendrá rápidamente, pero con la introducción de Internet y la enorme cantidad de datos que se examinan cuidadosamente, necesitarán alistarse soluciones como las OODB para manejarlos de manera satisfactoria.
Todd R. Manion es un estudiante de nivel avanzado no graduado trabajando en su grado de BSc en Ciencias de la Computación en el Colegio Mount Vernon Nazarene. Actualmente es el Vicepresidente de Asuntos Académios por la rama estudiantil y como Presidente del capítulo local de la ACM. Recientemente, Todd hizo una pasantía en Microsoft Corporation y planea volver a la industria luego de su graduación.
Last Modified:
Location: www.acm.org/crossroads/espanol/xrds7-3/objects.html