ORM, Object-Relational Mapping

Mapeo del modelo de objetos al modelo relacional

Pablo Pizarro Ingeniera de Software Facultad de Ingeniera - Universidad de Mendoza Mendoza, Argentina 2005

1 ndice
1 2 3 4 NDICE.................................................................................................................................. 2 RESUMEN............................................................................................................................ 3 INTRODUCCIN.................................................................................................................. 3 MAPEO DE OBJETOS AL MODELO RELACIONAL ......................................................... 4 4.1 GENERALIDADES ............................................................................................................ 4 4.2 INCONGRUENCIA ENTRE EL MODELO RELACIONAL Y EL DE OBJETOS ................................... 5 4.3 TERMINOLOGA............................................................................................................... 5 4.4 EJEMPLO A DESARROLLAR .............................................................................................. 6 4.5 MAPEO DE OBJETOS ....................................................................................................... 7 4.5.1 Identidad del Objeto................................................................................................. 8 4.6 MAPEO DE RELACIONES .................................................................................................. 8 4.6.1 Asociaciones............................................................................................................ 8 4.6.2 Agregacin / Composicin..................................................................................... 11 4.6.3 Herencia ................................................................................................................ 11 4.7 EJEMPLO DESARROLLADO............................................................................................. 13 4.8 RESUMEN .................................................................................................................... 13 5 PERSISTENCIA ................................................................................................................. 14 5.1 PATRN CRUD ........................................................................................................... 14 5.2 CACH......................................................................................................................... 15 5.2.1 Identidad en la cach............................................................................................. 15 5.3 CARGA DE LAS RELACIONES .......................................................................................... 16 5.3.1 Proxy (listado y seleccin, reporte) ....................................................................... 16 5.4 TRANSACCIN .............................................................................................................. 17 5.5 CONCURRENCIA ........................................................................................................... 18 5.5.1 Bloqueo optimista .................................................................................................. 18 5.5.2 Bloqueo pesimista ................................................................................................. 19 5.6 OTROS ASPECTOS ........................................................................................................ 19 6 FRAMEWORKS DE TRABAJO......................................................................................... 21 6.1 6.2 7 OJB.NET ...................................................................................................................... 21 NHIBERNATE ................................................................................................................ 22

BIBLIOGRAFA.................................................................................................................. 25

2 Resumen
La persistencia de la informacin es la parte ms crtica en una aplicacin de software. Si la aplicacin est diseada con orientacin a objetos, la persistencia se logra por: serializacin del objeto o, almacenando en una base de datos. Las bases de datos ms populares hoy en da son relacionales. El modelo de objetos difiere en muchos aspectos del modelo relacional. La interfase que une esos dos modelos se llama marco de mapeo relacional-objeto (ORM en ingls). En este documento describo el mapeo de un modelo de objetos hacia un modelo relacional. Tambin, los aspectos a considerar cuando se elige un marco ORM: cach, transacciones, carga retardada, concurrencia. Y por ltimo, una descripcin de los 2 marcos ORM ms usados en la tecnologa Microsoft.Net: Ojb.Net y NHibernate.

3 Introduccin
Organic el trabajo en 3 partes. En la primera parte, hablar sobre el paso del modelo de objetos al modelo relacional. Introducir el tema. Luego, describir las tcnicas de mapeo entre las tablas y los atributos de un objeto. Entonces, tratar sobre la complejidad de los ORM. Finalmente, describir brevemente las tecnologas ms usadas en la plataforma Micorosoft.Net.

ORM, Pizarro Pablo

Pgina 3

Agosto 2005

4 Mapeo de objetos al modelo relacional

4.1 Generalidades
Seccin basada en [GLOGLS1], [Hanson1], [Hanson2], [AMBLER2], [KELLER1]

La persistencia de la informacin es la parte ms crtica en una aplicacin de software. Si la aplicacin est diseada con orientacin a objetos, la persistencia se logra por: serializacin del objeto o, almacenando en una base de datos. El modelo de objetos difiere en muchos aspectos del modelo relacional. La interfase que une esos dos modelos se llama marco de mapeo relacional-objeto (ORM en ingls). Marcos de trabajo como Java o .Net han popularizado el uso de modelos de objetos (UML) en el diseo de aplicaciones dejando de lado el enfoque monoltico de una aplicacin. Las bases de datos ms populares hoy en da son relacionales. Oracle, SQLServer, Mysql, Postgress son los DBMS ms usados. En el momento de persistir un objeto, normalmente, se abre una conexin a la base de datos, se crea una sentencia SQL parametrizada, se asignan los parmetros y recin all se ejecuta la transaccin. Imaginemos que tenemos un objeto con varias propiedades, adems de varias relaciones, como las asociamos relacionalmente? Cmo las almacenamos? Automticamente, manualmente? Qu pasa con las claves secundarias? Ahora, si necesitamos recuperar los datos persistidos. Cargamos nicamente el objeto? Cargamos tambin las asociaciones? Cargamos el rbol completo? Y si los mismos objetos estn relacionados con otros, se cargan n veces hasta satisfacerlos? Est demostrado que un 35% de tiempo de desarrollo de software est dedicado al mapeo entre objeto y su correspondiente relacin. Como se ve, la incongruencia entre los 2 modelos aumenta a medida que crece el modelo de objetos. Hay varios puntos por considerar: Carga perezosa. Referencia Circular. Cach. Transacciones. El ORM debera resolver la mayora de las cargas. Un buen ORM permite: Mapear clases a tablas: propiedad a columna, clase a tabla. Persistir objetos. A travs de un mtodo Orm.Save(objeto). Encargndose de generar el SQL correspondiente. Recuperar objetos persistidos. A travs de un mtodo objeto = Orm.Load(objeto.class, clave_primaria). Recuperar una lista de objetos a partir de un lenguaje de consulta especial. A travs de un mtodo. ListObjetos = Orm.Find(Objeto FROM MyObject WHERE Objeto.Propiedad=5), o algo ms complejo ListObjetos = Orm.Find(Objeto

ORM, Pizarro Pablo

Pgina 4

Agosto 2005

FROM MyObject WHERE Objeto.Relacion1.Relacion2.Propiedad2=5), y el ORM transformar a travs de varios joins de tablas.

