Partie I
SQL de base
56
© Éditions Eyrolles
Il n’est pas possible de « tronquer » une table qui est référencée par des clés étrangères actives. La solution consiste à désactiver les contraintes puis à tronquer la table.
Intégrité référentielle
L’intégrité référentielle forme le cœur de la cohérence d’une base de données relationnelle.
Cette intégrité est fondée sur la relation entre clés étrangères et clés primaires (ou candidates :
colonnes indexées uniques et non nulles) qui permettent de programmer des règles de gestion
(exemple : l’affrètement d’un vol doit se faire par une compagnie et pour un avion tous deux
existant dans la base de données). Ce faisant, la plupart des contrôles côté client (interface)
sont ainsi déportés côté serveur.
Pour les règles de gestion plus complexes (exemple : l’affrètement d’un avion doit se faire par
une compagnie qui a embauché au moins quinze pilotes dans les six derniers mois), il faudra
programmer un déclencheur (décrits au chapitre 7). Il faut savoir que les déclencheurs sont
plus pénalisants que des contraintes dans un mode transactionnel.
La contrainte référentielle concerne toujours deux tables – une table « père » aussi dite « maître »
(parent/referenced) et une table « fils » (child/dependent) – possédant une ou plusieurs colonnes
en commun. Pour la table « père », ces colonnes composent la clé primaire (ou candidate avec un
index unique). Pour la table « fils », ces colonnes composent une clé étrangère.
Syntaxe
C’est seulement dans sa version 3.23.44 en 2002 (dix ans après Oracle), que MySQL a inclus
dans son offre les contraintes référentielles pour les tables InnoDB. L’intégrité référentielle se
programme dans la table « fils » par la contrainte suivante. Il est conseillé de nommer la
contrainte, sinon MySQL s’en charge. Si la clé étrangère n’est pas déjà indexée, MySQL s’en
charge aussi. Les deux tables ne doivent pas être temporaires.
[CONSTRAINT nomContrainte] FOREIGN KEY [id] (listeColonneEnfant)
REFERENCES nomTable (listeColonneParent)
[ON DELETE {RESTRICT | CASCADE | SET NULL | NO ACTION}]
[ON UPDATE {RESTRICT | CASCADE | SET NULL | NO ACTION}]
Cohérences assurées
L’exemple suivant illustre quatre contraintes référentielles. Une table peut être « père » pour
une contrainte et « fils » pour une autre (c’est le cas de la table Avion).
Web
SQL de base
56
© Éditions Eyrolles
Il n’est pas possible de « tronquer » une table qui est référencée par des clés étrangères actives. La solution consiste à désactiver les contraintes puis à tronquer la table.
Intégrité référentielle
L’intégrité référentielle forme le cœur de la cohérence d’une base de données relationnelle.
Cette intégrité est fondée sur la relation entre clés étrangères et clés primaires (ou candidates :
colonnes indexées uniques et non nulles) qui permettent de programmer des règles de gestion
(exemple : l’affrètement d’un vol doit se faire par une compagnie et pour un avion tous deux
existant dans la base de données). Ce faisant, la plupart des contrôles côté client (interface)
sont ainsi déportés côté serveur.
Pour les règles de gestion plus complexes (exemple : l’affrètement d’un avion doit se faire par
une compagnie qui a embauché au moins quinze pilotes dans les six derniers mois), il faudra
programmer un déclencheur (décrits au chapitre 7). Il faut savoir que les déclencheurs sont
plus pénalisants que des contraintes dans un mode transactionnel.
La contrainte référentielle concerne toujours deux tables – une table « père » aussi dite « maître »
(parent/referenced) et une table « fils » (child/dependent) – possédant une ou plusieurs colonnes
en commun. Pour la table « père », ces colonnes composent la clé primaire (ou candidate avec un
index unique). Pour la table « fils », ces colonnes composent une clé étrangère.
Syntaxe
C’est seulement dans sa version 3.23.44 en 2002 (dix ans après Oracle), que MySQL a inclus
dans son offre les contraintes référentielles pour les tables InnoDB. L’intégrité référentielle se
programme dans la table « fils » par la contrainte suivante. Il est conseillé de nommer la
contrainte, sinon MySQL s’en charge. Si la clé étrangère n’est pas déjà indexée, MySQL s’en
charge aussi. Les deux tables ne doivent pas être temporaires.
[CONSTRAINT nomContrainte] FOREIGN KEY [id] (listeColonneEnfant)
REFERENCES nomTable (listeColonneParent)
[ON DELETE {RESTRICT | CASCADE | SET NULL | NO ACTION}]
[ON UPDATE {RESTRICT | CASCADE | SET NULL | NO ACTION}]
Cohérences assurées
L’exemple suivant illustre quatre contraintes référentielles. Une table peut être « père » pour
une contrainte et « fils » pour une autre (c’est le cas de la table Avion).
Web