$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 (ou enregistrement)

]]> 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 manière unique chaque ligne de la table

]]> 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 être un nombre entier

]]> 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 qui référence 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é qui ne peut pas être modifiée

]]> 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ù
condition utilise les opérateurs SQL standard
(=, <, >, <=, >=, <>, LIKE, etc.).

]]> 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 qui restreint les valeurs admissibles dans la base, 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

]]> 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 du SQL DML (Data
Manipulation Language) sont : SELECT (lire),
INSERT (créer), 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 être un entier

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

]]> La valeur n'est pas décomposable en plusieurs informations distinctes (par exemple, on ne stocke pas plusieurs numéros de téléphone dans une même cellule)

]]> 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 pas être nulle

]]> 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 ?

]]> Différents types de jointures : INNER JOIN (ne garde
que les lignes appariées), LEFT JOIN (garde toutes les
lignes de la table de gauche), RIGHT JOIN (symétrique),
FULL JOIN (les deux côtés).

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

]]> Bonne réponse : c'est une jointure interne explicite.
Seules les commandes ayant un client correspondant
apparaissent. Syntaxe préférée à la virgule depuis
SQL-92.

]]> SELECT * FROM commandes, clients

]]> Erreur : cette syntaxe produit le produit cartésien
(toutes les paires possibles), sans condition de
jointure. Le résultat est rarement ce qu'on souhaite.

]]> SELECT * FROM commandes WITH clients

]]> Erreur : WITH introduit des sous-requêtes nommées
(CTE), pas des jointures.

]]> SELECT * FROM commandes UNION clients

]]> Erreur : UNION combine deux requêtes en empilant
leurs résultats (les lignes de l'une après l'autre).
Pour combiner colonnes côte à côte, c'est JOIN.

]]> 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 — Q17 : Recherche avec LIKE Pour trouver tous les élèves dont le nom commence par "Du",
quelle requête utiliser ?

]]> Les jokers de LIKE : % (zéro ou plus de caractères) et
_ (un caractère exactement). Pour une recherche
insensible à la casse, certains SGBD acceptent ILIKE
(PostgreSQL) ou LIKE avec LOWER() (portable).

]]> 1.0 0.0 0 true true abc WHERE nom STARTS 'Du'

]]> Erreur : STARTS n'est pas un mot-clé SQL standard.
Pour cette recherche, on utilise LIKE avec %.

]]> WHERE nom LIKE 'Du%'

]]> Bonne réponse : LIKE permet la correspondance par
motif. Le caractère % représente n'importe quelle
séquence de caractères (zéro ou plus). Donc 'Du%'
correspond à "Du", "Dupont", "Dubois", etc.

]]> WHERE nom = 'Du'

]]> Erreur : = teste l'égalité exacte. Cela ne
renverrait que les élèves dont le nom est exactement
"Du", pas ceux qui commencent par "Du".

]]> WHERE nom CONTAINS 'Du'

]]> Erreur : CONTAINS est non standard (existant dans
certains SGBD pour la recherche plein texte). Le SQL
standard utilise LIKE avec des jokers.

]]> 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 les
contraintes FOREIGN KEY. À la suppression d'un client,
on peut configurer ON DELETE CASCADE (supprimer aussi
les commandes), ON DELETE RESTRICT (interdire la
suppression s'il y a des commandes), etc.

]]> 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 qui n'existe pas dans la table 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 : c'est une violation de contrainte NOT NULL,
pas d'intégrité référentielle. Cette dernière concerne
les références entre tables.

]]> Trier les commandes par date

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

]]> Bases de données et SQL — Q21 : Sous-requête Que renvoie cette requête ?

