Le modèle relationnel
Introduction
Avant d'écrire la moindre requête, il faut modéliser. Le modèle relationnel, formalisé par Edgar F. Codd en 1970, propose un cadre mathématique simple pour organiser des données : tout se range dans des tables — appelées relations — dont la forme est rigoureusement contrainte. C'est ce cadre qui permet ensuite à un SGBD de garantir la cohérence des données et au langage SQL d'exprimer des questions complexes en quelques lignes.
Vous connaissez déjà l'intuition. Une feuille de tableur — Excel, LibreOffice Calc, Google Sheets — vous montre des colonnes nommées et des lignes de données. Le modèle relationnel reprend cette image et la discipline : une feuille devient une relation, ses colonnes des attributs, ses lignes des n-uplets, et plusieurs feuilles peuvent se relier rigoureusement par des références mutuelles.
Le vocabulaire du modèle
Une relation est ce que vous appelez intuitivement une table. Chaque colonne porte un attribut (un nom) ; chaque attribut tire ses valeurs d'un domaine (un ensemble de valeurs admissibles, par exemple les entiers, les chaînes de moins de 50 caractères, les dates). Chaque ligne constitue un n-uplet : un assemblage de valeurs, une pour chaque attribut. L'ensemble des n-uplets d'une relation forme son contenu ; l'ensemble des attributs et de leurs domaines forme son schéma.
Clés primaires et clés étrangères
Pour identifier sans ambiguïté chaque n-uplet, on choisit un attribut (ou une combinaison) qui ne se répète jamais : c'est la clé primaire. Pour relier une relation à une autre, on utilise un attribut dont les valeurs sont des clés primaires d'une autre relation : c'est une clé étrangère.
On note un schéma relationnel par R(att1, att2, att3*)
où att1 (souligné) est la clé primaire et att3* (étoile, parfois
notée att3# selon les ouvrages) est une clé étrangère vers la relation R'.
Exemple — un fragment de base scolaire :
Eleve(id_eleve, nom, prenom, classe)Cours(id_cours, intitule, niveau)Inscription(id_eleve, id_cours, date_inscription, note)
Dans Inscription, la clé primaire est composée : c'est la paire
(id_eleve, id_cours), et chacun des deux attributs est aussi une clé
étrangère, l'un vers Eleve, l'autre vers Cours. Cette table de liaison
modélise une relation plusieurs-à-plusieurs — un élève suit plusieurs
cours, un cours accueille plusieurs élèves. Vous retrouverez cette base
Eleve / Cours / Inscription dans tous les cours du chapitre, pour
garder vos repères.
Dans Eleve(id_eleve, nom, prenom, classe), où id_eleve est souligné, combien la clé primaire comporte-t-elle d'attributs ?
Les contraintes d'intégrité
Le modèle relationnel impose trois contraintes qui garantissent la cohérence des données :
| Contrainte | Sens |
|---|---|
| De domaine | Chaque valeur d'un attribut doit appartenir au domaine déclaré. On ne range pas du texte dans une colonne entier. |
| D'entité | Aucun composant d'une clé primaire ne peut être NULL (absent), et deux lignes ne peuvent partager la même clé primaire. |
| Référentielle | Toute valeur d'une clé étrangère doit exister comme clé primaire dans la relation référencée. Pas d'inscription pour un élève fantôme. |
Ces contraintes sont déclarées dans le schéma et vérifiées automatiquement par le SGBD à chaque insertion, mise à jour ou suppression. C'est ce qui distingue une vraie base de données d'un simple tableur.
Une clé étrangère peut-elle pointer vers une ligne qui n'existe pas dans la relation référencée ?
Schéma vs contenu
Le schéma est la forme de la base : noms de relations, attributs, domaines, clés. Il change rarement — sa modification s'appelle une migration. Le contenu est l'ensemble des n-uplets actuellement stockés. Il change sans cesse, à chaque insertion, modification, suppression. Cette distinction sera centrale pour comprendre les anomalies de schéma étudiées au cours suivant : un mauvais schéma peut rendre certains contenus impossibles à représenter proprement.