1. OBIEE Data Federation Limor Fledel-Vagman BI Practice Manager
Oracle Israel

2. Horizontal Federation
OBIEE Federation
Vertical Federation
Integrating two or more disparate data source having different levels of granularity joined by one or more conformed dimensions
Example: Essbase Sales cube to relational Sales detail data (drill-through)
Horizontal Federation
Integrating two or more disparate data source having the same level of granularity joined by one or more conformed dimensions
Example: Essbase Sales cube with HR relational database

3. LTS ???
Logical table sources (LTS’s) are a key feature within the OBIEE semantic model
Oracle BI Suite EE 10g R3: Build Repositories

4. OBIEE Aggregate Navigation

5. Why Aggregate Navigation?
Problem: Summary questions are slow
Example, “All sales worldwide for last 2 years by quarter by family”
This will potentially sum/group by millions of rows!
The disk spin time to scan all these rows will be very long
Solution: ETL to batch build high level aggregates
Oracle BI EE has “aggregate navigation” to use them
Aggregates can be in the same database as the source
They can also be in a different relational source or Essbase
Often orders of magnitude performance improvement

6. Oracle BI EE “Architecture”
Semantic Layer Metadata
BI Server
SQL
Relational
Tables

7. Oracle BI EE Aggregate Navigation
Metadata describes aggregate mappings
Semantic Layer Metadata
BI Server
At query time, BI Server queries the fastest source that has enough detail to satisfy the user request
Performance of highly summarized requests is dramatically improved
SQL
SQL
Summary
Relational
Load time aggregation
Detail

8. Federation Enables External Aggregates
Semantic Layer Metadata
BI Server
Aggregates can be in other federated sources
SQL
Summary
SQL
SQL
Summary
Relational
Load time aggregation
Detail

9. External Aggregates Can Be in Essbase
Semantic Layer Metadata
BI Server
Aggregate navigation can include multidimensional
MDX
Essbase
SQL
Summary
Relational
Load time aggregation
Detail

10. External Aggregates Can Be Oracle OLAP
Semantic Layer Metadata
BI Server
Aggregate navigation can include multidimensional
MDX
Oracle OLAP AW
SQL
Summary
Relational
Load time aggregation
Detail
"This information is not a commitment to deliver any material, code, or functionality. The development, release, and timing of any features or functionality described remains at the sole discretion of Oracle"

11. How is Aggregate Navigation Set Up?
Database Design time:
DBA defines aggregate stars at various grain combinations
Builds ETL to load the aggregates each night
Star
Time
Product
Base
Day
SKU
Agg 1
Month
Brand
Agg 2
Qtr -

12. Mapping a Base-Level Physical Star
Business Model and Mapping Layer
Mappings
Physical Layer
D0 Time
D4 Product
F0 Rev Base Measures
D_Day
D_Prod_SKU
F_Bill

13. Adding a Moderately Aggregated Star
Business Model and Mapping Layer
Mappings
Physical Layer
D0 Time
D4 Product
F0 Rev Base Measures
D_Month
D_Brand
F_Bill_agg2
D_Day
D_Prod_SKU
F_Bill

14. Adding a Highly-Aggregated Star
Business Model and Mapping Layer
Mappings
Physical Layer
D0 Time
D4 Product
F0 Rev Base Measures
D_Qtr
F_Bill_agg1
D_Month
D_Brand
F_Bill_agg2
D_Day
D_Prod_SKU
F_Bill

15. Essbase as an Aggregate Source
Business Model and Mapping Layer
Mappings
Physical Layer
D0 Time
D4 Product
F0 Rev Base Measures
Month
Billed Amt
Brand
D_Day
D_Prod_SKU
F_Bill

16. Adding a Highly-Aggregated Star
How does the query planner decide which FJC to use as its source for a given request?
Business Model and Mapping Layer
Mappings
Physical Layer
D0 Time
D4 Product
F0 Rev Base Measures
D_Qtr
F_Bill_agg1
D_Month
D_Brand
F_Bill_agg2
D_Day
D_Prod_SKU
F_Bill

17. Selecting an Aggregate or Base Star at Query Time
How does the query planner decide which star to use as its source for a given LSQL request?
First, it eliminates sources that don’t have enough detail to answer the question
Query grain < star grain star not qualified
Query grain = star grain star qualified
Query grain > star grain star qualified
Second, it estimates the fastest/prioritized source

18. How BI Server Knows the Grain of a Star
At query time, the BI Server checks the available mappings to find which ones are qualified by grain

19. How Does It Know Which Star is Fastest? Number of elements
Be sure to correctly populate the Dimension Level’s “Number of elements at this level”
OBIEE 10g

20. How Does It Know Which Star is Fastest? LTS Priority Group Order
Lower value = higher priority
LTS Priority Group becomes main decider in which LTS to use
OBIEE 11g New Feature

21. Aggregate Persistence

22. Aggregate Persistence Feature
Managing aggregates manually has high TCO
Oracle BI EE automates creation of aggregates
Leverages existing metadata
Orders of magnitude performance boost; low TCO

23. “Aggregate Persistence” Automates Create & Load
Semantic Layer Metadata
BI Server
Define agg navigation metadata
Run scripts
Create Tables
Aggregation
Admin Tool: Aggregate build automation wizard
Create & schedule scripts
Create Tables
Aggregation
Summary
Detail

24. Aggregate Persistence – Manual Option
Semantic Layer Metadata
BI Server
Define agg navigation metadata
DBA
Admin Tool: Aggregate build automation wizard
Create scripts
Create Table DDL
Aggregation
Run scripts
Create Tables
Aggregation
Summary
Detail

25. Aggregate Persistence with Essbase & Oracle OLAP
Semantic Layer Metadata
BI Server
Define agg navigation metadata
Admin Tool: Aggregate build automation wizard
Define cube schema
Essbase or AW
Summary
Create load rules & schedule
Detail
"This information is not a commitment to deliver any material, code, or functionality. The development, release, and timing of any features or functionality described remains at the sole discretion of Oracle"

26. Administration Steps Design aggregate facts and grains
Wizard to create metadata 1
Target database for create/load 3 2

27. Aggregate Persistence Wizard

28. Aggregate Persistence Wizard
Automates the creation of physical aggregate tables and their corresponding objects in the repository
Fact aggregate
Use wizard to build script to generate aggregate tables.
Script generates physical tables, repository objects, and mappings.
Aggregate Persistence Wizard
The traditional process of creating aggregates for Oracle BI Server queries is manual. It can be tedious, requiring complicated data definition language (DDL) and data manipulation language (DML) scripts to be written for creating tables in the databases involved. Additionally, these aggregated tables need to be mapped into the repository metadata to be available for queries. This is a time-consuming and, possibly, error-prone process.
The Aggregate Persistence Wizard enables the administrator to automate the creation of physical aggregate tables and their corresponding objects in the repository.
Dimension aggregates
Oracle BI Suite EE 10g R3: Build Repositories

29. Aggregate Persistence Wizard Steps
Open Aggregate Persistence Wizard.
Specify the file name and location.
Select business model and measures.
Select dimensions and levels
Select connection pool, container, and name.
Review aggregate definition.
View complete aggregate script.
Verify script is created.
Create and run a batch file.
Verify aggregates in the Physical layer.
Verify aggregates in the BMM layer.
Verify aggregates in the database.
Verify results in Answers.
Aggregate Persistence Wizard Steps
This slide lists the steps for building aggregates using the Aggregate Persistence Wizard. Each step is presented in detail in the slides that follow.
Oracle BI Suite EE 10g R3: Build Repositories

30. 1. Open Aggregate Persistence Wizard
Select Tools > Utilities > Aggregate Persistence Wizard and click the Execute button.
1. Open Aggregate Persistence Wizard
Select Tools > Utilities > Aggregate Persistence Wizard and click the Execute button to open the Aggregate Persistence Wizard.
Oracle BI Suite EE 10g R3: Build Repositories

