Slow Fast Changing Dim

SLOW AND FAST-CHANGING DIMENSIONS IN
HYPERION PLANNING
William 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 fast and Hyperion Planning included 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 compute
the 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, it calls for software methodologies and/or products that facilitate the implementation of these more complex
designs. 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.3 Hyperion 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
Hyperion 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 a
Reporting 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
www.odtug.com
ODTUG Kscope14
Slow and Fast-Changing Dimensions in HP
Hodges
attributes4 and 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 year
And:
YTD Profit at the end of September of some future year based on the metadata for January of the same
year 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. The
paper 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 Volume
Chairs
Chair-A
Chair-B
Desks
Desk-A
Desk-B
Lamps
Lamp-A
Lamp-B
Tables
Table-A
Table-B
Bookcases
Bookcase-A
Bookcase-B
North
220
128
92
137
71
66
245
123
122
236
91
145
215
130
85
South
168
116
52
206
98
108
140
90
50
241
119
122
209
76
133
Central
196
110
86
207
149
58
261
123
138
230
88
142
286
142
144
East
240
141
99
127
55
72
113
59
54
242
95
147
258
117
141
West
180
106
74
139
66
73
171
111
60
148
95
53
280
133
147
Other-A
123
55
68
123
55
68
141
68
73
123
55
68
123
55
68
Other-B
234
117
117
234
117
117
252
117
135
252
117
135
252
117
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 Volume imply the existence of two additional dimensions. They will be partly right. This is indeed a twodimensional 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 an
architectural point of view, the notions of Measure and Year can 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:
See Appendix B for a discussion about why Varying Attributes are not an option.
www.odtug.com
ODTUG Kscope14
Hodges
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
Figure 3. Smart Lists
dimensionality beyond the explicit
representations 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
Figure 4. Changing Dimensions as Data
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 dimension as defined in the data
warehousing literature. It is a Type 6 solution 5 because it maintains a history of all the changes.
en.wikipedia.org/wiki/Slowly_Changing_Dimension
www.odtug.com
ODTUG Kscope14
Hodges
First Level of Analysis - A Simple Sample

Application 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.6 This 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
Figure 5. Data from Essbase, Formulas in Excel
as revenue generated by them. The simple Smart View report in
Figure 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
Platinum
Gold
Silver
Status
FY11
YearTotal
(318)
14,779
13,575
28,036
FY12
YearTotal
7,329
17,469
12,821
37,619
FY13
YearTotal
13,585
10,018
4,428
28,030
SOLUTION B
FY14
YearTotal
16,256
11,820
9,643
37,719
FY15
YearTotal
17,833
15,906
19,170
52,909
Platinum
Gold
Silver
Status
FY11
YearTotal
(318)
14,779
13,575
28,036
FY12
YearTotal
7,329
17,469
12,821
37,619
FY13
YearTotal
13,585
10,018
4,428
28,030
FY14
YearTotal
16,256
11,820
9,643
37,719
FY15
YearTotal
17,833
15,906
19,170
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 a
characteristic 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 page 2 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
6
The paper shows only fictitious situations and data, yet these fictitious cases were inspired by and illustrate components of real applications successfully
implemented at client sites.
www.odtug.com
ODTUG Kscope14
Hodges
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" method7 discussed 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 8 published 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."9 Essbase 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.10 From 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 fundamental
principles.
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 have
participated 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
7
http://en.wikipedia.org/wiki/Slowly_changing_dimension
http://en.wikipedia.org/wiki/List_of_important_publications_in_computer_science
9
Niklaus Wirth, 1976, "Algorithms + Data Structures = Programs", Prentice Hall, p. 11.
10
ibid
8
www.odtug.com
ODTUG Kscope14
Hodges
that there is not more than one valid intersection for each entity of one of the dimensions, because this is an indicator of an
implicit one-to-many entity relationship and an invitation to model these two dimensions as a collection of parent-child
relationships within a single dimension.
From this paper's perspective, what is important is not the fact that a design can be shown to be sub-optimal, but rather that it
is possible to validly model dimensionality in a variety of ways. Justified by this realization, it is possible then to explore and
consider other ways to model a problem that, while atypical, may actually allow and support not otherwise possible dataprocessing requirements.
If we understand the problem as a classic case of "Data + Structures = Programs," we can design and implement solutions
before they are included as product features.
Atypical Essbase Designs

