Why does dimensionality depend on the attribute in MDX

Question

For the life of me I cannot figure out why MDX defines dimensionality per-attribute on a dimension rather than on the key. Perhaps I'm misunderstanding something here, but it seems like a very odd way to do this if I'm understanding things correctly. Let's say I have the following data:

Person

• ID (Key)
• Name
• Age

And I have some data like this: [('Tom123', 'Tom', 15), ('Brad456', 'Brad', 16).

Now, why I could select the two users the following two ways:

{Person.Name.Tom, Person.Name.Brad}

Or:

{Person.ID.Tom123, Person.ID.Brad456}

But not the following way:

{Person.Name.Tom, Person.ID.Brad456}

Yet all three use the same 'dimension' and even 'dimensionality' since all three ways uniquely address the same two Person entities!

This seems so odd to me, in that they are both using the same 'dimension' and 'dimensionality' and should be able to use the Key for that dimension rather than thinking each attribute is unique. Why is this so? Or, am I misunderstanding something in this.

If we use this image:

Why would it matter if we address the individual cube (tuple) by doing: {Product.TV, Geography.Asia, Time.Q1} or doing {Product.TV, Geography.Asia, Time.Quarter One}. They're just two ways of doing exactly the same thing but yet MDX considers them different dimensionality (?).

Answer 1

That is an excellect question.

Yet all three use the same 'dimension' and even 'dimensionality' since all three ways uniquely address the same two Person entities!

This seems so odd to me, in that they are both using the same 'dimension' and 'dimensionality' and should be able to use the Key for that dimension rather than thinking each attribute is unique. Why is this so? Or, am I misunderstanding something in this.

So for any language, the syntax is checked before anything else. The case you are refering is the only instance where Dimensionality can be ignored. But it will not be wise for a language to go evaluate the data first(in terms of SSAS and MDX its called AttributeID). Secondly this will be more confusing to a user. building on your example

{Person.Name.Tom, Person.ID.Brad456}

lets we have 100 people in Newyork, so as per your logic the following the set will be {Person.City.Newyork}, then MDX will replace all 100 IDs. This would prevent MDX from using Aggregates, which is the biggest advantge of a CUBE. Mostly the queries sent to a Cube are targeted towards summarized data. Most queries in MDX would need data of entire NEWYORK rather then a single person in NEWYORK

So to summarize, the compile time will increase and the Aggregates will not be useable.