slow fast changing dim

8/10/2019 Slow Fast Changing Dim

1/27

www.odtug.com 1 ODTUG Kscope14

SLOW AND FAST-CHANGING DIMENSIONS INHYPERION PLANNINGWilliam Hodges, The Hackett Group

Abstract

Changing dimensions is a well-known and widely discussed challenge in dimensional data modeling, particularly in the

context of data warehousing. Oracle Hyperion Planning and its underlying dimensional database and engine (Essbase) are not

immune to it. A relatively new Essbase feature called varying attributes is Oracles response to this challenge. Varying

attributes are a powerful feature, but this paper is concerned with situations whose requirements go beyond their capabilities.

The terms fastand Hyperion Planningincluded in the title are meant to unequivocally eliminate the possibility of using

varying attributes for two primary reasons: They do not support continually changing, user-driven attribute assignments, and

they are not supported by Hyperion Planning.1

Several solutions, one of them implemented by The Hackett Group at an S&P 500 company, are presented and discussed in

sufficient detail to facilitate replication. The solutions are all based on dynamically calculated dimension members that read

data values stored as identifiers of what otherwise would have been the members of new additional dimensions and computethe corresponding values. The solution is similar, from a computational point of view, to the dynamic allocation of global

values, with the allocations using as drivers not percents of some total but rather the above mentioned identifiers. Probably

most importantly, the heart of the solution is not dependent on a still-not-available product feature; it could be

implemented, in principle, on any platform capable of modeling dimensionality.

Introduction

Changing Dimensions

A changing dimension is metadata (a data attribute or qualifier) that changes through time and consequently moves a data

point from one analytical grouping to another (i.e., from one bucket to another) within an analytical database. From a data

processing point of view, a changing dimension creates a moving target and forces database designers to create analytical

bridges between what once was and what later is in order to be able to conduct analysis effectively. From a purely technical

point of view, i t calls for software methodologies and/or products that facilitate the implementation of these more complexdesigns. A fast, ever-changing dimension is, for the purposes of this paper, a dimension that can also change any time,

multiple times, as a result of a calculation or user input.

The data warehousing literature offers extensive discussions about changing dimension types and their corresponding

solutions.2 This nomenclature and these solutions have become conventional and are sometimes even built into system

integration tools.3Hyperion Essbase has had since Version 9 a feature known as varying attributes designed to address the

challenges discussed in the data warehousing literature.

This paper is not an effort to conform Hyperion Planning to these now-conventional ways of dealing with changing

dimensions. It is neither an attempt to elaborate on the use of varying attributes. Instead, the paper focuses on the

underlying computational phenomenon, that of changing dimensionalities, and shows how arrays, the foundational

technology within Hyperion Planning, offer opportunities to address requirements that lie beyond the capabilities of varying

1Hyperion Planning Version 11.1.2.1 has a new feature by which Smart Lists in a Hyperion Planning Application can be mapped to dimensions in aReporting Application. It may be the best feature-based solution yet to the modeling requirements discussed in this paper, but it is not a Hyperion Planning

solution per se. A solution using this approach is discussed in Appendix E of this paper.2

Issues well summarized in en.wikipedia.org/wiki/Slowly_Changing_Dimension. Ralph Kimball began to explain this phenomenon at least as early as 1995

in his "Data Warehouse Architect" series of articles in DBMA magazine. The earlier discussions include the April 1996 article "Slowly Changing

Dimensions" (www.kimballgroup.com/html/articles_search/articles1996/9604d05.html). See also Kimball, R, et al. (2010), The Kimball Group Reader,

Indianapolis: Wiley Publishing, Section 1.8 in which Dr. Kimball evaluates his 30 years of experience studying the time variance of dimensions.3

Informatica
http://www.odtug.com/http://www.odtug.com/


2/27

Slow and Fast-Changing Dimensions in HP Hodges


attributes4and beyond the classifications explained in the data warehousing literature. To focus and direct the contents of

this paper, the following requirement was established:

In a Hyperion Planning form

Display for comparison:

YTD Profit at the end of June of the current year based on the metadata of December of last yearAnd:

YTD Profit at the end of September of some future year based on the metadata for January of the sameyear generated by a forecasting algorithm launched by a business rule when the user's input is saved

This business requirement, while a bit convoluted, is not entirely artificial. Hackett consultants have encountered elements of

it in their practice. The requirement clearly indicates that a) the solution must operate within the Hyperion Planning

interactive user environment (it cannot use features that are available only in Essbase) and b) it must support interactive

forecasting of both data and metadata. Consequently, the solution must address the challenges posed by changing

dimensions, as defined in the data warehousing literature.

The above requirement is in fact similar to requirements mentioned in demonstrations of the capabilities of Essbases feature

varying attributes,but it has an additional level of complexity: the metadata must be allowed to change anytime, at the

discretion of a user, without the intervention of a database administrator and without causing a database restructure. Thepaper addresses the problem progressively, by means of an evolving example and a series of increasingly analytically

powerful solutions to the example.

Key Concept

At first sight, the following diagram can be said to represent a 15x7 two-dimensional array.

2010 Sales VolumeNorth South Central East West Other-A Other-B

Chairs 220 168 196 240 180 123 234

Chair-A 128 116 110 141 106 55 117

Chair-B 92 52 86 99 74 68 117

Desks 137 206 207 127 139 123 234

Desk-A 71 98 149 55 66 55 117

Desk-B 66 108 58 72 73 68 117

Lamps 245 140 261 113 171 141 252Lamp-A 123 90 123 59 111 68 117

Lamp-B 122 50 138 54 60 73 135

Tables 236 241 230 242 148 123 252

Table-A 91 119 88 95 95 55 117

Table-B 145 122 142 147 53 68 135

Bookcases 215 209 286 258 280 123 252

Bookcase-A 130 76 142 117 133 55 117

Bookcase-B 85 133 144 141 147 68 135

Figure 1. 15x7 Array

After some thought, some readers may say this is actually a two-dimensional view of a four-dimensional array because

2010 and Sales Volumeimply the existence of two additional dimensions. They will be partly right. This is indeed a two-

dimensional view of a four-dimensional array, but for a very different reason. The data it displays is all the data there is. The

report headings do not imply there are two additional dimensions, nor is there a requirement to have them. From anarchitectural point of view, the notions of Measure and Yearcan be ignored.

At first glance, it may appear or it would be reasonable to speculate that Other-A and Other-B are pseudo regions: for

example, the Federal Government, the Armed Forces, Exports, Discarded Product, etc. But if Other-A actually represents the

material that each product is made of and if Other-B actually represents the location where the product was manufactured,

then, conceptually speaking, this truly is a 15x5x3x2 four-dimensional array that can be represented on paper as follows:

4See Appendix B for a discussion about why Varying Attributesare not an option.


3/27



Figure 2. 15x5x3x2 Array

The following report provides further clarification. The type of data/information stored in members such as Other-A and

Other-B above is typically implemented as text-type data in Essbase and as Smart Lists in Hyperion Planning. The

underlying functionality is similar, but because this paper is about a Hyperion Planning solution, only Smart Lists are further

discussed here. A Smart List is a

reference lookup table with codes and

code descriptions that the software

uses to translate codes stored as

numerical data in the Essbase cube

into descriptions that can be displayed

on the screen or on a report. As

demonstrated by the preceding

figures, by virtue not of the

commercial software product to

which they belong but by virtue of the

array data structure itself, Smart Lists

implicitly implement additional

dimensionality beyond the explicitrepresentations provided by base dimensions, attribute

dimensions, and varying attributes. Smart List values are a

feature designed to facilitate non-numeric user input. But,

once implemented, they implicitly add dimensionality to

the database. In conclusion and generally speaking,

attributes (i.e., metadata) stored as data, whether fully

implemented as Smart Lists or not, provide the flexibility

