Re: Multi-Valued Dependencies
Date: 2000/03/22
Message-ID: <38D923E5.B3220C33_at_rtp.ericsson.com>#1/1
Harry Chomsky wrote:
>
> Randy Yates wrote in message <38D8B9BC.A4588176_at_207.87.184.178>...
> >OK, now here is the issue I have: At this point, Date asserts that
> >the course/teachers and course/texts relvars have no MVDs. I disagree.
> >Consider the course/teachers relvar, and let A=COURSE, B=TEACHER,
> >and C=nullset. Then A ->-> B.
>
> Perhaps Date should have said that the relvars have no *non-trivial* MVDs,
> or amended the definition of MVD to require the attribute sets B and C to be
> non-empty.
OK.
> You are technically correct that COURSE ->-> TEACHER in the given relation.
OK.
> In fact, in *any* relation with two or more attributes, you can partition
> the attributes into subsets X and Y and verify that X ->-> Y. This fact is
> not very interesting though. When designers talk about MVDs, they generally
> mean non-trivial ones.
You seem to be using the term trivial for two different reasons:
Trivial A: An MVD is trivial if the subset C is null
Trivial B: An MVD is trivial if the set of B values
matching a given (A value, C value) pair is of
cardinality "1" (i.e., the set contains only one value).
The case defined by trivial B is the only way I can reconcile your statement that *any* relation with two or more attributes and be considered MVDs, otherwise, e.g., the relation
COURSE TEACHER Physics Green Math Green,
where COURSE is a primary key, would not be considered an MVD.
I really don't mean to be hung up on this point - it really seems to be important in being able to proceed to the definition of fourth normal form. The problem is, I'm not sure which characteristic of relvars the concept of MVD is meant to identify: the characteristic in which two or more sets of attributes are independent of one another but dependent on some other set of attributes, or the characteristic in which a single set of attributes contains a "set" of values that are, as a set, dependent on another set of attributes (i.e., a "relation-valued" attribute).
-- Randy Yates DSP Engineer Ericsson / Research Triangle Park, NC, USA qusraya_at_rtp.ericsson.se, 919-472-1124Received on Wed Mar 22 2000 - 00:00:00 CET