Une jointure interne nécessite que chaque ligne des deux tables jointes ait des valeurs de colonne correspondantes, et est une opération de jointure couramment utilisée dans les applications mais ne doit pas être considérée comme le meilleur choix dans toutes les situations. La jointure interne crée une nouvelle table de résultats en combinant les valeurs de colonne de deux tables (A et B) en fonction du prédicat de jointure. La requête compare chaque ligne de A avec chaque ligne de B pour trouver toutes les paires de lignes qui satisfont le prédicat de jointure. Lorsque le prédicat de jointure est satisfait en faisant correspondre des valeurs non NULL, les valeurs de colonne pour chaque paire de lignes de A et B correspondantes sont combinées en une ligne de résultat.

Le résultat de la jointure peut être défini comme le résultat de la première prise du produit cartésien (ou jointure croisée) de toutes les lignes des tables (combinant chaque ligne de la table A avec chaque ligne de la table B), puis retour de toutes les lignes qui satisfont le prédicat de jointure. Les implémentations SQL réelles utilisent normalement d’autres approches, telles que les jointures par hachage ou les jointures par tri-fusion, car le calcul du produit cartésien est plus lent et nécessiterait souvent une quantité de mémoire prohibitive à stocker.

SQL spécifie deux syntaxiques différentes façons d’exprimer les jointures: la « notation de jointure explicite » et la « notation de jointure implicite ». La « notation de jointure implicite » n’est plus considérée comme une bonne pratique, bien que les systèmes de base de données la prennent toujours en charge.

La « notation de jointure explicite » utilise le mot-clé JOIN, éventuellement précédé du mot clé INNER, pour spécifier la table à joindre, et du mot clé ON pour spécifier les prédicats de la jointure, comme dans l’exemple suivant:

SELECT employee.LastName, employee.DepartmentID, department.DepartmentName FROM employee INNER JOIN department ONemployee.DepartmentID = department.DepartmentID;

La « notation de jointure implicite » répertorie simplement t Les tables de jonction, dans la clause FROM de l’instruction SELECT, en utilisant des virgules pour les séparer. Ainsi, il spécifie une jointure croisée, et la clause WHERE peut appliquer des prédicats de filtre supplémentaires (qui fonctionnent de manière comparable aux prédicats de jointure dans la notation explicite).

L’exemple suivant est équivalent au précédent, mais cette fois en utilisant la notation de jointure implicite:

SELECT employee.LastName, employee.DepartmentID, department.DepartmentName FROM employee, departmentWHERE employee.DepartmentID = department.DepartmentID;

Les requêtes données dans les exemples ci-dessus rejoindra les tables Employee et Department en utilisant la colonne DepartmentID des deux tables. Lorsque le DepartmentID de ces tables correspond (c’est-à-dire que le prédicat de jointure est satisfait), la requête combinera les colonnes LastName, DepartmentID et DepartmentName des deux tables en une ligne de résultat. Là où le DepartmentID ne correspond pas, aucune ligne de résultat n’est générée.

Ainsi, le résultat de l’exécution de la requête ci-dessus sera:

L’employé « Williams » et le service « Marketing » n’apparaissent pas dans les résultats de l’exécution de la requête. Aucun de ces éléments n’a de ligne correspondante dans l’autre table respective: « Williams » n’a pas de service associé et aucun employé n’a l’ID de service 35 (« Marketing »). Selon les résultats souhaités, ce comportement peut être un bogue subtil, qui peut être évité en remplaçant la jointure interne par une jointure externe.

Jointure interne et valeurs NULL Modifier

Les programmeurs devraient prendre attention particulière lors de la jonction de tables sur des colonnes pouvant contenir des valeurs NULL, car NULL ne correspondra jamais à aucune autre valeur (même pas NULL elle-même), à moins que la condition de jointure n’utilise explicitement un prédicat de combinaison qui vérifie d’abord que les colonnes de jointure sont NOT NULL avant d’appliquer la ou les conditions de prédicat restantes. La jointure interne ne peut être utilisée en toute sécurité que dans une base de données qui applique l’intégrité référentielle ou dans laquelle il est garanti que les colonnes de jointure ne sont pas NULL. De nombreuses bases de données relationnelles de traitement des transactions reposent sur les normes de mise à jour des données Atomicité, Cohérence, Isolation, Durabilité (ACID) pour garantir l’intégrité des données, faisant des jointures internes un choix approprié. Cependant, les bases de données de transaction ont généralement également des colonnes de jointure souhaitables qui peuvent être NULL.De nombreuses bases de données relationnelles de rapports et entrepôts de données utilisent des mises à jour par lots d’extraction, de transformation, de chargement (ETL) à grand volume qui rendent l’intégrité référentielle difficile voire impossible à appliquer, ce qui entraîne des colonnes de jointure potentiellement NULL qu’un auteur de requête SQL ne peut pas modifier et qui entraînent l’omission des jointures internes. données sans indication d’erreur. Le choix d’utiliser une jointure interne dépend de la conception de la base de données et des caractéristiques des données. Une jointure externe gauche peut généralement être remplacée par une jointure interne lorsque les colonnes de jointure d’une table peuvent contenir des valeurs NULL.

