Introduction to MSSQL Server 2000 Analysis Services: Manage Distinct Count with a Virtual Cube - Page 6

February 14, 2005

Customer Sales

After we create a virtual cube, we must process it before client applications can browse it. The necessary internal links to the specified dimensions and measures in the underlying cubes are established through processing the virtual cube. While the linking operation that is involved in processing is typically quick in itself, we need to keep in mind that initialization of processing of our virtual cube will automatically trigger the processing of any underlying cubes that themselves require processing. This can add significant time to the update, and needs to be included in planning when taking the virtual cube route. Ideally, the underlying cubes will be preprocessed, but this is certainly not a requirement, and may not even be the best strategy, in certain situations.

This, the last step of the Virtual Cube Wizard, presents us with the option to process the virtual cube now, or at a later time. The Finish the Virtual Cube Wizard dialog, with our selections, appears as depicted in Illustration 27.

After clicking Finish above, we see that the Process dialog appears just as it did when we processed the DISTINCT_CUSTOMER cube earlier, logging the significant processing events, then rapidly presenting a green Processing Completed Successfully message at the bottom of the dialog, as shown in Illustration 28.

The Process dialog closes, and the Virtual Cube Editor (a customized version of the Cube Editor, which has no Schema tab, as does the standard Cube Editor) appears, as partially depicted in Illustration 29.

We are returned to the main Analysis Manager console window.

We see the Customer Sales cube appear, as shown in Illustration 30.

Analysis Manager identifies virtual cubes with the "double" cube icon, as circled in red above.

Verification with MDX

Let's return to the MDX Sample Application, and resurrect our earlier query to execute it against the new virtual cube, taking the following steps:

The MDX Sample Application window appears.

The query appears in the Query pane.

The MDX Sample Application - Metadata tree (left section of the Metadata pane) should resemble that partially depicted in Illustration 31, complete with the measures from both physical cubes combined in the Customer Sales virtual cube displaying in the Metadata tree (left section of the Metadata pane).

We will make a couple of modifications to the query, and then execute it against the new virtual cube.

--ANSYS32-2 Distinct Customer Dataset with Isolated DISTINCT Cube

MEMBER
       [Measures].[Distinct Customers]
      AS
         'COUNT(CrossJoin({[Unit Sales]}, 
             Descendants ([Customers].CurrentMember, 
                [Customers].[Name])), ExcludeEmpty)'

[Sales]

[Customer Sales]

The query is now pointed toward our new virtual cube. The modified query appears as shown in Illustration 32.

The results dataset appears as partially depicted in Illustration 33.

We notice, after clicking Run Query, that the query runs and data is returned appreciably faster than the initial query we created in the first section of this article. This is because only the new DISTINCT_CUSTOMERS cube is subjected to the intensive portion of processing required to return the detailed set needed by the calculations we have put into place. The DISTINCT_CUSTOMERS cube, with only one measure, is much smaller than the Sales cube, so less processing is necessary to render the contextually important distinct count within our query. As we see, the results are identical to those of our initial query, with all that remains being to format the Avg Sales per Customer calculated measure, if we choose to do so.

There are more actions we can take within our current scenario, where we created the virtual cube, containing the DISTINCT_CUSTOMERS cube, which isolates the Distinct Count, to further increase performance. In our next article, we will examine a further step to leverage the solution we explored in this article to provide a higher degree of performance enhancement within the context of using distinct counts.

Conclusion

In this article, we extended our previous introduction to DISTINCT COUNT, and examined one approach to its efficient use within our applications. We focused upon the optimization of DISTINCT COUNT through the isolation of the distinct count measure into a separate cube, and showed how this "best practice" can help us to achieve our objectives with enhanced performance.

As in the other articles of our series, we set the stage by providing a hypothetical business requirement. We then examined a way to meet the requirement with an MDX query that contained DISTINCTCOUNT() in a calculated member, and that used a single cube as a data source. We noted query performance, and set about to improve it via the creation of a separate DISTINCT_CUSTOMERS cube, which we designed to house the distinct count attributes of our solution.

We then "married" the DISTINCT_CUSTOMERS cube to the initial cube data source through the creation of a virtual cube. Finally, we targeted the virtual cube with the query we had set out to improve, as a means of confirming that performance can be enhanced through the forehanded use of an isolated distinct count cube in scenarios with similar business requirements.

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

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