4.2 Incongruencia entre el modelo relacional y el de objetos Sabemos que las tablas tienen atributos simples, o sea, tipo definidos previamente por los arquitectos del software. Por otro lado, un objeto tiene tanto atributos simples como aquellos definidos por el usuario, que en s es otro objeto ms. La incongruencia entre el modelo relacional y el de objetos es la diferencia en la forma de representar atributos de los 2 modelos. As en uno tenemos una representacin tabular, mientras que en otro tenemos una representacin jerrquica. La incongruencia entre la tecnologa de objetos y la relacional, fuerza al programador a mapear el esquema de objetos a un esquema de datos. Hablamos de que los objetos deberan almacenarse en una base de datos relacional. Ahora, una tabla mantiene relacionados los atributos que contiene. Un modelo de objetos tiene una jerarqua en rbol. Para ello se usa una capa extra muy fina pero suficiente para servir como un puente entre los 2 modelos. Para implementar esos mapeos, se necesita agregar cdigo a los objetos de negocios, cdigo que impacta en la aplicacin. Para la mayora de las aplicaciones, almacenar y recuperar informacin implica alguna forma de interaccin con una base de datos relacional. Esto ha representado un problema fundamental para los desarrolladores porque algunas veces el diseo de datos relacionales y los ejemplares orientados a objetos comparten estructuras de relaciones muy diferentes dentro de sus respectivos entornos. Las bases de datos relacionales estn estructuradas en una configuracin tabular y los ejemplares orientados a objetos normalmente estn relacionados en forma de rbol. Esta 'diferencia de impedancia' ha llevado a los desarrolladores de varias tecnologas de persistencia de objetos a intentar construir un puente entre el mundo relacional y el mundo orientado a objetos. El marco de trabajo Enterprise JavaBeans (EJB) proporciona uno de los muchos mtodos para reducir esta distancia. 4.3 Terminologa
Seccin basada en [FUSSELL1]

Modelo de objetos: Identidad de objeto. Propiedad por la que cada objeto es distinguible de otros an si ambos tienen el mismo estado (o valores de atributos). Atributo. Propiedad del objeto al cual se le puede asignar un valor. Estado. Comportamiento. Es el conjunto de interfaces del objeto. Interfase. Operacin mediante la cual el cliente accede al objeto. Encapsulacin. Es el ocultamiento de los detalles de implementacin de las interfases del objeto respecto al cliente. Asociacin. Es la relacin que existe entre dos objetos.

ORM, Pizarro Pablo

Pgina 5

Agosto 2005

Clase. Define como ser el comportamiento del objeto y como almacenar su informacin. Es responsabilidad de cada objeto ir recordando el valor de sus atributos. Herencia. Especifica que una clase usa la implementacin de otra clase, con la posible sobreescritura de la implementacin de las interfases.

Modelo relacional: Base de datos. Conjunto de relaciones variables que describen el estado de un modelo de informacin. Puede cambiar de estado (valores) y puede responder preguntas sobre su estado. Relacin variable (Tabla). Mantiene tuplas relacionadas a lo largo del tiempo, y puede actualizar sus valores. Esquematiza como estn organizados los atributos para todas las tuplas que contiene. Tupla (fila). Es un predicado de verdad que indica la relacin entre todos sus atributos. Atributo (columna). Identifica un nombre que participa en una relacin y especifica el dominio sobre el cual se aplican los valores. Valor de atributo (valor de columna). Valor particular del atributo con el dominio especificado. Dominio. Tipos de datos simples. 4.4 Ejemplo a desarrollar La siguiente figura es un modelo de objetos simplificados. Al final del captulo mostrar uno de los posibles modelos relacionales a la que mapea. El modelo de ejemplo nos dice que los empleados de una organizacin publican cada cierto tiempo documentos (o contratos de especificaciones). Esos documentos deben ser aceptados por los clientes a quienes involucran. Los clientes de la organizacin son los que piden las especificaciones a los empleados. Esas especificaciones quedan plasmadas en un documento. Los empleados a su vez, pueden ser supervisores de otros. Tenemos 4 clases bsicas: Persona, Empleado, Cliente, Documento. Tenemos 3 relaciones: Firma (Cliente que Firma Documentos de especificaciones), Publica (cuando un empleado formaliza el documento) y Supervisa (relacin de dependencia entre los empleados).

ORM, Pizarro Pablo

Pgina 6

Agosto 2005

Figura 4-1 Modelo de objetos del ejemplo a desarrollar.

4.5

Mapeo de objetos
Seccin basada en [AMBLER2], [FOWLER1]

Un objeto est compuesto de propiedades y mtodos. Como las propiedades, representan a la parte esttica de ese objeto, son las partes que son persistidas. Cada propiedad puede ser simple o compleja. Por simple, se entiende que tiene algn tipo de datos nativos como por ejemplo entero, de coma flotante, cadena de caracteres. Por complejo se entiende algn tipo definido por el usuario ya sea objetos o estructuras. En esta seccin veremos como mapear propiedades simples de los objetos. El mapeo de tipos de datos complejos se ve en la seccin siguiente. En el modelo relacional, cada fila en la tabla se mapea a un objeto, y cada columna a una propiedad. Normalmente, cada objeto de nuestro modelo, representa una tabla en el modelo relacional. As que cada propiedad del objeto se mapea a cero, 1 o, ms de 1 columna en una tabla. Cero columnas, pues se puede dar el caso de propiedades que no necesitan ser persistidas, el ejemplo ms sencillo, es el de las propiedades que representan clculos temporarios. Lo ms comn que sucede es que cada propiedad del objeto se mapea a una nica columna, se debe tener en cuenta el tipo de datos. Una propiedad puede ser mapeada en ms de una columna, por ejemplo, las propiedades de clculos temporarios.

ORM, Pizarro Pablo

Pgina 7

Agosto 2005

Tambin se da el caso contrario de que en la tabla se tienen otros atributos que no se representan en el objeto real. Estos atributos suelen estar disponibles para el manejo de la concurrencia, auditoras, etctera. Cada columna de la tabla debera respetar el tipo de datos con su correspondiente en la propiedad del objeto. Aunque a veces, por optimizacin, es necesario algunos ajustes en la base de datos relacional. Una de las razones principales, es que la perfomance aumenta considerablemente si se trabaja con valores numricos que con caracteres. En caso de no poder representarse el tipo de datos se debe tener en cuenta la prdida de informacin. Por ejemplo si almacenamos un valor de punto flotante como cadena de caracteres, al reconstruirlo en propiedad, es posible la prdida de informacin. Para acceder a las propiedades normalmente se usan mtodos especiales llamados getters y setters, o mutadores y accesores. 4.5.1 Identidad del Objeto Para distinguir cada fila de las otras, se necesita un identificador de objetos (OID) que es una columna ms. Este identificador no es necesario en memoria, por que la unicidad del objeto queda representada por la unicidad de la posicin de memoria que ocupa. El OID siempre representa la clave primaria en la tabla. Normalmente es numrico por razones de perfomance. En esta seccin vimos que solo se mapea la parte esttica de un objeto. As cada clase se mapea a una tabla. Cada objeto se mapea a una fila en la tabla. Cada propiedad del objeto se mapea por lo general a una columna. Existe una columna especial que identifica al objeto en la tabla llamada Oid. 4.6 Mapeo de relaciones
Seccin basada en [AMBLER2]

