Discussion :

[Pupuce31]

Bonjour à tous,
Après avoir cherché sur le forum, je me permets de me tourner vers vous.
Je suis en pleine conception et j'ai un souci avec la modélisation du temps...

Dans mon magasin de données, je dois modéliser des commandes, plus précisément des lignes de commandes.
Je m'explique:

J'ai des dimensions telles que les articles, les fournisseurs, la commande...
J'ai une table de faits "lignes de commandes" qui comprend le montant de la ligne de commande, les quantités..., toutes les clés de dimension mais j'ai des dates qui m'embêtent!!
En effet, la ligne de commande a plusieurs dates (Date Commande, Date validation, Date Livraison...)

Et maintenant je n'arrive pas à choisir:

-> Soit je mets ces dates en clés primaires de ma table de fait en faisant plusieurs liens vers une dimension temps, sachant que toutes ces dates sont quand même liées à la commande
->Soit je mets ces dates dans la dimension 'Commande'

Y a-t-il une méthode meilleure que l'autre?Le pour , le contre??
Voilà, je vous remercie d'avance pour vos réponses

Pupuce31

[Antoun]

Si c'est un DW au niveau détaillé et que tu as déjà une table des commandes, je ne vois pas d'inconvénient à y mettre les dates.

[Pupuce31]

Merci pour ta réponse!!
Mais du coup dans mon magasin de données je n'aurais plus de dimension Temps si je mets toutes les dates dans la Commande?

Ca ne pose pas de problème?

[Benoit_Durand]

pourquoi ne pas mettre les clés vers la dimension Temps ?

[Pupuce31]

Du coup je laisse les dates en clés de la table de fait dans mon DW, ensuite dans le DM je fais pointer ces clés vers une dimension temps?

[Reskibil]

Je vais peut être dire une betise mais personnellement, je prendrai en compte le système qui sera utilisé pour créer le DW. Je m'explique, certains outils permettent de créer les cubes à partir de modèle en étoile, auquel cas avoir les clé permet de pointer sur la dimension temps ce qui est bien utile.
A contrario, d'autres systèmes permettent de créer le cube à partir d'une table unique dénormalisée auquel cas, la modélisation dans les règles de l'art avec les clés et tout se fait dans le DW pour au final se retrouver avec une table unique contenant toutes les valeurs dans le datamart. Dans ce cas, les clés ne sont pas plus utiles que ça.

Un autre point que je prendrais en considération, c'est l'usage que tu vas faire de ces dates. Si elles ne sont destinés qu'à être affichées pour information, les clés sont parfaitement inutiles. En revanche, si tu va utiliser ces dates pour agréger tes données avec des fonctions temps (YTD et consort), alors le lien vers la dimension temps est important (dans le 1er cas cité au dessus) et peut être multiple.
Perso, je conçois la modélisation en bottom-up, je pars du résultat souhaité, souhaitable ou éventuellement souhaité, et en fonction, je modélise le DTM et le DWH en fonction.

Voila, j'espère que je suis compréhensible (je relirai une fois les yeux ouverts )

[Antoun]

Je vais peut être dire une betise mais personnellement, je prendrai en compte le système qui sera utilisé pour créer le DW.

+1 ! on ne sait même pas s'il va y avoir un cube, du ROLAP, une couche sémantique relationnelle, du reporting statique, etc.

[TheLeadingEdge]

Sans plus de précisions, je dirais que mettre les clefs de la dimension temps dans la table de faits est la meilleure solution.
Si tu les mets dans ta dimension commandes tu n'auras plus une dimension temps, mais des caratéristiques navigables de ta dimension commande.
Ce n'est plus pareil. Si tu veux agréger tes qtés cdées par produits par ex. tu devras passer par la dimension cde.
Et aussi pourquoi est-ce génant pour toi d'avoir plusieurs dates dans ta table de faits ? Ce sont des info différentes.
La valeur du carnet de cdes est différent du volume des expéditions.

[EDIT]

c'est l'usage que tu vas faire de ces dates. Si elles ne sont destinés qu'à être affichées pour information, les clés sont parfaitement inutiles. En revanche, si tu va utiliser ces dates pour agréger tes données avec des fonctions temps (YTD et consort), alors le lien vers la dimension temps est important (dans le 1er cas cité au dessus) et peut être multiple.

Je n'avais pas lu ce passage. C'est exactement ça. Si tu veux faire des aggrégats les dates font partie de la surrogate key de la table de faits. Si c'est juste de l'info à afficher, ce sont simplement des caractéristiques de la dimension commande. (mais pas des clefs de la dimension temps dans commande) [/EDIT]

[Pupuce31]

