Re: constraints in algebra instead of calculus

"paul c" <toledobythesea_at_oohay.ac> wrote in message news:JQ94i.200044$DE1.108062_at_pd7urf2no...
> Brian Selzer wrote:
>> "paul c" <toledobythesea_at_oohay.ac> wrote in message
>> news:dX84i.201343$6m4.74192_at_pd7urf1no...
>>
>>>Marshall wrote:
>>>
>>>>Okay, a while back we were talking about writing constraints
>>>>in a language with aspects of the relational calculus, specifically
>>>>the existential and universal quantifiers. The point was made
>>>>that that's unnecessary; the calculus is no more expressive
>>>>than the algebra.
>>>>
>>>>So it ought to be possible to write any constraint from the
>>>>calculus in the algebra.
>>>>
>>>>Well, I'm having a hard time figuring out how to do it. Can
>>>>anyone help?
>>>>
>>>>How does one write a functional dependency in the algebra?
>>>>A foreign key?
>>>>
>>>>
>>>>Marshall
>>>>
>>>
>>>I thought that one was easy, if FK is the set of 'foreign key' attributes
>>>and A is the 'referencing table' and using an op like D&D <AND>, then
>>>it's something like A{FK} <AND> B{FK} = A{FK}. (I like this one because
>>>it's particularly easy to implement.)
>>>
>>
>>
>> Very slick. One point, though. The constraint
>>
>> A{FK} <AND> B{FK} = A{FK}
>>
>> Is not sufficient. Also required is the constraint
>>
>> COUNT(B{FK}) = COUNT(B)
>>
>>
>>
>>
>
> I've never seen anybody justify why a foreign key must be a candidate key
> in the referenced relation/relvar/table except for 'so-and-so says so'.
> Whereas I've seen examples where the non-key reference is essential.

There is a paper by Mark Levene and Millist W. Vincent, "Justification for Inclusion Dependency Normal Form." In it they argue that a database schema should be free of circular inclusion dependencies and should only contain key-based inclusion dependencies (which are as far as I can tell from their definition, foreign key constraints)

An inclusion dependency that is not also a foreign key constraint denotes a many-to-many relationship, whereas a foreign key constraint denotes a one-to-many relationship. It should be obvious that a database schema that contains inclusion dependencies that are not also foreign key constraints can be transformed into an equivalent schema that contains only foreign key constraints, provided the set of inclusion dependencies is noncircular. In that way each many-to-many relationship is split into two one-to-many relationships.

Circular inclusion dependencies can be transformed as well. For example, the following database schemata are equivalent:

(1) R{A, B, C, D} such that
A ->-> B | C and
ABC --> D (2) S{A, B, C}, T{A, D} such that
A ->-> B | C and
S[A] = T[A]

(3) U{A, B}, V{A, C}, W{A, D} such that
U[A] = V[A] = W[A]

In this case, (1) is superior, even though it has an embedded multivalued dependency. because it contains no cyclical interrelational constraints. Received on Tue May 22 2007 - 00:26:38 CEST