Re: 4NF is Where It Is At! [WAS Re: 1:1 relationships]

Barry wrote:
> Jan Hidders wrote:
>
> > Barry wrote:
> > >
> > > I find myself forced to come full-circle. I originally offered
> > > my vaguely-recalled expression of 4NF as:
> > >
> > > Given key k, non-key attributes of a and b, and f(k)->a, then
> > > f(k)->b for {k,a,b} to be in 4NF.
> > >
> > > In other words, if g(k)->b (i.e., the relationship of attribute b
> > > to the key is different to that of a), then {k,a,b} must be
> > > decomposed to {k,a} and {k,b} to satisfy 4NF.
> >
> > No, no, no! I am very sorry but this is *really* not correct. You
> > seem to be talking aboout functional dependencies here and these
> > are already dealt with by BCNF and lower. Moreover, it is also not
> > correct that if you have two functional dependencies which are
> > semantically different then you should split the table. And that is
> > simply not the case; no normal form (not even 5NF, the strongest
> > one, says that).
>
> No, I'm talking about functional *in*dependencies, a *very* different
> thing, in the way that a and b, relative to each other, relate to k.
> And which, I posit, is at the root of the MVD formulation you cite
> for 4NF.

Ah, I think I am beginning to see your point. But I am not really sure what a "functional *in*dependency" is. Is it really the same as a multi-valued dependency? Note that the absence of a functional dependency is not the same as a multi-valued dependency. Can you give me a (formal or informal) definition of a functional independency?

> > But I am also not really clear about what you are saying here
> > exactly. Let me ask you a question to verify something. If I have a
> > table R(name, address, phone-number) with key 'name', would you
> > then split it because you have the different dependencies
> > address(name) -> address and phone(name) -> pone-number?
>
> If that's the implication of the way I'd defined my fundamental
> attributes: yes, of course!

Just to get this straight. What I meant was that there are two functional dependencies 'name -> address' and 'name -> phone-number'. Are you really suggesting to split the relation just because these two functional dependencies are semantically different? (I hope you are now asking yourself what it exactly means to be 'semantically different'. :-))

Perhaps it would be helpful if you gave a definition of what you mean with statements like 'f(attr1) -> attr2'. The thing that puzzles me most is why you assign the name 'f', because in standard normalization theory dependencies are anonymous. When is it exactly that you assign the same name to two functional dependencies?

> Actually, I think far too little time is spent promoting the need to
> *strongly* define the elements before even thinking of normalisation.
> Since normalisation is ultimately an attempt to objectively decode
> the attribute definitions and what they mean in the way one attribute
> relates to another, I think that *that* is *really* "where it's all
> at".

I'm not sure I totally agree with this. In an ideal world you only can start normalization if you already know exactly what the relationships between the attributes are. On the other hand, when normalizing you are making (more or less) these relationships explicit in the table structures, and seeing them that way may lead to more insight into what these relationships exactly are. But perhaps that is what you mean.

-- 
  Jan Hidders