Préambule : Le choix du nom des tables a été fait en anglais, ce choix est purement une règle personnelle de toujours utiliser des noms anglais dans mon code. Désolé pour les irréductibles Gaulois, mais l’astuce est quand même intéressante et à autant de valeur avec des noms français. Je ferais l’effort de traduire quand je penserais que cela est nécessaire.
On a vu, dans le tip précédent (Tip #1 ORDA : Accéder à une sélection d’entité dans une relation N-N), une relation de type N-N entre la table « Movie » et la table « Actor ». La relation est construite via une table intermédiaire nommée « MovieActor ». Cette façon de nommer la table n’a pas été réfléchit et a été un choix purement technique. La réflexion derrière ce type de nommage était :
« J’ai besoin d’une table intermédiaire entre Movie et Actor donc je vais la nommer MovieActor comme ça on comprend que la table lie les 2 autres tables. »
Le choix de nommage des relations n’a pas reçu un meilleur traitement, quoiqu’il utilise une nomenclature correcte qui suit logiquement le choix du nom de la table.
Je vais faire un petit aparté sur le nommage des liens. Je tiens juste à préciser qu’en réalité on ne nomme pas des liens, on nomme une entity et une entitySelection. Cela peut paraitre un détail, mais si on ne comprend pas la différence c’est que l’on doit revenir sur des chapitres précédents pour bien comprendre et utiliser ORDA. Je vais donc dès à présent ne plus utiliser le terme « nom des liens », mais « nom des attributs relationnels ».
Je vais vous proposer ici un choix de nommage qui est un peu plus orienté métier.
Si on prend un peu de temps à réfléchir, on se rend compte que la table « MovieActor » représente le rôle d’un acteur dans un film. Le nom « Role » est donc plus adapté (rôle se dit aussi en anglais). J’ai aussi ajouté 3 champs à ma table : « firstName », « lastName » et « description », car la table ne doit pas servir seulement à lier 2 autres tables, mais peut aussi contenir des informations sur le rôle de l’acteur dans le film comme le nom et prénom du personnage incarné et une description du rôle.
Si nous regardons les attributs relationnels : Les attributs de type entity, n’ont pas changé, nous avons gardé « actor » et « movie ». Les attributs de type entitySelection ont quant à eux été renommés afin d’utiliser un terme plus descriptif de ce que l’entitySelection contient. L’attribut de type entitySelection partant de la table « Movie » s’appelle désormais « cast ». Je pensais d’abord l’appeler « casting », mais « casting » est un anglicisme qui en anglais désigne non pas la distribution de rôles dans un film, mais le fait d’auditionner un acteur pour un film. Le terme correct en anglais est « cast » 1. Quant à l’attribut partant de la table « Actor », je l’ai simplement appelé « roles », car nous souhaiterons avoir accès aux rôles de l’acteur (actor.roles).
Nous voyons que le nommage des éléments de la structure mérite un temps de réflexion et que parfois le premier choix n’est pas forcement le meilleur. Bien sûr l’impératif d’avancer dans le projet ne nous permet pas toujours d’attendre trop longtemps et nous aurions tendance à donner un nom « en attendant de trouver mieux ». La réalité est qu’une fois que l’on commence à coder, on ne revient presque jamais en arrière pour renommer une table ou un champ, sauf avec d’énormes pressions du chef de projet si cela devient important. Mais je pense qu’il est important de se donner le temps de bien nommer les tables et les attributs selon un code de nommage qui sera documenté et qui pourra être reprit par la suite par de nouveau arrivant dans le projet.