About Oracle BI Server and Oracle BI Repository Architecture

The architecture of the Oracle BI Server and the Oracle BI Repository provides a layer of abstraction that lets you submit simple Logical SQL queries against complex federated data sources.

This section contains the following topics:

• About Oracle BI Server Architecture

• About Layers in the Oracle BI Repository

About Oracle BI Server Architecture

The Oracle BI Server is an Oracle Business Intelligence component that processes user requests and queries in underlying data sources.

TheOracle BI Server maintains the logical data model and provides client access to the model using ODBC connectivity or native APIs, such as OCI for the Oracle Database.

The Oracle BI Server uses the metadata in the Oracle BI repository to perform the following two tasks:

• Interpret logical SQL queries and write corresponding physical queries against the appropriate data sources

• Transform and combine the physical result sets and perform final calculations

The Administration Tool client is a Windows application that you can use to create and edit your Oracle BI repository. The Administration Tool can connect directly to the repository in offline mode, or it can connect to the repository through the Oracle BI Server . Some options are only available in online mode. See Using Online and Offline Repository Modes for more information.

The image shows how theOracle BI Server interacts with query clients, data sources, the Oracle BI repository, and the Administration Tool.

Description of the illustration GUID-81B2D421-2EAA-4F22-811F-9BE7803CF0C2-default.gif

The example shows how theOracle BI Server interprets and converts Logical SQL queries.

Logical Requests Are Transformed Into Complex Physical Queries

Assume theOracle BI Server receives the following simple client request:

SELECT
"D0 Time"."T02 Per Name Month" saw_0,
"D4 Product"."P01 Product" saw_1,
"F2 Units"."2-01 Billed Qty (Sum All)" saw_2
FROM "Sample Sales"
ORDER BY saw_0, saw_1

The Oracle BI Server can then convert the Logical SQL query into a sophisticated physical query, as follows:

WITH SAWITH0 AS (
select T986.Per_Name_Month as c1, T879.Prod_Dsc as c2,
   sum(T835.Units) as c3, T879.Prod_Key as c4
from
   Product T879 /* A05 Product */ ,
   Time_Mth T986 /* A08 Time Mth */ ,
   FactsRev T835 /* A11 Revenue (Billed Time Join) */
where ( T835.Prod_Key = T879.Prod_Key and T835.Bill_Mth = T986.Row_Wid)
group by T879.Prod_Dsc, T879.Prod_Key, T986.Per_Name_Month
)
select SAWITH0.c1 as c1, SAWITH0.c2 as c2, SAWITH0.c3 as c3
from SAWITH0
order by c1, c2

About Layers in the Oracle BI Repository

Layers in the Oracle BI Repository define the objects and their relationships.

An Oracle BI Repository has the following layers:

• Physical layer. This layer defines the objects and relationships that the Oracle BI Server needs to write native queries against each physical data source. You create this layer by importing tables, cubes, and flat files from your data sources.

  Separating the logical behavior of the application from the physical model provides the ability to federate multiple physical sources to the same logical object, enabling aggregate navigation and partitioning, as well as dimension conformance and isolation from changes in the physical sources. This separation also enables the creation of portable Oracle BI Applications.

• Business Model and Mapping layer. This layer defines the business or logical model of the data and specifies the mapping between the business model and the physical schemas. This layer determines the analytic behavior seen by users, and defines the superset of objects and relationships available to users. It also hides the complexity of the source data models.

  Each column in the business model maps to one or more columns in the Physical layer. At run time, the Oracle BI Server evaluates Logical SQL requests against the business model, and then uses the mappings to determine the best set of physical tables, files, and cubes for generating the necessary physical queries. The mappings often contain calculations and transformations, and might combine multiple physical tables.

• Presentation layer. This layer provides a way to present customized, secure, role-based views of a business model to users. It adds a level of abstraction over the Business Model and Mapping layer and provides the view of the data seen by users building requests in Presentation Services and other clients.

  You can create multiple subject areas in the Presentation layer that map to a single business model, effectively breaking up the business model into manageable pieces.

Before you build any repository layers in the Administration Tool, it is important to create a high-level design of the Business Model and Mapping layer based on the analytic requirements of your users. After you have a conceptual design to work toward, you can then build your metadata objects.

The typical order is to create the Physical layer objects first, the Business Model and Mapping layer objects next, and the Presentation layer objects last. However, you can work on each layer at any stage. After you complete all three layers, you can set up security when you are ready to begin testing the repository.

The figure shows how a logical SQL query traverses the layers of an Oracle BI Repository.

Description of the illustration GUID-6769CC4C-C435-4838-8EAB-42200F36E8B7-default.gif

A single Oracle BI Repository can contain two or more independent semantic models, rather than a single, integrated, enterprise-wide model. A semantic model consists of one business model, its related objects in the Presentation and Physical layers, and additional related objects like variables, initialization blocks, and application roles. A semantic model is also known as a Common Enterprise Information Model.

See About Multiuser Development Styles for a visual representation of multiple semantic models.