needed to support dimensionality that changes not only

through time but also at the touch of button.

Figure 4 here to the left is a different perspective on the

same data. It shows manufacturing gradually moving to

foreign locations. At the beginning of the year, only two

products were imported. By the end of the year, only one

of the products were still being produced domestically. This is an example of a changing dimensionas defined in the data

warehousing literature. It is a Type 6 solution5because it maintains a history of all the changes.

5en.wikipedia.org/wiki/Slowly_Changing_Dimension

Figure 3. Smart Lists

Figure 4. Changing Dimensions as Data


4/27



First Level of Analysis - A Simple SampleApplication and Solution

The key concept presented above contains all the conceptual

elements necessary to build the solution to the requirements

presented at the beginning. It is clearly product independent, but it

also fits perfectly into any version of Hyperion Planning. It does not

require the use of varying attributes. And, as will be shown, even if

available in Planning, varying attributes would not fulfill the

requirements entirely.

Consider the following sample Hyperion Planning application, one

of several built for the purpose of demonstrating the solutions

discussed in this paper.6This application calculates profitability by

customer for a small tennis club. Profit was calculated in the cube,

and it required allocating overhead costs to each customer based on

facilities usage. The club is a partnership, and currently all nine

"customers" are also partners. Revenue comes from the partners'

monthly fees and from sponsorships. The latter are all individually

negotiated by, and accordingly individually credited to, the partners

as revenue generated by them. The simple Smart View report inFigure 5 shows nine rows of data extracted from the application's Essbase database and four rows calculated using Excel

formulas. The club utilizes a membership status program as a promotional mechanism. The first three customers have

reached Platinum status. The customers in the second group have reached Gold and those in the third Silver. Said Smart View

report demonstrates that a few formulas are sufficient to obtain profitability by status.

Because it is possible to perform the above calculations within Essbase, instead of exporting the detail and then manually

performing additional calculations in the reporting environment, two easy-to-implement Essbase solutions were designed as

possible alternatives. The same report, as produced by each of the two new Essbase applications, is shown immediately

below:

SOLUTION A SOLUTION B

FY11 FY12 FY13 FY14 FY15YearTotal YearTotal YearTotal YearTotal YearTotal

Platinum (318) 7,329 13,585 16,256 17,833Gold 14,779 17,469 10,018 11,820 15,906Silver 13,575 12,821 4,428 9,643 19,170

Status 28,036 37,619 28,030 37,719 52,909

FY11 FY12 FY13 FY14 FY15YearTotal YearTotal YearTotal YearTotal YearTotal

Platinum (318) 7,329 13,585 16,256 17,833Gold 14,779 17,469 10,018 11,820 15,906Silver 13,575 12,821 4,428 9,643 19,170

Status 28,036 37,619 28,030 37,719 52,909

Figure 6. Two Solutions, Same Output

The two outputs are identical to each other. Yet, behind the scenes, they are two very different solutions. Solution A uses

attribute dimensions assigned to Customers to dynamically allocate profit according to the corresponding attribute

designations. Solution B uses dynamic calc members to allocate the profit according to a status flag stored as a number in the

database. The outline member aliases shown here were expressly defined and selected to make the reports look identical,

even though the dimensions and dimension members participating as row headings are not the same. To further guarantee the

outputs will appear identical, the Point-Of-View (POV) boxes are not shown.

These two identical outputs, produced by two significantly different means and computational approaches, help to focus

attention on a principle that is rarely made explicit yet underlies all multidimensional financial models: Dimensionality is acharacteristic of the data, not of the system that hosts the data. The data host, in order to be a suitable host, has to recognize,

respect, and faithfully represent the data's dimensionality in order to be useful. How it does this is a matter of preference

and/or of expediency, given the state of technology and other considerations.

Solution B implements the key concept introduced on page2 and, as simple as it is, already satisfies the requirements with

one minor limitation with respect to what was established on that page: One must run and save the two scenarios individually

6The paper shows only fictitious situations and data, yet these fictitious cases were inspired by and illustrate components of real applications successfullyimplemented at client sites.

Figure 5. Data from Essbase, Formulas in Excel


5/27



and compare them later. "Beyond-the-Basics" sample implementations discussed in a later section of this paper describe

additional more advanced solutions. The last one satisfies the full requirement of calculating two or more scenarios

simultaneously and displaying them side by side in a Hyperion Planning application environment. Appendix B further

explains how these solutions match and surpass the history retention capabilities of the "Type 6 with Surrogate and Natural

Keys" method7discussed in the data warehousing literature and how they are much simpler to implement and use. All these

solutions evolved from and are a generalization of the requirements of an implementation successfully completed by Hackett

at a client site. The remainder of the paper provides additional background information and implementation details.

A Few Words about the Underlying Experimental Methodology

Not only does this paper propose and explain a solution, but it also exemplifies a quasi-scientific process by which different

options were hypothesized, discovered, tested, compared, and evaluated until a specific set of suitable and reliable design

patterns evolved. The paper presents sufficient information to facilitate replication. Replication would not only produce a

practical benefit, but it would also contribute to this quasi-scientific process. But the paper must limit itself to a reasonably

sized discussion of the design patterns and principles that resulted from the effort. Patterns that evolved from the process

include items as apparently insignificant as the names of the dimensions (View in Solution VS, Version in Solution HP), data

stored in Gen1 of dimension "View" in Solution VS vs. Gen2 of dimension "Version" in Solution HP, the use of substitution

variables early on versus Custom Defined Functions in the last implementation, flat allocation account lists vs. hierarchically

arranged allocation account lists (with non-competing allocation and aggregation paths), various levels of member formula

modularization (see formulas for "Improve - Professional" and "Improve - Professional - Platinum" on page 6), etc. It is

reasonable to expect future Hackett implementations inspired by this effort will result in additional improvements, but the

foundation produced by this effort can be considered to be complete.

Background

A Little Bit of History

In today's world of computing, it appears that the most popular, basic, and fundamental method for structuring data is a table.

But the table construct as we know it today is relatively new. One of the seminal authors in computer science 8published the

following statement in 1976: "The array is probably the most widely known structure of data because in many (computer)

languages ... it is the only explicitly available structure."9Essbase cubes (i.e., OLAP cubes) are arrays. Arrays are one of the

three fundamental data structures available to us to model and solve computational problems, the other two being a record

and a bitmap.10From a historical, high-level perspective, it seems fair to say that application developers have been modeling

dimensions longer than they have been modeling relations. This paper acknowledges this long tradition and obtains

inspiration from it in order to build a solution not according to current product trends but rather according to fundamentalprinciples.

Core Principle

Probably the most significant design principle applied in this discussion is: Dimensionality is not something one adds,

attaches, or superimposes onto data. Rather, it is something one discovers in the data as one studies it, asks questions about it,

and works with it. OLAP cube dimensionality must respect data dimensionality; it does not add it to pre-existing

dimensionless data. On the other hand, from a technical point of view, it does not have to match it literally. If the purpose is

to solve a computational problem, then the dimensionality chosen for a computer-based data structure (a matrix or an OLAP

cube) also needs to respond and be relevant to the requirements of the operations to be performed, all while faithfully

representing the universe of facts on which these operations will be performed. This is why, for example, designers are

justified when in Hyperion Planning they model time as two dimensions (Years and Months), even though clearly time is

only one dimension in the real world.

There exist practical analysis techniques to help in the design of Essbase cubes. Hyperion Planning professionals who haveparticipated in Essbase Bootcamps, or heard about their curriculum, may recall two techniques in particular. The first one

suggests looking for repeating patterns because they are reliable indicators of a missing dimension. The second technique

suggests making a representative list of all the possible combinations of entities from two dimensions to see if it is the case

