Re: SUPPORT FOR DECLARATIVE TRANSITION CONSTRAINTS

On 22 sep, 03:31, Brian <br..._at_selzer-software.com> wrote:
> On Sep 21, 12:52 pm, Erwin <e.sm..._at_myonline.be> wrote:
>
>
>
>
>
> > states transition: {t1 t2} ---> {t3 t4}.
> > tuple transition: {t1--->t3   t2--->t4} gets accepted.
> > tuple transition: {t1--->t4   t2--->t3} gets rejected.
>
> > You explain that (the difference between the rejected update and the
> > accepted one) to a user (e.g., me) without having to resort to
> > explanations that really are tuple-level.  That is, without using the
> > word 'tuple', and relying exclusively on words such as 'set' and
> > 'relation'.- Hide quoted text -
>
> > - Show quoted text -
>
> You haven't provided enough information to make that possible.

Yes, I have, as I will show.

> Constraints are a matter of semantics--that is, what the data means.

And what the data means is the logical conjunction of the propositions that the tuples represent, or in my abstract example, "P(t1) AND P(t2)", and "P(t3) AND P(t4)", respectively, and this regardless of what the P() is.

Nothing less, and most certainly nothing more. And I do not need to specify the predicate for that claim to be true.

Meaning that the transition itself, is not part of the semantics of the database. Meaning that transition constraints are, contrary to what you claim, NOT about semantics. And therefore NOT about business rules either.

Also meaning that if you have one possible transition from "P(t1) AND P(t2)" to "P(t3) AND P(t4)" that gets rejected, and another one from "P(t1) AND P(t2)" to "P(t3) AND P(t4)" that gets accepted, then that means that your model is driven by something more than merely semantics, and that in turn means that your model is flawed. Received on Wed Sep 22 2010 - 13:10:51 CEST