|
|
Abonnez-vous gratuitement à Decideo !
|
|
Forums, dernières contributions
Gestion des anomalies dans un datawarehouse
bonjour la liste,
je suis débutante dans le BI alors voilà je souhaite savoir s'il y a eu des articles qui soulèvent la gestions des anomalies suite au chargement de tables avec un etl, j'entends par anomalies des informaions qui ne répondent pas à certaines conditions. Aussi vos points de vue personnels sur ce point m'interesse, quelque soit le domaine fonctionnel le fait de ne pas exploiter ces données succitent quoi??? Comment organiser une éventuelle gestion des anomalies??? quelles méthodes me suggéré d'utiliser pour pourvoir qualifier le travail à faire.Au prix de paraitre ridicule avec ce type de questions je tiens à vous savoir que je suis débutant dans le domaine décisionnel.
Merci j'attends avec impatience vos suggestions.
Cordialement Med
Bonjour,
Personne n'est ridicule en posant une question ...
Il y a un fil qui se rapproche du sujet évoqué.
http://www.decideo.fr/index.php?action=forum&subaction=message&id_chambre=988&id_sujet=15919
Cordialement,
Willy LAW-DUNE
Bonjour,
Je suppose que vous parlez des anomalies fonctionnelles (du type des codes qui n'existe pas dans des référentiels car non validé/obligatoire en saisie). Dans ce cas j'utilise 2 méthodes au choix du responsable utilisateurs.
1ere méthode : les lignes sont rejetées et stockées en attendant d'etre réintégrées une fois les référentiels corrigés par les utilisateurs.
2eme méthode : les lignes sont intégrées avec un code générique par défaut 'inconnu' / 'non ventilées'...
Avantage et inconvénient de la 1ere méthode : les données sont parfaites mais arrivent en retard et cela coute cher en terme d'organisation (il faut qu'un utilisateur mette la base à niveau tous les matins). C'est docn souvent incompatible avec des contraintes de diffusion au petit matin...
Avantage/inconvénient de la 2eme méthode : les données sont imparfaites mais immédiatement disponible et il est facile d'avoir un % des non ventilées de part leur codification spécfique. Donc selon la criticité de l'indicateur, les utilisateur acceptent facilement 1 ou 2 % de dérive pour un cout nul.
Warning : cela devient contraignant quand les utilisateurs exigent ensuite de remettre les historiques à niveau pour retomber à 0%. C'est pourquoi en cas d'élection de la 2eme solution, prévoyez une mise à niveau des historiques au moins 1 week end par trimestre.
|
Ecrire une réponse
