Discussion :

[IsHappy]

Bonjour,

Il y a eu plusieurs discussions sur l'historisation, mais je n'ai hélas pas trouvé la réponse que je cherche. Pourtant Google est mon super ami.

Je cale depuis plusieurs jours sur cette question qui porte à la fois sur la gestion du changement et l'historisation des données, que ce soit dans des tables de fait de base (granularité la plus fine identique à celle du système opérationnel) ou les tables agrégées. Je ne parle pas ici du Slowly changing dimensions mais plutôt du Slowly changing facts, si je puis me permettre l'analogie.

Les changements sont variés : commande de décembre annulée en février ou au contraire une commande au départ de 100 euros en décembre et qui passe à 200 euros en février. Un taux de remise de 3% qui passe à 5% en février pour une commande passée en décembre. Si on change les données de décembre, les utilisateurs relançant leurs états sur décembre ou faisant des comparatifs mensuels verront leur reporting de décembre modifié. Et ce n'est pas envisageable, à part vouloir faire du support téléhonique et de l'exploration de données toute la journée pour expliquer chaque centime d'écart.

En clair, comment faites-vous pour gérer les changements du système opérationnel au niveau des faits, sans remettre en cause le reporting existant issu du datawarehouse? Certains changements peuvent même aller jusqu'à la suppression physique de la donnée (ce qui ne doit jamais arriver, mais bon).
Et en fait, je parle de changements entre décembre et février, mais ce pourrait être entre hier et aujourd'hui. Une fois que la donnée est communiquée à l'extérieur, elle ne devrait plus changer. Mais l'opérationnel lui change. Alors...?

Egalement, comment vérifier qu'un attribut d'une dimension/d'une table de fait a changé sans comparer un à un tous les champs? Je reprends l'exemple d'une commande passée en décembre pour laquelle une remise passe à 5% pour une ligne de la table détail_commande au niveau d'un produit. Mais ça peut être un autre lieu de livraison de la commande ( ce qui modifierait le total par région) ou un changement de commercial (ce qui changerait le total par commercial).

Désolé de ce message un peu long, mais je souhaitais éviter les ambigüités et les quiproquos.
Merci de vos réponses.

[Jean_Paul_XX]

Peux-tu préciser stp :
- Combien de temps reste 'Ouverte' une commande (non facturée) ?
- Nombre de changements qu'elle peut subir durant ce temps ?
- Combien de Cdes ouvertes à un instant t ? % Total ?

Ma question est orientée : as-tu envisagé un reporting à 2 niveaux, Cdes facturées et Cdes Ouvertes ?
En tout état de cause, ta réflexion me semble proche du domaine fonctionnel et transactionnel, plutot que du décisionnel : Quels sont les besoins en matière de reporting et analyse sur les commandes ouvertes ? Es-t'il vraiment nécessaire d'intégrer dans ton datawarehouse ces commandes ?

[ygrim]

Salut !
On en parle déjà ici : http://www.developpez.net/forums/sho...d.php?t=497730
Préviens nous si la solution ne te convient pas !

[IsHappy]

Ygrim, la discussion de Bassoum ne correspond pas à mon problème. Bassoum souhaite conserver toutes les étapes. Ce n'est pas mon souhait. Dans une journée, la commande peut évoluer, mais tant qu'elle n'est pas dans l'entrepôt, elle ne m'intéresse pas. Je ne souhaite pas historiser chaque journée non plus.
Jean-Paul_xx, concernant la question de savoir s'il est vraiment nécessaire d'intégrer dans le datawarehouse ces commandes ouvertes, c'est vraiment le coeur du problème. En terme de reporting, ça permet de savoir où se situe l'entreprise par rapport aux périodes précédentes en terme de "commandes ouvertes", ce qu'il y a dans le tuyau en fait. Egalement, ça mesure les performances "futures" des commerciaux, ce qui va tomber.
Le reporting sera forcément à deux niveaux, pour ne pas mélanger les commandes "ouvertes", les commandes soldées et les factures associées.
Les commandes ouvertes peuvent évoluer sur plusieurs années! Bon, c'est l'extrême, mais une commande peut évoluer tant qu'elle n'est pas facturée. Pour les deux autres questions, c'est un ratio normal de commandes/factures et toutes les possibilités de changement sont envisageable.

Si je comprends, vous n'intégrez dans l'entrepôt que les factures alors.

[Jester]

Tu peux estimer le nombre de commande ouvertes qu'il y a à gérer et le ratio de modifications?

Si c'est faible, il peut être intéressant de mettre les commandes ouvertes dans un ODS. Enfin c'est des détails de performance peut importants au niveau conceptuel.

Si on change les données de décembre, les utilisateurs relançant leurs états sur décembre ou faisant des comparatifs mensuels verront leur reporting de décembre modifié. Et ce n'est pas envisageable, à part vouloir faire du support téléhonique et de l'exploration de données toute la journée pour expliquer chaque centime d'écart.

Hum c'est un problème. mais en même temps si les chiffres changent les rapports doivent changer aussi.

Les utilisateurs ont-ils vraiment besoin de garder des rapports identiques quitte à ce qu'ils soient faux?

