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

Jan Hidders wrote:

> 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).

Doesn't having current_address and current_salary violate your definition of 4NF given earlier in the thread as:

    4NF: A relation is in 4NF if it holds for every     non-trivial multi-valued dependency X->>Y     that X is a candidate key

I'm thinking here that multiple people from different addresses might have the same current_salary ... and I never said :-) that co-residents could *not* work at the same company earning different salaries. So now I have current_address ->> current_salary *but* current_address is *not* a Candidate Key. And a case could also be made for the reverse.

Alas, the book-from-way-back whose formulations of Normal Forms I think I'm recalling is buried in boxes awaiting the second office move that is supposed to resolve my "temporary accommodation" status. I'd love to *not* be "flying solo" at this point %^}

Thanks for sticking with this ... Barry Johnson Received on Tue Jan 30 2001 - 03:43:07 CET