Une solution de dimensions qui changent lentement (2)

la
table Prod_log. Tout en étant connecté
à  la base de données source, exécutez
le script du listing 3 pour créer les triggers
INSERT et DELETE. Notons que
SQL Server utilise l’attribut de colonne
IDENTITY et la valeur par défaut GETDATE(),
respectivement, pour générer
les valeurs lsn et log_date. Les valeurs
namechg et packagechg n’ont aucune
importance quand vous insérez ou
supprimez des valeurs, donc elles reçoivent
des NULL.

Le trigger UPDATE est plus complexe.
Tout d’abord, il vérifie s’il y a eu
une tentative de changer l’ID du produit
et si oui, il ramène en arrière la
transaction. (Un système OLTP bien
conçu devrait interdire tout changement
de l’ID produit une fois qu’il est
défini.) Le trigger UPDATE doit aussi
comparer l’ancienne image des données
(la table supprimée) à  la nouvelle
image (la table insérée) pour s’assurer
que le nom ou le conditionnement du
produit a changé et pour déterminer
les nouvelles valeurs des colonnes namechg
et packagechg. Il est intéressant
d’utiliser la fonction UPDATE() pour
déterminer si ces colonnes ont changé,
pour deux raisons. Premièrement,
votre trigger devrait traiter des mises à 
jour multi lignes, mais les attributs
de produit dans certaines lignes
pourraient changer tandis que les attributs
d’autres produits restent les
mêmes. Deuxièmement, la fonction
UPDATE() renvoie TRUE quand vous
spécifiez une colonne dans la clause
SET d’une instruction UPDATE, et ce,
que la valeur de la colonne ait changé
ou non. Vous pouvez exécuter le script
illustré dans le listing 4 pour créer
un trigger UPDATE sur la table
Products.

Pour tester vos triggers, appliquez
les instructions INSERT suivantes à  la
table Products :

INSERT INTO Products(productid, productname,

package)

VALUES(1à˜1, 'prod1', 1à˜)

INSERT INTO Products(productid, productname,

package)

VALUES(1à˜2, 'prod2', 1à˜)

INSERT INTO Products(productid, productname,

package)

VALUES(1à˜3, 'prod3', 1à˜)