Opérations d’insertion

étrangères de cette table. Pour
chaque contrainte clé étrangère, le système s’assure qu’une valeur correspondante
pour la nouvelle clé étrangère de la ligne existe dans la table parent ou qu’une
ou plusieurs colonnes clés étrangères sont nulles.

5. Vérification des contraintes clé primaire, unique et de contrôle. Le processus
s’arrête si le trigger exécuté avant l’insertion retourne un message d’échappement
ou si une erreur se produit durant l’étape 2. Si le programme déclencheur exécuté
après l’insertion retourne un message d’échappement ou si une contrainte est violée,
l’opération d’insertion de la ligne est invalidée (la ligne est retirée de la
table) en utilisant l’environnement de contrôle de validation actif. Quand le
programme déclencheur exécuté après l’insertion retourne un message d’échappement
ou si une contrainte est violée, aucune autre opération ne sera exécutée.

Notez plusieurs implications importantes induites par cette séquence :

· Le trigger exécuté avant l’insertion peut modifier les valeurs des colonnes
de la nouvelle ligne avant que les contraintes ne soient vérifiées. Cela permet
au trigger de corriger d’éventuelles données invalides et assure que tous les
changements sont soumis au respect des contraintes.
· Si nécessaire, un trigger exécuté avant ou après l’insertion peut insérer une
ligne dans la table parent pour satisfaire une contrainte clé étrangère.

· Un trigger exécuté avant ou après l’insertion ne permet pas d’être certain que
la ligne sera insérée de façon définitive. En effet, une violation de contrainte
ou une opération d’invalidation de l’application (même après une insertion réussie)
peut bloquer ou invalider l’insertion. C’est pourquoi, il est généralement recommandé,
pour les programmes déclencheurs qui exécutent des I/O, d’être exécutés dans le
même environnement de contrôle de validation que l’application.
Ainsi, les opérations de validation ou d’invalidation subséquentes de l’application
couvriront également toutes les I/O effectuées par le programme déclencheur.

Pour les passionnés des bases de données qui s’intéressent aux menus détails de
la vérification des contraintes, voici une autre information pertinente : en fait
DB2 UDB vérifie les contraintes de clé primaire et d’unicité en deux phases. La
maintenance des index de base de données est effectuée tout de suite après que
la ligne ait été insérée dans la table (c’est-à -dire après l’étape 2). Si la clé
primaire ou l’index unique contiennent une erreur de type clé en double, cette
exception est différée et la clé en double est revérifiée dans la contrainte de
validation pendant la dernière étape (étape 5).

En dépit de cette nuance, les étapes énumérées ci-dessus fournissent une image
très proche de la séquence effective des événements. En ce qui concerne votre
application, la violation d’une contrainte clé primaire ou unique ne se produit
que si la contrainte échoue au cours de la dernière opération. DB2 UDB utilise
aussi cette approche à  deux étapes pour les opérations de mise à  jour.