Re: Multiple keys and transition constraints
Date: Sat, 16 Sep 2006 22:20:31 GMT
Message-ID: <PM_Og.2597$e66.347_at_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 Sun Sep 17 2006 - 00:20:31 CEST