,

APRIL2004

:

extract information from an Essbase database.The output of an MDX query has the form of acube itself. The query captures both the outputspecification and the dimensionality of theresulting cube. MDX-related procedural APIsallow a query to be submitted for execution andthe navigation of the query result consists ofmember combinations and corresponding datavalue A query and reporting application willuse these APIs to format and display the result.1

Report writer is also a declarative scriptinglanguage that can be used to report on anEssbase database. You can combine reportwriter's selection, layout, and formatting com-mands to build reports with different outputspecifications.

In this section, we will provide a briefoverview of the two query interfaces compar-ing and contrasting some commonly usedfunctions and execution paradigms.

MDX allows you to:

• Use declarative query as input and set ofstructures as output

• Transfer more calculations and selections intothe query from the client

• Use the same set of APIs for data and metadataqueries

• Return cell properties and properties of themembers in the same query

• Automate analysis with fewer steps

In this document, we will provide anoverview of MDX, its critical implementationaspects, and compare its interface with a reportwriter language, highlighting similarities anddifferences as relevant. We will also describespecific details of MDX query executionsemantics through examples. A solution sec-tion to demonstrate migration of existingreport writer-based queries into the MDX syn-tax is included. All the example queries assumethe Sample: Basic database as the queried datasource.

MDX (Multidimensional Expressions) is adeclarative query language that can be used to

MDX (Multidimensional Expressions) is a new data extrac-tion mechanism introduced in Hyperion Essbase AnalyticServices release 7.0 (herein referred to as “Essbase”), that

provides a method for forming complex and robust multidimen-sional queries.

[ ]

HYPERIONESSBASESERVER

REPORT SCRIPT

FORMATTED REPORTOUTPUT IN TEXT

MDX QUERY

MDX QUERYRESULT IN

BINARY

MDXRELATED

API'S

CLIENT APPLICATION

(e.g. END-USER QUERY AND REPORTING

TOOL)

REPORT WRITERINTERFACE MDX INTERFACE

tion, on the other hand, provides several variants that enable a more comprehensiveselection.

For example, Descendants (<member>,<layer>, SELF) returns the members of a par-ticular generation or a level in a sub-tree/sub-hierarchy rooted at the <member>. To returnthe same set of members in report writer, youhave to use Descendants (<member>).Toreturn all the members in the sub-tree rooted atthe member, use Gen or Lev command toreturn all the members of a generation or alevel of the entire dimension, and, finally, usethe Link command with an And operator.

Another example is the MDX Uda functionthat takes as its argument the root member of asub-hierarchy in a dimension of interest. Thefunction returns members with the specifiedUDA in the sub-tree. The report writer UDAcommand, in contrast, only works for the top-most member of the dimension. As a result,you have to use the Link command to pruneout members not in the sub-tree in the dimen-sion of interest.

MDX also provides functions that have nocounterparts in the report writer interface,such as the LastPeriods function, which can beused to analyze a sales trend over the last nmonths starting from a given month. Anotherexample is the ParallelPeriod function used tocompare same-period metrics in a prior year.OpeningPeriod and ClosingPeriod can be usedto achieve Time Balance functionalities similarto those provided by the custom TB First, TBLast outline tags.

1. For more information on a complete list ofMDX functions implemented, please refer to

Report writer commands enable a report to bedefined in terms of columns and rows acrossone or more pages. The equivalent construct inMDX is the axis – columns, rows and pages areconsidered three of the possible axes. A querymay have only one or two axes as well as threeor more (the maximum number that can beused within a single query is 64). An optionalslicer axis defines a point of view for the query.

MDX does not support functionality similarto the report-writer formatting commandssuch as PAGEHEADING. The resultant datastructure is not a text report, and it is left to theclient application to format results for presen-tation.

Both MDX and report writer support the ability to display query output using eithermember name or alias. MDX supports the dis-play and use of both in the same query. Asdescribed later, member attributes and cellproperties can also be presented to the clientthrough the MDX APIs.

Report writer member selection commandsenable construction of queries based on mem-ber (hierarchical) relationships in an outline.MDX supports a much richer set of functionsfor the same purpose. For example, the mem-ber relationship function, descendants, isexposed in the report writer in two variants –Descendants (all members in a sub-tree/sub-hierarchy rooted at the member whose descen-dants are desired) and Idescendants (same asdescendants but includes the rooted member inthe result set). The MDX Descendants func-

[ ]

Unlike dynamic-calc members, calculatedmembers are not considered part of the Essbaseoutline and will not be returned in functionsthat return a set of members from metadata.For example, the result of the MDX expressionYear.Members includes the member Qtr1,which is a dynamic calc member. In contrast, aMDX calculated member is defined only forthe duration of a query. It is not part of thedatabase outline, and metadata functions donot include such members in their result sets.

Consider a calculated member definitionsuch as:

MEMBER [Year].[MyQtr] as 'Feb +Mar + Apr'

The calculated member MyQtr will notappear in the result of the functionYear.Members, which will be resolved based onthe database in Essbase. Therefore, a calculatedmember has to be explicitly specified wheneverit is needed in a query.

For example, assume you must create a newtype of scenario that will indicate the differencewith the last quarter’s value.

the MAXL DML documentation in the EssbaseXTD Analytic Services 7.0 Technical Reference.

MDX, like report writer, supports both meta-data and data-based sorting. An example ofmetadata-based sorting is sorting by membername or generation number. MDX functionslike Filter, TopCount, and others provide functionality similar to report writer data rangecommands to restrict the range of selecteddata.

Whereas report writer allows custom calcula-tions to be performed on the result set of aquery, MDX allows custom calculations to bedefined within the scope of a query itself andproduces the result in the output. This isaccomplished through calculated members. Acalculated member is a member with a specificcustom formula defined for the duration of aquery and is similar to a dynamic-calc memberdefined in an Essbase outline. A calculatedmember can use a rich set of computation andreferencing primitives.

[ ]

WITH MEMBER Scenario.[Qtr to Qtr Variance] AS 'IIF (Is (Year.CurrentMember, Qtr1),

0, Year.CurrentMember - Year.CurrentMember.PrevMember

)'SELECT{ Scenario.Children, [Qtr to Qtr Variance] } on Columns,Year.Children on RowsWHERE (East, [100], Sales)

ber along Year dimension has a previous member at that generation – for the first member, for example January or Qtr1, IsValidwill return False. Thus, you can rewrite thesame formula so that it works on members ofall generations in Year dimension as follows.

Note that [Qtr to Qtr Variance] is specifiedexplicitly in the column axis. For Qtr1, there isno previous quarter – so the calculated mem-ber formula handles a special case for Qtr1 andevaluates the [Qtr to Qtr Variance] as 0.

The expression IsValid (Year.CurrentMember.PrevMember) returns True if the current mem-

[ ]

East 100 Sales

Actual Budget Variance Variance % Qtr to Qtr Variance

Qtr1 6292 5870 422 7.1891 0

Qtr2 7230 6760 470 6.95266 938

Qtr3 7770 7300 470 6.43836 540

Qtr4 6448 5570 878 15.763 -1322

WITH MEMBER [Scenario].[Qtr to Qtr Variance] as 'IIF (IsValid (Year.CurrentMember.PrevMember),Year.CurrentMember - Year.CurrentMember.PrevMember, 0

)'SELECT{ Scenario.Children, [Qtr to Qtr Variance] } on Columns,Year.Members on Rows FROM Sample.Basic WHERE (East, [100], Sales)

East 100 Sales

Actual Budget Variance Variance % Qtr to Qtr Variance

Year 27740 25500 2240 8.78431 0

Qtr1 6292 5870 422 7.1891 0

Jan 2105 1960 145 7.39796 0

Feb 2061 1920 141 7.34375 -44

Mar 2126 1990 136 6.83417 65

Qtr2 7230 6760 470 6.95266 938

Apr 2258 2110 148 7.01422 132

May 2347 2190 157 7.16895 89

Jun 2625 2460 165 6.70732 278

Qtr3 7770 7300 470 6.43836 540

Report writer interface lets you define thequery in a declarative fashion – but the reportwriter output is in text. As a result, if you aredeveloping a custom application using thereport writer interface, you have to parse thereport output before you can do any applica-tion-specific processing. You may have to usespecial formatting commands, to identifyinformation like member name/alias/pagebreak etc. Providing an application with aspreadsheet grid using the grid API requires anumber of API calls that use a number of datastructures in order to specify the query, whichcan be complex when the query is not based onplain, hierarchy operations. The only equiva-lent of MDX is the Grid API’s free-form APIssuch as EssGBeginReport(). However, thisworks only for limited kinds of reports and willbe deprecated in future Essbase releases. MDXsupports a powerful expressive language as wellas a set of APIs to introspect the contents of theresult set.

2. Transfer more calculations and selectionsinto the query from the client

One of the unique aspects of MDX is the abilityto write a query that can access sets of mem-bers/data values that is completely differentfrom the set of members/values reported in thefinal query output.

For example, assume you are responsible forthe Eastern Region, and you must analyze thebudgeted marketing dollars for products in Q2that had Q1 sales in excess of $1,000. You wishto return cells for Budget and Q2 for East basedon data from Actual and Q1 for East.

This query can be written in MDX as follows.

The addition of a calculated member in aquery does not affect the database outline andhence no database restructuring is needed. Inaddition, this new member (assuming it isalong dense dimensions) does not increase thesize of the big block – the unit of data thatEssbase server internally needs to allocate inmemory for calculating dynamic-calc data val-ues -- and hence has no effect on the dynamiccalculation cache.

Readers familiar with the calculation lan-guage in Essbase will notice similaritiesbetween the behavior of certain calculationfunctions and corresponding MDX functions.

Comparison of MDX to Essbase calculationlanguage is outside the scope of this document.In the MDX Calculated Members and Securitysection, we will describe other differences interms of the security model between a calculat-ed member in an MDX query and a formulaattached to a dynamic calc member in theEssbase outline.

In this section we provided an overview ofMDX with the report writer functionality asthe backdrop. We will now discuss why it maybe appropriate to transition your custom queryinterfaces to use MDX.

If you are familiar with reports and are won-dering why you may want to switch to MDX,this section describes specific concepts in MDXnot available in reports.

1. Declarative query as input and set of struc-tures as output

[ ]

interfaces does not change, regardless ofwhether you are interested in the actual datavalues or just the metadata combinations. Forexample, you may want to query for states inthe Eastern region, but are not interested in theactual data values that may exist for thosestates. In this case, you can execute the follow-ing query in data-less mode:

The next query is a data query retrieving theactual sales in Qtr1 for Colas in the Eastern-regional states:

The entire query uses data for the Easternregions. The Filter() expression prunes outthose Level-0 products based on the ActualSales numbers in Qtr1 – note that the queryoutputs the Budget numbers for Qtr2, whereasthe Actual values for Qtr 1 were used duringquery execution.

In a subsequent section (MDX QueryExecution Order), we will describe in moredetail the concept of a query context as itapplies to MDX query execution.

1. Same set of APIs for data and metadataqueries

The querying syntax as well as output processing

[ ]

SELECT {(Budget, Marketing)} on Columns,Filter (

Product.Levels(0).Members, (Qtr1, Actual, Sales) > 1000

) on RowsWHERE (East, Qtr2)

East Qtr2

