3
Materialized View Concepts and Architecture

This chapter explains the concepts and architecture of Oracle materialized views. This chapter contains these topics:

• Materialized View Concepts
• Materialized View Architecture

Materialized View Concepts

Oracle uses materialized views (also known as snapshots in prior releases) to replicate data to non-master sites in a replication environment and to cache expensive queries in a data warehouse environment. This chapter, and this Oracle9i Replication manual in general, discusses materialized views for use in a replication environment.

What is a Materialized View?

A materialized view is a replica of a target master from a single point in time. The master can be either a master table at a master site or a master materialized view at a materialized view site. Whereas in multimaster replication tables are continuously updated by other master sites, materialized views are updated from one or more masters through individual batch updates, known as a refreshes, from a single master site or master materialized view site, as illustrated in Figure 3-1. The arrows in Figure 3-1 represent database links.

Figure 3-1 Materialized View Connected to a Single Master Site

Text description of the illustration rep81072.gif

When a materialized view is fast refreshed, Oracle must examine all of the changes to the master table or master materialized view since the last refresh to see if any apply to the materialized view. Therefore, if any changes where made to the master since the last refresh, then a materialized view refresh takes some time to apply the changes to the materialized view. If, however, no changes at all were made to the master since the last refresh of a materialized view, then the materialized view refresh should be very quick.

Why Use Materialized Views?

You can use materialized views to achieve one or more of the following goals:

• Ease Network Loads
• Create a Mass Deployment Environment
• Enable Data Subsetting
• Enable Disconnected Computing

Ease Network Loads

If one of your goals is to reduce network loads, then you can use materialized views to distribute your corporate database to regional sites. Instead of the entire company accessing a single database server, user load is distributed across multiple database servers. Through the use of multitier materialized views, you can create materialized views based on other materialized views, which enables you to distribute user load to an even greater extent because clients can access materialized view sites instead of master sites. To decrease the amount of data that is replicated, a materialized view can be a subset of a master table or master materialized view.

While multimaster replication also distributes a corporate database among multiple sites, the networking requirements for multimaster replication are greater than those for replicating with materialized views because of the transaction by transaction nature of multimaster replication. Further, the ability of multimaster replication to provide real-time or near real-time replication may result in greater network traffic, and might require a dedicated network link.

Materialized views are updated through an efficient batch process from a single master site or master materialized view site. They have lower network requirements and dependencies than multimaster replication because of the point in time nature of materialized view replication. Whereas multimaster replication requires constant communication over the network, materialized view replication requires only periodic refreshes.

In addition to not requiring a dedicated network connection, replicating data with materialized views increases data availability by providing local access to the target data. These benefits, combined with mass deployment and data subsetting (both of which also reduce network loads), greatly enhance the performance and reliability of your replicated database.

Create a Mass Deployment Environment

Deployment templates allow you to precreate a materialized view environment locally. You can then use deployment templates to quickly and easily deploy materialized view environments to support sales force automation and other mass deployment environments. Parameters allow you to create custom data sets for individual users without changing the deployment template. This technology enables you to roll out a database infrastructure to hundreds or thousands of users.

Enable Data Subsetting

Materialized views allow you to replicate data based on column- and row-level subsetting, while multimaster replication requires replication of the entire table. Data subsetting enables you to replicate information that pertains only to a particular site. For example, if you have a regional sales office, then you might replicate only the data that is needed in that region, thereby cutting down on unnecessary network traffic.

Enable Disconnected Computing

Materialized views do not require a dedicated network connection. Though you have the option of automating the refresh process by scheduling a job, you can manually refresh your materialized view on-demand, which is an ideal solution for sales applications running on a laptop. For example, a developer can integrate the replication management API for refresh on-demand into the sales application. When the salesperson has completed the day's orders, the salesperson simply dials up the network and uses the integrated mechanism to refresh the database, thus transferring the orders to the main office.

Read-Only, Updatable, and Writeable Materialized Views

A materialized view can be either read-only, updatable, or writeable. Users cannot perform data manipulation language (DML) statements on read-only materialized views, but they can perform DML on updatable and writeable materialized views.

Read-Only Materialized Views

You can make a materialized view read-only during creation by omitting the FOR UPDATE clause or disabling the equivalent option in the Replication Management tool. Read-only materialized views use many of the same mechanisms as updatable materialized views, except that they do not need to belong to a materialized view group.

In addition, using read-only materialized views eliminates the possibility of a materialized view introducing data conflicts at the master site or master materialized view site, although this convenience means that updates cannot be made at the remote materialized view site. The following is an example of a read-only materialized view:

CREATE MATERIALIZED VIEW hr.employees AS
  SELECT * FROM hr.employees@orc1.world;

Updatable Materialized Views

You can make a materialized view updatable during creation by including the FOR UPDATE clause or enabling the equivalent option in the Replication Management tool. For changes made to an updatable materialized view to be pushed back to the master during refresh, the updatable materialized view must belong to a materialized view group.

Updatable materialized views enable you to decrease the load on master sites because users can make changes to the data at the materialized view site. The following is an example of an updatable materialized view:

CREATE MATERIALIZED VIEW hr.departments FOR UPDATE AS
  SELECT * FROM hr.departments@orc1.world;

The following statement creates a materialized view group:

BEGIN
   DBMS_REPCAT.CREATE_MVIEW_REPGROUP (
      gname => 'hr_repg',
      master => 'orc1.world',
      propagation_mode => 'ASYNCHRONOUS');
END;
/

The following statement adds the hr.departments materialized view to the materialized view group, making the materialized view updatable:

BEGIN
   DBMS_REPCAT.CREATE_MVIEW_REPOBJECT (
      gname => 'hr_repg',
      sname => 'hr',
      oname => 'departments',
      type => 'SNAPSHOT',
      min_communication => TRUE);
END;

/

You can also use the Replication Management tool to create a materialized view group and add a materialized view to it.

Writeable Materialized Views

A writeable materialized view is one that is created using the FOR UPDATE clause but is not part of a materialized view group. Users can perform DML operations on a writeable materialized view, but if you refresh the materialized view, then these changes are not pushed back to the master and the changes are lost in the materialized view itself. Writeable materialized views are typically allowed wherever fast-refreshable read-only materialized views are allowed.

Available Materialized Views

Oracle offers several types of materialized views to meet the needs of many different replication (and non-replication) situations. The following sections describe each type of materialized view and also describe some environments for which they are best suited.

The following sections contain examples of creating different types of materialized views:

• Primary Key Materialized Views
• Object Materialized Views
• ROWID Materialized Views
• Complex Materialized Views

Whenever you create a materialized view, regardless of its type, always specify the schema name of the table owner in the query for the materialized view. For example, consider the following CREATE MATERIALIZED VIEW statement:

CREATE MATERIALIZED VIEW hr.employees
  AS SELECT * FROM hr.employees@orc1.world;

Here, the schema hr is specified in the query.

Primary Key Materialized Views

Primary key materialized views are the default type of materialized view. They are updatable if the materialized view was created as part of a materialized view group and FOR UPDATE was specified when defining the materialized view. An updatable materialized view must belong to a materialized view group that has the same name as the replication group at its master site or master materialized view site. In addition, an updatable materialized view must reside in a different database than the master replication group.

Changes are propagated according to the row-level changes that have occurred, as identified by the primary key value of the row (not the ROWID). The following is an example of a SQL statement for creating an updatable, primary key materialized view:

CREATE MATERIALIZED VIEW oe.customers FOR UPDATE AS
  SELECT * FROM oe.customers@orc1.world;

Primary key materialized views may contain a subquery so that you can create a subset of rows at the remote materialized view site. A subquery is a query imbedded within the primary query, so that you have more than one SELECT statement in the CREATE MATERIALIZED VIEW statement. This subquery may be as simple as a basic WHERE clause or as complex as a multilevel WHERE EXISTS clause. Primary key materialized views that contain a selected class of subqueries can still be incrementally (or fast) refreshed, if each master referenced has a materialized view log. A fast refresh uses materialized view logs to update only the rows that have changed since the last refresh.

The following materialized view is created with a WHERE clause containing a subquery:

CREATE MATERIALIZED VIEW oe.orders REFRESH FAST AS
 SELECT * FROM oe.orders@orc1.world o
 WHERE EXISTS
   (SELECT * FROM oe.customers@orc1.world c
    WHERE o.customer_id = c.customer_id AND c.credit_limit > 10000);

This type of materialized view is called a subquery materialized view.

Object Materialized Views

If a materialized view is based on an object table and is created using the OF type clause, then the materialized view is called an object materialized view. An object materialized view is structured in the same way as an object table. That is, an object materialized view is composed of row objects, and each row object is identified by an object identifier (OID) column.

ROWID Materialized Views

For backward compatibility, Oracle supports ROWID materialized views in addition to the default primary key materialized views. A ROWID materialized view is based on the physical row identifiers (rowids) of the rows in a master. ROWID materialized views should be used only for materialized views based on master tables from an Oracle7 database, and should not be used when creating new materialized views based on masters from Oracle8 or higher databases.

The following is an example of a CREATE MATERIALIZED VIEW statement that creates a ROWID materialized view:

CREATE MATERIALIZED VIEW oe.orders REFRESH WITH ROWID AS
 SELECT * FROM oe.orders@orc1.world;

Complex Materialized Views

To be fast refreshed, the defining query for a materialized view must observe certain restrictions. If you require a materialized view whose defining query is more general and cannot observe the restrictions, then the materialized view is complex and cannot be fast refreshed.

Specifically, a materialized view is considered complex when the defining query of the materialized view contains:

• A CONNECT BY clause

  For example, the following statement creates a complex materialized view:

  CREATE MATERIALIZED VIEW hr.emp_hierarchy AS
    SELECT LPAD(' ', 4*(LEVEL-1))||email USERNAME 
      FROM hr.employees@orc1.world START WITH manager_id IS NULL 
      CONNECT BY PRIOR employee_id = manager_id;
  
  

• An INTERSECT, MINUS, or UNION ALL set operation

  For example, the following statement creates a complex materialized view because it has a UNION ALL set operation:

  CREATE MATERIALIZED VIEW hr.mview_employees AS
    SELECT employees.employee_id, employees.email 
    FROM hr.employees@orc1.world
  UNION ALL
    SELECT new_employees.employee_id, new_employees.email 
    FROM hr.new_employees@orc1.world;
  
  

• In some cases, the DISTINCT or UNIQUE keyword, although it is possible to have the DISTINCT or UNIQUE keyword in the defining query and still have a simple materialized view

  For example, the following statement creates a complex materialized view:

  CREATE MATERIALIZED VIEW hr.employee_depts AS
    SELECT DISTINCT department_id FROM hr.employees@orc1.world 
    ORDER BY department_id; 
  
  

• An aggregate function

  For example, the following statement creates a complex materialized view:

  CREATE MATERIALIZED VIEW hr.average_sal AS
    SELECT AVG(salary) "Average" FROM hr.employees@orc1.world;
  
  

• Joins other than those in a subquery

  For example, the following statement creates a complex materialized view:

  CREATE MATERIALIZED VIEW hr.emp_join_dep AS
    SELECT last_name 
    FROM hr.employees@orc1.world e, hr.departments@orc1.world d
    WHERE e.department_id = d.department_id; 
  
  

• In some cases, a UNION operation. Specifically, a materialized view with a UNION operation is complex if any one of these conditions is true:
  • Any query within the UNION is complex. The previous bullet items specify when a query makes a materialized view complex.
  • The outermost SELECT list columns do not match for the queries in the UNION. In the following example, the first query only has order_total in the outermost SELECT list while the second query has customer_id in the outermost SELECT list. Therefore, the materialized view is complex.

    CREATE MATERIALIZED VIEW oe.orders AS
      SELECT order_total 
      FROM oe.orders@orc1.world o
      WHERE EXISTS
        (SELECT cust_first_name, cust_last_name
           FROM oe.customers@orc1.world c
           WHERE o.customer_id = c.customer_id 
           AND c.credit_limit > 50)
    UNION    
      SELECT customer_id 
      FROM oe.orders@orc1.world o
      WHERE EXISTS
        (SELECT cust_first_name, cust_last_name 
           FROM oe.customers@orc1.world c
           WHERE o.customer_id = c.customer_id 
           AND c.account_mgr_id = 30);  
    
    

    The innermost SELECT list has no bearing on whether a materialized view is complex. In the previous example, the innermost SELECT list is cust_first_name and cust_last_name for both queries in the UNION.

• Clauses that do not comply with the requirements detailed in "Restrictions for Materialized Views with Subqueries".

  See Also: Oracle9i Data Warehousing Guide for more information about materialized views with aggregate functions and complex materialized views Oracle9i SQL Reference for more information about the CONNECT BY clause, set operations, the DISTINCT keyword, and aggregate functions

  Note: If possible, you should avoid using complex materialized views because they cannot be fast refreshed, which may degrade network performance (see "Refresh Process" for information).

A Comparison of Simple and Complex Materialized Views

For certain applications, you may want to consider using a complex materialized view. Figure 3-2 and the following text discuss some issues that you should consider.

Figure 3-2 Comparison of Simple and Complex Materialized Views

Text description of the illustration rep81023.gif

• Complex Materialized View: Method A in Figure 3-2 shows a complex materialized view. The materialized view in Database II exhibits efficient query performance because the join operation was completed during the materialized view's refresh. However, complete refreshes must be performed because the materialized view is complex, and these refreshes will probably be slower than fast refreshes.
• Simple Materialized Views with a Joined View: Method B in Figure 3-2 shows two simple materialized views in Database II, as well as a view that performs the join in the materialized view's database. Query performance against the view would not be as good as the query performance against the complex materialized view in Method A. However, the simple materialized views can be refreshed more efficiently using fast refresh and materialized view logs.

In summary, to decide which method to use:

• If you refresh rarely and want faster query performance, then use Method A (complex materialized view).
• If you refresh regularly and can sacrifice query performance, then use Method B (simple materialized view).

Required Privileges for Materialized View Operations

Three distinct types of users perform operations on materialized views:

• Creator: the user who creates the materialized view
• Refresher: the user who refreshes the materialized view
• Owner: the user who owns the materialized view. The materialized view resides in this user's schema.

One user may perform all of these operations on a particular materialized view. However, in some replication environments, different users perform these operations on a particular materialized view. The privileges required to perform these operations depend on whether the same user performs them or different users perform them. The following sections explain the privileges requirements in detail.

Creator Is Owner

If the creator of a materialized view also owns the materialized view, this user must have the following privileges to create a materialized view, granted either explicitly or through a role:

• CREATE MATERIALIZED VIEW or CREATE ANY MATERIALIZED VIEW
• CREATE TABLE or CREATE ANY TABLE
• CREATE VIEW or CREATE ANY VIEW if the compatibility level of the database is lower than 8.1.0
• SELECT object privilege on the master and the master's materialized view log or SELECT ANY TABLE system privilege. If the master site or master materialized view site is remote, then the SELECT object privilege must be granted to the user at the master site or master materialized view site to which the user at the materialized view site connects through a database link.

  If the owner of materialized view at the materialized view site has a private database link to the master site or master materialized view site, then the database link connects to the owner of the master at the master site or master materialized view site. Otherwise, the normal rules for connections through database links apply.

Creator Is Not Owner

If the creator of a materialized view is not the owner, certain privileges must be granted to the creator and to the owner to create a materialized view. The creator's privileges can be granted explicitly or through a role, but the owner's privileges must be granted explicitly. That is, the privileges granted to the owner cannot be granted through a role.

Table 3-1 shows the required privileges when the creator of the materialized view is not the owner.

Table 3-1 Required Privileges for Creating Materialized Views (Creator != Owner)

Creator

Owner

CREATE ANY MATERIALIZED VIEW

CREATE TABLE or CREATE ANY TABLE CREATE VIEW or CREATE ANY VIEW if the compatibility level of the database is lower than 8.1.0 SELECT object privilege on the master and the master's materialized view log or SELECT ANY TABLE system privilege. If the master site or master materialized view site is remote, then the SELECT object privilege must be granted to the user at the master site or master materialized view site to which the user at the materialized view site connects through a database link. If the owner of materialized view at the materialized view site has a private database link to the master site or master materialized view site, then the database link connects to the owner of the master at the master site or master materialized view site. Otherwise, the normal rules for connections through database links apply. Note: These privileges for the owner must be granted to the user explicitly, not through a role.

Refresher Is Owner

If the refresher of a materialized view also owns the materialized view, this user must have SELECT object privilege on the master and the master's materialized view log or SELECT ANY TABLE system privilege. If the master site or master materialized view site is remote, then the SELECT object privilege must be granted to the user at the master site or master materialized view site to which the user at the materialized view site connects through a database link. This privilege can be granted either explicitly or through a role.

If the owner of materialized view at the materialized view site has a private database link to the master site or master materialized view site, then the database link connects to the owner of the master at the master site or master materialized view site. Otherwise, the normal rules for connections through database links apply.

Refresher Is Not Owner

If the refresher of a materialized view is not the owner, certain privileges must be granted to the refresher and to the owner. These privileges can be granted either explicitly or through a role.

Table 3-2 shows the required privileges when the refresher of the materialized view is not the owner.

Table 3-2 Required Privileges for Refreshing Materialized Views (Refresher != Owner)

Refresher

Owner

ALTER ANY MATERIALIZED VIEW

If the master site or master materialized view site is local, then SELECT object privilege on the master and master's materialized view log or SELECT ANY TABLE system privilege. If the master site or master materialized view site is remote, then the SELECT object privilege must be granted to the user at the master site or master materialized view site to which the user at the materialized view site connects through a database link. If the owner of materialized view at the materialized view site has a private database link to the master site or master materialized view site, then the database link connects to the owner of the master at the master site or master materialized view site. Otherwise, the normal rules for connections through database links apply.

Data Subsetting with Materialized Views

In certain situations, you may want your materialized view to reflect a subset of the data in the master table or master materialized view. Row subsetting enables you to include only the rows that are needed from the master in the materialized views by using a WHERE clause. Column subsetting enables you to include only the columns that are needed from the master in the materialized views. You do this by specifying certain select columns in the SELECT statement during materialized view creation. If you use deployment templates to build your materialized views, then you can define column subsets on updatable materialized views.

Some reasons to use data subsetting are to:

• Reduce Network Traffic: In a column-subsetted materialized view, only changes that satisfy the WHERE clause of the materialized view's defining query are propagated to the materialized view site, thereby reducing the amount of data transferred and reducing network traffic.
• Secure Sensitive Data: Users can only view data that satisfies the defining query for the materialized view.
• Reduce Resource Requirements: If the materialized view is located on a laptop, then hard disks are generally significantly smaller than the hard disks on a corporate server. Subsetted materialized views may require significantly less storage space.
• Improve Refresh Times: Because less data is propagated to the materialized view site, the refresh process is faster, which is essential for those who need to refresh materialized views using a dial up network connection from a laptop.

For example, the following statement creates a materialized view based on the oe.orders@orc1.world master table and includes only the rows for the sales representative with a sales_rep_id number of 173:

CREATE MATERIALIZED VIEW oe.orders REFRESH FAST AS
 SELECT * FROM oe.orders@orc1.world
 WHERE sales_rep_id = 173;

Rows of the orders table with a sales_rep_id number other than 173 are excluded from this materialized view.

Materialized Views with Subqueries

The previous example works well for individual materialized views that do not have any referential constraints to other materialized views. But, if you want to replicate data based on the information in more than one table, then maintaining and defining these materialized views may be difficult. The following sections provide examples of situations where a subquery is useful.

Many to One Subqueries

Consider a scenario where you have the customers table and orders table in the oe schema, and you want to create a materialized view of the orders table based on data in both the orders table and the customers table. For example, suppose a salesperson wants to see all of the orders for the customers with a credit limit greater than $10,000. In this case, the CREATE MATERIALIZED VIEW statement that creates the orders materialized view has a subquery with a many to one relationship, because there can be many orders for each customer.

Look at the relationships in Figure 3-3, and notice that the customers and orders tables are related through the customer_id column. The following statement satisfies the original goal of the salesperson. That is, the following statement creates a materialized view that contains orders for customers whose credit limit is greater than $10,000:

CREATE MATERIALIZED VIEW oe.orders REFRESH FAST FOR UPDATE AS
  SELECT * FROM oe.orders@orc1.world o
  WHERE EXISTS
    (SELECT * FROM oe.customers@orc1.world c
     WHERE o.customer_id = c.customer_id AND c.credit_limit > 10000);

Figure 3-3 Row Subsetting with Many to One Subqueries

Text description of the illustration rep81088.gif

As you can see, the materialized view created by this statement is fast refreshable and updatable. If new customers are identified that have a credit limit greater than $10,000, then the new data will be propagated to the materialized view site during the subsequent refresh process. Similarly, if a customer's credit limit drops to less than $10,000, then the customer's data will be removed from the materialized view during the subsequent refresh process.

One to Many Subqueries

Consider a scenario where you have the customers table and orders table in the oe schema, and you want to create a materialized view of the customers table based on data in both the customers table and the orders table. For example, suppose a salesperson wants to see all of the customers who have an order with an order total greater than $20,000, then the most efficient method is to create a materialized view with a one to many subquery in the defining query of a materialized view.

Here, the defining query in the CREATE MATERIALIZED VIEW statement on the customers table has a subquery with a one to many relationship. That is, one customer can have many orders.

Look at the relationships in Figure 3-4, and notice that the orders table and customers table are related through the customer_id column. The following statement satisfies the original goal of the salesperson. That is, this statement creates a materialized view that contains customers who have an order with an order total greater than $20,000:

CREATE MATERIALIZED VIEW oe.customers REFRESH FAST FOR UPDATE AS
  SELECT * FROM oe.customers@orc1.world c
  WHERE EXISTS
    (SELECT * FROM oe.orders@orc1.world o
     WHERE c.customer_id = o.customer_id AND o.order_total > 20000);

Figure 3-4 Row Subsetting with One to Many Subqueries

Text description of the illustration rep81087.gif

The materialized view created by this statement is fast refreshable and updatable. If new customers are identified that have an order total greater than $20,000, then the new data will be propagated to the materialized view site during the subsequent refresh process. Similarly, if a customer cancels an order with an order total greater than $20,000 and has no other order totals greater than $20,000, then the customer's data will be removed from the materialized view during the subsequent refresh process.

Many to Many Subqueries

Consider a scenario where you have the order_items table and inventories table in the oe schema, and you want to create a materialized view of the inventories table based on data in both the inventories table and the order_items table. For example, suppose a salesperson wants to see all of the inventories with a quantity on hand greater than 0 (zero) for each product whose product_id is in the order_items table. In other words, the salesperson wants to see the inventories that are greater than zero for all of the products that customers have ordered. Here, an inventory is a certain quantity of a product at a particular warehouse. So, a certain product can be in many order items and in many inventories.

To accomplish the salesperson's goal, you can create a materialized view with a subquery on the many to many relationship between the order_items table and the inventories table.

When you create the inventories materialized view, you want to retrieve the inventories with the quantity on hand greater than zero for the products that appear in the order_items table. Look at the relationships in Figure 3-5, and note that the inventories table and order_items table are related through the product_id column. The following statement creates the materialized view:

CREATE MATERIALIZED VIEW oe.inventories REFRESH FAST FOR UPDATE AS
  SELECT * FROM oe.inventories@orc1.world i
  WHERE i.quantity_on_hand > 0 AND EXISTS
    (SELECT * FROM oe.order_items@orc1.world o
     WHERE i.product_id = o.product_id);

Figure 3-5 Row Subsetting with Many to Many Subqueries

Text description of the illustration rep81089.gif

The materialized view created by this statement is fast refreshable and updatable. If new inventories that are greater than zero are identified for products in the order_items table, then the new data will be propagated to the materialized view site during the subsequent refresh process. Similarly, if a customer cancels an order for a product and there are no other orders for the product in the order_items table, then the inventories for the product will be removed from the materialized view during the subsequent refresh process.

Materialized Views with Subqueries and Unions

In situations where you want a single materialized view to contain data that matches the complete results of two or more different queries, you can use the UNION operator. When you use the UNION operator to create a materialized view, you have two SELECT statements around each UNION operator, one is above it and one is below it. The resulting materialized view contains rows selected by either query.

You can use the UNION operator as a way to create fast refreshable materialized views that satisfy "or" conditions without using the OR expression in the WHERE clause of a subquery. Under some conditions, using an OR expression in the WHERE clause of a subquery causes the resulting materialized view to be complex, and therefore not fast refreshable.

For example, suppose a salesperson wants the product information for the products in a particular category_id that are either in a warehouse in California or contain the word "Rouge" in their translated product descriptions (for the French translation). The following statement uses the UNION operator and subqueries to capture this data in a materialized view for products in category_id 29:

CREATE MATERIALIZED VIEW oe.product_information REFRESH FAST FOR UPDATE AS
 SELECT * FROM product_information@orc1.world pi
 WHERE pi.category_id = 29 AND EXISTS
  (SELECT * FROM product_descriptions@orc1.world pd
  WHERE pi.product_id = pd.product_id AND translated_description LIKE '%Rouge%')  
UNION
 SELECT * FROM product_information@orc1.world pi
 WHERE pi.category_id = 29 AND EXISTS
  (SELECT * FROM oe.inventories@orc1.world i
  WHERE pi.product_id = i.product_id AND EXISTS
    (SELECT * FROM oe.warehouses@orc1.world w
    WHERE i.warehouse_id = w.warehouse_id AND EXISTS
      (SELECT * FROM hr.locations@orc1.world l
       WHERE w.location_id = l.location_id 
       AND l.state_province = 'California')));   
  

Figure 3-6 shows the relationships of the master tables involved in this statement.

Figure 3-6 Row Subsetting with Subqueries and Unions

Text description of the illustration rep81090.gif

In addition to the UNION operation, this statement contains the following subqueries:

• A subquery referencing the product_information table and the product_descriptions table. This subquery is one to many because one product can have multiple product descriptions (for different languages).
• A subquery referencing the product_information table and the inventories table. This subquery is one to many because a product can be in many inventories.
• A subquery referencing the inventories table and the warehouses table. This subquery is many to one because many inventories can be stored in one warehouse.
• A subquery referencing the warehouses table and the locations table. This subquery is many to one because many warehouses can be in one location.

The materialized view created by this statement is fast refreshable and updatable. If a new product is added that is stored in a warehouse in California or that has the string "Rouge" in the translated product description, then the new data will be propagated to the product_information materialized view during the subsequent refresh process.

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.

  Note: If the CREATE MATERIALIZED VIEW statement includes an ON PREBUILT TABLE clause and a subquery, then the subquery is treated as many to many. Therefore, in this case, the join columns must be recorded in the materialized view log. See the Oracle9i SQL Reference for more information about the ON PREBUILT TABLE clause in the CREATE MATERIALIZED VIEW statement.

  See Also: "Primary Key Materialized Views" for more information about primary key materialized views

Restrictions for Materialized Views with Unions Containing Subqueries

The following are restrictions for fast refresh materialized views with unions containing subqueries:

• All of the restrictions described in the previous section, "Restrictions for Materialized Views with Subqueries", apply to the subqueries in each union block.
• All join columns must be included in the materialized view log of the master, even if the subquery is many to one.
• All of the restrictions described in the previous section, "Complex Materialized Views", for clauses with UNIONS.

Examples of Materialized Views with Unions Containing Subqueries

The following statement creates the oe.orders materialized view. This materialized view is fast refreshable because the subquery in each union block satisfies the restrictions for subqueries described in "Restrictions for Materialized Views with Subqueries".

CREATE MATERIALIZED VIEW oe.orders REFRESH FAST AS
  SELECT * FROM oe.orders@orc1.world o
  WHERE EXISTS
    (SELECT * FROM oe.customers@orc1.world c
     WHERE o.customer_id = c.customer_id 
     AND c.credit_limit > 50)
UNION    
  SELECT * 
  FROM oe.orders@orc1.world o
  WHERE EXISTS
    (SELECT * FROM oe.customers@orc1.world c
     WHERE o.customer_id = c.customer_id 
     AND c.account_mgr_id = 30);  

Notice that one of the restrictions for subqueries states that each table can be in only one EXISTS expression. Here, the customers table appears in two EXISTS expressions, but the EXISTS expressions are in separate UNION blocks. Because the restrictions described in "Restrictions for Materialized Views with Subqueries" only apply to each UNION block, not to the entire CREATE MATERIALIZED VIEW statement, the materialized view is fast refreshable.

In contrast, the materialized view created with the following statement cannot be fast refreshed because the orders table is referenced in two different EXISTS expressions within the same UNION block:

CREATE MATERIALIZED VIEW oe.orders AS
  SELECT * FROM oe.orders@orc1.world o
  WHERE EXISTS
    (SELECT * FROM oe.customers@orc1.world c
     WHERE o.customer_id = c.customer_id  -- first reference to orders table
     AND c.credit_limit > 50
     AND EXISTS
        (SELECT * FROM oe.orders@orc1.world o
         WHERE order_total > 5000 
         AND o.customer_id = c.customer_id)) -- second reference to orders table
UNION    
  SELECT * 
  FROM oe.orders@orc1.world o
  WHERE EXISTS
    (SELECT * FROM oe.customers@orc1.world c
     WHERE o.customer_id = c.customer_id 
     AND c.account_mgr_id = 30);  

Determining the Fast Refresh Capabilities of a Materialized View

To determine whether a materialized view's subquery satisfies the restrictions detailed in the previous section, create the materialized view with fast refresh. Oracle returns errors if the materialized view violates any restrictions for subquery materialized views. If you specify force refresh, then you may not receive any errors because, when a force refresh is requested, Oracle automatically performs a complete refresh if it cannot perform a fast refresh.

You can also use the EXPLAIN_MVIEW procedure in the DBMS_MVIEW package to determine the following information about an existing materialized view or a proposed materialized view that does not yet exist:

• The capabilities of a materialized view
• Whether each capability is possible
• If a capability is not possible, why it is not possible

