$course$/QCM de NSI/Terminale/Bases de données et SQL Modèle relationnel (tables, attributs, clés primaires
et étrangères), contraintes d'intégrité, anomalies dans
un schéma, langage SQL (SELECT, FROM, WHERE, JOIN,
INSERT, UPDATE, DELETE), services rendus par un SGBD.

]]> Bases de données et SQL — Q01 : Définition d'un SGBD Que désigne le sigle SGBD ?

]]> Un SGBD relationnel (SGBDR) ajoute la gestion du modèle
relationnel et du langage SQL. Tous les exemples cités
ci-dessus sont des SGBDR.

]]> 1.0 0.0 0 true true abc Stockage Garanti des Bases Distribuées

]]> Erreur : sigle inventé.

]]> Système de Génération Binaire de Données

]]> Erreur : sigle inventé. SGBD est lié à la gestion
des bases de données.

]]> Standard Général des Bibliothèques de Données

]]> Erreur : sigle inventé.

]]> Système de Gestion de Base de Données

]]> Bonne réponse : un SGBD est un logiciel qui permet de
stocker, organiser, interroger et sécuriser des
données. Exemples : MySQL, PostgreSQL, SQLite, Oracle.

]]> Bases de données et SQL — Q02 : Vocabulaire du modèle relationnel Dans le modèle relationnel, comment appelle-t-on une ligne
d'une table ?

]]> Vocabulaire du modèle relationnel : table (relation),
ligne (n-uplet, enregistrement), colonne (attribut),
domaine (type des valeurs), clé primaire (identifiant
unique).

]]> 1.0 0.0 0 true true abc Un attribut

]]> Erreur : un attribut est une colonne (un champ),
pas une ligne.

]]> Un n-uplet

]]> Bonne réponse : une ligne d'une table relationnelle est
un n-uplet (en français) ou tuple (en anglais), aussi
appelé enregistrement. Elle représente une instance
d'entité.

]]> Une clé

]]> Erreur : une clé est une combinaison d'attributs qui
identifie de manière unique chaque ligne.

]]> Un domaine

]]> Erreur : un domaine est l'ensemble des valeurs possibles
pour un attribut (par exemple, les entiers naturels
pour l'âge).

]]> Bases de données et SQL — Q03 : Clé primaire Quelle est la propriété fondamentale d'une clé primaire ?

]]> Une clé primaire est : (1) unique, (2) non nulle, (3) stable
dans le temps. Elle peut être composite (composée de
plusieurs colonnes) si aucune colonne unique ne suffit.

]]> 1.0 0.0 0 true true abc Elle identifie de façon unique chaque ligne

]]> Bonne réponse : la clé primaire est par définition
unique dans la table. Deux lignes ne peuvent jamais
avoir la même valeur de clé primaire.

]]> Elle doit obligatoirement être un nombre entier positif

]]> Erreur : une clé primaire peut être de n'importe quel
type (chaîne, code-barre, identifiant composite). Le
type entier est seulement le plus courant.

]]> Elle peut prendre la valeur NULL

]]> Erreur : une clé primaire ne peut jamais être
NULL, sinon elle ne pourrait plus identifier une
ligne de manière unique.

]]> Elle doit toujours être une seule colonne

]]> Erreur : une clé primaire peut être composite (sur
plusieurs colonnes). Par exemple, dans une table
d'inscriptions, le couple (eleve_id, cours_id) peut
être une clé primaire composite.

]]> Bases de données et SQL — Q04 : Clé étrangère Que représente une clé étrangère dans une table ?

]]> Les clés étrangères implémentent les relations entre
tables et permettent au SGBD de garantir l'intégrité référentielle : on ne peut pas créer une commande pour
un client inexistant.

]]> 1.0 0.0 0 true true abc Un attribut référençant la clé primaire d'une autre table

]]> Bonne réponse : la clé étrangère établit un lien
relationnel entre deux tables. Par exemple, dans une
table Commandes, l'attribut client_id référence
la clé primaire de la table Clients.

]]> Une clé dont la valeur ne peut jamais être modifiée ensuite

]]> Erreur : la modification est possible. Le terme
« étrangère » concerne la référence vers une autre
table.

]]> Une clé importée d'un autre fichier

]]> Erreur : « étrangère » ne signifie pas « importée
d'un fichier ». Elle référence simplement une autre
table dans la même base.

]]> Un attribut crypté pour la sécurité

]]> Erreur : aucune notion de chiffrement dans le concept
de clé étrangère. C'est une notion structurelle, pas
de sécurité.

]]> Bases de données et SQL — Q05 : Syntaxe de base de SELECT Quelle est la syntaxe SQL pour récupérer toutes les
colonnes de la table eleves ?

]]> Bonne pratique : éviter SELECT * en production et lister
explicitement les colonnes nécessaires. Cela rend le code
plus robuste aux évolutions de schéma et plus clair.

]]> 1.0 0.0 0 true true abc SELECT eleves

]]> Erreur : la syntaxe SELECT requiert au minimum la
liste des colonnes (ou *) puis FROM pour la table.

]]> GET ALL FROM eleves

]]> Erreur : GET n'existe pas en SQL. La commande de
lecture est SELECT.

]]> SELECT * FROM eleves

]]> Bonne réponse : * est le joker qui désigne toutes
les colonnes. FROM indique la table source.

]]> READ eleves

]]> Erreur : READ n'est pas un mot-clé SQL. La lecture
se fait avec SELECT.

]]> Bases de données et SQL — Q06 : Filtrage avec WHERE Pour ne sélectionner que les élèves majeurs de la table
eleves, quelle requête utiliser ?

]]> Une requête SQL classique a la forme :
SELECT colonnes FROM table WHERE condition. Les
conditions multiples se combinent avec AND, OR, NOT.

]]> 1.0 0.0 0 true true abc FILTER eleves WHERE age >= 18

]]> Erreur : FILTER n'est pas la syntaxe SQL standard.
On utilise SELECT ... WHERE.

]]> SELECT * FROM eleves CONDITION age >= 18

]]> Erreur : CONDITION n'existe pas en SQL. C'est WHERE
qui introduit la condition.

]]> SELECT * FROM eleves WHERE age >= 18

]]> Bonne réponse : WHERE introduit la condition de
filtrage. La syntaxe est WHERE condition, où la
condition compare des valeurs avec les opérateurs
=, <, >, <=, >= ou <>.

]]> SELECT * FROM eleves IF age >= 18

]]> Erreur : IF n'est pas un mot-clé SQL pour le
filtrage. Le filtre se fait avec WHERE.

]]> Bases de données et SQL — Q07 : Tri avec ORDER BY Pour afficher les élèves par ordre alphabétique de leur
nom, on utilise :

]]> Pour trier par nom puis par prénom : ORDER BY nom, prenom.
Pour ordre décroissant : ORDER BY nom DESC. On peut
mélanger : ORDER BY classe ASC, moyenne DESC.

]]> 1.0 0.0 0 true true abc SELECT * FROM eleves ARRANGE BY nom

]]> Erreur : ARRANGE BY n'est pas du SQL valide.

]]> SELECT * FROM eleves ORDER BY nom

]]> Bonne réponse : ORDER BY trie le résultat selon une
ou plusieurs colonnes. Par défaut, l'ordre est
ascendant (ASC). Pour un ordre descendant, ajouter
DESC.

]]> SELECT * FROM eleves SORTED nom

]]> Erreur : SORTED n'existe pas en SQL.

]]> SELECT * FROM eleves SORT BY nom

]]> Erreur : SORT BY n'est pas une syntaxe SQL. Le tri
se fait avec ORDER BY.

]]> Bases de données et SQL — Q08 : Contraintes d'intégrité Qu'est-ce qu'une contrainte d'intégrité dans une base de
données relationnelle ?

]]> Les contraintes d'intégrité sont vérifiées automatiquement par le SGBD à chaque modification. Si
une opération les violerait, elle est rejetée. C'est une
garantie forte de cohérence.

]]> 1.0 0.0 0 true true abc Un mot de passe pour accéder à une table

]]> Erreur : aucun rapport avec l'authentification. Les
contraintes d'intégrité concernent la cohérence des
données, pas la sécurité d'accès.

]]> Une règle restreignant les valeurs admissibles, vérifiée par le SGBD

]]> Bonne réponse : les contraintes garantissent la
cohérence des données. Exemples : NOT NULL (valeur
obligatoire), UNIQUE (pas de doublon), clé primaire,
clé étrangère, CHECK (condition arbitraire).

]]> Une copie de sauvegarde automatique et régulière des données

]]> Erreur : aucun rapport avec les sauvegardes.

]]> Un index pour accélérer les requêtes

]]> Erreur : les index sont des structures auxiliaires
pour la performance, pas des règles de cohérence.

]]> Bases de données et SQL — Q09 : Insertion d'une ligne Quelle commande SQL ajoute une ligne dans une table ?

]]> Les quatre commandes principales pour manipuler les données
d'une table sont : SELECT (lire), INSERT (ajouter),
UPDATE (modifier), DELETE (supprimer).

]]> 1.0 0.0 0 true true abc INSERT INTO eleves VALUES ('Alice', 17)

]]> Bonne réponse : INSERT INTO table VALUES (...) est la
forme classique. On peut aussi préciser les colonnes :
INSERT INTO eleves (nom, age) VALUES ('Alice', 17).

]]> CREATE INTO eleves VALUES ('Alice', 17)

]]> Erreur : CREATE est utilisé pour créer une table
(CREATE TABLE), pas pour insérer une ligne.

]]> PUT INTO eleves VALUES ('Alice', 17)

]]> Erreur : PUT n'existe pas en SQL.

]]> ADD INTO eleves VALUES ('Alice', 17)

]]> Erreur : ADD n'est pas la syntaxe SQL standard pour
ajouter une ligne.

]]> Bases de données et SQL — Q10 : Valeurs atomiques Dans une base relationnelle correctement conçue, on
attend que chaque attribut contienne une valeur
atomique. Que signifie cette propriété ?

]]> Stocker des valeurs non atomiques (listes, couples,
tableaux) dans une cellule est une anomalie
fréquente. Cela empêche de filtrer ou de joindre
facilement la donnée et peut générer des
redondances et des incohérences.

]]> 1.0 0.0 0 true true abc La valeur doit impérativement être un nombre entier

]]> Erreur : aucune contrainte de type. Une valeur
atomique peut être une chaîne, un booléen, un
flottant…

]]> La valeur ne se décompose pas en plusieurs informations

]]> Bonne réponse : un attribut comme
telephones = "06 12 ; 06 34" mélange deux
informations dans une cellule, ce qui rend les
requêtes difficiles. Il faut alors créer une
seconde table reliée par une clé étrangère.

]]> La valeur ne peut jamais être modifiée

]]> Erreur : « atomique » ne signifie pas
« immuable ». Les valeurs peuvent évidemment
être mises à jour avec UPDATE.

]]> La valeur ne peut jamais être nulle (NULL interdit)

]]> Erreur : aucun rapport. L'absence de valeur est
gérée par NULL ou par la contrainte
NOT NULL.

]]> Bases de données et SQL — Q11 : Jointure entre deux tables Pour combiner les tables commandes et clients en
reliant commandes.client_id à clients.id, quelle
syntaxe utiliser ?

]]> Une jointure s'écrit FROM table1 JOIN table2 ON condition.
La condition relie en général la clé étrangère d'une table à
la clé primaire de l'autre ; les lignes sans correspondance
n'apparaissent pas dans le résultat.

]]> 1.0 0.0 0 true true abc SELECT * FROM commandes JOIN clients ON commandes.client_id = clients.id

]]> Bonne réponse : la condition ON relie la clé étrangère
commandes.client_id à la clé primaire clients.id. Seules
les commandes ayant un client correspondant apparaissent.

]]> SELECT * FROM commandes JOIN clients

]]> Erreur : sans condition ON, rien n'indique quelle commande
va avec quel client. Chaque commande est associée à chaque
client, ce qui n'a aucun sens.

]]> SELECT * FROM commandes JOIN clients ON commandes.id = clients.id

]]> Erreur : la condition relie la clé primaire des
commandes à celle des clients, alors que le lien est
porté par la clé étrangère commandes.client_id.
Chaque commande serait associée au client dont
l'identifiant coïncide par hasard avec son propre
numéro, ce qui n'a aucun sens.

]]> SELECT * FROM commandes WHERE commandes.client_id = clients.id

]]> Erreur : la table clients n'est citée ni dans FROM ni dans
un JOIN. Le SGBD ne connaît donc pas clients.id et signale
une colonne inconnue.

]]> Bases de données et SQL — Q12 : Fonctions d'agrégation Pour calculer la moyenne des âges des élèves, quelle
requête utiliser ?

]]> Les fonctions d'agrégation principales en SQL sont
COUNT, SUM, AVG, MIN et MAX. Elles
synthétisent une colonne entière en une seule
valeur dans le résultat de la requête.

]]> 1.0 0.0 0 true true abc SELECT MOYENNE(age) FROM eleves

]]> Erreur : SQL utilise des mots-clés en anglais. La
version française n'existe pas.

]]> SELECT (age) FROM eleves AVERAGE

]]> Erreur : la syntaxe AVERAGE après le FROM n'existe
pas. Les fonctions d'agrégation s'appliquent à
l'intérieur du SELECT.

]]> SELECT MEAN(age) FROM eleves

]]> Erreur : la fonction de moyenne en SQL standard
s'appelle AVG, pas MEAN.

]]> SELECT AVG(age) FROM eleves

]]> Bonne réponse : AVG (average) calcule la moyenne
arithmétique. Les fonctions d'agrégation principales
sont COUNT, SUM, AVG, MIN, MAX.

]]> Bases de données et SQL — Q13 : Combiner WHERE et ORDER BY Quelle requête renvoie les noms des élèves majeurs,
classés par âge décroissant ?

]]> L'ordre canonique des clauses dans une requête
d'interrogation est : SELECT … FROM … WHERE …
ORDER BY …. Le mot-clé DESC après ORDER BY
indique un tri décroissant ; ASC (par défaut)
indique un tri croissant.

]]> 1.0 0.0 0 true true abc SELECT nom FROM eleves ORDER BY age DESC WHERE age >= 18

]]> Erreur : l'ordre des clauses est imposé en SQL.
WHERE se place avant ORDER BY.

]]> SELECT nom FROM eleves WHERE age >= 18 ORDER BY age DESC

]]> Bonne réponse : WHERE filtre les lignes
(majeurs), puis ORDER BY age DESC les trie par
âge décroissant.

]]> SELECT nom FROM eleves WHERE age >= 18 ORDER BY age

]]> Erreur : sans le mot-clé DESC, le tri se fait
par défaut en ordre croissant.

]]> SELECT nom FROM eleves WHERE age >= 18 SORT age DESC

]]> Erreur : la clause SORT n'existe pas en SQL
standard. Il faut utiliser ORDER BY.

]]> Bases de données et SQL — Q14 : Modification d'une ligne Pour augmenter de $1$ point la note de l'élève d'identifiant
$42$, quelle requête utiliser ?

]]> Toujours penser à mettre une clause WHERE sur les
UPDATE et DELETE. Sans elle, la modification s'applique à toutes les lignes de la table, ce qui est rarement ce
qu'on veut et souvent catastrophique.

]]> 1.0 0.0 0 true true abc MODIFY eleves SET note = note + 1 WHERE id = 42

]]> Erreur : MODIFY n'est pas un mot-clé SQL standard.

]]> UPDATE eleves SET note = note + 1 WHERE id = 42

]]> Bonne réponse : UPDATE met à jour des lignes
existantes. La clause SET indique les modifications
et WHERE filtre les lignes affectées.

]]> UPDATE eleves WHERE id = 42 SET note = note + 1

]]> Erreur : ordre incorrect des clauses. La syntaxe
standard est UPDATE table SET ... WHERE ....

]]> CHANGE eleves SET note = note + 1 WHERE id = 42

]]> Erreur : CHANGE n'est pas un mot-clé SQL standard.

]]> Bases de données et SQL — Q15 : Suppression de doublons Pour obtenir la liste des classes différentes présentes
dans la table eleves (sans doublons), quelle requête
utiliser ?

]]> DISTINCT agit sur l'ensemble des colonnes
sélectionnées. Par exemple,
SELECT DISTINCT nom, prenom FROM eleves ne renverra
qu'une ligne par couple (nom, prenom) distinct.

]]> 1.0 0.0 0 true true abc SELECT DISTINCT classe FROM eleves

]]> Bonne réponse : DISTINCT élimine les doublons. Si
la table contient $30$ élèves de la classe « 1NSI »
et $25$ de « TNSI », la requête renvoie deux lignes :
« 1NSI » et « TNSI ».

]]> SELECT classe DISTINCT FROM eleves

]]> Erreur : DISTINCT se place avant la liste des
colonnes, juste après SELECT.

]]> SELECT UNIQUE classe FROM eleves

]]> Erreur : UNIQUE est utilisé pour les contraintes au
moment de la création de table, pas pour la sélection.
Le mot-clé pour la sélection est DISTINCT.

]]> SELECT classe FROM eleves

]]> Erreur : sans DISTINCT, le résultat contiendra une
entrée par élève, donc beaucoup de doublons.

]]> Bases de données et SQL — Q16 : Représenter une association multiple On souhaite représenter le fait qu'un élève peut
suivre plusieurs cours et qu'un cours peut
accueillir plusieurs élèves. Quel schéma
relationnel adopter ?

]]> Une association « plusieurs à plusieurs » se
représente par une table d'association qui contient
les clés étrangères des deux entités liées. C'est un
patron classique du modèle relationnel pour éviter
les redondances.

]]> 1.0 0.0 0 true true abc Deux tables avec une duplication des cours dans chaque ligne d'élève

]]> Erreur : la duplication crée des redondances et
des anomalies de mise à jour si l'intitulé
d'un cours change.

]]> Une seule table eleves avec autant de colonnes cours_1, cours_2, cours_3 qu'il y a de cours possibles

]]> Erreur : ce schéma est rigide (il faut
modifier la structure si un nouveau cours
apparaît) et la plupart des cellules seront
vides.

]]> Une seule table contenant eleve et tous ses cours dans une même cellule

]]> Erreur : on viole la propriété d'atomicité des
attributs et on ne peut plus interroger
facilement les données.

]]> Trois tables eleves(id, nom), cours(id, intitule) et inscriptions(eleve_id, cours_id) reliées par des clés étrangères

]]> Bonne réponse : on isole chaque entité dans sa
table et on crée une table d'association
dont chaque ligne représente une inscription
d'un élève à un cours.

]]> Bases de données et SQL — Q18 : Suppression d'une ligne Que fait la requête DELETE FROM eleves; ?

]]> Toujours utiliser WHERE avec DELETE, sauf intention
explicite de tout vider. Beaucoup de SGBD permettent
d'imposer une clause WHERE obligatoire en mode
« safe updates » pour éviter les catastrophes.

]]> 1.0 0.0 0 true true abc Elle supprime toutes les lignes de la table eleves

]]> Bonne réponse : DELETE sans clause WHERE vide la
table (mais la structure reste). C'est l'erreur
classique en production. Pour supprimer la table
entière (structure incluse), il faut DROP TABLE eleves.

]]> Elle supprime la table entière (structure et contenu)

]]> Erreur : c'est DROP TABLE qui supprime la structure.
DELETE FROM ne touche que les lignes, pas le schéma.

]]> Elle ne fait rien (manque de WHERE)

]]> Erreur : sans WHERE, la requête s'applique à
toutes les lignes. Elle est syntaxiquement valide.

]]> Elle lève une erreur SQL

]]> Erreur : la syntaxe est valide. Aucune erreur n'est
levée : c'est précisément le piège.

]]> Bases de données et SQL — Q19 : Services rendus par un SGBD Lequel des éléments suivants n'est pas un
service rendu par un système de gestion de bases de
données ?

]]> Les services principaux d'un SGBD sont la
persistance, la gestion des accès concurrents,
l'efficacité du traitement des requêtes et la
sécurisation des accès. Le programme officiel
demande de les identifier, sans en détailler le
fonctionnement interne.

]]> 1.0 0.0 0 true true abc La gestion des accès concurrents par plusieurs utilisateurs ou programmes

]]> Erreur : c'est bien un service du SGBD, qui évite
les incohérences quand plusieurs requêtes
modifient les mêmes données simultanément.

]]> La persistance des données (les données survivent à l'arrêt du programme)

]]> Erreur : c'est bien un service du SGBD, qui assure
le stockage durable des données sur disque.

]]> La compilation du code source d'un programme Python

]]> Bonne réponse : la compilation de code Python
n'a aucun rapport avec un SGBD. C'est le rôle de
l'interpréteur Python ou d'un compilateur, pas
du gestionnaire de bases de données.

]]> La sécurisation des accès (authentification, droits par utilisateur)

]]> Erreur : c'est bien un service du SGBD, qui
contrôle qui peut lire ou modifier quoi.

]]> Bases de données et SQL — Q20 : Intégrité référentielle Quelle situation viole l'intégrité référentielle ?

]]> L'intégrité référentielle est garantie par la clé étrangère :
le SGBD refuse toute insertion ou modification qui ferait
pointer client_id vers un client inexistant, et refuse aussi
de supprimer un client encore cité par des commandes.

]]> 1.0 0.0 0 true true abc Avoir deux clients avec le même nom

]]> Erreur : ce n'est pas une violation tant que la clé
primaire (l'id) est unique. Le nom peut être en
double.

]]> Insérer une commande avec un client_id inexistant dans clients

]]> Bonne réponse : la clé étrangère client_id doit
pointer vers une ligne existante de la table
clients. Sinon, on a une référence orpheline,
violation typique de l'intégrité référentielle.

]]> Insérer une commande sans préciser la quantité

]]> Erreur : une valeur manquante concerne l'attribut lui-même,
pas l'intégrité référentielle. Cette dernière porte sur les
références d'une table vers une autre.

]]> Trier l'ensemble des commandes par leur date croissante

]]> Erreur : un tri ne viole aucune contrainte.

]]> Bases de données et SQL — Q22 : Détection d'une redondance Une table commandes(id, client_id, nom_client, prenom_client, produit, prix)
pose un problème classique de schéma. Lequel ?

]]> La normalisation vise à éliminer les redondances pour
garantir la cohérence. Si on stocke le nom du client
dans chaque commande et que le client se marie, il faut
mettre à jour toutes ses commandes, risqué et coûteux.

]]> 1.0 0.0 0 true true abc La clé primaire de la table est manifestement mal choisie

]]> Erreur : id est un choix raisonnable de clé primaire
pour des commandes.

]]> Les informations du client sont dupliquées à chaque commande

]]> Bonne réponse : c'est une redondance
classique, source d'incohérences. Le nom et le prénom dépendent de
client_id, pas de l'id de commande. Il
faudrait les mettre dans une table clients
séparée et conserver uniquement la clé
étrangère client_id dans commandes.

]]> Le prix devrait être stocké dans une table produits séparée

]]> Erreur : le prix peut varier d'une commande à l'autre
(promotions, historiques) et a sa place dans commandes.

]]> La table contient trop de colonnes pour être performante

]]> Erreur : le nombre de colonnes n'est pas un problème
en soi. Le problème est ailleurs.

]]> Bases de données et SQL — Q23 : Anomalie de suppression Le lycée enregistre les inscriptions aux clubs dans une seule
table :