31. 2. Specify File Name and Location
Specify a file and location where the output script should be saved.
2. Specify File Name and Location
The wizard helps you generate logical SQL scripts for creating aggregates. This file stores the aggregate specifications and is updated if more aggregates are specified. When the script is executed, the aggregates are automatically mapped and created in the metadata as well as the database.
Oracle BI Suite EE 10g R3: Build Repositories

32. 3. Select Business Model and Measures
Select fact table.
Select measures.
3. Select Business Model and Measures
In the top pane, select the business model. When there are multiple business models, only one can be selected.
In the bottom pane, select the fact table. When there are multiple fact tables, only one fact table can be selected.
Expand the fact table and select the desired measures.
Oracle BI Suite EE 10g R3: Build Repositories

33. 4. Select Dimensions and Levels
Select corresponding aggregate dimensions and levels.
Instructor Note
If students ask about the Use Surrogate Key? check box, you can say that surrogate keys allow alternate keys to be specified for dimension aggregates. For example, replacing the Month varchar string with an integer would allow for smaller fact aggregate tables. The default join option between the fact and level aggregate tables is to use the primary keys from the level aggregate. If the primary key of the level is large and complex (composite of many columns), the join to the fact table is expensive.
A surrogate key is an artificially generated key, usually a number. A surrogate key in the level aggregate table would simplify this join, while also removing unnecessary (level primary key) columns from the fact table, resulting in a smaller sized fact table.
Oracle BI Suite EE 10g R3: Build Repositories

34. 5. Select Connection Pool, Container, and Name
Select the database object.
Select the schema.
Select the connection pool.
5. Select Connection Pool, Container, and Name
In the top pane, select the repository database object.
In the second pane, expand the database object and select the desired schema. In this example there is only one schema, SUPPLIER2.
In the third pane, select the connection pool. In this example there is only one, SUPPLIER CP.
In the Aggregate table name field, accept the default name or create a new name for the aggregate table. In this example the default name, ag_SalesFacts, is used.
Note that the parameters provided here are for output, which could be to a different database than where the detail tables reside.
Name the aggregate table.
Oracle BI Suite EE 10g R3: Build Repositories

35. 6. Review Aggregate Definition
View the aggregate definition.
6. Review Aggregate Definition
Review the aggregate definition. The screen displays the script that generates the aggregate tables based on the parameters defined in the previous steps. Click the View Script button to view, search, or copy the script. Here you can define another aggregate or select the “I am done” option.
Oracle BI Suite EE 10g R3: Build Repositories

36. 7. View Complete Aggregate Script
Confirmation of script creation and location
Script
7. View Complete Aggregate Script
When you have finished, the wizard displays the Complete Aggregate Script dialog box, confirming that the script has been generated and stored in the location identified in an earlier step.
Oracle BI Suite EE 10g R3: Build Repositories

37. 8. Verify that the Script Is Created
Navigate to the directory where the file was saved and verify that the script was created as expected.
Oracle BI Suite EE 10g R3: Build Repositories

38. 9. Create and Run a Batch File
Create and run a batch file with the following format to drive the aggregate creation process: nqcmd Oracle BI Server command utility -d Oracle BI Server data source name -u Repository username -p Repository password -s Path to the create aggregate SQL script
9. Create and Run Batch File
Follow these steps to create and run a batch file to drive the aggregate creation process:
1. Create a batch file using the following format: nqcmd Oracle BI Server command utility -d Oracle BI Server data source name -u Repository username -p Repository password -s Path to the create aggregate SQL script
2. Save and close the file.
3. Verify that the Oracle BI Server service is started. Oracle BI Server must be running to create the aggregates.
4. Open the command prompt and run the batch file.
5. Verify that you receive the “Statement execute succeeded” message.
Oracle BI Suite EE 10g R3: Build Repositories

39. 10. Verify Aggregates in the Physical Layer
Verify that the aggregates are created in the Physical layer of the repository as expected.
Fact aggregate
Instructor Note
The names of tables and columns in the aggregates created make debugging or verifying the SQL generated difficult. For some reason, the aggregation wizard creates these tables and columns with very opaque names, which may not be in accord with corporate naming policies. It is not clear why this decision was made in the product.
Dimension aggregates
Oracle BI Suite EE 10g R3: Build Repositories

