Relation 1:1 en base de données
Dans une relation 1:1, chaque enregistrement d’une table est associé à exactement un enregistrement de l’autre table. Ce type de relation est utilisé lorsque deux entités sont distinctes mais indissociables, comme une personne et son passeport. Une personne peut avoir un seul passeport, et un passeport appartient à une seule personne.
L’implémentation SQL consiste à ajouter une clé étrangère dans la table dépendante, ici passeports, accompagnée d’une contrainte UNIQUE. La contrainte UNIQUE sur la colonne personne_id empêche qu’un même passeport soit lié à plusieurs personnes. La contrainte FOREIGN KEY garantit que la valeur référencée existe bien dans la table personnes.
-- Schéma des tables
CREATE TABLE personnes (
id INT PRIMARY KEY,
nom VARCHAR(50)
);
CREATE TABLE passeports (
id INT PRIMARY KEY,
personne_id INT UNIQUE,
numero VARCHAR(20),
FOREIGN KEY (personne_id) REFERENCES personnes(id)
);
-- Données à insérer
INSERT INTO personnes (id, nom)
VALUES (1, 'Alice'), (2, 'Bob'), (3, 'Claire');
INSERT INTO passeports (id, personne_id, numero)
VALUES (1, 1, 'P-1001'), (2, 2, 'P-1002'), (3, 3, 'P-1003');
-- Requête de jointure : chaque personne avec son numéro de passeport
SELECT p.nom, pa.numero
FROM personnes p
INNER JOIN passeports pa
ON pa.personne_id = p.id;Intéressant à lire également
CARDINALITY VISUALIZER: Comprendre les relations entre tables
À quoi sert cet outil ? Le visualiseur de cardinalités SQL permet de voir en temps réel comment les lignes de deux tables se correspondent selon le type de relation choisi. Chaque relation est représentée par un code couleur : les lignes liées partagent la même couleur de fond. Le…
Relation 1:N en base de données
Une relation 1:N signifie qu’un enregistrement d’une table peut être associé à plusieurs enregistrements d’une autre table. Un client peut passer plusieurs commandes, mais chaque commande appartient à un seul client. C’est le type de relation le plus fréquent dans les bases de données relationnelles.
L’implémentation SQL repose sur une clé étrangère client_id placée dans la table commandes, du côté N. Cette clé étrangère référence la clé primaire de la table clients, du côté 1. L’absence de contrainte UNIQUE sur client_id est ce qui permet à plusieurs commandes de pointer vers un même client.
La clause ORDER BY c.id, o.id dans la requête de jointure permet de regrouper visuellement les commandes par client. Cela facilite la lecture des résultats lorsqu’un client possède plusieurs commandes. La jointure INNER JOIN ne retourne que les clients ayant au moins une commande enregistrée.
-- Schéma des tables
CREATE TABLE clients (
id INT PRIMARY KEY,
nom VARCHAR(50)
);
CREATE TABLE commandes (
id INT PRIMARY KEY,
client_id INT,
montant DECIMAL(10, 2),
FOREIGN KEY (client_id) REFERENCES clients(id)
);
-- Données à insérer
INSERT INTO clients (id, nom)
VALUES (1, 'Alice'), (2, 'Bob'), (3, 'Claire');
INSERT INTO commandes (id, client_id, montant)
VALUES (101, 1, 25.50), (102, 1, 12.00), (103, 2, 99.99),
(104, 1, 17.25), (105, 3, 48.00);
-- Requête de jointure : chaque client avec ses commandes
SELECT c.nom, o.id AS commande_id, o.montant
FROM clients c
INNER JOIN commandes o
ON o.client_id = c.id
ORDER BY c.id, o.id;Intéressant à lire également
SQL JOINS VISUALIZER: Comprendre les jointures avec notre outil visuel interactif
L’interface se divise en plusieurs sections qui collaborent pour illustrer le comportement d’une opération de jointure SQL. Vous sélectionnez un type de jointure et un jeu de données, puis l’outil calcule automatiquement le résultat de la requête. Un diagramme de zones de jointure coloré en vert indique visuellement quelle partition des données est conservée selon la jointure active.
Relation N:1 en base de données
Une relation N:1 est la symétrique d’une relation 1:N : on part de la table enfant pour remonter vers la table parente. Plusieurs commandes peuvent appartenir à un seul et même client. Le schéma SQL reste identique à celui d’une relation 1:N, seule la table de départ dans la requête change.
La différence avec 1:N réside uniquement dans la perspective de lecture de la requête. En partant de la table commandes, on interroge d’abord les enregistrements du côté N pour récupérer le client associé. Cette lecture est utile quand l’objectif est de savoir à quel client appartient chaque commande.
Le tri ORDER BY o.id classe les résultats par identifiant de commande plutôt que par client. Cela permet de présenter les commandes dans leur ordre naturel d’insertion ou de numérotation. La requête retourne les mêmes données qu’en 1:N, mais dans un ordre et une logique différents.
-- Schéma des tables (identique à 1:N)
CREATE TABLE clients (
id INT PRIMARY KEY,
nom VARCHAR(50)
);
CREATE TABLE commandes (
id INT PRIMARY KEY,
client_id INT,
montant DECIMAL(10, 2),
FOREIGN KEY (client_id) REFERENCES clients(id)
);
-- Données à insérer
INSERT INTO clients (id, nom)
VALUES (1, 'Alice'), (2, 'Bob'), (3, 'Claire');
INSERT INTO commandes (id, client_id, montant)
VALUES (101, 1, 25.50), (102, 1, 12.00), (103, 2, 99.99), (104, 1, 17.25);
-- Requête de jointure : chaque commande avec son client
SELECT o.id AS commande_id, o.montant, c.nom
FROM commandes o
INNER JOIN clients c
ON c.id = o.client_id
ORDER BY o.id;Relation plusieurs-à-plusieurs (N:N)
Une relation N:N signifie que plusieurs enregistrements d’une table peuvent être liés à plusieurs enregistrements d’une autre table. Un étudiant peut suivre plusieurs cours, et un cours peut accueillir plusieurs étudiants. Ce type de relation ne peut pas être modélisé directement avec une simple clé étrangère en SQL.
La solution consiste à créer une table de liaison, ici inscriptions, qui contient les clés étrangères des deux tables reliées. La clé primaire de cette table est composite : elle combine etudiant_id et cours_id pour garantir qu’un étudiant ne peut pas être inscrit deux fois au même cours. Des colonnes supplémentaires peuvent être ajoutées à cette table si la relation porte elle-même des données, comme une date d’inscription.
La requête de jointure nécessite deux INNER JOIN successifs pour traverser la table de liaison et atteindre les deux tables principales. Le premier INNER JOIN relie inscriptions à etudiants via etudiant_id. Le second INNER JOIN relie inscriptions à cours via cours_id.
-- Schéma des tables
CREATE TABLE etudiants (
id INT PRIMARY KEY,
nom VARCHAR(50)
);
CREATE TABLE cours (
id INT PRIMARY KEY,
intitule VARCHAR(100)
);
CREATE TABLE inscriptions (
etudiant_id INT,
cours_id INT,
PRIMARY KEY (etudiant_id, cours_id),
FOREIGN KEY (etudiant_id) REFERENCES etudiants(id),
FOREIGN KEY (cours_id) REFERENCES cours(id)
);
-- Données à insérer
INSERT INTO etudiants (id, nom)
VALUES (1, 'Alice'), (2, 'Bob'), (3, 'Claire');
INSERT INTO cours (id, intitule)
VALUES (10, 'SQL'), (20, 'PHP'), (30, 'JS');
INSERT INTO inscriptions (etudiant_id, cours_id)
VALUES (1, 10), (1, 20), (2, 20), (2, 30), (3, 10), (3, 30);
-- Requête de jointure : chaque étudiant avec ses cours
SELECT e.nom AS etudiant, c.intitule AS cours
FROM inscriptions i
INNER JOIN etudiants e
ON e.id = i.etudiant_id
INNER JOIN cours c
ON c.id = i.cours_id
ORDER BY e.id, c.id;