`SELECT nom FROM eleves WHERE moyenne > (SELECT AVG(moyenne) FROM eleves);`

]]> On peut utiliser >=, <, =, IN avec une sous-requête.
La sous-requête est exécutée une fois ici (elle ne
dépend pas de la ligne courante), donc le SGBD optimise
automatiquement.

]]> 1.0 0.0 0 true true abc Les moyennes des élèves au-dessus de zéro

]]> Erreur : la condition > ne porte pas sur zéro mais
sur la valeur de la sous-requête.

]]> Une erreur (sous-requête non autorisée)

]]> Erreur : les sous-requêtes sont parfaitement
autorisées en SQL. C'est une fonctionnalité
essentielle.

]]> La moyenne des moyennes des élèves

]]> Erreur : AVG(moyenne) calcule effectivement la
moyenne des moyennes, mais la requête principale
renvoie les noms des élèves dépassant cette
moyenne, pas le calcul lui-même.

]]> Les noms des élèves dont la moyenne est strictement supérieure à la moyenne de la classe

]]> Bonne réponse : la sous-requête calcule la moyenne
globale, et la requête principale filtre les élèves
au-dessus. C'est un usage très courant des
sous-requêtes pour comparer à un agrégat.

]]> 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 est mal choisie

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

]]> Les informations du client (nom, prénom) sont dupliquées à chaque commande, ce qui crée des incohérences potentielles si les noms sont mal mis à jour

]]> Bonne réponse : c'est une redondance
classique. 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é séparément

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

]]> La table contient trop de colonnes

]]> 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 : Différence entre INNER et LEFT JOIN Quelle est la différence entre INNER JOIN et LEFT JOIN ?

]]> Le JOIN simple (équivalent de INNER JOIN)
apparie les lignes selon la condition ON. Le
LEFT JOIN étend ce comportement en conservant
aussi les lignes de gauche sans correspondance, en
les complétant par des NULL côté droit.

]]> 1.0 0.0 0 true true abc INNER JOIN ne garde que les paires appariées ; LEFT JOIN garde toutes les lignes de la table de gauche, complétées par NULL à droite si aucune correspondance

]]> Bonne réponse : pour lister tous les clients avec
leurs commandes (ou pas), on utilise LEFT JOIN. Avec
INNER JOIN, les clients sans commande disparaissent
du résultat.

]]> Aucune, ce sont des synonymes

]]> Erreur : ils diffèrent sur la gestion des lignes non
appariées de la table de gauche.

]]> LEFT JOIN ne fonctionne que sur des tables triées

]]> Erreur : aucune contrainte de tri n'est requise pour
un LEFT JOIN.

]]> INNER JOIN est plus rapide que LEFT JOIN

]]> Erreur : la performance dépend du SGBD et du contexte.
La différence sémantique est ce qui compte avant
tout.

]]> Bases de données et SQL — Q24 : Problème de concurrence Sans isolation des transactions, deux transactions
simultanées qui modifient le même compte bancaire peuvent
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 : l'effet d'une transaction est annulé par l'autre, faisant disparaître un dépôt

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

]]> Une erreur de syntaxe SQL

]]> 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 transactions

]]> Erreur : sans isolation, on a au contraire des
incohérences. La gestion correcte est plus lente mais
fiable.

]]> Bases de données et SQL — Q25 : Index Pourquoi crée-t-on des index sur les colonnes
fréquemment utilisées dans des WHERE ou des jointures ?

]]> Compromis classique : un index accélère les lectures
mais ralentit les écritures (chaque insertion ou mise
à jour doit aussi mettre à jour l'index). On crée donc des
index uniquement sur les colonnes vraiment souvent
interrogées.

]]> 1.0 0.0 0 true true abc Pour accélérer la recherche en évitant un parcours complet de la table

]]> Bonne réponse : un index est une structure
auxiliaire qui permet de retrouver rapidement
les lignes correspondant à une valeur donnée,
sans avoir à parcourir toute la table.

]]> Pour économiser de l'espace de stockage

]]> Erreur : c'est l'inverse, un index consomme de
l'espace supplémentaire. Le bénéfice est ailleurs.

]]> Pour rendre les données automatiquement triées

]]> Erreur : un index trie en interne, mais les données
de la table elle-même restent dans leur ordre
original.

]]> Pour chiffrer les données sensibles

]]> Erreur : les index sont des structures de performance,
pas de sécurité.

]]> Bases de données et SQL — Q26 : Regroupement avec GROUP BY Pour obtenir le nombre d'élèves par classe dans la
table eleves(id, nom, classe), quelle requête utiliser ?

]]> Schéma général : SELECT colonne, AGREGATION(...) FROM
table GROUP BY colonne. Toutes les colonnes du SELECT
qui ne sont pas dans une fonction d'agrégation doivent
apparaître dans le GROUP BY. C'est la règle dite
« des colonnes visibles ».

]]> 1.0 0.0 0 true true abc `



SELECT classe, COUNT(*)

FROM eleves;

]]> Erreur : sans GROUP BY, mélanger une colonne et une
fonction d'agrégation provoque une erreur SQL ou un
résultat incohérent (selon le SGBD). Il faut grouper
explicitement par classe.

]]> `



