As the relational model has matured, careful analysis has continued to reveal facets of its definition that are obvious in hindsight, but had remained undiscovered and unstated until recently. An important example of such a revelation of the obvious is the relation variable, or relvar.
Relations, as defined in set theory, do not vary over time. A relation is a value, and values do not vary as a function of time. The number 3, for example, is always the number 3, and never 2 or 13 or 724.
Variables assume different values as a function of time. That is, the value of a relation variable changes as a function of time.
The distinction between a relation variable and its associated relation value is an important one because without it, the application of the axioms of traditional set theory to database relations is suspect at best. That set theory deals entirely with extensional sets: a set is determined entirely by its population. There is simply no notion of a set with changing population; each different population constitutes a different set.”
In the context of business rules and their relationship with integrity constraints, the concept of the relvar provides a formal, yet simple, framework in which to situate the idea of integrity constraints. The relvar concept applies equally well to views (virtual relvars) and base tables (base relvars).
The first principle captured by the concept of the relvar is that the value of a relation is unrelated to its defining variable. The easiest way to explain this is by analogy. A variable in a programming language represents the possible values that the variable can have, but the variable itself is not those values. The variable is a place holder for those values. The values represented by the variable can have multiple values, but the variable itself is an abstraction.
Think of a relvar as the heading definition for the attributes of a relation: the ANDing of all column headings, including their constraints, defined for the relation. Logically, a relvar is the predicate for a relation. More specifically, a relvar is the internal predicate for a relation.
The real world that relvar represents is its external predicate. Any lack of correspondence between the external and internal predicates for a relvar is the defining characteristic of the data quality issue (see the introduction to this section for more information) and the inspiration for the maxim that a database can only enforce consistency, not truth. Unless otherwise stated, the phrase relvar predicate refers to the internal relvar predicate in this document, while each individual instantiation of that relvar, a tuple (or row), is a proposition for that predicate that evaluates to TRUE.
The relation value is the net value of all data contained by the relation. Each time the relation is updated, its value changes, but its relation variable does not. A relation becomes an entirely new relation when an update occurs, but its relation variable does not change.
For example, consider the following equation:
x + y = 7
If you set the variable x=4, then the value for variable y must be 3. If you then change the value of the variable x to 3, you have updated x, but you have not changed the value of 4 to 3, you have only changed the value of the variable x from 4 to 3. This holds for any other valid number over the domain of x. Another way to think of this is as follows: values are not time-varying. A 3 is always a 3 and never a 4. A variable can represent any number of values over the course of time. An old joke also shows this point by confusing variables with values: "Do you realize that 2 + 2 = 5 for large values of 2?"
The integrity of this update relationship is maintained by the relvar predicate, which is defined by the logical ANDing of all the integrity constraints defined on the relation in question. The result of enforcing the relvar predicate is what Date and Darwen (1998, 2000) call The Golden Rule: no statement can leave any relvar with a value that violates its relvar predicate. Therefore, no update operation can ever cause any database constraint to evaluate to FALSE. That is, the integrity of the database cannot be violated. The Golden Rule is one of the fundamental principles of relational database theory.
Therefore, tuples (rows) are instantiations of the relvar predicate that represent propositions about the relation the tuples constitute. When you think of a row as a proposition, the row must also be a true proposition because, by definition, false propositions (wrong, or corrupt data in everyday language) are not permitted in a database that enforces integrity constraints. That is, if a given tuple is an element of a specific relvar, then that tuple satisfies its predicate by evaluating to TRUE.
Unfortunately, the representation of the real world by a database is only as good as its input, and any database allows the insertion of factually wrong data if that data does not violate the constraints specified for the base table or view through which the table is updated (see Sources of Data Quality Problems. That is, a database can only enforce consistency, not truth. All truths are consistent, but not all consistent things are true.
The database cannot know whether its information corresponds to real world facts (see Sources of Data Quality Problems), but can use constraints to make sure that incoming data does not violate business rules. These constraints provide the mechanism for enforcing the data integrity rules of relational database management systems.