Re: Multiple keys and transition constraints

From: Brian Selzer <brian_at_selzer-software.com>
Date: Sat, 16 Sep 2006 22:20:31 GMT
Message-ID: <PM_Og.2597$e66.347@newssvr13.news.prodigy.com>

"J M Davitt" <jdavitt_at_aeneas.net> wrote in message news:_fxOg.57$8e5.34_at_tornado.ohiordc.rr.com...
> Brian Selzer wrote:

>> "J M Davitt" <jdavitt_at_aeneas.net> wrote in message 
>> news:N_oOg.42$8e5.29_at_tornado.ohiordc.rr.com...
>>
>>>Brian Selzer wrote:
>>>
>>>>"JOG" <jog_at_cs.nott.ac.uk> wrote in message 
>>>>news:1158251660.983027.98520_at_e3g2000cwe.googlegroups.com...
>>>>
>>>>
>>>>>Brian Selzer wrote:
>>>>>
>>>>>
>>>>>>Given a relation schema R {A, B, C}, where A and B are each candidate 
>>>>>>keys.
>>>>>>
>>>>>>If the current extension is
>>>>>>
>>>>>>r  {{A:1, B:9, C:3}
>>>>>>   {A:2, B:8, C:4}}
>>>>>>
>>>>>>and the proposed extension is
>>>>>>
>>>>>>r' {{A:1, B:8, C:4}
>>>>>>   {A:2, B:9, C:3}}
>>>>>>
>>>>>>is only A different? Or are both B and C different?  From one 
>>>>>>perspective,
>>>>>>both B and C remain constant but A is different.  From another 
>>>>>>perspective,
>>>>>>A remains constant but both B and C are different.  If you're trying 
>>>>>>to
>>>>>>specify the allowable transitions for C, which key do you use?  A, B, 
>>>>>>the
>>>>>>superkey, AB, or none of the above?
>>>>>
>>>>>This requires more information to answer.
>>>>>
>>>>>Can you tell us which attribute identifies the subject [of each
>>>>>proposition] in real life over the updates. Then I can determine /what/
>>>>>exactly has experienced the transition.
>>>>>
>>>>>No other questions, just that.
>>>>>
>>>>
>>>>
>>>>Well, that's the dilemma, there are two subjects because there are two 
>>>>keys. Consider the following relation:
>>>
>>>[Why do you flog yourself with this nonsense?!]
>>>
>>>"subjects."  "keys."  Hmm...  re:  r v. r':
>>>
>>>B is a key, you say?  Well, the same determinant
>>>values in B have different dependent values.  So?
>>>
>>>A is a key, you say?  Well, the same determinant
>>>values in A have different dependent values.  So?
>>>
>>>If that design doesn't make you happy, concoct
>>>one that will.
>>
>>
>> I am completely at a loss as to the content and purpose of your post: 
>> What nonsense?  Are you questioning whether A and B are keys?  Are you 
>> saying that transition constraints are irrelevant?  What is your point? 
>> Mind reading isn't my forte, so could you please be a little more 
>> specific?
>

> It seems that you keep presenting some design
> fragments then complaining about what the design
> won't let you do or what the design will let you
> do - when you want to or don't want to - and
> then seem to ponder the question, "Why doesn't
> the model protect me from my design?"

>

> Look, I'm no happier than the next guy with the
> cacophony of constraints (key, referential,
> column, row, table, &c.) one finds in the
> literature but I see no need to try to invent
> another variety -- especially when the problem
> these new constraints are supposed to remedy is
> really due to a shortcoming in the design.
>

Constraints are a good thing. It's a lot cheaper to keep garbage out of a database than to clean it up once it's been trashed (if it is even possible). I'm not trying to invent a new variety of constraint. Codd included "changes of state" in the context of integrity rules when he defined what a data model is in 1980. Also, Date and Darwin include support for transition constraints in their list of RM VERY STRONG SUGGESTIONS.

I absolutely disagree that the problems that transition constraints are supposed to remedy are due to shortcomings in design. It's not uncommon to have multiple candidate keys on a relation schema, but in order to determine whether or not a transition should be allowed, it's necessary to be able to detect what will be different. As I illustrated earlier, when there are multiple keys, it's unclear whether or not a constraint has been violated because it's unclear whether what is being constrained has been affected.

> Just like that "replacement v. modification"
> issue you raised.

I stand by that. If the variable on the left-hand side of an assignment is referenced in the right-hand side, then it's a modification, not a replacement, because the new value depends on the old value. Funny that you should bring that up in this context. For a scalar variable, the old and new values can be compared during an assignment because there is always a 1:1 relationship between the old value and the new value. For a tuple variable, the elements of the old and new tuples can be compared because each element is named, so there is always a 1:1 relationship between elements in the old tuple and elements in the new tuple (unless of course there is a schema change). For a relation variable, on the other hand, the 1:1 relationship may not exist if there are multiple keys or if one of the keys is "updated" as a result of the assignment. Therefore, you can't pair a datum in the old relation value with one in the new for comparison, so you can't enforce a transition constraints for an update that involves that datum. Received on Sat Sep 16 2006 - 17:20:31 CDT