Motores de Persistencia

Articulo cedido por Aurum Solutions, S.A. de C.V.

Es generalmente sabido que una aplicacin informtica consta de dos componentes principales que colaboran para llevar a cabo la funcionalidad que el usuario desea. El primero de estos componentes es la base de datos, que guarda la informacin necesaria para operar la aplicacin, en forma de datos en disco. El segundo de estos componentes es el programa propiamente dicho, que recupera esos datos de la base de datos, realiza los clculos necesarios y presenta los resultados deseados al usuario.

Para que estos dos componentes puedan funcionar juntos deben poder comunicarse intercambiando datos, como se observa en la figura 1. En otras palabras, deben ser compatibles. Sin embargo, durante los ltimos treinta aos la evolucin de estos dos componentes ha sido divergente, de forma que cada vez se ha hecho ms difcil que colaboren en una misma aplicacin.

As, desde los aos 70 a la actualidad, las bases de datos utilizan un modelo terico llamado relacional, que se ha convertido en un estndar y que es utilizado en la prctica totalidad de aplicaciones de software.

En cambio, los programas han usado, desde los aos 80, un modelo llamado orientado a objetos, que difiere en mucho del modelo relacional y que se ha extendido cada vez ms. Es por ello que aparece un conflicto a la hora de reunir estos dos componentes en una aplicacin, ya que cada uno responde a diferente modelo y forma de operar. Cada componente maneja los datos con un formato diferente. Metafricamente, podramos afirmar que el programa y la base de datos hablan idiomas diferentes y, por lo tanto, la comunicacin entre ellos resulta difcil.

Este artculo comienza con una descripcin de los dos modelos mencionados y de las diferencias que dificultan su combinacin en una sola aplicacin. A continuacin, se exploran las diferentes soluciones a este problema y se acaba concluyendo que la mejor manera de resolverlo es usando un motor de persistencia. El artculo finaliza indicando los nombres de los motores de persistencia ms usados, con el fin de que el lector pueda elegir el que ms se adapta a sus necesidades.

Modelo orientado a objetos

El modelo orientado a objetos es el modelo terico que usa la mayora de los programas actuales. La programacin orientada a objetos hunde sus races en los aos sesenta (en los que aparecieron los primeros lenguajes de este tipo, llamados Simula I y Simula 67, desarrollados en el Centro Noruego de Computacin, en Oslo). En los primeros 70, aparece Smalltalk, un lenguaje fundamental en la historia de la orientacin a objetos.

Sin embargo, no es hasta la segunda mitad de los aos 80 cuando la orientacin de objetos se generaliza, convirtindose en el estndar predominante en los aos 90, de la mano de lenguajes como C++ y Java. El triunfo de la programacin orientada a objetos ha sido impulsado por la enorme difusin de otras tecnologas (como la interfaz grfica o las arquitecturas distribuidas) que son ms fciles de implementar mediante este tipo de desarrollo que mediante una programacin tradicional.

Hoy en da, la prctica totalidad de los lenguajes de programacin que surgen son orientados a objetos y esta tecnologa se ha convertido en el estndar actual de programacin que, a su vez, est generando nuevos desarrollos muy prometedores para el futuro (como, por ejemplo, la programacin orientada a aspectos).

La idea de la orientacin a objetos es modelar los programas de una forma parecida a cmo percibimos la realidad. Para la mente humana, el universo est compuesto por una serie de objetos (en el sentido ms amplio de la palabra, incluyendo seres vivos, ideas, etc.). Cada objeto tiene unas caractersticas que lo diferencian de los dems y, con cada objeto, se pueden realizar unas acciones que son propias y especficas del mismo.

As, por ejemplo, un determinado auto tiene unas caractersticas (color rojo, caja de cambios automtica, diesel, etc.) y puede realizar unas determinadas acciones (acelerar, frenar, etc.).

La programacin orientada a objetos intenta modelar estos objetos reales con estructuras de programa, llamadas objetos de software o, simplemente, objetos. Cada uno de estos objetos de software, est compuesto por una serie de caractersticas (llamadas atributos) y una serie de acciones (llamadas mtodos), al igual que un objeto de la vida real. Una representacin grfica de un objeto de software se muestra en la figura 2.

La forma de programar estos objetos de software es similar a la forma en la que se comportan los objetos en la realidad. As, por ejemplo, en la vida real un auto contiene piezas. Anlogamente, en el programa, un objeto de software Auto contiene objetos Pieza, como podemos observar en la figura 3.

