Plusieurs dates dans une table de faits [Résolu]

Julioun · 05/05/2011, 10h25

Bonjour à tous,

Ayant fait une recherche sur le forum, j'ai vu que l'on pouvait mettre plusieurs dates dans une même table de fait (date de création, date de livraison par exemple).

Mon soucis est que ma commande peut passer dans une vingtaine de statut différents et pas toujours dans chaque statut.

Est-ce que je dois inclure également mais 20 dates dans ma table de fait même si certaines dates ne seront jamais renseignée puisque la commande ne sera pas passée par ce statut ? Ou existe t-il une autre solution plus adéquat ?

Merci

Julien

doc malkovich · 05/05/2011, 11h30

Si tu as trop de dates ou de statuts tu peux garder une table d'historique avec un enregistrement par statut et par date, c'est plus simple.
Et aussi plus souple, si on rajoute un statut tu n'as pas à modifier la structure de la table.
Après tout se fait en restit.

Julioun · 05/05/2011, 11h39

Donc ce sera tout de même une table de fait "historique" donc ? Cette table historique est liée juste aux dimensions "Temps" et "Statut des commandes" ?

Cela ne pose pas de problème si il y a rien de quantifiable dedans juste une date un statut ?

Merci pour ta réponse.

Julien

doc malkovich · 05/05/2011, 12h01

Oui c'est ça.
Il faut la lier à ta table de fait principale où tu as tes mesures.
Evidemment il faut faire attention aux cardinalités en sql car tu peux multiplier facilement tes indicateurs.
Mais je l'ai déjà mis en oeuvre et je trouve que c'est la meilleure solution pour ce type de problème.

Benoit_Durand · 05/05/2011, 14h18

A ce moment là on peut parler de table d'événements.
Il n'y a pas de faits mais un historique des événements de ta commande par exemple.

doc malkovich · 05/05/2011, 14h59

C'est en effet ce qu'on appelle une table de suivi d'événements, une table de faits sans faits dans la littérature.
Maintenant on peut aussi imaginer de rajouter un indicateur comme le solde de la commande, la durée ouvrable depuis le début de la commande, etc ...

Julioun · 05/05/2011, 16h28

Très bien, merci beaucoup

Je vais étudier cette solution qui me semble plus propre que d'ajouter 25 dates dans ma table de fait.

Geo55 · 27/07/2011, 10h49

Bonjour,

Je me permet de relancer la discussion car mon problème, de ce que j'ai compris, est presque similaire à celui de Julioun.

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...

Dois-je relier chacune de ces dates en tant que clés étrangères dans ma table de fait à la clé primaire de la dimension Temps ? Ou bien dois-je récupérer ces dates directement depuis mes données sources et les mettre en champ date dans ma table de fait ?

De manière générale, comment utilise-t-on la dimension Temps ?

Merci pour vos suggestions

Jester · 27/07/2011, 11h27

En général je fais les deux.

Une clé vers la table date (à la granularité jour donc) et une copie de la date dans un autre champs (pour avoir la granularité seconde). Pour chaque date a stocker.

Geo55 · 27/07/2011, 11h46

Encore une fois merci Jester.

