Re: SUPPORT FOR DECLARATIVE TRANSITION CONSTRAINTS

On Sep 22, 12:46 pm, paul c <toledobythe..._at_oohay.ac> wrote:
> On 22/09/2010 6:52 AM, Brian wrote:
>
>
>
>
>
> > On Sep 22, 7:10 am, Erwin<e.sm..._at_myonline.be>  wrote:
> >> On 22 sep, 03:31, Brian<br..._at_selzer-software.com>  wrote:
> ...
> >>> 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.- Hide quoted text -
>
> >> - Show quoted text -
> > ... Your argument above is lacking because it
> > doesn't take into account that since P(t1) and P(t3) were judged to be
> > true at different times, P(t1) and P(t3) can mean the same thing at
> > different times, or different things at different times.  ...
>
> Heh, here we go again, more attacking mutant tuples, but thanks for a
> great example of undersimplification.  A database where two different
> propositions mean the same thing (no matter whether at the same time or
> at different times) is seriously nonsensical, likely laughable even to a
> layman, possibly dangerously unmaintainable and certainly over-priced.
> Redundant, anyone?- Hide quoted text -
>
> - Show quoted text -

The employee named paul c fills the position named toilet scrubber.

Let's look at the information conveyed by this statement:

1. there is an employee named 'paul c.'
2. there is a position named 'toilet scrubber.'
3. the named employee fills the named position.

also deny that there is an employee named paul c and that there is a position named toilet scrubber? Wouldn't the assertion of

(b) The employee named paul c fills the position named floor sweeper.

then also assert that there is an employee named paul c and a position named floor sweeper?

Can you prove that if both the denial of (a) and the assertion of (b) occur simultaneously whether or not the employee named paul c referenced in (a) is the employee named paul c in (b)?

Can you prove that paul c's position is in fact different? Isn't it possible that the position is the same--that is, that in addition to scrubbing toilets, paul c also swept floors--but the name has been changed for aestethic reasons? "Floor sweeper" sounds so much better than "toilet scrubber," doesn't it?

If, on the other hand, this

The employee named paul c who until now filled the position named toilet scrubber, now fills a different position named floor sweeper.

or this

The employee named paul c fills the position that was until now named toilet scrubber, but is now named floor sweeper.

or this

The employee named paul c who had until now filled the position named toilet scribber no longer does, but a different employee named paul c now fills the position named floor sweeper.

or this

The employee named paul c who had until now filled the position that was until now named toilet scrubber, but is now named floor sweeper and is now filled by a different employee who is named paul c.

were asserted, then there would no problem proving whether or not the employee named paul c in (a) is the employee named paul c in (b) and whether or not the position named toilet scrubber in (a) is the position named floor sweeper in (b). Received on Sat Sep 25 2010 - 22:41:19 CEST