L’héritage avec Jakarta Persistence

Contrôle de l’héritage avec Jakarta Persistence

Auteur

Affiliations

Emmanuel BRUNO

Université de Toulon

LIS UMR CNRS 7020

Source	https://github.com/ebpro/notebook-java-jpa
Branch	develop (c88a48e) 2024/03/08 11:41:10
Java	OpenJDK Temurin-21.0.5+11 Apache Maven 3.9.9
Docker	Client: 27.3.1 - buildx v0.18.0 - compose v2.30.3 Server: 27.3.1

JPA supporte plusieurs stratégies d’héritage, chacune adaptée à des besoins spécifiques en termes de structure de base de données.

En utilisant l’annotations @Inheritance il est possible de spécifier comment les entités héritées seront stockées dans la base de données, que ce soit dans une table unique regroupant toutes les entités, des tables distinctes pour chaque classe, ou une approche intermédiaire.

Figure 1: La hiérarchie des personnes

1 Une seule relation par hiérarchie

Par défault JPA défini une seule relation pour une hiérarchie d’héritage. Toutes les classes de la hiérarchie sont mappées vers une seule table dans la base de données. La table contient des colonnes pour toutes les propriétés de toutes les classes de la hiérarchie. Un discriminant (généralement une colonne spécifiant le type) est utilisé pour différencier les enregistrements appartenant à différentes classes.

Figure 2: La relation Personne

salary	status	id	dtype	name
		1	Person	P1
	0	2	Student	S1
3000		3	Teacher	T1

2 Une relation par classe (strategies JOINED ou TABLE_PER_CLASS)

Mais il est aussi possible de demander une relation par classe.

Avec @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS) chaque classe de la hiérarchie est mappée vers sa propre table dans la base de données. Les tables ne contiennent que les colonnes nécessaires pour stocker les propriétés spécifiques à chaque classe.

Avec @Inheritance(strategy = InheritanceType.JOINED) chaque classe de la hiérarchie est mappée vers une table distincte, et il y a également une table commune (table de la superclasse) contenant les propriétés partagées par toutes les sous-classes. Les tables des sous-classes contiennent uniquement les colonnes spécifiques à chaque classe, et une clé étrangère relie ces tables à la table commune.

@SuperBuilder
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Getter
@Setter
@ToString(callSuper = true)

@Entity(name="TeacherHeritage2")
@Table(name="TEACHER", schema = "EX_HERITAGE2")
public class Teacher extends Person {

    @Column(nullable = false)
    private double salary;
}

3 Conclusion

En résumé, la stratégie JOINED privilégie la normalisation des données en utilisant une table commune pour les propriétés partagées, tandis que la stratégie TABLE_PER_CLASS favorise l’indépendance des tables pour chaque classe.