|
Chapitre 19 :
la sélection en SQL |
|
|
1 - Introduction |
|
||||||||||
|
|
|
Nous
connaissons désormais l'allure des commandes SQL, dans le cadre de la
sélection simple. Il est temps que nous abordions : |
|
|||||||||
|
|
|
|
|
|||||||||
|
|
|
Comme
pour les autres chapitres, nous utilisons le SGBD Access comme support
pratique de ce tutoriel (ou tutorial, ou cours en ligne). |
|
|||||||||
|
|
|
Chaque
fois que cela sera possible, nous ferons écrire le code SQL par le SGBD, en
partant de l'interface graphique de définition des requêtes avant de basculer
en mode SQL. |
|
|||||||||
|
|
||||||||||||
|
|
2 - La sélection en SQL |
|
||
|
|
|
La
sélection permet d'extraire d'une table (ou de plusieurs tables liées par des
relations) les enregistrements répondant à un ou plusieurs critères. Notons
au passage qu'un critère peut aussi être appelé une condition. Rappelons que l'ensemble des critères
définit un filtre. |
|
|
|
|
|
A
titre de premier exemple, cherchons dans la table "Personnes" (qui
contient des noms, des prénoms, des adresses, etc.) les personnes dont le nom
commence par la lettre "c" (majuscule ou minuscule, la casse n'importe
pas). Dans la grille de création de la requête, nous exprimons la condition
sous la forme : |
|
|
|
|
|
Comme "c*" |
|
|
|
|
|
Si
nous basculons en mode SQL, nous obtenons le code suivant : |
|
|
|
||||
|
|
|
Nous
voyons que la condition s'exprime à l'aide de la clause WHERE, suivie du nom
du champ et de la condition. L'opérateur
LIKE correspond au français "Comme". |
|
|
|
|
|
La
clause WHERE est suivie d'un parenthèsage aussi
impressionnant qu'inutile. De plus, la qualification est superflue. Si nous
écrivons la requête sous la forme : |
|
|
|
||||
|
|
|
elle
fonctionne tout aussi bien, et le SGBD Access ne tente de rétablir ni les
parenthèses, ni la qualification. |
|
|
|
|
|
Rajoutons
un champ de type date dans la table "Personnes", et sélectionnons les
enregistrements relatifs à l'année 2002 seule. Dans l'interface graphique,
nous écrivons le critère sous la forme : |
|
|
|
|
|
>#31/12/2001# ET <#01/01/2003# |
|
|
|
|
|
Si
nous basculons en mode SQL, nous obtenons le code suivant, après élimination des
parenthèses et de la qualification : |
|
|
|
||||
|
|
|
Nous
pourrions faire des expériences analogues avec un champ numérique (opérateurs
arithmétiques), ou un champ booléen. Les conditions sur le "Null" (champ non renseigné dans un enregistrement
donné) s'écrivent à l'aide des expressions "Is Null"
et "Is Not Null", dont la traduction
française dans Access est "Est Null" ou
"Est Pas Null". On peut combiner
plusieurs conditions à l'aide des opérateurs logiques "And",
"Or" et "Not", dont la traduction française dans Access
est "Et", "Ou" et "Pas". Enfin, une condition
peut comprendre des opérateurs arithmétiques ou des fonctions mathématiques (si
elle porte sur des nombres) ou des opérateurs de chaînes (si elle porte sur
du texte). |
|
|
|
|
|
Remarque
: notre façon de sélectionner l'année 2002 est d'un usage très général, mais
elle semble un peu lourde. L'utilisation de la fonction "Year()"
est plus élégante, mais cette fonction est spécifique de VBA (Visual Basic
for Applications, le langage de programmation lié à Office). Voici le code
SQL correspondant : |
|
|
|
||||
|
|
|
Nous
constatons que la requête fonctionne toujours si nous éliminons les crochets
entourant l'argument "Date" dans la fonction "Year". Mais, dans l'interface graphique, la
définition de la requête a changé ! Access a créé un nouveau champ
intitulé "Année([Date])" et inscrit la
valeur "2002"sur la ligne "Critères :". Notons au passage
que l'on peut franciser "Year" en
"Année" dans l'interface graphique d'Access, mais pas dans la
programmation d'un module VBA ou l'écriture d'une commande SQL. |
|
|
|
|
||||
|
|
3 - Les jointures |
|
||||||||||
|
|
|
Effectuons
maintenant une requête sur deux tables ("Personne" et
"Communes") liées par une relation (appliquée aux champs "code_commune"). La requête SQL s'écrit : |
|
|||||||||
|
||||||||||||
|
|
|
|
|
|||||||||
|
||||||||||||
|
|
|
Nous
voyons que "INNER JOIN" traduit l'existence d'une relation entre
les deux tables, et que "ON" précise quels sont les champs mis en
relation. |
|
|||||||||
|
|
|
En
SQL1, la commande précédente s'écrit différemment. La clause INNER JOIN disparaît
au profit d'une simple virgule, et la traduction de la mise en relation des
tables s'exprime à l'aide de la clause WHERE : |
|
|||||||||
|
||||||||||||
|
|
|
Le
SGBD Access accepte cette syntaxe mais, si nous revenons dans l'interface graphique,
nous constatons que cette dernière a changé : la relation entre les deux
tables a disparu ! Elle est remplacée par la condition d'égalité de
contenu entre les champs "code_commune"
des deux tables (condition exprimée en utilisant la syntaxe du SQL), comme le
montre la figure ci-dessous -- une façon élémentaire, mais parfaitement
exacte, de créer une relation entre deux tables. On notera que la relation
normale entre les deux tables n'est pas supprimée, mais simplement éliminée
de la fenêtre de création de la requête. |
|
|||||||||
|
|
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
|
|
La
clause INNER JOIN a fait son apparition avec la version 2 de SQL, parce que
le besoin s'était fait sentir de préciser à quel type de jointure appartenait une relation. Plus
précisément, on distingue : |
|
|||||||||
|
|
|
|
|
|||||||||
|
|
|
Dans
Access, la syntaxe des jointures gauche et droite est simplifiée en LEFT JOIN
et RIGHT JOIN, comme le montrent les deux exemples suivants : |
|
|||||||||
|
||||||||||||
|
|
|
La
jointure peut également être précisée dans la fenêtre graphique de définition
d'une requête, comme nous l'avons vu au chapitre 13. |
|
|||||||||
|
|
||||||||||||
|
|
4 - Le regroupement |
|
||||||||||||||||||||||
|
|
|
Nous
avons étudié le regroupement au chapitre 14. Nous réutilisons la même table,
intitulée "Résultats" et représentée ci-dessous. |
|
|||||||||||||||||||||
|
|
||||||||||||||||||||||||
|
||||||||||||||||||||||||
|
|
||||||||||||||||||||||||
|
|
|
Nous
effectuons le regroupement par date et nous sommons sur le CA. Nous obtenons
le code SQL suivant : |
|
|||||||||||||||||||||
|
||||||||||||||||||||||||
|
|
|
dans
lequel le regroupement est exprimé par la clause GROUP BY. La requête fournit
le résultat suivant : |
|
|||||||||||||||||||||
|
|
||||||||||||||||||||||||
|
||||||||||||||||||||||||
|
|
||||||||||||||||||||||||
|
|
|
Nous
avons vu au chapitre 14 qu'une requête avec regroupement peut être
filtrée avant ou après regroupement. Nous créons un exemple de filtrage avant
regroupement en éliminant l'agence Est. Nous obtenons le code SQL suivant : |
|
|||||||||||||||||||||
|
||||||||||||||||||||||||
|
|
|
Nous
reconnaissons une requête de sélection classique (dans les trois premières
lignes), suivie d'un regroupement. La requête fournit le résultat
suivant : |
|
|||||||||||||||||||||
|
|
||||||||||||||||||||||||
|
||||||||||||||||||||||||
|
|
||||||||||||||||||||||||
|
|
|
Nous
rajoutons ensuite un filtrage après regroupement en ne retenant que les
CA supérieurs à 2500 €. Nous obtenons le code SQL suivant : |
|
|||||||||||||||||||||
|
||||||||||||||||||||||||
|
|
|
dans
lequel le filtrage après regroupement utilise la clause HAVING. La requête
fournit le résultat suivant : |
|
|||||||||||||||||||||
|
|
||||||||||||||||||||||||
|
||||||||||||||||||||||||
|
|
||||||||||||||||||||||||
|
|
|
D'une
manière générale, une requête avec regroupement s'écrit en SQL : |
|
|||||||||||||||||||||
|
||||||||||||||||||||||||
|
|
||||||||||||||||||||||||
|
|
4 - Conclusion |
|
|
|
|
|
Comme
dans le chapitre précédent, le langage SQL ne nous a pas permis d'effectuer
des requêtes qui eussent été impossibles dans l'interface graphique d'Access.
Il nous a cependant permis de simplifier la recherche des doublons (Cf le chapitre 15). Une commande SQL plus simple
s'exécute plus vite, et la différence de temps devient sensible lorsqu'on
traite un grand volume de données. |
|
|
|
|||