40. 11. Verify Aggregates in the BMM Layer
Verify that the aggregates are created in the Business Model and Mapping layer of the repository as expected.
Dimension aggregate
Fact aggregate
Oracle BI Suite EE 10g R3: Build Repositories

41. 12. Verify Aggregates in the Database
Verify that the aggregates are created in the database.
Oracle BI Suite EE 10g R3: Build Repositories

42. 13. Verify Results in Answers
Activate the aggregate tables:
Run a query in Answers:
Check the log and verify that the aggregate tables are accessed as expected:
Oracle BI Suite EE 10g R3: Build Repositories

43. Troubleshooting Aggregate Navigation
If aggregate navigation is not working, the cause might be one of the following:
Aggregation content is not specified correctly for one or more sources.
Aggregate dimension sources are not physically joined to aggregate fact table sources at the same level.
Dimensional source does not exist at the same level as a fact table source.
Aggregate dimension sources do not contain a column that maps to the primary key of the dimension hierarchy level.
The number of elements is not specified correctly for dimension hierarchy levels.
If Aggregate Navigation Fails to Work
The slide lists some of the common reasons that aggregate navigation fails to work. Use this as a troubleshooting list to help identify causes and solutions.
Oracle BI Suite EE 10g R3: Build Repositories

44. Using aggregates comes with a price:
Considerations
Using aggregates comes with a price:
Additional time is required to build and load these tables.
Additional storage is necessary.
Build only the aggregates you need:
Look at query patterns and build aggregates to speed up common queries that require summarized results.
Ensure that enough data is combined to offset the cost of building aggregates.
Monitor and adjust to account for changing query patterns.
Instructor Note
Ensure that enough data is combined to offset the cost to build aggregates. There are no rules regarding the ratio between detail and aggregate tables. Recommendation for detail to aggregate ratios ranges from 30:1 to 100:1.
Oracle advises customers not to create time dimension aggregates (for example, Month level from Day level data) because data probably does not compress significantly over time (for example, the same customer does not order a product 30 times a month).
Oracle BI Suite EE 10g R3: Build Repositories

45. In this lesson, you should have learned how to:
Summary
In this lesson, you should have learned how to:
Describe aggregate tables and their purpose in dimensional modeling
Model aggregate tables
Use the Aggregate Persistence Wizard to create aggregates
Instructor Note
Review Questions
Question: Your implementation will run the best if you build aggregates for all possible level combinations. True or false?
Answer: False. You should build aggregates only to support common queries. Building more than what you need takes up space and also requires Oracle BI Server to consider more possibilities.
Question: Setting the number of elements in the dimensional hierarchy has no impact on aggregate processing. True or false?
Answer: False. These numbers are used by the server to help determine whether or not to access the aggregate table.
Question: If you can build an aggregate only for a fact source, you should do so. True or false?
Answer: False. You need to have aggregates for both dimension and fact sources for accurate results.
Oracle BI Suite EE 10g R3: Build Repositories

46. Using Partitions and Fragments

47. Business Challenge
Data is often partitioned into multiple physical sources for a single logical table.
Organizations need to seamlessly and efficiently access and process data from multiple sources to satisfy user requests.
Business applications must “know” where to go for what type of data and under what conditions.
Business Challenge
Data is often partitioned into multiple physical sources for a single logical table in a business model. When a logical table source does not contain the entire set of data at a given level, you need to specify the portion or fragment of the set that it contains.
For example, there are situations where data may be fragmented or partitioned. When individual sources at a given level contain information for a portion or fragment of the domain, an application needs to know the content of the sources to pick the appropriate source for the query. Seamless and efficient access from the users’ perspective is the goal.
Oracle BI Suite EE 10g R3: Build Repositories

