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.

12. Ensure that the Process Now radio button is selected (the default).

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.

Illustration 27: The Completed Finish the Virtual Cube Wizard Dialog

13. Click Finish.

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.

Illustration 29: The Virtual Cube Editor (Compressed, Partial View)

15. Select File --> Exit from the Virtual Cube Editor main menu to close the Virtual Cube Editor.

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).

Illustration 31: The MDX Sample Application Window (Compressed View)

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

7. Change the first line of the query (the comment line) to the following:

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

8. Select File -> Save As ...

9. Save the query as ANSYS32-2, to protect ANSYS32-1.

10. Remove the following (the first calculated member definition within the WITH clause)

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

Illustration 32: The Modified Query

12. Execute the query using the Run Query button.

The results dataset appears as partially depicted in Illustration 33.

Illustration 33: The Results Dataset (Partial View)

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.