Връзка „много към много“ в JPA

1. Въведение

В този урок ще видим множество начини за справяне с връзки много към много, използвайки JPA .

За да представим идеите, ще използваме модел на студенти, курсове и различни взаимоотношения между тях.

За по-голяма простота в примерите за кодове ще покажем само атрибутите и конфигурацията на JPA, свързани с връзките много към много.

2. Основни много към много

2.1. Моделиране на връзката много към много

Връзката е връзка между два вида обекти. В случай на връзка много към много, и двете страни могат да се свържат с множество случаи на другата страна.

Имайте предвид, че е възможно типовете обекти да са във връзка със себе си. Например, когато моделираме семейни дървета: всеки възел е човек, така че ако говорим за връзката родител-дете, и двамата участници ще бъдат човек.

Това обаче не прави такава разлика дали говорим за връзка между единични или множество типове обекти. Тъй като е по-лесно да мислим за връзките между два различни типа обекти, ще използваме това, за да илюстрираме нашите случаи.

Например, когато студентите маркират курсовете, които харесват: студентът може да хареса много курсове и много студенти могат да харесат един и същ курс:

Както знаем, в RDBMSes можем да създаваме връзки с чужди ключове. Тъй като и двете страни трябва да могат да се позовават на другата, трябва да създадем отделна таблица, която да държи външните ключове :

Такава таблица се нарича таблица за присъединяване . Имайте предвид, че в таблица за присъединяване комбинацията от външни ключове ще бъде нейният композитен първичен ключ.

2.2. Прилагане в JPA

Моделирането на взаимоотношения много към много с POJO е лесно. В двата класа трябва да включим Колекция , която съдържа елементите на останалите.

След това трябва да маркираме класа с @Entity , а първичния ключ с @Id, за да ги направим правилни JPA обекти.

Също така трябва да конфигурираме типа на връзката. Следователно ние маркираме колекциите с @ManyToMany анотации:

@Entity class Student { @Id Long id; @ManyToMany Set likedCourses; // additional properties // standard constructors, getters, and setters } @Entity class Course { @Id Long id; @ManyToMany Set likes; // additional properties // standard constructors, getters, and setters }

Освен това трябва да конфигурираме как да моделираме връзката в RDBMS.

Страната на собственика е мястото, където конфигурираме връзката, която за този пример ще изберем класът Student .

Можем да направим това с анотацията @JoinTable в класа Student . Предоставяме името на таблицата за присъединяване ( подобно на курса ) и външните ключове с анотациите @JoinColumn . В joinColumn атрибут ще се свърже към страната собственик на връзката, а inverseJoinColumn от другата страна:

@ManyToMany @JoinTable( name = "course_like", joinColumns = @JoinColumn(name = "student_id"), inverseJoinColumns = @JoinColumn(name = "course_id")) Set likedCourses;

Имайте предвид, че използването на @JoinTable или дори @JoinColumn не е необходимо: JPA ще генерира имената на таблиците и колоните за нас. Въпреки това стратегията, която JPA използва, не винаги съответства на конвенциите за именуване, които използваме. Оттук и възможността за конфигуриране на имена на таблици и колони.

От целевата страна трябва само да предоставим името на полето, което картографира връзката . Следователно задаваме атрибута mappedBy на анотацията @ManyToMany в класа Course :

@ManyToMany(mappedBy = "likedCourses") Set likes;

Имайте предвид, че тъй като връзката много към много няма страна на собственика в базата данни , можем да конфигурираме таблицата за присъединяване в класа Course и да я препратим от класа Student .

3. Много към много с помощта на композитен ключ

3.1. Моделиране на атрибути на връзката

Да кажем, че искаме да позволим на учениците да оценяват курсовете. Студентът може да оцени произволен брой курсове и произволен брой студенти могат да оценят същия курс. Следователно това е и връзка много към много. Това, което го прави малко по-сложно е, че връзката с рейтинга има нещо повече от факта, че тя съществува. Трябва да съхраним оценката, която студентът е дал в курса.

Къде можем да съхраняваме тази информация? Не можем да го поставим в студентския обект, тъй като студентът може да дава различни оценки на различни курсове. По същия начин съхраняването му в обекта на курса също не би било добро решение.

Това е ситуация, когато самата връзка има атрибут .

Използвайки този пример, прикачването на атрибут към връзка изглежда по следния начин в диаграма ER:

Можем да го моделираме почти по същия начин, както направихме с простата връзка много към много. Единствената разлика е, че прикачваме нов атрибут към таблицата за присъединяване:

3.2. Създаване на композитен ключ в JPA

Внедряването на обикновена връзка много към много беше доста просто. Единственият проблем е, че не можем да добавим свойство към връзка по този начин, тъй като свързваме обектите директно. Следователно нямахме начин да добавим свойство към самата връзка .

Тъй като съпоставяме DB атрибутите с полета на класа в JPA, трябва да създадем нов клас обект за връзката.

Of course, every JPA entity needs a primary key. Because our primary key is a composite key, we have to create a new class, which will hold the different parts of the key:

@Embeddable class CourseRatingKey implements Serializable { @Column(name = "student_id") Long studentId; @Column(name = "course_id") Long courseId; // standard constructors, getters, and setters // hashcode and equals implementation }

Note, that there're some key requirements, which a composite key class has to fulfill:

