Aller au contenu

Un mot pour Fahmio

Tu écris. Tu continues.

Un problème, une idée — assez pour qu’on comprenne, puis tu retournes à ta copie.

On lit. Tu n’as rien d’autre à faire.

Où veux-tu aller ?

↑ ↓ pour parcourir · Entrée pour ouvrir · Échap pour fermer

Fahmio
Fahmio
Bac Tunisie
BD-KBases de données et SQL

Étude de cas complète sur un seul schéma : partie A en quatre exercices — lire le schéma, interpréter des requêtes, interroger, étendre

Idée directrice

Depuis la session 2025, la partie A de l'épreuve de la section Sciences de l'informatique (12 à 13 points) porte tout entière sur une seule base de données, en quatre exercices numérotés : interpréter la base (représentation textuelle, propositions vraies ou fausses, lignes refusées à l'insertion), interpréter des requêtes, manipuler les données, étendre la structure selon des règles de gestion. La difficulté n'est pas une requête isolée mais la tenue du schéma sur plus de vingt questions : chaque réponse se justifie par la place d'un champ — clé primaire, clé étrangère, attribut de telle table — ou par une propriété du tableau de description. L'exercice reprend la base VéloCité des scénarios de requêtes et de mises à jour du chapitre et enchaîne sur ce seul schéma les gestes que les autres scénarios entraînent séparément.

Ce qui aide à reconnaître la démarche

« Partie A : Gestion de la base de données » ; « Donner la représentation textuelle de cette base de données en précisant pour chaque table son nom » ; « compléter la colonne Réponse avec la lettre correspondante à son rôle » ; « Écrire en SQL les requêtes permettant de répondre aux questions suivantes » ; « Le tableau ci-dessous contient quatre représentations textuelles erronées »

Besoin d’un point de départ ? Voir la méthode
  • Avant d'écrire, lire le schéma lien par lien : table côté 1 (clé primaire), table côté ∞ (clé étrangère). Les réponses de l'exercice 1 et les jointures de l'exercice 3 en découlent.
  • Justifier chaque Vrai/Faux par un fait du schéma : clé étrangère simple → une seule valeur ; clé primaire composée → ce qui ne peut pas se répéter ; champ placé dans une table → il décrit cette table ; propriété du tableau de description (unique, facultatif, liste de valeurs).
  • Insertions : rejouer les lignes dans l'ordre ; clé répétée → intégrité de table, ligne mère absente → intégrité référentielle, valeur hors propriété → intégrité de domaine.
  • Requêtes : repérer le mot déclencheur (« sans répétition », « de chaque », « dont le total dépasse », « aucun », « le plus ») avant d'écrire la clause correspondante.
  • Extension : une règle « un seul » place la clé étrangère du côté « plusieurs » ; deux règles « plusieurs » croisées créent une table d'association dont le couple forme la clé et qui porte les champs propres au couple.
Les pièges à vérifier dans ta démarche

Oublier qu'une ligne refusée ne peut pas servir de ligne mère aux insertions suivantes ; justifier un Faux par le bon sens au lieu de la clé ; confondre libellé et code (« E-City ») ou « commence par » et « contient » ; oublier la table intermédiaire Velo entre Modele et Reparation ; inverser les dates dans DATEDIFF ; écrire SUM(cout) > 100 dans WHERE ; garder une clé technique (idVerif) quand la règle exige « une seule fois » par couple ; placer idVelo# dans Verification au lieu d'Inspection.

Sujet principal

Partie A (12 points) — dans l'esprit de la session principale 2025, section Sciences de l'informatique

28 questionsFigure fournieCorrigé masqué

Partie A : Gestion de la base de données (12 points)

Le service municipal VéloCité de Sfax met des vélos, classiques ou électriques, à la disposition de ses abonnés dans les stations de la ville. Pour gérer les abonnements, les trajets et l'entretien du parc, il utilise la base de données Gestion_VeloCite, dont la représentation graphique est la suivante :

Les champs des tables sont décrits ci-dessous :

ChampDescriptionType et propriété(s)
idStationIdentifiant d'une stationEntier
nomStationNom d'une stationChaîne de 20 caractères, unique
quartierQuartier où se trouve une stationChaîne de 30 caractères
capaciteNombre maximal de vélos d'une stationEntier compris entre 5 et 40
codeModeleCode d'un modèle de véloChaîne de 4 caractères
libModeleLibellé d'un modèleChaîne de 30 caractères, unique
typeModeleType d'un modèle« Classique » ou « Electrique »
tarifMinutePrix d'une minute de trajet (dinars)Réel strictement positif
idVeloIdentifiant d'un véloEntier
dateServiceDate de mise en service d'un véloDate
codeFormuleCode d'une formule d'abonnementChaîne de 3 caractères
libFormuleLibellé d'une formuleChaîne de 20 caractères, unique
prixMensuelPrix mensuel d'une formule (dinars)Réel strictement positif
numAbonneNuméro d'un abonnéEntier
nomAbonneNom et prénom d'un abonnéChaîne de 40 caractères
telAbonneTéléphone d'un abonnéChaîne de 8 caractères, unique
emailAbonneAdresse mail d'un abonnéChaîne de 50 caractères, facultative
idTrajetIdentifiant d'un trajetEntier
dateTrajetDate d'un trajetDate (sans heure)
dureeMinDurée d'un trajet en minutesEntier, vide tant que le vélo n'est pas restitué
montantMontant payé pour un trajet (dinars)Réel, vide tant que le vélo n'est pas restitué
dateRepDate d'une réparationDate (sans heure)
panneDescription de la panne réparéeChaîne de 50 caractères
coutCoût d'une réparation (dinars)Réel strictement positif

Exercice 1 : Interprétation de la base de données (3 points)

  1. Donner la représentation textuelle de cette base de données en précisant pour chaque table son nom, ses champs, sa clé primaire et sa (ses) clé(s) étrangère(s) s'il y en a.
  2. Pour chacune des propositions suivantes, répondre par « Vrai » si elle est vérifiée ou par « Faux » dans le cas contraire :
    1. Un vélo peut être rattaché en même temps à deux stations différentes.
    2. Deux vélos du même modèle ont toujours le même tarif à la minute.
    3. Un vélo peut faire l'objet de deux réparations le même jour.
    4. Un abonné peut souscrire à deux formules d'abonnement en même temps.
    5. Un abonné peut emprunter le même vélo plusieurs fois dans la même journée.
    6. Un trajet peut être enregistré avant que son montant ne soit connu.
    7. Deux abonnés peuvent avoir le même numéro de téléphone.
  3. Les tables « Modele » et « Velo » sont vides et les stations d'identifiants 1 à 4 existent déjà. On insère dans l'ordre les lignes du document 1, d'abord dans la table « Modele » puis dans la table « Velo ». Le SGBD génère des erreurs au niveau de quelques lignes. Pour chaque erreur, indiquer le numéro de la ligne, le nom de la table, le nom du champ ainsi que la contrainte d'intégrité non respectée (intégrité de table (clé primaire), intégrité référentielle ou intégrité de domaine).

Document 1 — lignes à insérer dans la table « Modele » puis dans la table « Velo » :

N° lignecodeModelelibModeletypeModeletarifMinute
1M1Urbain 3VClassique0.040
2M5E-CityElectrique0.100
3M7VéloCargoCargo0.120
4M5E-TrekElectrique0.120
5M8Urbain 7VClassique0.050
N° ligneidVelodateServicecodeModeleidStation
12012025-03-10M12
22022025-03-10M73
32012025-04-02M51
42042025-04-02M84

Exercice 2 : Interprétation des requêtes (1,5 point)

Soit la liste des rôles suivante :

  • a. Supprimer les stations dont le nom contient « Gare ».
  • b. Ajouter une contrainte de domaine sur un champ de la table « Formule ».
  • c. Afficher les vélos du modèle dont le code est « E-City ».
  • d. Modifier la formule d'un abonné dont le numéro est spécifié.
  • e. Supprimer les stations dont le nom commence par « Gare ».
  • f. Ajouter une nouvelle formule avec des valeurs spécifiques.
  • g. Modifier la valeur par défaut d'un champ de la table « Station ».
  • h. Afficher les vélos du modèle dont le libellé est « E-City ».
  • i. Modifier le prix mensuel d'une formule donnée.
  • j. Modifier le type d'un champ de la table « Station ».

Pour chacune des requêtes R1 à R6 ci-dessous, donner la lettre correspondant à son rôle dans la liste ci-dessus.

-- R1
INSERT INTO Formule
VALUES ('F4', 'Etudiant', 10.000);
-- R2
SELECT idVelo, dateService
FROM Velo V, Modele M
WHERE V.codeModele = M.codeModele
  AND libModele = 'E-City';
-- R3
UPDATE Abonne SET codeFormule = 'F3'
WHERE numAbonne = 1002;
-- R4
DELETE FROM Station
WHERE nomStation LIKE 'Gare%';
-- R5
ALTER TABLE Formule
ADD CHECK (prixMensuel > 0);
-- R6
ALTER TABLE Station
MODIFY capacite INT DEFAULT 20;

Exercice 3 : Manipulation des données de la base (6 points)

On suppose que la base de données est déjà créée et contient des données. Écrire en SQL les requêtes permettant de répondre aux questions suivantes :

  1. Quels sont les différents quartiers dans lesquels se trouvent les stations ? On affichera, sans répétition, le champ quartier.
  2. Quels sont les vélos réparés moins de 365 jours après leur mise en service ? On affichera les champs idVelo, dateService, dateRep et panne.
  3. Comment réduire de 20 % le tarif à la minute des modèles de type « Classique » ?
  4. Quels sont les modèles dont au moins un vélo a fait l'objet d'une réparation ? On affichera, sans répétition, les champs libModele et typeModele.
  5. Quels sont les trajets effectués en 2026 par l'abonné nommé « Karim Jmal » ? On affichera les champs idTrajet, dateTrajet et dureeMin, du trajet le plus long au plus court.
  6. Quel est le nombre d'abonnés de chaque formule ? On affichera les champs codeFormule et libFormule ainsi que le nombre d'abonnés.
  7. Quels sont les vélos dont le coût total des réparations dépasse strictement 100 dinars ? On affichera les champs idVelo et libModele ainsi que ce coût total.
  8. Quels sont les vélos qui n'ont été empruntés par aucun abonné pendant l'année 2025 ? On affichera les champs idVelo et dateService.
  9. Quels sont les vélos avec lesquels a été effectué le trajet le plus cher ? On affichera les champs idVelo, libModele et montant.

Exercice 4 : Extension et modification de la structure de la base de données (1,5 point)

Important : à chaque représentation textuelle demandée, indiquer la clé primaire et la (les) clé(s) étrangère(s) de chaque table.

  1. Le quartier d'une station est saisi en toutes lettres, si bien qu'un même quartier apparaît sous des écritures différentes (« Sfax Jadida », « Sfax El Jadida »…). Pour éliminer cette incohérence, on propose de modifier la structure de la base en respectant les règles de gestion suivantes : R1 : une station se trouve dans un seul quartier ; R2 : un quartier peut compter plusieurs stations. Proposer une représentation textuelle de la table « Station » ainsi que de toute nouvelle table indispensable.
  2. Pour suivre l'état du parc, le service inspecte régulièrement ses vélos : lors d'une inspection, on vérifie des points de contrôle (freins, pneus, éclairage, batterie…) et, pour chacun, on enregistre un résultat (« Conforme » ou « Non conforme ») et une remarque. On propose de créer les tables PointControle, Inspection et Verification en respectant les règles de gestion suivantes : R3 : une inspection porte sur plusieurs points de contrôle ; R4 : un point de contrôle est vérifié lors de plusieurs inspections ; R5 : une inspection concerne un seul vélo ; R6 : lors d'une inspection, un point de contrôle n'est vérifié qu'une seule fois, avec l'enregistrement de son résultat.
    1. Les propositions 1 à 4 ci-dessous sont quatre représentations textuelles erronées. Pour chacune, indiquer la règle de gestion (R3, R4, R5 ou R6) non respectée.
    2. En déduire une représentation textuelle correcte des tables « PointControle », « Inspection » et « Verification ».
  • Proposition 1 : PointControle ( codePoint , libPoint ) ; Inspection ( idInsp , dateInsp ) ; Verification ( idInsp# , codePoint# , resultat , remarque , idVelo# )
  • Proposition 2 : PointControle ( codePoint , libPoint ) ; Inspection ( idInsp , dateInsp , idVelo# ) ; Verification ( idVerif , idInsp# , codePoint# , resultat , remarque )
  • Proposition 3 : PointControle ( codePoint , libPoint ) ; Inspection ( idInsp , dateInsp , idVelo# , codePoint# , resultat ) ; Verification ( idInsp# , remarque )
  • Proposition 4 : PointControle ( codePoint , libPoint , idInsp# , resultat ) ; Inspection ( idInsp , dateInsp , idVelo# ) ; Verification ( idInsp# , remarque )
Voir la correction commentéeAprès avoir posé votre démarche

Exercice 1

1. Idée : une table par cadre ; les champs soulignés forment la clé primaire, les champs suivis de # sont les clés étrangères, toujours du côté ∞ d'un lien.

  • Formule ( codeFormule , libFormule , prixMensuel )
  • Abonne ( numAbonne , nomAbonne , telAbonne , emailAbonne , codeFormule# )
  • Station ( idStation , nomStation , quartier , capacite )
  • Modele ( codeModele , libModele , typeModele , tarifMinute )
  • Velo ( idVelo , dateService , codeModele# , idStation# )
  • Trajet ( idTrajet , dateTrajet , dureeMin , montant , idVelo# , numAbonne# )
  • Reparation ( idVelo# , dateRep , panne , cout )

Reparation a une clé primaire composée (idVelo, dateRep) dont idVelo est aussi clé étrangère vers Velo : ce champ est souligné et suivi de #.

2. Idée : une clé étrangère simple ne prend qu'une valeur par ligne ; ce que la clé primaire n'interdit pas est permis ; un attribut décrit la table qui le porte ; le tableau de description dit ce qui est unique ou peut rester vide.

PropositionRéponseJustification
aFauxidStation# est une clé étrangère simple de Velo : chaque vélo ne référence qu'une seule station à la fois.
bVraitarifMinute est un champ de Modele et non de Velo : tous les vélos d'un même modèle partagent cette valeur.
cFauxLa clé primaire (idVelo, dateRep) de Reparation, avec une date sans heure, interdit une seconde réparation du même vélo à la même date.
dFauxcodeFormule# est une clé étrangère simple de Abonne : une seule formule par abonné.
eVraiLa clé de Trajet est idTrajet : rien n'interdit deux trajets du même abonné, avec le même vélo, à la même date.
fVraidureeMin et montant restent vides tant que le vélo n'est pas restitué : le trajet est enregistré dès l'emprunt.
gFauxtelAbonne est unique d'après le tableau de description des champs.

3. Idée : rejouer les insertions dans l'ordre en tenant à jour le contenu des tables ; une ligne refusée n'est pas enregistrée et ne peut donc pas servir de ligne mère aux insertions suivantes.

LigneTableChampContrainte non respectée
3ModeletypeModeleIntégrité de domaine : « Cargo » n'est ni « Classique » ni « Electrique »
4ModelecodeModeleIntégrité de table (clé primaire) : « M5 » a déjà été inséré à la ligne 2
2VelocodeModeleIntégrité référentielle : « M7 » n'existe pas dans Modele, sa ligne 3 ayant été refusée
3VeloidVeloIntégrité de table (clé primaire) : le vélo 201 vient d'être inséré à la ligne 1

Les lignes 1, 2 et 5 de Modele et les lignes 1 et 4 de Velo sont enregistrées. La ligne 2 de Velo est un piège : « M7 » figure bien dans le document 1, mais sa ligne a été refusée.

Exercice 2

Idée : lire d'abord la commande (INSERT, SELECT, UPDATE, DELETE, ALTER), puis le détail qui départage deux rôles voisins : la colonne de la condition, le joker de LIKE, la clause ajoutée.

RequêteRéponseJustification
R1fajout d'une ligne complète dans Formule
R2hla condition porte sur libModele, après jointure avec Modele ; « E-City » est un libellé, le rôle c chercherait un code
R3dseul le champ codeFormule de l'abonné 1002 change ; le prix des formules n'est pas touché (rôle i)
R4e'Gare%' : le nom commence par « Gare » ; « contient » s'écrirait '%Gare%' (rôle a)
R5bADD CHECK ajoute une contrainte de domaine sur prixMensuel
R6gle type INT est conservé, seule la valeur par défaut change ; le rôle j supposerait un nouveau type

Exercice 3

1. Idée : un même quartier compte plusieurs stations ; sans DISTINCT, « Sfax Jadida » apparaîtrait autant de fois qu'il a de stations.

SELECT DISTINCT quartier
FROM Station;

2. Idée : la date de mise en service est dans Velo, celle de la réparation dans Reparation : une jointure, puis DATEDIFF(date1, date2), qui renvoie le nombre de jours écoulés de date2 à date1.

SELECT V.idVelo, dateService, dateRep, panne
FROM Velo V, Reparation R
WHERE V.idVelo = R.idVelo
  AND DATEDIFF(dateRep, dateService) < 365;

Avec DATEDIFF(dateService, dateRep), le nombre de jours serait négatif et tous les vélos réparés passeraient le filtre : l'ordre des arguments compte.

3. Idée : réduire de 20 % revient à multiplier par 0,8 ; le type est un champ de Modele, aucune jointure n'est utile.

UPDATE Modele
SET tarifMinute = tarifMinute * 0.8
WHERE typeModele = 'Classique';

4. Idée : le libellé est dans Modele, les réparations dans Reparation ; on traverse Velo, dont rien n'est affiché. Un modèle réparé plusieurs fois reviendrait sur plusieurs lignes, d'où DISTINCT.

SELECT DISTINCT libModele, typeModele
FROM Modele M, Velo V, Reparation R
WHERE M.codeModele = V.codeModele
  AND V.idVelo = R.idVelo;

Trois tables dans le FROM, donc deux conditions de jointure (clé étrangère = clé primaire).

5. Idée : le nom est dans Abonne, les trajets dans Trajet ; deux filtres (nom, année), puis un tri décroissant sur la durée.

SELECT idTrajet, dateTrajet, dureeMin
FROM Trajet T, Abonne A
WHERE T.numAbonne = A.numAbonne
  AND nomAbonne = 'Karim Jmal'
  AND YEAR(dateTrajet) = 2026
ORDER BY dureeMin DESC;

6. Idée : « de chaque formule » : un groupe par formule ; les colonnes affichées sans fonction d'agrégat figurent toutes dans le GROUP BY.

SELECT F.codeFormule, libFormule,
       COUNT(numAbonne) AS nbAbonnes
FROM Formule F, Abonne A
WHERE F.codeFormule = A.codeFormule
GROUP BY F.codeFormule, libFormule;

La jointure ne garde que les couples formule–abonné existants : une formule sans abonné n'apparaît pas.

7. Idée : le coût total est calculé par vélo (GROUP BY) ; « dépasse strictement 100 » porte sur une somme, c'est donc un filtre de groupes : HAVING, pas WHERE.

SELECT V.idVelo, libModele,
       SUM(cout) AS coutTotal
FROM Velo V, Modele M, Reparation R
WHERE V.codeModele = M.codeModele
  AND V.idVelo = R.idVelo
GROUP BY V.idVelo, libModele
HAVING SUM(cout) > 100;

8. Idée : « aucun … pendant l'année 2025 » : la sous-requête construit la liste des vélos empruntés en 2025, puis on garde ceux qui n'y figurent pas.

SELECT idVelo, dateService
FROM Velo
WHERE idVelo NOT IN (
    SELECT idVelo FROM Trajet
    WHERE YEAR(dateTrajet) = 2025);

Un vélo jamais emprunté, par exemple mis en service à la fin de 2025, fait aussi partie du résultat.

9. Idée : « le plus cher » : chaque montant est comparé au maximum calculé par une sous-requête ; MAX ignore les trajets dont le montant est encore vide.

SELECT V.idVelo, libModele, montant
FROM Velo V, Modele M, Trajet T
WHERE V.codeModele = M.codeModele
  AND V.idVelo = T.idVelo
  AND montant = (SELECT MAX(montant)
                 FROM Trajet);

WHERE montant = MAX(montant) est refusé : une fonction d'agrégat ne peut pas figurer dans WHERE.

Exercice 4

1. Idée : R1 donne une seule valeur de quartier à chaque station, la clé étrangère va donc dans Station ; le nom du quartier n'est plus saisi qu'une fois, dans la nouvelle table.

  • Quartier ( codeQuartier , nomQuartier )
  • Station ( idStation , nomStation , capacite , codeQuartier# )

2.a Idée : pour chaque proposition, chercher ce que sa clé ou la place d'un champ interdit ou permet, puis confronter le résultat à chaque règle.

PropositionRègle non respectéeJustification
1R5idVelo# est dans Verification : les lignes d'une même inspection pourraient citer des vélos différents ; le vélo doit être porté par Inspection
2R6la clé idVerif change à chaque ligne : le même point de contrôle pourrait être vérifié deux fois lors de la même inspection
3R3codePoint# et resultat sont dans Inspection : une inspection ne porterait que sur un seul point de contrôle
4R4idInsp# est dans PointControle : un point de contrôle ne serait vérifié que lors d'une seule inspection

2.b Idée : R3 et R4 forment une relation « plusieurs à plusieurs » entre Inspection et PointControle : la table d'association Verification a pour clé le couple (idInsp, codePoint), ce qui traduit R6, et porte le résultat ; le vélo reste dans Inspection (R5).

  • PointControle ( codePoint , libPoint )
  • Inspection ( idInsp , dateInsp , idVelo# )
  • Verification ( idInsp# , codePoint# , resultat , remarque )

Changer d’énoncé, garder le raisonnement

Choisis un seul transfert après le sujet principal. Qu’est-ce qui change ? Quel résultat ou quelle méthode peux-tu réutiliser ? Les autres exercices restent disponibles pour une prochaine séance.

Variantes rencontrées : partie A sur un seul schéma, en quatre exercices numérotés, notée 12 points (principale et contrôle 2025), 12,5 points (principale 2026) ou 13 points (contrôle 2026) ; interprétation par règles « Valide / Invalide » (principale 2026) ou par règles à compléter avec « un seul » ou « plusieurs » (contrôle 2026) ; affirmations Oui / Non, mots-clés DEFAULT, REFERENCES, NOT NULL, UNIQUE, ON DELETE CASCADE et lignes refusées à l'insertion (contrôle 2025) ; phrases à compléter : référentielle, composée, de domaine (principale 2025) ; requête interprétée par son résultat sur des extraits puis complétée par un HAVING (contrôle 2025) ; requêtes d'insertion refusées à expliquer (principale 2026) ; table de référence Pays ou StatutEspece et règles R3 à R6 (2025). Avant 2025, la même chaîne occupait un seul exercice de 5 à 8 points (principale 2023 : BioLab-Medoc ; contrôle 2024 : BD_Collecte).

Relier ce raisonnement au bac

Choisis une filière pour voir les sujets qui étayent ce scénario.