J’ai plusieurs véhicules dont je relève le compteur à chaque plein. [Id] est un numéro auto dont je ne peux évidemment pas me servir pour retrouver le plein « précédent ».
Dans une table de base de données, les lignes sont un peu comme des billes mélangées dans un sac et retrouver la ligne « précédente » dans ces conditions n’a pas de sens.

Et pourtant il faudrait obtenir :

Sauriez-vous trouver le jeu de requête/sous-requête pour obtenir le résultat ci-dessus ?
Uniquement avec les assistants, bien sûr ! QBEO*
*Query By Example Only

On commence par une requête intermédiaire R_DatePrecedente.

Celle-ci nécessite une auto-jointure sur la table [Journal]. Dans l’assistant il faut ajouter une deuxième fois la table Journal qui prendra automatiquement l’alias [journal_1].
Pour chaque plein d’un véhicule, on recherche les dates des pleins précédents et on retient la date du plein le plus récent (avec Max(Journal_1.DatePlein)).

La requête R_final reprend la requête précédente comme sous-requête :

Dans le QBE d’Access, après avoir opéré le regroupement, on sélectionne l’opération Compte avec le champ de la table concerné.
Par exemple, si on souhaite connaître le nombre de commandes par client :

dont la traduction en SQL, nous donne l’opération :
…Count(Commandes.[N° commande]) AS [CompteDeN° commande]

Or on peut lire dans l’aide Access:

Count(*) s’exécute beaucoup plus rapidement que Count([nom_de_colonne])

Ce qui fait que l’on devrait plutôt utiliser le caractère générique *, et écrire quelque chose de normalement plus performant avec:

Soit en SQL,:
…Count(*) AS [CompteDeN° commande]

Notre requête présente toutefois l’inconvénient de ne pas présenter les clients qui n’ont jamais commandé. Pour tenter d’y remédier, on modifie dans un premier temps la requête avec une jointure externe LEFT (type « 2 » dans le QBE) :

qui retourne un résultat faux avec un nombre de commandes égal à 1 pour les clients qui n’ont jamais commandé. Cela est logique puisque le but de la jointure LEFT est justement de retourner au moins un enregistrement par client.

Pour s’en sortir il suffit de consulter l’aide à nouveau :

La fonction Count(expr) ne compte pas les enregistrements possédant des champs Null sauf si l’argument expr est remplacé par le caractère générique astérisque (*)

Si on écrit, la requête :

La requête retourne, pour les clients qui n’ont jamais commandé, un enregistrement avec [N° commande]=Null.

Il suffit de regrouper par client et de compter le nombre de champ [N° Commande] non à Null.

Il faut donc utiliser dans ce cas précis count([N°Commande]) et non count(*):

Conclusion :

Je reprends l’aide Access:

La fonction Count(expr) ne compte pas les enregistrements possédant des champs Null sauf si l’argument expr est remplacé par le caractère générique astérisque (*). Si vous utilisez un astérisque, la fonction Count calcule le nombre total des enregistrements, y compris ceux qui contiennent des champs Null.
Count(*) s’exécute beaucoup plus rapidement que Count([nom_de_colonne]).

En fonction des scores des rencontres, on souhaite une requête qui renverrait pour chaque équipe les nombres de victoires, nuls et défaites à domicile.

1ère solution: avec des sous-requêtes corrélées,

2ème solution: sans sous-requêtes, dans une requête qui regroupe les rencontres à domicile de chaque équipe,

…SUM(Iif(scoreequipedomicile > scoreequipeext, 1, 0)) AS gagne, …
En cas de victoire à domicile, l’expression Iif retourne 1 et 0 sinon. Puis on somme les victoires.
Même principe pour les nuls et défaites.

Et vous, quelle solution vous préférez, 1 ou 2 ?

1ère solution : avec une requête UNION

2ème solution: avec un champ calculé placé dans la clause ORDER BY

On veut pour l’année 2011 la liste de tous les adhérents avec le montant de la cotisation ou la mention « pas de cotisation » s’ils n’ont pas cotisé en 2011.


Évidemment la 1ère tentative avec la jointure naturelle par défaut ne convient pas :

