Analysis Services: Understanding "Dimension Usage"

I'm running the "SQL Server Analysis Services Tutorial" (see, using Visual Studio 2008 against the AdventureWorks database in SQL Server 2008.  I'm finding the "Attribute Relation" tab within the cube design to be extremely baffling and frustrating.  I would appreciate a salient description of the connection between creating a hierarchy and setting Attribute Relationships.  Specifically, I am getting warning messages that I do not understand: "Attribute relationships do not exist between one or more levels of this hierarchy.  This may result in decreased query performance."; "Avoid visible attribute hierarchies for attributes used as levels in user-defined hierarchies."; and "Set at least one of the attribute types to match the 'Time' dimension type."  I've attempted to change the Attribute Relationships so they match the levels hierarchy (Year/Semester/Quarter/Month/Date), which results in errors and an application that won't deploy.  

Since an application that deploys with warnings is a far lesser evil  than one that won't deploy, I've chosen not to perform those procedures that have me resetting Attribute Relationships.  I've tried resolving the question using help screens, but I get definitions for people who already know what they're doing: without concrete examples, these descriptions are worthless.  I would really appreciate a plain-English description of "Dimension Usage", perhaps including a link to a simple example of an Analysis service that deploys with no warning messages.  Im just learning about Analysis Services, and the "Attribute Relationships" feature is proving to be insurmountable stumbling block.

Many thanks, ~Peter Ferber
Who is Participating?
rob_farleyConnect With a Mentor Commented:

If you have cities and countries, such as:

Country      City
US    New York, NY
UK    London, GB
CA    London, OT

"London, GB" can only be in one country, so it makes sense to have an attribute relationship set up between them. It means that the system never has to wonder how many sales there were for "London, GB" in the US. This is where the performance gain comes in.

However, if you just had "London" as your city, then you can't set up a relationship between city and country, because London could be the UK one or the CA one.

So a lot of the ideas behind attribute relationships are affected by the data that's in your warehouse. They're worth having, but if your data doesn't suit, then just put up with the warnings.

Hope this helps...

PeterFrbAuthor Commented:
I went on to study Attribute Relationships, and the key information that you don't mention here is the way to set up Key Columns and the Name column.  Conceptually you're correct, but without that information you've given, although correct, is not of much practical use.  It's still good information, though, and thank you.
Ah - I was assuming that you had a very denormalized environment, at which point the attribute has its own key and name. And then, if your city is just called "London", and you make no differentiation between one London and another, you can't really do attribute relationships in the same way.

In a Snowflake arrangement, where you actually have a CityID, then you will almost certainly want to use a different Key and Name column, and are fully able to leverage attribute relationships too.


Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.