Requirement Gathering

we will discuss how to use the data elements required by the customer and transform them from the usual row and column relational schema into Essbase-friendly meta-data dimensions and data members.
Lets Take an Example of Esscar Motor Company which is a mutinational manufacturing enterprise.

Determining the data requirements

To build any successful Essbase database design is to determine up-front what data elements and attributes are required. Our business customer is the director of sales forecasting and production planning for the Esscar Motor Company.

Questions ??
What if our customer would like to have the ability to create a monthly sales forecast for the vehicles manufactured by Esscar Motor Company and then sold in the various markets they compete in? The customer also needs to see the effects of the sales forecast on the planned production volumes and the required stock of vehicles. In addition, with regard to future monthly planning, the data needs to be robust enough to provide historical looks at the data and year over year comparisons.

Recollect what we learn !!

What data elements are important and must be included in the database? Our customer has indicated that they need to track vehicle sales, vehicle production, gross stocks, and profits. Chances are that there will be more data elements, but because we are working with Essbase, they can be added quickly and easily at anytime in the future.

 The elements listed in the previous slide will become members under a dimension, which we will call Measures. These elements are what the customer is using to measure his business. It is the attributes of these data elements which will help us determine the rest of the necessary dimensions in the Essbase outline. The Measures dimension is included in most databases as it contains the customer-required measurables. The other dimensions can be thought of as the necessary descriptors of the measurable data, such as Calendar Periods, product lines, markets.

More requirement ??
What is the frequency of the data? Is it safe to figure that we need a Calendar Periods dimension in the database outline? Depending on how we build the Calendar Periods dimension, we will be able to work with the data on a monthly, quarterly, or yearly basis. What is it that our customer produces? Why, it's automobiles of course! Wouldn't our customer want to track the company's performance in many ways? We are probably safe in assuming that we need to create a Total Vehicle dimension that allows us to look at the data by an individual vehicle line or by the total of all vehicles.

 One main feature in autombile is Model Year Typically, automobile manufacturers produce the same vehicle line year after year, but introduce a new model year for every calendar year. It's a pretty safe bet that our customer would like a Total Model Year dimension in the database. Type of Customers - You will find this to be true in many situations when dealing with an enterprise that manufactures and sells a product. In the case of the Esscar Motor Company, vehicles are marketed to retail customers and fleet customers. Retail customers are the typical private consumers who buy one car at a time and the fleet customer is usually another company or entity, that purchases many vehicles at once. The customer agrees he needs a Total Customer dimension.

 As our customer is spread across globe so Would it be safe to say we need a Total Market dimension? If we structure the Total Market dimension properly, we can look at company performance by individual country (Market) or by total country (Total Market). So now as we gathered all the data requirements , so are we missing something ??

 Our customer has asked if there is a way he can have his data "as is", and prepare different versions of the data to help with analyzing and strategizing. In other words, our customer needs to have the ability to create full looks at the data with many different versions or scenarios. Thus, we provide a Scenario dimension. The customer can now create a forecast that has several looks at the same data with only "what if" changes made and see the effects side-by-side with the other scenarios. It's a beautiful thing!
So lets see what we collected till now.

Data Storage Options

In this section we will see the best methods to store data in our Essbase database.

 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. Essbase stores data in what is commonly referred to as a multidimensional array. 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

 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.

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 a new row in the Stock table of your relational database.

In Essbase, that same new piece of data is plugged into the waiting data cell that was created in the data block, when the database outline was structured or restructured. You can add a new dimension to the database outline or add new members to an 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. 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.

Storage Options in Essbase

While creating an application there are two type of option : Block Storage Option (BSO) Aggregate Storage Option (ASO)

Types of Essbase applications

ASO BSO

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.

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.

BSO
The BSO is best suited for denser concentrations of data. The BSO also supports write back or update capabilities from Microsoft Excel using the "Lock and Send" method within the Essbase add-in or from automated batch data load operations.