Business Objects : Alias vs Context

Context- is the sets of join path for one table to another table

Alias-  Alias breaks the loop by using same table with different name in the query.

Contexts have a purpose. Aliases have a purpose. In every case , which one you select is based on the problem you are trying to solve, not really what you think will be the best maintenance option. If you need a context, then you need a context. 

But  there are two key rules of thumb: 

A context for each fact table .

An alias for each different use of a reference table - e.g. multiple uses of calendar_ref for invoice dates, sales dates, delivery dates, etc.

Another factor that can be consider could be Based on usability -

if the universe is very large and complex then always try to use contexts. It will reduce the pain of adding redundant aliases. If universe is a small relatively simple in terms of tables present, joins and other properties of the universe then you can think of aliases.

The only real alternative to creating contexts is to create more than one universe. That's essentially what a context is, really, by identifying a set of joins that work together you are essentially subdividing a single universe into smaller sub-universes of tables that work together. You could separate them into different universes. 

Aliases are not substitutes for contexts, and vice versa. Once you have identified the problem, the solution choice is made for you.

So based on the thumb rule here are the best way of designing a universe is inserting one fact table at a time. 

1. Insert one fact table and related dimension tables to that fact table. 

2. Create all the joins. 

3. Check for loops. 

4. See if it can be resolved with an alias. 

5. Create context. Make sure a context doesn't have any loops 

6. Each join must present in atleast one context.