Namespace (or Scope) for TM1 Dimensions?

[mrnara]

I'd like to create a Dimension called Date, but someone using my server has already defined a Date Dimension (that has a much larger range than I would like, and has some sub-divisions that I don't want).

In a normal programming language, one can use a local variable "x" in separate subroutines, without the value of one "x" adversely affecting another.
Is there a similar notion of a Scope in TM1? i.e. we both can have a Date Dimension in different "areas" of TM1 that won't adversely affect one another?
I'd prefer not to have to rename my "Date" to something else. And using a separate server instance seems like a high overhead.

[Alan Kirk]

I'd like to create a Dimension called Date, but someone using my server has already defined a Date Dimension (that has a much larger range than I would like, and has some sub-divisions that I don't want).

In a normal programming language, one can use a local variable "x" in separate subroutines, without the value of one "x" adversely affecting another.
Is there a similar notion of a Scope in TM1? i.e. we both can have a Date Dimension in different "areas" of TM1 that won't adversely affect one another?
I'd prefer not to have to rename my "Date" to something else. And using a separate server instance seems like a high overhead.

I think it may help if you have a read through some of the manuals to get your head around what TM1 is, and what it is not.

One thing that it is not is a programming language. Dimensions are not variables, they are part of the metadata of your TM1 database. (Though when I say "database" I'm using it in the broader sense of the term. Don't try to compare it to an RDBMS server like SQL Server either, where you could have objects of the same name within different schemas; there's no equivalent to that in TM1.) The entire database is in effect everything that is on the server. (And you can't just put it on another server unless your licencing permits you to run multiple servers anyway; beware of that one in case you're ever audited.)

So no, you can't have two objects of the same name within a single server. Your only option is to create the dimension with a different name. Then I'd suggest that you decide on having one primary administrator who can act as an arbitrator and map out a master plan before these kinds of conflicts arise. TM1 is very flexible but if you intend to put it to serious work it's best to map out a plan first rather than making it up as you go; that's possible, but you may not get the best results from it.

[rmackenzie]

we both can have a Date Dimension in different "areas" of TM1 that won't adversely affect one another?

Nope - once a server instance has a dimension called Date, then that's it - everyone will have to use the same Date dimension.

someone using my server has already defined a Date Dimension (that has a much larger range than I would like, and has some sub-divisions that I don't want).

The range shouldn't matter because TM1 handles sparsity really well. Can't you define alternate consolidations in the existing Date dimension that you can use for your cube? E.g. if the current sub-divisions/ consolidations are based on weekly roll-ups, then there's nothing to stop you creating monthly roll-ups based on different date ranges. As long as the granularity of the dimension suits then different structures can co-exist. If the granularity doesn't suit then you've got a genuine need for a different dimension.

[Lukas Meyer]

The range shouldn't matter because TM1 handles sparsity really well. Can't you define alternate consolidations in the existing Date dimension that you can use for your cube? E.g. if the current sub-divisions/ consolidations are based on weekly roll-ups, then there's nothing to stop you creating monthly roll-ups based on different date ranges. As long as the granularity of the dimension suits then different structures can co-exist. If the granularity doesn't suit then you've got a genuine need for a different dimension.

I would not recommend to simply use a dimension from someone else (their requirements might change and they decide to trash the dimensions structure) - you should really talk to the person(s) responsible for the current model.

If "your" data is likely to always be independent from the other just add a prefix to your objects and don't share objects. If there is an intersection it's the other way around: use as many existing objects as possible, as you need one "point of truth" for your structures. (If the data needs to be merged in the future it gets annoying if one model uses year and month dimensions and the other a continuous "Year per Month" dimension it gets annoying. If it's not a finite dimension like month (there are no more than 14 month that would make sense and only so-many consolidation possibilities) but accounts you can imagine what happens if everyone and their dog uses a different naming for the same stuff)

[rmackenzie]

I would not recommend to simply use a dimension from someone else (their requirements might change and they decide to trash the dimensions structure) - you should really talk to the person(s) responsible for the current model.

I'd suggest that you decide on having one primary administrator who can act as an arbitrator and map out a master plan before these kinds of conflicts arise. TM1 is very flexible but if you intend to put it to serious work it's best to map out a plan first rather than making it up as you go; that's possible, but you may not get the best results from it.

Totally agree with Alan. If one developer is having to negotiate 'borrowing' another developers dimension, then that's probably a problem.