Utiliser des prédicats quantifiés de SQL

L’instruction Select ci-dessous produit une table de résultat avec tous les clients
dont l’encours est supérieur à  l’encours moyen de tous les clients :



Select *

   From Customer

   Where CuAmtDue

         > ( Select Avg( CuAmtDue
)

               From
Customer )



The = All Quantified Predicate



Dans cet article, j’explique comment utiliser des sous-requêtes avec un prédicat
quantifié. La figure 1 présente la table « Sale », déclarée dans la requête de la
figure 2. La figure 3 montre une requête qui produit une table résultat (figure
4) des clients dont toutes les commandes ont été livrées à  la même date. J’ai
utilisé le mot-clé Distinct dans la figure 3 pour que chaque client ne figure
qu’une fois dans la table de résultat.

Notons que par défaut tous les clients n’ayant qu’une livraison satisfont aux
exigences de cette requête. Ce sont tous les clients présents dans la figure 4,
à  l’exception du client 246900. En revenant à  la figure 1, nous voyons que ce
dernier satisfait aux exigences de cette requête parce que deux de ses livraisons
s’effectuent à  la même date (2000-05-08). Le client 499320 n’est pas inclus parce
qu’il a trois livraisons, toutes avec des dates de livraison différentes.



Voyons de plus près la requête de la figure 3. Le prédicat quantifié ici est



ShpDate

   = All

      ( Select … )



Les prédicats quantifiés doivent être suivis d’une sous-requête



Le signe égal (=) est appelé opérateur de comparaison ; le mot All est appelé
quantifieur.

Le quantifieur est suivi de la sous-requête entre parenthèses. On se souvient
que les sous-requêtes se trouvent toujours entre parenthèses. Contrairement aux
prédicats simples, les prédicats quantifiés doivent être suivis d’une sous-requête.
De plus, la sous-requête doit définir une colonne unique. Mais, avec les prédicats
quantifiés, la sous-requête peut produire (et produit généralement) des lignes
multiples.



Chaque fois qu’on définit = All comme dans cet exemple, on stipule que chaque
valeur produite dans la sous-requête doit être égale à  l’expression située du
côté gauche du prédicat. Dans la figure 3, j’indique que ShpDate (situé à  gauche
de = All) doit être égal à  chaque valeur produite dans la sous-requête.



Les étapes suivantes représentent ce qui se produit (sur un plan conceptuel, mais
pas forcément réel) dans cette requête.



1. Les lignes sont examinées une à  une dans la requête principale.

2. Pour chaque ligne de la table Sale, le gestionnaire de base de données évalue
la sous-requête pour produire une table résultat.

3. Le ShpDate pour la ligne prise en compte dans la requête principale est comparé
à  chaque date de livraison produite dans la sous-requête.

4. Si les dates de livraison sont égales dans tous les cas, la ligne est placée
dans la table résultat finale. Elle n’y est pas placée si les dates de livraison
sont différentes dans l’une quelconque des comparaisons.



La sous-requête utilise la même table (Sale) dans sa clause From que la requête
principale. Comme la clause Where dans la sous-requête doit se référer aux colonnes
de la requête principale et de la sous-requête, et comme les tables sous-jacentes
sont les mêmes, j’ai dû donner un nom de corrélation pour les deux tables : OuterSale
et InnerSale dans cet exemple.



Pour certains, les noms de corrélation servent à  raccourcir le nom d’une table.
On pourrait, par exemple, utiliser la lettre A comme nom de corrélation dans la
requête principale et B comme nom de corrélation dans la sous-requête. Dans ce
cas, la clause Where pour la sous-requête se présenterait ainsi :



Where A.CustID = B.CustID



Il est vrai qu’en choisissant des noms de corrélation courts, on réduit le nombre
de frappes nécessaires pour entrer une requête. Mais la requête est alors moins
lisible. Il est donc préférable d’utiliser des noms plus significatifs pour les
noms de corrélation, comme dans la figure 3.