SSAS many-to-many relation between dimension levels in a hierarchy using a ragged hierarchy

1
votes

I've got a question about how to create one dimension in SSAS that contains a hierarchy built from two dimensions.

I have a fact-table: sales

and a many-to-many relation between two dimensions: customers bridgecustomersTerritory territory

And the Territorydimension is at the moment built as a ragged hierarchy containing a ID and a parentID.

This works fine if i use the Territory dimension and Customer dimension apart from eachother as dimensions.

But i would like to add the customer at the bottom of the territory hierarchy Is this even possible with the setup that i've got right now?

If i change the Territory to a "normal" hierarchy with a solid number of levels, would that help?

//Kriss

1
many-to-manyssashierarchydimension

1 Answers

0
votes

You cannot have attributes from two dimensions in one hierarchy. And as you use a many-to-many relationship between customer and territory, I assume you need it as a customer can be located in several territories, and there is obviously more than one customer per territory.

But why do you want to have customers and territory in one hierarchy? You can have them in separate hierarchies, and still use them in one query. In MDX, and hence in most client tools accessing Analysis Services that I know, you can drag more than one hierarchy to the rows or columns.

UPDATE To some extent, I can understand the requirement to combine things. In a client tool that I developed, we do not expose the dimensions to the user at all, we are just using the display folders of the attributes/hierarchies. In this way, we can show attributes/hierarchies close together even if they technically need to be in different dimensions due to the modeling requirements. But they are still separate attributes/hierarchies, and users work well with this.

Yes, if you would want one hierarchy, you would need to integrate the customers into your territory dimension, taking care that you break down a customers measures like sales correctly between the different territories. And if you can do that easily, maybe there is no need for a many-to-man relationship at all.