The table below lists seven ways in which a given design could be modified to fit specific requirements. Readers may
recognize some of them as techniques they have themselves used in the past to handle some real-world requirement.
Short Description
Remarks
1.
Flat Hierarchies with member

formulas
2.
Two dimensions in one, one

dimension in two
Multiple versions of a dimension
member, in particular, accounts
3.
4.
Hybrid dimensions
5.
Combining dimensions in order to

reduce the number of dimensions
users must think about
Attribute dimensions as a means to
eliminate dimensions
6.
7.
An outline ultimately is a collection of formulas. From a mathematical point of view, it is possible to obtain
the exact same results in every member, eliminating the hierarchical relationships and instead using
member formulas to produce all the member values. In planning applications using Smart Lists, if a parent
is the sum of mutually exclusive children, and if the requirements call for the Smart List values to appear
when displaying the parent, then a formula must be used instead.
e.g., Portfolio within Region, Region within Portfolio; two dimensions for time, Year and Period
General Ledgers often include accounts that imply a multi-dimensional meaning: for example, 10000.001,
10000.002 where 10000 means "Sales", 001 means "Cars" and "002" means "Trucks." When similar multidimensionality applies only to a few accounts, then rather than creating two dimensions (in this case,
"Account" and "Product") it may be preferable to retain the two accounts in a single "Account" dimension in
the Essbase outline.
When an application includes dimensions valid in very limited mutually exclusive contexts, it may be best to
combine them all into a single hybrid dimension in order to keep the number of dimensions low.
Similar to number 4 above but for the explicit purpose of reducing the total number of dimensions,
candidates should be chosen such that combining them does not create a very complex hierarchy.
When we discover that a dimension is actually an attribute of a metadata value, rather than of a numeric
value, we have a perfect candidate for an attribute dimension. This will reduce the number of potential
blocks and will retain cross-tabulation capabilities. Analytically, this is similar to eliminating transitional
relationships in database normalization exercises.
The best example of this is Time broken up into Year and Period, but there may be others. One of the
arguments for implementing attribute dimensions in place of alternate hierarchies within a single dimension
is that attribute dimensions support cross-tabulations.
Breaking up dimensions in order to

facilitate cross-tabulation
More about Solution A and Solution B