En cherchant je me suis aperçu que je suis exactement dans la même situation que Pupuce31 (sauf que je n'ai pas de dimension commande) dans ce sujet :
http://www.developpez.net/forums/d77...usieurs-dates/

Jester pour reprendre ce que tu dis je n'ai pas besoin de la granularité seconde. Mes dates sont au format JJ/MM/AAAA.

Si j'ai bien compris, si mes dates vont servir pour être analyser par la suite en tant qu'axe, alors je relie les clés à la dimension Temps. Si elles ne sont qu'informelles, alors je les laisse en tant que champ Date dans ma table de faits.

Je voulais rajouter que j'ai aussi le même problème avec des adresses. En effet chacune de mes commandes a deux adresses type d'adresse. Dois-je les renseigner en dur dans la table de faits ou bien mettre une clé étrangère lié à une table adresses ?

05/05/2011, 10h25	#1
Julioun Invité de passage Inscription : octobre 2006 Messages : 26 Détails du profil Informations forums : Inscription : octobre 2006 Messages : 26 Points : 3 Points : 3	Plusieurs dates dans une table de faits Bonjour à tous, Ayant fait une recherche sur le forum, j'ai vu que l'on pouvait mettre plusieurs dates dans une même table de fait (date de création, date de livraison par exemple). Mon soucis est que ma commande peut passer dans une vingtaine de statut différents et pas toujours dans chaque statut. Est-ce que je dois inclure également mais 20 dates dans ma table de fait même si certaines dates ne seront jamais renseignée puisque la commande ne sera pas passée par ce statut ? Ou existe t-il une autre solution plus adéquat ? Merci Julien
	00

05/05/2011, 11h30	#2
doc malkovich Modérateur Consultant en Business Intelligence Inscription : juillet 2008 Messages : 950 Détails du profil Informations personnelles : Sexe : Localisation : France, Nord (Nord Pas de Calais) Informations professionnelles : Activité : Consultant en Business Intelligence Informations forums : Inscription : juillet 2008 Messages : 950 Points : 1 467 Points : 1 467	Si tu as trop de dates ou de statuts tu peux garder une table d'historique avec un enregistrement par statut et par date, c'est plus simple. Et aussi plus souple, si on rajoute un statut tu n'as pas à modifier la structure de la table. Après tout se fait en restit. __________________ Avez-vous 60 secondes pour répondre aux sondages sur BO ici et là ?
	00

05/05/2011, 11h39	#3
Julioun Invité de passage Inscription : octobre 2006 Messages : 26 Détails du profil Informations forums : Inscription : octobre 2006 Messages : 26 Points : 3 Points : 3	Donc ce sera tout de même une table de fait "historique" donc ? Cette table historique est liée juste aux dimensions "Temps" et "Statut des commandes" ? Cela ne pose pas de problème si il y a rien de quantifiable dedans juste une date un statut ? Merci pour ta réponse. Julien
	00

05/05/2011, 12h01	#4
doc malkovich Modérateur Consultant en Business Intelligence Inscription : juillet 2008 Messages : 950 Détails du profil Informations personnelles : Sexe : Localisation : France, Nord (Nord Pas de Calais) Informations professionnelles : Activité : Consultant en Business Intelligence Informations forums : Inscription : juillet 2008 Messages : 950 Points : 1 467 Points : 1 467	Oui c'est ça. Il faut la lier à ta table de fait principale où tu as tes mesures. Evidemment il faut faire attention aux cardinalités en sql car tu peux multiplier facilement tes indicateurs. Mais je l'ai déjà mis en oeuvre et je trouve que c'est la meilleure solution pour ce type de problème. __________________ Avez-vous 60 secondes pour répondre aux sondages sur BO ici et là ?
	00

05/05/2011, 14h18	#5
Benoit_Durand Membre Expert Benoit Durand Consultant en Business Intelligence Freelance Inscription : mars 2005 Messages : 812 Détails du profil Informations personnelles : Nom : Benoit Durand Localisation : France, Gironde (Aquitaine) Informations professionnelles : Activité : Consultant en Business Intelligence Freelance Informations forums : Inscription : mars 2005 Messages : 812 Points : 1 084 Points : 1 084	A ce moment là on peut parler de table d'événements. Il n'y a pas de faits mais un historique des événements de ta commande par exemple. __________________ Pensez à la fonction Recherche
	00

05/05/2011, 14h59	#6
doc malkovich Modérateur Consultant en Business Intelligence Inscription : juillet 2008 Messages : 950 Détails du profil Informations personnelles : Sexe : Localisation : France, Nord (Nord Pas de Calais) Informations professionnelles : Activité : Consultant en Business Intelligence Informations forums : Inscription : juillet 2008 Messages : 950 Points : 1 467 Points : 1 467	C'est en effet ce qu'on appelle une table de suivi d'événements, une table de faits sans faits dans la littérature. Maintenant on peut aussi imaginer de rajouter un indicateur comme le solde de la commande, la durée ouvrable depuis le début de la commande, etc ... __________________ Avez-vous 60 secondes pour répondre aux sondages sur BO ici et là ?
	00

05/05/2011, 16h28	#7
Julioun Invité de passage Inscription : octobre 2006 Messages : 26 Détails du profil Informations forums : Inscription : octobre 2006 Messages : 26 Points : 3 Points : 3	Très bien, merci beaucoup Je vais étudier cette solution qui me semble plus propre que d'ajouter 25 dates dans ma table de fait.
	00

27/07/2011, 10h49	#8
Geo55 Nouveau Membre du Club Inscription : mai 2011 Messages : 89 Détails du profil Informations forums : Inscription : mai 2011 Messages : 89 Points : 36 Points : 36	Bonjour, Je me permet de relancer la discussion car mon problème, de ce que j'ai compris, est presque similaire à celui de Julioun. 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... Dois-je relier chacune de ces dates en tant que clés étrangères dans ma table de fait à la clé primaire de la dimension Temps ? Ou bien dois-je récupérer ces dates directement depuis mes données sources et les mettre en champ date dans ma table de fait ? De manière générale, comment utilise-t-on la dimension Temps ? Merci pour vos suggestions
	00

27/07/2011, 11h27	#9
Jester Membre chevronné Inscription : septembre 2003 Messages : 623 Détails du profil Informations forums : Inscription : septembre 2003 Messages : 623 Points : 632 Points : 632	En général je fais les deux. Une clé vers la table date (à la granularité jour donc) et une copie de la date dans un autre champs (pour avoir la granularité seconde). Pour chaque date a stocker.
	00

27/07/2011, 11h46	#10
Geo55 Nouveau Membre du Club Inscription : mai 2011 Messages : 89 Détails du profil Informations forums : Inscription : mai 2011 Messages : 89 Points : 36 Points : 36	Encore une fois merci Jester. En cherchant je me suis aperçu que je suis exactement dans la même situation que Pupuce31 (sauf que je n'ai pas de dimension commande) dans ce sujet : http://www.developpez.net/forums/d77...usieurs-dates/ Jester pour reprendre ce que tu dis je n'ai pas besoin de la granularité seconde. Mes dates sont au format JJ/MM/AAAA. Si j'ai bien compris, si mes dates vont servir pour être analyser par la suite en tant qu'axe, alors je relie les clés à la dimension Temps. Si elles ne sont qu'informelles, alors je les laisse en tant que champ Date dans ma table de faits. Je voulais rajouter que j'ai aussi le même problème avec des adresses. En effet chacune de mes commandes a deux adresses type d'adresse. Dois-je les renseigner en dur dans la table de faits ou bien mettre une clé étrangère lié à une table adresses ?
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email