Re: foreign key constraint versus referential integrity constraint
Date: Wed, 28 Oct 2009 18:41:48 GMT
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.
Forgot to mention that I don't see that a "a constraint defined on a join" would necessarily be "of the form (p /\ q) -> r". I had thought that many people think it could be any truth-valued expression such as "(p /\ q) = r".
This leads me to think that most, if not all, view definitions can be interpreted as constraints. It is interesting to me to then ask what makes a view different from a base. Is it enough to say that a view always has one constraint (of possibly several) that is an equality and a view may be 'updated' without reference to the view?
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