Pour partager cette vidéo sur les réseaux sociaux ou sur un site, voici son url :
Sujets que vous pourriez aussi aimer :
Exercice Access sur les requêtes SQL
Jusqu'alors nous avons construit des requêtes sélection, paramétrées et de synthèse avec l'éditeur qu'offre
Access . Mais cet éditeur ne fait rien de plus que transcrire visuellement les actions enclenchées par le
langage SQL .
SQL signifie
Structured Query Language . Ce langage est effectivement à la fois simple et structuré. Nous proposons de l'aborder dans ce quatrième
exercice sur les
requêtes . Dans certaines circonstances, il permet d'atteindre les objectifs et d'obtenir les résultats plus simplement qu'avec l'éditeur. En outre, il délivre rapidement souplesse et puissance.
Base de données source
Nous poursuivons la construction de notre
base de données . Et pour cela, nous devons commencer par récupérer les travaux là où nous les avions laissés.
Les
tables que nous avons paramétrées et les
requêtes que nous avons construites sont énumérées dans le
volet des objets Access , sur la gauche de l'écran.
Dans ce volet, cliquer droit sur la requête RS_nb_clients_dep ,
Dans le menu contextuel, choisir Mode création ,
Nous basculons dans l'éditeur de requête. Cette vue en conception permet d'ajuster ou de modifier les réglages. Il s'agit d'une
requête de synthèse paramétrée . Nous l'avons bâtie dans l'exercice précédent. Elle compte tous les clients habitant un département à définir au moment de l'exécution.
Découverte du langage Sql
Nous l'avons évoqué, la vue en conception est une transcription de ce qui est engendré par le
langage SQL .
Access permet donc d'accéder à la correspondance
SQL d'une requête construite avec l'éditeur. Nous proposons de nous appuyer sur une
requête sélection simple afin de découvrir la syntaxe, les mots clés et les clauses. Nous comprendrons ainsi comment construire les expressions destinées à produire les extractions souhaitées.
Fermer la requête RS_nb_clients_dep en cliquant sur la croix de son onglet,
Dans le volet des objets Access , cliquer droit sur la requête R_Clients ,
Dans le menu contextuel, choisir Mode création ,
Cette petite
requête sélection extrait tous les enregistrements de la
table Clients . Elle n'émet en effet aucune condition. Cependant, elle offre deux spécificités. Seules les informations sur la civilité, le nom et la ville sont restituées. De plus, les clients sont triés par ordre alphabétique croissant sur leur nom.
Dans le ruban contextuel Créer, cliquer sur le bouton Exécuter ,
Nous affichons ainsi le résultat de l'extraction de la requête en mode feuille de données. Les 34 enregistrements de la
table Clients sont en effet restitués. Mais ils sont bien filtrés sur les champs. De plus, les clients sont bien classés en fonction de leur nom.
Dans le ruban Accueil, cliquer sur la flèche du bouton Affichage ,
Dans la liste, choisir Mode SQL ,
Nous basculons ainsi dans l'
éditeur SQL . Cette vue permet de construire les
requêtes par le langage. Et à ce titre, nous pouvons consulter la
syntaxe SQL de notre petite requête sélection :
SELECT Clients.Client_civilite, Clients.Client_nom, Clients.Client_ville FROM Clients ORDER BY Clients.Client_nom;
Elle est écrite sur plusieurs lignes. Cependant, la syntaxe peut être ramenée sur une seule et même ligne. De plus, cette expression peut être simplifiée. Le nom de la table (Clients.) est rappelé en préfixe de chaque champ. Or, cette requête n'agit que sur une seule table.
Supprimer tous les préfixes Clients. de la syntaxe,
Vous ne devez pas oublier le point (.). La syntaxe purgée est désormais la suivante :
SELECT Client_civilite, Client_nom, Client_ville FROM Clients ORDER BY Client_nom;
Dans le ruban contextuel Créer, cliquer sur le bouton Exécuter ,
Nous retrouvons bien les 34 enregistrements filtrés et triés comme précédemment.
Dans le ruban Accueil, cliquer sur la flèche du bouton Affichage ,
Dans la liste, choisir Mode SQL ,
Tout d'abord, le
mot clé SELECT est utilisé pour annoncer les champs à sélectionner, pour la restitution des informations. Il est donc suivi des noms de champs énumérés, séparés les uns des autres par une virgule. Dans l'ordre, c'est le
mot clé FROM qui intervient ensuite. Il sert à indiquer à partir de quelle table cette extraction doit être effectuée. C'est pourquoi il est suivi du nom de la table (Clients). Puis, la
clause SQL ORDER BY permet d'ordonner un tri sur le champ, ou les champs énumérés. Ici, le tri croissant est engagé sur le
champ Client_nom . Avec l'
attribut DESC , nous ordonnons un tri décroissant.
A la fin de la syntaxe, ajouter l'attribut DESC , comme suit :
SELECT Client_civilite, Client_nom, Client_ville FROM Clients ORDER BY Client_nom DESC ;
Dans le ruban contextuel Créer, cliquer sur le bouton Exécuter ,
L'extraction fournit toujours les 34 enregistrements de la
table Clients . Mais cette fois, ils sont triés par ordre alphabétique décroissant sur le nom du client. Il est donc intéressant de constater l'impact non négligeable que peut engendrer l'ajout d'un simple attribut dans la
syntaxe SQL .
Dans le ruban Accueil, cliquer sur la flèche du bouton Affichage ,
Dans la liste, choisir Mode SQL ,
Nous souhaitons désormais plus d'informations dans la vue extraite en ajoutant la précision sur le code postal, archivé dans le
champ Client_dep . Comme nous l'avons évoqué, il suffit simplement d'intégrer le nom du champ dans l'énumération.
Ajouter le champ Client_dep après le champ Client_ville, sans oublier la virgule :
SELECT Client_civilite, Client_nom, Client_ville, Client_dep FROM Clients ORDER BY Client_nom DESC;
Enregistrer les modifications (CTRL + S),
Puis, cliquer sur le bouton Exécuter dans le ruban contextuel Créer ,
Les 34 fidèles enregistrements sont parfaitement restitués. Ils sont toujours triés de façon décroissante sur le nom grâce à la
clause ORDER BY et son
attribut DESC . Mais cette fois, ils sont accompagnés d'un niveau de détail supplémentaire sur le code postal.
Vous en conviendrez, la souplesse du
langage SQL est redoutable.
Revenir dans l'éditeur SQL de la requête,
Critères et Clause Where
Dans les précédents exercices sur les
requêtes , nous avons appris à produire des
extractions sélectives des données . Et pour cela, nous avions placé des
conditions sur des champs. Nous avions compris qu'il était possible de les combiner ou de les recouper. En
SQL , c'est la
clause WHERE qui permet de poser des critères sur des champs de la table. Cette clause doit être suivie du nom du champ et de la condition à respecter.
Pour débuter avec une démonstration triviale, nous proposons de ne sélectionner que les clientes, en excluant donc les personnes masculines. Nous avions bâti cette requête avec l'éditeur dans un exercice précédent. Cette
clause WHERE intervient nécessairement après la
clause FROM , une fois donc que la table est désignée. Mais elle intervient forcément avant la
clause ORDER BY , toujours placée en bout de syntaxe.
Adapter la syntaxe de la requête SQL comme suit :
SELECT Client_civilite, Client_nom, Client_ville, Client_dep FROM Clients WHERE Client_civilite='Madame' ORDER BY Client_nom DESC;
La condition est une égalité (=) posée sur le
champ Client_civilite . L'équivalence à respecter est spécifiée entre guillemets. Le champ est en effet typé comme un texte.
Enregistrer les modifications et cliquer sur le bouton Exécuter ,
Cette fois, seuls 16 enregistrements subsistent. Ils ont donc été filtrés conformément à la condition posée. Les hommes sont exclus de la vue extraite. Tous les autres réglages, comme le tri décroissant, restent vrais.
Revenir dans l'éditeur SQL de la requête,
Nous souhaitons affiner l'étude de manière à connaître les femmes habitant dans le département du VAR (83). Bien que le
champ Client_dep soit typé comme un texte, en raison de l'ordre logique des chiffres, nous pouvons exploiter les opérateurs numériques d'inégalité. Les deux conditions doivent être vérifiées ensemble. En
SQL , c'est l'
opérateur AND qui permet de recouper des critères.
Adapter la syntaxe de la requête SQL comme suit :
SELECT Client_civilite, Client_nom, Client_ville, Client_dep FROM Clients WHERE Client_civilite='Madame' AND Client_dep>='83000' ORDER BY Client_nom DESC;
Enregistrer les modifications et cliquer sur le bouton Exécuter ,
Le nombre d'enregistrements diminue encore. Du fait des conditions recoupées, à vérifier ensemble, ils ne sont plus que 6. La sélection est plus fine. Seules résistent les femmes habitant dans le département du VAR.
Mais, nous allons le constater, notre second critère n'est pas tout à fait correct. L'entreprise agit sur la région PACA. Le département 84 en fait partie. Dans la précédente extraction, il n'apparaît pas. Aucune femme ne semble y habiter.
Revenir dans l'éditeur SQL de la requête ,
Remplacer la valeur Madame du premier critère par Monsieur :
SELECT Client_civilite, Client_nom, Client_ville, Client_dep FROM Clients WHERE Client_civilite='Monsieur ' AND Client_dep>='83000' ORDER BY Client_nom DESC;
Puis, exécuter la requête ,
Cette fois, seuls les hommes sont extraits. La
syntaxe SQL , par fines retouches, est donc définitivement souple. Mais comme vous le remarquez, un enregistrement appartient bien au département 84, en dehors donc des bornes que nous souhaitions définir.
Revenir dans l'éditeur SQL de la requête,
Nous pourrions très bien recouper une troisième condition grâce à l'
opérateur AND comme suit :
SELECT Client_civilite, Client_nom, Client_ville, Client_dep FROM Clients WHERE Client_civilite='Monsieur' AND Client_dep>='83000' AND Client_dep<'84000' ORDER BY Client_nom DESC;
Et cette syntaxe produit bien les résultats escomptés en isolant les hommes du Var. Cependant, il est possible de simplifier la syntaxe, ce qui est toujours conseillé. Le
langage SQL propose l'
opérateur LIKE . Il est l'équivalent de l'
opérateur Comme que nous avons exploité dans les exercices précédents, pour construire des
requêtes sélection et des
requêtes paramétrées . Il peut être exploité pour isoler tous les codes postaux commençant par le nombre 83, soit le département du Var. Tous les autres seront ainsi naturellement exclus. L'expression du critère doit être concaténée avec le symbole de l'étoile (*) en suffixe. Ainsi, nous indiquons au
SQL que le début du code postal est bien 83, peu importe les chiffres qui suivent.
La première condition sur la civilité doit être conservée bien sûr. Les suivantes, sur le code postal, doivent être remplacées.
Adapter la syntaxe de la requête SQL comme suit :
SELECT Client_civilite, Client_nom, Client_ville, Client_dep FROM Clients WHERE Client_civilite='Monsieur' AND Client_dep LIKE '83*' ORDER BY Client_nom DESC;
Enregistrer les modifications et exécuter la requête,
L'enregistrement du département 84 est bien exclu et pourtant, nous avons simplifié la syntaxe de l'
expression Sql .
Revenir dans l'éditeur SQL de la requête ,
Nous proposons de poursuivre la découverte du
langage en focalisant encore notre attention sur les
critères . Nous pouvons recouper les conditions, comme nous venons de le voir, grâce au
mot clé AND . Mais nous le disions, nous pouvons aussi les combiner. Nous souhaiterions désormais offrir une vue de synthèse de tous les clients hommes habitant dans les départements du Var (83) et des Bouches du Rhône (13). Aucun code postal ne peut à la fois commencer par le nombre 83 et par le nombre 13. Certes, nous pourrions nous en sortir grâce aux opérateurs d'inégalité, en raisonnant par tranches. Mais la
syntaxe SQL s'alourdirait sensiblement.
La solution consiste donc à combiner ces conditions. Nous souhaitons extraire les hommes habitant soit dans le Var, soit dans les Bouches du Rhône. Cette formulation se traduit par l'
opérateur SQL OR .
Adapter la syntaxe de la requête SQL comme suit :
SELECT Client_civilite, Client_nom, Client_ville, Client_dep FROM Clients WHERE Client_civilite='Monsieur' AND ( Client_dep LIKE '83*' OR Client_dep LIKE '13*') ORDER BY Client_nom DESC;
Les parenthèses sont absolument nécessaires pour que le critère sur la civilité soit recoupé avec la combinaison des conditions sur le département. En d'autres termes, en l'absence de parenthèses, l'expression chercherait à extraire tous les hommes du 83 et tous les enregistrements du 13 quelle que soit la civilité.
Enregistrer les modifications et exécuter la requête,
L'extraction fournit 8 enregistrements. Il ne s'agit bien que des hommes habitant dans le Var ou dans les Bouches du Rhône.
Si vous enlevez les parenthèses dans l'
expression SQL , l'extraction conduit à 13 enregistrements. Les femmes habitant les Bouches du Rhône sont incluses.
Extraction sans doublons
Nous abordons désormais des notions qui peuvent difficilement être mises en oeuvre sans l'appui du
langage SQL .
Fermer la requête précédente en cliquant sur la croix de son onglet,
Dans le volet des objets Access, double cliquer sur la table Communes ,
Nous affichons ainsi son contenu en mode feuille de données.
Elle recense les villes de la région Paca avec les codes postaux associés. Et comme nous l'avons évoqué dans les exercices précédents, elle propose de nombreux doublons qu'il s'agira de supprimer. Nous nous y attèlerons lorsque nous maitriserons les
requêtes Action .
En SQL, c'est la
clause DISTINCT qui permet d'extraire les valeurs uniques des champs désignés. Elle intervient juste après le
mot clé SELECT et juste avant l'énumération des champs.
En haut de la fenêtre Access, cliquer sur l'onglet Créer pour activer son ruban,
Dans la section Requêtes du ruban, cliquer sur le bouton Création de requête ,
Dans la boîte de dialogue, cliquer directement sur le bouton Fermer ,
Ainsi, nous ne désignons aucune table et le
mode Sql est proposé par défaut, à gauche dans le
ruban Créer .
A gauche du ruban contextuel Créer, cliquer donc sur le bouton SQL ,
Nous revenons dans l'
éditeur Sql de
requête . Vous notez la présence du
mot clé Select initiant la syntaxe.
Bâtir l'expression SQL suivante :
SELECT DISTINCT Commune_nom FROM Communes;
Enregistrer la requête (CTRL + S) sous le nom : R_Communes_uniques ,
Puis, cliquer sur le bouton Exécuter du ruban Créer,
L'extraction fournit 807 enregistrements sur les 1003 que compte la
table Communes . Toutes les villes en double ont été éliminées. Nous commençons à mesurer l'étendue de la puissance délivrée par le
langage Sql , étant donnée la simplicité de l'expression permettant de construire un résultat aussi précieux.
Revenir dans l'éditeur Sql de la requête,
Comme vous le savez, ces villes sont associées à des codes postaux. Et plusieurs codes postaux peuvent correspondre à une même ville, pour les grandes agglomérations notamment. En considérant cette paire, une ville répétée n'est donc pas forcément un doublon.
Dans l'énumération, ajouter le champ Commune_dep :
SELECT DISTINCT Commune_nom, Commune_dep FROM Communes;
Enregistrer la requête et cliquer sur le bouton Exécuter dans le ruban Créer,
Cette fois, l'extraction conduit à 845 enregistrements. La
clause DISTINCT a donc agi sur la paire Ville et Code postal. La ville d'Aix en Provence est effectivement répétée à 5 reprises. Mais à chaque fois, elle est associée à un code postal explicitement différent.
Pour encore mieux tirer partie de cette puissance, rien n'empêche de combiner cette
clause avec celles que nous avons apprises précédemment. Par exemple, nous souhaiterions extraire les villes sans doublons pour le département du Var uniquement, triées par ordre décroissant sur les codes postaux.
Revenir dans l'éditeur Sql de la requête ,
Puis, adapter l'expression, comme suit :
SELECT DISTINCT Commune_nom, Commune_dep FROM Communes WHERE Commune_dep LIKE '83*' ORDER BY Commune_dep DESC;
Effectivement la
clause Where permet d'émettre une condition sur le
champ Commune_dep . Comme l'égalité stricte ne peut être obtenue, nous cherchons l'équivalence grâce à l'
opérateur LIKE , comme nous l'avons appris. Puis, nous exploitons la clause
ORDER BY afin d'organiser les données dans l'ordre décroissant sur les codes postaux, grâce à l'
attribut DESC .
Enregistrer la requête et cliquer sur le bouton Exécuter du ruban,
Il en résulte bien les villes uniques du Var, organisées comme nous l'avons défini. Le
langage Sql nous permet définitivement de manipuler et triturer les données comme bon nous semble et ce, avec beaucoup de facilité.
Pour des besoins statistiques ou pour le système de pagination d'un site Web, nous pourrions être tentés de n'extraire que les premiers résultats de la requête, par exemple les 10 premiers. C'est alors la
clause TOP qui doit intervenir en préfixe de l'énumération des champs. Dans notre cas spécifique en revanche, la
clause DISTINCT doit toujours être en tête juste après le SELECT.
SELECT DISTINCT TOP 10 Commune_nom, Commune_dep FROM Communes WHERE Commune_dep LIKE '83*' ORDER BY Commune_dep DESC;
Avec cette syntaxe, désormais seuls les 10 premiers résultats sont en effet extraits.
Regroupements Sql et opérations de synthèse
Dans l'exercice précédent, nous avons exploité les lignes d'opération pour produire des requêtes de synthèse. Tout est encore plus simple grâce au
langage Sql . Et nous allons nous appuyer sur la
table Produits pour le démontrer.
Fermer la requête précédente,
Dans le volet des objets Access, double cliquer sur la table Produits ,
Comme vous le constatez, elle archive 245 articles. Ils sont identifiés par leur référence, sur le
champ produit_ref de la
clé primaire . Ils sont définis sur un certain niveau de détail, décrit par les champs. L'un d'entre eux nous intéresse particulièrement. Il s'agit du
champ produit_poids . Ce poids est une donnée importante en termes de coûts de livraison à intégrer dans la facture. Et comme vous le remarquez, ces poids sont identifiés par tranches (150, 200, 250, 350g etc...).
Cliquer sur l'onglet Créer en haut de la fenêtre Access pour activer son ruban,
Dans la section Requêtes du ruban, cliquer sur le bouton Création de requête ,
Dans la boîte de dialogue, cliquer sur le bouton Fermer pour n'ajouter aucune table,
A gauche du ruban contextuel Créer, cliquer sur le bouton SQL ,
Pour des raisons statistiques, nous souhaiterions connaître la répartition des produits en vente dans ces tranches. Il s'agit donc de comptabiliser chaque produit appartenant à un niveau de poids bien précis. En
langage SQL , c'est la
fonction Count appliquée sur un champ qui permet de dénombrer ce dernier. Mais ce dénombrement doit se faire par catégorie, soit par regroupement de poids. Et c'est la
clause GROUP BY suivi du nom du champ qui permet de réaliser ce regroupement, essentiel pour le décompte catégorisé. Cette clause intervient en fin de
syntaxe Sql après la
clause FROM naturellement.
Remarque : Il est conseillé d'écrire tous les mots clés, clauses et fonctions SQL en lettres capitales. Par cette rigueur, vous produirez toujours des expressions suffisamment claires et explicites.
Créer l'expression SQL suivante :
SELECT COUNT(produit_ref) AS NB, produit_poids FROM produits GROUP BY produit_poids;
A la base, il s'agit bien d'une
requête de sélection . Nous construisons donc son ossature classique avec le
mot clé SELECT pour énumérer les champs et la
clause FROM pour désigner la table. Mais dans l'énumération des champs, nous engageons un calcul. La
fonction SQL COUNT est appliquée sur le
champ produit_ref . Il s'agit en effet du champ de la clé primaire, n'offrant que des valeurs uniques, propices aux décomptes. A la volée, nous restitutions le résultat de l'opération dans un nouveau champ que nous nommons arbitrairement NB. C'est le
mot clé AS , intervenant nécessairement après le calcul, qui permet cette création dynamique. Puis, nous souhaitons restituer l'information sur le poids. Et à la toute fin de la syntaxe, précisément sur ce poids, nous effectuons un regroupement grâce à la
clause GROUP BY . En conséquence, le décompte opéré par la
fonction COUNT doit être réalisé sur ces groupes.
Enregistrer la requête (CTRL + S) sous le nom : R_nb_poids ,
Puis, cliquer sur le bouton Exécuter du ruban Créer,
Comme vous le remarquez, sur la base de la
table Produits comptant pourtant 245 enregistrements, nous obtenons une vue on ne peut plus synthétisée. L'extraction fournit 17 lignes. Et chacune comptabilise bien le nombre d'articles appartenant à la catégorie de poids, définie par le niveau de regroupement.
Ces opérations de synthèse sont précieuses pour l'entreprise désireuse de maîtriser ses stocks, ses livraisons et ses produits. Nous constatons que les produits pesant 350 grammes seront vraisemblablement les plus nombreux. Mais soyons prudents. D'autres paramètres sont à considérer, comme la popularité des produits. Et justement, la table Produits donne cette information avec le
champ produit_vues . Ces scores correspondent aux nombres de visites engrangées par chaque article sur sa fiche.
Pour recouper ou infirmer la synthèse précédente, nous souhaiterions désormais réaliser la somme de ces visites, par catégories de poids. Au même titre que la
fonction COUNT ,
SQL propose la
fonction AVERAGE pour la moyenne et
SUM pour la somme. Il ne nous reste qu'Ã adapter la syntaxe.
Revenir dans l'éditeur SQL de la requête,
Adapter la syntaxe de l'expression SQL comme suit :
SELECT SUM(produit_vues) AS Total , produit_poids FROM produits GROUP BY produit_poids;
Nous remplaçons donc la
fonction SQL COUNT par la
fonction SUM . Bien sûr, nous adaptons le champ produit_vues sur lequel nous l'appliquons. Nous en profitons pour renommer explicitement le champ de réception (Total).
Enregistrer la requête et cliquer sur le bouton Exécuter ,
L'extraction conduit naturellement au même nombre d'enregistrements. Les regroupements sont en effet strictement identiques. L'
opération de synthèse quant à elle, est bien différente. Nous confirmons ce que nous pressentions avec la requête précédente. Les colis à 350 grammes risquent d'être les plus fréquents. Ils représentent à la fois le plus grand nombre d'articles et la plus importante popularité cumulée. Cependant les colis à 900 grammes surgissent non loin derrière. Pourtant, avec la précédente
requête , ils ne sortaient pas du lot. Le poids est beaucoup plus important. Cette information est donc précieuse à considérer en termes de frais de livraison potentiels.
Requêtes SQL paramétrées
Dans un précédent exercice, nous avons appris à créer des
requêtes paramétrées . Leur intérêt est de déclencher des critères dynamiques, définis par l'utilisateur, seulement au moment de l'exécution. Il s'agit d'un très bon moyen, avec une seule requête, de retrouver rapidement un client par son nom par exemple ou encore un article par sa référence. L'astuce avait consisté à leurrer
Access en inscrivant un nom de champ non reconnu dans la zone de critères. De fait, à l'exécution,
Access demande précision. L'utilisateur n'a plus qu'à saisir la valeur souhaitée. En
SQL , le principe est strictement identique.
Fermer la précédente requête,
Puis, créer une nouvelle requête vierge en mode SQL ,
Dans l'éditeur, taper l'expression SQL suivante :
SELECT * FROM Clients WHERE Client_nom = [Quel nom ?]
Souvenez-vous, le symbole de l'étoile permet de remplacer l'énumération de tous les champs. Il les désigne tous.
Enregistrer la requête sous le nom : R_Quel_Client_SQL ,
Puis, cliquer sur le bouton Exécuter dans le ruban contextuel Créer,
Le paramètre
Quel nom n'est pas reconnu comme un champ existant. De fait, la fameuse boîte de dialogue se déclenche.
Access vous invite à préciser la valeur du critère sur ce
champ Client_nom . Si vous tapez un nom de client existant, la
requête SQL paramétrée restitue toutes les informations qui le concernent. A l'occasion d'une nouvelle exécution, avec un autre nom, elle restitue d'autres résultats. Ces requêtes sont définitivement précieuses pour répondre rapidement à un besoin précis à l'instant T.
Comme nous l'avons dit, tout ce que nous avons appris précédemment reste vrai. Pour profiter de la pleine puissance du
SQL , il est intéressant de combiner les techniques.
SELECT * FROM Clients WHERE Client_dep LIKE [Quel Ddépartement ?] & '*' ORDER BY Client_nom;
Cette
requête permet d'extraire tous les clients triés croissant, d'un département défini par l'utilisateur au moment de l'exécution.
SELECT COUNT(Client_id) AS NB, Client_dep FROM Clients WHERE Client_dep Like [Quel dep ?] & '*' GROUP BY Client_dep;
Cette
requête devrait permettre de compter le nombre de clients dans le département défini dynamiquement. Mais le
champ Client_dep renferme des codes postaux. A défaut donc, elle livre pour le département désigné, le nombre de personnes possédant le même code postal.
Nous comprenons néanmoins la puissance et l'intérêt dans des contextes adaptés.
Requête équijointure
Dans un précédent exercice, nous avions démontré l'intérêt majeur d'une
requête équijointure . Par correspondance entre deux champs respectifs de deux tables, elle permet d'extraire tous les enregistrements pour lesquels le lien est avéré. Dans le
champ produit_code de la
table Produits , certains codes de remise sont renseignés, mais pas pour tous les articles. Ces codes sont issus de la table Remises. Cette requête avait permis d'extraire uniquement les articles en promotion. Nous avions bâti cette équijointure visuelle, grâce à l'éditeur de
requête Access . Mais c'est encore plus simple avec le
langage SQL .
Fermer la précédente requête,
Puis, créer une nouvelle requête vierge en mode SQL ,
Taper l'expression SQL suivante :
SELECT * FROM produits, Remises WHERE produit_code=Remises.Remise_id;
Il s'agit d'une
requête multitable . De fait, nous les énumérons dans la
clause FROM . La correspondance est établie par la
clause WHERE sur l'égalité des deux champs. Comme ils n'appartiennent pas à la même table, il est nécessaire et préférable de les préfixer du nom de leur table respective.
Enregistrer cette requête sous le nom : R_Articles_Promos ,
Puis, cliquer sur le bouton Exécuter du ruban Créer,
Nous l'avions constaté, seuls deux articles sont en promotion pour l'instant. Mais si ces promotions venaient à évoluer, cela va de soi, cette requête livrerait de tout autres résultats et nous le constaterons bientôt.
Nous pourrions décliner ce procédé pour recenser dans la
table Communes , toutes les villes dans lesquelles habitent les clients de la table Clients :
SELECT Commune_nom, commune_dep FROM Communes, Clients WHERE Commune_dep=Client_dep AND Client_dep LIKE '83*';
Dans cet exemple, nous filtrons les résultats sur les communes du Var. Comme vous le remarquez, nous n'avons pas pris soin de préfixer les noms des champs du nom de leur table. Ici, cette largesse est autorisée car nous avons pris soin de nommer explicitement et différemment tous les champs en conception de table. Mais gardez présent à l'esprit, qu'il est préférable de la faire.