Designing A OBIEE Repository - 1

Step 1 - Analyzing your Business Model

Your first task is to thoroughly understand your business model. You have to understand what business model you want to build

before you can determine what the physical layer needs to have in it.

In a Decision Support Environment, the objective of Data Modeling is to design a model that presents business information in

a manner that parallels business analysts' understanding of the business structure. A successful model allows the query process

to become a natural process by allowing analysts to structure queries in the same intuitive fashion as they would ask business

questions. This model must be one that business analysts will inherently understand and that will answer meaningful questions

correctly.

This requires breaking down your business into several components to answer the following questions:

1. What kinds of business questions are analysts trying to answer?

2. What are the measures required to understand business performance?

3. What are all the dimensions under which the business operates?

4. Are there hierarchical elements in each dimension and what are the parent-child relationships that define each

hierarchy?

After you have answered these questions, you can identify and define the elements of your business model.

Identifying the Content of the Business Model:

Businesses are analyzed by relevant dimensional criteria, and the business model is developed from these relevant dimensions.

These dimensional models form the basis of the valid business models to use with the Oracle BI Server. All dimensional

models build on a star schema. That is, they model some measurable facts that are viewed in terms of various dimensional

attributes. Below are some concepts used in Analyzing the Business Model for designing your repository.

Fact Tables: It is a table with measures that are typically calculated data such as dollar value or quantity sold and they can be

specified in dimensions. For example, you might want to determine the sum of dollars for a given product in a given market over

a given time period.

Dimension Tables: A business uses facts to measure performance by well-established dimensions, for example, by time,

product and market. Dimension tables contain attributes that describe business entities. Dimension table attributes provide

context to numeric data, such as being able to categorize service requests. The best method to identify dimensions and their

attributes is to talk with the analysts in the organization who will use the data.

Bridge Tables: A bridge table resides between the fact table and the dimension table where there is many-to-many relationship

between the two types of tables. For example, if Employees table is a fact table and Jobs table is a dimension table, it is possible

that an employee can have multiple jobs such as clerk and programmer. Additionally, the job of programmer can be held by

many employees. There is a many-to-many relationship here between the Employees table and the Jobs table. The Bridge

table lists out the Employee ID and Job ID in a separate table to account for the many-to-many relationship.

Identifying Dimension Hierarchies: A hierarchy is a parent-child relationship between certain attributes within a dimension.

These hierarchy attributes, called levels, roll up from child to parent; for ex, months can roll up into a year. Similarly consider the

hierarchies in the Time-Period dimension that need to be defined such as Month/Year to Quarter, Days to Week, Weeks to Year,

etc.

Star and Snowflake Models: Star schemas have one-to-many relationships between the logical dimension tables and the

logical fact table. For example the Logical Dimension Tables, such as the products, customers, regions, time periods have a one-to-many relationships with the Logical Fact Table - Sales.

 

Snowflake schemas have the same type of relationship, but also include one-to-many relationships between elements in the dimensions. For example, Town's Table has a one-to-many relationship with Sales Table and State Table in turn has to one-to-many relationship with Town's Table, and so on...

 

It is recommended to use the Star schemas and minimize use of Snowflake schemas.

Step -2: Creating the Physical Schema, Business Model and Presentation Layers

Step 1 - Analyzing your Business Model

Step 2 - Creating the Physical Schema, Business Model and Presentation Layers

The Oracle BI server stores metadata in repositories. The repository consists of three layers:

The Physical Layer (Schema)

The Business Model and Mapping Layer

The Presentation Layer

 

Creating the Physical Layer:

1. Create physical joins between the Dimension and Fact Tables.

2. Change the names in the physical layer (if necessary)

The Physical Layer contains information about the physical data sources. The most common way to create the schema in the

Physical layer is by importing metadata from databases and other data sources. This layer supports Federated Query - i.e. the

database operation (query) involving data sets from 2 different data sources can be performed in OBIEE. This can be as disparate

as querying an excel sheet along with a table from the oracle database.

Creating the Business Model and Mapping Layer:

3. Promote to Business Layer

4. Define the dimensions and hierarchies - Create the levels of hierarchy

5. Map tables to dimensional hierarchies - Assign fields to the hierarchy

6. Create joins in the Business layer - Joins in the business model are complex joins

7. Change names in the business layer (if necessary)

8. Enable the Business Model to query

The Business Model and Mapping layer organizes information by business model. Each business model contains logical tables.

Logical tables map to the source data in the Physical layer. The mapping can include complex transformations and formulas. The

business model and mapping layer defines the meaning and content of each physical source in business model terms.

Creating the Presentation Layer:

9. Promote to Presentation layer

10. Change names in the Presentation layer (if necessary)

Detailed presentation catalogs should include measures from one fact table only, i.e. you should construct a subject area that

consists of a single table. You first create a logical dimensional model, and then present it as a single table schema. The

Logical dimensional model will setup the necessary metadata for the BI Server to navigate to the proper physical tables.

Conclusion: It is Important to note here that the business user will mainly be interacting with the presentation layer of the

repository.