The queries discussed earlier are shown again here below, but this time more is revealed. Member names instead of aliases
and the POV members are displayed to reveal the structural differences.
SOLUTION A
SOLUTION B
NoCourt
Customers
Profit
Platinum
Gold
Silver
Status
All Customers
Customers
NoCourt
FY11
YearTotal
(318)
14,779
13,575
28,036
FY12
YearTotal
7,329
17,469
12,821
37,619
FY13
YearTotal
13,585
10,018
4,428
28,030
FY14
YearTotal
16,256
11,820
9,643
37,719
FY15
YearTotal
17,833
15,906
19,170
52,909
Profit - Platinum
Profit - Gold
Profit - Silver
Profit
FY11
YearTotal
(318)
14,779
13,575
28,036
FY12
YearTotal
7,329
17,469
12,821
37,619
FY13
YearTotal
13,585
10,018
4,428
28,030
FY14
YearTotal
16,256
11,820
9,643
37,719
FY15
YearTotal
17,833
15,906
19,170
52,909
Figure 7. Difference between Solution A and Solution B
www.odtug.com
ODTUG Kscope14
Hodges
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
Figure 8. Substitution Variables
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 of
the two approaches.
"View"->"MembershipStatus"->&ReferenceYear->&ReferenceMonth
"DefaultRating"->"Total"->"Default"->@Member(@HspNumToString(@Int("sRefYear")))->@Member(@HspNumToString(@Int("sRefMonth")))
11
More specifically, it is very common to store "timeless" data in Essbase making use of naming conventions such as "No Month" and "No Year". All the
possible 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 also
Appendix D for a brief discussion on dimensionality as implemented in single-matrix databases such as Essbase.
www.odtug.com
ODTUG Kscope14
Membership Status
David
David
David
David
David
David
David
David
David
David
David
David
FY11
FY11
FY11
FY11
FY11
FY11
FY11
FY11
FY11
FY11
FY11
FY11
Jan
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
Oct
Nov
Dec
Silver
Silver
Silver
Gold
Gold
Gold
Platinum
Platinum
Platinum
Gold
Gold
Gold
Hodges
Profit
1,588.78
(50.01)
1,473.21
1,183.84
410.69
662.64
1,857.67
974.22
1,715.23
1,068.45
429.00
2,047.12
Profit-Platinum
Profit-Gold
Profit-Silver
1,588.78
(50.01)
1,473.21
1,183.84
410.69
662.64
1,857.67
974.22
1,715.23
1,068.45
429.00
2,047.12
Figure 9. Profit Assigned to Status Based on Current Status
Membership Status
David
David
David
David
David
David
David
David
David
David
David
David
FY11
FY11
FY11
FY11
FY11
FY11
FY11
FY11
FY11
FY11
FY11
FY11
Jan
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
Oct
Nov
Dec
3
3
3
2
2
2
1
1
1
2
2
2
Profit
Profit-Platinum
1,588.78
(50.01)
1,473.21
1,183.84
410.69
662.64
1,857.67
974.22
1,715.23
1,068.45
429.00
2,047.12
Profit-Gold
Profit-Silver
1,588.78
(50.01)
1,473.21
1,183.84
410.69
662.64
1,857.67
974.22
1,715.23
1,068.45
429.00
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 page 6).
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.
www.odtug.com
ODTUG Kscope14
Hodges
Solution B discussed in the Introduction has several advantages over Solution A, primarily the ability to handle changing
dimensions. Yet, relative to what is normally expected from dimensional models, it is limited in two ways: a) It requires the
explicit creation of each and every version of each and every metric or account required to represent the changing
dimensions, and b) the metrics must be created in such a way that the natural order of calculation does not interfere or nullify
the order of calculation required to compute these metrics.
Having stated above that a host environment must match the dimensionality of
the data it hosts, it is relevant now to point to the fact that none of the data
displayed in these reports existed prior to any of it being loaded into the
environment, and more importantly nothing in the original data itself revealed
the existence of an amount for Platinum, an amount for Gold, and an amount for
Silver. As a corollary to the earlier-mentioned principle, one can further assert
that a host needs to recognize, respect, and faithfully represent the data's
dimensionality, in its current form as well as in forms that may be derived
through further analysis. Again, the host, contrary to what the above reports
could be interpreted to illustrate, does not add dimensionality to the data.
Instead, it provides the structure and possibly the computational mechanisms to
derive new data points that are implicit in those that already exist, as was the
case in the derivation of profit by status from available totals (indicated by the
circular arrows above).
For many years, Essbase was a financial analysis environment designed to store
numbers only. Purists might argue that this is all it should ever be expected or
allowed to do. Yet, as adoption increased and evolved, users requested the
ability to store non-numeric information. Text and Date measure types were
Figure 11. Text Data Types
added to the product (see Figure 11). Essbase utilization was also extended by
making it the core component of business applications such as Hyperion
Planning. Smart Lists are used in Hyperion Planning to simulate and support the storage of text in Essbase. Smart Lists are
applicable to any dimension, not only measures. Attribute dimensions are related features that, while primarily a metadata
construct, are also a way to store qualitative information and thus satisfy some of the user-expressed requirements.
With these advancements, it is now possible, and indeed users expect to be able, to input into Hyperion Planning not only
data but also metadata, for example, to change a product classification from "Domestic" to "Commercial." The classifications
will be stored as numbers: for example, 1 for "Domestic" and 2 for "Commercial," and the Smart List feature will translate
these numbers to text at display time. Users will expect reports to immediately reflect these changes. They will also expect to
be able to select something like "Domestic" from a list of dimension members in order to get the monthly revenue for sales of
"Domestic" products (the type of requirement this paper addresses).
Solutions
This section summarizes four solutions, each more analytically powerful than the previous one. It also mentions in passing
solutions that could not at all satisfy the requirements. In order of complexity and analytical power, they have been identified
as Solution B, Solution V, Solution VS, and Solution HP. Solution B has two variations: Solution B1 and Solution B2, for a
total of five separate sample implementations capable of addressing the requirements set forth at the beginning of this paper.
Solution B1 is the simplest to implement; Solution VS is more technically challenging but also more analytically powerful;
Solution HP is the Hyperion Planning version of Solution VS. In addition and to provide a means for comparison, a solution
using varying attributes was partially implemented. This solution is illustrated in the appendix and is called Solution VA.
Rejected Solutions
1.
Stored (Basic) Dimensions: The requirements are not only about adding a stored dimension.
2.
Attribute Dimensions: An attribute dimension is an unchanging dimension, therefore it cannot fulfill the
requirements stated at the beginning. Solution A above must be rejected.
3.
Varying Attributes: Varying attributes are managed by system administrators and are not operational with Hyperion
Planning. Varying attributes are a "better Solution A" and would satisfy the requirement of maintaining metadata
history and of supporting analysis based on metadata as of a certain time period. But they cannot be managed by the
user and therefore they do not satisfy the requirements presented in this paper.
www.odtug.com
ODTUG Kscope14
4.
Hodges
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 this
paper, 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. 12 The 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 calcs so 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 can
be 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.
Figure 12. Outline - Solution B1
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 (see Figure 13). As can be seen in the figure,
the combinations have to be built explicitly.
Figure 13. Outline - Solution B2
12
The solution was a direct response to reporting requirements that would have otherwise been impossible to implement, namely, the slicing and dicing of a
20-GB cube based on the ever-changing dimensionality implicit in the various smart list values users must select in order to build their budgets. The
application 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 the
approach explained in this paper, limiting their effort to the final nuances of the requirements of the moment.
www.odtug.com
10
ODTUG Kscope14
Hodges
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.
Figure 14. Outline - Solution V
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 Application

