Through a view, users can query and modify only the data they can see. The rest of the database is neither visible nor accessible.
Permission to access the view must be explicitly granted or revoked, regardless of the permissions on the view’s underlying tables. If the view and underlying tables are owned by the same owner, no permissions need to be given to the underlying tables. Data in an underlying table that is not included in the view is hidden from users who are authorized to access the view but not the underlying table.
By defining different views and selectively granting permissions on them, a user (or any combination of users) can be restricted to different subsets of data. Access can be restricted to:
A subset of the rows of a base table (a value-dependent subset). For example, you might define a view that contains only the rows for business and psychology books to keep information about other types of books hidden from some users.
A subset of the columns of a base table (a value-independent subset). For example, you might define a view that contains all the rows of the titles table, but omits the price and advance columns, since this information is sensitive.
A row-and-column subset of a base table.
The rows that qualify for a join of more than one base table. For example, you might define a view that joins the titles, authors, and titleauthor tables. This view would hide personal data about authors and financial information about the books.
A statistical summary of data in a base table. For example, you might define a view that contains only the average price of each type of book.
A subset of another view, or of some combination of views and base tables.
Let’s say you want to prevent some users from accessing the columns in the titles table that display money and sales amounts. You could create a view of the titles table that omits those columns, and then give all users permission on the view but only the Sales Department permission on the table:
grant all on bookview to public
grant all on titles to sales
An equivalent way of setting up these privilege conditions, without using a view, is to use the following statements:
grant all on titles to public
revoke select, update on titles (price, advance,
total_sales)
from public
grant select, update on titles (price, advance,
total_sales)
to sales
One possible problem with the second solution is that users not in the sales group who enter the select * from titles command might be surprised to see the message that includes the phrase:
permission denied
Adaptive Server expands the asterisk into a list of all the columns in the titles table, and since permission on some of these columns has been revoked from non-sales users, access to these columns is denied. The error message lists the columns for which the user does not have access.
To see all the columns for which they do have permission, the non-sales users would have to name them explicitly. For this reason, creating a view and granting the appropriate permissions on it is a better solution.
You can also use views for context-sensitive protection. For example, you can create a view that gives a data entry clerk permission to access only those rows that he or she has added or updated. To do so, add a column to a table in which the user ID of the user entering each row is automatically recorded with a default. You can define this default in the create table statement, like this:
create table testtable (empid int, startdate datetime, username varchar(30) default user)
Next, define a view that includes all the rows of the table where uid is the current user:
create view context_view as select * from testtable where username = user_name() with check option
The rows retrievable through this view depend on the identity of the person who issues the select command against the view. By adding with check option to the view definition, you make it impossible for any data entry clerk to falsify the information in the username column.
