Re: On specialization constraints time of application

> 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.
There is no denying (or argument) that when one thinks of constraints 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. Received on Tue Jun 16 2009 - 09:44:27 CEST