| id_inscription | nom_eleve | club      | salle |
|----------------|-----------|-----------|-------|
| 1              | Amina     | Échecs    | B12   |
| 2              | Basile    | Théâtre   | A03   |
| 3              | Chloé     | Théâtre   | A03   |
| 4              | Dorian    | Robotique | C07   |

Dorian quitte le club de robotique, et l'on exécute
DELETE FROM inscriptions WHERE id_inscription = 4;.
Quel défaut du schéma cette suppression révèle-t-elle ?

]]> La table mélange deux informations : les inscriptions et les
salles des clubs. On sépare le schéma en
clubs(id_club, nom, salle) et
inscriptions(id_inscription, nom_eleve, id_club#) : supprimer
une inscription ne fait alors plus rien perdre sur le club.

]]> 1.0 0.0 0 true true abc La base ne sait plus que la robotique a lieu en salle C07

]]> Bonne réponse : la salle d'un club n'est enregistrée que dans
les lignes d'inscription. En supprimant la seule inscription au
club de robotique, on perd aussi cette information : c'est une
anomalie de suppression.

]]> Le SGBD refuse la suppression, la salle C07 étant encore utilisée

]]> Erreur : aucune clé étrangère ne relie cette table à une table
de salles. Rien n'empêche la suppression, qui est acceptée, et
c'est justement ce qui fait perdre l'information.

]]> La requête supprime aussi les autres inscriptions de Dorian

]]> Erreur : la condition id_inscription = 4 désigne une seule
ligne, puisque id_inscription est la clé primaire. Aucune autre
ligne n'est touchée.

]]> Aucun défaut : chaque club garde sa salle dans une autre ligne

]]> Erreur : c'est vrai pour le théâtre, présent dans deux lignes,
mais pas pour la robotique, qui n'apparaissait que dans la ligne
supprimée.

]]> Bases de données et SQL — Q24 : Problème de concurrence Si le SGBD ne gérait pas les accès concurrents, deux programmes
qui modifient en même temps le même compte bancaire pourraient
provoquer :

]]> La gestion des accès concurrents est l'un des
services principaux d'un SGBD. Le système prend en
charge l'enchaînement des opérations pour garantir
la cohérence des données, même quand plusieurs
utilisateurs ou programmes les manipulent en même
temps.

]]> 1.0 0.0 0 true true abc Une perte de mise à jour : une modification efface l'effet de l'autre

]]> Bonne réponse : si le programme A lit le solde ($1000$), puis
le programme B le lit aussi ($1000$), puis A ajoute $100$ et
écrit $1100$, puis B ajoute $50$ et écrit $1050$, le dépôt
de A est perdu. C'est la perte de mise à jour
classique.

]]> Une erreur de syntaxe SQL au moment de l'exécution

]]> Erreur : la syntaxe est correcte. Le problème est de
cohérence, pas syntaxique.

]]> Une duplication automatique des données

]]> Erreur : aucune duplication automatique. C'est plutôt
de la perte d'information.

]]> Une accélération de l'exécution des deux programmes

]]> Erreur : sans gestion des accès concurrents, on obtient au
contraire des incohérences. La coordination des écritures
demande un peu de temps, mais rend les données fiables.

]]> Bases de données et SQL — Q26 : Structure ou contenu d'une base Dans la base de données d'un lycée, laquelle de ces opérations
modifie la structure de la base, et non son contenu ?

]]> La structure d'une base est l'ensemble de ses schémas
relationnels : relations, attributs, domaines, clés primaires et
étrangères. Le contenu, ce sont les lignes, que les requêtes
INSERT, UPDATE et DELETE font évoluer sans toucher à la
structure.

]]> 1.0 0.0 0 true true abc Inscrire un nouvel élève dans la relation eleves

]]> Erreur : un INSERT ajoute une ligne, c'est-à-dire un nouvel
élément du contenu. Le schéma de la relation eleves reste le
même.

]]> Changer la classe d'un élève qui a été réorienté

]]> Erreur : un UPDATE modifie la valeur d'un attribut dans une
ligne existante. Les attributs de la relation et leurs domaines
ne changent pas.

]]> Ajouter un attribut email à la relation eleves

]]> Bonne réponse : ajouter un attribut change le schéma relationnel
de eleves, donc la structure de la base. Toutes les lignes,
présentes et futures, sont concernées.

]]> Supprimer tous les élèves qui ont quitté le lycée

]]> Erreur : même s'il retire beaucoup de lignes d'un coup, un
DELETE ne touche que le contenu. La relation garde les mêmes
attributs.

]]> Bases de données et SQL — Q27 : Compter après une jointure filtrée On dispose des deux tables suivantes.
Table eleves :
| id | nom    | classe |
|----|--------|--------|
| 1  | Amina  | T1     |
| 2  | Basile | T2     |
| 3  | Chloé  | T1     |
| 4  | Dorian | T1     |

