1. Java Persistence API (JPA) Relationships

2. 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

3. @Entity public class Order implements Serializable { @Id private int id; private String orderName; @OneToOne 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

4. Attribute cascade Example above could be written this way too: @OneToOne(cascade={CascadeType.PERSIST}) 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

5. Association and aggregation: bidirectional one-to-one @Entity public class Shipment implements Serializable { @Id private int id; private String city; private String zipcode; @OneToOne(mappedBy=”shipment”) 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

6. Association and aggregation: unidirectional many-to-one @Entity public class Employee implements Serializable {... @ManyToOne 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.

7. Association and aggregation: bidirectional many-to-one @Entity public class Company implements Serializable {... @OneToMany(mappedBy="company") private Collection employees; public Collection getEmployees() { return this.employees; } public void setEmployees(Collection employees){ this.employees = employees; } Java Persistence API - relationships7

8. 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

9. Association and aggregation: unidirectional many-to-many @Entity public class Student implements Serializable { @ManyToMany @JoinTable(name=”STUDENT_COURSE”) private Collection courses; public Collection getCourses() { return courses; } public void setCourses(Collection courses) { this.courses = courses; } Java Persistence API - relationships9

10. Association and aggregation: bidirectional many-to-many @Entity public class Course implements Serializable { @ManyToMany(mappedBy="courses") private Collection students; public Collection getStudents() { return students; } public void setStudents(Collection students) { this.students = students; } Java Persistence API - relationships10

11. 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

12. 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

13. 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

14. 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

15. 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 ( @ElementCollection ) it is enough to take care of one end of relationship Java Persistence API - relationships15

16. Composition: one-to-many with orphan removal Relationships @OneToOne and @OneToMany may be specified with orphanRemoval=true @Entity public class House { @OneToMany(mappedBy="room", 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

17. 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

18. Java Persistence API - relationships18 Example

19. Composition: StudyJournal – Record embedded element collection public class StudyJournal implements Serializable { @ElementCollection @CollectionTable( name=“Record", joinColumns=@JoinColumn(name=“Student_id")) private List records;... } Java Persistence API - relationships19

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

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

22. 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

23. 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 use @OneToMany 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