OTBI Cross Subject Area Reporting Guidelines

ORACLE WHITE PAPER
Guidelines for creating Cross Subject Area

Transactional BI Reports in Fusion
Applications Release: Fusion Applications Release 7 and prior releases.
Author: Imran Ali
Table of Contents
Introduction ......................................................................................................................................................3
Subject Areas in OTBI ....................................................................................................................................3
What is a Cross-Subject Area Analysis? .......................................................................................................4
Building Cross-Subject Area Reports using Common Dimensions ............................................................4

Guidelines for creating a Cross-Subject Area Analysis using multiple Subject areas and
common dimensions ..............................................................................................................................7
Building Cross-Subject Area Reports using Common and Local Dimensions ..........................................8
Configuration/Setup Required for Cross Subject Area reports to work ................................................8
How local dimensions may impact the rows returned in a report........................................................10
How results returned from the individual Cross Subject Area queries may not get merged
the way you would want. .....................................................................................................................11
How to Create a Cross-Subject Area Analysis Using Set Operations ......................................................14
Appendix A. ....................................................................................................................................................16
Appendix B. ....................................................................................................................................................18
Terms/Glossary. .............................................................................................................................................19
Introduction
Oracle Transactional BI (OTBI) is a real-time reporting solution for Fusion Applications. This document
contains recommendations for building OTBI reports. Specifically it focuses on how to create Cross
Subject Area reports and addresses some of the main issues report developers face while generating such
reports.
The document also includes logical SQLs for all examples used in the document. Understanding these
logical SQLs is not necessary to understand most of these guidelines and have been included for advanced
users.
This document is applicable for Fusion Applications Release 7 and earlier releases.
Subject Areas in OTBI

OTBI organizes reporting data elements like Dimensions and Facts by business function in Subject Areas.
Each Subject Area contains a collection of dimensional attributes and measures relating to one
dimensional STAR model and grouped into individual folders. The term STAR refers to the semantic
model where a single fact is joined to multiple dimensions. For instance the “Workforce Management -
Worker Assignment Real Time" subject area has Worker, Job, Grade and Worker Assignment Details
dimension folders and a fact folder named Worker Assignment that has metrics like headcount and FTE.
The fact folder usually has the same name as the Subject Area (minus Real Time). There is also another
folder that is named same as the fact name but has “Detail” at the end. This folder always contains all the
attributes of the fact and is a local degenerate dimension. For instance for the “Worker Assignment Real
Time” subject area this dimension is called “Worker Assignment Details”.
All OTBI Subject Area names in FSCM and HCM end with “Real Time”.
Here is an example of an OTBI subject area with fact and dimension folders.
What is a Cross-Subject Area Analysis?
OTBI allows creating a report that combines data from more than one Subject Area. Such a query would
be referred to as a Cross Subject Area query in this document. We will discuss 3 different types of Cross
Subject Area queries and how the result set varies based upon what type of a query is being executed.
Cross Subject Area queries can be classified into 3 broad categories:
1. Using common (conformed) Dimensions

2. Using common and local (non-conformed) Dimensions
3. Combining more than one result set from different subject areas using set operators such as union,
union all, intersection and difference.
Before we discuss these three types of reports, it is important to distinguish between a common and a
local dimension. A common dimension is a dimension that exists in all subject areas that are being joined
in the report. For example, both “Workforce Management - Worker Assignment Real Time" and
“Workforce Management - Worker Assignment Event Real Time" subject areas have Worker, Job,
Department etc. available for use in the respective subject areas. These are considered common
dimensions between these two subject areas and can be used to build a Cross Subject Area report. On the
other hand “Worker Assignment Details” dimension in the “Workforce Management - Worker
Assignment Real Time" subject area is not available in the “Workforce Management - Worker
Assignment Event Real Time" subject area, therefore it is a local dimension for the purposes of a Cross
Subject Area query between these two subject areas.
Next we will examine the three types of reports mentioned above in more detail.
Building Cross-Subject Area Reports using Common

