Jointure

Une jointure est une opération permettant de relier des données présentent dans différentes tables ou vues. Incontournables dans les bases de données relationnelles, les jointures permettent d’extraire des données qui se trouvent dans différents endroits.

Une bonne modélisation impose d’éclater les données et de les répartir dans différents objets afin d’éviter les redondances et d’améliorer les performances. Mais lorsqu’il faut récupérer les données pour les traiter, il faut aller les chercher à différents endroits. C’est à ce moment que les jointures ou appariement sont nécessaires.

Concrètement, il existe des instructions basées sur l’algèbre relationnel qui permettent d’associer des valeurs entre tables ou vues. L’idée c’est d’associer clé primaire et clé étrangère et de se baser sur cet élément commun pour aller chercher des données. Il est possible de réaliser plusieurs jointures dans la même requête.

Réalisées en SQL, les types de jointures sont variés. Elles ne sont pas compliquées mais il est facile de faire des erreurs. D’autant plus que d’un SGBD à l’autre, les instructions ne sont pas implémentées de la même façon et ne renvoient pas les mêmes types de résultats.

Produit cartésien

Il est possible d’associer 2 ensembles de données qui n’ont rien à voir. On obtient alors le produit cartésien des 2 ou multiplication. Si chaque table à 1000 lignes, le produit cartésien générera 1 million de lignes (la combinaison des 1000 lignes du premier ensemble avec pour chaque ligne les 1000 lignes du second ensemble).

Laissons de côté le produit cartésien. C’est, dans l’immense majorité des cas, une erreur de jointure plutôt qu’une opération délibérée.

Jointures historiques

Historiquement, les jointures étaient réalisées avec des restrictions dans la clause WHERE en empilant les égalités entre clés primaires et clés étrangères de différentes tables :

SELECT presta_nom, part_nom, part_prenom, fact_devise, fact_montant-fact_payee FROM sejour, concerne, factureprestataire, prestataire, participant
WHERE sejour.participant_part_numauto=participant.part_numauto
AND factureprestataire.presta_numauto=prestataire.presta_numauto
AND factureprestataire.fact_numauto=concerne.fact_numauto
AND concerne.sej_numauto=sejour.sej_numauto
AND fact_actif=1
AND sej_datefacture>="2019-10-01"
AND fact_montant-fact_payee>0;

Cette requête affiche le montant déjà réglé par prestataire pour des inscription à des séjours réalisés depuis le 1er octobre 2019. Les données se trouvent réparties dans plusieurs tables (sejour, concerne, factureprestataire, prestataire et participant) et il est nécessaires de les lier entre elles pour remonter les données

Ce type de jointure permet uniquement d’obtenir l’intersection entre les tables jointes. Et c’est limitant. De plus, ces requêtes sont moins lisibles : les jointures sont mélangées avec les filtres.

Jointures modernes en SQL

Les jointures historiques fonctionnent mais ne permettent pas de faire de jointures externes. C’est pourquoi, on utilise désormais la syntaxe avec JOIN qui est beaucoup plus souple et puissant. Ça ressemble à ça :

SELECT ca_date, caisse.ca_numauto, ca_type, ca_volume, ca_tare, mouv_numauto
FROM caisse
INNER JOIN entreprise
ON caisse.client_numauto = entreprise.ent_numauto
LEFT JOIN mouvement
ON mouvement.ca_numauto=caisse.ca_numauto
LEFT JOIN produit
ON mouvement.prod_numauto=produit.prod_numauto
WHERE entreprise.ent_numauto=1234
ORDER BY ca_numauto ASC

On peut par exemple obtenir les résultats suivants :

• INNER JOIN : simple intersection (équivalent de la méthode historique) ;
• LEFT JOIN et RIGHT JOIN : toutes les valeurs d’une table + les valeurs communes avec l’autre table. Gauche et droite définissent quelle table est la table de base dans laquelle toutes les valeurs seront récupérées) ;
• LEFT JOIN et RIGHT JOIN sans intersection : toutes les valeurs d’une table – les valeurs communes avec l’autre table ;
• FULL JOIN : toutes les valeurs des 2 tables ;
• FULL JOIN sans intersection : toutes les valeurs des 2 tables – les valeurs communes.