Une solution de dimensions qui changent lentement

dans le data warehouse de
destination. Vous voulez aussi appliquer
un processus de rafraîchissement,
ou régénération – le processus
qui modifie réellement les attributs de
dimension – qui utilise celle des trois
techniques de dimensions qui changent
lentement, la mieux adaptée à  vos
besoins. Pour les besoins de la démonstration,
nous nommerons les
tables de dimensions de destination
Products_type1, Products_type2 et
Products_type3 et appliquerons trois processus qui utilisent les trois techniques
de dimensions qui changent
lentement. Nous appliquerons le processus
de rafraîchissement au travers
d’un package DTS, en utilisant la DDQ
task comme l’outil principal du package.
Une base de données appelée
Source représente le système OLTP et
une autre appelée Destination est le
data warehouse de destination. Vous
pouvez créer ces bases de données
dans la même installation de SQL
Server, sur deux instances de SQL Server sur la même machine, ou sur
des machines séparées.

Tout d’abord, il faut préparer l’infrastructure
du système OLTP source.
Connectez-vous au serveur source et
exécutez le script du listing 1 pour
créer la base de données Source et la
table Products. Pour suivre les changements,
vous pouvez créer une table de
journalisation qui enregistre toutes les
transactions émises contre la table
Products, y compris toutes les informations
que demande l’opération de rafraîchissement. On peut comparer la
table de journalisation à  une sorte de
journal de transactions personnalisé.
Nous utiliserons plus tard la table de
journalisation comme source pour le
rafraîchissement.

Ensuite, tout en restant connecté
au serveur source, exécutez le script
du listing 2 pour créer la table
Prod_log. La colonne lsn (log serial
numbers) maintient les numéros de
série du journal, qui sont des valeurs
consécutives générées automatiquement
représentant l’ordre chronologique
des transactions. Les valeurs lsn
détermineront l’ordre dans lequel le
rafraîchissement traite les transactions.
Il est important de traiter les transactions
du système de destination dans le
même ordre que dans le système
source. La colonne log_date stocke les
dates effectives et la colonne tran_type
stocke le type de transaction : I pour
INSERT, D pour DELETE et U pour UPDATE.
Les colonnes productid, productname
et package contiennent les
attributs originaux du produit.
Namechg et packagechg sont des colonnes
binaires qui contiennent 1 si la
colonne qu’elles représentent a
changé et 0 dans le cas contraire.