A view is a virtual table derived from one or more tables or other views. It is virtual because it does not contain any data, but a definition of a table based on the result of a
SELECT statement. Figure 7.21 illustrates view
view1 derived from table
table1 .
A view does not need to contain all the columns of the base table. Its columns do not need to have the same names as the base table, either. This is illustrated in Figure 7.21, where the view consists of only two columns, and the first column of the view has a different name than the corresponding column in the base table. This is particularly useful for hiding confidential information from users.
You can create a view using the
CREATE VIEW statement. For example, to create the view
view1 shown in Figure 7.21, issue this statement.
CREATE VIEW view1 (id, name)
AS SELECT employee_id, name FROM table1
To display the contents of
view1 , use the following statement.
SELECT * FROM view1
You can also create views based on multiple tables. Figure 7.22 shows a view created from two tables.
Here is the corresponding
CREATE VIEW statement for Figure 7.22.
CREATE VIEW view2 (id, name, region)
AS SELECT table1.employee_id, table1.name, table2.region
FROM table1,table2
WHERE table1.employee_id = table2.employee_id
With this statement we have combined the information of
table1 and
table2 into
view2 , while limiting access to the salary information.
When you create a view, its definition is stored in the system catalog table SYSCAT.VIEWS. This table contains information about each view such as its name, schema, whether or not it is read-only, and the SQL statement used to create the view. For example, in Figure 7.23 we show part of the information for views
view1 and
view2 in SYSCAT.VIEWS.
When a view is referenced in a query, DB2 reads and executes the view definition from the SYSCAT.VIEWS table, pulls the data from the base table, and presents it to the users.
To remove a view, use the
DROP VIEW statement. For example, to remove the view
view1 use:
DROP VIEW view1
If any of the base tables or views is dropped, the views that are dependent on them will be marked invalid and the value in the VALID column shown in Figure 7.23 will be set to X instead of Y. When this happens, you will not be able to use these views. This is true even if you have recreated the base table or view afterward.
Views are classified by the operations they allow. There are four classes of views:
Deleteable views
Updatable views
Insertable views
Read-only views
In the SYSCAT.VIEWS catalog table, when the value of the column READ-ONLY is Y, this indicates that the view is read-only; otherwise, it is either a deleteable, updatable, or insertable view. Figure 7.23 shows
view2 is a read-only view, but
view1 is not.
Figure 7.24 illustrates the relationship between the different types of views. The views are discussed further in the next sections.
A
deleteable view allows you to execute the
DELETE statement against it. All of the following must be true.
Each
FROM clause of the outer fullselect identifies only one base table (with no
OUTER clause), a deleteable view (with no
OUTER clause), a deleteable nested table expression, or a deleteable common table expression (cannot identify a NICKNAME used with federated support).
The outer fullselect does not include a
VALUES clause.
The outer fullselect does not include a
GROUP BY clause or a
HAVING clause.
The outer fullselect does not include column functions in the
SELECT list.
The outer fullselect does not include
SET operations (
UNION, EXCEPT , or
INTERSECT ), with the exception of
UNION ALL .
The base tables in the operands of a
UNION ALL must not be the same table, and each operand must be deleteable.
The select list of the outer fullselect does not include
DISTINCT .
For further detail, refer to the
DB2 UDB SQL Reference manual. In our previous example,
view1 is a deleteable view. However,
view2 is not because it does not follow the first rule. In
view2 's definition, the
SELECT statement contains two base tables in the
FROM clause.
An
updatable view is a special case of a deleteable view. A view is updatable when at least one of its columns is updatable. All of the following must be true.
The view is deleteable.
The column resolves to a column of a base table (not using a dereference operation), and the
READ ONLY option is not specified
All the corresponding columns of the operands of a
UNION ALL have exactly matching data types (including length or precision and scale) and matching default values if the fullselect of the view includes a
UNION ALL .
In our previous example,
view1 is an updatable view. However,
view2 is not because it is not deleteable.
You can update
view1 using the
UPDATE statement, and the changes will be applied to its base table. For example, the following statement changes the value of column
employee_id to 100 for records with the
name value of Mary in
table1 .
UPDATE view1 SET id='100' WHERE name = 'Mary';
An
insertable view allows you to execute the
INSERT statement against it. A view is insertable when all of its columns are updatable. For example,
view1 fits this rule. The following statement will insert a row into
table1 , which is the base table of
view1 .
INSERT INTO view1 VALUES ('200', 'Ben');
Figure 7.25 displays the contents of
table1 after executing the
INSERT statement on
view1 . Note that the
salary and
deptno columns for Ben contain NULL values because these two columns are not contained in
view1 .
table1 after inserting a row into
view1
If
table1 were defined such that NULL values were not allowed in one of the
salary or
deptno columns, the
INSERT statement would fail, and
view1 would not be an insertable view.
A
read-only view is not deleteable. In Figure 7.22, shown earlier,
view2 is a read-only view. Its read-only property is also stored in the SYSCAT.VIEWS table, which is shown in Figure 7.23.
NOTE
Even if a view is read-only,
INSERT, UPDATE , and
DELETE operations are still possible by using an
INSTEAD OF trigger. For more information, see section 7.13, Triggers.
You can define a view to selectively display a subset of rows of its base table by using the
WHERE clause in the
CREATE VIEW statement. To ensure that all the
INSERT and
UPDATE operations conform to the criteria specified in the
WHERE clause of the view, you can use the
WITH CHECK OPTION clause. For example, let's create the view
view3 derived from table
table1 (see Figure 7.22) as follows.
CREATE VIEW view3 (id, name,deptno)
AS SELECT employee_id, name, deptno
FROM table1
WHERE deptno = 101
WITH CHECK OPTION
If you issue a
SELECT * FROM view3 statement, you will obtain the following result:
ID NAME DEPTNO --- -------------------- ----------- 001 John 101 002 Mary 101
Only two rows are retrieved because these are the only rows that satisfy the
WHERE clause. What happens if you issue the following statement?
INSERT INTO view3 VALUES ('007','Shawn',201)
This statement fails because 201 does not conform to the criteria of the
WHERE clause used in the
CREATE VIEW definition, which is enforced because of
WITH CHECK OPTION . If
view3 had not been defined with this clause, the
INSERT statement would have succeeded.
Nested views are ones based on other views, for example:
CREATE VIEW view4
AS SELECT * FROM view3
In this example,
view4 has been created based on
view3 , which was used in earlier examples. The
WITH CHECK OPTION clause specified in
view3 is still in effect for
view4 ; therefore, the following
INSERT statement fails for the same reason it fails when inserting into
view3 .
INSERT INTO view4 VALUES ('007','Shawn',201)
When a view is defined with the
WITH CHECK OPTION clause, the search condition is propagated through all the views that depend on it.
![[View full size image]](/image/library/english/13748_07fig22_alt.jpg;382543){kind=link}
![[View full size image]](/image/library/english/13748_07fig24_alt.jpg;382543){kind=link}