Re: foreign key constraint versus referential integrity constraint
From: Mr. Scott <do_not_reply_at_noone.com>
Date: Mon, 26 Oct 2009 09:15:43 -0400
Message-ID: <-t6dne8OIN2dPHjXnZ2dnUVZ_uOdnZ2d_at_giganews.com>
> ...
> 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?
Date: Mon, 26 Oct 2009 09:15:43 -0400
Message-ID: <-t6dne8OIN2dPHjXnZ2dnUVZ_uOdnZ2d_at_giganews.com>
"paul c" <toledobythesea_at_oohay.ac> wrote in message
news:yydFm.50294$PH1.7159_at_edtnps82...
> Mr. Scott wrote:
>> "Marshall" <marshall.spight_at_gmail.com> wrote in message >> news:386975f9-472c-4184-8661-5c3d1e2f7621_at_r24g2000prf.googlegroups.com... >>> On Oct 24, 10:53 am, Keith H Duggar <dug..._at_alum.mit.edu> 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?
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