Bonjour,
Merci beaucoup pour vos réponses et surtout désolée pour ma réponse tardive (pont oblige!!)
Pour préciser un peu, le but est de faire du Rolap avec de la restitution sur BO.
D'après vos réponses, je vais garder les clés dans la table de fait car le but est d'agréger ces différentes dates.

Merci encore pour votre aide!!

[Geo55]

Bonjour à tous,

Je suis dans le même cas que Pupuce.

Pour relancer le débat, j'ai un datamart des ventes qui recense les commandes en cours de facturation et celles qui sont facturées. Le but est d'établir des rapports sur les commandes en carnet, les commandes facturées et l'ensemble des deux sur 2 mois glissants, appelé prise de commandes.

J'ai donc une table de fait contenant des lignes de commandes. A chaque ligne de commande est associée plusieurs dates que les analystes ont besoin d'avoir dans leur rapport telle que la date de livraison souhaitée, la date de livraison planifiée, la date d'expédition planifiée, la date de livraison promise, etc...

Comment être sûre de la meilleur façon de faire entre laisser les dates dans la table de fait en tant que champs Date ou bien les relier en tant que clés étrangères à la dimension Temps ?

J'ai aussi le même problème avec les adresses. Chacune de mes commandes a deux types d'adresses. Dois-je relier les adresses à la dimension Adresses ou les laisser en dur dans ma table de faits ?

D'avance merci pour vos éventuelles réponses

[Prjprj]

Il est d'usage de faire que la clé de la dimension TEMPS soit construite de la sorte :
YYYYMMDD (en entier, cela fait Année * 10000 + Mois *100 + Jour).

De la sorte, on a une clé qui a du sens, et qui, d'un point de vu des tris, conserve la notion d'ordre dans les dates.

Enfin un entier est plus simple à indexer qu'une Date.

[Geo55]

Désolé mais je ne comprends pas bien ton raisonnement. Peux-tu m'expliquer un peu plus ?

Merci

[Prjprj]

C'est simple, dans ta dimension temps, tu crées une clé numérique unique afin de faciliter tes jointures. Au lieu de faire une séquence de type (1, 2, 3, 4, ...) pour cette clé, tu peux construire un nombre de la forme 20110830 qui permettra d'identifier de manière unique un jour et qui sera supérieur à 20110829 ou à 20110730 ou encore à 20100830.

Ce type de clé possède l'avantage de porter du sens pour les personnes qui manipulent ces données (puisque c'est en fait la date écrite d'une certaine manière), de maintenir la notion d'ordre entre des dates (une date inférieure sera toujours inférieure avec cette clé) et d'être plus simple à manipuler qu'un champ DATE.

En clair, ta date apparait dans ta table de fait via cette clé et est facilement manipulable, mais ton champ Date n'apparait que dans la table de dimension TEMPS

[Geo55]

Yes merci beaucoup !

Ah y'a pas à dire c'est très clair !

Donc si j'ai bien compris, avec ma dimensions Temps j'aurai des enregistrements qui ressembleront au tableau en pièce jointe ?


Merci en tout cas pour ton explication ça me retire une épine du pied

Bonne journée.

[Prjprj]

Yes merci beaucoup !

Ah y'a pas à dire c'est très clair !

Donc si j'ai bien compris, avec ma dimensions Temps j'aurai des enregistrements qui ressembleront au tableau en pièce jointe ?


Merci en tout cas pour ton explication ça me retire une épine du pied

Bonne journée.

Exactement.

Attention aux fonctions Week pour la manipulation des dates, certains outils ou bases ne gèrent pas la semaine ISO (Je te laisse chercher sur wikipedia)

[Geo55]

Ok. J'aurai besoin de récupérer des semaines car mes utilisateurs utilisent à la fois les dates complète (jour/mois/année) mais ils travaillent également à la semaine.

Merci de l'info je vais essayer de me renseigner là-dessus. Je suis pas du tout spécialiste en BDD

J'ai aussi le même problème avec les adresses. Chacune de mes commandes a deux types d'adresses. Dois-je relier les adresses à la dimension Adresses ou les laisser en dur dans ma table de faits ?

Et as-tu toutefois une idée pour gérer les adresses multiples dans une table de faits ?

[Prjprj]

Et as-tu toutefois une idée pour gérer les adresses multiples dans une table de faits ?

Un fait peut avoir entre 0 et N adresses ou une personne a X adresses (choisir une valeur fixe) qui sont ou non renseignées?

Je m'explique mieux :

