Oracle Essbase 9 Implementation Guide- P79 pdf

Again, this is because an ASO database does not store the complete set of data like a BSO database does.. ASO only physically stores the data at the lowest levels and is a lot like a rel

Take a close look at the functions, most of them are intuitive as to their function and you will also notice a complete array of functions that are suspiciously similar to the column functions in relational SQL Again, this is because an ASO database does not store the complete set of data like a BSO database does ASO only physically stores

the data at the lowest levels and is a lot like a relational database where you depend heavily on functions such as SUM, MAX, and ABS to massage the data as it is delivered

to you

MDX function examples

Here, we will show you the same data query function twice One will be in the

format used by the Essbase Calculation Script language and the other example will

be in the MDX data query language The reason for this is to illustrate how vastly

different each language is

The @ANCEST function is a very commonly used function In an Essbase database,

where the data is stored at all levels, you can easily ask for the ancestor member In

an ASO database however, the data in most cases is dynamically calculated, so you have to ask for it in a different way so Essbase can interpret your request properly

• Essbase Calculation Script

Syntax:

@ANCEST (dimName, genLevNum, [ mbrName])

Example:

@ANCEST(Product,2,Sales)

• MDX Query Language

Ancestor

Example:

(

Sales,

Ancestor(

Product.CurrentMember,

Product.Generations(2)

)

)

The command above assumes you are keying off of the member currently

selected What will be returned is the value of Sales from the ancestor of

the member in the product dimension and the Generation level 2

MDX query syntax

To make querying an ASO database more relational and SQL like, you can actually

write your queries like you would in a relational database using SQL.

Looking at the following examples, you can see that the SELECT statement is almost identical to that of a query written in SQL Because the data is stored similarly, the

query language is similar That way, you won't forget when you're querying an

Essbase BSO database or an Essbase ASO database

Typical MDX query structure:

SELECT [<member_name>,[ <member_name>]]

FROM [<Essbase_database_name>]]

WHERE [<dimension_name.member_name>

[, <dimension_name.member_name>]]

Syntax:

SELECT Sales,Stocks

FROM EssCar

WHERE Calendar Periods.June, Model Year.2010

Typical SQL Query Structure

SELECT column_name>[, <column_name> ]

FROM table_name

WHERE value = value [and value = value]

Syntax:

SELECT Sales, Stocks

FROM MARKET_INFO_TBL

WHERE Month = June and ModelYear = 2010

Well, this should put you in a good place for querying an ASO database The Essbase Technical Reference included and installed with the EAS on your client PC contains all

of the information you need on the actual query functions and member set functions

As with everything else in this book, the only way you will get proficient is to play

around in the database

Executing an MDX query

Now, here is a question that is begging to be asked How do we execute an

MDX query?

The answer is easy enough You execute an MDX query in exactly the same fashion

as you execute any MaxL statement Remember, both DDL and MDX are really

MaxL scripts The only difference between MaxL DDL and MaxL MDX is the editor used through the EAS tool

In the previous screenshot, we showed you the MDX editor that you can access from

the EAS tool by clicking on the Editors menu selection and then selecting MDX.

When you are using the MDX editor, you have the same nice features as the other

editors that are included in the EAS tool It is through the editor that you can also

execute your MDX statements

The other way to execute your MDX statements is through the command line prompt This is exactly like you were shown earlier in this book for the MaxL DDL statements Honestly, if it wasn't for the major outline differences between an ASO database

and a BSO database, you could travel through your entire Essbase career and not

really need the MDX piece of MaxL Because the ASO database structure can

actually be at least conceptually compared with a relational database more than

a multidimensional database, it's a good idea to get friendly with MDX

Tuples and Sets

A Tuple is a collection of members from different dimensions that represent a slice

of data from the database A tuple can contain one member from each dimension

A tuple should be wrapped in parentheses when written In theory, each cell in the

Essbase cube is defined by a tuple with one member from each dimension A single member is also considered a tuple

A tuple is an easy way to describe a slice of data from an Essbase database

A correctly written tuple can contain very few actual words, but can describe

a large amount of data

Here is an example of a tuple:

(Total Market United States)

The tuple above will return all data at the Total Market level for the United States

Null Dimensions or Null member references are not valid tuples

Sets are an ordered collection of tuples A set can be empty, have one tuple,

or it can have more than one tuple Duplicates of tuples are allowed Sets

are enclosed in curly brackets

Here is an example of a set:

{CALENDER PERIOD.2008}—defines one Tuple

{CALENDER PERIOD.2008, CALENDER PERIOD.2007}—defines sets of two Tuples

Pros and cons of ASO and BSO

As you have seen earlier in the chapter, there are some differences between the ASO and the BSO Even though there are differences, we would like the reporting output

to be the same and the analyst who is running the report should not even know to

which type of database he is connected Let us take some time to look at a few of

the pros and cons between these two types of databases

Pros and cons of BSO

The Essbase BSO is the original format of the Essbase database technology The BSO

is also the mainstay for Essbase as it offers robust, full-featured functionality Here

we will describe what we feel are some of the positive features of the BSO as well

as some of the not so positive features for you

Pros

Listed below are just a few high-level features that we feel makes the Essbase BSO

a good choice:

• Several databases stored in one application

• No reserved names for application and database names

• Account dimension supports all types of calculations and attribute members

• Calculation scripts are supported

• Uncomplicated write back ability

• Formulas are allowed in all dimensions with no restrictions

• Outline changes do not automatically clear data values, even if a data source

is used to both modify members and load values Therefore, incremental data loads are supported for all outlines

• Currency conversion is supported

Cons

Listed below are a few high-level features that we feel you may need to be wary

of when using the Essbase BSO:

• For better performance, the outline dimensions must be defined as Dense

or Sparse, based on data density, which can sometimes be difficult to get

exactly right

• Database calculation—calculation script or outline consolidation

• Calculation order will need to be defined in the calc scripts and is

predetermined in a default outline calculation

• Unrestricted write back ability which can be dangerous if care is not exercised

• No automatic update to values after data load Necessary calculation

scripts need to be specially executed, including any default calculations

• Sometimes requires large amounts of resources