Version imprimable
Voilà mon pb :
j'ai dans 4 cubes différents un même menbre EMAIL. J'ai 1 cube virtuel qui repose repose sur ces cubes. EMAIL est l'adresse email (text), et non un nombre d'email.
Je voudrais faire la somme "distincte" du nombre de ces emails (et ne pas compter ceux en double, c'est à dire les adresses présentes dans plusieurs cubes). Cette somme "distincte" est un membre calculé de mon cube virtuel ...
Je n'ai aucune piste ...
pardon, mais je ne comprends pas bien.Citation:
Envoyé par Guizz
Tu veux dire que le champ EMAIL est un des niveaux d'une dimension partagée, utilisée dans chacun des 4 cubes (et si oui quelle dimension)?
ou c'est complètement autre chose?
un exemple de niveau : Mois (de la dimension Temps)
un exemple de membre : janvier
donnes plus de précision concernant les dimensions partagées utilisées dans ton cube virtuel (puisque c'est dans celuià que tu veux le nombre d'email non?)
non, email est une "mesure" présente dans chaque cube; en fait c'est plus un champs informatif qu'autre chose ... parceque ce que je compte ce sont des clics, des ouvertures mais il ne faut pas que je perde l'email, qui sert en fait d'identifiant unique ... (mais qui ne fait pas parti de ma clé primaire dans ma table de fait) ...
Desfois je me dis que je dois vraiment pas être clair ... :oops:
Tu places un champ texte en mesure? vraiment bizarre
si c'est le cas, tu peux utiliser la fonction d'agrégat "distinct count" à modifier dans propriétés/Aggreggate Function
C'est ce que j'ai essayé mais je n'est pas distinct count de présent ... (count, min, max, sum) ...
pour email, en fait je ne sais pas comment te le dire, ce n'est en fait ni une mesure, ni un menbre ... juste une ibnfo que je conserve
d'acccord, mais tu la conserves sous quelle forme :
"propriétés de membre" d'un niveau, autre,...? parceque la solution risque vachement de dépendre de ça.
Tes questions me permettent moi même d'avancer ... l'email n'est pas stocké au niveau du cube, mais dans la table de faits ... ce que je voudrais de présent dans le cube, c'est le nombre d'email distincts par table de faits, sachant que j'ai une table de faits pour chacunde mes 4 cubes ... :roll:
si tu veux le nombre d'emails distincts par table de faits, pourquoi ne pas rajouter un champ "présence" dans chacune des tables ?
Pour chaque ligne,tu le mets à 1 si l'email est unique et 0 si tu l'as déja.
Ensuite, tu n'as plus qu'a sommer au sein du cube.
et si tu veux pour l'ensemble de tes cubes, tu reprends le principe en vérifiant la présence/absence de doublons dans les autres tables.
Ce sera peut-être plus simple,non?
C'est pas con ... 8) mais il me reste un problème: le nombre total d'emails envoyés c'est la somme des emails distincts des 4 tables de faits.
(Si mes tables de faits sont T1 .... T4) :
Les emails distincts de T1 sont un sous ensemble de T2 ... d'ou un problème de doublons. Les emails distincts de {T3,T4} sont indépendants, de même que ceux des sur ensembles {T1,T3,T4} & {T2,T3,T4} ... par contre l'intersection des emails distincts de {T1,T2} n'est pas vide ...
Le problème de la méthode précedente, c'est que le compte des emails doit se faire sur les dimensions communes du cube virtuel ... ce qui veut dire que dans mes tables de faits j'ai des dimensions qui ne seront pas prises en compte d'où une hétérogénéité des données dans le cube ...
Comment marche un cube virtuel ? est ce qu'il agrège au niveau "tous" toutes les dimensions non présentes ?
J'ai quand même l'impression que la solution passe par le MDX et le distinct count, mais je n'arrive pas à comprendre la syntaxe, particulièrement les "sets" ...
par exemple qu'est qui n'est pas bon là dedans:
Code:DISTINCTCOUNT("dbo"."TABLE_FAITS_CIBLES_CLICS"."EMAIL")
regarde la syntaxe de la fonction MDX.Citation:
Envoyé par Guizz
DistinctCount nécessite un jeu de données (Set) en paramètre. Toi, tu lui donnes une mesure ! définis un jeu (regarde les fonctions qui renvoient Set, c'est facile c'est classé).
mais là tu crées un membre calculé. Comme je te l'ai dit , il est à mon avis plus simple de définir une mesure.
Concernant les cubes virtuels, tu ne peux avoir en commun que les dimensions conformes (ou partagées) mais je ne vois pas où est le pb?
les dimensions non-prises en compte correspondent (logiquement) à celles pour lesquelles la comparaison de tes cubes n'a pas de sens.
ok pour les mesures; cependant, je vais avoir des données incohérentes dans mes tables de faits:
ex:
FAIT_CLICS
--------------
cibleid --> id de la cible du mail
campaignid --> id de la mailist
segementid --> id du segment de la cible
tempsid --> id temps
mesure1 --> nombre de clics
mesure2 --> email distinct
tempsid n'est pas une dimension de mon cube virtuel; donc par exemple, je pourrais avoir les données suivantes:
15,12,10,1,12,1
15,12,10,2,3,0
15,12,10,3,15,0
ce qui introduit de l'incohérence non ? 1 email unique devrais aussi l'être par unité de temps (tempsid est menbre de la clé) mais si je fais ça, quand je vais "sommer" les mesures dans le cube virtuel, j'aurai plusieures fois l'email unique par {cibleid,campaignid,segementid} ...
la véritable question devient maintenant :
pourquoi la dimension Temps n'est-elle pas partagée?
je suppose que ton identifiant temps pointe vers une table de dimension indépendante des tables de faits. Pourquoi n'est-elle pas conforme?
P.S et svp, après on s'arrête :?
Concernant la dim temps, elle est bien partagée; le pb, c'est qu'un email distinct par unité de temps ne veut rien dire. Cet email doit être distinct seulement par campagne ... si j'ai 3 clics d'une même cible à trois moments différents pour la même campagne, j'ai 1 seul email distinct. Or ça ne veut pas dire grand chose de mettre dans la table de faits clics '1' pour un des trois clics et '0' pour les deux autres ...
Bon merci quand même ... je sais que c'est pas trés clair ... et dis moi quand tu prends tes vacances pour que je m'arrange à les prendre en même temps :lol:
ultime recommandation :
peut-être, dans ton cas, faut-il distinguer l'analyse des clics de l'analyse du nombre de mails (cubes distincts) puisqu'apparement il n'y a pas de lien logique. Demande toi ce que représente une ligne de ta table de fait (quel évenement),...
Je ne saurais trop te conseiller (ainsi qu'a tous ceux que le concept OLAP intéresse) la lecture des ouvrages de R.Kimball :
”Concevoir et déployer un data warehouse”, Eyrolles, 2000
”Entrepôts de données”, International Thomson publishing, 1997
Voilà, sinon, pour les vacances, eh bien, je sais pas encore si j'en aurais! :cry: