Préambule

Les TD 1 & 2 se basent sur une seule table en BdD et le TP 1 utilise des jointure faites "à la main" entre 2 tables. Dans les faits, un modèle relationnel correct utilise le principe de clef étrangère pour établir des relations entre des tables. Le problème est de traduire cette relation en une relation entre objets puisque dans les projets spring boot, on manipule des instances plutôt que de traiter directement des enregistrements en BdD. Pour cela, hibernate propose un ensemble d'annotations que l'on utilise dans les entités, la difficulté étant de bien choisir quelle annotation utiliser pour représenter quelle relation.

Le projet de démonstration des points abordés est téléchargeable [ici]

1°/ Les mappings relationnels avec hibernate

1.1°/ Kesako

La notion de mapping relationnel vient du fait que l'on cherche à traduire (donc "mapper") une relation dans un modèle de BdD relationnel en une relation entre des classes, à savoir des relation du type :

• 1, 1 : un élément d'une table est en relation avec un seul autre élément d'une table (par ex, table user en relation avec table user_profile = un utilisateur n'a qu'un seul profil associé).
• 1, \: un élément d'une table est en relation avec plusieurs autres éléments d'une table (par ex, table user en relation avec table user_bank_account = un utilisateur peut avoir plusieurs comptes bancaires)
• \, \ : plusieurs éléments d'une table se trouvent en relation avec plusieurs éléments d'une autre table (par ex, table user en relation avec table rooms = un utilisateur utilise plusieurs salles & une salle est utilisée par plusieurs utilisateurs)

Or, l'expressivité des classes est plus grande que celle d'un modèle relationnel, il est possible de décrire ces 3 types par plus que 3 solutions. Prenons un exemple pour le montrer. Soit une table user et une table user_bank_account avec une relation de type 1,\*. Cela implique que la table user_bank_account contient un clef étrangère correspondant à la clef primaire de user.

Si on doit modéliser cette relation en objet, on a globalement 3 choix :

1. la classe User ne contient rien permettant de le raccrocher à un compte bancaire et la classe UserBankAccount contient un attribut de type User
2. la classe UserBankAccount ne contient rien permettant de le raccrocher à un utilisateur et la classe User contient un attribut de type List<UserBankAccount>
3. la classe User contient un attribut de type List<UserBankAccount> et la classe UserBankAccount contient un attribut de type User

La solution 1 est celle qui se rapproche le plus du modèle relationnel, alors qu'il est strictement impossible de représenter les 2 et 3 en SQL. Pourtant, la dernière solution serait sans doute la plus pratique pour créer une application bancaire. En effet, quand on édite un utilisateur, on accède directement à ses comptes, et quand on édite un compte, on retrouve directement son propriétaire.

Cela dit, la solution 3 n'est pas "forcément" souhaitable. Par exemple, dans un bibliothèque, on cherche généralement des livres, plutôt que des auteurs. On aurait donc plutôt besoin d'une solution 1, avec la classe Book qui contient un attribut de type Author. Sur un blog, un article peut recevoir des commentaires, mais on ne cherche jamais un commentaire en particulier. On aruait donc une solution 2, avec la classe Article qui contient un attribut de type List<Comment>.

De fait, il serait intéressant de pouvoir utiliser l'une de ces 3 solutions au choix selon l'application, alors qu'au niveau BdD, les tables seraient exactement les mêmes.

1.2°/ Les bases