JPA

Componentes:
1. Entity Objects (entidades)
Objeto persistente del modelo de dominio, con las caractersticas de un
POJO, que ha sido mapeada a una Tabla de BD aplicando ORM, donde cada
instancia representa un registro en la Tabla, por lo cual tiene un objeto
identificador nico (Llave primaria) que le da identidad y maneja un conjunto
de estados a travs de sus propiedades persistentes (setter/getter) o campos
persistentes (variables de instancia).
El ORM consiste en asociar Metadata a las entidades lo cual se realiza con
Anotaciones o XML. JPA 2 con Hibernate 6
En general son POJO mapeados con anotacin @Entity
El estado de persistencia de una entidad se representa a travs de
campos persistentes o propiedades persistentes.
Los campos persistentes o mtodos getter de propiedades persistentes
pueden tener definido el mapeo con Anotaciones.
No se consideran para la persistencia aquellos campos que estn
mapeados con la anotacin @Transient.
La identidad de una entidad puede estar definida con uno o ms
campos persistentes o propiedades persistentes.
Debe tener como mnimo mtodo constructor sin argumentos.
Tanto la clase como sus mtodos o campos persistentes no pueden
ser final.
Campos persistentes son private o protected.
Pueden heredar otras entidades y no entidades.
Son transaccionales.
Los campos o propiedades persistentes pueden ser los siguientes:
Datos primitivos
Objetos serializados por ejemplo String, Integer, Date, byte[], etc.
Enumeraciones
Otras entidades o coleccin de entidades.
Clases embebidas.

2. Entity Manager
Es un API que gestiona el ciclo de vida de las instancias de Entidades y
permite realizar operaciones con BD, por ejemplo persistir el estado de la
entidad u obtener datos de una Entidad.
Las entidades gestionadas por el Entity Manager son denominadas managed
(attached).
Su implementacin se basa en la interfaz EntityManager que define los
mtodos que sern usados para sincronizar la informacin entre las Entidades
y la BD cuando el Entity Manager lo solicite.
Una Entidad que no est gestionada por el Entity Manager no es un objeto
persistente, por tanto su estado no ser controlado ni sincronizado en BD,
siendo solo una clase java simple en caso de ser nuevas instancias o
detached si previamente fueron managed.
Una instancia de EntityManager est asociada solo a un nico Persistence
Context.

a. Entity Manger Factory

Fbrica utilizada para crear Entity Manager de entidades configuradas

en un Persistence Unit.
Su uso en la programacin es necesario cuando la aplicacin gestiona
los Entity Manager. De lo contrario, el contenedor se encarga de
generar las instancias del Entity Manager. De cualquier forma, a partir
de una instancia de EntityManager, se puede acceder al Entity Manager
Factory que lo cre.
Instancias de este objeto son Thread Safe.

b. Persistence Unit
Una unidad de persistencia define la configuracin y entidades que
sern gestionadas por los Entity Managers. Ello se realiza en un archivo
llamado persistence.xml.
La relacin entre un Persistence Unit y un Entity Manager Factory es de
uno a uno.

c. Persistence Context
Contiene un conjunto de instancias de Entidades managed, por tanto
est asociado a un Entity Manager.
Entidades que salen del Persistence Context se les denomina
detached.
No es visible en la aplicacin pero se accede indirectamente a travs
del Entity Manager.
En un mismo Persistence Context no puede haber dos instancias de
Entidades con la misma identidad.
Tiene dos tipos de scope:
a) Transaction-scoped Persistence Context
Su tiempo de vida est asociado con la duracin de una transaccin.
Cuando un mtodo de negocio inicia su ejecucin, al primer uso del
Entity Manager se crea el Persistence Context con las instancias de
Entidades managed.
Posteriores usos de instancia del EntityManager dentro de la misma
transaccin reutilizan el Persistence Context.
Al terminar una transaccin (commit o rollback), se persisten los
cambios de estado de las entidades y luego dichas entidades se
vuelven detached, es decir dejan de estar asociadas al
Persistence Context y ya no son gestionadas por el
EntityManager.
Finalmente, el Persistence Context asociado es cerrado.
Se puede utilizar solo cuando un contenedor gestiona los Entity
Manager con transaccin JTA.
b) Extended-scoped Persistence Context
Su tiempo de vida es independiente al de una transaccin. Por tanto,
el mismo Persistence Context se puede utilizar en mltiples
transacciones de un proceso de negocio manteniendo en
managed las instancias de Entidades asociadas.
Utilizado en Statefull Session Bean.
Cuando Persistence Context es cerrado, las instancias de entidades
se vuelven detached.
JPA maneja dos niveles de Cach. El Persistence Context acta
como First Level Cache mientras dura una transaccin
(Transaction-scoped) o mientras est activa la instancia del Entity
Manager (Extendedscoped).

