Les Jointures en SQL: à quoi ça sert? allons à sa découverte

A quoi sert les Jointures en SQL dans une BDD(Base de données relationnelle) ?

La programmation comme vous le savez, est uniqument fait pour manipuler les données, car ce sont les données qui constituent l'essence meme de la app (web, desktop, mobile) que nous sommes entrain de construire. Les données que nous manipulons peuvent provenir de divers sources et dans la meme mesure peuvent etre sauveguarder dans plusieurs support (fichiers sur disque dur qui peut etre un fichier json, xml, un fichier binaire etc..). La façon la plus simple de sauver les données de manière structurée est d'utiliser une base de donnée relationnelle qui en fait n'est rien d'autre qu'un fichier binaire mieux organisé sous forme de tableau/table donc chaque table ayant des lignes et des colonnes.

Pour eviter de repeter la theorie derrière les base de données relationnelle et ses formes normales, l'idée a toujours été de diviser pour mieux reigner, du coup face à un probleme informatique, après avoir bien etudié le domaine de l'application, on subdivise le probleme en entité qui permet de cabler en quelque sorte chaque entité comme un tableau et la base de données devient une mosaique de table ayant des relations entre elles, c'est cela qui fait naitre ce qu'on appelle:

Clée Primaire : qui represente un champ(colonne) de la table qui permet d'identifier de manière unique une ligne(row) de la table, donc deux record (ligne) de la table ne peuvent pas avoir la meme clée primaire, une clée primaire peut aussi etre composée de plusieurs colonnes.

Clée Etrangère : Pour mettre en relation une table avec une autre, on utilise ce qu'on appelle une clée étrangère dans l'une des table qui fait partir de la relation, l'idée de mettre deux ou plusieurs tables en relation est simplement d'éviter la redondance de l'information(des data ou données) c'est à a dire la repétition des données inutilement. Supposons qu'on ait à faire un e-commerce ou les produits doivent etre regroupés par categorie et suposons que les categories comprennent les champs suivant (IdCategorie,NomCategorie,DescriptionCategorie,DateCreation) et supposons que les produits contiennent (IdProduit, NomProduit, Description,PrixProduitod) comment fera le developpeur pour associer les produits à leur categorie?, un developpeur qui fait à sa tete et ne veut pas respecter les concepts des BDD peut aller droit au but, rien ne l'empeche de créer une table disons CategorieProduit(NomCategorie,DescriptionCategorie,NomProduit,DescriptionProduit,PrixProduit) et la remplir par exemple comme suit:

NomCategorie	DescriptionCategorie	NomProduit	DescriptionProduit,	PrixProduit
Cat1	Categorie1	Prod1	Produit1	10
Cat1	Categorie1	Prod2	Produit2	15
Cat1	Categorie1	Prod3	Produit3	20
Cat1	Categorie1	Prod4	Produit4	30

Qu'est ce qui ne va pas dans ce tableaux? : la redondance, la repetition, les deux premières colonnes en rouge sont repetées ce qui à la longue peut faire en sorte qu'on ait des data pas coherents car le meme développeur peut etre, auparavent avait deja crée les tables Categorie et Produit comme on l'a fait si haut, la meilleur approche ce serait plutot de créer une relation entre les tables Categorie et Produit, un Produit peut faire partire d'une et une seule categorie et dans une categorie on peut retrouver plusieurs produit, on parle donc d'une relation 1-N entre Categorie et produit, en terme technique, cela signifit que dans la table produit, on doit avoir une reference sur chaque ligne sur le produit d'appartenance, on materialise ce concept en utilisant une colonne dans la table produit appellée clée étrangère, notre table produit devient donc (IdProduit, IdCategorie, NomProduit, Description,PrixProduitod), donc IdCategorie c'est une clée étrangère qui est en fait la clée primaire de la table Categorie, dans mon exemple ci dessus, IdCategorie c'est la clé primaire de la table categorie et IdProduit c'est la clée primaire de la table produit mais IdCategorie dans la table produit en rouge represente l'identifiant unique donc la clée primaire de la categorie dans la table Produit, cela nous permet de materialiser  dans la pratique la relation 1-N qui existe entre Category et Produit. Voici une image juste illustrative

