Re: foreign key constraint versus referential integrity constraint

From: Mr. Scott <>
Date: Mon, 26 Oct 2009 09:15:43 -0400
Message-ID: <>

"paul c" <> wrote in message news:yydFm.50294$PH1.7159_at_edtnps82...
> Mr. Scott wrote:

>> "Marshall" <> wrote in message 
>>> On Oct 24, 10:53 am, Keith H Duggar <> wrote:
>>>> Anyhow, the question here is not one of our imagination but rather
>>>> simply this: if it makes sense for the RM to support constraints
>>>> on relational /values/ (taken on by variables) why does it not
>>>> make sense to support constraints on relational /expressions/?
>>>> That is a question of general principle not specific design.
>>> This question, it seems to me, is clear and to the point.
>>> And I would answer it by saying that we shouldn't really
>>> even make the distinction! (At least not formally.)
>> I think we should make the distinction, and formally.
>> (p /\ q) -> r   is not the same as   (p -> r) /\ (q -> r)
>> but  (p \/ q) -> r   is the same as   (p -> r) \/ (q -> r)
>> A view consisting of a natural join, for example, represents a set of 
>> conjunctions.  Each row of the join represents a conjunction of 
>> propositions, one for each operand.  A constraint defined on a join would 
>> be of the form (p /\ q) -> r.  That is definitely not the same as 
>> constraints defined on one or more tables, which would take the form (p 
>> \/ q) -> r.

> ...

> I guess the attitude, interpretation if you like, that relational ops
> implement logic leads to that but another attitude is that they merely
> apply logic to obtain relations that consist of simple propositions. I
> believe most people happily accept the latter interpretation when looking
> at a relation value that has been obtained by a language devices such as
> insert or assignment where the definition is based on union. The 'OR'
> disappears. I think there is a big difference between the implementation
> and the application of logic. Another question is what happens to the
> join's conjunction when we project, does it survive or not depending on
> which attributes we choose?

I'm not really sure what you mean by "The 'OR' disappears." An insert into a union view is inherently ambiguous.

The propositions represented in the rows of a projection imply the propositions represented in the operand of the projection. That's why when you insert through a projection, the columns on the operand that are not represented must either allow nulls or have a default constraint defined. Received on Mon Oct 26 2009 - 14:15:43 CET

Original text of this message