View Materialized or Snapshot

[Deathão]

Good morning guys, I have some questions about materialized view or snapshots ....
Next, when trying to create a materialized view or a snapshot using a query, only there is a problem that it does not Accepts when a query contains sub-queries inside, does anyone know the reason this ???

I think it's kind of absurd not to accept this kind of query ..

If someone has already encountered it, please give a tip here ...
PS: To solve my problem, I had to create an PL / SQL procedure that does the same as a materialized view, I created a table with the fields of my view, and I gave the load In this table, it is kind of "gambiarra" this, if someone has a better idea to warn me and please, thank you ..

[dr_gori]

For it is ...
there are a series of restrictions for the use of materialized views.
This link has several examples about this (in English) http://www.lc.leidenuniv.nl/awcourse/or ... .htm#28373
I will cite some:

Select all

Restrictions for Materialized Views with Subqueries 
 
The defining query of a materialized view with a subquery is subject to several restrictions to preserve the materialized view's fast refresh capability. 
 
The following are restrictions for fast refresh materialized views with subqueries: 
 
    * Materialized views must be primary key materialized views. 
    * The master's materialized view log must include certain columns referenced in the subquery. For information about which columns must be included, see "Logging Columns in the Materialized View Log". 
    * If the subquery is many to many or one to many, join columns that are not part of a primary key must be included in the materialized view log of the master. This restriction does not apply to many to one subqueries. 
    * The subquery must be a positive subquery. For example, you can use EXISTS, but not NOT EXISTS. 
    * The subquery must use EXISTS to connect each nested level (IN is not allowed). 
    * Each table can be in only one EXISTS expression. 
    * The join expression must use exact match or equality comparisons (that is, equi-joins). 
    * Each table can be joined only once within the subquery. 
    * A primary key must exist for each table at each nested level. 
    * Each nested level can only reference the table in the level above it. 
    * Subqueries can include AND operators, but each OR operator may only reference columns contained within one row. Multiple OR operators within a subquery can be connected with an AND operator. 
    * All tables referenced in a subquery must reside in the same master site or master materialized view site.