Un cap pour ce chapitre
Ce que vous saurez faire
- Identifier une clé primaire pertinente.
- Expliquer une clé étrangère et sa référence.
- Distinguer intégrité de domaine, d’identité et de référence.
Les bases utiles pour commencer
Identifier chaque ligne sans ambiguïté
Une clé primaire identifie chaque tuple d’une relation. Ses valeurs doivent être uniques et présentes. Dans Club(id_club, nom, salle), id_club peut jouer ce rôle. Deux clubs peuvent occuper la même salle ; la salle ne convient alors pas comme identifiant unique. Un nom peut aussi changer ou être partagé selon le domaine étudié.
Une clé peut réunir plusieurs attributs. Pour une relation Inscription(id_membre, id_club), le couple peut identifier une inscription si une personne peut rejoindre plusieurs clubs mais pas s’inscrire deux fois au même. L’unicité porte alors sur la combinaison, pas sur chacun des deux attributs séparément.
L’unicité doit découler d’une règle durable du domaine, pas du seul contenu observé aujourd’hui. Si tous les membres ont momentanément des prénoms différents, cela ne garantit pas qu’un futur homonyme sera impossible. Une clé bien choisie continue d’identifier les personnes après une modification descriptive. Les contraintes documentent ces garanties pour les futures insertions.
Référencer une ligne d’une autre relation
Dans Membre(id_membre, prenom, id_club), l’attribut id_club peut être une clé étrangère référençant Club.id_club. Si le membre indique le club 2, une ligne correspondante doit exister dans Club, sous les règles du schéma. Cela empêche de faire référence à un club inconnu.
Plusieurs membres peuvent partager la même valeur de clé étrangère : ils sont simplement inscrits au même club. Une clé étrangère n’est donc pas nécessairement unique dans sa relation. Dans notre modèle, l’inscription à un club est obligatoire ; une valeur absente n’est pas autorisée.
Trois familles de cohérence
L’intégrité de domaine vérifie la nature et les valeurs admises : un identifiant entier positif, par exemple. L’intégrité d’identité concerne la clé primaire, qui ne doit pas être dupliquée ou manquante. L’intégrité référentielle garantit que les références correspondent à des données existantes.
Ces contrôles sont complémentaires. Le nombre 9 peut être un identifiant de club bien formé mais ne correspondre à aucun club. Une nouvelle ligne peut avoir des domaines corrects et une référence existante tout en réutilisant l’identifiant d’un autre membre. Diagnostiquer la contrainte exacte aide à corriger les données proprement.
Un même tuple peut violer plusieurs contraintes. Un identifiant déjà présent, un prénom vide et un club inconnu constituent trois défauts distincts. Corriger seulement l’un ne rend pas l’insertion valide. L’atelier présente donc plusieurs contrôles simultanés et conserve intégralement l’état initial tant qu’au moins une règle échoue.
Prévoir aussi les modifications et suppressions
Les contraintes ne concernent pas seulement les insertions. Supprimer un club encore référencé pourrait laisser des membres sans destination. Une base doit appliquer une politique définie : refuser la suppression, propager certaines suppressions ou modifier les références selon des règles explicites. Aucun comportement universel ne doit être supposé sans lire le schéma.
L’atelier retient une règle simple : une insertion est acceptée seulement si son identifiant est nouveau, son prénom non vide et son club existant. Il signale chaque raison de refus sans effectuer de modification partielle. Les clubs et membres utilisés sont des données fictives destinées à l’apprentissage.
Exemple suivi : diagnostiquer une insertion
Les membres existants portent les identifiants 101,102,103 et les clubs existants 1,2,3. La proposition (102,"",9) possède un identifiant positif, mais réutilise une clé primaire, présente un prénom vide et référence un club absent. Une vérification limitée au type entier du premier champ accepterait à tort plusieurs incohérences.
La proposition (105,"Adam",2) respecte les quatre règles du simulateur : identifiant positif, clé nouvelle, prénom non vide et club existant. Elle ajoute un membre. Pour documenter une correction, indiquez quelle règle est réparée et sur quelle donnée elle repose. Inventer arbitrairement un club pour faire disparaître une erreur technique ne suffit pas à représenter une inscription réelle : les contraintes contrôlent la cohérence du modèle, pas la vérité de toutes les informations saisies.
Clé composée et effets d’une suppression
La relation Inscription(id_membre,id_club) peut utiliser le couple comme clé primaire. Les lignes (101,1), (101,3) et (102,1) sont alors distinctes. Répéter 101 ou 1 est permis, mais répéter exactement (101,1) ne l’est pas. Chaque colonne peut en plus être une clé étrangère vers sa relation d’origine.
Supprimer le club 1 pose une question sur les inscriptions qui le référencent. Une politique peut interdire la suppression tant que ces lignes existent ; une autre peut supprimer aussi les inscriptions, si le schéma et le besoin le prévoient. Il faut lire la règle annoncée, sans supposer une cascade automatique. L’intégrité référentielle garantit qu’une référence obligatoire ne reste pas dirigée vers un tuple inexistant ; elle ne choisit pas à elle seule toutes les politiques de gestion.
À vous de faire varier les choses
L’inscription sera-t-elle acceptée ?
Essayez un identifiant déjà utilisé, un prénom vide et un club absent. Le laboratoire indique toutes les contraintes qui échouent.
Lire le résultat de l’expérience initiale
Insertion acceptée
Clubs existants : 1 Robotique, 2 Astronomie, 3 Photo. Aucun changement partiel n’est effectué en cas de refus.
| id_membre | prenom | id_club |
|---|---|---|
| 101 | Lina | 1 |
| 102 | Noé | 2 |
| 103 | Sara | 1 |
| 105 | Adam | 2 |
Une donnée peut être bien typée tout en violant une identité ou une référence.
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.
Une clé étrangère répétée
Les membres 101 et 103 indiquent tous deux id_club = 1. Est-ce nécessairement une violation de clé ?
Indice 1
La clé primaire des membres est id_membre.
Indice 2
Plusieurs personnes peuvent rejoindre le même club.
Comprendre la correction
Non. Les identifiants des membres sont différents et leur clé étrangère désigne le même club. Cette répétition est normale dans une relation où plusieurs membres peuvent dépendre d’un club. Il faut seulement vérifier que le club 1 existe et que le schéma n’impose pas une contrainte supplémentaire.
Une référence bien formée mais inexistante
Club contient les identifiants 1, 2 et 3. Une nouvelle ligne Membre(105, Adam, 9) utilise un identifiant membre inédit. Quelle contrainte échoue ?
Indice 1
9 est un entier positif.
Indice 2
Cherchez une ligne de Club portant cet identifiant.
Comprendre la correction
L’intégrité référentielle échoue parce que le club 9 n’existe pas. L’identifiant membre 105 peut être parfaitement valide et unique. Il faut choisir un club existant ou créer préalablement un club réel correspondant, selon le besoin, plutôt que contourner la contrainte.
Le prénom comme identifiant
Deux membres se prénomment Lina. Pourquoi prenom ne convient-il pas comme clé primaire dans ce jeu de données ?
Indice 1
Une clé primaire doit distinguer toutes les lignes.
Indice 2
Les deux personnes doivent rester enregistrables.
Comprendre la correction
Le prénom n’est pas unique. L’utiliser comme clé primaire empêcherait d’enregistrer les deux personnes distinctes. Un identifiant de membre permet de préserver leur identité même lorsqu’elles partagent un prénom ou qu’une information descriptive change.
Une clé composée
Dans Inscription(id_membre, id_club), la clé primaire est le couple. Après (101,1), peut-on ajouter (101,2) ? Et une seconde fois (101,1) ?
Indice 1
Comparez les couples complets.
Indice 2
Les clés étrangères doivent également être valides.
Comprendre la correction
(101,2) peut être ajouté si le membre et le club existent : le couple est différent. Une seconde ligne (101,1) violerait l’unicité de la clé composée. Chaque attribut peut donc se répéter, tandis que leur combinaison reste unique.
Trois défauts indépendants
Les membres 101,102,103 et les clubs 1,2,3 existent. On propose (102,prénom vide,9). Examinez les quatre contrôles du cours, donnez le nombre de règles violées et proposez un tuple qui les respecte.
Indice 1
Le nombre 102 est positif même s’il est déjà utilisé.
Indice 2
Le club 9 échoue sur l’existence, pas sur son caractère entier.
Comprendre la correction
La positivité est respectée. L’unicité, le prénom non vide et la référence échouent, soit trois violations. Par exemple (105,Adam,2) respecte les règles. La proposition invalide ne doit provoquer aucun ajout partiel.
Une clé sur deux colonnes
Inscription contient (101,1),(101,3),(102,1), avec clé primaire composée. Les membres 101,102 et les clubs 1,2,3 existent. Parmi (101,2),(101,1),(102,3), lesquels peut-on ajouter ? Justifiez l’unicité du couple.
Indice 1
La répétition d’un seul attribut ne suffit pas à créer un doublon.
Indice 2
Comparez chaque couple complet aux lignes déjà présentes.
Comprendre la correction
(101,2) et (102,3) sont admissibles : les références existent et les couples sont nouveaux. (101,1) duplique une clé déjà présente. La clé composée autorise plusieurs clubs par membre et plusieurs membres par club, mais une seule ligne pour chaque participation.
Supprimer un parent référencé
Le club 1 est référencé par les membres 101 et 103. Le schéma impose des références obligatoires et refuse la suppression d’un club encore utilisé. On demande de supprimer le club 1. Quel résultat doit-on attendre ? Proposez deux décisions métier possibles avant une suppression ultérieure.
Indice 1
La règle de l’énoncé exclut une cascade implicite.
Indice 2
On peut conserver le club ou réaffecter les membres à des clubs existants si cela correspond au besoin.
Comprendre la correction
La suppression est refusée et les données restent inchangées. On peut décider de conserver le club ou de réaffecter correctement ses membres avant une nouvelle suppression. Une autre décision pourrait supprimer des inscriptions dans un modèle qui les sépare, mais elle doit être autorisée et définie. Une référence obligatoire ne doit pas devenir orpheline.
Les erreurs qui méritent un détour
- Prendre une clé étrangère pour une copie de toute la ligne référencée.
- Elle conserve un identifiant permettant de relier les faits. Les informations du club restent dans leur relation.
- Supposer que toute suppression est automatiquement propagée.
- Les actions référentielles dépendent du schéma ; une suppression peut aussi être refusée.
La fiche à garder
L’essentiel à retenir
- La clé primaire exprime une identité unique.
- La clé étrangère doit viser une référence admise.
- Les domaines et les références vérifient des propriétés distinctes.
Cette notion au bac
Retrouvez ces idées dans un sujet complet, avec des indices, une correction expliquée et des ateliers.
- Bac 2026 · Métropole · Jour 1 : Plateforme de débats : arbres d’arguments et base relationnelle
- Bac 2026 · Métropole · Jour 2 : Covoiturage : requêtes SQL, files et point de rendez-vous
- Bac 2026 · Centres étrangers groupe 1 · Jour 1 : Démineur : voisinage, propagation et scores en ligne
- Bac 2026 · Centres étrangers groupe 1 · Jour 2 : VintagePixel : collection relationnelle et choix des routes
Le prochain pas
- Concevoir une base et repérer les anomalies
- SQL : comprendre et écrire des jointures
- SQL : insérer, modifier et supprimer des données
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.