Joins in Oracle BI   EE

06/08/2010 BY DAAN BAKBOORD LEAVE A COMMENT

There a lot of questions on the Oracle Forums, recently also, about join in Oracle BI EE. It seems like there are a lot

of misconceptions about the use of joins in Oracle BI EE. 

There are two types of joins;

Foreign Key Join

Complex Join

These joins could be applied to two different in layers;

Physical Layer

Logical Layer (Business Model)

 –> When would you use which join?

You can use both joins in both layers. There are some basic rules when it comes to using joins in Oracle BI EE.

In the Physical Layer, you should use Foreign Key joins, while in the Logical layer it’s common to use Complex Joins.

–> Why should you use these joins ?

Physical Layer – Foreign Key Join

The Oracle BI Server uses the Foreign Key Joins to construct the where clause when selecting form multiple tables.

There are two types of keys in the Physical Layer:

Primary Key – Unique identifier of a single record in a table

Foreign Key – Reference to the Primary Key of another table

So basically the Foreign Key Join is a ‘Primary Key / Foreign Key’- relationship between two tables.

 There are situations where you could use Complex Joins in the Physical Layer. Jeff McQuigg  has written a good

blogpost about this subject.

Basically it comes down to the following three situations:

Range Joins

Data Type Conversion Joins

Cartesian Joins

Logical Layer – Complex Join

You use Complex Joins in the Logical Layer only to tell the Oracle BI Server that there is a link between the two

tables. The Oracle BI Server should go to the Physical layer to see the actual link between the two tables.

A logical tabel consists of one or more Logical Table Sources. Multiple Logical Table Sources  lead to multiple join

paths. Using a Foreign Key join in a situation where multiple join paths exists, restricts the Oracle BI Server only to

use the specified join. Therefore it is common practice to use a Complex Join in the Logical Layer.

I hear you think; Why is the Foreign Key Join supported in the first place? It seems to only be there for backwards

compatibility

In the Logical Layer you define Primary Keys as well. The purpose of a Primary Key in the Logical Layer is….

…to identify the Unique identifier of a single record in a Logical Table

… to identify the lowes level of detail of a Logical Table

FILED UNDER MODELLING TAGGED WITH JOIN, LOGICAL LAYER, ORACLE BI EE, PHYSICAL LAYER

Sorting the Month   Name

22/06/2010 BY DAAN BAKBOORD LEAVE A COMMENT

I saw a post on the Oracle BI EE Forums today; Sorting month name. There were various solutions to the question. I

think Kishore Guggilla  came up with the best solution, so he deserves all the credits.

Although, it’s a very easy solution to a very simple ‘problem’, I thought I write a little post about the subject, because

the solution can be used very often. Not only in a month sort.

Picture the following. I have created a dimension table with month names and month numbers.

Based on this dimension table I have created the following Business Model.

Now we can create a simple report with the month names.

As you can see the month names ar sorted alphabetically. We can verify that by the query fired.

If we want to sort the month names based on theire month number, we have various options. As said before I like the

solution via the repository. In the repository you can sort a column, using another column. Just change the properties

of the logical column. Now the BI Server knows that it hast to sort the month name via the month number.

Now we can create the same simple report with the month names.

As you can see now the month names ar sorted by month number. We can verify that by the query fired.

Easy but powerful in some cases.

FILED UNDER LOGICAL LAYER TAGGED WITH DIMENSION, LOGICAL LAYER, ORACLE BI EE

Multiple Fact Reporting on (Non-)Conforming dimensions – Part   II

06/06/2010 BY DAAN BAKBOORD LEAVE A COMMENT

Last week I have been blogging about Multiple Fact Reporting on (Non-)Conforming   dimensions . Thanks to NicolaeI

was triggered to do some further investigation on this topic. He had a question; What happens when you want to filter

on a non-conforming dimension?

When you filter an a non-conforming dimension, you could get a null value for the fact which has all the dimensions

as conforming.

 

 

Is this not exactly how the Oracle BI-server works? We have created one logical fact table and two different logical

table sources (LTS). The Oracle BI-server creates seperate queries for each LTS in a Oracle BI Answers query.

Query I:

Query I connects fact table 1 to all the dimensions, including a filter on the non-conforming dimension.

Query II:

Query II connects fact table 2 one to the conforming dimensions only. Because there is no physical relationship

between fact table 2 and the non-conforming dimension, it is not possible to filter query II on  dtnc1.value3 = ’3CCC3′

as well.

The results of both queries:

Lucky enough for me Nicolas did some investigating himself to:

Oracle BI EE Forum

Filter on a dimension with a fact that don’t depend on that dimension

filter and non-conforming dimensions

Siebel IT Toolbox

Two fact tables and non-conforming dimensions

