| 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: A real world example
"JOG" <jog_at_cs.nott.ac.uk> wrote in message news:1156047823.641966.136920_at_m79g2000cwm.googlegroups.com...
> Brian Selzer wrote:
>>
> > No. > >>>> > 'Indirect identity'? There is no such distinction to be made.
>> >> For example, consider a line of people at the bank. Both
>> >> Person and Position are identifying properties. Assume that you're
>> >> third
>> >> in
>> >> line, so Person is you, and Position is 3. When the guy at the head
>> >> of
>> >> the
>> >> line leaves, your Position changes to 2. Now let's put that in the
>> >> context
>> >> of a database. You have a relation with candidate keys Person and
>> >> Position.
>> >> So the current instance might look something like
>> >>
>> >> {(Bob, 1), (Brian, 2), (You, 3)}.
>> >>
>> >> The proposed instance would look something like
>> >>
>> >> {(Brian, 1), (You, 2)}
>> >>
>> >> Even though Position is a candidate key in each situation and
>> >> indirectly
>> >> identifies
>> >
>>
>>>> > you as making more sense?
>> >> an entry in the queue, the value 2 from the current instance
>> >> identifies the tuple containing You in the proposed instance, not the
>> >> one
>> >> containing Brian. This illustrates the difference in the frame of
>> >> reference
>> >> for a candidate key and that for an update, and Position is an example
>> >> of
>> >> an
>> >> identifying property that can change.
>> >
>> > Why not extend this? Perhaps brian changed his name to bob while he was
>> > waiting, and queueing positions are changed from numerical to
>> > alphabetical by the bank
>> >
>> > rv1: { (Brian, 2) }
>> > rv2: { (Bob, A) }
>> >
>> > ...and you want to automagically correlate these things? Rather than
>> > think in hindsight maybe the identifiers chosen for the entities
>> > concerned might have been a wee bit of a mistake? Does that not strike
>>
> > Yes, yes, I follow your logic, but it is still flawed: one attribute > out there will be completely stable for your specific problem space, if > you so desire to find it. That's the nature of identity and what allows > you identification in the first place. >
Then the definition of the model should reflect that, but I'm not sure that surrogates are the only answer. All that is required is the ability to correlate tuples during an update. A possibility: require that the user reassert the original candidate key values during the update. The predicate of a database along with the current database instance determines the set of all possible instances that can become current. There should be a way to obtain the set of possible instances from a set of possible transitions, each of which would contain what is different on a tuple by tuple basis between the current instance and a proposed instance. A transition could 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 instance, and t' is a tuple from the proposed instance. t would be empty for an inserted tuple, t' would be empty for a deleted tuple, and neither would be empty for a corresponding tuple. I positive that I read somewhere that it is possible to transform all state constraints into transition constraints (I'll have to find out where I read this). So, given a current instance and a set of transition constraints, you should be able to construct a set of possible transitions. What I'm not absolutely sure of is whether or not there are more possible transitions than possible instances. For some reason it seems likely, unless infinity is involved. Two different possible transitions could result in the same possible instance.
I was just thinking: if more than one possible transition can result in the same possible instance, then given only the current instance and a proposed instance, can you determine which transition a transition constraint should enforce? Does it matter, that is, is it possible for one transition that determines a possible instance to be prohibited but for another transition that determines the same possible instance to be accepted? If it does matter, then the notions of relational assignment and multiple assignment are broken: updates would have to be submitted as transitions or something equivalent, not just as sets of relation values.
A light bulb just came on! Whether or not different candidate key values identify the same thing in successive database instances is something that the user must determine, not the model, but there must be some mechanism for a user to assert that, otherwise transition constraints cannot always be enforced. It is up to the user to correlate tuples, not the model, but if a transition constraint is to be enforced, then the system must be informed how they correlate, and thus the model should reflect that. Perhaps this supports Fabian Pascal's objections to variables and relational assignment.
> With a surrogate you are representing that attribute anyhow. You're > just completely wrong to hide it from the thing that needs to use it as > identification. (all your examples rely on an entity having some sort > of memory of what previous state it was in, which is an incredible > assumption) >
I concede that it is wrong to hide it. Whether or not it's hidden diverts attention away from the main issue I'm trying to describe.
I don't think it's an assumption at all. Enforcement of any transition constraint depends not only on the definition of the constraint, but also on the current database instance in order to determine whether or not a proposed database instance should be rejected.
>>>> >> >>> >> > means
>> >>
>> >> >>> >> > Maybe, but from a functional standpoint, that operator is
>> >> >>> >> > just a
>> >> >>> >> > function (e.g. "subtract $500 from X), in which the balance
>> >> >>> >> > is a
>> >> >>> >> > free
>> >> >>> >> > variable. Only in an imperative world does that involve
>> >> >>> >> > "knowing"
>> >> >>> >> > (referencing) the "previous" balance. Function application
 |
 |