Table notes :
| id | id_eleve | valeur |
|----|----------|--------|
| 10 | 1        | 14     |
| 11 | 1        | 10     |
| 12 | 2        | 16     |
| 13 | 3        | 9      |
| 14 | 1        | 15     |
| 15 | 3        | 12     |
| 16 | 4        | 7      |

Que renvoie la requête suivante ?
SELECT COUNT(*)
FROM notes
JOIN eleves ON notes.id_eleve = eleves.id
WHERE eleves.classe = 'T1' AND notes.valeur >= 10;

]]> La requête s'évalue en trois temps : la jointure apparie chaque
note à son élève, le WHERE ne garde que les lignes qui vérifient
les deux conditions, puis COUNT(*) compte les lignes restantes.

]]> 1.0 0.0 0 true true abc $2$

]]> Erreur : $2$ est le nombre d’élèves concernés, Amina et Chloé.
La requête compte les lignes de la jointure, une par note : les
notes retenues d'un même élève comptent chacune.

]]> $3$

]]> Erreur : ce serait le résultat avec notes.valeur > 10. La
condition >= retient aussi la note $10$.

]]> $4$

]]> Bonne réponse : la jointure associe chaque note à son élève.
Parmi les six notes des élèves de T1, quatre valent au moins
$10$ : $14, 10, 15$ pour Amina, 12 pour Chloé.

]]> $6$

]]> Erreur : $6$ est le nombre de notes des élèves de T1. La seconde
condition du WHERE écarte encore les notes $9, 7$.

]]> Bases de données et SQL — Q30 : Trace d'une requête SELECT avec WHERE On considère la table eleves suivante :
| id | nom    | classe | moyenne |
|----|--------|--------|---------|
| 1  | Alice  | 1A     | 14.5    |
| 2  | Bob    | 1B     | 9.0     |
| 3  | Chloé  | 1A     | 16.0    |
| 4  | David  | 1B     | 13.0    |
| 5  | Émma   | 1A     | 11.5    |

