Discussion :

[patriceharel]

Bonjour,

J’ai un petit doute sur la modélisation à apporter au SID dans le cas suivant. Dans ma dimension établissement, j’ai des champs qui n’évolueront pas (le code, le nom) et d’autres qui peuvent évoluer quelques fois par an mais cela n’est pas obligatoire (la capacité de l’établissement par exemple). Je voulais savoir quelle était la meilleure façon de procéder ?
- La gérer comme une dimension changeante ? (une date de début et de fin de validité)
- Externaliser les champs changeants dans une table de fait ?

Sachant que cette dimension établissement est une dimension conforme au sens de Kimball (c'est-à-dire utilisée dans plusieurs datamarts) et que certains de ces attributs changeants seront utilisés pour des calculs sur des faits.

[patriceharel]

On vient de me préciser que les données de la dimension changeront au moins une fois par an.

[doc malkovich]

Tu peux aussi historiser la table de dim au mois, comme tu le fais pour les faits.
Après tu rajoutes le mois dans la jointure.
( évidemment ça ne marche que pour des historiques mensuels )

Après il faut voir si les utilisateurs veulent historiser cette info ... Peut-être qu'ils ne veulent que la dernière vision ?

[patriceharel]

Quand tu dis historiser au mois, qu'est ce que tu entends par là? Ajouter une colonne date avec mois et année dedans?

On a obligation de conserver l'historique car les anciennes valeurs des champs serviront dans le cas ou l'on doit recalculer les faits qui en dépendent!!

[Jester]

Si ça peut être caché en mémoire, je ne vois pas problème à faire une SCD classique.

Potentiellement cette table de dimension pourra être utilisée comme table de faits pour certaines requêtes (évolution de la capacité des établissement par exemple).

[patriceharel]

Merci à vous pour vos contributions. Effectivement j'ai gérer ça avec une SCD et ça fonctionne bien. On respect les contraintes client et c'est finalement ça le plus important.
Par contre je m'interroge sur l'utilisation d'une dimension en tant que table de fait : c'est propre comme procédé? On dérive un peu de la définition de dimension non?

[doc malkovich]

[QUOTE=patriceharel;4084232]Quand tu dis historiser au mois, qu'est ce que tu entends par là? Ajouter une colonne date avec mois et année dedans?/QUOTE]

oui, nous par exemple on a ajouté une colonne CHAR(6) qui est année*100 + mois
ensuite les tables sont partitionnées là-dessus, ça permet d'avoir une très bonne réactivité au niveau requête, contrairement aux SCD classiques

[Jester]

> Par contre je m'interroge sur l'utilisation d'une dimension en tant que table de fait : c'est propre comme procédé? On dérive un peu de la définition de dimension non?

Je ne sais pas si c'est propre, mais je ne vois pas de problèmes. Normalement, il n'y a pas de dimensions associées (sauf cas des snowflake).

> ensuite les tables sont partitionnées là-dessus, ça permet d'avoir une très bonne réactivité au niveau requête, contrairement aux SCD classiques

Simple question que je me pose. Une dimension n'est pas sensée tenir en mémoire et donc avoir un index de type hash? Dans ce cas, un partitionnement n'a aucun impact non?

[doc malkovich]

>Simple question que je me pose. Une dimension n'est pas sensée tenir en mémoire et donc avoir un index de type hash? Dans ce cas, un partitionnement n'a aucun impact non?

si tu stockes toutes les photos mensuelles de ta dimension dans une seule table elle risque d'avoir une volumétrie importante, et ne vaut plus le coup d'être chargée en mémoire