Dimensions
The simplest and fastest way to generate a report is to use a single subject area. If the dimension attributes
and fact metrics that you are interested in are all available from a single subject area then you must use
that subject area to build the report. Such a report will result in better performance and would be much
easier to maintain.
If your report requirements cannot be met by any single subject area because you need metrics from more
than one subject area, then you can build a Cross Subject Area report using common dimensions. There
are clear advantages to building a Cross Subject Area report using only common dimensions and we
highly recommend using this approach to build your Cross Subject Area queries if possible. Note that for
a dimension to be common between 3 subject areas being pulled into a report, it must exist in all 3 subject
areas. You can use any metric from either subject area in your report. Joining on common dimensions
gives the benefit of including metrics from multiple subject areas in a single report. As mentioned earlier,
each subject area has one folder that contains metrics and usually has the same name as the Subject Area
(minus Real Time).
While Answers gives a user the flexibility to create a report joining any subject area the user has access
to, one must understand that only a Cross Subject Area query that uses common dimensions would return
data that is at the same dimension grain and hence can be cleanly merged resulting in a report that returns
exactly the data you are looking for. See Report 1 below for an example of a report that is at the grain of
the worker dimension.
It is important to understand how Cross Subject Area queries are executed in BI to fully understand the
importance of using common dimensions when building such a report. When a Cross Subject Area report
is generated in OTBI, Oracle BI executes separate queries for each subject area in the report and then
merges the results to generate the final report. The data being returned from the different subject areas is
merged using these common dimensions. If you have used common dimensions, the result set returned by
each subject area query would be at the same dimensional grain and hence can be cleanly merged and
rendered in the report. The following examples explain this behavior in detail.
Here are two examples of a Cross Subject Area query that reports on metrics coming from two separate
facts (separate subject areas) and using common dimensions.
Report 1.
Cross Subject Area report on Worker Assignments and Assignment Events to fetch a count of
Assignments, and # of hire and promotion events for a worker.
Subject area 1: Workforce Management - Worker Assignment Real Time

Subject area 2: Workforce Management – Worker Assignment Events Real Time
Common Dimension: Worker

Metrics (measures): Assignment Count comes from first subject area and # of Hires and Promotions
from the second subject area.
Logical SQL for Report 1.
SELECT
0 s_0,
"Workforce Management - Worker Assignment Real Time"."Worker"."Employee First Name" s_1,
"Workforce Management - Worker Assignment Real Time"."Worker"."Employee Last Name" s_2,
"Workforce Management - Worker Assignment Event Real Time"."Assignment Event"."# Of Hires" s_3,
"Workforce Management - Worker Assignment Event Real Time"."Assignment Event"."# Of Promotions" s_4,
"Workforce Management - Worker Assignment Real Time"."Worker Assignment"."Assignment Count" s_5
FROM "Workforce Management - Worker Assignment Real Time"
WHERE
(("Worker"."Employee First Name" = 'George') AND ("Worker"."Employee Last Name" = 'Weasley'))
ORDER BY 1, 2 ASC NULLS LAST, 3 ASC NULLS LAST
FETCH FIRST 65001 ROWS ONLY
Report 2.
Cross Subject Area query to fetch worker assignment and salary information.
Subject area 1: Workforce Management - Worker Assignment Real Time

