Database Journal
MS SQL Oracle DB2 Access MySQL PostgreSQL Sybase PHP SQL Etc SQL Scripts & Samples Tips Database Forum Rss Feed

» Database Journal Home
» Database Articles
» Database Tutorials
MS Access
SQL Scripts & Samples
» Database Forum
» Slideshows
Free Newsletters:

News Via RSS Feed

Rss Feed

Database Journal |DBA Support |SQLCourse |SQLCourse2

Featured Database Articles


Posted Dec 23, 2008

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

By William Pearson

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.

NOTE: We will examine detailed settings that support existing attribute relationships within the sample Adventure Works cube in the hands-on practice section of the article that follows this one.

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.

Establishing a Unique Key for the City Attribute, Relative to the State-Province Attribute
Illustration 5: Establishing a Unique Key for the City Attribute, Relative to the State-Province Attribute

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.


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.

MS SQL Archives

Latest Forum Threads
MS SQL Forum
Topic By Replies Updated
SQL 2005: SSIS: Error using SQL Server credentials poverty 3 August 17th, 07:43 AM
Need help changing table contents nkawtg 1 August 17th, 03:02 AM
SQL Server Memory confifuration bhosalenarayan 2 August 14th, 05:33 AM
SQL Server Primary Key and a Unique Key katty.jonh 2 July 25th, 10:36 AM