Une base de données relationnelle n’est pas un simple tableau géant. Sa force vient de la manière dont les tables sont reliées entre elles. Deux notions rendent ces liens possibles : la clé primaire et la clé étrangère. Les comprendre évite la majorité des problèmes de données incohérentes.
Pourquoi séparer les données en plusieurs tables
Imaginons une boutique qui enregistre ses commandes dans une seule table contenant le nom du client, son adresse, son téléphone et le détail de chaque commande. Les problèmes apparaissent vite :
- Les coordonnées du client sont répétées à chaque commande.
- Un changement d’adresse oblige à modifier des dizaines de lignes.
- Une faute de frappe crée deux versions du même client.
- Supprimer une commande peut faire disparaître la seule trace du client.
La solution consiste à créer une table Clients et une table Commandes, puis à les relier. Chaque information n’est stockée qu’à un seul endroit.
La clé primaire : identifier sans ambiguïté
La clé primaire est la colonne (ou l’ensemble de colonnes) qui identifie de façon unique chaque ligne d’une table. Elle obéit à trois règles :
- Sa valeur est unique dans toute la table.
- Elle ne peut jamais être vide (NULL).
- Elle est stable : sa valeur ne devrait pas changer au fil du temps.
En pratique, on distingue deux approches :
| Type de clé | Description | Exemple |
|---|---|---|
| Clé naturelle | Une donnée métier déjà unique | Un numéro de série produit |
| Clé artificielle | Un identifiant créé uniquement pour la base | Un entier auto-incrémenté ou un UUID |
Les clés artificielles sont très répandues car elles restent stables même si les règles métier évoluent. Utiliser une adresse e-mail comme clé primaire, par exemple, pose problème le jour où un client change d’adresse.
La clé étrangère : créer le lien
Une clé étrangère est une colonne d’une table qui pointe vers la clé primaire d’une autre table. Dans notre exemple, la table Commandes contient une colonne client_id qui référence la clé primaire de Clients.
Le résultat est double : les informations du client ne sont plus dupliquées, et le système de gestion de base de données peut vérifier que chaque commande appartient bien à un client existant. C’est ce que l’on appelle l’intégrité référentielle.
Les trois types de relations
- Un à plusieurs (1:N) — la plus fréquente. Un client passe plusieurs commandes, mais chaque commande appartient à un seul client. La clé étrangère se place du côté « plusieurs ».
- Un à un (1:1) — chaque ligne d’une table correspond à une seule ligne de l’autre. Utile pour isoler des données sensibles ou rarement consultées.
- Plusieurs à plusieurs (N:N) — un étudiant suit plusieurs cours et un cours accueille plusieurs étudiants. Une base relationnelle ne gère pas ce cas directement : il faut une table de liaison contenant les deux clés étrangères.
Cette table de liaison peut d’ailleurs porter ses propres informations, comme la date d’inscription ou la note obtenue.
Que se passe-t-il en cas de suppression ?
Si l’on supprime un client qui possède des commandes, que deviennent ces commandes ? La définition de la clé étrangère permet de choisir le comportement :
| Option | Effet |
|---|---|
| RESTRICT / NO ACTION | La suppression est refusée tant que des lignes liées existent |
| CASCADE | Les lignes liées sont supprimées automatiquement |
| SET NULL | La clé étrangère est vidée, la ligne subsiste |
CASCADE est pratique mais dangereux : une seule suppression peut effacer des milliers de lignes. Pour des données historiques comme des factures, le refus pur et simple est souvent préférable.
Index et performance
La clé primaire est automatiquement indexée par le système, ce qui rend les recherches sur cette colonne très rapides. En revanche, les colonnes de clé étrangère ne le sont pas toujours.
Comme ces colonnes servent constamment aux jointures, il est généralement recommandé de les indexer explicitement. C’est l’une des optimisations les plus simples et les plus efficaces sur une base qui ralentit.
Erreurs courantes chez les débutants
- Tout mettre dans une seule table. Cela paraît plus simple au début et devient ingérable ensuite.
- Choisir une clé primaire instable, comme un numéro de téléphone ou un nom.
- Ne pas déclarer les clés étrangères et se contenter de « faire attention » dans le code applicatif.
- Stocker plusieurs valeurs dans une même colonne, séparées par des virgules, au lieu de créer une table de liaison.
- Oublier d’indexer les colonnes utilisées dans les jointures.
Une méthode simple pour concevoir un schéma
- Listez les entités du domaine : clients, produits, commandes, employés.
- Créez une table par entité, avec sa clé primaire.
- Décrivez les relations à voix haute : « un client passe plusieurs commandes ».
- Placez les clés étrangères selon le type de relation identifié.
- Vérifiez qu’aucune information n’est stockée à deux endroits différents.
Ce raisonnement, formalisé, correspond aux premières formes normales de la modélisation relationnelle. Nul besoin de maîtriser toute la théorie pour en tirer profit : éliminer les redondances évidentes suffit déjà à obtenir un schéma solide.
Pour aller plus loin sur la conception de schémas, les jointures SQL et l’optimisation des requêtes, les cours gratuits de bases de données et d’informatique proposés sur Cursa constituent une suite logique à ces fondamentaux.
