Continuons sur notre exemple, en ajoutant à notre table, la commune où sont nés nos marins.
L'approche naïve consisterait à ajouter une colonne à notre table, de type varchar, et à renseigner cette colonne avec ces nouvelles données. Cette approche pourrait certainement fonctionner, mais elle poserait d'emblée un problème. Dans notre exemple très simple, sur 9 marins, nous en avons déjà 2 qui sont nés au même endroit : Saint Malo. On peut supposer que si l'on avait des milliers de marins dans notre table, le nombre de doublons dans cette colonne serait assez important. Le traitement d'une requête du type "je veux extraire tous les marins nés à Saint Malo" fonctionnerait de façon triviale, en sélectionnant toutes les valeurs "Saint Malo" dans la colonne "lieu de naissance". Il vaut mieux que la saisie des valeurs de cette colonne se passe sans erreur, car si la valeur "Saint Malau" a été saisie à la place de "Saint Malo", le marin associé ne sera jamais sélectionné par une telle requête ! Pire que cela, détecter ce genre d'erreurs sur de très grands volumes de données peut devenir un réel problème : il se peut que notre marin soit perdu à jamais dans l'immensité océanique des bases de donneés mal rangées. De plus, enregistrer une commune dans une table Marins n'est pas une façon naturelle de traiter un tel problème. Après tout, une commune existe indépendamment du fait qu'un marin y est né. Une bonne façon de traiter ce problème, est de reconnaître l'indépendance de ces communes, et de leur offrir leur propre table. Afin de pouvoir référencer ces communes, on ajoute à cette table une colonne ID, qui portera un numéro, unique dans cette table, et qui nous servira de clé de référence. Créons donc la table Communes suivante.

Une fois cette table créée et renseignée, il nous faut ajouter une colonne à la table Marins.
Il ne nous reste plus qu'à renseigner la table Marins avec les valeurs suivantes.
Une fois nos tables mises à jour, on peut écrire une requête sur la table Marins et la table Communes, qui nous affiche le nom de chaque marin et sa commune de naissance.
Le résultat est bien sûr le suivant.

NOM                      PRENOM                      NOM
----------------------- --------------------------- ---------------
Auguin                   Christophe                  Granville
Bart                     Jean                        Dunkerque
Cartier                  Jacques                     St Malo
Dumont d'Urville         Jules                       Condé
Dupleix                  Joseph                      Landrecies
Moitessier               Bernard                     Saïgon
Montcalm                 Louis                       Nîmes
Surcouf                  Robert                      Saint Malo
Tabarly                  Eric                        Nantes

Détaillons ici les nouveautés de cette requête. Formellement, une jointure entre deux tables est un produit cartésien entre ces deux tables. Le produit cartésien entre un ensemble A et un ensemble B est l’ensemble de tous les couples formés d’un élément de A et d’un élément de B. Le nombre de lignes de la table jointe est donc le produit du nombre de lignes des tables initiales. La sélection des lignes dans la table jointe se fait ensuite de façon classique, comme s’il s’agissait d’une table normale. Bien sûr, cette table jointe est juste une façon de raisonner. En aucun cas le serveur ne la construit : si c’était le cas, il aurait à gérer des tables de taille énorme, même pour des petites requêtes. Notons l'ancienne syntaxe SQL pour écrire cette jointure. Il faut clairement lui préférer la nouvelle (d'ailleurs pas si nouvelle que cela...) syntaxe ci-dessus. Elle nous permettra de gérer les valeurs nulles de façon explicite, ce qui n'est pas le cas de cette ancienne syntaxe.

La façon dont nous avons traité le problème de l'association entre un marin et sa commune de naissance est tout à fait correcte, mais elle a besoin d'être sécurisée. Effectivement, deux problèmes peuvent se poser : À chacune de ces questions une réponse SQL apportera. Déclarer la colonne ID de la table Communes comme étant une clé primaire répond aux deux premières interrogations. Cette notion est centrale en SQL, et nous la reverrons en détails. Indiquons ici simplement qu'une colonne déclarée comme étant une clé primaire d'une table ne peut pas prendre de valeurs nulles, et ne peut pas porter de doublons. Notons toutefois, qu'il est possible en SQL d'empêcher la présence de doublons dans une colonne, de même que la présence de valeurs nulles, sans utiliser le mécanisme des clés primaires. Les deux dernières interrogations sont un peu plus subtiles : on souhaite établir une double contrainte entre une colonne d'une table, et une colonne d'une autre table. Effectivement, lors de l'insertion d'un nouveau marin, on souhaite que id_commune, s'il est non nul, référence obligatoirement une valeur de la colonne ID de la table Communes, et que réciproquement, il ne soit pas possible d'effacer une commune si elle est référencée par un marin. L'outil que nous fournit SQL pour ce faire et la clé étrangère . Une colonne peut être déclarée comme étant une clé étrangère. Dans ce cas, les valeurs qu'elle porte doivent correspondre à celles d'une autre colonne, en général d'une autre table. Si, lors de la création, la valeur insérée ne correspond à aucune valeur, alors l'insertion échoue. De l'autre côté de la relation, si l'on tente d'effacer la valeur référencée, une erreur est générée, qui peut être gérée applicativement ou non.