Documente Academic
Documente Profesional
Documente Cultură
February 2013
Revision 10.1.3.4.1.34
Page 2 of 36
4.1.4 Complex Folders ....................................................................................................23
4.1.5 Custom Folders ......................................................................................................24
4.1.6 Items .......................................................................................................................25
4.1.7 Joins .......................................................................................................................26
4.1.7.1 Multiple Join Paths ................................................................................................27
4.1.7.2 Circular Joins .........................................................................................................29
4.1.7.3 Duplicate Joins .......................................................................................................30
4.1.7.4 Notes on Migrating Joins .......................................................................................30
4.1.8 Conditions ..............................................................................................................31
4.1.8.1 Mandatory Conditions ...........................................................................................31
4.1.8.2 Optional Conditions ...............................................................................................31
4.1.9 Aggregate Calculated Items ...................................................................................31
4.1.10 Item hierarchies ......................................................................................................32
4.1.11 Discoverer Date Hierarchies ..................................................................................33
4.1.12 Item Classes ...........................................................................................................33
4.1.13 Summary Folders ...................................................................................................33
4.2 DESCRIPTION OF CATALOG OUTPUT FROM DOMA........................................................................ 33
4.2.1 Workbooks .............................................................................................................33
5. HOW DOMA TRANSLATES RPD METADATA ....................................................................... 34
5.1.1 Measures ................................................................................................................34
5.1.2 Facts and Dimensions ............................................................................................34
5.1.3 Key Columns .........................................................................................................34
5.1.4 Migrating Folders without Joins ............................................................................34
5.1.5 Creation of Alias Objects .......................................................................................35
5.1.6 Aggregates and Calculations..................................................................................35
5.1.7 User Privileges .......................................................................................................35
5.2 EVALUATING THE OUTPUT FROM DOMA ...................................................................................... 35
5.2.1 Use of the EUL_DATE_TRUNC function ............................................................36
5.2.2 Joins Involving Different Data Types ....................................................................36
Page 3 of 36
1. Introduction
This document provides a single source of information about translating the metadata
from an Oracle BI Discoverer system to that which can be used by Oracle BI
Enterprise Edition (Oracle BI EE).
The Oracle BI Server includes a multi-user data cache that provides high scalability
and improved query performance. Cache administration is carried out from the Oracle
BI Administration Tool where metadata objects can be flagged as being cacheable in
the physical layer. Other benefits of the Oracle BI Server include clustering capability
enabling high availability and ability to use a variety of enterprise security models.
There is a key difference between the metadata models of the two products whereby
BI EE metadata consists of three layers. A Physical Layer contains the mappings to
the objects that hold the data e.g. a database, MS Excel spreadsheet, XML file etc.
This layer also contains information about how the mappings relate to each other in
the form of primary/foreign keys. The Logical or Business Model Layer contains
mappings of how objects in the physical layer relate to each other. Key differences
with Discoverer are the creation of dimensions and facts leading to the ability to
define level based measures. The Presentation Layer contains the view of the
metadata that the end users see. It is possible to view a diagrammatic representation of
both the physical model (i.e. database model) and logical business model layers. The
Page 4 of 36
benefit of this is a clear and quick understanding of how the metadata objects are
related.
Page 5 of 36
1.8 Oracle BI Applications
The Oracle BI Applications are a complete prebuilt BI solutions that deliver intuitive,
role based intelligence for everyone in an organization. They consist of ETL adapters,
metadata, dashboards and KPIs built to industry best practices to gain insight from
applications including Siebel, Oracle E-Business Suite, PeopleSoft Enterprise, JD
Edwards and SAP.
Page 6 of 36
2. Discoverer to OBI EE Migration Assistant
This section describes and provides instructions for using the Discoverer to OBI EE
Migration Assistant (DOMA). This is a command line utility that greatly accelerates
the translation of Discoverer metadata from the EUL to Oracle BI EE.
Data warehouse i.e. a star or snowflake schema. This is the optimum type of
metadata to use with DOMA and due to the nature of the Oracle BI EE
business model layer generates metadata that in the majority of cases needs
few manual changes before being able to create queries.
Custom built OLTP schema. This type of metadata will probably need manual
changes after being run through DOMA as the Discoverer metadata can
contain join mappings that do not directly translate to the Oracle BI EE
business model layer e.g. multiple join paths between folders and circular
joins. DOMA can cope with these scenarios by the optional creation of
additional objects in the BI EE metadata logical layer e.g. alias dimension or
fact tables. Further details can be found later in this document.
DOMA is a free tool kit. It is made available via the Oracle Technology Network on
an as is basis without any provision of support or plan for any additional
enhancements. While every care has been taken with the production of the tool kit,
there are no warranties of any sort made on the outcomes it produces.
While Oracle BI Discoverer and Oracle BI EE are both tools that provide end users
with information sourced from databases, their approach to this is significantly
different, and complete translation of metadata is not possible.
DOMA provides an excellent starting point for evaluating what an OBI EE based
environment can look like, but as with any move to a new environment, a direct
transplantation may not provide the business benefits that the new environment can
deliver. Consideration should be given as to whether aspects of the current reporting
metadata design exist to suit Oracle BI Discoverer rather than the business needs that
the tool serves. Often a fresh approach delivers many more benefits than a literal
translation.
Page 7 of 36
2.2 Pre-requisites
2.2.1 Windows XP
The DOMA only works on workstations running Windows XP or a virtualized
environment that emulates this operating system.
2.2.4 Tm-extractors-0.4.jar
DOMA also depends on the above jar file to perform its work. The file
tm-extractors-0.4.jar must be downloaded into the java\lib folder of DOMA’s release
package. One source for this file is
http://mirrors.ibiblio.org/pub/mirrors/maven/org.textmining/jars/tm-extractors-0.4.jar
Page 8 of 36
File / Folder Description
Doma_bin Contains all the executables released with the Discovere to OBI
EE Migration Assistant (DOMA).
Migrate.bat Orchestrates the process of migrating the
EUL and workbooks to OBI EE. This
must be run in a command window and
takes a minimum of 2 arguments, the name
of .eex file and the location of where the
intermediate workbooks .xml file should be
placed
setEnvironment.bat Sets variables and updates the path settings
required by DOMA. Migtate.bat saves the
PATH when it starts, calls
setEnvironment.bat, then the other
components. Finally it restores the original
path statement.
DOMA_cat Is the folder into which the generated Answers reports will be
placed. This folder must be created by the user, or if the generate
process is to use another folder, then the file
C:\Doma\OracleBIData\web\config\ instanceconfig.xml must be
modified to reference another folder that exists.
Java\lib This contains jar files required by DOMA. This release excludes
the tm-extractors-0.4.jar which cannot be distributed for legal
reasons. This jar file is required and must be downloaded into
this location by users.
Sample & Contains a command file and a sample eex file to quickly test the
..\hrsample translation of its metadata. This serves as an example that you
can replicate or replace with your own .eex file for your own
translation
translateMyEUL.bat Can be double clicked in Windows
Explorer to call Migrate.bat to orchestrate
the translation processes for the
hr_sample.eex. This can be edited to allow
you translate your own custom .eex file
OracleBIData, Contains the OBI EE elements that are called by DOMA to
server & web perform the migration. These elements are from the OBI EE 10g
release, so the resulting RPD and Answers reports need to be
upgraded to whatever version of OBI EE is installed at the
customer site.
Page 9 of 36
Note: tm-extractors-0.4.jar is not included in the release package and needs to
be downloaded into this folder.
Page 10 of 36
File / Folder Description
hrsample.eex Is the extracted Discoverer End User Layer and a set of
Workbooks
The resulting RPD file and the logs that document the actions
taken during the translation of the EUL to an RPD will also be
placed here
Edit the instanceconfig.xml file – for the supplied sample the current value is shown
on line 5 of the screen shot below
You are now ready to translate the metadata in the supplied hr_sample.eex
Page 11 of 36
2.4 Instructions for using DOMA
2.4.1 Export Discoverer metadata
The first stage in the process is to export the Discoverer metadata you wish to
translate to an .eex file using the Discoverer Administration tool. This document
assumes familiarity with the Discoverer product but details of this process can be
found online in the section About using the Discoverer Export Wizard and Import
Wizard in the Discoverer Administration Guide:
http://download.oracle.com/docs/pdf/B13916_04.pdf
You should export the workbooks as well as the EUL at the same time.
The release bundle includes a sample that you can use as a template and then modify
if required. The command file translateMyEUL.bat works with the exported EUL file
called hr_sample.eex, the folder hrsample and its sub-folders.
Make sure that new_workbooks are empty and edit the file
Doma\OracleBIDate\web\config\instanceconfig.xml as described earlier.
After the RPD file has been generated, open this file using the Oracle BI EE
Administration Tool to update the connection pool settings to point to the data source
being used, run a consistency check and save these changes to the RPD file.
The rpd file is named <eex_file>.rpd – for the hr_sample.eex sample provided that
will be hr_sample.rpd.
1 <Assistant>\translateMyEUL.bat calls
1.1 <Assistant>\bin\Migrate.bat calls
1.1.1 <Assistant>\bin\MigrateEUL.exe to create the RPD
1.1.2 <Assistant>\bin\WorkbookXMLGen.bat calls
1.1.2.1 Java to generate the XML from the .eex file
1.1.2.2 <Assistant>\bin\MigrateWorkbooks.exe to create the webcat
Step 1 can be run after editing the bat file to make use of a different .eex file
and folder structure
Step 1.1 can be run with custom initiating parameters (equivalent to the edits in
Step 1) to generate an RPD and the webcat files – see the usage notes
later
Step 1.1.2.2 can be run separately to read the XML files and create the webcat. If
some workbooks are causing a problem their XML can be selectively
removed to detour any such problems
Page 12 of 36
2.4.3 Usage Notes
You can change highlighted items on line 3 of the command file as follows to make
this change
1. @echo off
2. rem MODIFY this value for your own EEX or replace hrsample.eex with yours
3. SET MYSAMPLE=hrsample
4. rem MODIFY this value if you need to set a font family eg ARIAL
5. SET FONTFAM=
The item on line 5 identifies a font family to be used when generating the Answers
reports. By default this is null, but in some cases following the upgrade of the catalog
to the most current version of OBI EE, when running a report you may get the
following error "Catalog object schema validation failed" and this may be
due to an invalid font family. Add a font family that is installed on the machine
running the presentation server. For example Arial or “Times New Roman” – note
that where the font family has a multi part name, enclose it with quotes.
Page 13 of 36
Param Usage explanation
5 true / false (optional)
true – Use existing discoverer Worksheet format
false – Use OBIEE default format (the default)
6 1 / 2 (optional)
1 less logging (the default)
2 debug logging
7 Font Family Name (optional)
You will probably want to upgrade the generated RPD and Answers from the 10g
format to your current release. Information on how to do this is available in Oracle®
Fusion Middleware Upgrade Guide for Oracle Business Intelligence
Once upgraded to the required version, you should always open the final RPD and do
the following.
a) Set the credential for the data source – these are not migrated
b) Set the database properties to Default
c) Run the consistency checker
d) Save the updated RPD
Note: the folder in which the catalog files will be created is dictated by the setting
in the file Doma\OracleBIData\web\config\ instanceconfig.xml .
Page 14 of 36
2.4.4 Migration Log Files
DOMA generates two log files that contain the following information:
<eex_ file>.exception.log - captures the items whose metadata could not be migrated
such as skipped joins and folders.
For each of the business areas whose metadata is translated, these files contain the
following details:
Page 15 of 36
Dimension : Geography Hierarchy
-- Dimension(s) creation...[DONE]
************* LOGICAL LAYER CREATION DONE *************
************* CREATING PRESENTATION LAYER *************
-- Creating Presentation Folder(s)...
Folder : HR: Regions
Folder : HR: Countries
Folder : HR: Locations
Folder : HR: Departments
Folder : HR: Employees
Folder : HR: Managers
Folder : HR: Jobs
-- Presentation Folder(s) creation...[DONE]
************* PRESENTATION LAYER CREATION DONE *************
****************************************************************
Business Area : HR - Employee History
****************************************************************
-- Processing EUL Joins....
-- Processing Folder(s) based on EUL Joins....
## List of Folder(s) with SKIPPED JOINS / PATHS
FOLDER_ID SELECTED = ### FOLDER_NAME JOIN_NAME
--------------------------------------------
### FOLDER CONTAINER MAPPING ###
Mapping For Folder : HIST: Departments : HIST: Departments
Mapping For Folder : HIST: Employees : HIST: Employees
Mapping For Folder : HIST: Job History : HIST: Job History
Mapping For Folder : HIST: Jobs : HIST: Jobs
-- Processing Complex Folder(s)....
-- Processing Dimension(s)....
************* CREATING PHYSICAL LAYER *************
-- Creating Database...[DONE]
-- Creating Connection Pool...[DONE]
-- Creating Physical Table(s)...
-- Physical Table(s) creation...[DONE]
-- Creating Physical Join(s)...
-- Physical Join(s) creation...[DONE]
************* PHYSICAL LAYER CREATION DONE *************
************* CREATING LOGICAL LAYER *************
-- Creating Subject Area...[DONE]
-- Creating Logical Table(s)...
-- Creating Logical Join(s)...
-- Logical Join(s) creation...[DONE]
-- Creating Calculation(s)...
- Creating Complex Folder Calculation(s)...
-- Calculation(s) creation...[DONE]
-- Logical Table(s) creation...[DONE]
-- Creating Dimension(s)...
-- Dimension(s) creation...[DONE]
************* LOGICAL LAYER CREATION DONE *************
************* CREATING PRESENTATION LAYER *************
-- Creating Presentation Folder(s)...
Folder : HIST: Employee Job History
-- Presentation Folder(s) creation...[DONE]
************* PRESENTATION LAYER CREATION DONE *************
****************************************************************
Business Area : TEST Business Area
****************************************************************
-- Processing EUL Joins....
-- Processing Folder(s) based on EUL Joins....
## List of Folder(s) with SKIPPED JOINS / PATHS
FOLDER_ID SELECTED = ### FOLDER_NAME JOIN_NAME
--------------------------------------------
### FOLDER CONTAINER MAPPING ###
Mapping For Folder : Countries : Countries
Mapping For Folder : Regions : Regions
-- Processing Complex Folder(s)....
-- Processing Dimension(s)....
************* CREATING PHYSICAL LAYER *************
Page 16 of 36
-- Creating Database...[DONE]
-- Creating Connection Pool...[DONE]
-- Creating Physical Table(s)...
-- Physical Table(s) creation...[DONE]
-- Creating Physical Join(s)...
-- Physical Join(s) creation...[DONE]
************* PHYSICAL LAYER CREATION DONE *************
************* CREATING LOGICAL LAYER *************
-- Creating Subject Area...[DONE]
-- Creating Logical Table(s)...
-- Creating Logical Join(s)...
-- Logical Join(s) creation...[DONE]
-- Creating Calculation(s)...
- Creating Complex Folder Calculation(s)...
-- Calculation(s) creation...[DONE]
-- Logical Table(s) creation...[DONE]
-- Creating Dimension(s)...
-- Dimension(s) creation...[DONE]
************* LOGICAL LAYER CREATION DONE *************
************* CREATING PRESENTATION LAYER *************
-- Creating Presentation Folder(s)...
Folder : Regions
Folder : Countries
Folder : Region Country
-- Presentation Folder(s) creation...[DONE]
************* PRESENTATION LAYER CREATION DONE *************
Page 17 of 36
Oracle BI SE - EE Workbook Migration Assistant Version 10.1.3.4.1
Discoverer Worksheet Format will be applied to Migrated Reports as per your Option:
Filters will be shown in Results page of Answers as per your Option:
*** Formula isEVALUATE('TO_CHAR(%1,''YYYYMMDD'' )' AS CHAR,NOW())
*** Formula isEVALUATE('TO_CHAR(%1,''YYYYMMDD'' )' AS CHAR,NOW())
*** Formula isEVALUATE('TO_CHAR(21)',)
Creating Request : discoverer.HR.Job History...[DONE]
Creating Request : discoverer.HR.Emp by Region (NOT IN)...
Token Conditions in Title is not supported, it will not be migrated[DONE]
Creating Request : discoverer.HR.Emp by Dept & Mgr...[DONE]
Creating Request : discoverer.HR.Employee Salary By Dept Custom Format (__)...
Token Conditions in Title is not supported, it will not be migrated[DONE]
Creating Request : discoverer.HR.Employee Salary By Dept Format Currency...
Token Conditions in Title is not supported, it will not be migrated[DONE]
Creating Request : discoverer.HR.Currency Format Only...
Token Conditions in Title is not supported, it will not be migrated[DONE]
Creating Request : discoverer.HR.CASE DECODE...[DONE]
Creating Request : discoverer.HR.CASE Complex...[DONE]
Creating Request : discoverer.HR.Concatenation...[DONE]
Creating Request : discoverer.HR.Substring...[DONE]
Creating Request : discoverer.HR.Parameter...
Token Parameters in Title is not supported, it will not be migrated[DONE]
Creating Request : discoverer.HR.Condition with OR...
Token Conditions in Title is not supported, it will not be migrated[DONE]
Creating Request : discoverer.HR.Format Tests...[DONE]
Creating Request : discoverer.HR.Calc Item Format...[DONE]
Creating Request : discoverer.HR.Crosstab Analysis...[DONE]
Creating Request : discoverer.HR.InitCap...[DONE]
---------------------------------------
WORKBOOK MIGRATION SUCCESSFUL
---------------------------------------
Page 18 of 36
****************************************************************
Business Area : HR - Employee History
****************************************************************
## List of Folder(s) with SKIPPED JOINS / PATHS
FOLDER_ID SELECTED = ### FOLDER_NAME JOIN_NAME
--------------------------------------------
****************************************************************
Business Area : TEST Business Area
****************************************************************
## List of Folder(s) with SKIPPED JOINS / PATHS
FOLDER_ID SELECTED = ### FOLDER_NAME JOIN_NAME
--------------------------------------------
Property Settings
CreateAggregatedCols TRUE - Columns with aggregations like SUM, MIN, MAX,
AVG and COUNT will be created for measure columns.
FALSE - Aggregated Columns will be created for measure
columns based on the DEFAULT AGGREGATION property
set in the EUL
CreateSeperateRPDs TRUE - Separate repository is generated for each business
area.
FALSE - All the business areas are migrated to a single
repository.
ExcludeJoins A comma separated list of JOIN_ID to be skipped during
migration. Any JOIN_ID listed here will get excluded during
migration.
ConsiderMultiplePaths TRUE - The migration assistant will accommodate the
joins that would be otherwise skipped during migration.
FALSE - The migration assistant will not accommodate
the joins skipped during migration.
IncludePathsForFolders Valid values are comma separated TABLE_IDs as
generated in the log file for the folders with joins that are
skipped to eliminate Circular and Multiple Join paths.
If ConsiderMultiplePaths property is TRUE
AND IF there are no values specified for
IncludePathsForFolders then
all the Skipped Joins will be migrated.
If there are values specified, then the joins for these are
migrated.
If ConsiderMultiplePaths property is FALSE
It will not consider IncludePathsForFolders values
Connection pool DataSourceName, Username
parameters
Page 19 of 36
3. Problems and Detours
This section provides a list of known problems that are not feasible to fix and require
detours
To detour this problem, use the Admin tool to go to the Database properties and reset
its features to Default. After you have done this verify consistency and save.
Page 20 of 36
store tutorial sample workbooks. If “generate column name automatically” is
selected in Discoverer, then the XML for the worksheet, does not contain a
real column name as Discoverer dynamically generates this. Consequently a
report cannot be built because there is no way to identify what RPD column to
use.
The only supported version of OBI EE is 10.1.3.4.1 and the required components
from this are included with the DOMA bundle – the RPD and Answers reports
generated must then be upgraded using the upgrade tools available with the specific
version of OBI EE 11g that the customer has deployed.
This may be due to an invalid font family. In this case you need to specify a font
family that is installed on the machine running the presentation server. For example
Arial or “Times New Roman” – note that where the font family has a multi part name,
enclose it with quotes.
Page 21 of 36
3.10 Japanese workbook names not translated correctly
The character set encoding in the Oracle database used to create the EUL needs to be
UTF-8 otherwise the folder name generated may contain invalid characters.
Page 22 of 36
4. Description of RPD output from DOMA
This section describes the mappings used by DOMA for the metadata properties in
Discoverer Administrator. Where there is no equivalent property in Oracle BI EE this
is indicated by ‘n/a’. It also describes any assumptions that DOMA makes when
creating the three layers that make up the Oracle BIEE metadata model.
Page 23 of 36
Discoverer administration perspective, they are useful for combining items into
logical groups to simplify the end users view of the metadata. From an end users
perspective, this can make life easier as they only need to go to a single folder to get
all the items they need for a report rather than multiple folders.
Complex folders will be mapped to a logical table in the Logical Layer having a
Logical Table Source that contains the base folders and the joins between them. This
folder in turn will be joined to those base folders, which are Dimensions.
Complex folders appear in the Presentation Layer with the following mapping:
The item references of the complex folder will be picked from the respective
base folders in the logical layer.
For creating the Discoverer ‘admin calculations’ within a complex folder, a
logical table corresponding to the complex folder will be created in the logical
layer.. Those calculations involving items from more than one base table will
be created in the Complex Folder. The Logical Folder will then be moved to
the presentation layer. However, if the ‘admin calculations’ are based on a
single base folder, they will be migrated to the corresponding Logical folder
and not the Complex Folder.
Note that complex folders based on items from another complex folder cannot be
migrated automatically.
Page 24 of 36
Description Description Description Description
Visible to User Will not appear in n/a n/a
this layer if set to
NO
Valid Will not appear in n/a Only created if its
this layer if not valid
valid
Custom SQL n/a n/a Default
initialization string
Identifier n/a n/a n/a
4.1.6 Items
Items are the basic building block for queries. They are mapped to columns in
database tables or views or created from calculations in Discoverer Administrator.
These calculations can be based upon PL/SQL functions. Discoverer items migrate to
physical columns in the physical layer, logical columns in the business model layer
and presentation columns in the presentation layer of Oracle BI EE. Only items that
are not hidden from end users will appear in the presentation layer.
Page 25 of 36
Replace NULL n/a n/a n/a
with
Content type n/a n/a n/a
Alternative n/a n/a n/a
display value
Max char n/a n/a n/a
fetched
Indexed item n/a n/a n/a
Identifier n/a n/a n/a
In Discoverer, when building a query, end users are able to use either the default
aggregation for an item or select from a list of available aggregation functions. In
Oracle BI EE metadata, it is possible to specify the default aggregation for a particular
column in the logical layer, however this aggregation cannot be changed (in a similar
manner to Discoverer) during the creation of the answers worksheet. The user needs
to create another column and define the required aggregation.
In order to offer end users a similar experience for selecting aggregations the
migration has an option to create a separate column in the logical layer for each
default aggregation that is supported in Discoverer. This configuration option is
CreateAggregatedCols. If set to TRUE while migrating, all aggregations supported by
Discoverer will be generated. If set to FALSE then a column with its aggregation
function set to the Discoverer ‘default aggregation’ will be created.
4.1.7 Joins
Joins in Discoverer metadata define relationships between the folders that are used for
building queries. Usually joins are defined using the corresponding key columns of
the underlying database objects. Due to the differences in the metadata models
between Discoverer and Oracle BIEE there are some differences in the types of joins
that can be migrated automatically.
It is in this area of metadata that the differences between Discoverer and Oracle BIEE
metadata become apparent. The main difference is that the logical business model
layer needs to be based around one or more star schema models (this is a common
data model for data warehouse design). A variation on the star schema model is
known as a snowflake model (commonly represents the hierarchy levels of a
dimension as separate tables). In these cases, the migration assistant ‘collapses’ the
snowflake dimensions to their lowest level of dimension above the fact table.
The physical metadata layer does not need to be modeled around a star schema so this
layer is created using the join information from the Discoverer metadata.
Page 26 of 36
Property In Presentation In Logical Layer In Physical Layer
Layer
Name n/a Logical join name Physical foreign key name
Auto generate n/a n/a n/a
name
Description n/a n/a n/a
Master n/a Cardinality = 1 The master table is the one
containing a primary key
Detail n/a Cardinality = N The detail table is the one
containing the foreign key
Formula n/a n/a Expression for the foreign
key relationship
Outer join on n/a Type Type.
OuterJoinOnMaster
is mapped as
RightOuterJoin
DetailItemValuesAl
waysExistInMaster
is mapped as 1:N
DetailItemValuesM
ightNotExistInMast
er is mapped as
0,1:N
Page 27 of 36
In the case of multiple joins to the same folder, the detail folder will be aliased:
CALENDAR DATE
J1 J2
SALES
CALENDAR DATE
J1 J2
SALES SALES_A1
Page 28 of 36
J2 BONUS.EMP_ID = EMPLOYEE.EMP_ID
J3 BONUS. DEPT_NO = DEPT.DEPT_NO
Page 29 of 36
4.1.7.3 Duplicate Joins
In the case where duplicate join definitions exist in the Discoverer metadata, only one
of the duplicate joins created in Discoverer will be considered for migration. Any
duplicate joins that have been detected will be noted in the migration log files.
The join between any two folders is skipped when they share more than one
common dimension, for example see below:
Table F2 Table D3
This heuristic is applied to simplify the model..In the case above, table F1 and F2
are better treated as facts and D1, D2,D3 as dimensions in a classical star schema.
The join between F1 and F2 is redundant for most practical situations. In the
cases where it is determined to be important, it can be manually restored by
aliasing table F2.
Folder A has a join to Folder B and vice-versa. In such a scenario one of the
joins will be skipped randomly. The skipped join is not available for further
inclusion
Joins involving calculations in the join condition will not be migrated.
Only one join path is available between the component folders of a complex
folder
Page 30 of 36
In the case of non-equi joins in Discoverer metadata, the resulting object in the
physical layer is a complex join
Oracle BIEE does not support 1:1 joins
In the following cases, Oracle recommends checking the results of the migration
assistant:
Joins based on columns where the column in the master and the detail tables
have different data type
Calculations involving EUL_DATE_TRUNC function
Admin mandatory conditions based on date columns
4.1.8 Conditions
Discoverer allows the creation of conditions in the metadata. Conditions can be both
mandatory and optional. Mandatory conditions are not visible to the end user and
have the effect of limiting the data that can be queried. Optional conditions can be
defined for end user convenience, i.e. the user (who may not be familiar with SQL
syntax) can optionally use pre-defined conditions, perhaps containing complicated
logic in their reports by dragging them into their report from a list of available
conditions.
Page 31 of 36
The formula for the ‘margin percentage’ item highlighted above is:
Discoverer has the ability to allow the creation of multiple hierarchy drill paths. This
migrates to entries in the preferred drill path property of the BI EE dimension level
property.
Page 32 of 36
name
Description n/a Dimension n/a
description
4.2.1 Workbooks
A workbook contains worksheets displaying data retrieved from the database.
Workbooks typically contain data that is related in some way but organized to show
different perspectives. Worksheets contain the data that one wants to analyze, together
with a number of Discoverer components like parameters, totals, percentages,
exceptions, and calculations to help one analyze the data. Each worksheet in a
workbook contains the result of a query.
Page 33 of 36
5. How DOMA Translates RPD Metadata
5.1.1 Measures
Measures are identified by their placement and default aggregation settings in the
Discoverer metadata. Any attribute having placement value as data point and default
aggregation value that is neither ‘none’ nor ‘detail’ is defined as a measure. Any non-
measure is considered a dimension
The leaf node for any dimension is always the level containing the folder key
columns.
The content of a logical table source for a folder is mapped to its linked dimension
levels.
Page 34 of 36
5.1.5 Creation of Alias Objects
A dimension alias is created for a fact folder when there exists a hierarchy based on it.
The description of an aliased folder contains the usage information and the join for
which it was created. The original folder must be used for all those joins which don’t
have an aliased folder based on it.
Calculations involving columns from only one folder is created in its own folder
whereas those calculations that involve columns from multiple folders are created in
the complex folder.
All calculations are created using either the Evaluate or Evaluate_Aggr function in the
logical table source containing the column mappings.
Page 35 of 36
5.2.1 Use of the EUL_DATE_TRUNC function
The date hierarchies that Discoverer can automatically generate make use of a built in
function called EUL_DATE_TRUNC. For example, the following calculation in
Discoverer returns a ‘Quarter’ for a date column e.g. ‘Transaction Date’. The valid
values are ‘Q1’, ‘Q2’, ‘Q3’, ‘Q4’ and the result is a ‘date’ data type:
EUL_DATE_TRUNC(Transaction Date,'"Q"Q')
Again, the resultant column is a ‘date’ data type. However, if this column is used in
another calculation:
The migration assistant will not apply any data type Translations but will migrates the
join ‘as is’. The Translations need to be added as a post migration assistant step.
Page 36 of 36