NSI Terminale • Programme français, lycées de Montréal

Fiche de révision : bases de données relationnelles et SQL

Le chapitre des bases de données est celui où l'erreur ne se voit pas : une jointure sans condition rend un tableau, un filtre placé au mauvais endroit rend un tableau, une moyenne de moyennes rend un nombre. Tout est plausible, et seul le compte des lignes permet de savoir si la requête a fait ce qu'on croyait.

Cette fiche liste les dix erreurs qui reviennent dans les copies, avec la requête exacte à écrire à la place et ce que chacune coûte au barème. Elle s'en tient aux clauses du programme de Terminale, qui autorise les fonctions d'agrégation sans les clauses GROUP BY et HAVING ; ces deux clauses sont présentées à part, pour aller plus loin.

Marque ici la fiche comme lue ou mets-la en favori : un compte gratuit, sans mot de passe, retient tes fiches lues et tes favoris d'une visite à l'autre, te dit quel chapitre attaquer ensuite et te permet de demander la méthode ou l'exercice qui te manque. Crée ton espace, un courriel suffit.

Le fil du chapitre

Une requête SQL fausse ne plante presque jamais : elle rend un tableau plausible, et c'est le NOMBRE de lignes, pas leur contenu, qui trahit l'erreur.

Ce chapitre fait partie de NSI en Terminale

Pour s'entraîner Les exercices corrigés de ce chapitre, 16 exercices

Avant ce chapitre

Cette fiche suppose ces notions acquises. Si une méthode ci-dessous reste opaque, c'est presque toujours l'une d'elles qui manque, pas la fiche.

Traitement de données en tables et types construitsPremière Exercices

Remonter plus loin : la chaîne complète (4 chapitres) ↓

Le chemin de remédiation, du plus ancien au plus proche. Un élève qui reprend ce chapitre de zéro le reprend dans cet ordre.

1Algorithmique et ScratchTroisième, Mathématiques
2Algorithmique et PythonSeconde, Mathématiques
3Python : types, contrôle, fonctions et tableauxPremière
4Traitement de données en tables et types construitsPremière

L'essentiel

Le vocabulaire qui est noté

• Une relation a un DEGRÉ, son nombre d'attributs, et une CARDINALITÉ, son nombre de lignes. Chaque ligne est un fait.
• Clé primaire : unique, non nulle et STABLE. Un identifiant artificiel vaut mieux qu'une donnée métier, qui peut changer.
• Clé étrangère : sa valeur doit exister comme clé primaire dans une autre table. La contrainte pèse sur la table qui RÉFÉRENCE, pas sur celle qui est référencée.
• Trois anomalies justifient la séparation en plusieurs tables : mise à jour, insertion, suppression. Les nommer vaut les points.

Une question « justifiez le choix de la clé primaire » attend trois mots : unique, non nulle, stable. Les écrire tous les trois rapporte plus que la meilleure des explications.

L'ordre d'exécution, qui n'est pas l'ordre d'écriture

• FROM et les jointures d'abord, puis WHERE, puis SELECT avec ses fonctions d'agrégation, puis ORDER BY.
• WHERE filtre des LIGNES. COUNT, SUM, AVG, MIN et MAX s'appliquent ENSUITE aux seules lignes retenues, et rendent UNE ligne.
• Une colonne ordinaire ne se met pas à côté d'un agrégat dans le SELECT : l'une a une valeur par ligne, l'autre une seule pour toutes.
• Un alias défini dans le SELECT n'existe pas encore quand le WHERE s'exécute ; un ORDER BY, qui vient après, peut l'utiliser.

Le compte des lignes chute à chaque étape : 60, puis 4 après le WHERE, puis 1 après l'agrégat. L'étape en pointillé, GROUP BY et HAVING, est hors programme en Terminale.

Écrire le compte des lignes après chaque étape, même approximatif, transforme une requête devinée en requête justifiée.

La valeur nulle n'est pas une valeur

