par Paul Conte
Maîtrisez la chronologie d'exécution des contraintes et des triggers des bases
de données
DB2 Universal Database for AS/400 (DB2 UDB) comporte plusieurs fonctions importantes
qui d'une part assurent l'intégrité des données et d'autre part, étendent les
fonctions des bases de données. Deux de ces fonctions, les contraintes d'intégrité
référentielle et les triggers (ou programmes déclencheurs) peuvent être définis
par un administrateur de bases de données (ou un utilisateur autorisé) pour se
protéger des mises à jour susceptibles de générer des données invalides ou incohérentes.
On peut également utiliser des triggers pour exécuter des tâches qui ne sont pas
intégrées dans DB2 UDB (comme afficher des informations sélectionnées sur des
mises à jour de bases de données dans une table de journalisation définie par
un utilisateur par exemple).
Du fait qu'une opération sur une base de données peut entraîner DB2 UDB à évaluer
une ou plusieurs contraintes et appeler un ou plusieurs triggers, il est essentiel
de maîtriser la chronologie des différentes opérations d'insertion, de modification
et de suppression dans les bases de données. Le présent article apporte quelques
informations sur la chronologie des contraintes et des triggers afin de vous permettre
de concevoir des applications fonctionnant de manière efficace.
Pour commencer, examinons rapidement les concepts de base des contraintes d'intégrité
référentielles et des triggers (pour plus de plus amples informations, veuillez
consulter l'encadré "Bibliographie").
Les contraintes d'intégrité référentielle et les triggers peuvent protéger des
données invalides ou incohérentes
Contraintes d’intégrité et Triggers: vers une chronologie parfaite
DB2 UDB prend en charge quatre types de contraintes d’intégrité référentielle
:
Primary Key (clé primaire). Une table (c’est-à -dire un fichier
physique) peut posséder une clé primaire composée d’une ou plusieurs colonnes
(c’est-à -dire des champs) de la table. Toutes les lignes (c’est-à -dire enregistrements)
de la table doivent satisfaire les conditions suivantes :
· Toutes les colonnes des clés primaires doivent ne pas être nulles.
· Toutes les lignes doivent posséder une valeur de clé primaire différente.
Unicité. Une table peut posséder une ou plusieurs contraintes
d’unicité, chacune étant composée d’une ou plusieurs colonnes de la table. Pour
chaque contrainte d’unicité, toutes les lignes de la table doivent posséder une
valeur distincte pour la (les) colonne(s) de la contrainte ou avoir une ou plusieurs
des colonnes de la contrainte d’unicité installée nulles.
Foreign key (clé étrangère). Une table (appelée table dépendante)
peut disposer d’une ou plusieurs clés étrangères, chacune étant constituée d’une
ou plusieurs colonnes de la table. Chaque clé étrangère fait référence à une (ou
plusieurs) colonne(s) correspondante(s) d’une clé primaire ou d’une contrainte
unique dans la table parent. La table parent peut être une table différente de
la table dépendante (mais pas obligatoirement). Pour chaque clé étrangère, toutes
les lignes de la table dépendante doivent posséder une valeur correspondante dans
la table parent ou avoir une ou plusieurs colonnes de la clé étrangère nulles.
Check (contrôle).Une table peut posséder une ou plusieurs
contraintes de contrôle, chacune constituée d’une condition impliquant une ou
plusieurs colonnes de la table. Par exemple, une contrainte de contrôle peut spécifier
CustomerId > 0. Toutes les lignes d’une table doivent alors satisfaire aux conditions
de la contrainte de contrôle.
On peut créer des contraintes avec les instructions SQL/400 Create Table et Alter
Table ou avec la commande AddPfCst de l’OS/400
On peut créer des contraintes avec les instructions SQL/400 Create Table et Alter
Table ou avec la commande AddPfCst de l’OS/400 (Add Physical File Constraint).
DB2 UDB bloque toujours les opérations d’insertion ou de modification de ligne
qui violeraient une contrainte clé primaire, d’unicité ou de contrôle (les opérations
de suppression ne peuvent, quant à elles, jamais violer un de ces trois types
de contraintes).
Pour les contraintes de clés étrangères, DB2 UDB bloque toujours les opérations
d’insertion ou de modification sur la table dépendante (celle possédant la contrainte
clé étrangère) susceptible de créer une ligne orpheline (ligne possédant une valeur
de clé étrangère non nulle qui ne correspond à aucune valeur des colonnes associées
de la table parent). Par exemple, une table « Ventes » reprenant les ventes réalisées
peut être définie avec une colonne clé étrangère CustomerId qui fait référence
à la colonne clé primaire CustomerId dans la table Customer. DB2 UDB empêche l’insertion
ou la modification d’une ligne de Ventes si celle-ci doit être enregistrée avec
une colonne CustomerId non nulle qui ne correspond à aucune valeur de la colonne
CustomerId de la table Customer.
Lorsqu’on définit une contrainte de clé étrangère, on définit également l’action
que DB2 UDB doit entreprendre lorsqu’une modification ou une suppression de ligne
parent est susceptible de laisser des lignes de la table dépendante sans correspondance
(par exemple lorsque la suppression d’une ligne Customer risque de laisser un
enregistrement Ventes sans correspondance). « Restrict » et « No Action » sont les
options disponibles pour les opérations de mise à jour. Les deux options bloquent
toutes mises à jour susceptibles de générer des lignes orphelines, mais elles
réagissent différemment lorsque DB2 UDB les met en oeuvre. J’en parlerai un peu
plus loin.
Pour les opérations de suppression, on peut indiquer « Restrict » ou « No Action »,
ces deux options sont semblables aux options de mise à jour. De plus, on peut
spécifier « Set Default » ou « Set Null », qui incitent DB2 UDB à placer toutes les
colonnes des clés étrangères correspondantes à leur valeur par défaut ou nulle
dans la mesure du possible. Si cette action évite une violation de la contrainte
clé étrangère, la suppression de la ligne parent est autorisée. On peut aussi
spécifier « Cascade » pour les opérations de suppression. Cela entraîne DB2 UDB
à tenter de supprimer toutes les lignes dépendantes. Si ces suppressions en cascade
sont exécutées avec succès, la suppression de la ligne parent est autorisée.
DB2 UDB peut avoir à invalider une opération de mise à jour ou de suppression
dans la base de données à cause d’une violation de la contrainte de clé étrangère
DB2 UDB impose cependant une condition importante : lorsqu’on définit une contrainte
de clé étrangère avec une action autre que « Restrict » pour la règle de mise à
jour ou de suppression, la table dépendante et la table parent doivent toutes
deux être historisées dans le même journal. Comme je l’explique plus loin, DB2
UDB peut avoir à invalider une opération de mise à jour ou de suppression dans
la base de données à cause d’une violation de la contrainte de clé étrangère et
DB2 UDB utilise alors les entrées du journal pour accomplir cette invalidation.
Un trigger appelé avant l’insertion ou avant la mise à jour peut modifier le contenu
de la ligne à insérer ou à mettre à jour
Téléchargez cette ressource
Comment lutter contre le Phishing ?
Dans un environnement cyber en constante mutation, le phishing évolue vers des attaques toujours plus sophistiquées combinant IA, automatisation et industrialisation. Découvrez les réponses technologiques préconisées par les experts Eviden et les perspectives associées à leur mise en œuvre.
Les articles les plus consultés
- Une baie de stockage c’est quoi ?
- Cybersécurité Active Directory et les attaques de nouvelle génération
- Activer la mise en veille prolongée dans Windows 10
- N° 2 : Il faut supporter des langues multiples dans SharePoint Portal Server
- Partager vos images, vidéos, musique et imprimante avec le Groupe résidentiel
Les plus consultés sur iTPro.fr
- 5 tendances 2025 pour un virage technologique stratégique
- Comment éviter les fuites de données ? un webinaire des experts Kyocera
- Black Friday le 29 novembre : les cybercriminels en embuscade, prudence !
- DSI & directeurs financiers : une relation plus solide pour de meilleurs résultats
- Le support IT traditionnel pourrait disparaitre d’ici 2027