Re: ID field as logical address

From: JOG <jog_at_cs.nott.ac.uk>
Date: Thu, 4 Jun 2009 10:46:33 -0700 (PDT)
Message-ID: <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.

Anyhow here's an important question:
Q. What happens in Brian's model when that transition history it relies on can't be determined? Received on Thu Jun 04 2009 - 19:46:33 CEST

Original text of this message