Discussion :

[mederik]

Re bonjour,

bon j'ai honte de poser la question mais j'y vais : je dois créer une dimension temps mais qu'est ce que je mets comme clé dans la table de fait en reference a cette dimension temps ?

Une clé technique générée par l'ETL ? Mais aussi, sur quelle date de quelle dim je vais contraindre ma table de fait avec ma dim temps ? En fait ce que je comprends pas c'est comment on raccroche un fait à une dimension temps. Pour ca il faut prendre une date de référence non ? Mais cette date de reference, ou est-ce qu'on la prend. Si c'est ca l'idee...

Et puis quelle différence entre une la constitution et l'utilisation d'une dimension temps et l'utilisation des SCD où on fait des requette avec des contrainte de cette ordre DIM_HISTO.ID = FAIT_ID et DIM_HISTO.DATE_DEB_VALIDITE <= FAIT.DATE_REF et DIM_HISTO.DATE_FIN_VALIDITE > FAIT.DATE_REF

Je suis en train de tout mélanger et je ne comprends plus rien...Please help...

Merci de votre aide par avance

[Jester]

Pour info, ma modélisation de la table Date contient :
id dayOfMonth dayOfWeek dayOfYear month quarter weekOfYear year
avec un exemple :
127795457 1 1 1 1 1 52 1950

Mon champs id est en fait calculable à partir de (dayOfMonth, month, year), je sais que c'est mal (normalement la clé d'une dimension ne doit avoir aucune sémantique), mais ça me semble une optimisation tout à fait pertinente par exemple pour définir un ordre sur les dates facilement.

Donc du coup dans mes tables de fait, il y a une colonne dateId qui correspond à Date.id. La correspondance entre les dates et la clé correspondante, se fait à l'insertion des informations dans la base. Grâce à mon optimisation, je peux retrouver la clé à utiliser pour une date donnés, mais il suffit aussi de faire un select sur la table Date pour trouver la clé à utiliser.

Tu as des requêtes par ex :
select * from Fact join Date on Fact.dateId = Date.id where Date.year < 1999

pour retourner les fait d'avant 1999.

[mederik]

La correspondance entre les dates et la clé correspondante, se fait à l'insertion des informations dans la base. Grâce à mon optimisation, je peux retrouver la clé à utiliser pour une date donnés

Ben voila c'est ca que je ne comprends pas. Pour faire la correspondance entre l'ID_date de ma DIM DATE et ma table de fait, il faut bien prendre une date quelconque. Est-ce a dire que ce choix de date que j'appelerai "référentielle" est "libre".

On peut si l'on veut prendre la date d'insertion dans le DWH de la ligne de la table de fait. Ou prendre, dans le cas d'une notion plus concrète et fonctionnelle, la date de signature d'un contrat ?

Exemple : on a une table de fait au niveau du contrat rattachée entre autre à une DIM CONTRAT. Dans la table de fait on a un indicateur : "marge". Comme date de référence, on peut prendre si cela a un sens la date de signature du contrat. Il n'y a donc plus qu'a aller chercher pour une valorisation donnée de "marge" le contrat qui lui est associé, voir sa date de signature et en fonction de cette date, associer à "marge" dans la table de fait l'ID_date de ma DIM DATE qui lui correspond.
C'est ca le principe ?

[DevNico]

Question intéressante...

En ce qui concerne ta dernière question et la gestion des SCD, ce type de requête se fait par exemple lors de l'alimentation de ta table de fait, lorsque tu cherches à identifier quelle ligne de ton référentiel est à liée à ta table de fait.

Par exemple avec un référentiel comme ceci :
(Le code C1 a changé de libellé le 1er janvier 2006)
Id Code Libellé Date de début Date de fin
1 C1 Ref1 01/01/2000 31/12/2005
2 C1 Ref1bis 01/01/2006 31/12/9999

