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
Informatique/BD-H
BD-HBases de données et SQL

Réparer ou faire évoluer un schéma selon des règles de gestion R1…Rn : côté de la clé étrangère, clé d'une table d'historique, table de référence, table d'association

Idée directrice

Depuis 2021, le sujet de la section Sciences de l'informatique ne fait plus concevoir une base à partir de zéro : il donne une première conception (représentation graphique) et une liste de règles de gestion R1, R2, …, puis fait juger et corriger. Chaque règle se traduit en cardinalité : « un seul » d'un côté et « plusieurs » de l'autre place la clé étrangère du côté « plusieurs » ; « plusieurs » des deux côtés impose une table d'association dont la clé primaire est le couple des clés étrangères ; « plusieurs fois à des dates différentes » met la date dans la clé. Pour juger une proposition, on se demande quelles lignes elle refuse et quelles lignes elle laisse passer.

Ce qui aide à reconnaître la démarche

« afin de remédier aux anomalies détectées dans la conception de la base de données » ; « La règle R1 est-elle respectée ? Répondre par Oui ou Non » ; « tout en soulignant les clés primaires et spécifiant les clés étrangères par l'ajout du symbole # » ; « le nom de la règle de gestion … non respectée » ; « Réécrire la représentation textuelle de la base en tenant compte de cette nouvelle contrainte »

Besoin d’un point de départ ? Voir la méthode
  • Traduire chaque règle en cardinalité : « un seul » d'un côté et « plusieurs » de l'autre → relation 1–n ; « plusieurs » des deux côtés → relation n–n.
  • Relation 1–n : la clé étrangère va dans la table du côté « plusieurs », celle dont chaque ligne ne pointe que vers une ligne de l'autre table.
  • Relation n–n : table d'association, clé primaire = couple des clés étrangères ; les attributs qui dépendent du couple (note, score, quantité) y sont placés.
  • Répétition datée : la date entre dans la clé pour autoriser plusieurs lignes à des dates différentes ; une règle « une seule fois » se traduit par le couple seul en clé.
  • Juger une proposition ou un jeu de lignes : tester la clé primaire ligne par ligne (doublon ?) et chaque clé étrangère (une seule valeur par ligne).
Les pièges à vérifier dans ta démarche

Placer la clé étrangère du côté « un » ; ajouter à la clé un attribut quelconque (nbFautes, score) pour faire passer des lignes ; garder l'ancienne colonne (marque) après avoir créé la table de référence ; oublier de retirer la clé étrangère de l'ancienne table lors du passage à une table d'association ; répondre Oui ou Non sans justifier par la position de la clé ; confondre « une seule fois » (couple en clé) et « plusieurs fois à des dates différentes » (date ajoutée à la clé).

Sujet principal

Exercice (4 points) — dans l'esprit des sessions 2022–2025, section Sciences de l'informatique

19 questionsFigure fournieCorrigé masqué

Le réseau d'auto-écoles Permis+ prépare des candidats à l'examen du code de la route. Les règles de gestion définies sont :

  • R1 : un moniteur travaille dans une seule agence.
  • R2 : une agence emploie plusieurs moniteurs.
  • R3 : un candidat est inscrit dans une seule agence.
  • R4 : un candidat peut passer l'examen du code plusieurs fois, à des dates différentes.
  • R5 : un candidat ne peut pas passer l'examen du code deux fois le même jour.
  • R6 : un véhicule appartient à une seule agence.

Le concepteur propose une première version de la base de données, dont la représentation graphique suit ; des anomalies y ont été détectées.

ChampDescription
cinMoniteurNuméro de CIN d'un moniteur.
nomMoniteurNom et prénom d'un moniteur.
telMoniteurTéléphone d'un moniteur.
idAgenceIdentifiant d'une agence.
nomAgenceNom d'une agence.
villeVille où se trouve une agence.
immatNuméro d'immatriculation d'un véhicule.
marqueMarque d'un véhicule.
modeleModèle d'un véhicule.
anneeAnnée de mise en circulation d'un véhicule.
numCandNuméro d'un candidat.
nomCandNom et prénom d'un candidat.
dateNaissDate de naissance d'un candidat.
dateExamDate de passage de l'examen du code.
nbFautesNombre de fautes commises à l'examen du code.

