SQL/MP Installation and Management Guide

Creating a Database
HP NonStop SQL/MP Installation and Management Guide—523353-004
5-38
Creating Views of Base Tables
This example shows security that enables any network user to read or write to a table.
Only the development manager (user 100, 255) has the authority to perform the listed
DDL operations. Although the security gives read, write, and purge access to additional
users, the DDL statements, except DROP TABLE, require ownership of the table. Any
user in group 100 can drop the table.
$VOL2.APPLTAB.TABLE2 Owner = 100,255
Security = "NNOG"
Creating Views of Base Tables
To create a view, use the CREATE VIEW statement. CREATE VIEW statements
enable you to define new column names for a view, instead of using the column names
from the underlying tables. When using the view, applications use the view-defined
column names. Applications can also use views to rename, reorder, and project
subsets of columns from one or more base tables. For background information about
views, see Using Views on page 3-13.
Before you create views for your database, see the SQL/MP Query Guide for
information about formulating queries.
Creating a Protection View
A protection view is a view that has only one underlying table and is defined with the
PROTECTION attribute. The view can be a projection of columns or a selection of
rows from the underlying table, or both. The rows in a protection view are accessible
by applications for read, insert, update, and delete operations. A protection view can
be secured for read, write, execute, and purge access.
If you plan to use similarity checking with a protection view, be sure to use the
CREATE VIEW statement’s SIMILARITY CHECK ENABLE clause.
Security Guidelines for Protection Views
These guidelines apply to securing protection views:
•
A protection view can have only a single underlying table. You must put a
protection view on the same volume as its underlying table and register the view in
the same catalog as the table.
•
To create a protection view, you must have read, write, and purge authority for the
underlying table and write authority for the catalog in which the underlying table is
registered. You must also be the local owner of the underlying table or a remote
owner with authority to purge the table.
•
The owner of a protection view is always the same as the owner of the underlying
table.
•
The security string of a protection view has these dependencies on the underlying
table: