Views: Limiting Access to Data A view is a named select statement that is stored in a database as an object. It allows you to view a subset of rows or columns in one or more tables. You can use the view by invoking its name in other Transact-SQL statements. You can use views to focus, simplify, and customize each user’s perception of the tables in a particular database. Views also provide a security mechanism by allowing users access only to the data they require.

How views work A view is an alternative way of looking at the data in one or more tables. For example, suppose you are working on a project that is specific to the state of Utah. You can create a view that lists only the authors who live in Utah: create view authors_ut as select * from authors where state = ‘UT’ To display the authors_ut view, enter: select * from authors_ut

How views work A view is derived from one or more real tables whose data is physically stored in the database. The tables from which a view is derived are called its base tables or underlying tables. A view can also be derived from another view. The definition of a view, in terms of the base tables from which it is derived, is stored in the database. No separate copies of data are associated with this stored definition. The data that you view is stored in the underlying tables.

How views work A view looks exactly like any other database table. You can display it and operate on it almost exactly as you can any other table. There are no restrictions at all on querying through views and fewer than usual on modifying them. The exceptions are explained later in this chapter. When you modify the data in a view, you are actually changing the data in the underlying base tables. Conversely, changes to data in the underlying base tables are automatically reflected in the views that are derived from them.

Advantages of views You can use views to: Focus on the data that interests them and on the tasks for which they are responsible. Data that is not of interest to a user can be left out of the view. Define frequently used joins, projections, and selections as views so that users do not have to specify all the conditions and qualifications each time an operation is performed on that data. Display different data for different users, even when they are using the same data at the same time. This advantage is particularly important when users of many different interests and skill levels share the same database.

Advantages of views You can use views to: Through a view, users can query and modify only the data they can see. The rest of the database is neither visible nor accessible. Access can be restricted to a subset of the rows of a base table, that is, a value-dependent subset. For example, you might define a view that contains only the rows for business and psychology books, in order to keep information about other types of books hidden from some users.

Advantages of views You can use views to: Access can be restricted to a subset of the columns of a base table, that is, a value- independent subset. For example, you might define a view that contains all the rows of the titles table, except the royalty and advance columns. Access can be restricted to a row-and-column subset of a base table. Access can be restricted to a statistical summary of data in a base table. For example, through the view category_price a user can access only the average price of each type of book.

Advantages of views You can use views to: Access can be restricted to 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 to display the names of the authors and the books they have written. This view would hide personal data about authors and financial information about the books. Access can be restricted to a row-and- column subset of a base table.

Logical data independence Views can shield users from changes in the structure of the real tables if such changes become necessary. For example, suppose you restructure the database by using select into to split the titles table into these two new base tables and then dropping the titles table: titletext (title_id, title, type, notes) titlenumbers (title_id, pub_id, price, advance, royalty, total_sales, pub_date)

Logical data independence The old titles table can be “regenerated” by joining on the title_id columns of the two new tables. You can create a view that is a join of the two new tables. You can even name it titles. Any query or stored procedure that previously referred to the base table titles now refers to the view titles.

View examples The first example is a view derived from the titles table. Suppose you are interested only in books priced higher than $15 and for which an advance of more than $5000 was paid. create view hiprice as select * from titles where price > $15 and advance > $5000

View examples When Server receives this command, it does not actually execute the select statement that follows the keyword as. Instead, it stores the select statement, which is the definition of the view hiprice, in the system table syscomments. Entries are also made in sysobjects and in syscolumns for each column included in the view. When you display or operate on hiprice, Server combines your statement with the stored definition of hiprice. For example, you can change all the prices in hiprice just as you can change any other table: update hiprice set price = price * 2

Creating Views Here is the full syntax for create view: create view [owner.]view_name [(column_name [, column_name ]...)] as select [distinct] select_statement [with check option] Here is a view definition statement that makes the name of a column in the view different from its name in the underlying table: create view pub_view1 (Publisher, City, State) as select pub_name, city, state from publishers Here is an alternate method of creating the same view but renaming the columns in the select statement: create view pub_view2 as select Publisher = pub_name, City = city, State = state from publishers

Using the select statement with create view You can create a view using more than one table and other views by using a select statement of any complexity. There are a few restrictions on the select statements in a view definition: You cannot include order by or compute clauses. You cannot include the into keyword. You cannot reference a temporary table. View definition with projection : To create a view with all the rows of the titles table, but with only a subset of its columns, enter: create view titles_view as select title, type, price, pubdate from titles