  • We have to mark it with @Embeddable
  • It has to implement java.io.Serializable
  • We need to provide an implementation of the hashcode() and equals() methods
  • None of the fields can be an entity themselves

3.3. Using a Composite Key in JPA

Using this composite key class, we can create the entity class, which models the join table:

@Entity class CourseRating { @EmbeddedId CourseRatingKey id; @ManyToOne @MapsId("studentId") @JoinColumn(name = "student_id") Student student; @ManyToOne @MapsId("courseId") @JoinColumn(name = "course_id") Course course; int rating; // standard constructors, getters, and setters }

This code is very similar to a regular entity implementation. However, we have some key differences:

  • we used @EmbeddedId, to mark the primary key, which is an instance of the CourseRatingKey class
  • we marked the student and course fields with @MapsId

@MapsId means that we tie those fields to a part of the key, and they're the foreign keys of a many-to-one relationship. We need it, because as we mentioned above, in the composite key we can't have entities.

After this, we can configure the inverse references in the Student and Course entities like before:

class Student { // ... @OneToMany(mappedBy = "student") Set ratings; // ... } class Course { // ... @OneToMany(mappedBy = "course") Set ratings; // ... }

Note, that there's an alternative way to use composite keys: the @IdClass annotation.

3.4. Further Characteristics

We configured the relationships to the Student and Course classes as @ManyToOne. We could do this because with the new entity we structurally decomposed the many-to-many relationship to two many-to-one relationships.

Why were we able to do this? If we inspect the tables closely in the previous case, we can see, that it contained two many-to-one relationships. In other words, there isn't any many-to-many relationship in an RDBMS. We call the structures we create with join tables many-to-many relationships because that's what we model.

Besides, it's more clear if we talk about many-to-many relationships, because that's our intention. Meanwhile, a join table is just an implementation detail; we don't really care about it.

Moreover, this solution has an additional feature we didn't mention yet. The simple many-to-many solution creates a relationship between two entities. Therefore, we cannot expand the relationship to more entities. However, in this solution we don't have this limit: we can model relationships between any number of entity types.

For example, when multiple teachers can teach a course, students can rate how a specific teacher teaches a specific course. That way, a rating would be a relationship between three entities: a student, a course, and a teacher.

4. Many-to-Many With a New Entity

4.1. Modeling Relationship Attributes

Let's say we want to let students register to courses. Also, we need to store the point when a student registered for a specific course. On top of that, we also want to store what grade she received in the course.

In an ideal world, we could solve this with the previous solution, when we had an entity with a composite key. However, our world is far from ideal and students don't always accomplish a course on the first try.

In this case, there're multiple connections between the same student-course pairs, or multiple rows, with the same student_id-course_id pairs. We can't model it using any of the previous solutions because all primary keys must be unique. Therefore, we need to use a separate primary key.

Therefore, we can introduce an entity, which will hold the attributes of the registration:

In this case, the Registration entity represents the relationship between the other two entities.

Since it's an entity, it'll have its own primary key.

Note, that in the previous solution we had a composite primary key, which we created from the two foreign keys. Now, the two foreign keys won't be the part of the primary key:

4.2. Implementation in JPA

Since the coure_registration became a regular table, we can create a plain old JPA entity modeling it:

@Entity class CourseRegistration { @Id Long id; @ManyToOne @JoinColumn(name = "student_id") Student student; @ManyToOne @JoinColumn(name = "course_id") Course course; LocalDateTime registeredAt; int grade; // additional properties // standard constructors, getters, and setters }

Also, we need to configure the relationships in the Student and Course classes:

class Student { // ... @OneToMany(mappedBy = "student") Set registrations; // ... } class Course { // ... @OneToMany(mappedBy = "courses") Set registrations; // ... }

Again, we configured the relationship before. Hence, we only need to tell JPA, where can it find that configuration.

Note, that we could use this solution to address the previous problem: students rating courses. However, it feels weird to create a dedicated primary key unless we have to. Moreover, from an RDBMS perspective, it doesn't make much sense, since combining the two foreign keys made a perfect composite key. Besides, that composite key had a clear meaning: which entities we connect in the relationship.

Otherwise, the choice between these two implementations is often simply personal preference.

5. Conclusion

In this tutorial, we saw what a many-to-many relationship is and how can we model it in an RDBMS using JPA.

Видяхме три начина да го моделираме в JPA. И трите имат различни предимства и недостатъци, когато става въпрос за:

  • яснота на кода
  • Яснота на DB
  • способност за присвояване на атрибути на връзката
  • колко субекти можем да свържем с връзката и
  • поддръжка за множество връзки между едни и същи обекти

Както обикновено, примерите са достъпни в GitHub.