Capstone : trouver les six mauvaises requêtes

L'audit de synthèse

Le projet expédie dix requêtes dans queries/audit-lab/, nommées q01.sql jusqu'à q10.sql. Chacun fonctionne sans erreur et renvoie une réponse claire, et chacun porte sa question commerciale dans un commentaire en haut. Exactement six des dix sont faux. Les quatre autres sont corrects, et cela compte tout autant : quelqu'un qui signale les dix a appris la suspicion, pas l'audit. Une partie de la compétence consiste à laisser une requête correcte seule.

Pour chaque requête, donnez un verdict : correct ou faux. Si c'est faux, nommez la classe d'échec, écrivez une requête corrigée, enregistrez à la fois le mauvais numéro et le bon, et notez la ligne représentée avant et après votre correctif.

Un avertissement. docs/known-defects.md décrit ce qui ne va pas délibérément avec les données, ce qui est une question différente de ce qui ne va pas avec ces requêtes. Le lire en espérant des verdicts vous induira en erreur. Le corrigé se trouve au bas de cette page, délibérément pas dans le référentiel, vous ne pouvez donc pas l'ouvrir par accident avant d'avoir des verdicts.

Les classes d'échec

Chaque mauvaise requête échoue d'une manière identifiable, et chacune de ces six requêtes apparaît exactement une fois :

Un fan-out de jointure qui gonfle une mesure d'en-tête de commande.
Un filtre != ou IN qui supprime silencieusement NULL order_status.
La mauvaise colonne de revenus, unit_price où il s'agissait de net_price.
Un BETWEEN sur une colonne d'horodatage qui laisse tomber le dernier jour.
Un INNER JOIN vers une dimension qui supprime les lignes avec des clés orphelines.
Un DISTINCT qui masque une ligne de dimension dupliquée.

Votre tâche

Exécutez chaque requête, puis parcourez la liste de contrôle en sept points de « Audit ce qu'elle a écrit » dessus. Copiez queries/audit-lab/findings-template.md dans queries/audit-lab/findings.md et écrivez une section par requête : le verdict, la classe d'échec si elle est incorrecte, la requête corrigée, les deux nombres et quelle ligne représentait avant et après votre correctif. Ne modifiez pas les fichiers de requête eux-mêmes.

Rubrique

Notez-vous sur 10. Dix sur dix signifie que la pierre angulaire répond aux exigences du cours.

Zone	Points	Preuve
Verdicts corrects	3	Les dix classés correctement, y compris les quatre qui ont raison
Dénomination des échecs	2	Chaque requête erronée étiquetée avec la classe d'échec qui s'applique réellement
Requêtes corrigées	2	Chaque correctif s'exécute et renvoie le bon numéro
Les deux chiffres indiqués	1	Mauvais numéro et bon numéro enregistrés pour chaque constatation
Qualité du raisonnement	1	Chaque résultat indique ce qu'une ligne représentait avant et après le correctif
Pas de faux positifs	1	Les quatre requêtes correctes ne sont pas "corrigées"

Extensions facultatives

Terminez la moitié client de la question vertébrale : auditez la jointure à customers qui identifie les clients qui ont généré la croissance dans les catégories gagnantes, en utilisant ce que q09 vous a appris à vérifier.
Demandez à l'agent d'auditer les dix mêmes requêtes, puis comparez ses résultats aux vôtres. Là où vous n’étiez pas d’accord, qui avait raison ?
Rédigez un contrôle de qualité Bruin qui aurait détecté automatiquement l'un des six.
Ajoutez l'échec que vous avez trouvé le plus difficile à AGENTS.md, puis voyez si l'agent l'évite la prochaine fois.

Vérifiez votre compréhension

Combien des dix requêtes sont fausses ?
Pourquoi les quatre bonnes requêtes sont-elles aussi importantes que les six mauvaises ?
Nommez trois des six classes d'échec.

Faites-le avec votre agent

Dites next lesson et votre agent vous apprend cela, vous pose ces questions, puis définit la tâche ci-dessus. Faites-le à la main, puis dites review my work - il vérifie votre travail par rapport à une rubrique et vous indique ce qu'il faut corriger ou marque la leçon terminée.

Spoilers pour tout le laboratoire. Engagez-vous à rendre un verdict sur les dix requêtes dans findings.md avant de poursuivre la lecture.

Corrigé

Les six requêtes erronées sont q02, q04, q05, q07, q08, q09. Les quatre bons sont q01, q03, q06 et q10. Chaque classe de défaillance apparaît exactement une fois et toutes les valeurs sont exactes, car les données sont générées de manière identique sur chaque machine.

Requête	Verdict	Comme écrit	Corriger	Pourquoi
q01	correct	1 200	1 200	`COUNT(*)` simple sur une table ; rien à déployer.
q02	faux	Londres 261 246,42	Londres 102 911,39	`order_total` est l'en-tête de commande ; la jointure à `order_items` répète chaque commande par ligne. Somme de `orders` seul.
q03	correct	Paris 190	Paris 190	Rejoindre `stores` ajoute uniquement un nom de ville ; grain inchangé.
q04	faux	1 069	1 093	`!= 'cancelled'` supprime 24 commandes au statut NULL. Utilisez `IS DISTINCT FROM`.
q05	faux	381 357,00	338 209,56	`unit_price` est le prix catalogue ; le chiffre d'affaires est `quantity * net_price`.
q06	correct	503.39	503.39	`AVG(order_total)` sur `orders` seul ; bon dénominateur.
q07	faux	478	480	`ordered_at` est un horodatage ; `BETWEEN ... AND '2024-12-31'` s'arrête à minuit et abandonne deux commandes plus tard. Utilisez une cuisinière semi-ouverte.
q08	faux	847 979,80 répartis en 8 catégories	851 617,69 TTC Seau inconnu	15 lignes pointent vers un `product_id` pas dans `products` ; l'INNER JOIN les laisse tomber ainsi que 3 637,89.
q09	faux	1 411,16	1 310,60	Dix lignes dupliquées dans `customers` répètent ces ordres dans la jointure ; `COUNT(DISTINCT customer_id)` reste correct, c'est pourquoi il semble sûr.
q10	correct	2.4	2.4	Lignes divisées par des commandes distinctes, toutes deux de `order_items` à leur propre grain.

Le facteur de répartition est exactement de 2,4 pour l'ensemble de la table, mais varie d'environ 2,31 à 2,54 par magasin, car les commandes avec plus de lignes ne sont pas réparties uniformément, donc un ratio par magasin proche mais pas exactement de 2,4 est correct, ce n'est pas une erreur arithmétique.

Capstone : trouver les six mauvaises requêtes

Sign up to our newsletter