# INNER JOIN : définition et application

Grâce aux **[SQL JOIN](https://www.ionos.fr/digitalguide/hebergement/aspects-techniques/sql-join/ "SQL JOIN")**, vous pouvez utiliser [**les modèles de bases de données relationnelles**](https://www.ionos.fr/digitalguide/hebergement/aspects-techniques/base-de-donnees-relationnelle/ "Base de données relationnelle") pour faire des requêtes sur plusieurs tables de base de données. À l’exception du CROSS JOIN, tous les types de JOIN consistent en une association de produit cartésien et de sélection.

Le [système de gestion de base de données (SGBD)](https://www.ionos.fr/digitalguide/hebergement/aspects-techniques/systeme-de-gestion-de-base-de-donnees-sgbd/ "Système de gestion de base de données (SGBD)") est **le produit croisé** de deux tables de base de données. Il filtre ensuite le résultat selon **une condition de sélection** définie par l’utilisateur à l’aide d’une instruction SQL. INNER JOIN se distingue de tous les autres types de JOIN par **un ensemble de résultats minimal**. Le résultat d’un INNER JOIN ne consiste qu’aux données du produit croisé qui remplissent la condition de sélection. La sortie est une table de résultats (*View*) sans valeurs nulles.

## INNER JOIN dans la pratique

Nous illustrerons INNER JOIN par un exemple en partant de deux tables. La table « salariés » contient les employés d’une entreprise, avec un ID (e\_id) et leur département respectif (d\_id).

**Table : salariés**

<table>
  <thead>
    <tr>
      <th>e\_id</th>
      <th>nom</th>
      <th>prenom</th>
      <th>d\_id</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>1</td>
      <td>Dupond</td>
      <td>Jacques</td>
      <td>3</td>
    </tr>
    <tr>
      <td>2</td>
      <td>Martin</td>
      <td>Jean</td>
      <td>1</td>
    </tr>
    <tr>
      <td>3</td>
      <td>Petit</td>
      <td>Hélène</td>
      <td>1</td>
    </tr>
    <tr>
      <td>4</td>
      <td>Lefevre</td>
      <td>Lisa</td>
      <td>2</td>
    </tr>
    <tr>
      <td>5</td>
      <td>Leroy</td>
      <td>Sophie</td>
      <td>NULL</td>
    </tr>
  </tbody>
</table>

La table présente deux particularités : les collaborateurs Martin et Petit travaillent dans le même département. La salariée Leroy n’a pas encore été affectée à un service.

La table « département » répertorie tous les départements de l’entreprise, avec un identifiant et une localisation.

**Table : département**

<table>
  <thead>
    <tr>
      <th>d\_id</th>
      <th>designation</th>
      <th>emplacement</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>1</td>
      <td>Distribution</td>
      <td>Strasbourg</td>
    </tr>
    <tr>
      <td>2</td>
      <td>IT</td>
      <td>Poitiers</td>
    </tr>
    <tr>
      <td>3</td>
      <td>HR</td>
      <td>Toulouse</td>
    </tr>
    <tr>
      <td>4</td>
      <td>Recherche</td>
      <td>Poitiers</td>
    </tr>
  </tbody>
</table>

Les deux tables sont liées par **une relation de clé étrangère**. L’ID du département, qui sert de clé primaire dans la table « département », a été intégré comme clé étrangère dans la table « salariés ».

Ce lien nous permet d’avoir un INNER JOIN entre les deux tables. Ceci est nécessaire, par exemple, pour déterminer quel employé travaille à quel endroit.

En consultant des bases de données relationnelles, **une correspondance entre clés primaires et clés étrangères est généralement définie comme condition de sélection**. La condition est considérée comme remplie si la clé étrangère sélectionnée pour une table correspond à la clé primaire de l’autre table (=). Cela signifie que seules les entrées de données qui contiennent des valeurs communes sont éditées.

Un tel INNER JOIN est noté en **algèbre relationnelle** comme suit.

salaries⋈d\_id=d\_iddepartement

Cependant, les systèmes de bases de données relationnelles n’acceptent pas les commandes dans la syntaxe de l’algèbre relationnelle, mais sous la forme d’**instructions SQL**.

```none
SELECT * FROM salaries INNER JOIN departement ON salaries.d_id = departement.d_id;
```

La **commande SELECT** demande au SGBD de récupérer les données de la base de données. Sinon, SQL donne la possibilité d’entrer des données (INSERT INTO), de les modifier (UPDATE) ou de les supprimer (DELETE FROM). La commande SELECT est suivie de la spécification des données à récupérer. Puisque nous souhaitons utiliser l’ensemble complet des données, nous utilisons l’astérisque (\*).

La commande SELECT nécessite toujours le mot-clé **FROM** et la spécification de la table ou du groupe de tables (JOIN) dont les données doivent être extraites. Dans notre cas, notre source de données est un INNER JOIN via les tables « département » et « salariés ». Nous utilisons également le mot-clé **ON** pour spécifier une condition pour le lien. Nous voulons seulement lier les enregistrements de données et les sortir sous la forme d’une table de résultats dans laquelle *d\_id* de la table « salariés » correspond à *d\_id* de la table « département ».

Conseil Comme INNER JOIN est le plus important SQL JOIN, vous pouvez omettre le mot-clé “INNER” si nécessaire.

Le INNER JOIN avec la condition *salaries.d\_id = departement.d\_id* renvoie la table de résultats suivante :

**Table : SQL INNER JOIN pour « salariés » et « département »**

<table>
  <thead>
    <tr>
      <th>e\_id</th>
      <th>nom</th>
      <th>prenom</th>
      <th>salaries.d\_id</th>
      <th>departement.d\_id</th>
      <th>designation</th>
      <th>emplacement</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>1</td>
      <td>Dupond</td>
      <td>Jacques</td>
      <td>3</td>
      <td>3</td>
      <td>RH</td>
      <td>Toulouse</td>
    </tr>
    <tr>
      <td>2</td>
      <td>Martin</td>
      <td>Jean</td>
      <td>1</td>
      <td>1</td>
      <td>Distribution</td>
      <td>Strasbourg</td>
    </tr>
    <tr>
      <td>3</td>
      <td>Petit</td>
      <td>Hélène</td>
      <td>1</td>
      <td>1</td>
      <td>Distribution</td>
      <td>Strasbourg</td>
    </tr>
    <tr>
      <td>4</td>
      <td>Lefevre</td>
      <td>Lisa</td>
      <td>2</td>
      <td>2</td>
      <td>IT</td>
      <td>Poitiers</td>
    </tr>
  </tbody>
</table>

Si vous comparez la table des résultats avec les deux autres, vous remarquerez qu’il manque une entrée de chaque tableau. Il s’agit des entrées dont la valeur dans la colonne *d\_id* n’a pas d’équivalent dans l’autre table.

```none
(5, Leroy, Sophie, NULL)
```

et

```none
(4, Recherche, Poitiers)
```

La salariée S. Leroy n’a pas encore été affectée à un service. Par ailleurs, aucun salarié n’a encore été affecté au departement *Recherche*. Les deux entrées sont donc masquées avec le INNER JOIN, qui est lui utilisé pour comparer les salariés avec leurs services respectifs.

Si nous voulons identifier exactement ces irrégularités et les rendre visibles pour la requête, il faudra avoir recours à un **OUTER JOIN** et non un INNER JOIN.

[![Image: Schéma représentatif d’un INNER JOIN avec les ensembles A et B.](https://www.ionos.fr/digitalguide/fileadmin/_processed_/1/c/csm_inner-join_3029ec5a43.webp "Schéma représentatif d’un INNER JOIN avec les ensembles A et B.")](https://www.ionos.fr/digitalguide/fileadmin/DigitalGuide/Screenshots_2019/inner-join.png) Schéma représentatif d’un INNER JOIN avec les ensembles A et B. ## Sous-type pour INNER JOIN

Les jointures INNER JOIN peuvent être réalisés comme THETA JOIN, EQUI JOIN, NON EQUI JOIN et NATURAL JOIN.

### THETA JOIN, EQUI JOIN et NON EQUI JOIN

INNER JOIN dans la terminologie SQL correspond au **THETA JOIN** de l’algèbre relationnelle. Le THETA JOIN diffère des EQUI JOIN et des NON EQUI JOIN en ce qu’il offre aux utilisateurs un choix illimité d’opérateurs de comparaison. Les **EQUI JOIN**, d’autre part, limitent la condition de sélection pour les requêtes à l’égalité des valeurs des colonnes. Avec les **NON EQUI JOIN** en revanche, tous les opérateurs de comparaison sont autorisés, à l’exception du signe égal.

<table>
  <thead>
    <tr>
      <th>Type JOIN</th>
      <th>Opérateurs de comparaison autorisés</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>THETA JOIN</td>
      <td>= (égal) &lt; (inférieur à) &gt; (supérieur à)≤ (inférieur ou égal à)≥ (supérieur ou égal à)&lt;&gt; (différent)!= (différent)</td>
    </tr>
    <tr>
      <td>EQUI JOIN</td>
      <td>= (égal)</td>
    </tr>
    <tr>
      <td>NON EQUI JOIN</td>
      <td>&lt; (inférieur à)) &gt; (supérieur à)≤ (inférieur ou égal à)≥ (supérieur ou égal à)&lt;&gt; (différent)!= (différent)</td>
    </tr>
  </tbody>
</table>

### NATURAL JOIN

Si deux tables (comme dans les exemples précédents) sont reliées par des colonnes du même nom, les jointures INNER JOIN sont généralement converties en **NATURAL JOIN**.

Le **NATURAL JOIN** est un sous-type des EQUI JOIN. Comme EQUI JOIN, NATURAL JOIN exige l’égalité de deux valeurs de colonne comme condition de sélection.

Un NATURAL JOIN utilisant les tables « salariés » et « département » pourrait, par exemple, être mis en œuvre comme suit :

```none
SELECT * FROM salaries INNER JOIN departement USING(d_id);
```

L’instruction SQL demande au SGBD de relier les tables nommées. La condition de sélection est mise en œuvre à l’aide du mot-clé USING, qui spécifie les colonnes à vérifier pour l’égalité. La condition préalable pour que cela fonctionne est qu’une colonne *d\_id* existe bien dans les deux tables. Les saisies des deux tables ne sont incluses dans l’ensemble de résultats que si le SGBD trouve des valeurs identiques dans les colonnes désignées *d\_id*.

La table de résultats du NATURAL JOIN diffère également de celle du classique INNER JOIN car les colonnes du même nom des tables de sortie ne sont pas listées deux fois, mais sont fusionnées pour former une colonne commune.

**Table : NATURAL JOIN pour « salariés » et « département »**

<table>
  <thead>
    <tr>
      <th>e\_id</th>
      <th>nom</th>
      <th>prenom</th>
      <th>d\_id</th>
      <th>designation</th>
      <th>emplacement</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>1</td>
      <td>Dupond</td>
      <td>Jacques</td>
      <td>3</td>
      <td>RH</td>
      <td>Toulouse</td>
    </tr>
    <tr>
      <td>2</td>
      <td>Martin</td>
      <td>Jean</td>
      <td>1</td>
      <td>Distribution</td>
      <td>Strasbourg</td>
    </tr>
    <tr>
      <td>3</td>
      <td>Petit</td>
      <td>Hélène</td>
      <td>1</td>
      <td>Distribution</td>
      <td>Strasbourg</td>
    </tr>
    <tr>
      <td>4</td>
      <td>Lefevre</td>
      <td>Lisa</td>
      <td>2</td>
      <td>IT</td>
      <td>Poitiers</td>
    </tr>
  </tbody>
</table>

Au lieu de lister les ID des départements des deux tables deux fois avec *salaries.d\_id* et *departement.d\_id*, une seule colonne *d\_id* est affichée.

Pour les NATURAL JOIN, il existe une notation courte qui ne nécessite pas de clause USING. A la place, l’opérateur NATURAL JOIN est utilisé. Voici l’instruction SQL correspondante :

```none
SELECT * FROM salaries NATURAL JOIN departement;
```

L’opérateur NATURAL JOIN relie automatiquement les tables en utilisant les colonnes du même nom. La condition de sélection ne doit pas être définie explicitement.

Note NATURAL JOIN est automatiquement converti en INNER JOIN. Toutefois, si vous souhaitez convertir un INNER JOIN en NATURAL JOIN, des mots-clés supplémentaires sont nécessaires (par exemple, NATURAL LEFT OUTER JOIN.


This is a markdown version of: [https://www.ionos.fr/digitalguide/hebergement/aspects-techniques/sql-inner-join/](https://www.ionos.fr/digitalguide/hebergement/aspects-techniques/sql-inner-join/) for AI/LLM consumption.