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

Barry wrote:
> Jan Hidders wrote:
>
> > Barry wrote:
> > > ...
> > > 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
> >
> > Yes, this is a correct example. Let me explain how the definition
> > of 4NF deals with this. We are talking about the following relation
> >
> > R(Person, Curr_addr, Curr_home_ph, Curr_sal)
> >
> > It follows from the dependencies you gave that there is only one
> > candidate key for this relation: {Person, Curr_sal}. ...
>
> I'd intended {person} as the candidate key, and (unstated)
>
> earns( person ) -> current_salary
>
> as an example of "g(k)->b" justifying, in my 4NF "formulation",
> current_salary being split from the other attributes. And the prefixing of
> "current" on each was meant to imply there is only a single value in each
> case for a given candidate key.

Ok. I sort of assumed that some people might be having two jobs. :-) But the normal normal forms do not look at *why* the functional dependencies hold, but only *if* they hold. So, if earns( person ) -> current_salary holds then your example has the candidate key {person} and is therefore already in 4NF (and even in 5NF if there are no other join dependencies).

-- 
  Jan Hidders