Revenons un peu sur les bases des modèles de Kimball, autrement appelés modèles en étoile ou en flocon de neige (star-schema, snowflake-schema).

On distingue différentes façons de gérer les dimensions que l’on classe en types (les attributs essentiellement).

• Type 1 : dès qu’un attribut de la dimension change, on met à jour le membre
• Type 2 : si un attribut change, on crée une nouvelle entrée pour conserver l’historique des valeurs
• Type 3 : une version hybride que je n’ai jamais vu une seule fois en prod (ni même en dev)

Pour les attributs de Type 2, il faudra gérer des marqueurs indiquant quelle est la valeur en cours. On peut utiliser un booléen ou des dates (la dernière étant à NULL).

Un exemple pour comprendre :

Dans un cube CRM, j’analyse des ventes par clients et par extension par les différentes caractéristiques de ceux-ci (nombre d’enfants, CSP, etc.).
Quand M. Moulin change de CSP, on souhaite tracer cet événement car on veut garder le fait que M. Moulin était “ouvrier qualifié” quand il a fait son premier achat en 2005 et que ses achats de 2010 sont sous la catégorie “commerçant”.
On crée donc une nouvelle ligne dans la dimension pour représenter ce nouveau M. Moulin.
En revanche, on ne souhaite n’avoir qu’un seul M. Moulin et ses différents achats si on regarde sur l’ensemble des années.
Et si par exemple M. Moulin devenait Mme Moulin (c’est rare mais ça peut arriver), on ne souhaite pas forcément historiser cette information. On changera le champ dans toutes les occurrences.

On a donc une table de dimension qui ressemble à cela :

Et la table de faits comme ceci :

Analysis Services (ie. le cube) saura agréger les ventes de Monsieur Moulin mais aussi les ventes par CSP. Ce “doublon” dans la dimension n’est pas un problème.

Comment implémenter cela dans l’ETL :

En SSIS (et plus généralement dans les ETL), on utilise un composant appelé SCD (Slowly Changing Dimension / Dimension à variation lente) qui prend en charge la mise à jour de la dimension en fonction des types de ses attributs.

On a un assistant qui nous guide dans cette tâche et qui va tout gérer, y compris l’historisation en générant les tâches sous-jacentes

Dans le screenshot ci-dessus, on voit plusieurs sorties au SCD. C’est l’assistant qui a créé tous les composants en dessous en fonction du type des attributs.
Je vous conseille de les renommer (pour les logs) sauf que si vous rejouez l’assistant, il recréera les composants

La question des Inferred Member :

Une étape de l’assistant demande si on doit gérer les Inferred Members (désolé, je n’ai pas le traduction à portée de main). J’ai souvent des questions sur ce point.

C’est pour gérer ce qu’on appelle les “early arriving fact”. En langage clair, ce sont des membres de la dimension qui ont été insérés par un autre moyen (souvent des membres créés à la volée lors de l’insertion des faits pour ne pas lever d’erreur et perdre d’information). Cette gestion évitera qu’au prochain passage du SCD, quand la ligne viendra de la source principale de recréer une ligne d’historique inutile.

Personnellement, je ne l’utilise jamais et je ne suis jamais tombé sur un DataWarehouse utilisant ce concept.

A surveiller :

Attention aux performances. Tout système décisionnel doit gérer des dimensions à variation lente mais c’est souvent un point noir dans le process.

En effet, pour chaque ligne d’entrée, une requête ramenant la ligne est effectuée pour faire la comparaison. Quelques tips :

• faire de l’incrémental (CDC, champ “date de modification”, etc.)
• mettre l’index Clustered sur la Business Key
• ne pas historiser ()

Un point sur la conception :

Lors de la conception de la dimension, quand on fait le choix de l’historisation, il faut être vigilant.

Si vous demandez à l’utilisateur ce qu’on doit historiser, il répondra : “TOUT”. On connait l’adage, “qui peut le plus, peut le moins” mais il faut néanmoins raisonner tout cela car on peut vite tomber sur une usine à gaz.

Y’a t-il vraiment une réalité d’analyse derrière ?

N’oubliez pas que la clé d’un projet de business intelligence est la modélisation de l’analyse (approche top-down, approche MDM, etc.).
La phase d’interview doit être vigilante à ces problématiques “techniques” car ce n’est pas parce que c’est supporté que c’est bon de le mettre.

On sera donc vigilant à la cardinalité. Si votre dimension à 40 attributs et que la fréquence de changement est haute, vous risquez d’avoir énormément de lignes dans la table de dimension.
Je suis tombé une fois sur une dimension ou au moins un des attributs changeait tous les jours. A ce niveau, ce n’est pas une dimension historisée mais des faits.

Un dernier tip pour la route :

Pour la développeur qui doit ouvrir le package longtemps après la conception ou bien le consultant qui l’ouvre pour faire une analyse ou un optimisation, il peut arriver (si le modèle de données est désynchroniser) que le composant perdre sa configuration. C’est rare mais ça m’est arrivé (de moins en moins avec les versions qui avancent).

Pour ne pas devoir fouiller dans le XML du DTSX, je demande à mes équipes de documenter le SCD avec une annotation. Voici un exemple ci-dessous.

Pour finir, les problèmes :

Dans le post suivant, je parlerai d’un petit problème qui existe avec le SCD, les dimensions de Type 2 et les marqueurs de type date

(et je ne parle pas du fait que si vous rejouez l’assistant, il recrée les composants sous-jacent et donc casse tout votre nommage )