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

[I have copied this answer from LinkedIn BI group - Answer given by Sandeep]

I have already explained and here goes my explanation for this group as well. :) 

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. 

http://www.rittmanmead.com/2012/06/using-obiee-against-transactional-schemas-part-1-introduction/ 

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. 

http://docs.oracle.com/cd/E21764_01/bi.1111/e10540/busmodlayer.htm#BIEMG1386 

Happy OBIEEying and hope someone can also add another comment to clear the concept. 

Thanks,
Zafar Habib