Bases de données : le modèle relationnel

Imaginons une association qui gère ses adhérents et leurs inscriptions à des activités dans un seul fichier texte :

Dupont;Marie;Tennis;Mardi 18h;0612345678
Dupont;Marie;Natation;Jeudi 19h;0612345678
Martin;Léo;Tennis;Mardi 18h;0698765432

Le numéro de téléphone de Marie Dupont est répété sur deux lignes. S'il change, il faut penser à modifier toutes les lignes : c'est une source d'erreur. De plus, répondre à une question comme « combien d'adhérents font du tennis ? » nécessite un traitement manuel. Une base de données relationnelle résout élégamment ces deux problèmes.

Considérons la relation Eleve décrivant des élèves :

Ici :

• les attributs sont id, nom, prenom, annee_naissance ;
• le domaine de annee_naissance est l'ensemble des entiers (par exemple compris entre 1900 et 2100) ;
• la ligne (2, Martin, Léo, 2008) est un n-uplet.

Dans le modèle relationnel :

• chaque attribut possède un nom unique dans la relation ;
• chaque attribut a un domaine fixé ;
• toutes les valeurs d'une même colonne appartiennent à ce domaine ;
• les n-uplets sont deux à deux distincts ;
• l'ordre des lignes et l'ordre des colonnes sont sans importance.

Dans la relation Eleve précédente, l'attribut nom ne peut pas servir de clé (deux élèves peuvent s'appeler Dupont). L'attribut id, créé spécialement, est une clé primaire idéale : on souligne traditionnellement les attributs de la clé primaire dans le schéma :

$$\text{Eleve(id, nom, prenom, annee\_naissance)}$$

Considérons deux relations :

Schéma associé :

$$\begin{array}{rl}& \text{Classe(id, nom\_classe)}\\ & \text{Eleve(id, nom, prenom, annee\_naissance, \#id\_classe)}\end{array}$$

L'attribut id_classe de Eleve (noté avec un #) est une clé étrangère qui référence la clé primaire id de Classe. La valeur 10 apparaît bien dans Classe : le lien est valide.

On note un schéma de relation par le nom de la relation suivi de la liste de ses attributs entre parenthèses. Les attributs de la clé primaire sont

soulignés, et les clés étrangères sont précédées d'un `#`

(ou suivies d'une indication du type « référence »).

Avec les relations Classe et Eleve précédentes :

• insérer un élève avec annee_naissance = "deux mille" viole la contrainte de domaine (ce n'est pas un entier) ;
• insérer un élève sans id viole la contrainte d'entité ;
• insérer un élève avec id_classe = 99 alors qu'aucune classe n'a l'identifiant 99 viole la contrainte référentielle ;
• supprimer la classe d'id 10 alors que des élèves y sont rattachés violerait aussi l'intégrité référentielle.

Reprenons l'association du début du chapitre. Le fichier unique répétait le numéro de téléphone de chaque adhérent à chaque inscription. En séparant les données en deux relations, la redondance disparaît :

$$\begin{array}{rl}& \text{Adherent(id, nom, prenom, telephone)}\\ & \text{Inscription(\#id\_adherent, \#id\_activite)}\end{array}$$

Le téléphone n'est plus stocké qu'une seule fois, dans Adherent. S'il change, une seule modification suffit : la cohérence est garantie. Ici la clé primaire d'Inscription est composée de deux clés étrangères, ce qui modélise l'association « un adhérent s'inscrit à plusieurs activités, et une activité accueille plusieurs adhérents ».

Une base bien conçue (peu redondante et bien contrainte) offre :

• un gain de place (chaque information stockée une fois) ;
• une cohérence forte (pas de versions contradictoires) ;
• des mises à jour simples et sûres ;
• des interrogations efficaces et fiables.

Un SGBD assure notamment :

• la persistance des données (conservation sur disque) ;
• le respect des contraintes d'intégrité (il refuse les opérations qui les violeraient) ;
• l'interrogation des données via un langage dédié, le plus souvent SQL ;
• la gestion des accès concurrents : plusieurs utilisateurs peuvent travailler simultanément sans corrompre les données ;
• la sécurité (droits d'accès) et la reprise après panne.

En SQL, le langage des SGBD relationnels, on déclare une table en précisant ses attributs, leurs domaines (types) et ses contraintes :

CREATE TABLE Classe (
    id          INTEGER PRIMARY KEY,
    nom_classe  TEXT NOT NULL
);

CREATE TABLE Eleve (
    id               INTEGER PRIMARY KEY,
    nom              TEXT NOT NULL,
    prenom           TEXT NOT NULL,
    annee_naissance  INTEGER,
    id_classe        INTEGER,
    FOREIGN KEY (id_classe) REFERENCES Classe(id)
);

On retrouve les trois familles de contraintes : les types (INTEGER, TEXT) traduisent les domaines, PRIMARY KEY la contrainte d'entité, et FOREIGN KEY la contrainte référentielle.