• Soit ton fait peut avoir autant d'adresse qu'il veut, dans ce cas là, tu ne peux pas stocker cette adresse dans ta table de fait pour la bonne et simple raison que tu ne sais pas de combien de champs tu peux avoir besoin.
• Soit ton fait a 2 ou 3 adresses correspondant par exemple à une adresse d'envoi d'un colis et une adresse de facturation, dans ce cas là, tu peux prévoir les champs pour stocker tes adresses.

Un second problème arrive par dessus, est-ce qu'une adresse peut appartenir à plusieurs faits?
Dans ce cas là, tu dois stocker cette adresse dans une table de dimension, afin que les X faits qui ont cette adresse pointent dessus.

Donc en gros, les cas sont les suivants :

• Ton fait peut avoir quelques adresses dont le nombre est fixe, et qui ne peuvent pas être partagées avec d'autres personnes, dans ce cas là, tu stocke l'adresse dans ta table de faits
• Ton fait peut avoir quelques adresses dont le nombre est fixe, ces adresses peuvent être partagées, dans ce cas là, tu stockes les adresses dans une table de dimension et les clés dans les différents champs correspondant à tes différentes adresses
• Ton fait peut avoir n'importe quel nombre d'adresses, dans ce cas là, les adresses doivent être stockées dans une table de dimension, que tu lies à la table de faits via une table de lien (une table qui contient l'identifiant de ton fait et l'identifiant de ton adresse, un type de lien éventuellement).

Ensuite, dans le cas d'une table de dimension d'adresses, dans ton outil de reporting, tu crées autant d'alias de ta table des adresses que tu en as besoin pour les lier à ta table de faits et tu crées les objets qui vont bien par rapport à chaque type d'adresse.

[Geo55]

Merci beaucoup pour le temps précieux que tu me consacres, c'est super

Je suis dans le cas où mon fait a deux adresses correspondant à l'adresse de livraison et l'adresse de destination finale (là où le produit sera utilisé réellement, car l'adresse de livraison est un port parfois...).

Ensuite, dire si ces adresses appartiennent à plusieurs faits, ce n'est pas évident. Mes faits sont mes lignes de commandes et mes lignes de factures. Sachant qu'une ligne de commande peut avoir 0 ou plusieurs lignes de facture. Il faut que je vois plus clairement si les adresses se rattachent à la ligne de commande ou à la ligne de facture, ou les 2.

Je ne connais encore pas bien l'ERP de l'entreprise, ça fait que 4 mois que j'y suis.

Que veux-tu dire quand tu dis que mes adresses sont partagées ou non par plusieurs personnes ? C'est juste pour pouvoir retrouver ces adresses dans les statistiques...

[Prjprj]

Que veux-tu dire quand tu dis que mes adresses sont partagées ou non par plusieurs personnes ? C'est juste pour pouvoir retrouver ces adresses dans les statistiques...

Erreur de terme, je voulais parler de plusieurs faits partageant les mêmes adresses.

Je pense qu'il serait mieux de créer une table d'adresses, cela permet de gagner en perfs sur les états basés sur les adresses (l'outil de restits ne sera pas obligé de balayer toute la table de faits pour faire un distinct des adresses mais ira lister les libellés d'une table toute propre).

En gros, il y a plusieurs visions, soit on se dit qu'on analyse le fait par son adresse et donc on stocke cette adresse dans une table, on peut en profiter pour la retravailler pour produire quelques informations supplémentaires (par exemple, regroupements par régions administratives ou Business ou Business Division), soit on se dit que l'adresse est une information sur le fait mais pas un axe d'analyse à part entière, dans ce cas là, on peut la laisser dans la table de faits bien que cela représente souvent un poids mémoire supplémentaire (duplication probable des données si une adresse est répétée, stockage d'infos textuelles dans une table de faits, difficulté d'indexation).

En BI, on est assez libres de faire la modélisation que l'on veut et on peut bidouiller les clés que l'on veut, mais on en revient souvent aux fondamentaux, plus logiques et performants.

[Geo55]

Je vois bien ce que tu veux dire par rapport à la surcharge mémoire engendré par le stockage des adresses dans la table de fait.

Je vais te faire confiance et laisser ma table d'adresses, même si je suis quasi sûre que les adresses de livraisons ne seront pas des axes d'analyse...

Et quand tu dis qu'on est libre en BI, j'essaie quand même de respecter un peu près les règles de modélisation en étoile mais c'est pas évident...

Par exemple j'ai 2 tables de faits qui sont reliées entre elles dans mon schéma : les lignes de commandes et les lignes de factures. Car dans l'ERP, une ligne de commande peut avoir 0 ou plusieurs lignes de factures.

Pour t'expliquer un peu où je veux en venir : ma direction souhaite réaliser des statistiques sur le carnet de commande mais aussi sur la facturation.

Encore merci pour ta contribuation et tes lumières !