As we conclude this exercise, review the values in the report to make sure they are accurate. We provided some SQL code for this in Listing 11-1, but for now we will assume that all are correct and move on to our next topic.
in this exercise, you made changes to the cube using the Cube Structure tab and the Dimension Usage tab.
You then processed the cube and verified that the changes were successful using the browser tab. Next we focus on the other tabs that come with the cube designer.
The Calculations Tab
The Calculations tab enables you to create named MDX expressions, also known as calculated members. Typically these calculated members are used to create additional measures, but they can also be used to create additional dimensional attributes.
An example of an additional measure is acquiring the total price of an individual sale by multiplying the quantity by the price of the product. An additional dimensional member example is combining countries into groups such as combining Mexico, Canada, and the United States into one member called North America.
The Calculations tab consists of three basic sections: the Script Organizer and Calculation Tools panes on the left side of your screen and the script-editing area on the right (Figure 11-31).
Figure 11-30. Browsing the DimAuthors dimension
Figure 11-31. The Calculations tab
Figure 11-32. The Calculations tab toolbar Note
■ The Metadata table in the lower-right side of the Calculations tab will not display the treeview until you have processed the cube at least once. After processing, you may have to use the Reconnect button on the Calcula- tions tab’s toolbar to force a refresh.
Adding a Calculated Member
To create a new member, click the New Calculated Member button, which conveniently looks like a calculator (circled in Figure 11-32). When clicked, the script editing area changes to display in a form view. You can switch between the Form View and the Script View in the script editing area by clicking their respective buttons (circled in Figure 11-31).
Important
■ Make sure you do not delete the CALCULATE command from the Script organizer or from the script-editing area, or your cube will not be able to process correctly.
When the Calculations tab is displaying the Form View, it will look as shown in Figure 11-33. Here you can type an MDX expression into the Expression textbox, define its name in the Name textbox, and determine whether it is going to be part of the measures or a particular dimension in the Parent Hierarchy dropdown box.
Figure 11-33. The Calculations Tab
By default, all new calculated members are created on the Measures dimension. Calculated members in the Measures dimension go by a special name, known as calculated measures. You will note that we are using the term Measures dimension to distinguish it from all of the other dimensions. This may seem confusing at first, but as you will see in Chapter 14, measures are nonhierarchical dimensions. In other words, there is no All level that acts as a parent to all the members of the Measures dimension. Therefore, the parent member dropdown box is grayed out.
Configuring a Calculated Member
To configure your calculated member, choose an appropriate name, determine the parent hierarchy, and define an MDX expression. For example, we are going to create a calculated member that gives us the extended price by multiplying the title price in the titles dimension by the sales quantity from the Measures dimension. So, we
Important
■ The expression we have used in Figure 11-34 will not work as expected! We explain the reason in just a bit.
We set four other commonly used properties in Figure 11-34. The “Format string” property allows you to define how the values will be displayed in client applications like Excel. By default it is blank, but as you can see in Figure 11-34, it can be adjusted using the dropdown box or typing in a pattern.
The Visible dropdown box determines whether the member will be displayed by client applications. Setting it to True can be useful when the calculated member is to be treated as an intermediate value for additional calculations; it is not designed to be used independently.
The “Non-empty behavior” setting allows you to define the value you would like to display if the calculation returns an empty value. This setting determines what will be displayed. For example, multiplying a null Title Price by 5 Sales Quantity returns a null value. Setting the nonempty behavior to SalesQuantity overrides the null and displays the Sale Quantity value of 5.
Note
■ our example begs the question: Why was there a null price for an item, yet the company sold five of them?
it also reminds us that the Sales table in Pubs should have had a Sales Price column to store the price a title sold for, in a given sales event. Sadly, this is not the case, so we will have to work with what we have.
Figure 11-34. Configuring the new calculated measure
The Associated Measure Group dropdown box allows you to determine where the new calculated measure will be displayed within a client application. Although it may seem strange, even after you change this setting and process the cube, you will not see your new calculated member displayed in the Cube Structure tab as you would expect. However, you will be able to see it in the Browser tab, and most Microsoft clients will see it as well.
Calculated Members vs. Derived Members
In our example, we want a measure that multiplies the current price by the sales quantity. You would think that the simple MDX statement in Listing 11-2 would do this for us. After all, it multiplies the TitlePrice for the DimTitles table by the SaleQuantity in the FactSales table.
Listing 11-2. This MDX Expression Produces a Null Value
[DimTitles].[TitlePrice] * [Measures].[SalesQuantity] -- Will be Null due to the context!
Nevertheless, if you use this expression to create a calculated measure, you will find that it does not return the extended sales price because of the context of the expression. Unfortunately, SSAS cannot automatically map the TitlePrice from the DimTitles table to the SalesQuantity in the FactSales table, so you have to help it by creating a derived member in the FactSales table.
Derived members are created in SSAS by modifying the SQL code behind each table in a data source view. This can be somewhat confusing, so let’s review the difference between calculated members and derived members.
Calculated members use MDX expressions to create new members to the measures or other dimensions.
Derived members use SQL expressions to create new members on the measures or other dimensions.
Both are similar, but they each use a different language for the expression, and they evaluate their expressions during different events. In the case of a calculated member, the event that causes the expression to evaluate is when a client application queries the cube or dimension. In the case of a derived member, the event that causes the expression to evaluate is when a cube or dimension is processed.
Listing 11-3 is a SQL statement that can be used to create two additional columns in a data source view. One is a copy of the TitlePrice member of the Titles dimension, and one is a new member that represents the product of the price of a given title by the sales quantity of a sales event.
Listing 11-3. SQL Code for a Derived Measure SELECT
FactSales.OrderNumber , FactSales.OrderDateKey , FactSales.TitleKey , FactSales.StoreKey , FactSales.SalesQuantity -- Adding derived measures
, DimTitles.TitlePrice as [CurrentStdPrice]
, (DimTitles.TitlePrice * FactSales.SalesQuantity) as DerivedTotalPrice FROM FactSales
INNER JOIN DimTitles
ON FactSales.TitleKey = DimTitles.TitleKey
Note
■ We could have created both of these during the ETL process instead of here, but we chose not to do so in order to show you this feature.
Columns can be added to a table in the data source view either by adding a new Named Calculation or by replacing a table completely using a named query. For our example, it is necessary to use a named query, because we must join data from two tables, and named calculations cannot do this.
You can add members from other tables, and even databases, by replacing the table with a new named query, as shown in Figure 11-35.
Figure 11-35. Adding a derived measure using a named query
Tip
■ of course, you must reopen the data source view editor in order to do this. it can be reopened any time by right-clicking the data source view icon in Solution Explorer and selecting View Designer from the context menu.
Once you select this option from the context menu, you will be presented with a query designer. You can either type in the code or let the designer create it for you. Another option is to copy and paste code that has been created and tested in SQL Server Management Studio, as we have done in Figure 11-36.
Clicking OK adds the derived members to the fact table. Now the data source view will display these additional members, as shown in Figure 11-37. When the cube is processed, the SQL statement that represents the FactSales table will run and copy the new DerivedTotalPrice values to the SSAS cube folder.
Figure 11-36. Adding SQL code to the Edit Named Query dialog window
Note that this differentiates calculated from derived members. Derived members are stored in the folders managed by SSAS, but calculated members are never stored. Instead, each time a client executes a query against the cube or dimension, the calculated member expression is evaluated. This can have a performance impact since the aggregations have to be evaluated on each query request.
This might lead you to believe that the derived member is always the best choice since you likely want the best query performance for your end users. But this is not always the case, because sometimes the calculations will be incorrect when you use a derived member instead of a calculated member.
This has to do with the order of operations used to evaluate the expression. In other words, when we multiply a price by the quantity, does the multiplication happen after the summation of the individual quantity values, or does it happen before? As you know from learning mathematics in school, the order of operations directly impacts the results.
In the end, this means you must always test them to verify that the values are correct, whether you are using derived or calculated members. If the results are the same, then you can choose to use a derived member for its increased query performance. But, remember that it will be at the cost of taking longer to process (since the values have to be aggregated and stored during the processing). If the values are different, you need to figure out which is the correct value and use the member that is correct, regardless of performance.
In the upcoming exercise, we create both derived and calculated members for comparison and then validate which one is correct. Before we do that, let’s talk about how you can create a copy of a working cube for testing purposes.
Making a Test Copy of a Cube
Microsoft has made it easy to create a copy of your cube. You can simply right-click the cube in Solution Explorer and choose Copy from the context menu. After that, highlight the Cubes folder, right-click the folder, and select Paste from the context menu to create your copy, and a dialog window appears that allows you to name your new Figure 11-37. The FactSales table now has a derived measure
At this point you have a copy of the cube, but it does not include the derived member if it has been added to the data source view after the cube’s creation. To add the derived member to an existing cube, navigate to the Cube Structure tab and select the folder that represents the fact table where the derived member was created. In our example, we have added the derived member to the Fact Sales table. Therefore, it appears under the Sales measure group. By right-clicking the Sales measure group, we can add the new derived member, as shown in Figure 11-39.
Figure 11-38. Pasting the cube file brings up the “Enter new object name” dialog window
Once you have added the derived member to the cube, the queue must be processed for it to appear. This is logical, because it is the act of processing that creates the derived member and its values on the SSAS server.
Let’s put our knowledge to work in the next exercise by creating both a calculated measure and a derived measure and testing to see whether one or both of them are correct.