Es un hecho que la mayoría de los sistemas de información actuales se desarrollan utilizando lenguajes orientados a objetos. Dentro de este paradigma, los objetos en cierta manera representan objetos del mundo real. Por ejemplo, imaginemos una agenda que contiene una lista de personas con cero o más direcciones y números telefónicos. En el mundo de objetos, éstos se representarían como objetos “persona”, con atributos correspondientes a la información relevante a cada persona, como su nombre, una lista de teléfonos de diferentes tipos (casa, oficina, móvil) y otra lista de direcciones.
El problema llega cuando debemos almacenar esta información en algún medio permanente. Desde la perspectiva de un desarrollador, una posible solución sería utilizar un almacenamiento de objetos persistentes, en el que se almacenan objetos que pueden ser encontrados posteriormente. La mayoría de los lenguajes de objetos proveen algún mecanismo para lograr esto. Por ejemplo, en Java se pueden “serializar” los objetos y así almacenarlos en disco. Esto puede ser aceptable en la programación de sistemas de bajo nivel. Sin embargo, no sería útil en aplicaciones empresariales donde los usuarios deben poder acceder los datos de diferentes maneras y con diferentes clientes para obtener la información que requieran (reportes, análisis de datos, etc.). Adicionalmente, en aplicaciones empresariales el almacenamiento de información debe tener un alto desempeño y confiabilidad.
Como sabemos, la solución a todas estas necesidades de almacenamiento ya existe, y son las bases de datos. La solución que podría parecer ideal en principio sería utilizar bases de datos orientadas a objetos. Sin embargo, éstas no han logrado penetrar el mercado en general, por lo que en la mayoría de las ocasiones nos vemos obligados a recurrir a bases de datos relacionales (RDBMS). Como sabemos, casi todos los manejadores de bases de datos relacionales son previos al paradigma de objetos y el soporte que tienen hacia éste es bastante pobre.
Diferencias Entre Paradigmas
El mapeo entre objetos y relaciones no es algo trivial, ya que existen diferencias fundamentales entre estos modelos. La teoría relacional se centra en los datos, mientras que la de objetos se enfoca en el comportamiento. Estos son algunos de los aspectos en que difieren:
• Los objetos tienen un claro sentido de identidad y de propiedad de sus atributos. En cambio, en una base de datos es necesario construir queries utilizando llaves para relacionar y darle sentido a los datos que contienen las tablas.
• Dado que la información de un objeto típicamente abarca varias tablas, se requiere de varias sentencias o del uso de JOINS para obtener toda la información de un objeto.
• Las bases de datos realizan búsquedas a través de índices, pero no pueden ver objetos residentes en memoria.
• Los tipos de datos manejados por ambos modelos son diferentes.
• Las relaciones soportados por ambos modelos son diferentes. Por ejemplo, los RDBMS no soportan directamente la herencia.
• Los RDBMS proveen mecanismos para aislar y evitar cambios a ciertos registros (locking).
Object-Relational Mapping
De todo esto surge la necesidad de utilizar algún mecanismo para integrar la información contenida en nuestros objetos con los datos almacenados en el RDBMS. Esto típicamente se logra a través de una capa de traducción objeto-relacional. Tal estrategia es conocida como Object-Relational Mapping (ORM). Dependiendo de que tanto se apoyan en ORM, podemos clasificar las aplicaciones en las siguientes categorías:
Puramente relacional - Todo el sistema, incluyendo la interfaz de usuario, está diseñado en base al modelo relacional, utilizando statements de SQL dentro de los programas. Los queries se pueden ajustar directamente, pero a costa de poca portabilidad y dificultad en el mantenimiento. Las aplicaciones en esta categoría típicamente utilizan mucho los stored procedures, llevando la mayoría del trabajo de procesamiento hacia la capa de datos.
Mapeo de objetos sencillo - Las entidades se representan como clases que se mapean manualmente a las tablas en la base de datos. Las llamadas al RDBMS se separan de la lógica de negocio a través de algún patrón de diseño como el DAO (Data Access Object). Esta estrategia es muy común y tiene éxito en aplicaciones con entidades sencillas.
Mapeo de objetos medio - La aplicación se diseña en base a un modelo de objetos. Las sentencias SQL se generan en tiempo de ejecución a través un framework o generadores de código. Las asociaciones entre objetos son manejadas por el mecanismo de persistencia y es posible refinar el acceso a datos a través de expresiones en un lenguaje orientado a objetos. Típicamente se maneja un cache de objetos en la capa de persistencia. La mayoría de los productos ORM y soluciones desarrolladas internamente (in-house) soportan este nivel de funcionalidad. Este nivel es adecuado para aplicaciones de complejidad media, donde es importante la portabilidad hacia diferentes RDBMS.
Mapeo de objetos completo - Se soporta modelado de objetos complejo con composición, herencia, polimorfismo, etc. La capa de persistencia implementa persistencia transparente, esto es la capacidad de manipular los datos almacenados en el RDBMS directamente a través de objetos, sin tener que implementar alguna interfaz especial o heredar una clase. Se utilizan técnicas eficientes para la obtención y cacheo de información, las cuales son transparentes hacia la aplicación. Este nivel de funcionalidad es muy difícil de lograr a través de una solución in-house, ya que requiere meses o tal vez años de desarrollo.
Diferentes Técnicas
En el mercado existe una gran variedad de herramientas y productos para ORM. Conozcamos algunas de las técnicas más utilizadas por estas herramientas:
Mapeo directo sin identidad – El desarrollador crea clases con atributos de cuyo nombre se derivan las columnas de las tablas en la base de datos (o viceversa). Las herramientas examinan estas clases y generan los queries correspondientes. No se mantiene identidad basada en la llave primaria. Esto significa que es posible que en memoria existan dos objetos diferentes que corresponden a la misma hilera de una tabla. Si ambos objetos son actualizados, entonces se perderán los cambios en alguno de ellos. Esto implica que la lógica de la aplicación esté al pendiente de que esto no suceda.
Mapeo directo con identidad – Similar al anterior, pero se mantiene un índice (típicamente un hash table) de todos los registros residentes en memoria. De esta manera se asegura que no puedan existir dos objetos que correspondan a la misma hilera de una tabla. El inconveniente de esta estrategia es que la capa ORM debe responsabilizarse de administrar el ciclo de vida de los objetos, ya que la lógica de la aplicación no tendrá forma de saber cuando se deba eliminar un objeto compartido. Esto puede presentar complicaciones dependiendo del lenguaje de programación utilizado y los mecanismos que provea para administrar el ciclo de vida de los objetos.
EJB CMP - En el caso de J2EE, se puede utilizar la persistencia administrada por el contenedor o CMP. El desarrollador define clases abstractas para cada atributo de los objetos, y se generan métodos get/set que encapsulan el acceso a las variables. Se utiliza EJB QL, un lenguaje similar a SQL, para definir statements para acceder información.
JDO – JDO (Java Data Objects) es un API creado por Sun para abstraer la persistencia en los objetos. Los desarrolladores se apoyan en este API para lograr que la información de su modelo de dominio se almacene en la base de datos. A diferencia de CMP, JDO está diseñado para funcionar con cualquier tipo de objetos Java, no solamente EJBs. JDO ha tenido un gran éxito y se espera que la versión 3 de EJB se base en JDO.
Generación a partir de XML – Consiste en generar código a partir de definiciones escritas en XML. Es recomendable que el código generado no sea modificado posteriormente.
Autores varios, “Object Relational Mapping Articles”
www.service-architecture.com/object-relational-mapping/articles
Berglas, Anthony. “Object Relational Mapping Tools”
www.uq.net.au/~zzabergl/simpleorm/ORMTools.html
- Log in to post comments