Discussion :

[Jinroh77]

Bonjour,
J'ai un cube avec des faits et des dimensions.
Sur une de ces dimensions, on peut me demande d'historiser nu certain nombre d'attributs.
le principe étant que l'utilisateur voit la valeur de l'attribut valable au jour où il consulte les données.

Pour le moment j'ai conserver ma table de dimension classique, puis j'ai rajouté une dimension ne contenant que les attributs historisés et enfin je crée une factless table permettant de faire une jointure, à date, entre ma dimension normale et l'historisation des attributs de celle-ci.

Avec cela je crée une relation Many-to-Many et le tout fonctionne à peu près...

Problème... J'ai besoin que la date de validité de mes attributs historisés soit automatiquement celle de mon fait que je filtre... Comment réaliser cela ?


Autre chose, au début, j'étais passé par une dimension SCD (sans le M2M bien sûr) ce qui me permettait de filtrer cela automatiquement.. Manque de chance, les valeurs d'attributs changent tous les jours et le SCD a alors peu d'intérêts.

Merci pour vos idées, conseils...

[asaintraymond]

Je vais peut-être dire une connerie, mais si les attributs changent tous les jours comme tu le dis, j'aurais tendance à penser qu'il vaudrait mieux les stocker dans ta table de faits.
Tu peux ensuite créer une dimension directement à partir de ta table de faits en utilisant une relation de type "Fact".

[Jinroh77]

C'est aussi une idée, sauf qu'il peut y avoir beaucoup d'attributs changeant et en ajouter 1 dans la table de faits et vite plus compliqué que dans une table de dimension.
Maintenant si ce problème ne trouve pas d'autres solution, j'irai vers cela.

Le problème, avec l'idée présentée est aussi d'avoir 2 dimensions pour représenter les attributs "statiques" et les attributs changeant ; Ce qui est plutôt gênant, aussi, pour les utilisateurs.

[asaintraymond]

Quelle genre de valeurs stockes-tu dans tes attributs changeants ?

[Jinroh77]

Il y a des champs de types texte, des chiffres etc..
En gros, c'est une liste de produits, dont les caractéristiques évoluent au cours du temps.

[Jinroh77]

Une dimension dont les attributs la définissent comme alimentée en SCD, ne réagit-elle pas comme je le souhaite ?

[Jinroh77]

Bizarrement, lorsque je reprends mon projet de base (sans le M2M), je rajoute une date de début, date de fin, un flag dans ma table de dimension et que je spécifie tout cela dans les propriétés de ma dimension de mon cube, sans changer le type de liaison avec mon fait, mon attribut historisé change automatiquement lorsque l'utilisateur choisi une AsOfDate.
J'ai donc exactement le processus que je souhaite, sans créer une nouvelle table, sans faire du many2many, mais simplement en spécifiant des propriétés dans ma table...
Comment faire la même chose mais sans avoir de flag ni de date de début et de fin, mais simplement 1 date de validité ??
Et si possible, en reportant les données à historiser dans une autre table, mais ça, ça ne devrait pas poser trop de problème via une vue.

[Jinroh77]

Hummm à la réflexion, lorsque je génère une nouvelle ligne avec des attributs différents, je génère également un nouvel Id de ma dimension qui est utilisé pour la liaison avec ma table de faits...
J'ai donc loupé quelque chose au niveau du SCD ??

[asaintraymond]

Ben c'est comme ça que fonctionne le SCD type 2, quand tu modifies un attribut ça ajoute un enregistrement dans ta dimension avec une nouvelle clé.

Ca fonctionne pour ce que tu veux faire, mais ta table dimension aura quasiment autant d'enregistrement que ta table de faits si les valeurs changent beaucoup.

[dream_rachid]

Je joins l'avis de Jinroh77 je pense pas que c'est une bonne idée d'avoir deux tables de dimensions (1 historisé et l'autre dernière situation)

je préconise que tu limite à une seule table en ajoutant un Id avec date début et date fin et dans ton cube y a pas de prob sois que tu utilises toute la table de dimension avec l'ajout d'un axe date modif ou bien faire une vue en sélectionnant que les dernière date de modification

[Jinroh77]

Si on reprends les solutions possibles, en imaginant que certains attributs changent tous les jours.

Utiliser le concept du SCD
Ma table de dimension complète prend 50 000 lignes par jour.
Chaque jour je crée une nouvelle ligne avec un nouvel Id, la liaison avec le fait est alors évident, pas besoin des dates de validité.
Le fonctionnement pour l'utilisateur est évident, pour chaque jour de données il a la ligne de dimension qui va avec : complètement transparent.


Utiliser le Many to Many
La table de dim n'a que 50 000 lignes.
Une table FactLess prend 50 000 lignes tous les jours.
Une table de dim historisée, ne contenant que les champs à historiser, prends 50 000 tous les jours.
Je suis obligé de me retrouver avec 2 dimensions.
La gestion de la date de la dimension = date du fait n'est pas solutionné.
La gestion du many-to-many avec mes partitions particulière est très compliquée à gérer...


Bilan
Dans le premier cas la dim complète prends 50 000 lignes par jour et tout fonctionne parfaitement.
Dans le second cas, j'ai 2 tables, plus petites, mais représentant 100 000 lignes par jour + une utilisation compliqué pour mes utilisateur + une alimentation compliqué à gérer..

Le choix est fait, non ?
Peut-être une autre idée ?