SQLab : un système de création d'aventures SQL

Si vous enseignez SQL, vous fournissez probablement à vos étudiants une base de données et des énoncés de requêtes SQL à écrire sur cette base. Quand leurs requêtes ne donnent pas le résultat attendu, vous leur faites comprendre pourquoi, leur donnez une indication ; à un moment, vous décidez de corriger et de passer à la question suivante.

SQLab (SQL adventure builder) est un nouvel outil visant à intégrer ce mécanisme dans une base de données « métier » avec les métadonnées des exercices correspondants : énoncés, corrections, indications, explications, etc. Il produit une nouvelle base entièrement self-contained, qui permet aux étudiants de faire les exercices à leur rythme, d'obtenir de l'aide, de valider leurs réponses, etc. La progression peut être libre (exercices indépendants) ou guidée (aventure). Dans ce dernier cas, une réponse correcte permet de décrypter la question suivante.

Il existe sur internet de nombreux exercices de SQL, mais très peu d'aventures, hormis :

- SQL Island (Université technique de Kaiserslautern) : la progression est guidée (chaque question débloque la suivante), mais la base n'est pas self-contained (il faut un site web pour la faire fonctionner) ;
- SQL Murder Mystery (Northwestern University, Chicago) : la base est self-contained (les données et les métadonnées sont contenues dans un seul dump SQL), mais la progression n'est pas guidée.

SQLab est à ma connaissance le premier outil capable de créer des aventures à la fois guidées et self-contained. Bien sûr, rien n'empêche d'écrire un site web autour d'une base SQLab (un tel site pourrait d'ailleurs être complètement générique, et cela fait partie des développements possibles du projet).

Pour mieux comprendre le principe de SQLab, le mieux est de jouer avec l'une des bases fournies, notamment sessform (en français), qui comprend des exercices indépendants de niveau élémentaire, un examen blanc de niveau intermédiaire, ainsi qu'une aventure plus complexe.

Un article et une documentation sont en cours d'écriture. Si d'ici-là vous souhaitez vous lancer dans la création de votre propre collection d'exercices, étudiez le notebook source de SQLab Island (en anglais) dans sa version PostgreSQL, MySQL ou SQLite.

Je suis Aristide Grange, de l'Université de Lorraine. J'ai mis au point ce système pour mes étudiants au cours des trois dernières années. Je le rends aujourd'hui public (licence MIT), accompagné de plusieurs bases (licence CC BY-SA 4.0), dans l'espoir qu'il sera utile aux collègues. Tout retour constructif est le bienvenu. Pour les problèmes et les bogues, merci d'ouvrir une issue GitHub.

Bonjour,

Merci beaucoup pour cette contribution très intéressante.
Après une première lecture du modèle de données proposé, j'ai quelques remarques :

• préfixer le nom des identifiants par une lettre différente dans chaque entité-type du MCD est une excellente chose. Mais c'est dommage de ne pas avoir fait de même avec les autres attributs.
  Car on trouve du coup des homonymes (même nom, mais dans des types d'entité différents). Pour ma part, j'utilise un préfixe de deux à trois caractères (selon la richesse du modèle) pour chaque type d'entité et chaque attribut, ainsi, plus d'homonyme, les études d'impact sont fortement simplifiées et il n'y aucun risque de percussion avec un mot réservé SQL ;
• à l'inverse, si je comprends bien la remarque
  Citation:

  ---

  Les valeurs de ces clés sont de la forme « Xn », où « n » est un entier positif.

  ---

  , ça signifie que chaque PK commence par une constante (la lettre issue du type d'entité).
  Si c'est bien le cas, c'est une mauvaise pratique : cette lettre augmente la longueur de la clef d'un octet inutile puisqu'invariant, et surtout, elle impose une PK de type char qui sera sensible à la collation et beaucoup plus encombrante à nombre de valeurs égal qu'un integer ;
• animateur et client sont des personnes physiques qui partagent les mêmes attributs, il aurait donc été préférable d'utiliser l'héritage pour éviter ces redondances ;
• la ville devrait faire l'objet d'une entité-type spécifique mise en association avec les entreprises et les personnes (personnes qui remplacent animateurs et clients) ;
• la présence des accents ne me gêne pas dans le modèle conceptuel, par contre, au niveau tabulaire, c'est assez pénible à l'usage, car ça implique d'encadrer les noms des objets concernés par des délimiteurs (double quote le plus souvent)
  La plupart des logiciels de modélisation permettent de nommer différemment les attributs du modèle conceptuel des colonnes du modèle tabulaire (MLD et MPD).

Je retournerais aussi que le niveau de SQL des outils libres (PostGreSQL, MySQL SQLite...) est loin d'être complet et strict par rapport au langage SQL et à la norme. Quelques exemples :
1) MySQL, sauf si mode strict, retourne des résultats aléatoires du fait de GROUP BY inconsistant
2) les types de données sont souvent anormatifs (notamment chaines de caractères qui ne fait pas de distinctions entre [VAR]CHAR et N[VAR]CHAR) et exotiques
3) absence de certains opérateurs (MERGE par exemple) ou de certaines fonctions (tables temporelles par exemple)...

Il aurait mieux valu utiliser un SGBDR comme IBM Db2 très respectueux de la norme SQL ou MS SQL Server (version gratuite Express...)

A +

Citation:

---

Envoyé par SQLpro

Il aurait mieux valu utiliser un SGBDR comme...

---

La première version de SQLab prend effectivement en charge trois SGBDR. Les intégrer successivement m'a, à chaque fois, obligé à élever le niveau d'abstraction de l'infrastructure, que je veux totalement agnostique. Et, croyez-le ou non, c'était d'autant plus complexe que le SGBDR-cible était plus fruste (SQLite). Le résultat net de ces efforts (désintéressés, car je ne défends pas tel ou tel vendeur) est une meilleure portabilité du logiciel, par exemple vers les systèmes que vous citez.

Mes connaissances, mes moyens et mon temps sont malheureusement limités. Il ne vous aura cependant pas échappé que le logiciel est sous licence libre. Cela signifie qu'il est ouvert à tout contributeur suffisamment compétent et motivé pour ajouter le support de son SGBDR préféré. Cela devrait représenter moins de 200 lignes de Python / UDF à écrire.

Merci en tout cas pour cette suggestion qui a l'avantage de rester dans le sujet.

Désolé si ma réponse a pu paraitre en marge du sujet, mais je n'ai aucune connaissance en Python, je me garderai donc d'examiner les entrailles du logiciel.
Et comme il s'agit d'un logiciel à vocation didactique, il m'a semblé intéressant d'améliorer ce qui peut l'être coté modèle de données.

Le logiciel n'ayant pas encore de documentation, je crois utile de préciser ici que les publics/compétences visés sont :

1. Étudiants : savoir écrire des requêtes SQL ANSI permet de jouer.
2. Enseignants : savoir utiliser un Jupyter Notebook (soit 10-15 mn pour la prise en main) et lancer un logiciel depuis la ligne de commande permet de créer sa propre aventure.
3. Développeurs : maîtriser Python et les UDF permet d'envisager de collaborer utilement au projet.

Merci de votre bienveillance.

Pour info j'avais lancé un projet similaire mais je voulais la participation de Microsoft sur le sujet avec un serveur dédie du genre de fidlle... mais MS ne m'a pas suivie hélas...
Mais bonne initiative !!!! Et courage (moi aussi je suis NULL en python...) et proche de la "casse" départ !

A +