En esta seccin veremos como se mapean las relaciones entre los objetos. Por relacin se entiende asociacin, herencia o agregacin. Cualquiera sea el caso, para persistir las relaciones, se usan transacciones, ya que los cambios pueden incluir varias tablas. En el caso de que la transaccin falle, se aumenta la probabilidad de xito integridad referencial. 4.6.1 Asociaciones
Seccin basada en [AMBLER2]

Una regla general para el mapeo es respetar el tipo de multiplicidad en el modelo de objetos, y en el modelo relacional. As una relacin 1-1 en el modelo de objetos, deber corresponder a una relacin 1-1 en el modelo relacional. La asociaciones, a su vez, estn divididas segn su multiplicidad y su navagabilididad. Segn su multiplicidad, pueden existir asociaciones 1-1, 1-n, m-n. Segn su navegabilidad, se tiene unidireccional o bidireccional. Se puede dar la seis combinaciones posibles. Una aclaracin importante, es que en las base de datos relacionales, todas las asociaciones son bidireccionales, tambin es un factor de la incongruencia del modelos.

ORM, Pizarro Pablo

Pgina 8

Agosto 2005

4.6.1.1 Asociacin clave fornea

Seccin basada en [FOWLER1]

Para mapear las relaciones, se usan los identificadores de objetos (OID). Estos OID se agregan como una columna ms en la tabla donde se quiere establecer la relacin. Dicha columna es una clave fornea a la tabla con la que se est relacionada. As, queda asignada la relacin. Recordar que las relaciones en el modelo relacional son siempre bidireccionales. El patrn se llama Foreign Key Mapping. 4.6.1.2 Multiplicidad 1-1
Seccin basada en [AMBLER2]

Cada objeto A est asociado con cero o un objeto B y, cada objeto B est asociado con cero o un objeto A. En el modelo de objetos, este tipo de relacin, se representa como una propiedad de tipo de datos de Usuario. As es comn accederla via setObjetoB(), getObjetoB(). En el modelo relacional, cualquiera de las 2 tablas relacionadas implementar una columna con el Oid de la otra tabla, y esta columna ser la clave fornea para relacionarlas.
Por ejemplo, entre Empleado y Posicion existe una relacin 1 a 1 y se mapea a 2 tablas.

No obstante, este tipo de relacin al ser un subconjunto de 1-n, y sta a su vez de nm, puede mapearse como esta ltima a travs de una tabla asociativa o implementando la clave en la otra tabla relacionada (ver Nevegabilidad unidireccional). 4.6.1.3 Multiplicidad 1-n
Seccin basada en [AMBLER2]

Cada objeto A puede estar asociado con cero o ms objetos B, pero cada objeto B est asociado con cero o un objeto A. En el modelo de objetos, este tipo de relacin, se representa como una coleccin o array de tipo de datos de usuario. As es comn accederla via addObjectosB(ObjetoB), removeObjetosB(ObjetoB). En el modelo relacional se pueden seguir 2 estrategias para establecer la relacin: Implementando la clave fornea OID en la tabla muchos a la tabla uno. Implementando una tabla asociativa, convirtiendo la relacin en muchos a muchos. Ver seccin siguiente. 4.6.1.4 Multiplicidad n-m
Seccin basada en [AMBLER2]

Cada objeto A est asociado con cero o ms objetos B, y a su vez, cada objeto B est asociado a cero o ms objetos A. En el modelo de objetos, esta relacin ser similar a la anterior. Ser implementada mediante una coleccin o array en ambos objetos. En el modelo relacional, se usa una tabla auxiliar asociativa para representar la relacin y cuyo +unico objetivo es relacionar 2 o ms tablas. Dicha tabla tendr al menos 2 columnas, cada una representando la clave fornea a las 2 tablas que relaciona. Con esto se transforma la relacion n-m a dos relaciones (1-n y 1-m).

ORM, Pizarro Pablo

Pgina 9

Agosto 2005

4.6.1.5 Navegabilidad unidireccional

Seccin basada en [AMBLER2]

Una relacin unidireccional es aquella que sabe con que objetos est relacionado, pero dichos objetos no conocen al objeto original. En el modelo de objetos, la navegabilidad unidireccional est representada por una flecha en el extremo de la asociacin. Por lo tanto el objeto original es quien implementa los mtodos de acceso, mientras que el secundario no. En el modelo relacional, la navegabilidad est representada por un clave fornea y depende de la multiplicidad la tabla en la que se implementa. Como ya se dijo, todas las relaciones en la base de datos son bidireccionales. Por ejemplo, para implementar una relacin 1-1 podramos haber puesto la clave fornea en cualquiera de las 2 tablas, pues al hacer la unin (INNER JOIN, LEFT JOIN, RIGHT JOIN) solo indicamos la clave fornea y su unin.
Si la tabla Posicion implementara el empleado que la ocupa el select sera: SELECT Empleado.Nombre, Posicion.Nombre FROM Posicion INNER JOIN Empleado ON Posicion.EmpleadoOid = Empleado.EmpleadoOid Pero, si la tabla Empleado implementara la posicin, no habra ningn tipo de problemas: SELECT Empleado.Nombre, Posicion.Nombre FROM Posicion INNER JOIN Empleado ON Posicion.PosicionOid = Empleado.PosicionOid

4.6.1.6 Navegabilidad bidireccional

Seccin basada en [AMBLER2]

Una relacin bidireccional existe cuando los objetos en ambos extremos de la relacin saben del objeto en el extremo contrario. En el modelo de objetos se representa por una linea que los une, sin flechas que indiquen direccionalidad. Ambos objetos deben implementar los mtodos de acceso hacia el objeto con el cual est relacionado. 4.6.1.7 Asociacin recursiva
Seccin basada en [AMBLER2]

Una asociacin recursiva (o reflexiva) es aquella donde ambos extremos de la asociacin es una misma entidad (clase, tabla). En el modelo de objetos se representa por una linea asociativa que empieza y termina en la misma clase. Puede tener cualquier multiplicidad y navegabilidad. En el modelo relacional, se representa por una clave fornea a s misma, y depende de la multiplicidad si esa clave se implementa en la misma tabla o en una tabla asociativa.

