Data warehouse de destination

Destination et trois versions de la table
de dimensions Products.

La table Products_type1 est la plus
simple. Elle contient l’ID produit dans
la colonne productid_app et une clé de
remplacement dans la colonne productid_
key. Il est vrai que dans une implémentation
de type 1, la clé de remplacement
n’est pas obligatoire. Mais le
fait de l’avoir dans la table et de l’utiliser
comme clé de corrélation dans la
table de faits est conseillé pour deux
raisons. Premièrement, vous vous préparez
ainsi à  de futurs changements
qui pourraient nécessiter un type de
traitement plus complexe. Deuxièmement,
la clé application, qui contient la
clé originale provenant du système
source, pourrait être grande, tandis
que la clé dimension de remplacement
est un type de données entier, donc
petit. Gardez à  l’esprit que la clé dimension
sera utilisée comme une clé
étrangère dans toutes les lignes de la
table de faits, qui contient généralement
un grand nombre de lignes : des
dizaines voire des centaines de
millions. Le second argument en
faveur de l’utilisation d’une clé de remplacement
ne s’applique pas au scénario des boissons non alcoolisées
parce que la clé application modèle –
l’ID produit – est aussi un type de données
entier, mais le premier argument
à  lui seul justifie l’ajout d’une clé de
remplacement.

Notons également que l’unicité
des deux clés est imposée car on ne
garde pas plusieurs versions d’un produit
dans une implémentation de type
1. Les autres colonnes de la table
Products_type1 sont productname,
package, et discontinued – une colonne
binaire qui contient 0 (false) si le
produit est actif dans le système de
production, et 1 (true) s’il en a été retiré.
Pour le suivi des produits abandonnés,
voir l’encadré « Produits abandonnés
».

La table Products_type2 contient
les colonnes effective_date et to_date
en plus des colonnes que contient
Products_type1. L’unicité n’est pas imposée
sur la colonne productid_app
parce que, par définition, dans une implémentation
de type 2, il peut y avoir
plusieurs versions de produits avec
une clé application et différentes clés
de remplacement.

La table Products_type3 contient
trois versions d’un produit dans la
même ligne. On voit que les colonnes
package et effective_date sont dupliquées trois fois. On n’a pas besoin
de colonnes effective_date et to_date
séparées parce que la « effective date »
d’une version est la « to date » de la version
précédente. Une implémentation
de type 3 a une ligne pour chaque produit,
donc vous devez imposer l’unicité
des deux clés : production et de
remplacement.

L’infrastructure dans le data warehouse
de destination est en place. Le
moment est venu de passer à  la tâche
principale : créer le package DTS qui
effectuera le rafraîchissement.