APPRENDRE AVEC LA CORRECTIONLes cinq questions et leurs réponses expliquées
Faites d’abord l’essai ci-dessus si vous souhaitez répondre sans aide. Retrouvez ensuite les raisonnements de ce chapitre : Structurer une base de données. Ouvrez une explication pour comprendre la réponse attendue.
1. Quelle propriété est indispensable à une clé primaire dans une table relationnelle ?
- Elle doit être unique dans chaque export, même si elle se répète dans la table.
- Elle identifie chaque ligne sans doublon ni valeur NULL.
- Elle identifie obligatoirement une ligne dans toutes les tables du système.
- Elle autorise NULL si aucune autre ligne ne porte NULL.
Afficher la réponse et l’explication
Réponse : Elle identifie chaque ligne sans doublon ni valeur NULL.
La clé primaire distingue chaque ligne et exclut les valeurs NULL. Son format peut être numérique, textuel ou composé : c’est son rôle d’identification qui compte.
2. Dans Commande, pourquoi plusieurs lignes peuvent-elles porter la même clé étrangère idClient ?
- Parce que idClient constitue aussi la clé primaire de chaque commande.
- Parce qu’une clé étrangère n’est contrôlée que lors des suppressions.
- Parce que la clé primaire de Client est alors répétée dans Client.
- Parce qu’un client peut être associé à plusieurs commandes.
Afficher la réponse et l’explication
Réponse : Parce qu’un client peut être associé à plusieurs commandes.
La répétition de idClient dans Commande traduit la relation un à plusieurs. L’unicité porte ici sur idCommande, pas sur la référence commune à plusieurs achats du même client.
3. Un logiciel attribue le même idCommande à deux achats différents. Pourquoi ce comportement viole-t-il le rôle de la clé primaire ?
- Une valeur de clé n’identifie plus une seule ligne.
- Une clé primaire ne peut pas identifier des opérations de dates différentes.
- La clé étrangère client devient nécessairement NULL.
- Les deux achats deviennent automatiquement une seule opération métier.
Afficher la réponse et l’explication
Réponse : Une valeur de clé n’identifie plus une seule ligne.
Une clé primaire doit distinguer sans ambiguïté les lignes. Réutiliser le même identifiant pour deux achats détruit cette identification, indépendamment du type choisi pour la clé.
4. Une clé primaire doit-elle nécessairement être un numéro généré automatiquement ?
- Non : une autre clé est possible si elle est unique, non NULL et adaptée aux règles métier.
- Oui : une clé métier ne peut jamais garantir une identification.
- Oui : l’existence de plusieurs colonnes rend une clé invalide.
- Non : l’unicité observée sur un échantillon suffit sans contrainte durable.
Afficher la réponse et l’explication
Réponse : Non : une autre clé est possible si elle est unique, non NULL et adaptée aux règles métier.
Un numéro automatique est une solution pratique, pas une propriété imposée par la notion de clé primaire. Une clé métier ou composée convient si ses contraintes d’identification sont garanties.
5. Un concepteur impose idClient UNIQUE dans Commande alors que les clients doivent pouvoir acheter plusieurs fois. Quelle conséquence obtient-il ?
- Il empêche seulement deux commandes d’un même client à la même date.
- Il autorise une seconde commande si son montant est différent.
- Il contrôle uniquement l’existence du client dans Client.
- Il interdit une seconde commande portant le même client.
Afficher la réponse et l’explication
Réponse : Il interdit une seconde commande portant le même client.
La contrainte UNIQUE rend chaque référence client utilisable une seule fois dans Commande. Elle contredit donc la relation un à plusieurs voulue, même si les identifiants de commande sont différents.
Trois flashcards pour retenir les distinctions
Deux clients différents portent le même nom et peuvent habiter à la même adresse. Quel choix identifie durablement chacun dans la base ?
Un identifiant client unique et non NULL.
Les règles données autorisent des noms et adresses identiques. Un identifiant client unique évite ces collisions sans dépendre d’une donnée descriptive susceptible de changer.
Une clé étrangère relie les commandes aux clients, mais une commande peut encore afficher un montant négatif contraire aux règles internes. Quelle conclusion est correcte ?
Le contrôle de référence ne remplace pas le contrôle du montant.
L’intégrité référentielle vérifie le lien entre les tables. Une règle de domaine ou un contrôle métier supplémentaire reste nécessaire pour imposer les valeurs autorisées du montant.
Dans un échantillon de vingt salariés, tous les prénoms sont différents. Cela suffit-il à choisir le prénom comme clé primaire durable ?
Non : l’unicité doit être garantie par les règles, pas seulement observée dans l’échantillon.
Un constat provisoire ne démontre pas une règle d’unicité durable. Des homonymes futurs sont possibles ; l’identifiant doit rester compatible avec les faits que la base est censée représenter.
Ces exercices originaux portent sur un aperçu d’un chapitre. Ils ne constituent pas une annale officielle ni une évaluation complète de votre niveau. Voir les chapitres disponibles en Systèmes d’information de gestion.
