TM1 Forum

Hello, I am new to TM1 and I do not really get it:

Measures are the cells/intersections of dimensions, correct?

Here, in an example, I have two dimensions:

Time
Price_and_Cost_Measures

At Price_And_Cost_Measures I have Unit Sales Price which is an n-element, and then I have "Status", which is an string-element. That's where I am getting confused: How can an element of ONE dimension describe what kind of value is in the cell, as the cell is an intersection of all dimensions?

Thanks a lot for your help and my start in TM1!

Cheers,

Toto

Toto wrote:Hello, I am new to TM1 and I do not really get it:

Measures are the cells/intersections of dimensions, correct?

Not exactly; that's a value rather than a measure. What's the difference? Think of someone telling you the temperature; they may say that it's 25. That tells you the VALUE of the temperature, and is equivalent to the number that's stored in the cell of a cube. But it tells you nothing about what the MEASURE of the temperature is, since 25 means something quite different here in Australia (temperate) compared to what it would mean in the US (freezing).

You'd therefore have a dimension which has elements telling you what that number represents; in this case, one of the elements of that "measures" dimension would be "Degrees Celsius".

More typically, a measures dimension (for, say, a P&L cube) might be the chart of accounts one; it may include elements like Sales, Purchases, Salaries and Wages, Cost of Production and so on.

Suppose that you had a simple retail business with two stores. You might have the dimensions:
- Store (with 3 elements, Store 1, Store 2 and the consolidation Total Stores)
- Period (which might have the weeks of the year; this would be your time dimension); and
- Account (which might have the elements Profit and Loss (calculated from the rest of the elements), Sales, Purchases, Rent, Salaries, Advertising) This would effectively be your "measures" dimension.

So if you wanted to look at the sales for store 1 for the current week, for example, you would pick the elements
- Store1
- WE 02/08/09
- Sales.

The number that's stored in that cell (say, $20,000) is your value, but your "measure" is really "sales".

Measure isn't really a defined term in TM1, but generally it's one dimension which will tell you, for all of the other elements that you select, what the number in a cell represents. If you read through the manuals you'll note that you can set a "Measures Dimension" in a TM1 cube, but that's mostly for other systems which may be getting data from TM1; TM1 itself doesn't use it.

Toto wrote:Here, in an example, I have two dimensions:

Time
Price_and_Cost_Measures

At Price_And_Cost_Measures I have Unit Sales Price which is an n-element, and then I have "Status", which is an string-element. That's where I am getting confused: How can an element of ONE dimension describe what kind of value is in the cell, as the cell is an intersection of all dimensions?

If your Time elements represent months, you may have an element for "Jul 09".

If you select Jul 09, then the value stored at the intersection of:
- Jul 09; and
- Unit Sales Price
will tell you what the unit sales price is for that month.

The value which is stored at the intersection of:
- Jul 09; and
- Status
will tell you what the status is for that month.

So it isn't really the element of one dimension that's telling you what the value is. The elements of one dimension (in this case Price_And_Cost_Measures) are telling you what the value represents, but only for the combination of elements that you have selected from all of the other dimensions.

Hi Alan,

thanks a lot four your reply! Ok, I got it. But one last question:
How does TM1 evaluate which dimension to take if there are several dimension with string-elements?
Example:

Just for testing I made three dimensions:

Measures:
Units n-Element
Revenue n-Element
TestString String-Element

Countries:
US n-Element
GB n-Element
Other String-Element


Cars:
Seat n-Element
Peugeot n-Element
Chrysler STring-Element

Cube looked like this:
Country: GB

Units Revenue TestString
Seat 20 20 String
Peugeot 20 20 String
Chrysler 20 20 String


Why does only the column "TestString" expects a string and not "Chrysler"??

Thanks again!!

Toto wrote:Hi Alan,

thanks a lot four your reply! Ok, I got it. But one last question:
How does TM1 evaluate which dimension to take if there are several dimension with string-elements?
Example:

Just for testing I made three dimensions:

Measures:
Units n-Element
Revenue n-Element
TestString String-Element

Countries:
US n-Element
GB n-Element
Other String-Element


Cars:
Seat n-Element
Peugeot n-Element
Chrysler STring-Element

Cube looked like this:
Country: GB

Units Revenue TestString
Seat 20 20 String
Peugeot 20 20 String
Chrysler 20 20 String


Why does only the column "TestString" expects a string and not "Chrysler"??

Three things to note about strings:
(a) Use them sparingly, if you really need to use them at all. TM1 is basically a number-crunching machine, and strings often get in the way;
(b) They don't consolidate. That means that if you put a string in at N level and look at a browse using a C level element, you won't see the underlying comments unless you replicate them at every C level. If you must store strings, I find it's better to have them in a separate cube from numeric values and then pull them together in an Excel report; and
(c) You can use them in only one dimension, the last one. See page 2-12 of the 9.4 Developers Guide:

9.4 Developers Guide wrote:To include a string in a cell in a cube, the element from the last dimension defining the cell must be a string element. TM1 treats string elements that occur in any dimension other than the last one as numeric elements. The typical use for string elements is in a two‐dimensional cube that converts codes in an input file to formal element names. For example, if you want to convert account codes to account names.

(That last example is marginally dodgy and probably hasn't been rewritten since version 6. In reality an Alias will usually work just as well for that, assuming that the codes and names are unique.)

While we're on the subject of questionable entries in the manuals (as we were in a recent thread), I thought that this entry in the 8.2 manual was interesting:

is_Document_888_eng-clnt.pdf wrote:Also, note that when optimizing the order of dimensions in a cube, you should not move string dimensions from the last position, nor should you move string dimensions to the last position.

One wonders how you could move a string dimension to the last position, when it shouldn't have been anywhere else in the first place. But I digress.

Ah ok, understood.
Many thanks again Alan, have a good day!

Toto

Alan,

I always find your posts to be very helpful to me. Some (or a lot) may be over my head, but I generally take something out of your posts.

Thanks,

Steve

osteveo wrote: I always find your posts to be very helpful to me. Some (or a lot) may be over my head, but I generally take something out of your posts.

Thank you kindly, Steve.