En la actualidad, el uso de las Bases de Datos Orientadas a Objetos no está muy extendido. Bajo nuestra opinión, esto se debe a varios factores:
Ausencia de una implementación completa del estándar desarrollado por el ODMG: Ninguna implementación real se ha ceñido estrictamente al estándar, debido a su complejidad. Por lo tanto no hay un referente a seguir y no se soportan cosas mejores que las bases de datos relacionales, en conjunto, aunque si en partes específicas.
SQL: La evolución de este lenguaje de consulta es uno de los grandes “lastres” que ralentizan la evolución e implantación de los sistemas orientados a objetos. Las versiones de 1999 y 2003 de este estándar ya definen una forma de acceso similar a la orientada a objetos, así como un mecanismo de definición, extensión y herencia de tipos de datos, por lo tanto los sistemas Orientados a Objetos, en muchos casos carecen de sentido.
Frameworks de trabajo con bases de datos: Este punto está muy relacionado con el anterior. En poco tiempo han surgido una inmensa cantidad de frameworks para lenguajes de programación orientados a objetos, que hacen que el trabajo con la base de datos sea transparente y aparentemente orientado a objetos debido a que mapean los resultados de las consultas en objetos directamente. Esto, unido a que utilizan una serie de patrones y buenas prácticas (DAO, factorías, variaciones protegidas...) han extendido mucho su uso y evitado la necesidad de las nuevas bases de datos.
XML: Este lenguaje estándar de marcas también se puede considerar una causa del lento avance de la orientación a objetos en bases de datos ya que se ha mostrado como una muy eficiente forma de almacenamiento, de acceso rápido y trabajo sencillo.
Baja complejidad de la mayoría de las aplicaciones: Las aplicaciones que se desarrollan en la actualidad son, en general, de una complejidad baja, basadas en el mantenimiento y gestión de entidades sencillas y fácilmente modelables con los sistemas relacionales. Esto hace que la orientación a objetos sólo avance y se utilice en ámbitos muy concretos debido a la pronunciada curva de aprendizaje que tienen que, en la mayoría de los casos no merece la pena para una aplicación web sencilla o una aplicación de escritorio de la que ya existen infinidad de modelos de ejemplo.
Detractores reconocidos: Hay muchos eruditos de las bases de datos que son detractores de las bases de datos orientadas a objetos por opinar que el modelo relacional es capaz de resolver los problemas que se le planteen ya que es muy potente además de contar con una base matemática, de la que el modelo objeto carece. Un ejemplo de esta afirmación son las opiniones que da C. J. Date sobre las bases de datos orientadas a objetos ya que opina que su única aportación útil es la capacidad de definir tipos de datos de muy alta complejidad y que eso ya lo da la buena definición de dominios del modelo relacional, por lo tanto, el modelo relacional es tan poderoso como el orientado a objetos.
Todas estas razones causan el lento avance de las bases de datos orientadas a objetos. Pero deja una evidencia clara de que hay un abismo que hay que salvar debido a que el resto de ramas de la informática cada vez son más semánticos, más basados en clases, objetos, herencia y otros principios. No podemos olvidarnos de que, en los orígenes del modelo relacional, cuando aún no existían implementaciones eficientes, muy pocos creían que ese, conceptualmente, muy poderoso modelo, llegaría a sustituir a los modelos jerárquico y de red. Se tardaron muchos años en cambiar al modelo relacional y se afianzó.
El modelo objeto aún es muy joven, se basa en ideas avanzadas y diferentes de las tradicionales. Es un modelo difícil de comprender en su totalidad y “cambiar el chip” para pensar orientado a objetos.
En cualquier caso, se ha demostrado que el modelo objeto es muy poderoso y facilita mucho la tarea de programadores y diseñadores además de capturar mucha más semántica del mundo real y por lo tanto buscamos acercarnos a él.
Se ha tratado este acercamiento en varios frentes, sin acabar del todo con el modelo relacional. Un ejemplo de esto son los, ya citados, frameworks de acceso a datos para los diferentes lenguajes que “atacan” el problema en el programa. O las últimas versiones de SQL 3 que permite unas consultas y definiciones de datos muy cercanas al modelo objeto, con lo que se trata de acercar en las consultas.
Un último lugar dónde se puede producir este amoldamiento del modelo relacional al objeto es en el propio sistema gestor de bases de datos. Así surgen los modelos Objeto/Relacionales. Estos sistemas emulan el funcionamiento de un sistema gestor de bases de datos orientado a objetos pero, internamente, trabajan con un modelo relacional. En ellos se ha definido una capa intermedia, a la que acceden las aplicaciones, que será la que permita un acceso directamente orientado a objetos y se encargará de traducir las peticiones a consultas, recuperar los datos y transformarlos en objetos, de manera parecida a cómo lo hacen los frameworks, pero directamente imbuido en el gestor.
Un ejemplo de estos sistemas sería PostGreSQL (considerado a veces como un sistema gestor orientado a objetos completamente).
Como sistemas Objeto/Relacionales también cabría definir los sistemas orientados a objetos, que suplen las carencias de la ausencia de implementación estándar de OQL permitiendo el uso de SQL en sus consultas pero apenas se encuentran ejemplos de este caso.
Finalmente, hablaremos un poco de las implementaciones que existen de sistemas orientados a objetos. Un primer modelo que se trata, según algunos autores, de esta forma serían los modelos objeto relacionales de los que ya hemos hablado.
Otra posible implementación existente es la de sistemas gestores de bases de datos orientados a objetos. Algunos ejemplos de estos sistemas son: Caché, Zope o incluso una implementación de Oracle orientada a objetos. Estos gestores buscan cierta independencia del lenguaje de programación utilizado para la aplicación que accederá a ellas, siempre con limitaciones debido a la diferencia entre unos lenguajes y otros y que el modelo objeto busca, precisamente, ser más eficiente con los lenguajes debido a su cercanía.
La 3º forma implementada de estas bases de datos es como extensiones directas de lenguajes de programación orientados a objetos. Esto, por supuesto, crea una dependencia total del lenguaje de programación pero, por a favor tiene que es muchísimo más eficiente y transparente el acceso y recuperación de objetos, así como la creación o eliminación de los mismos. En un principio fueron las implementaciones más utilizadas ya que eran relativamente sencillas de conseguir, pero muchas se quedaron por el camino. Hoy en día podemos encontrar algunos ejemplos como ObjectStore para C++ o JDO (Java Database Objects) para java.
Estas extensiones de los lenguajes se diferenciaban unas de otras, dentro de un mismo lenguaje, normalmente en la forma en que manejaban la persistencia de objetos, así por ejemplo ObjectStore maneja punteros persistentes almacenados en punteros normales. Estos punteros persistentes apuntaban a los objetos almacenados en disco y al cargarlos en memoria se sustituían por punteros normales que se transformaban en punteros persistentes al devolver a memoria los objetos. En cambio, la extinta norma ODMG para C++ definía la clase de plantillas d_Ref< T > para manejar punteros persistentes a la clase T.
Como hemos visto, hay muchas implementaciones y acercamientos diferentes a la orientación a objetos lo que nos demuestra que, lentamente, se va tendiendo a ello. Pero aún queda un largo camino por recorrer para ver si se convierten en una completa alternativa al modelo relacional o verdaderamente el modelo relacional es lo suficientemente potente como para resistir ese avance.
Lo que está claro es que el modelo relacional no se adapta del todo bien a las novedosas aplicaciones de computación en nube, computación grid, complejos sistemas de cálculo, necesidades multimedia o aplicaciones de diseño asistido por ordenador. Aplicaciones para las que el modelo objeto está demostrando su eficiencia.
Bibliografía