7http://en.wikipedia.org/wiki/Slowly_changing_dimension8http://en.wikipedia.org/wiki/List_of_important_publications_in_computer_science9Niklaus Wirth, 1976, "Algorithms + Data Structures = Programs", Prentice Hall, p. 11.10ibid


6/27


7/27



In Solution A, Status is an attribute dimension assigned to the Customers dimension. In Solution B, Profit - Platinum, Profit -

Gold and Profit - Silver are dynamically calculated sub-accounts of Profit also defined in the Accounts dimension. How

exactly they are defined so they can accomplish the desired task is not yet obvious from looking at the results; they involve

one of the solution techniques this paper offers as a solution to the requirements; the specifics are discussed in a later section.

The circular arrows are a reminder of the fact that in both cases a certain total (Status in Solution A and Profit in Solution B)

is dynamically broken down into components at querying time. In other words, while a report reader unfamiliar with the

application upon reading it would likely conclude that the last row is the sum of the previous three rows, someone slightly

familiar with attribute dimensions in Essbase and with the fact that they are being used in Solution A would know

immediately that the opposite has taken place: the total has been dynamically distributed among the participants based on

their status. Solution B is simply a different way of accomplishing the same computational task.

Metadata History vs. Metadata Versions

Metadata History is one type of metadata versioning.

Another could be versioning due to competing sets of

classification criteria. In our example, a person's status

has been designed to change through time based on

participation in club activities. Decision makers could

decide to assign status based on other, more obscure

criteria, and there could be competing opinions as to how

status should be conferred. The club may wish to study

profitability based on a variety of opinions in order to be

more confident about the validity of a final compromise.

The solutions presented in this paper do not limit

themselves to modeling historical change but are

applicable to any situation in which a classifying value

can be read from more than one place in the database.

Two of the solutions use global variables (i.e., Essbase

substitution variables). The last one uses data values and

CDFs (custom defined functions) to build references to

the location of the data. The preceding figure shows

different examples of substitution variables, suggesting a

variety of ways to reference criteria with different results

in each case.

11

The code segments here below, extracted from formulas from two different solutions, provide a comparison ofthe two approaches.

"View"->"MembershipStatus"->&ReferenceYear->&ReferenceMonth

"DefaultRating"->"Total"->"Default"->@Member(@HspNumToString(@Int("sRefYear")))->@Member(@HspNumToString(@Int("sRefMonth")))

11More specifically, it is very common to store "timeless" data in Essbase making use of naming conventions such as "No Month" and "No Year". All thepossible combinations of "No Month" with any "Years" dimension member and/or of "No Year" with any "Months" dimension member provide ample

storage space to store the results of a variety of opinions unrelated to those which one standard agreed-upon classification criteria has produced through time.

This analytical flexibility can be expanded even more with the introduction a Scenarios dimension. This option will be discussed in a later section. See alsoAppendix D for a brief discussion on dimensionality as implemented in single-matrix databases such as Essbase.

Figure 8. Substitution Variables


8/27



Membership Status Profit Profit-Platinum Profit-Gold Profit-Silver

David FY11 Jan Silver 1,588.78 1,588.78

David FY11 Feb Silver (50.01) (50.01)

David FY11 Mar Silver 1,473.21 1,473.21

David FY11 Apr Gold 1,183.84 1,183.84David FY11 May Gold 410.69 410.69

David FY11 Jun Gold 662.64 662.64

David FY11 Jul Platinum 1,857.67 1,857.67

David FY11 Aug Platinum 974.22 974.22

David FY11 Sep Platinum 1,715.23 1,715.23

David FY11 Oct Gold 1,068.45 1,068.45

David FY11 Nov Gold 429.00 429.00

David FY11 Dec Gold 2,047.12 2,047.12

Figure 9. Profit Assigned to Status Based on Current Status

Membership Status Profit Profit-Platinum Profit-Gold Profit-Silver

David FY11 Jan 3 1,588.78 1,588.78

David FY11 Feb 3 (50.01) (50.01)

David FY11 Mar 3 1,473.21 1,473.21

David FY11 Apr 2 1,183.84 1,183.84

David FY11 May 2 410.69 410.69

David FY11 Jun 2 662.64 662.64

David FY11 Jul 1 1,857.67 1,857.67David FY11 Aug 1 974.22 974.22

David FY11 Sep 1 1,715.23 1,715.23

David FY11 Oct 2 1,068.45 1,068.45

David FY11 Nov 2 429.00 429.00

David FY11 Dec 2 2,047.12 2,047.12

Figure 10. Profit Assigned to Status based on Status in May 2011

Studying and comparing the two grids on this page, armed only with the information that has been discussed up to this point,

it is possible to observe and conclude that the first grid is displaying data from the whECD.whECDr Essbase cube while the

second is displaying data from the whECD.whECDp Essbase cube and, in addition, that in database whECD.ECDr, the

"typed measures" feature has been activated such that under Membership Status we see text instead of numeric values

(explanation on page6).

Gradual Development of Increasing Analytical Power

It is appropriate to remember here once more that this paper is not a proposal or description of a preferred solution but rather

the review of an investigation, through a series of trials, where each trial is an improvement over the previous one.

Improvements are discussed for their own sake, to make more evident the principles inherent in the overall problem and help

guarantee the value and accuracy of the final solution. A certain amount of effort was made to use the same data throughout

to be able to compare the results, but in some cases this was not practical, in particular in case of the last solution (Solution

HP) as will be further explained.


9/27


10/27



4.

Reporting Application: Implies two databases, the main one being the BSO cube of a Hyperion Planning

application, the dependent downstream reporting application being implemented as an ASO cube, and the Planning

Smart List values mapped to dimensions in the reporting application. Based on the text of the requirements, this

solution, while powerful, cannot be considered. It is briefly discussed in Appendix E.

Basic Solution (Solution B)

This solution was already partially presented in the Introduction as "Solution B." It is the solution that first inspired thispaper, a design approach that has been implemented more extensively than illustrated here at an S&P 500 company by

Hackett consultants and has been in production mode for five years.12The other solutions described in this paper are the

result of further thinking about possibilities without the restrictions imposed by pre-existing implementation contracts. This

solution has been further expanded from its initial form to include two flavors discussed here below.

Solution B1 - Multiple Versions of an Account in a Flat Hierarchy

This solution is the least intrusive and fastest to implement within an existing

Hyperion Planning application. Consider an application that is already using

Smart Lists to keep track of a club member's status and the application owner

requests the ability to "slice and dice" based on the categories specified by

this list; then all that is required is to create one calculated account for each of

the Smart List values and optionally to put all of them in an account group to

facilitate their use and identification as illustrated in the adjacent figure

(Figure 12). To satisfy the requirements set at the beginning of this paper, the

accounts should be defined as dynamic calcsso their values will immediately

reflect any related data changes (may we say: "metadata changes"?).

In the example shown here, obeying the outline's natural order of calculation,

after the dynamic calc account Profit is computed, it will be "allocated" based

on the club member's membership status into one of three membership levels.

By virtue of the way Essbase outlines work, account "Profit by Status" will

then be computed as the sum of the three Profit by Status detail accounts and

will have, if the allocation rules were properly coded, the same value as the

one in Profit, confirming that the allocation was correctly calculated.

As displayed, the outline gives its viewers the impression that it contains a

hierarchy, but in reality, the Analytics section is only a flat list of accounts

arranged into groups. Because of this, the natural order of calculation canbe easily made to support the requirements by simply making sure that

dependent accounts appear after the accounts on which their values depend. In

the example above, "Profit - Platinum" will be calculated as a portion of

"Profit" after "Profit" already has a value. Building a multi-level hierarchy is

more challenging but is possible as can be seen in the following section.

Solution B2 - Multiple Versions of an Account in a Tree Hierarchy

If there is more than one Smart List or data item capable of taking on the role

