Conceptos sobre la funcionalidad de la capa de persistencia

Asociación Objeto-Relacional

La asociación objeto-relacional (más conocido por su nombre en inglés, Object-Relational Mapping, o sus siglas O/RM, ORM, y O/R mapping) es una técnica de programación para convertir datos entre el sistema de tipos utilizado en un lenguaje de programación orientado a objetos y el utilizado en una base de datos relacional. En la práctica esto crea una base de datos orientada a objetos virtual, sobre la base de datos relacional. Esto posibilita el uso de las características propias de la orientación a objetos (básicamente herencia y polimorfismo). Hay paquetes comerciales y de uso libre disponibles que desarrollan la asociación relacional de objetos, aunque algunos programadores prefieren crear sus propias herramientas ORM.

Un objeto está compuesto de propiedades y métodos. Como las propiedades representan a la parte estática de ese objeto, son las partes que se dotan de persistencia. Cada propiedad puede ser simple o compleja.

• Por simple, se entiende que tiene algún tipo de datos nativos como por ejemplo: entero, coma flotante o cadena de caracteres.
• Por complejo se entiende algún tipo definido por el usuario, ya sean objetos o estructuras.

Por relación se entiende asociación, herencia o agregación. Para dotar de persistencia las relaciones, se usan transacciones, ya que los cambios pueden incluir varias tablas.

Para vincular las relaciones, se usan los identificadores de objetos (OID). Estos OID se agregan como una columna más en la tabla donde se quiere establecer la relación. Dicha columna es una clave foránea a la tabla con la que se está relacionada. Así, queda asignada la relación. Recordar que las relaciones en el modelo relacional son siempre bidireccionales.

Manejo de la caché

En la mayoría de las aplicaciones, se aplica la regla del 80-20 en cuanto al acceso a datos, el 80% de accesos de lectura accede al 20% de los datos de la aplicación. Esto significa que hay un conjunto de datos dinámicos que son relevantes a todos los usuarios del sistema, y por lo tanto accedido con mas frecuencia. Las aplicaciones de sincronización de caché normalmente necesitan escalarse para manejar grandes cargas transaccionales. Así, múltiples instancias se pueden procesar simultáneamente.

Es un problema serio para el acceso a datos desde la aplicación, especialmente cuando los datos involucrados necesitan actualizarse dinámicamente a través de esas instancias. Para asegurar la integridad de datos, la base de datos comúnmente juega el rol de árbitro para todos los datos de la aplicación. Es un rol muy importante dado que los datos representan la parte de valor más significativa de una organización. Desafortunadamente, este rol no está fácilmente distribuido sin introducir problemas importantes, especialmente en un entorno transaccional.

Es común para la base de datos usar replicación para lograr datos sincronizados, pero comúnmente ofrece una copia offline del estado de los datos más que una instancia secundaria activa. Es posible usar bases de datos que puedan soportar múltiples instancias activas, pero se pueden volver caras en cuanto a mantenimiento y escalabilidad, debido a que introducen el bloqueo de objetos y la latencia de distribución. La mayoría de los sistemas usan una única base de datos activa, con múltiples servidores conectados directamente a ella, soportando un número variable de clientes.

En esta arquitectura, la carga en la base de datos se incrementará linealmente con el número de instancias de la aplicación en uso, a menos que se emplee alguna caché. Pero implementar un mecanismo de caché en esta arquitectura puede traer muchos problemas, incluso corrupción en los datos, porque la caché en el servidor 1 no conocerá los cambios en el servidor 2.

Concurrencia de usuarios

La capa de persistencia debe permitir que múltiples usuarios trabajen en la misma base de datos y proteger los datos de ser escritos erróneamente. También es importante minimizar las restricciones en su capacidad concurrente para ver y acceder.

La integridad de datos es un riesgo cuando dos sesiones trabajan sobre la misma tupla: la pérdida de alguna actualización está asegurada. También se puede dar el caso, cuando una sesión está leyendo los datos y la otra los está editando: una lectura inconsistente es muy probable.

Hay dos técnicas principales para el problema: bloqueo pesimista y bloqueo optimista. Con el primero, se bloquea todo acceso desde que el usuario empieza a cambiar los datos hasta que se hace COMMIT en la transacción. Mientras que en el optimista, el bloqueo se aplica cuando los datos son aplicados y se van verificando mientras los datos son escritos.

En la mayoría de los casos el bloqueo optimista es suficiente, controlando los lost-updates. Para casos concretos, por ejemplo en los que se necesite generar algo como un número de factura sin que queden huecos entre uno y otro se podría usar el bloqueo pesimista.