Introduction (2)

techniques pour changer un
attribut dans le volume de conditionnement
d’un produit.

Supposons qu’un fabricant de boissons
non alcoolisées veuille promouvoir
un certain produit. Il augmente le
volume du contenant de 10 %, afin d’offrir plus de liquide pour le même
prix. Voyons chacune de ces trois techniques
de dimensions qui changent
lentement et leurs implications dans
cette situation.

Type 1. Le traitement de type 1
remplace l’ancien attribut par un nouveau.
On utilise généralement ce type
pour corriger des erreurs d’historique
ou quand il importe peu de perdre des données d’historique. Si l’on remplace
le volume de l’ancien conditionnement
par le nouveau, on ne pourra pas
calculer correctement les volumes de
ventes passées du produit. Ce type de
changement est le plus simple à  appliquer
sur le plan technique.

Type 2. Avec le traitement de type
2, on crée une ligne nouvelle dimension
avec une clé nouvelle dimension
mais on garde aussi la ligne ancienne
dimension, ainsi que la clé ancienne dimension.
On voudra probablement
garder deux clés dans le data warehouse
: la clé application et la clé dimension.
La clé application est la clé de
production de l’environnement OLTP
(online transactional processing), qui
est inchangée. La clé dimension est
une clé de remplacement qui établit la
corrélation entre les lignes de la table
de faits et celles de la table de dimensions.
La clé dimension prend une
nouvelle valeur.

Il faut aussi suivre la date d’effet de
chaque clé dimension. On pourrait
stocker un intervalle de dates effectives
sous forme de deux valeurs :
from_date et to_date – pour simplifier
la manipulation des données. Le traitement
de type 2 permet de calculer correctement
les volumes de liquide dans
les ventes passées, par exemple, mais
pourrait obliger à  maintenir plusieurs
clés par produit. Appelons la clé
application de notre exemple productid_
app et la clé dimension propre au
data warehouse productid_key.

Type 3. Le traitement de type 3 assure
le suivi des changements d’attributs
dans la même ligne dimension. La
clé reste la même qu’en type 1, mais on
suit l’historique comme en type 2 – ou
presque. Le nombre de changements
que l’on peut suivre n’est pas illimité.
On prédétermine le nombre de changements
ou de versions que l’on veut
suivre – disons trois – et on duplique la
colonne de ce nombre de fois. On
stocke aussi une date effective pour
chaque attribut. Chaque fois qu’un attribut
de produit change, on « pousse »
vers la droite les versions existantes de l’attribut et les dates effectives dans
l’ordre FIFO (first in/first out), en stockant
les nouvelles valeurs dans les colonnes
qui contiennent la version courante
de l’attribut. Ce type est adéquat
quand on veut suivre les changements
historiques, mais qu’on ne veut suivre
avec exactitude que les changements
récents. Il a pour avantage de ne garder
qu’une clé par instance d’une entité (et
pas garder plusieurs clés dimension
comme en type 2) et aussi de maintenir
un historique jusqu’à  un certain
point. Dans l’exemple, nous suivons
trois versions des changements du volume
de conditionnement du produit.