# Re: foreign key constraint versus referential integrity constraint

From: paul c <toledobythesea_at_oohay.ac>
Date: Wed, 28 Oct 2009 18:41:48 GMT
Message-ID: <Mf0Gm.50609\$PH1.4563_at_edtnps82>

Mr. Scott wrote:
> "Marshall" <marshall.spight_at_gmail.com> wrote in message

```>> 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.
> ...

A more opaque way but perhaps less useful way of saying this is that a relation's definition in the first place amounts to nothing more than a constraint. Received on Wed Oct 28 2009 - 19:41:48 CET

Original text of this message