Power Datawarehouse Builder

Power Datawarehouse Builder est l'outil de transformation ETL (Extract Transform Load) des données de la base de l'ERP vers la base Datawarehouse, chaque base ayant un dictionnaire de données différent.

OPTIONS
La liste des dossiers à ignorer, permet d'exclure des dossiers complets du datawarehouse. Minimalement il s'agit du dossier 999.
Le fait d'exclure le dossier 999 n'a aucun impact sur la gestion des tables communes qui est gérée dans le programme.
Un fichier des logs est disponible en activant la trace de l'exécution dans un fichier. Le fichier est ensuite ouvert à la fin de l'exécution et est disponible dans le chemin des fichiers temporaires.
La mémorisation du numéro de modification, qui intervient uniquement pour le mode par suivi des modifications, peut être demandé pour un mode par insertion ou différentiel.

DOMAINES FONCTIONNELS
Les traitements sont organisés par domaines fonctionnels. Cela permet de traiter les domaines séparément ; les domaines fonctionnels correspondent à des cubes de données.
Les dimensions communes sont nécessaires à tout autre domaine fonctionnel.
Il existe 4 modes de mise à jour :
Ne pas traiter : utilisé lorsqu'un domaine fonctionnel n'est pas requis en décisionnel.
Insertion seule : ajoute toutes les données par domaine de la base ERP dans la base Datawarehouse, ce qui correspond au chargement complet/initial. Dans ce cas il est préférable de vider la base avec l'option "Effacement complet avant insertion".
Différentiel par requêtes : rajoute, supprime et modifie les données. Toutes les données par domaine de la base ERP sont lues et synchronisées vers la base Datawarehouse.
Différentiel par suivi des modifications : nécessite l'activation du suivi des modifications (Data tracking) dans SQL Server. Rajoute, supprime et modifie les données. Les données par domaine de la base ERP qui ont fait l'objet d'une modification sont synchronisées vers la base Datawarehouse. Le numéro de tracking est mémorisé dans la base Datawarehouse ; on ne synchronise donc que les modifications de la base ERP à partir de ce numéro de tracking.

Dans tous les modes différentiels, c'est l'ID interne numérique de la donnée ERP qui est utilisé afin de trouver la donnée Datawarehouse. Toute action ERP ou Datawarehouse modifiant les ID internes numériques entraîne un dé-synchronisation des deux bases. Un mode insertion avec effacement devient alors nécessaire au rétablissement de la cohérence des données.

 Suivi des modifications : c'est le mode qui permet de bénéficier rapidement des dernières modifications de l'ERP, puisqu'un lancement fréquent (quotidien par exemple) permet de synchroniser dans le Datawarehouse les données modifiées depuis le lancement précédent (de la veille par exemple).
Certaines actions ne sont pas réalisées dans ce mode, notamment la mise à jour de libellés en cascade sur les dimensions communes (par exemple la modification du libellé d'un établissement sera mis à jour sur l'enregistrement lui-même, mais pas dans toutes les tables qui reprennent ce libellé).
Attention a bien corréler l'horizon du suivi des modifications qui a été configuré dans SQL Server avec la fréquence d'exécution de ce mode.
Pour exploiter ce mode, il convient de:
Lancer une première fois l'ETL en mode "Insertion" en cochant l'option de "Mémorisation du dernier numéro de modification". Cette action va remplir la base Datawarehouse et stocker le numéro de version tracking courant.
Planifier fréquemment (quotidiennement par exemple) l'ETL en mode "Différentiel par suivi des modifications". Cette action va mettre à jour la base Datawarehouse en traitant uniquement les évènements ERP depuis le numéro de tracking.
Planifier l'ETL en mode "Différentiel par requêtes" de manière régulière (hebdomadaire par exemple). Cette action permet de mettre à jour les données non traitées par le mode suivi des modifications.

Communs
Concernant les données communes, aucun mode de mise à jour ne gère la suppression de données afin de préserver l'intégrité de celles-ci. Seul l'effacement avant insertion permet de ne plus avoir de données historiques.

Gestion commerciale
Dans le cas particulier de la gestion commerciale, il faut choisir le mode de gestion des pièces périmées :
L'effacement permet de ne garder que les pièces actives, c'est-à-dire le portefeuille.
En conservant les pièces périmées, un pseudo historique est conservé. Attention, il faudra penser à filtrer chaque requête avec l'état de la pièce pour éviter les mélanges inopportuns.
Un filtrage sur les dates est possible : la plage de dates est appliquée aux dates de pièces, permettant de réduire la dimension temps à traiter sur les pièces de gestion commerciale.
 Effacement complet avant insertion : Cette option efface toutes les données, mais uniquement concernant des dossiers/établissements qui existent dans la base source. Ainsi, les données d'un dossier X de la base DWDIVALTO ne seront effacées que si ce dossier X existe dans la base ERP qui est lue. Voir la fiche expert d'installation pour créer une base vide.

MEMORISATION DES PARAMETRES
Afin de conserver les paramètres correspondants aux différents modes d'exécutions, il est possible de mémoriser les paramètres dans une "configuration" par la gestion des paramètres de l'écran de sélection.
Il est alors possible de mettre au menu Divalto une "configuration" pour la rendre directement accessible.

 Consultez la documentation fiche expert relative au décisionnel pour la configuration d'un menu, ainsi que pour l'installation de Divalto BI et Cube.