Introduction to Attribute Relationships in MSSQL Server Analysis Services - Page 3

December 23, 2008

Best Practices and Other Considerations Surrounding Attribute Relationships

Best practices dictate that, in designing attribute relationships, we 1) create the most efficient dimension model that 2) best represents the semantics of the business that it represents. Perhaps the most critical element of success we can seek in doing so is a deep familiarity with the organization’s data, together with an extensive understanding of the business requirements that the data must support. Defining attribute relationships incorrectly can cause invalid query results, among other maladies, within our Analysis Services databases.

Anytime the data underlying our Analysis Services UDM support the definition of unique attribute relationships, we should use the Attribute Relationships tab of Dimension Designer to define these unique relationships.

Any attribute that has an “outbound” relationship must have a unique key relative to its related attribute. In other words, a member in a source attribute must identify one - and only one - member in a related attribute. For example, consider the relationship, City -> State-Province that we used in examples earlier: in this relationship, the source attribute is City and the related attribute is State. The source attribute is the “many” side and the related side is the “one” side of the many-to-one relationship. The key for the source attribute would be City + State. A visual example how this key is established in the Customer dimension of the Adventure Works cube is depicted in Illustration 5.

We noted earlier that attributes within a given dimension are always related either directly or indirectly to the key attribute. We also noted that, when we define a dimension based on a star schema (again, typically a scenario where all dimension attributes are derived from the same relational table), an attribute relationship is automatically defined between the key attribute and each non-key attribute of the dimension. Moreover, when we define a dimension based upon a snowflake schema (a scenario where dimension attributes are derived from multiple related tables), an attribute relationship is automatically defined as follows:

• Between the key attribute and each non-key attribute bound to columns in the main dimension table.
• Between the key attribute and the attribute associated with the foreign key in the secondary table that links the underlying dimension tables.
• Between the attribute associated with the foreign key in the secondary table and each non-key attribute bound to columns from the secondary table.

We noted earlier that we might want to modify these default attribute relationships, and cited but one example. Reasons might include the following:

• To define a natural hierarchy;
• To define a custom sort order; or
• To define dimension granularity based upon a non-key attribute.

Natural Hierarchy Relationships

A hierarchy is known as a “natural” hierarchy when each attribute included in the user-defined hierarchy has a one-to-many relationship with the attribute immediately below it. For example, consider a Customer dimension (in this case, a “slimmed down” version of the Customer dimension table that underlies the sample Adventure Works cube), based upon a relational source table with these columns:

• CustomerKey
• CustomerName
• Age
• Gender
• Email
• City
• Country
• Region

The corresponding Analysis Services dimension has seven attributes:

• Customer (based on CustomerKey, with CustomerName supplying member names)
• Age
• Gender
• Email
• City
• Region
• Country

Relationships representing natural hierarchies are enforced by creating an attribute relationship between the attribute for a level, and the attribute for the level there under. This specifies a natural relationship and potential aggregation within Analysis Services. In our “slim version” of the Customer dimension, a natural hierarchy exists for the Country, Region, City, and Customer attributes. The natural hierarchy for {Country, Region, City, Customer} is described by adding the following attribute relationships:

• The Country attribute has an attribute relationship to the Region attribute.
• The Region attribute has an attribute relationship to the City attribute.
• The City attribute has an attribute relationship to the Customer attribute.

As we see in other articles of this series, we are not limited to working with natural hierarchies in Analysis Services. We can also create navigational structures via user-defined hierarchies (which represent ad hoc, reporting hierarchies) whose bases reside in logical hierarchical relationships versus associations that exist in the data.

For example, we might create a user-defined hierarchy based on {Age, Gender}. The ultimate information consumer would not see any difference in how the natural and user-defined hierarchies behave, although performance benefits would accrue to the natural hierarchy in terms of aggregating and indexing structures (invisible to the consumer, in this case) based upon the natural associations within the source data.

We will examine the many properties, and their settings that we use in constructing attribute relationships in next month’s column, where we will gain hands-on exposure to these in a working environment.

Conclusion

In this article we introduced attribute relationships in Analysis Services, extending the examination of the dimensional model that we began in Dimensional Model Components: Dimensions Parts I and II. In a manner similar to previous articles within this subseries, we overviewed the general concepts involved and looked ahead to our next article, where we will perform a hands-on, detailed examination of the properties that support attribute relationships existing within a working sample environment. Our focus, we stated, was upon the appropriate use of attribute relationships in providing support for the selection and delivery of enterprise data in a more focused and consumer-friendly manner, without the unwanted effects of system performance degradation, and other unexpected or undesirable results that can accompany the uninformed use of this component of the conceptual model.

Our introduction included a review of the nature of attribute relationships, and their purposes / uses within a containing dimension within Analysis Services, as well as their role in helping to meet the primary objectives of business intelligence. We performed an overview of attribute relationships, and a discussion of their default configurations, and how we can improve upon those configurations to enhance overall processing performance. We then moved into a discussion of other best practices and general considerations surrounding attribute relationships. Finally, we looked ahead to the next article of this series, where we will examine the individual properties underlying attribute relationships, and conduct a review of the respective settings associated with each property, basing our exercise upon the review of a representative dimension attribute within our sample UDM.

About the MSSQL Server Analysis Services Series

This article is a member of the series Introduction to MSSQL Server Analysis Services. The monthly column is designed to provide hands-on application of the fundamentals of MS SQL Server Analysis Services (“Analysis Services”), with each installment progressively presenting features and techniques designed to meet specific real-world needs. For more information on the series, please see my initial article, Creating Our First Cube. For the software components, samples and tools needed to complete the hands-on portions of this article, see Usage-Based Optimization in Analysis Services 2005, another article within this series.

» See All Articles by Columnist William E. Pearson, III

Discuss this article in the MSSQL Server 2000 Analysis Services and MDX Topics Forum.