Logical Functions: IsSibling(): Conditional Logic within Calculations - Page 3

December 4, 2006

We have specified that the Calendar Date members are to populate the rows axis to provide, to some extent, a quick means of reasonability testing our the logic within the calculation that we have defined, as we shall see.

The Results pane is populated by Analysis Services, and the dataset, partially depicted in Illustration 3, appears.

In the partial view of the returned dataset, we see that the calculation accomplishes the intended purpose - generating the Order Count for the individual January 2004 dates, which share the same parent member (the month of January, 2004), obviously, as the secondary member expression of January 1, 2004. Again, the conditional test of “sibling-hood” is applied via a calculated member within which we have leveraged the IsSibling() function.

Our client colleagues express satisfaction with the contextual backdrop we have established for introducing the IsSibling() function. We will use a similar query within another such example next, to confirm understanding of the concepts. This query will provide an illustration of the use of the IsSibling() function within the context we have already seen, the definition of a calculated member based upon a comparison. And as before, we will base our example upon a local scenario described by the client representatives.

The developers / authors cite the following example as useful. They would like to create a basic query that returns the Customer Count for the respective month, quarter, half-year and annual levels for Calendar Year 2004. In addition, they are interested in seeing a simple 3-month Rolling Average Customer Count, but they wish for this calculated measure to appear only at the month level, and for a null to appear at the quarter, half-year and annual levels, of the Date hierarchy.

They further specify that they wish to see the calculated measure rounded to two decimal places. Finally, they prefer to present the Date hierarchy levels in the columns, and the measures in the rows, of the returned dataset.

A new tab, with a connection to the Adventure Works cube (we can see it listed in the selector of the Metadata pane, once again) appears in the Query pane.

-- MDX050-002 ISSIBLING()Function: Conditional Logic in 
--   the Definition of a Calculation
WITH
MEMBER
   [Measures].[3-Mo Rolling Avg Customer Count]
AS
   'IIF(
   
      ISSIBLING([Date].[Calendar].CURRENTMEMBER, 
         [Date].[Calendar].[Month].[January 2004]),
     
             AVG(LASTPERIODS(3, [Date].[Calendar].CURRENTMEMBER), 
         
         [Measures].[Customer Count]),
    
     NULL
    
  )', FORMAT_STRING = "#,###.00" 

SELECT 
    
   {DESCENDANTS(
      [Date].[Calendar].[Calendar Year].[CY 2003]:[CY 2004],
          [Date].[Calendar].[Month],
      SELF_AND_BEFORE)} ON AXIS(0),
    
    
   CROSSJOIN( 
      {[Product].[Product Categories].[Category].[Bikes].CHILDREN },
    
         {[Measures].[Customer Count],
             [Measures].[3-Mo Rolling Avg Customer Count]}
    
         ) ON AXIS(1)
    
FROM
   [Adventure Works]

The Query pane appears, with our input, as depicted in Illustration 5.

Note that we are adding a wider “presentation” date range (by specifying the range between Calendar Year 2003 and Calendar Year 2004 within the row axis) than required by the specification; this is to allow us to see months preceding 2004, so that we can ascertain that the rolling average is working as planned. (We would remove the “[CY 2003]:” portion of the specification after testing the average, as appropriate.)

The Results pane is, once again, populated by Analysis Services. This time, the dataset (including the most relevant 2004 data - that containing the 3-month Rolling Average Customer Count - along with a couple of the preceding months of 2003), appears as partially shown in Illustration 6.

In the returned dataset, we see that the query appears to meet the business requirements outlined by the client analysts group. We have delivered a simple rolling average, 3-Mo Rolling Avg Customer Count, based upon the total count of customers recorded for a given month (that is, a month that shares the parent of the secondary member expression of January 1, 2004 within the IsSibling() function), plus the two preceding months (as specified within the expression LASTPERIODS(3, [Date].[Calendar].CURRENTMEMBER - the “True” portion of our IsSibling() function - divided by the number of months specified within the Avg() function (3, as we stipulate within the function).

Our calculation employs the IsSibling() function, much in the same manner as we have employed and explained it in our first example above: it supports conditional logic to determine the specified “focus” members of the Date dimension, and then retrieves the associated values based upon the outcome of this test. We can see each of the Customer Count values involved in the calculation of the 3-Mo Rolling Avg Customer Count within the returned data set, together with the average itself, as a means of presenting data useful in helping us to ascertain that our calculations are performing as expected.

Example:

 1,053    Total Customer Count for Jan 2004, Dec 2003 and Nov 2003 (311 + 442 + 300)
 Divided by 3 Mos.
 = 351.00  (as indicated in the 3-Mo Rolling Avg Customer Count for Jan 2004

The client representatives confirm that the immediate goal of a simple Rolling Avg Customer Count, the presentation of which has been dictated by the IsSibling() function in a manner that lends itself to the parameterization objectives that will arise at the reporting layer, (which we have explained within our discussion surrounding the earlier example) has been met. Moreover, they state that the illustration we have provided will be easily extrapolated to other scenarios where they need to perform an action, or to present a value, based upon the outcome of a test as to whether or not a given dimensional member is the sibling of a specified member.

Summary ...

In this article, we exposed another logical function contained within the MDX toolset, the IsSibling() function, whose general purpose, we learned, is to return a value indicating whether or not a member that we specify is the sibling of another member we specify. We learned that a significant part of the utility of the IsSibling() function lies in the fact that it can be used to test whether the member shares the same parent, and, therefore, the same hierarchical “distance” from the parent, as another dimensional member that we specify.

We noted that, similar to other logical functions, IsSibling() can best be employed to apply conditional logic within a couple of primary ways: as a component within a calculation, and as a component within a filter expression. In this article, we concentrated upon IsSibling() from the perspective of its use within a calculation. We discussed the straightforward purpose of the function, to ascertain whether a member is the sibling of another specified member; the manner in which IsSibling() manages to do this; and ways we can leverage the function to support effective conditional logic to meet various business needs within our own environments.

After introducing IsSibling(), we examined the syntax with which we employ the function. We then undertook illustrative examples whereby we put the IsSibling() function to work, within a couple of simple illustrations, to meet the business needs of a hypothetical client. Throughout our practice session, we briefly discussed the results datasets we obtained from each of the queries we constructed.

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

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