La sélection simple en SQL
1 - Introduction
Nous
avons vu au chapitre précédent qu'il était possible, dans le SGBD Access, de
manipuler les tables en langage SQL.
Cependant, les commandes correspondantes sont considérées comme des requêtes, et il n'est pas possible de basculer entre le mode graphique et le mode SQL.
En effet, le mode graphique s'obtient lorsque l'objet "Tables" est sélectionné, alors que le mode SQL requiert que l'objet "Requêtes" soit actif.
Cependant, les commandes correspondantes sont considérées comme des requêtes, et il n'est pas possible de basculer entre le mode graphique et le mode SQL.
En effet, le mode graphique s'obtient lorsque l'objet "Tables" est sélectionné, alors que le mode SQL requiert que l'objet "Requêtes" soit actif.
En ce qui concerne les requêtes, la situation est nettement plus satisfaisante.
La plupart des commandes SQL relatives aux requêtes sont connues du moteur d'Access, et on bascule sans problème du mode graphique au mode SQL (l'objet "Requêtes" étant sélectionné).
Il
existe cependant quelques exceptions, que nous étudierons plus tard. Il
s'agit des opérations ensemblistes, pour lesquelles il n'existe pas d'interface
graphique.
Ces trois opérations sont :
Ces trois opérations sont :
- l'union de deux tables, pour laquelle l'opérateur UNION fonctionne ;
- l'intersection de deux tables, pour laquelle l'opérateur INTERSECT ne fonctionne pas ;
- la différence de deux tables, pour laquelle les opérateurs EXCEPT et MINUS ne fonctionnent pas.
2 - La sélection simple
Créons,
dans l'interface graphique, la requête qui extrait de la table
"Personnes" (contenant une liste de personnes) les deux champs
"Nom" et "Prénom".
Cliquons sur la petite flèche située à droite de l'outil "Affichage", et dans la liste déroulante, choisissons "Mode SQL".
La commande (ou instruction) suivante s'affiche :
Cliquons sur la petite flèche située à droite de l'outil "Affichage", et dans la liste déroulante, choisissons "Mode SQL".
La commande (ou instruction) suivante s'affiche :
SELECT Personnes.Nom, Personnes.Prénom
FROM Personnes;
La requête simple commence par la clause "SELECT", suivie du nom des champs, puis continue avec la clause "FROM", suivie du nom de la table à laquelle appartiennent les champs.
Le point-virgule marque la fin de la commande.
La syntaxe relative aux noms des champs consiste à écrire le
nom de la table, suivi d'un point et du nom du champ. Cette façon de procéder s'appelle
la qualification.
Dans le cas présent, cette qualification est redondante, et nous pouvons très bien écrire :
Dans le cas présent, cette qualification est redondante, et nous pouvons très bien écrire :
SELECT Nom,
Prénom FROM Personnes;
La politique la plus raisonnable consiste à qualifier les
champs chaque fois qu'une ambiguïté existe (même nom de champ dans deux tables
différentes, lors d'une requête multi-table), et de ne pas les qualifier dans
le cas contraire.
Nous avons vu au chapitre précédent qu'il existait des restrictions sévères sur les noms des tables et des champs en SQL.
Pour s'en affranchir, il faut mettre les noms des champs, et celui de la table, entre crochets pour éviter les ennuis.
Les expressions :
SELECT [Personnes].[Nom], [Personnes].[Prénom] FROM
[Personnes];
SELECT [Nom], [Prénom] FROM [Personnes];
sont parfaitement valables.
Par prudence, certains
professionnels utilisant les SGBD préfèrent s'abstenir de tout caractère
accentué, remplacent systématiquement l'espace par le caractère de
soulignement, et évitent d'utiliser les termes réservés.Rappelons que l'implémentation de SQL par Access accepte les caractères accentués pour les noms des champs et des tables.
Attention aux détails de syntaxe !
Comme tous les langages informatiques, SQL a ses petites manies qui empoisonnent les utilisateurs. L'interface graphique a ceci de bon qu'elle nous débarrasse de ces problèmes stupides -- en plus du fait qu'elle nous permet de créer des requêtes plus simplement et plus rapidement.
On notera que, dans Access, le point-virgule qui marque la fin d'une commande n'est pas indispensable.
Comme tous les langages informatiques, SQL a ses petites manies qui empoisonnent les utilisateurs. L'interface graphique a ceci de bon qu'elle nous débarrasse de ces problèmes stupides -- en plus du fait qu'elle nous permet de créer des requêtes plus simplement et plus rapidement.
On notera que, dans Access, le point-virgule qui marque la fin d'une commande n'est pas indispensable.
3 - La requête avec création de table
Récupérons
la requête précédente dans l'interface graphique, faisons en sorte qu'elle crée
une table appelée "Essai", puis basculons en mode SQL.
Nous obtenons :
Nous obtenons :
SELECT Personnes.Nom, Personnes.Prénom INTO Essai
FROM Personnes;
Nous voyons que la création de la table est effectuée grâce
à la clause INTO, suivi du nom de la table.
En SQL version Oracle, on écrirait
plutôt :
INSERT INTO Essai
SELECT Personnes.Nom, Personnes.Prénom
FROM Personnes;
Dans Access, cette syntaxe fonctionne à condition que la
table "Essai" préexiste, et contienne au moins les champs
"Nom" et "Prénom" avec les mêmes propriétés que dans la
table "Personnes". Access effectue alors une requête ajout des deux
premières colonnes de la table "Personnes" à la table
"Essai".
4 - Le tri simple ou multiple
Nous
pouvons demander que le résultat de la requête soit trié sur un ou plusieurs
champs.
Récupérons la requête précédente dans l'interface graphique, faisons en sorte que le résultat soit trié sur les noms d'abord, sur les prénoms ensuite, et basculons en mode SQL. Nous obtenons :
Récupérons la requête précédente dans l'interface graphique, faisons en sorte que le résultat soit trié sur les noms d'abord, sur les prénoms ensuite, et basculons en mode SQL. Nous obtenons :
SELECT Personnes.Nom, Personnes.Prénom
FROM Personnes
ORDER BY Personnes.Nom, Personnes.Prénom;
Nous voyons que le tri (dans l'ordre croissant) s'obtient
grâce à la clause ORDER BY, suivi des noms des champs. Le tri multiple est
effectué dans l'ordre d'énumération des champs.
Le tri d'un champ dans l'ordre décroissant s'obtient en
faisant suivre le nom de ce champ par l'opérateur DESC.
L'exemple suivant effectue un tri croissant sur les noms, suivi d'un tri décroissant sur les prénoms :
L'exemple suivant effectue un tri croissant sur les noms, suivi d'un tri décroissant sur les prénoms :
SELECT Personnes.Nom, Personnes.Prénom
FROM Personnes
ORDER BY Personnes.Nom, Personnes.Prénom DESC;
5 - L'élimination des doublons
Comme nous l'avons vu, la requête simple peut
créer des doublons, et il est possible de remédier de façon simple à cette
situation en jouant sur les propriétés de la requête.
Créons dans l'interface
graphique une requête de sélection simple qui concerne le seul champ
"Nom" de la table "Personnes".
Modifions la propriété
"Valeurs distinctes" de "Non" à "Oui", puis
basculons en mode SQL.
Nous obtenons :
SELECT DISTINCT Personnes.Nom
FROM Personnes;
Nous voyons que l'élimination des doublons s'obtient à
l'aide de l'opérateur DISTINCT placé juste après la clause SELECT.
Une syntaxe plus ancienne est également comprise par Access, mais elle ne semble plus guère utilisée :
Une syntaxe plus ancienne est également comprise par Access, mais elle ne semble plus guère utilisée :
SELECT
DISTINCT(Nom)
FROM Personnes;
Pour éviter de créer des doublons sur deux champs, la
commande SQL s'écrit :
SELECT DISTINCT Personnes.Nom, Personnes.Prénom
FROM Personnes;
6 - La requête avec création de champ
Reprenons l'exemple lequel
consiste à concaténer le nom avec le prénom, en les séparant par un espace.
Appelons "Nom_complet" le nouveau champ.
En mode SQL, nous obtenons :
SELECT [Nom] & " " & [Prénom] AS
Nom_complet
FROM Personnes;
La façon d'extraire le contenu des champs et d'exprimer la
concaténation varient d'un SGBD à l'autre. Cependant, la possibilité de créer
un nouveau champ (et d'en définir le contenu à partir de champs existants) se
retrouve dans tous les SGBD dignes de ce nom.
7 - La requête multi-fonctionnelle
En définitive, nous pouvons regrouper toutes les opérations
précédentes (requête simple, création de table, création de champ, tri et
élimination des doublons) en une seule requête, dont voici le code SQL (en
version Access) :
SELECT DISTINCT [Nom] & " " & [Prénom] AS
Nom_complet INTO Liste_de_noms
FROM Personnes
ORDER BY [Nom] & " " & [Prénom];
8 - Les requêtes emboîtées
Nous
avons vu au chapitre 8 qu'il est possible de créer dans Access une requête à
partir du résultat d'une autre requête, à condition que cette dernière ne crée
pas de table.
En mode SQL, la commande s'écrit :
En mode SQL, la commande s'écrit :
SELECT Requête1.Nom
FROM Requête1;
On ne peut pas rêver plus simple pour emboîter deux requêtes
! Cette belle simplicité ne se retrouve pas en SQL pur et dur, où l'emboîtement
de deux requêtes est d'une écriture plutôt complexe.
Que l'on en juge :
Que l'on en juge :
- si la première requête (encore appelée sous-requête, ou sous-interrogation) ramène une valeur numérique unique (résultat d'une opération du type comptage, sommation, calcul de moyenne, etc.), on utilise les opérateurs arithmétiques usuels : =, <, >, >=, <= et <> ;
- si la première requête ramène une seule ligne, on utilise les opérateurs IN, ALL, ou ANY suivant les cas ;
- si la première requête est susceptible de ramener plusieurs lignes, on utilise EXISTS ou NON EXISTS.
Bonjour les erreurs !
9 - Conclusion
Une double constatation :
- le langage SQL est d'un usage assez facile, sauf en ce qui concerne l'emboîtement des requêtes. Pour réaliser l'emboîtement, l'utilisation de l'interface graphique d'Access est beaucoup plus simple. Cette situation résulte du fait que le SQL mis en oeuvre par Access permet d'évoquer une requête par son nom, ce qui n'est pas le cas du SQL usuel ;
- Access fournit un moyen didactique commode pour aborder l'étude du langage SQL.
Aucun commentaire:
Enregistrer un commentaire