Budget

Marketing

100-10 490

200-10 910

200-40 310

300-10 390

300-20 250

400-10 130

400-30 90

SELECT Children (East) on ColumnsFROM Sample.Basic

SELECT Children (East) on Columns,Children (Colas) on RowsFROM Sample.BasicWHERE (Qtr1, Actual, Sales)

[ ]

Note that in both cases the query uses thesame children operator to query for states inthe Eastern region. The output processing isalso identical. Logically, an MDX-API basedclient program may be interested in

a.) finding the number of tuples (known inMDX as members and cross-members )on thecolumn axis(number of states in this case)

b.) finding the tuple at ith position ( i.e. getname of the ith state).

Invoking the function EssMdxSetDataLess()before submitting a query for execution tellsthe server that the query is interested in retriev-ing just the metadata. Metadata queries may bebeneficial in certain types of screening. Notethat although a query may be interested inobtaining only metadata, the selection criterionfor the metadata itself could be based on data.For instance, a query may retrieve just thoseProduct-Market combinations for which quar-ter-to-quarter variance is significant.

1. Property support: the ability to return cellproperties and properties of the members inthe same query

The MDX language includes constructs thatcan be used to request Grid-API style cell-prop-erties in the query output. Such propertiesidentify whether a cell is read-only, dynamical-ly calculated etc. In addition, MDX has con-structs that allow certain member properties tobe displayed in the output as well. MDXextends the notion of properties to includeuser-defined attributes (UDA) and attributedimensions in Essbase. For example, you canrequest Color and Size properties for everymember of the Product dimension (Color andSize are attributes of product) or if you want to

know whether a market is a “Major Market” forevery member from Market dimension in thequery result. Report writer does not supportcell-properties. You can get some of the mem-ber properties (e.g. use {IndentGen} and parsethe output to figure out the generation number). However, such a task is extremelycumbersome and error-prone in report writer.Neither Grid API nor report writer supportsthe MDX style of exposing user-defined attrib-utes or attribute dimensions as properties.

2. Automating analysis with fewer steps

You can write MDX queries to automate theproduction of reports that would otherwiseneed substantial human intervention. Forexample, you may want to report on the mar-kets at the regional level – you want the statelevel details for the regions with a negative vari-ance from last quarter. You might want toreport on the states with substantial (30% andabove for example) contribution to its region’ssales. The richness of the MDX expressionmodel makes these queries straightforward.

3. MDX is not an end-user interface for churn-ing out end-user reports from the EssbaseServer. Report writer has a rich formatting sup-port and you can write a report to output thequery result in a presentable fashion. Of course,you can also use the powerful Essbase spread-sheet Add-in interface to design robust Excelspreadsheets to retrieve data from Essbase.

On the other hand, MDX lets the user spec-ify the query and supports a set of APIs to navigate over the query results. The EssbaseMultidimensional Access Language (MAXL),

An axis consists of members retrieved from oneor more dimensions. Two different axes maynot select members from the same dimensionfor output. However, an axis may internally usea dimension that is already specified as an out-put dimension in a different axis for computa-tion/member-filtering purposes. In addition tomembers and cross-members (referred to astuples in MDX), MDX introduces a new entitycalled SET. A set is an ordered collection oftuple(s). All tuples within a set must have thesame dimensionality and the dimension orderof members within each tuple in a set must beidentical.

MDX query execution involves independentprocessing of the set definitions along each axispresent in the query and then returning thedata points at the intersection of all possiblecombinations of members (member combina-tions) from all axis. Let us define MDX contextas a calculation context that holds one memberfrom every dimension present in the cube.Contents of MDX context are well defined bythe query execution semantics as explainedbelow.

MDX query execution begins with a defaultMDX context. The context has the dimensionroot members for all regular dimensions.Hence,the smallest valid MDX query support-ed in Essbase is “SELECT” which returns thecell-value at the intersection of top membersfrom each dimension (and no members fromattribute dimensions). In Sample/Basic, theintersection is (Year, Measures, Product,Market, Scenario).

for example, chooses to display the queryresults in a two-dimensional format. Use ofthese APIs is required to create a reportinginterface.

4. MDX is not an interface for churning outdatabase exports, or very large production-typereports from the Essbase Server. The reportwriter interface supports streaming of theresult set. Neither the server nor the clientneeds to hold on to the entire result set. Youmay potentially write a report to back up a por-tion of the database without needing the serverto go offline. The Grid API (used by the spread-sheet interface) does not stream in the serverand in the client. As a result, when a large queryis executed, the server has to hold on to theentire result set before sending it to the client.

MDX, on the other hand, supports server-side streaming and as a result the server doesnot need to hold on to the entire result set. Theserver is capable of sending partial results tothe client. In order to provide easy navigationover the query results, the API accumulates theentire result, before returning control to thecaller. Even though the API stores the queryresults in an optimized compressed form, theclient may not have enough memory to hold onto the entire result set.

Recall that an MDX query consists of a datarequest clause (SELECT), a context clause(FROM) and an optional point-of-view clause(WHERE). The SELECT clause determines theaxis dimensions and up to 64 different axes canbe specified in a single query. In practice, how-ever, between 2 and 4 axes are more common.

[ ]

Query:SELECTResult:(Year, Measures, Product, Market, Scenario)105,522

the MDX execution does not need the MDXcontext to resolve the set definition.

In contrast, if the named set definition is thefollowing, then the TopCount function execu-tion needs to use MDX context (since the setconstruction is a function of data values in thecube).

If the slicer specifies to use Qtr1, we will getthe top 2 children based on Qtr1 sales, whereasif the slicer specifies to use Qtr2, we will get thetop 2 children based on Qtr2 sales.

Let us change the above query to add a slicerclause as follows.

