sistemas

Hibernate Framework
Persistencia relacional para Java y .NET
Javier Alexander Hurtado
Ingeniero en Electrónica y Telecomunicaciones
javhur@unicauca.edu.co

¿Qué es Persistencia?
• Concepto fundamental en el desarrollo
de aplicaciones
• Preservar los datos que han ingresado
los usuarios ante cualquier eventualidad
• Persistencia en Java = Almacenar
datos en un RDBMS usando SQL
•Implementaciones
– POJO’s
– JavaBeans

EJB Entidad
DAO’s

Ing. Javier Alexander Hurtado

1

El problema de la Persistencia
• ¿Es un problema resuelto por la Tecnología
Relacional
y
extensiones
como
Procedimientos Almacenados?
• ¿Es tan importante que debe ser resuelto con
modelos de componentes Java especiales
como EJB’s de entidad?
• ¿Debemos escribir a mano las operacionesbásicas usando SQL y JDBC? ¿Debería ser
automático?
• ¿Y la portabilidad? Cada RDBMS tiene su
propio dialecto SQL
• ¿Debemos considerar el uso de tecnologías
como Bases de Datos Orientadas a Objetos?
Ing. Javier Alexander Hurtado

¿Qué hacen bien los RDBMS?
• Trabaja con grandes cantidades de datos
– Buscando, Ordenando

• Trabaja con conjuntos de datos
– Uniendo, Agregando

• Comparten– Concurrencia (Transacciones)
– Muchas aplicaciones

• Integridad
– Constraints (Restricciones / Reglas / Llaves)
– Transacciones aisladas / separadas
Ing. Javier Alexander Hurtado

2

¿Qué hacen mal los RDBMS?
• Modelado
– No soporta polimorfismo
– Modelos muy granulares son difíciles

• Lógica de Negocio
– Procedimientos almacenados no portables

• Distribución
–(discutible)
Ing. Javier Alexander Hurtado

Modelo Relacional vs Modelo OO
• Operaciones SQL resultan en una
representación tabular de los datos, algo
bien diferente al modelo de objetos
interconectados en un modelo del dominio.

Ing. Javier Alexander Hurtado

3

Modelo Relacional vs Modelo OO
User

BillingDetails
1*

public class User {
private String userName;
private String name;private String address;
private Set billingDetails;
// accessor methods (get/set pairs),
...
}

public class BillingDetails {
private String accountNumber;
private String accountName;
private String accountType;
private User user;
// accessor methods (get/set pairs),
}

Ing. Javier Alexander Hurtado

Modelo Relacional vs Modelo OO
User

BillingDetails
1*

create table USER (USERNAME VARCHAR(15) NOT NULL PRIMARY KEY,
NAME VARCHAR(50) NOT NULL,
ADDRESS VARCHAR(100)
)
create table BILLING_DETAILS (
ACCOUNT_NUMBER VARCHAR(10) NOT NULL PRIMARY Key,
ACCOUNT_NAME VARCHAR(50) NOT NULL,
ACCOUNT_TYPE VARCHAR(2) NOT NULL,
USERNAME VARCHAR(15) FOREIGN KEY REFERENCES USER
)

Ing. Javier Alexander Hurtado

4

Modelo Relacional vs Modelo OO

Address

1..*User

BillingDetails

Opción 1: Uso de UDT (User Defined Type)
Desventaja: No es portable

User
Name

Adress:ADDRESS

…….

Ing. Javier Alexander Hurtado

Modelo Relacional vs Modelo OO
Address

User

1..*

BillingDetails

Opción 2: Forzar los tipos al modelo relacional
create table USER (
USERNAME VARCHAR(15) NOT NULL PRIMARY KEY,
NAME VARCHAR(50) NOT NULL,
ADDRESS_STREETVARCHAR(50),
ADDRESS_CITY VARCHAR(15),
ADDRESS_STATE VARCHAR(15),
ADDRESS_ZIPCODE VARCHAR(5),
ADDRESS_COUNTRY VARCHAR(15)
)

Ing. Javier Alexander Hurtado

5

Modelo Relacional vs Modelo OO
• El problema de la herencia
Address

User

1..*

BillingDetails

CreditCard

BankAccount

SQL: No soporta directamente la herencia
CREATE TABLE CREDIT_CARD_DETAILS EXTENDSBILLING_DETAILS (...) ????

Ing. Javier Alexander Hurtado

Modelo Relacional vs Modelo OO
• El problema del polimorfismo
Address

User

1..*

BillingDetails

CreditCard

BankAccount

Modelo de objetos: en tiempo de ejecución User podría estar
asociado con cualquiera de las instancias de BillingDetails
Modelo Relacional: una clave foránea se refiere a una y sola
una tabla. No es tan...