Java Persistence API (JPA) Relationships

Kinds of relationships UML associations and aggregations (ER non- identifying relationships, shared semantics) One-to-one One-to-many Many-to-one Many-to-many UML compositions (ER identifying relationships, non- shared semantics) One-to-one One-to-many Java Persistence API - relationships2

@Entity public class Order implements Serializable private int id; private String private Shipment shipment;... public Shipment getShipment() { return shipment; } public void setShipment(Shipment shipment) { this.shipment = shipment; } Table Order has foreign key to table Shipment Java Persistence API - relationships3 Association and aggregation: unidirectional one-to-one

Attribute cascade Example above could be written this way private Shipment shipment; We specified that method persist() invoked on entity Order must cascade to related entity Shipment Attribute cascade may have these values: PERSIST, MERGE, REMOVE, REFRESH, and ALL Java Persistence API - relationships4

Association and aggregation: bidirectional public class Shipment implements Serializable private int id; private String city; private String private Order order; public Order getOrder() { return order; } public void setOrder(Order order) { this.order = order; } } Java Persistence API - relationships5 Table Order has foreign key to table Shipment because Order is owner of the relationship Table Order has foreign key to table Shipment because Order is owner of the relationship

Association and aggregation: unidirectional public class Employee implements Serializable private Company company; public Company getCompany() { return this.company; } public void setCompany(Company company){ this.company = company; } Java Persistence API - relationships6 Table Employee contains a foreign key to table Company.

Association and aggregation: bidirectional public class Company implements Serializable private Collection employees; public Collection getEmployees() { return this.employees; } public void setEmployees(Collection employees){ this.employees = employees; } Java Persistence API - relationships7

Association and aggregation: unidirectional one-to-many Per JPA specification: Unidirectional multi-valued relationships always have join table (!) That is, we cannot have unidirectional one-to-many relationship with the owner being on “one” side We can: create bidirectional relationship, owner must be “many” side or create join table Java Persistence API - relationships8

Association and aggregation: unidirectional public class Student implements private Collection courses; public Collection getCourses() { return courses; } public void setCourses(Collection courses) { this.courses = courses; } Java Persistence API - relationships9

Association and aggregation: bidirectional public class Course implements Serializable private Collection students; public Collection getStudents() { return students; } public void setStudents(Collection students) { this.students = students; } Java Persistence API - relationships10

Association and aggregation: what needs to be known For one-to-one bidirectional relationships, the owning side corresponds to the side that contains the corresponding foreign key The many side of one-to-many / many-to-one bidirectional relationships must be the owning side hence the mappedBy element cannot be specified on the ManyToOne annotation. For many-to-many bidirectional relationships either side may be the owning side Java Persistence API - relationships11

Association and aggregation: what needs to be known Bidirectional relationships will be persisted based on references held by the owning side of the relationship It is the developer’s responsibility to keep the in-memory references held on the owning side and those held on the inverse side consistent with each other when they change It is particularly important to ensure that changes to the inverse side of a relationship result in appropriate changes on the owning side, so as to ensure the changes are not lost when they are synchronized to the database Java Persistence API - relationships12

Kinds of relationships – aggregation Room – Chair identity of chair does not depend on identity of room chair is sharable – we can move chair from one room to another, and chair will not change its identity chair may exist without room – it may temporarily be placed outside of the house All these properties characterize aggregation relationship – relationship with sharable semantics Also known as non-identifying relationships in ER modeling Java Persistence API - relationships13

Kinds of relationships – composition House – Room identity of room depends on identity of house – room is always part of some house if house would change its identity (imagine reconstruction), rooms most probably would be renumbered room is non-sharable – we cannot move room from one house to another room cannot exist without house – if we destroy house, all its rooms are destroyed implicitly All these properties characterize composition relationship – relationship with non-sharable semantics Also known as identifying relationships in ER modeling Java Persistence API - relationships14

Implementing composition with JPA There are two ways to model composition (ER identifying) relationship: Usual one-to-many relationship with additionally applied non-shared semantics (automatic orphan deletion) – attribute orphanRemoval as noted above, programmer must take care of both ends of relationship Specialized relationship – embedded element collection ) it is enough to take care of one end of relationship Java Persistence API - relationships15

Composition: one-to-many with orphan removal may be specified with public class House orphanRemoval=true) Collection rooms; } This way we are requesting non-sharable semantics – if relation “child – parent” gets broken (parent is destroyed, or child is removed from parent’s collection), child is destroyed automatically Java Persistence API - relationships16

Composition: one-to-many with orphan removal In the example above: If room gets removed from house’s collection (e.g.: house.getRooms.remove(0) ), then the room will be deleted from DB automatically If house is deleted from database then all its rooms are deleted from database automatically Note: programmer must obey the rules of non- sharable semantics Removing one room from some house’s collection and adding it to other house’s collection would violate rules of non-sharable semantics Java Persistence API - relationships17

Java Persistence API - relationships18 Example

Composition: StudyJournal – Record embedded element collection public class StudyJournal implements name=“Record", private List records;... } Java Persistence API - relationships19

Composition: StudyJournal – Record embedded element // ! public class Record implements Serializable = "semester") private String = "courseTitle") private String = "assessment") private Integer assessment;... setters/getters... public boolean equals(Object obj) {...} public int hashCode() {...} } Java Persistence API - relationships20

Composition: Student – StudyJournal One-to-one relationship cannot be implemented as embedded element collection, we use orphanRemoval attribute instead: In entity = "student", orphanRemoval=true) private StudyJournal studyJournal ; In dependent @JoinColumn(name = "Student_id", referencedColumnName = "id") private Student student; Java Persistence API - relationships21

What is important for an architect Data/information models can be design in different abstraction levels: Logical UML class diagrams many kinds of relationships (association, aggregation, composition, etc.) normal forms are not being applied usually Logical ER models two relationships (identifying and not-identifying) normal forms are being applied Physical ER models data types and other physical properties (table partitioning etc.) are specified Java Persistence API - relationships22

What is important for an architect If database is designed with wrong relationships (aggregation in place of composition): you will not be able to use embeddable element collections you’ll have to relationship with orphan removal set to true and take care of both ends of the relationship – more chances that programmer will make a mistake Conclusion: architect must participate in data/information logical model reviews Java Persistence API - relationships23