TM1 Forum

As many TM1 models include a year and a month dimension, is there a good reason to avoid naming them year and month'?
I am just asking because the advanced rule editor highlights both words in blue in statements like:
Would it be better to call them e.g. d_year and d_month instead, to have unique names which are definitely not used as predefined key words or functions?

A matter of preference. Yes it is best to avoid reserved function names but it has to be balanced against ease of use. TM1 is an end user tool and there's a lot to be said for having intuitive and "plain English" dimension and cube names. Certainly the vast majority of TM1 models I have seen have simple used "Year" and "Month" as the dimension names with no ill effect from these being reserved words. Where there are multiple time dimensions I can see the value in a naming convention that groups all related dimensions together (e.g. Time_Date, Time_DayInMonth, Time_Month, Time_Year, Time_Year-Month, Time_WeekInYear, etc...) but I can't see any value in prefixing each and every dimension with "d_" as is habit of many from an EP background, after all you already know all the dimensions ARE dimensions so the "d_" prefix doesn't add any value (personal opinion).

I've used Year and Month for dimension names many times and have never had an issue with rules. Perhaps it''s because any time you reference them in rules you either have a "!" in front of them or they are enclosed in apostrophes. I always try to use the most descriptive names possible for TM1 objects with the underlying reason to be as user friendly as I can.

I once worked on a site that had a naming convention of prefixing cubes with cub_ and dimensions with dim_. I could never see the point of it, personally, and found it quite annoying.

After that experience, I developed a naming convention I liked better and have used it ever since. It basically involves a 3-letter prefix that indicates the function of the cube -- for example CPX for capex, etc. For shared dimensions, I used GBL (for global), and for system and control cubes that are usually not browsed, I use SYS.

This makes it much cleaner and allows the model to grow over time. For instance, imagine you decided to model retail revenue in detail in the future, and needed to keep data in a 4-4-5 week structure. Instead of using your "GBL Year" and "GBL Month" dimensions, you could create "REV Year" and "REV Month", or simply, "REV Period", and it would be clear that it was just for your revenue model.

I mention it in my blog post here. At the very end of the article, I provide a copy of the naming convention specification I use as a starting point on each project.

This is also the naming convention we use for Propel Planning, so it might be worth having a look at our demo for an example.

Good to see someone dealing with naming early in a project, as it's a bit of a pet peeve of mine!

Hello everyone after a longer break.

Few comments from my side on this:

1. If you use d_/dim_/c_/cub_/p_/pro_ prefixes you lose opportunity to navigate to object in Server Explorer by pressing first letter of its name. Especially when you have lots of objects and you need display of control objects to be turned on and you have full suite of Bedrock or }tp processes then this becomes handy.

2. Using function prefixes has advantages, but can become misleading when your model grows and you would like to use your "specific" dimension also for other functions. Name does not fit so nicely anymore, but maintaining exactly the same dimension with better name is even worse. That is why I would rather try to give a general name, but of course I can think of exceptions that make sense to do it different.

3. I used Year and Month names many times and never had problems with it. In rules I have standard of always putting dimension name prior to elements list and I like to do it without apostrophes, as this is coloured differently in Rules Editor and makes rule more readible. But in such cases those apostrophes are just needed (also for dimension names that start with }).

4. Even if you have a nice standard of how to name and organize your objects you always can get to a model where it is better to make an exception and do it differently. That is why there is never a one good universal approach .

Regards.