Upload
sen2nat
View
245
Download
0
Embed Size (px)
Citation preview
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/8/10/2019 Slow Fast Changing Dim
2/27
Slow and Fast-Changing Dimensions in HP Hodges
www.odtug.com 2 ODTUG Kscope14
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.
http://www.odtug.com/http://www.odtug.com/8/10/2019 Slow Fast Changing Dim
3/27
Slow and Fast-Changing Dimensions in HP Hodges
www.odtug.com 3 ODTUG Kscope14
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
http://www.odtug.com/http://www.odtug.com/8/10/2019 Slow Fast Changing Dim
4/27
Slow and Fast-Changing Dimensions in HP Hodges
www.odtug.com 4 ODTUG Kscope14
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
http://www.odtug.com/http://www.odtug.com/8/10/2019 Slow Fast Changing Dim
5/27
Slow and Fast-Changing Dimensions in HP Hodges
www.odtug.com 5 ODTUG Kscope14
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
http://www.odtug.com/http://www.odtug.com/8/10/2019 Slow Fast Changing Dim
6/27
8/10/2019 Slow Fast Changing Dim
7/27
Slow and Fast-Changing Dimensions in HP Hodges
www.odtug.com 7 ODTUG Kscope14
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
http://www.odtug.com/http://www.odtug.com/8/10/2019 Slow Fast Changing Dim
8/27
Slow and Fast-Changing Dimensions in HP Hodges
www.odtug.com 8 ODTUG Kscope14
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.
http://www.odtug.com/http://www.odtug.com/8/10/2019 Slow Fast Changing Dim
9/27
8/10/2019 Slow Fast Changing Dim
10/27
Slow and Fast-Changing Dimensions in HP Hodges
www.odtug.com 10 ODTUG Kscope14
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
http://www.odtug.com/http://www.odtug.com/8/10/2019 Slow Fast Changing Dim
11/27
Slow and Fast-Changing Dimensions in HP Hodges
www.odtug.com 11 ODTUG Kscope14
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
http://www.odtug.com/http://www.odtug.com/8/10/2019 Slow Fast Changing Dim
12/27
Slow and Fast-Changing Dimensions in HP Hodges
www.odtug.com 12 ODTUG Kscope14
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
http://www.odtug.com/http://www.odtug.com/8/10/2019 Slow Fast Changing Dim
13/27
Slow and Fast-Changing Dimensions in HP Hodges
www.odtug.com 13 ODTUG Kscope14
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
http://www.odtug.com/http://www.odtug.com/8/10/2019 Slow Fast Changing Dim
14/27
Slow and Fast-Changing Dimensions in HP Hodges
www.odtug.com 14 ODTUG Kscope14
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
http://www.odtug.com/http://www.odtug.com/8/10/2019 Slow Fast Changing Dim
15/27
Slow and Fast-Changing Dimensions in HP Hodges
www.odtug.com 15 ODTUG Kscope14
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
http://www.odtug.com/http://www.odtug.com/8/10/2019 Slow Fast Changing Dim
16/27
Slow and Fast-Changing Dimensions in HP Hodges
www.odtug.com 16 ODTUG Kscope14
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
http://www.odtug.com/http://www.odtug.com/8/10/2019 Slow Fast Changing Dim
17/27
Slow and Fast-Changing Dimensions in HP Hodges
www.odtug.com 17 ODTUG Kscope14
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
http://www.odtug.com/http://www.odtug.com/8/10/2019 Slow Fast Changing Dim
18/27
Slow and Fast-Changing Dimensions in HP Hodges
www.odtug.com 18 ODTUG Kscope14
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
http://www.odtug.com/http://www.odtug.com/8/10/2019 Slow Fast Changing Dim
19/27
Slow and Fast-Changing Dimensions in HP Hodges
www.odtug.com 19 ODTUG Kscope14
/* 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.
http://www.odtug.com/http://www.odtug.com/8/10/2019 Slow Fast Changing Dim
20/27
8/10/2019 Slow Fast Changing Dim
21/27
Slow and Fast-Changing Dimensions in HP Hodges
www.odtug.com 21 ODTUG Kscope14
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
http://www.odtug.com/http://www.odtug.com/8/10/2019 Slow Fast Changing Dim
22/27
Slow and Fast-Changing Dimensions in HP Hodges
www.odtug.com 22 ODTUG Kscope14
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
http://www.odtug.com/http://www.odtug.com/8/10/2019 Slow Fast Changing Dim
23/27
Slow and Fast-Changing Dimensions in HP Hodges
www.odtug.com 23 ODTUG Kscope14
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
http://www.odtug.com/http://www.odtug.com/8/10/2019 Slow Fast Changing Dim
24/27
Slow and Fast-Changing Dimensions in HP Hodges
www.odtug.com 24 ODTUG Kscope14
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.
http://www.odtug.com/http://www.odtug.com/8/10/2019 Slow Fast Changing Dim
25/27
Slow and Fast-Changing Dimensions in HP Hodges
www.odtug.com 25 ODTUG Kscope14
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
http://www.odtug.com/http://www.odtug.com/8/10/2019 Slow Fast Changing Dim
26/27
Slow and Fast-Changing Dimensions in HP Hodges
www.odtug.com 26 ODTUG Kscope14
Figure 38. Smart View Query Against ASO Cube
Figure 39.Smart View Query Against BSO Cube
http://www.odtug.com/http://www.odtug.com/8/10/2019 Slow Fast Changing Dim
27/27
Slow and Fast-Changing Dimensions in HP 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).