Modèle relationnel

Dans le modèle relationnel, une relation est un ensemble de tuples qui partagent les mêmes attributs. On la représente souvent par une table : les attributs correspondent aux colonnes et les tuples aux lignes. Un attribut possède un domaine, c’est-à-dire un ensemble de valeurs autorisées. Un entier, un texte ou une date peuvent donner une première description du domaine ; on peut aussi préciser une condition, comme un entier strictement positif. Le domaine indique donc ce qu’une valeur signifie et ce qui est admissible, pas seulement la manière dont elle s’affiche.

Le schéma décrit la structure : nom de relation, attributs, domaines et contraintes. Le contenu est l’ensemble des tuples présents à un moment donné. Ajouter un livre change le contenu sans ajouter de colonne au schéma. Ajouter un attribut langue change le schéma. Dans le modèle mathématique, les lignes ne sont pas ordonnées et une relation ne contient pas deux tuples entièrement identiques. Les tableaux affichés et les résultats SQL peuvent avoir des propriétés différentes ; ne déduis donc pas du seul ordre d’un écran une propriété du modèle relationnel.

Une clé est un attribut ou un ensemble d’attributs permettant d’identifier chaque tuple de manière unique selon les règles du modèle. Une clé candidate est minimale pour cette propriété : aucun de ses attributs ne peut être retiré tout en conservant l’identification. La clé primaire est celle que l’on choisit comme identifiant principal parmi les possibilités adaptées. Ses valeurs doivent être uniques et présentes. Un titre n’est généralement pas un bon identifiant : deux livres peuvent avoir le même titre. Un numéro artificiel id_livre convient si son unicité est imposée et conservée.

L’unicité doit être une règle durable, pas seulement un constat sur les deux lignes affichées. Un tableau où deux personnes ont aujourd’hui des prénoms différents ne prouve pas que le prénom puisse servir de clé. Il faut examiner les cas possibles. Une clé peut être composée : dans une relation Participation(code_membre, code_seance), si chaque membre ne peut apparaître qu’une fois par séance, la paire peut identifier une participation. code_membre seul ne suffit pas si une personne participe à plusieurs séances ; code_seance seul ne suffit pas si une séance accueille plusieurs personnes.

Une clé primaire ne doit pas être confondue avec un numéro de ligne. Trier l’affichage ne change pas l’identité du livre. Retirer une ligne ne doit pas renuméroter silencieusement tous les objets restants. Un identifiant choisi pour établir des liens doit rester assez stable pour que les références conservent leur sens. Il faut aussi distinguer une valeur absente et une valeur normale comme zéro ou chaîne vide : leur admissibilité dépend du domaine et des contraintes annoncées, pas d’une règle improvisée au moment de l’affichage.

Une clé étrangère est un attribut ou un groupe d’attributs qui référence une clé de la relation cible. Dans les exemples scolaires, elle renvoie généralement à la clé primaire d’une autre relation. Des références à une clé unique ou à la même relation sont aussi possibles selon le modèle utilisé. Ici, Emprunt(id_emprunt, id_livre) possède sa propre clé primaire id_emprunt et une clé étrangère id_livre vers Catalogue.id_livre. Nous imposons que chaque emprunt concerne un livre connu : la référence est obligatoire et ne peut pas être absente.

Séparer Catalogue et Emprunt évite de répéter le titre à chaque emprunt. Dans une table unique, corriger le titre d’un livre demanderait de modifier toutes ses occurrences ; une seule correction oubliée laisserait des titres contradictoires pour le même identifiant. On parle d’anomalie de mise à jour. Une anomalie d’insertion apparaîtrait si l’on ne pouvait ajouter un livre avant son premier emprunt. Une anomalie de suppression apparaîtrait si supprimer le dernier emprunt faisait disparaître la seule information sur ce livre. La séparation répond à ces problèmes sans demander ici une théorie complète de la normalisation.

Le schéma présenté reste simplifié : il ne distingue pas les exemplaires physiques et les œuvres, ni les dates de prêt ou de retour. Pour une vraie bibliothèque, il faudrait préciser ces objets et leurs contraintes. Cette limite n’annule pas le raisonnement ; elle délimite ce que le modèle décrit. Une bonne réponse ne prétend pas qu’une table de démonstration couvre tous les besoins possibles. Elle énonce le périmètre, choisit les attributs nécessaires et vérifie les règles correspondantes.

Pour justifier une correction, donne un cas concret. Si un titre est répété dans cinq lignes d’emprunts, montre ce qui arrive lorsqu’une seule ligne est corrigée. Si une référence est inconnue, indique exactement quelle valeur manque dans la relation cible. Ces exemples rendent le diagnostic vérifiable. Le SGBD pourra contrôler des contraintes déclarées, mais il ne devine pas le sens des attributs ni les règles oubliées par le concepteur. Le modèle précède donc l’écriture des requêtes et reste nécessaire pour interpréter leurs résultats.

S’entraîner : ouvre l’espace Exercices du site.