48. Business Solution: Oracle BI Server
Oracle BI repository can be configured so that Oracle BI Server handles the navigation to the appropriate source.
Oracle BI Server seamlessly and efficiently accesses and processes data from multiple sources to satisfy user requests.
Business Solution: Oracle BI Server
When there are multiple sources, the metadata can be built so that Oracle BI Server handles the navigation to the appropriate source. Oracle BI Server can seamlessly access and process data from multiple sources efficiently to satisfy users’ requests. For example, as you saw in the previous lesson titled “Using Aggregates,” a database administrator may create an aggregate table to improve performance. The metadata must be configured correctly so that Oracle BI Server knows when it is appropriate to access the aggregate table instead of the detailed table when satisfying a user’s request.
Oracle BI Suite EE 10g R3: Build Repositories

49. Partition
Is a database element that contains part of the data for a fact or a dimension
Combines with other data fragments as necessary
May be:
Fact-based
Value-based
Level-based
Complex
Partition
A partition typically contains a subset of the data for a fact or dimension. A partition is the division of a database or its elements into distinct independent parts. Database partitioning is done for manageability, performance, or availability reasons. Partitioning can be done by building separate smaller databases or by splitting larger selected elements into smaller ones. For example, splitting one large table into many smaller tables. When a user requests data, it may be necessary to consolidate data from different partitions to complete the request.
There are different partition types: fact-based, value-based, level-based, and complex. Each is discussed in detail in the slides that follow.
Oracle BI Suite EE 10g R3: Build Repositories

50. Partitioning by Fact
Data is partitioned by fact when different fact data is stored in different tables.
Example: Actual sales versus quota targets
Actual sales
Quota targets
Sales Rep
Product Sale
Sales Rep
Product Quota
1100
1000
1100
2000
Partitioning by Fact
Data may be stored in such a way that different facts are in different tables. For example, companies usually store sales quotas in tables separate from the actual sales history. Inventory data is also commonly found stored in a database separate from sales history. This is sometimes referred to as vertical partitioning because a theoretical all-encompassing fact table can be thought to be sliced “vertically,” with different columns going to different fact tables.
Oracle BI Suite EE 10g R3: Build Repositories

51. Partitioning by Value
Data is partitioned by value when the data is split into separate tables according to the values of the data.
Example: Invoice data is stored separately for each region.
Invoices for Central Region
InvNbr
Dollars
Region
1000
Central
Partitioning by Value
Data can also be partitioned into separate tables according to the values of the data. For example:
East Region sales data may be in a different table from West Region sales data.
Inventory data may be in separate tables segregated by warehouse.
The data for the current year may not be in the same table as the data for prior years, or data could be separated by month, so that the last three years of data are in 36 separate tables.
This type of partitioning creates complexity in the query environment. Not only is the table population increased, thereby creating another query navigation issue, but any user who seeks to answer a question such as “What is the total number of widgets in inventory?” has to query multiple tables and then consolidate the results. One of the important benefits of Oracle BI Server is that it can do this type of navigation and consolidation automatically, preserving a simple logical model of the data for the user to interact with.
Invoices for West Region
InvNbr
Dollars
Region
114444
200
West
Oracle BI Suite EE 10g R3: Build Repositories

52. Partitioning by Level
Data is partitioned by level when the same facts are stored in separate tables at different levels of aggregation.
Example: Detailed sales data is summarized and stored by year and region.
Sales detailed data
Sales by year and region
Sales Rep
Date
Product Sale
Year
Total Dollars
Region
Partitioning by Level
Data may also be partitioned by level. This occurs when the same facts are stored in separate tables at different levels of aggregation. You saw examples of this in the previous lesson. The use of aggregate tables is a common practice in data warehouse design because it is a very effective tool for improving query performance.
Theoretically, however, the number of aggregate tables in a data warehouse can get very large. As such, data warehouse designers prefer to follow an incremental approach to creating aggregations. They look for the best performance, creating the aggregate tables that are going to be used most frequently and that offer the most data compression, that is, where the row counts decrease the most.
Of course, aggregate fact tables invite aggregate dimension tables. The result is that while introducing aggregate tables goes a long way toward improving query performance, it also complicates the overall query environment. One of the important benefits of Oracle BI Server is that it is “aggregate aware.” It writes SQL to use an efficient aggregate table automatically, while preserving a simple logical model of the data for the user to interact with. The user, therefore, remains insulated from the actual aggregate navigation process and sees only the query results.
1100
10000
1998
200000
Central
1100
25000
1999
300000
Central
1100
10000
Oracle BI Suite EE 10g R3: Build Repositories