First, Children ([100]) will be resolveddirectly from the outline into [100-10], [100-20] and [100-30]. Next, the set will be prunedto include just the top 2 products based ontheir sales values.

In order to get any cell data values fromEssbase, we need the members from all regulardimensions and, optionally, from attributedimensions. The sales value for [100-10] doesnot resolve into one data point – representativemembers from the missing dimension(s) arerequired and hence are taken from the MDXcontext.

Then the Slicer clause (i.e. singleton set def-inition in the WHERE clause), if present, isprocessed. Member(s) corresponding to thedimension(s) present in the slicer override thedefault context to form the new MDX context.This new context is used for the rest of theMDX query execution. Note that the slicerclause can only specify singleton membersfrom each dimension.

For example, the following query

returns the data point at the intersection of(Qtr1, East, Measures, Product, Scenario). Notethat Measures, Product and Scenario are theroot members of the respective dimensions notexplicitly specified in the query, and are part ofthe POV by default.

MDX also has an optional WITH clause thatcan be used to define calculated members andnamed sets.

The named sets are processed in order inwhich they are defined in the query. Note thatnamed set evaluations may or may not need theMDX context. For example, if the named setdefinition is

[ ]

SELECT WHERE (EAST, QTR1)

(East, Qtr1, Measures, Product, Scenario)5,380

With:

Set Favourite_Colas as ‘{[100-10],[100-30] }, :

WithSet Favourite_Colas as 'TopCount(Children ([100]), 2, Sales)':

With Set Favourite_Colas as 'TopCount(Children ([100]), 2, Sales)'::Where {(EAST, QTR1)}

So the comparison to find top 2 will takeplace among the data values below:

(QTR1, Sales, [100-10], EAST, Scenario),

(QTR1, Sales, [100-20], EAST, Scenario),

(QTR1, Sales, [100-30], EAST, Scenario)

1. As an optimization the named-set defini-tions are processed only if they are later refer-enced in the query. If they’re not actually used,Essbase spends no time building them.

After any necessary named sets are resolved,the individual axis sets (i.e. set definitions alongmultiple axes) are resolved. The axis set resolu-tion may or may not require MDX context forthe same reason explained for named sets.

After all the axes sets are resolved (i.e. all themember combinations/tuples are found for aset), the final retrieval stage pulls data-values

for all possible combinations of members (i.e.member combinations) from all the axes, usingMDX context, as needed.

Let us next consider a slightly more advancedrole that the MDX context plays using a class offunctions called Iterative functions.

An iterative function in MDX is a functionthat works on a set of tuples performing anoperation on every tuple in an iterative fashion.For example, the Sum function

SUM (<input-set>, <numeric-value-expression>)

evaluates a numeric-value-expression for everytuple in the input set, adds all these values up toreturn the total. The following are some exam-ples of MDX functions that operate on sets iter-atively:

[ ]

SUM MIN MAX

AVG NONEMPTYCOUNT FILTER

TOPCOUNT BOTTOMCOUNT TOPSUM

BOTTOMSUM TOPPERCENT BOTTOMPERCENT

ORDER GENERATE

[ ]

All the functions listed above take an expres-sion argument like SUM. However, the expres-sion type is different for each function. Forexample, the ORDER function requires either anumeric or string expression, GENERATE takesa set as the second argument and the FILTERfunction takes a conditional expression. Theexpression is numeric for the remaining func-tions.

Logically, an iterative function works as follows:

1. For every tuple in input set

2. Begin

3. Save the current MDX context (C1)

4. Create new MDX context (C2) overridingthe iterating tuples on C1.

5. Evaluate the expression using C2

6. :

7. : Iterative function specific tasks e.g.cumulatively add the values in case of SUM

8. Restore the saved context (C1) i.e. the cur-rent MDX context at this point is C1.

9. End

Now, let us consider an example to illustratethe above logic in steps. The following querysorts the Colas (i.e., Children of [100]) based onActual Sales in Qtr1 and displays the sortedcolas’ Budgeted Sales and Marketing in Qtr2

The ORDER function is specified in the set‘Children ([100])’ (i.e. {[100-10], [100-20],[100-30]}) to iterate upon.

The expression used for ordering is '(Qtr1,Actual)' – a numeric expression that needs to becomputed for each element of the set. The factthat the cell value of (Qtr1, Actual) is requiredis implicit because it is a numeric expression.Recall that each axis in an MDX query is evalu-ated independently. Thus, the context at thebeginning of the execution (using the abovelogic) of the ORDER function is the tuple([Qtr2], [Measures], [Product], [Market],[Scenario]) where Qtr2 is obtained from theslicer clause.

In the first iteration the [Product] is replacedin context with [100-10], the first member inthe set. Thus the tuple for the first iteration ofORDER is ([Qtr2], [Measures], [100-10],[Market], [Scenario]).

The numeric value expression is evaluatedwith this context, and thus the expression trans-lates into the retrieval of the data point ([Qtr1],[Measures], [100-10], [Market], [Actual]).

The second iteration starts with the sameMDX Context as the first iteration, namely,([Qtr2], [Measures], [Product], [Market],[Scenario]). This time, [100-20] will replace[Product] to form the new MDX context.

SELECTCrossJoin ({Budget}, {Marketing,Sales}) on Columns,Order (Children ([100]), (Qtr1,Actual)) on RowsWHERE (Qtr2)

Qtr2 Market

Budget Budget

Marketing Sales

100-30 450 3400

100-20 1160 8800

100-10 1800 17230

So the expression evaluation will use([Qtr2], [Measures], [100-20], [Market],[Scenario]) as the context and thus the expres-sion translates into retrieval of the data point([Qtr1], [Measures], [100-20], [Market],[Actual]).

