In the first course in this series, you looked at requirements analysis
in the context of initial database design culminating in the creation of a normalized (to 1NF) ER diagram.
Requirements analysis 
does not stop there. It is an ongoing process, which includes determining the smallest set of permissions users need to do their job. The best way to define which permissions users need is to sit down with their supervisors and review their job descriptions. Determine what information they will need to use, what information (if any) they will need to change, and what information (if any) they will need to delete. If users need to analyze table data independently, then they may require the Reference permission.
There are three good reasons to include views in the design of a database:
- As mentioned earlier, views provide a significant security mechanism by restricting users from viewing portions of a schema to which they should not have access.
- Views can simplify the design of a database for technologically unsophisticated users.
- Because views are stored as named queries, they can be used to store frequently used, complex queries. The queries can then be executed by using the name of the view in a simple query.
Like other structural elements in a relational database, views can be created and destroyed at any time. However, because views do not contain stored data but only specification of a query that will generate a virtual table, adding or removing view definitions has no impact on base tables or the data they contain. Removing a view will create problems only when that view is used in an application program and the program is not modified to work with a different view or base table.
The next lesson wraps up this module.