TM1 Forum

I'm a TM1 newbie and just coming off the heels of another post where I was experiencing an "cell type is string" error (see link below) related to how I defined the Element Types for each Element in my Dimension. Since that post it dawned on me that I may not be understanding what an Element truly is in the world of TM1 and just what truly is meant by Element Type.

Using an example, assume you have a Dimension named "GL Accounts" with four Elements: "Revenues", "COGS", "Labor", and "Expenses".

As you can see, all the Elements in my Dimension are "string" data types, so intuitively I thought I had to set the Element Type to "string" as well. But, I learned instead that I had to define my Element Type as "numeric" in order to avoid the error I was experiencing. And, I learned (now) that Element Type "refers to the type of data to be stored in the cell" and "does not have anything to do with the name of the element". Or, in other words, it defines the data type for an associated data value stored in a cube cell and not the type for the Element itself.

Given that, here are where my TM1 questions come in....

1). Why isn't Element Type associated with the Element's data type?
2). What is an Element really?
3). What is the distinction between Elements and Element Names?

Intuitively I would have defined

• Elements as the items or records in a Dimension.

• Element Names as the value for the Element itself.

• Element Types as the data type for the Element (now I know that is not true).

Maybe cell data values are Elements also? I say that because if data values stored in cells are considered Elements too, then Element Type needing to be numeric makes since.

Any help or reference to a resource that defines these terms technically would be great appreciated.


Link to other post
http://www.tm1forum.com/viewtopic.php?f ... 959#p66959

ptownbro wrote: ↑Sat Sep 16, 2017 8:07 pm Given that, here are where my TM1 questions come in....

1). Why isn't Element Type associated with the Element's data type?

I know that Lotsa isn't out at Jungfraujoch at the moment because if he was then the scream would be echoing off the mountains loudly enough to be heard from here. He explained this clearly. You even quoted his explanation.

lotsaram wrote: ↑Sat Sep 16, 2017 8:59 am Note the "element type" refers to the type of data to be stored. It does not have anything to do with the name of the element. All element names are strings.

Let's go back to what you said above.

ptownbro wrote: ↑Sat Sep 16, 2017 8:07 pm Using an example, assume you have a Dimension named "GL Accounts" with four Elements: "Revenues", "COGS", "Labor", and "Expenses".

As you can see, all the Elements in my Dimension are "string" data types,

No. They. Aren't.

Elements are not data. They are metadata. They describe data. They tell you where the data lives within a cube. They tell you what the data represents. They are not, themselves, data.

It's like saying "My name is "ptownbro" which is a string, so clearly I am a string".

Or, if you prefer a relational explanation, ask yourself this question; what is the data type of a field name in a table?

No, not the field, the field name?

Yes, it's a string. Can it ever be anything other than a string? No. Does the type of the name have any effect on what the field can store? No. So why even consider it as having a data type?

Now ask yourself this question; what is the data type of an element name? Repeat the rest of what I wrote above and you'll get to the same destination.

ptownbro wrote: ↑Sat Sep 16, 2017 8:07 pm 2). What is an Element really?

For N elements, and for S elements in the last dimension of a cube, it is either:
- a location where a value is stored for a given dimension; or
- the location of a value which is calculated by rules.
For a C element it's the location of a value which is calculated by consolidations.

ptownbro wrote: ↑Sat Sep 16, 2017 8:07 pm 3). What is the distinction between Elements and Element Names?

What's the distinction between the person who uses the user name "ptownbro" and the string "ptownbro"? What's the distinction between the first worksheet in a default Excel workbook, and the string "Sheet1"? What's the distinction between the 4th planet from the sun, and the string "Mars"? In every case, as with the answer to this question, one is the object, the other is text that merely names that object.

ptownbro wrote: ↑Sat Sep 16, 2017 8:07 pm Intuitively I would have defined

• Elements as the items or records in a Dimension.

• Element Names as the value for the Element itself.

• Element Types as the data type for the Element (now I know that is not true).

The biggest favour you can do yourself is to stop trying to see multidimensional storage as analogies of the relational world. Yes, analogies do exist; a cube can be seen as analogous to a table, a dimension to some extent can be seen as analogous to a field, but the analogies are imperfect and can easily lead to confusion, like the way the measure concept spun your head around. You'll be far better off treating it as something new that you have to learn.

ptownbro wrote: ↑Sat Sep 16, 2017 8:07 pm Maybe cell data values are Elements also?

They are not. Values are values. Elements, dimensions and cubes are all metadata, which define the location of values.

You're encountering the hardest part of OLAP systems which is that they do not work the way you would intuitively think they would coming from an Excel or relational database background. Your brain wants to relate (pun intended) back to those mental models, and it just will not fit. It's a steep learning curve, and it's only going to get worse when you start learning to use rules.

Dimensions are just a list of elements. Each element name isn't the data you're storing, it's just a label. The element type describes which kind of data you plan to store BUT, importantly, the element type is only relevant if it's the last dimension in a cube (with caveats best not delved now). If a dimension appears earlier, the element types are irrelevant/ignored.

Matt

Thanks again Alan for the response. I really appreciate you taking time to explain and help. I believe I get it.

While both you and Matt warned against thinking of it in similar terms as relational databases, what finally made it click for me was the comparison between Fields in a Table and Elements in a Dimension. With that it makes sense that the Field/Element would have a Field Name/Element Name (which obviously will always be string but does not matter). Then, what you are setting is the Field Type/Element Type which would be "Numeric" or "String" to define the data type of the associated data. In the case, of my example, I'd like set the Element Type (Field "data" Type) to "Numeric" because that is what the associated data's data type would be.

A note about that comparison though which may help others coming from my background

Alan Kirk wrote: ↑Sun Sep 17, 2017 9:54 pm The biggest favour you can do yourself is to stop trying to see multidimensional storage as analogies of the relational world.

mattgoff wrote: ↑Mon Sep 18, 2017 5:28 pm You're encountering the hardest part of OLAP systems which is that they do not work the way you would intuitively think they would coming from an Excel or relational database background.

Actually, I was not comparing to relational databases. Instead, I was comparing to my experience with SQL Server Analysis Services (SSAS) which I'm sure you know is Microsoft's competing OLAP/multi-dimensional tool to TM1. With those with experience in that world, you can (hopefully) understand where my confusion came from as it pertains to TM1.

To briefly explain...

In the world of SSAS, they conceptually structure Dimensions with Attributes and each Attribute with belonging Members (which are akin to Elements in TM1). To continue, those Attributes have an Attribute Data Type which are dependent on the data type of the Members.

Following my original example, if we have a Dimension named "Accounts", with an Attribute named "Account Name", with Members (aka Elements) "Revenues", "COGS", "Labor", and "Expenses"... you would set the data type of the Attribute as "String" because the Member data types are "String". Then, you'd have a separate Measure (which effectively holds the data) that you would set the Measure Data Type as "Numeric".

So, that where I was getting that concept from... the SSAS concepts of OLAP data structures versus the TM1 concepts of OLAP data structures.

Anyway,.. great stuff and again thanks for the help.


By the way, ... One thing to clean up to not confuse others following with a similar question:

Alan Kirk wrote: ↑Sun Sep 17, 2017 9:54 pm Elements are not data. They are metadata. They describe data. They tell you where the data lives within a cube. They tell you what the data represents. They are not, themselves, data.

Some of this is not true or misleading. Metadata is data. It's data that describes other data... but it is data. So if you describe Elements as "metadata", but say "Elements are not data" - that would a contradiction. Elements would be data that describe other data.

ptownbro wrote: ↑Wed Sep 20, 2017 2:37 am By the way, ... One thing to clean up to not confuse others following with a similar question:

Alan Kirk wrote: ↑Sun Sep 17, 2017 9:54 pm Elements are not data. They are metadata. They describe data. They tell you where the data lives within a cube. They tell you what the data represents. They are not, themselves, data.

Some of this is not true or misleading. Metadata is data. It's data that describes other data... but it is data. So if you describe Elements as "metadata", but say "Elements are not data" - that would a contradiction. Elements would be data that describe other data.

That's semantically correct, but a functionally dangerous way for new TM1 users to think. Look at the second and third tabs of a TI process. They are separate, and named the way they are, for a reason. If you fail to make a distinction between metadata and data (even if it is a distinction that may not exist inside a dictionary) you have the potential to faceplant into a metaphorical concrete floor when you try to write a process that both updates metadata (the structure that stores the values) and the data (the values inside the cube).

It's like describing the structure of an atom as being like a solar system to someone who is completely new to atomic theory. Is it pedantically correct? No. Is it the easiest way to begin to get the student's head around the subject? Yes. It's just the same as regarding "data" as being only the values that go into the cube.