PERDU !

On pense à faire une jointure externe de type « 2 ».
Une nouvelle tentative :

Si on complète avec le critère de restriction sur l’année 2011 :

PERDU !!

Comme le décrit Cinephil dans son blog:

Quand on fait une jointure externe à gauche et qu’on pose une restriction (dans le WHERE) sur la table de droite, c’est comme si on faisait une jointure interne !

La solution, toujours proposée par CinePhil :

… il faut déplacer les conditions de restriction sur la table externe du WHERE vers la condition de jointure.

Comme la modification qui suit n’est pas interprétable dans le QBE d’Access, j’édite la requête précédente en mode SQL…

… et je la modifie en déplaçant le critère WHERE dans la condition de jointure ON (attention aux parenthèses):

GAGNÉ !!

voici pourtant ce qu’on peut lire dans le livre : Access 2007 et VBA (paru en 03/2008)
par Bernard Minot, Jean-Michel Léry

dont l’extrait ci-dessous est disponible chez Google books à la page 42:

Les relations de 1 à 1
Nous supposons la présence de deux tables contenant des données relatives, par exemple, à vos contacts professionnels, d’une part, et à vos contacts personnels, d’autre part. La conjugaison de ces deux tables peut se décliner ainsi :
– Un contact professionnel correspond soit à zéro, soit à un et au plus un contact personnel (un partenaire commercial peut aussi être un ami !) ;
– Un contact personnel correspond soit à zéro, soit à un et au plus un contact personnel (même raison).
Nous sommes ici devant une relation de un à un. A priori, et pourvu que les uns et les autres n’aient pas de rôle particulier à jouer dans le système d’information à mettre en place, il n’y a aucune raison pour ne pas fusionner purement et simplement les deux fichiers. La seule opération à mettre en place avant ladite fusion consiste à créer une propriété particulière à la table qui fusionne les deux fichiers pour distinguer les « commerciaux » des « amis personnels ». Cet exemple peut être généralisé : les relations de un à un dans une base bien conçue n’existent pas(1).

(1). Seul cas de figure possible : si la table doit compter plus de 255 colonnes, il sera nécessaire de créer une table « fille ».

grrrmffff…

Rideau…


Je développe un peu quand même en prenant un exemple pratique avec la requête suivante (qui change un peu du traditionnel schéma : Client-1—–∞-Commande):

On recherche les élèves qui ont exprimé au moins une fois le souhait de suivre le module n°7 dans leurs trois premiers vœux. Parmi ces élèves on ne retiendra que ceux qui n’ont jamais pu obtenir d’affectation sur ce module.

La requête retourne 59 lignes en tout :

Les doublons s’expliquent ici car lors des différentes rotations (NumRotation=1,2,…), certains élèves peuvent redemander ce module n°7 tant qu’ils n’ont pu l’obtenir (par manque de place car la demande est forte sur ce module !).

1ère tentative d’élimination des doublons :

Une bonne vielle clause DISTINCT :

Vous pouvez utiliser la propriété UniqueValues lorsque vous souhaitez écarter les enregistrements qui contiennent des données en double dans les champs affichés en mode Feuille de données. Par exemple, si le résultat d’une requête inclut plusieurs champs, la combinaison des valeurs de tous les champs doit être unique pour un enregistrement donné à inclure dans les résultats.

Au niveau SQL :
SELECT DISTINCT Eleve.idEleve, Eleve.NomEleve, Eleve.PrenomEleve FROM …

La requête ne retourne plus que 41 enregistrements sans doublon.

En clair, l’opérateur DISTINCT agit donc en omettant les doublons sur la combinaison des colonnes affichées (ici le triplet{idEleve,NomEleve,PrenomEleve} ).

2ème tentative d’élimination des doublons :

Vous pouvez utiliser la propriété UniqueRecords lorsque vous souhaitez omettre les données basées sur des enregistrements en double entiers, pas uniquement des champs en double. Microsoft Access considère qu’un enregistrement est unique pour autant que la valeur d’un champ dans l’enregistrement diffère de la valeur du même champ dans un autre enregistrement.