ORM, Pizarro Pablo

Pgina 10

Agosto 2005

4.6.2 Agregacin / Composicin

Seccin basada en, [AMBLER2]

Como ya sabemos, una asociacin es una relacin dbil e independiente entre 2 objetos. Una agregacin es una relacin ms fuerte que una asocacin pero an independiente. Una composicin es a la vez una relacin fuerte y dependiente entre 2 objetos. Con lo anterior asumimos que tanto una asociacin, agregacin o composicin se mapea en el modelo relacional como una relacin. La agregacin normalmente se mapea como una relacin n-m, o sea que hay una tabla auxiliar para mapear la relacin. La composicin puede mapearse como una relacin 1-n. Donde los objetos compuestos mantienen una relacin con el objeto compositor. A nivel relacional, indica que la tabla de los objetos compuestos tienen una columna con la clave fornea al objeto que los compuso. En el modelo objetos, tanto las agregaciones como las composiciones se corresponden con un array o una coleccin de objetos. 4.6.3 Herencia
Seccin basada en [KELLER1], [FOWLER1] y [AMBLER2]

Como vimos anteriormente, las asociaciones funcionan en ambos modelos, objeto y relacional. Para el caso de la herencia se presenta el problema que las base de datos relacionales no la soportan. As es que somos nosotros quienes debemos modelar como se ver la herencia en el modelo relacional. Una regla a seguir es que se debe minimizar la cantidad de joins posibles. Existen 3 tipos de mapeos principales: modelar la jerarqua a una sola tabla, modelar la jerarqua concreta en tablas, modelar la jerarqua completa en tablas. La desicin estar basado en la perfomance y, en la escalabilidad del modelo. 4.6.3.1 Mapeo de la jerarqua a una tabla.
Seccin basada en [FOWLER1] y [AMBLER2]

Se mapean todos los atributos, de todas las clases del rbol de herencia en una nica tabla. En el mapeo, se agregan 2 columnas de informacin oculta (ver captulo siguiente): la clave primaria de la tabla OID y, el tipo de clase que es cada registro. El tipo de clase se resuelve con 1 columna carcter o numrica entera. Para los casos ms complejos se necesita de varias columnas booleanas (si/no). Por ejemplo, la jerarqua Persona (que es abstracta), Cliente y Empleado quedaran en una nica tabla llamada persona (es recomendable colocarle el nombre de la raz de la estructura). A la tabla se le agrega el tipo de clase que es, as, tenemos la columna TipoPersona donde C ser cliente, E empleado, D para aquellos que son clientes y empleados al mismo tiempo. Las ventahas son: Aproximacin simple. Cada nueva clase, simplemente se agregan columnas para datos adicionales. Soporta el polimorfismo cambiando el tipo de fila. El acceso a los datos es rpido por que los datos estn en una sola tabla. El reporte es facil por que los datos estn en una tabla. Las desventajas son: Mayor acoplamiento entre las clases. Un cambio en una de ellas puede afectar a las otras clases ya que comparten la misma tabla.

ORM, Pizarro Pablo

Pgina 11

Agosto 2005

Se desperdicia espacio en la base de datos (por la tanto disminuye perfomance), para aquellas columnas en las que son de las clases derivadas. El tipo se complica cuando hay sobrelapamiento de clases derivadas. La tabla crece rpidamente a mayor jerarqua.

Cuando usar: es una estrategia para clases de jerarquias simples And/Or, donde hay poco sobrelapamiento entre los tipos de la jerarqua. 4.6.3.2 Mapeo de cada clase concreta a una tabla.
Seccin basada en [AMBLER2]

Cada clase concreta es mapeada a una tabla. Cada tabla incluye los atributos heredados ms los implementados en la clase. La clase base abstracta entoncs, es mapeada en cada tabla de las derivadas. Ventajas: Reportes facles de obtener ya que los datos necesarios estn en una sola tabla. Buena perfomance para acceder a datos de un objeto. Desventajas: Pobre escalabilidad, si se modifica la clase base, se debe modificar en todas las tablas de las clases derivadas para reflejar ese cambio. Por ejemplo, si a la clase Persona le agregamos el atributo de EstadoCivil, debemos agregarlo en las tablas Cliente y en Empleado. Actualizacin compleja, si un objeto cambia su rol, se le asigna un nuevo OID y se mueven los datos a la tabla correrpondiente. Se pierde integridad en los datos, para el caso en que el objeto tenga los 2 roles. Por ejemplo Cliente y Empleado a la vez. Cuando usar: Cuando el cambio en el tipo y/o sobrelapamiento sea raro.

4.6.3.3 Mapeo de cada clase a su propia tabla.

Seccin basada en [AMBLER2]

Se crea una tabla por cada clase de la herencia, an la clase base abstracta. Se agregan tambin las columnas para el control de la concurrencia o version a cualquiera de las tablas. Cuando se necesita leer el objeto heredado se unen (join) las 2 tablas de la relacin o se leen las 2 tablas en forma separada. Las claves primarias de todas las tablas heredadas, ser la misma que la tabla base. A su vez, tambin sern claves forneas hacia la tabla base. Para simplificar las consultas, a veces ser necesario agregar una columna en la tabla base indicando los subtipos de ese elemento, o, agregando varias columnas booleanas. El mismo efecto se logra, y mucho ms eficiente, a travs de vistas. Ventajas: Fcil de entender, por que es un mapeo uno a uno. Soporta muy bien el polimorfismo, ya que tiene almacenado los registros en la tabla correspondiente. Facil escalabilidad, se pueden modificar atributos en la superclase que afectan a una sola tabla. Agregar subclases es simplemente agregar nuevas tablas. Desventajas:
ORM, Pizarro Pablo Pgina 12 Agosto 2005

 Hay muchas tablas en la base de datos. Menor perfomance, pues se necesita leer y escribir sobre varias tablas. Reportes rpidos dificiles de armar, a menos que se tengan vistas. Usar cuando el sobrelapamiento de tipos o cuando el cambio de tipos sea muy comn. 4.7 Ejemplo desarrollado Por lo visto, este es el resultado final del ejemplo desarrollado. Para el caso de la herencia prefer usar la tcnica del mapeo clase a tabla, por que el sobrelapamiento es muy comn.

Figura 4-2 Modelo relacional del ejemplo desarrollado