Toute colonne de données pouvant être NULL (vide) ne doit jamais être utilisée comme lien dans un jointure interne, sauf si le résultat attendu est d’éliminer les lignes avec la valeur NULL. Si les colonnes de jointure NULL doivent être délibérément supprimées du jeu de résultats, une jointure interne peut être plus rapide qu’une jointure externe car la jointure de table et le filtrage sont effectués en une seule étape. À l’inverse, une jointure interne peut entraîner des performances désastreusement lentes ou même un plantage du serveur lorsqu’elle est utilisée dans une requête de grand volume en combinaison avec des fonctions de base de données dans une clause SQL Where. Une fonction dans une clause SQL Where peut amener la base de données à ignorer les index de table relativement compacts. La base de données peut lire et joindre en interne les colonnes sélectionnées des deux tables avant de réduire le nombre de lignes à l’aide du filtre qui dépend d’une valeur calculée, ce qui entraîne une quantité relativement énorme de traitement inefficace.

Lorsqu’un ensemble de résultats est produite en joignant plusieurs tables, y compris les tables maîtres utilisées pour rechercher des descriptions en texte intégral des codes d’identificateurs numériques (une table de recherche), une valeur NULL dans l’une des clés étrangères peut entraîner l’élimination de la ligne entière du jeu de résultats, sans indication d’erreur. Une requête SQL complexe qui comprend une ou plusieurs jointures internes et plusieurs jointures externes présente le même risque pour les valeurs NULL dans les colonnes de lien de jointure interne.

Un engagement envers un code SQL contenant des jointures internes suppose que les colonnes de jointure NULL ne le seront pas être introduit par les futures modifications, y compris les mises à jour du fournisseur, les modifications de conception et le traitement en masse en dehors des règles de validation des données de l’application telles que les conversions de données, les migrations, les importations en masse et les fusions.

On peut classer davantage les jointures internes comme équi-jointures, comme jointures naturelles ou comme jointures croisées.

Equi-joinEdit

Une équi-jointure est un type spécifique de jointure basée sur un comparateur, qui utilise uniquement des comparaisons d’égalité dans le prédicat de jointure. L’utilisation d’autres opérateurs de comparaison (tels que <) disqualifie une jointure en tant qu’équi-jointure. La requête ci-dessus a déjà fourni un exemple d’équi-jointure:

SELECT *FROM employee JOIN department ON employee.DepartmentID = department.DepartmentID;

Nous pouvons écrire une équi-jointure comme ci-dessous,

SELECT *FROM employee, departmentWHERE employee.DepartmentID = department.DepartmentID;

Si co les lumns dans une équi-jointure ont le même nom, SQL-92 fournit une notation abrégée facultative pour exprimer les équi-jointures, via la construction USING:

SELECT *FROM employee INNER JOIN department USING (DepartmentID);

La construction USING est cependant plus qu’un simple sucre syntaxique, car l’ensemble de résultats diffère du résultat ensemble de la version avec le prédicat explicite. Plus précisément, toutes les colonnes mentionnées dans la liste USING n’apparaîtront qu’une seule fois, avec un nom non qualifié, plutôt qu’une fois pour chaque table de la jointure. Dans le cas ci-dessus, il y aura une seule colonne DepartmentID et pas de employee.DepartmentID ou department.DepartmentID .

La clause USING n’est pas prise en charge par MS SQL Server et Sybase.

Natural joinEdit

Le naturel join est un cas particulier d’équi-jointure. La jointure naturelle (⋈) est un opérateur binaire qui s’écrit (R ⋈ S) où R et S sont des relations. Le résultat de la jointure naturelle est l’ensemble de toutes les combinaisons de tuples dans R et S qui sont égales sur leurs noms d’attributs communs.Pour un exemple, considérez les tables Employee et Dept et leur jointure naturelle:

Ceci peut également être utilisé pour définir la composition des relations. Par exemple, la composition de Employee et Dept est leur jointure comme indiqué ci-dessus, projetée sur tous sauf l’attribut commun DeptName. Dans la théorie des catégories, la jointure est précisément le produit de la fibre.

La jointure naturelle est sans doute l’un des opérateurs les plus importants car elle est la contrepartie relationnelle du ET logique. Notez que si la même variable apparaît dans chacun des deux prédicats qui sont connectés par AND, alors cette variable représente la même chose et les deux apparences doivent toujours être remplacées par la même valeur. En particulier, la jointure naturelle permet la combinaison de relations associées par une clé étrangère. Par exemple, dans l’exemple ci-dessus, une clé étrangère contient probablement de Employee.DeptName à Dept.DeptName, puis la jointure naturelle de Employee et Dept combine tous les employés avec leurs départements. Cela fonctionne car la clé étrangère contient entre les attributs du même nom. Si ce n’est pas le cas, comme dans la clé étrangère de Dept.manager à Employee.Name, ces colonnes doivent être renommées avant que la jointure naturelle ne soit prise. Une telle jointure est parfois également appelée équi-jointure.

