# Re: foreign key constraint versus referential integrity constraint

Date: Wed, 28 Oct 2009 13:29:32 -0700 (PDT)

Message-ID: <c5b63b8e-045e-41d6-be5e-1ce753a15c0e_at_a37g2000prf.googlegroups.com>

On Oct 28, 10:41 am, paul c <toledobythe..._at_oohay.ac> wrote:

*> Mr. Scott wrote:
**> > "Marshall" <marshall.spi..._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.
**> > ...
**>
**> 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.
*

Is view definition a constraint? IMO it's purely terminological matter. Consider relations x and y defined by some algebraic identities. Is adding new view z (as a function of x and y) adding a constraint to the system?

Let's analyze a simpler example. Consider two real values constrained by the equality:

x + y = 5

Is introducing a new variable z, say

z = x - 2y

a new constraint imposed onto the system? Not really, because, variable z is redundant and can be eliminated, and it doesn't affect the formal property of the system of being under constrained. Received on Wed Oct 28 2009 - 21:29:32 CET