You can explicitly enumerate the columns in MDX. you do not have to use a cross product. Instead of
{ Accounts.Version.Actual, Accounts.Version.Budget }
*
(Date.Calendar.Year_2012 + Date.Calendar.Year_2012.Children)
(which would produce a "symmetric report"), you can use
{
(Accounts.Version.Actual, Date.Calendar.Month1_2012),
(Accounts.Version.Actual, Date.Calendar.Month2_2012),
(Accounts.Version.Actual, Date.Calendar.Month3_2012),
(Accounts.Version.Actual, Date.Calendar.Month4_2012),
(Accounts.Version.Actual, Date.Calendar.Month5_2012),
(Accounts.Version.Actual, Date.Calendar.Month6_2012),
(Accounts.Version.Actual, Date.Calendar.Month7_2012),
(Accounts.Version.Actual, Date.Calendar.Month8_2012),
(Accounts.Version.Actual, Date.Calendar.Month9_2012),
(Accounts.Version.Actual, Date.Calendar.Month10_2012),
(Accounts.Version.Actual, Date.Calendar.Month11_2012),
(Accounts.Version.Actual, Date.Calendar.Month12_2012),
(Accounts.Version.Budget, Date.Calendar.Year_2012)
}
(or adapt the above column list as you like), or use any way to build the column axis set that you prefer like
{ Accounts.Version.Actual } * (Date.Calendar.Month1_2012 : date.Calendar.Month12_2012)
+
{ (Accounts.Version.Budget, Date.Calendar.Year_2012) }
as long as the dimensionality of the axis set stays consistent, i. e. all tuples of the set have the same number of members (two in this case), and in each position of the tuples of the set, there are only members of the same hierarchy (Accounts.Version
in the first position, and Date.Calendar
in the second here).
That is just with regard to MDX. Another question is which user interfaces expose which of the possibilities of MDX.
And finally: Named sets are named sets in MDX. At least Analysis Services does not have the concept of a named tuple. I think the Essbase MDX dialect has this.