Configuracin Bsica
1. Archivos de Configuracin: persistence.xml (requerido)

Permite configurar uno o ms Persistence Unit.

Las configuraciones de Persistence Unit solo se pueden realizar en XML, el
cual debe estar ubicado dentro de la carpeta META-INF del proyecto.
Elementos:
a) persistence-unit
Es independiente de los dems, por ello tiene un nombre que lo
identifica y a travs del mismo ser referenciado al crear un Entity
Manager Factory.
Asimismo, define el tipo de Transaccin RESOURCE_LOCAL o JTA.
RESOURCE_LOCAL: Este tipo de transaccin permite al programador
controlar y validar la ejecucin de las transacciones, por lo cual
determinar cuando confirmar la transaccin a la base de datos
(commit) o cuando cancelar una transaccin (rollback). Por default en
aplicacions Java SE.
JTA: Con este tipo de transaccin, el programador no debe preocuparse
por la parte transaccional, ya que es el Contenedor de aplicaciones el
que se encargar de realizar los commit o rollback de manera
automtica. Por default en aplicaciones Java EE.
b) provider
JPA define un SPI (Service Provider Interface) que permite a cualquier
servidor de aplicaciones Java EE comunicarse con cualquier proveedor
de implementacin de JPA.
Un servidor puede tener definido un proveedor por defecto.
Si se requiere utilizar una implementacin de JPA distinta a la que el
servidor maneja por defecto, se debe indicar en el elemento Provider la
clase que implementa la interfaz javax.persistence.spi.PersistenceProvider,
por ejemplo en el caso de Hibernate.
c) class
Permite definir las Entidades mapeadas con Anotaciones @Entity,
@Embeddable o @MappedSuperclass; que sern parte de un
Persistence Unit.
d) mapping-file
La configuracin de Entidades tambin puede realizarse en uno o ms
archivos XML. Dichos archivos, por lo general se ubican en la carpeta
META-INF del proyecto. Cada archivo debe declararse con este
elemento.
e) jar-file
Las entidades tambin pueden ser empaquetadas en un archivo jar que
est en el classpath de la aplicacin.
Con este elemento se indica el nombre del jar que contiene las
entidades. Al inicializar el Persistence-Unit, el Provider aadir los
Entitys configurados con anotaciones y de haber mapping-file tambin
aquellos Entitys configuradas all.
f) properties

Utilizado para especificar propiedades de configuracin del API y de la

implementacin en Uso, por ejemplo el nivel de logging a utilizar, datos
de conexin a base de datos, etc.

2. Entidad
En el curso para aplicar ORM vamos a realizar la configuracin de metadata
con
Anotaciones.
Anotaciones
Permite definir metadatos a elementos de un programa Java. Estos metadatos
estarn disponibles en tiempo de ejecucin permitiendo a otros programas
determinar cmo interactuar con los elementos del programa.
Sintaxis: @NombreAnotacion (atributos)
Las anotaciones se pueden aplicar a Clases Java, mtodos, variables de
instancia, parmetros, etc.
En JPA se tiene definido un conjunto de Anotaciones de Persistencia
personalizadas, que en su mayora realizan una configuracin equivalente al
uso de archivos externos (XML). En este caso, se puede aplicar a nivel de
Clase, mtodos y variables de instancia.
Aqu mencionaremos las Anotaciones mnimas necesarias para aplicar
ORM.
@Entity: Indica que la clase es persistente.
@Id: Indica el campo identificador de la clase que representa la llave
primaria en la tabla
Por defecto, todos los campos de la Entidad son persistentes.
Dado que el nombre de la clase y campos persistentes son idnticos al nombre
de la tabla y columnas, respectivamente, el mapeo es automtico y no se
requiere mayor configuracin por el momento.

3. Gestin de los Entity Manager

