Re: Relation Schemata vs. Relation Variables

"David Portas" <REMOVE_BEFORE_REPLYING_dportas_at_acm.org> wrote in message news:1156102677.260478.222220_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. t would be empty for an inserted tuple, t' would be
>> empty for a deleted tuple, and neither would be empty for tuples
>> corresponding in an update. From that set of transitions, only those
>> that
>> satisfy all transition constraints are /possible transitions/. The
>> problem
>> is that more than one transition can result in the same /possible state/
>> but
>> that not all of those are /possible transitions/.
>>
>> For instance, consider the following states for a relation describing
>> people's marital status, and a transition constraint that says: Single
>> people can't become Divorced:
>>
>> Current Proposed
>> Jane Jones Married Jane Jones Married
>> Jane Smith Single Jane Smith Divorced
>>
>> Should the proposed state be rejected? Or did Jane Jones get Divorced
>> becoming Jane Smith at the same time that Jane Smith married Bob Jones?
>> It
>> is impossible to tell: not enough information has been provided.
>>
>> Since a transition that violates a transition constraint can result in
>> the
>> same /possible state/ as a transition that doesn't, the notions of
>> relational assignment and multiple assignment are broken: an update must
>> be
>> submitted as a transition or something equivalent, not just as sets of
>> relation values, otherwise transition constraints cannot always be
>> enforced.
>> So, should Relation Variables be discarded in favor of Relation Schemata?
>
> I think a transition constraint must be defined as a relational
> expression in the general form of some join between t and t'. So in all
> cases I'd say that the precise nature and syntax of the update
> operation is irrelevant. The proposed transition has to be permitted or
> rejected based purely on the relation values of t and t'. Assignment
> won't break; Jane Smith cannot get divorced.
>

But that assumes that the key value from the current state identifies a tuple in the proposed state. That is outside of the scope of a key as defined by the model; moreover, it injects meaning into the key that may or may not match what the user perceives that meaning to be. Thus, the user must specify during the update whether or not tuples in successive database states correspond so that transition constraints can be enforced.

> --
> David Portas
>
Received on Mon Aug 21 2006 - 06:58:24 CEST