Subject area 2: Workforce Compensation - Salary Details Real Time
Common Dimensions: Worker, Grade, and Location
Metrics:
“Worker Assignment Real Time” subject area: Headcount
“Salary Details Real Time” subject area: Current Salary, Annualized Salary, Previous Salary, Days Since
Last Salary Change.
Logical Sql for Report 2.
SELECT
0 s_0,
"Compensation - Salary Details Real Time"."HR Grade"."Grade Name" s_1,
"Compensation - Salary Details Real Time"."Worker Location"."Worker Location Name" s_2,
"Compensation - Salary Details Real Time"."Worker"."Employee Full Name" s_3,
"Workforce Management - Worker Assignment Real Time"."Location"."Location Address" s_4,
"Compensation - Salary Details Real Time"."Salary"."Annualized Salary" s_5,
"Compensation - Salary Details Real Time"."Salary"."Current Salary" s_6,
"Compensation - Salary Details Real Time"."Salary"."Days Since Last Salary Change" s_7,
"Compensation - Salary Details Real Time"."Salary"."Previous Salary" s_8,
"Workforce Management - Worker Assignment Real Time"."Worker Assignment"."Head Count" s_9
FROM "Compensation - Salary Details Real Time"
WHERE
("Salary"."Current Salary" IS NOT NULL)
ORDER BY 1, 4 ASC NULLS LAST, 2 ASC NULLS LAST, 3 ASC NULLS LAST, 5 ASC NULLS LAST
As we are only using common dimensions the resulting report is at the grain of Worker, Grade and
Location with one record per worker, grade and location combination.
Guidelines for creating a Cross-Subject Area Analysis using multiple
Subject areas and common dimensions
Here are some guidelines and best practices when building Cross Subject Area reports. This list should
also be used to troubleshoot issues with Cross Subject Area reports. Make sure the following guidelines
have been followed if you run into issues building Cross Subject Area reports.
o If all the metrics and attributes needed for the report are available in a single subject area and
fact, use that subject area only and do not create a Cross Subject Area query. Such a report
will perform better and will be easier to maintain.
o When joining two subject areas in a report, make sure at least one attribute from a common
dimension is used in the report.
o When using common dimensions always pick attributes from the common dimension from a
single subject area. For instance if you are using “Worker” dimension to build a query
between subject area 1 and subject area 2 then pick all worker dimension attributes from
subject area 1 or 2. But not some worker attributes from subject area 1 and some from subject
area 2. In some scenarios, the common dimension may have more attributes in one subject
area vs the other. In such a situation you can only use the subset of common attributes in a
Cross Subject Area query.
o Always include a measure from each subject area that is being used in your report. You don’t
have to display measures or use them. But you should include a measure in the report
nonetheless and hide it if it is not needed in the report.
o When using scalar metrics like percentage or average values (metrics that don’t have
aggregation function defined on them) make sure you add an aggregation like MAX. For
example, Calculated Manager Overall Rating from Performance Rating Subject area needs an
aggregation function.
You can do this by either editing the column property and adding a function or by navigating
to the “Advanced” tab in Answers and wrapping the column name with the “”max” function.
The end result should be the following logical sql:
SET VARIABLE ENABLE_DIMENSIONALITY=1, NO_FORCE_TO_DETAIL_BIN=1; SELECT

