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

» Database Journal Home
» Database Articles
» Database Tutorials
MS SQL
Oracle
DB2
MS Access
MySQL
» RESOURCES
Database Tools
SQL Scripts & Samples
Links
» Database Forum
» Sitemap
Free Newsletters:
DatabaseDaily  
News Via RSS Feed


follow us on Twitter
Database Journal |DBA Support |SQLCourse |SQLCourse2
 

Featured Database Articles

MS SQL

Posted Apr 4, 2005

MDX Essentials: Enhancing CROSSJOIN() with Calculated Members - Page 8

By William Pearson

Based upon what we know about the CROSSJOIN() function, we can readily see that the query above can be optimized. First, we note that the query as originally written creates, for the Bellmont Distributing Warehouse, every Store Country (four, including the new Non-Domestic calculated member) and Product Name (1,560 exist) combination. This is only 6,240 combinations, but we certainly must acknowledge that the query is time consuming.

3.  Scroll down in the viewer to ascertain that the Non-Domestic calculated member appears, as depicted in Illustration 17.

Click for larger image

Illustration 17: The Results Dataset (Top Section Only) - Original Approach

As we noted in our previous article, there are many "empties" that we might attempt to eliminate as a first step in enhancing query performance. The complication within our current enhancement effort lies in the expressed business requirement to return the calculated member. While we found the NONEMPTYCROSSJOIN() a helpful ally, in The CROSSJOIN() Function: Breaking Bottlenecks, in a scenario that was devoid of calculated member considerations, we will see that it tends to "scalp" the returned dataset of calculated members when they are present.

4.  Save the query as MDX30-01.

5.  Create the following new query, where we substitute the NONEMPTYCROSSJOIN() approach:


--MDX30-02: NONEMPTYCROSSJOIN() fails to recognize Calculated Members
SELECT 
    {[Measures].[Warehouse Sales]} ON COLUMNS,
    {NONEMPTYCROSSJOIN({[Warehouse].[All Warehouses].[Canada].[BC].[Vancouver].
        [Bellmont Distributing]}, [Store].[Store Country].AllMembers, 
             [Product].[Product Name].Members)} ON ROWS
FROM  
   [MDX30 Optimize CrossJoin]
WHERE
    ([Time].[1998])

6.  Execute the query using the Run Query button.

The query executes far more rapidly, and the empties are eliminated. We note, however, if we attempt to scroll to the Non-Domestic calculated member once again, that it no longer appears - even though we retain .AllMembers in our Store Country specification. This, as we have already intimated, is because the NONEMPTYCROSSJOIN() function strips the calculated member out of the returned results dataset. This eliminates the powerful NONEMPTYCROSSJOIN() option in the current scenario, not to mention the option to tune NONEMPTYCROSSJOIN() even further, with the addition of the set-count parameter that we witnessed in the final refinement of our solution in The CROSSJOIN() Function: Breaking Bottleneck.

Fortunately, as we have seen myriad times in the past, MDX offers alternative approaches to meeting our needs. To accomplish our ends, enhancement of the query with retrieval of the calculated member, we can employ a combination of the CROSSJOIN() and FILTER() functions, together with NOT ISEMPTY(), as we shall see in the next steps.

7.  Save the query as MDX30-02.

Fortunately, as we have seen myriad times in the past, MDX offers alternative approaches to meeting our needs. To accomplish our ends - enhancement of the query with retrieval of the calculated member - we can employ a combination of the CROSSJOIN() and FILTER() functions, together with NOT ISEMPTY(), as we shall see in the next steps.

8.  Create the following new query, where we substitute the new approach NONEMPTYCROSSJOIN() approach:


--MDX30-03: Using GENERATE() to enhance CROSSJOIN() performance when
--  Calculated Members are a consideration
SELECT 
    {[Measures].[Warehouse Sales]} ON COLUMNS,
    GENERATE({[Warehouse].[All Warehouses].[Canada].[BC].[Vancouver].
       [Bellmont Distributing]},
        CROSSJOIN({[Warehouse].CurrentMember},
            GENERATE([Store].[Store Country].AllMembers,
                CROSSJOIN({[Store].CurrentMember},
                    FILTER([Product].[Product Name].Members,
                        NOT ISEMPTY ([Measures].[Warehouse Sales])))))) ON ROWS
   FROM 
   [MDX30 Optimize CrossJoin]
WHERE
   ([Time].[1998])

9.  Execute the query using the Run Query button.

The query returns in far less time than in its original incarnation. In addition, the absence of empties is pronounced. Finally, we see, if we scroll once again to our calculated member Non-Domestic, that the calculated member does, indeed, appear. We note that the USA Store Country does not appear at all: the Canadian warehouse had no sales with US Stores in 1998. In contrast to the dataset, appearing in Illustration 17 above, our new query has eliminated the empty Store Country. The newly derived results dataset appears as partially depicted in Illustration 18.


Illustration 18: The Results Dataset (Portion Showing Non-Domestic Calculated Member)

The query we have constructed is faster than the original query, and is faster than would be the application of the filter to both CROSSJOINS(), another approach to the same end. While this approach is still slower than the NONEMPTYCROSSJOIN() solution, we obtain a palpable relief in processing time over the original query, while meeting the need to retain calculated members in the final presentation, as we can see in Illustration 18 above.

10.  Save the query as MDX30-03.

11.  Close the MDX Sample Application, when ready.

We report our success to the information consumers, detailing the steps we took and documenting the modifications to the query. We conclude by expressing our hopes that other disrupted development projects that were in the hands of the offshore organization meet with successful recoveries, as well.

Summary ...

In this article, we continued our examination of the enhancement of queries using the powerful CROSSJOIN() function. We reviewed CROSSJOIN() performance considerations introduced in earlier articles, and extended our exploration of enhancement approaches to scenarios where the presence of calculated members render ineffective the NONEMPTYCROSSJOIN() options we presented earlier. After preparing a copy of the Warehouse sample cube, and modifying it to include a calculated member contained in the hypothetical cube we intended to mirror, we processed the cube, and then set about deriving enhancements to a query whose performance had been impacted by the injudicious use of CROSSJOIN().

In a multi-step practice exercise, we determined that CROSSJOIN() was behind the suboptimal query performance suffered by a hypothetical group of information consumers. We demonstrated how a solution we employed in an earlier article, which relied upon substitution of NONEMPTYCROSSJOIN() for the original CROSSJOIN() to make significant performance gains, failed to retrieve calculated members, and thus rendered the approach ineffective to meet the current business requirement. We then provided an approach to enhancement of the CROSSJOIN() scenario with concomitant return of calculated members, using a combination of the CROSSJOIN() and FILTER() functions, together with NOT ISEMPTY(). Throughout our practice exercise we explained the results we obtained from the steps we took to accomplish the solution.

» 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

Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 




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