"Cimode" <cimode (AT) hotmail (DOT) com> wrote

I would argue that it can only be when new information is submitted. A user
submits a set of deletes, updates and/or inserts that describe exactly which
tuples in base relations represent things that no longer exist, which tuples
in base relations represent things that differ in appearance, and which
tuples should now be in base relations because things have come into
existence. The point in time that that set of deletes, updates and/or
inserts is submitted is the time that constraints should be evaluated. The
set of deletes, updates and/or inserts can be packaged as a set of
relations, up to three for each relation schema involved, one for tuples
targeted by deletes, one for tuples targeted by updates and one for tuples
slated to be inserted. In this way, constraints can be declared in terms of
exactly what is different between the current database and a proposed
database, and the constraint engine need only be concerned with what is
different, which may obviate the need to materialize a virtual relation. I
think that most if not all constraints defined in terms of just the base
relations in the proposed database (state constraints) can be translated to
constraints defined in terms of what is being deleted, what is being updated
and what is being inserted, combined with the current database. Accesses to
the current database can be just plain index seeks, and the indexes that
need to be maintaned for constraint enforcement should be able to be
determined as a consequence of the constraints defined on the database. The
approach I would take to implementing constraints on relational expressions
would be to examine how a typical insert, update or delete or combination
thereof affects the result of the expression, to discover a deterministic
mechanism for translating the constraint so that it is defined in terms of
what is being deleted, what is being updated and what is being inserted.
For those expressions for which there isn't a translation, the result of the
expression would probably have to be materialized, at least partially.

one naturally the operations updating a relation body. However, I
discovered that constraints may play a role outside of that scope
because the representation scheme of the relation on a non direct
image system can actually allow to enforce it *once* at compile time.

To clarify...

Since relations de facto define types and decomposition is just
another term for relation subtyping, the process of building a subtype
is in fact the inheritance of a constraint set from the supertype
relation. Therefore, the declaration of a subtype in further
definitions is in fact an implicit declaration and enforcement of the
constraints. Starting from that, it is possible to design a system,
whose relation representation scheme would reflect the inheritance
relationship between the two relations by allowing the constraint to
be enforced through the storage mechanism itself. As a consequence of
that, the constraints are not enforced as a part of the traditional
execution process at the time of relation change but as a part of the
deisgn effort.

Your response has pointed out that the subject should have been
formulated otherwise. I think I am going to create a new thread.