Multipurpose Dimensions - good or bad practice?

[fleaster]

Ok, so basically I'm creating a Finance/General Ledger cube that may have around 16 dimensions:

ReportType
Version
SectionA
SectionB
SectionC
Company
Affiliate
FunctionalCell
Product
ProductProcessor
ResponsibilityCentre
Account
CurrencyCode
Period
BalanceType
MeasureType

...4 of these are kind of "spare" or "multi purpose" dimensions i.e.

Report...........SectionA..........SectionB.................SectionC
BASE................NA.................NA.......................NA
LOCALREG.........Total Domicile....Interest Type..........NA
BIZ1.................Cust Segment....Channel.................Initiatives/Projects

...the idea is the primary source of data will be the BASE element in the Report dimension, with SectionA/B/C being "NA". Then the LOCALREG and BIZ1 Report Types (which the user can switch between) will then split these by % into various other structures as needed - Domicile, Segment, Channel etc in SectionA/B/C, which are the "multipurpose" dimensions. All the other 14 dimensions will be the same. It is also expected there may be new Report types that will split balances in different ways/structures in future.

So I guess the question is, do you think this design will work (from a maintenance + performance + user point of view), or would you rather have a new cube for each dimensionality requirement etc...?

Cheers,

Matt

P.S. am considering rule calculating the % proportions in a staging cube then TI them into the primary cube

[rmackenzie]

Hi Matt. In my view, multi-purpose dimensions would need very strong justification and my default position would be to say that they are not good practice.

My main reason would be that one of the key strengths of TM1 is that you can name your dimensions and elements in any way you choose - meaning that you can customise a dimension to suit the business language of your organisation. E.g. some people have products and some people have categories, some peoples divisions are other peoples departments and some peoples months are other peoples periods and the list goes on. But at least the dimension name and elements were meaningful. When you just have a generic dimension with generic elements then people can start to lose sight of what the cube means to the user in terms of their business understanding. Also, the more generic items you add to your build, the less intuitive it is for not only users but future developers (think about rules being 'readable' from a business calculation point-of-view).

However, I like that you want to futureproof the reporting capability of the cube. I wonder if you've thought about using alternate hierarchies in the 'real' dimensions built up from attributes that you can progressively add to as, inevitably, reporting requirements and defintions change over time. It might be that managing the growing list of attributes and hierachies requires some overhead but at least you get to deal with the requirement at the time rather than guess at how to implement a future requirement up-front by putting in the spare dimension.

There is always lots of worthwhile discussion to be had during the design/ development phase of your project regarding which dimensions are really attributes and which attributes are really dimensions. That is also the time to have a discussion about whether you building the cube to support a reporting layer that obfuscates the use of barebones TM1 or not. At some point if people are comfortable just jumping in the cube to self-serve data to support their reporting and analytics then you'd want to try and make it as intuitive as possible for them to get what they need.

Just my thruppence.
Robin

[lotsaram]

From the title of the thread my assumption was you were talking about "common or shared" dimensions that might be used in several cubes like year, month, product, version, etc. Which are generally a good idea and it is a relative strength of TM1 vs. Essbase for example that dimensions can be shared among cubes which means they only need to be defined and maintained once and not all over the place. however there are some caveats as inexperienced TM1 designers often "over share" which can cause a lot of problems and unnecessary additional complexity when it comes to measures, security models and approval hierarchies. I would go with the ("best") practice of a separate measure dimension per cube and when it comes to dimensions like version and even cost center, business unit etc you need to be careful as what may at first glance seem the same may actually need to be several different but equivalent dimensions for the purposes of security or managing approval hierarchies and Contributor applications. It is MUCH better to get this right first time or err on the side of caution than have to change a design later and separate dimensions out.

But I digress because that's not what you meant! If by "multi-purpose" you are talking about some kind of future-proofing for a rainy day where "we might need to split this in the future but we don't really know how or why just yet" kind of scenario then I would say DON'T. Adding unnecessary dimensions with no business meaning adds no value, in fact it destroys value as it makes browsing data more difficult and less intuitive. IMO any "hyper-cube" design where there are 20 dimensions but only 6 are relevant to the query to be performed and the user therefore needs to select "NA" or "TOTAL" on every one of the other 14 dimensions is bad design. Sometimes there may be good reasons for some additional dimensions like keeping dimensions equivalent between cubes or having a version dimension even though there are only actuals, but keep this to a minimum. Always best to minimize complexity.

[fleaster]

thanks again for the tips

I think what I'd like to understand is what is a good practice when it comes to future proofing cubes, and what factors should one consider?

...or should we just assume a full rebuild/rollout is needed each time additional dimensionality is required? (am also not too fond of sticking additional stuff in a Measures dimension just because it's the only one "spare")

But I digress because that's not what you meant! If by "multi-purpose" you are talking about some kind of future-proofing for a rainy day where "we might need to split this in the future but we don't really know how or why just yet" kind of scenario then I would say DON'T.

This going to sound bad but I am 100% certain we will need 2-3 dimensions and 70% sure I know what the additional structures will look like - just that we may not have the capacity to bring everything together in the 1 go (it may be a followup project, but would prefer not to have to rebuild any primary cubes and cause user headaches 6 months later)

...am wondering if a better strategy is to build the BASE cube first (that I know will be used by all 100 users), then feed this into a Secondary "Split" cube (that may be used by 20-30 users), and upgrade this one later if needed... would still like at least 1 spare dimension though... hmmmm...