Que renvoie la requête suivante ?
SELECT nom, moyenne
FROM eleves
WHERE classe = '1A' AND moyenne >= 12
ORDER BY moyenne DESC;

]]> Méthode systématique pour évaluer une requête
SQL : (1) appliquer le filtre WHERE pour ne
conserver que les lignes pertinentes ; (2)
projeter sur les colonnes du SELECT ; (3)
trier selon ORDER BY si présent. Cette
séquence d'étapes est l'algèbre relationnelle en
action.

]]> 1.0 0.0 0 true true abc Cinq lignes (toutes les lignes de la table)

]]> Erreur : on a oublié le filtrage par WHERE.
Sans filtre, on aurait bien toutes les
lignes, mais ici la requête restreint aux
élèves de 1A avec une moyenne d'au moins
$12$.

]]> Trois lignes, dans l'ordre de la table : ('Alice', 14.5), ('Chloé', 16.0), ('Émma', 11.5)

]]> Erreur : l'ordre n'est pas celui de la table
mais celui de ORDER BY moyenne DESC, et le
filtre moyenne >= 12 doit être vérifié
ligne par ligne.

]]> Deux lignes : ('Chloé', 16.0) puis ('Alice', 14.5)

]]> Bonne réponse. Étape 1, le filtre
WHERE classe = '1A' AND moyenne >= 12
retient les élèves de la classe 1A avec
une moyenne d'au moins $12$ : Alice ($14{,}5$) et Chloé ($16$).
Émma est en 1A mais sa moyenne ($11{,}5$) ne satisfait pas la deuxième condition. Étape 2, on ne garde
que les colonnes nom et moyenne. Étape 3,
on trie par moyenne DESC : Chloé d'abord, puis Alice.

]]> Une seule ligne : ('Chloé', 16.0)

]]> Erreur : Alice satisfait aussi les deux
conditions (classe 1A et moyenne d'au moins
$12$). Cette ligne doit donc apparaître dans le
résultat, après la première du fait du tri
décroissant.

]]> Bases de données et SQL — Q31 : Trace d'une jointure On dispose des deux tables suivantes :