4.8 Resumen En esta seccin vimos como mapear las relaciones que existen entre los objetos. Entre las relaciones distinguimos las asociaciones segn su multiplicidad y segn su navegabilidad. Adems vimos 3 estrategias para mapear la herencia, simplificamos el mapeo de una agregacin. Y tratamos el mapeo de asociaciones recursivas.

ORM, Pizarro Pablo

Pgina 13

Agosto 2005

5 Persistencia
Seccin basada en [GLOGLS1], [BERGLAS1], [BELLWARE1], [KELLER1] y [AMBLER2]

Persistencia es la habilidad que tiene un objeto de sobrevivir al ciclo de vida del proceso en el que reside. Los objetos que mueren al final de un proceso se llaman transitorios. [KELLER1] Ya dije que haba un incongruencia entre el mundo orientado a objetos y las base de datos relacionales. Para reducir ese incongruencia recurrimos a una capa auxiliar que mapear entre los 2 mundos, adaptndolo segn las especificaciones hechas. Esa capa auxiliar se denomina ORM, object relational mapping. Los ORM nacieron a mediados de la dcada del 90, se hicieron masivos a partir de la masificacin de Java. Por esa razn, los frameworks ms populares hoy en da en .Net son adaptaciones del modelo pensado para Java. Imaginemos que queremos cargar un objeto persistido en memoria, los pasos a seguir seran: abrir la conexin a la base de datos, crear una sentencia sql parametrizada, llenar los parmetros (por ejemplo la clave primaria), recin all ejecutarlo como una transaccin y, cerrar la conexin a la base de datos. Con un framework, la tarea se reduce a: abrir una sesin con la base de datos, especificar el tipo de objeto que queremos (y su clave primaria correspondiente), cerrar la sesin. No obstante, el framework debera resolver los siguientes puntos: Transacciones. Se hacen todos los cambios sin excepcin, o, se hace nada? Cach. se almacenan en memoria los objetos usados? se almacenan las consultas SQL hechas? Carga retardada. cundo se carga el objeto en memoria, se cargan en memoria todas sus relaciones? se cargan en memoria sus campos menos usados (por ejemplo los BLOBS de gran tamao)? Referencia circular. Si el objeto est relacionado 2 veces con el mismo objeto, se carga 2 veces el objeto relacionado? OID. asignamos manualmente o automticamente las claves primarias? Estudios muestran que aproximadamente, el 35% de desarrollo de software est dedicado al mapeo entre el modelo de objetos y su correspondiente modelo relacional. Ahora imaginemos, que necesitamos actaulizar nuestro software. Como sabemos, al ser objetos, lo que proveemos al cliente son las interfases de acceso. 5.1 Patrn CRUD
Seccin basada en [KELLER1]

Acrnimo de Create-Read-Update-Delete. Conocido como el padre de todos los patrones de capa de acceso. Describe que cada objeto debe ser creado en la base de datos para que sea persistente. Una vez creado, la capa de acceso debe tener una forma de leerlo para poder actualizarlo o simplemente borrarlo. Tericamente el borrado de objetos debera quedar a acargo de la misma base de datos. Pero un recolector de objetos basura (garbage collector) en una base de datos gigante afecta en gran medida la perfomance. Por ello es que la tarea de borrado queda delegada al programador.
ORM, Pizarro Pablo Pgina 14 Agosto 2005

5.2

Cach
Seccin basada en [PERSISTENCE1]

En la mayoria 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 aplicacin. Esto significa que hay un un conjunto de datos dinmicos que son relevantes a todos los usuarios del sistema, y por lo tanto accedido con mas frecuencia. Las aplicaciones empresariales de sincronizacin de cach normalmente necesitan escalarse para manejar grandes cargas transaccionales, as mltiples instancias pueden procesar simultneamente. Es un problema serio para el acceso a datos desde la aplicacin, especialmente cuando los datos involucrados necesitan actualizarse dinmicamente a travs de esas instancias. Para asegurar la integridad de datos, la base de datos comnmente juega el ol de rbitro para todos los datos de la aplicacin. Es un rol muy importante dado que los datos representan la proporcin de valor ms significante de una organizacin. Desafortunadamente, este rol tambin no est fcilmente distribuido sin introducir problemas significantes, especialmente en un entorno transaccional. Es comn para la base de datos usar replicacin para lograr datos sincronizados, pero comnmente ofrece una copia offline del estado de los datos ms que una instancia secundaria activa. Es posible usar base de datos que puedan soportar multiples instancias activas, pero se pueden volver caras en cuanto a perfomance y escalabilidad, debido a que introducen el bloqueo de objetos y la latencia de distribucin. La mayora de los sistemas usan una nica base de datos activa, con mltiples servidores conectada directamente a ella, soportando un nmero variables de clientes. En esta arquitectura, la carga en la base de datos incrementar linealmente con el nmero de instancias de la aplicacin en uso, a menos que se emplee alguna cach. Pero implementando un mecanismo de cach en esta arquitectura puede traer muchos problemas, incluso corrupcin en los datos, por que la cach en el servidor 1 no sabr sobre los cambios en el servidor 2. 5.2.1 Identidad en la cach
Seccin basada en [KELLER1], [PERSISTENCE1]

En la siguiente porcin de cdigo veremos algunos aspectos de la cache.

Persona prsnPerezJuan = new Persona(Perez, Juan) Persona prsnPerezAlberto = new Persona(Perez, Alberto) Persona prsnPerez = ORM.LoadByApellido(Perez) //?

Hemos creado 2 instancias en memoria de la clase Perosna. O sea que para el objeto tenemos 2 objetos diferentes usando el mismo apellido. Si el apellido es la clave primaria en la base de datos, tendramos problemas cuando la apliacin trate de escribir la segunda instancia en la base de datos. Por eso debemos tener cuidado con la identidad del objeto y sus diferentes notaciones en la base de datos y en el programa. La solucin para esto es aplicar la identidad en la misma cach. Normalmente, se usa una tabla de hashing en base a las claves primarias. Imaginemos un cdigo como el siguiente:
Persona prsnJuan = (Persona) ORM.Load(PersonaOID,100) Persona prsnPerez = (Persona) ORM.Load(PersonaOID,100) If (prsnJuan != prsnPerez) // Houston, we have a problem
ORM, Pizarro Pablo Pgina 15 Agosto 2005

