Introduction aux Jointures

les Jointures Externes

les jointures Externes sont utilisés pour faire correspondre les lignes de deux tables. Même s’il n’y a pas de correspondance, les lignes sont incluses. Les lignes de l’une des tables sont toujours incluses, pour l’autre, lorsqu’il n’y a pas de correspondance, les valeurs NULL sont incluses.

la série commence par L’article Introduction aux jointures de base de données. Tous les exemples de cette leçon sont basés sur Microsoft SQL Server Management Studio et la base de données AdventureWorks2012. Vous pouvez commencer à utiliser ces outils gratuits en utilisant mon Guide pour commencer à utiliser SQL Server., Dans cet article, nous allons couvrir les jointures externes.

Types de jointures externes

Il existe trois types de jointures externes:

• LEFT Outer Join – toutes les lignes de la table de gauche sont incluses, les lignes non appariées de la droite sont remplacées par des valeurs NULL.
• Right Outer Join-toutes les lignes de la table de droite sont incluses, les lignes non appariées de la gauche sont remplacées par des valeurs NULL.
• FULL Outer Join – toutes les lignes des deux tables sont incluses, les valeurs NULL remplissent les lignes non appariées.

creusons plus profondément et explorons la jointure extérieure gauche.,

LEFT Outer Join

consultez le modèle de données suivant. Ceci est tiré de la base de données AdventureWorks2012. Dans ce modèle, il y a 1 personne pour 0 ou 1 employé.

pour construire une liste de tous les noms de famille de personnes, mais aussi afficher JobTitle si la personne est un employé, nous avons besoin d’un moyen de joindre les deux tables et d’inclure des lignes de personnes dans le résultat, même si elles ne correspondent pas à Employee.

Ce type de jointure est appelé jointure externe gauche, car toutes les lignes de la table du côté gauche du mot clé jointure sont incluses quelle que soit la correspondance., La syntaxe de base pour une jointure externe gauche est:

SELECT columnlistFROM tableLEFT OUTER JOIN othertable ON join condition

le code SQL de La rejoindre dans le diagramme ci-dessus est:

SELECT person.Person.BusinessEntityID, Person.Person.LastName, HumanResources.Employee.NationalIDNumber, HumanResources.Employee.JobTitleFROM person.PersonLEFT OUTER JOIN HumanResources.Employee ON person.BusinessEntityID = Employee.BusinessEntityID

Voici les premiers résultats de la requête

Notez qu’il existe des valeurs NULL sont répertoriés dans la deuxième ligne pour NationalIDNumber et JobTitle. En effet, il n’y a pas d’employés correspondant BusinessEntityID 293.

Right Outer Join

prenons un autre regard sur le schéma, mais cette fois nous faisons une jointure externe droite., Comme vous l’aurez deviné, il n’y a pas trop de différence dans l’instruction SQL entre une jointure externe gauche et une jointure externe droite. La syntaxe de base pour une jointure externe droite est:

SELECT columnlistFROM tableRIGHT OUTER JOIN othertable ON join condition

ci-Dessous notre exemple de requête écrite comme une jointure externe droite:

SELECT person.Person.BusinessEntityID, Person.Person.LastName, HumanResources.Employee.NationalIDNumber, HumanResources.Employee.JobTitleFROM person.PersonRIGHT OUTER JOIN HumanResources.Employee ON person.BusinessEntityID = Employee.BusinessEntityID

La principale différence est que maintenant, nous allons retourner tous les enregistrements de la table des Employés, qui est le tableau à droite de la jointure mot-clé. Si un enregistrement employé correspondant n’est pas trouvé, NULL sera renvoyé pour BusinessEntityID et LastName.

Voici les résultats de la requête.,

j’ai fait défiler tous les résultats et j’ai été surpris de ne voir aucune valeur nulle.

savez-vous pourquoi?

la réponse réside dans le modèle de données. Il y a un 0..1 à 1 relation entre L’employé et la personne. Cela signifie que pour chaque employé, il y a une personne. Compte tenu de cela, pour la jointure droite, il n’existera aucune ligne non correspondante. Avec ce type de relation, vous auriez également pu utiliser une jointure interne.

Gauche contre Droite, les Jointures Externes