Table clients :

| id | nom    |
|----|--------|
| 1  | Alice  |
| 2  | Bob    |
| 3  | Chloé  |

Table commandes :

| id | client_id | produit  |
|----|-----------|----------|
| 10 | 1         | Livre    |
| 11 | 2         | Cahier   |
| 12 | 1         | Stylo    |

Combien de lignes renvoie la requête suivante ?

SELECT c.nom, cmd.produit
FROM clients c
JOIN commandes cmd ON c.id = cmd.client_id;
]]> Une jointure JOIN ... ON produit une
ligne par paire qui vérifie la
condition. Un client sans commande,
comme Chloé, disparaît du résultat ;
un client à plusieurs commandes, comme
Alice, y figure plusieurs fois.

]]> 1.0 0.0 0 true true abc 2 lignes (une seule par client présent dans
les commandes)

]]> Erreur : Alice a deux commandes, donc
elle apparaît deux fois dans le résultat
(avec 'Livre' et avec 'Stylo'). La
jointure ne fusionne pas les commandes
d'un même client.

]]> 3 lignes

]]> Bonne réponse : la jointure interne (JOIN,
synonyme de INNER JOIN) ne garde que les
paires (client, commande) où la condition
c.id = cmd.client_id est vraie. Alice
(id $1$) a deux commandes ($10$ et $12$),
Bob (id $2$) en a une, Chloé n'en a aucune
et disparaît du résultat. Total : trois
lignes. Le résultat est :
('Alice', 'Livre'), ('Bob', 'Cahier'),
('Alice', 'Stylo').

]]> 9 lignes (chaque client apparié à chaque commande)

]]> Erreur : ce serait le résultat sans
condition de jointure. La condition
ON c.id = cmd.client_id ne garde que
les paires cohérentes, soit trois
lignes ici.

]]> 4 lignes

]]> Erreur : seules trois commandes existent,
et chacune est associée à un seul
client. Chloé, qui n'a aucune commande,
n'apporte aucune ligne au résultat.

]]> Bases de données et SQL — Q32 : Lire un résultat de requête depuis Python La table eleves(id, nom, moyenne) de la base lycee.db contient
quatre lignes : Basile ($13.5$), Amina ($15.0$), Chloé ($11.0$) et
Dorian ($12.0$). On exécute :

import sqlite3

connexion = sqlite3.connect("lycee.db")
curseur = connexion.cursor()
curseur.execute("SELECT nom, moyenne FROM eleves WHERE moyenne > 12 ORDER BY nom")
resultats = curseur.fetchall()
print(resultats[0])
connexion.close()

Qu'affiche ce programme ?

]]> Depuis Python, execute envoie la requête SQL au SGBD, et
fetchall récupère le résultat sous forme de liste de p-uplets,
un par ligne. On traite ensuite ces données avec les outils
habituels : indexation, boucles, tests.

]]> 1.0 0.0 0 true true abc Amina

]]> Erreur : chaque ligne du résultat est un p-uplet qui contient
toutes les colonnes demandées dans le SELECT, ici nom et
moyenne. resultats[0] est ce p-uplet entier.

]]> ('Basile', 13.5)

]]> Erreur : Basile est la première ligne de la table, mais
ORDER BY nom range le résultat par ordre alphabétique. Amina
passe devant.

]]> ('Amina', 15.0)

]]> Bonne réponse : fetchall renvoie la liste des lignes du
résultat, chacune sous forme de p-uplet. Amina et Basile ont une
moyenne supérieure à $12$, et Amina vient en premier dans
l'ordre alphabétique.

]]> [('Amina', 15.0), ('Basile', 13.5)]

]]> Erreur : c'est le contenu de resultats tout entier.
L'indexation resultats[0] n'en extrait que le premier
élément.

]]> Bases de données et SQL — Q34 : Lecture d'un schéma relationnel On considère le schéma relationnel suivant :

eleves(*id_eleve, nom, prenom, id_classe#)
classes(*id_classe, niveau, salle)
notes(*id_eleve#, *id_devoir#, note)
devoirs(*id_devoir, matiere, date)

Le * marque les attributs qui composent la
clé primaire de chaque table (souligné dans
la notation usuelle) et le # désigne une
clé étrangère. Quelle affirmation est
correcte ?

]]> Méthode pour lire un schéma relationnel : (1)
identifier la clé primaire de chaque table
(souvent soulignée ou notée en premier) ; (2)
repérer les clés étrangères (notées #,
soulignées en pointillés, ou en italique selon
la convention) ; (3) interpréter les
cardinalités. Ici, l'association notes est
une association plusieurs-à-plusieurs
typique, qui ne peut pas se modéliser par une
simple clé étrangère ajoutée à une table
existante.

]]> 1.0 0.0 0 true true abc La table eleves n'a pas de lien avec
classes

]]> Erreur : la colonne id_classe# dans
eleves est précisément une clé
étrangère qui pointe vers classes, ce
qui établit le lien « un élève appartient
à une classe ».

]]> On peut avoir plusieurs élèves avec le
même id_eleve

]]> Erreur : id_eleve est la clé primaire de
la table eleves, donc unique par
définition. Deux élèves différents ne
peuvent pas partager la même valeur de
id_eleve.

]]> Pour ajouter une note dans notes, il
n'est pas nécessaire que l'élève existe
dans eleves

]]> Erreur : la clé étrangère id_eleve# dans
notes impose que la valeur référence un
élève existant. Insérer une note pour un
élève inexistant viole l'intégrité
référentielle et le SGBD rejette
l'opération.

]]> La clé primaire de notes est composite,
formée de deux clés étrangères

]]> Bonne réponse : la clé (id_eleve,
id_devoir) référence respectivement
eleves et devoirs. C'est la lecture
correcte du schéma. La table notes représente une
association binaire porteuse d'un attribut
(elle relie un élève et un devoir, et
porte la note). La clé primaire composite
garantit l'unicité (un élève ne peut avoir
qu'une note par devoir), et les clés
étrangères assurent l'intégrité
référentielle (on ne peut pas mettre une
note pour un élève ou un devoir
inexistants).

]]> Bases de données et SQL — Q35 : Injection SQL Un programme construit la requête SQL suivante
en concaténant directement la chaîne
nom_saisi reçue de l'utilisateur :

requete = "SELECT * FROM users WHERE nom = '" + nom_saisi + "';"

