Re: Relation Schemata vs. Relation Variables


"Jan Hidders" <hidders@xxxxxxxxx> wrote in message
news:1157574550.782575.68320@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Brian Selzer wrote:

The point that I was making in the original post is that because keys can
change, there isn't enough information given only the old state and the
new
state to pair up the values in the old state with those in the new state
for
comparison.

Well, it means that the old rule that was used in the transition
constraint to "pair up" tuples such that they describe the same entity
isn't right anymore, and should be changed. So you have to redefine the
transition constraint. It's not really that surprising that a change to
your static constraints also implies a change to your dynamic
constraint, is it? But I assume you are arguing that such changes to
dynamic constraint would be unncessary under your approach.

[...] Instead, a transition constraint could be defined as a
function f(D, P), where P is a set of paired tuples describing what is
different between D and D'. P is the result of observation, not
identification.

I can see where the pairing would come from for updates, but not with
deletes and inserts. So you could get around the constraint by
simulating the update with a combination of delets and inserts. If you
want a real solution for this I don't think you can get around proper
support for object / entity / tuple identifiers at the logical level.


I need to think about this.... A delete/insert combination would have to
satisfy any delete constraints or insert constraints or both, but that
doesn't mean that the update constraint couldn't still be circumvented.
Foreign key constraints would make it more difficult, still.... I think
this may have to do with the difference between consistency and correctness.
A DBMS can't get inside the mind of a user to determine intent: it can only
work with what it has been told, and under different circumstances the
delete and insert could be a valid transition. Relational assignment can't
prevent a user from inserting consistent but incorrect information, so it
stands to reason that a user could choose a consistent but incorrect
transition. What I want is a mechanism for the user to specify which of the
many transitions that produce the proposed database state was intended. I
also don't want to lose any information in translation. Additional
information than just the old and new tuples may be useful, such as the
names of the attributes that were targeted by the change, the names of the
attributes that were used to target a subset of the relation, and the
identity of the user that initiated the change.

-- Jan Hidders



.

Relevant Pages

  • Re: Relation Schemata vs. Relation Variables
    ... shorthand for the respective relvar constraint: ... assignment unless keys cannot change. ... from successive database states for comparison because those elements are ... If you define a transition constraint that states: ...
    (comp.databases.theory)
  • Re: ID field as logical address
    ... CONSTRAINT TRC1 IS_EMPTY ... relvar as it was /prior to the update under consideration./ .... ... to a relvar is not a sound means of defining transition constraints. ... again - it is clearly an unstable identifier for a supplier (just as ...
    (comp.databases.theory)
  • Re: Key attributes with list values was Re: What are the differences ...KEY
    ... Jane Harper is married. ... And a constraint that states that single people cannot become divorced. ... database, or users, for that matter, to distinguish between them. ... That's the whole point of keys. ...
    (comp.databases.theory)
  • Re: Key attributes with list values was Re: What are the differences ...KEY
    ... database, or users, for that matter, to distinguish between them. ... That's the whole point of keys. ... But that is true of any constraint. ... keys can change, then either updates must be singular, that is, must affect ...
    (comp.databases.theory)
  • Re: UNIQUE constraint problem
    ... > Another mistake in the standard (and T-SQL, for being consistent). ... It's not the case that NULLs are treated differently in CHECK constraints. ... "A table check constraint is satisfied if and only if the specified <search ... the CHECK constraint allows the UNKNOWN case. ...
    (microsoft.public.sqlserver.programming)