Attention, on peut avoir aussi des exigences dans notre e-commerce ou un produit peut faire partire de plusieurs categories, du coup il ne s'agira plus d'une simple relation 1-N entre produit et categorie, mais d'une relation N-N, pour materialiser techniquement ce type de relation, on doit diviser la relation N-N en deux relations 1-N à travers une table intermediaire qu'on appelle dans le jargon "Cross Table", toujours comme image d'illustration, ici dans cette image pris sur internet, l'auteur a juste crée une table intermediaire (Product_Category) qui est lié d'un coté avec produit dans une relation 1-N et d'un autre coté avec categories dans une autre relation 1-N

Passer cette revue sur les relations entre les tables, comment donc acceder aux données cumulatives des tables dans notre app par exemple dans une page web en php/java/c#/python etc.. generalement on a un menu ou l'utilisateur doit choisir une categorie et on lui fait voir les produit de cette categorie, ou bien l'utilisateur fait une recherche d'un produit ou d'une categorie et on lui met en evidence tous les produits de cette meme catégorie, c'est la que surviennent les concepts de JOINTURE objet de ce post, JOIN en anglais, la jointure permet en sql, de mettre en relation deux ou plusieurs tables qui sont en relations dans une requete sql de manière à recuperer les données qui font partir de toutes ces tables car le model relationnel comme je l'ai demontré en grande ligne si haut, permet de diviser pour mieux reigner en éparpillant les données dans plusieurs entités qu'on materialise physiquement dans les tables en créant dans la mesure du possible des relations entre ces tables pour éviter la redondance des données, du coup en phase de requet pour recuperer ces données, on utilise la jointure qui va prendre les clée primaire, les associées aux clée étrangère qui ne sont en fait qu'une reference des clée primaire dans une table externe, pour recuperer les données dans toutes les tables à travers une seule requetes, par exemple recuperer à la fois les données d'une categories et tous les produits associés en faisant juste une seule requete, voila l'objectif des jointures.

Il existe:

Inner Join : Jointure qui ne tien compte que des donnèes qui existe entre les deux tables conviées dans la relation, donc si la clée primaire n'a pas de correspondance effective comme valeur de la clée etrangère, le record est exclut

 

pour ceux qui ont fait la theorie des ensembles en math le comprennent immediatement, dans le resulta  ne sera pris en consideration que les données des deux tables ou la clée primaire à une correspondance à une clée étangère dans la table correspindante, dans l'image il s'agit d'une table Commande(order) et Clients(Customer), un client peut faire une ou plusiueurs commandes du coup on a customerId dans la table Order qui en fait est une clée etrangère qui represente la clée primaire (Id) de la table Customer la requete sql

SELECT OrderNumber, TotalAmount, FirstName, LastName, City, Country
  FROM [Order] O
  JOIN Customer C ON C.Id = O.CustomerId

dans une requete sql, la lettre O à coté de Order represente une alias donc un raccourcit pour identier la table dans la requete de meme que la lettre C qui represente un alias pour la table Customer du cout notre jointure est specifiée en Jaune, ou on indique clairement que la clée primaire Id de la table Costomer (C) doit contenir la meme valeur pour chauque ligne de la table Order(aliasé par O) sur la clée étrangère CustomerId.

Jointure de type left Join : ce type de jointure permet de retourner tous les données de la table de gauche de la relation meme s'il n'y a pas sa correspondance dans la table de droite de la relation. dans l'image suivante, la table de gauche c'est Order

 

 

Jointure de type right Join : c'est le contraire de left join, on cherche à retourner les données de la table de droite meme s'il n'y a pas de correspondance dans la table de gauche.

Voila le minium a connaitre et comprendre sur les tables, les relations entre elle et les jointures, il y a des SGBD qui accepte aussi des jointure de type cross qui en fait est le produit cartesien de deux tables.

Happy coding

---

---

Share

Comments (1)

Leave A Comment

Your Name:
Comment: