The fact that the design of Example 12 from the previous section is redundant is clearly shown by the fact that the specified equality dependency holds (constraint C12). And there are, at least in principle, four basic approaches to dealing with the kind of redundancy illustrated by that example:
Raw design only
Declare the constraint
Use a view
Use a snapshot
Let’s take a closer look.
This is perhaps the approach most likely to be encountered in practice, given the limited functionality provided by most of today’s DBMS implementations. The idea is simply that:
Relvars PAYMENTS and TOTALS are defined exactly as shown in the previous section.
Constraint C12 is not declared to the DBMS.
Maintaining the derived data is the user’s responsibility one hundred percent. (Or some user’s responsibility, at any rate; the maintenance might be done by means of a triggered procedure, but some user still has to write the code for that procedure.)
In effect, this approach trades off (a) the extra work involved on the part of the user—or some user, at any rate—in executing certain updates (as well as the associated performance hit) against (b) the improved performance obtained when executing certain queries. But there are no guarantees; if the user makes a mistake during some update that (in effect) causes Constraint C12 to be violated, well, tough.
In this approach Constraint C12 is explicitly declared to the DBMS and the DBMS takes the responsibility ...