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

From: Barry <BarryJJ_at_ATTGlobal.Net>
Date: Fri, 26 Jan 2001 17:06:10 -0500
Message-ID: <3a71f6f0_1_at_news1.prserv.net>


Jan Hidders wrote:

> Barry wrote:
> >
> > And this is where I've concluded 4th Normal Form is actually the most
> > important of all. At the risk of being flamed for overly-simplifying it,
> > 4NF asks: do all non-key attributes have the *same* relationship to the
> > key? If not, then split the non-key attributes apart.
>
> I do not really know how to say this but I think you are
> over-simplifying. :-) The problem is that you are talking about non-key
> attributes where the real 4NF talks about *all* attributes. So your
> normal form is stronger than 3NF but weaker than 4NF and different from
> BCNF. So I suggest that we call it the BJNF and define it as follows:
>
> A relation is in BJNF if
> 1. all multi-valued dependencies are functional dependencies, and
> 2. it is in 3NF.
>
> I conjecture that -- just as 3NF -- you can always reach BJNF while
> staying dependency preserving.

Been a *long* time since I've had an opportunity to discuss this, so I'm doubtless in need of a refresher. But the 4NF formulation I remember is something like:

For tuple (k, a, b) where k is the key, a and b are non key attributes, and f( k ) -> a, then f( k ) -> b for 4NF to be satisfied. If g( k ) -> b, then the tuple needs to be decomposed into (k, a) and (k, b).

The classic example used to be
  lives_at( person ) -> current_address
and
  lives_at( person ) -> current_home_ph# but
  lives_at( person ) -/-> current_salary

Of course, cell phones mean I need to find a new example :-( But even then, current_salary and current_address have a full, singular, and direct relationship to the key satisfying 3NF, but not the *same* relationship so I need to split current_salary off to satisfy 4NF.

But I guess my rustiness leaves me unclear on how this and my application of it is wrong/different to what you are saying. I welcome you setting me straight.

TIA ... Barry J. Received on Fri Jan 26 2001 - 23:06:10 CET

Original text of this message