En el desarrollo de una aplicación suelen estar involucradas dos entidades diferentes, por una parte  el código que mueve la aplicación y por otra los datos que se manejan. Con el tiempo estas dos entidades han evolucionado de manera diferente, y el acceso a los datos desde los programas se ha vuelto una tarea en ocasiones, complicada. Los sistemas de Mapeo Objeto-Relacional u ORM ayudan a combatir esta complicación.

En este artículo se verá una definición de estos sistemas, así como algunos ejemplos de motores ORM empleados en la actualidad de manera comercial.

Origen de los conflictos: Las bases de datos relacionales

En un principio los programas accedían físicamente al disco para escribir los datos, algo que implicaba que el programa tuviese que implementar toda la lógica de una base de datos para permitir agregar, modificar o eliminar datos.

Con el tiempo se han desarrollado lo que se conoce como sistemas de bases de datos relacionales, que permiten mantener entidades (Artículo, Ficha médica o Factura), sus respectivas relaciones (Una ficha médica corresponde a un solo paciente) y sus atributos (Una ficha médica contiene fecha de entrada, fecha de salida, síntomas… etc).

Estos sistemas poseen además una interfaz para acceder a ellos llamada SQL o Structured Queried Language (lenguaje estructurado de consultas) que permiten hacer peticiones de una base de datos usando una notación muy similar a lenguaje natural, como muestra el siguiente ejemplo:

    select nombre,apellidos from pacientes where id_paciente = 1;

Este código tendría como objetivo hacer una petición a la base de datos pacientes, buscar el identificador 1 y devolver la fila (o filas) resultante de la petición.

Estos sistemas permiten mantener cierta integridad de los datos, y usando ciertas reglas se pueden definir tablas y restricciones como muestra el siguiente ejemplo:

    create database pacientes(
        id_paciente int,
        nombre varchar(80),
        apellidos varchar(120)
    );

Entre los sistemas gestores de bases de datos más utilizados se encuentran:

• SQL Server de Microsoft: Es la solución por excelencia del stack Microsoft. Existen al menos una docena de ediciones diferentes dirigidas a un público específico, desde la versión Express, gratuita y con limitaciones (1 GB de consumo de memoria y 4 GB de capacidad) hasta la Datacenter, que permite el uso de 256 núcleos (poca cosa…)  y dirigida a un mercado empresarial.

• mySQL: Anteriormente propiedad de Sun Microsystems y con doble licencia (libre para proyectos compatibles con la licencia GNU GPL y privativa para el resto de los proyectos, que implica la compra de una licencia), actualmente propiedad de Oracle, es la base de datos más empleada por la comunidad OpenSource (+6.000.000 de instalaciones).

• PosgreSQL: Empleada en ámbito docente aunque no por ello menos potente que la anterior, libre (licencia BSD) y mantenida por la comunidad de desarrolladores.

• Oracle: Considerado por muchos uno de los sistemas de bases de datos más complejos, usado fundamentalmente en el mercado de servidores empresariales donde su hegemonía ha sido casi total hasta hace poco, por la competencia del resto de sistemas antes mencionados. Posee también una versión Express (gratuita)

Antes de los ORM

Antes de la aparición de estos sistemas las consultas se tenían que realizar a mano dentro de las propias aplicaciones, con lo cual la ventaja de los lenguajes orientados a objetos se perdía, ya que había que crear una petición a la base de datos de manera manual (y específica para cada sistema, ya que no todos los gestores de bases de datos tienen la misma implementación del lenguaje SQL).

Para muestra, un ejemplo que se puede encontrar en la documentación del lenguaje PHP:

// El siguiente código puede ser proporcionado por el usuario, a modo de ejemplo
$firstname = 'fred';
$lastname  = 'fox';

// Formular Consulta
// Este es el mejor método para formular una consulta SQL
// Para más ejemplos, consulte mysql_real_escape_string()
$query = sprintf("SELECT firstname, lastname, address, age FROM friends
    WHERE firstname='%s' AND lastname='%s'",
    mysql_real_escape_string($firstname),
    mysql_real_escape_string($lastname));

// Ejecutar Consulta
$result = mysql_query($query);

