Architecture, Features, and Hierarchical Data Types 13
Tracks all hierarchy and attribute changes with a full-featured audit log
Manages parallel hierarchies
Can serve as the main point-of-entry to update subscribing systems or be used after-the-fact
for reconciliation and analysis
Ease of Use
Although Hyperion MDM is designed to manage and validate the most complex dimensional
structures and their related metadata requirements, the interface provides the user with an
intuitive and familiar look and feel.
For each system or data set that the tool manages (though import or direct input), there is a
graphical representation of the data. To validate this dimensional data, a metadata repository is
used to house user-defined business rules, validation instructions, and relationship
information. As the dimensional data changes within each participating system or within
Hyperion MDM, data integrity issues are regulated, validated, and reported.
Hyperion MDM is specifically designed to synchronize data across multiple systems. All
functionality within the tool is focused on adding efficiency to the hierarchical data-
The implementation of Hyperion MDM involves a configuration process, as opposed to a
custom development process. Configuration mitigates the inherent risks and testing cycles
associated with custom programming.
After implementation, Hyperion MDM provides several data management features that
support large-scale analysis and reconciliation of data.
Table 2 Efficiency Features
Multiple instances of data dimensions that can be saved and used for historical
reporting, comparisons, reconciliations, and what-if analysis
Business rule enforcement
User-defined validations, ranging from simple data verification to organizational
policies, that can be applied across dimensions in a real-time or batch mode
Hierarchy debugging tools
Instruments that enable the user to analyze integrity issues across multiple data
To support the changing needs of a dynamic business environment, Hyperion MDM provides
an intuitive, graphical configuration utility. This utility, designed for the non-technical user,
enables immediate changes to Hyperion MDM functionality without the need for custom
14 About Hyperion MDM
The security model of Hyperion MDM manages user access at the following levels:
Versions—User access is restricted based on the version status
A working version is accessible to all users based on their access
A submitted version is editable only to system administrators and functional
Finalized and expired versions are read only to all users and administrators.
Hierarchy—User access can be restricted to certain areas within a hierarchy. For example,
within the chart of accounts, group y can only maintain the Asset structure. If a user does
not have access to a hierarchy, the hierarchy is not displayed. If a user does not have access
to any hierarchies in a version, the version is not displayed.
Property categories—User access can be restricted to certain property categories for a
specified node. In most cases property categories are based on a system basis. For example,
user A may be allowed to access the Essbase property category with read/write permission
and the Financial Management property category group with read only permission. If a user
does not have access to a property category, the tab does not display.
Administrative and User Types—Users can be grouped into four administrative types:
System Administrator—have full access including to metadata
Functional Administrator—have full access to the hierarchy data but do not have
ability to change metadata
Security Administrator—can only create and assign logins
Normal user—only have access to the information based on the node access groups to
which they are assigned and the property categories to which they are granted access
The configuration utility for Hyperion MDM supports user-defined validations that enforce
integrity and policy issues. These business rules can be applied during the data entry process or
routinely in a batch mode.
Hierarchical Data Management Types
Types of hierarchical data managed by Hyperion MDM are:
Charts of accounts
Hyperion MDM Components 15
The Hyperion MDM N-Tier application is based on an application server (n-tier) architecture
rather than upon the model used in the Hyperion MDM Client Server product. Use of an
application-server architecture enables the bulk of the system processing to be performed on a
centralized server and simplifies the client requirements for each end user. The difference to the
back-end of the system is significant, however, the difference to the user interface and thus to
the user is minor.
Figure 2 N-Tier Architecture
The preceding diagram gives a top-level overview of the Hyperion MDM N-Tier architecture.
Hyperion MDM Client is a Windows application that runs on the user’s local machine. The
client connects to Hyperion MDM Application Server that can support multiple, simultaneous
users. The Hyperion MDM database can be hosted on the application server machine or
Hyperion MDM Components
The following topics describe the main components and features of Hyperion MDM.
A Hyperion MDM installation can use multiple back-end databases to support the many
business needs for hierarchical data within an organization. Each database is referred to as an
application, and each application is independent from any other application. If you are in
doubt about which application to use, see your system administrator.
16 About Hyperion MDM
Hyperion MDM groups sets of hierarchies into versions. A version represents a single,
independent set of data that is arranged into related hierarchies. Versions are usually related to
time periods or functions. Examples of versions are March 2001, 3rd Quarter 2000, and
Planning. All Hyperion MDM maintenance is performed within versions; users cannot copy or
move nodes across versions. The only features that work across versions are Compare and
Nodes and properties within a version are shared among the hierarchies within the version.
Versions are typically used for the following purposes:
To represent a set of hierarchies used during a particular month (or other business cycle
period). Each month a version is created, maintaining an audit trail of hierarchies.
To differentiate between real and test data during system testing.
To compare different versions to identify changes made to the hierarchies within a time
You can create new versions by copying existing versions, but, after a version is created, it is
totally independent of other versions. Versions can be copied, created, and deleted by the
Each version has an associated status.
A hierarchy is a set of nodes that are all descendants of the same node. Thus, a hierarchy is
defined by its top node and represents all nodes in the hierarchical relationships below that top
Hierarchies are contained within a version; and a version can contain multiple hierarchies.
Hierarchies provide the main interface for a user when working with Hyperion MDM.
Each hierarchy is usually associated with a certain view, external system, or management
report. Examples of hierarchies are Line of Business, Geographic, SAP - Legal, and
Table 3 Status Descriptions
Users can edit the hierarchies within the version
System administrators are performing final validations on the hierarchies. No further changes by
other users are permitted
No changes are permitted. From the current version, all exports to other systems are performed.
The hierarchies are now out-of-date. Data is maintained for historical purposes and as an audit
Hyperion MDM Components 17
A node is a point within a hierarchy. Every point in a hierarchy is a node. For example, within a
hierarchy that represents an organizational structure, a node might represent a department or
a cost center.
Within a version, a node may be a part of more than one hierarchy. A node can have many
user-defined properties that store information about the node and control the use of the node
within the information systems of an organization.
The following terms are used to define the position of a node and node behavior within a
Referential integrity (RI) is a concept normally associated with relational databases. In
Hyperion MDM, RI means that no relational data violates established keys or domain ranges.
In this database context, RI refers to two core rules that the Hyperion MDM engine enforces
while users are editing hierarchies:
A node must have the same children in all hierarchies. Thus, a node always represents the
same rollup structure regardless of context.
A node cannot exist more than once in a hierarchy. Thus avoiding any “circular reference”
By enforcing RI, Hyperion MDM inhibits errors related to structure and redundancy that
might occur during the maintenance process.
Table 4 Node Terminology
A node that cannot have children
A node that can have children
A node directly below another node (if B is directly below A, B is a child of A)
A node directly above another node (in the previous example, A is the parent of B)
All nodes below a specified node (including children and all children of children)
All nodes between a node and the top of the hierarchy (including the parent, the parent of the
parent, and so on)
All nodes directly below a node
All nodes that share a parent node in a particular hierarchy
A node not assigned to any hierarchy
18 About Hyperion MDM
Properties are data elements that are similar to fields in a database. Properties can be defined
and stored at four levels:
Global node - the value for the node is the same no matter what hierarchy it is in or what
parent it has
Local node - the value for the node can be different for the node in different hierarchies
Most properties in Hyperion MDM are defined at the node level and contain node
descriptions. Examples include the name of a node (called Abbrev in Hyperion MDM), the
description for a node, and the number of children of a node. Properties at the version and
hierarchy level are less common. Examples include properties used for header-level
information in Hyperion MDM exports.
The system administrator can define as many properties as needed. Hyperion MDM is
delivered with two categories of standard properties:
System properties that define a node
Statistical properties that provide information about a node
Inheritance is a feature that enables high-level nodes to share their property values with lower
points in the hierarchy, eliminating the need to store and maintain redundant information. It
enables newly entered nodes to automatically obtain their property values from the
appropriate ancestors. Proper use of inheritance can greatly reduce data-entry requirements.
When defining a property, the system administrator can define the property as inheriting. This
definition enables the values for the property to cascade down to its descendants.
Inheritance moves through a specific chain of events to determine the value for a property:
1. Hyperion MDM looks for a value entered at the current node. If a user has directly entered
a value at the node, the entered value is used.
2. If a value does not exist, Hyperion MDM searches the ancestors of the node for a value.
The first entered value that Hyperion MDM finds, moving up the hierarchy is used. Thus,
a change to the properties of a node can affect any descendents.
3. If no ancestor has an entered value, the default value is used. A default value is assigned by
the system administrator.
Global properties that inherit follow a slightly different path. In step 2, as Hyperion MDM
moves up the hierarchy in search of an entered value, it encounters the ancestors in the
controlling hierarchy. When the system administrator creates a global property, a controlling
hierarchy must be designated for the property. A controlling hierarchy tells the system which
hierarchy to use to determine the inheriting value for a global property.
Hyperion MDM Components 19
Many tools are available in Hyperion MDM for maintaining inherited values:
Locking a value so that it cannot be overridden at a descendant
Clearing all descendant values for a particular property
Removing an overridden value so that the property inherits from a node above
Validations and Verifications
Validations and verifications are tests to ensure that hierarchy rules are observed. They help
enforce business rules.
Validations—run automatically (in real-time) as users edit the structures and properties of
hierarchies. Validations are automatically performed for the node being edited and also for
Verifications—run on-demand (as a batch) after users make a set of changes. Users can
choose specific verifications or run a set of verifications defined by the system
Validation and Verification Example
An organization has a business rule that requires that a sales representative assigned more than
20 customers obtain special approval from the marketing department.
A validation using this business rule within Hyperion MDM permits no more than 20
customers to be added to a sales representative node.
A verification using this business rule reports only upon sales representatives with more
than 20 customers.
Comparing Validations and Verifications
Some business rules call for real-time enforcement and, therefore, should be defined by the
system administrator as validations.
Other business rules only need to be monitored and should be established as verifications.
In the preceding example, a verification is probably more appropriate because, in certain
circumstances, it is appropriate for a sales representative to have more than 20 customers.
Validations are more appropriate for rules that can never be broken and require immediate
Hyperion MDM can import data from external systems of various formats, including text files,
data extracts, and other sources. An import is always performed on a new, empty version that is
created as part of the import process. Thus, the user can verify that the import has run
correctly before moving the imported data into a production environment. After the data is
verified, Blender can be used to incorporate the new data. Imports can be customized and
saved by any Hyperion MDM user who is authorized to run imports.
20 About Hyperion MDM
Automator is an alternative mechanism that enables Hyperion MDM users to make bulk
hierarchy changes. The changes are defined in a text file. The functions supported are typical
node and property manipulations. When Automator is used, the changes defined in a text file
can be performed automatically and easily. Rather than using Automator, you can make
corrections to the data as it is processed.
Blender enables you to combine elements of two versions into a new version or to combine
elements into an existing version. The elements to be blended can include various
combinations of structural elements such as hierarchies, nodes, and properties.
Exports are tools that are used to transfer hierarchy data to external systems or to a database
table. Exports are sometimes referred to as reports or extracts. Exports also serve as the main
reporting mechanism for Hyperion MDM. Hyperion MDM provides users a wizard-like
export builder that enables them to create and save exports.
Exports can create paper reports for distribution or text files to be imported by external
systems. If an external system requires a complex export that cannot be generated by the report
writer, a new class of export can be created by the programming team and added into the
export builder. Each export class has a set of parameters that enable it to be customized for a
user’s specific requirements.
Using Structured Query Language (SQL) to query hierarchically structured data has always
been difficult (if not impossible) due to the recursive nature of the required query. Property
queries enable you to investigate the hierarchical structure and the property values of sets of
nodes without the need for complex recursive SQL programming.
Property queries can be used for several purposes:
To find nodes that meet certain criteria
In exports and comparisons as a filtering mechanism
As a parameter in a generic validation routine (providing queries additional functionality
Users create a list of criteria, similar to the WHERE clause in a conventional SQL statement,
and run it against a set of nodes. The property query returns a list of nodes that meet the
Documents you may be interested
Documents you may be interested