Manual de JPA - Java

Manual Avanzado de JPA
Por:
Carmelo Navarro Serna

1

ÍNDICE
INTRODUCCIÓN

3

BASES DE DATOS

3

CONFIGURACIÓN DE JPA

5

TRANSACCIONES

10

MODIFICAR DATOS

13

CONCLUSIÓN

16

2

Introducción
El siguiente artículo está dirigido a personas que tienen un buen conocimiento
de JPA. No voy a explicar que es JPA, para que sirve, como se configura, cual
es lamejor implementación, no voy a explicar Javadoc, ni nada por el estilo. Si
quieres algo como lo que enumerado anteriormente mejor mira otro artículo y/o
tutorial; en la red hay muchos muy buenos.
Mi objetivo es explicar como utilizar JPA en una aplicación pero no desde el
punto de vista solo de la programación sino explicar como utilizar JPA de forma
correcta para resolver las situaciones máscomunes que se presentan en una
aplicación.
Mi intención es profundizar lo suficiente para poder ayudar en la construcción
de aplicaciones proporcionando decisiones generales que se deben tomar
desde el principio del desarrollo como el uso de las funciones del
EntityManager, ciclo de vida de las transacciones, uso de las entidades, etc…
Por este motivo voy a ir al grano y daré por entendido queel lector tiene un
conocimiento mínimo de JPA.
El artículo es un manual para desarrolladores sobre la especificación de JPA
1.0. Para ilustrar ejemplos he utilizado la implementación OPENJPA 1.2.0.

Bases de datos
El primer problema que se nos plantea es la base de datos. A la hora de
planificar el modelo de datos debemos seguir las siguientes pautas:
-

La clave primaria mejor que seaun campo numérico por varios motivos:
o La clave primaria NUNCA puede ser vista por el usuario de la
aplicación donde estemos utilizando JPA. Esta prohibido mostrar
una clave primaria por pantalla. Esto descarta campos mas
pesados que los numéricos como los de texto.
o El orden es el más obvio de todos los tipos de datos.
o Permite su uso para operaciones aritméticas de forma fácil.
oPermite el uso de secuencias.
o Etc..

-

Respetar la lógica de los nombres. Es decir, si la tabla PERSONA tiene
una clave primaria que es el campo ID ó ID_PERSONA entonces si la
tabla TRABAJADOR tiene un campo que hace referencia a la tabla
persona se ha de llamar ID_PERSONA (no PERSONA ó REF_PERS ni
nada por el estilo). Y esta regla se aplicaría a cualquier tabla que haga
referencia aPERSONA.
Si un campo de una tabla es clave ajena entonces DEBEMOS CREAR
DICHA CLAVE AJENA. Esto puede parecer una tontería tener que
puntualizarlo pero en muchos casos el equipo de desarrollo sabe que un
campo es clave ajena pero la clave ajena como tal no esta creada.

-

3

-

Buena estrategia de índices. No todos los campos pueden ser índices.
Merece la pena hacer un esfuerzo porconocer bien el negocio de la
aplicación y establecer los campos que van a ser índices en cada tabla.
Yo te recomiendo el siguiente proceso:
o Todos los campos que se utilizan como criterios de búsqueda
desde la interfaz son índices. Ejemplo, si tienes una tabla
Persona que tiene un campo Id_Provincia y tienes una pantalla
de búsqueda de personas y sale el campo provincia entonces
Id_Provinciaes un índice.
o Mira TODAS las consultas de la base de datos y si un campo se
repite varias veces en consultas que tienen una alta frecuencia de
uso entonces ese campo es índice. Ejemplo, si tienes una tabla
Persona que tiene un campo Id_Empresa y en casi todas tus
consultas sobre la tabla Persona haces JOIN con la tabla
Empresa a través del campo Id_Empresa entonces Id_Empresa
es un índice.Todas las operaciones que se hacen de acceso a datos al final son consultas
(‘select’) y modificaciones (‘insert’, ‘update’ y ‘remove’).
Por rendimiento siempre hay que ver cual es el tamaño de operaciones
atómicas (que afectan solo a un registro) de modificación (‘insert’, ‘update’ y
‘remove’) que caben en una transacción. Es decir, en una transacción se
pueden incluir cualquier número...