ORM ( mapeo relacional de objetos en inglés , mapeo relacional de objetos ruso o transformación) es una tecnología de programación que conecta las bases de datos con los conceptos de los lenguajes de programación orientados a objetos , creando una " base de datos de objetos virtuales ". Hay implementaciones propietarias y gratuitas de esta tecnología.
Es necesario trabajar con datos en términos de clases, no tablas de datos y, por el contrario, transformar los términos y datos de clases en datos aptos para almacenar en el SGBD. También es necesario proporcionar una interfaz para las operaciones de datos CRUD . En general, debe deshacerse de la necesidad de escribir código SQL para la interacción en el DBMS [1] .
La solución al problema del almacenamiento de datos existe: estos son los sistemas de administración de bases de datos relacionales . El uso de una base de datos relacional para almacenar datos orientados a objetos conduce a una brecha semántica , lo que obliga a los programadores a escribir software que debe poder procesar datos de forma orientada a objetos, pero almacenar esos datos de forma relacional. Esta necesidad constante de convertir entre dos formas diferentes de datos no solo reduce en gran medida el rendimiento, sino que también crea dificultades para los programadores, ya que ambas formas de datos se imponen restricciones entre sí.
Las bases de datos relacionales utilizan un conjunto de tablas que representan datos simples. La información adicional o relacionada se almacena en otras tablas. A menudo, se utilizan varias tablas para almacenar un solo objeto en una base de datos relacional; esto, a su vez, requiere una operación JOIN para obtener toda la información relacionada con el objeto para poder procesarlo. Por ejemplo, para almacenar datos del cuaderno, lo más probable es que haya al menos dos tablas: personas y direcciones, y tal vez incluso una tabla con números de teléfono.
Dado que los sistemas de administración de bases de datos relacionales normalmente no implementan una representación relacional de la capa física de las relaciones, ejecutar múltiples consultas consecutivas (referidas a la misma estructura de datos "orientada a objetos") puede ser prohibitivamente costoso. En particular, es probable que una sola consulta como "buscar tal o cual usuario y todos sus teléfonos y todas sus direcciones y devolverlos en este formato" sea más rápida que una serie de consultas como "Buscar usuario". Encuentra su dirección. Encuentra sus teléfonos. Esto se debe al trabajo del optimizador y al costo de analizar la consulta.
Algunas implementaciones de ORM sincronizan automáticamente los objetos en memoria con la base de datos. Para que esto sea posible, después de crear una consulta SQL de transformación de objeto a SQL (la clase que implementa la comunicación con la base de datos), los datos recibidos se copian en los campos del objeto, como en todas las demás implementaciones de ORM. Después de eso, el objeto debe estar atento a los cambios en estos valores y escribirlos en la base de datos.
Los sistemas de gestión de bases de datos relacionales muestran un buen rendimiento en consultas globales que afectan a una gran área de la base de datos, pero el acceso orientado a objetos es más eficiente cuando se trabaja con pequeñas cantidades de datos, ya que reduce la brecha semántica entre el objeto y las formas relacionales de datos.
Con la existencia simultánea de estos dos mundos diferentes, la complejidad del código objeto para trabajar con bases de datos relacionales aumenta y se vuelve más propenso a errores. Los desarrolladores de software de bases de datos han estado buscando una forma más fácil de lograr la persistencia de sus objetos.
Se han desarrollado muchos paquetes para eliminar la necesidad de convertir objetos para almacenarlos en bases de datos relacionales.
Algunos paquetes resuelven este problema al proporcionar bibliotecas de clases que pueden realizar estas conversiones automáticamente. Al tener una lista de tablas en la base de datos y objetos en el programa, convierten automáticamente las consultas de un tipo a otro. Como resultado de consultar el objeto "persona" (del ejemplo de la libreta de direcciones), se generará y ejecutará la consulta SQL requerida, y los resultados se convertirán "mágicamente" en objetos "número de teléfono" dentro del programa.
Desde el punto de vista de un programador, el sistema debería verse como un almacén persistente de objetos. Simplemente puede crear objetos y trabajar con ellos como de costumbre, y se almacenarán automáticamente en una base de datos relacional.
En la práctica, no todo es tan simple y obvio. Todos los sistemas ORM tienden a exhibirse de una forma u otra, reduciendo la posibilidad de ignorar la base de datos de alguna manera. Además, la capa de transacción puede ser lenta e ineficiente (especialmente en términos de SQL generado). Todo esto puede hacer que los programas se ejecuten más lentamente y usen más memoria que los programas escritos a mano.
Pero ORM evita que el programador escriba una gran cantidad de código, a menudo repetitivo y propenso a errores, lo que aumenta significativamente la velocidad de desarrollo. Además, la mayoría de las implementaciones modernas de ORM permiten al programador, si es necesario, codificar las consultas SQL que se usarán para ciertas acciones (guardar en la base de datos, cargar, buscar, etc.) con un objeto persistente.