// Comprobar resultado
// El siguiente código muestra la consulta enviada a MySQL y el error ocurrido. Útil para debugging.
if (!$result) {
    $message  = 'Invalid query: ' . mysql_error() . "\n";
    $message .= 'Whole query: ' . $query;
    die($message);
}

// Usar resultado
// Si intenta imprimir $result no será posible acceder a la información del recurso
// Una de las funciones mysql result debe ser usada
// Consulte también mysql_result(), mysql_fetch_array(), mysql_fetch_row(), etc.
while ($row = mysql_fetch_assoc($result)) {
    echo $row['firstname'];
    echo $row['lastname'];
    echo $row['address'];
    echo $row['age'];
}

// Libere los recursos asociados con el resultset
// Esto es ejecutado automáticamente al finalizar el script.
mysql_free_result($result);

Como se aprecia, es necesaria una adaptación de los datos a la aplicación además del aprendizaje del lenguaje de gestión de las bases de datos.

El mapeo relacional

La ventaja principal de estos sistemas es que reducen la cantidad de código necesario para lograr lo que se conoce como una persistencia de objetos

Esto permite además, lograr una integración con otros patrones como el Modelo-Vista-Controlador, donde el modelo puede ser este objeto. En el ejemplo siguiente se muestra cómo se define un modelo usando Doctrine, uno de los sistemas ORM más usados para PHP, donde se muestra el tipo usuario y los campos username y password. Será el propio sistema el que se encargue de convertir esta información a tablas SQL y a realizar el procesamiento, mientras que nosotros trabajaremos fundamentalmente con objetos

class User extends Doctrine_Record
{
    public function setTableDefinition()
    {
        $this->hasColumn('username', 'string', 255);
        $this->hasColumn('password', 'string', 255);
    }
}

Este otro ejemplo, que usa ADO.net Entity Framework, el ORM de .NET, se pueden apreciar también la facilidad para establecer propiedades a campos, como en este caso establecer obligatoriedad.

namespace MyApp.Models
{
    public class User
    {
        public int Id { get; set; }
        [Required] public string UserName { get; set; }
        [Required] public string Password { get; set; }
    }
}

Motores de persistencia

Estos son algunos motores de persistencia a los que he podido echar un vistazo, algunos forman parte de frameworks más potentes (Como Core Data en el caso de iOS) y otros son independientes (como el anteriormente mencionado Doctrine), aunque todos comparten la misma base, dar un modelo de persistencia de objetos.

• C#: Entity Framework es un conjunto de APIs que proporcionan acceso a datos en .NET. Se distribuye junto con el .NET framework y tiene 3 posibles modos de trabajo, Database First, Model First y Code First, más información en el sitio oficial

• Java: Hibernate es una herramienta de mapeo relacional para la plataforma Java, que emplea atributos declarativos mediante XML o anotaciones, se distribuye con licencia GNU/LGPL y posee una versión para .NET llamada nHibernate, más información en el sitio oficial

• Objective-C: Core Data (Parte de la API de Cocoa), proporciona la capacidad de persistencia mediante serialización para dispositivos con Mac OSX o iOS, más información en la guía de programación de Core Data

• PHP: Doctrine, mencionado anteriormente, un proyecto independiente, con la especialidad de que posee su propio lenguaje para el acceso a datos, llamado Doctrine Query Language. Más información en el sitio oficial

• Ruby: ActiveRecord (Parte de Ruby On Rails), genera un modelo de persistencia basado en las clases, proporciona acceso a datos en el framework y es la clase base para los modelos del mismo. En la API de Rails se puede ver el sistema en detalle.

Conclusiones

Los modelos ORM proporcionan grandes ventajas a proyectos que empiezan, ya que permiten tener acceso a los datos de una manera sencilla y rápida, además de proporcionar cierta abstracción sobre la base de datos que se encuentra por debajo.

Es cierto que no es la única manera de acceder a los datos, ya que soluciones específicas habitualmente tendrán mejor rendimiento, ya que no se hace una transformación de las ordenes y de los datos.

Finalmente creo que se deben conocer, y tenerlos como alternativa o como sistema principal. Como siempre, todo depende del uso.