Re: ID field as logical address

"JOG" <jog_at_cs.nott.ac.uk> wrote in message news:6bfce62b-5fb9-4a33-9715-2a642b4070e9_at_o30g2000vbc.googlegroups.com...
> On Jun 5, 4:12 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> > "JOG" <j..._at_cs.nott.ac.uk> wrote in message
> >
> > news:467475e3-b073-43a7-bd8e-c02325090071_at_b1g2000vbc.googlegroups.com...

<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.

>

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, 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.

>

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.

> 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? Received on Fri Jun 05 2009 - 15:10:48 CEST