En la porcin de cdigo anterior tenemos 2 varibles que deberan hacer referencia al mismo objeto: Juan Perez. Si la capa de acceso no es buena, habr cargado dos instancias del objeto en memoria de los mismos datos en la base de datos. Para evitar que suceda, necesitamos tener un mecanismo que verificque que el objeto ya est cargado en memoria desde la base de datos. La primera vez que cargamos el objeto, la capa de acceso lo lee desde la base de datos; la a segunda vez, el mtodo Load necesita verificar si la Persona con OID igual a 100 ya est cargada en memoria. Si es as, solo retorna la referencia al objeto en memoria creado por la primera llamada. 5.3 Carga de las relaciones
Seccin basada en [KELLER1], [AMBLER2]

Uno de los problemas que debemos decidir luego del mapeo es si siempre se cargan todos los objetos relacionados a uno principal. La respuesta mas probable es no, porque las redes de relaciones tienden a ser ms compleja y la cadena de relacin tienden a ser ms larga en la vida real. Imaginemos que por defecto se carga cada relacin de un objeto. En el caso de una gran base de datos se volver grandsimo y habr prdida de perfomance. La solucin para este problema es conocida como Carga retardada de las relaciones, y se implementa por algn tipo de objetos con Patrn Proxy que lanzan la carga cuando se acceden (punteros inteligentes en C++). Para lograrlo, el objeto tiene un mtodo accesor (Get) cuyo nico propsito es proveer el valor de un atributo simple, que verifica a ver si el atributo ha sido inicializado y si no es as lo lee desde la base de datos. Otro uso comn de cargas retardada es la generacin de reporte y objetos que se dan como resultados de una bsqueda, casos en los cuales se necesita solo un subconjunto de datos del objeto. Lo mismo sucede para aquellos campos grandes y menos usados. Por ejemplo si se almacena la foto de una Persona ocupar alrededor de 100k mientras que el resto de los atributos no llegan, en total, a 1k; y, raramente son accedidas. Pero tambin, habr veces en la que la Carga Directa de las relaciones se prefiera. Con ella, cada v4ez que se cargue un objeto, querramos tener algunas de sus relaciones cargadas sin necesidad de volver a consultar la base de datos. 5.3.1 Proxy (listado y seleccin, reporte)
Seccin basada en [SCE1]

Es normal que la aplicacin presente un listado de un objeto particular, mostrando campos como OID, nombre y un resumen breve de otros campos; el objetivo de ese listado es darle al usuario la posibilidad de seleccionarlo para ver informacin ms detallada. Algo similar se da en la generacin de reportes. Si siguieramos aplicando un ORM, quizs produjeramos una sobrecarga innecesaria en la capa de persistencia con cargas no triviales en la base de datos. La aproximacin ms bsica, es no manejarla con los mecanismo de persistencia. Algunos consejois seran: 1. Evitar mostrar al usuario todos los objetos al principio. Dejarlo como posibilidad, pero mientras tanto, darle una opcin de bsqueda. Mostrar ventanas de seleccin en vez de cajas de seleccin (combo box). Da una mayor usabilidad y puede incluir un buen resumen. 2. La capa de persistencia debe proveer el manejo de solo lectura en masa. Retornando los datos en forma de filas o tuplas.
ORM, Pizarro Pablo Pgina 16 Agosto 2005

3. La consulta a la base de datos debera usar un cursor. Ir retornando los cursores gradualmente al cliente. Tambin debera tener en cuenta, que la mayoria de las bases proveen cursores hacia delante; con esto la capa de persistencia debera bufferear internamente as el cliente puede volver atrs. 4. A veces, el reporte y la seleccin requieren que los datos sean unidos a travs de mltiples tablas. Por defecto son las uniones hacia la izquierda las que se usan en las asociaciones incluyendo los roles de las tablas unidas; nombre de columnas no ambiguas, alias nicos cuando una talba se une a si misma; tipicamente para estructuras de jerarqua o rbol. 5.3.1.1 Proxy
Seccin basada en [AMBLER1]

Un proxy es un objeto que representa a otro objeto pero no incurre en la misma sobrecarga que al objeto representado. Un proxy contiene bastante informacin para que, tanto la aplicacin como el usuario puedan identificar el objeto. Por ejemplo el proxy para el objeto Persona debera contener su oid as la aplicacin pueda identificarlo y el apellido as el usuario puede reconocer a quien representa el objeto proxy. Los proxies se usan, generalmente, cuando se muestran los resultados de una consulta, de la cual el usuario elegir solo una o dos. Cuando el usuario elige el objeto proxy de la lista, recin ah se trae automticamente el objeto real del framework ORM, el cual es mucho mas grande que el proxy. Por ejemplo, el objeto real de Persona incluye direccin, foto de la persona. Con el patrn proxy solo se da la informacin que el usuario necesita.

Figura 5-1 Diagrama UML del Patrn Proxy. [DOFACTORY1]

5.4

Transaccin
Seccin basada en [SCE1]

Los datos almacenados en una base de datos necesitan ser protegidos por una transaccin. Esto permite mltiples inserciones, modificaciones y borrados con la seguridad de que todo o se ejecuta o falla, como si fuera una sola entidad coherente. Las transacciones tambin pueden ofrecer proteccin de concurrencia; el bloqueo pesimista de tuplas mientras los usuarios estn trabajando en ellos, evita que otros usuarios comiencen con sus cambios. Sin embargo, el mecanismo de transaccin de la base de datos tiene alguna limitaciones:

ORM, Pizarro Pablo

Pgina 17

Agosto 2005

Cada transaccin requiere una sesin separada, para permitir que los usuarios abran ventanas relacionadas a su trabajo requerira de licencias extras o que las ventas estn limitada a acceso de solo lectura. Una alta aislacin en la transaccin y bloqueo basado en pginas puede evitar que otros usuarios accedan a los datos que deberan estar legitimamente permitidos.

Una alternativa es que los datos sean puestos en un buffer en la capa de persistencia, con todas las escrituras que se harn hasta que el usuario lo confirme. Esta transaccin de base de datos se necesita solo durante la operacin de escritura en masa (bulk operation), permitiendo ser compartida entre mltiples ventanas. Esto requiere un esquema de bloqueo optimista donde las tuplas son chequeadas mientras se escriben. Obviamente, esta escritura en masa corre protegida por la integridad referencial. Esas restricciones especifican los requerimientos lgicos segn el caso: la tupla debe existir antes de que se la relacione y, las tuplas relacionadas a otra deben ser borradas antes de que se borre la tupla objetivo. Esto se logra mediante un mecanismo en la base de datos que mantiene correctamente las dependencias entre las tuplas. 5.5 Concurrencia
Seccin basada en [KELLER1] y [SCE1]

