Essayez-le (2)

processus
de rafraîchissement pour la transformation
de type 1. Cliquez sur OK et
ouvrez la boîte de dialogue Properties
de Type2 Refresh DDQ task.
Remplissez les propriétés des onglets
Source et Bindings avec les mêmes paramètres
que dans la Type1 Refresh
DDQ task, mais en utilisant
Products_type2 comme table de destination.
Sur l’onglet Transformations,
créez une transformation ActiveX
d’après les associations de la figure 3.

A noter qu’avec la transformation
de type 2, vous extrayez également la
log_date, qui sera la date effective, et la
valeur packagechg, qui détermine s’il faut créer ou non une nouvelle ligne
dimension. La figure 3 montre également
que la colonne namechg est extraite
mais, dans ce cas, utilisons un
traitement de type 1 pour le nom du
produit. Nous pourrons ainsi toujours
remplacer le nom de produit précédent,
qu’il change ou non. Vous pouvez
omettre namechg de la sélection
des colonnes source. Tapez le code de
la boîte de dialogue ActiveX Script
Transformation Properties du listing 7
pour créer la fonction Main().

Si le conditionnement du produit
source n’a pas changé, une valeur -1
(moins un) est stockée dans la valeur
destination package. La raison de cette
attribution est que les requêtes sur
l’onglet Queries n’ont accès qu’au recordset
de destination (qui contient
les colonnes qui apparaissent dans la
table Products_type2) et pas au recordset
source. Cette astuce permet
de dire aux paramètres de requête qui
doivent s’associer aux colonnes dans le
recordset de destination, qu’un package
n’a pas changé. Pour une autre solution,
voir l’encadré « Table de liens
fictive ».

Ensuite, exécutez le script du listing
8 dans une connexion Query
Analyzer vers la base de données de
destination pour créer la procédure
stockée usp_Update_Products_type2,
que je décrirai sous peu. Allez à  l’onglet
Queries et utilisez l’information de
la table 3 pour remplir les requêtes paramétrées
et pour associer les paramètres
aux colonnes du recordset de
destination. La requête Insert insère
dans la table Products_type2 une nouvelle
ligne qui inclut une colonne effective_
date. La requête Delete met à  1
la valeur discontinued du produit qui a
été supprimé du système OLTP.

La requête Update a une tâche plus
complexe. Vous la mettez en oeuvre par
la procédure stockée usp_Update_
Products_type2, créée par le code du
listing 8. Cette procédure vérifie
d’abord si le conditionnement a
changé (@package <> -1). Si oui, la
procédure stockée utilise une instruction
Update pour définir le to_date de
la version produit la plus récente
d’après la date effective courante, puis
utilise une instruction Insert pour générer
une nouvelle version du produit.
Si le conditionnement n’a pas changé,
le nom du produit doit avoir changé et
donc la procédure stockée utilise une
requête Update pour remplacer le
nom du produit existant dans toutes
les versions du produit. Rappelons que
nous utilisons le traitement de type 1
pour tous les noms de produits dans ce
scénario.