*Sucks teeth like a mechanic*

Oooookay. As ever with this type of thing the answer is definitely "it depends".

I would never completely ignore them though (particularly 2, 4 and 6 - if the developer tells you "it's fine" for these please feel free to assault them with a snooker cue).

I shall share with you my thoughts on all of these warnings, based upon all of the reading I've done plus all of the times I've dealt with them over the years. People may disagree and that's fine as they may have read different things, had different experiences, be an annoying contrarian etc.

1. Avoid visible attribute hierarchies for attributes used as levels in user-defined hierarchies.

This is from a "best practice" that states that if an attribute is a member of a defined hierarchy then it shouldn't be available as a selection on its own.

There's a kind of logic to this; you don't want an overcrowded dimension and most client tools will allow a user to hide parts of a hierarchy. In the real world though

you might have, for example, a date hierarchy that goes Year > Quarter > Month > Day. Then you might have a user that only ever cares about looking at

measures by month. Asking them to hide the rest of the hierarchy levels in the client tool may cause you to lose them from day one (getting users onside is soooo important

in a DW/OLAP implementation, not to say that you should acquiesce to all of their desires, but that's a discussion for another day).

So yeah, tidy up where possible but not at the sake of usability.

2. Define attribute relationships as 'Rigid' where appropriate.

This depends on what sort of data is in the dimension. Relationships that are "Rigid" do not change - an example of this is a Calendar Date hierarchy as mentioned above

(Year > Quarter > Month > Day). 1st April 2015 will always be in the Month of April in the 2nd Quarter in the Year 2015 (in a Calendar, not Fiscal, hierarchy) so it can be

defined as "Rigid". Rigid relationships can lead to performance improvement. Examine the dimensions that are giving you this warning. Are the relationships Rigid? If not leave

them as Flexible as defining a relationship as Rigid when it is not will result in a processing error when doing a Process Update.

3. Create hierarchies in non-parent child dimensions.

An easy one; Do your dimension attributes form a logical (one-to-many) hierarchy? If so then put them in a user defined hierarchy for improved usability. If not, ignore.

4. Do not ignore duplicate key errors. Change the KeyDuplicate property of the error configuration so that it is not set to IgnoreError.

This is an indicator that a conscious choice has been made by the developer to turn off the defualt error configuration (which doesn't ignore key duplicates). It can mean

that they just haven't bothered to properly set up the attribute key columns to be unique or it could be a workaround for an underlying issue with the data itself. Seek

to resolve this by setting up appropriate attribute key columns in the first instance. If you have user hierarchies and the key columns are not set up correctly then the

hierarchy may not display properly. If this is not possible then fix how the data is consumed by the cube so there are no duplicates.

More on key columns here: http://www.bidn.com/blogs/DevinKnight/ssis/1887/ssas-understanding-keycolumns-dimension-property

5. Use numeric key columns for attributes with 500000 or more members.

This is a question of design. What specifically has more than 500000 members? Is it really useful to have this as an attribute to "slice" the data by? Really? Have you

recently sustained a head injury? Joking aside, this might just mean that the key column of the dimension is not numeric (it probably should be but this is not the place to

get into database design....) or it could be that the dimension size is a bit silly and rather useless for an OLAP solution.

6. Attribute relationships do not exist between one or more levels of this hierarchy. This may result in decreased query performance.

Another easy one. Create the attribute relationships or you're in for performance problems 🙂 More here: http://www.mssqltips.com/sqlservertip/3414/sql-server-analysis-services-attribute-relationships/

7. The ' Blah 47' and ' Blah 47' measure groups have the same dimensionality and granularity. Consider unifying them to improve performance.

What it says on the tin....if these dimensions can be sensibly unified then do it, otherwise ignore.

I hope this helps. Any follow up questions then give me a shout.