Re: Relation Schemata vs. Relation Variables

"Sampo Syreeni" <decoy_at_iki.fi> wrote in message news:Pine.SOL.4.62.0609051434540.671_at_kruuna.helsinki.fi...
> On 2006-09-03, Brian Selzer wrote:
>
>> What if the customer number changes because the user that added the
>> customer keyed in the wrong information and is now correcting a mistake?
>
> What if the front office system wanted to remove some customer from the
> system, it decided to immediately reuse the customer number because it
> knew it wasn't used for anything else anymore, and then it decided to
> optimize the two transactions into a single update clause? The only reason
> that shouldn't be possible is if we agree that there's some semantic
> difference between insert/delete and update -- possibly expressed by
> stating that there's a hidden surrogate key which is guaranteed to stay
> constant under update but will change with insert/delete -- but if we
> don't agree on that, the two states are all that the database knows about.
> In its eyes there's no difference because in either case, the end result
> is a world where a certain customer number is associated with certain
> other attributes. As far as the DB is concerned, it's the same world
> because you failed to include a predicate which would help it tell the
> worlds/models/extensions apart.
>

I would say that the model failed to define a mechanism to pair up atomic values from successive database states for comparison when keys can change. So it may not be possible to specify a predicate that would help it tell the worlds/models/extensions apart.

>> My "transition sets" do not depend upon key stability. They provide
>> enough information to define constraints that can be enforced even when
>> prime attributes are affected by a change: it is up to the user to
>> specify how tuples correlate by issuing the appropriate type of
>> modification or set of modifications, that is, INSERT, UDPATE, DELETE, or
>> assignment.
>
> Then what you're saying is essentially that knowing the difference in
> database state caused by a transaction isn't alone sufficient to determine
> whether the transition is legal. You'd rather know the reason for the
> change as well, and you've chosen to encode this reason as something that
> can be derived from the user's choice between insert/delete and update.
> I.e. you're (re?)defining the interface to the database so that in certain
> limited cases where two sequences of operations can be used to cause an
> identical change of state, the precise choice between the sequences
> signals intent to the database management system. The system then uses
> this signal as an additional decision variable.

Because a relational database state is a set of named sets of sets of named values instead of a set of named sets of named sets of named values, the information available given only the current database state and the proposed database state is not sufficient to pair values for comparison in a transition constraint; therefore, either tuples must be named, or the formulation of a modification must complement that information so that values can be paired.

The reason for a change is subjective and indeterminent and, therefore, not at all useful. The target of a change, on the other hand, is neither subjective nor indeterminent and can be very useful. That information is lost when transforming an update into an assignment. An update may target only a subset of a relation or only a subset of the attributes in the schema or both. It may be significant that one set of tuples was targeted while another was not; it may be significant that one set of attributes was targeted while another was not. It may be significant that an attribute or a set of attributes that was the target of a transition remained constant, or that a tuple or set of tuples targeted by a transition stayed the same. Also, how a given subset of a relation was arrived at may also be significant: it should be possible to at least determine which attributes of a targeted relation were referenced in the where clause. In addition, and maybe most important, the name of the user should be made available for the definition of transition constraints. You may not want to enforce a constraint if a particular user issued the modification. Put it another way: you may want to reject what someone says about something if you know that they don't know what they're talking about.

>
> Wouldn't it be simpler and more general to just enumerate the possible
> reasons and pass one of them as a parameter? Or to separate concerns
> entirely, so that when the client has some information (whatever enables
> it to choose update over insert/delete) that the database doesn't have (if
> it had, that fact would be asserted by some pre-transition relation and it
> could be checked as part of validating a more traditional looking
> transition constraint), the database isn't involved in validating the
> constraint in the first place?

I don't understand what you mean. The reason for a change is subjective, and you can't constrain what's in someone's mind.

> --
> Sampo Syreeni, aka decoy - mailto:decoy_at_iki.fi, tel:+358-50-5756111
> student/math+cs/helsinki university, http://www.iki.fi/~decoy/front
> openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
Received on Tue Sep 05 2006 - 23:36:41 CEST