The ORDER function finally sorts inputtuples based on these values and arranges thesetuples in ascending order (the default order).

All other iterative functions operate similar-ly. After evaluating the expression, the actiontaken depends on the function. In case ofORDER, the action is to sort tuples in input setbased upon values evaluated. In case of SUM,the action is to add up all the value. In case ofGENERATE the action is to create an output setby performing a “UNION” of all sets.

Continuing the discussion on current con-text, it is worthwhile to point out a special func-tion called CURRENTMEMBER (which is nodifferent from the corresponding calculatorlanguage function) which takes as input adimension and is used to refer to the memberpresent in the current MDX context during thecourse of execution.

The calculated member evaluation is like anyother numeric expression evaluation.Depending on the context in which such amember is used, it can be resolved either at axesresolution time or during the final retrievalstage. For example, consider the query:

To return ([100-10], [Revised Budget]) cellvalue, the expression ‘Budget * 0.5’ will be eval-uated in the context of ([Qtr1], [Sales], [100-10], [East], [Scenario]).

To return ([100-20], [Revised Budget]) cellvalue, the same expression will be evaluated inthe context of ([Qtr1], [Sales], [100-20], [East],[Scenario]).

Next, we explore the notion ofSOLVE_ORDER, a construct that enablesremoval of potential ambiguities in a query execution.

_

A SOLVE_ORDER clause can be specified fol-lowing the definition of a calculated member todisambiguate the order of evaluation of calcu-lated members in a query that has more thanone such definition. We illustrate the use ofsuch a clause by means of an example.

Q1 and M are two calculated membersdefined on Year and Measures dimensionsrespectively in the following query.

[ ]

With Member [Scenario].[Revised Budget] as 'Budget * 0.5'::SELECT {Actual, [Revised Budget]} on Columns,Children ([100]) on RowsFROM (Qtr1, Sales, East)

We have a question as to whether to calculatethe (M, Q1) cell by the M formula or by the Q1formula.

Let us compute the data value at the intersec-tion (Q1, M, Product, Market, Actual) using thequery execution rules we have learned thus far.There are two potential ways in which the datavalue can be computed: , using the definition ofthe calculated member Q1 or the definition of M.

If the formula for Q1 is evaluated first, thenthe result will be calculated as follows:

Value of (Q1, M, Product, Market, Actual) =

Value of (Jan, M, Product, Market, Actual) +

Value of (Feb, M, Product, Market, Actual) +

Value of (Mar, M, Product, Market, Actual)

In this case, the value would be calculated as55.1 + 55.38 + 55.26 = 165.74

If, however, the formula for M is evaluatedfirst, then the result will be calculated as follows:

Value of (Q1, M, Product, Market, Actual) =

Value of (Q1, Margin, Product, Market,Actual) * 100 /

Value of (Q1, Sales, Product, Market, Actual)

In this case, the value would be calculated as52943 * 100 / 95820 = 55.25

As can be seen from the above two examples,there is a need for disambiguation and the solveorder clause enables override of the calculationorder to achieve the desired end result. In thepresence of SOLVE_ORDER clause, Formulacorresponding to the member with highestsolve order will be evaluated first. So, if theabove query were altered as follows,

[ ]

WITHMEMBER [Year].[Q1] as ‘Jan + Feb + Mar’MEMBER [Measures].[M] as ‘Margin * 100 / Sales’SELECT {M} on Columns,{Q1} on RowsWhere (Product, Market, Actual)

Product Market Actual

Margin Sales M = Margin * 100/Sales

Jan 17,378 31,538 55.1

Feb 17,762 32,069 55.38

Mar 17,803 32,213 55.26

Q1 = Jan + Feb + Mar 52,943 95,820 ???

WITH:MEMBER [Year].[Q1] as ‘Jan + Feb + Mar’, SOLVE_ORDER = 10MEMBER [Measures].[M] as ‘Margin * 100 / Sales’, SOLVE_ORDER = 20:

then the result will be 55.25, which is desired inthis example.

The default SOLVE_ORDER of a calculatedmember is assumed to be 0.

If multiple members at the intersection havethe same SOLVE_ORDER (or no explicitSOLVE_ORDER clause is present), for example,

then the tie is resolved using the order ofrespective dimensions as they appear in theOutline.

Thus, in the above example, since the Yeardimension appears before Measures in theOutline, the formula for Q1 will be evaluatedfirst and the resulting value will be 165.74. Ifyou run the example query without specifyingthe SOLVE_ORDER, both the members areassumed to have SOLVE_ORDER 0 and the tiehas to be resolved using dimension informa-tion. Hence, the result will be the same in previ-ous case, 165.74.

Recall that MDX supports calculated membersto define dynamic calculations.

Calculated members are similar to customformulas that can be attached to dynamic-calcmembers defined in the outline. The advantageof using a calculated member is that no outline

change is required, nor is the cube structureimpacted to execute the custom calculation.While calculated members are functionally sim-ilar to custom member formulas, there is animportant difference in data access privilegesbetween the two.

In the case of dynamic-calc members, theadministrator defines the member and the cal-culation formula associated with the member.Since the administrator is also responsible forenforcing user-level metadata and data securitythrough appropriate filter definitions, it isassumed that the administrator is cognizant ofsecurity requirements for the dynamically cal-culated members as well. Thus, the formulaassociated with a dynamically calculated mem-ber does not enforce metadata or data security-members and cell data which is otherwise hidden from the user can be used in the calcu-lation.

In MDX, in contrast, the end-user can definethe calculation in a query. The administratormay not know about the formula and thedependent data-accesses during query execu-tion. Therefore, the MDX implementationensures that execution of a calculated memberformula only uses data and metadata that theuser has access to. The value of any data-pointreferred by the formula execution that the userhas no access to is assumed to be MISSING.