Il n’y a pas de différence de fonctionnalités entre une jointure externe gauche et une jointure externe droite.,

L’instruction

SELECT person.Person.BusinessEntityID, HumanResources.Employee.NationalIDNumberFROM person.PersonLEFT OUTER JOIN HumanResources.Employee ON person.BusinessEntityID = Employee.BusinessEntityID

Renvoie le même résultat que

SELECT person.Person.BusinessEntityID, HumanResources.Employee.NationalIDNumberFROM HumanResources.EmployeeRIGHT OUTER JOIN person.Person ON person.BusinessEntityID = Employee.BusinessEntityID

bien sûr, ce ne serait pas le cas si j’avais changé le rejoindre de GAUCHE à DROITE et pas inversé les noms de table.

j’utilise généralement les jointures externes gauche plus que les jointures externes droite. Je pense que c’est parce que quand je dessine des relations, je le fais de gauche à droite. Aussi, je traverse des tables dans ma tête de gauche à droite.

cela s’intègre bien avec SQL car la table « gauche” est dans L’instruction FROM.

je suis curieux de savoir ce que vous utilisez., Je suis vraiment curieux de savoir si une jointure à droite vous semble plus intuitive Si vous êtes un locuteur natif de l’arabe ou d’une autre langue « de droite à gauche”.

jointure externe complète

une jointure externe complète est la combinaison des résultats d’une jointure externe gauche et droite. Les résultats renvoyés par ce type de jointure incluent toutes les lignes des deux tables. Lorsque des correspondances se produisent, les valeurs sont liées. Où la correspondance de l’une ou l’autre table ne le fait pas, alors NULL est renvoyé à la place.,

la syntaxe de base pour une jointure externe complète est:

SELECT columnlistFROM tableFULL OUTER JOIN othertable ON join condition

examinons une autre partie de la base de données AdventureWork2012. Cette fois, nous allons nous concentrer sur les relations entre les tables SalesOrderHeader et CurrencyRate.

le modèle est illustré ci-dessous:

supposons que nous souhaitions connaître toutes les devises dans lesquelles nous pouvons passer des ordres et quelles commandes ont été passées dans ces devises?

SELECT sales.SalesOrderHeader.AccountNumber, sales.SalesOrderHeader.OrderDate, sales.CurrencyRate.ToCurrencyCode, sales.CurrencyRate.AverageRateFROM sales.SalesOrderHeaderFULL OUTER JOIN sales.CurrencyRate ON sales.CurrencyRate.CurrencyRateID = sales.SalesOrderHeader.CurrencyRateID

Voici une partie des résultats montrant où certaines ventes correspondent à une devise et d’autres non., La raison pour laquelle il y a des ventes qui ne correspondent pas est que ce sont des ventes en USD.

plus bas dans les résultats, vous voyez des devises sans Ventes correspondantes. Cela reflète le fait qu’aucune vente n’a été effectuée dans ces monnaies.

Note: j’ai été surpris de voir USD répertorié, consultez la ligne 42463, car je pense que la majorité des ventes seraient dans cette monnaie. Ma pensée est que plutôt que de respecter le taux de change pour ces transactions, la valeur SalesOrderHeader pour CurrencyRateID a été définie sur null pour toutes les transactions en USD., Je pense que c’est incohérent, et ce n’est pas la façon dont je le ferais, mais ce n’est pas ma base de données

exemple avancé

Jusqu’à présent, nous avons examiné les trois types de jointures externes mais n’avons pas exploré certains concepts plus avancés tels que la jointure de plusieurs tables et

Nous avons couvert ces concepts lorsque nous avons exploré les jointures internes, donc ce que je vais vous montrer ne devrait pas être trop nouveau, mais je pense qu’il est toujours logique de passer en revue, car dans certains cas, mélanger des jointures complètes avec des jointures internes peut produire des résultats inattendus ou involontaires.,

concentrons-nous sur le schéma de production et explorons les produits et les catégories. Produisons une liste de toutes les catégories de produits et des modèles de produits contenus dans.

