企业绩效管理网

 找回密码
 立即注册

QQ登录

只需一步,快速开始

查看: 452|回复: 4

Namespace (or Scope) for TM1 Dimensions?

[复制链接]

77

主题

412

帖子

594

积分

高级会员

Rank: 4

积分
594
QQ
发表于 2014-3-21 07:50:33 | 显示全部楼层 |阅读模式
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.
回复

使用道具 举报

90

主题

419

帖子

614

积分

高级会员

Rank: 4

积分
614
QQ
发表于 2014-3-21 09:15:53 | 显示全部楼层
mrnara wrote: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.
回复 支持 反对

使用道具 举报

75

主题

385

帖子

554

积分

高级会员

Rank: 4

积分
554
QQ
发表于 2014-3-21 09:34:24 | 显示全部楼层
mrnara wrote: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.
mrnara wrote: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.
回复 支持 反对

使用道具 举报

62

主题

411

帖子

557

积分

高级会员

Rank: 4

积分
557
QQ
发表于 2014-3-21 09:40:56 | 显示全部楼层
rmackenzie wrote: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)
回复 支持 反对

使用道具 举报

78

主题

397

帖子

582

积分

高级会员

Rank: 4

积分
582
QQ
发表于 2014-3-21 09:53:01 | 显示全部楼层
Lukas Meyer wrote: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.
Alan Kirk wrote: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.
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|手机版|小黑屋|企业绩效管理网 ( 京ICP备14007298号   

GMT+8, 2018-11-14 18:56 , Processed in 0.176430 second(s), 13 queries , Memcache On.

Powered by Discuz! X3.1 Licensed

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表