Re: Multi-Valued Dependencies

Randy Yates wrote in message <38DD844F.A59CCF42_at_207.87.184.178>...
>> > 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).

Before we continue, let me observe that these are very different kinds of properties. An MVD can be stated as a condition on a relvar. Some instances of the relvar (i.e., some relations) may satisfy the MVD, some may not. Now, trivial-A is a property of the MVD *as stated*. You can tell simply by looking at the statement of the MVD whether it's trivial-A or not. Trivial-B, OTOH, is a property of the way the MVD is satisfied *by a particular relation*. If you describe a relvar and an MVD X ->-> Y on that relvar, you can meaningfully ask whether the MVD is trivial-A or not: simply determine whether Y is empty or X U Y = { all attributes of the relvar }. In that case, the MVD will always be satisfied. It will be satisfied by every relation instance of that relvar. That's why I call it trivial. But you cannot meaningfully ask whether the MVD is trivial-B or not. To ask that, you first have to identify a particular relation instance, then see whether that instance satisfies the MVD and how it satisfies the MVD. Keep this difference in mind in the discussion below.

>> > COURSE TEACHER
>> > Physics Green
>> > Math Green,
>> >
>> In this case, still, we have the trivial (in sense A) MVD COURSE ->->
>> TEACHER.
>
>1. I agree with you that, in my example above, COURSE ->-> TEACHER,
>according to Date's definition of MVD, which did not exclude trivial
>A or trivial B types of MVDs.

Rather, according to Date's definition of MVD, which did not exclude trivial-A MVDs, and which didn't exclude trivial-B satisfaction of MVDs.

>2. I disagree that, if you limit MVD to the non-trivial B types, that
>my example above contains MVDs. However, this was not Date's
>original definition, i.e., he had no restriction on the cardinality
>of the multi-dependent set of attribute values.

There are too many negatives here for me to follow your logic, I'm afraid... But do try to understand the issue without recourse to trivial-B. A relation either satisfies an MVD or it doesn't. It makes no difference whether the satisfaction is trivial-B or not.

>> For example, if X = { COURSE } and Y = { TEACHER }, the new relation
 would
>> contain a row for each course, in which the A value would be the set of
>> teachers of that course. This works whether or not the FD COURSE ->
 TEACHER
>> is satisfied in the original relation.
>
>I agree, IF we do not exclude relations which have only one value in the
>relation-valued attribute.

Why would we make such an exclusion? Let's try using the definitions as they're stated, instead of imposing artificial new restrictions and then wondering why they don't work! :-) Or am I misunderstanding you?

>OK, here's the real issue for me: Date's definition of MVD does not match
>the characteristic I think he is after. That characteristic is the
 situation
>in which a relvar contains non-trivial B relation-valued attributes. This
>is supported by Date's statement just prior to his definition of MVD:
 "Intuitively,
>what this means is that, although a course does not have a *single*
 corresponding
>teacher---i.e., the *functional* dependence COURSE -> TEACHER does *not*
>hold---nevertheless, each course does have a well-defined *set* of
 corresponding
>teachers."

I think Date's definition stands up just fine. I need a more specific example to see why you think otherwise. In particular, your mention of a "relvar [that] contains non-trivial B relation-valued attributes" sounds meaningless to me. Again, trivial-B is a property of *relations*, not *relvars*. If you can put aside the whole notion of trivial-B and give an example of a relation that satisfies an MVD where you think it shouldn't, or vice versa, I'll see what I can do.

>Given that the distinguishing feature is that of a *set* of values of
 attribute set
>B that depend on another attribute set A, I see no reason to to split the
 relvar
>into *three* sets A, B, and C in the MVD definition. Herein lies my
 confusion. Even
>though I can agree with you on many of your points on MVDs *as Date defines
 them*,
>I don't see how Date's definition of MVD gets us where we really want to
go.

I don't see how to define MVD without using the sets A, B and C. The set C is simply defined to be the attributes not included in A U B. You could restate the definition without using the variable C simply by replacing "C" with "the attributes not included in A U B", but that would make the definition wordier and harder to understand.

When you write down A ->-> B you are implicitly identifying C as well, even if you don't say what it is. It's much easier to see whether a relation satisfies A ->-> B if you give a name to the set C. What's wrong with that?

>> Date actually gives examples like
>> this in his "Third Manifesto".
>
>Is that another book of his?

Date and a colleague wrote a treatise called "The Third Manifesto" that explains how they think relational-object-oriented database systems should be designed. I was referring to their book-length version of the treatise, with a similar title that I don't recall exactly. It's a good read, though they certainly don't have all the answers. Received on Fri Mar 31 2000 - 00:00:00 CEST