Re: foreign key constraint versus referential integrity constraint

From: paul c <toledobythesea_at_oohay.ac>
Date: Thu, 22 Oct 2009 02:57:18 GMT
Message-ID: <iSPDm.49829$PH1.6158_at_edtnps82>


Keith H Duggar wrote:
> On Oct 21, 12:18 pm, Sampo Syreeni <de..._at_iki.fi> wrote:

>>> I prefer the term "inclusion dependency": projection of one relation
>>> (that is rvRedemptions v [CouponID]) is a supepersetset of projection
>>> of the other (i.e. rvOrders v [CouponID]). I thought that all three
>>> terms are the same; perhaps with foreign key constraint adding some
>>> insignificant matter, like the "smaller" set being unique.
>> BTW, one limitation of foreign keys which I find particularly annoying
>> is that they only work when we're talking about base tables whereas
>> I've already bumped a few times into a situation where I would have
>> liked to constrain (on) the contents of a view. That sometimes happens
>> when you have to go beyond 3NF or you're working with a conceptual
>> model which allows multiple inheritance and/or union types. Do you
>> happen to know whether this sort of thing is formally covered by the
>> concept of inclusion dependency?

>
> I'm guessing this is just a limitation of some particular products?
> Because if I'm understanding "The Principle of Interchangeability"
> that for example Date's discusses in "Databases In Depth" then the
> RM has nothing to say about the arbitrary distinction between base
> versus virtual relvars (views). So in principle one should be able
> to define constraints on any relvars base or otherwise at least in
> so far as the RM is concerned. Is this correct?
>
> KHD
Date's POI has this caveat about "no unnecessary" which always troubles me. I would like to know if Codd ever said his foreign key couldn't be defined against his views. Received on Thu Oct 22 2009 - 04:57:18 CEST

Original text of this message