Create/Edit View |
The view dialog box is used for creating or editing a view or materialized view. You must use the Entire SQL Query tab to specify the query part of the view definition, and you can use one or more other tabs (depending on the type of view) for other parts of the definition.
If you click OK before you are finished creating or editing the view, right-click the view name in the Connections navigator, select Edit, and continue creating or editing the view.
Schema: Database schema in which to create the view.
Name: Name of the view. Must be unique within a schema.
Entire SQL Query tab
Specifies the query part of the view definition, using the SELECT and FROM keywords and usually a WHERE clause with whatever syntax is needed to retrieve the desired information.
For example, the following query, from the Creating a View tutorial topic, selects columns from the Patrons and Transactions tables, ordering them first by values in the the PATRON_ID column in the Patrons table and then by values in the TRANSACTION_TYPE column in the Transactions table. The result is a listing by patron ID of all patrons who had transactions, and for each listed patron the transaction information listed by transaction type
CREATE VIEW patrons_trans_view AS
SELECT p.patron_id, p.last_name, p.first_name,
t.transaction_type, t.transaction_date
FROM patrons p, transactions t
WHERE p.patron_id = t.patron_id
ORDER BY p.patron_id, t.transaction_type;
SQL Parse Results: If you click Test Syntax, displays any SQL syntax errors, or displays a message indicating no errors if there are no syntax errors.
Revert: Cancels any edits you have made in the Entire SQL Query box, and displays the contents of the box before these edits.
Test Syntax: Checks the statement in the Entire SQL Query box for any SQL syntax errors.
View Information or Materialized View Information tab
Options for a standard view:
Restrict Query: If this option is checked, you can enable one of the following options
Read Only: Prevents the view from being used to add, delete, or change data in the underlying table or tables.
Check Option: If this option is checked, it prohibits any changes to the underlying table or tables that would produce rows that are not included in this view.
Force on create: If this option is checked, the view is created even if it has errors in its definition. This option is useful if you want to create the view regardless of any errors, and go back and correct the errors later. If this option is not checked, the view is not created is its definition contains any errors.
Options for a materialized view:
Refresh Options:
Method: The method of refresh operation to be performed:
Complete Refresh: Executes the defining query of the materialized view, even if a fast refresh is possible.
Fast Refresh: Uses 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.
Forced Refresh: Performs a fast refresh if one is possible; otherwise, performs a complete refresh.
Never: Do not perform refresh operations.
When: The type of refresh operation to be performed:
Automatic: Automatically performs a refresh operation, starting and continuing as specified in the remaining fields.
On Commit: Performs a fast refresh whenever the database commits a transaction that operates on a master table of the materialized view. This may increase the time taken to complete the commit, because the database performs the refresh operation as part of the commit process.
On Demand: Performs a refresh when one of the DBMS_MVIEW refresh procedures is called.
Type: Refresh type, which determines the type of materialized view:
Primary Key: Creates a primary key materialized view, which allows materialized view master tables to be reorganized without affecting the eligibility of the materialized view for fast refresh.
Row ID: Creates a rowid materialized view, which is useful if the materialized view does not include all primary key columns of the master tables.
Start on: Starting date and time for the first automatic refresh operation. Must be in the future.
Next: Time for the next automatic refresh operation. The interval between the Start on and Next times establishes the interval for subsequent automatic refresh operations. If you do not specify a value, the refresh operation is performed only once at the time specified for Start on.
Materialized View Options:
Parallel: If this option is checked, parallel operations will be supported for the materialized view, and you can specify a number for the default degree of parallelism for queries and DML on the materialized view after creation.
Enable Cache: If this option is checked, 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 setting is useful for small lookup tables. If this option is not checked, the blocks are placed at the least recently used end of the LRU list.
Build Type: Specifies when to populate the materialized view. Immediate indicates that the materialized view is to be populated immediately. Deferred indicates that the materialized view is to be populated by the next refresh operation. If you specify Deferred, 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.
Enable Query Rewrite: If this option is checked, the materialized view is enabled for 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.
Prebuilt Option: If this option is checked, an existing table is registered as a preinitialized materialized view. This option 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, and the table should reflect the materialization of a subquery. Reduced Precision authorizes 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 subquery. No Reduced Precision requires that the precision of the table or materialized view columns match exactly the precision returned by subquery, or the create operation will fail.
Index Storage Options:
Use Index: If this option is checked, a default index is created and used to speed up incremental (fast) refresh of the materialized view. If this option is not checked, this default index is not created. (For example, you might choose to suppress the index creation now and to create such an index explicitly later.)
Use Tablespace: If this option is checked, you can specify the tablespace in which the materialized view is to be created. If this option is not checked, the materialized view is created in the default tablespace of the schema containing the materialized view.
DDL tab
If you are editing an existing view or if you have only partially created a view, this tab contains a read-only display of a SQL statement that reflects the current definition of the view.
To save the SQL statement to a script file, click Save and specify the location and file name.
Related Topics