Comprendre les relations entre tables
Avant de combiner des tables avec JOIN, comprends pourquoi une base en a plusieurs et comment elles sont reliées — clé primaire, clé étrangère, relation.
Quand une colonne se répète
Jusqu'ici, tu travaillais sur une table à la fois. Mais une vraie base en contient plusieurs — et elles sont reliées entre elles. Avant de les combiner avec JOIN, il faut comprendre pourquoi elles sont séparées.
Supposons qu'on veuille ajouter le pays de production à la table films. L'approche la plus directe : une colonne pays_production qui stocke le nom en clair.
Table films — pays_production en clair (exemple fictif, pas dans le seed réel)
| titre | annee | pays_production |
|---|---|---|
| Inception | 2010 | USA |
| Le Parrain | 1972 | USA |
| Pulp Fiction | 1994 | USA |
| Amélie Poulain | 2001 | France |
Ça fonctionne, mais 'USA' apparaît trois fois. Sur une vraie base avec des milliers de films américains, cette valeur serait répétée des milliers de fois. Et si quelqu'un écrit 'Etats-Unis' au lieu de 'USA' pour un film, les données deviennent incohérentes sans que personne ne le détecte.
La solution propre est de séparer cette information dans une table dédiée — et c'est exactement ce que font les bases de données bien conçues. Cette colonne pays_production est un exemple ponctuel pour ce raisonnement : elle n'apparaîtra plus après cette leçon.
La clé primaire : un seul endroit
La solution : créer une table pays qui liste chaque pays une seule fois, et lui attribuer un identifiant numérique unique.
Table pays (fictive — illustre le concept)
| id | nom |
|---|---|
| 1 | USA |
| 2 | France |
Cette colonne id est la clé primaire de la table pays. Elle a deux propriétés : chaque valeur est unique (deux pays ne partagent jamais le même id), et elle n'est jamais vide. C'est la carte d'identité de chaque ligne.
Toute table bien conçue a une clé primaire. Tu ne la vois pas toujours dans les exercices — elle est là, en coulisses, à chaque fois.
La clé étrangère : le lien entre tables
Maintenant que pays existe, on peut alléger la table films. Au lieu de stocker 'USA' en clair, on stocke le numéro du pays correspondant — son id dans la table pays.
Table films — avec pays_id à la place de pays_production (exemple fictif, pas dans le seed réel)
| titre | annee | pays_id |
|---|---|---|
| Inception | 2010 | 1 |
| Le Parrain | 1972 | 1 |
| Pulp Fiction | 1994 | 1 |
| Amélie Poulain | 2001 | 2 |
Cette colonne pays_id est une clé étrangère : elle ne stocke pas la valeur elle-même, mais un pointeur vers la clé primaire d'une autre table. Le 1 dans films.pays_id signifie « cherche la ligne dont l'id est 1 dans la table pays » — et tu trouves 'USA'.
Le problème de répétition est résolu : 'USA' n'existe qu'en un seul endroit. Si un jour le nom change, on modifie une seule ligne dans pays — et tous les films qui pointent vers cet id reflètent automatiquement le changement.
Ce que ça change vraiment
On a maintenant deux tables liées : pays contient les noms, films contient les liens sous forme de numéros. Cette séparation s'appelle une relation, et c'est le cœur de toute base de données relationnelle.
Le bénéfice concret : pas de redondance, pas de risque d'incohérence. Il est impossible d'avoir 'USA' dans un film et 'Etats-Unis' dans un autre — la valeur de référence est unique et centralisée dans pays.
Mais regarder films.pays_id = 1 ne dit rien à un être humain. Pour afficher 'USA' à côté du titre du film, il faut combiner les deux tables — lire dans films et aller chercher la valeur correspondante dans pays en même temps. C'est précisément ce que fait JOIN, qu'on découvre dans la leçon suivante.
Récapitulatif
Ce que tu retiens de cette leçon :
💡 Bon à savoir : dans les exercices qui suivent, tu travailleras sur les tables employes et departements du bac à sable RH. Elles sont reliées exactement comme films et pays dans cet exemple — employes.dept_id pointe vers departements.id.
Passe à la pratique
Cette leçon t'a montré la théorie. Pour maîtriser SQL, rien ne vaut la pratique : accède aux exercices et au bac à sable PostgreSQL réel.