Oracle Essbase 9 Implementation Guide- P78 ppsx

In ASO, there are two types of hierarchies: • Stored hierarchies • Dynamic hierarchies An outline dimension in an ASO database can have any number of members and these members can only b

Dimensions can have one or more hierarchies of the members Included with your

installation of Essbase, you get the sample ASO application called ASOsamp to use

as a guide when learning about ASO

In ASO, there are two types of hierarchies:

• Stored hierarchies

• Dynamic hierarchies

An outline dimension in an ASO database can have any number of members and

these members can only be set as either stored members or dynamic members

They can even have both of the hierarchies In order to set the dimension to have

both types of hierarchies, you need to enable Multiple Hierarchies Enabled If no

hierarchy is defined, then by default it is tagged as Stored hierarchy.

To enable multiple hierarchies, follow these steps:

1 Right-click on the dimension or member name you wish to enable

the multiple hierarchies on Click on Edit member properties….

2 On the Member Properties screen, under the Hierarchy section,

select Hierarchies Enabled from the Hierarchy list box:

Stored hierarchies

Using Stored hierarchies, the data is aggregated based on the outline structure

The data aggregation and data retrieval is faster There are a few restrictions

when using Stored hierarchies:

• Stored hierarchies cannot have member formulas

• Stored hierarchies can have the no-consolidation (~) operator for Label-only

members A member that is label only is merely in the outline as a place holder

or to be informational and does not store data A good example of this is our

Calendar Periods dimension While the root member Calendar Periods is

useful to have for information, the data would make no sense rolled upto

this level

Dynamic hierarchies

Using Dynamic hierarchies, the data is not aggregated but is calculated at the time

of the data retrieval Since the data is calculated at the time of retrieve, the response

time for the output is longer The account dimension is always tagged as Dynamic

hierarchies and you cannot change the account dimension to stored hierarchy The

advantages of the Dynamic hierarchies are:

• Dynamic hierarchies can have formulas

• Dynamic hierarchies can have any consolidation operator

The following screenshot shows an example of how the Dynamic and Stored

hierarchies are used in the sample ASO database In the sample ASO database's

case, you can see that the Time dimension has MultipleHierarchies Enabled:

Outline paging

This is one major difference between a Block Storage application and an Aggregate

Storage application that provides a noticeable boost in performance Unlike a BSO

application, where the database outline must be loaded into memory as a single

There is no need for complex calculation scripts in an ASO database Now, you may

be wondering how the data gets aggregated without performing any calculated

aggregation? How fast will my data get retrieved? In an ASO database, the data gets

loaded only into the level 0 (leaf node) cells When the user attempts to retrieve data at

a level higher than the zero level, the data is dynamically aggregated Also, remember

a good portion of this aggregated data is not physically stored in the database As the database size increases, the dynamic aggregation consumes more time In order to

improve the database performance, you may need to pre-aggregate the data

MDX query language

So is now a good time to spring a new scripting language on you? Of course it is!

Okay, so it's not really a whole new language, it's just a piece of the MaxL scripting

language we haven't gone over with you yet

You may recall how we've gone over the MaxL scripting language previously

Well, the MaxL scripting language actually has two pieces These MaxL pieces

are known as MaxL DDL for Data Definition Language, which is the piece you

are already familiar with and MaxL MDX for Multidimensional Expressions

Why have we not explained something like MDX in-depth already? The reason

is that while the DDL piece of MaxL contains many powerful functions that are

written in relatively easy to understand syntax and it can easily replace the Essbase

Command scripting language (EssCmd) as your primary tool for automating database maintenance and support processes, the MDX piece of MaxL is more of a data

querying language Yes, MDX is very powerful as is DDL, but its usefulness can be

debated since there are several other methods of querying data in Essbase that are

just as effective and easier or more convenient to use The Essbase Reports scripting

language with the aid of the Essbase Query Designer, is one example that comes to

mind as an effective data querying tool MDX also supports the XML for Analysis

(XMLA) API

MDX however, has its place and its place is where it is best suited The place

for MDX is querying ASO Essbase databases

MDX functions for ASO

As we said earlier, the MDX data query language is a useful tool in its own right

In most cases, the MDX language has equivalent functions for each member set

function found in the Essbase Calculation Script language or the Essbase report

script language The following screenshot shows the complete list of MDX data

query functions available:

Now, look at the functions listed here They look like a hybrid between

Essbase member selection functions and typical SQL functions found in

any relational database

Unfortunately, after all of the hard work we've been through getting you to think

and act like an Essbase programmer/administrator, we don't want you to slip back into the relational way of thinking This is only acceptable when querying an ASO

database, because it is indeed set up somewhat similar to a relational database in

terms of data structure