Ce qui me semble une solution médiane, c'est de mieux faire les rapport. I.e. au lieu de donner le chiffre d'affaire (par exemple), le décomposer en chiffre d'affaire déjà facturé + chiffre d'affaire estimation (non encore facturé). Dans ce cas, c'est seulement la deuxième partie qui peut changer et les utilisateurs pourront le comprendre.

Par contre garder les modifications des commandes peut se faire dans une autre table de faits où chaque modification serait conserver. Cette information est précieuse (peut-être). il est par exemple possible d'explorer plus précisement ces modifications via des dimensions temporelle et causales.

Selon ces données, il devient possible de corriger les estimations des nouvelles commandes. Par exemple dans la promotion immobilière on sais tôt les réservations, mais certaines ne vont pas aboutir. On aura donc tendance à surveiller le taux d'annulation de réservations. Si on sais que le taux d'annulation est de 20%, cela peut réduire les facturations d'autant et faire passer un résultat net prévisionnel du positif au négatif.

On peut aussi fouiller pour extraire des patterns sur quelles commandes sont plus susceptibles de voir leur facturation être réduites.

Bref, c'est de l'information, certes pas facile à exploiter, mais qui peut augmenter le ROI.

Par contre que les utilisateurs ne veulent pas voir leur rapports changer parce que la réalité a changé, ce n'est pas acceptable. Soit il faut leur fournir des rapports qui ne changeront pas (facturation définitive), soit faire de la pédagogie et les aider à accepter ce changement (en mettant en avant le terme estimation).

Bref, je divague un peu.

[IsHappy]

Le nombre de commandes ouvertes = 5000 et un ratio de 30% au minimum.

Jester, ton exemple de réservation immobilière est intéressant et devrait mieux te permettre de comprendre mon point de vue de penser qu'une réalité, même si elle a été modifiée par la suite, est tout de même juste au moment où on l'étudie et ce moment là doit être conservé pour comparaison:
- En septembre 2006, il y a 300 réservations prévisionnelles dans un hôtel pour les vacances de Noêl 2006. Suite aux désistements et réservations ultérieures, on aboutit début décembre 2006 à 220 réservations prévisionnelles pour Noêl 2006.(pas assez d'enneigement)
- En septembre 2007, il y a 350 réservations prévisionnelles pour les vacances de Noêl 2007. Il est intéressant de rapprocher ce chiffre non pas aux 220, mais aux 300
réservations prévisionnelles de la même période de l'année passée afin de prendre les meilleures décisions. Ce chiffre de 300 est tout de même la réalité de ce qui existait en septembre 2006, et est donc juste selon ce point de vu.
Je pense qu'en terme de reporting, d'analyse et d'aide à la décision, c'est super important.

Ceci étant dit, je ne vois pas, du coup, d'autre possibilité que de conserver ces données dans une autre table en historisant chaque journée ou chaque fin de mois. Mais en ne gardant que les données pertinentes. Pour mes analyses, je n'ai pas intérêt à conserver que telle famille a réservé tel jour puis s'est désisté tel autre jour et a re-réservé tel autre jour mais avec moins de jours. Par contre, historiser simplement les volumes (tel hôtel, tel jour, tant de résa prévisionnelles) me ferait du coup baisser la volumétrie du stockage, ce dont je craignais au départ.
Qu'en pensez-vous?

[Jester]

Comme je l'ai indiqué, je pense en effet qu'il va falloir plusieurs tables.

Dans une table tu peut mettre les modifications de commandes (dont la création), utilisant donc une dimension dégénéré n° commande.

Une table dérivée, qui stockera les commandes facturées.

Une autre toutes les variations des commandes ouvertes.

L'idée c'est de garder une table qui a une granularité assez fine pour alimenter toutes les autres.

[IsHappy]

La table de granularité, ce n'est pas possible via les tables de l'opérationnelle?

[ygrim]

Comme je l'ai indiqué, je pense en effet qu'il va falloir plusieurs tables.

Dans une table tu peut mettre les modifications de commandes (dont la création), utilisant donc une dimension dégénéré n° commande.

Une table dérivée, qui stockera les commandes facturées.

Une autre toutes les variations des commandes ouvertes.

L'idée c'est de garder une table qui a une granularité assez fine pour alimenter toutes les autres.

+1 pour Jester,
Une dimension dégénérée avec le numéro de commande te permettra de suivre l'évolution de celles ci. Peut être ajouter à cette dimension des informations sur les clients dans le cas ou un client annule une commande et la repasse, ça sera pas la même commande...

Il faudra cependant faire très attention aux rapports ne traitant pas cet aspect et intégrer la notion d'état de commande (facturée, en attente, etc.) à tous les rapports utilisant cette table de fait

IsHappy, je n'ai pas compris ta dernière phrase. Les tables opérationnelles ne servent qu'a alimenter l'entrepôt dans notre cas. Donc oui tu vas utiliser les tables opérationnelles pour alimenter les dimensions et les faits...

[IsHappy]

Désolé pour la dernière question, j'ai mal interprétée la phrase de Jesster. ça va mieux à tête reposée.
Merci de vos réponses qui m'ont beaucoup aidé dans ma réflexion, et fécilicitations pour ton blog Ygrim, que j'ai lu la semaine dernière avec intérêt.

Concernant le deuxième point, à savoir la détection des changements, donc plus au niveau des dimensions du coup, vous avez des idées?