Modéliser les données du quiz

Décrire les données du quiz avec un MCD et un MLD, avant de créer la base de données Supabase.

Objectifs de la séance

• comprendre pourquoi les questions doivent quitter l'application pour entrer dans une base de données ;
• repérer les entités, les attributs et les associations (avec leurs cardinalités) du quiz ;
• passer du MCD (modèle conceptuel) au MLD (modèle logique) : clés primaires et clés étrangères ;
• travailler sur une branche Git feature/supabase et documenter le modèle dans le fichier sql/README.md.

---

Petite vérification

Avant de commencer, vérifiez si vous savez...

1. jouer un quiz de 3 questions (thème Tous, niveau Tous) jusqu'au bout, puis lire le titre affiché sur l'écran final
2. dans la barre d'adresse du navigateur, ouvrir l'adresse http://localhost:8081/resultat?score=9&total=3&secondes=5&theme=tous&niveau=tous&nombre=3 et lire le message affiché
3. citer la méthode de router qui remplace l'écran courant, pour que le bouton « retour » ne ramène pas dans une partie terminée

📌 Réponse attendue

Vous devez être connecté pour voir le contenu.

Email : Mot de passe :

---

Notions théoriques

Pourquoi une base de données ?

Pour l'instant, les 27 questions du quiz sont écrites dans le code de l'application (src/data/questionsLocales.ts). Cela pose plusieurs problèmes :

• corriger une faute dans une question oblige à republier toute l'application ;
• les données ne sont pas partagées : chaque téléphone possède sa propre copie ;
• on ne peut pas enregistrer les parties des joueurs ni construire un classement.

Une base de données règle ces problèmes : les données vivent hors de l'application, sur un serveur. L'application les demande au moment où elle en a besoin, et l'enseignant peut modifier une question sans publier de nouvelle version.

Dans cette série, vous utiliserez Supabase, un service qui héberge une base de données PostgreSQL (une base de données relationnelle) et qui fournit en plus une API (une adresse Web pour interroger la base) et un système d'authentification.

Une base de données relationnelle range les informations dans des tables : chaque ligne décrit un élément (une question), chaque colonne décrit une propriété (l'énoncé, le niveau...). Les tables sont reliées entre elles.

Entité, attribut, association

Avant de créer des tables, on réfléchit sur papier avec un MCD (Modèle Conceptuel de Données) :

• une entité est un type de « chose » dont on veut garder la trace (un thème, une question, une réponse) ;
• un attribut est une propriété d'une entité (l'énoncé d'une question, le texte d'une réponse) ;
• une association est un lien entre deux entités (un thème regroupe des questions) ;
• l'identifiant d'une entité est l'attribut qui permet de la distinguer de toutes les autres.

Pour le quiz, on obtient trois entités :

Entité	Attributs	Rôle
THEME	code, libelle	un sujet du quiz (mots de passe, hameçonnage, réseaux et Wi-Fi)
QUESTION	id, niveau, enonce, explication, image_nom, est_active	une question posée au joueur
REPONSE	id, texte, est_correcte	l'une des quatre réponses proposées pour une question

Les cardinalités

Une association se lit dans les deux sens. À chaque extrémité, la cardinalité indique le nombre minimum et maximum de liens :

Cardinalité	Signification
0,1	zéro ou un
1,1	exactement un
0,n	zéro, un ou plusieurs
1,n	au moins un, et jusqu'à plusieurs

Pour l'association entre THEME et QUESTION :

• un thème regroupe au moins une question et plusieurs : côté THEME, la cardinalité est 1,n ;
• une question appartient à un seul thème : côté QUESTION, la cardinalité est 1,1.

THEME 1,n ---- regroupe ---- 1,1 QUESTION

La même logique relie QUESTION et REPONSE : une question propose plusieurs réponses (1,n), et une réponse appartient à une seule question (1,1).

Du MCD au MLD

Le MLD (Modèle Logique de Données) est la version du MCD prête à devenir des tables. Trois règles suffisent :

1. chaque entité devient une table ;
2. chaque attribut devient une colonne ;
3. une association qui a la cardinalité 1,1 d'un côté et 1,n de l'autre devient une clé étrangère, placée dans la table du côté 1,1 (la table « enfant »).

