Discussion :

[raph-68i]

Hello, Bonjour à tous.

Pour un nouveau projet, je dois créer une table de fait.

Ayant déjà tous les besoins des utilisateurs, je me demande comment créer cette table et organiser les colonnes afin de me donner les meilleures performance et aussi éviter les sous requêtes.

En temps normal mes tables sont organiser en général de la manière suivante (star schema avec mes dimensions) :

Fact table :

• GEO_ID (FK avec dimension)
• MONTH_ID (FK avec dimension)
• YEAR_ID (FK avec dimension)
• TIMESERIES_ID (FK avec dimension)
• SCENARIO_ID (FK avec dimension)
• VALUE

Cependant, lorsque je souhaite faire des comparaisons entre le mois actuel et le mois précédent, il me faut au minimum une sous requête.

J'ai déjà organiser une table de fait de la manière suivante lors d'un précédent projet:

• GEO_ID
• YEAR_ID
• TIMESERIES_ID
• VAL_MONTH_01
• VAL_MONTH_02
• VAL_MONTH_03
• ...
• VAL_MONTH_12

De manière générale les besoins sont :

- afficher le mois courant
- afficher le mois précédent
- afficher le budget pour le mois courant
- afficher la variance entre mois courant et budget
- ...


Si quelqu'un dans l'assemblée à une idée pour organiser ma table de fait de la meilleure façon afin de débuter mon projet sur de bonnes bases je suis preneur.

Juste pour être sur je ne demande pas d'aide pour faire les "select" ou le "create".. je ne souhaite que discuter du design de la table.

Par avance, merci pour votre aide.

Cordialement,

Raph.

[al1_24]

La première structure est bien sur préférable. Dans le second cas il est nécessaire de modifier les colonnes sélectionnées en fonction du mois consulté alors que dans le premier il ne s'agit que d'un critère de restriction.

[raph-68i]

Merci pour la réponse.

Je pensais qu'il existait un design de Fact Table permettant de simplifier la comparaison entre deux mois (ou plus).

Car, avec cette méthode "classique", je dois avoir une ou plusieurs sous requête si je veux afficher en une seule requête:

la valeur du mois courant | la valeur du mois précédent | la différence

Je laisse le post ouvert encore un peu si quelqu'un a une autre idée.

Merci d'avance.

[Waldar]

Car, avec cette méthode "classique", je dois avoir une ou plusieurs sous requête si je veux afficher en une seule requête:
la valeur du mois courant | la valeur du mois précédent | la différence

Non, une requête suffit.

Regardez les fonctions LEAD / LAG, ainsi que PIVOT.

[mnitu]

Je ne suis pas vraiment spécialiste dans le domaine mais à ce que j'ai (peut-être mal) compris dans un modèle pour un DW l n'est pas de tout choquant d'organiser le données en dé-normalisant les 12 mois de l'année. Donc je suis preneur plutôt de la deuxième solution.

[raph-68i]

Merci a tous pour vos réponses.

Pour ce projet j'ai utilisé la méthode de base :

Fact table :
GEO_ID (FK avec dimension)
MONTH_ID (FK avec dimension)
YEAR_ID (FK avec dimension)
TIMESERIES_ID (FK avec dimension)
SCENARIO_ID (FK avec dimension)
VALUE

Je vais continuer a me renseigner mais a priori pas de méthode miracle dans les livres de Ralph Kimball.

Bonne journée.

[Waldar]

Je ne suis pas vraiment spécialiste dans le domaine mais à ce que j'ai (peut-être mal) compris dans un modèle pour un DW l n'est pas de tout choquant d'organiser le données en dé-normalisant les 12 mois de l'année. Donc je suis preneur plutôt de la deuxième solution.

Aucun soucis quant à la dénormalisation en DWH, néanmoins la solution "colonne" impose la problématique de mise à jour de la donnée, sachant que les updates c'est toujours un peu lent.

C'est le critère de performance qui est déterminant : si le PIVOT est assez rapide (moins de 60 sec pour afficher le reporting), pas besoin de dénormaliser.