Skip to content

4. Relationships

1. Mapping Relations

As we mentioned in the introduction, we are going to analyze how to map the different types of relationships. Before we start discussing the cardinality of relationships, we have to consider the meaning of these relationships, and we are going to review the concept of directionality of relationships.

  • Unidirectional \(\rightarrow\) We will say that a relationship is unidirectional when we will access the related object (component) from another object (owner). For example, if we mount an engine in a car, the logical thing is that the owner is the car, and from it, we will obtain the engine. In this case, inside the Car object, an Engine object will appear, and the Engine will not have an existence of its own.
  • Bi directional \(\rightarrow\) They are relations in which the related elements usually have the same weight or entity. For example, a Group of an institute and a Tutor. From a group if it makes sense to know the tutor, and we can also from a teacher (the tutor), access the group he tutors. In this case, within the Group object we have a reference to the Tutor object and vice versa.

Warning

In this type of references, as can be deduced, there is an intrinsic recursion. So, when we handle this type of bidirectional relationships, be very careful not to cause loops, since even something as simple as printing can cause our program to crash and the well-known StackOverflowException

From now, we could study all representations with JPA

2. One to One Relationships

For the explanation of the examples, we will see the design and implementation in the database of each case and how it looks in Hibernate. For this example we are going to represent a 1:1 relationship between Group and Teacher, whereas you can see that a Group has a Tutor, and a Tutor only could tutoring one Group.

![one_to_one](./img/1_1.png){width=90%}

Firstly, the class that is pointed by the foreign key. Easy-peasy, because we do not need nothing to do.

Java
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
@Data
@NoArgsConstructor
@Entity
@Table(name="Profesor")
public class Profesor {

  static final long serialVersionUID = 1L;

  @Id
  @GeneratedValue(strategy=GenerationType.IDENTITY)
  private int idTeacher;

  @Column
  private String name;

  public Profesor(String name) {
      this.name = name;
  }   
}

And now, the class that contains the foreign key. Here we need to mark that a Group need a Teacher as tutor. Let's see:

Java
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
@Data
@NoArgsConstructor
@Entity
@Table(name = "Grupo")
public class Grupo implements Serializable {

  static final long serialVersionUID = 137L;

  @Id
  @GeneratedValue(strategy = GenerationType.IDENTITY)
  private long idGroup;

  @Column
  private String level;

  @Column
  private String course;

  @Column
  private int year;

  @OneToOne(cascade = CascadeType.ALL)
  @JoinColumn(
      name="id_tutor",
      referencedColumnName = "idTeacher",
      unique=true,
      foreignKey = @ForeignKey(name = "FK_GRP_TEACH"))
  private Profesor tutor;

  public Grupo(String level, String course, int year) {
      this.level = level;
      this.course = course;
      this.year = year;
  }  

}
Notice that Group class contains a field called tutor of Profesor class, and:

  • @OneToOne(cascade = CascadeType.ALL) we mark this relation as 1:1. Moreover, we say the cascade attribute, the most important thing. Cascading is the way say that when we perform some action on the target entity (Grupo), the same action will be applied to the associated entity (Profesor). Let's review the most relevant options:
  • CascadeType.ALL propagates all operations. The same operation that we do in the target will be done it in the associated.
  • CascadeType.PERSIST propagates only persist operation on database (save).
  • CascadeType.SAVE_UPDATE is from Hibernate, not JPA, and propagate the saveOrUpdate() method. Is very similar to persist.
  • CascadeType.REMOVE or CascadeType.DELETE propagates deletion of entities. Be very careful with this option to avoid lose data.
  • In the @JoinColumn we set:
  • name of the column in our database
  • name of the column referenced in target entity Profesor
  • unique=true to ensure that the relation is 1:1 (a teacher can not be related with any other Group)
  • [optional] to set the foreign key constraint name, in case you want to rename or remove in future operations.

You can find more info at baeldung

2.1. One to One bidirectional

If we want to store in Profesor the groups that he or she is tutoring, we need to add a reference to the Group. Due to we have done the foreign key in Group, it will be very easy:

Java
1
2
@OneToOne(mappedBy= "tutor") 
private Grupo elGrupo;

With mappedBy="tutor" we are saying that in Grupo class exists a field called tutor with the whole information about the relation. Notice that no extra fields will beb added in Profesor, because information about the relation is in Group table.

3. One to Many

For this explanation we will start from the following model, in which a Book has an Author who has written it, and an Author may have written several Books. In the relational schema, the relationship is from idAuthor in Books, which is foreign key to the Author table (ID).

![one_to_many](./img/1_N.png){width=90%}

First, we can decide who is the owner of the relation. It really does not mind, but in several designs it is very clear, for instance between Student and Email, who obviously the owner is Student. Normally should be the class with many cardinality the owner. Let's go with the sample.