Si tu reçois un fait sur 2004, tu utilises l'id 1. Si le fait est sur 2007, c'est l'id 2 qui est utilisé.
(Dans mon exemple, la requête se fait sur le code, et non sur l'id comme dans ta requête).


De mon coté, nous n'avons pas de table de dimension temps.
Les dates sont stockées telles qu'elles dans les tables de fait. (On a juste une table des mois, pour récupérer les libellés dans les différentes langues).

J'imagine qu'on n'a jamais vu d'intérêt à en utiliser, mais je ne m'avancerai pas sur le fait qu'on a pris la bonne solution...
(En fait, toutes les données contenues dans la table de Jester sont calculables à partir de la date).

Quelqu'un saurait m'indiquer l'avantage à gérer l'alimentation d'une table de dimension temps ?

Nicolas

[brunolf]

Il y a plein de choses que l'on peut rajouter dans une dimension temps, et qui n'est pas forcément calculable à partir du champ date.

- Période comptable
- Jours fériés / ouvrés / ouvrables
- Vacances scolaires / Période de fermeture de l'entreprise.
- ... et tout les cas spécifiques que l'on peux rencontrer en fonction du besoin...

[mederik]

Argh
bon alors je vais essayé de faire simple (ce qui n'est pas gagné).
Je confonds plusieurs concepts ; je les mélange sans comprendre les interactions entre ces concepts (les utilise-t-on tous ensemble, l'utilisation de l'un exclu-t-il l'autre) et leur utilité.

Ces concepts sont :

1 : les SCD
2 : l'historisation
3 : la dimension temps
4 : a quoi servent alors et dans quel cadre on utilise des jointures de types DIM_HISTO.ID = FAIT_ID et DIM_HISTO.DATE_DEB_VALIDITE <= FAIT.DATE_REF et DIM_HISTO.DATE_FIN_VALIDITE > FAIT.DATE_REF

Pour résumer : quelqu'un peut il m'expliquer les relations entre ces trois concepts, qui pris individuellement, j'arrive à comprendre plus ou moins (d'ailleurs plutot moins que plus) mais je n'arrive pas à saisir dans quel contexte les utiliser.

[Benoit_Durand]

Exemple : on a une table de fait au niveau du contrat rattachée entre autre à une DIM CONTRAT. Dans la table de fait on a un indicateur : "marge". Comme date de référence, on peut prendre si cela a un sens la date de signature du contrat. Il n'y a donc plus qu'a aller chercher pour une valorisation donnée de "marge" le contrat qui lui est associé, voir sa date de signature et en fonction de cette date, associer à "marge" dans la table de fait l'ID_date de ma DIM DATE qui lui correspond.
C'est ca le principe ?

Pour moi c'est en effet le principe, date de signature, date de création d'une commande , date de validation, date de l'écriture de la ligne dans la bd ...
la date qui fonctionnellement correspond le plus au fait.

par exemple sur un commande on peut avoir une date de création de la commande et la date de paiement et la date de livraison.
dans la table de fait du CA tu prendras la date de paiment et pour la table de fait du suivi réception la date de réception.

[mederik]

Ah...je te bénis Hebus merci.
Si tu permets, je voudrais prolonger la question : en reprenant alors l'exemple de la date de signature du contrat comme date de référence, que se passe-t-il si dans la table FAIT_CONTRAT, pour certains indicateurs, cela n'a pas de sens de prendre la date de signature du contrat.....

Exemple : pour un indicateur acompte, cela à un sens de lui rattacher la date de signature du contrat. Mais pour un inidcateur "valeur résiduelle" qui est calculé lorsque le contrat arrive à echéance, donc a la fin de vie du contrat. Commlent fait on ?

Ce que je veux dire c'est : est-ce qu'il est possible pour des indicateurs au meme niveau de prendre des dates différentes pour leur coller lID date qui lui va bien dans la table de fait ?!?

[Benoit_Durand]

Il nous arrive d'avoir plusieurs DateId dans une meme table de faits. DateCreationId, DateValidationId après pour l'analyse suivant l'indicateur il faudra faire la jointure qui va bien.

[mederik]

Ah je pensais que pour autant de date de référence différentes il fallait une table de fait différente. Mais oui, il suffit d'avoir plusieurs date_id différents. Je suppose que le choix de la bonne jointure se gère très bien dans les outils de restit genre BO non ?

[DevNico]

Il y a plein de choses que l'on peut rajouter dans une dimension temps, et qui n'est pas forcément calculable à partir du champ date.

- Période comptable
- Jours fériés / ouvrés / ouvrables
- Vacances scolaires / Période de fermeture de l'entreprise.
- ... et tout les cas spécifiques que l'on peux rencontrer en fonction du besoin...

Ok, je vois.
Et donc si aucun de ces concepts n'est nécessaire dans le projet, la dimension temps n'est pas indispensable ?

[DevNico]

1 : les SCD
2 : l'historisation
3 : la dimension temps
4 : a quoi servent alors et dans quel cadre on utilise des jointures de types DIM_HISTO.ID = FAIT_ID et DIM_HISTO.DATE_DEB_VALIDITE <= FAIT.DATE_REF et DIM_HISTO.DATE_FIN_VALIDITE > FAIT.DATE_REF

Pour résumer : quelqu'un peut il m'expliquer les relations entre ces trois concepts, qui pris individuellement, j'arrive à comprendre plus ou moins (d'ailleurs plutot moins que plus) mais je n'arrive pas à saisir dans quel contexte les utiliser.

Je dirais que les points 1, 2 et 4 sont intimement liés. Le points 3 étant à part.
Tu utilises le concept de SCD pour gérer l'historisation des référentiels par exemple.
Et comme je l'ai dit dans un post au dessus, tu utilises le point 4 pour faire le lien entre les données de fait et les données de référence.
(Pour récupérer l'id de la ligne active à la date du fait dans la table de référence)

Nicolas

[DevNico]

Ah je pensais que pour autant de date de référence différentes il fallait une table de fait différente. Mais oui, il suffit d'avoir plusieurs date_id différents. Je suppose que le choix de la bonne jointure se gère très bien dans les outils de restit genre BO non ?

Je confirme. Avec BO par exemple, tu utilises une seule table de fait sur laquelle tu gères plusieurs alias (un alias par jointure).
Dans le modèle de ton univers, tu vois donc autant d'alias que de dates de référence différentes.

[mederik]

Ok merci a tous pour nvos réponses !!

[Jester]

Ok, je vois.
Et donc si aucun de ces concepts n'est nécessaire dans le projet, la dimension temps n'est pas indispensable ?

Avoir une dimension temps permet aussi d'affecter une Date pour chaque mois (sans un jour précis) et une Date "Non valide" voire "Un jour".

Pour ma part, j'ai utiliser un dimension date (et un entier pour la clé au lieu d'un type Date) aussi pour la raison qu'avec hibernate, une colonne DATE est traduite en instance de java.sql.Date ce qui dans mon cas posait des problèmes (taille/performance). Avoir une clé "intelligente", permet de conserver les avantages des deux mondes.

Des textes de Kimball dessus :

http://www.kimballgroup.com/html/des...rogateKeys.pdf

http://www.kimballgroup.com/html/des...stThinking.pdf

http://www.kimballgroup.com/html/des...rogateKeys.pdf

[DevNico]

Merci pour ces infos Jester.
Je vais étudier tout ça.