MDX: Forming Complex "Structures" (for lack of a better term)

Question

I'm trying to create a "structure" that contains (Customer, Date of First Purchase, Date of Last Purchase) where the last 2 items are members from the same dimension attribute. This structure will form the basis of some more complex logic...for
example, I may have another "structure" containing (Customer, Date of Event1, Date of Event2) that needs to be intersected with the first:
Intersect(
Struct1 (Customer, Date of First Purchase, Date of Last Purchase)
Struct2 (Customer, Date of Event1, Date of Event1)
One option I'm considering (since a tuple cannot contain multiple members from the same dimension attribute according to
this article) to create additional date dimensions with the same relationship to the fact tables and use LINKMEMBER.
Another option would be to create a set consisting of 2 tuples for each customer:
(Customer A, Date of First Purchase),(Customer A, Date of Last Purchase),
(Customer B, Date of First Purchase),(Customer B, Date of Last Purchase),
...and then using some FILTER/GENERATE logic to work through the remaining logic...but I'm not convinced this would be any easier than simply maintaining 2 separate sets:
(Customer A, Date of First Purchase),
(Customer B, Date of First Purchase),
(Customer A, Date of Last Purchase),
(Customer B, Date of Last Purchase),
Any suggestions/recommendations?
Is my approach way off?
BI Developer and lover of data (Blog |
Twitter)

Answer 1

hi,
another idea: take the same attributes from different hierarchies , make  pseudo hierarchies if needed.
Philip,
thanks - that is also a good idea. However, and just like with the option of creating extra role-playing date dimensions, the drawback is that it isn't "dynamic" - I would need to know ahead of time the max number of possible members from the dimension attribute
to include. 
I'm essentially trying to implement complex temporal logic dealing with events in time...and while so far I've only seen the need to have 4 members from the same dimension attribute in a "structure" future requirements may call for more than that.
BI Developer and lover of data (Blog |
Twitter)