For example, while evaluating a calculatedmember formula, if the Budgeted Sales for Qtr2is not accessible to the user (suppressed via adata security filter), it will be assumed to beMISSING.

[ ]

:MEMBER [Year].[Q1] as ‘Jan + Feb +Mar’, SOLVE_ORDER = 10MEMBER [Measures].[M] as ‘Margin *100 / Sales’, SOLVE_ORDER = 10:

Functions such as <IDesc and <Gen in reportwriter and Descendants() and Members() inMDX return a collection of members. Betweena report script and an equivalent MDX query,there is a difference in the order in which mem-bers are returned in the result set. Whereas thereport writer interface returns members of thedimension tree in an order where all children ofmembers appear before the parent, MDX meta-data-based set-functions return members in anorder where the parent appears before the chil-dren. The MDX function Hierarchize (<set>,POST) allows you to reorder the elements of<SET> in post-order form if desired.

Report writer and other interfaces like Grid-API use dynamic time series (DTS) membersdefined in the outline along with another timedimension member that specifies the latesttime-period. MDX does not recognize DTSmembers defined in the Essbase outline direct-ly. However, MDX can return the same value asreturned by requests such as Q-T-D(Aug) (i.e.sum of the values up to month of August in thecurrent Quarter) through functions such asQTD(), YTD(), etc.. These functions take thetime dimension member (that one would spec-ify to identify the latest time period in thereport writer interface) as an argument.Internally, MDX uses the generation numberfor the corresponding Essbase member Q-T-D/Y-T-D. For example, the MDX expressionQTD(Aug) returns the set of all time dimensionmembers of the generation of Aug up to and

including Aug, that fall in the quarter thatincludes Aug.

We can define a calculated member to returnsum/min/max/average of the values for the setreturned by the set expressions QTD(), YTD(),etc. Defining a calculated member to Sum overthe set returned by MDX QTD() function islogically equivalent to Q-T-D followed by<LATEST latestmember syntax in report writer.For example:

WITH

MEMBER Measures.[QTD Margin] AS'Sum (QTD(), Margin)' ...

You can alternately use PeriodsToDate(<Layer>, <member>) in place of xTD() func-tions. For example, if you have a generationnamed Quarter already in your database, thenPeriodsToDate (Quarter, Aug) is equivalent toQTD (Aug). Note that PeriodsToDate works onany dimension whereas the xTD() functionscan work only on a Time dimension.

There are major differences in the way sort-ing commands work in MDX and report writer.In report writer, there are different commandsto sort the members of a dimension and therows of a report. In MDX, there is one functionORDER (<set>, <expression>) that performsall sorting. It evaluates the input value expres-sion iteratively for every tuple in the set, and theexpression can provide names, generation orlevel numbers, property or cell values to com-pare. Furthermore, sorting on multiple criteriacan be carried out by nesting calls to Order. Forexample, the following report snippet andMDX snippet are logically equivalent:

[ ]

However, the report writer sorting com-mands are stateful. That is, once a sort com-mand is specified in a script, the sortingrequirement will be applicable to all subsequentmember selection commands in the script. TheMDX Order() function, on the other hand, isapplied to the input set to the function, and theresult of the Order() function is a sorted set.Any other set expressions appearing in the sameMDX query will not be effected by the presenceof a prior ORDER command. Thus while<SORTNONE functionality is required inreport writer language, such a command ismeaningless in MDX.

Secondly, report writer sorting commandsare applied to the members added with a member command such as <Children,<Descendants, etc. The MDX Order() functionworks for the entire input set, regardless of howit was created. For example,

in report writer returns members in the follow-ing order: Nov, Feb, Jan, Mar.

Whereas

returns the members in the following order:Feb, Jan, Mar, Nov

The MDX expression

returns the members in the order{Nov, Feb, Jan,Mar}, since the Order() function is only appliedto the children of Qtr1.

We will compare report writer commands suchas RESTRICT/TOP/BOTTOM /ORDERBY thatare used to accomplish filtering with correspon-ding functionality in MDX.

The report writer retrieves all the data valuesas specified in the query and then executes thedata- related filtering commands on the result.In other words, these commands are post-processing operations in report writer.

On the other hand, equivalent MDX func-tions are executed as a part of the individualaxis processing. Since each of the axis isprocessed independently, the context of the exe-cution may not be intuitive from report writeruser’s perspective. Context processing rulesdescribed in section <> apply for MDX execu-tion.

Consider a simple example,

The set definition along rows will be execut-ed independently of the contents of what isspecified on Columns. Since the <numeric

[ ]

<SORTGEN<IDESCENDANTS Market

ORDER (DESCENDANTS (Market),Market.CURRENTMEMBER. GEN_NUMBER)

<SORTMBRNAMESNov<Children Qtr1

Order ({ Nov, Children(Qtr1)},Year.CurrentMember.Member_name)

{ Nov, Order (Children (Qtr1),Year.CurrentMember.Member_name)}

SELECT CrossJoin ({Qtr1, Qtr2}, {Sales})on Columns,TopCount (Market.Levels(0).Members,5) on RowsFrom Sample.Basic

value expression>, which is used to identify thetop 5 members along Markets, is not specified,TopCount function will retrieve the value usingthe current context of execution. In this partic-ular case, the root member along Measuresdimension will be used for evaluation, which isdifferent from Sales specified on the columns.

Secondly, each of these report writer com-mands can be used once in a script in effect. Iftwo or more different commands (TOP/BOT-TOM and ORDERBY) are specified, then all ofthem have to work on the same row dimensiongrouping. On the other hand, the equivalentMDX functions have no dependency amongeach other. For example, TOPCOUNT imple-mentation has no assumption about the opera-tions/functions used to create the input set.

