Datawarehouse | BI experience

Archive pour la catégorie ‘Datawarehouse’

Industrialiser son datawarehouse

Vendredi 8 octobre 2010

Comment rechargez-vous, ou rafraichissez-vous votre datawarehouse? Quelle est votre méthode d’industrialisation afin que la plateforme de production puisse offrir des données à jour aux utilisateurs finaux?

Voici la méthodologie utilisée dans mon projet :

1 - Pointer les bases de données sources des datamarts => il faudra séparer les datamarts en fonction afin que s’il y est un problème sur l’une des bases de données sources cela n’impacte pas d’autres datamarts non liés à cette source.

2 - Lister les dimensions et les datamarts qu’elles touchent => si une dimension est rechargée il faudra recharger les faits concernés en conséquence

3 - Identifier les fréquences de chargement pour rassembler les faits ou dimensions qui devront être rafraichis en même temps

4 - Etablir l’ordre dans lequel les dimensions et faits doivent être remplis

En fonction des ces 4 points il se dégage deux visions :

- une vision faits => en fonction de la base de données, de la fréquence, de l’ordre de chargement il faudra créer des blocs de faits qui seront ensuite schedulés en évaluant le temps de chargement de chaque blocs

- une vision dimensions/faits => dès qu’une dimension est rechargée il faudra recharger les faits qu’elle touche. Lors du scheduling il faudra aussi évaluer le temps de chargement de ces blocs dimensions/faits

La représentation sous forme de schémas peut vraiment aider…

Ce scheduling est donc fait pour les jobs de production sur le datawarehouse de production. La fenêtre de temps d’exécution de cet industrialisation doit quand même être bien évaluée car si juste avant vous avez l’alimentation de votre infocentre (copie des bases de données sources) lui même lancer après les actions de backup, restore des bases de données sources…Vous imaginez que tout ça doit être prévu assez précisement.

Et vous comment faites vous?

Création d’une Dimension temps

Dimanche 14 mars 2010

Dans un projet décisionnel, la dimension temps est toujours nécessaire. Dans mon projet actuel, nous avons fait le choix d’avoir 3 dimensions temps :

  • la première ne répertorie que des années
  • la seconde des années et des mois
  • la troisième va jusqu’au jour

Ces 3 dimensions sont utilisées dans des datamarts différents qui n’ont pas forcement la même granularité de temps.

Dans cette article je voulais juste vous montrer comment nous avons construit la troisième dimension temps puisque tous les développeurs BI seront amenés à en construire une :

construction_dim_temps

Comme vous pouvez le voir nous avons un tLoop qui va nous permettre d’incrémenter l’année au fur et à mesure. Voici ce qu’il y a dans le composant d’input de type PostgresInput :


SELECT

/**”+((Integer)globalMap.get(”tLoop_1_CURRENT_ITERATION”))+” représente le 1 à ajouter à chaque itération provenant du tLoop**/
“+((Integer)globalMap.get(”tLoop_1_CURRENT_ITERATION”))+” + 1,

/**utilisation de la fonction (date interval 1 day) afin d’ajouter 1 jour en plus à l’année ***/
(date \’1900-01-01\’ + interval \’”  +((Integer)globalMap.get(”tLoop_1_CURRENT_ITERATION”))+  ” day\’),

/**utilisation de la fonction date_part (’day’, date) afin de récupérer le jour de la date ***/
date_part(\’day\’,(date \’1900-01-01\’ + interval \’”+((Integer)globalMap.get(”tLoop_1_CURRENT_ITERATION”))+” day\’)),

/**utilisation de la fonction date_part (’month’, date) afin de récupérer le mois de la date ***/
date_part(\’month\’,(date \’1900-01-01\’ + interval \’”+((Integer)globalMap.get(”tLoop_1_CURRENT_ITERATION”))+” day\’)),

/**utilisation de la fonction date_part (’year’, date) afin de récupérer l’année de la date ***/
date_part(\’year\’,(date \’1900-01-01\’ + interval \’”+((Integer)globalMap.get(”tLoop_1_CURRENT_ITERATION”))+” day\’))

Et donc il ne restera donc plus qu’à insérer dans notre dimension temps :

  • la date
  • l’année
  • le mois
  • le jour

Et vous, comment avez vous géré vos dimensions temps ?

ODS vs Staging Area

Lundi 16 mars 2009

Certains parlent d’ODS (Operating Data Store ou magasin de données opérationnelles) d’autres de Staging Area. Mais quelles en sont les points communs et les différences?

l’ODS et le Staging Area ont deux points communs :

  • ils permettent de stocker les données extraites des SI sources
  • de faire des opérations sur ces données

Leurs différences :

Dans le cas du staging Area, les données sont détruits directement après avoir été chargées dans le Datawarehouse mais pas pour l’ODS ou les données auront quand même une durée de vie plus longue.

Finalement l’ODS répond plus à une problématique de reporting immédiat dans le sens ou l’ODS sera mis à jour plus souvent que le datawarehouse : on pourrait dire que l’ODS pourrait être alimenté toutes les semaines et le Datawarehouse une fois par mois.

l’ODS n’est donc pas forcement indispensable si l’entreprise peut recharger son Datawarehouse toutes les semaines : Il sera plus utilisé dans ce cas un Staging Area. C’est une question de politique, de stratégie.

Et vous, dans quel cas êtes vous?

la nomenclature de votre Datawarehouse

Dimanche 8 mars 2009

Il est conseillé lors de la création de votre datawarehouse d’avoir, au préalable, réfléchi à une nomenclature. Alors voici celle que l’on m’a conseillé :

Les tables devrons s’appeler :

  • tb_dwh_fait_nomdufait
  • tb_dwh_dim_nomdemadimension

Pour les tables présentent dans l’ODS qui sont finalement des tables provenant de sources fichiers ou de copies de table de production faute de bases de données de préproduction :

  • tb_ods_fic_nomdufichier
  • tb_ods_source_nomdelatable
  • tbw_ods_nomdelatable : table de travail

Ensuite il faut que

  • les clefs primaires s’écrivent : pk_nomdemaclef
  • les clefs étrangères s’écrivent : fk_nomdelatable_nomduchamp
  • pour les index s’écrivent : idx_nomdelatable_nomduchamp
  • pour les séquences s’écrivent : seq_nomdelatable_nomduchamp

Et enfin les colonnes de vos tables commenceront si possibles par :

  • type_nomduchamp
  • bool_nomduchamp
  • num_nomduchamp
  • code_nomduchamp
  • lib_nomduchamp
  • date_nomduchamp
  • nb_nomduchamp

Tout ce travail de nommage permettra une lecture plus aisée et de finalement pourvoir mieux naviguer dans les données.

Et vous, avez vous un autre type de nomenclature?