Si l'utilisateur saisit
' OR '1'='1, que se passe-t-il ?

]]> L'injection SQL reste, en 2026, l'une des
vulnérabilités les plus exploitées dans les
applications web. La parade est connue depuis
longtemps : ne jamais construire une
requête SQL par concaténation de chaînes
utilisateur, mais utiliser systématiquement
des requêtes préparées où les paramètres
sont passés séparément
(cursor.execute("... WHERE nom = ?", (nom_saisi,))).
Le SGBD échappe alors automatiquement les
caractères dangereux.

]]> 1.0 0.0 0 true true abc Le SGBD détecte l'injection et rejette la
requête

]]> Erreur : la requête est syntaxiquement
parfaitement valide. Le SGBD n'a aucun
moyen de détecter qu'elle vient d'une
concaténation dangereuse plutôt que d'une
intention légitime. C'est précisément ce
qui rend l'injection SQL si pernicieuse.

]]> Python lève une exception au moment de la
concaténation

]]> Erreur : Python concatène sans aucun
problème les chaînes, quel que soit leur
contenu. Aucune exception n'est levée.
C'est précisément le drame : tout se passe
silencieusement.

]]> Toutes les lignes de la table sont
renvoyées : c'est une injection SQL

]]> Bonne réponse : la requête devient
SELECT * FROM users WHERE nom = '' OR '1'='1';.
La concaténation naïve fait
sortir la chaîne saisie de son rôle de
simple donnée et l'injecte dans la
structure SQL. La condition '1'='1'
étant toujours vraie, l'opérateur OR la
fait court-circuiter le filtre. C'est la
forme la plus simple d'injection SQL,
célèbre attaque qui a touché de nombreux
sites mal protégés. La parade standard :
utiliser des requêtes préparées avec
des paramètres liés
(cursor.execute(req, (nom_saisi,))).

]]> La requête ne retourne aucune ligne

]]> Erreur : c'est l'inverse. La condition
'1'='1' étant toujours vraie, toutes
les lignes de la table sont retournées,
y compris des données potentiellement
sensibles que l'utilisateur ne devrait
pas voir.

]]> Bases de données et SQL — Q36 : Trace d'un UPDATE ciblé On part de la table comptes suivante :
| id | titulaire | solde |
|----|-----------|-------|
| 1  | Alice     | 1000  |
| 2  | Bob       | 500   |
| 3  | Chloé     | 2000  |

On exécute la requête suivante :
UPDATE comptes
SET solde = solde * 1.05
WHERE solde >= 1000;

Quel est le contenu de la table après
exécution ?

]]> Schéma général d'un UPDATE : (1) la clause
WHERE sélectionne les lignes affectées ; (2)
la clause SET indique comment modifier ces
lignes ; (3) le SGBD applique la modification
atomiquement (toutes les lignes en une seule
opération). Sans WHERE, toutes les lignes
sont modifiées, ce qui est rarement souhaité
et souvent catastrophique.

]]> 1.0 0.0 0 true true abc Bob est supprimé de la table

]]> Erreur : UPDATE ne supprime jamais de
ligne, il ne fait que modifier des
valeurs. Pour supprimer une ligne, il
faudrait utiliser DELETE FROM comptes
WHERE solde < 1000;.

]]> Toutes les lignes voient leur solde
multiplié par $1{,}05$

]]> Erreur : c'est ce qui se passerait si la
clause WHERE était absente. Avec
WHERE solde >= 1000, seules les lignes
satisfaisant la condition sont
modifiées. Bob ($500$) ne fait pas partie
du lot.

]]> Alice : $1050$, Bob : $500$ (inchangé), Chloé : $2100$

]]> Bonne réponse : la clause WHERE solde >= 1000
sélectionne les lignes où le solde est
d'au moins $1000$ (Alice et Chloé). Pour
chacune, on applique solde = solde * 1.05.
Alice passe de $1000$ à $1050$, Chloé de $2000$ à $2100$. Bob, dont le solde est inférieur à $1000$, n'est pas affecté.

]]> La table reste inchangée car la clause
WHERE est trop restrictive

]]> Erreur : Alice ($1000$) et Chloé ($2000$)
satisfait bien la condition solde >= 1000,
donc la ligne est modifiée. La
condition n'est pas trop restrictive : elle
est ciblée.

]]> Bases de données et SQL — Q37 : Rôle de la clause ON Dans la requête
SELECT * FROM livres JOIN auteurs ON livres.id_auteur = auteurs.id,
à quoi sert la clause ON ?

]]> Une jointure combine deux tables ligne à ligne. La
clause ON donne la règle d'appariement, presque
toujours l'égalité entre la clé étrangère d'une
table et la clé primaire de l'autre. Sans elle, le
SGBD ne saurait pas quelle ligne d'auteurs
accompagne chaque livre.

]]> 1.0 0.0 0 true true abc À indiquer la condition qui apparie une ligne de livres à une ligne d'auteurs

]]> Chaque livre est associé à l'auteur dont
l'identifiant est égal à sa clé étrangère
id_auteur.

]]> À trier les lignes du résultat selon les valeurs de la colonne auteurs.id

]]> Le tri s'obtient avec ORDER BY ; ON ne
change pas l'ordre des lignes.

]]> À choisir les colonnes des deux tables qui apparaissent dans le résultat

]]> Ce choix revient à SELECT ; ici l'étoile
affiche toutes les colonnes des deux tables.

]]> À renommer la table auteurs en livres le temps de la requête

]]> Renommer une table se fait avec AS ; ON
compare des colonnes, il ne renomme rien.

]]> Bases de données et SQL — Q38 : Écrire une jointure villes et pays La base contient villes(id, nom, id_pays) et
pays(id, nom), où id_pays est une clé étrangère
vers pays. Quelle requête affiche le nom de chaque
ville suivi du nom de son pays ?

]]> Pour relier deux tables, on cherche la clé étrangère
de l'une et la clé primaire de l'autre :
villes.id_pays désigne pays.id. La condition de
jointure compare exactement ces deux colonnes.

]]> 1.0 0.0 0 true true abc SELECT villes.nom, pays.nom FROM villes JOIN pays ON villes.id_pays = pays.id

]]> La clé étrangère id_pays est comparée à la clé
primaire id de la table pays.

]]> SELECT villes.nom, pays.nom FROM villes JOIN pays ON villes.id = pays.id

]]> Cette condition apparie une ville et un pays qui
ont par hasard le même numéro d'identifiant, ce
qui n'a aucun sens.

]]> SELECT villes.nom, pays.nom FROM villes WHERE villes.id_pays = pays.id

]]> La table pays n'est pas dans la clause FROM :
le SGBD signale une colonne inconnue.

]]> SELECT villes.nom, pays.nom FROM villes JOIN pays ON villes.nom = pays.nom

]]> Comparer le nom d'une ville au nom d'un pays
n'apparie rien, sauf homonymie accidentelle.

]]> Bases de données et SQL — Q39 : Un auteur absent du résultat Table auteurs :

| id | nom     |
|----|---------|
| 1  | Colette |
| 2  | Camus   |
| 3  | Duras   |

Table livres :

| id | titre      | id_auteur |
|----|------------|-----------|
| 10 | Chéri      | 1         |
| 11 | La Peste   | 2         |
| 12 | Sido       | 1         |
| 13 | L'Étranger | 2         |
| 14 | Gigi       | 1         |

On exécute :

SELECT auteurs.nom, livres.titre
FROM auteurs JOIN livres ON auteurs.id = livres.id_auteur;