53. Complex Partitioning
Data is partitioned using more than one technique.
Example: Invoice sales data is partitioned by value and level.
Invoices by month for Central
Invoices by year for Central
Month
Total Dollars
Region
Year
Total Dollars
Region
199801
10000
Central
1998
200000
Central
199802
25000
Central
Invoices by month for West
Invoices by year for West
Complex Partitioning
Partitioning strategies can be mixed. For example, data may be partitioned by level and value so that at any given intersection of levels, multiple aggregate tables may exist. Moreover, at any given intersection of levels, not all values might be stored. For example, at a Brand, Month, and Market aggregate level, just the important brands might be stored. Certain queries at this level can use the aggregate tables; other queries, with different constraints, would have to use more detailed tables. Oracle BI Server also navigates complex partitions for the user.
Month
Total Dollars
Region
Year
Total Dollars
Region
199801
300000
West
1998
West
199802
350000
West
Oracle BI Suite EE 10g R3: Build Repositories

54. ABC Example: Fact-Based (Quota)
Allow users to query for actual sales data and quota data in a single query.
Actual sales
Quota targets
Sales Rep
Product Sale
Sales Rep
Product Quota
1100
1000
1100
2000
ABC Example: Fact-Based
ABC sets sales quotas for its sales organization. These quotas are set at the region level by quarter. In addition, each of the region sales quotas is broken down by product type. Quota numbers are stored in an Excel workbook. You incorporate the quota numbers in the business model and create business measures to report variance from quota and percent of quota.
Oracle BI Suite EE 10g R3: Build Repositories

55. ABC Example: Value-Based (Customer)
Replace the current, single source for customer data with two value-based partitions.
Customers with names starting with letters A–M
NewKey
Name
1000
Clifton Lunch
Customers with names starting with letters N–Z
NewKey
Name
ABC Example: Value-Based (Customer)
ABC wants to implement separate partitions for customer data. One partition will store data for A–M customers, the other stores data for N–Z customers.
1002
Tong’s Wok
Oracle BI Suite EE 10g R3: Build Repositories

56. ABC Example: Value-Based (Inventory)
Build a business model for inventory data that is fragmented into multiple tables.
Eight quarters of inventory data stored in eight separate tables
ABC Example: Value-Based (Inventory)
ABC’s inventory data is fragmented; that is, it is split into multiple tables. Data values determine which table contains what data. In this example, eight quarters of inventory data are stored in eight separate tables. You need to create a business model for this fragmented inventory data.
Oracle BI Suite EE 10g R3: Build Repositories

57. Implementation Steps Import physical sources. Create physical joins.
Add sources to the Business Model and Mapping layer.
Specify fragmentation content.
Test the results.
New step
Implementation Steps
Most of the steps listed here should be familiar by now. The only new step is specifying fragmentation content, which is discussed in detail in the next slide.
Oracle BI Suite EE 10g R3: Build Repositories

58. Specify Fragmentation Content
Use the Expression Builder to define the type of content that the fragment contains.
Set the flag to specify whether to combine this fragment with other data.
Specifies that customer data from A–M is contained in this fragment
Specify Fragmentation Content
When a logical table source does not contain the entire set of data at a given level, you need to specify the portion, or fragment, of the set that it contains. Describe the content in terms of logical columns, using the “Fragmentation content” edit box on the Content tab of the Logical Table Source window. Click the ellipsis next to the “Fragmentation content” box to open the Expression Builder to build the expression.
This is similar to the steps used to define aggregates. For aggregates, you specified the content using the level indicator. Here you use an expression to serve the same purpose—to identify what data the source contains. In this example, the D1_CustAtoM table contains the customer data for all customers whose names start with the letters A through M. In a request for customer data, this source may need to be combined with data from other sources at this level. In this example, that would be the D1_CustNtoZ table, which contains rest of the customer data.
Specifies combining this fragment with the other
Oracle BI Suite EE 10g R3: Build Repositories