Java
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
@Entity
@Table(name="Libro")
public class Libro implements Serializable {

    @Id
    @GeneratedValue(strategy=GenerationType.IDENTITY)
    private Long idLibro;

    @Column
    private String titol;

    @Column
    private String tipus;

    @ManyToOne(cascade=CascadeType.PERSIST)
    @JoinColumn(name="idAutor",
                foreignKey = @ForeignKey(name = "FK_LIB_AUT" ))
    private Autor elAutor;

In this sample, a Book has an (unique) author. We implement it storing a reference to an Author object, called elAutor inside our Book. We have to write the relation information in this field:

  • We must mark this field as @ManyToOne, because Book is at the many's side of the relation (remember that an Author can write several Books)
  • The foreign key will be annotated with @JoinColumn label, with several attributes:
  • Since elAutor is the initial point of the foreign key, who point to the Author table, we need to say the name of the primary key in it class. This attribute is optional, but is a good option to improve our code.
  • Optional, we can name the constraint of the foreign key, with a well-structured name, with the foreignKey attribute
Java
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
@Entity
@Table(name="Libro")
public class Autor implements Serializable{

    static final long serialVersionUID = 137L;

    @Id
    @GeneratedValue(strategy=GenerationType.IDENTITY)
    private Long idAutor;

    @Column
    private String nom;

    @Column
    private String nacionalitat;

    @OneToMany(mappedBy="elAutor",
            cascade=CascadeType.PERSIST,
            fetch = FetchType.LAZY)
    private Set<Libro> elsLlibres;

    // rest of the class

Author class is on the one side, and it means that it can write many Books. For this reason we store all the books it has written in a Set of books. The annotations will be:

  • As one Author can write many books, we mark the Set of books as @OneToMany. As we have written the relation specification in Book, we could say that the relation is mapped in elAutor field inside Book class, with mappedBy="elAutor" easily.

Decissió

Instead of storing books in a Set, it can be stored in List. The main difference is to answer this question: is it important the order?. If you respond yes, you must use a List. It the response is no you must use a Set.

Espai

The 1:N that we have explained is bidirectional relation. It means that from an Author we can get all the Books he/she has written, and from a Book we can get the Author.

one_to_many_bidirectional

You could find several pages and books who explain unidirectional 1:N relations. It means that with this kind of implementation we only can travel in one direction. In this case we must store only inside a Book who is the author, because Book is the owner. We must remove the Set of books in author to get an unidirectional relation.

3.1. Fetch type

This attribute usually appears when we have in a 1:N or N:M relationship in a class that has a collection of related classes (can also be specified with a 1:1 but is less common). When Hibernate loads an object, it will load its general attributes (name, nationality, etc...), but what about the Books he has written, loads them or not?

  • DateType.EAGER \(\rightarrow\) Literally translated as anxious (ansioso). We can't wait, and when Author is loaded, Hibernate will resolve the relationship and load all the books with all the internal data for each book. We have all the data at the moment.
  • DateType.LAZY \(\rightarrow\) Literally as lazy (vago), but more representative as lazy loading. If we load the Author, Hibernate only loads the Author's own attributes, without loading its Books. When we try to access their books from our program, Hibernate is activated and loads them. That is, in LAZY mode, the data is loaded when is needed.

What we will do?*

Which is better or worse? The answer is not simple, since both have pros and cons:

  • In EAGER only one access is made, while in LAZY two accesses or more.
  • In the EAGER all data is loaded, even if they are not needed, in the LAZY only what is needed is loaded.

The programmer must assess and balance the amount of information required at a given time and the cost of access to the database.

4. Many to Many

In this section we will finish with the last type of relationships that we can find in the E/R model, which are many-to-many relationships. It can appear other relationships with higher cardinalities, such as ternary relationships, but as was studied in the first year, all of them can be modeled with binary transformations.

Within binary relationships, we can find two possibilities:

  • Relationships that simply indicate the relationship (for example, that a character may or may not carry a certain type of weapon in a role-playing game) or
  • Relationships that, apart from indicating it, add new attributes. For instance, an actor participates in a film in a type of role: main, secondary, etc.

In the relational model, both cases ended up being modeled as a new table (with or without the attribute). If we find ourselves in the second case, a new table with the attributes it possesses must be modeled with a class, so the N:M relationship between two tables there will be two one-to-many relationships 1:N and N:1 (actor-performance and performance-film) We will focus on the first case, since we are already prepared to solve the second one.

Improving

For the second part, this tutorial explains how to do it N_M with attributes. Is very recommmended to implement it a sample.

We are going to model the typical case of a Teacher who teaches several Modules, which can be taught by several teachers. The scheme looks like below:

![many to many](./img/N_M.png){width=90%}

As we can see, the typical central table of the N:M relationship remains. As previously mentioned, the Teaching table will not exist in the OO model, since it only serves to relate the elements.

The Module and Teacher classes are as follows (only the part related to the relationship is shown) choosing in this case Teacher as the owner of the relationship:

Java
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
// in Professor, a set of Modulo
@ManyToMany(cascade=CascadeType.PERSIST,
            fetch=FetchType.LAZY)
@JoinTable(name="Docencia",
          joinColumns = {@JoinColumn(
            name="idProfesor",
            foreignKey = @ForeignKey(name = "FK_DOC_PROF" ))},
          inverseJoinColumns = {@JoinColumn(
            name="idModulo",
            foreignKey = @ForeignKey(name = "FK_DOC_MOD" ))})
private Set<Modulo> losModulos=new HashSet<>();
Java
1
2
3
4
5
// in Modulo.. a set of Professor
@ManyToMany(cascade = CascadeType.PERSIST,
            fetch = FetchType.LAZY,
            mappedBy = "losModulos")
private Set<Profesor> losProfesores=new HashSet<>();;

This is the most complicated specification, let's go:

  • In both classes the mapping is @ManyToMany
  • In both cases we indicate how we handle the cascade operations (cascade) and the loading of the related objects of the other class (fetch)
  • In the owner class (Professor) a Set<Module> is mapped with the relationship will start from my current class Professor \(\rightarrow\) teaching \(\rightarrow\) Modulo (the base type of the Set)
  • With @JoinTable It is indicated that the relationship links to a table with Docencia name, where:
  • It will be linked (joincolumns), and the join is with @JoinColumn:
    • Starting from the idProfesor field inside the Docencia table
    • Finishing on the Profesor primary key,
    • The FK is named foreignKey = @ForeignKey(name = "FK_DOC_PROF" ).
  • Pay attention that name inside @JoinTable are names in the table Docencia (existing only on the database).
  • It is mapped from the Docencia table to the Modulo source entity inversely (from the point to the origin of the arrow):
  • This is achieved with inverseJoinColumns:
    • linking from the idModule field (@JoinColumn).
    • We also name the FK.
  • In the related class (Modulo), which is not the owner, we simply indicate that the owner is Profesor, by means of mappedBy="losModulos".

A sample code will be like this:

Java
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
Profesor p1 = new Profesor("Mario Benedé");
Profesor p2 = new Profesor("Jose Fernandez");

Modulo m1 = new Modulo("Acceso a Datos");
Modulo m2 = new Modulo("Bases de Datos");
Modulo m3 = new Modulo("Programación");
Modulo m4 = new Modulo("Diseño de Interfaces");

// añadimos modulos a p1
p1.addModulo(m3);
p1.addModulo(m1);

// añadimos modulos a p2
p2.addModulo(m2);
p2.addModulo(m3);
p2.addModulo(m4);

// guardamos
laSesion.persist(p1);
laSesion.persist(p2);

and the hibernate output will be something like:

Bash
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
Hibernate: drop table if exists Modulo
Hibernate: drop table if exists Profesor
Hibernate: create table Docencia (
    idProfesor bigint not null, 
    idModulo bigint not null, 
    primary key (idProfesor, idModulo)) engine=InnoDB
Hibernate: create table Modulo (
    idModulo bigint not null auto_increment, 
    nombre varchar(255), 
    primary key (idModulo)) engine=InnoDB
Hibernate: create table Profesor (
    idProfe bigint not null auto_increment, 
    nomProfe varchar(255), 
    primary key (idProfe)) engine=InnoDB
Hibernate: alter table Docencia add constraint FK_DOC_MOD 
    foreign key (idModulo) references Modulo (idModulo)
Hibernate: alter table Docencia add constraint FK_DOC_PROF 
    foreign key (idProfesor) references Profesor (idProfe)
Hibernate: insert into Profesor (nomProfe) values (?)
Hibernate: insert into Modulo (nombre) values (?)
Hibernate: insert into Modulo (nombre) values (?)
Hibernate: insert into Profesor (nomProfe) values (?)
Hibernate: insert into Modulo (nombre) values (?)
Hibernate: insert into Modulo (nombre) values (?)
Hibernate: insert into Docencia (idProfesor, idModulo) values (?, ?)
Hibernate: insert into Docencia (idProfesor, idModulo) values (?, ?)
Hibernate: insert into Docencia (idProfesor, idModulo) values (?, ?)
Hibernate: insert into Docencia (idProfesor, idModulo) values (?, ?)
Hibernate: insert into Docencia (idProfesor, idModulo) values (?, ?)

After all the tables were created, Hibernate creates the foreign keys, and then insert the recors. Firstly, Profesor and Modulo, and finally the relation in Docencia table.