The Logic of Database Integrity
To ensure that no row in the database represents a logically false proposition, each table in the database must be capable of evaluating its own predicate, or relvar, for its truth value, and the only way it can enforce this integrity is to enforce the set of business rules defined by the enterprise it supports. In practice, this means that the predicate for any table is its sole criterion for update acceptability (McGoveran and Date, 1994). From this, it follows that the formal meaning of any table is defined by the logical ANDing of its component column and table constraints. This logically ANDed constraint set is also the best approximation the database management system can make to any table predicate.
From this, it follows that the meaning of an entire database, its predicate, can be represented formally as the logical ORing of its table constraints logically ANDed with the set of all database constraints.
Although most workers in database management are not familiar with this treatment of databases as systems of logical constraints, the concept is at least as old as the paper of Kanellakis et al. (1990), which is usually credited with being the foundation paper for the concept of constraint databases (see, for example, Gunther et al., 1997; Kuijpers and Revesz, 2004; Kuper and Wallace, 1996; Kuper et al., 2000; Ramakrishnan and Stuckey, 1997; Revesz, 2002).