in this exercise, we created five dimensions using the Dimension Wizard. At this point, all the dimensions are created but still need additional configurations.
Moving On
In this chapter, you saw how to create an SSAS project, data source, data source view, and five dimensions. We have covered a lot, but we are still just beginning. In Chapter 10, we configure each of the dimensions and then create a cube that uses them.
Figure 9-56. Unchecking the unrelated attributes
LearN BY DOING
in this “Learn by Doing” exercise, you create a project and dimensions very similar to those defined in this chapter. This exercise uses the northwind database. We have included an outline of the steps you performed in this chapter as well as an example of how the authors handled this exercise in two Word documents.
These documents are found in the folder C:\_BookFiles\_LearnByDoing\Chapter09Files. Please see the ReadMe.doc for detailed instructions.
What’s Next?
Getting started with SSAS can be a tricky, but it gets easier the more you are exposed to it! For further study, we
Configuring Dimensions with SSAS
O Marvelous! What new configuration will come next? I am bewildered with multiplicity.
— William Carlos Williams Over the years, we have developed a proven method of creating and configuring SSAS cubes that provides the least amount of pain and the greatest chance of success. We have already begun our process within the previous chapter by preparing for the creation of our SSAS cubes by making our data source, data source view, and dimensions.
In this chapter, we continue this process by configuring SSAS dimensions using the dimension designer.
We also discuss deploying and processing dimension and cubes. Along the way, we verify that the cubes and dimensions are working as expected and what to do when they are not.
Let’s get started with configuring the dimension created in Chapter 9, using Visual Studio’s Dimension Designer.
The Dimension Designer
In Visual Studio, dimensions must be created using the Dimension Wizard, but after each dimension is created, the Dimension Designer is used to complete its configuration. The designer is divided into four tabs (Figure 10-1):
Dimension Structure
•
Attribute Relationships
•
Translations
•
Brower
•
Let’s take a look at each of these and see how they are used in the configuration process.
Dimension Structure Tab
The Dimension Structure tab allows you to add, remove, and group attributes within your dimension. It is divided into three panes:
Attributes
•
Hierarchies
•
Data Source View
•
Let’s take a closer look at each of these.
The Attributes Pane
The Attributes pane allows you to select an attribute and configure it using the Properties window of Visual Studio (Figure 10-2). To edit a property, right-click an attribute and select Properties from the context menu.
This will open the Visual Studio Properties window if it is not already open or bring it to the forefront if it is already open.
As mentioned in previous chapters, dimensions are made of a collection of one or more attributes. Attributes are similar to columns in a database table, with one important exception: each attribute can be associated with one or more columns in a table. For instance, in Figure 10-2, the Properties window shows that the Author attribute is associated with the DimAuthors.AuthorsKey column (used as a key column) and the DimAuthors.
AuthorName column (used as a name column).
Figure 10-1. The Dimension Designer tabs
Table 10-1 describes the most commonly used properties.
Each attribute must have one or more KeyColumns. Most of the time you will have just one column defined in the KeyColumns property. But if a single column cannot uniquely identify one row from another, you can configure this property to use multiple columns, as we will show you later in this chapter.
Each attribute must have a name. We recommend using a name without spaces to avoid rare problems with some client applications. The name should be simple and descriptive. As an example, in Figure 10-3 we elected to change the attribute name Date in the DimTitles dimension to PublishedDate, because it is more explicit.
Figure 10-2. Accessing the Properties window
Table 10-1. Common Attribute Properties
Property Description
KeyColumns A collection of one or more columns uniquely identifying one row from another in the dimension table (for example, 1, 2, or 3)
Name The logical name of an attribute
NameColumn The values that are displayed in the client application when a particular attribute is selected (for example, Red, Green, or Blue)
Type The type of data the attribute represents (for example, day, month, or year)
Each attribute uses the NameColumn property to determine which values are displayed to a client application. If you do not select a column, SSAS will use the KeyColumn by default. If this happens, the results will display integer values instead of names. For example, if someone creates a report showing the quantity of sales based on published dates, that report will display the date key (such as 1) instead of the actual date (such as 01/01/2012). As you might imagine, this renders the report useless. Therefore, be sure to set a NameColumn property where appropriate. For example, in Figure 10-3 we have configured it to use the DateName column.
In Chapter 9 we discussed how most attributes types are configured as regular. A special few, such as date attributes, are set to other predefined types, such as Date, Month, or Year. If you did not set the attributes type in the Dimension Wizard, you can change it in the Properties window as shown in Figure 10-3.
The Hierarchies Pane
When you first create a dimension, each attribute is independent of each other, but user hierarchies allow you to group attributes into one or more parent-child relationships. Each relationship forms a new level of the hierarchy and provides reporting software with a way to browse data as a collection of levels-based attributes.
Creating Hierarchies
Figure 10-3. Common setting in the Properties window
In Figure 10-4 you can see that the DimAuthor’s dimension contains the Author Key, Author Id, and Author State attributes, renamed to Author, AuthorId, and AuthorState.
SSAS always provides a default, invisible hierarchy for each attribute consisting of two levels. In this default design, each individual attribute of the dimension is considered a child attribute of an All attribute, as illustrated in Figure 10-5. The All level contains only one member called, well, All.
The All member forms the root-level value of the hierarchy. Once this is set, the All level represents the total of all the members of a group (Figure 10-6). It is simply a way of organizing information. Microsoft recommends that you define user hierarchies when it makes sense to do so.
Figure 10-4. The DimAuthors attributes
Figure 10-5. The default attribute hierarchy
In our example, we grouped authors by states by dragging and dropping the AuthorState attribute into the Hierarchies pane and then dragging and dropping the child-level attribute, Author, beneath it (Figure 10-7). Once this is set, reporting software like Excel can easily browse the authors grouped by state.
Figure 10-6. Using a user hierarchy in Excel
Each dimension can have many hierarchies, and the implied individual hierarchy exists even after you create your own user-defined attribute hierarchies. In our example, we have three attributes and have added a user-defined hierarchy, so we now have four hierarchies total. Figure 10-8 is a conceptual example of this concept.
The attributes AuthorID, Author, and AuthorState still form their own hierarchical parent-child relationship with the All attribute. Microsoft calls these attribute hierarchies in contrast to the term user hierarchies.
Microsoft recommends hiding attribute hierarchies if you will not use them independently in your reporting applications. They can be hidden by setting the AttributeHierarchyVisible property to False, as shown in Figure 10-9.
Figure 10-8. The DimAuthors dimension including the new user-defined attribute hierarchy Figure 10-7. A new user-defined attribute hierarchy
Now, in Microsoft Excel, the AuthorState and Authors attributes will no longer be displayed independently of the AuthorState.
Not all client applications hide the individual attributes when this setting is applied. This may seem strange, but because the attribute hierarchy is marked only as hidden, it is not deleted (Figure 10-10). Since some software does not check to see whether the property is set to True or False, the individual attribute may appear in some reporting applications.
Note
■ Although microsoft recommends hiding the attribute hierarchies after you have created a user-defined hierarchy, it is not always in your best interest to do so. often, report builders want more options instead of less. we configure the Authors dimension to hide the Authors attribute in the next exercise, and in Chapter 15 we demonstrate the impact that this choice has in microsoft Excel.
Now that the hierarchies are defined, let’s configure them.
Configuring Hierarchies
Table 10-2 describes the most common properties for user-defined hierarchies.
Figure 10-10. Hidden attribute hierarchies are invisible to only some client applications Figure 10-9. Hiding attribute hierarchy
No matter what the settings, attribute values must have some way of determining which child value belongs to which parent value, or the user-defined hierarchy will not work. This causes problems is when dealing with dates, because the child value of January is duplicated under the first quarter of one year as well as the first quarter of another, thus giving January two parents.
When situations like this occur, the error displayed while processing the dimension states, “A duplicate key has been found,” as shown in Figure 10-11.
This issue can be resolved by uniquely identifying the parent of January. Let’s discuss two ways of making this distinction.
The first method of distinguishing one value of January from another is by concatenating additional text to the word January, such as the year. This will give each a unique value, eliminating duplication. With this method the values will no longer all be “January”; they will be “January 2000,” “January 2001,” and so on.
If concatenating the year with the month is inconvenient for whatever reason, the second method is to uniquely identify January’s parent using a composite key. With this method, January will be identified by both its quarter and its year. Each value has a unique parent value that defines its individuality.
To set a composite key for an attribute, access the Properties window and modify the KeyColumns property by clicking the ellipsis (…) button that magically appears when you click the Properties window (Figure 10-12).
Figure 10-11. A typical error message when duplicate keys are found Table 10-2. Common Attribute Properties
Property Description
AllowDuplicateNames Allows an attribute member name to appear more than once under the same parent attribute. When set to True, a parent can have two children named Bob. This is a bad idea most of the time, but if it could conceivably happen in your data, you can leave this set to True, which is the default.
MemberKeysUnique When set to Unique, the key values, like 1, 2, or 3, must not repeat in the user- defined hierarchy. For example, this setting would cause an error if the Author attribute has a key value of 1 and the AuthorState attribute has a key value of 1. The default setting of NotUnique is the most common selection.
MemberNamesUnique When True, the member name values must be unique. For example, setting Mexico at the city level with Mexico at the country level causes an error. The default setting of False is the most common selection.
Name The logical name of the user-defined hierarchy and is displayed in most client software.
Clicking the ellipsis button launches the Key Columns dialog window (Figure 10-13); columns can be added and removed using the right and left arrow buttons. Additionally, columns can be moved up or down by using the arrow buttons on the left side of the dialog window. Be sure to move the parent column to the top followed by each level of the hierarchy in its proper order. In our example, the proper order for the Month attribute is the year, followed by the quarter, followed by the month, as shown in Figure 10-13.
Figure 10-12. Modifying the KeyColumns property to use a collection
Figure 10-13. Selecting multiple KeyColumns
You now have a lot of new information to think about. Let’s put your knowledge to work by configuring the dimensions created in the previous chapter.
eXerCISe 10-1: CONFIGUrING KeYS, NaMeS, aND hIerarChIeS
In this exercise you will start configuring your dimensions by verifying or changing the names, keys, and hierarchy properties.
Note: If the solution from the previous exercise is closed, open Visual studio by clicking the start button and navigating to All Programs ➤ Visual studio 2010. Right-click this menu item, select Run as Administrator, and then answer Yes to close the uAC. If did not complete the project in the previous chapter, you can find our completed version in the
C:\_BookFiles\Chapter09Files\Chapter09_Complete\PublicationsIndustries folder.
Configure the Authors Dimension we begin by configuring the Authors dimension.