Lastly, the report writer TOP/BOTTOM andORDERBY commands work on a group ofmembers from the innermost row dimensionby default, though the grouping dimension canalso be input explicitly. The equivalent MDXfunctions TOP(/BOTTOM)COUNT orORDER have no such assumption about thedimension grouping. For example, the follow-ing report will get Top 5 Products for everymarket.

Whereas the MDX expression

TopCount (

CrossJoin (Children (Market),Descendants (Product)),

5,

(Budget, Dec)

)

will return only 5 tuples of (Market, Product)combinations.

In order to get the same result as the abovereport script i.e. top 5 Products for everyMarket member, use Generate function asshown in the following MDX query:

[ ]

<Sym<Column (Scenario, Year)Actual BudgetJan Dec<Top ( 5, @DataCol(4))<Row (Market, Product)<children Market<Idescendants Product!

SELECTCrossJoin ( {Actual, Budget},{Jan, Dec}) on Columns,Generate (

Children (Market),CrossJoin (

{Market.CurrentMember},TopCount (

Descendants (Product),5,(Budget, Dec)

))) on Rows

The Generate function will iterate througheach child of Market, and for each of those willcombine (using CrossJoin) that market childwith the top 5 descendants of Product.

Any multidimensional query language musthave first class support to handle processing ofmissing or non-existent cell values.

The SUPMISSINGROWS command in reportwriter suppresses the display of all rows thatcontain only #MISSING values.

The equivalent construct in MDX is the NONEMPTY clause, which, if present on an axis spec-ification will result in suppression of thetuple(s) that contain only #MISSING values forall possible combination of tuples from otheraxes.

SUPMISSINGROWS only works for dimen-sions formatted to appear along rows, whereasthe NON EMPTY clause can be specified for anyaxis. For example, NON EMPTY on columns willcheck and suppress, if needed, tuples presentalong the columns. In addition, NON EMPTYcan be specified for any combination of the axespresent in the query.

[ ]

Measures

Actual Actual Budget Budget

Jan Dec Jan Dec

East Product 1732 2037 2080 2120

East 100 924 1026 960 990

East 100-10 837 867 860 830

East 400 466 501 600 580

East 200-40 267 383 310 400

West Product 2339 2448 2980 2710

West 300 755 971 830 950

West 200 752 820 850 860

West Diet 663 629 850 730

West 100 378 223 830 530

South Product 997 1141 1330 1270

South 100 329 432 540 640

South 100-10 244 327 370 460

South Diet 355 404 490 430

South 200 480 496 520 390

Central Product 2956 3154 3550 3570

Central Diet 1080 1064 1340 1300

Central 200 751 753 1060 1220

Central 100 724 792 900 890

Central 300 790 824 930 810

Secondly, SUPMISSINGROWS logic workson every page in the report. On the other hand,NON EMPTY functionality logically works on allpossible member combinations on all axes.

Consider an example,

The SUPMISSINGROWS will cause display ofonly the eligible Products per Market page inthe report. (It may so happen that one productsuppressed in one page (market) is displayed onanother page (market), depending on the datadistribution). By contrast, NON EMPTY logical-ly takes into account all possible member com-binations on other axes.

For example:

NON EMPTY will suppress the productsmissing for every (Scenario, Measure) combina-tion specified in the query for all the markets. Itmay so happen that one product has all missingvalues for some markets, but not the others.Such a product is not suppressed from the out-put as the product has at least one non-MISSING value for at least one market.

Conceptually, the Report writer output canbe viewed as outputting a multi-cube structure,whereas the MDX output is a hypercube.

[ ]

<Page (Market)<Children Market <Row<Idescendants Product{SUPMISSINGROWS}<Column (Scenario, Measures)Actual BudgetSales COGS Profit

!

SELECT Crossjoin ({Actual, Budget}, {Sales, COGS, Profit}) on Columns,NON EMPTY Descendants (Product) on Rows,Children (Market) on PagesFrom Sample.Basic

[ ]

<COLUMN<PAGE<ROW

<ASYM<SYM

On COLUMNSOn ROWSOn PAGESOn CHAPTERSOn SECTIONSOn AXIS (n) where n is the axis number

Report writer supports up to 3 axes. MDXsupports up to 64 axes. The first five axesare named as COLUMNS (0), ROWS (1),PAGES (2), CHAPTERS (3) and SECTIONS(5) respectively. The axes numberingincreases from faster to slower movingaxes.

Operations like suppress missing or filteringcan only be done on member combinationsalong Row in report writer.

MDX treats all axes uniformly in the sensethat all such operations are valid for sets onany axis.

MDX lets you define the set in any way youwant.

For example, the MDX set expression“{(Actual, Sales), {Budget, Profit)}” is logi-cally equivalent to the report-script snippet“<ASYM Actual BudgetSales Profit”.

Whereas “CROSSJOIN ({Actual, Budget},{Sales, Profit})” along columns will producea symmetric output like report snippet“<SYM Actual BudgetSales Profit”.

MDX does not need to assume symmet-ric/asymmetric columns, as it deals with theway the set is defined.

[ ]

<ALLINSAMEDIM mbrName

<ALLSIBLINGS mbrName

<ANCESTORS mbrName <ATTRIBUTE attMbrName

<CHILDREN mbrName<CURRENCY

targetCurrency<DESCENDANTS mbrName

<DIMBOTTOM mbrName

<DIMTOP mbrName

GEN name, dimension LEV name,dimension

