Pourquoi relier des tables ?
Quand tout est dans une seule table, vous dupliquez des informations et vous perdez le contrôle.
Les relations permettent de séparer les informations et de les connecter proprement.
Imaginez un dossier “Clients” et un dossier “Commandes”.
Chaque commande appartient à un client.
Au lieu de recopier les infos du client dans chaque commande, on garde un lien vers sa fiche.
Une relation est un lien logique entre deux tables, généralement basé sur :
clé primaire (dans la table “parent”) ↔ clé étrangère (dans la table “enfant”).
Clé primaire et clé étrangère : le duo de base
Vous connaissez déjà la clé primaire (PK). Maintenant, voici la clé étrangère (FK).
🪪
Clé primaire (PK)
Identifie une ligne de manière unique dans sa table (souvent id).
🔗
Clé étrangère (FK)
Colonne qui contient une valeur de clé primaire d’une autre table.
Elle crée le “lien”.
✅
Exemple
commandes.client_id pointe vers clients.id.
🎯
Objectif
Éviter la duplication et garantir la cohérence des données.
Relation 1-N (un-à-plusieurs)
C’est la relation la plus fréquente : un client peut avoir plusieurs commandes.
Mais une commande appartient à un seul client.
CREATE TABLE clients (
id INTEGER PRIMARY KEY,
nom TEXT NOT NULL
);
CREATE TABLE commandes (
id INTEGER PRIMARY KEY,
date_commande TEXT,
client_id INTEGER,
FOREIGN KEY (client_id) REFERENCES clients(id)
);
Dans une relation 1-N, la clé étrangère se trouve dans la table “N”
(celle qui contient plusieurs lignes liées à une seule ligne).
Relation 1-1 (un-à-un)
Plus rare : une ligne correspond à une seule autre ligne.
Exemple : un utilisateur ↔ un profil détaillé.
Souvent pour alléger la table principale : la table “profil” peut contenir des champs optionnels,
tandis que la table “utilisateurs” contient les champs essentiels.
CREATE TABLE utilisateurs (
id INTEGER PRIMARY KEY,
email TEXT NOT NULL
);
CREATE TABLE profils (
utilisateur_id INTEGER PRIMARY KEY,
bio TEXT,
FOREIGN KEY (utilisateur_id) REFERENCES utilisateurs(id)
);
👉 Ici, profils.utilisateur_id est à la fois clé primaire et clé étrangère,
ce qui impose : un profil maximum par utilisateur.
Relation N-N (plusieurs-à-plusieurs)
Exemple : un étudiant suit plusieurs cours, et un cours a plusieurs étudiants.
On ne peut pas mettre une seule clé étrangère dans une seule table : il faut une table intermédiaire.
Une fiche “Étudiants”, une fiche “Cours”, et une fiche “Inscriptions” qui note qui est inscrit à quoi.
CREATE TABLE etudiants (
id INTEGER PRIMARY KEY,
nom TEXT NOT NULL
);
CREATE TABLE cours (
id INTEGER PRIMARY KEY,
titre TEXT NOT NULL
);
CREATE TABLE inscriptions (
etudiant_id INTEGER,
cours_id INTEGER,
PRIMARY KEY (etudiant_id, cours_id),
FOREIGN KEY (etudiant_id) REFERENCES etudiants(id),
FOREIGN KEY (cours_id) REFERENCES cours(id)
);
Une relation N-N se fait avec une table de liaison :
elle contient deux clés étrangères (et souvent une clé primaire composite).
Intégrité référentielle : éviter les “liens cassés”
Le but d’une clé étrangère est aussi d’empêcher les incohérences.
Exemple : une commande ne doit pas référencer un client qui n’existe pas.
L’intégrité référentielle signifie que les relations restent cohérentes :
une clé étrangère doit pointer vers une clé primaire existante (sauf si elle est NULL, selon les règles).
Si vous supprimez un client alors qu’il a des commandes, que se passe-t-il ?
Sans règle, vous obtenez des commandes “orphelines”.
Les SGBD proposent des stratégies (cascade, restriction, etc.).
On les détaillera au bon moment, mais retenez l’idée : supprimer un parent peut impacter des enfants.
Ce que vous venez d’apprendre… sert aux JOIN
Pour l’instant, vous avez compris la logique : PK ↔ FK, 1-1, 1-N, N-N.
Au chapitre suivant, on va exploiter ces relations pour afficher des données combinées avec JOIN.
SELECT commandes.id, clients.nom
FROM commandes
JOIN clients ON commandes.client_id = clients.id;
Vous allez bientôt pouvoir afficher : “Liste des commandes avec le nom du client”,
“Liste des livres avec leur auteur”, etc.
Exercice pratique : reconnaître le bon type de relation
Pour chaque situation, indiquez le type : 1-1, 1-N ou N-N.
1) Un auteur écrit plusieurs livres
Un livre a un seul auteur (dans cette version).
2) Un utilisateur a un profil
Un profil correspond à un seul utilisateur.
3) Un film a plusieurs acteurs
Un acteur joue dans plusieurs films.
Bonus
Écrivez une table de liaison film_acteur (film_id, acteur_id) avec une clé primaire composite.
CREATE TABLE film_acteur (
film_id INTEGER,
acteur_id INTEGER,
PRIMARY KEY (film_id, acteur_id)
);
1) 1-N (auteur → livres) • 2) 1-1 (utilisateur ↔ profil) • 3) N-N (films ↔ acteurs).
Récapitulatif du chapitre
- Expliquer pourquoi on sépare les données en plusieurs tables
- Comprendre la différence PK (clé primaire) / FK (clé étrangère)
- Identifier une relation 1-1, 1-N ou N-N
- Créer une table de liaison pour une relation N-N
- Comprendre l’idée d’intégrité référentielle
Prochain chapitre : les jointures (JOIN) pour afficher des données provenant de plusieurs tables.