Un cap pour ce chapitre
Ce que vous saurez faire
- Identifier les principaux services d’un SGBD.
- Expliquer le risque des accès concurrents.
- Distinguer stockage, traitement et sécurisation des accès.
Un logiciel qui gère les données pour les applications
Un système de gestion de bases de données, ou SGBD, est un logiciel qui organise le stockage et les opérations sur une base. Les applications lui adressent des requêtes au lieu de réécrire chacune tous les mécanismes de fichiers. La base contient les données et leur structure ; le SGBD est le logiciel qui les gère.
Une même base peut être utilisée par plusieurs programmes ou utilisateurs. Cette séparation fournit un point commun pour appliquer des contraintes, gérer des autorisations et coordonner les traitements. Le SGBD ne remplace cependant pas la réflexion sur le schéma ou sur les opérations que l’application demande.
Une application décide par exemple qu’une inscription est demandée ; le SGBD fournit les mécanismes permettant de consulter et de modifier les relations. Si l’application formule une mauvaise requête, le SGBD peut l’exécuter exactement sans comprendre l’intention de son auteur. Ses services rendent possible une gestion cohérente, mais ils ne remplacent ni les règles du domaine ni la vérification des requêtes.
La persistance et les traitements efficaces
La persistance permet de retrouver les données enregistrées après la fin d’un programme. Une variable Python disparaissant avec son exécution ne fournit pas ce service à elle seule. Le SGBD organise les écritures, les lectures et des mécanismes de reprise selon ses garanties et sa configuration.
Pour répondre aux requêtes, il peut exploiter des index et choisir des stratégies de traitement. Un index facilite certains accès mais occupe de la place et doit évoluer lorsque les données changent. L’objectif en Terminale est d’identifier ces services et leurs enjeux, sans détailler tous leurs mécanismes internes.
Coordonner les accès concurrents
Deux applications peuvent lire le même nombre de places puis calculer séparément une nouvelle valeur. Si chacune voit 1 et écrit ensuite 0, elles peuvent toutes deux croire avoir obtenu la dernière place. La valeur finale semble plausible, mais deux réservations correspondent à une seule place initiale.
Un SGBD offre des outils, notamment des transactions et des mécanismes de coordination, pour réaliser les opérations de manière cohérente. Il faut néanmoins que l’application les utilise correctement. Une lecture suivie d’une écriture mal coordonnées ne devient pas automatiquement sûre parce qu’elle passe par SQL. Dans le mode protégé de l’atelier, vérifier puis réserver forme une opération indivisible dans le modèle.
Le problème ne suppose pas deux écritures matériellement simultanées. Il suffit que les deux traitements aient lu l’ancienne valeur avant d’effectuer leurs écritures successives. L’ordre A lit, B lit, A écrit, B écrit produit déjà une mise à jour perdue. Une trace des lectures et écritures rend le défaut visible même sur un seul cœur.
Contrôler les accès selon les besoins
Tout utilisateur n’a pas besoin de modifier toutes les relations. Un rôle de consultation peut lire un catalogue, tandis qu’un rôle de gestion peut le mettre à jour. Le contrôle des accès limite les opérations autorisées. Une authentification identifie le compte ; une autorisation détermine ce qu’il peut effectuer.
Ces services sont complémentaires. La persistance ne garantit pas que toutes les données sont exactes, et les droits ne remplacent pas les contraintes d’intégrité. Une bonne application combine un schéma cohérent, des requêtes adaptées, une coordination des modifications et des permissions correspondant aux responsabilités réelles.
Exemple suivi : deux places et une mise à jour perdue
Il reste deux places. A et B lisent chacun 2, puis chacun calcule 1. A enregistre sa réservation et écrit 1 ; B enregistre la sienne et écrit également 1. Le système a accepté deux réservations mais annonce encore une place. La valeur finale reste positive et ne paraît pas immédiatement aberrante, pourtant le bilan est faux.
Une relation de contrôle est places_initiales = reservations_acceptees + places_restantes dans le modèle sans annulation. Ici 2 n’est pas égal à 2+1. Avec un traitement coordonné, A lit 2 puis laisse 1 ; B observe ensuite 1 puis laisse 0. La même relation est respectée. La coordination protège un ensemble d’opérations liées, et pas seulement le fait que chaque écriture de nombre se termine correctement.
Relier services, droits et garanties
La persistance permet de retrouver les données enregistrées. L’intégrité vérifie des contraintes comme l’existence d’un club référencé. Les autorisations limitent ce que chaque compte peut lire ou modifier. La gestion de concurrence organise les demandes qui se chevauchent. Ces fonctions répondent à des risques différents : aucune ne suffit à elle seule à assurer toutes les autres.
Un compte affichant le catalogue peut avoir besoin de lire Club sans pouvoir supprimer Membre. Un gestionnaire d’inscriptions doit modifier des participations tout en respectant les clés et les règles de concurrence. Un index peut accélérer certaines recherches mais demande du stockage et un entretien lors des modifications. Pour expliquer le choix d’un SGBD, reliez chaque service à une situation concrète. Le fonctionnement interne détaillé des transactions et des index dépasse l’objectif de cette introduction.
À vous de faire varier les choses
Deux demandes, une disponibilité partagée
Comparez deux lectures avant écritures à deux réservations coordonnées. Changez la capacité et contrôlez les réservations réellement acceptées.
Lire le résultat de l’expérience initiale
2 réservation(s), compteur final 0.
Tous les traitements ont lu la même ancienne valeur avant les écritures : chaque calcul local ignore les autres réservations.
| Demande | Lecture utilisée | Action | Compteur après |
|---|---|---|---|
| A | 1 | Lit avant les écritures | 1 |
| B | 1 | Lit avant les écritures | 1 |
| A | 1 | Accepte puis écrit son ancien calcul | 0 |
| B | 1 | Accepte puis écrit son ancien calcul | 0 |
Une valeur finale plausible peut masquer une mise à jour perdue lorsque les opérations se chevauchent.
De la compréhension à l’autonomie
À vous de résoudre
Cherchez d’abord par vous-même. Vérifiez les résultats demandés, utilisez les indices si nécessaire, puis comparez votre méthode à la correction.
Base ou logiciel ?
Un établissement stocke des clubs et des inscriptions. Le logiciel qui reçoit SELECT et contrôle les accès est-il la base elle-même ou le SGBD ?
Indice 1
Les données et leur gestionnaire sont deux éléments différents.
Indice 2
Le logiciel fournit des services sur plusieurs relations.
Comprendre la correction
Il s’agit du SGBD. La base rassemble les structures et données enregistrées, tandis que le SGBD interprète les requêtes et applique ses mécanismes de gestion. Une application peut communiquer avec lui sans gérer directement les fichiers physiques de chaque relation.
La dernière place attribuée deux fois
A et B lisent chacune une place disponible, acceptent leur réservation puis écrivent zéro. Combien de réservations sont acceptées et pourquoi le résultat est-il incohérent ?
Indice 1
La valeur finale ne raconte pas toutes les actions réalisées.
Indice 2
Comparez le nombre de réservations à la capacité initiale.
Comprendre la correction
Deux réservations sont acceptées pour une seule place. Les deux écritures de zéro masquent ce double usage. La vérification de disponibilité et la réservation doivent être coordonnées comme une opération cohérente, afin que la seconde demande observe l’effet de la première.
Une permission trop large
Un écran public doit afficher les noms des clubs, mais son compte de connexion peut supprimer tous les membres. Quelle amélioration est pertinente ?
Indice 1
Les droits doivent correspondre aux opérations nécessaires.
Indice 2
Afficher n’exige pas de supprimer.
Comprendre la correction
On donne au compte les droits de lecture nécessaires et on retire les droits de modification ou suppression inutiles. Cela réduit les conséquences d’une erreur ou d’un usage détourné. Les autres comptes peuvent conserver des droits différents selon leur fonction réelle.
Un index n’est pas gratuit
Pourquoi créer un index sur chaque information imaginable n’est-il pas automatiquement la meilleure manière d’utiliser un SGBD ?
Indice 1
Un index est une structure supplémentaire à stocker.
Indice 2
Les modifications des données doivent y être répercutées.
Comprendre la correction
Chaque index consomme de la mémoire ou du stockage et ajoute du travail lors des mises à jour. Il faut donc considérer les requêtes fréquentes et les modifications attendues. L’efficacité se raisonne selon les usages ; un mécanisme utile pour une recherche peut alourdir d’autres opérations.
Une erreur cachée par un compteur positif
Deux places sont disponibles. A et B lisent chacune 2 puis écrivent chacune 1 après avoir accepté leur réservation. Donnez réservations acceptées et compteur final, puis vérifiez le bilan comptable. Pourquoi la positivité du compteur ne suffit-elle pas ?
Indice 1
Les deux lectures portent sur la même ancienne valeur.
Indice 2
Additionnez acceptations et places annoncées.
Comprendre la correction
Deux réservations sont acceptées et le compteur final vaut 1. Le total 2+1=3 dépasse les deux places initiales : une mise à jour est perdue. Un compteur positif peut donc être incohérent ; il faut contrôler la relation entre toutes les informations du modèle.
Protéger la dernière place
Une seule place reste. Vérifier puis réserver est exécuté comme une opération indivisible : A passe avant B. Donnez la lecture et la décision de chaque demande, puis les compteurs finaux. Quel changement observerait-on si B passait avant A ?
Indice 1
La seconde demande observe la modification de la première.
Indice 2
L’ordre décide de la personne servie, pas de la capacité totale.
Comprendre la correction
A lit 1, est accepté et laisse 0. B lit 0 et est refusé. Il y a une réservation acceptée et zéro place restante. En inversant l’ordre, B serait accepté et A refusé ; le bilan resterait identique. La coordination n’attribue pas automatiquement une priorité métier particulière.
Associer une panne au service concerné
Un compte de consultation peut supprimer des membres ; deux demandes réservent la dernière place ; une application oublie tout après sa fermeture car elle gardait seulement une variable. Associez chaque situation au service manquant et proposez une correction de principe.
Indice 1
Distinguez autorisations, coordination et persistance.
Indice 2
Une seule correction ne traite pas forcément les trois situations.
Comprendre la correction
Le premier cas demande des droits adaptés à la consultation. Le second demande une réservation coordonnée. Le troisième demande l’enregistrement persistant des données. Un SGBD offre des mécanismes pour ces besoins, mais l’application doit choisir les droits et utiliser les opérations appropriées ; sa seule présence ne rend pas tout traitement correct.
Les erreurs qui méritent un détour
- Supposer que
SQLélimine automatiquement toute concurrence incorrecte. - Les opérations et garanties choisies doivent rendre la vérification et la modification cohérentes.
- Confondre persistance et sauvegarde universelle.
- Retrouver les données enregistrées ne dispense pas de prévoir les défaillances et la récupération selon le système utilisé.
La fiche à garder
L’essentiel à retenir
- Le SGBD gère les données pour les applications.
- Persistance, efficacité, concurrence et droits répondent à des besoins différents.
- Les outils du SGBD doivent être utilisés avec un modèle et des opérations cohérents.
Cette notion au bac
Retrouvez ces idées dans un sujet complet, avec des indices, une correction expliquée et des ateliers.
Le prochain pas
Retrouver le catalogue de Terminale
Ce chapitre s’appuie sur le programme officiel de Terminale (PDF, nouvel onglet). Les explications et exercices sont proposés pour l’apprentissage.