Pourquoi le nom « Duras » n'apparaît-il pas dans le
résultat ?

]]> Le résultat compte cinq lignes, une par livre,
chacune avec le nom de son auteur. Un auteur sans
livre ne forme aucune paire et disparaît : c'est le
comportement de la jointure interne, la seule au
programme.

]]> 1.0 0.0 0 true true abc Parce qu'aucun livre n'a id_auteur égal à $3$ : la jointure ne garde que les paires appariées

]]> Une jointure produit une ligne par couple
(auteur, livre) vérifiant la condition ; Duras
n'entre dans aucun couple.

]]> Parce que la table auteurs est citée en premier dans FROM, ce qui l'exclut du résultat

]]> L'ordre des tables dans la jointure ne retire
aucune ligne ; Colette et Camus, de la même
table, apparaissent bien.

]]> Parce que le SGBD n'affiche que les deux premiers auteurs de la table

]]> Rien ne limite le nombre d'auteurs ; Colette et
Camus figurent parce qu'ils ont des livres, pas
parce qu'ils sont en tête.

]]> Parce que la requête contient une erreur et ne renvoie que des lignes partielles

]]> La requête est correcte et renvoie cinq lignes
complètes, une par livre.

]]> Bases de données et SQL — Q40 : Noms courts dans une jointure Que désignent e et c dans la requête suivante ?

SELECT e.nom, c.libelle
FROM eleves AS e
JOIN clubs AS c ON e.id_club = c.id;
]]> eleves AS e déclare un alias. Partout ailleurs
dans la requête, e.nom signifie eleves.nom. Le
mot AS est facultatif : FROM eleves e a le même
effet.

]]> 1.0 0.0 0 true true abc Des alias : des noms courts donnés aux tables eleves et clubs le temps de la requête

]]> Ils allègent l'écriture des colonnes et lèvent
toute ambiguïté quand deux tables ont une colonne
de même nom.

]]> Deux colonnes de la table eleves, qui contiennent respectivement le nom et le libellé

]]> nom et libelle sont les colonnes ; e et c
précèdent le point et désignent des tables.

]]> Deux nouvelles tables, créées dans la base au moment où la requête est exécutée

]]> AS n'écrit rien dans la base ; les noms courts
disparaissent dès la fin de la requête.

]]> L'ordre de tri du résultat : d'abord selon les élèves (e), puis selon les clubs (c)

]]> Aucun ORDER BY n'est présent ; e et c ne
disent rien de l'ordre des lignes.

]]> Bases de données et SQL — Q41 : Jointure puis filtre Avec livres(id, titre, annee, id_auteur) et
auteurs(id, nom), quelle requête renvoie les
titres des livres écrits par Colette ?

]]> Deux étapes : relier chaque livre à son auteur par
la clé étrangère, puis filtrer sur le nom. Le filtre
va dans WHERE, la règle d'appariement dans ON.

]]> 1.0 0.0 0 true true abc SELECT livres.titre FROM livres JOIN auteurs ON livres.id_auteur = auteurs.id WHERE auteurs.nom = 'Colette'

]]> La jointure attache l'auteur à chaque livre, puis
WHERE ne garde que les lignes dont l'auteur
s'appelle Colette.

]]> SELECT livres.titre FROM livres JOIN auteurs ON livres.id = auteurs.id WHERE auteurs.nom = 'Colette'

]]> La condition de jointure compare deux clés
primaires sans rapport : aucun livre n'est relié
à son auteur, et le résultat est faux sans
message d'erreur.

]]> SELECT livres.titre FROM livres JOIN auteurs ON livres.id_auteur = auteurs.id WHERE livres.id_auteur = 'Colette'

]]> La jointure est bonne, mais id_auteur contient un
numéro, jamais un nom : le filtre ne garde aucune
ligne.

]]> SELECT livres.titre FROM livres JOIN auteurs ON auteurs.nom = 'Colette'

]]> La condition de jointure ne relie pas les deux
tables : chaque livre est apparié à Colette,
qu'il soit d'elle ou non, et tous les titres
sortent.

]]> Bases de données et SQL — Q42 : Première ligne d'une jointure triée Table equipes :

| id | nom     |
|----|---------|
| 1  | Lions   |
| 2  | Aigles  |
| 3  | Requins |

Table joueurs :

| id | nom  | id_equipe | buts |
|----|------|-----------|------|
| 1  | Sami | 2         | 4    |
| 2  | Lou  | 1         | 7    |
| 3  | Inès | 3         | 2    |
| 4  | Teo  | 2         | 9    |
| 5  | Maya | 1         | 5    |
SELECT joueurs.nom, equipes.nom
FROM joueurs JOIN equipes ON joueurs.id_equipe = equipes.id
ORDER BY joueurs.buts DESC;

