Fuctioning of Views Relationship? I am trying to understand the Views relationship. As I am searching the tutorials, it all described, "When you want to include data which is not directly available Views relationship lets you include that data through the common connector(joint)." Now in theory it is very straight there is a some connector which does provide the data, but How to get visualize this thing in the Views User Interface. 

Let me put this way for the ease of visualization and understanding, Lets say, there is A, C and B in the following image, where C is a connector, A is data available and B is the data which is not directly available. So how can I find the A, B and C looking at Views User Interface, Hence I can Put All this three on the paper and put the logic.



Why I am putting this way, because after observing too much, I realize that why people have difficulty in understanding the views Relationship is that, what comes from  where are not so clear, hence people gets confuse which content comes from  where and how they connect each other and which one is actually not accessible. If this gets clear, the understanding of Views Relationship will be much simpler.
First understand entities, attributes, bundles and fields:

Node and User are entities. Both have a unique identifier. For Node it is nid, for User it is uid. Entities have attributes associated with them. These are the fields that you will see in the Node or Users table in the database. For instance, Node has author, data published etc, and User has name, mail etc.

Between the attributes of entities there are links, for instance: Node has an author, which is just the uid key of the User entity. In other words via a SQL join you can get from the one to the other. This is what Views do when you add a user relationship on the node view to bring in the extra information of the user table.

 

Bundles have fields. A bundle is an entity type with additional fields attached. For instance, Article is a bundle of entity type node. Article has all the attributes of Node, and it also has an image field. If you look at the Node table there is no image field on it. The image field is created as its own table,   field_data_field_image. In this table there is a field entity_id which contains the nid of the node it belongs to.

When you add a field that is not part of the node entity (node table) but part of the bundle (ie Article) to Views, Views will do a SQL join to get that field 
into the display. Therefore Views is bringing in a relationship for you, nl. the relationship between the entity and the field.



When you install Entity reference you can add a field to an entity that will reference another entity. For instance, you add an entity reference field to an Article that can reference Basic Pages. 

In the database you have now added a new field as a separate table which points to the node, of type article, as its parent container, as well as to the node of type Basic Page as the referenced node. It looks like this:



To add it to Views you need to include the relationship manually as an Entity Reference. There will be two possibilities:


Entity Reference: Referenced Entity - A bridge to the Content entity
that is referenced via field_reference
Entity Reference: Referencing entity - A bridge to the Content entity
that is referencing Content via field_reference


which is just the direction of the relationship. If I have the article in my View and I want to include the Basic Page, then it will be Referenced Entity. If I have the Basic Page and I want the Article, then it will be Referencing entity.

Views will bring in this relationship via two joins, the first to bring in the field belonging to the Article, and the second to bring in the Basic Page node that is pointed to by the entity reference field (the order depending on the direction)

NOTE that you can bring in even more relationships in a chain-like fashion. You may have a node whose author user has an entity reference to a profile type node that has a Taxonomy Tag etc.