Beginning SQL

check constraints can be used in a similar manner. Because check constraints do not expose data to viewing,
update, and deletion, they are often treated differently by the DBMS when it comes to security.
Thus, a user could include tables and fields in a check constraint to which he otherwise wouldn’t have
access. This opens up a similar security hole in that a user could try different values in a check constraint
to discover the values of a field that he isn’t supposed to be able to see.
To eliminate this hole in security, the REFERENCES keyword was added. The REFERENCES privilege is
assigned to specific rows of tables. Unless assigned a REFERENCES privilege, a user cannot reference that
column in that table in any manner.
The USAGE Privilege
The USAGE privilege is used to control access to domains, or the sets of legal values in a given column, as
well as user-defined character sets, translations, and collating sequences. USAGE is a simple true/false
property that says a user has access to one of these objects for individual user ID. This privilege is aimed
at the corporate developer more than the individual database user.
Ownership
When you create a table in SQL using the CREATE TABLE statement, you become the owner of that table
and control security on that table. You have full privileges for SELECT, INSERT, DELETE, and UPDATE for
that table. You also are able to grant privileges to that table to other user IDs. In fact, other users have no
privileges on that table until you specifically grant those privileges to those users.
The situation for views is a little different, however. In order to create a view, you must have specific
privileges on the table or tables from which you pull data. You must at least have SELECT privileges to
the underlying tables. Thus, the DBMS automatically gives you SELECT privileges to the resulting view.
The other privileges (INSERT, DELETE, and UPDATE) depend on your privileges in the underlying tables
for the view, and you must have each privilege for every table in the view before you are granted that
privilege in the resulting view. Furthermore, you can grant privileges to other user IDs for the view only
if you have been granted the privilege to grant those privileges. You learn about granting privileges in a
later section of this chapter, but first you learn more about the relationship between views and security.
Views and Security
Views are often used to enforce security on viewing data. By creating views that display specific columns
from specific tables, a user can be granted SELECT privileges for that view but not for the underlying
table. Using this strategy makes it possible to determine exactly what information a specific user is
allowed to view.
Vertical and Horizontal Views
Vertical views represent select columns of one or more tables such that the user can see only portions of a
table or tables. This allows you to hide sensitive data columns from certain users while allowing access
to those columns to other users.
For example, suppose you had a business rule that states that employees in the Personnel department
should be able to see the names and addresses of all employees, but not the SSN or salary. You might
implement this view with a SQL statement similar to the following:
CREATE VIEW vEmployeeNonSensitive AS
SELECT Name, Address, City, State, ZIP, Phone FROM tblEmployees
SQL Security
337