Imaginez une situation pédagogique : vous voulez identifier les étudiants qui n'ont pas encore rendu leur devoir, et vous demandez à une IA d'écrire une requête SQL. Le programme s'exécute sans problème et une liste bien ordonnée apparaît à l'écran.
Aucune erreur, les noms de colonnes correspondent. Vous vous apprêtez à envoyer un rappel, quand vous remarquez qu'un étudiant qui n'a aucun enregistrement de rendu n'apparaît pas dans le résultat.
Le problème se cache peut-être dans le type de jointure. La requête ne conserve que les enregistrements correspondants des deux tables ; celui qui « n'a pas encore d'enregistrement » a été exclu dès le départ.
Ce type d'erreur est discret. La base de données a exécuté l'opération que vous avez écrite ; ce qu'il faut vraiment vérifier, c'est si cette opération exprime bien ce que vous vouliez dire.
Le cours DSAI2202 « Database Principles » (Principes des bases de données) de l'Université polytechnique de Hong Kong aborde la modélisation des données, le SQL, la gestion des transactions et la sécurité des bases de données. En entrant dans le cours avec une question comme « pourquoi manque-t-il une personne dans le résultat ? », les concepts abstraits acquièrent des pistes concrètes à suivre. Description officielle du cours PolyU
Absent de la liste : pas d'enregistrement, ou pas de personne du tout ?
Réduisons d'abord l'exemple du début.
La table des étudiants contient trois personnes : Ah Ming, Xiao Xin et Ah Jie. La table des rendus ne contient que les enregistrements d'Ah Ming et de Xiao Xin ; Ah Jie n'a pas encore rendu.
Si l'on joint d'abord les deux tables par une jointure interne, puis que l'on cherche les étudiants « n'ayant pas rendu », Ah Jie ne figure déjà plus dans le résultat intermédiaire. Aussi minutieux que soit le filtrage ultérieur, il ne pourra pas retrouver une personne écartée plus tôt.
Une piste consiste à partir de la liste complète des étudiants, à conserver chaque étudiant, puis à vérifier s'il existe un enregistrement de rendu correspondant. La jointure gauche peut aider à exprimer cette relation, mais il faut encore vérifier le périmètre du devoir, les champs de correspondance et les conditions de filtrage ultérieures. Changer un mot-clé de jointure ne garantit pas automatiquement une réponse correcte. Tutoriel officiel PostgreSQL sur les jointures
Dans le Lab 7 : raisonnement entre relations d'EvoClass, les apprenants comparent la liste d'inscription des étudiants avec celle de la plateforme d'apprentissage et observent comment les différents types de jointures conservent ou excluent des enregistrements.
L'exercice utile ici consiste à clarifier les choses avant d'écrire la requête : que représente une ligne du résultat ? Quelles personnes doivent être conservées ? Que signifie l'absence d'enregistrement correspondant ?
Avec ces quelques phrases, le SQL dispose d'un objectif auquel se comparer.
Avant d'interroger, décider comment représenter le monde
Revenons à cette liste. Un étudiant peut suivre plusieurs cours, un cours peut comporter plusieurs devoirs, et chaque devoir peut autoriser plusieurs rendus.
Si l'on entasse tout cela dans une grande table, les noms, les intitulés de cours et les informations sur les enseignants risquent de se répéter. On modifie un endroit, d'autres gardent l'ancienne valeur ; et pour compter les étudiants, on risque de compter plusieurs fois la même personne.
Le problème se situe alors avant la requête : que représente exactement chaque ligne de la table ?
Le Lab 2 : du monde réel aux tables PostgreSQL part de la redondance et des problèmes de mise à jour des tables à plat pour entrer dans la conception des bases de données relationnelles ; le Lab 9 : normaliser un formulaire d'inscription aborde ensuite la normalisation.
On peut commencer par un petit exercice sur papier : écrire « étudiant », « cours » et « relation d'inscription » sur trois feuilles, puis expliquer comment elles se relient. Un étudiant change de spécialité : que faut-il modifier ? Un nouveau cours n'a encore aucun inscrit : peut-on l'enregistrer malgré tout ?
Ces questions soumettent la structure des données à l'épreuve des changements quotidiens. La pertinence du découpage des tables se juge à sa capacité à exprimer clairement les relations et à rester cohérente lors des modifications.
En revenant à la requête du début, il devient aussi plus facile de juger : les quelques lignes en trop représentent-elles plusieurs étudiants différents, ou plusieurs rendus d'un même étudiant ?
Une instruction correcte ne suffit pas : l'opération entière peut rester à moitié faite
Après avoir obtenu un résultat, le système doit souvent modifier des données.
Par exemple, un étudiant demande à changer de classe : il faut le retirer de son ancienne classe et l'ajouter à la nouvelle. Si la première étape est déjà validée mais que la seconde échoue pour une raison quelconque, l'étudiant peut se retrouver temporairement sans classe. Prises séparément, les deux instructions peuvent être correctement écrites ; prises ensemble, le système laisse un état incomplet.
Les transactions offrent un outil de base face à ce type de problème : regrouper les étapes qui doivent être accomplies ensemble, pour les valider comme un tout ou les annuler en cas d'échec. La délimitation de ce « tout » demande encore de comprendre la tâche concrète. Tutoriel officiel PostgreSQL sur les transactions
Le Lab 10 : expériences sur les transactions et la concurrence pousse le sujet vers les frontières des transactions et le contrôle de concurrence, avec pour contexte la gestion des places à un guichet d'inscription aux cours, et observe ce qui se passe lorsque deux sessions opèrent simultanément.
Pendant l'exercice, on peut provoquer volontairement un échec entre deux étapes, puis examiner ce que la base de données a réellement conservé. Ensuite, faire opérer deux sessions simultanément sur les mêmes données et observer si les étapes qui semblaient fluides tiennent toujours.
L'expérience prend alors une dimension supplémentaire : au-delà de voir comment les choses réussissent, il faut aussi savoir comment elles échouent.
Après avoir demandé du SQL à une IA, que faut-il vérifier soi-même ?
Avec l'expérience acquise, le regard porté sur la requête fournie par l'IA change.
La liste incomplète du début peut être testée avec trois enregistrements d'étudiants fictifs ; le problème de double comptage, en ajoutant un étudiant ayant deux rendus ; l'opération de changement de classe, en vérifiant l'état des données lorsqu'elle échoue en cours de route.
Ces petits exemples fournissent une base de jugement. Une explication fluide ne remplace pas la vérification du résultat.
Le Lab 12 : vérifier le SQL généré par une IA intègre la revue critique dans l'exercice : la requête peut-elle s'exécuter ? Répond-elle à la question ? Que pourrait-elle casser ? Qui a le droit de l'exécuter ?
Les apprenants peuvent suivre pas à pas une tâche concrète : quels enregistrements cette requête conserve-t-elle ? Combien de lignes la modification affectera-t-elle ? Si l'on prévoit de ne modifier qu'une seule personne, comment repérer avant l'exécution que le périmètre est mal défini ? Et si l'outil dispose des droits de modification, cela signifie-t-il pour autant que la tâche actuelle l'autorise à le faire ?
Pour ceux qui découvrent les bases de données relationnelles ou qui commencent déjà à faire écrire des requêtes par une IA, le portail du cours DSAI2202 sur EvoClass propose un parcours qui approfondit les opérations de base. On peut d'abord préparer un petit jeu de données que l'on sait vérifier manuellement, puis entrer dans l'exercice avec un résultat attendu.
La prochaine fois qu'une liste bien ordonnée s'affichera à l'écran, cherchez d'abord la personne la plus facile à oublier.
Si vous pouvez expliquer pourquoi elle apparaît, ou pourquoi elle est absente, alors vous commencez à savoir si cette réponse mérite d'être crue.
Le positionnement du cours s'appuie sur la description officielle de PolyU, et la présentation des laboratoires sur les supports de cours actuels d'EvoClass. Les liens vers les séances renvoient à des supports d'apprentissage en chinois simplifié. La liste, les rendus de devoirs et la situation de changement de classe sont des exemples pédagogiques construits pour faciliter la compréhension des concepts ; ils ne constituent ni des cas d'étudiants ni des retours d'expérience d'utilisation.