Example 1: Changing the comment on a view A comment can be added or changed on a view using the COMMENT IS clause as shown in this example. SQL> show view (comment) current_job Information for table CURRENT_JOB SQL> alter view CURRENT_JOB cont> comment is 'Select the most recent job for the employee'; SQL> show view (comment) current_job Information for table CURRENT_JOB Comment on table CURRENT_JOB: Select the most recent job for the employee SQL> Example 2: Changing the column's results of a view definition The following view uses a derived table and join to collect the count of employees in each department. The view is used in several reporting programs used by the department and company managers. SQL> create view DEPARTMENTS_SUMMARY cont> as cont> select department_code, d.department_name, cont> d.manager_id, jh.employee_count cont> from departments d inner join cont> (select department_code, count (*) cont> from job_history cont> where job_end is null cont> group by department_code) cont> as jh (department_code, employee_count) cont> using (department_code); SQL> SQL> show view DEPARTMENTS_SUMMARY; Information for table DEPARTMENTS_SUMMARY Columns for view DEPARTMENTS_SUMMARY: Column Name Data Type Domain ----------- --------- ------ DEPARTMENT_CODE CHAR(4) DEPARTMENT_NAME CHAR(30) Missing Value: None MANAGER_ID CHAR(5) Missing Value: EMPLOYEE_COUNT INTEGER Source: select department_code, d.department_name, d.manager_id, jh.employee_count from departments d inner join (select department_code, count (*) from job_history where job_end is null group by department_code) as jh (department_code, employee_count) using (department_code) SQL> The database administrator decides to create a column in the DEPARTMENTS table to hold the count of employees (rather than using a query to gather the total) and to maintain the value through triggers on EMPLOYEES and JOB_HISTORY (not shown here). Now the view can be simplified without resorting to a DROP VIEW and CREATE VIEW. The ALTER VIEW statement preserves the dependencies on the view from other views, triggers, and routines and so minimizes the work required to implement such a change. SQL> alter table DEPARTMENTS cont> add column EMPLOYEE_COUNT integer; SQL> SQL> alter view DEPARTMENTS_SUMMARY cont> as cont> select department_code, d.department_name, cont> d.manager_id, d.employee_count cont> from departments d; SQL> SQL> show view DEPARTMENTS_SUMMARY; Information for table DEPARTMENTS_SUMMARY Columns for view DEPARTMENTS_SUMMARY: Column Name Data Type Domain ----------- --------- ------ DEPARTMENT_CODE CHAR(4) Missing Value: None DEPARTMENT_NAME CHAR(30) Missing Value: None MANAGER_ID CHAR(5) Missing Value: EMPLOYEE_COUNT INTEGER Source: select department_code, d.department_name, d.manager_id, d.employee_count from departments d SQL> Example 3: Changing the WITH CHECK OPTION constraint of a view definition This example shows that a WITH CHECK OPTION constraint restricts the inserted data to the view's WHERE clause. Once the constraint is removed, the INSERT is no longer constrained. SQL> create view TOLIVER_EMPLOYEE cont> as select * from EMPLOYEES where employee_id = '00164' cont> with check option; SQL> insert into TOLIVER_EMPLOYEE (employee_id) value ('00000'); %RDB-E-INTEG_FAIL, violation of constraint TOLIVER_EMPLOYEE_CHECKOPT1 caused operation to fail -RDB-F-ON_DB, on database DISK1:[DATABASES]MF_PERSONNEL.RDB;1 SQL> SQL> alter view TOLIVER_EMPLOYEE with no check option; SQL> SQL> insert into TOLIVER_EMPLOYEE (employee_id) value ('00000'); 1 row inserted SQL>