Significado, alcance e importancia de la decisión de la Unesco.

Note that although views are a useful tool for queries, they present significant problems if we allow updates, insertions or deletions to be performed on views. The difficulty comes from the fact that a modification to the database expressed in terms of a view must be translated to a modification to the actual relations in the logical model of the database. As a simplest example, let us consider a view involving one relation only. Consider a relational schema S_info = (SID, major, GPA) with F = {SID → major, SID

→ GPA}. Apparently SID is the key. A view is constructed with schema S1 = {major, GPA}, which is a virtual relation with SID removed from S_info. Suppose S1 consists of two tuples: {(CS, 3.5), (MIS, 3.6)}. (Here we use the predicate format to represent a relation.) Now assume a user wants to insert a tuple (Math, 2.8) into S1. This request should be translated into an insert of tuple (?, Math, 2.8) into S_info. Note the question mark ? stands for a null value, because SID is not specified in the user's request. If we do allow this insert operation to occur, we will end up with a new tuple in S_info which does not have the primary key. Apparently this is a scenario we should avoid. For this reason, modification through views should be carried out carefully. Commercial products may disallow modification through views entirely (or only provide mechanism to allow modification through only one view).

The above discussion is concerned with a more general topic, namely, the consideration of integrity constraints. In fact, integrity constraints are an important concern for stored relations as well. In general, integrity constraints (ICs) provide a means of ensuring that changes made to the database by authorized users do not result in a loss of data consistency. There are several forms of ICs. One important form of IC is called referential integrity, and will be discussed in the next section. Other forms include domain constraints, assertions, triggers, functional and other forms of dependencies.

• Functional dependencies are a very important form of IC and are a very important factor which affects relational database design. Among other things, functional dependencies can be used to determine the primary key of a relation. A key (or superkey) in a relation is a set of attributes which uniquely determines the values of all attributes. As a simple intuitive example, in a student relation with schema (name, ID, major, GPA), the name or ID of a student should determine all the attributes (assuming names and IDs are all unique). Therefore, student name is a key, and ID is another key. Note also that a key combined with any other attributes is still a key. For example, name combined with major is a key. Therefore, it makes sense to define the concept of candidate key, which refers to a set of attributes which uniquely determine the value of other attributes, and if any attribute is removed from the candidate key, it will no longer be a key. Apparently, candidate key may not be unique; for example, student name and ID are two candidate keys. Therefore, there is a need to define the concept of primary key, which is the designated candidate key actually used by the database designer. In our example either student

name or ID can be designated as the primary key. Concepts related to keys and functional dependencies play important roles in relational database design, and will be discussed in the next section.

• Referential integrity refers to a particular kind of integrity constraint to ensure data consistency. It is concerned with the situations in which change in a relation may affect other relations; it usually involves foreign keys. For example, consider a relation for course registration in a university database. If a previously planned course is to be dropped, all the tuples in the registration relation referring that course should be dropped as well. It is therefore important to preserve the referential- integrity constraint. We will revisit this issue in Section 4.6.6.

• An assertion is a predicate expressing a condition that we wish the database to always satisfy; it may involve several relations.

• Triggers (active rules): A trigger is a statement that is executed automatically by the system as a side effect of a modification to the database. An active rule consists of condition and action. An active database is equipped with active rules, and can be considered as a special form of knowledge-based system.

In general, an integrity constraint is a clause of the form false :- a1, … ak,

where commas denote "and," the ai's are atoms and false is a special atom that is false in all interpretations.

At the first sight, one may think ICs may have very limited usefulness, they turn out to be a very powerful tool. In databases, there are often constraints that the designer of a database knows should never be violated. If a database ever violates an IC, an error message should be displayed, and the offending clauses should be identified. In a relational database, integrity constraints are assertions database instances that are compelled to obey. Therefore, ICs play an important role in agent-based database problem solving. To illustrate, we consider the following two types of integrity constraints.

(a) An IC specifies that some conjunction of conditions should never be true of a database; for example, that no instructor should have taught a graduate-only course and a freshman course in the same semester at the same time slot 4:00pm - 5:15pm, Monday and Wednesday.

(b) An IC specifies that some condition should always be provable when another is; for example, a payment should be made to an employee at the end of each month

4.6

FUNCTIONAL DEPENDENCIES

Integrity constraints play an important role in relational database design. Although this book is not intended for a theoretical study of this topic, we will study several important forms of integrity constraints, including functional dependencies.