La capa de persistencia debe permitir que mltiples usuarios trabajen en la misma base de datos y proteger los datos de ser escritos equivocadamente. Tambin es importante minimizar las restricciones en su capacidad concurrente para verl y acceder. La integridad de datos es un riesgo cuando 2 sesiones trabajan sobre la misma tupla: la prdida de alguna actualizacin est asegurada. Tambin se puede dar el caso, cuando una sesin est leyendo los datos y la otra los est editando: una lectura incosistente es muy probable. Hay dos tcnicas principales para el problema: bloqueo pesimista y bloqueo optimista. Con el primero, se bloquea todos acceso desde que el usuario empieza a cambiar los datos hasta que COMMIT la transaccin. Mientras que en el optimista, el bloqueo se aplica cuando los datos son aplicados y se van verificando mientras los datos son escritos. 5.5.1 Bloqueo optimista
Seccin basada en [FOWLER1] y [SCE1]

Cuando detecta un conflicto entre transacciones concurrentes, cancela alguna de las transacciones. Para resolver el problema, valida que los cambios COMMIT por una sesin no entran en conflicto con los cambios hechos en otra sesin. Una validacin exitosa preCOMMIT es obtener un bloqueo de los registros con una transaccin simple. Asume que la chance de que aparezcan conflictos es baja: se espera que no sea probable que los usuarios trabajen sobre los mismos datos al mismo tiempo. El bloqueo optimista desacopla la capa de persistencia de la necesidad de mantener una transaccin pendiente, chequeando los datos mientras se escribe. Se usan varios esquemas de bloqueo optimista. Difieren en que campos son verificados; a veces se usa un campo de estampa de tiempo (timestamp) o un simple contador (counter). El bloqueo por estampa de tiempo no es confiable, hoy en da el hardware es cada vez ms rpido y la cuantizacin del tiempo llega al orden de los
ORM, Pizarro Pablo Pgina 18 Agosto 2005

microsegundos. Los contadores van indicando la ltima versin guardada en la base de datos. Generalmente, la aplicacin iniciar una transaccin, leer los datos desde la base, cerrar su transaccin, seguir con las reglas de negocio involucradas para volver a iniciar una transaccin, esta vez con los datos a ser escritos. En el caso de la estampa de tiempo, la capa de persistencia verificar que sea la misma que existe en la base de datos, escribir los datos y actualizar la estampa de tiempo a la hora actual. Muy similar para el contador, difiere en que la actaulizacin consiste en incrementar en 1 el campo. 5.5.2 Bloqueo pesimista
Seccin basada en [FOWLER1] y [SCE1]

Evita que aparezcan conflictos entres transacciones concurrentes permitiendo acceder a los datos a solo una transaccin a la vez. La aproximacin ms simple, consiste en tener una transaccin abierta para todas la reglas de negocios involucradas. Hay que tener precaucin con transacciones largas. Por eso se recomienda, usar mltiples transacciones en las reglas de negocios. Imaginemos que varios usuarios acceden a los mismos datos dentro de una regla de negocios, uno de ellos COMMIT todo mientras que otros usuarios no lo lograrn y fallarn. Dado que el conflicto se detecta cuando termina la transaccin, las vctimas harn todas las reglas de negocios hasta que en el ltimo instante, cuando todo fallar, con lo cual fue una prdida de tiempo. El bloqueo pesimista evita el conflicto anterior en total. Fuerza a las reglas de negocios a adquirir el bloqueo de los datos antes de empezar a usarlo, as, la transaccin se usa completamente sin preocuparse por los controles de concurrencia. El bloqueo pesimista notifica a los usuarios tempranamente de la contencin de los datos, pero para los propsitos de negocios la concurrencia es considerada altamente importante. 5.6 Otros aspectos
Seccin basada en [KELLER1], [FOWLER1] y, mayoritariamente, en [AMBLER2]

En esta seccin veremos otros aspectos a tener en cuenta en la eleccin de un framework ORM. Referencia circular. Se refiere a si el framework es capaz de detectar cual es el objeto que se est solicitando, sin hacer el roundtrip a la base de datos. Informacin oculta (Shadow information). As como el OID hay muchas columnas de la tabla que no necesitan ser mapeadas a una propiedad del objeto. Esta columnas contienen informacin oculta para el modelo de objetos pero necesaria para el modelo relacional. En esta categora entran los mecanismos de concurrencia: estampa de tiempo y versin de objeto. Al leer el objeto, se lee esta informacin que es ocultada al objeto pero mantenida por el framework. Lenguaje de consulta (OQL - Object Query Language). La obtencin de varios objetos a travs de un lenguaje especial es una de las caractersticas ms apreciadas. Por ejemplo, obtener todos los Juan Perez de una base de Personas. SELECT Persona FROM Personas WHERE Nombre = Juan. NHibernate con HQL es uno de los mejores. Actualizacin en cascada. La posibilidad de que modificaciones hechas a un objetos repliquen en los objetos relacionados.
ORM, Pizarro Pablo Pgina 19 Agosto 2005

Operaciones en masa. Habr veces que por razones de perfomance, se querr hacer una operacin en masa. Por ejemplo, actualizar todos los objetos con nombre Juan a J. De la manera tradicional, deberamos leer cada objeto, modificarlos en memoria, y recin all guardarlos de nuevo.

ORM, Pizarro Pablo

Pgina 20

Agosto 2005

6 Frameworks de trabajo
Seccin basada en [KELLER1], [FOWLER1] y, mayoritariamente, en [AMBLER2]

6.1

Ojb.Net
Seccin basada en [KELLER1], [FOWLER1] y, mayoritariamente, en [AMBLER2]

OJB.NET es un framework ORM para .Net que est basado en OJB de la plataforma JAVA. Es un proyecto open source. Algunas caractersticas que posee son: Herramienta que genera las clases correspondientes y asociaciones a partir del modelo relacional (ingeniera inversa). Genera el CRUD bsico en tiempo de ejecucin, lo que permite una configuracin out-of-band ms administrable. Cach de objetos y de consultas. Soporta lmites de transacciones (patrn units-of-work), administrandolos transparentemente.
class FacturacionBiz{ [Transaction(TransactionOption.Required)] void Facturar(){} }

Una de las diferencias de OJB.NET respecto a otros frameworks, es que las clases persistentes deben heredar de algunas de las siguientes clases abstractas: PO::EditableObject, aquellas clases cuyos atributos o relaciones pueden ser actualizadas a nuevos valores o referencias. PO::ImmutableObject, aquellas clases persistentes que solo permiten la insercin o el borrado en la base de datos relacional. PO::ReadOnlyObject, aquellas clases cuya informacin ya reside en una base de datos, pero no es posible actualizarlas. En la siguiente figura se ilustra los tipos persistibles en OJB.NET (en color azul).

