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

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.

> 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!

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 *really* bridle when I see things like "Employee Name: Name of employee". I think a definition like that is even worse than not have a definition at all.

But that's probably a "soapbox" for a different thread!

> > But I do remember struggling with the ... dare I say it? ... Date
> > formulations of Normalisation, and then bumping into statements of
> > each more in the terms I cite above, and finding it much easier to
> > understand.
>
> Well, to be completely honest, I have been teaching normalization for a
> couple of years from his book and I have also been struggling with his
> definitions, but for exactly the opposite reason. :-) Date often tries
> to take intuitive shortcuts where the real formal definitions are
> actually more clear (provided you willing and able to understand them).
> Also he tends to simplify things (assume only one key for instance) and
> then later gets into trouble when he has to explain higher normal
> forms.

I wouldn't interpret my comments as being opposite to yours :-))

Barry J. Received on Sat Feb 10 2001 - 15:50:04 CET