a) Entity Manager gestionado por Contenedor: Container-Managed
El contenedor es responsable del ciclo de vida del Entity
Manager/Persistence Context as como aspectos de las transacciones.
Una instancia de EntityManager se puede obtener de dos formas.
Por JNDI.
Por
Inyeccin
de
Dependencias
con
la
anotacin
@PersistenceContext
Se utiliza en entornos Java EE y requiere JTA.
Sobre el Persistence Context:
Es propagado automticamente por el contenedor asocindolo a una
transaccin JTA cuando se inyecta una instancia de EntityManager en
los componentes de la aplicacin.
Soporta dos tipos de scope:
Transaction-scoped Persistence Context
Extended Persistence Context
b) Entity Manager gestionado por Aplicacin: Application-Managed
El control de ciclo de vida de los Entity Managers, del Persistence Context
as como el manejo de las transacciones lo tiene la aplicacin.
Se utiliza en entornos Java EE y Java SE.
Tenemos dos formas para obtener instancia de EntityManagerFactory.

Entorno Java SE: Uso de la clase Persistence

Entorno Java EE: Inyeccin de Dependencias con la anotacin
@PersistenceUnit
Una instancia de EntityManager se obtiene invocando el mtodo
createEntityManager() de un EntityManagerFactory.
Sobre el Persistence Context:
No es propagado automticamente a los componentes, por tanto se
crear al instanciar un nuevo EntityManager y este deber ser
compartido a los dems componentes envindolo como argumento de
los mtodos.
Soporta tipo de transaccin RESOURCE-LOCAL (JDBC) que es
gestionada en la aplicacin con el objeto EntityTransaction (Java EE/
Java SE) y tipo de transaccin JTA (Java EE) con el Objeto
UserTransaction.

4. Entity Manager
Una vez terminado el ORM y definido el tipo de gestin del Entity Manager,
se procede a implementar las operaciones bsicas del CRUD utilizando el
Entity Manager.
Las operaciones principales son las siguientes:

persist
Convierte una instancia nueva de una Entidad en managed volvindola
persistente.
Su estado se sincronizar con BD al ejecutar el commit de la transaccin o
antes de ello, ejecutando el mtodo flush() del Entity Manager.

remove
Remueve una instancia de Entidad managed y queda en espera para su
sincronizacin.
Su estado se sincronizar con BD al ejecutar el commit de la transaccin
o antes de ello, ejecutando el mtodo flush() del Entity Manager.

merge
Convierte en managed instancias detached o nuevas.
Su caracterstica principal es que puede trabajar con instancias detached
o instancias nuevas, segn ello en la BD persistir los cambios o crear
un nuevo registro.
Su estado se sincronizar con la BD al ejecutar el commit de la
transaccin o antes de ello, ejecutando el mtodo flush() del Entity
Manager.
Tpicamente es usado en el siguiente escenario:

Se obtiene instancia managed y al cerrar Persistence Context, se

enva como detached a la capa de presentacin.
Usuario realiza algunos cambios en los estados y solicita persistirlos.

Se obtiene nueva instancia de EntityManager y se convierte instancia

detached en managed a travs del mtodo merge.

find
Busca en BD una Entidad a travs de su llave primaria. De encontrarla
asocia su instancia al Persistence Context, por tanto es managed. Al
cerrar el Persistence Context, instancia se vuelve detached.

flush
Sincroniza el Persistence Context con la BD.
Los cambios de estado realizados en las Entidades managed durante
una transaccin son sincronizados antes de que se ejecute el commit de
la misma.
Por ejemplo, si durante una transaccin, se ejecut el mtodo persist()
para una nueva instancia de Entidad, est instancia permanecer en el
Persistence Context esperando su sincronizacin con la BD hasta que se
ejecute el mtodo flush() o el commit de la transaccin.

clear
Limpia el Persistence Context, volviendo todas las instancias managed
en detached. Los cambios de estado que no hayan sido sincronizados
previamente se perdern.

detach
Quita una instancia de Entidad managed del Persistence Context
convirtindola en detached sin necesidad de esperar a que el
PersistenceContext sea cerrado.

Ciclo de Vida

En JPA las entidades tienen asociadas un conjunto de eventos, que se

activarn segn las operaciones realizadas sobre cada entidad.
Tenemos 4 categoras de eventos.

Registro
Actualizacin
Eliminacin
Lectura

Para las 3 primeras categoras se activa un evento antes y otro despus de la