Quelle est la première ligne du résultat ?

]]> La jointure remplace chaque id_equipe par le nom
de l'équipe correspondante ; le tri décroissant sur
buts place Teo ($9$) devant Lou ($7$), Maya ($5$),
Sami ($4$) et Inès ($2$).

]]> 1.0 0.0 0 true true abc Teo | Aigles

]]> Teo a le plus de buts ($9$) et son équipe,
d'identifiant $2$, est Aigles.

]]> Lou | Lions

]]> Lou vient en deuxième position avec $7$ buts.

]]> Teo | Lions

]]> Teo joue dans l'équipe $2$, Aigles ; Lions porte
l'identifiant $1$.

]]> Inès | Requins

]]> Inès, avec $2$ buts, termine dernière du
classement décroissant.

]]> Bases de données et SQL — Q43 : Jointure sur trois tables Schéma : eleves(id, nom), activites(id, libelle)
et inscriptions(id_eleve, id_activite). Quelle
requête affiche le nom de chaque élève avec le
libellé de chaque activité où il est inscrit ?

]]> inscriptions est une table de liaison : elle ne
contient que des clés étrangères. Il faut deux
jointures en chaîne, chacune reliant une clé
étrangère à la clé primaire visée.

]]> 1.0 0.0 0 true true abc SELECT eleves.nom, activites.libelle FROM eleves JOIN inscriptions ON eleves.id = inscriptions.id_eleve JOIN activites ON inscriptions.id_activite = activites.id;]]> Deux jointures en chaîne : l'élève est relié à
ses inscriptions, chaque inscription à son
activité.

]]> SELECT eleves.nom, activites.libelle FROM eleves JOIN inscriptions ON eleves.id = inscriptions.id_activite JOIN activites ON inscriptions.id_eleve = activites.id;]]> Les clés sont croisées : un élève est apparié
aux inscriptions dont le numéro d'activité vaut
son propre numéro. Le résultat est faux sans
aucun message d'erreur.

]]> SELECT eleves.nom, activites.libelle FROM eleves JOIN activites ON eleves.id = activites.id;]]> La table inscriptions est oubliée : on apparie
un élève à l'activité qui porte le même numéro,
sans rapport avec ses inscriptions.

]]> SELECT eleves.nom, activites.libelle FROM eleves, inscriptions, activites;]]> Sans condition d'appariement, chaque élève est
associé à chaque inscription et à chaque
activité : le résultat contient toutes les
combinaisons.

]]> Bases de données et SQL — Q44 : Quand une jointure est nécessaire Base : livres(id, titre, annee, id_auteur) et
auteurs(id, nom, pays). Quelle demande exige une
jointure ?

]]> Une jointure sert quand les informations demandées,
ou les critères de filtrage, sont répartis sur
plusieurs tables. Si tout se trouve dans une seule
table, un SELECT simple suffit.

]]> 1.0 0.0 0 true true abc Les titres des livres parus après l'année $2000$

]]> Titre et année sont dans la seule table
livres : un WHERE annee > 2000 suffit.

]]> Les noms des auteurs dont le pays est la France

]]> La table auteurs contient le nom et le pays :
aucune autre table n'est nécessaire.

]]> Les titres des livres d'un auteur irlandais

]]> Le titre est dans livres et le pays dans
auteurs : il faut relier les deux par
id_auteur.

]]> Le nombre de livres parus pendant l'année $1947$

]]> COUNT(*) sur livres avec WHERE annee = 1947
répond sans toucher à auteurs.

]]> Bases de données et SQL — Q45 : Persistance des données On dit qu'un SGBD assure la persistance des données. Que
signifie cette propriété ?

]]> La persistance est l'un des services fondamentaux d'un SGBD : ce
qui a été validé est conservé durablement, quels que soient les
arrêts ou les pannes de courant ultérieurs.

]]> 1.0 0.0 0 true true abc Les données survivent à l'arrêt du programme et de la machine

]]> Bonne réponse : les données sont écrites sur un support durable
et retrouvées intactes au redémarrage, contrairement aux
variables d'un programme, qui disparaissent avec lui.

]]> Les données sont gardées en mémoire vive pour être lues plus rapidement

]]> Erreur : la mémoire vive s'efface à l'extinction. La persistance
repose justement sur l'écriture sur un support durable, le cache
en mémoire n'étant qu'une accélération.

]]> Les données ne peuvent plus être modifiées une fois insérées dans la base

]]> Erreur : une base vit, on y insère, modifie et supprime des
lignes. La persistance garantit que l'état courant survit aux
arrêts, pas qu'il est figé.

]]> Les données sont recopiées automatiquement sur un second site distant

]]> Erreur : la réplication est une mesure de sécurité
supplémentaire, pas la définition de la persistance, qui
concerne d'abord la conservation locale sur disque.

]]> Bases de données et SQL — Q46 : Droits d'accès à une table Dans la base d'un lycée, le compte utilisé par l'application
d'affichage des emplois du temps doit pouvoir lire la table cours
mais jamais la modifier. Quel mécanisme du SGBD répond à ce
besoin ?

]]> La sécurisation des accès est un service du SGBD : chaque compte
reçoit des droits précis, lecture seule pour une application
d'affichage, écriture pour la gestion, administration pour
quelques personnes.

]]> 1.0 0.0 0 true true abc Des droits d'accès limités à SELECT pour ce compte

]]> Bonne réponse : le SGBD associe à chaque compte des droits par
table et par opération. Une requête de modification émise par
ce compte est refusée avant même d'être exécutée.

]]> Le chiffrement de la table cours, illisible sans la clé de déchiffrement

]]> Erreur : chiffrer la table empêcherait aussi la lecture, qui est
précisément ce que l'application doit pouvoir faire. Le besoin
porte sur les opérations autorisées, pas sur la confidentialité.

]]> La clé primaire de la table cours, qui interdit toute modification des lignes

]]> Erreur : une clé primaire garantit l'unicité des lignes, elle ne
limite en rien les opérations permises à un compte.

]]> Une contrainte d'intégrité qui rejette toute requête UPDATE sur la table

]]> Erreur : les contraintes d'intégrité portent sur la validité des
données, pas sur l'identité de celui qui les modifie. C'est la
gestion des droits qui distingue les comptes.

]]> Bases de données et SQL — Q47 : Deux réservations simultanées Deux clients tentent au même instant de réserver la dernière place
d'un spectacle. Comment le SGBD évite-t-il de vendre deux fois la
même place ?

]]> Sans gestion des accès concurrents, deux lectures simultanées de
« place libre » conduiraient à deux ventes. Le SGBD sérialise les
opérations conflictuelles pour que la base reste cohérente.

]]> 1.0 0.0 0 true true abc Il les traite l'une après l'autre, et la seconde trouve la place déjà prise

]]> Bonne réponse : la gestion des accès concurrents ordonne les
opérations comme si elles avaient été faites l'une après
l'autre. Le second client reçoit un refus cohérent.

]]> Il accepte les deux réservations et signale le conflit à l'administrateur du site

]]> Erreur : accepter les deux, c'est précisément l'incohérence à
éviter. Le SGBD l'empêche avant qu'elle ne soit écrite, il ne se
contente pas de la signaler.

]]> Il refuse toute réservation tant que plusieurs clients sont connectés en même temps

]]> Erreur : bloquer tout le monde rendrait le service inutilisable.
Le SGBD n'arbitre que les opérations qui touchent les mêmes
données.

]]> Il attribue la place au client dont la connexion au serveur est la plus rapide

]]> Erreur : la vitesse de connexion n'intervient pas. Le SGBD
garantit seulement qu'une des deux opérations est entièrement
traitée avant que l'autre ne lise l'état de la place.

]]> Bases de données et SQL — Q48 : Parade à l'injection SQL Un programme construit ses requêtes à partir de valeurs saisies
par l'utilisateur. Quelle pratique le protège contre l'injection
SQL ?

]]> L'injection SQL vient de la concaténation de texte saisi dans une
requête. La parade consiste à ne jamais mélanger les deux : la
requête est écrite avec des emplacements, et les valeurs sont
fournies à part.

]]> 1.0 0.0 0 true true abc Des requêtes paramétrées, les valeurs étant transmises à part

]]> Bonne réponse : avec une requête paramétrée, la structure de la
requête est fixée avant que les valeurs n'y soient insérées.
Une saisie contenant ' OR 1=1 reste une simple chaîne de
caractères comparée telle quelle.

]]> Le masquage des messages d'erreur renvoyés par le SGBD à l'utilisateur

]]> Erreur : cacher les erreurs complique le travail de l'attaquant
mais n'empêche pas l'injection. Une requête détournée s'exécute
toujours, en silence.

]]> La limitation de la longueur des champs du formulaire à vingt caractères

]]> Erreur : ' OR 1=1 -- tient en moins de vingt caractères. La
limitation gêne à peine l'attaque et ne traite pas sa cause, le
mélange entre code SQL et données.

]]> Le chiffrement de l'ensemble du contenu de la base de données

]]> Erreur : le chiffrement protège les données volées ou lues sur
le disque. Une requête injectée est exécutée par le SGBD
lui-même, qui déchiffre normalement ce qu'il renvoie.

]]> Bases de données et SQL — Q49 : Les sauvegardes d'une base de données Pourquoi un système de gestion de bases de données sauvegarde-t-il
régulièrement les données qu'il héberge ?

]]> Parmi les services d'un SGBD figure la sécurité des données au
sens de leur conservation : la sauvegarde en est l'outil.

]]> 1.0 0.0 0 true true abc Pour restaurer les données après une panne ou une erreur

]]> Bonne réponse : un disque qui lâche, une requête de suppression
malheureuse ou un piratage détruisent des données ; seule une
copie récente permet de les retrouver.

]]> Pour accélérer les requêtes les plus fréquentes du site

]]> Erreur : la vitesse relève des index et de la mémoire cache, pas
des sauvegardes.

]]> Pour supprimer automatiquement les lignes en double

]]> Erreur : les doublons se traitent par les contraintes
d'intégrité.

]]> Pour remplacer la gestion des droits d'accès des utilisateurs

]]> Erreur : sauvegarde et droits d'accès sont deux garanties
distinctes.

]]> Bases de données et SQL — Q50 : Le compte utilisé par une application de consultation Un site affiche les horaires d'une bibliothèque depuis une base de
données, sans jamais les modifier. Avec quel compte doit-il se
connecter à la base ?

]]> Les droits d'accès s'attribuent selon le besoin réel : lire quand
il suffit de lire.

]]> 1.0 0.0 0 true true abc Un compte limité à la lecture, pour qu'une faille ne modifie rien

]]> Bonne réponse : donner le moins de droits possible limite les
dégâts d'une attaque ; un compte en lecture seule ne peut ni
effacer ni altérer les horaires.

]]> Le compte administrateur, pour n'essuyer aucun refus d'accès

]]> Erreur : une injection réussie disposerait alors de tous les
droits, suppression comprise.

]]> Aucun compte, les horaires étant des données publiques de toute façon

]]> Erreur : le SGBD exige une identification pour tout accès, même
en lecture.

]]> Un compte distinct pour chaque visiteur, créé à la volée

]]> Erreur : les visiteurs ne se connectent pas à la base, c'est le
site qui le fait.

]]>