TM1 Forum

Hi all,

I am not a true tm1 developer as yet i am currently in training however i would like to ask you for some guidance on which approach is better when it comes to dimensions/Elements.

I come from a background of relationship databases and before tomok says.. Olaps and relationships are diffrent (as i read on a previous post answered by him ) im sure certain aspects of the olap systems within TM1 are still the same. (could be wrong)

ok so heres my question..

When it comes to a TM1 enviroment with multiple Suits of databases is a shared dimension aspect quicker than individual dimensions?

also can dimensions be turned into subsets for individual cubes without the need to update the subsets if new dimensions are added to the parents?

Like i said im new to this forum and system so please be gentle on the answers

I think you will have to try to rephrase your question as currently it is not really comprehensable to a TM1 Developer.

I'll have a stab, but as you allude to yourself your question is phrased from a DB admin's point of view, and there's a bit of a paradigm shift in moving to OLAP.

Darkhorse wrote: When it comes to a TM1 enviroment with multiple Suits of databases is a shared dimension aspect quicker than individual dimensions?

Within an individual instance of TM1 there is only shared dimensions, there is no individual dimensions unless you actively design it that way. If you use the "Cost Centre" dimension in the HR cube and the P&L cube then the dimension is common and any changes to the dimension will be reflected in both cubes. If you want individual dimensions you'll have to create "Cost Centre HR" and "Cost Centre P&L" as separate dimensions on purpose.

Darkhorse wrote: also can dimensions be turned into subsets for individual cubes without the need to update the subsets if new dimensions are added to the parents?

I think you meant "also can dimensions be turned into subsets for individual cubes without the need to update the subsets if new elements are added to the parents?"
If that is what you meant then yes, do a search on MDX. In particular have a look for the MDX primer in the useful code, tips and tricks forum.

Darkhorse wrote: Like i said im new to this forum and system so please be gentle on the answers

We're generally only rough on beginners who make no effort to educate themselves before asking basic questions in the forum. Especially when they're consultants who are passing themselves off as experts and making a buck off our knowledge. We're more than happy to help people with concepts, poorly documented aspects of TM1 and more technical things like how to do complex rules and feeders.

Thanks Martin Ryan that was quite informative sorry about the question i really should of worded this better but you have answered my question

I would like to delv into this question a little further if you wouldnt mind?

as i said before in my previous question im coming from a relationship database history which in olap world is not that useful, so im trying to get my head around some of the design work already completed by work place,

heres my example..

i have a cube called main sales data and dimensions called cost centres, one called measures,

in my cost centres cubes i have

Rail
-London
--1101123
--1231222
-North
-- (Etc)
-South
-- (Etc)
Air
-- (Etc)
Sea
-- (Etc)

In my Main sales cube i utilise all these cost centre hierachies. nothing to taxing however when i look at other cubes built and defined within the same tm1 server most of these cubes have created there own verisons of the Cost Centre Dimension using only Rail or Air. the reason for this is due to the high amount of cost centre codes available and they want to shorten the amount of options available to the users. (this in my eyes makes administration a nightmare when new cost centres appear)

i have read all around the Tm1 forum and found Subsets mentioned and have googled this alot but im finding no direct answer to which is more flexible and effiecient within tm1. refering back to Martin ryans response MDX is the way to go utilising subsets but i would really like to gather some knowledge on best practice in utilising Dimensions to there full effect as dimension architecture and modelling is very sparse to find on the tinternet. if someone could point me in a direction of a site that would be just as usefull.

Thanks all that read this.

and thanks once again to Martin Ryans

Ach, what the hell, I'm waiting on a big TI to process so may as well have a stab.

The answer to the question around shared / unique dims depends on your model and user base predominantly however for the majority of the time it's best to used a shared dimension (ie multiple cubes having the same dim in the architecture) for the simple reason of maintenance, functionality and data integrity.

By using this method, any changes to attributes, aliases, heirarchy, etc are replicated across all associated cubes as the changes are being made to the dimension and it's elements. Having unique dimensions means headaches looking after multiple instances to make them sync correctly - even with a fully automated suite of TI's, etc it's still a risk you generally don't need in a model.

That said, on occasion, it can make sense to have unique dims. It's very situational though. The other part is the half way house you can see of having two very similar dimensions where one is at a lower level than the other - eg, one dimensions with days consolidating into months then years and a seperate dim which is the same but a level higher (ie no days so that the month is the bottom level element). This is generally done when numeric data needs to be entered directly into the consolidated layer as the Lvl 1 data in Dim A is effectively Lvl 0 data in Dim B (in that case the month) and then rules / feeders often use ELPAR/ELCOMP type functionality to tie the cubes together.

When you talk about subsets, you'll soon learn if you haven't already that terminology is key in TM1 . Basically, a subset is just a selection of elements which have been selected from all the available elements in a dimension. IE, subset A and subset B both live within a dimension and are selections made from the same overall list of elements in the dimension. MDX is where you essentially give TM1 a list of instructions to trim down the list from the full available list to the ones you want which is executed whenever the subset is referenced. Eg, Always give me all bottom level elements is a very common MDX statement. This means that whenvere dimensions are updated, your subsets will update without manual intervention. You may already know this but felt it was worth clarifying.

So basically, you can't set a subset and only allow the users to access only that subset in a cube view. You can set up the view so that it opens up defaulted to the subset list thus restricting what they see but once they hit the refresh (or Upside Down A button - old habits die hard ) then all the avaialble elements to the user based on their security level will be available to them. You can actually set security in rules to work around this in certain circumstances but that's a bit further down the line for you at this stage.

Also, bear in mind that if you supress zeros on the view that any empty data will not be shown anyway so it shouldn't matter if your dim has lots of elements and you only use a few from a user viewing point of view. You want to encourage your users to use supress zeros in most cases anyway (or at least you'll want them to understand what it does).

The real issue comes though from your rules and feeders accessing large dimensions if they are badly defined. Without pre-judging your model, I suspect you may find this to be the case based on what you've described of your model. Without going into a long winded paragraph, I'd suggest you read the feeders section of the guides if you've not already then you'll be able to see why the designer if he felt uncomfortable with sorting out feeders decided to trim the dimensions into smaller self contained, less sparse versions of the same dim. Just a hunch but suspect that's what you'll find.

If you decide to get your hands dirty and do some re-writing, I'd suggest getting an experienced consultant / contractor to come in and go through this with you by the way as TM1 has a number of "unique" ways of doing things, unusual syntax and quirks that you only really come across through experience. The training material and advice from forums such as this will get you a good proportion of the way along and I'd get through that first to make sure your investment is well utilised as it's the training your looking for as much as getting the actual task done. Also bear in mind that the TI's are going to need a thorough review at the same time.

If like many instances, your users think that TM1 is a spreadsheet with some buttons on it, you may want to bear in mind that you could use a SUBNM formula which will restrict the returned list to only those elements in the subset. This is often held within a validation list to ensure there are no typos against the element names with the DBR / DBS functions pointing at the validation cell. These will always reflect the latest elements held within the subsets so large volumes of reports can be updated in one central area.

So basically, it depends on what you're trying to do, how well trained your user base is, what mechanism they're using to interact with TM1 and how complicated the architecture and rules/feeders in your system are

Good Luck!

Apologise for not replying sooner, i forgot to say Thank you to all that replied i found what was said to be extremely useful, alhough still confused 2 months on i think i can understand most of the logic behind this

thank you all once again