Re: ID field as logical address

> <robur.6_at_gmail.com> wrote in message
> news:43a5ac21-08f1-4922-a457-61e77c8cc8eb_at_r13g2000vbr.googlegroups.com...
> On May 31, 5:38 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> ...
> > If instances of a key do not
> > permanently identify things in the Universe, then transition constraints
> > that join the relation values before and after an assignment to a relvar
> > would not be sound. For example, suppose that you have a relation, {L,
> > F,
> > Stat} Key {L, F}that starts out with the following value:
> >
> > {{L:Smith, F:Mary, Stat:Single},
> > {L:Jones, F:Mary, Stat:Married}}
> >
> > and is then assigned the value,
> >
> > {{L:Smith, F:Mary, Stat:Divorced},
> > {L:Jones, F:Mary, Stat:Married}}
> >
> > You might be wondering how someone who is Single can become Divorced?
> > Should the assignment be rejected on that basis? Or is it possible that
> > Mary Jones' maiden name is Smith, and that she became Divorced while at
> > the
> > same time the Mary Smith who was Single Married Robert Jones? It might
> > also
> > be that the Mary Smith who was Single moved out of the area while a
> > different Mary Smith, who is Divorced, moved in.
>
>
>
> A very good example indeed. However let’s imagine the following
> conversation:
>
> -“Do you know that Mary Smith got divorced?”
> -“It must be a mistake, Mary Smith has never been married!”
> -“Well, actually it is about Mary Jones that married and became Mary
> Smith. The Mary Smith you know changed his name to Jones before that.”
>
> As can be seen an ambiguous statement can be confusing for humans as
> well (and requiring supplementary explanations). A database (loosely
> speaking) is just a collection of statements. The system is not
> supposed to know (or guess) the truth, but just to check the new
> statements for consistency with the existing statements in the
> database.
>
> So in specified context a statement “Mary Smith got divorced” should
> be rejected due the transitional constraint. A correct sequence of
> statements is “Mary Smith changed his name to Jones”, “Mary Jones got
> married and changed his name to Smith” and “Mary Smith got divorced”.
> This is unambiguous for both database system and a human as well.
>
>
>
>
>
> ...
> > If, on the other hand, insert,
> > update and delete are not shortcuts, but rather primitive operations,
> > then
> > the introduction of the autogenerated IDs is not necessary. All that is
> > needed is to correlate the tuples in a relation that are the target of
> > an
> > update with those in its successor. For example, the update
> >
> > {{L:Smith, F:Mary, Stat:Single, L':Smith, F':Mary, Stat':Divorced}}
> >
> > should clearly be rejected, but the update,
> >
> > {{L:Smith, F:Mary, Stat:Single, L':Jones, F':Mary, Stat':Married},
> > {L:Jones, F:Mary, Stat:Married, L':Smith, F':Mary, Stat':Divorced}}
> >
>
>
> The relation variable changes its state from one set of statements to
> a different one. No one should care which tuple was replaced by which
> tuple. It is just a new set of statements consistent with the current
> state of the database.

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> Received on Wed Jun 03 2009 - 15:06:05 CEST