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.