Re: On specialization constraints time of application

"Cimode" <cimode_at_hotmail.com> wrote in message news:74a3cb84-8694-4954-9bb9-a56a8ccb584f_at_f19g2000yqo.googlegroups.com...
> On 14 juin, 11:28, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> > "Cimode" <cim..._at_hotmail.com> wrote in message
> >
> > news:af92f612-e800-46b2-bc0d-707c231daf61_at_r10g2000yqa.googlegroups.com...
> >
> > <snip>
> >
> > > Interesting. However, I am not working at the moment in the layer of
> > > RM.
> >
> > I understand.
>
> Thank you. To clarify further...
>
> The point of the post was to point out a important question to be
> answered when designing a relation operating engine. The question is
> about the timing at which constraints are to be implemented.

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.

> At the
> moment, I implement constraints at compile time comes the problem of
> implementing constraints on virtual relvar representation. Since
> these are represented at run time only, I was wandering if anybody had
> feedback on that matter.
>
> But thanks for bringing some insight on missing information.
Received on Mon Jun 15 2009 - 17:31:33 CEST