Re: Enforcing functional dependecy constraints

From: x <x_at_not-exists.org>
Date: Mon, 12 Dec 2005 12:54:01 +0200
Message-ID: <dnjksn$7dk$1_at_domitilla.aioe.org>


"David Cressey" <david.cressey_at_earthlink.net> wrote in message news:wpClf.507$nm.373_at_newsread2.news.atl.earthlink.net...
>
> "x" <x_at_not-exists.org> wrote in message
> news:dn1j2m$fpo$1_at_domitilla.aioe.org...
> > Hi !
> >
> > Since this is a database theory group and I'm bored by the null and 3vl
> > threads I ask yet another elementary question:
> >
> > Suppose you have this relation R(A,B,C) with the following functional
> > dependencies AB->C and C->B.
> > What is the best way to implement this in available SQL DBMS in your
> opinion
> > ?
> >
> > Regards,
> > x

> I'm not sure what you mean by "best". If it's my opinion of "what's
best",
> I'm going to dodge the question by giving the universal answer: "It
> depends".

Best as in "best implementation" of the constraints in SQL with some particular products.
There could be many answers and tradeoffs.
Elementary as in "elementary in theory" because this is the standard problem for BCNF.
Have you encountered this problem in practice ?

> But before we move from relations to SQL, maybe we could discuss a little
> normalization:

> You could decompose the relation R(A,B,C) into two relations S(A,C)
and
> T(C,B).

> Please bear with me for presenting relation T in a curious order. These
> two can be recombined, unless I miss my guess,
> back into R(A,B,C) without loss. I think S and T are better than R from
the
> point of view of hermful redundancy and update anomalies. Is this
relevant
> to your original question?

This is the standard theoretical decomposition. How the AB->C is enforced ?

> Do you have a different answer?

Yes.
a)R(A,B,C) with (A,B) primary key, (B,C) foreign key into T and T(B,C) with C primary key.

b)S(A,C) and T(B,C) with some triggers
c)R(A,B,C) with some triggers
d) S(A,C) and T(B,C) with R(A,B,C) a view with some unique index on it
e) ...
Received on Mon Dec 12 2005 - 11:54:01 CET

Original text of this message