Dans l'écriture du MLD, la clé primaire est soulignée et la clé étrangère est précédée du signe #.

Clé primaire et clé étrangère

• une clé primaire identifie chaque ligne de façon unique : deux lignes d'une même table ne peuvent jamais avoir la même valeur, et elle n'est jamais vide. Ici, theme.code est un texte lisible (par exemple reseaux), alors que question.id et reponse.id sont des nombres ;
• une clé étrangère est une colonne qui contient la clé primaire d'une autre table. Par exemple, reponse.question_id contient l'id de la question à laquelle appartient la réponse. La base de données refusera donc de créer une réponse pour une question qui n'existe pas.

Les règles métier

Un MCD ne dit pas tout. Notre quiz impose aussi des règles métier :

• une question a quatre réponses, dont une seule est correcte ;
• le niveau d'une question est compris entre 1 et 3.

Dans cette série, ces règles seront garanties par la base de données elle-même autant que possible (contraintes check, index unique), et vérifiées une seconde fois par l'application.

D'autres tables viendront plus tard

Ce modèle ne contient que les données du catalogue de questions. Les joueurs et leurs parties seront ajoutés au tutoriel 8, quand l'application saura identifier un joueur.

---

TP pour réfléchir et résoudre des problèmes

Votre mission : documenter le modèle de données dans votre dépôt, dans un fichier sql/README.md. Vous allez travailler sur une branche dédiée, comme dans une vraie équipe.

Étape 1 — Créer la branche du tutoriel

Revenez sur main, mettez-le à jour, puis créez la branche feature/supabase et placez-vous dessus (git status doit d'abord indiquer que votre dossier de travail est propre) :

git switch main
git pull
git switch -c feature/supabase

Bonne pratique - Ne jamais travailler directement sur main

La branche main doit toujours contenir une version qui fonctionne. Tout le travail du tutoriel 6 se fait sur feature/supabase, et ne rejoindra main qu'à la fin du tutoriel, par une Pull Request.

Étape 2 — Créer le dossier sql et le début du README

Créez un dossier sql à la racine du projet, puis le fichier sql/README.md. Il contiendra tous les scripts SQL de la série : mieux vaut les garder dans le dépôt, pour ne jamais les perdre. Commencez par ce texte :

# Base de données Supabase du Quiz Cyber

Les scripts SQL de ce dossier sont à exécuter **dans l'ordre**, dans
**Supabase > SQL Editor** (un script = une requête, bouton **Run**).

| Script | Contenu |
|--------|---------|
| `01_tables.sql` | tables `theme`, `question`, `reponse` |
| `02_seed.sql` | jeu de données : 3 thèmes, 27 questions, 108 réponses |
| `03_rls_lecture.sql` | Row Level Security : lecture publique des questions |

Les trois scripts n'existent pas encore : vous les écrirez dans les prochaines séances.

Bonne pratique - Garder ses scripts SQL dans le dépôt

Une base de données se reconstruit avec des scripts. S'ils sont versionnés avec Git, n'importe quel développeur peut recréer la même base en les rejouant dans l'ordre.

Étape 3 — Écrire le MCD

Ajoutez ensuite la section du modèle conceptuel. Les trois entités sont données, ainsi que la première association : à vous d'écrire la seconde.

Bonne pratique - Lire une association dans les deux sens

Pour vérifier une cardinalité, posez la question dans les deux sens : « un thème regroupe combien de questions ? » (1,n) puis « une question appartient à combien de thèmes ? » (1,1).

Étape 4 — Écrire le MLD

Terminez le fichier par le modèle logique. Les clés primaires sont soulignées avec la balise <u> et les clés étrangères sont précédées de #. Les tables theme et reponse sont données : écrivez la ligne de la table question, qui possède une clé étrangère vers theme.

Bonne pratique - Nommer les colonnes sans ambiguïté

Une clé étrangère porte le nom de la table visée suivi de la colonne visée (theme_code, question_id). En lisant reponse.question_id, on comprend immédiatement à quoi la colonne sert.

Étape 5 — Enregistrer votre travail

Enregistrez le README dans l'historique Git, puis envoyez la nouvelle branche sur GitHub (l'option -u mémorise le lien avec la branche distante, il ne sera plus utile ensuite) :

