Re: foreign key constraint versus referential integrity constraint
Date: Wed, 28 Oct 2009 19:19:59 -0400
Message-ID: <DtqdnQXShNc9THXXnZ2dnUVZ_t-dnZ2d_at_giganews.com>
"paul c" <toledobythesea_at_oohay.ac> wrote in message
news:Mf0Gm.50609$PH1.4563_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. >> ... >
> 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".
The form (p /\ q) -> r applies because whenever r does not hold, neither can (p /\ q). r is in fact your "any truth valued expression." In the case of a join view, the antecedent is a conjunction, not a disjunction.
>
> 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?
>
Tables house data; views just present it. That is in a nutshell the difference between tables and views. What is presented by a view implies what is in the operands of the view's definition. As a consequence, in order to be fully updatable and therefore interchangable, each and every set of inserts, updates and deletes applied to a view must map one-to-one to a set of inserts, updates and deletes applied to those operands. Views that are joins or unions or restrictions or projections in general aren't fully updatable. There are exceptions, of course. A view defined on a pair of tables that participate in mutual foreign keys is fully updatable because each and every set of inserts, updates and deletes applied to the view maps one-to-one to a set of inserts, updates and deletes applied to the tables.
> 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 Thu Oct 29 2009 - 00:19:59 CET