<GEN(dimension,genNumber)<LEV(dimension,levNumber

<IANCESTORS mbrName <ICHILDREN mbrName

<IDESCENDANTS mbrName<IPARENT mbrName<LATEST mbrName

<LINK (extractionCommand[operator extractionCommand])

<MATCH("Member"|"Gen"|"Level","Pattern")

<OFSAMEGEN mbrName <ONSAMELEVELAS mbrName

<PARENT mbrName <TODATE (formatString,

dateString)<UDA (dimName, udaStr)

<WITHATTR (dimName, "opera-tor", value)

[mbrName].DIMENSION.members or[mbrName].Members[mbrName].Siblings or Siblings([mbrName])

Attribute ( [attMbrName] )

[mbrName].Children or Children([mbrName])Descendants ([mbrName],[mbrName].GENERATION, AFTER)[mbrName].DIMENSION.Levels(0).MembersAncestor (mbrName,mbrName.Dimension.Generations(1))[name].Members

dimension.GENERATIONS( genNumber).Members dimension.LEVELS(levNumber).Members

{CHILDREN ([mbrName], mbrName }Descendants([mbrName]){[mbrName], [mbrName].PARENT}

UNION, INTERSECTION, EXCEPT,EXTRACT

[mbrName].GENERATION.Members[mbrName].LEVEL.Members[mbrName].PARENTTODATE (formatString, dateString)

UDA (dimName, udaStr)WITHATTR (member, STRING_LITERAL, [ signed_numeric_literal |character_string_literal ] )

No equivalent MDX construct available in 7.0

No equivalent MDX construct available in 7.0

Please see the section on MDX member Ordering.

In case of MDX, the name refers to user definedGeneration / Level Name. Default generation/levelnames like Gen0, Gen1, Lev0, Lev1 are not supportedin MDX. Usedimension.Generations(genNumber).MembersOr dimension.Levels(levelNumber).Members syntax toselect members of a particular generation or level.

No equivalent MDX construct available in 7.0

Please see the section MDX and Sorting.

MDX does not support D-T-S members in ESSBASE.Please see the section MDX and Dynamic Time SeriesMembers Support.

No equivalent MDX construct available in 7.0

[ ]

<SORTNONE

<SORTASC<SORTDESC

<SORTGEN <SORTLEVEL

<SORTMBRNAMES <SORTALTNAMES

ORDER (<set>, <value_expres-sion>, BASC | BDESC )

The value expression has to bewritten using <dimension>.CURRENTMEM-BER.propertyWhere propertycan beGEN_NUMBER LEVEL_NUMBERMEMBER_NAME,MEMBER_ALIAS

Equivalent MDX construct not required.

Please see the section MDX and Sorting

[ ]

<ORDERBY

<RESTRICT

<TOP

<BOTTOM

ORDER (<set>,<numeric_value_expression>,BASC|BDESC)

FILTER (<set>,<conditional_expression>)

TOPCOUNT( set , index[,numeric_value_expression ] )

BOTTOMCOUNT ( set , index[,numeric_value_expression ] )

Please see the section MDX and AdvancedFiltering Options.

Please see the section MDX and AdvancedFiltering Options

Please see the section MDX and AdvancedFiltering Options

Please see the section MDX and AdvancedFiltering Options

[ ]

SUPMISSINGROWS

All other report writerformat commands

like WIDTH, ZERO-TEXT etc.

NON EMPTY Please see the section MDX andSuppression of Missing Values in Output

MDX does not support any formatting com-mands.

[ ]

All Column or RowCalculation com-

mands

MDX does not support any such com-mands. Calculated members can be usedto perform custom calculations in query.

[ ]

OutMbrAlt

OutAltMbr

OutAlt

OutAltNames

OutAltSelect

Use the Api EssMdxSetMbrIdType andspecify the property MEMBER_NAME orMEMBER ALIAS in DIMENSION PROPER-TIES clause for every axis. The current aliastable will be used to return the alias.

Use the Api EssMdxSetMbrIdType andspecify the property MEMBER_NAME orMEMBER ALIAS in DIMENSION PROPER-TIES clause for every axis. The current aliastable will be used to return the alias.

Use the Api EssMdxSetMbrIdType to setESS_MDX_MEMBERIDTYPE_ALIAS. Thecurrent alias table will be used to return thealias.

Not needed in MDX.

No equivalent MDX construct available in7.0.

, ..

Hyperion is the global leader in Business Performance

Management software. More than 9,000 customers – includ-

ing 91 of the FORTUNE 100 – rely on Hyperion software to

translate strategies into plans, monitor execution and provide

insight to improve financial and operational performance.

Hyperion combines the most complete set of interoperable

applications with the leading business intelligence platform to

support and create Business Performance Management

solutions. A network of more than 600 partners provides the

company’s innovative and specialized solutions and services.

Named one of the FORTUNE 100 Best Companies to

Work For 2004, Hyperion employs approximately 2,600

people in 20 countries. Distributors represent Hyperion in an

additional 25 countries. Headquartered in Sunnyvale,

California, Hyperion – together with recently acquired Brio

Software Inc. – generated combined annual revenues of $612

million for the 12 months ending June 30, 2003. Hyperion is

traded under the Nasdaq symbol HYSL. For more informa-

tion, please visit www. hyperion.com, www.hyperion.com/

contactus or call 800 286 8000 (U.S. only).

© 2004 Hyperion Solutions Corporation. All rights reserved. “Hyperion,” the Hyperion “H” logo and Hyperion’s product names are trademarks of Hyperion. References to other companies and their products use trademarks owned by the respective companies and are for reference purpose only. 4247_0204

,

. . . . . .

1 Note that Hyperion also supports the production of MDX results in XML format through its sup-port for XML for Analysis (XMLA). XMLA opens up new possibilities in the integration ofEssbase-held information in an enterprise. This paper will not discuss XMLA; please refer to theXML for Analysis API Reference in the Essbase Deployment Services technical documentation.