Product a une relation un à plusieurs avec ProductModel et ProductSubcategory. Puisqu’il se trouve entre ces deux tables, il existe une relation implicite plusieurs à plusieurs entre ProductModel et ProductSubcategory. Pour cette raison, c’est un bon candidat pour les jointures externes car il peut y avoir des modèles de produits sans produits assignés et des entrées ProductSubcategory sans produit.,

pour surmonter cette situation, nous allons faire une jointure externe à la table ProductModel et ProductCategory.

Voici le SQL

SELECT PC.Name AS Category, PSC.Name AS Subcategory, PM.Name AS Model, P.Name AS ProductFROM Production.Product AS PFULL OUTER JOIN Production.ProductModel AS PM ON PM.ProductModelID = P.ProductModelIDFULL OUTER JOIN Production.ProductSubcategory AS PSC ON PSC.ProductSubcategoryID = P.ProductSubcategoryIDINNER JOIN Production.ProductCategory AS PC ON PC.ProductCategoryID = PSC.ProductCategoryIDORDER BY PC.Name, PSC.Name

Il y a plusieurs éléments à noter:

• j’ai utilisé des alias de table pour rendre le SQL plus lisible.
• Il y a plus d’une clause de jointure externe complète.,
• La Table ProductCategory fait également partie d’une jointure externe

à l’origine, lorsque j’ai écrit le SQL pour cette requête, j’avais une jointure interne entre ProductSubcategory et ProductCategory, mais je ne voyais pas de valeurs NULL pour les enregistrements inégalés auxquels je m’attendais.

une Fois que j’ai changé le rejoindre pour une jointure externe complète, j’ai vu les résultats que j’attendais. La raison pour laquelle cela se produit est subtile.

Après avoir vérifié les données, j’ai confirmé que toutes les catégories sont affectées de sous-catégories., Compte tenu de cela, vous penseriez qu’une jointure interne fonctionnerait; cependant, considérez que lorsque l’instruction entière est exécutée et que les lignes sont renvoyées, la valeur ProductSubcategoryID est NULL chaque fois qu’un produit ne correspond pas à une sous-catégorie de produit.

Les valeurs Null, par définition, ne sont pas égales les unes aux autres, donc la jointure interne échoue. Compte tenu de cela, lorsque ces valeurs sont ensuite appariées à ProductCategory, elles ne sont pas incluses dans le résultat, sauf si la jointure à ProductCategory est une jointure externe.,

en fait, la jointure ne doit pas nécessairement être une jointure externe complète, une jointure gauche fonctionne tout aussi bien:

SELECT PC.Name AS Category,PSC.Name AS Subcategory,PM.Name AS Model,P.Name AS ProductFROM Production.Product AS PFULL OUTER JOINProduction.ProductModel AS PMON PM.ProductModelID = P.ProductModelIDFULL OUTER JOINProduction.ProductSubcategory AS PSCON PSC.ProductSubcategoryID = P.ProductSubcategoryIDLEFT OUTER JOIN Production.ProductCategory AS PC ON PC.ProductCategoryID = PSC.ProductCategoryIDORDER BY PC.Name, PSC.Name

utilise pour les jointures externes

car les jointures externes non seulement les lignes correspondantes mais aussi celles qui ne le font pas, elles sont un très bon C’est génial lorsque vous devez effectuer un diagnostic sur votre base de données pour déterminer s’il y a des problèmes d’intégrité des données.

par exemple, supposons que nous craignions d’avoir des entrées ProductSubcategory qui ne correspondent pas aux catégories., Nous pourrions tester en exécutant le SQL suivant

SELECT PSC.Name AS SubcategoryFROM Production.ProductCategory AS PSCLEFT OUTER JOIN Production.ProductSubcategory AS PC ON PC.ProductCategoryID = PSC.ProductCategoryIDWHERE PSC.ProductCategoryID is NULL

la jointure externe renvoie les valeurs de ligne non appariées sous forme de valeurs NULL. La clause where filtre sur les valeurs non nulles, ne laissant que les noms de sous-catégories non correspondants à examiner.

les jointures externes peuvent également être utilisées pour poser des questions telles que:

« quels vendeurs n’ont jamais fait de vente? »

 » quels produits ne sont pas affectés à un modèle de produit? »

 » quels ministères n’ont pas d’employés affectés? »

 » liste tous les territoires de vente non affectés aux vendeurs.”

---