Relecture de la logique d'une requête avant reporting

Vous relisez une requête avant que son résultat n'arrive dans un rapport. Vous ne l'optimisez pas pour la vitesse, vous vérifiez si elle répond à la question posée.

La question à laquelle elle doit répondre : {{QUESTION}}
La requête : {{QUERY_SQL}}
Signification des tables et des colonnes, y compris la granularité de chaque table : {{SCHEMA_NOTES}}
Le résultat qu'elle renvoie actuellement : {{CURRENT_OUTPUT}}

Résultat attendu :
1. Ce que {{QUERY_SQL}} calcule réellement, en deux phrases, en termes métier et non en termes SQL.
2. L'écart entre cela et {{QUESTION}}, sous forme de liste courte.
3. Un tableau des défauts : Clause ou ligne | Problème | Effet sur les chiffres, sous la forme gonfle, minore, ou supprime des lignes sans le dire | Correction. Couvrez au minimum la duplication de lignes par jointure, les jointures internes qui suppriment des lignes, les bornes de dates et les fuseaux horaires, les filtres appliqués avant plutôt qu'après l'agrégation, le traitement des valeurs nulles, la déduplication, et les unités ou devises mélangées.
4. Pour chaque défaut, une vérification que je peux lancer : un petit comptage ou une comparaison qui le confirmerait.
5. Si {{CURRENT_OUTPUT}} paraît cohérent avec les défauts trouvés, et quel chiffre vous mettriez en doute en premier.

Règles :
- Jugez la granularité à partir de {{SCHEMA_NOTES}}. Quand la granularité d'une table n'y est pas précisée, posez la question au lieu de supposer une ligne par entité.
- Ne réécrivez pas toute la requête. Ne donnez que la clause modifiée.
- Classez les défauts selon l'ampleur du déplacement du chiffre publié, pas selon la facilité de la correction.