Bonne pratique - Pousser sa branche dès le premier commit

Une branche poussée sur GitHub est sauvegardée : si votre ordinateur tombe en panne, votre travail n'est pas perdu. La Pull Request viendra à la fin du tutoriel.

📌 Une solution

Vous devez être connecté pour voir le contenu.

Email : Mot de passe :

---

Test de mémorisation/compréhension

Que décrit le MCD (modèle conceptuel de données) ?

Les tables, les colonnes et leurs types exacts dans PostgreSQL, avec les contraintes

Les écrans de l'application et la navigation entre eux

Les entités, leurs attributs et leurs associations

Les commandes SQL à exécuter pour remplir la base

L'ordre d'exécution des scripts du dossier sql

Que signifie « THEME 1,n ---- regroupe ---- 1,1 QUESTION » ?

Une question peut appartenir à plusieurs thèmes différents

Un thème ne contient jamais plus d'une question

Un thème regroupe au moins une question, et une question appartient à un seul thème

Une question n'a pas besoin d'appartenir à un thème pour exister

Un thème est supprimé automatiquement dès que l'une de ses questions disparaît de la base

Dans le MLD, où se trouve la clé étrangère de l'association entre QUESTION et REPONSE ?

Dans la table question, colonne reponse_id

Dans la table reponse, colonne question_id

Dans une troisième table dédiée à l'association

Dans la table theme, colonne code

Dans la table question, colonne est_active

Quelle propriété doit avoir une clé primaire ?

Être un nombre entier généré automatiquement par la base de données

Contenir le nom de l'application ou du projet

Pouvoir être vide pour les lignes les plus anciennes

Identifier une ligne de façon unique

Être identique pour toutes les lignes d'une même table

Pourquoi theme.code (par exemple reseaux) est-il une clé primaire adaptée ?

Il est unique, lisible, et utilisable tel quel dans l'application

Parce que les clés primaires doivent toujours être du texte

Parce qu'une table ne peut pas avoir d'autre colonne

Parce qu'il est calculé automatiquement par PostgreSQL à chaque insertion

Parce qu'il est secret et ne doit jamais être affiché à l'utilisateur

Quelle commande Git crée la branche feature/supabase et s'y place ?

git branch feature/supabase

git switch feature/supabase

git switch -c feature/supabase

git commit -b feature/supabase

git push -u origin feature/supabase

Quel est l'avantage principal de sortir les questions de l'application ?

Les modifier sans republier l'application

Rendre l'application plus rapide à compiler dans tous les cas

Ne plus avoir besoin de connexion Internet pour jouer

Supprimer la nécessité d'écrire des tests unitaires dans le projet

Empêcher définitivement toute triche des joueurs sur le score

---

Exercices complémentaires

Exercice A : le MCD en schéma

Dessinez sur papier le MCD du quiz avec la notation graphique : un rectangle par entité (son nom en haut, ses attributs en dessous), un ovale pour chaque association, et les cardinalités le long des traits.

Exercice B : une règle à faire respecter

Expliquez avec vos mots pourquoi la règle « une seule bonne réponse par question » ne peut pas être exprimée par les cardinalités du MCD, et proposez une solution pour qu'elle soit respectée.

---

Ce qu'il faut retenir

Notion	Résumé
Base de données	Données stockées hors de l'application, partagées et modifiables sans republier l'application.
MCD	Modèle conceptuel : entités, attributs, associations avec leurs cardinalités.
Cardinalité	Nombre minimum et maximum de liens à chaque extrémité d'une association (0,1, 1,1, 0,n, 1,n).
MLD	Le MCD traduit en tables : entités en tables, attributs en colonnes, associations en clés étrangères.
Clé primaire	Colonne qui identifie chaque ligne de façon unique (soulignée dans le MLD).
Clé étrangère	Colonne qui contient la clé primaire d'une autre table (précédée de #), placée côté 1,1.
Règle métier	Contrainte propre au sujet (une seule bonne réponse par question) à faire respecter par la base.

---

Aperçu de la prochaine séance

Le modèle est écrit sur le papier, il faut maintenant le construire. Dans la prochaine séance, vous allez créer votre projet Supabase puis transformer ce MLD en véritables tables grâce à des instructions SQL : create table, clés étrangères, contraintes de validité...