The user interface building capabilities offered by Hyperion Planning facilitate addressing the requirements stated on page 2.
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.
Figure 15. Outline - Solution VS
13
The earlier-mentioned 20-GB real world solution that inspired this investigation and this paper required the creation of about 150 dynamic calc accounts
modeling slicing and dicing according to four data-driven implicit dimensions. Without much effort, they were structured and designed in a modular fashion
so 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. This
papers content still remains a faithful representation of the foundational principles that made that applications reporting capabilities possible.
www.odtug.com
11
ODTUG Kscope14
Hodges
Figure 17. Scenarios
Figure 16. Perspectives
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 on
performance 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
www.odtug.com
12
ODTUG Kscope14
Hodges
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 Implementation
Implementation 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.15 The 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
14
15
Players
See Appendix C for an explanation of the inclusion of @CALCMODE and pages 19 and 20 for details regarding the aggregation of upper-level members.
Adamson, Christopher (2006), Mastering Data warehouse Aggregates: Solutions for Star Schema Performance, Indianapolis, IN: Wiley.
www.odtug.com
13
ODTUG Kscope14
Hodges
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.
YearTotal
FY10
NoCourt
Revenue
Platinum 57,389
Gold
46,808
Silver
25,091
Expenses
35,045
36,944
20,262
Profit
22,344
9,864
4,829
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.
Platinum
IF( ("View"->"MembershipStatus"->&ReferenceYear->&ReferenceMonth ) == 1 )
"View";
ENDIF
ENDIF
Gold
"View";
ENDIF
ENDIF
Silver
"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 (@IsMbr("Main"))
IF( "Main"->"View"->"MembershipStatus"->&ReferenceYear->&ReferenceMonth" == 1 )
"Main"->"View";
ENDIF
ELSEIF (@IsMbr("ScenarioA"))
IF( "Main"->"View"->"MembershipStatus"->&ReferenceYearA->&ReferenceMonthA == 1 )
"Main"->"View";
ENDIF
ELSEIF (@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 page 6. 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).
www.odtug.com
14
ODTUG Kscope14
Hodges
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.
Figure 23. Results - VS - 1
FY11
FY11
FY11
FY11
FY11
FY11
FY11
FY11
FY11
FY11
FY11
FY11
FY11
Jan
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
Oct
Nov
Dec
YearTotal
David
Main
View
Membership
Status
2
3
2
2
2
1
2
3
2
3
2
3
David
Main
View
David
ScenarioA
Platinum
Profit
Profit
David
ScenarioA
Gold
David
ScenarioA
Silver
Profit
Profit
369.26
480.44
820.00
898.52
895.05
898.38
877.34
880.64
896.60
891.26
904.15
887.53
9,699.15
369.26
480.44
820.00
898.52
895.05
898.38
877.34
880.64
896.60
891.26
904.15
887.53
9,699.15
David
ScenarioB
Platinum
David
ScenarioB
Gold
David
ScenarioB
Silver
David
ScenarioC
Platinum
David
ScenarioC
Gold
Profit
Profit
Profit
Profit
Profit
369.26
480.44
820.00
898.52
895.05
898.38
877.34
880.64
896.60
891.26
904.15
887.53
9,699.15
David
ScenarioC
Silver
Profit
369.26
480.44
820.00
898.52
895.05
898.38
877.34
880.64
896.60
891.26
904.15
887.53
9,699.15
Figure 24. Results - VS - 2
FY11
FY11
FY11
FY11
Platinum
Gold
Silver
ByStatus
Players
ScenarioA
28,729
42,497
12,907
84,133
Players
ScenarioB
34,078
39,085
10,970
84,133
Players
ScenarioC
43,768
9,340
31,025
84,133
FY12
FY12
FY12
FY12
Platinum
Gold
Silver
ByStatus
29,153
44,383
13,543
87,079
36,283
39,665
11,131
87,079
45,002
9,922
32,155
87,079
FY13
FY13
FY13
FY13
Platinum
Gold
Silver
ByStatus
33,885
45,180
22,588
101,653
45,178
45,180
11,295
101,653
45,180
22,588
33,885
101,653
FY14
FY14
FY14
FY14
Platinum
Gold
Silver
ByStatus
34,380
45,840
22,920
103,140
45,840
45,840
11,460
103,140
45,840
22,920
34,380
103,140
FY15
FY15
FY15
FY15
Platinum
Gold
Silver
ByStatus
34,863
46,484
23,242
104,589
46,484
46,484
11,621
104,589
46,484
23,242
34,863
104,589
David
ScenarioA
David
ScenarioB
9,699
David
ScenarioC
Matthew
ScenarioA
9,699
9,699
10,356
10,356
9,699
9,699
Matthew
ScenarioB
Matthew
ScenarioC
10,356
9,699
10,356
10,356
10,356
Thomas
ScenarioA
Thomas
ScenarioB
10,970
10,970
10,970
10,970
11,131
11,131
11,131
11,131
11,295
11,295
11,295
11,295
11,460
11,460
11,460
11,460
11,621
11,621
11,621
11,621
10,512
10,512
10,512
10,512
10,512
10,512
10,512
10,512
10,512
10,512
11,295
11,295
11,295
11,295
11,295
11,295
11,295
11,295
11,295
11,295
11,460
11,460
11,460
11,460
11,460
11,460
11,460
11,460
11,460
11,460
11,621
11,621
11,621
11,460
11,621
11,621
11,621
11,295
11,460
11,460
11,460
11,131
11,295
11,295
11,295
10,970
11,131
10,512
10,512
Thomas
ScenarioC
10,970
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.
www.odtug.com
15
ODTUG Kscope14
Hodges
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.
Figure 26. Allocation of Total Profit
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
www.odtug.com
16
ODTUG Kscope14
Hodges
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.
Figure 27. Slowly Changing Dimensions
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 and
6) 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
www.odtug.com
Figure 28. Scenario Definitions
17
ODTUG Kscope14
Figure 29. Compare Scenarios Form
Hodges
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
Figure 30. Player-level Analysis
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.
www.odtug.com
18
ODTUG Kscope14
Hodges
/* 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";
ENDIF
ENDIF
/* Platinum */
@CALCMODE(CELL);
@CALCMODE(TOPDOWN);
IF ( @IsSibling("NoPlayer") AND @IsMbr("NoCourt") AND @IsGen("Period",4) )
IF ( "MembershipStatus" == 1 )
"Default"->"Version";
ENDIF
ENDIF
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.
www.odtug.com
19
ODTUG Kscope14
Hodges
Solution VS discussed earlier defines "Player" (the generation 1 member of the "Player" dimension) as a dynamic calc
member, thus eliminating the need for dynamic aggregation. In cases where databases are small, this is most likely the better
solution.
Again,
Stated Requirement
Default Scenario: Current metadata
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 year.
YTD Profit at the end of September of some future year based on the
metadata for January of the same year generated by a forecasting
algorithm launched by a business rule when the user's input is saved.
ScenarioA:
March 2012 metadata
ScenarioB:
June 2013 metadata
ScenarioC:
Same month, 2011 metadata
ScenarioD:
Metadata from January of the same year
ScenarioE:
December 2011 metadata
In order to be able to satisfy the requirement of performing the comparison of summary-level data using a Hyperion Planning
form, "Player" (the Gen 1 member of the dimension of the same name) was also implemented as a dynamic calc member in
the Planning cube.
www.odtug.com
20
ODTUG Kscope14
Hodges
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 page 5, 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.
Membership Status
Platinum
Gold
Silver
Total
FY11
7,134
17,829
3,074
28,036
www.odtug.com
FY12
16,838
14,592
6,189
37,619
FY13
11,234
11,920
4,876
28,030
FY14
22,425
7,927
7,367
37,719
FY15
26,945
19,745
6,219
52,909
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
21
ODTUG Kscope14
Hodges
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: Varying
Attributes
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 fulfillment
of the requirements presented in the
Introduction on page 1. 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
Figure 32. Varying Attributes
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
www.odtug.com
22
ODTUG Kscope14
Hodges
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 still
allows for manual forecasting by simply allowing users to enter "Actual Clinic Hours"
into future data cells.
/* ClinicHours: Computed as Actual value if available otherwise as a randomized
moving average. Rounded to multiples of 1/4 hour (notice division by four).
*/
@CALCMODE(CELL);
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 ;
ENDIF
ENDIF
ENDIF
Future court usage hours are estimated using a randomized moving average. The formula allows for manual
forecasting by simply allowing users to enter "Actual Hours" values into future data cells.
/* Hours: Computed as Actual value if available otherwise as a randomized moving average rounded
to multiples of 1/4 hour (notice division by four).
*/
@CALCMODE(CELL);
and @IsMbr("Total")
and @IsMbr("Default")
and @isMbr("NoCourt")
and @IsSibling("NoPlayer") )
IF ( "ActualHours" <> #MISSING )
"ActualHours";
ELSE
@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;
@ROUND ( ( @PRIOR( "Hours"->"Nov",1,("FY10":"FY20") )
+ @PRIOR( "Hours"->"Dec",1,("FY10":"FY20") )
+ "Hours"->"Jan" ) / ( 3 + "RandomNumber") * 3.8 , 0 ) / 4;
@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 ;
ENDIF
ENDIF
ENDIF
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
www.odtug.com
23
ODTUG Kscope14
Membership Status is computed as a function of the total number of hours paid for
during the last three months.
Hodges
The number of hours paid for in the future is computed using a randomized moving average (as earlier
illustrated). The table below illustrates the fact that court hours have been paid through December 2012
and that hours in subsequent months have been estimated in multiples of 15 minutes. Then the number of
hours of court usage over a period of three months has been used to determine membership status.
/* MembershipStatus
Computed based on the total number of usage hours during the previous three months.
1 = Platinum, 2 = Gold, 3 = Silver.
*/
@CALCMODE(CELL);
AND @IsMbr("Total")
AND @IsMbr("Default")
AND @isMbr("NoCourt")
AND @IsSibling("NoPlayer") )
3 - @MIN(2,
@ROUND ( ( @PRIOR( "Hours"->"Oct",1,("FY10":"FY20") )
+ @PRIOR( "Hours"->"Nov",1,("FY10":"FY20") )
+ @PRIOR( "Hours"->"Dec",1,("FY10":"FY20") ) ) / 111, 0 ));
3 - @MIN(2,
@ROUND ( ( @PRIOR( "Hours"->"Nov",1,("FY10":"FY20") )
+ @PRIOR( "Hours"->"Dec",1,("FY10":"FY20") )
+ "Hours"->"Jan" ) / 111 , 0 ));
3 - @MIN(2,
@ROUND ( ( @PRIOR("Hours"->"Dec",1,("FY10":"FY20"))
+ "Hours"->"Jan"
+ "Hours"->"Feb" ) / 111 , 0 ));
ELSE
3 - @MIN(2,
@ROUND ( ( @PRIOR( "Hours", 3 , ("Jan":"Dec") )
+ @PRIOR( "Hours", 2 , ("Jan":"Dec") )
+ @PRIOR( "Hours", 1 , ("Jan":"Dec") ) ) / 111, 0 ));
ENDIF
ENDIF
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
<dimension name>": 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 Lists

