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!
) im sure certain aspects of the olap systems within TM1 are still the same. (could be wrong)