0 s_0,
"Workforce Performance - Performance Rating Real Time"."Worker"."Employee Full Name" s_1,
"Workforce Performance - Performance Document Status Real Time"."Performance Document
Status"."Performance Documents Completed" s_2,
"Workforce Performance - Performance Document Status Real Time"."Performance Document
Status"."Performance Documents" s_3,
max("Workforce Performance - Performance Rating Real Time"."- Performance Rating"."Calculated
Manager Overall Rating") s_4
FROM "Workforce Performance - Performance Rating Real Time"
ORDER BY 1, 2 ASC NULLS LAST
Note that the patch for bug 16538633 will fix this issue. If you have this patch applied then
you will not need to treat scalar metrics as explained above. Scalar Metrics show up in the
fact folder with a white icon as shown in the following screenshot.
Building Cross-Subject Area Reports using Common and
Local Dimensions
Configuration/Setup Required for Cross Subject Area reports to work
Before you generate any Cross Subject Area reports please review the following section to understand the
configuration and report changes required to get such reports to work. You will also need to make sure
you have the appropriate patches applied on the instance.
The following two configuration changes are required for Cross Subject Area reports to work:
o System Configuration changes to the opmn.xml file

o Set two session variables for every report in the Prefix tab
For details about how to do these configuration changes please see Appendix A.
You will also need some patches from OBIEE and BIApps. For a list of patches see Appendix B.
Without doing the config/setup changes described in Appendix A and patches mentioned in Appendix B,
cross-subject area reporting is only supported for common dimensions, dimensions that exist in all subject
areas included in the report. If you are getting an error when running such a report or not getting expected
results please check your setup and ensure all patches are applied.
Here is an example of the report behavior you should expect to see if the necessary setup changes and
patches are not applied on your instance.
Continuing with our Assignment and Assignment Event example in Report 1, if I add attributes from
“Assignment Event Details” (not a common dimension) from the Assignment subject area into our Cross
Subject Area query, the Assignment Count which comes from the Worker Assignment subject area is cast
to NULL and returns 0 for count as seen in the screenshot below. In some scenarios the query may fail.
Report 3.
Logical Sql for Report 3.
SELECT
0 s_0,
"Workforce Management - Worker Assignment Event Real Time"."Assignment Event Details"."Assignment Number" s_1,
"Workforce Management - Worker Assignment Event Real Time"."Assignment Event Details"."Assignment Sequence" s_2,
"Workforce Management - Worker Assignment Event Real Time"."Assignment Event Details"."Assignment Status Type" s_3,
"Workforce Management - Worker Assignment Event Real Time"."Assignment Event Details"."Assignment Type" s_4,
"Workforce Management - Worker Assignment Event Real Time"."Worker"."Employee First Name" s_5,
"Workforce Management - Worker Assignment Event Real Time"."Worker"."Employee Last Name" s_6,
"Workforce Management - Worker Assignment Event Real Time"."Assignment Event"."Assignment Event Count" s_7,
FROM "Workforce Management - Worker Assignment Event Real Time"
WHERE
(("Worker"."Employee Last Name" = 'Weasley') AND ("Worker"."Employee First Name" = 'George'))
ORDER BY 1, 2 ASC NULLS LAST, 3 ASC NULLS LAST, 5 ASC NULLS LAST, 4 ASC NULLS LAST, 6 ASC NULLS
LAST, 7 ASC NULLS LAST
Once you do the setup mentioned in Appendix A and apply the patches from Appendix B the same query
will give correct results as shown below.
Report 4.
Logical Sql for Report 4:

SET VARIABLE ENABLE_DIMENSIONALITY = 1; SELECT
0 s_0,
"Workforce Management - Worker Assignment Real Time"."Worker Assignment Details"."Assignment Sequence" s_7,
"Workforce Management - Worker Assignment Real Time"."Worker Assignment Details"."Assignment Status Type" s_8,
WHERE
(("Worker"."Employee Last Name" = 'Weasley') AND ("Worker"."Employee First Name" = 'George') AND ("Workforce
Management - Worker Assignment Real Time"."Worker Assignment Details"."Assignment Status Type" = 'Active'))
LAST, 4 ASC NULLS LAST, 6 ASC NULLS LAST, 7 ASC NULLS LAST
How local dimensions may impact the rows returned in a report.
We will continue with the same example from Workforce Management Subject areas and see how adding
additional local dimensions will change the result set being returned.
In Report 4 we have added additional columns from the Assignment Event Details folder. As you recall
this is a degenerate dimension that is local to the Worker Assignment Event subject area. Because we
have changed the grain of the report we are getting a number of rows for the different actions for the same
worker. The metrics are simply repeated for each of these rows.
Report 5.
Logical Sql for Report 5:

0 s_0,
"Workforce Management - Worker Assignment Event Real Time"."Assignment Event Details"."Effective Start Date" s_5,
"Workforce Management - Worker Assignment Event Real Time"."HR Action Reason"."Action Reason" s_6,
"Workforce Management - Worker Assignment Event Real Time"."HR Action"."Action Code" s_7,
WHERE
(("Worker"."Employee Last Name" = 'Weasley') AND ("Worker"."Employee First Name" = 'George') AND ("Workforce
Management - Worker Assignment Real Time"."Worker Assignment Details"."Assignment Status Type" = 'Active'))
LAST, 5 ASC NULLS LAST, 4 ASC NULLS LAST, 8 ASC NULLS LAST, 7 ASC NULLS LAST, 9 ASC NULLS LAST, 10
ASC NULLS LAST
How results returned from the individual Cross Subject Area queries may
not get merged the way you would want.
We will continue with our example of a Cross Subject Area query on Worker Assignment and
Assignment Events to illustrate this point.
Let’s look at the results we get from each subject area when we run a report on that specific subject area
and then we will analyze how the results may end up getting merged and what can be done to address this
issue and avoid a Cartesian join.
Simple Report on Worker Assignment Subject Area.
This report shows 2 Assignment.
Simple Report on Worker Assignment Events Subject Area.
This report returns 2 assignment events for the first assignment and 5 for the second assignment.
If we were to simply join these 2 subject areas in a Cross Subject Area report then we only have the
worker as a common dimension in such a Cross Subject Area query and you will end up with a report that
returns a Cartesian join of the 2 result sets above as shown below:
There are a couple of ways to address this problem and we’ll discuss these below but this example
highlights why it is important to analyze the results carefully if you are not using conformed dimensions
in a Cross Subject Area report.
Solution 1.
Restrict the result set from the first subject area so you only get a single active assignment. This can be
done by restricting the records to only ACTIVE assignment.
Solution 2.
If you need both ACTIVE and INACTIVE assignments from the Assignment subject area then you can
use a UNION operator to generate 2 separate queries and merge the results to avoid the Cartesian join.
You can use the assignment number or sequence to do this. See next section, “How to Create a Cross-
Subject Area Analysis Using Set Operations”, for details on how to construct such a report.
SET VARIABLE ENABLE_DIMENSIONALITY = 1;

SELECT 0 saw_0,
"Workforce Management - Worker Assignment Event Real Time"."Assignment Event Details"."Assignment Name" saw_1,
"Workforce Management - Worker Assignment Event Real Time"."Assignment Event Details"."Assignment Sequence" saw_2,
"Workforce Management - Worker Assignment Event Real Time"."Assignment Event Details"."Assignment Status Type"
saw_3,
"Workforce Management - Worker Assignment Event Real Time"."Assignment Event Details"."Assignment Type" saw_4,
"Workforce Management - Worker Assignment Event Real Time"."Assignment Event Details"."Effective Start Date" saw_5,
"Workforce Management - Worker Assignment Event Real Time"."HR Action Reason"."Action Reason" saw_6,
"Workforce Management - Worker Assignment Event Real Time"."HR Action"."Action Code" saw_7,
"Workforce Management - Worker Assignment Event Real Time"."Worker"."Employee First Name" saw_8,
"Workforce Management - Worker Assignment Event Real Time"."Worker"."Employee Last Name" saw_9,
"Workforce Management - Worker Assignment Event Real Time"."Assignment Event"."Assignment Event Count" saw_10,
"Workforce Management - Worker Assignment Real Time"."Worker Assignment"."Assignment Count" saw_11
WHERE (("Workforce Management - Worker Assignment Event Real Time"."Worker"."Employee First Name" = 'George')
AND ("Workforce Management - Worker Assignment Event Real Time"."Worker"."Employee Last Name" = 'Weasley')
AND ("Workforce Management - Worker Assignment Event Real Time"."Assignment Event Details"."Assignment Name" =
'E100000019382761'))
UNION ALL
SELECT 0 s_0,
"Workforce Management - Worker Assignment Event Real Time"."Assignment Event Details"."Assignment Name" s_1,
WHERE (("Workforce Management - Worker Assignment Event Real Time"."Worker"."Employee First Name" = 'George')
AND ("Workforce Management - Worker Assignment Event Real Time"."Worker"."Employee Last Name" = 'Weasley')
AND ("Workforce Management - Worker Assignment Event Real Time"."Assignment Event Details"."Assignment Name" =
'E100000019382761-2'))
ORDER BY 1,
2 ASC NULLS LAST,
5 ASC NULLS LAST,
6 ASC NULLS LAST,
4 ASC NULLS LAST,
3 ASC NULLS LAST,
9 ASC NULLS LAST,
10 ASC NULLS LAST,
7 ASC NULLS LAST,
8 ASC NULLS LAST
Solution 3.
This is a more generic solution and would work in most such cases. It does involve understanding how
OBIEE logical query is constructed and how to join two 2 logical queries on common dimension
attributes.
Here is the logical sql that queries the two subject areas separately and then joins the result sets on
Assignment number.

SubjectArea1.s_0 s_0,
SubjectArea2.s2_1 s2_1,
SubjectArea2.s_8 s_8
FROM
(
SELECT
0 s_0,
"Workforce Management - Worker Assignment Event Real Time"."Assignment Event"."Assignment Event Count" s_10
WHERE
) SubjectArea1 FULL OUTER JOIN
(
SELECT
0 s_0,
"Workforce Management - Worker Assignment Real Time"."Worker Assignment Details"."Assignment Number" s2_1,
WHERE
) SubjectArea2
ON
SubjectArea1.s_1 = SubjectArea2.s2_1
ORDER BY s_0, s2_1
How to Create a Cross-Subject Area Analysis Using Set

Operations
The following example is a compound Analysis query that is a union of two result subsets combining
employees’ personal status change from Person subject area (result 1) and assignment changes from
Worker Assignment subject area (result 2). As the two subject areas are not joined in a single result, this
compound analysis will execute successfully.
Appendix A.
1. System Config changes to the opmn.xml file.

BI server and BI Presentation Server needs to be bounce after doing the following changes for the
changes to take effect.
Open following file under bi instance home for editing:

$ORACLE_INSTANCE/config/OPMN/opmn/opmn.xml
Search for following string: <ias-component id="coreapplication_obis1"
You will see a section that looks something like this:
- <ias-component id="coreapplication_obis1" inherit-environment="true">

- <environment>
<variable id="ORACLE_BI_OPMNMANAGED" value="true" />
<variable id="ORACLE_BI_APPLICATION" value="coreapplication" />
<variable id="ORA_NLS10" value="$ORACLE_HOME/nls/data" />
<variable id="PATH"
value="$ORACLE_HOME/common/ODBC/Merant/5.3/Drivers$:$ORACLE_HOME/bifoundation/
server/bin$:$ORACLE_HOME/bifoundation/web/bin$:$ORACLE_HOME/clients/epm/Essbas
e/EssbaseRTC/bin$:$ORACLE_INSTANCE$:$ORACLE_HOME/lib$:$Path" append="true" />
<variable id="ESSBASEPATH"
value="$ORACLE_HOME/clients/epm/Essbase/EssbaseRTC" />
<variable id="ORACLE_BI_SYSTEM_LOGGING" value="off" />
</environment>
Add the following variable to this section:

<variable id="SAS_APPLY_LB_FILTERS" value="1"/>
After this change the new xml snippet would look something like:
- <ias-component id="coreapplication_obis1" inherit-environment="true">

- <environment>
<variable id="ORACLE_BI_OPMNMANAGED" value="true" />
<variable id="ORACLE_BI_APPLICATION" value="coreapplication" />
<variable id="ORA_NLS10" value="$ORACLE_HOME/nls/data" />
<variable id="PATH"
value="$ORACLE_HOME/common/ODBC/Merant/5.3/Drivers$:$ORACLE_HOME/bifoundation/
server/bin$:$ORACLE_HOME/bifoundation/web/bin$:$ORACLE_HOME/clients/epm/Essbase/EssbaseR
TC/bin$:$ORACLE_INSTANCE$:$ORACLE_HOME/lib$:$Path" append="true" />
<variable id="ESSBASEPATH"
value="$ORACLE_HOME/clients/epm/Essbase/EssbaseRTC" />
<variable id="ORACLE_BI_SYSTEM_LOGGING" value="off" />
<variable id="SAS_APPLY_LB_FILTERS" value="1"/>
</environment>
2. Set a session variables for every report from the Advanced tab
Set following 2 variable in the prefix box as shown below. Note that setting
NO_FORCE_TO_DETAIL_BIN=1 is not required in BI Server version 11.1.1.7 and later releases.
The flow is as follows:
(1) Create your Cross Subject Area report in answers.
(2) Click on Advanced tab.
(3) Look for “Prefix” section under “Advanced SQL Clauses”
(4) Copy and paste the following in this box (see screenshot below):
SET VARIABLE ENABLE_DIMENSIONALITY=1,

NO_FORCE_TO_DETAIL_BIN=1;
(5) Click “Apply SQL” button
(6) Click on Results tab.
(7) Review results and save your report
Once variable is set in the prefix box, and you click the “Apply SQL”, this set command is appended
to the Logical query.
Appendix B.
The following patches are needed for the specified releases to get Cross Subject Area queries working.
BIApps Patches.
Fusion Apps Release BIApps Patch Number

Release 5 BIApps Release 5 Patch 8 (Bug 16667334)
Or newer.
BI Tech (OBIEE) Patches.
Fusion Apps Release BI Tech Patch

Release 7 Bug 16615894 - BISERVER RC2 CUMULATIVE PATCH 4
Or Newer.
Terms/Glossary.
Dimensions:
A dimension is a structure that categorizes data in order to enable users to answer business questions.
Commonly used dimensions are Time, Worker, Customer, etc.
Facts and measures:

Facts contain measures like salary, headcount, sales, etc. that you want to report on.
Subject Area:
OTBI organizes reporting data elements like Dimensions and Facts by business function in Subject Areas.
Each Subject Area contains a collection of dimensions and a single fact related to a functional area.
Degenerate Dimension:
Such a dimension comprises the attributes from a fact and is at the same grain as the fact.
Common versus Local Dimension/Conformed versus Non-conformed:

Common or conformed dimensions are available in the subject areas being used in the report. Local or
Non-conformed dimensions are only available in one of the subject areas.
Grain of a Report:
By grain we are referring to the dimensionality of the report. For instance a report showing department
data is at the grain of a department. A report showing department and worker data is at the grain of a
worker.
Scalar Metric:
These are measures or metrics that do not have an aggregation rule defined for them. For example a
percentage measure would not have an aggregation rule as we do not want to sum up percentage values in
a report.
Aggregation function:
These are functions like SUM, COUNT etc that are applied on measures when aggregating for the
dimensions in the report.
STAR Schema:
A STAR schema comprises of a single fact joined to n number of dimensions.
Cartesian join:
A Cartesian join is executed between two tables when no join condition exists between them. The result
set is a product of the rows returned from each table.

OTBI Cross Subject Area Reporting Guidelines

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

OTBI Cross Subject Area Reporting Guidelines

Transféré par

Droits d'auteur :

Formats disponibles

ORACLE WHITE PAPER

Guidelines for creating Cross Subject Area

Subject Areas in OTBI ....................................................................................................................................3

What is a Cross-Subject Area Analysis? .......................................................................................................4

Building Cross-Subject Area Reports using Common Dimensions ............................................................4

How to Create a Cross-Subject Area Analysis Using Set Operations ......................................................14

Subject Areas in OTBI

1. Using common (conformed) Dimensions

Building Cross-Subject Area Reports using Common

Subject area 1: Workforce Management - Worker Assignment Real Time

Common Dimension: Worker

Logical SQL for Report 1.

Subject area 1: Workforce Management - Worker Assignment Real Time

Common Dimensions: Worker, Grade, and Location

Logical Sql for Report 2.

SET VARIABLE ENABLE_DIMENSIONALITY=1, NO_FORCE_TO_DETAIL_BIN=1; SELECT

o System Configuration changes to the opmn.xml file

Logical Sql for Report 3.

Logical Sql for Report 4:

How local dimensions may impact the rows returned in a report.

Logical Sql for Report 5:

Simple Report on Worker Assignment Subject Area.

This report shows 2 Assignment.

Simple Report on Worker Assignment Events Subject Area.

SET VARIABLE ENABLE_DIMENSIONALITY = 1;

SET VARIABLE ENABLE_DIMENSIONALITY = 1; SELECT

How to Create a Cross-Subject Area Analysis Using Set

1. System Config changes to the opmn.xml file.

Open following file under bi instance home for editing:

Search for following string: <ias-component id="coreapplication_obis1"

You will see a section that looks something like this:

- <ias-component id="coreapplication_obis1" inherit-environment="true">

Add the following variable to this section:

- <ias-component id="coreapplication_obis1" inherit-environment="true">

The flow is as follows:

(1) Create your Cross Subject Area report in answers.

(2) Click on Advanced tab.

(3) Look for “Prefix” section under “Advanced SQL Clauses”

SET VARIABLE ENABLE_DIMENSIONALITY=1,

(5) Click “Apply SQL” button

(6) Click on Results tab.

(7) Review results and save your report

Fusion Apps Release BIApps Patch Number

BI Tech (OBIEE) Patches.

Fusion Apps Release BI Tech Patch

Facts and measures:

Common versus Local Dimension/Conformed versus Non-conformed:

Vous aimerez peut-être aussi