of metadata on the rest of the data in the database, and if slicing and dicing

should be possible by two or more criteria at the same time, the option of

arranging all the possible data intersections hierarchically presents itself as a

very enticing design alternative (seeFigure 13). As can be seen in the figure,

the combinations have to be built explicitly.

12The solution was a direct response to reporting requirements that would have otherwise been impossible to implement, namely, the slicing and dicing of a20-GB cube based on the ever-changing dimensionality implicit in the various smart list values users must select in order to build their budgets. Theapplication is a bottom-up planning solution, recording and summarizing the 180-month budgets of 27 thousand entities; in other words, it contains a large

amount of detail-level data. And, while some of the applications 100-plus reports are detailed reports, each covering only a certain portion of the budget,

reports presented to upper management are by necessity high-level and summarize the entire database. The type of slicing and dicing requested by the client

would have required loading all the applicable detail-level data into each report in order to perform the corresponding selections within the report, an

obvious impossibility. Beyond this difficulty, the work of analysts would have also been needlessly tedious, forcing them to load enormous amounts of

detail-level data into smart view queries just to be able to locate the items of interest. Today, they simply select dynamic calc members built according to theapproach explained in this paper, limiting their effort to the final nuances of the requirements of the moment.

Figure 12. Outline - Solution B1

Figure 13. Outline - Solution B2


11/27



Unfortunately, the natural order of calculation for BSO Essbase Outlines

conflicts with this alternative. Lower-level members are allocations of

upper-level members, yet Essbase expects to be able to compute upper

levels as aggregations of lower-member levels. There is a workaround, and

it is presented in the implementation section further below.

Beyond-the-Basics Solutions

Solution V - View Dimension

If slicing and dicing based on data must be done with more than a handful

of accounts, Solution B would not be easy to implement and maintain. 13

Adding a "View" dimension allows the designer to build generic allocation

formulas applicable to any measure (see Figure 14). In the example

shown, all the data resides in the top level member "View." All the other

hierarchy members in this dimension are dynamically calculated members

whose formulas get their values from "View" when the required conditions

are met. For example, if the customer whose data is being viewed has met

"Platinum" status, then all of the customer's data will be shown in the

"Platinum" dynamic slice. If, on the other hand, the customer has "Gold"

status, the data will be shown in the "Gold" dynamic slice.

Solution VS - View and Scenario Dimensions

With a solution that includes a View dimension and a Scenario dimension it becomes possible and convenient to work

simultaneously with multiple views of the data; in particular, it becomes possible to view any account or group of accounts,

broken down by one or more versions or instances of metadata-like data values.

In Solution VS, each scenario has its own global variables (i.e., substitution variables). The formulas in the view dimension

have to not only reference their corresponding metadata identifier (e.g., status) but decipher the identity of the scenario

referenced in the query in order to properly select the global variables to use to point to the desired metadata values stored as

data. The implementation section provides some examples of this.

Solution HP - Hyperion Planning ApplicationThe user interface building capabilities offered by Hyperion Planning facilitate addressing the requirements stated on page2.

Beyond the important fact that varying attributes cannot be managed directly by users (see Appendix B), making this

discussion about a Hyperion Planning application conveniently eliminates from the discussion the option of using varying

attributes. The requirements call for an environment to manage changing dimensions and to then be

able to compare data classifications based on current, historical, or future metadata.

Solution HP's "Perspectives" form allows users to define an analytic scenario's metadata. The

"Compare Three Scenarios" form allows users to compare data from the

scenarios thus defined.

13The earlier-mentioned 20-GB real world solution that inspired this investigation and this paper required the creation of about 150 dynamic calc accountsmodeling slicing and dicing according to four data-driven implicit dimensions. Without much effort, they were structured and designed in a modular fashionso maintenance would not be a problem. In the five years they have been in operation, they have undergone very minimal modifications due to requirement

changes. Without question, they have performed efficiently and reliably and, again, they have provided levels of analysis that would have otherwise been

impossible. One key element that made efficient performance possible in that application but which would require delving into details beyond the scope of

this paper was the inclusion of three stored accounts acting as anchors or markers. In the initial solution, these had also been created as dynamic calcs.

Making them stored had the effect of immediately improving the performance of all the other dynamic calc accounts. This underscores the reality that

particularly in the case of large databases, additional strategically selected design features may be needed to produce acceptable levels of performance. Thispapers content still remains a faithful representation of the foundational principles that made that applications reportingcapabilities possible.

Figure 14. Outline - Solution V

Figure 15. Outline - Solution VS


12/27



Figure 16. PerspectivesFigure 17. Scenarios

FORECASTING ALGORITHM

A forecasting algorithm was purposely added to the requirements in order to emphasize the need to handle the metadata as

data in real time. The paper is not a discussion of forecasting methods, and so the algorithm used in these solutions is not

intended to be an integral component of any real-world solution. The algorithm makes use of probability by means of a

random number generator applied to a moving average, but the random numbers are computed externally and imported as

data. The numbers are then used to progressively modify a moving average in order to produce future data based onperformance commitments entered by users for the current budget year. The requirement to include a forecasting algorithm in

the solution eliminates the possibility of using varying attributes, even if they were available in Hyperion Planning. For

varying attributes to be a possible option, the forecasting algorithm would have to not only compute future metadata values

but also modify the varying attribute definitions and all of this in real time.

For the record and to demonstrate compatibility with other computational requirements, the application includes an allocation

algorithm by which expenses (recorded irrespective of court usage) are allocated down to each club partner, 50% in equal

parts and 50% based on court usage. These allocations are clearly essential to the calculation of profitability.

Figure 18. Forecasting Algorithm

Benefits

The value these solutions offer is at least five-fold: 1) Any time and immediately after a driver/metadata value is "changed,"

through user input or otherwise, the amounts per bucket change accordingly, 2) the drivers can be read from any place within

the cube, so the allocations can be based on values stored in different time periods (or in "No Year," "No Period," or

elsewhere); in other words, they can be based on any "changing dimension type" defined in the data warehousing literature,

3) the data in the individual buckets is not stored, so the size of the cube and the daily update time are not affected; only the

values requested by a query need to be computed, 4) the physical dimensionality of the cube can be maintained fixed, yet the


13/27



analytical dimensionality is in principle unlimited, and 5) probably most importantly, the heart of the solution is not

dependent on a "still-not-available" product feature; it could be implemented, in principle, on any platform capable of

modeling dimensionality.

Implementations

Basic ImplementationImplementation B1 - Multiple Versions of an Account - Flat Hierarchy

After Profit is computed, it is "allocated" based on the member's membership status into one of three membership levels. 14

Status Dimension within Accounts Dimension Formula for Profit - Platinum

@CALCMODE(CELL);

@CALCMODE(BOTTOMUP);

/* MembershipStatus: 1=Platinum, 2=Gold, 3=Silver */

IF ( @IsLev("Players",0) )

IF( "MembershipStatus"->&ReferenceYear->&ReferenceMonth == 1 )

"Profit";

ENDIF

ENDIF

Figure 19. Implementation of Solution B1

Implementation B2 - Multiple Versions of an Account - Tree Hierarchy

Implementation B2 is the result of an effort to build a hierarchical arrangement of aggregation levels. This effort is similar to

and related to the investment made in data warehouse implementations to build aggregate tables in order to improve response

times.15The similarity is not so much because of their purpose but because of the effort required to pre-define the dimension

combinations.

Figure 20. Implementation of Solution B2

"Beyond-the-Basics" Implementations

14See Appendix C for an explanation of the inclusion of @CALCMODE and pages 19 and 20 for detai ls regarding the aggregation of upper-level members.15Adamson, Christopher (2006),Mastering Data warehouse Aggregates: Solutions for Star Schema Performance, Indianapolis, IN: Wiley.

Players


14/27



Implementation of Solution V - View Dimension

