| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> comp.databases.theory -> Re: Relation Schemata vs. Relation Variables
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.
>
>> > A candidate key value can only identify a tuple within a single
> >
>
>> > database state implies that the value identifes more than just a tuple
> > Using that value to identify a tuple in a different
>
>> > database state represents a fact about something, then the gross
> > 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
>
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.
>
>> > something in the universe, then it's also possible for that key to
> > Therefore, if it's possible for a key value to identify
>
>
>
>
>
>> > Bottom line: if a transition constraint can be defined, then 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.
> >
>
>
 |
 |