Transformation de dimension à variation lente :
J'ai déjà évoqué cette transformation ici http://www.dominiqueverriere.com/SSIS/Lists/Billets/Post.aspx?ID=12 elle est utilisée en amont d'un cube pour permettre de stocker/gérer des données instables dans le temps.
La notion de membre inféré est assez fumeuse dans la documentation ,aussi ai-je voulu aller plus loin pour mesurer les tenants et aboutissants.
Soit cette table d'origine :
Source de mes données de dimension ….et celle-ci :
Cible de mes données de dimension.
Voici la transformation mise en œuvre :
La stratégie que j'ai choisie est la suivante :
- Changement de prénom : modification en lieu et place
- Changement de nom (mariage) : historisation sur un nouveau membre de dimension avec horodatage de l'événement
Cela étant l'objet de la transformation.
Maintenant le membre inféré ?
Imaginons que la table DimPersonne soit mise à jour de deux façons :
- L'une par ce package
- L'autre par un autre traitement (package ou autre)
Et que l'on puisse insérer des membres de dimension dans un 1er temps par cet autre traitement, membres qui seront complétés par mon package dans un deuxième temps.
Ceux qui ont du métier se diront tout de suite : mais il y a violation des clés étrangères ??? En effet si on a du insérer un membre de dimension, c'est qu'on en avait besoin et donc qu'une ligne du groupe de mesure y faisait référence…
Donc pour moi, du travail de cochon… mais bon, admettons le cas…
Pour gérer ceci, il nous faut un indicateur sur la table cible, c'est-à-dire ma table DimPersonne : j'ai choisi Infere de type bit.
1ère mise en garde :
Les valeurs NULL ne sont pas gérées et provoquent un plantage du package (Type DT_BOOL) ; il faut donc avoir toujours une valeur.
Je règle ce problème de cette manière :
Et là :
En clair, tot ce qui vient par mon pakgae se voit attribuer Infere à FALSE.
Ceci étant fait, la notion de membre inféré peut être utilisée.
Voyons ceci en exécution :
| | Table d'origine | Table de destination |
Avant mon 1er run | 
| |
Après mon 1er run | | 
|
Insertion d'un membre inféré | 
| 
|
Données sur le membre arrivent à la source | 
| 
|
Après mon 2ème run | 
| 
|
2ème mise en garde :
Si vous gérez les dates de début et fin de validité comme dans cete exemple, il faut toujours une valeur de DtDebut même pour les membres inférés.
Ce que je corrige ici :
Et qui me donne l'éxecution correcte :
Après mon 2ème run | 
| 
|
Comme chacun sait, en relationnel, NULL ne se compare à rien…
Conclusion :
Je trouve que cette possibilité est une porte ouverte aux 'bidouilleurs' qui refusent l'intégrité référentielle, mais elle existe…et est une question de certification…donc …