Execute the stored procedure to verify that it works. (Your results should look like Figure 13-24.) if you get stuck, the answers for this exercise can be found in the example files for this book. Look in the folder for Chapter 13.
Figure 13-24. Results showing sales by store
in this exercise, you wrote a report query that captured sales data based on sales by stores.
Using Your Code in Reporting Applications
Once you have created your code, views, or stored procedures, you can use them in a number of reporting applications. For example, Microsoft Excel allows you to easily connect to a database and access both views and tables, as shown in Figure 13-25.
Figure 13-25. Connecting to a view from Microsoft Excel
In Excel you can display the information in either a tabular or pivot table format. The pivot table format provides options such as sorting, filtering, and subtotals, and it easily generates charts, making it a popular choice. This is significant, because as we have seen, many of these features cannot be stored directly as part of a SQL view’s code. Figure 13-26 shows an example of a pivot table using the view we created.
Excel can use SQL stored procedures as well, but it’s not as straightforward as it could be. Other applications such as Microsoft Reporting Server (SSRS), however, have no such problems. In SSRS you can effortlessly launch a wizard and include the stored procedure name you want to use to capture your report data. Figure 13-27 shows the SSRS Report Wizard on its final dialog window, which list the details about the wizard configuration. Note that the stored procedure name was used as a query.
Figure 13-27. Getting report data from the stored procedure with Reporting Services
When the wizard completes, your SSRS project will include a new report that contains data generated from your stored procedure (Figure 13-28).
We will delve deeper into both of these scenarios in the chapters on Excel reporting and reporting services.
Moving On
You will need quite a bit of practice to become an expert at writing report queries. Report stored procedures often included hundreds of lines of code. These stored procedures take many days to write and test correctly. When stored procedures become this large, it is very easy to make mistakes that can cost a lot of time and money. The methodology of incrementally building and reviewing your results, using consistent formatting and abstraction layers, make reporting queries easier to maintain and cost effective.
Learn By doing
in this “Learn by Doing” exercise, you create several SQL queries using the northwind database. We included an outline of the steps to perform and an example of how the authors handled them in two Word documents.
These documents are found in the folder
C:\_BISolutionsBookFiles\_LearnByDoing\Chapter13Files. Please see the ReadMe.doc file for detailed instructions.
Figure 13-28. Displaying the results of the stored procedure in Reporting Services
What’s Next?
There is a lot to understand to become good at writing report queries. This includes proper syntax, performance considerations, and checking validity. While experience is your best teacher, we also recommend this book, that may help you along the way.
SQL Server 2008 Transact-SQL Recipes A Problem-Solution Approach By Joseph Sack
ISBN13: 978-1-59059-980-8
Chapter 14
Reporting with MDX Queries
But for me, it was a code I myself had invented! Yet I could not read it.
—Erno Rubik Multidimensional Expressions (MDX) is a Microsoft-owned specification, not an open standard language. But, it has been adopted by many vendors and is considered an industry standard for querying and manipulating multidimensional data for SSAS.
If you are working with OLAP cubes, you will likely be working with MDX at some point. While you do not have to be an expert in MDX to work with SSAS cubes, acquiring a more in-depth understanding of the language is helpful in a number of ways. For example, calculated members, KPIs, and security structures within SSAS require MDX expressions. And while many client applications can work to create MDX code for you, you may find yourself troubleshooting to find out why the MDX code you are using is not returning the data you want. If you are unable to read MDX, you will not be able to manage troubleshooting problems.
Superficially, MDX is similar to the SQL language; however, MDX also has many differences. In this chapter, we explore these similarities and differences, and show you how to read and create MDX queries.
Key Concepts and Terms
You do not have to know everything about OLAP cubes to begin programming in MDX, but there are a few key concepts and terms that you need to know before you begin. Let’s begin by reviewing some of them.
Consider a typical date dimension hierarchy, as shown in Figure 14-1. The dimension hierarchy is made up of levels such as year, month, and quarter. The dimension attributes are made up of members, such as 1992, 1993, and 1994.
When creating a date dimension in SSAS, the attributes and hierarchies are defined as shown in Figure 14-2.
Figure 14-1. A typical date hierarchy
Table 14-1. MDX Concepts
Concept Description Details/Examples
Dimensions A way of grouping attributes. Title names and publisher names are values.
Dimensions are groupings of these values.
Measures A column of values in the fact table described by the dimensional keys.
Each measure represents a column or calculated column from a fact table. An example is SalesQuantity from our fact table in the DWPubsSales data warehouse.
Member Individual attributes of a dimension, hierarchy, or level. Each attribute within a hierarchy is a member.
Let’s say you have a Date dimension with the levels of Years, Quarters, and Months; June would be an individual member of the Month level.
Measures dimension The special dimension that all measures are grouped within.
The Measures dimension has only a single level and does not include an All
level/member.
Measure groups A way of organizing measures. One SSAS cube can contain many measure groups.
All member A grand total of all items within a dimension (not including the Measures dimension).
Every dimension (except the Measures dimension) has an All member. For example, in the Date dimension of Figure 14-1, there is an implied All Dates member.
Attribute The property of a member or combination of members.
Attributes in SSAS are mapped to one or more columns in your data warehouse tables. For example, the Date key and the Date name combine to make up the Date attribute within the Date dimension. In MDX you can reference an attribute by either its key or its name.
Hierarchy The manner in which data is grouped together and structured into levels.
For example, dates may be grouped by months, months by quarters, and quarters by years. Each dimension (except the Measures dimension) is made up of one or more hierarchies. For example, titles are grouped in one hierarchy by publishers and in a second hierarchy by types, creating more than one hierarchy.
Parent The family relationship within a hierarchy that lower-level members are derived from.
For example, the month of January 1992 is the parent of the date January 1, 1992.
(continued) Table 14-1 lists common MDX dimension terms and definitions. These terms are important to understand, because we use them to discuss MDX report queries.
Programming with MDX
To program with MDX, it is helpful to understand the differences and similarities between MDX and SQL languages. We have several topics to discuss, so let’s get right to it.
Comments
There are three ways to comment in MDX. Listing 14-1 shows an example of each.
Listing 14-1. MDX Comments -- MDX and SQL Comment // MDX Only Comment
/* MDX and SQL Block Comment */
Table 14-1. (continued)
Concept Description Details/Examples
Attribute hierarchy The manner in which attributes are grouped together and structured into levels. This can be implied by the location of the data within a dimension.
Even when attributes are not grouped together explicitly, each attribute within an SSAS dimension is implicitly considered a hierarchy of one attribute. For example, in Figure 14-2, the Year attribute forms a Year hierarchy, but it is also part of the DatesByMonthQtrYear hierarchy.
Level The manner in which hierarchies are structured, in a family type of parent–child relationship.
Figure 14-1 illustrates five levels of a hierarchy: All, Year, Quarter, Month, and Date. In Figure 14-2 the All level is implied.
Leaf level The lowest level of data within a dimension’s hierarchy.
For example, Date is the leaf level in Figure 14-2.
Cell An individual member value
within a cube.
Cell locations can be referenced by member and dimension coordinates within a cube.
For example, each cell in the CubePubsSales cube can be located by indicating a specific value of a member within each of the five dimensions—Measures, DimAuthors, DimTitles, DimDates, and DimStores.
An example of cells themselves are the SalesQuantity values for a given author, title, date, and store within each listed dimension.
A default member A member used to calculate an expression when an attribute is left out of a query.
The default member is usually the All member of that dimension, although it can be reconfigured.
Basic and Raw Syntax
The basic syntax of an MDX select statement starts like a standard SQL select statement, but soon the differences are quite apparent. Listing 14-2 outlines the basic MDX select syntax.
Listing 14-2. Basic MDX Select Syntax Select
{ <a set of attributes> } On Columns, { <a set of attributes> } On Rows From < cube name>
Where ( <member> );
The following are some key differences:
Instead of using the table name in the
• FROM clause, MDX uses the cube name. This
makes sense, because the cube is equivalent to a set of one or more tables in a relational database.
Curly braces and semicolons are not commonly used in SQL programming but are used
•
often in MDX programming.
MDX uses the keywords
• ON COLUMNS and ON ROWS to indicate how the results should be displayed within an Analysis Server client application. Analysis Server applications can use 128 different axis positions to return results. Most applications, like SQL Server Management Studio, are designed only to handle the first two axis (columns and rows).
In custom applications, you may see more axis used that indicate the next two positions after columns and rows, such as pages and chapters.
Listing 14-3 shows an example of a raw MDX statement that queries the CubePubsSales cube.
Listing 14-3. A Raw MDX Statement Select
{ [Measures].[SalesQuantity] } On Columns, -- Axis 0
{ [DimTitles].[Title].[Is Anger the Enemy?] } On Rows -- Axis 1 From [CubePubsSales]
Where ( [DimStores].[Store].[Eric the Read Books] );
Note
■ we recommend typing each code sample, but for your convenience we have included a script file in our downloadable content called Chapter14 All MDX Listings.mdx that contains all of the MDX code used in this chapter. we have also included a processed backup of the PubsBiCubes database for ssAs so that if you did not complete your cube in previous chapters, you would be able to restore the database and cube, allowing you to run the code in this chapter. The instructions on how to restore this type of database can be found in the readme file along with the backup file. You will find both items within C:\_BookFiles\Chapter14Files\.
Running Your MDX Code
To run your MDX code from SQL Server Management Studio, you must either create a new MDX script or open
Figure 14-3 shows a typical layout within SQL Server Management Studio while creating an MDX query. If you are familiar only with running SQL code in SQL Server Management Studio, things will look quite different here.
Table 14-2 gives a brief description of key objects used from SQL Server Management Studio while creating and executing MDX statements.
Reconnect
Cube Metadata Cube Selector Results Pane Query Window Database Selector
New MDX Query
Execute Selected Query
Show/Hide Results Pane
Figure 14-3. The MDX query window
Optional Syntax
Table 14-2. Features of the MDX Editor Within SQL Server Management Studio
Feature Description
Database Selector dropdown Allows you to select which database for your query window to use. Since the SSAS server can host many databases, you must select which database to use by selecting it in this dropdown prior to executing MDX code for that database.
Cube Selector dropdown Allows you to choose which cube in the database your Cube Metadata tab will use. One SSAS database can have many cubes; therefore, the correct one must be selected to display.
This does not affect the query window.
New Query and MDX Query buttons Creates a new MDX query window. The New Query button is context sensitive, and creates an MDX query window only if you are currently connected and focused on SSAS in Object Explorer. Otherwise a standard SQL query window is created instead. (The MDX query button always creates an MDX query window.)
Query window Provides a location to type in one or more MDX statements, but only one statement can be executed at a time. It should be noted that this is very different from the SQL query window, which can execute several statements at a time.
Execute Selected Query button Sends the highlighted MDX code to the SSAS database engine for processing.
Results pane Shows the results of the executed query.
Show/Hide Results button Allows you to toggle between showing and hiding the Results pane. This button is not included in the UI by default and must be added by customizing the toolbar. Instruction on how to do so can be found by searching for Customizing Visual Studio 2010 toolbar. The Ctrl + R shortcut can be used as an alternative to this button.
Cube Metadata tab Allows you to browse the cube’s members, levels, hierarchies, and dimensions. You can drag items from this tab into the query window, and its location within the cube will be typed out for you.
Reconnect button Allows you to reconnect to the SSAS server. If you change, deploy, or process the cube or dimensions, you must reconnect using this button before those changes show up on the Cube Metadata tab. Since this tab is quite useful in creating your MDX code using its drag-and-drop functionality, it is a very good button to know about.
Listing 14-4. Examples in MDX with Optional Syntax Items Select
{ [Measures].[SalesQuantity] } On Columns,
{ [DimTitles].[Title].[Is Anger the Enemy?] } On Rows From [CubePubsSales]
Where ( [DimStores].[Store].[Eric the Read Books] );
-- The same code with optional syntax items removed Select
Measures.SalesQuantity On Columns,
-- Curly Braces {} are optional: Defines a Set of Results DimTitles.Title.[Is Anger the Enemy?] On Rows
-- Square Brackets [] are optional: Defines an Object Identifier From CubePubsSales
-- Parentheses () are optional: Defines Function Parameters or Set of Coordinates Where DimStores.Store.[Eric the Read Books];
-- Semi-colons; are optional: Defines the End of a Statement
Additionally, as in SQL, there is an optional WHERE clause. MDX code is not case-sensitive, and it isn’t sensitive to white spaces within your code. Listing 14-5 gives three examples that highlight this point.
Listing 14-5. Three More Syntax Examples in MDX -- The Where clause is also optional
Select
[Measures].[SalesQuantity] On Columns,
[DimTitles].[Title].[Is Anger the Enemy?] On Rows From [CubePubsSales]
-- MDX is not sensitive to white spaces Select [Measures].[SalesQuantity]
On Columns ,
[DimTitles]. [Title].
[Is Anger the Enemy?]
On Rows From [CubePubsSales]
-- MDX is not Case Sensitive SelECt
[MeaSURes].[SALESQUANTITY] On CoLUMns,
[DimTITLes].[TitLe].[Is ANGER THE ENemy?] ON ROWs From [CubePubsSales]
code in a professional manner, we recommend using curly braces and square brackets even when they are not required. We also recommend using sentence, or Pascal, casing when defining objects and using white spaces consistently to organize your code.
Tip
■ it is considered an unofficial industry standard to use curly braces and square brackets at all times in MDX code. Most printed material demonstrating code, such as magazine articles, books, and web pages, do so as well.
Default Members
The code samples so far have included members of the Titles and Measures dimensions but have not explicitly defined members from the others. Yet, the measured values returned in the results include members from each and every dimension. Dimensions that are not explicitly specified within your MDX query are implicitly defined using a default member.
The way this works is that a default member exists for each dimension, and unless you specify otherwise, it will be the grand total of all the members within the dimensions. The grand total is referred to as the All member. For example, if we do not specify which author we want information about, MDX will assume we want information about all authors. And any totals that we receive as part of the measure will be an aggregation of all authors combined.
It is possible to set a specific member as a default for a dimension, but this is probably not the best way to handle it. For example, if you define the current year as the default member of the date dimension and somebody forgot to include a specific date within their MDX query, Analysis Server returns data only for the current year. If everyone in the client’s company understood that rule, then everything would be OK. Otherwise, your users will be under the assumption that they are receiving the total of every year, not just the current one, and the report will be inaccurate. For this reason, we recommend leaving the default setting for your dimensions, which is the total of all members for each dimension.
To explicitly tell Analysis Server to use the default member of a dimension in MDX, you can use the DefaultMember function, as shown in Listing 14-6. Note that we are using the name of the dimension, and the name of the leaf member in this example. But we could have used any of the attributes or user-defined hierarchies defined in each dimension, because they all have the same ultimate parent, the All member.
Listing 14-6. The DefaultMember Function Select
From [CubePubsSales];
-- Same As. . . Select
{ [Measures].DefaultMember } On Columns,
{( −- Parentheses are required to Define a SET of Coordinates [DimAuthors].[Author].DefaultMember
,[DimDates].[Date].DefaultMember
,[DimOrders].[OrderNumber].DefaultMember ,[DimStores].[Store].DefaultMember ,[DimTitles].[Title].DefaultMember )} On Rows
From [CubePubsSales];
Note
■ in most MDX documentation, both functions and properties are referred to as functions. so, DefaultMember may look like a property, but in MDX it is called a function.
You can specify the All member and still receive the same results as the default (Listing 14-7). The Measures dimension is the single exception to this rule, because it does not have an All member. Instead, the first member of the Measures dimension is used implicitly whenever you do not explicitly specify which measure you want.
Listing 14-7. The All vs. the Default Member Dimension Select
{
[Measures].DefaultMember
-- You cannot use the [All] member on the Measures dimension.
-- So, we are still using the default member here.
} On Columns,
{( −- Parentheses required to Define a SET of Coordinates [DimAuthors].[All]
,[DimDates].[All]
,[DimOrders].[All]
,[DimStores].[All]
,[DimTitles].[All]
)} On Rows
From [CubePubsSales];
-- In this case, since the [SalesQuantity] attribute is -- the default member in the cube, it's the same as…
Select
{[Measures].[SalesQuantity]} On Columns, {(
[DimAuthors].[All]
,[DimDates].[All]
,[DimOrders].[All]
,[DimStores].[All]
,[DimTitles].[All]
)} On Rows
From [CubePubsSales];
You can set the default measure in Business Intelligence Development Studio by selecting the measure within the cube-editing window and using the up and down arrows provided on the toolbar, as shown in Figure 14-4. The measure that is placed closest to the top of the Measures pane will be used as the default measure.