OBIEE - Logical Table Source (LTS)

(Physical and Logical Column Mappings)

About
Logical table sources define the mappings from a single logical table to one or more physical
tables. A logical table contains one or more logical table source. The mapping between physical
columns and logical columns are done in this element.
The definition of the logical table source is used:

to specify transformations/calculations (in the column mapping tab),

to enable aggregate navigation and fragmentation (in the content tab)

The Content tab of the Logical Table Source is used to define :

any aggregate table content definitions (specify the grain of the physical tables),
fragmented table definitions for the source,

and WHERE clauses (if you want to limit the number of rows returned).

Benefit of using multiple Logical table Source in OBIEE 11g Admin Tool

One of the use of multiple LTS is converting a snow flake schema to star schema.
Take below as example.
Let's say we have dept, emp and the attendance fact. In a warehouse we usually keep both employee
and dept data in a single employee dimension. But lets assume we have them normalized for this
example.
So in the rpd physical diagram would be
dept <- emp <- attendance fact
This is snow flaked and when we transfer these table to BMM layer we will create a single dimension like
Dim - Employee, with 2 logical sources corresponding to dept and emp tables.
Another one would a fact for attendance and the BMM diagram would look something like as below
Dim - Employee <- Fact - Attendance
Now you can create a report like monthly attendance of employees or see how many employees were
present department wise in a month etc., etc.

Another way of doing this would be that you create 2 dimensions in BMM layer. One would be Dim Employee and other would be Dim - Department.
Employee dimension would only contain 1 LTS mapping to emp table in physical layer.
Your BMM diagram would look like as below this time.
Dim - Employee <- Fact - Attendance -> Dim - Department
Now in the physical layer emp table has a direct join with the attendance table, so no issues in that.
But the dept table does not have a direct join with attendance, in fact it needs to pass through emp table
to get to attendance table.
So this is one of the case where you use the approach of multiple tables into a single logical table
source.
You will create a new logical table like Dim - Department in BMM layer and then will add both emp table
and dept table in the logical source with an equi join. This way when you are going to use a column from
Dim - Department table in reports against Fact - Attendance, OBIEE is always going to add the below join
in the physical query and hence defining a path to the attendance table from dept table.
where dept.deptno = emp.deptno
and emp.eno = attendance.eno
The same concepts we use while using OBIEE against OLTP systems where the tables are highly
normalized and we need to jump several tables to get the table we have declared as fact, essential doing
the whole work of ETL in the BMM layer.
But that's a whole different story and you can refer the below link to get a better understanding of the
concept. Also, since OBIEE 11g do not have option to declare a table as bridge table, so we can use both
of the above approaches to model a bridge table.
Below is a link where you can get some more insight of the concept.