This information can be stored in a varray or in the MV_CAPABILITIES_TABLE. If you want to store the information in the table, then, before you run the EXPLAIN_MVIEW procedure, you must build this table by running the utlxmv.sql script in the Oracle_home/rdbms/admin directory.

For example, to determine the capabilities of the oe.orders materialized view, enter:

EXECUTE DBMS_MVIEW.EXPLAIN_MVIEW ('oe.orders');

Or, if the materialized view does not yet exist, then you can supply the query that you want to use to create it:

BEGIN
  DBMS_MVIEW.EXPLAIN_MVIEW ('SELECT * FROM oe.orders@orc1.world o
    WHERE EXISTS (SELECT * FROM oe.customers@orc1.world c
    WHERE o.customer_id = c.customer_id AND c.credit_limit > 500)');
END;
/

Query the MV_CAPABILITIES_TABLE to see the results.

Multitier Materialized Views

The ability to create materialized views that are based on other materialized views enables you to create multitier materialized views. Materialized views that are based on other materialized views can be read-only or updatable. The arrows in Figure 3-7 represent database links.

Figure 3-7 Multitier Materialized Views

Text description of the illustration rep81085.gif

When you are using multitier materialized views, the materialized view based on a master table is called a level 1 materialized view. Then, a materialized view based on the level 1 materialized view is called a level 2 materialized view. Next is level 3 and so on. Figure 3-8 shows these levels.

Figure 3-8 Levels of Materialized Views

Text description of the illustration rep81095.gif

A materialized view that is acting as the master for another materialized view is called a master materialized view. A materialized view at any level can be a master materialized view, and, as you can see in Figure 3-8, a master materialized view can have more than one materialized view based on it. In Figure 3-8, two level 2 materialized views are based on one level 1 materialized view. Figure 3-9 illustrates an example that shows a master materialized view at level 1 (orders_1) and level 2 (orders_2).

Figure 3-9 Master Materialized Views

Text description of the illustration rep81097.gif

The master for the level 1 materialized view orders_1 is the master table orders at the master site, but, starting with level 2, each materialized view has a master materialized view at the level above it. For example, the master for the level 2 materialized view orders_2 is the level 1 materialized view orders_1.

A master materialized view functions the same way a master table does at a master site. That is, changes pushed from a level 2 materialized view to a level 1 materialized view are handled in exactly the same way that changes pushed from a level 1 materialized view to a master table are handled.

A receiver must be registered at a master materialized view site. The receiver is responsible for receiving and applying the deferred transactions from the propagator at multitier materialized view sites that are based on the master materialized view.

Multitier materialized views offer greater flexibility in the design of a replication environment. Some materialized view sites may not need to replicate all of the data in master tables, and, in fact, these sites may not have the storage capacity for all of the data. In addition, replicating less data means that there is less activity on the network.

Multitier materialized views are ideal for organizations that are structured on three or more levels or constrained by limited network resources. For example, consider a company with international, national, and local offices. This company has many computers at both the national and local level that replicate data. Here, the replication environment can be configured with the master site at the international headquarters and with materialized views at the national level. These materialized views at the national level only replicate the subset of data from the master tables that apply to their respective countries. Now, using multitier materialized views, another level of materialized views at the local level can be based on the materialized views at the national level. The materialized views at the local level contain the subset of data from the level 1 materialized views that apply to their local customers.

Scenario for Using Multitier Materialized Views

Consider a multinational company that maintains all employee information at headquarters, which is in the in the United States. The company uses the tables in the hr schema to maintain the employee information. This company has one main office in 14 countries and many regional offices for cities in these countries.

For example, the company has one main office for all of the United Kingdom, but it also has an office in the city of London. The United Kingdom office maintains employee information for all of the employees in the United Kingdom, while the London office only maintains employee information for the employees at the London office. In this scenario, the hr.employees master table is at headquarters in the United States and each regional office has a an hr.employees materialized view that only contains the necessary employee information.

The following statement creates the hr.employees materialized view for the United Kingdom office. The statement queries the master table in the database at headquarters, which is orc1.world. Notice that the statement uses subqueries so that the materialized view only contains employees whose country_id is UK.

CREATE MATERIALIZED VIEW hr.employees REFRESH FAST FOR UPDATE AS
  SELECT * FROM hr.employees@orc1.world e
    WHERE EXISTS
      (SELECT * FROM hr.departments@orc1.world d
       WHERE e.department_id = d.department_id
       AND EXISTS
         (SELECT * FROM hr.locations@orc1.world l
          WHERE l.country_id = 'UK'
          AND d.location_id = l.location_id));

The following statement creates the hr.employees materialized view for the London office based on the level 1 materialized view at the United Kingdom office. The statement queries the materialized view in the database at the United Kingdom office, which is reg_uk.world. Notice that the statement uses subqueries so that the materialized view only contains employees whose city is London.

CREATE MATERIALIZED VIEW hr.employees REFRESH FAST FOR UPDATE AS
  SELECT * FROM hr.employees@reg_uk.world e
    WHERE EXISTS
      (SELECT * FROM hr.departments@reg_uk.world d
       WHERE e.department_id = d.department_id
       AND EXISTS
         (SELECT * FROM hr.locations@reg_uk.world l
          WHERE l.city = 'London'
          AND d.location_id = l.location_id));

Restrictions for Using Multitier Materialized Views

Both master materialized views and materialized views based on materialized views must:

• Be primary key materialized views
• Reside in a database that is at 9.0.1 or higher compatibility level

  Note: The COMPATIBLE initialization parameter controls a database's compatibility level.

Additional Restrictions for Master Materialized Views

The following types of materialized views cannot be masters for updatable materialized views:

• ROWID materialized views
• Complex materialized views
• Read-only materialized views

However, these types of materialized views can be masters for read-only materialized views.

Additional Restrictions for Updatable Materialized Views Based on Materialized Views

Updatable materialized views based on materialized views must:

• Belong to a materialized view group that has the same name as the materialized view group at its master materialized view site
• Reside in a different database than the materialized view group at its master materialized view site
• Be based on another updatable materialized view or other updatable materialized views, not on a read-only materialized view
• Be based on a materialized view in a materialized view group that is owned by PUBLIC at the master materialized view site.

Materialized Views with User-Defined Types

Oracle object types are user-defined datatypes that make it possible to model complex real-world entities such as customers and orders as single entities, called objects, in the database. You create object types using the CREATE TYPE ... AS OBJECT statement. You can replicate object types and objects between master sites and materialized view sites in a replication environment.

An Oracle object that occupies a single column in a table is called a column object. Typically, tables that contain column objects also contain other columns, which may be built-in datatypes, such as VARCHAR2 and NUMBER. An object table is a special kind of table in which each row represents an object. Each row in an object table is a row object.

You can also replicate collections. Collections are user-defined datatypes that are based on VARRAY and nested table datatypes. You create varrays with the CREATE TYPE ... AS VARRAY statement, and you create nested tables with the CREATE TYPE ... AS TABLE statement.

Type Agreement at Replication Sites

User-defined types include all types created using the CREATE TYPE statement, including object, nested table, VARRAY, and indextype. To replicate schema objects based on user-defined types, the user-defined types themselves must exist, and must be exactly the same, at all replication sites. In addition, Oracle Corporation recommends that you add a user-defined type to the replication group in which it is used, but doing so is not required.

When replicating user-defined types and the schema objects on which they are based, the following conditions apply:

• The user-defined types replicated at the master site and materialized view site must be created at the materialized view site before you create any materialized views that depend on these types.
• All of the masters on which a materialized view is based must be at the same master site to create a materialized view with user-defined types.
• A user-defined type must be exactly the same at all replication sites:
  • All replication sites must have the same object identifier (OID), schema owner, and type name for each replicated user-defined type.
  • If the user-defined type is an object type, then all replication sites must agree on the order and datatype of the attributes in the object type. You establish the order and datatypes of the attributes when you create the object type. For example, consider the following object type:

    CREATE TYPE cust_address_typ AS OBJECT
         (street_address     VARCHAR2(40), 
          postal_code        VARCHAR2(10), 
          city               VARCHAR2(30), 
          state_province     VARCHAR2(10), 
          country_id         CHAR(2));
    /
    
    

    At all replication sites, street_address must be the first attribute for this type and must be VARCHAR2(40), postal_code must be the second attribute and must be VARCHAR2(10), city must be the third attribute and must be VARCHAR2(30), and so on.

  • All replication sites must agree on the hashcode of the user-defined type. Oracle examines a user-defined type and assigns the hashcode. This examination includes the type attributes, order of attributes, and type name. When all of these items are the same for two or more types, the types have the same hashcode. You can view the hashcode for a type by querying the DBA_TYPE_VERSIONS data dictionary view.

To ensure that a user-defined type is exactly the same at all replication sites, you must create the user-defined type at the materialized view site in one of the following ways:

• Use the Replication Management API
• Use a CREATE TYPE Statement

Use the Replication Management API

Oracle Corporation recommends that you use the replication management API to create, modify, or drop any replicated object at a materialized view site, including user-defined types. If you do not use the replication management API for these actions, then replication errors may result.

Specifically, to create a user-defined type that is exactly the same at the master site and the materialized view site, use the CREATE_MVIEW_REPOBJECT procedure in the DBMS_REPCAT package. This procedure creates the type and adds it to a materialized view group. To drop a user-defined type from the materialized view site, use the DROP_MVIEW_REPOBJECT procedure in the DBMS_REPCAT package.

Use a CREATE TYPE Statement

You can use a CREATE TYPE statement at the materialized view site to create the type. It may be necessary to do this if you want to create a read-only materialized view that uses the type, and you do not want to add the read-only materialized view to a materialized view group.

If you choose this option, then you must ensure the following:

• The type is in the same schema at both the materialized view site and the master site.
• The type has exactly the same attributes in exactly the same order at both the materialized view site and the master site.
• The type has exactly the same datatype for each attribute at both the materialized view site and the master site.
• The type has the same object identifier at both the materialized view site and the master site.

You can find the object identifier for a type by querying the DBA_TYPES data dictionary view. For example, to find the object identifier (OID) for the cust_address_typ, enter the following query:

SELECT TYPE_OID FROM DBA_TYPES WHERE TYPE_NAME = 'CUST_ADDRESS_TYP';

TYPE_OID
--------------------------------
6F9BC33653681B7CE03400400B40A607

Now that you know the OID for the type at the master site, complete the following steps to create the type at the materialized view site:

1. Log in to the materialized view site as the user who owns the type at the master site. If this user does not exist at the materialized view site, then create the user.
2. Issue the CREATE TYPE statement and specify the OID:

   CREATE TYPE oe.cust_address_typ OID '6F9BC33653681B7CE03400400B40A607' 
        AS OBJECT (
        street_address     VARCHAR2(40), 
        postal_code        VARCHAR2(10), 
        city               VARCHAR2(30), 
        state_province     VARCHAR2(10), 
        country_id         CHAR(2));
   /
   
   

The type is now ready for use at the materialized view site.

Column Subsetting of Masters with Column Objects

A read-only materialized view can replicate specific attributes of a column object without replicating other attributes. For example, using the cust_address_typ user-defined datatype described in the previous section, suppose a customers master table is created at master site orc1.world:

CREATE TABLE oe.customers (
          customer_id        NUMBER(6), 
      cust_first_name    VARCHAR2(20), 
      cust_last_name     VARCHAR2(20),
      cust_address       cust_address_typ);

You can create the following read-only materialized view at a remote materialized view site:

CREATE MATERIALIZED VIEW oe.customers_mv1 AS
   SELECT customer_id, cust_last_name, c.cust_address.postal_code
   FROM oe.customers@orc1.world c;

Notice that the postal_code attribute is specified in the cust_address column object.

An updatable materialized view must replicate the entire column object. It cannot replicate some attributes of a column object but not others. The following statement is valid because it specifies the entire cust_address column object:

CREATE MATERIALIZED VIEW oe.customers_mv1 FOR UPDATE AS
   SELECT customer_id, cust_last_name, cust_address
   FROM oe.customers@orc1.world;

Materialized Views Based on Object Tables

If a materialized view is based on an object table and is created using the OF type clause, then the materialized view is called an object materialized view. An object materialized view is structured in the same way as an object table. That is, an object materialized view is composed of row objects. If a materialized view that is based on an object table is created without using the OF type clause, then the materialized view is read-only and is not an object materialized view. That is, such a materialized view has regular rows, not row objects.

To create a materialized view based on an object table, the types on which the materialized view depends must exist at the materialized view site, and each type must have the same object identifier as it does at the master site.

Creation of Object Materialized Views Using the OF type Clause

After the required types are created at the materialized view site, you can create an object materialized view by specifying the OF type clause.

For example, suppose the following SQL statements create the categories_tab object table at the orc1.world master site:

CREATE TYPE category_typ AS OBJECT
   (category_name           VARCHAR2(50), 
    category_description    VARCHAR2(1000), 
    category_id             NUMBER(2))
NOT FINAL;
/

CREATE TABLE categories_tab OF category_typ
    (category_id    PRIMARY KEY);

If you want to create materialized views that can be fast refreshed based on the categories_tab master table, then create a materialized view log for this table:

CREATE MATERIALIZED VIEW LOG ON categories_tab WITH OBJECT ID;

The WITH OBJECT ID clause is required when you create a materialized view log on an object table.

After you create the category_typ type at the materialized view site, you can create an object materialized view based on the categories_tab object table using the OF type clause, as in the following SQL statement:

CREATE MATERIALIZED VIEW categories_objmv OF category_typ 
   REFRESH FAST FOR UPDATE
   AS SELECT * FROM categories_tab@orc1.world;

Here, type is category_typ.

Materialized Views Based on Object Tables Created Without Using the OF type Clause

If you create a materialized view based on an object table without using the OF type clause, then the materialized view is read-only, and it loses the object properties of the object table on which it is based. That is, the resulting read-only materialized view contains one or more of the columns of the master, but each row functions as a row in a relational table. The rows are not row objects.

For example, you can create a materialized view base on the categories_tab master by using the following SQL statement:

CREATE MATERIALIZED VIEW categories_relmv
   AS SELECT * FROM categories_tab@orc1.world;

In this case, the categories_relmv materialized view must be read-only, and the rows in this materialized view function in the same way as rows in a relational table.

OID Preservation in Object Materialized Views

An object materialized view inherits the object identifier (OID) specifications of its master. If the master has a primary key-based OID, then the OIDs of row objects in the materialized view are primary key-based. If the master has a system generated OID, then the OIDs of row objects in the materialized view are system generated. Also, the OID of each row in the object materialized view matches the OID of the same row in the master, and the OIDs are preserved during refresh of the materialized view. Consequently, REFs to the rows in the object table remain valid at the materialized view site.

Materialized Views with Collection Columns

Collection columns are columns based on varray and nested table datatypes. Oracle supports the creation of materialized views with collection columns.

If the collection column is a nested table, then you can optionally specify the nested_table_storage_clause during materialized view creation. The nested_table_storage_clause lets you specify the name of the storage table for the nested table in the materialized view. For example, suppose you create the master table people_reltab at the master site orc1.world that contains the nested table phones_ntab:

CREATE TYPE phone_typ AS OBJECT (
   location    VARCHAR2(15),
   num         VARCHAR2(14));
/

CREATE TYPE phone_ntabtyp AS TABLE OF phone_typ;
/

CREATE TABLE people_reltab (
   id               NUMBER(4) CONSTRAINT pk_people_reltab PRIMARY KEY,
   first_name       VARCHAR2(20),
   last_name        VARCHAR2(20),
   phones_ntab      phone_ntabtyp)
   NESTED TABLE phones_ntab STORE AS phone_store_ntab
   ((PRIMARY KEY (NESTED_TABLE_ID, location)));

Notice the PRIMARY KEY specification in the last line of the preceding SQL statement. You must specify a primary key for the storage table if you plan to create materialized views based on its parent table. In this case, the storage table is phone_store_ntab and the parent table is people_reltab.

If you want to create materialized views that can be fast refreshed, then create a materialized view log on both the parent table and the storage table, specifying the nested table column as a filter column for the parent table's materialized view log:

CREATE MATERIALIZED VIEW LOG ON people_reltab;

ALTER MATERIALIZED VIEW LOG ON people_reltab ADD(phones_ntab);

CREATE MATERIALIZED VIEW LOG ON phone_store_ntab WITH PRIMARY KEY;

At the materialized view site, create the required types, ensuring that the object identifier for each type is the same as the object identifier at the master site. Then, you can create a materialized view based on people_reltab and specify its storage table using the following statement:

CREATE MATERIALIZED VIEW people_reltab_mv
   NESTED TABLE phones_ntab STORE AS phone_store_ntab_mv 
   REFRESH FAST AS SELECT * FROM people_reltab@orc1.world;

In this case, the nested_table_storage_clause is the line that begins with "NESTED TABLE" in the previous example, and it specifies that the storage table's name is phone_store_ntab_mv. The nested_table_storage_clause is optional. If you do not specify this clause, Oracle automatically names the storage table. To view the name of a storage table, query the DBA_NESTED_TABLES data dictionary table.

The storage table:

• Is a separate, secondary materialized view
• Is refreshed automatically when you refresh the materialized view containing the nested table
• Is dropped automatically when you drop the materialized view containing the nested table
• Inherits the primary key constraint of the master's storage table

Because the storage table inherits the primary key constraint of the master's storage table, do not specify PRIMARY KEY in the STORE AS clause.

The following actions are not allowed directly on the storage table of a nested table in a materialized view:

• Refreshing the storage table
• Adding the storage table to a replication group
• Altering the storage table
• Dropping the storage table
• Generating replication support on the storage table

These actions can occur indirectly when they are performed on the materialized view that contains the nested table. In addition, you cannot replicate a subset of the columns in a storage table.

Restrictions for Materialized Views with Collection Columns

The following restrictions apply to materialized views with collection columns:

• Row subsetting of collection columns is not allowed. However, you can use row subsetting on the parent table of a nested table and doing so can result in a subset of the nested tables in the materialized view.
• Column subsetting of collection columns is not allowed.
• A nested table's storage table must have a primary key.