ejecucin, mientras que para la Lectura, solo se maneja un evento despus de
la ejecucin.
El manejo de los eventos se realiza en mtodos implementados en la Entidad
que lo requiera en clases externas conocidas como EntityListeners.
Cada mtodo debe cumplir con la firma requerida y ser asociado a un evento
en particular con el uso de Anotaciones.

Mapeo Relacional Objeto

1. Mapeo de una entidad
Hemos visto en temas anteriores como aplicar ORM a entidades utilizando las
Anotaciones requeridas.
Las anotaciones JPA se pueden clasificar en 2 categoras.
a) Anotaciones de Mapeo Lgico: Permiten describir el modelo de
objeto, asociacin entre clases, etc.
b) Anotaciones de Mapeo Fsico: Describen el modelo fsico de la BD
como lo son schemas, tablas, columnas, ndices, etc.
Las anotaciones JPA se encuentran en el paquete javax.persistence y las de
Hibernate en el paquete org.hibernate.annotations.
Sobre las anotaciones:
a) @Entity: Indica que la clase es persistente.
name: alias de Entidad utilizado en JPQL
b) @Table: Indica la tabla asociada a la Entidad. si se omite, se asume
que la tabla tiene el mismo nombre que la clase pertenece al esquema
configurado por defecto.
name: Permite indicar el nombre de la Tabla especfica para la
persistencia de esta entidad.
catalog: sobreescribe el nombre de catlogo de BD
schema: sobreescribe el nombre de schema de BD
uniqueConstraints: para indicar columnas definidas como
unique.
Sobre los atributos de entidad:
Identificadores:
a) @Id: Indica el atributo identificador de la Entidad que representa la llave
primaria en la tabla.
b) Estrategia de autogeneracin de valores de Llave primaria:
@GeneratedValue: Indica que el valor puede ser generado
automticamente usando una de las siguientes estrategias.
SEQUENCE: Usar una secuencia definida en BD.
Para configurar el generador puede tener asociada la anotacin
@SequenceGenerator. Se utiliza si BD soporta sequences.
IDENTITY: Indica que columna asociada es de tipo identity, es decir
la BD se encarga de asignarle valor. Se utiliza si BD soporta
columnas de tipo identity.
TABLE: Usar una tabla para almacenar valores de llave primaria de
una o ms tablas (cada fila es una secuencia para una entidad
particular). Para configuracin el generador puede tener asociada la
anotacin @TableGenerator. Se puede utilizar en cualquier BD.
AUTO: La implementacin del API de Persistencia decide la
estrategia en funcin de la BD que se est usando.
c) Llaves primarias compuestas (Composite ID):
Tenemos dos formas de implementacin.
i.
Definir en la Entidad un nico atributo que referencie un
componente cuyos atributos forman parte de la Entidad. Para ellos,
debe realizar lo siguiente:

ii.

Crear la clase que defina un campo por cada columna que

forma la llave primaria y tenga definida la anotacin
@Embeddable.
En la entidad aplicarle la anotacin @EmbeddedId al atributo
que referencie la clase @Embeddable.
Definir en la Entidad dos o ms atributos identificadores con la
anotacin @Id segn las columnas de la llave primaria. Crear una
clase externa que replique los mismos atributos identificadores de la
Entidad.
Finalmente, en la Entidad se debe aplicar la anotacin @IdClass
para referenciar la clase externa.