A "View" dimension allows us to build generic allocation formulas applicable to

any measure. This figure's "View" dimension has three Gen2 dynamic calc

members: "Platinum", "Gold," and "Silver." The data is stored in Gen1. The

dynamic calc formulas distribute the total stored at Gen1 among its child members.

In Solution V, all the accounts are dynamically allocated down to view members in

accordance to the Smart List values stored at a location identified by two substitution variables.

PlatinumIF ( @IsLev("Players",0) )

IF( ("View"->"MembershipStatus"->&ReferenceYear->&ReferenceMonth ) == 1 )"View";

ENDIF

ENDIF

GoldIF ( @IsLev("Players",0) )

IF( ("View"->"MembershipStatus"->&ReferenceYear->&ReferenceMonth ) == 2 )

"View";ENDIF

ENDIF

Silver

IF ( @IsLev("Players",0) )IF( ("View"->"MembershipStatus"->&ReferenceYear->&ReferenceMonth ) == 3 )

"View";

ENDIF

ENDIF

Figure 21. Implementation of Solution V

Implementation of Solution VS - View and Scenario Dimensions

Platinum: Status==1, Gold: Status==2, Silver: Status==3

IF ( @IsLev("Players",0) )IF (@IsMbr("Main"))

IF( "Main"->"View"->"MembershipStatus"->&ReferenceYear->&ReferenceMonth" == 1 )

"Main"->"View";ENDIF

ELSEIF (@IsMbr("ScenarioA"))IF( "Main"->"View"->"MembershipStatus"->&ReferenceYearA->&ReferenceMonthA == 1 )

"Main"->"View";

ENDIFELSEIF (@IsMbr("ScenarioB"))

IF( "Main"->"View"->"MembershipStatus"->&ReferenceYearB->&ReferenceMonthB == 1 )

"Main"->"View";

ENDIF

ELSEIF (@IsMbr("ScenarioC"))

IF( "Main"->"View"->"MembershipStatus"->&ReferenceYearC->&ReferenceMonthC == 1 )"Main"->"View";

ENDIF

ENDIF

ENDIF

Figure 22. Implementation of Solution VS

The substitution variable values were defined as illustrated on page6.Long member formulas like this one provided an

incentive to move beyond substitution variables and store the location of the metadata as data as well. New opportunities for

modularization and simplifications quickly became possible (as will be seen shortly).

YearTotal

FY10

NoCourt

Revenue Expenses Profit

Platinum 57,389 35,045 22,344

Gold 46,808 36,944 9,864

Silver 25,091 20,262 4,829


15/27



The adjacent grid shows the results of the calculations performed by the

formulas in the View dimension. The current settings of the

corresponding substitution variables are shown in the insert immediately

below the grid. For example, according to Scenario A, the applicable

Status values are those of January FY11. In January 2011, David had

"Gold" Status. Therefore, the Club's profit due to David's activities

belongs to the Gold category and contributes to the club's portfolio from

"Gold" sources. In Scenario B, David has "Platinum" status and in

Scenario C, David has Silver status. In the following table, we can see

even more clearly how profit due to David's participation in the

activities of the club moves from category to category depending on the

selected scenario of analysis.

David David David David David David David David David David David

Main Main ScenarioA ScenarioA ScenarioA ScenarioB ScenarioB ScenarioB ScenarioC ScenarioC ScenarioC

View View Platinum Gold Silver Platinum Gold Silver Platinum Gold Silver

MembershipStatus

Profit Profit Profit Profit Profit Profit Profit Profit Profit Profit

FY11 Jan 2 369.26 369.26 369.26 369.26

FY11 Feb 3 480.44 480.44 480.44 480.44

FY11 Mar 2 820.00 820.00 820.00 820.00

FY11 Apr 2 898.52 898.52 898.52 898.52FY11 May 2 895.05 895.05 895.05 895.05

FY11 Jun 1 898.38 898.38 898.38 898.38

FY11 Jul 2 877.34 877.34 877.34 877.34

FY11 Aug 3 880.64 880.64 880.64 880.64

FY11 Sep 2 896.60 896.60 896.60 896.60

FY11 Oct 3 891.26 891.26 891.26 891.26

FY11 Nov 2 904.15 904.15 904.15 904.15

FY11 Dec 3 887.53 887.53 887.53 887.53

FY11 YearTotal 9,699.15 9,699.15 9,699.15 9,699.15

Figure 24. Results - VS - 2

Players Players Players David David David Matthew Matthew Matthew Thomas Thomas Thomas

ScenarioA ScenarioB ScenarioC ScenarioA ScenarioB ScenarioC ScenarioA ScenarioB ScenarioC ScenarioA ScenarioB ScenarioC

FY11 Platinum 28,729 34,078 43,768 9,699 10,970

FY11 Gold 42,497 39,085 9,340 9,699 10,356 10,970 10,970

FY11 Silver 12,907 10,970 31,025 9,699 10,356 10,356

FY11 ByStatus 84,133 84,133 84,133 9,699 9,699 9,699 10,356 10,356 10,356 10,970 10,970 10,970

FY12 Platinum 29,153 36,283 45,002 10,512 11,131

FY12 Gold 44,383 39,665 9,922 10,512 10,512 11,131 11,131

FY12 Silver 13,543 11,131 32,155 10,512 10,512 10,512

FY12 ByStatus 87,079 87,079 87,079 10,512 10,512 10,512 10,512 10,512 10,512 11,131 11,131 11,131

FY13 Platinum 33,885 45,178 45,180 11,295 11,295

FY13 Gold 45,180 45,180 22,588 11,295 11,295 11,295 11,295

FY13 Silver 22,588 11,295 33,885 11,295 11,295 11,295

FY13 ByStatus 101,653 101,653 101,653 11,295 11,295 11,295 11,295 11,295 11,295 11,295 11,295 11,295

FY14 Platinum 34,380 45,840 45,840 11,460 11,460

FY14 Gold 45,840 45,840 22,920 11,460 11,460 11,460 11,460

FY14 Silver 22,920 11,460 34,380 11,460 11,460 11,460

FY14 ByStatus 103,140 103,140 103,140 11,460 11,460 11,460 11,460 11,460 11,460 11,460 11,460 11,460

FY15 Platinum 34,863 46,484 46,484 11,621 11,621

FY15 Gold 46,484 46,484 23,242 11,621 11,621 11,621 11,621

FY15 Silver 23,242 11,621 34,863 11,621 11,621 11,621

FY15 ByStatus 104,589 104,589 104,589 11,621 11,621 11,621 11,621 11,621 11,621 11,621 11,621 11,621

Figure 25. Results - VS - 3 - Aggregated Values

The previous grid demonstrates that the fact that, when these results are aggregated, data begins to appear in all the columns

as the contributions of each player are assigned to the applicable categories.

Figure 23. Results - VS - 1


16/27



The figures displayed on this page collectively

demonstrate the dynamic process of allocating

total profit down to a variety of detail levels as

defined by metadata stored as data result, once

re-aggregated, in totals identical to the original

number. This is true not only when computing

the allocations based on current metadata values

but also when computing them according to

metadata values residing elsewhere in the

database, per the instructions of substitution

variables.

The formulas below validate the expectation

that once a first level of selection is completed,

further allocations can be completed by very

simple formulas.

Implementation of Solution HP - Hyperion Planning

Solution HP is the target solution built to fully address the requirements stated on page 1. Compared to the solutions

presented earlier in this paper, this solution has more data as well as data generated by forecasting algorithms. Therefore, the

Figure 26. Allocation of Total Profit


17/27



numerical results are different from those obtained from earlier solutions. It should be noted that the nature of the

computations facilitates self-validation.

The principal features distinguishing Solution HP and allowing it to directly respond to the requirements stated on page 1 are:

1. Implemented in Hyperion Planning to provide changing dimension functionality within a Planning application.

2.

Metadata can be entered by users as data via input forms at any time.

3.

Metadata is entered for a specific point in time (as well as for other dimension values), therefore this metadata can

be different for each valid dimensional intersection and fits the definition of a "changing dimension" recognized in

data warehousing.

4.

Metadata in future years is generated by forecasting algorithms. This enforces the requirement of allowing metadata

to change beyond the control of a database administrator.

5.

Users also define scenarios by specifying as data the year and month from which to obtain player classifications. In

contrast to Solution VS, this eliminates the need to create or maintain substitution variables, not something users are

typically allowed to do.

6.

The application has the ability to combine metadata and scenario definitions to be able to simultaneously display

financial results according to competing criteria.

The remainder of this section focuses on the features that prove that the solution satisfies the requirements.

METADATA STORED AS DATA

The adjacent figure shows three metadata values

computed by the system, entered by users or

loaded from external sources. In this particular

case we see that between May and August of 2013

only two changes occur: David turns Professional

in August and Edward begins to spend less time in

training sometime in early 2013, thus going from

"Objective=Improve" to "Objective=Maintain" in

June of that year. Rating is the only metadata item

that is not controlled by algorithms, and therefore

2013 forecasts must be specified by users.

SCENARIO DEFINITIONS

According to the data displayed in the

"Perspectives" form, users have determined that

1) the default scenario should use player

