Opérations de suppression

dans cette table ne laisse pas
de ligne orpheline dans une table dépendante.
3. Suppression de la ligne et vérifications autres que les contraintes.
4. Appel du trigger exécuté après la suppression.
5. Mise en oeuvre des suppressions de lignes en cascade pour toutes les tables
dépendantes qui spécifient la contrainte « On Delete Cascade » pour cette table.
6. Mise à  jour des lignes de toutes les tables dépendantes qui spécifient les
contraintes « On Delete Set Null » ou « On Delete Set Default » pour cette table.
7. Vérification des contraintes de clés étrangères de toutes les tables dépendantes
qui spécifient la contrainte « On Delete No Action » pour cette table.

Les opérations de suppression ne peuvent jamais violer une
contrainte clé primaire, unique ou de vérification

Cette séquence est une version étendue des opérations effectuées
pour une mise à  jour. Les ajouts principaux sont les étapes qui gèrent les options
supplémentaires (Cascade, Set Null et Set Default) pour la règle clé étrangère
« On Delete ». Bien entendu, les opérations de suppression ne peuvent jamais violer
une contrainte de clé primaire, d’unicité ou de contrôle. Ainsi celles-ci ne
font pas partie du processus.
Quand une contrainte « On Delete Cascade » est traitée (étape 5), il est possible
qu’une table dépendante soit la table parent d’une contrainte de clé étrangère
« On Delete Restrict » d’une autre table. Regardez l’exemple de la figure 1 où
la table T1 est le parent de la table T2 dans une contrainte « On Delete Cascade »
et la table T2 est le parent de la table T3 dans une contrainte « On Delete Restrict ».
Dans l’étape 2 susmentionnée, on voit qu’une application ne peut pas exécuter
directement une opération de suppression sur T2 si des lignes orphelines peuvent
en résulter dans T3. DB2 UDB empêchera également toute suppression de T1 si
une suppression de T2 résultante en cascade est susceptible de générer des lignes
orphelines dans T3.
Il est cependant possible que T1 soit aussi le parent de la table T3 dans une
contrainte « On Delete Cascade ». C’est-à -dire T3 pourrait avoir deux contraintes
de clé étrangère : une contrainte « On Delete Cascade » avec T1 comme parent et
une contrainte « On Delete Restrict » avec T2 comme parent. Si c’est le cas, DB2
UDB achève toutes les suppressions en cascade dans T2 et T3 avant d’évaluer
la contrainte « On Delete Restrict » de la table T3 avec T2 comme parent. Une
logique similaire gère les contraintes « On Delete Set Default » et « On Delete
Set Null ».
En général, une opération de suppression est autorisée aussi longtemps que l’état
résultant de la base de données satisfait toutes les contraintes clés étrangères.
Il existe une exception importante à  cette règle : une contrainte « On Delete
Restrict » sur la table principale (celle à  partir de laquelle l’application
efface directement les lignes) est mise en application immédiatement, une ligne
à  la fois. La vérification d’une contrainte « On Delete Restrict » est différée
jusqu’à  la fin de l’opération uniquement lorsque la contrainte s’applique à 
des suppressions en cascade.
DB2 UDB impose aussi deux restrictions aux triggers sur une table possédant
une contrainte clé étrangère :

· Une table possédant une règle clé étrangère « On Delete Cascade » ne peut pas
posséder de trigger exécuté avant ou après la suppression.
· Une table possédant une règle clé étrangère « On Delete Set Null » ou « On Delete
Set Default » ne peut pas posséder de trigger exécuté avant ou après la mise
à  jour.

Ces restrictions évitent que la suppression en cascade ou la mise à  jour indirecte
d’une table dépendante active un programme déclencheur pour cette table. Ces
restrictions sont nécessaires parce que DB2 UDB met en oeuvre des actions liées
aux règles de suppression à  un niveau plus bas sur le système d’exploitation
que ne le font les triggers, ainsi une suppression en cascade ou une mise à 
jour indirecte ne peut pas activer de trigger sous l’architecture DB2 UDB actuelle.

On peut désormais utiliser sans risque ces deux fonctions puissantes
pour protéger ses bases de données

Fort de ces informations détaillées sur l’ordonnancement des vérifications
des contraintes et l’activation des programmes déclencheurs DB2 UDB, on peut
désormais utiliser sans risque ces deux fonctions puissantes pour protéger ses
bases de données et étendre leurs fonctionnalités.