Re: ID field as logical address

On Jun 5, 2:10 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> "JOG" <j..._at_cs.nott.ac.uk> wrote in message
> <snip>
> > At risk of repeating myself, S# has merely proven to be a bad key
> > again - it is clearly an unstable identifier for a supplier (just as
> > 'name' was in the 'divorcee' example). This is just another flawed
> > schema, not a problem with the RM.
>
> I didn't say it was a problem with the RM. I said it was a problem with
> Date and Darwen's notions that a database is a collection of relvars and
> that insert, update and delete are shortcuts for relational assignments.
>
> You're underscoring my point, by the way, which is that adopting those
> notions requires that every instance of every key be a permanent identifier
> for something in the Universe of Discourse

Yup, if you talk about something in a proposition use a stable identifier for it. It's not just desirable, but essential. Use a nice stable EMP# not a person's name. It is about integrity not 'expressiveness'.

> , thereby limiting the
> expressiveness of the model.
>
> > > > 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.
>
> > What would happen if noone knew that supplier 123 had become supplier
> > 456 (i.e. there was no fact available representing that change, so
> > nothing that could be used in an update)?
>
> If the user didn't know that fact, then they wouldn't have issued an update
> stating that fact. They would have attempted to issue an update targetting
> supplier 456, and the update would of course have been rejected.

This is the crucks of the matter. You'd then be stuck with a fact in your database that is false. Why the integrity failure? Because a poor, unstable key was used. There is no solving this with rowid's, or any other kind of shims.

>
> > You always pick examples where there is someone to ask in order that
> > some disparity in identification can be ameliorated, but there are
> > many situations where this information may simply not be available, or
> > even exist at all. It therefore simply has to be all about picking
> > good reliable keys.
>
> If it is possible for a prime attribute to be the target of an update, then
> one must assume that it will. Whenever it should not be possible, there
> should be a transition constraint that prevents it. Of course, if one
> adopts Date and Darwen's notions that a database is a collection of relvars
> and that inserts, updates and deletes are shortcuts for relational
> assignments, then it isn't possible to define let alone enforce such a
> constraint.
>
> Question: what if the entire heading is the key. Should updates be
> prevented altogether for such relvars?

Aye. Received on Sat Jun 06 2009 - 01:06:22 CEST