• NULL signifie « inconnue » : toute comparaison avec elle rend « inconnu », donc jamais vrai.
• On écrit IS NULL et IS NOT NULL, jamais un signe égale ni un signe différent.
• Une fonction d'agrégat IGNORE les valeurs nulles : une moyenne sur 30 lignes dont 4 nulles porte sur 26 valeurs.
• COUNT d'une colonne compte les valeurs non nulles ; COUNT sans colonne compte toutes les lignes.

La même colonne interrogée deux fois : la comparaison par égalité ne trouve jamais la ligne inconnue, seul IS NULL la ramène.

Les transactions

• Atomicité : tout ou rien. Cohérence : les contraintes restent vérifiées. Isolation : les transactions concurrentes ne s'observent pas. Durabilité : ce qui est validé survit à la panne.
• La mise à jour perdue est une violation d'ISOLATION : deux lectures, deux écritures, une modification effacée.
• Le remède est le verrouillage, aussi court que possible : un verrou long garantit l'isolation et bloque tout le monde.
• Une lecture suivie d'une écriture sur la même donnée forme une section critique, exactement comme en programmation concurrente.

Pour aller plus loin, hors programme : GROUP BY et HAVING

• Le programme de Terminale autorise les fonctions d'agrégation « sans utiliser les clauses GROUP BY et HAVING » : ces deux clauses ne sont pas exigibles, et une copie n'en a jamais besoin.
• GROUP BY X découpe les lignes retenues par le WHERE en un groupe par valeur de X, et chaque agrégat se calcule alors par groupe : une ligne par groupe.
• HAVING filtre des GROUPES, après le GROUP BY : c'est le seul filtre qui puisse porter sur un agrégat. WHERE, lui, filtre des lignes, avant.
• Ordre complet d'exécution : FROM, JOIN, WHERE, GROUP BY, HAVING, SELECT, ORDER BY.

Sans GROUP BY, la même question se traite par une requête par valeur de X, filtrée dans le WHERE : les nombres sont les mêmes, et la somme des comptes redonne le total.

Les pièges qui coûtent des points

Les erreurs ci-dessous sont celles que je corrige le plus souvent en séance. Chacune coûte des points sur une copie, même quand le raisonnement est juste.

1. Écrire une jointure sans condition

toute la question, et toutes celles qui réutilisent la requête

Ce qu'il ne faut pas écrire

« SELECT * FROM emprunt, livre : ça me donne les emprunts avec leur livre. »

Ce qu'il faut écrire

« Sans condition de jointure, on obtient le PRODUIT CARTÉSIEN : chaque emprunt apparié à chaque livre. J'écris JOIN livre ON emprunt.id_livre = livre.id. »

Quatre lignes appariées à trois lignes en donnent douze : le tableau obtenu est plausible, et seul son nombre de lignes révèle la condition manquante.

Pourquoi : Aucune erreur n'est levée : le résultat est un tableau de $4 \times 3 = 12$ lignes là où on en attendait 4. Le symptôme est toujours le même, un nombre de lignes multiple de l'attendu.

2. Écrire une fonction d'agrégation dans le WHERE

2 points, et la requête est refusée par le moteur

Ce qu'il ne faut pas écrire

« SELECT nom FROM eleve WHERE note = MAX(note), pour trouver l'élève qui a la meilleure note. »

Ce qu'il faut écrire

« Une fonction d'agrégation ne s'écrit pas dans un WHERE : SELECT MAX(note) FROM eleve donne 18, puis SELECT nom FROM eleve WHERE note = 18. Ou bien SELECT nom, note FROM eleve ORDER BY note DESC, et je lis la première ligne. »

Pourquoi : Le WHERE examine les lignes une à une, avant que l'agrégat soit calculé sur l'ensemble : il ne peut donc pas s'y référer. Avec les clauses du programme, on calcule l'agrégat d'abord, puis on reporte sa valeur.

3. Mêler une colonne ordinaire et un agrégat dans le SELECT

1 à 2 points, même quand le moteur renvoie par chance la bonne ligne

Ce qu'il ne faut pas écrire

« SELECT velo, MAX(duree) FROM trajet : voilà le vélo qui a fait le plus long trajet. »

