Troisième principe des bases de données, il faut lier les tables entre elles. L'ennemi ultime dans le contexte des bases de données, c'est le doublon. Il est essentiel, primordial, performatif de tout faire pour ne jamais avoir la même donnée en double. Cette prévention des doublons doit s'effectuer au sein même d'une table, mais également entre les tables.

Une même donnée peut être visible à différents endroits, mais une même donnée ne peut pas être stockée en différents endroits. Faites bien cette différence essentielle : visible ou stockée.

On peut voir l’information à plusieurs endroits, mais son lieu de stockage est unique. Il est essentiel de créer des liens entre les tables pour voir les données à différents endroits sans chaque fois les répéter réellement. Tentons d'expliquer ça comme dans un film.

Réalisateurs, acteurs, scénaristes, mais aussi techniciens, bruiteurs, monteurs, toutes ces PERSONNES participent à la création et à la réussite des FILMS que nous adorons regarder.

Quentin Tarantino est un dieu aux yeux de certains, mais stockons-le pour l'instant dans la table des PERSONNES. Il aura l'id 1 que nous placerons dans une colonne du type Auto-Increment qui réplique ce que les bases de données traditionnelles proposent.

Cette table contient les colonnes dont nous avons déjà parlé. L’id, que nous venons d’évoquer, mais aussi le nom, la date de naissance. Mais maintenant, notre table des PERSONNES va être mise en Relation avec celle des FILMS.

Christopher Nolan, PERSONNES id 2, va être mis en Relation avec Memento, FILMS id 1, Inception, FILMS id 2 ou The Dark Night, FILMS id 3. Facile, mais incomplet.

Tarantino, PERSONNES id 1 sera lié à Pulp Fiction, FILMS id 4, Kill Bill, FILMS id 5, ou encore Inglorious Basterds, FILMS id 6 puisqu'il les a réalisés.

Mais dans From Dusk Till Dawn, FILMS id 7, il est scénariste, acteur en compagnie de George Clooney, PERSONNES id 3, mais pas réalisateur.

C'est pour ça que je ne peux pas créer une table qui ne contiendrait que les réalisateurs, une autre table uniquement affectée aux acteurs et une troisième pour les scénaristes.

Je retrouverais Quentin à trois endroits, dans trois tables différentes, et ça n'est pas permis.

Pourquoi ? Et bien admettons que vous vous soyez trompés sur sa date de naissance et que vous la modifiez dans une table, il faudrait être certain d’également modifier les deux autres tables pour assurer la cohérence des données. Et ça, ce n'est pas gérable, ça pue l'erreur possible à plein nez. C’est le retour de notre premier principe, l’abstraction.

Nous avons donc une table des PERSONNES et une table des FILMS et les deux tables ont une Relation qui les lie. Quant au poste que chacun a rempli dans le processus créatif, on en revient au plan, à la structure nécessaire à votre application. On pourrait avoir, au sein de la table FILMS, différents champs liés à la table des PERSONNES : réalisateur, scénariste, acteurs, ces colonnes pourraient être chacune liées à la table des PERSONNES.

Mais, et essayez de me suivre car ça devient croustillant, on pourrait créer une troisième table avec les POSTES, une colonne du type Texte dont les valeurs seraient Réalisateur, POSTES id 1, Acteur, POSTES id 2, Scénariste, POSTES id 3 etc.

Il faudrait alors une quatrième table nommée CREDITS qui servirait uniquement à lier PERSONNES, FILMS et POSTES. Cette table ne contiendrait pas vraiment le nom des personnes, la dénomination du poste ni même le titre du film mais simplement une référence tirée de ces différentes tables. Une des lignes de cette table contiendrait donc 1 dans la colonne Personne, pour évoquer Quentin Tarantino, 3 pour évoquer son rôle d’acteur dans la colonne Poste et 7 pour évoquer From Dusk Till Dawn dans la colonne Film.

Cette structure permet de ne pas être limité dans les postes par film. Si de nouveaux postes devaient être créés, pour de nouvelles technologies ou de nouvelles aptitudes, pas de souci, c’est toujours possible.

<aside> 👉🏻 Principe numéro 3 des bases de données, Lier les tables entre elles permet d’encore mieux abstraire et structurer sa base de données et les informations qu’elle contient. Cela permet surtout d’éviter les doublons. Les Relations permettent de lier les tables entre elles et de visualiser les données d’une table dans une autre table, sans avoir besoin de les stocker à plusieurs endroits.

</aside>