FOREIGN KEY CONSTRAINT VISUALIZER

L’outil décompose un scénario complet en 6 étapes navigables pas à pas pour matérialiser visuellement la différence entre un INSERT accepté (ligne verte dans la table commandes) et un INSERT rejeté (table commandes inchangée, bannière rouge). Cette distinction visuelle immédiate ancre la compréhension que le rejet est total : aucune donnée partielle n’est jamais écrite en base lors d’une violation de contrainte.

Le code couleur persistant entre les étapes permet également de suivre le cycle de vie des données. La ligne Alice reste visible en fond neutre tout au long des étapes suivantes, servant de repère visuel constant pour comprendre pourquoi client_id=1 est valide. Cette continuité visuelle est impossible à reproduire dans un exemple de documentation statique.

Les 6 étapes simulées par l’outil

Chaque étape met en surbrillance verte la ligne SQL correspondante dans le bloc de code affiché en haut, et affiche l’état des tables sous forme de grille côte à côte. Une bannière verte ✅ INSERT ACCEPTÉ ou rouge ❌ INSERT REJETÉ indique immédiatement si l’opération a réussi ou échoué, avant même de lire la description textuelle.

Les étapes 1 et 2 montrent la création des deux tables : clients d’abord (table parente), puis commandes avec sa contrainte FOREIGN KEY. Les étapes 3 et 4 insèrent les clients Alice (id=1) et Bob (id=2) dans la table parente. Les lignes insérées apparaissent en vert italique pour signaler qu’elles viennent d’être ajoutées et constituent désormais les valeurs de référence valides pour la FK.

L’étape 5 insère une commande avec client_id=1 : la bannière verte confirme que la clé étrangère est respectée car id=1 existe dans clients. L’étape 6 tente d’insérer une commande avec client_id=99 : la bannière rouge signale le rejet, la table commandes reste inchangée, et la ligne violante est affichée barrée en rouge pour matérialiser l’annulation.

-- Étape 3 et 4 : insertion des données de référence (table parente)
INSERT INTO clients VALUES (1, 'Alice');
INSERT INTO clients VALUES (2, 'Bob');

-- Étape 5 : INSERT accepté — client_id=1 existe dans clients
INSERT INTO commandes VALUES (101, 1, 150.00);

-- Étape 6 : INSERT rejeté — client_id=99 n'existe pas dans clients
INSERT INTO commandes VALUES (102, 99, 200.00);
-- Erreur : Cannot add or update a child row: a foreign key constraint fails

Qu’est ce qu’une clé étrangère et pourquoi elle existe

Une clé étrangère (FOREIGN KEY) est une colonne d’une table dont chaque valeur doit correspondre à une valeur existante dans la clé primaire d’une autre table. Elle crée un lien obligatoire entre une table enfant et une table parente, garantissant que les données référencées existent réellement. Sans cette contrainte, une commande pourrait pointer vers un client inexistant, corrompant silencieusement l’intégrité de la base.

La table qui déclare la FOREIGN KEY est appelée table enfant, et la table qu’elle référence est la table parente. Dans l’outil, la table commandes est l’enfant et la table clients est le parent. La colonne client_id de commandes doit obligatoirement pointer vers un id existant dans clients.

Le moteur SQL vérifie cette contrainte à chaque INSERT et UPDATE sur la table enfant. Si la valeur insérée dans client_id ne correspond à aucun id dans clients, la commande est rejetée intégralement et aucune ligne n’est ajoutée. Ce rejet automatique protège la cohérence relationnelle sans qu’aucun code applicatif ne soit nécessaire.

-- Schéma avec clé étrangère
CREATE TABLE clients (
  id  INT PRIMARY KEY,
  nom VARCHAR(50)
);

CREATE TABLE commandes (
  id        INT,
  client_id INT,
  montant   DECIMAL(10, 2),
  FOREIGN KEY (client_id) REFERENCES clients(id)
);

Pourquoi l’ordre de création des tables est obligatoire

La table parente doit toujours être créée avant la table enfant qui la référence. Tenter de créer commandes avant clients déclencherait une erreur immédiate du moteur, car la contrainte FOREIGN KEY ne peut pas référencer une table inexistante. L’outil le modélise explicitement en plaçant la création de clients en étape 1 et celle de commandes en étape 2.

La même règle s’applique à l’insertion des données : les lignes de la table parente doivent exister avant d’insérer des lignes dans la table enfant. C’est pourquoi les étapes 3 et 4 insèrent les clients avant que la commande ne soit insérée en étape 5. Inverser cet ordre provoquerait exactement le même rejet que celui montré en étape 6.

-- ❌ Incorrect : créer la table enfant avant la table parente
CREATE TABLE commandes (
  client_id INT,
  FOREIGN KEY (client_id) REFERENCES clients(id) -- clients n'existe pas encore
);

-- ✅ Correct : créer la table parente en premier
CREATE TABLE clients (id INT PRIMARY KEY, nom VARCHAR(50));
CREATE TABLE commandes (client_id INT, FOREIGN KEY (client_id) REFERENCES clients(id));