SELECT DISTINCT classe, COUNT(*)

FROM eleves;

]]> Erreur : DISTINCT élimine les doublons après calcul,
il ne sert pas à regrouper pour appliquer une
agrégation. La syntaxe correcte est GROUP BY.

]]> `



SELECT classe, COUNT(eleves)

FROM eleves

GROUP BY classe;

]]> Erreur : COUNT(eleves) n'est pas valide :
eleves est le nom de la table, pas une colonne.
Pour compter les lignes, on utilise COUNT(*) ou une
colonne précise (COUNT(id)).

]]> `



SELECT classe, COUNT(*)

FROM eleves

GROUP BY classe;

]]> Bonne réponse : GROUP BY regroupe les lignes par
valeur distincte de classe. La fonction d'agrégation
COUNT(*) compte les lignes de chaque groupe. Le
résultat est une ligne par classe avec son effectif.

]]> Bases de données et SQL — Q27 : HAVING vs WHERE Pour ne garder que les classes ayant au moins
25 élèves, on doit filtrer un résultat agrégé. Quelle
est la requête correcte ?

]]> Ordre canonique des clauses :
SELECT ... FROM ... WHERE ... GROUP BY ... HAVING ... ORDER BY.
Mnémonique : WHERE filtre les lignes individuelles avant
regroupement ; HAVING filtre les groupes après agrégation.

]]> 1.0 0.0 0 true true abc `



SELECT classe

FROM eleves

GROUP BY classe

WHERE COUNT(*) >= 25;

]]> Erreur : la clause WHERE doit toujours apparaître
avant GROUP BY dans la syntaxe SQL. De plus,
on ne peut pas y mettre une fonction d'agrégation.

]]> `



SELECT classe, COUNT()

FROM eleves

WHERE COUNT() >= 25

GROUP BY classe;

]]> Erreur : WHERE ne peut pas porter sur une fonction
d'agrégation, qui n'est calculée qu'après le
regroupement. Cette requête échoue avec une erreur
SQL. C'est précisément le rôle de HAVING.

]]> `



SELECT classe, COUNT()

FROM eleves

HAVING classe COUNT() >= 25;

]]> Erreur : la syntaxe est invalide. HAVING doit
contenir une condition logique, et il manque le
GROUP BY qui définit les groupes sur lesquels
porte le HAVING.

]]> `



SELECT classe, COUNT()

FROM eleves

GROUP BY classe

