Purpose of Views
The view mechanism is desirable for several reasons:
n It provides a powerful and flexible security mechanism by hiding parts of the database
from certain users. Users are not aware of the existence of any attributes or tuples that
are missing from the view.
n It permits users to access data in a way that is customized to their needs, so that the same
data can be seen by different users in different ways, at the same time.
n It can simplify complex operations on the base relations. For example, if a view is
defined as a combination (join) of two relations (see Section 4.1), users may now perform
more simple operations on the view, which will be translated by the DBMS into
equivalent operations on the join.
A view should be designed to support the external model that the user finds familiar. For
example:
n A user might need Branch tuples that contain the names of managers as well as the other
attributes already in Branch. This view is created by combining the Branch relation with
a restricted form of the Staff relation where the staff position is ‘Manager’.
n Some members of staff should see Staff tuples without the salary attribute.
n Attributes may be renamed or the order of attributes changed. For example, the user
accustomed to calling the branchNo attribute of branches by the full name Branch Number
may see that column heading.
n Some members of staff should see only property records for those properties that they
manage.
Although all these examples demonstrate that a view provides logical data independence
(see Section 2.1.5), views allow a more significant type of logical data independence
that supports the reorganization of the conceptual schema. For example, if a new
attribute is added to a relation, existing users can be unaware of its existence if their views
are defined to exclude it. If an existing relation is rearranged or split up, a view may be
defined so that users can continue to see their original views. We will see an example of
this in Section 6.4.7 when we discuss the advantages and disadvantages of views in more
detail.
Updating Views
All updates to a base relation should be immediately reflected in all views that reference
that base relation. Similarly, if a view is updated, then the underlying base relation should
reflect the change. However, there are restrictions on the types of modification that can be
made through views. We summarize below the conditions under which most systems
determine whether an update is allowed through a view:
n Updates are allowed through a view defined using a simple query involving a single
base relation and containing either the primary key or a candidate key of the base
relation.
n Updates are not allowed through views involving multiple base relations.
n Updates are not allowed through views involving aggregation or grouping operations.
Classes of views have been defined that are theoretically not updatable, theoretically
updatable, and partially updatable. A survey on updating relational views can be found
in Furtado and Casanova (1985).
The view mechanism is desirable for several reasons:
n It provides a powerful and flexible security mechanism by hiding parts of the database
from certain users. Users are not aware of the existence of any attributes or tuples that
are missing from the view.
n It permits users to access data in a way that is customized to their needs, so that the same
data can be seen by different users in different ways, at the same time.
n It can simplify complex operations on the base relations. For example, if a view is
defined as a combination (join) of two relations (see Section 4.1), users may now perform
more simple operations on the view, which will be translated by the DBMS into
equivalent operations on the join.
A view should be designed to support the external model that the user finds familiar. For
example:
n A user might need Branch tuples that contain the names of managers as well as the other
attributes already in Branch. This view is created by combining the Branch relation with
a restricted form of the Staff relation where the staff position is ‘Manager’.
n Some members of staff should see Staff tuples without the salary attribute.
n Attributes may be renamed or the order of attributes changed. For example, the user
accustomed to calling the branchNo attribute of branches by the full name Branch Number
may see that column heading.
n Some members of staff should see only property records for those properties that they
manage.
Although all these examples demonstrate that a view provides logical data independence
(see Section 2.1.5), views allow a more significant type of logical data independence
that supports the reorganization of the conceptual schema. For example, if a new
attribute is added to a relation, existing users can be unaware of its existence if their views
are defined to exclude it. If an existing relation is rearranged or split up, a view may be
defined so that users can continue to see their original views. We will see an example of
this in Section 6.4.7 when we discuss the advantages and disadvantages of views in more
detail.
Updating Views
All updates to a base relation should be immediately reflected in all views that reference
that base relation. Similarly, if a view is updated, then the underlying base relation should
reflect the change. However, there are restrictions on the types of modification that can be
made through views. We summarize below the conditions under which most systems
determine whether an update is allowed through a view:
n Updates are allowed through a view defined using a simple query involving a single
base relation and containing either the primary key or a candidate key of the base
relation.
n Updates are not allowed through views involving multiple base relations.
n Updates are not allowed through views involving aggregation or grouping operations.
Classes of views have been defined that are theoretically not updatable, theoretically
updatable, and partially updatable. A survey on updating relational views can be found
in Furtado and Casanova (1985).
No comments: