Le temps qui passe ?
Voilà un sujet bien poétique.. mais quel rapport avec les cubes ?
Ceci :
La granularité des analyses, typiquement la dimension de temps, est en général bien importante que la finesse de mise à jour dans les bases de données sources.
Par ailleurs, les données immuables n'existent pas !
Je ne peux jamais réprimer un sourire quand un développeur me dit : c'est rare….
Cette approche optimiste ira bien dans certains cas :
- Sexe (M ou F) d'une personne (et encore J)
- Poids d'un article vendu
- …
Mais sera une hérésie dans bien d'autres cas :
- Service d'une personne
- Catégorie d'un article
- …
Le 1er exemple, s'il est mal géré aura pour effet de transférer les charges et produits dans le passé à chaque fois qu'une personne change de service : bonjour les comparaisons au fil des ans : ces comparaisons seront totalement idiotes, rendant le cube totalement inutilisable…
On voit que l'on touche à la véracité des données produites : donc du lourd….
Que faire ?
Bien sûr, faire varier les membres des dimensions intéressantes au fil du temps ; dans mon exemple des catégories d'articles : insérer si besoin est le nouveau membre de dimension Catégories, et insérer dans la dimension articles un nouvel article.
Comment le faire ?
C'est évidemment au niveau du datawarehouse que cela doit se passer.
J'ai déjà évoqué précédemment http://www.dominiqueverriere.com/SSIS/Lists/Billets/Post.aspx?ID=12 l'utilisation de SSIS et de son composant Dimension à variation lente.
On peut aussi utiliser un trigger qui capture les modifications sur la ou les tables intéressantes.
On peut aussi utiliser la capture des données modifiées (Change Data Capture) de SQLServer2008, c'est ce que je vais montrer ici.
On doit d'abord activer la capture des données modifiées pour la base à suivre :
Ensuite le faire pour la ou les tables à surveiller :
Le rôle est créé s'il n'existe pas…net_changes à 1 active la surveillance.
A partir de ce moment sont créés (entre autres)
- Des jobs de capture et ménage
Des tables système :
Celle qui nous intéresse le plus est cdc.<Schéma>_<Table>_CT, dans mon cas cdc.dbo_Personnel_CT.
Je peux en effet voir les effets des mises à jour par :
On voit bien, que, derrière tout cela, il y a du journal de transactions (start_lsn).
On peut traduire lsn en temps et vice-versa par :
Par exemple, pour avoir l'horodatage précis des modifications :
On voit que toutes les modifications (Insert,update,delete) sont capturées ce qui peut poser un problème sur les tables instables : on n'activera jamais le CDC sur une table de ligne de vie qui a un update par seconde !
Que se passe-t-il si on change le schéma d'une table :
Ma table de suivi n'a pas bougé ….
Je désactive et réactive la capture….quid de mes données historiques ?
Snif J
Il faudrait creuser plus (Microsoft si tu me lis…) pour savoir si on peut conserver cet historique malgré tout….sinon cela met tout par terre.
Intégration en amont du cube :
Ayant cette table d'historique, il ne restera plus qu'à extraire les données qui nous intéressent avec la granularité voulue… ex si deux changement de services ont lieu dans la journée et que mon cube est à la journée, je prends le dernier service car il s'agit sans doute d'une correction d'erreur de saisie.
Conclusion :
Voici une technique que j'utiliserai avec précaution car :
- Des problèmes de performances importants peuvent apparaitre si la table devient instable
- La volumétrie de la base sera à surveiller (comme d'habitude)
- Les altérations de schémas me paraissent sensibles
- Il peut arriver que l'on souhaite capturer certaines mises à jour sur une table et pas toutes….