Ce qu'il faut écrire

« SELECT MAX(duree) FROM trajet donne 34, puis SELECT velo FROM trajet WHERE duree = 34 donne V5. En cas d'égalité, j'obtiens tous les vélos concernés. »

Pourquoi : velo a une valeur par ligne, MAX une seule pour toutes : la norme SQL refuse ce mélange. Certains moteurs l'acceptent et choisissent la ligne selon leurs propres règles, ce qu'une copie ne peut pas invoquer.

4. Comparer une valeur nulle avec un signe égale

1 point, et la requête renvoie zéro ligne sans erreur

Ce qu'il ne faut pas écrire

« SELECT * FROM eleve WHERE note = NULL pour trouver les notes manquantes. »

Ce qu'il faut écrire

« SELECT * FROM eleve WHERE note IS NULL : la comparaison par égalité avec une valeur inconnue rend « inconnu », donc aucune ligne. »

Pourquoi : NULL n'est pas une valeur mais l'absence de valeur : deux inconnues ne sont pas égales, elles sont indéterminées. C'est pour cela que SQL a inventé un opérateur dédié.

5. Oublier DISTINCT après une jointure

1 point, et la question « combien d'auteurs » devient fausse

Ce qu'il ne faut pas écrire

« SELECT nom FROM auteur JOIN livre ON ... WHERE annee > 2000 : voilà la liste des auteurs. »

Ce qu'il faut écrire

« Un auteur ayant trois livres apparaît trois fois : SELECT DISTINCT nom, dès que l'on projette sur une table après un filtre portant sur une table liée. »

Pourquoi : La jointure duplique les lignes de la table de gauche autant de fois qu'elles ont de correspondances à droite. La projection ne supprime pas ces doublons, elle les rend seulement invisibles.

6. Faire la moyenne des moyennes

2 points sur la question d'agrégation, et la conclusion du sujet en dépend

Ce qu'il ne faut pas écrire

« La classe A a 14 de moyenne sur 3 élèves et la classe B a 8 sur 1 élève, donc l'établissement est à 11. »

Ce qu'il faut écrire

« La moyenne pondérée s'écrit SUM(note) / COUNT(note), ou SUM(valeur * coefficient) / SUM(coefficient) : elle vaut ici $(42 + 8)/4 = 12{,}5$ . »

Pourquoi : Une moyenne est un rapport, et les rapports ne s'additionnent pas. La moyenne des moyennes ne serait juste que si tous les groupes avaient le même effectif.

7. Choisir une donnée métier comme clé primaire

1 point, et toute la question de conception qui suit

Ce qu'il ne faut pas écrire

« L'adresse de courriel identifie l'élève de façon unique, elle fera une bonne clé primaire. »

Ce qu'il faut écrire

« Une clé primaire doit être STABLE : un courriel change. Je crée un identifiant artificiel, et je mets une contrainte d'unicité sur le courriel. »

Pourquoi : Changer une clé primaire oblige à mettre à jour toutes les clés étrangères qui la référencent. L'identifiant artificiel n'a aucune raison de changer, c'est précisément sa qualité.

8. Croire que la contrainte de clé étrangère pèse sur la table référencée

1 point, et le schéma proposé est inversé

Ce qu'il ne faut pas écrire

« La table livre a une clé étrangère vers emprunt, donc on ne peut pas ajouter d'emprunt inconnu. »

Ce qu'il faut écrire

« La clé étrangère est portée par la table qui RÉFÉRENCE : c'est emprunt qui pointe vers livre, et c'est donc l'insertion dans emprunt qui est contrôlée. »

Pourquoi : Le sens de la référence décide de tout : quelle insertion est refusée, quelle suppression est bloquée. L'inverser rend le schéma incapable d'exprimer un livre sans emprunt.

9. Écrire un UPDATE ou un DELETE sans WHERE

2 points, et la question suivante décrit une base entièrement fausse

Ce qu'il ne faut pas écrire

« UPDATE livre SET disponible = 0 pour marquer ce livre comme sorti. »

Ce qu'il faut écrire

