Discussion :

[Jinroh77]

Bonjour à tous,
Je cherche à créer une dimension technique me permettant d’agréger mes croisements de ventes.

Un fait au niveau Produit, Magasin, ticket de caisse.
Une table pour une dimension technique avec une tête comme cela

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Id, Libellé
0, 'Produit seul'
1, 'Produit +1'
2, 'Produit +2'
etc.

J'ai ensuite une mesure de nombre de distinct de produit.

Il ne me reste "plus qu'à" lier ma dimension technique à mon fait, mais je ne parviens pas à créer la définition de mon scope...

[arnaudvoisin]

Bonjour Alex,

Petite question, tu as lié ta dimension technique avec ton groupe de mesure ? Ce n'est pas obligatoire, il y a plusieurs méthode.

Tu as essayé quelque chose qui ressemblerait à ça ? Je n'ai pas de certitude sur le fait que ça fonctionne mais essais et tu me diras.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SCOPE([TaDimTechnique].&[0],[TaDimProduit].Members));
      This =([TaDimProduit].CurrentMember);
END SCOPE;

Bien sur, avec ce type de scope il faudra scoper autant de fois que tu as de membres.

Sinon tu pourrais nous en dire plus sur ton design et sur le genre de calcul que tu voudrais appliquer aux membres de ta dimension technique ?

Arnaud VOISIN
Consultant BI chez WAISSO | MCITP - SQL SERVER 2008 BI
http://arnaudvoisin.blogspot.fr/
http://www.waisso.com/

[Jinroh77]

C'est justement cette liaison que je cherche à construire, avec un SCOPE.
La dimension n'est pas liée dans la définition des relations d'attribut.

Le CurrentMember seul, ne sera pas suffisant.
Cette dimension doit se lier en fonction du nombre distinct de produit vendu par ticket de caisse.

J'ai donc besoin de définir cette liaison en utilisant à mon avis :
- la mesure du nombre de produit distinct, lié, je ne sais comment avec la dimension ticket de caisse, que ensuite, je relie avec le scope sur la dimension technique Association et sa clef qui représente le nombre distinct de produits : 1, 2, 3, etc.

[Jester]

Mettre la clé de jointure avec cette dimension dans la table de fait dans le DSV?

Genre (exemple un peu bateau où chaque item est sur sa ligne avec quantité = 1 mais ça donne l'idée) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
with temp as (
select *, count(*) over (partition by order_id, produit_id) as nb_produit_dans_cette_commande
from ta_table_de_fait
)
select *, case when nb_produit_dans_cette_commande = 0 then 0/* l'id dimension technique */ when ...

[Jinroh77]

Merci pour l'idée, mais le problème est que j'ai besoin de rendre cela dépendant du membre Produit.

L'idée est bien de faire des associations de vente :
- le produit en filtre de ma requête est vendu avec 1, 2, 3, etc. autres produits sur le même ticket de caisse.

Par ailleurs, je dois abandonné ma dimension dégénéré Ticket de caisse. Impossible de faire un select distinct ticket de caisse sur mon fait. Trop de volumétrie.

[FrancoisJehl]

En gros ce que tu voudrais c'est une dimension de détail dégénérée des faits - parce que tu vas être obligé de faire ça pour avoir toutes les possibilités - et une dimension tech avec hiérarchie scopée, sur laquelle tu affecterais les membres fins - i.e. tes ventes - grâce à une mesure en DistinctCount?

Hmmmpfh. C'est probablement faisable mais ça va péter, parce que je ne vois pas comment contourner le fait que tu vas devoir affecter des membres d'une dimension de détail dans chaque membre de ta dim technique, en te basant sur des égalités pourries ( d'une member property/member key) de ta dim technique avec ton DistinctCount. Waow.

Je regarderais quand j'aurai un AW sous le coude mais je pense que même AW peut péter sur un truc pareil. Je pense que tu ferais mieux de le gérer en SQL, surtout que c'est un attribut de la vente et que c'est non dynamique.

[Jinroh77]

En gros ce que tu voudrais c'est une dimension de détail dégénérée des faits - parce que tu vas être obligé de faire ça pour avoir toutes les possibilités - et une dimension tech avec hiérarchie scopée, sur laquelle tu affecterais les membres fins - i.e. tes ventes - grâce à une mesure en DistinctCount?

C'est ça.
Actuellement, avec un simple fait de produit, date, magasin, ticket de caisse, je me retrouve déjà avec des groupes de mesures Distinct Produit, Distinct Magasin et Distinct Ticket de caisse.

Je pensais ré-utiliser ta dimension tranche d'âge pour en faire quelque chose, mais rien ne passe. Mes essais d'égalité sur les member_key de ma dimension Association et le DistinctCountProduit sont KO.


En SQL, ça reviendrait à :
- conserver ma dimension association
- ajouter une colonne sur mon fait pour compter le nbr de produit pour chaque ligne de mon détail Produit / Magasin / date / ticket de caisse ?

[trash_07]

A) Tu devrais créer une fausse dimension :
"1" Produit
"2" Produit +1
"3" Produit +2
B) Dans ta table de fait créer une colonne "LienDimension" avec comme valeur 1 pour toute valeur.
C) Lier ta dimension avec ta table de fait
D)Créer un membre par défaut :
alter cube currentcube update dimension [CumulProduit] , default_member='[CumulProduit].[CumulProduits].&[1]';
E) Avant tout calcul de membre (nottament les divisions) faire des scopes sur cette dimension
scope ([CumulProduit].[CumulProduit].&[2] , *);
this = (sum(
{"[Produit].[Produits].currentmember+1 : Ton calcul sur te produits aller chercher la sum avec le produit +1"}, [CumulProduit].[CumulProduit].&[1]), [Measures].currentmember
),
;
end scope;

J'espére que j'ai bien compris ton problème et que cela a pu le résoudre
Cordialement,