Atributos
@Basic: Anotacin que se asigna por defecto a todos los atributos de
una Entidad, por lo cual JPA asume que todos los atributos son
persistentes. Se utiliza para definir estrategias de Fetch e indicar si el
campo es opcional. El FetchType recomendado para este tipo de
atributos es EAGER, el cual viene configurado por defecto.
@Column: Permite definir caractersticas fsicas de una columna de la
tabla asociada a la entidad. Por ejemplo, si el nombre del atributo es
distinto del de la columna, se debe utilizar el nombre de la columna en
atributo name para que la referencia de mapeo sea correcta. Tambin,
permite configurar si el atributo debe incluirse en la sentencia INSERT o
UPDATE con los atributos insertable updatable respectivamente.
@Embedded: Anotacin que se asigna a los atributos asociados a un
componente @Embeddable. En un componente @Embeddable se
definen atributos que son parte de una o ms Entidades y no representa
una tabla por s sola.
Dichos atributos pueden ser parte de Entidades como Cliente,
Empleado, Proveedor, etc; por tanto, una de sus caractersticas es ser
reutilizable. Cada Entidad puede agregar los atributos del componente
como un atributo ms, haciendo uso de la anotacin @Embedded.
Asimismo, en la Entidad se puede sobreescribir la configuracin de
cada atributo con la anotacin @AtributeOverrides.
@Temporal:
Utilizado
en
atributos
tipo
java.util.Date
o
java.util.Calendar para indicar la precisin de fecha requerida por la
columna en BD.
Precisiones:
DATE
TIME
TIMESTAMP
Ello es equivalente a utilizar clases del paquete java.sql.*(Date, Time y
Timestamp) para las cuales no se requiere el uso de esta anotacin por
ser especficas.
@Transient: Permite definir atributos No persistentes en un Entidad, es
decir sern ignorados por JPA. Se refiere a atributos usados en tiempo
de ejecucin cuyo valor solo es utilizado/calculado por una funcin
especfica y no requiere ser almacenado en BD.

2. Mapeo de Relaciones entre Entidades

La mayora de Entidades requiere relacionarse con una o ms entidades, lo
cual genera el modelo de dominio de una aplicacin.

En una relacin entre dos entidades se define: navegabilidad, multiplicidad y el

Rol que cada entidad asumir en la relacin.
Respecto a la navegabilidad puede ser bidireccional o unidireccional, lo cual
define si una entidad puede conocer/navegar hacia la entidad relacionada:
Bidireccional: La clase Cliente podr acceder a la clase Pas y viceversa.
Unidireccional: La clase Cliente podr acceder a la clase Pas, pero la clase
Pas no podr acceder a la clase Cliente.
Respecto a la multiplicidad define cuantas instancias de la entidad
relacionada puede tener una instancia de la Entidad: Un Cliente reside en
un Pas y en un Pas residen muchos clientes. Ello indica que una
instancia de Cliente puede acceder a una instancia de Pas, y que una
instancia de Pas puede acceder a una o muchas instancias de Cliente.
En JPA tenemos anotaciones para representar/mapear cuatro tipos de
relaciones:

@OneToOne: Representa relacin Uno a Uno. Cada instancia de una

Entidad se relaciona con una sola instancia de otra entidad.
@ManyToOne: Representa relacin Muchos a Uno. Mltiples instancias
de
una entidad pueden estar relacionadas con una sola instancia de otra
entidad.
@OneToMany: Representa relacin Uno a Muchos. Cada instancia de
una
Entidad puede estar relacionada con una o ms instancias de otra Entidad.
Esta multiplicidad es lo inverso a la relacin ManyToOne.
@ManyToMany: Representa relacin Muchos a Muchos. En este caso,
varias instancias de una Entidad pueden relacionarse con mltiples
instancias de otra Entidad.

En una entidad, las anotaciones @OneToOne y @ManyToOne se aplicarn a

atributos cuyo tipo sea un Entidad relacionada.
En una entidad, las anotaciones @ OneToMany y @ ManyToMany se
aplicarn a atributos cuyo tipo sea un Collection, Set, List Map de la
Entidad relacionada.

3. Fetch
Fetch se refiere a la estrategia definida en cada atributo de Entidad para
obtener su valor desde la BD. Hay dos tipos y son los siguientes:
EAGER: Los datos son obtenidos desde BD en un solo query al momento
de cargar una Entidad.
LAZY: El dato es obtenido desde BD la primera vez que se accede al
atributo. Es decir, al cargar una instancia de Entidad desde BD, el query no
incluir aquellas columnas que estn mapeadas como LAZY en la Entidad.
Luego de cargada la instancia de Entidad, la primera vez que se acceda a
un atributo LAZY, se generar un nuevo query para obtener desde BD su
respectivo valor.

Usos:

En atributos solo de la Entidad por defecto tiene Fetch Type EAGER, lo

cual es lo recomendable.
En atributos que representan relaciones tenemos los siguientes:
i.
@OneToOne y @ManyToOne por defecto tiene Fetch Type
EAGER, lo recomendable es configurarles Fetch Type LAZY.
ii.
@OneToMany y @ManyToMany por defecto tiene Fetch Type
LAZY, lo cual es lo recomendable.

La configuracin de FETCH realizada a nivel de atributos es genrica para su