« Sans WHERE, la mise à jour touche TOUTE la table : UPDATE livre SET disponible = 0 WHERE id = 42. »

Pourquoi : SQL applique par défaut l'opération à toutes les lignes. C'est aussi l'accident réel le plus courant en base de données, et le sujet le teste presque toujours sous forme de question à corriger.

10. Croire que le SELECT s'exécute en premier

1 point, et la requête est refusée

Ce qu'il ne faut pas écrire

« SELECT prix * 1.2 AS ttc FROM article WHERE ttc > 20. »

Ce qu'il faut écrire

« L'alias ttc est créé par le SELECT, qui s'exécute APRÈS le WHERE : j'écris WHERE prix * 1.2 > 20. Dans un ORDER BY, qui vient après le SELECT, ORDER BY ttc est permis. »

Pourquoi : L'ordre d'écriture d'une requête n'est pas son ordre d'exécution. Retenir la chaîne FROM, JOIN, WHERE, SELECT, ORDER BY résout à lui seul trois pièges du chapitre.

Quelle méthode choisir

Où écrire la condition

Ce sur quoi porte la condition : une colonne d'une ligne, le lien entre deux tables, ou une fonction d'agrégation.

Si la condition porte sur une colonne d'une ligne → WHERE

Exemple : WHERE annee > 2000
Si la condition relie deux tables → condition de jointure dans le ON

Exemple : JOIN livre ON emprunt.id_livre = livre.id
Si la condition contient COUNT, SUM, AVG, MIN ou MAX → deux requêtes : calculer l'agrégat, puis reporter sa valeur dans un WHERE

Exemple : SELECT MAX(note) FROM eleve donne 18, puis WHERE note = 18
Si la condition porte sur un alias du SELECT → répéter l'expression dans le WHERE

Exemple : WHERE prix * 1.2 > 20, jamais WHERE ttc > 20

Au programme de Terminale, ni GROUP BY ni HAVING : une condition sur un agrégat se traite en deux temps, l'agrégat d'abord, sa valeur reportée ensuite dans un WHERE. HAVING, qui filtre des groupes, est un approfondissement.

Quelle requête pour quelle question

Le mot de l'énoncé : « combien », « pour chaque », « le plus », « la liste des ».

Si « combien de », sans découpage → SELECT COUNT(*) avec un WHERE

Exemple : combien d'emprunts en retard
Si « pour chaque X, le nombre de Y » → une requête COUNT(*) par valeur de X, filtrée dans le WHERE, et la somme des comptes redonne le total

Exemple : 4 + 2 + 2 = 8 trajets pour trois stations

GROUP BY X le ferait en une requête, mais il est hors programme
Si « le plus grand », « le plus petit » → MAX ou MIN, puis un WHERE sur la valeur trouvée, ou ORDER BY et la première ligne

Exemple : MAX(duree) vaut 34, puis WHERE duree = 34
Si « la liste des X qui ont un Y tel que... » → jointure, puis SELECT DISTINCT

Exemple : les auteurs publiés après 2000

sans DISTINCT, un auteur apparaît autant de fois qu'il a de livres
Si « la moyenne sur l'ensemble » → SUM divisé par COUNT, jamais une moyenne de moyennes

Exemple : $(42 + 8)/4$ , jamais $(14 + 8)/2$

Si aucune branche ne s'applique, c'est une composition : une jointure, un filtre de lignes, puis un agrégat ou un tri.

La rédaction attendue

Le correcteur coche des étapes. Les voici dans l'ordre, avec la phrase de conclusion qu'il attend mot pour mot.

Écrire une requête et la justifier

Quand l'utiliser : L'énoncé donne un schéma et demande une requête en français.

1 Repérer les tables nécessaires, et écrire une condition de jointure par table ajoutée : $k$ tables demandent $k-1$ conditions.
2 Écrire le filtre de lignes dans le WHERE, avec les colonnes des tables jointes.
3 Si l'énoncé demande un nombre, un total, une moyenne ou un extremum, placer la fonction d'agrégation dans le SELECT : elle résume en UNE ligne les lignes retenues par le WHERE.
4 Si l'énoncé dit « pour chaque », écrire une requête par valeur, filtrée dans le WHERE, et vérifier que la somme des comptes redonne le total.
5 Projeter en dernier, en ajoutant DISTINCT si la jointure a pu dupliquer des lignes, puis trier si l'énoncé le demande.