Es importante remarcar que el modelo orientado a objetos es un modelo que incluye tanto la parte esttica de un objeto (los atributos del mismo, es decir, sus caractersticas) como su parte dinmica (los mtodos, es decir, sus acciones). Usando una terminologa bien conocida en desarrollo, incluye tanto los datos como los procesos.

En resumen, la programacin orientada a objetos se basa en la realidad. Su mayor ventaja es que simplifica el mantenimiento de los programas y hace posible programar y mantener hasta los programas ms enormes al dividirlos en partes ms pequeas, es decir, en objetos. Como consecuencia, produce reducciones de costos y mayor calidad del cdigo y se ha convertido en el estndar actual de programacin.

Modelo relacional

Muy ajeno a la revolucin que supuso la orientacin a objetos, el rea de las bases de datos sigue fiel a un modelo antiguo pero que ha probado su eficacia, el llamado modelo relacional.

El modelo relacional se basa en un artculo publicado por E.F.Codd en 1970. Las primeras bases de datos relacionales comerciales aparecen en la segunda mitad de los aos setenta. Desde entonces, el modelo relacional se convierte en un estndar prcticamente universal para el acceso a datos, dominando totalmente el rea de las bases de datos hasta la actualidad.

El modelo relacional es muy diferente del modelo orientado a objetos. Por una parte, el modelo relacional slo se ocupa de la parte esttica de la aplicacin (de los datos) y no de la parte dinmica (los procesos). Usando el ejemplo anterior, en el modelo relacional, slo me interesan las caractersticas del auto (su color, su tipo de caja de cambios, etc) y no las acciones que puedo hacer con l (acelerar, frenar, etc.) . Este nfasis en los datos es lgico en un modelo cuyo objetivo es modelar la parte esttica de la aplicacin, es decir, la base de datos.

Hay otras diferencias entre los dos modelos. Por ejemplo, la forma en la que el modelo relacional trata los datos es muy diferente a cmo lo hace el modelo orientado a objetos. Mientras en este ltimo, los datos son modelados en forma de objetos, en el modelo relacional son modelados como registros, los cuales son una serie de datos pertenecientes a una misma entidad de la vida real. Un registro difiere de un objeto en que slo modela datos y que stos no tienen estructura. La representacin grfica de un registro aparece en la figura 4.

Los registros similares se agrupan en tablas. Podemos imaginarnos las tablas como listados de datos parecidos a los listados de impresin que hay en las empresas (de empleados, de facturas, etc.). En esta comparacin, cada registro sera una lnea del listado.

Usando el ejemplo anterior, cada registro contendra los datos de un determinado auto (color rojo, caja de cambios automtica, diesel, etc.) y las tablas no seran ms que listas de autos con todos sus datos, como se observa en la figura 5.

El modelo relacional no refleja la estructura de la realidad. Como hemos dicho, si un auto contiene piezas, un objeto de software Auto contiene objetos Pieza. Sin embargo, en el modelo relacional, los registros de los autos y piezas estn por separado (esto se muestra en la figura 5) y se relacionan por un mecanismo implcito llamado clave fornea. El programador debe saber que hay una relacin entre los autos y las piezas y debe programar de acuerdo a ello. Sin embargo, el modelo no refleja explcitamente esta relacin y, en general, la estructura de la realidad, al contrario del modelo orientado a objetos.

Aplicaciones tradicionales

Como conclusin de lo que se ha dicho hasta ahora, una aplicacin est formada por un programa y una base de datos que se comunican entre s. El programa suele estar diseado segn el modelo orientado a objetos y, por lo tanto, trabaja con datos en formato de objetos. Por el contrario, la base de datos est diseada segn el modelo relacional y, por lo tanto, trabaja con datos en formato de registros. Esto introduce una dificultad importante, porque los dos formatos de datos (objetos y registros) son incompatibles entre s. As, cuando el programa quiere guardar o recuperar los datos en disco (para que no se pierdan entre ejecuciones), lo hace n forma de objetos, pues es el formato de datos que conoce. Sin embargo, la base de datos no puede guardar o recuperar objetos, pues est diseada para guardar o recuperar registros (y no objetos), que es el formato de datos que ella reconoce. Esto se muestra en la figura 6. Resumiendo, los formatos de datos que utilizan el programa y la base de datos son incompatibles entre s. Podemos decir que el programa y la aplicacin hablan idiomas diferentes y, por lo tanto, debemos encontrar una solucin para que se comuniquen.

La solucin ms obvia a este problema es hacer que uno de los componentes hable el idioma del otro. Es decir, que un componente use el formato de datos del otro. As, la primera opcin que examinamos en este artculo es la de que el programa est diseado para tratar con datos relacionales, la cual se refleja en la figura 7. En esta opcin, tanto el programa como la base de datos hablan un mismo idioma: el relacional y utilizan como formato de datos el de registro. Por lo tanto, la comunicacin es posible.