Early 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:
16
Nagabhushana, S. (2006), Data Warehousing: OLAP and Data Mining, New Delhi: New Age International (P) Limited, Publishers
(www.newagepublishers.com), pp. 231-232.
www.odtug.com
24
ODTUG Kscope14
a)
Hodges
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
Figure 36. ASO Cube
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 Version is 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.
Figure 37. Creating the Reporting Application
17
Power, 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.
www.odtug.com
25
ODTUG Kscope14
Hodges
Figure 38. Smart View Query Against ASO Cube
Figure 39.Smart View Query Against BSO Cube
www.odtug.com
26
ODTUG Kscope14
Hodges
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).
www.odtug.com
27
ODTUG Kscope14

Slow Fast Changing Dim

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Slow Fast Changing Dim

Uploaded by

Copyright:

Available Formats

SLOW AND FAST-CHANGING DIMENSIONS IN

Slow and Fast-Changing Dimensions in HP

Figure 1. 15x7 Array

Slow and Fast-Changing Dimensions in HP

Figure 2. 15x5x3x2 Array

Slow and Fast-Changing Dimensions in HP

First Level of Analysis - A Simple Sample

Figure 6. Two Solutions, Same Output

Slow and Fast-Changing Dimensions in HP

A Few Words about the Underlying Experimental Methodology

