Filter
Top Products
CHAPTER 10 Managing User IDs and Permissions
371
TO SalesManager
Exactly the same command is used to grant permission on a view as to
grant permission on a table.
Example 2
The next example creates a view which allows the Sales Manager to look at a
summary of sales orders. This view requires information from more than one
table for its definition:
1 Create the view.
CREATE VIEW order_summary AS
SELECT order_date, region, sales_rep, company_name
FROM "DBA".sales_order
KEY JOIN "DBA".customer
2 Grant permission for the Sales Manager to examine this view.
GRANT SELECT
ON order_summary
TO SalesManager
3 To check that the process has worked properly, connect to the
SalesManager user ID and look at the views you have created:
CONNECT SalesManager IDENTIFIED BY sales ;
SELECT * FROM "DBA".emp_sales ;
SELECT * FROM "DBA".order_summary ;
No permissions have been granted to the Sales Manager to look at the
underlying tables. The following commands produce permission errors.
SELECT * FROM "DBA".employee ;
SELECT * FROM "DBA".sales_order;
Other permissions on
views
The previous example shows how to use views to tailor SELECT permissions.
INSERT, DELETE, and UPDATE permissions can be granted on views in the
same way.
For information on allowing data modification on views, see “Using views”
on page 129.
Using procedures for tailored security
While views restrict access on the basis of data, procedures restrict the actions
a user may take. As described in “Granting permissions on procedures” a user
may have EXECUTE permission on a procedure without having any
permissions on the table or tables on which the procedure acts.