Re: ID field as logical address

From: Brian Selzer <brian_at_selzer-software.com>
Date: Thu, 4 Jun 2009 23:12:53 -0400
Message-ID: <W20Wl.25182$as4.14010_at_nlpi069.nbdc.sbc.com>


"JOG" <jog_at_cs.nott.ac.uk> wrote in message news:467475e3-b073-43a7-bd8e-c02325090071_at_b1g2000vbc.googlegroups.com...
> On Jun 3, 2:06 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> > I disagree. It is my contention that each tuple in a
> > database--regardless
> > of whether it is in a base or a derived relation--maps to some thing in
> > the
> > Universe of Discourse but no two tuples in the same database map to
> > exactly
> > the same thing. When presented with a proposed database, there must be
> > some
> > mechanism to correlate the things that each tuple in the current
> > database
> > maps to with the things that each tuple in the proposed database maps
> > to.
> > Keys are not sufficient because their scope is /each/ possible relation
> > for
> > a relation schema instead of /every/ possible relation.
> > In the example, this is evidenced by the fact that the Mary Smith at one
> > database may not be the Mary Smith at its successor.
> > As a consequence, a join of a relation in
> > the proposed database to its corresponding relation in the current
> > database
> > would compare the appearances of two different people instead of two
> > appearances of the same person. It is only when every instance of every
> > key
> > permanently identifies some thing in the Universe that such a join can
> > be
> > considered valid, and that severely limits the expressiveness of the
> > model.
> > If, on the other hand, we simply make use of the information supplied by
> > the
> > user when they issue deletes, inserts and updates, then there is no need
> > for
> > the join because the requisite correlation of old to new values is in
> > fact
> > supplied.
> >
> > <snip>
>
> Ahhh, the fun me and Brian used to have, arguing about this till we
> were blue in the face. Why, it warms my cockles to see new people
> taking over the mantle! For those posters, who continue to fight the
> good fight, I always held that his examples were simply of flawed
> schema designs (and excellent examples at that, but merely ones where
> the DDL chosen was insufficient to model the world he was
> considering). For instance, in the 'divorcee' example, I'm sure most
> can see that a name is neither unique nor stable enough to identify a
> person in real life, never mind within the RM. So its hardly a shock
> when the database breaks down because of that bad key choice.
>

This is another example of the noise I referred to earlier. Out of respect for him and those fun arguments we had, I will sketch out another example just to illustrate that the problems with Date and Darwen's notions are not the result of poor key choice. Let's start with the example transition constraint from TTM 3rd edition, page 220-221:

    Here is an example ("no supplier's status must ever decrease"):

    CONSTRAINT TRC1 IS_EMPTY
    ( ( ( S' { S#, STATUS } RENAME ( STATUS AS STATUS' ) )

            JOIN
            ( S {S#, STATUS } ) )
        WHERE STATUS' > STATUS ) ;

    /Explanation:/ We introduce the convention that a primed relvar name,     such as S' in the example, is understood to refer to the corresponding     relvar as it was /prior to the update under consideration./ ....

Now, suppose that relvar S contains the following relation,

{S# := '123', STATUS := 30} So, should the following update be rejected?

UPDATE S (S# := '456', STATUS := 15) When coerced into being an assignment, S would contain the relation

{S# := '456', STATUS := 15} and then under the convention, S' would contain

{S# := '123', STATUS := 30} As a consequence, the constraint above returns TRUE because

(S' {S#, STATUS} RENAME (STATUS AS STATUS' ) )     JOIN (S {S#, STATUS}) is empty despite the fact that the status of the supplier whose S# was '123' before the update and '456' after the update decreased. It should be obvious from this that joining the relations before and after an assignment to a relvar is not a sound means of defining transition constraints.

> Anyhow here's an important question:
> Q. What happens in Brian's model when that transition history it
> relies on can't be determined?

What transition history are you referring to? A transition is an assertion that states, in the context of what has since the last update and up to now been the case, exactly what is now different and how. There is no reliance on history, since the context of both the current database, which states what has since the last update and up to now been the case, and the transition are the same. Received on Fri Jun 05 2009 - 05:12:53 CEST

Original text of this message