It looks like the most easy solution is to filter on the fact table which has all the dimensions as conforming. In this

case, that would be; Fct1 Value1.

I will try to ask some other sources what their solution is to this ‘problem’.

More to come.

FILED UNDER LOGICAL LAYER TAGGED WITH CONFORMED, DIMENSION, FACTS, HIERARCHY, LOGICAL

LAYER,ORACLE BI EE

Multiple Fact Reporting on (Non-)Conforming   dimensions

31/05/2010 BY DAAN BAKBOORD 3 COMMENTS

There are some questions, which are popping up at the Oracle BI EE Forums regularly. One of those questions is; 

*** How to model multiple facts against (non-) conforming dimensions?

I will try to work things out. Click on the images to see more detail.

Note: I am aware of the extra white space between the images. That’s not intended functionality, but lack of

knowledge of  WordPress. 

Picture the following:

There are two fact tables and three dimension tables. FACT_TABLE_1 has two conformed dimension tables;

DIM_TABLE_CONF_1 and DIM_TABLE_CONF_2 and one non-conformed dimension table

DIM_TABLE_NON_CONF_1.

FACT_TABLE_2 has two conformed dimension tables; DIM_TABLE_CONF_1 and DIM_TABLE_CONF_2. 

The Physical Model would have the following structure:

Physical Diagram

Based on the Physical Model we could construct the following Logical Model: 

Logical Diagram

I have created one fact table which contains Logical Table Sources (LTS) for FACT_TABLE_1 and FACT_TABLE_2

Logical Model

As you can see I have created Dimensions (Hierarchy’s) for each Dimension Table.   

FACT_TABLE_2 has no physical relationship with DIM_TABLE_NON_CONF_1. Therefore you should set the logical

levels for FACT_TABLE_2 to the ‘Grand Total’-level of DIM_TABLE_NON_CONF_1. This way the Oracle BI Server

won’t look for a join between DIM_TABLE_NON_CONF_1 and FACT_TABLE_2.

If you want to avoid nulls, set the detail levels for the facts. Set the ‘Grand Total’-levels for the metrics as well.

Logical Table Source - Fact I

Logical Table Source - Fact II

Logical Column - Fact II

If we take a look at Oracle BI Answers, we can create a report which contains data from the following tables;

DIM_TABLE_CONF_1

DIM_TABLE_CONF_2

FACT_TABLE_1

FACT_TABLE_2 

Oracle BI Answers - Conformed Dimension

Now we can bring data from DIM_TABLE_NON_CONF_1 into this report. It is impossible to devide data from

FACT_TABLE_2 over this dimension. Therefore the data will be the same for every value of this dimension.

Oracle BI Answers - (Non-) Conformed Dimension

*** Summary:

 It’s possible to report on facts and dimensions which not have a physical relationship to each other. Just make sure

you create dimensions (hierarchy’s) for every dimension table. Next to that you should set the logical levels for your

logical tables.

FILED UNDER LOGICAL LAYER TAGGED WITH CONFORMED, DIMENSION, FACTS, HIERARCHY, LOGICAL

LAYER, OBIEE

Circular JoinsThe first physical layer problem is Circular Joins.  A circular join is where there are 2

routes to get from one table to another, going from a dimension to a fact.  Aggregate

tables don’t count, as they are alternate tables used and won’t cause circular joins in

the SQL.  A real circular join is where usually 2 dimension tables join to each other, and

each dimension tables also joins to a fact.  This can happen frequently with small look-

up tables in a non-denormalized schema, such as a snowflake or Transactional model.

There are three ways to fight this, and if you follow them, you will never ever encounter

them.  In fact, I haven’t seen a circular join in a few years.

1. Import physical tables without FK joins turned on.  Make the joins yourself, so there is nothing hidden that could cause problem.  You should “own” your joins, not the other way around.

2. Aliases are the technique one uses to eliminate circular joins.  An easy example of how to use aliases is when you have a lookup table, like W_LOV_D – each version of it requires an alias, which will be joined to differently.

3. With all tables & aliases, using a naming standard will guarantee that only one physical layer object will exist in one Business Model object.  If you prefix every object in the physical layer with its Logical usage first (essentially making everything an alias), you will not be able to use the Customer (W_COUNTRY_D) table in the Employee logical table, as the standard would require you to use a table alias called Employee (W_COUNTRY_D).   The 7.9 OOB repository has finally adopted a similar approach.

Nullable FlagThe most devious Gotcha however is the nullable flag on each column.  Since many

DBAs get lazy and do not set NOT NULL constraints in the database; this mis-

information is consumed by the BI Server and gives it a tummy ache.  Incorrect not-null

settings are important to the BI server as they guide how it not only generates SQL but

