Re: Relation Schemata vs. Relation Variables
From: J M Davitt <jdavitt_at_aeneas.net>
Date: Wed, 23 Aug 2006 02:52:52 GMT
Message-ID: <8qPGg.68910$u11.46673_at_tornado.ohiordc.rr.com>
>>Brian Selzer wrote:
>>
>>>"JOG" <jog_at_cs.nott.ac.uk> wrote in message
>>>news:1156107137.284318.326750_at_m73g2000cwd.googlegroups.com...
>>>
>>>>Brian Selzer wrote:
>>>>
>>>>>In the context of an update, the predicate of a database along with the
>>>>>current database state determines the set of all /possible states/ that
>>>>>can
>>>>>become current. Integrity rules, which are implicitly or explicity
>>>>>specified as part of the database predicate, can be classified as either
>>>>>state constraints or transition constraints. State constraints define
>>>>>the
>>>>>set of all consistent database states; transition constraints determine
>>>>>whether or not a state change should be allowed. Given a set of
>>>>>consistent
>>>>>database states and the current state, one can derive a set of
>>>>>transitions,
>>>>>each containing what is different on a tuple by tuple basis between the
>>>>>current state and a proposed state (any one of the consistent states). A
>>>>>transition can be defined as a set of triples (r, t, t') where r is the
>>>>>name
>>>>>of a relation, t is a tuple from the current state, and t' is a tuple
>>>>>from
>>>>>the proposed state.
>>>>
>>>><argggghhhh/>.Sorry brian, but this still isn't right. It is illogical
>>>>to talk about the transition of a tuple from one value to another, as
>>>>though they were entities from the real world themselves. Look, say
>>>>mathematically you are talking about a relation composed of three
>>>>tuples:
>>>>
>>>>R := {x, y, z}
>>>>
>>>>x, y and z are not variables! They are aliases for values. I can't
>>>>compare x, y an z with their future selves - they only have one value,
>>>>today, tomorrow, for evermore.
>>>>
>>>
>>>I think you're confusing attributes with tuples. Even if you're not, I
>>>agree: tuples are values. If they *can* correspond, it is in the mind of
>>>the designer of the database who defined the transition constraint, and thus
>>>the fact that they *do* correspond must be conveyed by the user during the
>>>update.
>>
>>I am not confusing anything. If you agree tuples are not variables,
>>then you agree that tuples cannot 'change'. And by that one is saying
>>that they /cannot/ have a transition. That's the logic, and its
>>unavoidable - how can you argue against it?
>>
Date: Wed, 23 Aug 2006 02:52:52 GMT
Message-ID: <8qPGg.68910$u11.46673_at_tornado.ohiordc.rr.com>
brian_at_selzer-software.com wrote:
> JOG wrote: >
>>Brian Selzer wrote:
>>
>>>"JOG" <jog_at_cs.nott.ac.uk> wrote in message
>>>news:1156107137.284318.326750_at_m73g2000cwd.googlegroups.com...
>>>
>>>>Brian Selzer wrote:
>>>>
>>>>>In the context of an update, the predicate of a database along with the
>>>>>current database state determines the set of all /possible states/ that
>>>>>can
>>>>>become current. Integrity rules, which are implicitly or explicity
>>>>>specified as part of the database predicate, can be classified as either
>>>>>state constraints or transition constraints. State constraints define
>>>>>the
>>>>>set of all consistent database states; transition constraints determine
>>>>>whether or not a state change should be allowed. Given a set of
>>>>>consistent
>>>>>database states and the current state, one can derive a set of
>>>>>transitions,
>>>>>each containing what is different on a tuple by tuple basis between the
>>>>>current state and a proposed state (any one of the consistent states). A
>>>>>transition can be defined as a set of triples (r, t, t') where r is the
>>>>>name
>>>>>of a relation, t is a tuple from the current state, and t' is a tuple
>>>>>from
>>>>>the proposed state.
>>>>
>>>><argggghhhh/>.Sorry brian, but this still isn't right. It is illogical
>>>>to talk about the transition of a tuple from one value to another, as
>>>>though they were entities from the real world themselves. Look, say
>>>>mathematically you are talking about a relation composed of three
>>>>tuples:
>>>>
>>>>R := {x, y, z}
>>>>
>>>>x, y and z are not variables! They are aliases for values. I can't
>>>>compare x, y an z with their future selves - they only have one value,
>>>>today, tomorrow, for evermore.
>>>>
>>>
>>>I think you're confusing attributes with tuples. Even if you're not, I
>>>agree: tuples are values. If they *can* correspond, it is in the mind of
>>>the designer of the database who defined the transition constraint, and thus
>>>the fact that they *do* correspond must be conveyed by the user during the
>>>update.
>>
>>I am not confusing anything. If you agree tuples are not variables,
>>then you agree that tuples cannot 'change'. And by that one is saying
>>that they /cannot/ have a transition. That's the logic, and its
>>unavoidable - how can you argue against it?
>>
> > > Because facts are about things, and things /do/ change. If you want to > limit the set of possible database states to include only facts that > reflect alterations that /can/ occur, then you need to know what each > thing looked like at the end of the last change and what it looks like > in each consistent database state.
[snip] Received on Wed Aug 23 2006 - 04:52:52 CEST