Re: Relation Schemata vs. Relation Variables

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.

> 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.

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?

-- 
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