Phrase de conclusion

« SELECT COUNT(*), AVG(emprunt.jours) FROM emprunt JOIN lecteur ON emprunt.id_lecteur = lecteur.id WHERE emprunt.rendu = 0 AND lecteur.nom = 'Martin' : une table jointe donc une condition de jointure, le filtre sur les lignes dans le WHERE, et les agrégats appliqués aux seules lignes retenues. »

Le piège : Ajouter une table dans le FROM sans ajouter sa condition de jointure : le résultat est un produit cartésien silencieux.

Barème : 1 point par condition de jointure, 1 point pour le WHERE, 1 point pour les fonctions d'agrégation, 1 point pour la projection.

Justifier la séparation en plusieurs tables

Quand l'utiliser : L'énoncé montre une table unique redondante et demande pourquoi la découper.

1 Montrer la redondance sur une ligne précise du tableau donné : la même information répétée.
2 Nommer l'anomalie de MISE À JOUR : corriger l'adresse d'un lecteur oblige à modifier toutes ses lignes, et une seule oubliée rend la base incohérente.
3 Nommer l'anomalie d'INSERTION : impossible d'enregistrer un lecteur qui n'a pas encore emprunté.
4 Nommer l'anomalie de SUPPRESSION : supprimer le dernier emprunt d'un lecteur efface aussi le lecteur.
5 Donner le découpage proposé, avec la clé primaire de chaque table et la clé étrangère qui les relie.

Phrase de conclusion

« La table unique répète l'adresse du lecteur à chaque emprunt, ce qui expose aux trois anomalies. On sépare en une table lecteur, de clé primaire id_lecteur, et une table emprunt, dont la clé étrangère id_lecteur référence la précédente. »

Le piège : Se contenter de dire « c'est redondant » : le barème attend les trois anomalies nommées, une par une.

Barème : 1 point par anomalie nommée et illustrée, 1 point pour le schéma corrigé.

Vérifier avant de rendre

Cinq minutes de vérification récupèrent plus de points qu'un exercice de plus commencé à la hâte.

Compter les lignes attendues avant d'exécuter

Annoncer le nombre de lignes que la requête devrait rendre, puis comparer. Un multiple exact de l'attendu signale une jointure sans condition.

Douze lignes au lieu de quatre, avec trois livres dans la base : la condition de jointure manque.
Compter les conditions de jointure

Avec $k$ tables dans le FROM, il faut $k-1$ conditions de jointure. Moins, et il reste un produit cartésien.

Trois tables et une seule condition : une table est appariée à toutes les lignes des autres.
Relire les valeurs nulles

Pour chaque colonne susceptible d'être nulle, vérifier qu'aucune comparaison n'utilise un signe égale, et se demander si l'agrégat doit ou non les ignorer.

Une moyenne calculée sur 26 valeurs dans une table de 30 lignes indique quatre notes nulles, ignorées par AVG.
Vérifier la place de chaque filtre

Aucune fonction d'agrégation dans un WHERE, ni à côté d'une colonne ordinaire dans le SELECT. Une condition sur un agrégat se traite en deux requêtes.

WHERE COUNT(*) > 3 est refusée par le moteur, quel que soit le sujet.
La somme des comptes redonne le total

Après une requête par valeur, additionner les comptes obtenus et les comparer au COUNT(*) de la table entière.

$4+2+2=8$ trajets pour trois stations : aucune n'est oubliée. Une somme de $7$ signalerait une station omise ou un filtre mal écrit.

L'exercice type décortiqué

La bibliothèque : les emprunts en cours d'une lectrice et leur durée moyenne