Au niveau SQL :
SELECT DISTINCTROW Eleve.idEleve, Eleve.NomEleve, Eleve.PrenomEleve FROM …

Notez que nous sommes dans le cadre d’utilisation normale de la clause DISTINCTROW :

DISTINCTROW n’a d’effet que si vous sélectionnez des champs pour certaines tables utilisées dans la requête, mais pas toutes. DISTINCTROW est ignorée si votre requête n’inclut qu’une seule table, ou si vous produisez des champs à partir de toutes les tables.

La requête omettant les données basées sur des enregistrements en double de la table Eleve (et pas seulement les doublons sur les seules colonnes affichées), celle-ci retournera …les mêmes lignes qu’avec la clause DISTINCT, rigoureusement…

Conclusion :

La différence entre DISTINCT et DISTINCTROW est donc subtile et a de quoi embrouiller le développeur qui dans ce cas particulier a déjà deux solutions pour obtenir le même résultat :
SELECT DISTINCT Eleve.idEleve, Eleve.NomEleve, Eleve.PrenomEleve FROM …
ou bien,
SELECT DISTINCTROW Eleve.idEleve, Eleve.NomEleve, Eleve.PrenomEleve FROM …

L’écart entre les durées moyennes d’exécution des deux requêtes avec DISTINCT et DISTINCTROW est négligeable sur mon jeu de données. Rien à attendre sur les performances en faveur de l’un ou l’autre a priori.

Le connaisseur pourra quand même rétorquer que le DISTINCTROW agissant au niveau de l’enregistrement, la requête devient « updatable » (eupedatabeul, miseàjourable) contrairement à celle avec DISTINCT.

Au fait, DISTINCTROW est spécifique à Access et ne fait pas partie de la norme SQL. Comment faire avec du SQL standard ?

On peut se contenter de DISTINCT ou bien on emploie l’opérateur EXISTS :

Certes, on sort des assistants pour rédiger cette requête…

…mais le temps d’exécution de la requête avec EXISTS me semble bien meilleur et les données peuvent aussi être mises à jour…

Si vous avez un retour d’expérience avec DISTINCTROW, n’hésitez pas à en faire profiter ici…

(*) Q.B.E.O : Query By Example Only (0% SQL) -<8-) mouarf

Proposition de corrigé en page 3

Comme chacun sait, la base de données du forum Dvp est gérée sous Access ;-).

Afin également de réviser le fonctionnement du forum, on va s’intéresser ici au calcul des points de chacun des membres.
Voir : [Nouveauté] Nouveau système de rangs basé sur des points

Nous avons donc des membres,

qui ouvrent des discussions, chaque discussion comportant des messages rédigés par des membres.

Grâce au récent système de votes, chaque message peut comporter des votes positifs et négatifs :

Le champ [Vote] prendra les valeurs +1 ou -1, l’application prendra soin de vérifier qu’un membre ne puisse voter pour ses propres messages. Un membre ne peut voter pour un même message qu’une seule fois.

Les discussions qui ont le tag [Résolu] sont dans la table [TagRésolu] avec le membre qui a posé le tag:

La discussion est généralement taguée [Résolu] par son auteur (celui qui a posté le 1er message de la discussion) mais elle peut l’être par un autre membre ayant les droits requis (modérateur,…) qui récupèrera alors le point.

Voir le message ici:

… Désormais le forum « mémorise » qui utilise le bouton [Résolu] et donc, désormais, si c’est un modérateur qui utilise le bouton sur votre discussion à votre place, c’est le modérateur qui sera crédité d’1 point et non plus vous !

La requête au final doit retourner le total de points de chaque membre du forum (sans arrondi):

Le mode de calcul sera le suivant (allégé par rapport au système réel sur Dvp, pas de note sur les discussions, pas de point pour les articles ou les billets blogs…):
[Nouveauté] Nouveau système de rangs basé sur des points

0 point par discussion créée
0 point par réponse dans votre propre discussion
1 point par réponse dans une discussion qui n’est pas la vôtre
1 point par discussion marquée résolue
1 point par vote positif reçu sur un de vos messages
-1 point par vote négatif reçu sur un de vos messages
0,1 point par vote message envoyé

