|Oracle® Database SQL Language Reference
11g Release 2 (11.2)
|PDF · Mobi · ePub|
VIEW statement to create a materialized view. A materialized view is a database object that contains the results of a query. The
FROM clause of the query can name tables, views, and other materialized views. Collectively these objects are called master tables (a replication term) or detail tables (a data warehousing term). This reference uses "master tables" for consistency. The databases containing the master tables are called the master databases.
SNAPSHOTis supported in place of
VIEWfor backward compatibility.
For replication purposes, materialized views allow you to maintain copies of remote data on your local node. The copies can be updatable with the Advanced Replication feature and are read-only without this feature. You can select data from a materialized view as you would from a table or view. In replication environments, the materialized views commonly created are primary key, rowid, object, and subquery materialized views.
See Also:Oracle Database Advanced Replication for information on the types of materialized views used to support replication
For data warehousing purposes, the materialized views commonly created are materialized aggregate views, single-table materialized aggregate views, and materialized join views. All three types of materialized views can be used by query rewrite, an optimization technique that transforms a user request written in terms of master tables into a semantically equivalent request that includes one or more materialized views.
The privileges required to create a materialized view should be granted directly rather than through a role.
To create a materialized view in your own schema:
You must have been granted the
VIEW system privilege and either the
TABLE system privilege.
You must also have access to any master tables of the materialized view that you do not own, either through a
SELECT object privilege on each of the tables or through the
TABLE system privilege.
To create a materialized view in another user's schema:
You must have the
VIEW system privilege.
The owner of the materialized view must have the
TABLE system privilege. The owner must also have access to any master tables of the materialized view that the schema owner does not own (for example, if the master tables are on a remote database) and to any materialized view logs defined on those master tables, either through a
SELECT object privilege on each of the tables or through the
TABLE system privilege.
To create a refresh-on-commit materialized view (
REFRESH clause), in addition to the preceding privileges, you must have the
REFRESH object privilege on any master tables that you do not own or you must have the
REFRESH system privilege.
To create the materialized view with query rewrite enabled, in addition to the preceding privileges:
If the schema owner does not own the master tables, then the schema owner must have the
REWRITE privilege or the
REWRITE object privilege on each table outside the schema.
If you are defining the materialized view on a prebuilt container (
TABLE clause), then you must have the
OPTION on the container table.
The user whose schema contains the materialized view must have sufficient quota in the target tablespace to store the master table and index of the materialized view or must have the
TABLESPACE system privilege.
When you create a materialized view, Oracle Database creates one internal table and at least one index, and may create one view, all in the schema of the materialized view. Oracle Database uses these objects to maintain the materialized view data. You must have the privileges necessary to create these objects.
You can create the following types of local materialized views (including both
DEMAND) on master tables with commit SCN-based materialized view logs:
Materialized aggregate views, including materialized aggregate views on a single table
Materialized join views
Primary-key-based and rowid-based single table materialized views
ALL materialized views, where each
ALL branch is one of the above materialized view types
You cannot create remote materialized views on master tables with commit SCN-based materialized view logs.
Creating a materialized view on master tables with different types of materialized view logs (that is, a master table with timestamp-based materialized view logs and a master table with commit SCN-based materialized view logs) is not supported and causes
Oracle Database Advanced Replication for information about the prerequisites that apply to creating replication materialized views
Oracle Database Data Warehousing Guide for information about the prerequisites that apply to creating data warehousing materialized views
(object_type_col_properties::=, nested_table_col_properties::=, varray_col_properties::=, LOB_partition_storage::=, LOB_storage_clause::=,
XMLType_column_properties: not supported for materialized views)
Specify the schema to contain the materialized view. If you omit
schema, then Oracle Database creates the materialized view in your schema.
Specify the name of the materialized view to be created. The name must satisfy the requirements listed in "Database Object Naming Rules". Oracle Database generates names for the table and indexes used to maintain the materialized view by adding a prefix or suffix to the materialized view name.
You can specify a column alias for each column of the materialized view. The column alias list explicitly resolves any column name conflict, eliminating the need to specify aliases in the
SELECT clause of the materialized view. If you specify any column alias in this clause, then you must specify an alias for each data source referenced in the
Use this clause to encrypt this column of the materialized view. Please refer to the
TABLE clause encryption_spec for more information on column encryption.
object_type clause lets you explicitly create an object materialized view of type
TABLE... object_table for more information on the
FOR clause to restrict the scope of references to a single object table. You can refer either to the table name with
scope_table_name or to a column alias. The values in the
REF column or attribute point to objects in
c_alias, in which object instances of the same type as the
REF column are stored. If you specify aliases, then they must have a one-to-one correspondence with the columns in the
SELECT list of the defining query of the materialized view.
See Also:"SCOPE REF Constraints" for more information
TABLE clause lets you register an existing table as a preinitialized materialized view. This clause is particularly useful for registering large materialized views in a data warehousing environment. The table must have the same name and be in the same schema as the resulting materialized view.
If the materialized view is dropped, then the preexisting table reverts to its identity as a table.
Caution:This clause assumes that the table object reflects the materialization of a subquery. Oracle strongly recommends that you ensure that this assumption is true in order to ensure that the materialized view correctly reflects the data in its master tables.
TABLE clause could be useful in the following scenarios:
You have a table representing the result of a query. Creating the table was an expensive operation that possibly took a long time. You want to create a materialized view on the query. You can use the
TABLE clause to avoid the expense of executing the query and populating the container for the materialized view.
You temporarily discontinue having a materialized view, but keep its container table, using the
TABLE statement. You then decide to recreate the materialized view and you know that the master tables of the view have not changed. You can create the materialized view using the
TABLE clause. This avoids the expense and time of creating and populating the container table for the materialized view.
WITH REDUCED PRECISION Specify
PRECISION to authorize the loss of precision that will result if the precision of the table or materialized view columns do not exactly match the precision returned by
WITHOUT REDUCED PRECISION Specify
PRECISION to require that the precision of the table or materialized view columns match exactly the precision returned by
subquery, or the create operation will fail. This is the default.
Each column alias in
subquery must correspond to a column in the prebuilt table, and corresponding columns must have matching data types.
If you specify this clause, then you cannot specify a
NULL constraint for any column that is not referenced in
subquery unless you also specify a default value for that column.
The components of the
physical_properties_clause have the same semantics for materialized views that they have for tables, with exceptions and additions described in the sections that follow.
Use this clause to determine when the segment for this materialized view should be created. See the
TABLE clause deferred_segment_creation for more information.
segment_attributes_clause to establish values for the
INITRANS parameters, the storage characteristics for the materialized view, to assign a tablespace, and to specify whether logging is to occur. In the
INDEX clause, you cannot specify
TABLESPACE Clause Specify the tablespace in which the materialized view is to be created. If you omit this clause, then Oracle Database creates the materialized view in the default tablespace of the schema containing the materialized view.
See Also:physical_attributes_clause and storage_clause for a complete description of these clauses, including default values
NOLOGGING to establish the logging characteristics for the materialized view. The logging characteristic affects the creation of the materialized view and any nonatomic refresh that is initiated by way of the
DBMS_REFRESH package. The default is the logging characteristic of the tablespace in which the materialized view resides.
See Also:logging_clause for a full description of this clause and Oracle Database PL/SQL Packages and Types Reference for more information on atomic and nonatomic refresh
table_compression clause to instruct the database whether to compress data segments to reduce disk and memory use.
See Also:Refer to the
TABLEtable_compression for the full semantics of this clause
INDEX clause lets you create an index-organized materialized view. In such a materialized view, data rows are stored in an index defined on the primary key of the materialized view. You can specify index organization for the following types of materialized views:
Read-only and updatable object materialized views. You must ensure that the master table has a primary key.
Read-only and updatable primary key materialized views.
Read-only rowid materialized views.
The keywords and parameters of the
index_org_table_clause have the same semantics as described in
TABLE, with the restrictions that follow.
See Also:The index_org_table_clause of
You cannot specify the following
You cannot specify the
You can specify
COMPRESS only for a materialized view based on a composite primary key. You can specify
NOCOMPRESS for a materialized view based on either a simple or composite primary key.
CLUSTER clause lets you create the materialized view as part of the specified cluster. A cluster materialized view uses the space allocation of the cluster. Therefore, you do not specify physical attributes or the
TABLESPACE clause with the
Use these property clauses to describe a materialized view that is not based on an existing table. To create a materialized view that is based on an existing table, use the
column_properties clause lets you specify the storage characteristics of a LOB, nested table, varray, or
XMLType column. The
object_type_col_properties are not relevant for a materialized view.
See Also:CREATE TABLE for detailed information about specifying the parameters of this clause
table_partitioning_clauses let you specify that the materialized view is partitioned on specified ranges of values or on a hash function. Partitioning of materialized views is the same as partitioning of tables.
See Also:table_partitioning_clauses in the
For data that will be accessed frequently,
CACHE specifies that the blocks retrieved for this table are placed at the most recently used end of the least recently used (LRU) list in the buffer cache when a full table scan is performed. This attribute is useful for small lookup tables.
NOCACHE specifies that the blocks are placed at the least recently used end of the LRU list.
NOCACHEhas no effect on materialized views for which you specify
See Also:CREATE TABLE for information about specifying
parallel_clause lets you indicate whether parallel operations will be supported for the materialized view and sets the default degree of parallelism for queries and DML on the materialized view after creation.
For complete information on this clause, refer to parallel_clause in the documentation on
build_clause lets you specify when to populate the materialized view.
DEFERRED to indicate that the materialized view is to be populated by the next
REFRESH operation. The first (deferred) refresh must always be a complete refresh. Until then, the materialized view has a staleness value of
UNUSABLE, so it cannot be used for query rewrite.
INDEX clause lets you establish the value of the
STORAGE parameters for the default index Oracle Database uses to maintain the materialized view data. If
INDEX is not specified, then default values are used for the index. Oracle Database uses the default index to speed up incremental (
FAST) refresh of the materialized view.
INDEX to suppress the creation of the default index. You can create an alternative index explicitly by using the
INDEX statement. You should create such an index if you specify
INDEX and you are creating the materialized view with the incremental refresh method (
create_mv_refresh clause to specify the default methods, modes, and times for the database to refresh the materialized view. If the master tables of a materialized view are modified, then the data in the materialized view must be updated to make the materialized view accurately reflect the data currently in its master tables. This clause lets you schedule the times and specify the method and mode for the database to refresh the materialized view.
Note:This clause only sets the default refresh options. For instructions on actually implementing the refresh, refer to Oracle Database Advanced Replication and Oracle Database Data Warehousing Guide.
Oracle Database PL/SQL Packages and Types Reference for more information on refresh methods
FAST to indicate the incremental refresh method, which performs the refresh according to the changes that have occurred to the master tables. The changes for conventional DML changes are stored in the materialized view log associated with the master table. The changes for direct-path
INSERT operations are stored in the direct loader log.
If you specify
FAST, then the
CREATE statement will fail unless materialized view logs already exist for the materialized view master tables. Oracle Database creates the direct loader log automatically when a direct-path
INSERT takes place. No user intervention is needed.
For both conventional DML changes and for direct-path
INSERT operations, other conditions may restrict the eligibility of a materialized view for fast refresh.
Materialized views are not eligible for fast refresh if the defining query contains an analytic function.
Oracle Database Advanced Replication for restrictions on fast refresh in replication environments
Oracle Database Data Warehousing Guide for restrictions on fast refresh in data warehousing environments
COMPLETE to indicate the complete refresh method, which is implemented by executing the defining query of the materialized view. If you request a complete refresh, then Oracle Database performs a complete refresh even if a fast refresh is possible.
FORCE to indicate that when a refresh occurs, Oracle Database will perform a fast refresh if one is possible or a complete refresh if fast refresh is not possible. If you do not specify a refresh method (
FORCE is the default.
COMMIT to indicate that a fast refresh is to occur whenever the database commits a transaction that operates on a master table of the materialized view. This clause may increase the time taken to complete the commit, because the database performs the refresh operation as part of the commit process.
You cannot specify both
DEMAND. If you specify
COMMIT, then you cannot also specify
This clause is not supported for materialized views containing object types or Oracle-supplied types.
This clause is not supported for materialized views with remote tables.
If you specify this clause, then you cannot subsequently execute a distributed transaction on any master table of this materialized view. For example, you cannot insert into the master by selecting from a remote table. The
DEMAND clause does not impose this restriction on subsequent distributed transactions on master tables.
DEMAND to indicate that database will not refresh the materialized view unless the user manually launches a refresh through one of the three
DBMS_MVIEW refresh procedures.
You cannot specify both
DEMAND. If you omit both
DEMAND is the default. You can override this default setting by specifying the
NEXT clauses, either in the same
VIEW statement or a subsequent
NEXT take precedence over
DEMAND. Therefore, in most circumstances it is not meaningful to specify
DEMAND when you have specified
Oracle Database PL/SQL Packages and Types Reference for information on these procedures
Oracle Database Data Warehousing Guide on the types of materialized views you can create by specifying
Specify a datetime expression for the first automatic refresh time.
Specify a datetime expression for calculating the interval between automatic refreshes.
NEXT values must evaluate to a time in the future. If you omit the
WITH value, then the database determines the first automatic refresh time by evaluating the
NEXT expression with respect to the creation time of the materialized view. If you specify a
WITH value but omit the
NEXT value, then the database refreshes the materialized view only once. If you omit both the
NEXT values, or if you omit the
create_mv_refresh entirely, then the database does not automatically refresh the materialized view.
KEY to create a primary key materialized view. This is the default and should be used in all cases except those described for
ROWID. Primary key materialized views allow materialized view master tables to be reorganized without affecting the eligibility of the materialized view for fast refresh. The master table must contain an enabled primary key constraint, and the defining query of the materialized view must specify all of the primary key columns directly. In the defining query, the primary key columns cannot be specified as the argument to a function such as
See Also:Oracle Database Advanced Replication for detailed information about primary key materialized views and "Creating Primary Key Materialized Views: Example"
ROWID to create a rowid materialized view. Rowid materialized views are useful if the materialized view does not include all primary key columns of the master tables. Rowid materialized views must be based on a single table and cannot contain any of the following:
Distinct or aggregate functions
ROWID clause has no effect if there are multiple master tables in the defining query.
Rowid materialized views are not eligible for fast refresh after a master table reorganization until a complete refresh has been performed.
See Also:"Creating Materialized Aggregate Views: Example" and "Creating Rowid Materialized Views: Example"
This clause is not valid if your database is in automatic undo mode, because in that mode Oracle Database uses undo tablespaces instead of rollback segments. Oracle strongly recommends that you use automatic undo mode. This clause is supported for backward compatibility with replication environments containing older versions of Oracle Database that still use rollback segments.
rollback_segment, specify the remote rollback segment to be used during materialized view refresh.
DEFAULT specifies that Oracle Database will choose automatically which rollback segment to use. If you specify
DEFAULT, then you cannot specify
DEFAULT is most useful when modifying, rather than creating, a materialized view.
See Also:ALTER MATERIALIZED VIEW
See Also:Oracle Database Advanced Replication for information on specifying the local materialized view rollback segment using the
If you omit
rollback_segment, then the database automatically chooses the rollback segment to be used. One master rollback segment is stored for each materialized view and is validated during materialized view creation and refresh. If the materialized view is complex, then the database ignores any master rollback segment you specify.
CONSTRAINTS clause lets Oracle Database choose more rewrite options during the refresh operation, resulting in more efficient refresh execution. The clause lets Oracle Database use unenforced constraints, such as dimension relationships or constraints in the
RELY state, rather than relying only on enforced constraints during the refresh operation.
CONSTRAINTS clause enables you to create a materialized view on top of a table that has a non-NULL Virtual Private Database (VPD) policy on it. In this case, ensure that the materialized view behaves correctly. Materialized view results are computed based on the rows and columns filtered by VPD policy. Therefore, you must coordinate the materialized view definition with the VPD policy to ensure the correct results. Without the
CONSTRAINTS clause, any VPD policy on a master table will prevent a materialized view from being created.
CONSTRAINTSclause lets Oracle Database use dimension and constraint information that has been declared trustworthy by the database administrator but that has not been validated by the database. If the dimension and constraint information is valid, then performance may improve. However, if this information is invalid, then the refresh procedure may corrupt the materialized view even though it returns a success status.
If you omit this clause, then the default is
REFRESH to prevent the materialized view from being refreshed with any Oracle Database refresh mechanism or packaged procedure. Oracle Database will ignore any
REFRESH statement on the materialized view issued from such a procedure. To reverse this clause, you must issue an
UPDATE to allow a subquery, primary key, object, or rowid materialized view to be updated. When used in conjunction with Advanced Replication, these updates will be propagated to the master.
REWRITE clause lets you specify whether the materialized view is eligible to be used for query rewrite.
You can enable query rewrite only if all user-defined functions in the materialized view are
You can enable query rewrite only if expressions in the statement are repeatable. For example, you cannot include
USER, sequence values (such as the
NEXTVAL pseudocolumns), or the
SAMPLE clause (which may sample different rows as the contents of the materialized view change).
Query rewrite is disabled by default, so you must specify this clause to make materialized views eligible for query rewrite.
After you create the materialized view, you must collect statistics on it using the
DBMS_STATS package. Oracle Database needs the statistics generated by this package to optimize query rewrite.
Oracle Database Data Warehousing Guide for more information on query rewrite
Oracle Database PL/SQL Packages and Types Reference for information about the
Specify the defining query of the materialized view. When you create the materialized view, Oracle Database executes this subquery and places the results in the materialized view. This subquery is any valid SQL subquery. However, not all subqueries are fast refreshable, nor are all subqueries eligible for query rewrite.
Oracle Database does not execute the defining query immediately if you specify
Oracle recommends that you qualify each table and view in the
FROM clause of the defining query of the materialized view with the schema containing it.
The defining query of a materialized view can select from tables, views, or materialized views owned by the user
SYS, but you cannot enable
REWRITE on such a materialized view.
You cannot define a materialized view with a subquery in the select list of the defining query. You can, however, include subqueries elsewhere in the defining query, such as in the
You cannot use the
OF clause of the
flashback_query_clause in the defining query of a materialized view.
Materialized join views and materialized aggregate views with a
BY clause cannot select from an index-organized table.
Materialized views cannot contain columns of data type
Materialized views cannot contain virtual columns.
You cannot create a materialized view log on a temporary table. Therefore, if the defining query references a temporary table, then this materialized view will not be eligible for
FAST refresh, nor can you specify the
REWRITE clause in this statement.
FROM clause of the defining query references another materialized view, then you must always refresh the materialized view referenced in the defining query before refreshing the materialized view you are creating in this statement.
Materialized views with join expressions in the defining query cannot have XML data type columns. The XML data types include
XMLType and URI data type columns.
If you are creating a materialized view enabled for query rewrite, then:
The defining query cannot contain, either directly or through a view, references to
SYSDATE, remote tables, sequences, or PL/SQL functions that write or read database or package state.
Neither the materialized view nor the master tables of the materialized view can be remote.
If you want the materialized view to be eligible for fast refresh using a materialized view log, then some additional restrictions may apply.
Oracle Database Data Warehousing Guide for more information on restrictions relating to data warehousing
Oracle Database Advanced Replication for more information on restrictions relating to replication
The following examples require the materialized logs that are created in the "Examples" section of CREATE MATERIALIZED VIEW LOG.
CREATE MATERIALIZED VIEW mv1 AS SELECT * FROM hr.employees;
By default, Oracle Database creates a primary key materialized view with refresh on demand only. If a materialized view log exists on
mv1 can be altered to be capable of fast refresh. If no such log exists, then only full refresh of
mv1 is possible. Oracle Database uses default storage properties for
mv1. The only privileges required for this operation are the
VIEW system privilege, and the
SELECT object privilege on hr.employees.
CREATE MATERIALIZED VIEW foreign_customers FOR UPDATE AS SELECT * FROM sh.customers@remote cu WHERE EXISTS (SELECT * FROM sh.countries@remote co WHERE co.country_id = cu.country_id);
Creating Materialized Aggregate Views: Example The following statement creates and populates a materialized aggregate view on the sample
sh.sales table and specifies the default refresh method, mode, and time. It uses the materialized view log created in "Creating a Materialized View Log: Examples", as well as the two additional logs shown here:
CREATE MATERIALIZED VIEW LOG ON times WITH ROWID, SEQUENCE (time_id, calendar_year) INCLUDING NEW VALUES; CREATE MATERIALIZED VIEW LOG ON products WITH ROWID, SEQUENCE (prod_id) INCLUDING NEW VALUES; CREATE MATERIALIZED VIEW sales_mv BUILD IMMEDIATE REFRESH FAST ON COMMIT AS SELECT t.calendar_year, p.prod_id, SUM(s.amount_sold) AS sum_sales FROM times t, products p, sales s WHERE t.time_id = s.time_id AND p.prod_id = s.prod_id GROUP BY t.calendar_year, p.prod_id;
Creating Materialized Join Views: Example The following statement creates and populates the materialized aggregate view
sales_by_month_by_state using tables in the sample
sh schema. The materialized view will be populated with data as soon as the statement executes successfully. By default, subsequent refreshes will be accomplished by reexecuting the defining query of the materialized view:
CREATE MATERIALIZED VIEW sales_by_month_by_state TABLESPACE example PARALLEL 4 BUILD IMMEDIATE REFRESH COMPLETE ENABLE QUERY REWRITE AS SELECT t.calendar_month_desc, c.cust_state_province, SUM(s.amount_sold) AS sum_sales FROM times t, sales s, customers c WHERE s.time_id = t.time_id AND s.cust_id = c.cust_id GROUP BY t.calendar_month_desc, c.cust_state_province;
CREATE TABLE sales_sum_table (month VARCHAR2(8), state VARCHAR2(40), sales NUMBER(10,2)); CREATE MATERIALIZED VIEW sales_sum_table ON PREBUILT TABLE WITH REDUCED PRECISION ENABLE QUERY REWRITE AS SELECT t.calendar_month_desc AS month, c.cust_state_province AS state, SUM(s.amount_sold) AS sales FROM times t, customers c, sales s WHERE s.time_id = t.time_id AND s.cust_id = c.cust_id GROUP BY t.calendar_month_desc, c.cust_state_province;
In the preceding example, the materialized view has the same name and also has the same number of columns with the same data types as the prebuilt table. The
PRECISION clause allows for differences between the precision of the materialized view columns and the precision of the values returned by the subquery.
CREATE MATERIALIZED VIEW catalog REFRESH FAST START WITH SYSDATE NEXT SYSDATE + 1/4096 WITH PRIMARY KEY AS SELECT * FROM product_information;
CREATE MATERIALIZED VIEW order_data REFRESH WITH ROWID AS SELECT * FROM orders;
CREATE MATERIALIZED VIEW LOG ON employees WITH PRIMARY KEY INCLUDING NEW VALUES; CREATE MATERIALIZED VIEW emp_data PCTFREE 5 PCTUSED 60 TABLESPACE example STORAGE (INITIAL 50K) REFRESH FAST NEXT sysdate + 7 AS SELECT * FROM employees;
The preceding statement does not include a
WITH parameter, so Oracle Database determines the first automatic refresh time by evaluating the
NEXT value using the current
SYSDATE. A materialized view log was created for the employee table, so Oracle Database performs a fast refresh of the materialized view every 7 days, beginning 7 days after the materialized view is created.
Because the materialized view conforms to the conditions for fast refresh, the database will perform a fast refresh. The preceding statement also establishes storage characteristics that the database uses to maintain the materialized view.
CREATE MATERIALIZED VIEW all_customers PCTFREE 5 PCTUSED 60 TABLESPACE example STORAGE (INITIAL 50K) USING INDEX STORAGE (INITIAL 25K) REFRESH START WITH ROUND(SYSDATE + 1) + 11/24 NEXT NEXT_DAY(TRUNC(SYSDATE), 'MONDAY') + 15/24 AS SELECT * FROM sh.customers@remote UNION SELECT * FROM sh.customers@local;
Oracle Database automatically refreshes this materialized view tomorrow at 11:00 a.m. and subsequently every Monday at 3:00 p.m. The default refresh method is
FORCE. The defining query contains a
UNION operator, which is not supported for fast refresh, so the database will automatically perform a complete refresh.
The preceding statement also establishes storage characteristics for both the materialized view and the index that the database uses to maintain it:
STORAGE clause establishes the sizes of the first and second extents of the materialized view as 50 kilobytes each.
STORAGE clause, appearing with the
INDEX clause, establishes the sizes of the first and second extents of the index as 25 kilobytes each.
Creating a Fast Refreshable Materialized View: Example The following statement creates a fast-refreshable materialized view that selects columns from the
order_items table in the sample
oe schema, using the
UNION set operator to restrict the rows returned from the
inventories tables using
WHERE conditions. The materialized view logs for
product_information were created in the "Examples" section of
LOG. This example also requires a materialized view log on
CREATE MATERIALIZED VIEW LOG ON inventories WITH (quantity_on_hand); CREATE MATERIALIZED VIEW warranty_orders REFRESH FAST AS SELECT order_id, line_item_id, product_id FROM order_items o WHERE EXISTS (SELECT * FROM inventories i WHERE o.product_id = i.product_id AND i.quantity_on_hand IS NOT NULL) UNION SELECT order_id, line_item_id, product_id FROM order_items WHERE quantity > 5;
The materialized view
warranty_orders requires that materialized view logs be defined on
product_id as a join column) and on inventories (with
quantity_on_hand as a filter column). See "Specifying Filter Columns for Materialized View Logs: Example" and "Specifying Join Columns for Materialized View Logs: Example".
Creating a Nested Materialized View: Example The following example uses the materialized view from the preceding example as a master table to create a materialized view tailored for a particular sales representative in the sample
CREATE MATERIALIZED VIEW my_warranty_orders AS SELECT w.order_id, w.line_item_id, o.order_date FROM warranty_orders w, orders o WHERE o.order_id = o.order_id AND o.sales_rep_id = 165;