59. Identify reasons for segmenting data and
Summary
Identify reasons for segmenting data and
implement it – benefit is promised!
Question:
The end user needs to know what data is contained in which partition before submitting a query. True or false?
Instructor Note
Review Questions
Question: An aggregate table is a partition. True or false?
Answer: True.
Question: The end user needs to know what data is contained in which partition before submitting a query. True or false?
Answer: False. The application handles the navigation to the partitions. The access for the user is seamless.
Oracle BI Suite EE 10g R3: Build Repositories

60. Real-time BI
Federated OLTP/EDW Reporting

61. Horizontal Federation for Real-Time BI
Using horizontal fragmentation in OBIEE, we can map a single logical fact table to multiple LTS’s.
Physical fact table in our EDW called SALES_FACT
Physical fact table in our source system to represent real-time data
One logical fact table in the BMM — called “Sales Fact Realtime”
Oracle BI Suite EE 10g R3: Build Repositories

62. Horizontal Federation for Real-Time BI
Fact table mapping
Oracle BI Suite EE 10g R3: Build Repositories

63. Horizontal Federation for Real-Time BI
Customer dimension mapping
Oracle BI Suite EE 10g R3: Build Repositories

64. Horizontal Federation for Real-Time BI
Use variable as the threshold between reporting against the EDW schema and the source system schema
With the two LTS’s, we still need to configure the horizontal fragmentation. For this implementation, I have configured a repository variable called RV_REALTIME_THRESHOLD_DT, with an initialization block that keeps the value consistently at TRUNC(SYSTDATE). I use this variable as the threshold between reporting against the EDW schema and the source system schema.
Oracle BI Suite EE 10g R3: Build Repositories

65. Horizontal Federation for Real-Time BI
LTS mapping using threshold date
Once I have the variable available, I can configure the fragmentation on the fact table to use the threshold to determine the appropriate source for a particular record. This is less complicated with the EDW LTS… simple fragmentation configured for all rows with a transaction date less than the threshold date.
Whereas only the source system contains the newer rows needed for layering in real-time data… both the EDW and the source system contain historic data, albeit the EDW data is likely transformed to a certain degree. So we have to configure fragmentation using the RV_REALTIME_THRESHOLD_DT variable, but we also have to use that variable as a filter on the source system LTS to make sure we don’t over allocate the data.
Oracle BI Suite EE 10g R3: Build Repositories

66. Horizontal Federation for Real-Time BI
OBIEE does the logical union
The interesting part is how OBIEE does the logical union. When the EDW and the transactional schema exist in separate databases, the BI Server issues two different database queries and combines them into a single result set in its own memory space. However, if the schemas exist within the same database, as the Oracle Next-Generation Reference Architecture recommends, then the BI Server is able to issue a single query, transforming the logical union into an actual physical union in the SQL statement, as demonstrated in the statement below. Notice that the SQL threshold has been applied, and the UNION was constructed with a single SQL statement pushed down from the BI Server to the Oracle Database holding the Foundation and Presentation and Access layers in our Oracle architecture:
Oracle BI Suite EE 10g R3: Build Repositories

67. Horizontal Federation for Real-Time BI
When the BI Server has enough information to know that the entire result set will come from a single source, then the SQL will be issued against only one of the LTS’s.
But OBIEE is also capable of doing the fragmentation equivalent of “partition pruning.” When the BI Server has enough information to know that the entire result set will come from a single source, then the SQL will be issued against only one of the LTS’s. For instance, if I click on one of the “SQL Date” attributes in the above report which will apply a filter on the fragmentation column, the BI Server will know that the result set only comes from the EDW
Oracle BI Suite EE 10g R3: Build Repositories

68. Q
& A

69. Oracle by Example and Relevant Blogs
Web tutorial :Oracle by Example
“Federating Essbase and Relational Data Sources in OBIEE”