HAVING COUNT() >= 25;

]]> Bonne réponse : HAVING filtre les groupes après
agrégation, contrairement à WHERE qui filtre les
lignes avant agrégation. Pour porter sur le résultat
de COUNT(*), il faut utiliser HAVING.

]]> Bases de données et SQL — Q28 : Propriétés ACID Les propriétés ACID des transactions garantissent leur
bon comportement dans un SGBD. Que désigne le « C » de
ACID ?

]]> Les quatre propriétés ACID sont : Atomicité (tout
ou rien), Cohérence (contraintes respectées),
Isolation (transactions concurrentes invisibles
les unes aux autres), Durabilité (modifications
persistées même en cas de panne). Indispensable pour
les bases métier (banque, santé, stock).

]]> 1.0 0.0 0 true true abc Compression

]]> Erreur : la compression est une optimisation de
stockage, sans rapport avec les transactions.

]]> Confidentialité

]]> Erreur : la confidentialité relève de la sécurité
(chiffrement, contrôle d'accès), pas des propriétés
ACID des transactions. Ce sont deux dimensions
différentes du SGBD.

]]> Connexion

]]> Erreur : la connexion à la base est un mécanisme
d'accès, pas une propriété des transactions. Le
« C » désigne une propriété logique des transactions.

]]> Cohérence

]]> Bonne réponse : la cohérence garantit qu'une
transaction fait passer la base d'un état cohérent
(toutes les contraintes respectées) à un autre état
cohérent. Si une transaction violerait une
contrainte d'intégrité, elle est rejetée
intégralement.

]]> Bases de données et SQL — Q29 : DROP, DELETE, TRUNCATE Quelle est la différence entre DROP TABLE eleves,
DELETE FROM eleves et TRUNCATE TABLE eleves ?

]]> Bonne pratique : utiliser DELETE FROM ... WHERE pour
des suppressions ciblées et sécurisées ; TRUNCATE pour
vider rapidement une table en conservant son schéma ;
DROP TABLE uniquement quand on veut effectivement se
débarrasser de la table elle-même. Toujours sauvegarder
avant DROP.

]]> 1.0 0.0 0 true true abc Aucune n'est valide en SQL standard

]]> Erreur : les trois sont des commandes SQL valides.
TRUNCATE est légèrement moins répandu que les
deux autres, mais reste standard dans la plupart
des SGBD relationnels.

]]> DROP et DELETE sont identiques ; seul
TRUNCATE est différent (il vide aussi les
fichiers de log)

]]> Erreur : DROP TABLE et DELETE FROM ne sont
pas équivalents. Le premier supprime la
structure de la table ; le second ne supprime
que les lignes.

]]> Les trois commandes sont équivalentes

]]> Erreur : elles ont des effets très différents,
comme le détaille la bonne réponse. Confondre
DROP et DELETE peut être catastrophique en
production : DROP supprime tout, structure
comprise.

]]> DROP TABLE supprime la table entière (structure et
contenu) ; DELETE FROM (sans WHERE) supprime
toutes les lignes mais conserve la structure (les
contraintes et les types restent) ; TRUNCATE TABLE
vide rapidement le contenu en conservant la
structure (souvent plus rapide que DELETE)

]]> Bonne réponse : trois commandes très différentes.
DROP est destructif sur le schéma : la table
n'existe plus du tout après. DELETE est une
opération transactionnelle au cas par cas (logge
chaque suppression). TRUNCATE est une opération
en bloc, sans logging détaillé, généralement plus
rapide pour vider une grosse table.

]]> 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 ?