Plus formellement, la sémantique de la jointure naturelle est définie comme suit:

R ⋈ S = {t ∪ s ∣ t ∈ R ∧ s ∈ S ∧ F un (t ∪ s)} {\ Displaystyle R \ bowtie S = \ left \ {t \ cup s \ mid t \ in R \ \ land \ s \ in S \ \ land \ {\ mathit {Fun}} (t \ cup s) \ right \}},

où Fun est un prédicat qui est vrai pour une relation r si et seulement si r est une fonction. Il est généralement nécessaire que R et S aient au moins un attribut commun, mais si cette contrainte est omise et que R et S n’ont pas d’attributs communs, alors la jointure naturelle devient exactement le produit cartésien.

Le la jointure naturelle peut être simulée avec les primitives de Codd comme suit. Soit c1,…, cm les noms d’attributs communs à R et S, r1,…, rn les noms d’attributs uniques à R et soit s1,…, sk le attributs propres à S. De plus, supposons que les noms d’attributs x1,…, xm ne soient ni dans R ni dans S. Dans un premier temps, les noms d’attributs communs dans S peuvent maintenant être renommés:

T = ρ x 1 / c 1,…, xm / cm (S) = ρ x 1 / c 1 (ρ x 2 / c 2 (… ρ xm / cm (S)…)) {\ Displaystyle T = \ rho _ {x_ {1} / c_ {1}, \ ldots, x_ {m} / c_ {m}} (S) = \ rho _ {x_ {1} / c_ {1}} (\ rho _ {x_ {2} / c_ {2 }} (\ ldots \ rho _ {x_ {m} / c_ {m}} (S) \ ldots))}

Ensuite, nous prenons le produit cartésien et sélectionnons les tuples à joindre:

U = π r 1,…, rn, c 1,…, cm, s 1,…, sk (P) {\ displaystyle U = \ pi _ {r_ {1}, \ ldots, r_ {n}, c_ {1}, \ ldots, c_ {m}, s_ {1}, \ ldots, s_ {k}} (P)}

Une jointure naturelle est un type d’équi- join où le prédicat de jointure survient implicitement en comparant toutes les colonnes des deux tables qui ont les mêmes noms de colonne dans les tables jointes. La table jointe résultante contient une seule colonne pour chaque paire de colonnes de même nom. Dans le cas où aucune colonne portant le même nom n’est trouvée, le résultat est une jointure croisée.

La plupart des experts s’accordent à dire que les JOINTS NATURELS sont dangereux et découragent donc fortement leur utilisation. Le danger vient de l’ajout par inadvertance d’une nouvelle colonne, nommée de la même manière qu’une autre colonne de l’autre table. Une jointure naturelle existante pourrait alors utiliser « naturellement » la nouvelle colonne pour des comparaisons, en effectuant des comparaisons / correspondances en utilisant des critères différents (de colonnes différentes) qu’auparavant. Ainsi, une requête existante pourrait produire des résultats différents, même si les données des tables n’ont pas été modifiées, mais seulement augmentées.L’utilisation de noms de colonnes pour déterminer automatiquement les liens de table n’est pas une option dans les grandes bases de données avec des centaines ou des milliers de tables où elle placerait une contrainte irréaliste sur les conventions de dénomination. Les bases de données du monde réel sont généralement conçues avec des données de clé étrangère qui ne sont pas systématiquement renseignées (les valeurs NULL sont autorisées), en raison des règles métier et du contexte. Il est courant de modifier les noms de colonne de données similaires dans différentes tables et ce manque de cohérence rigide relègue les jointures naturelles à un concept théorique de discussion.

L’exemple de requête ci-dessus pour les jointures internes peut être exprimé comme un naturel joignez-vous de la manière suivante:

SELECT *FROM employee NATURAL JOIN department;

Comme pour la clause USING explicite, une seule colonne DepartmentID apparaît dans la table jointe, sans qualificatif:

PostgreSQL, MySQL et Oracle su pporter les jointures naturelles; Microsoft T-SQL et IBM DB2 ne le font pas. Les colonnes utilisées dans la jointure sont implicites, de sorte que le code de jointure n’indique pas les colonnes attendues et une modification des noms de colonne peut modifier les résultats. Dans la norme SQL: 2011, les jointures naturelles font partie du package optionnel F401, « Table jointe étendue ».

Dans de nombreux environnements de base de données, les noms de colonne sont contrôlés par un fournisseur externe, et non par le développeur de requêtes. Une jointure naturelle suppose la stabilité et la cohérence des noms de colonnes qui peuvent changer lors des mises à niveau de version mandatées par le fournisseur.