> Tech > Contraintes

Contraintes

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

Les tables SQL (et les fichiers physiques DDS) peuvent avoir quatre genres de contraintes : clé primaire, unique, clé étrangère et contraintes de vérification. DB2 utilise les chemins d’accès indexés associés au fichier physique sousjacent pour mettre en oeuvre des contraintes de clé primaire et unique

Contraintes

pour les tables SQL. Une contrainte de clé étrangère utilise un chemin d’accès indexé sur le fichier physique de la table dépendante. L’utilisation de la commande MovObj pour déplacer une table SQL vers un schéma différent conserve les contraintes de la table. Si la table a une contrainte de clé étrangère, la table « parente » est inchangée.

Quand vous utilisez CrtDupObj pour créer un double d’une table dans le même schéma, la table conserve ses contraintes inchangées. Si vous dupliquez aussi les données de la table et si la table originale a une contrainte avec l’état « check pending » (par exemple, une certaine ligne de la table viole une contrainte qui est validée), l’état check pending demeure également pour la nouvelle table. Tant que vous n’aurez pas corrigé les violations de contraintes, aucune opération ne sera autorisée sur une table avec l’état check pending pour une contrainte de vérification. Pour une contrainte de clé étrangère avec un état check pending, seules les opérations de lecture et d’insertion sont autorisées sur la table parente, et aucune opération n’est autorisée sur la table dépendante.

Pour corriger les violations de contraintes, utilisez la commande ChgPfCst pour changer l’état de contrainte en *Disabled, ce qui vous permet de mettre à jour les données de la table. Une fois les violations corrigées, rechangez l’état de la contrainte en Enabled.

La création d’un double d’une table dans un schéma différent présente une singularité : quand la table originale a une clé étrangère qui référence une table parente dans le même schéma, la clé étrangère de la nouvelle table est elle aussi changée pour référencer une table parente (avec les mêmes champs name et key) dans le même schéma que la nouvelle table.

A titre d’exemple, supposons une table parente P et une table dépendante D dans le schéma S1, et aussi une table P dans le schéma S2. Quand vous exécutez une commande telle que

CrtDupObj Obj( D )

FromLib( S1 ) +

ObjType( *File ) +

ToLib( S2 )

le système essaie d’ajouter une contrainte de clé étrangère à la table D dans le schéma S2, et cette contrainte référence la table P dans le schéma S2. S’il n’existe pas de table nommée P dans S2, la contrainte est ajoutée à la nouvelle table D, mais elle est placée dans l’état « defined/enabled ». Quand une table parente adéquate est créée dans S2, la contrainte de clé étrangère de la table D sera changée en « established/enabled ».

(Le processeur de commandes SQL ne vous permettra pas d’utiliser une instruction Create Table pour créer une table avec une contrainte de clé étrangère qui référence un parent non existant. Cependant, la commande CrtDupObj n’a pas besoin que la table parente existe au moment où vous dupliquez une table dépendante.)

Si une table parente (P dans cet exemple) existe dans S2 mais est dépourvue des colonnes référencées dans la clé étrangère de la table D nouvellement dupliquée, la contrainte de clé étrangère est entièrement abandonnée dans la nouvelle table. Si la table parente a les colonnes nécessaires mais pas une clé primaire ou une contrainte unique appropriée (comme DB2 l’exige pour toutes les tables parentes), la contrainte est placée dans l’état defined/enabled jusqu’à ce qu’une clé primaire ou une contrainte unique adéquate soit ajoutée à la table parente.

Quand une contrainte de clé étrangère devient established/enabled, le système vérifie que les lignes de la table dépendante satisfont toutes à la contrainte de clé étrangère ; si une ligne n’y satisfait pas, la contrainte est marquée en check pending. Comme dit plus haut, jusqu’à ce que vous ayez corrigé toutes les violations de contrainte (ou que vous ayez désactivé ou supprimé la contrainte), seules des opérations read et insert seront autorisées sur la table parente, et aucune opération ne sera autorisée sur la table dépendante.

CrtDupObj a une autre particularité : le fait de créer une table en double dans le même schéma génère de nouveaux noms uniques pour les contraintes detoutes les tables. Les noms sont du genre QSYS_xxx_00001, où xxx est tout ou partie du nom de contrainte originale (ou le nom de la table, si la contrainte originale avait un nom généré par le système) et les cinq derniers caractères sont un numéro de séquence chargé de rendre le nom de contrainte unique dans le schéma.

 

Téléchargez gratuitement cette ressource

Protection des Données : 10 Best Practices

Protection des Données : 10 Best Practices

Le TOP 10 des meilleures pratiques, processus et solutions de sécurité pour mettre en œuvre une protection efficace des données et limiter au maximum les répercutions d’une violation de données.

Tech - Par iTPro - Publié le 24 juin 2010