Document 1 — lignes à enregistrer dans la table ExamenCode (les candidats C104 et C118 sont déjà inscrits dans la table Candidat) :

N°numCanddateExamnbFautes
1C1042026-01-157
2C1042026-02-193
3C1182026-02-195

Document 2 — extrait de la table Vehicule :

immatmarquemodeleanneeidAgence
123TU4567Peugeot2082022A1
124TU1010PEUGEOT3012023A1
125TU2020RenaultClio2021A2
126TU3030Peugot2082024A2
127TU4040RenaultSymbol2024A3

Pour les séances de code (cours théoriques en salle), le concepteur ajoute deux tables, Seance et Presence (numSeance, dateSeance, salle et score, la note obtenue par un candidat au test de fin de séance), et les règles suivantes :

  • R9 : une séance de code est animée par un seul moniteur.
  • R10 : un candidat peut assister à plusieurs séances de code.
  • R11 : une séance de code accueille plusieurs candidats.
  • R12 : la présence d'un candidat à une séance n'est enregistrée qu'une seule fois, avec son score.

Document 3 — quatre représentations textuelles erronées :

  • Représentation 1 : Seance ( numSeance , dateSeance , salle ) ; Presence ( numSeance# , numCand# , score , cinMoniteur# )
  • Représentation 2 : Seance ( numSeance , dateSeance , salle , cinMoniteur# , numCand# , score )
  • Représentation 3 : Seance ( numSeance , dateSeance , salle , cinMoniteur# ) ; Presence ( numSeance# , numCand# , score )
  • Représentation 4 : Seance ( numSeance , dateSeance , salle , cinMoniteur# ) ; Candidat ( numCand , nomCand , dateNaiss , idAgence# , numSeance# , score )

Important : à chaque représentation textuelle demandée, souligner les clés primaires et faire suivre les clés étrangères du symbole #.

  1. On s'intéresse aux règles R1 à R6.
    1. Pour chacune de ces règles, dire si la conception proposée la respecte (Oui ou Non) et justifier.
    2. Proposer une représentation textuelle des tables Agence et Moniteur qui respecte R1 et R2.
  2. Avec la conception proposée, quelle ligne du document 1 ne pourra pas être enregistrée ? Justifier.
  3. On s'intéresse à la table ExamenCode.
    1. Proposer une clé primaire qui respecte R4 et R5 et réécrire la représentation textuelle de la table.
    2. Un camarade propose la clé (numCand, dateExam, nbFautes). Quelle règle cette clé ne garantit-elle plus ? Illustrer par deux lignes.
  4. Le document 2 montre une même marque écrite de plusieurs façons. Pour éliminer cette incohérence, on crée une table Marque (idMarque, nomMarque) en respectant les règles R7 : un véhicule est d'une seule marque ; R8 : une marque peut concerner plusieurs véhicules. Proposer une représentation textuelle des tables Marque et Vehicule.
  5. On s'intéresse aux séances de code.
    1. Pour chaque représentation du document 3, donner la règle (R9, R10, R11 ou R12) non respectée.
    2. En déduire une représentation textuelle correcte des tables Seance et Presence.
Voir la correction commentéeAprès avoir posé votre démarche

1.a Idée : traduire chaque règle en cardinalité, puis regarder de quel côté se trouve la clé étrangère, ou quelle est la clé primaire.

  • R1 : Non. La clé étrangère cinMoniteur# est dans Agence : rien n'empêche plusieurs agences de citer le même moniteur, qui travaillerait alors dans plusieurs agences.
  • R2 : Non. Chaque ligne de Agence ne référence qu'un moniteur : une agence ne peut pas en employer plusieurs.
  • R3 : Oui. idAgence# est dans Candidat : chaque candidat référence une seule agence, qui peut être citée par plusieurs candidats.
  • R4 : Non. La clé primaire de ExamenCode est numCand seul : un candidat n'y figure qu'une fois, il ne peut donc passer l'examen qu'une seule fois.
  • R5 : Oui, mais au prix de R4 : un candidat n'ayant qu'une ligne, il ne peut pas en avoir deux le même jour.
  • R6 : Oui. idAgence# est dans Vehicule.

1.b Idée : la clé étrangère se place du côté « plusieurs » : c'est le moniteur qui appartient à une seule agence.

  • Agence ( idAgence , nomAgence , ville )
  • Moniteur ( cinMoniteur , nomMoniteur , telMoniteur , idAgence# )

2. Idée : tester la clé primaire ligne par ligne. La ligne 2 (C104, 2026-02-19, 3) est refusée : C104 figure déjà à la ligne 1 et numCand est à lui seul la clé primaire, d'où une duplication de clé. La ligne 3 est acceptée : C118 n'a pas encore de ligne, même si sa date est celle de la ligne 2.

3.a Idée : R4 autorise plusieurs lignes par candidat, R5 en interdit deux le même jour : c'est le couple (candidat, date) qui doit être unique.

  • ExamenCode ( numCand# , dateExam , nbFautes )

Les trois lignes du document 1 sont alors acceptées.

3.b La clé (numCand, dateExam, nbFautes) ne garantit plus R5 : deux passages du même candidat le même jour, qui ne diffèrent que par le nombre de fautes, sont acceptés, par exemple (C118, 2026-02-19, 5) et (C118, 2026-02-19, 2). Ajouter à la clé un attribut qui n'identifie rien affaiblit la règle d'unicité.

4. Idée : un véhicule a une seule marque (R7) et une marque concerne plusieurs véhicules (R8) : la clé étrangère idMarque# va dans Vehicule, qui perd sa colonne marque.

  • Marque ( idMarque , nomMarque )
  • Vehicule ( immat , modele , annee , idAgence# , idMarque# )

Le nom de chaque marque n'est plus saisi qu'une fois, dans Marque ; les véhicules d'une même marque référencent tous le même idMarque.

5.a Idée : pour chaque représentation, chercher ce qu'elle interdit ou autorise à tort.

  • Représentation 1 : R9. Le moniteur est porté par chaque ligne de Presence : deux candidats d'une même séance pourraient avoir deux moniteurs différents ; il doit être porté par Seance.
  • Représentation 2 : R11. numCand# et score sont dans Seance, dont la clé est numSeance : une séance ne peut avoir qu'un seul candidat.
  • Représentation 3 : R12. score fait partie de la clé de Presence : le même candidat peut être enregistré deux fois dans la même séance avec deux scores différents.
  • Représentation 4 : R10. numSeance# et score sont dans Candidat : un candidat ne peut être rattaché qu'à une seule séance.

5.b Idée : relation plusieurs–plusieurs entre Seance et Candidat : table d'association Presence, de clé (numSeance, numCand), qui porte le score ; le moniteur, unique par séance, reste dans Seance.

  • Seance ( numSeance , dateSeance , salle , cinMoniteur# )
  • Presence ( numSeance# , numCand# , score )

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 : clé étrangère du mauvais côté entre deux tables (principale 2022 : Zone et Cage ; contrôle 2022 : Ville et Centre ; principale 2023 : Leçon et Matière) ; clé d'une table d'historique qui refuse une deuxième ligne (principale 2022 : vaccins d'un animal ; contrôle 2022 : visites d'un véhicule) ; date dans ou hors de la clé selon deux règles opposées (principale 2023) ; table de référence pour une valeur redondante ou incohérente (principale 2018 : région ; principale 2022 : pays d'origine ; contrôle 2024 : rue ; principale 2025 : pays du client) ; passage d'une relation 1–n à n–n (contrôle 2019 ; principale 2024 : copropriété datée) ; clé auto-incrémentée qui laisse répéter un couple (contrôle 2025) ; table sans clé primaire (contrôle 2021) ; règle non respectée par chacune de quatre représentations (principale 2025) ou de trois propositions (principale et contrôle 2022).

Exercices d'entraînement — une nuance à la fois

1 Drill BD-H.1 — clé étrangère du mauvais côté d'une relation 1–n
Entraînement 01 / 05

Drill BD-H.1 — clé étrangère du mauvais côté d'une relation 1–n

5 questionsCorrigé masqué

Une clinique gère ses chambres selon les règles R1 : une chambre appartient à un seul service ; R2 : un service comporte plusieurs chambres. Le concepteur propose :

  • Service ( codeServ , libServ , numChambre# )
  • Chambre ( numChambre , etage , nbLits )
  1. On veut enregistrer que le service de cardiologie (code « CAR ») comporte les chambres 101 et 102. Écrire les lignes nécessaires dans la table Service et dire laquelle sera refusée.
  2. Les règles R1 et R2 sont-elles respectées ? Répondre par Oui ou Non en justifiant.
  3. Proposer une représentation textuelle correcte des deux tables.
Voir la correction commentéeAprès avoir posé votre démarche

1. Il faudrait les lignes (CAR, Cardiologie, 101) et (CAR, Cardiologie, 102) ; la seconde est refusée, car « CAR », clé primaire de Service, y figure déjà.

2. Idée : la table qui porte la clé étrangère ne peut citer qu'une seule ligne de l'autre table. R2 : Non, un service ne peut référencer qu'une chambre. R1 : Non, rien n'empêche deux services de citer la même chambre, qui appartiendrait alors à deux services.

3. La clé étrangère passe du côté « plusieurs », dans Chambre :

  • Service ( codeServ , libServ )
  • Chambre ( numChambre , etage , nbLits , codeServ# )
2 Drill BD-H.2 — une relation 1–n devient n–n : table d'association
Entraînement 02 / 05

Drill BD-H.2 — une relation 1–n devient n–n : table d'association

5 questionsCorrigé masqué

Une radio en ligne enregistre ses podcasts dans la base suivante :

  • Animateur ( idAnim , nomAnim , mailAnim )
  • Podcast ( idPod , titre , dateDiff , idAnim# )

Jusqu'ici, chaque podcast était présenté par un seul animateur. Désormais, un podcast peut être co-animé par plusieurs animateurs, et un animateur continue de présenter plusieurs podcasts.

  1. Pourquoi la conception actuelle ne permet-elle pas d'enregistrer le podcast 40, « Tech Tounsi », co-animé par les animateurs 1 et 2 ?
  2. Réécrire la représentation textuelle de la base en tenant compte de cette nouvelle contrainte.
  3. Donner les lignes à insérer dans la nouvelle table pour le podcast 40.
Voir la correction commentéeAprès avoir posé votre démarche

1. idAnim# est dans Podcast : une ligne de podcast ne peut citer qu'un animateur. Une seconde ligne pour le podcast 40 serait refusée, 40 étant déjà présent comme clé primaire.

2. Idée : « plusieurs » des deux côtés : la clé étrangère quitte Podcast pour une table d'association dont la clé primaire est le couple des deux clés.

  • Animateur ( idAnim , nomAnim , mailAnim )
  • Podcast ( idPod , titre , dateDiff )
  • Animer ( idPod# , idAnim# )

3. Deux lignes dans Animer : (40, 1) et (40, 2).

3 Drill BD-H.3 — date et heure dans la clé : autoriser une répétition, pas un doublon
Entraînement 03 / 05

Drill BD-H.3 — date et heure dans la clé : autoriser une répétition, pas un doublon

3 questionsCorrigé masqué

Un complexe sportif loue ses terrains par créneaux, selon les règles R1 : un terrain peut être réservé plusieurs fois le même jour, à des heures de début différentes ; R2 : un créneau (terrain, date, heure de début) n'est réservé qu'une seule fois ; R3 : un client peut faire plusieurs réservations. Première conception : Reservation ( idTerrain# , dateRes , heureDeb , cinClient# ). Lignes à enregistrer :

N°idTerraindateResheureDebcinClient
1T12026-05-0909:0009876543
2T12026-05-0911:0001234567
3T12026-05-1609:0009876543
  1. Quelle ligne sera refusée ? Quelle règle la conception ne respecte-t-elle pas ?
  2. Proposer une clé primaire qui respecte R1 et R2.
  3. Si la clé était (idTerrain, heureDeb), quelle ligne serait refusée ? Qu'en conclure sur la place de la date ?
Voir la correction commentéeAprès avoir posé votre démarche

1. La ligne 2 : le couple (T1, 2026-05-09) figure déjà à la ligne 1. R1 n'est pas respectée : un terrain ne peut être réservé qu'une fois par jour.

2. Idée : c'est le créneau entier qui doit être unique (R2) : terrain, date et heure de début.

  • Reservation ( idTerrain# , dateRes , heureDeb , cinClient# )

3. La ligne 3 : (T1, 09:00) figure déjà à la ligne 1, une semaine plus tôt. Sans la date dans la clé, un créneau horaire ne pourrait être réservé qu'une seule fois pour toujours : la date doit faire partie de la clé pour autoriser la répétition d'un jour à l'autre.

4 Drill BD-H.4 — table sans clé primaire : proposer une clé composée
Entraînement 04 / 05

Drill BD-H.4 — table sans clé primaire : proposer une clé composée

4 questionsCorrigé masqué

Une société de transport décrit la desserte de ses lignes de bus par la table Desserte ( numLigne , codeArret , rang ), dans laquelle aucune colonne n'est soulignée ; rang est la position de l'arrêt sur la ligne (1 pour le premier). Un même arrêt n'est desservi qu'une fois par une ligne donnée, mais il peut être desservi par plusieurs lignes. Extrait :

numLignecodeArretrang
L12A051
L12A172
L12A093
L30A171
L30A212
L45A054
  1. Quelle contrainte d'intégrité n'a pas été respectée lors de la création de cette table ?
  2. Pourquoi ni numLigne ni codeArret ne peut-il être, à lui seul, la clé primaire ?
  3. Proposer une clé primaire pour cette table.
  4. Comment appelle-t-on la contrainte qui oblige rang à être supérieur ou égal à 1 ? L'écrire en SQL.
Voir la correction commentéeAprès avoir posé votre démarche

1. La table a été créée sans clé primaire : la contrainte d'intégrité d'entité (clé primaire) n'est pas respectée.

2. L12 apparaît sur trois lignes ; A17 apparaît pour L12 et pour L30, A05 pour L12 et pour L45 : aucune des deux colonnes n'identifie une ligne unique.

3. Idée : chercher le plus petit groupe de colonnes qui ne se répète jamais et qui traduit la règle « un arrêt une fois par ligne ». La clé composée (numLigne, codeArret) :

  • Desserte ( numLigne , codeArret , rang )

4. Une contrainte de domaine :

ALTER TABLE Desserte
ADD CONSTRAINT ck_rang CHECK (rang >= 1);
5 Drill BD-H.5 — l'attribut qui dépend du couple va dans la table d'association
Entraînement 05 / 05

Drill BD-H.5 — l'attribut qui dépend du couple va dans la table d'association

3 questionsCorrigé masqué

Une coopérative agricole enregistre les livraisons de ses adhérents selon les règles R1 : un agriculteur livre plusieurs produits ; R2 : un produit est livré par plusieurs agriculteurs ; R3 : pour un agriculteur et un produit donnés, on enregistre une seule quantité livrée (cumul de la saison). Tables existantes : Agriculteur ( cinAgri , nomAgri , region ) et Produit ( codeProd , libelle , prixUnitaire ). Au cours de la saison, l'agriculteur 07111111 a livré 120 kg du produit P1 et 40 kg du produit P2 ; l'agriculteur 07222222 a livré 80 kg du produit P1.

  1. Un concepteur place le champ quantite dans la table Produit. Montrer, à l'aide des livraisons ci-dessus, que c'est impossible.
  2. Proposer la représentation textuelle de la table Livrer qui enregistre ces livraisons.
  3. Le prix unitaire d'un produit est le même pour tous les agriculteurs. Pourquoi reste-t-il dans Produit ?
Voir la correction commentéeAprès avoir posé votre démarche

1. Le produit P1 n'a qu'une ligne dans Produit : elle devrait contenir à la fois 120 (livraison de 07111111) et 80 (livraison de 07222222). La quantité dépend du couple agriculteur–produit, pas du produit seul.

2. Idée : relation plusieurs–plusieurs (R1, R2) : table d'association de clé (cinAgri, codeProd), unique par couple (R3), qui porte l'attribut du couple.

  • Livrer ( cinAgri# , codeProd# , quantite )

3. prixUnitaire ne dépend que du produit : placé dans Livrer, il serait répété à chaque livraison et pourrait prendre des valeurs différentes pour un même produit.

Relier ce raisonnement au bac

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