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
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
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
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
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
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.
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.
Remarks
1.
2.
3.
4.
Hybrid dimensions
5.
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.
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
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.
"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
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
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).
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.
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
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.
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
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.
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
"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
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 ( @IsLev("Players",0) )
IF( ("View"->"MembershipStatus"->&ReferenceYear->&ReferenceMonth ) == 1 )
"View";
ENDIF
ENDIF
Gold
IF ( @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
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
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
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
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
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
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
ScenarioA:
ScenarioB:
ScenarioC:
ScenarioD:
ScenarioE:
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
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.
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.
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);
@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 ;
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);
@CALCMODE(BOTTOMUP);
IF ( @IsGen("Period",4)
and @IsMbr("Total")
and @IsMbr("Default")
and @isMbr("NoCourt")
and @IsSibling("NoPlayer") )
IF ( "ActualHours" <> #MISSING )
"ActualHours";
ELSE
IF ( @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 ;
ENDIF
ENDIF
ENDIF
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);
@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 ));
ELSE
3 - @MIN(2,
@ROUND ( ( @PRIOR( "Hours", 3 , ("Jan":"Dec") )
+ @PRIOR( "Hours", 2 , ("Jan":"Dec") )
+ @PRIOR( "Hours", 1 , ("Jan":"Dec") ) ) / 111, 0 ));
ENDIF
ENDIF
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...
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."
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
www.odtug.com
26
ODTUG Kscope14
Hodges
www.odtug.com
27
ODTUG Kscope14