mdx1

Title：

MDX（1）

Publisher：

Friend Lv

 

Lab 1: Introduction to MDX

 

 

 

 

 

 

Lesson 1: MDX and the Sample Application

Lesson 2: Basic MDX Syntax

 

 

 

 

 

 

 

 

This page left intentionally blank

Lesson 1: MDX and the Sample Application

This lesson will define MDX and learn its uses. Then it will discuss and create a simple query using the MDX sample application.

What You Will Learn

After completing this lesson, you will be able to:

·         Define MDX

·         List the MDX terms and the analogous terms in SQL

·         Use the MDX Sample Application

·         Describer the data structures in the FoodMart database

·         Write a simple MDX statement

 

Before You Begin

Prerequisites

·         Those who are familiar with the SQL language or an equivalent database language will have an advantage when learning MDX.

Lab Setup

·         You must have a workstation with SQL Server OLAP services installed. The OLAP installation will setup the FoodMart database, which is used throughout this Lab.

 

MDX Defined

What is MDX?

The name MDX originated from Multi-Dimensional eXtensions. As this origin implies, MDX started as extensions to the SQL language.  If you know the SQL language, you will have a good platform for learning MDX. But don’t be led to believe that it is SQL with a bit extra, it has a very different structure from SQL.

Is MDX like SQL?

Very simple MDX statements resemble SQL, they both take the format

 SELECT …..
 FROM ….
 WHERE ….

That is where the similarity ends. However someone with SQL skills will have a good base for learning MDX. Both are data manipulation languages.

Why MDX, why not SQL?

MDX is designed to facilitate queries on multidimensional cubes, while the SQL language is designed to facilitate queries on two-dimensional tables.

SQL and MDX Analogous Terms

Multidimensional Term	Relational Analog
Cube	Table
Level	Column (string or discrete numeric)
Dimension	Several related columns or dimension table
Measure	Column (discrete or continuos numeric)
Dimension member	The value in the specific row and column corresponding to the given dimension level

 

How does OLE DB fit in?

OLE DB is a data access API. Just as you can call relational database OLE DB providers with SQL requests, you can call OLAP OLE DB providers with MDX queries.

 

The MDX Sample Application

The MDX Sample application started out in life, as its name implies, a sample application to demonstrate how to call OLAP from a VB application. This application was the only interface that supported freeform MDX. Subsequently its importance rose. It is currently not an official part of SQL Server 7.0, but being the only MDX query editor it is extremely useful. Being a sample application, you get the source code for the MDX Sample with SQL Server. By default the sample application will be found at C:\Program Files\OLAP Services\Samples\MdxSample\. This is what the application looks like:

Notice that it has 4 panes. The top pane is where you can type in your MDX query; the bottom pane is where the results are displayed; the middle left pane is displaying the cube structure; and the middle right pane contains templates for MDX functions. This application is very useful in the way it supports drag and drop from the cube structure and function templates to the query pane.

 

The Sample Database

All examples in this lab are based on the Sales cube in the FoodMart sample database. This cube has been designed to facilitate the analysis of a chain of grocery stores and their promotions, customers and products. We have the following dimensions:

Sales Cube Dimensions

Key Points

Take a moment to review this information about the data cube.

- In particular note that some dimensions such as Customers have several levels.

- Some dimensions such as Gender and Marital Status have only one level.

Dimension Name	Level	Description
Customers	Country, State or Province, City, Name	Geographical hierarchy for registered customers of our stores
Education Level	Education Level	Education level of customer, such as “Graduate Degree”, “High School Degree”
Gender	Gender	Customer gender, “M” or “F”
Marital Status	Marital Status	Customer marital status “S” or “M”
Product	Product Family, Product Department, Product Category, Product Subcategory, Brand Name, Product Name	The products that are on sale in these stores.
Promotion Media	Media Type	The media used for a promotion, such as Daily Paper, Radio, etc.
Promotions	Promotion Name	Identifies promotion that triggered the sale
Store	Store Country, Store State, Store City, Store Name	Geographical hierarchy for different stores in the chain (country, state, city)
Store Size in SQFT	Store Sqft	Area occupied by store, in square feet.
Store Type	Store Type	Type of store, such as “Deluxe Supermarket”, “Small Grocery” etc
Time	Years, Quarters, Months	Time period the sale was made
Yearly Income	Yearly Income	Income of customer

Notice how some Dimensions, such as Customers, have multiple levels. This means that the dimension is hierarchical. Country is the highest level, each country will have one or more State Provinces; each State Province will have one or more cities; and each city will have one or more Names (customers).

Sales Cube Measures

Measure Name	Description
Unit Sales	Number of units sold
Store Cost	Cost of goods sold
Store Sales	Value of Sales transactions
Sales Count	Number of Sales transactions
Store Sales Net	Value of Sales transactions less cost of goods sold
Average Sale	“Store Sales”/”Sale Count”.  This is a Calculated Measure, which means that it is derived from other measures and does not need to be stored in the cube.

Measures are the things you want to aggregate (count, sum, average, max, min etc.) When you come to writing MDX, it is useful to think of measures as like dimensions. In MDX whenever we reference a cell, we explicitly or implicitly specify which member of every dimension and measure we want as coordinates for that cell.

Basic MDX

Let’s think about our first MDX query. The simplest MDX query has the following structure:

SELECT something ON COLUMNS
FROM cube

So far MDX syntax looks similar to SQL. This is where the similarity ends. MDX is a language designed for multidimensional cubes. Dimensions are the basic constructs, not tables.

In MDX, we can specify any number of dimensions in our resultset. We will call them axes to prevent the confusion with a cube’s dimensions. We can have zero, one, two, three…n. axes.  All of the axes are symmetric. That means, whatever we can do on one, we can do on another. Typically MDX queries don’t have more than two dimensions in the resultset as we do not have many tools to display more than two-dimensional results.

Members

A member is an item in a dimension or measure[1]. For example in the Gender dimension “M”, “F” and “All Gender” are all members.

Exercise 1
Using the MDX Sample Application to Write a Simple MDX Query

In this exercise, you will open the MDX sample program, create and execute a simple query.

Opening the MDX Sample Application

Let’s start the MDX Query Application.

1.        From the Start menu select Programs, Microsoft SQL Server 7.0, OLAP Services, and the MDX Sample Application.

2.        You will be prompted for the server and the provider. Enter the name of the server that has the OLAP Services and sample database installed. By default it is the Windows NT name of your machine. Leave the provider as MSOLAP and select OK. The MDX Sample Application will start.

3.        Select the “FoodMart” database from the “DB” drop down list at the top of the screen.

4.        Select the “Sales” cube from the “Cube” drop down list near the middle of the screen.

5.        Select New from the File menu (or click on the “New Query File” button at the left of the toolbar).

We now have a fresh query window to start MDXing.

Your first MDX query

Your first MDX query will report on the number of units sold to male versus female customers.

1.        Type the following query into the new query window.

SELECT
   Gender.MEMBERS ON COLUMNS
FROM Sales

2.        Run the query by clicking the green arrow on the toolbar (or click the F5 key).

Note

Notice, how the result set also has a column headed “All Gender.” By default, MS OLAP will create an “All” level at the peak of the hierarchy. When you create dimensions in Plato, the “All” member is generated by default and it becomes the default member. This turns out to be very useful. In our query, we did not specify which member of the “Marital Status” dimension to use, so Plato used the default member “All”. By default this member has the format [All dimensionname], but if the dimension name is very large, it might be abbreviated to [All].  You may call the all member by any name. For example in the FoodMart database the all member of “Media Type” is “All Media”.

Now that you are familiar with the MDX Sample Application proceed to lesson 2 to study MDX syntax.

 

 

Lesson 2: Basic MDX Syntax

Now the fun starts:

We are now going to write some MDX queries. In some ways MDX is simpler than SQL.  Plato has a lot of meta knowledge. That is, it knows about the relationships between the dimensions and members. You do not need to write INNER, LEFT/RIGHT/FULL OUTER JOIN etc.

What You Will Learn

After completing this lesson, you will be able to:

·         Write two dimensional MDX statements

·         Use identifiers

·         Use the CHILDREN syntax

·         Apply a WHERE clause

·         Enumerate the axes

 

Making More Complex Queries

Now we will explore some additional concepts.

Two Dimensional Queries

MDX can request resultsets with more than two dimensions. However, most tools have difficulty in presenting more than two dimensions. Hence, two-dimensional queries are the most common. Lets enhance the previous query by putting measures on rows.

1.        Add a comma after COLUMNS and insert a new line with “Measures.MEMBERS ON ROWS”.

SELECT
Gender.MEMBERS ON COLUMNS,
Measures.MEMBERS ON ROWS
FROM Sales

Congratulations, you have written a two dimensional query.

Identifiers and Qualifiers

In the MDX language, identifiers can be delimited with square brackets.

2.        Update the above query to use delimiters around the member names.

SELECT
[Gender].MEMBERS ON COLUMNS,
[Measures].MEMBERS ON ROWS
FROM Sales

Square brackets are always required when identifiers have spaces, are numbers or are also reserved words. MEMBERS is a reserved word, hence you should not enclose it in square brackets (unless you have a member called “MEMBERS”). Now that we know how to qualify identifiers we can query on any of the dimensions.

3.        Update your query to report [Marital Status].MEMBERS ON COLUMNS and [Promotion Media].MEMBERS ON ROWS.

SELECT
[Marital Status].MEMBERS ON COLUMNS,
[Promotion Media].MEMBERS ON ROWS
FROM Sales

Set Identifiers

Curly brackets are used to denote sets. [Marital Status].MEMBERS and [Promotion Media].MEMBERS are sets and can be delimited by curly brackets. In the preceding query, Plato “knew” they were sets so the curly brackets were not necessary. However sets are not always evident to Plato. Hence it is good practice to write queries with curly braces.

4.        Put curly braces around the set specifications in your query.

SELECT
{[Marital Status].MEMBERS} ON COLUMNS,
{[Promotion Media].MEMBERS} ON ROWS
FROM Sales

 

Children

For Your Information

Remember the chart on page 6. - The Customers dimension had several levels.

- Marital Status had only one level.

Dimensions are often hierarchical. For example, our Customers dimension has 4 levels (Country, State or Province, City, Name). If we write a query using Customers.members on one of the axes, we are asking for the items at every level of the Customers dimension. That is all Countries, all States/Provinces, all Cities, and all Names. Perhaps we only want the members at one level. Children are very useful in limiting the output to the immediate level. For example, let’s report on the Customers dimension at the first (country) level.

5.        Write a query that has [Marital Status].MEMBERS on columns and [Customers].CHILDREN on rows.

SELECT
{[Marital Status].MEMBERS} ON COLUMNS,
{[Customers].CHILDREN} ON ROWS
FROM Sales

Note

Notice how the resultset only includes members of the first level of Customers. That is Country. Expand the Customers dimension on the cube browser pane (middle left) to view the levels in the Customers dimension. You might also notice in the results that we only have figures for USA. While Canada and Mexico are valid countries, there is no data to report on. You might say, that there could be stores in Canada and Mexico, but as yet there are no Sales.

 

We might want to drill down on USA and show the figures for states within the USA.

6.        Use the CHILDREN keyword on the [Customers].[USA] member to show the USA states.

SELECT
{[Marital Status].MEMBERS} ON COLUMNS,
{[Customers].[USA].CHILDREN} ON ROWS
FROM Sales

This query asks for all the children members (all states) within USA. Notice how Plato knows about this hierarchy. We did not have to specify parent child joins as we would normally need to in SQL. We could further drill down on one of the states.

7.        Ask for all the cities in WA by typing “.[WA]” after “[USA]” in your query.

SELECT
{[Marital Status].MEMBERS} ON COLUMNS,
{[Customers].[USA].[WA].CHILDREN} ON ROWS
FROM Sales

Note

You can pivot the result set with a button on the far right of the toolbar. Look for the curved double-headed arrow.

The WHERE Clause

At first glance the WHERE clause appears similar to the corresponding clause in SQL. For example, we might want to report on Education Level by Marital Status, but only where customers are male.

8.        Update your query by inserting a line at the end and type “WHERE Gender.[M]”

SELECT
{[Education Level].MEMBERS} ON COLUMNS,
{[Marital Status].CHILDREN} ON ROWS
FROM Sales
WHERE Gender.[M]

If we want to add further filters to the WHERE clause we enclose the whole WHERE clause in rounded brackets and dimension filters with commas. For example we might want to restrict the previous query to only those Sales where the sale was induced by a promotion media of “Radio”.

9.        Add “,[Promotion Media].[Radio]” to the end of your WHERE clause and enclose the clause in rounded brackets.

SELECT
{[Education Level].MEMBERS} ON COLUMNS,
{[Marital Status].CHILDREN} ON ROWS
FROM Sales
WHERE (Gender.[M],[Promotion Media].[Radio])

We could continue to add filters to the WHERE clause, until we had one for each dimension. But we cannot create a query with a dimension on an axis (row or column) and in the WHERE clause.  For example in the previous query, it would be illegal to put [Education Level].[Graduate Degree] on the where clause.

[Gender] and [Promotion Media] dimensions both have (the default) all level. Hence if we were to be particular about writing the WHERE clause we would have written it as:

WHERE (Gender.[All Gender].[M],
[Promotion Media].[All Media].[Radio])

 [M] and [Radio] are not ambiguous in their respective dimensions, so it was not necessary to qualify them with their parent level. Indeed if the member is unambiguous in the cube, it is not necessary to qualify it at all. However, it is a good practice to qualify members.

There are many dimensions not specified in this query. For non-specified dimensions, it is useful to think of them as being specified with their default member, which is usually the [All] member.

The full measure

What if we want to measure something other than [Unit Sales]? The preceding queries have reported on the default measure (Unit Sales). It is the default measure because there is no [All] member and [Unit Sales] is the first member of Measures. If we want to report on another dimension, we would name it in the WHERE clause.

10.     Modify the preceding query to report on Store Sales instead of Unit Sales by adding “,Measures.[Store Sales]” to your WHERE clause.

SELECT
{[Education Level].MEMBERS} ON COLUMNS,
{[Marital Status].CHILDREN} ON ROWS
FROM Sales
WHERE (Gender.[M],[Promotion Media].[Radio],
Measures.[Store Sales])

 

 

 

 

 

 

Review of Brackets, Braces and Parentheses

Let’s recap this area, as it is often an area of confusion.

·         Square brackets [ ] are used to delimit member names.

·         Curly brackets { } are used to define sets.

·         Round brackets ( ) are used in functions and to delimit tuples.  There will be examples of these soon.

Note

A tuple is another word for a row in a table.

 

Review - Practicing the Basics

Now you know the basics of the MDX query language. Let’s practice using these elements before we move onto more sophisticated aspects of the language. The answers are at the bottom of the page. All examples use the Sales cube.

1.        Write a query to show measures on columns and all of the [Promotion Media] members on rows.

2.        Write a query to show the first level members (CHILDREN) of Product on columns and gender members on rows.

3.        Write a query to show the first level members (CHILDREN) of [Product].[Drink] on columns and [Marital Status] members on rows. But only show figures for Gender [F].

4.        Modify the WHERE clause so the report shows [Store Sales Net] figures.

 

 

 

 

 

 

 

 

 

Answers:

1.        Suggested syntax:

SELECT
Measures.MEMBERS ON COLUMNS,
[Promotion Media].MEMBERS ON ROWS
FROM Sales

2.        Suggested syntax:

SELECT
Product.CHILDREN ON COLUMNS,
[Gender].MEMBERS ON ROWS
FROM Sales

3.        Suggested syntax:

SELECT
[Product].[Drink].CHILDREN ON COLUMNS,
[Marital Status].MEMBERS ON ROWS
FROM Sales
WHERE [Gender].[F]

This query shows figures for [Unit Sale] as it is the default measure.

4.        Suggested syntax:

SELECT
Product.CHILDREN ON COLUMNS,
[Marital Status].MEMBERS ON ROWS
FROM Sales
WHERE ([Gender].[F], Measures.[Store Sales Net])

Axes and Members

Enumerating Our Own Axes

So far we have only used the MEMBERS and CHILDREN collections of dimensions. Very often we want to be more precise than this. We might want to report on just two selected products, or we might want to select months October and November and the full year. Fortunately, in MDX we can specify exactly which members we want on an axis. We do this by enumerating our own set with declared tuples. For example, there are lots of promotions, but we only want to look at [Price Destroyers], [Price Slashers], and [All Promotions].

1.        Enclose the above promotions within curly braces, which delimit the set, to enumerate your own row axis. Put {[Time].[1997].CHILDREN} on columns.

SELECT
{[Time].[1997].CHILDREN} ON COLUMNS,
{Promotions.[All Promotions].[Price Destroyers],
   Promotions.[All Promotions].[Price Slashers],
   Promotions.[All Promotions]} ON ROWS
FROM Sales

Note

We have written the fully qualified member names with all levels qualified. Because the low level member names are not ambiguous, an equivalent query would be:

SELECT
{[Time].[1997].CHILDREN} ON COLUMNS,
{[Price Destroyers], [Price Slashers],
   [All Promotions]} ON ROWS
