saliente "unidireccional" lado por el momento, se podría modelar una relación cliente-Orden de la siguiente manera.
@Entity
public class Customer {
// ...
@Id @GeneratedValue
int id;
@OneToMany(cascade = CascadeType.ALL, mappedBy = "customer")
Set<Order> orders;
// ...
}
@Entity
public class Order {
// ...
@ManyToOne(optional = false)
Customer customer;
// ...
}
Aquí supongo que cada pedido tiene exactamente un cliente. En la base de datos, la tabla de pedidos tendría una columna "customer_id" con una clave externa a la columna "id" de la tabla Customer. El DDL se parecería a lo siguiente.
CREATE TABLE Customer (
id INT NOT NULL,
...
PRIMARY KEY (id)
);
CREATE TABLE Order (
...
customer_id INT NOT NULL,
...
FOREIGN KEY (customer_id) REFERENCES Customer (id)
);
Aunque la clase Cliente contiene una colección de pedidos, esto en realidad no afecta la estructura de la base de datos de ninguna manera; es solo una forma conveniente de recuperar/administrar pedidos que pertenecen al cliente. Por ejemplo, puede eliminar el miembro de "pedidos" del cliente y confiar en las consultas para recuperar estos registros.
El punto que estoy tratando de hacer es que, desde la perspectiva de la base de datos , realmente no existe una relación "unidireccional". El ejemplo reverendgreen proporcionado producirá clases Java donde no hay directa forma de obtener un objeto Cliente de un objeto Orden, pero la estructura resultante de la base de datos será idéntica (ignorando las diferencias menores en los nombres de las columnas). Siempre puede encontrar al cliente para un pedido determinado mediante una consulta.
Tenga en cuenta que JPA 1.0 ** no admite una relación 'OneToMany' unidireccional ** sin ** una' JoinTable'. En otras palabras, no puede mapear el modelo de tablas anterior con un 'OneToMany' unidireccional y, por lo tanto, no ilustra su respuesta con precisión. –
Pascal es correcto. El ejemplo anterior funciona solo para JPA 2.0. –
@JoinColumn (name = "cust_id", referenciadoColumnName = "owner_id") ¿verdad? – uuidcode