Une base de données relationnelle ne se contente pas de ranger des informations dans des tables : elle organise aussi les liens qui les rendent compréhensibles. L’intégrité référentielle garantit qu’une référence vers un enregistrement correspond bien à une donnée existante.
Pour examiner cette relation, suivons le cas pédagogique d’une petite librairie qui gère ses livres et ses commandes. Les clés, les contraintes et la normalisation montrent comment le système de gestion de base de données protège la cohérence des données.
A retenir :
- Clés bien définies pour relier livres, clients et commandes
- Contraintes adaptées pour bloquer les références inexistantes
- Modèle relationnel lisible, fiable et plus facile à maintenir
Base de données relationnelle et intégrité référentielle
Dans ce modèle, chaque table décrit un type d’objet, tandis que des colonnes communes établissent les relations entre tables. Pour la librairie, une table « Client » et une table « Commande » sont reliées par un identifiant de client.
Cette organisation évite de recopier les coordonnées du client dans chaque commande. Elle facilite les mises à jour et limite les divergences, à condition que les identifiants soient correctement définis.
Clé primaire et clé étrangère : des rôles complémentaires
La clé primaire identifie chaque ligne de manière unique, comme le numéro d’un client dans la table correspondante. Une clé étrangère reprend cette valeur dans une autre table pour désigner la ligne liée.
Selon la documentation PostgreSQL, une contrainte de clé étrangère empêche notamment l’ajout d’une référence qui ne correspond à aucune ligne dans la table cible. Si une commande désigne un client absent, le système peut donc refuser l’opération plutôt que d’enregistrer un lien incohérent.
Pour visualiser les règles, il est utile de distinguer les colonnes identifiantes des relations qu’elles construisent.
Repères des clés relationnelles :
- Clé primaire : identifiant unique d’une ligne dans sa table
- Clé étrangère : colonne qui référence une clé d’une autre table
- Contrainte de référence : règle qui contrôle la validité du lien
- Valeur absente : situation à traiter selon les règles métier
Élément
Emplacement
Fonction
Identifiant client
Table Client
Distinguer chaque client
Identifiant commande
Table Commande
Distinguer chaque commande
Référence client
Table Commande
Relier la commande à son client
Référence livre
Table LigneCommande
Relier une ligne au livre commandé
Contrainte de référence et cohérence des données
Une fois les clés choisies, la contrainte de référence précise ce qui peut arriver lorsqu’un enregistrement lié est supprimé ou modifié. Ce choix doit refléter les règles concrètes de l’activité, et non seulement simplifier les requêtes.
Selon la documentation MySQL, les clés étrangères participent à la vérification des relations entre les tables. Dans une application, le comportement exact dépend du moteur et des règles configurées ; il faut donc vérifier la documentation du système utilisé.
Suppression et mise à jour des enregistrements
Pour la librairie, supprimer un client ayant passé des commandes peut être interdit, afin de préserver l’historique. Une autre politique consiste à supprimer les commandes associées, mais elle risque d’effacer des informations utiles à la comptabilité.
La suppression en cascade convient plutôt aux données dépendantes dont la disparition est logique, comme des lignes de panier temporaire. Un choix prudent se discute avec les personnes qui utiliseront les données, car une décision technique peut modifier leur travail quotidien.
Effets possibles des règles de référence :
- Refus de suppression : conservation des enregistrements dépendants
- Suppression en cascade : retrait des lignes associées
- Mise à jour en cascade : propagation d’un nouvel identifiant
- Valeur nulle : absence de lien lorsque le schéma l’autorise
Selon la documentation Microsoft sur les contraintes de clés, les clés primaire et étrangère servent à formaliser ces liens dans le schéma. La politique choisie doit rester compatible avec les besoins de conservation et de traçabilité.
« Dans notre scénario, je bloque la suppression d’un client tant que ses commandes doivent rester consultables. »
Cas pédagogique fictif — gestionnaire de librairie
Un contrôle utile dans les opérations courantes
Lorsqu’un employé saisit une commande, le système peut contrôler immédiatement l’existence du client et des livres concernés. Cette vérification réduit les corrections manuelles et empêche qu’une erreur de saisie devienne une anomalie durable.
La contrainte ne remplace toutefois pas les règles métier : elle ne garantit pas qu’une quantité commandée est raisonnable, ni qu’un prix est à jour. Elle sécurise le lien structurel, tandis que d’autres validations contrôlent le contenu.
Situation
Risque sans règle
Réponse possible
Commande liée à un client absent
Référence orpheline
Refuser l’insertion
Suppression d’un client actif
Commandes sans propriétaire
Bloquer ou appliquer une politique explicite
Changement d’identifiant référencé
Liens devenus invalides
Propager la modification ou interdire l’opération
Suppression d’une ligne de panier
Données temporaires conservées inutilement
Autoriser une cascade maîtrisée
« Je préfère tester les suppressions sur une copie avant de modifier les règles en production. »
Cas pédagogique fictif — administratrice de base de données
Modèle relationnel, normalisation et conception fiable
Après la définition des références, la conception des tables détermine si la base restera compréhensible lorsque les besoins évolueront. La normalisation aide à limiter les répétitions et les anomalies, mais elle ne remplace pas les contraintes d’intégrité.
Normaliser pour limiter les incohérences
Si chaque commande répète le nom et l’adresse du client, une modification d’adresse peut laisser plusieurs versions contradictoires. En séparant les clients des commandes, le modèle relationnel conserve une donnée de référence unique et relie les informations par identifiant.
La normalisation consiste à structurer les données pour réduire certaines répétitions et dépendances indésirables. Elle se construit progressivement : une conception utile dépend des questions auxquelles l’application doit répondre et des opérations qu’elle réalise.
Dans le scénario de la librairie, une table de lignes de commande peut relier les commandes aux livres et stocker la quantité achetée. Ce découpage représente correctement le fait qu’une commande comprend plusieurs livres et qu’un même livre apparaît dans plusieurs commandes.
« Nous avons séparé les livres des lignes de commande pour éviter de ressaisir leurs caractéristiques à chaque achat. »
Cas pédagogique fictif — équipe de développement
Tester les relations avant la mise en service
Des essais simples permettent de vérifier le schéma : créer une commande valide, tenter une référence inexistante, puis tester la suppression d’un client lié à des achats. Ces cas révèlent rapidement si les règles correspondent aux attentes des utilisateurs.
Une revue de conception doit aussi examiner les valeurs facultatives, les imports et les comptes applicatifs. Une contrainte correctement définie protège la base même lorsqu’une erreur échappe à l’interface, mais chaque opération doit respecter les autorisations prévues.
Contrôles avant déploiement :
- Vérifier l’unicité des clés primaires dans chaque table
- Tester les références valides et les références inexistantes
- Examiner les effets de suppression et de modification
- Documenter les règles métier associées aux relations
« À mon avis, une contrainte bien nommée aide autant au diagnostic qu’à la prévention des erreurs. »
Cas pédagogique fictif — avis de conception
Source : PostgreSQL, « Constraints », documentation officielle ; MySQL, « FOREIGN KEY Constraints », documentation officielle ; Microsoft Learn, « Primary and foreign key constraints », documentation officielle.