does internal joins as well.

By leaving the default of Nullable set to true, just think what that is saying:  it is saying

that one can expect null values to appear in the column. Whenever a join on this

column is needed, such as for a subtotal or a logical query that derives into multiple

physical SQLs, the join syntax can be affected.  When subtotaling on such a field,

certain kinds of metrics that are calculated in the SQL (such as a count distinct) can

cause problems.

When subtotaling on a field in a report, this will translate into a multi-part query of the

basic format:

Select  fields

from Select (Detail Rows) DR,

Select (SubTotal Rows) SR

Where DR.SubTotal Field = SR.SubTotal Field

Note that for straight additive measures, the server will do the calculation and not the

SQL.

If the field you are SubTotaling on is set to nullable, then you have the following join

condition:

nvl(DR.c1 , 88.0) = nvl(SR.c1 , 88.0)

and nvl(DR.c1 , 99.0) = nvl(SR.c1 , 99.0)

No that is not a typo.  Although the join condition it generates is a little bizarre by being

redundant, it is clear that the server is taking into consideration that the field may be

null.  For varchar fileds, it uses ‘q’ and ‘z’ instead of 88 and 99.  (This is dangerous if

you actually have those values in the field!)

When set to Not Null, your join condition will be simply:

D1.C1 = SR.C1

There are two errors you can make, each the opposite of the other:

1. Setting the column to null when it is really not null.  This will give you the correct answer, however it will be slower than the straight join due to the non-use of indexes.

2. Setting the column to not null when it is really nullable.  This will result in the wrong answer, as the equi-join will remove null rows from the recordset completely.

Thus, be very accurate about your nullable settings in the physical layer.  Ideally this

should be handled in the database data model before you import a table to ensure that

your physical layer does not become out of synch with the actual database.

Primary KeysWhen beginning with Analytics / OBI, a lot of people make the mistake of creating too

many primary keys when their PK simply has multiple columns.

Normally in Data Warehousing, a dimension table has a single field to be its primary

key.  However sometimes we do not have that luxury, and must use multiple fields to

represent our PK.  The best example of this is a Fact table: its PK is a combination of all

the FKS to the dimension.  For example, a small fact table with FKs to Product, Month

and Region has a composite Primary Key of PRODUCT_KEY, MONTH_KEY, REGION_KEY. 

It is one key and not three: in the Analytics Physical layer, configure one Primary key

but select multiple physical columns to define the key.

As a basic rule, think of the Highlander: “There can be only one!”  There are advanced

scenarios where their may be more than one, but 99% of the time, make sure every

physical layer table has a single PK.

Complex JoinsOccasionally I will see complex joins where a complex join is not needed.  The vast

majority of the time your joins should be straight FK joins, even if the PK of the parent

table is a composite PK (see above).

Complex joins are used in the following scenarios:

Range Joins . Useful for YTD metrics or rolling metrics.  In 10.1.3.2, the need to do this has been eliminated, but your legacy config may still need them for this purpose.  An example might be: W_DAY_D.DAY_KEY <= FACTS.DAY_KEY AND W_DAY_D.DAY_KEY < FACTS.DAY_KEY + 7.  This query will bring back the last seven days of facts for the current day selected.  (Yes this looks strange, but try it out on a piece of paper to see how it works)

Data Type Conversion Joins .  This is common in non-star schema models, or poorly designed ones.  The most common example is the conversion of a date field to a YYYYMMDD format to join to a date table that has a field of the same YYYYMMDD format.  Incidentally, this is one of the reasons why you would have more than one PK of the date table – DAY_KEY and DAY_NUMBER would both be PKs if you had to do this.

Cartesian Joins .  In strange circumstances, a 1=1 join can be used.  Be extremely careful, as this is a Cartesian product, which means the same thing as no join, which in turn means all records from table 1 will be pared with all records from table 2.  I have had to use this in my current project extensively, where we have to force a dimension to work with a fact table for the sake of the UI.  When doing so, you must guarantee that only one of the dimensional values is selected in the report or prompt; otherwise your result will be substantially incorrect.

Scenarios when you should not use a complex join

1:1 Joins .  This is common when using _DX and _FX tables in the Oracle BI applications (the RMW).  A complex join frequently is over included in SQL, meaning that sometimes it is added and slows down performance even when it is not needed.  Model this with the _DX or _FX as the parent of the base _D or _F table using a regular FK join

Filtering .  This is where there is a filter in the join to exclude some rows from one of the tables.  Think about a LOV table.  One could make a join to a LOV and filter out the TYPE field to just ‘Case Status Types’.  Although this will work, it is poor design and can be missed in other joins.  It is best to put the filters in the LTS Content tab for the Dimension table it is mapped to.