FROM Sales

 

We can combine these enumerated axes with a WHERE clause and our query starts to get interesting.

2.        Write a query to look at January, February, March and April of 1997 on columns, [Price Destroyers], [Price Slashers], [All Promotions] on rows, and filter for store Sales to male customers in the state [WA]. And we want to measure [Store Sales].

SELECT
{[Time].[1997].[Q1].[1],
 [Time].[1997].[Q1].[2],
 [Time].[1997].[Q1].[3],
 [Time].[1997].[Q2].[4]} ON COLUMNS,
{[Price Destroyers],
 [Price Slashers],
 [All Promotions]} ON ROWS
FROM Sales
WHERE (Gender.[M],
Customers.[USA].[WA],
Measures.[Store Sales])

 

Let’s create our own tuples for the axis

In the previous section we enumerated our own axes from individual members. We can take that further by specifying dimension intersections on axes. For example[2] we might want to compare Store Sales to female customers in WA compared with male customers in CA. And view this by quarters of the year 1997. The tuple females in WA can be specified as ([Customers].[USA].[WA],[Gender].[F]), likewise males in CA can be specified as ([Customers].[USA].[CA],[Gender].[M]).

3.        Put these together to make a request to show [Store Sales] with 1997 quarters on columns, Female WA customers on one row and male CA customers on another row.

SELECT
{[Time].[1997].CHILDREN} ON COLUMNS,
{([Customers].[USA].[WA], [Gender].[F]),
 ([Customers].[USA].[CA], [Gender].[M])} ON ROWS
FROM Sales
WHERE (Measures.[Store Sales])

All members welcome

Whenever we specify a tuple, we are actually specifying an intersection of all dimensions. The dimensions that we do not specify have their default member included. You might see now why it is useful to have the [All] member as the default member.

Note

There is no [All] member for measures. It does not make sense to aggregate the different measures. For measures, the default member is the first member. Some of your cubes may have dimensions without an [All] level. For example, Time dimensions often do not have [All] levels. Also a dimension with members [Forecast] and [Actual] might not have an [All] member. A default of either [Forecast] or [Actual] is probably more useful.

 

Review

Finally, let’s do an exercise to review the previous sections.

1.        Write a query to report on store Sales; put the USA states on columns and all the combinations of gender and marital status on rows.

Answer:

SELECT
{[Customers].[All Customers].[USA].CHILDREN}
  ON COLUMNS,
{([Gender].[M],[Marital Status].[S]),
 ([Gender].[M],[Marital Status].[M]),
 ([Gender].[F],[Marital Status].[S]),
 ([Gender].[F],[Marital Status].[M])} ON ROWS
FROM Sales
WHERE ([Store Sales])

The Use of Functions

At this stage you would be forgiven for thinking that MDX would be difficult for complex reports. Fortunately, it has the richness of many functions. We will introduce one here in our discussion of syntax.

The CROSSJOIN Function

As we said, MDX, like SQL, is a redundant language. That is, the same request, can be written in many different (redundant) ways. The previous query, for example, wanted all the possible join combinations between [gender] and [marital status] on rows. We wrote the MDX with the members hard coded. How about just asking Plato to join all the possible combinations using the CrossJoin function such as:

SELECT
{[Customers].[All Customers].[USA].CHILDREN}
  ON COLUMNS,
{CROSSJOIN([Gender].CHILDREN,
  [Marital Status].CHILDREN)} ON ROWS
FROM Sales
WHERE ([Store Sales])

Of course if we wanted to have totals by [gender] and [marital status] we could use MEMBERS in place of CHILDREN. 

2.        Modify the previous query to use Members for both gender and marital status.

Warning

Note: Using members for the customers dimension might not be such a good idea as that would involve loading all 10,000 customers in the MDX Sample Application.

SELECT
{[Customers].[All Customers].[USA].CHILDREN}
  ON COLUMNS,
{CROSSJOIN([Gender].MEMBERS,
  [Marital Status]. MEMBERS)} ON ROWS
FROM Sales
WHERE ([Store Sales])

 

Congratulations

You have completed this Introduction to MDX. You should now know what MDX is and how to use the language to write basic queries. If you would like to continue to learn more about the richness of this language, go on to Lab 2: MDX Functions and Calculated Members.

 

 

---

[1] It is often useful to view measures as a dimension, albeit a special one.

[2] Ignoring any politically correct debate