On considèrera que le créateur de la discussion est le membre qui a rédigé le 1er message (celui avec le champ [NumeroOrdre]=1).

A vous de jouer… Lien vers Exercice2.mdb

Note : l’usage de la fonction Nz est autorisé

Nz(Expression ; ValeurSiNull)

Ex : Nz([UnChamp] ; 0)
Si [UnChamp] est Null, la fonction Nz renvoie le nombre zéro

Proposition de corrigé

Voici les « vues » intermédiaires dont nous avons besoin.

1 point par discussion marquée résolue
0,1 point par vote message envoyé

1 point par vote positif reçu sur un de vos messages
-1 point par vote négatif reçu sur un de vos messages

0 point par discussion créée
0 point par réponse dans votre propre discussion
1 point par réponse dans une discussion qui n’est pas la vôtre

On commence par sélectionner le membre créateur de chaque discussion ouverte :

Pour chaque discussion, on élimine tous les messages rédigés par son créateur (idMembreOuverture Est Null). Puis on compte les messages restants regroupés par membre et qui rapportent des points à leurs auteurs.

Et enfin, on additionne tous ces points :

Seules les solutions obtenues avec l’assistant QBE (Query By Example) d’Access seront retenues.

Exercice 1 :

Il s’agit donc des interventions de membres sur des forums (liste des interventions arrêtée à l’année 2010).
La requête R_final doit retourner le nombre de forums dans lesquels sont intervenus chacun des membres en 2010.

Pour corser l’affaire, nous excluons les membres qui ne sont jamais intervenus (cas du membre n°6 inactif) et ceux dont l’année de la dernière intervention date d’avant 2009 (cas du membre n°4 dont la dernière intervention date de 2008).

Je mets un lien vers la base de départ : Exercice1.zip

Proposition de corrigé

Il faut donc passer par quelques « vues » intermédiaires.

1ère étape : déterminer les membres « actifs » (ceux qui ont au moins une intervention depuis 2009)
On commence par sélectionner les membres qui n’ont pas d’intervention ou dont la date de dernière intervention remonte avant 2009.

On peut maintenant obtenir les membres « actifs » (requête de non-correspondance):

2ème étape : déterminer les forums où sont intervenus les membres au cours de l’année 2010
On sélectionne les couples {membre, forum} sur les interventions de l’année 2010. Comme un membre peut intervenir plusieurs fois dans le même forum, on ne retient que les couples {membre, forum} distincts.

Dernière étape : le comptage des forums parmi les membres actifs
La requête R_Final compte le nombre souhaité de forums :

N’hésitez pas à laisser vos commentaires…

Prenons un exemple avec le schéma des relations :

Étant donné un découpage de la région en territoires comportant des adresses.
Les territoires sont attribués à des colporteurs et dans le cadre de leurs attributions, ceux-ci effectuent des visites.

Les contraintes à vérifier ici sont les suivantes :

C1) Une visite effectuée dans le cadre d’une attribution doit être réalisée parmi les adresses faisant partie des adresses du territoire attribué
C2) On ne rend pas visite à une adresse si la seule personne qui y habite est un colporteur.

La contrainte à programmer est donc sur le couple {idAttribution, idAdresse} de la table Visite.

Une première tentative…

La seule contrainte C1 peut être assurée grâce au jeu de l’intégrité référentielle en modifiant le schéma (adresses et attributions identifiées relativement au territoire):

Pas forcément simple à gérer au niveau de l’IHM et il reste encore la contrainte C2 à programmer.

2ème tentative avec une macro de données :

Enregistrons une première requête,

qui retourne les couples (adresse, attribution) possibles. J’ai retiré les occurrences où l’adresse est celle d’un colporteur (critère PersonneQuiEstColporteur.idPersonne Est Null).

Sur l’évènement « Avant Modification » de la table Visite, on écrit la macro commentée suivante:

On teste…

Soit l’adresse n°4 ne fait pas partie du territoire de l’attribution n°3, soit elle en fait éventuellement partie mais c’est un colporteur qui est enregistré à cette adresse.

CQFD : l’action de donnée « DéclencherErreur » invalide la saisie/modification de la visite n°12 dans la table.