Well the question is a little trickier than I made out, it's the 2nd part and it's asking me to implement location transparency on a number of queries I have just come up with and give justification for my choice. But I would just use views on the lot of them and I don't know why I would do that. It's possible to use synonyms on them as well.
As already stated views are typically used to display subsets of data or data from multiple tables using joins, to reduce the complexity of a common the search query.
Another benefit of views is that you can modify the query the view calls. This can be beneficial from an application development point of view. You can specify a query within the application as :
select * from a_view;
Regardless of what "a_view" does as long as "a_view" exists the application will work. In generation 1 of a_view it might be something like
select name, age, address from person;
in generation 2 of "a_view" it might be
select hight, width, depth from object_dimensions;
The view user_tables is such an instance. user_tables shows a selection of data from various system tables that users might require to see, without having the painful task of having to construct a multi-table join.
Views are owned by their creator (or a designated schema by the creator schema)
Synonyms are used to simplify the addressing of a database object by removing the requirement to specify the schema owner as a prefix of the table name (ie sys.dba_tables can be referred to as dba_tables when the correct synonym is in place) Additionally synonyms can be used to alias a database object (ie user_tables could be aliased as my_tables or bob using a synonym)
As a View is owned by a particular schema, it may be necessary to create a synonym of that view so that all users can address the view in a uniform way (ie select * from multi_table_view;
rather than
select * from davestar_delux.multi_table_view;
Synonyms are most useful when there are many users using their own Schemas and creating their own objects that might be beneficial to users using different schemas.
You could create a bunch of tables and then give them public synonyms so all users with permissions on the tables can view them without needing to know the schema owner. You could then create a view using these synonyms. and then use a synonym to simplify the name of the view.
Going further you could make a second generation of one of the tables used in a view (for what ever reason you need a new version of the table but also need the older version) and you could then drop the synonym used by the view to access that table and recreate it using the new table.
And I was going to write a simple 3 line answer.
