Discussion :

[_skip]

Bonjour,

Je suis en train d'essayer de réaliser une modélisation en étoile pour une base de donnée destinée au reporting.
Pour cela je compte créer un job talend qui puisera régulièrement (généralement 1 fois par jour) dans une base de production d'un logiciel que j'ai moi-même écrit, puis à partir de cela, une deuxième base de donnée avec un schéma en étoile sera populée.

Je n'ai pas vraiment de formation consistante en BI, dans un premier temps les requêtes qui attaqueront la base de production seront du SQL standard relationnel.
En fait mon problème est que je ne sais pas trop quelles sont les bonnes pratiques lorsqu'on en vient aux modifications de données.

Je m'explique, si un client change d'adresse, et que mon schéma contient une dimension géographique, Ok les nouveaux faits de vente pour ce client pointeront vers un autre enregistrement géographique que les précédents. Ce cas me convient.

Mon problème est surtout le suivant : les filles qui travaillent dans les magasins saisissent les clients mais il arrive que les informations du client soient complétées ou mises à jour plus tard (plusieurs jours plus tard), il arrive aussi qu'on fasse une erreur de saisie (nom-prénom mal orthographié, date de naissance non indiquée) et qu'on ne rectifie la donnée que le lendemain, ou la semaine suivante.

Dans ce cas je pense que ce serait pas si mal si l'ETL pouvait systèmatiquement updater certaines données dans mon schéma en étoile afin de tenir compte des corrections effectuées, dans le sens ou si j'ai un nouveau fait de vente à importer, je peux aussi forcer un update sur certains champs du client comme son nom par exemple.

D'un autre coté je suis tombé sur un article qui disait que les modifications de données importées dans une base d'analyse étaient la main droite du diable ou alors la résultante d'un design pauvre.

Je suis donc obligé de vous demander comment vous pensez que je devrai manager ceci?

Merci d'avance....

[Stefan C]

Vous avez 2 choix :

1) vous forcez le update. Cette approche est simple mais a le désavantage de l'auditabilité. Vous aurez forcément un jour un gus qui va se pointer en disant "qui a modifié ce client? c'est pas le bon no de téléphone!!!"

Il va falloir donc garder l'historique. La plus simple façon de faire est de charger la table CLIENT tous les jours et stocker toutes les alimentations journalières dans une table historique. Rustique , simple , mais efficace sur des petits projets.

2) vous utilisez les SCD. ( Slowly changing dimensions ). Pour faire simple , à chaque fois qu'on modifie une ligne dans une dimension identifié par sa clé , on "sauvegarde" l'ancienne avec une "date de fin". également on alimente la nouvelle données avec une "date de début".

Resultat :

Client X , adresse A1 , Date de debut D1 , Date de fin D2 , date alimentation D2

Client X : adresse A2 , Date de debut D2 , Date de fin ....( vide car actif ) , date alimentations D2.

Pour ne pas charger la table dimension inutilement et perdre en performance , dans la plupart du temps on stocke tout le "courant" ( date de fin vide ) dans une table CLIENT , et toutes les modifs dans une table CLIENT_HISTO.

La table CLIENT_HISTO montrera donc l'image de la table CLIENT à la date Y dans le passé.

Le net est plein d'articles sur les SCD. Talend a un composant SCD depuis peu il me semble.

Bon courage.

[_skip]

Bonjour,

Tout d'abord merci de votre réponse (et navré de revenir si tardivement donner de mes nouvelles).
Les méthodes que vous proposez, si je les comprend bien, concernent principalement le problème de la traçabilité du changement.

C'est vrai que j'aurai du le préciser mais la vérité est que la modification d'un client dans la base de production est soumise à un droit spécial, et il n'y a pas de demandes de retrouver l'historique des changements.
Ma question était juste de savoir si c'était admis de modifier le client importé par l'ETL 2 semaines plus tard? Partout on lit que ce qui est importé ne doit plus jamais bouger, mais bon c'est de la théorie alors qu'en est-il dans la pratique?

[Prjprj]

Dans la pratique on voit tout, et surtout le pire...

Ce qu'on ne doit pas toucher dans une base d'analyse, se sont les faits : Quand j'ai vendu un DVD, même si je me suis trompé sur le nom du client à qui je l'ai vendu, il n'en reste pas moins vendu. Sauf exception (corrections ponctuelles suite à des bugs par exemple), on ne touche pas à une table de faits.

Pour les dimensions, il arrive que les données changent, pour diverses raisons, la principale restant la correction des erreurs de saisies dues au gens qui tapent trop vite sur leur clavier (c'est ce qu'on appelle la qualité des données, tu trouveras plein de documentation sur le net dessus). Dans ce cas là, dans la majorité des cas, on va faire en sorte que le traitement automatique prenne en compte ces corrections et corrige la dimension en simple update.
Il arrive aussi que Jean Dupont, client fidèle, décide de déménager; de façon à ne pas voir toutes les ventes imputées à notre bon client déménager avec lui (avec un update simple, toutes les ventes avant déménagement se retrouvent à la nouvelle adresse, pas très pratique quand on fait des stats géographiques), il faut utiliser les SCD dont parle cucubau123.

C'est un gros travail de conception à faire, une fois que c'est fait, ton ETL va te simplifier la tache (en général) en te proposant des transformations toutes prêtes pour ne pas avoir à réinventer la roue.

Bonne soirée

[DevNico]

Dans les quelques projets sur lesquels j'ai mis en oeuvre ce genre d'alimentation, on se basait sur les besoin émis par le client pour décider le type de traitement de mise à jour à utiliser.

Si les utilisateurs n'émettent pas de besoin de gestion de l'historique des changements, alors on met en place la première stratégie citée par Cucubau.
C'est moins couteux à mettre en oeuvre, mais une fois qu'une ligne a été mise à jour, on n'a plus d'information sur la donnée écrasée.

Si les besoins de restitution font apparaître la nécessité de garder un historique sur les mises à jour, alors c'est la 2ème stratégie qui doit être utilisée.
La mise en oeuvre est plus lourde, et peut même être complexe (dans le cas des hiérarchies par exemple).

Sinon j'aime bien le "les modifications de données importées dans une base d'analyse étaient la main droite du diable ou alors la résultante d'un design pauvre", mais quand il s'agit de faire le choix entre un projet de 100 jours qui répond au besoin des utilisateurs, et un projet de 500 jours qui propose de mettre en place un environnement qui permettra de répondre à d'éventuels besoins futurs, peu de clients font le choix de la sérénité couteuse.
(Même si je suis d'accord que c'est rarement un choix judicieux à long terme).

Nicolas

[_skip]

Merci de vos réponses

Il arrive aussi que Jean Dupont, client fidèle, décide de déménager; de façon à ne pas voir toutes les ventes imputées à notre bon client déménager avec lui (avec un update simple, toutes les ventes avant déménagement se retrouvent à la nouvelle adresse, pas très pratique quand on fait des stats géographiques), il faut utiliser les SCD dont parle cucubau123.

J'imagine que la solution pour une telle chose serait d'avoir une dimension géographique indépendante de la dimension client. Ainsi un nouveau fait de vente de mr Dupont qui a déménagé se retrouve lié à une autre localité sans affecter ce qui s'est passé dans le temps.

Je pense que ça doit être raisonnable de stocker néanmoins la ville et l'adresse dans la dimension client non pas à des fins d'analyse mais dans le but peut être de pouvoir préparer un mailing ou quelque chose comme ça, cette donnée pourrait alors être mise à jour systématiquement et sans effet rétro-actif en se basant sur la date de dernière modification du client présente dans la base de production.
Qu'en dites-vous?