- the values that you enter or load (input data)
- and the values that are calculated from the input data (calculated data)
Then a typical Essbase - Database (cube) conforms to the following process :
- Input data is loaded to the lowest levels in Essbase - Hierarchies
The process of creating a production database involves these tasks:
- Analyse Business Need and plans
- Creating a Database outline, defining database dimension and hierarchies
- Checking System Requirement
- Loading data by using rules files to map to the database dimension
- Defining Report
- Verifying the design
Applications that use the optional Essbase Currency Conversion module are an exception to this recommendation. Currency conversion applications generally consist of a main database and a separate currency database (see Designing and Building Currency Conversion Applications).
User Requirement to determine the Dimension and Members
User Management and security
- Do some users require access to information that other users should not see?
- Who are the users and what permissions should they have?
- Who should have load data permissions?
- Which users can be grouped, and as a group, given similar permissions?
Analyzing Source Data
Determine the location of the current data.
- Where does each department currently store data?
- Is data in a form that Essbase can use? see Data Sources.
- Who updates the database and how frequently?
- Does the data support the desired analysis and reporting goals?
- Do those who need to update data have access to it?
Checklist for Dimension and Member
Most businesses analyse the following areas:
- Time periods
- Accounting measures
- Scenarios (to give different point of view - actual vs budget vs forecast)
- Distribution channels
- Geographical regions
- Business units
If you need to analyze a business area by classification or attribute, such as by the size or color of products, you can use attribute dimensions to represent the classification views.
- What are the candidates for dimensions?
- Do any of the dimensions classify or describe other dimensions? These dimensions are candidates for attribute dimensions.
- What are the candidates for members?
- Does it add analytic value?
- Does it add utility for reporting?
- Does it avoid an excess of unused combinations?
Checklist for Dimension and Member Properties
- Can you identify a time dimension?
- Can you identify an accounts dimension?
- Does the data include foreign currencies? If so, did you identify a currency partition dimension?
- Can you identify qualities or characteristics of dimensions that should be defined as separate attribute dimensions?
- Which members require special data storage properties?
To split ?
- Did you avoid repetition in the outline? : Essbase - Suppression of repetitions in Outline by adding a dimension
- Did you avoid interdimensional irrelevance? : Essbase - Suppression of interdimensional irrelevance by splitting the database
- Did you split the databases as necessary? : Reasons to Split Databases
Checklist for Consolidation
Use the following checklist to help define Essbase - (Consolidations|Aggregations):
Checking System Requirements
Now you are ready to determine the system requirements for the database.
Loading Test Data
Before you can test Essbase - Calculations, consolidations, and reports, you need data in the database. During the design process, loading mocked-up data or a subset of real data provides flexibility and shortens the time required to test and analyze results.
Detailed instructions for loading data are in the following chapters:
If you are satisfied with your database design after the preliminary test, test load the complete set of real data with which you will populate the final database. Use the test Essbase - Rules File if possible. This final test may reveal source data problems that were not anticipated during earlier design process phases.
Use the following checklist when you define a Essbase - Calculations:
To ensure that the design meets user information requirements, you must view data as users view it. Users typically view data through spreadsheets, printed reports, or reports published on the Web.
Verifying the Design
Ensure that the database satisfies all of their goals
- Do the calculations provide the information they need?
- Are they able to generate reports quickly?
- Are they satisfied with consolidation times?
In short, ask users if the database works for them.
Near the end of the design cycle, test with real data.
- Does the outline build correctly?
- Does all data load?
If the database fails in any area, repeat the steps of the design cycle to identify the cause of the problem.
Most likely, you will need to repeat one or more steps of the design process to arrive at the ideal database solution.
Essbase provides several sources of information to help you isolate problems :
- application and Essbase Server logs,
- exception logs,
- and database information accessible from Administration Services.