Discussion :

[VITALTH]

Voilà,
Pour faire simple je souhaiterai monter un cube de vente.
L'idée est la suivante
La table de fait serait :

tFait
idFacture (N) Facture
idLigne (Ligne facture)
dateEcheance
dateReglement

Avec les dimensions Factures
dimFact
idFacture
titreFacture

et temps
temps
pkDate
mois
annee
...

Evidemment ma table de fait est en relation avec la dimension facture par idFacture/idFacture et avec le temps par dateEcheance/pkDate et dateReglement/pkDate.


Sauf que ça devient un peu touchy sur ce que je veux mesurer.
En fait il faudrait que l'utilisateur choisisse une date quelconque (disons pas exemple le 21/10/2015) et que le cube me donne le nombre de jour d'échéance par rapport à cette date.

Imaginons qu'on ait deux lignes de factures : une dont la date d'échéance est le 19/10/2015 : le nombre de jour d'échéance serait de 2 (21 - 19) et une autre dont la date d'échéance est le 25/10/2015 : le nombre de jour d'échéance serait de 0 car 25 est postérieur à 21.

Maintenant si l'utilisateur choisit le 26 /10/2015, le nombre de jour d"échéance serait de 7 de la première ligne alors que celui de la deuxième ligne serait de 1.

Avez vous une idée de la conception du truc?

[Elros]

Bonjour,

Est-ce que l'alimentation de ta table est quotidienne ? Si oui, tu peux créer un indicateur "Délai d'échéance" à la granularité ligne de facture qui est incrémenté de 1 à chaque alimentation.

Elros

[VITALTH]

Ouais... en fait non :il y a trop de lignes de facture.

[Elros]

Chez un client, on a mis en place ce genre de délai sur des tables à 50 millions de lignes et cela fonctionne plus tôt pas mal ! ;-)

Qu'elle est l'utilité de ce délai ? Si tu n'as pas d'intérêt à t'en servir pour toutes les lignes de facture, tu peux le calculer côté outil de restitution. Mais, si l'utilisateur analyse beaucoup de données cela demandera un certain temps.

[VITALTH]

On est d'accord que dans mon exemple y a pas tout, j'ai simplifié. L'idée est d'avoir un nbre de jour d'échéance pour un client donné et de pouvoir remonter dans le temps pour connaitre ce nbre jours d'échéance. Mais je conserver l'idée, elle me parait intéressante. Sachant que je suis aux alentours de 500 000 enrgts dans la table.

[GeekMokona]

On est d'accord que dans mon exemple y a pas tout, j'ai simplifié. L'idée est d'avoir un nbre de jour d'échéance pour un client donné et de pouvoir remonter dans le temps pour connaitre ce nbre jours d'échéance. Mais je conserver l'idée, elle me parait intéressante. Sachant que je suis aux alentours de 500 000 enrgts dans la table.

500 000 pour quelle période ? Par Jour ? Par Semaine ???

T'est 500 000 lignes sont des lignes de Facture , n'es ce pas ? ton échancre tu souhaite l'avoir par facture ou par ligne de facture ? cela est important dans ta modélisation car cela peux supposer un groupe de mesure a part à la facture et te permettre de réduire la volumétrie et donc pouvoir mettre en place le modélisation proposé par Elros

[VITALTH]

C'est bien sur la ligne de facture en fait. Car dans la modélisation la dateReglement peut changer pour chaque ligne d'une même facture ansi que la date d'échéance.
En fait la solution proposée par Elros j'y avais pensé mais je me voyais mal faire un cross join entre la table temps et la table de ligne de facture.