Our use of the NON EMPTY keyword is simply a means of issuing instructions, for the stores in the second axis dimension (rows), which do not have values for the Units Shipped and Units Ordered of the product, to be excluded from the result dataset. The empty tuples are screened out of the result dataset of the MDX query.
11. Click Query on the top menu, and then select Run.
The Results pane appears as partially shown below.

Illustration 6: The Query Results
Now, to continue with the focus of our lesson, the .Members operator; we can see in the example we have created that the use of .Members in the above query gives us every member of the dimension, including levels and the members for each of those levels. This result might tend to confuse more than help an information consumer, because total numbers would not necessarily agree with a total of the values appearing in the result dataset for either measure. In short, a "dump" of the entire list of hierarchy objects with their associated values might not serve to be useful from an analysis perspective to an uninformed consumer.
Let's explore going to a specific level in the hierarchy for the Store dimension.
12. Type the following query into the Query pane:
-- MDX04-3: Tutorial Query No. 3
SELECT
{ [Measures].[Units Shipped], [Measures].[Units Ordered] } ON COLUMNS,
NON EMPTY [Store].[Store State].Members ON ROWS
FROM [Warehouse]
We are now using the .Member function to ask for the "membership" of the Store State level in the row axis.
13. Click Query on the top menu, and then select Run.
The Results pane appears as partially shown below.

Illustration 7: The Query Results
We see that we have now obtained a summary by store state of the two measures--and by store state only--because we made the more specific request for members of the Store State level.
We can easily replicate the effects we have obtained at the Store City and other levels of the Store dimension, as well as in the other dimensions and their levels. Practice the concept with various dimensions and their component levels to get a feel for how the .Members operator works.
As we progress into the Member Functions segment of our series, and the coverage of many of the member functions available in MDX, as well as into even more advanced stages of query building, we will revisit the .Members operator often. Practice with this powerful operator will make its use easy and natural; we will come to value it highly in our more advanced MDX exercises later.
Next in Our Series ...
In this lesson, MDX Members: Introducing Members and Member Functions, we introduced the concept of members, and discussed their significance within MDX. We then launched the first group of articles in the series, Member Functions with an exploration of the powerful .Members operator. As a part of exploring this highly useful operator, we discussed the syntax within which we can best employ it, and illustrated its common use within MDX expressions through the use of practice exercises.
In our next lesson, MDX Member Functions: The "Family" Functions, we will move into a multiple-article segment that focuses upon the member functions one at a time, contrasting the uses and effects of each. In the next article, we will expose the .Parent, .Children and Ancestor() functions, discussing the information they return, together with syntactical points of their use. We will illustrate further how to take advantage of these useful functions by performing practice exercises, and commenting on the result datasets we obtain.
» See All Articles by Columnist William E. Pearson, III
Discuss this article in the MSSQL Server 2000 Analysis Services and MDX Topics Forum.