sta era la forma de programar universalmente adoptada antes de la aparicin de la orientacin a objetos y sigue siendo la arquitectura dominante en El Salvador. An entre las empresas que utilizan lenguajes orientados a objetos, la mayora programa sin tener en cuenta la orientacin a objetos a la hora de usar los datos, los cuales se gestionan de forma relacional.

El problema de esta arquitectura es que se desaprovechan las grandes ventajas de flexibilidad, facilidad de mantenimiento y facilidad de gestin de sistemas complejos que da la programacin orientada a objetos. Asimismo, el cdigo que opera con datos relacionales suele ser complejo, difcil de mantener y de ampliar y muy dependiente de la estructura de los datos.

Bases de datos orientadas a objetos

Como hemos visto en el apartado anterior, la opcin consistente en que toda la aplicacin use un mismo modelo terico relacional no es la ms adecuada. Examinemos ahora la opcin en que toda la aplicacin tenga un nico modelo terico, pero que ste sea el de orientacin a objetos. Esta opcin, que se refleja en la figura 8, implica que el formato de datos que usa toda la aplicacin es el formato de objetos.

Para un programa resulta natural trabajar con objetos. Sin embargo, esto es imposible para las bases de datos tradicionales, basadas en el modelo relacional. Para resolver este problema han aparecido las bases de datos orientadas a objetos. Al contrario de sus homlogas relacionales, que trabajan con registros, las bases de datos orientadas a objetos guardan y recuperan objetos. Por lo tanto, la comunicacin de este tipo de base de datos con un programa orientado a objetos es posible.

Aunque, sobre el papel, sta es la mejor opcin para implementar una aplicacin de base de datos, en la prctica presenta una serie de problemas importantes, debido a las caractersticas actuales de las bases de datos orientadas a objetos. stas no estn tan maduras como sus homlogas relacionales y, por lo tanto, no gozan de la abundancia de herramientas, la fiabilidad, facilidad de administracin y rendimiento de estas ltimas.

Lo que es peor, las bases de datos orientadas a objetos frecuentemente son incompatibles entre ellas. Esto hace imposible migrar una aplicacin desde una base de datos orientada a objetos a otra, lo que nos obliga a depender de un nico proveedor (fenmeno conocido como vendor lock-in), con todas las incoveniencias que esto supone (obligacin de aceptar los aumentos de precio del proveedor, falta de soporte si el proveedor sale del mercado, etc.).

Como conclusin, aunque sta pueda ser la opcin preferible en un futuro, en el que las bases de datos orientadas a objetos alcancen una madurez y estandarizacin suficientes, en el presente resulta arriesgado aplicarla.

Motores de persistencia

Hemos visto que las opciones que se basan en imponer un nico modelo terico (un nico formato de datos) a toda la aplicacin padecen de graves inconvenientes. En el caso de que toda la aplicacin siga el modelo relacional, perdemos las ventajas de la orientacin a objetos. En el caso de que toda la aplicacin siga el modelo orientado a objetos, tenemos que las bases de datos que debemos usar estn inmaduras y tienen un bajo nivel de estandarizacin.

Examinemos ahora la opcin de que el programa sea orientado a objetos y la base de datos sea relacional, lo que, en principio, constituye la opcin ms natural. Sin embargo, plantea el problema de cmo hacemos que dos componentes con formatos de datos muy diferentes puedan comunicarse y trabajar conjuntamente. Siguiendo la metfora anterior, se trata de hacer que dos personas que hablan idiomas diferentes se comprendan.

La solucin es la misma que se dara en la vida real. Se debe encontrar un traductor que sepa traducir de cada idioma al otro. De esta forma, las dos personas se entendern sin necesidad de que uno hable el idioma del otro. En el mundo de la programacin este traductor no es ms que un componente de software (concretamente, una capa de programacin), al que se le dan los nombres de capa de persistencia, capa de datos, correspondencia O/R (OR mapping) o motor de persistencia.

El motor de persistencia traduce entre los dos formatos de datos: de registros a objetos y de objetos a registros. La situacin se ejemplifica en la figura 9. Cuando el programa quiere grabar un objeto llama al motor de persistencia, que traduce el objeto a registros y llama a la base de datos para que guarde estos registros. De la misma manera, cuando el programa quiere recuperar un objeto, la base de datos recupera los registros correspondientes, los cuales son traducidos en formato de objeto por el motor de persistencia.