Using the select statement with create view View definition with a computed column: Here is a view definition statement that creates a view with a computed column generated from the columns price, royalty, and total_sales: create view accounts (title, advance, amt_due) as select titles.title_id, advance, (price * royalty /100) * total_sales from titles, roysched where price > $15 and advance > $5000 and titles.title_id = roysched.title_id and total_sales between lorange and hirange

Using the select statement with create view View definition with an aggregate or built-in function: A view definition that includes an aggregate or built-in function must include column names in the create clause. For example: create view categories1 (category, average_price) as select type, avg(price) from titles group by type You can create a view derived from more than one base table. Here is an example of a view derived from both the authors and the publishers tables. The view contains the names and cities of the authors that live in the same city as a publisher, along with each publisher’s name and city. create view cities (authorname, acity, publishername, pcity) as select au_lname, authors.city, pub_name, publishers.city from authors, publishers where authors.city = publishers.city

Validating a view’s selection criteria using with check option Normally, Server does not check insert and update statements on views to determine whether the affected rows are within the scope of the view. A statement can insert a row into the underlying base table, but not into the view, or change an existing row so that it no longer meets the view’s selection criteria. When you create a view using the with check option clause, each insert and update through the view, is validated against the view’s selection criteria. All rows inserted or updated through the view must remain visible through the view, or the statement fails.

Validating a view’s selection criteria using with check option Here is an example of a view, stores_ca, created using with check option. This view includes information about stores located in California, but excludes information about stores located in any other state. The view is created by selecting all rows from the stores table for which state has a value of ‘CA’: create view stores_ca as select * from stores where state = "CA" with check option When you try to insert a row through stores_ca, Adaptive Server verifies that the new row falls within the scope of the view. The following insert statement fails because the new row would have a state value of “NY”, rather than “CA”: insert stores_ca values ("7100", "Castle Books", "351 West 24 St.", "New York", "NY", "USA", "10011", "Net 30")

Retrieving data through views When you retrieve data through a view, Server checks to make sure that all the database objects referenced anywhere in the statement exist and that they are valid in the context of the statement. If the checks are successful, Server combines the statement with the stored definition of the view and translates it into a query on the view’s underlying tables. This process is called view resolution. Consider the following view definition statement and a query against it: create view hiprice as select * from titles where price > $15 and advance > $5000 select title, type from hiprice where type = "popular_comp" select title, type from titles where price > $15 and advance > $5000 and type = ‘popular_comp’

Modifying data through views Rules for data modification operations: update, insert, or delete operations that refer to a computed column or a built-in function in a view are not allowed. update, insert, or delete operations that refer to a view that includes aggregates or row aggregates are not allowed. insert, delete, and update operations that refer to a distinct view are not allowed. insert statements are not allowed unless all NOT NULL columns in the underlying tables or views are included in the view through which you are inserting new rows. Server has no way to supply values for NOT NULL columns in the underlying objects.

Modifying data through views If a view has a with check option clause, all rows inserted or updated through the view (or through any derived views) must satisfy the view’s selection criteria. delete statements are not allowed on multitable views. insert statements are not allowed on multitable views created with the with check option clause. update statements are allowed on multitable views where with check option is used. The update fails if any of the affected columns appears in the where clause, in an expression that includes columns from more than one table. insert and update statements are not allowed on multitable distinct views. If you insert or update a row through a multitable view, all affected columns must belong to the same base table.

Restrictions on updating views Computed columns in a view definition: This restriction applies to columns of views that are derived from computed columns or built-in functions. For example, the amt_due column in the view accounts is a computed column. create view accounts (title_id, advance, amt_due) as select titles.title_id, advance, (price * royalty/100) * total_sales from titles, roysched where price > $15 and advance > $5000 and titles.title_id = roysched.title_id and total_sales between lorange and hirange updates and inserts to the amt_due column are not allowed because there is no way to deduce the underlying values for price, royalty, or year-to-date sales from any value you might enter in the amt_due column. delete operations do not make sense because there is no underlying value to delete.

Restrictions on updating views group by or compute in a view definition: This restriction applies to all columns in views that contain aggregate values that is, views whose definition includes a group by or compute clause. Here is a view defined with a group by clause and the rows seen through it: create view categories (category, average_price) as select type, avg(price) from titles group by type select * from categories category average_price

Getting information about views

Using sp_helptext to display view information To display the text of the create view statement, execute sp_helptext: sp_helptext hiprice (1 row affected) text create view hiprice as select * from titles where price > $15 and advance > $5000 (1 row affected, return status = 0)