Re: Question re: Practical Issues in Database Management

From: TroyK <cs_troyk_at_juno.com>
Date: 22 Mar 2007 15:28:16 -0700
Message-ID: <1174602496.621571.29900_at_p15g2000hsd.googlegroups.com>


On Mar 22, 3:03 pm, Joe Thurbon <use..._at_thurbon.com> wrote:
> Carlos M. Calvelo wrote:
> > On 22 mrt, 00:49, Joe Thurbon <use..._at_thurbon.com> wrote:
> >> I've had a look on the dbdebunk website, but errata are only available
> >> via email. As far as I'm aware, the site is no longer kept active.
>
> >> Does anyone know if the errata are available through another means?
>
> > Another (different!) errata at
> >http://www.dbdebunk.com/page/page/668187.htm
>
> > The two lists seem to overlap.
>
> Hmm, an update anomaly?
>
> Thanks Carlos.
>
> To all:
>
> It seems to me that neither of the errata I've been pointed to address
> the issue that I originally mentioned in this thread. Namely, that the
> definitions of multivalued dependencies and 4th normal form given in the
> book seem to be overly strict.
>
> In particular, if a multivalued dependancy is defined as:
>
> "A MVD between two columns exists when sets of values in one column are
> each associated with values in another column"
>
> and 4th normal form is defined as
>
> "If no MVDs exist between columns, then a table is in 4th normal form"
>
> Even assuming that 'no MVDs' is shorthand for 'no MVDs that are not also
> FDs' these definition would mean that the table,
>
> EMP# ACTIVITY
> ==============
> 130 DEBUG
> 130 SUPPORT
>
> would not be in 4th normal form. (Since, it's clear that there is a set
> of values {DEBUG, SUPPORT} that is functionally dependant on EMP#. The
> caption of the example on page 138 says that the above table is in 4th
> normal form (as do all other definitions I've read).

But the set of values is not, in fact, functionally determined by emp #.

By taking the projections as detailed in the book, we are able to assert, e.g., that employee "130" is also responsible for activity "DESIGN" on all of the projects on which she works by simply adding that tuple to the EMP-ACT relation.

Prior to the normalization, it would have been necessary to record the fact multiple times, once for each of the projects to which employee 130 is assigned. (Try adding the "DESIGN" activity to table A in the diagram, paying attention to the business rules, to see the effect).

>
> Have I found an error in the book (unlikely). And if not, what am I missing?

Perhaps unlikely, but not impossible; there is another error not listed in either of the linked errata -- carefully examine the BCNF example on P136.

>
> Cheers,
> Joe
Received on Thu Mar 22 2007 - 23:28:16 CET

Original text of this message