Slow and Fast-Changing Dimensions in HP

Atypical Essbase Designs

Flat Hierarchies with member

Two dimensions in one, one

Combining dimensions in order to

Breaking up dimensions in order to

More about Solution A and Solution B

Figure 7. Difference between Solution A and Solution B

Slow and Fast-Changing Dimensions in HP

Metadata History vs. Metadata Versions

Slow and Fast-Changing Dimensions in HP

Figure 9. Profit Assigned to Status Based on Current Status

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

Gradual Development of Increasing Analytical Power

Slow and Fast-Changing Dimensions in HP

Slow and Fast-Changing Dimensions in HP

Basic Solution (Solution B)

Figure 12. Outline - Solution B1

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

Figure 13. Outline - Solution B2

Slow and Fast-Changing Dimensions in HP

Unfortunately, the natural order of calculation for BSO Essbase Outlines

Figure 14. Outline - Solution V

Solution VS - View and Scenario Dimensions

Solution HP - Hyperion Planning Application

Slow and Fast-Changing Dimensions in HP

Figure 17. Scenarios

Figure 16. Perspectives

Figure 18. Forecasting Algorithm

Slow and Fast-Changing Dimensions in HP

Formula for Profit - Platinum

Figure 19. Implementation of Solution B1

Implementation B2 - Multiple Versions of an Account - Tree Hierarchy

Figure 20. Implementation of Solution B2

Slow and Fast-Changing Dimensions in HP

Implementation of Solution V - View Dimension

Figure 21. Implementation of Solution V

Implementation of Solution VS - View and Scenario Dimensions

Figure 22. Implementation of Solution VS

Slow and Fast-Changing Dimensions in HP

Figure 24. Results - VS - 2

Figure 25. Results - VS - 3 - Aggregated Values

Slow and Fast-Changing Dimensions in HP

The figures displayed on this page collectively

Implementation of Solution HP - Hyperion Planning

Slow and Fast-Changing Dimensions in HP

Figure 28. Scenario Definitions

Slow and Fast-Changing Dimensions in HP

Slow and Fast-Changing Dimensions in HP

Figure 31. Dynamically Calculated Versions

Slow and Fast-Changing Dimensions in HP

Default Scenario: Current metadata

In a Hyperion Planning form Display for comparison:

March 2012 metadata