`sql 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 : ('Alice', 14.5),
('Chloé', 16.0), ('Émma', 11.5)

]]> Erreur : Émma est en 1A mais sa moyenne
(11{,}5) est inférieure à 12, donc elle
ne satisfait pas la condition moyenne >= 12.
De plus, l'ordre n'est pas décroissant ici.

]]> 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 elle aussi les deux
conditions (14{,}5 \geq 12 et classe
1A). Elle doit donc apparaître dans le
résultat, après Chloé 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 ?

`sql SELECT c.nom, cmd.produit FROM clients c JOIN commandes cmd ON c.id = cmd.client_id;`

]]> Pour faire apparaître Chloé (qui n'a aucune
commande) dans le résultat, il faudrait
utiliser un LEFT JOIN. La ligne
correspondante aurait alors NULL dans la
colonne cmd.produit. Cela permet de
répondre à la question « tous les clients,
avec leurs commandes éventuelles ».

]]> 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 (le produit cartésien 3 × 3)

]]> Erreur : ce serait le résultat sans la
condition ON c.id = cmd.client_id. Avec
la condition, on ne garde que les paires
cohérentes, soit trois lignes ici. Le
produit cartésien apparaît avec
FROM clients, commandes (sans JOIN).

]]> 4 lignes

]]> Erreur : seules trois commandes existent,
donc au plus trois lignes peuvent
apparaître. Une ligne supplémentaire
n'apparaîtrait que si l'on utilisait un
LEFT JOIN qui inclurait Chloé sans
commande (avec NULL côté commandes).

]]> Bases de données et SQL — Q32 : GROUP BY avec HAVING en pratique Avec la table eleves(id, nom, classe, moyenne)
contenant trente élèves répartis entre trois
classes (1A, 1B, 1C), que renvoie la
requête suivante ?

`sql SELECT classe, AVG(moyenne) AS moy_classe FROM eleves GROUP BY classe HAVING AVG(moyenne) > 12 ORDER BY moy_classe DESC;`

]]> Distinction essentielle : WHERE filtre les
lignes individuelles avant l'agrégation ;
HAVING filtre les groupes après
l'agrégation. Si on voulait restreindre aux
élèves majeurs avant de calculer les moyennes,
on aurait combiné les deux :
WHERE age >= 18 ... HAVING AVG(moyenne) > 12.

]]> 1.0 0.0 0 true true abc La liste des classes dont la moyenne de
la classe est strictement supérieure à
12, avec leur moyenne, triée par
moyenne décroissante

]]> Bonne réponse. Étape 1, GROUP BY classe
regroupe les élèves par classe. Étape 2,
AVG(moyenne) calcule la moyenne de chaque
groupe. Étape 3, HAVING AVG(moyenne) > 12
filtre les groupes (et non les lignes
individuelles) selon cette condition.
Étape 4, ORDER BY moy_classe DESC trie
le résultat.

]]> Une erreur SQL, car on ne peut pas mettre
un alias dans ORDER BY

]]> Erreur : SQL autorise tout à fait
d'utiliser un alias défini dans le
SELECT (ici moy_classe) au sein de
ORDER BY. La requête est valide.

]]> Toutes les classes, avec la somme des
moyennes des élèves

]]> Erreur : la fonction utilisée est AVG
(moyenne), pas SUM (somme). Les deux
fonctions d'agrégation sont distinctes.
De plus, le HAVING filtrerait certaines
classes.

]]> La liste des élèves dont la moyenne
individuelle est supérieure à 12

]]> Erreur : c'est ce que ferait un simple
WHERE moyenne > 12 sans GROUP BY. Ici,
la fonction d'agrégation AVG(moyenne)
combinée à GROUP BY classe calcule la
moyenne par classe, pas par élève.

]]> Bases de données et SQL — Q33 : Notion de vue Une vue (VIEW) en SQL est :

]]> Les vues facilitent aussi la sécurité : on
peut accorder l'accès à une vue qui masque
certaines colonnes sensibles, sans donner
accès aux tables sous-jacentes. Variante
avancée : la vue matérialisée stocke
effectivement le résultat, et est rafraîchie
périodiquement ; elle combine vue et cache.

]]> 1.0 0.0 0 true true abc Une requête nommée dont le résultat se
comporte comme une table virtuelle :
chaque interrogation de la vue
réexécute la requête sous-jacente sur les
données actuelles

]]> Bonne réponse : on définit une vue avec
CREATE VIEW majeurs AS SELECT ... FROM
eleves WHERE age >= 18;. Ensuite,
SELECT * FROM majeurs renvoie le résultat
actualisé. Avantages : factoriser des
requêtes complexes, masquer certaines
colonnes (sécurité), simplifier l'écriture
des requêtes. La vue ne stocke pas les
données, elle stocke la requête.

]]> Une représentation graphique des relations
entre les tables

]]> Erreur : une représentation graphique
s'appelle un schéma ou un diagramme
entité-association, pas une vue. La vue est
une notion logique (une requête nommée),
pas une représentation visuelle.

]]> Un type particulier d'index pour accélérer
les recherches

]]> Erreur : un index est une structure
auxiliaire de performance ; une vue est une
requête nommée. Ces deux notions sont
totalement distinctes, même si certains
SGBD permettent des « vues matérialisées »
qui s'apparentent à un index.

]]> Une copie figée des données à un instant
donné

]]> Erreur : ce serait une table (par
exemple créée via CREATE TABLE ... AS
SELECT ...). La vue, elle, ne contient pas
de données : elle contient une requête,
réévaluée à chaque interrogation pour
refléter l'état courant des tables source.

]]> 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 #` 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 n-aire 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 table notes a une clé primaire
composite (id_eleve, id_devoir), et ses
deux composantes sont des clés étrangères
référençant respectivement eleves et
devoirs

]]> Bonne réponse : c'est la lecture correcte
du schéma. La table notes représente une
association ternaire (un élève, un devoir,
une 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 :

`python 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.

]]> La requête devient
SELECT * FROM users WHERE nom = '' OR '1'='1';,
ce qui sélectionne toutes les lignes
de la table : c'est une injection SQL

]]> Bonne réponse : 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 :

`sql 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)
satisfont bien la condition solde >= 1000,
donc leurs lignes sont modifiées. La
condition n'est pas trop restrictive : elle
est ciblée.

]]>