Les contraintes d’intégrité en base de données (PRIMARY KEY, FOREIGN KEY, CHECK)

Une base de données ne sert à rien si ses données sont fausses ou incohérentes : un employé rattaché à un service qui n’existe pas, deux clients avec le même identifiant, un âge négatif… Pour éviter ces situations, les SGBD offrent des contraintes d’intégrité : des règles déclarées une fois, que la base fait respecter automatiquement à chaque insertion ou modification. Ce guide présente les principales, avec leur syntaxe et leur rôle.

À quoi servent les contraintes ?

Une contrainte est une règle de validité attachée à une table ou une colonne. Dès qu’une opération (INSERT, UPDATE) violerait cette règle, la base la refuse et renvoie une erreur. L’intérêt est double : les données restent fiables quoi qu’il arrive, et la règle est centralisée dans la base plutôt que répétée dans chaque programme qui y accède. On distingue cinq grands types de contraintes.

NOT NULL : interdire les valeurs vides

La contrainte NOT NULL impose qu’une colonne soit toujours renseignée. Elle empêche d’enregistrer une ligne où cette valeur manque :

CREATE TABLE employes (
    id      NUMBER,
    nom     VARCHAR2(50) NOT NULL,
    salaire NUMBER
);

Ici, un employé sans nom sera refusé : la colonne est obligatoire. Le salaire, en revanche, peut rester vide (NULL). C’est la contrainte la plus simple, à poser sur toute donnée réellement indispensable.

UNIQUE : interdire les doublons

La contrainte UNIQUE garantit qu’une valeur n’apparaît qu’une seule fois dans la colonne. Idéale pour un email, un numéro de série, un code :

CREATE TABLE employes (
    id    NUMBER,
    email VARCHAR2(100) UNIQUE
);

Tenter d’insérer un second employé avec un email déjà présent déclenchera une erreur. À noter : UNIQUE autorise en général plusieurs valeurs NULL (l’absence de valeur n’est pas un « doublon »).

PRIMARY KEY : la clé primaire

La clé primaire identifie de façon unique chaque ligne d’une table. C’est en réalité la combinaison de NOT NULL et UNIQUE : la valeur doit être présente et unique. Chaque table ne peut avoir qu’une seule clé primaire.

CREATE TABLE employes (
    id      NUMBER PRIMARY KEY,
    nom     VARCHAR2(50) NOT NULL,
    salaire NUMBER
);

La colonne id devient l’identifiant fiable de chaque employé : jamais vide, jamais dupliqué. C’est sur cette clé que s’appuient les relations entre tables — et elle bénéficie automatiquement d’un index qui accélère les recherches.

FOREIGN KEY : la clé étrangère (intégrité référentielle)

C’est la contrainte la plus puissante. Une clé étrangère garantit qu’une valeur existe bien dans une autre table. Elle empêche par exemple de rattacher un employé à un service inexistant :

CREATE TABLE employes (
    id         NUMBER PRIMARY KEY,
    nom        VARCHAR2(50) NOT NULL,
    id_service NUMBER,
    FOREIGN KEY (id_service) REFERENCES services(id_service)
);

Désormais, tout id_service saisi dans employes doit exister dans la table services. C’est ce qu’on appelle l’intégrité référentielle : elle maintient la cohérence des liens entre tables. Cette contrainte régit aussi les suppressions : que se passe-t-il si l’on supprime un service auquel des employés sont rattachés ? On le précise avec des options comme ON DELETE CASCADE (supprimer aussi les employés) ou ON DELETE SET NULL (détacher les employés). Par défaut, la suppression est refusée tant que des employés y sont liés.

CHECK : imposer une condition

La contrainte CHECK vérifie qu’une valeur respecte une condition personnalisée. Parfaite pour interdire les valeurs absurdes :

CREATE TABLE employes (
    id      NUMBER PRIMARY KEY,
    nom     VARCHAR2(50) NOT NULL,
    salaire NUMBER CHECK (salaire > 0)
);

Ici, un salaire nul ou négatif sera refusé. On peut exprimer des conditions variées : CHECK (age BETWEEN 16 AND 70), CHECK (statut IN ('actif','inactif')), etc. C’est un garde-fou métier très utile pour bloquer les saisies incohérentes à la source.

Nommer ses contraintes

On peut donner un nom explicite à une contrainte, ce qui rend les messages d’erreur plus clairs et facilite sa modification ultérieure :

CONSTRAINT chk_salaire_positif CHECK (salaire > 0)

Lorsqu’une insertion viole cette règle, l’erreur mentionne chk_salaire_positif — bien plus parlant qu’un nom généré automatiquement. C’est une bonne pratique dès qu’une table dépasse le stade du prototype.

Récapitulatif

En résumé

Les contraintes d’intégrité déplacent la responsabilité de la validité des données du programme vers la base : une fois déclarées, elles sont respectées quoi qu’il arrive. NOT NULL impose la présence, UNIQUE évite les doublons, PRIMARY KEY identifie chaque ligne, FOREIGN KEY maintient la cohérence entre tables, et CHECK filtre les valeurs invalides. Bien pensées dès la conception, elles évitent quantité de bugs et garantissent des données propres sur le long terme. Pour compléter, voyez notre article sur les index SQL et les requêtes SQL essentielles.