Vérifier la phrase de conclusion

Tu as corrigé une requête, mais la phrase placée dessous décrit encore une ancienne version. Le SQL s'exécute ; le fichier raconte pourtant deux choses.

Cette fiche travaille l'interprétation en BC02 et la restitution en BC04.

1. Ce que la base vérifie, et ce qu'elle ne vérifie pas

PostgreSQL contrôle la requête. Il refuse une colonne qui n'existe pas ou une parenthèse manquante. Il ne contrôle pas le commentaire écrit à côté.

Ce texte est pourtant ce que ton lecteur lit en premier. Souvent il ne lit que lui. C'est sur cette phrase qu'une décision se prend dans l'entreprise. La requête est le moyen. La phrase est le livrable.

2. Trois façons dont la phrase se détache du résultat

Commence par cet exemple Olist, qui ne répond à aucune question évaluée du TP :

SELECT seller_state AS etat, COUNT(*) AS vendeurs
FROM sellers
GROUP BY seller_state
ORDER BY vendeurs DESC
LIMIT 3;

Le résultat commence par SP | 1849, PR | 349, MG | 244. Une conclusion dit : « SP compte 1 849 produits ». Repère l'erreur avant de lire la suite. Le nombre est bien recopié, mais l'objet compté est faux : une ligne de sellers représente un vendeur.

La conclusion écrite pour une version précédente de la requête

Ce cas apparaît au moment où tu corriges ton travail.

Le scénario : ta requête donne un nombre d'emprunts rendus. Tu ajoutes ensuite un filtre sur la période et relances. La conclusion, trois lignes plus bas, porte encore le total de toute la période.

La méthode annoncée dans le commentaire, une autre dans la requête

Ce cas apparaît quand tu essaies plusieurs versions.

Tu écris en commentaire : « je compte les retours enregistrés en 2024 ». Mais le fichier que tu commites filtre la date d'emprunt, pas la date de retour.

Le fichier est alors incohérent : le commentaire dit A, la requête fait B, le résultat collé est celui de A. Chaque élément a l'air de répondre aux autres.

Le contrôle : relance ton fichier en entier et compare le résultat obtenu à celui que tu as collé.

La phrase qui ajoute ce que la requête n'a pas calculé

Ta requête compte les emprunts sans date de retour. Tu écris « ces ouvrages sont perdus ». La cause ne vient pas de la base : une date absente peut aussi venir d'un retour non saisi.

La même chose arrive avec « la majorité », « en forte hausse », « les clients préfèrent ». Chacune de ces expressions est une affirmation. Chacune demande un calcul, que tu n'as peut-être pas fait.

3. Le contrôle, en trois questions

Avant de commiter un fichier, pose ces trois questions à chaque phrase de conclusion, dans cet ordre.

Ce nombre est-il dans le résultat collé juste au-dessus ? Pas « est-ce que je l'ai calculé un jour ». Est-ce que je le vois, maintenant, dans la sortie collée. Sinon, retrouve sa source : calcul secondaire, dictionnaire de données, ancienne version ou ajout sans preuve.

La requête au-dessus fait-elle ce que ma phrase décrit ? Lis les deux côte à côte, en oubliant ce que tu voulais faire. Tu relis ton texte en sachant ce que tu as voulu dire. Tu ne vois donc plus ce qu'il dit.

Qu'est-ce que ma phrase affirme que la requête ne calcule pas ? Une unité, une devise, un « la plupart », une cause. Un nombre ou « la plupart » se vérifie par le calcul. Une unité ou une devise se vérifie dans le dictionnaire de données. Une cause demande une autre preuve. Cite la source ou retire seulement ce qui ne peut pas être établi.

4. Écrire la conclusion avec le nombre dedans

Écris ta conclusion au présent, avec le nombre dedans. Pas sous forme de règle générale.

Compare ces deux phrases :

• « Si le nombre total dépasse le nombre d'identifiants distincts, des identifiants se répètent. »
• « Le résultat exécuté compte N lignes et M identifiants distincts, soit N - M lignes supplémentaires. »

La première est vraie quoi qu'il arrive. Elle reste vraie si tu n'as jamais lancé la requête, ou si la requête est fausse. Elle ne dit rien de tes données.

La seconde doit être complétée avec les résultats exécutés. Elle devient fausse dès qu'ils changent, donc l'écart se verra à la prochaine exécution.

Une conclusion qui ne peut pas devenir fausse ne prouve rien.

5. Vérifier sur ton propre fichier

Choisis une conclusion de ton analyse. Souligne la population, la période et le nombre. Relie chacun à la clause SQL qui le produit, puis demande à une autre personne de relancer le fichier et de retrouver la même phrase.

La fiche Vérifier le résultat d'une requête traite des requêtes qui tournent et répondent à côté. Ici, la requête est bonne. Le texte écrit à côté ne l'est pas, et aucun message d'erreur ne te prévient.