Re: Relation Schemata vs. Relation Variables

From: <brian_at_selzer-software.com>
Date: 23 Aug 2006 11:31:55 -0700
Message-ID: <1156357915.287345.254650_at_75g2000cwc.googlegroups.com>


JOG wrote:
> brian_at_selzer-software.com wrote:
> > JOG 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?
> > >
> > > You have still not explained how you intend to go against this logic.
> >
> > I posted a detailed explanation to J M Davitt, but here's the short
> > version.

>

> This is not an explanation of how you are going against the logic. It's
> fluff. If tuples cannot change there can be no transition.
>

> >
> > A candidate key value can only identify a tuple within a single
> > database state.
>

> No. That is only a /necessary/ condition of a candidate key. There are
> further characteristics that seperate choosing a good key from a bad
> one.
>

> > Using that value to identify a tuple in a different
> > database state implies that the value identifes more than just a tuple
> > (or fact).
>

> It gives us a clue that the key for a tuple /may/ also be a good
> identifying attribute for an item in the real world. This may not be
> true.
>

> > So if a tuple from the current database state represents a
> > fact about something, and a tuple with the same key value in a proposed
> > database state represents a fact about something, then the gross
> > assumption is that both facts are about the same thing.
>

> More than Gross, its an atrocious assumption. Facts are not about
> things, they /concern/ things. In fact the above assumption shows a
> misunderstanding about the nature of the statements we are recording.
> This is the root of your mistake imho.
>

In what way does whether a fact is about something or a fact concerns something make any difference in this context? If this is the root of my mistake, then could you please explain? I guess if a fact describes a class of things (in the mathematical sense, things with a common property), then it could /concern/ something indirectly. Is that the distinction you're making? Regardless, if a fact /concern's/ something, then there's still something out there in the universe that's associated with the fact.

> > So, you're
> > right, tuples are values and cannot change, but using a candidate key
> > value beyond the scope of its definition injects meaning into that
> > value so that it doesn't just identify a tuple, but also something in
> > the universe.

>

> An identifying value can be used as a key in a statement, but we cannot
> assume the reverse. It is illogical. I think you are confusing the role
> of identifying an item and identifying a statement of fact.
>

> > Therefore, if it's possible for a key value to identify
> > something in the universe, then it's also possible for that key to
> > change and still identify the same thing.
>

> It can be renamed and happily identify the same 'thing' (i.e. a domain
> renaming). However this would require a renaming in old relation values
> too to maintain consistency.
>

> It can also change values (within a domain) and identify a snapshot of
> a 'thing'.
>

> However it no longer identifies a things identity over several
> snapshots of it. If that is what matters it was an error using that
> identifier in the initial propositions. You should have used an
> identifier that represents that 'thing' over that time.
>

> > It's also possible for
> > things to change so that the key value identifies something else.
>

> This sentence makes no sense. Things don't have key values, only
> tuples.
>

> > Hence, a transition constraint prevents database states that are
> > illogical not because values are different, but because the new values
> > represent facts about things that cannot be true given the current
> > state of things reflected in the old values.
> >
> > Bottom line: if a transition constraint can be defined, then tuples
> > represent facts about things that can change.
>

> No. Things can change, however to identify something over time in the
> real world we need /some identifying attribute/. How on earth would we
> ever know it was the same thing otherwise! When you meet someone you
> have not known since they were a child, and they have changed their
> name through marriage, you cannot identify them. They have to ascertain
> a consistent identifier for you to recognise them.
>

> All you have done is highlight bad key choices. This is a valid
> problem, but external to the RM.
Received on Wed Aug 23 2006 - 20:31:55 CEST

Original text of this message