classifications from the current year and month,

2) Scenario A should use player classifications from

March 2012, 3) Scenario B should use player

classifications from June 2013, 4) Scenario C

should use player classifications from the same

Month in 2011, 5) Scenario D should use player

classifications from January of the same year and6) Scenario E should use player classifications from

December 2011.

The Compare Scenario to Default form here

below is set to display revenue from Brian's

membership. In April 2012, Brian was a

"Gold" member, working toward improving

his skills and playing as an amateur. Objective

is determined by level of participation in

Figure 27. Slowly Changing Dimensions

Figure 28. Scenario Definitions

Figure 29. Compare Scenarios Form


18/27



clinic hours, thus demonstrating the true intention of a player. In the Default scenario, revenue from Brian's membership

appears classified as Revenue from Gold members, Revenue from members wishing to improve, and Revenue from amateur

players. As earlier illustrated, Scenario E is currently defined as a player's classification as of December 2011. At that time,

Brian was considered a "retiring," "Platinum" member. So, in this Scenario, revenue from Brian's membership appears in the

"Platinum" row instead of the "Gold" row, in the "Retire" row instead of the "Improve" row, but still in the "Amateur" row.

PLAYER-LEVEL ANALYSIS

The "Compare Three Scenarios" form allows

a user to select three scenarios to compare.

Depending on the design decision made with

respect to the calculation mode for the upper

levels of the "Player" dimension, in particular

Gen1 of this dimension, it may or may not be

possible to use this form to view scenarios at

an aggregate level. But it will always be

possible to view them using Smart View

queries or Hyperion Reports (see subsequent

pages, in particular page 21).

Hyperion Planning has a very specific way of

creating the initial Essbase structure needed to

support a planning application. The initial

database includes six "required dimensions":

Period, Year, Scenario, Version, Entity and

Account. For this reason, it seemed appropriate

to replace "View" with "Version" in Solution

HP. In our demo application "Player" plays the

part of "Entity" so "Entity" was also renamed. To respect the design principle of always loading data into level-zero

members, the "Total" version was created and "Version" was declared a "Label Only" member. Still, there is only one stored

member in this dimension. As in Solution VS, the scenario dimension contains several stored members, but data is loaded

into only one of the scenarios, the "Default" scenario. The other stored scenarios perform a very simple but critical role. They

store each scenario's "RefYear" and "RefMonth" values, thus driving the calculation of the scenarios themselves. In this

version, scenarios are selected earlier in the sequence of calculations, e.g., at the calculation of "MembershipStatus". This

makes the formulas in the "Version" dimension members much simpler than they were in the previously discussed solutions.

Figure 30. Player-level Analysis


19/27



/* MembershipStatus */@CALCMODE(CELL);@CALCMODE(TOPDOWN);IF ( @IsSibling("NoPlayer") AND @IsLev("Period",0) AND @IsMbr("NoCourt") )IF ( "sRefYear" #MISSING AND "sRefMonth" #MISSING )

"DefaultMembershipStatus"->"Total"->"Default"->@Member(@HspNumToString(@Int("sRefYear")))->@Member(@HspNumToString(@Int("sRefMonth")));ELSEIF ( "sRefYear" #MISSING )

"DefaultMembershipStatus"->"Total"->"Default"->@Member(@HspNumToString(@Int("sRefYear")));ELSEIF ( "sRefMonth" #MISSING )

"DefaultMembershipStatus"->"Total"->"Default"->@Member(@HspNumToString(@Int("sRefMonth")));ELSE

"DefaultMembershipStatus"->"Total"->"Default";ENDIFENDIF

/* Platinum */@CALCMODE(CELL);@CALCMODE(TOPDOWN);IF ( @IsSibling("NoPlayer") AND @IsMbr("NoCourt") AND @IsGen("Period",4) )IF ( "MembershipStatus" == 1 )

"Default"->"Version";ENDIFENDIF

Figure 31. Dynamically Calculated Versions

TARGET

The stated ultimate goal is to compare YTD profit according to several

scenarios. The following Smart View query gives this information. Notice

in particular the "AllPlayers" dimension value. This is an attribute

dimension used to dynamically consolidate the values computed at level

zero of player. All the players have been tagged with the value "Yes," one

of the two level-zero members in this attribute dimension. Without it, the

Smart View query would return blanks because the values must be

computed for each player at level zero. In real-world applications, the

dimension here represented by the "Player" dimension would be large,

and none of its upper-level members would be dynamic.


20/27


21/27



Conclusion

The objectives set forth on page 1 have been met. Specifically,

1.

The paper has provided a demonstration of a variety of Essbase solutions capable of handling dimensions that

change in real time, through time, and/or according to the application of competing criteria.

2.

The paper describes an implementation in which a user can compare results based on competing metadata.

3.

The paper has provided evidence that the output is the same as what would be obtained from a classic data

warehouse design (see Appendix A).

4.

The paper has provided a solution using varying attributes (see Appendix B) and has presented evidence of the fact

that varying attributes cannot provide the required functionality, namely, that users be allowed to manipulate

attributes.

5.

The paper has provided sufficient implementation details to enable and facilitate replication of these solutions in

Hyperion Planning 11.1.2, which does not support varying attributes.

6.

The paper has demonstrated that multidimensionality is not a product feature but rather a modeling concept with a

variety of implementation forms.

7.

The paper has demonstrated similar results would be obtained if the solution consisted of a Reporting Application

with Smart List values in Planning mapped to dimension members in the Reporting Application, but this would

require two databases and would not be a real-time solution (see Appendix E).

Appendix

Appendix A - Core Principle Revisited

The purpose of this appendix is to further emphasize the fact that the solutions offered in this paper are concept-based rather

than product-based.

Relational Solution

To further emphasize the core principle presented on page5,the same raw, non-allocated, non-aggregated data loaded into

Essbase was also loaded into a relational database. A simple star schema was derived from it.

The required allocations and aggregations were performed on

the data using standard relational database operations. The final

output is shown here to the left.

Again, the numerical results are exactly the same (compare

Membership Status FY11 FY12 FY13 FY14 FY15

Platinum 7,134 16,838 11,234 22,425 26,945

Gold 17,829 14,592 11,920 7,927 19,745

Silver 3,074 6,189 4,876 7,367 6,219

Total 28,036 37,619 28,030 37,719 52,909


22/27



them to those of Solutions A and B on page 4). Making sure the labels also look identical is no longer of concern at this point

in this proof of concept. The labels conveniently illustrate the fact that the output was obtained from a relational source (there

is a heading in the first column and the last row was actually computed within the reporting environment).

Essbase Version 4 Solution

One could also load the data into an Essbase Version 4 cube, if such a version were physically available, and produce the

exact same results. Version 4 did not have dynamically calculated members (they were added in version 5) and it did not

have attribute dimensions (they were added in Version 6). The calculations would need to be performed in batch mode by

scripts (instead of dynamically) and the results would be contained in stored cells. But the numbers shown in the report

would be the same. Or one could load the data into some other multi-dimensional data processing system and apply similar

calculations. The principle would be further validated by the identical results.

Appendix B: VaryingAttributes

Varying attributes are indeed Oracle

Hyperion's solution to the problem of

changing dimensions. The purpose of

this appendix is to explain in further

detail the reasons why varying attributes

are not a viable option for the fulfillmentof the requirements presented in the

Introduction on page1.The figure shows

a solution implemented using varying

attributes for the purpose of

demonstrating that they indeed address

the problem of maintaining metadata

history and allocating numbers to

buckets based on the metadata of a given

time period. In combination with

Smart View, through the use of

Perspectives, they even support the comparison of two sets of numbers, one derived applying metadata from one time period

and the other applying metadata from another time period. The reasons why they still do not satisfy the requirements set in

the Introduction are:

1.

Varying attribute ranges must be set up by an administrator (painstakingly with this type of data).

2.

Varying attribute ranges are not compatible with Hyperion Planning.

Because the application must be a planning application, more specifically, a Hyperion Planning application, it must be

possible for any authorized user to forecast data and metadata values for future years and to produce YTD profit as of the end

of a future month based on the metadata entered for another future month, and if the user decides to change some of the

forecasted data and/or metadata values, it must be possible to do so through a planning form and immediately obtain a new

report or query based on these changes.

Some of the reasons why the solution surpasses what standard data warehousing solutions may offer include the following:

1) While it may be possible to design a data warehouse to support a budgeting application, its technologies and

methodologies are intended for historical analysis exclusively; 2) correspondingly, data warehouses are not typically

intended for interactive data input; 3) varying levels of detail require multiple fact/aggregate tables. See Appendix A for

