Como hemos podido observar en la definición de ambos paradigmas de gestión e implementación de bases de datos, hay grandes diferencias entre el modelo más utilizado en la actualidad, el Modelo Relacional y el paradigma más utilizado en la informática en los últimos tiempos, el Modelo Objeto. En este apartado vamos a tratar de dar una visión global de ambos sistemas presentando las diferencias más importantes que se observan tratando de encontrar una explicación al hecho de que aún se siga utilizando en las bases de datos el modelo relacional y si, es mejor que el orientado a objetos, ¿por qué se sigue desarrollando este 2º modelo?
Una principal diferencia la vemos ya al comparar la definición de las unidades básicas de información de cada caso. El modelo relacional define las tuplas como “instancias específicas de una entidad” con un identificador único y las propiedades de esa entidad. En cambio, en el caso de las bases de datos orientadas a objetos, se almacenan los objetos que se definen como “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”. Las tuplas del modelo relacional carecen de esa habilidad de trabajar con otras tuplas ya que carecen de comportamiento. Además, el modelo objeto es capaz de representar situaciones del mundo real, en cambio el modelo relacional sólo trabaja con entidades, por lo tanto, si se quisiera modelar situaciones habría que adaptarlas, convirtiéndolas en entidades perdiendo por el camino parte de la información, o creando un modelo extremadamente complejo.
La identificación única de las entidades/objetos también difiere en ambos casos. El modelo relacional utiliza el concepto de Clave Primaria para identificar a sus entidades de una manera única. Esta clave es un valor que puede introducir y cambiar el usuario del sistema gestor con la única restricción de que no se repita con ninguna otra clave primaria que contenga la tabla en ese momento, aunque también puede asignarla el propio sistema gestor. En cambio, el modelo objeto define el OID (Object Identity) que proveerá el sistema y le otorgará al objeto su identidad única. No puede ser cambiado ni introducido por el usuario. Al desaparecer el objeto, el sistema elimina ese OID pero no vuelve a asignárselo nunca a ningún objeto nuevo.
Los modelos relacionales tradicionales sólo permitían tipos de datos simples ofrecidos por SQL y en última instancia por el sistema gestor. Esto hace bastante costoso trabajar con atributos multivaluados pudiendo hacerse este tratamiento de 2 formas, o bien saltándose la 1FN o separando esos atributos en más tablas lo que, sin duda, carga mucho el sistema y convierte las consultas en algo muy complejo. El modelo objeto, por definición provee de un sistema de tipos análogo al lenguaje de programación con el que se utiliza. De esta forma permite definir nuevas clases así como utilizar la herencia para extender las ya creadas. Así se consigue aplicar toda la potencia de la Orientación a Objetos en las bases de datos.
Los modelos relacionales utilizan el lenguaje estándar de consultas SQL, que es declarativo lo que hace que las consultas no vayan a la forma de encontrar el dato sino que sea el sistema gestor el que realice esta tarea. Además, el hecho de ser estándar permite que las aplicaciones lo utilicen sin importar el lenguaje de programación en el que están escritas. Por contra carga mucho el procesamiento y hace que haya que tratar los datos para convertirlos a objetos en el lenguaje de programación utilizado.
El modelo objeto difiere en este sentido bastante. Utiliza varios sistemas diferentes dependiendo de la implementación que se esté utilizando. Hay sistemas, directamente imbuidos en el lenguaje de programación que hacen esta recuperación de los datos transparente al programador, trabajando con los objetos persistentes como si fueran objetos de memoria normales. Esta visión es muy eficiente e intuitiva pero al no tener un lenguaje específico para trabajar con las consultas no controla de forma alguna este acceso siendo vulnerable a errores del programador.
Otra forma de implementar las consultas ha sido el estándar OQL (Object Query Language) definido por el Object Data Management Group (ODMG) que busca ser un estándar declarativo para consultas a bases de datos orientadas a objetos. Su uso sería análogo al de SQL pero, debido a su complejidad aún no hay ninguna implementación completa del estándar, sólo se han llegado a realizar subconjuntos como JDOQL y EJB QL.
La forma de trabajar con los datos persistentes en el modelo relacional es seleccionando los datos que queremos que persistan en el tiempo y grabándolos de manera explicita mediante consultas de alta/modificación de SQL, previa transformación de los datos. Los objetos trabajan de otra forma. Dependiendo de la implementación particular puede ser que haya clases persistentes, cuyos objetos siempre se almacenen en disco, marcar especiales para los objetos que permitan discriminar cuáles se almacenarán, y otras técnicas.
Esta es una de las partes más complejas de implementar de un sistema gestor de bases de datos orientados a objetos ya que se busca que este paso a datos persistentes sea lo más transparente posible para el programador de aplicaciones orientadas a objetos.
Obviamente el modelo objeto es una forma de centrar el desarrollo y explotación de un sistema en la semántica del dato. En el modelo relacional había que adaptar la semántica a las capacidades del sistema de una manera bastante estricta. En cambio, cuando trabajamos con objetos podemos aplicar la semántica propia del problema de una manera mucho más natural, ya que este paradigma se basa en modelar el mundo real.
Las relaciones entre entidades des modelo es una característica muy importante que cualquier base de datos moderna debe poseer. La orientación a objetos facilita mucho esta tarea gracias a los OID y a la herencia. Las relaciones de herencia, para lo cual se permite la herencia entre clases de la misma forma que en los lenguajes de programación, heredando el hijo todos los atributos y métodos que hubiera definido su padre. El resto de relaciones que hubiera que representar se haría mediante los OID que identifican univocamente a un objeto.
En las bases de datos relaciones, las relaciones de herencia se pueden simular mediante complejos sistemas que obligaban al programador a aplicar una serie de mecanismos que garantizaran la integridad. Y el resto de relaciones, por norma general crean una serie de tablas intermedias que complica las sentencias SQL necesarias para recuperar los datos.
El acceso a los datos, en la gran mayoría de los sistemas gestores de bases de datos orientados a objetos, se realiza de una forma navegacional, al estilo de los modelos jerárquico y red lo cual obliga al usuario a conocer la ruta de acceso a los objetos. Esto, además de complicar el uso para usuarios no programadores, unido a la necesidad de requisitos indirectos de hardware y software debido al uso de objetos ralentiza las transacciones respecto al modelo relacional, lo que lo convierte en muchos casos en algo inaceptable.
Las bases de datos orientadas a objetos permiten el almacenamiento de archivos multimedia ya que un objeto puede ser cualquier cosa. Las bases de datos relacionales no permiten esto y hay que simularlo guardando la dirección del archivo, con lo que no se garantiza que el archivo exista, o almacenando en un campo binario de longitud indeterminada el archivo completo sin capturar la propia base de datos de que tipo de archivo se trata.
Los sistemas gestores de bases de datos orientados a objetos proporcionan un importante control de versiones sobre los objetos almacenados, característica que junto a la capacidad de almacenar objetos multimedia antes citada, hace a estos sistemas muy válidos en campos como el CAD, aplicaciones científicas y otras aplicaciones igualmente específicas.
Bibliografía
ROB, Peter. CORONEL, Carlos. Sistemas de Bases de Datos. Diseño, Implementación y Administración. Thomson ed 5ª: Mexico. Enero de 2006, citada en Abril de 2010. Disponible electrónicamente en: http://books.google.es/books?id=B_UVi51RDY4C&lpg=PA562&ots=NezoMJpP7g&dq=uso%20actual%20OODB&pg=PP1#v=onepage&q&f=false
MANION, Tod R. ROGINA, Pablo J (Traducción). Objetos, Objetos en todos lados. Citado en Abril de 2010. ACM. Disponible electrónicamente en: http://www.acm.org/crossroads/espanol/xrds7-3/objects.html
Object Database. Citado en Abril de 2010. Wikipedia. Disponible electrónicamente en: http://en.wikipedia.org/wiki/Object_database
Comparison of object database management systems. Citado en Abril de 2010. Wikipedia. Disponible electrónicamente en: http://en.wikipedia.org/wiki/Comparison_of_object_database_management_systems
Object Data Management Group (ODMG). Citado en Abril de 2010. Wikipedia. Disponible electrónicamente en: http://en.wikipedia.org/wiki/Object_Data_Management_Group
SILBERSCHATZ, Avi. KORTH, Hank. SUDARSHAN, S. Fundamentos de Bases de Datos. McGraw Hill ed 5ª: España. 2006, citada en Abril de 2010.
Autor: Enrique Vázquez de Luis
1 comentario:
Tu explicación para mí que no poseo una educación formal en informática, pero me encanta el tema de bases de datos, me resultó muy útil para mejorar mis auto conocimientos sobre la diferencia, pro y contras entre un modelo de base de datos relacional y otro a objetos... Muchas Gracias por compartir tus conocimientos... miguelangel.bh
Publicar un comentario