1. Trang chủ
  2. » Công Nghệ Thông Tin

Oracle Essbase 9 Implementation Guide- P11 doc

5 189 0
Tài liệu đã được kiểm tra trùng lặp

Đang tải... (xem toàn văn)

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 5
Dung lượng 727,75 KB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

An Essbase cube usually stores less physical data than a typical relational database must store to deliver the same results to the user.. The smallest usable vehicle to store data, conta

Trang 1

Study carefully how the MYR 2009 number can be easily added to the MYR 2010

number to give us the Total Model Year number

This is a highly simplified example of an Essbase database outline, its structure, and relationships In the next chapter, we will go over the Essbase database outline much more thoroughly

In the next section, we shall use what we have learned here to make decisions on

the best methods to store data in our Essbase database

Determine data storage options

Get ready to toss out everything you've ever learned about storing data in a typical

relational database with tables, rows, and columns Keeping the above example of

the Essbase outline in mind, we will now begin covering how the data is stored in

Essbase and the various options available to you (the Essbase programmer)

An Essbase cube usually stores less physical data than a typical relational

database must store to deliver the same results to the user Usually,

the greatest saving is in the expense of data retrieval times The results

returned from a typical Essbase database require less processing overhead

than the similar results being delivered as the result of queries performed

against relational database tables

Essbase stores data in what is commonly referred to as a multidimensional array

Trang 2

Inside the multidimensional array are the data cells It is these data cells where the

data is actually stored

The smallest vehicle that Essbase uses to store data is a cell A data cell however,

cannot stand alone The smallest usable vehicle to store data, contained in an

Essbase database, is the data block (see the following figure) These data blocks

are the building blocks of the Essbase cube:

Scenario 1 Scenario 2 Production Sales Stock Profit Jan Feb Mar Apr

A simplified explanation is that the data blocks are made up of data cells

The number of data cells are, for the most part, in direct relation to the number

of dimensions in the Essbase outline (the data attributes explained previously),

and the number of possible data combinations or intersections that can be created

Relational Sales Table Country

Country

Vehicle

Vehicle Model Year

Retail

Retail

Fleet

Fleet

Total

Total US

US US

US

Sedan

Sedan 4-Door

4-Door

2010

2010 2010

2010

50 33

200 67

250 100 Relational Stock Table

75 75

150 200 Model Year

In a traditional relational database, one new element of data may require an entire

new row of data in one to many tables Looking at the previous screenshot, you can

see that if you need to add stock information on a vehicle, you will need to insert

Trang 3

existing dimension at any time By adding dimensions to the database outline, you

are actually increasing the size of the data block When a data block is created by

Essbase, it contains cells for all of the various dimensions whether you have the

data at that point or not In our example, the data block created by the database

would already contain a cell for stock, even if you did not yet have a value to store

there When you have a value for stock, it just gets plugged into its data cell and

the size of the database is unaffected

When you add or remove information from the outline and save the outline,

Essbase will automatically restructure the database and modify the data blocks

(add/remove data cells) to incorporate the new outline information as necessary

In Oracle Essbase there are two distinct storage options that can be used when

creating a database These storage options are known as the Block Storage

Option (BSO) and the Aggregate Storage Option (ASO) These storage options

are discussed in greater detail later in this book For most transactional Essbase

applications, the more suitable of the two options is the BSO For our example

in this book, we will create an Application|Database using the BSO

It should be mentioned that the size of the data blocks can have a

dramatic effect on the performance of the system It is always best to

try and avoid extremely large and complex database outlines As we

explained previously, the data blocks are structured roughly in relation

to the possible combinations of data based on the number of members in

the database outline

More members = larger data blocks

Less members = smaller data blocks.

Oracle Essbase offers an extremely valuable option to help keep block

sizes to a minimum in order to help keep your database running at peak

performance The dynamically calculated database member!

Trang 4

The dynamically calculated member is a measure typically derived from other

data elements in the database It is not physically stored in the database Instead,

it is only created (calculated) at the time you ask for it There are three great

benefits for building your database with dynamically calculated members:

1 There is a huge potential to create many new measures without adding

new sources of data or writing expensive programs to derive the values

2 While the dynamically calculated member occupies a place in the database

outline, it does not affect the block size in the database, therefore, it does

not affect performance

3 The resultant measure is always accurate to the other measures in the

database and will always tally (the derived number will always equal

the result of the stored component numbers) There is never a question

of "where did this number come from?"

Types of Essbase applications

A nice feature of Oracle Essbase is that it allows you to create high level

umbrella applications under which you can group similar databases

The similarity in databases means they are either similar in function or purpose

When we speak of an Essbase application, it must be noted that all

databases are created under an umbrella application You may have one

or many databases under an application, but you cannot create a database

without a parent application Likewise, an application is virtually useless

without dependent databases

Oracle recommends that we have only one database for an application

The reason for this is that when you restructure a database, the entire

application is locked and you will not be able to perform any other

actions on the application or dependent databases

This Application|Database structure allows for a more organized layout

and design and also allows for better data and security management

As mentioned, an Essbase application can be one of two types:

1 Aggregate Storage Option

2 Block Storage Option

Trang 5

Aggregate Storage Option (ASO)

In Essbase 9.x versions, the ASO is also called Essbase analytics The ASO is most

suitable for the sparser data sets of high dimensionality, allowing a greater number

of dimensions and members The ASO model is not a replacement for the BSO, but

it is an alternative for the business users depending on the needs of the customer

In an Essbase Application|Database built using ASO, the data is loaded into the

leaf nodes or lowest levels, but are not aggregated into the upper levels using typical Essbase calc and store methods Rather, they are calculated dynamically on the

fly (per user request)

It must also be mentioned that the ASO is best suited as a Read Only application

It is best used when analysis on large amounts of data is necessary for presentation, analysis, or reporting purposes

We will talk more about ASO, and the differences between ASO and BSO, in

Chapter 10

Ngày đăng: 06/07/2014, 00:20