related details.

Some of the reasons why the solution surpasses even Essbase's own varying attributes include the following: 1) attribute

assignments in this paper's solutions are data input and can thus be entered and updated by users, 2) Smart View environment

configuration is not required, and 3) varying attributes are currently not compatible with Hyperion Planning.

Appendix C - Additional Technical Details

During development, it was occasionally necessary to stop a database for certain changes to take effect. Implementers should

be ready to recognize the need to do the same. The @CALCMODE() variations recognizable in member formulas were an

integral part of the experimentation done to best understand dynamic calculation performance limitations. The implications

Figure 32. Varying Attributes


23/27



for each solution type are not simple to summarize. Rather than discussing all the findings, it is hereby proposed that

implementers consider and try all four possible combinations if necessary.

Clinic Hours are estimated using a randomized moving average. The formula stillallows for manual forecasting by simply allowing users to enter "Actual Clinic Hours"into future data cells.

Future court usage hours are estimated using a randomized moving average. The formula allows for manualforecasting by simply allowing users to enter "Actual Hours" values into future data cells.

/* ClinicHours: Computed as Actual value if available otherwise as a randomizedmoving average. Rounded to multiples of 1/4 hour (notice division by four).*/

@CALCMODE(CELL);@CALCMODE(BOTTOMUP);IF ( @IsGen("Period",4)

AND @IsMbr("Total")AND @IsMbr("Default")AND @isMbr("NoCourt")AND @IsSibling("NoPlayer") )IF ( "ActualClinicHours" #MISSING )

"ActualClinicHours";ELSE

IF ( @IsMbr("Jan") )@ROUND ( ( @PRIOR( "ClinicHours"->"Oct",1,("FY10":"FY20") )

+ @PRIOR( "ClinicHours"->"Nov",1,("FY10":"FY20") )+ @PRIOR( "ClinicHours"->"Dec",1,("FY10":"FY20") ) )/ ( 3 + "RandomNumber") * 4 , 0 ) / 4 ;

ELSEIF ( @IsMbr("Feb") )@ROUND ( ( @PRIOR( "ClinicHours"->"Nov",1,("FY10":"FY20") )

+ @PRIOR( "ClinicHours"->"Dec",1,("FY10":"FY20") )+ "ClinicHours"->"Jan" ) / ( 3 + "RandomNumber") * 4 , 0 ) / 4 ;

ELSEIF ( @IsMbr("Mar") )@ROUND ( ( @PRIOR("ClinicHours"->"Dec",1,("FY10":"FY20"))

+ "ClinicHours"->"Jan"+ "ClinicHours"->"Feb" ) / ( 3 + "RandomNumber") * 4 , 0 ) / 4;

ELSE@ROUND ( ( @PRIOR( "ClinicHours", 3 , ("Jan":"Dec") )

+ @PRIOR( "ClinicHours", 2 , ("Jan":"Dec") )+ @PRIOR( "ClinicHours", 1 , ("Jan":"Dec") ) )/ ( 3 + "RandomNumber") * 4 , 0 ) / 4 ;

ENDIFENDIFENDIF

/* Hours: Computed as Actual value if available otherwise as a randomized moving average roundedto multiples of 1/4 hour (notice division by four).

*/

@CALCMODE(CELL);@CALCMODE(BOTTOMUP);

IF ( @IsGen("Period",4)and @IsMbr("Total")and @IsMbr("Default")and @isMbr("NoCourt")and @IsSibling("NoPlayer") )

IF ( "ActualHours" #MISSING )"ActualHours";

ELSEIF ( @IsMbr("Jan") )

@ROUND ( ( @PRIOR( "Hours"->"Oct",1,("FY10":"FY20") )+ @PRIOR( "Hours"->"Nov",1,("FY10":"FY20") )+ @PRIOR( "Hours"->"Dec",1,("FY10":"FY20") ) ) / ( 3 + "RandomNumber") * 3.8 , 0 ) / 4;

ELSEIF ( @IsMbr("Feb") )@ROUND ( ( @PRIOR( "Hours"->"Nov",1,("FY10":"FY20") )

+ @PRIOR( "Hours"->"Dec",1,("FY10":"FY20") )

+ "Hours"->"Jan" ) / ( 3 + "RandomNumber") * 3.8 , 0 ) / 4;ELSEIF ( @IsMbr("Mar") )

@ROUND ( ( @PRIOR("Hours"->"Dec",1,("FY10":"FY20"))+ "Hours"->"Jan"+ "Hours"->"Feb" ) / ( 3 + "RandomNumber") * 3.8 , 0 ) / 4 ;

ELSE@ROUND ( ( @PRIOR( "Hours", 3 , ("Jan":"Dec") )

+ @PRIOR( "Hours", 2 , ("Jan":"Dec") )+ @PRIOR( "Hours", 1 , ("Jan":"Dec") ) ) / ( 3 + "RandomNumber") * 3.8 , 0 ) / 4 ;

ENDIFENDIFENDIF

Figure 33. Technical Details - A

It is interesting to observe that the forecasting

algorithm charged with computing future court

usage has estimated that Oliver, the least engaged

club member in year 2010, will end up being one

of the most active in 2020, while it has estimated

that Robert, the most active club member in 2010,

will be among the least active in 2020. Again, this

paper is not about forecasting and the algorithm

itself does not have any scientific validity, but it

helps to emphasize the goal of this paper, which is

to facilitate analysis based on metadata stored as

data and metadata beyond the control of a database

administrator.

Figure 34. Technical Details - B


24/27



Membership Status is computed as a function of the total number of hours paid forduring the last three months.

The number of hours paid for in the future is computed using a randomized moving average (as earlierillustrated). The table below illustrates the fact that court hours have been paid t hrough December 2012and that hours in subsequent months have been estimated in multiples of 15 minutes. Then the number ofhours of court usage over a period of three months has been used to determine membership status.

/* MembershipStatusComputed based on the total number of usage hours during the previous three months.

1 = Platinum, 2 = Gold, 3 = Silver.*/

@CALCMODE(CELL);@CALCMODE(BOTTOMUP);

IF ( @IsGen("Period",4)AND @IsMbr("Total")AND @IsMbr("Default")AND @isMbr("NoCourt")AND @IsSibling("NoPlayer") )

IF ( @IsMbr("Jan") )3 - @MIN(2,@ROUND ( ( @PRIOR( "Hours"->"Oct",1,("FY10":"FY20") )

+ @PRIOR( "Hours"->"Nov",1,("FY10":"FY20") )+ @PRIOR( "Hours"->"Dec",1,("FY10":"FY20") ) ) / 111, 0 ));

ELSEIF ( @IsMbr("Feb") )3 - @MIN(2,@ROUND ( ( @PRIOR( "Hours"->"Nov",1,("FY10":"FY20") )

+ @PRIOR( "Hours"->"Dec",1,("FY10":"FY20") )+ "Hours"->"Jan" ) / 111 , 0 ));

ELSEIF ( @IsMbr("Mar") )3 - @MIN(2,@ROUND ( ( @PRIOR("Hours"->"Dec",1,("FY10":"FY20"))

+ "Hours"->"Jan"+ "Hours"->"Feb" ) / 111 , 0 ));

ELSE3 - @MIN(2,@ROUND ( ( @PRIOR( "Hours", 3 , ("Jan":"Dec") )

+ @PRIOR( "Hours", 2 , ("Jan":"Dec") )+ @PRIOR( "Hours", 1 , ("Jan":"Dec") ) ) / 111, 0 ));

ENDIFENDIF

Figure 35. Technical Details - C

Appendix D - Single-Matrix vs. Multi-Matrix Solutions

From a technical point of view, the structure of an Essbase cube forces all data points to have the same dimensionality.

Strictly speaking, it is not possible to store within an Essbase cube data points of diverse dimensionalities. This is not a defect

but rather a practical and clearly very successful compromise in order to implement Essbase's overall functionality. The most

common workaround is the inclusion, potentially in each and every dimension, of a dimension member called "No

": for example, "No Year", "No Period", "No Product", "No Geography", etc.

Other software product designers have approached the issue differently by implementing data structures that allow measures

of different dimensionalities to coexist. Nagabhushana16 calls these solutions "Multicube" solutions and classifies them

according to several criteria. One classification uses four group descriptors: 1) variables (Express, Pilot, Acumate),

2) structures (Holos), 3) cubes (TM1 and MS OLAP Services), and 4) indicators (Speedware Media). The other classification