uso en toda la aplicacin.

JAVA PERSISTENCE QUERY LANGUAJE

1. JPQL
Siglas de Java Persistence Query Language, es el lenguaje de consulta
estndar de JPA, el cual combina la sintaxis del lenguaje SQL con expresiones
de Lenguaje orientado a Objetos. Es decir que es un lenguaje similar a SQL
para consultar Entidades (objetos) en vez de Tablas.
Luego de compilar/ejecutar una sentencia JPQL, el API de JPA en base al
ORM configurado, generar una sentencia equivalente en SQL segn el motor
de BD.
Por tal razn, en JPQL se tiene soporte de caractersticas de SQL como
funciones (por ejemplo count, sum, avg), expresiones (por ejemplo LIKE,
BETWEEN), JOINS, subconsultas e inclusive definir sentencias UPDATE y
DELETE.
Estructura de una consulta JPQL:
SELECT objetos o proyecciones.
FROM Entidades(s)
WHERE filtro(s)
GROUP BY atributo(s)
HAVING filtro(s)
ORDER BY (atributo)s
Una vez definido el JPQL, se debe decidir que interfaz se usar para controlar
la ejecucin del Query. Tenemos dos interfaces: Query y TypeQuery
Query: Desde JPA 1.0 No se configura un tipo de Objeto especfico para
los resultados, por lo cualse debe realizar un casting a los resultados.
TypeQuery<Entidad>: Desde JPA 2.0, hereda la interfaz Query. Permite
especificar el tipo de Objeto asociado al resultado de la consulta JPQL.
En cualquier de las interfaces se tienen estos dos mtodos:

getResultList: Cuando el resultado esperado de consulta es una o ms

instancias.
getSingleResult: Cuando el resultado esperado de consulta es solo una
instancia.

Una forma de categorizar los tipos de consulta puede ser con JPQL dinmico.

JPQL DINMICO
Una consulta JPQL se define en un objeto STRING utilizando
concatenaciones.
Permite definir consultas dinmicas, por ejemplo una misma consulta
puede tener uno o ms filtros segn seleccin de usuario final. Ello implica
que el servidor no conozca de antemano cuales son las consultas definidas
para la aplicacin; por lo cual, el API de JPA primero debe compilar el JPQL
cada vez que se solicite su ejecucin. Otra desventaja es que por el hecho
de establecer valores dinmicamente es propenso a SQL Injection.
Para evitar SQL Injection se recomienda uso de Named Parameters u
Ordinal (Positional) Parameters.

Named Parameters

Positional Parameters

NAMED QUERIES
Permite definir consultas estticas.
Se define a nivel de Entidad utilizando las Anotaciones
@NamedQueries y @NamedQuery o con XML. Cada consulta tendr
asociado un identificador indicado con el atributo name.
Los parmetros de la consulta deben ser NamedParameter o
PositionalParameter.
Los query se compilan y mantienen en memoria desde el momento
en que se carga la aplicacin en el servidor.
Para casos de consulta a BD para reportes con datos de dos o ms tablas
tenemos las siguientes estrategias:

Obtener
Entidades
cuyas
relaciones
son
EAGER.
(NO
RECOMENDADO).
Obtener Entidades cuyas relaciones son LAZY e ir accediendo a dichos
atributos a demanda antes de que sea DETACHED. (NO
RECOMENDADO).
Obtener Entidades cuyas relaciones son LAZY, pero sobre-escribiendo
temporalmente el FETCH en el JPQL.
Mantener Persistence Context activo durante el procesamiento del
request para su uso en todas las capas y no tener error por lazy
loading.
Usar JPQL projections (Es el ms recomendado).

CRITERIA QUERY API

1. Estructura bsica de una Criteria Query
De manera anloga a JQPL, Criteria Query API permite la generacin de
sentencias de consultas, modificacin y eliminacin de manera programtica
usando las caractersticas del lenguaje de programacin Java y garantizando
seguridad en la utilizacin de tipos de datos. Al igual que JPQL su
funcionamiento se fundamente en el esquema abstracto formado por
entitidades persistentes, sus relaciones y objetos embebidos.
A continuacin el anlisis de las operaciones de Criteria query, es importante
sealar que independientemente de la complejidad de las sentencias que se
realicen, los pasos mostrados y explicados aqu son siempre los mismos.