> Tech > Contraintes d’intégrité et Triggers: vers une chronologie parfaite

Contraintes d’intégrité et Triggers: vers une chronologie parfaite

Tech - Par iTPro.fr - Publié le 24 juin 2010
email

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

Guide de Sécurité IA et IoT

Guide de Sécurité IA et IoT

Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.

Tech - Par iTPro.fr - Publié le 24 juin 2010