is based on three multicube types: 1) block multicube (Business Objects, Gentia, Holos, MS Analysis Services, and TM1),

2) series multicube (Acumate, Express, Media, and Pilot) and 3) atomic multicube (without examples). The author also

mentions "Essbase transparent partitions" as Essbase's way of joining multiple cubes with possibly different dimensionalities.

Appendix E - Dimensions and Smart ListsEarly research to find published material to help evaluate the relevance of this white paper and the solutions already in the

making reinforced the conviction that:

16Nagabhushana, S. (2006),Data Warehousing: OLAP and Data Mining, New Delhi: New Age International (P) Limited, Publishers(www.newagepublishers.com), pp. 231-232.


25/27



a)

the specific treatment of Smart Lists, or more simply of metadata stored as data, has not to date been explored with

as much detail as has been done in this paper, while...

b) Smart Lists implicitly implement changing dimensions...

c) users and developers have indicated that slicing and dicing by Smart List values needs to exist and...

d)

Oracle has specifically addressed the issue in Hyperion Planning version 11.1.2.1 (see Appendix F) and thus in a

way superseded its own solution using "varying Attributes."

Appendix F - Sequel - BSO to ASO

A sequel to this white paper was initiated to investigate

and evaluate the option of programmatically pushing

planning data to a reporting application in order to be

able to fairly compare and contrast the solution presented

in this paper to a solution using this BSO-to-ASO link

offered by Version 11.1.2.1. This investigation has been

rendered practically irrelevant by the release of Hyperion

Planning 11.1.2.3.500, in particular, by a new feature

called Hybrid Aggregation Mode that effectively

implements the automatic link between BSO and ASO as

a built-in feature. This does not mean, though, that

Hybrid Aggregation Mode has also rendered irrelevant

the solutions presented in this paper. They remain quite

relevant in two major ways: a) Structurally, these

solutions do not require a second cube, and they can

implement logic beyond simple selections based on

smart list values, and b) they clearly demonstrate the important distinction between product expertise and design expertise, so

essential to the definition of value-add consulting services. Without a doubt, the commercial product we know as Oracle

Hyperion Planning packages an enormous amount of functionality, know-how, and design. Understanding and knowing how

to apply all its features are extremely valuable skills and can yield much benefit to Oracle clients. Implementing the software

exactly as predicted and prescribed by Oracle will likely result in stable, easy-to-maintain solutions. But it should be obvious

that architecting solutions should be more than faithfully executing recipes, and this, more than the specific solutions

presented in it, is the central message of this paper; product-agnostic guidelines and principles have existed for a long time.17

From the perspective of this paper's objectives, it still seems beneficial to

investigate and document here how quickly a version 11.1.2.1 reporting

application can be created starting from the point of not knowing anything

about this feature. The following two Smart View queries compare 2012

profit numbers from the whECDaso and the whECDpln applications

respectively. whECDaso is a Reporting Application created using the

standard procedure offered by Oracle to set up Reporting Applications. It is

an ASO cube and it was initially created using the "Aggregate Storage

Outline Conversion" wizard. The resulting database was then modified to

convert the Version dimension to three separate "Smart List" dimensions

and to remove irrelevant member formulas. As evidenced by the text in the

first three columns of the first query and a comparison of the data in the two

queries, it is clear that the process correctly mapped the Smart List values

into the nine-dimension ASO cube producing equivalent outputs. The

dimension Versionis no longer needed and is therefore not present in the

reporting application. Not counting interruptions and a couple of typing

errors, it took less than an hour to implement this solution. Analyzing the

effect of the mistakes was in itself a valuable experience.

17Power, D.J.A Brief History of Decision Support Systems.DSSResources.COM, World Wide Web, http://DSSResources.COM/history/dsshistory.html,version 4.0, March 10, 2007.

Figure 36. ASO Cube

Figure 37. Creating the Reporting Application


26/27



Figure 38. Smart View Query Against ASO Cube

Figure 39.Smart View Query Against BSO Cube


27/27


About the Author

Toward the tenth year of a stable career in academia, specializing in decision support technologies, William Hodges accepted

an invitation to step into the trenches to participate directly in the implementation of the type of management-support

applications he could only talk about in an academic environment. He has spent the last 15 years pursuing this line of work in

various capacities, including as a certified Essbase Bootcamp instructor, an independent consultant, a co-proprietor of a

successful mid-size consulting firm, and more recently on the consulting staff of one of todays largest international Oracle EPM implementers.

This career evolution gives him a unique alternate perspective on the challenges and opportunities EPM technologies offer to

designers, implementers, and consumers of management and decision support. He enjoys sharing his perspective on both

nuts-and-bolts matters and theoretical guiding principles, the combination of which has served him well in his own effort to

deliver value to his clients and employers. Earlier presentations include an invitation to data analysts to explore the power of

MDX (see A Path to MDX Mastery, Kscope13, New Orleans, Louisiana, 2013).

slow fast changing dim

Documents