Le schéma comporte lecteur, de clé primaire id et d'attribut nom, et emprunt, d'attributs id, id_lecteur, id_livre, rendu et jours, où rendu vaut 0 tant que le livre n'est pas revenu et jours compte les jours écoulés depuis l'emprunt. La table emprunt compte 60 lignes, dont 18 emprunts en cours, et la table lecteur 25 lignes.

Écrire, sans GROUP BY, la requête qui donne le nombre d'emprunts en cours de la lectrice Martin et leur durée moyenne.

Étape 1

FROM emprunt JOIN lecteur ON emprunt.id_lecteur = lecteur.id : 60 lignes, une par emprunt.

Pourquoi

Le nom est dans lecteur, la durée dans emprunt : deux tables, donc exactement une condition de jointure. Sans elle, le produit cartésien donnerait $60\times 25=1\,500$ lignes, et tous les comptes suivants seraient faux sans message d'erreur.

Étape 2

WHERE emprunt.rendu = 0 AND lecteur.nom = 'Martin' : il reste 4 lignes.

Pourquoi

Les deux conditions portent sur des colonnes d'une ligne, donc elles vont dans le WHERE. Filtrer AVANT l'agrégat change le résultat : les emprunts rendus ne doivent pas compter.

Étape 3

SELECT COUNT(*), AVG(emprunt.jours) : les 4 lignes, de 12, 30, 7 et 19 jours, deviennent UNE ligne, 4 et $\frac{68}{4}=17$ .

Pourquoi

Les fonctions d'agrégation s'appliquent aux seules lignes retenues par le WHERE. On n'ajoute pas lecteur.nom dans le SELECT : une colonne ordinaire à côté d'un agrégat est refusée par la norme.

Étape 4

Pour tous les lecteurs, pas de GROUP BY : une requête par nom, en changeant la valeur du WHERE.

Pourquoi

Le programme exclut GROUP BY et HAVING. La somme des comptes de tous les lecteurs doit redonner les 18 emprunts en cours : c'est le contrôle qui prouve qu'aucun n'est oublié.

Étape 5

Vérification : $4\leqslant 18$ emprunts en cours, et la moyenne $17$ est comprise entre $7$ et $30$ .

Pourquoi

Ce contrôle ne refait pas la requête. Un compte supérieur à 18 signalerait une jointure sans condition ; et s'il existe deux lecteurs nommés Martin, le compte les mélange : c'est alors sur lecteur.id, la clé primaire, qu'il faut filtrer.

Conclusion rédigée

« SELECT COUNT(*), AVG(emprunt.jours) FROM emprunt JOIN lecteur ON emprunt.id_lecteur = lecteur.id WHERE emprunt.rendu = 0 AND lecteur.nom = 'Martin'. Le résultat est une ligne : 4 emprunts en cours, 17 jours en moyenne. »

L'erreur classique sur cet exercice : Écrire SELECT lecteur.nom, COUNT(*) FROM ... WHERE emprunt.rendu = 0 en espérant un compte par lecteur : sans GROUP BY, hors programme, la requête résume les 18 lignes en une seule, et le nom affiché ne veut rien dire.

À savoir par cœur

• Ordre d'exécution : FROM, JOIN, WHERE, SELECT, ORDER BY.
• WHERE filtre des LIGNES ; une fonction d'agrégation résume les lignes retenues en UNE ligne, et ne s'écrit jamais dans un WHERE.
• « Pour chaque » valeur, au programme : une requête par valeur, et la somme des comptes redonne le total.
• $k$ tables dans le FROM demandent $k-1$ conditions de jointure. Sinon, produit cartésien silencieux.
• IS NULL et IS NOT NULL, jamais un signe égale : toute comparaison avec NULL rend « inconnu ».
• DISTINCT dès qu'on projette après une jointure qui peut dupliquer.
• Moyenne pondérée : SUM sur SUM, jamais une moyenne de moyennes.
• Clé primaire : unique, non nulle, STABLE. Clé étrangère : portée par la table qui référence.
• Trois anomalies à nommer : mise à jour, insertion, suppression.
• ACID : atomicité, cohérence, isolation, durabilité. La mise à jour perdue viole l'isolation.