ORM, Pizarro Pablo

Pgina 21

Agosto 2005

Figura 6-1 Diagrama de clases de OJB.Net [OJB1]

6.2

Nhibernate
Seccin basada en [KELLER1], [FOWLER1] y, mayoritariamente, en [AMBLER2]

NHibernate es uno de los frameworks ms usados. Se debe principalmente al poderoso lenguaje de consulta que trae consigo: HQL. Hibernate Query Language. Est basado en el proyecto Hibernate de Java, al igual que OJB.NET es un proyecto open source.

ORM, Pizarro Pablo

Pgina 22

Agosto 2005

Figura 6-2 Arquitectura de NHibernate

Algunas de las caractersticas ms importantes: Permite el mapeo de relaciones a tipos .NET especficos. Permite una buena interfase para estructurar la consulta a partir de criterios. Las transacciones son administradas por objetos Session. La configuracin del mapeo y dems se administra tanto por cdigo como por fuera de l. Accede tanto a propiedades privadas, pblicas o protegidas. No soporta an la carga retardada en asociaciones 1 a 1. Las asociaciones son mapeadas a objetos IList, Collection o Dictionary. Asocias las clases con sus correspondientes proxys. Soporta bases en SQLServer, Oracle y parcialmente OleDB. Soporta actualizaciones en cascada, con posibilidad de especificar que tipo de actualizacin est permitido: insert, update y delete.

La configuracin de NHibernate es fuera de banda, a travs de archivos en xml.

ORM, Pizarro Pablo

Pgina 23

Agosto 2005

Figura 6-3 Configuracin de NHibernate

7 Conclusin
En el presente trabajo, mostr como unir los 2 mundos de software actuales ms difundido, modelo de objetos y base de datos relacionales, a travs de frameworks conocidos como Object Relacional Mapping. Hay 3 pasos para mapear objetos a relaciones: 1. Disear el modelo de objetos. 2. Modelar el relacional. 3. Aplicar los mapeos correpondientes. Hemos visto los 2 frameworks en ,Net ms usados, NHibernate y OJB.NET, con sus ventajas y desventajas. En conclusin, el uso de herramientas ORM presenta las siguientes ventajas: Reduccin de hasta un 25% del tiempo de desarrollo dedicado al mapeo. Evita el SQL HARD-CODED, especificando en archivos de configuracin las tablas, propiedades, etc. Sin preocuparse por el renombre de tablas, columnas etc. Correspondencia lgica y natural del modelo de objetos.

ORM, Pizarro Pablo

Pgina 24

Agosto 2005

8 Bibliografa
[AMBLER1] Ambler, Scott. The Design of a Robust Persistence Layer for Relational Databases, http://www.ambysoft.com/persistenceLayer.pdf. Ledo el 11 de Marzo del 2005. [AMBLER2] Ambler, Scott. Mapping Objects to Relational Databases: O/R Mapping In Detail. http://www.agiledata.org/essays/mappingObjects.html. Ledo el 20 de Marzo del 2005. [BEAUCHAMP1] Beauchamp, Richard. OJB.NET an object-to-relational persistence tool for the .NET platform: User QuickStart Tutorial. http://ojb-net.sourceforge.net. Ledo el 20 de Marzo del 2005. [BELLWARE1] Bellware, Scott. Object-Relational Persistence for .NET, http://www.15seconds.com/issue/040112.htm. Ledo el 20 de Marzo del 2005. [BERGLAS1] Berglas, Anthony. Object Relational Mapping Tools. http://www.uq.net.au/~zzabergl/simpleorm/ORMTools.html. Ledo el 11 de Marzo del 2005. [CRESPO1] Crespo Martn, Cesar. Tutorial de Hibernate, http://www.adictosaltrabajo.com/tutoriales/view.php?tutorial=hibernate. Ledo el 8 de Marzo del 2005. [FOWLER1] Fowler, Martin.Catalog of Patterns of Enterprise Application Architecture. http://martinfowler.com/eaaCatalog/index.html. Ledo el 11 de Marzo del 2005. [FUSSELL1] Fussell, Mark. Foundations of Object Relational Mapping. http://www.chimu.com/objectRelational.pdf . Ledo el 20 de Abril del 2005. [GLOGLS1] Glgls, Michael. Why we need Hibernate: What an object-relational mapper does. http://www.gloegl.de/17.html. Ledo el 20 de Marzo del 2005. [HANSON1] Hanson, Jeff. Persistencia de Objetos Java utilizando EJBs, Traduccin de Juan Antonio Palos. Error! Referencia de hipervnculo no vlida.. Ledo el 20 de Marzo del 2005. [HANSON2] Hanson, Jeff. Persistencia de Objetos Java utilizando Hibernate, Traduccin de Juan Antonio Palos. http://programacion.com/articulo/jap_persis_hib. Ledo el 20 de Marzo del 2005. [KELLER1] Keller, Wolfgang. Persistence Options for Object-Oriented Programs. http://www.objectarchitects.de/PersistenceOptionsOOP2004e.pdf. Ledo el 20 de Marzo del 2005. [KELLER2] Keller, Wolfgang. Object/Relational Access Layers: A Roadmap, Missing Links and More Patterns. http://www.objectarchitects.de/or06_proceedings.pdf. Ledo el 20 de Abril del 2005.

ORM, Pizarro Pablo

Pgina 25

Agosto 2005

[MARGUERIE1] Marguerie, Fabrice. Choosing an object-relational mapping tool. http://madgeek.com/Articles/ORMapping/EN/mapping.htm, http://weblogs.asp.net/fmarguerie. Ledo el 20 de Marzo del 2005. [NHIBERNATE1] NHibernate Project. What is NHibernate. http://nhibernate.sourceforge.net/ . Ledo el 20 de Abril del 2005. [OJB1] OJB project. OJB Project. http://ojb-net.sourceforge.net/ . Ledo el 20 de Abril del 2005. [PERSISTENCE1] Persistence Software. Edge Extend for .Net. http://www.persistence.com/docs/edgextendfor.net_us.pdf. Ledo el 20 de Marzo del 2005. [SCE1] SCE. Persistence Layer Architecture. http://www.scetech.com/architecture/persistence_layers.html. Ledo el 20 de Marzo del 2005.

ORM, Pizarro Pablo

Pgina 26

Agosto 2005