Re: Constraints and Functional Dependencies

On 26 fév, 05:13, "NENASHI, Tegiri" <tnmai..._at_gmail.com> wrote:

> This is a fact that is very well known that one can express constraints
> as implications. Like Abiteboul said in some place "the presence of
> some tuples *implies* the presence of some other tuples" (or something
> like this).
Would you please suggest a reference to Abiteboul's works. Not the first time I hear about him but I never had a chance to read him.

> "Referential integrity" is the argot of SQL programmers. In the theory
> of relational databases one uses the term of "inclusion dependency" and
> "referential integrity is a particular case of that.
Watch out! some people here will accuse you of inventing new terms. ;)

> The inclusion dependency can be formulated in terms of the relational
> algebra. Let R(X,Y,U) and S(M,X,Y) be some relations. Then in terms of
> the relational algebra ProjectAttrXY(R) is_a_subset of ProjectAttrXY(S),
> or the equivalent in tuple relational calculus: forall(r in R)exists(s
> in S)(r[X,Y] = s[X,Y]), is an example of inclusion dependency. In terms
> of first order logic it is: forall(x)forall(y)forall(u) (R(x,y,u) -->
> exists(m)S(m,x,y) ) where "-->" is the sign of implication.
>
> Other dependencies like functional dependencies or join dependencies are
> also implications. For example FD for R(X, Y, Z) can be XY --> Z. Et
> cetera. Abiteboul explicates it very well.

> The inclusion dependency does not utilize the notion of the candidate
> key. Date, in some place perhaps Tutorial D, has said that the key
> is not necessary for the inclusion dependency. The SQL designers made
> the referential integrity like a special case because it is efficient to
> use the primary key to validate the constraint. Of fcourse SQL permits
> to define the inclusion dependency with the "check" constraint.
>
> --
> Tegi
Received on Mon Feb 26 2007 - 08:01:32 CET