Questions fréquentes

Quelle est la différence entre WHERE et HAVING en SQL ?

En NSI, le programme de Terminale exclut les clauses GROUP BY et HAVING : seul WHERE est exigible. WHERE filtre des lignes, avant tout calcul ; HAVING, hors programme, filtre les groupes formés par GROUP BY. Une condition sur une moyenne ou un maximum se traite donc en deux requêtes : on calcule l'agrégat, puis on reporte sa valeur dans un WHERE.

Comment compter pour chaque valeur sans GROUP BY en SQL ?

On écrit une requête par valeur, en changeant la valeur filtrée dans le WHERE : un COUNT avec WHERE depart_id égal à 1, puis à 2, puis à 3. On vérifie ensuite que la somme des comptes redonne le nombre total de lignes, obtenu par un COUNT sans filtre. GROUP BY ferait tout en une requête, mais il n'est pas au programme de Terminale.

Pourquoi ma jointure donne-t-elle trop de lignes ?

Presque toujours parce qu'une condition de jointure manque : sans elle, chaque ligne de la première table est appariée à chaque ligne de la seconde, ce qui donne le produit cartésien. Il faut une condition par table ajoutée, donc deux conditions pour trois tables. Le symptôme est un nombre de lignes multiple exact du nombre attendu.

Comment chercher les valeurs manquantes dans une base de données ?

Avec IS NULL, jamais avec un signe égale. La valeur nulle signifie inconnue, si bien que toute comparaison la concernant rend inconnu plutôt que vrai : une condition écrite avec un signe égale ne ramène donc aucune ligne, sans lever la moindre erreur. On écrit IS NOT NULL pour l'inverse.

Pourquoi un identifiant artificiel comme clé primaire ?

Parce qu'une clé primaire doit être stable autant qu'unique. Une donnée métier comme un courriel ou un nom peut changer, et la modifier obligerait à mettre à jour toutes les clés étrangères qui la référencent, avec le risque d'incohérence. Un identifiant artificiel n'a aucune raison de changer ; on peut toujours poser en plus une contrainte d'unicité sur le courriel.

Qu'est-ce qu'une mise à jour perdue dans une base de données ?

C'est le cas où deux transactions lisent la même valeur, la modifient chacune de leur côté, puis écrivent : la seconde écriture efface la première, dont l'effet disparaît sans trace. C'est une violation de l'isolation, la lettre I du sigle ACID. Le remède est de verrouiller la donnée pendant la lecture et l'écriture, sur une durée aussi courte que possible.

Passer à la pratique

Exercices corrigés : Bases de données relationnelles et langage SQL

Une méthode se prouve sur une copie, pas sur une fiche. La série du même chapitre reprend chacun de ces pièges dans un exercice, avec le corrigé rédigé étape par étape.

16 exercices corrigés
160 points
272 minutes

Faire les exercices

Il manque quelque chose dans cette fiche ? Une méthode, un piège, un exercice pour l'appliquer, une erreur repérée : dis-le-moi, je lis chaque demande.

L'envoi passe par ton espace gratuit : c'est ce qui me permet de te répondre et de te prévenir quand l'exercice est ajouté. Un courriel suffit, pas de mot de passe. Crée ton espace. Pas envie de créer un compte ? Écris-moi directement.

Fiche précédente Structures de données : piles, files, arbres et graphes Fiche suivante Processus, réseaux et sécurisation

© Ahmed Squalli Houssaini. Fiche publiée sur www.letuteurscientifique.ca/fiches/tnsi-bases-donnees-sql. Libre pour l'usage personnel et en classe ; sa republication ailleurs demande une autorisation écrite (mentions légales).

Voir aussi

Toutes les fiches Tous les exercices Tuteur NSI Tuteur Terminale

Vous cherchez un tuteur en NSI à Montréal ?

Contactez-moi pour une première séance. On reprend les points de méthode qui font perdre des points en évaluation, puis on les met à l'épreuve sur des exercices du niveau réel de l'examen.

Me contacter WhatsApp

Site par Studio Squalli