Naming Conventions and Syntax
Within TM1 all objects names and contents are completely defined by the Developer. Cubes, Public Views, Dimensions, Public Subsets, Processes, Chores and Applications are all named on creation.
All too often naming conventions are disregarded within the initial development stages of a TM1 implementation. Usually an attempt is made to bring these in at a later time, often too late – it will never be considered as a value-add enhancement by management.
Below are some simple guidelines to naming objects within TM1.
Across all of the next tips and recommendations the golden rule is this – Once you begin with a set of conventions, do not stray from them. This can often lead to the messiest TM1 implementations around.
- Decide whether to use underscore instead of space, and stick to it!
- (Can exclude Subsets and Views)
- The first folder under Applications should be the type of the TM1 Solution
- Example: ‘Applications’ is the Parent of ‘Planning’ and ‘Reporting’
- If there are plans to expand the solution in the future append a Prefix based on the TM1 Solutions Function
Example: For a Budgeting & Planning Solution append ‘Plan_’ to the start of each Cube name.
- Append a Prefix based on the TM1 Solutions Function, even if there are no plans to expand the solution in the future. (See exclusions below)
Example: For a Budgeting & Planning Solution append ‘Plan_’ to the start of each Dimension name.
- For shared dimensions such as ‘Year’, ‘Month’ or ‘Scenario’ which for example may be shared between Reporting and Planning Environments use ‘Base_’ instead of the standard Prefix (‘Plan_’)
- For values dimensions use ‘Values_’ instead of the standard Prefix (‘Plan_’)
- Name the Dimension in the nouns singular form, unless that noun is always in a plural form in English
Example: The ‘Plan_Account’ Dimension (Correct) vs. the ‘Plan_Accounts’ Dimension (Incorrect).
Views and Subsets
- If possible align it to a step within the Administrators/Budget Line Managers Task list by appending the corresponding number to the start of it.
Example: Within the ‘Plan_GL’ cube – ‘1) HL Comparison Act vs. Bud 2009’
- Append either ‘META’ or ‘DATA’ to the beginning of the Process name to define whether the Process is making Data or Meta (Dimensions / Subsets) changes.
- Next append either ‘import’ or ‘export’ to the Process name to define the direction of Information.
- Next append the cube name or a description of the Mapping/Transformation the data undertakes.
- Avoid Hard Coding Processes to work for only a Single Element/Data set unless it is absolutely necessary.
- Avoid ‘DATA import GL Actuals’ as this process should be ‘DATA import GL’ – and the Process should be built to cater for importing information from any scenario/version within the source system to any scenario/version within the TM1 cube. The Source and Destination should be given to the process as a Parameter.
- Avoid ‘DATA import GL 2008’ as again the Year should be given to the process as a Parameter
- This may not always be possible due to a messy source system/data which may require transformation/mapping per scenario etc.
- Whenever creating a Process on the fly to re-load information/clear out/fix an issue, append ‘_Temp’ at the end unless the process is going to become permanent. It’s then just as important to look through all processes removing all processes with ‘_Temp’ monthly/weekly.