El programa slo ve que puede guardar objetos y recuperar objetos, como si estuviera programado para una base de datos orientada a objetos. La base de datos slo ve que guarda registros y recupera registros, como si el programa estuviera dirigindose a ella de forma relacional. Es decir, cada uno de los dos componentes trabaja con el formato de datos (el idioma) que le resulta ms natural y es el motor de persistencia el que acta de traductor entre los dos modelos, permitiendo que los dos componentes se comuniquen y trabajen conjuntamente.

Esta solucin goza de las mejores ventajas de los dos modelos.

  • Por una parte, podemos programar con orientacin a objetos, aprovechando las ventajas de flexibilidad, mantenimiento y reusabilidad.
  • Por otra parte, podemos usar una base de datos relacional, aprovechndonos de su madurez y su estandarizacin as como de las herramientas relacionales que hay para ella.

Se calcula que un motor de persistencia puede reducir el cdigo de una aplicacin en un 40%, hacindola menos costosa de desarrollar. Adems, el cdigo que se obtiene programando de esta manera es ms limpio y sencillo y, por lo tanto, ms fcil de mantener y ms robusto. Por aadidura, el motor de persistencia no slo simplifica la programacin, sino que permite hacer ciertas optimizaciones de rendimiento que seran difciles de programar por nosotros mismos.

Como conclusin, sta es la mejor opcin en la actualidad para implementar una aplicacin de software.

Opciones para motores de persistencia

Una ventaja del motor de persistencia es que es el mismo para todas las aplicaciones. De esta forma slo debe programarse una vez y puede usarse para todas las aplicaciones que se desarrollen en nuestra empresa. Sin embargo, un motor de persistencia es difcil de programar y de mantener, por lo que necesita un gran esfuerzo en costo y tiempo de desarrollo.

Es por ello que hay dos opciones a la hora de usar un motor de persistencia:

  • Programarlo dentro de nuestra empresa. Como se ha dicho, esto no es lo ms recomendable, por la complejidad y costo que introduce esta opcin.
  • Utilizar un motor que ya est programado, comprndolo a un vendedor o bien usando un motor gratuito de cdigo abierto.

Se recomienda fuertemente la segunda opcin, que es la menos costosa y la menos propensa a fallos. Se debe escoger un motor de persistencia de los que estn programados, estudiarlo y aplicarlo a todas las aplicaciones de una misma empresa. A continuacin, explicamos algunos de los motores de persistencia ms importantes para la plataforma Java y para la plataforma .NET, con el fin de que el lector pueda comenzar una investigacin que le lleve a escoger el que ms se ajuste a sus necesidades.

En cuanto a la plataforma Java, los servidores de aplicaciones basados en la especificacin EJB (Enterprise JavaBeans), incorporan un motor de persistencia a travs del mecanismo conocido como entity beans. Sin embargo, los entity beans no son un mecanismo de persistencia totalmente recomendable, pues no permiten implementar algunas caractersticas de la programacin orientada a objetos (por ejemplo, herencia) y adems, obligan a una forma de programar diferente a los objetos normales de Java (o POJOs, por Plain Old Java Objects).

Hay motores de persistencia ms completos que no tienen este tipo de inconvenientes que se acaba de mencionar. Entre los de cdigo abierto podemos destacar: Hibernate, Castor, Torque, OJB y Cayenne. Entre los comerciales, podemos destacar TopLink, Cocobase y FastObjects. En los ltimos aos se ha creado una especificacin llamada JDO, para estandarizar la forma de programar en Java con esos motores de persistencia. Ejemplos de motores de persistencia que cumplen el estndar JDO son Kodo, JDO Genie, LiDo, Exadel JDO, IntelliBO, JRelay JDO (todos ellos comerciales), TJDO y XORM (de cdigo abierto).

La plataforma .NET, por su relativa novedad, est ms inmadura que la plataforma Java. Adems, al ser una plataforma propietaria, cuesta ms encontrar proyectos de cdigo abierto para ella. Por todo ello que no hay tanta variedad de motores de persistencia en esta plataforma. Recientemente, Microsoft ha anunciado un motor de persistencia llamado Objectspaces para .NET 2004. Mientras tanto, se puede usar ORM.NET, que es un motor de persistencia comercial para .NET.

COMPARTE ESTE ARTÍCULO

ENVIAR A UN AMIGO
COMPARTIR EN FACEBOOK
COMPARTIR EN TWITTER
COMPARTIR EN GOOGLE +
ARTÍCULO ANTERIOR

SIGUIENTE ARTÍCULO

¡SÉ EL PRIMERO EN COMENTAR!
Conéctate o Regístrate para dejar tu comentario.