Re: How to normalize this?

From: Erwin <e.smout_at_myonline.be>
Date: Sun, 5 May 2013 12:32:35 -0700 (PDT)
Message-ID: <1bfb1fe5-85f2-4cc9-af50-a88a667b601e_at_googlegroups.com>


Op zondag 5 mei 2013 10:10:49 UTC+2 schreef Jan Hidders het volgende:
> On 2013-05-04 23:32:18 +0000, ... said:
>
>
>
> > On Thursday, May 2, 2013 6:23:07 AM UTC-7, Jan Hidders wrote:
>
> >> But most> textbooks I know are correct and clear on this and will state
>
> >> that the> goal is for example a lossless-join and
>
> >> dependency-preserving> decomposition.
>
> >
>
> > Can you name some? Because I don't think books are clear about
>
> > normalization within design, which involves generated predicates and
>
> > constraint preservation. Normalization per se assumes the generated
>
> > components are projections of the original, ie are suitably
>
> > constrained, without addressing the management of those constraints (eg
>
> > introducing FKs for lost FDs).
>
> >
>
> >> 1. Apply the 3NF normalization procedure we discussed earlier
>
> >> 2. Include with each component only the FDs that generated that component
>
> >
>
> > It's not clear to me what you are describing or how it relates to
>
> > arguing against stopping at 3nf.
>
>
>
> I've described to you a normalization algorithm that seems to produce a
>
> schema in BCNF that is also lossless-join and dependency preserving,
>
> but also has no inter-component dependencies. That's not supposed to be
>
> possible according to the usual normalization explanation. So what went
>
> wrong here?
>
>
>
> -- Jan Hidders

That's simply not true is it ?

You are referring to the three-table decomposition, right ?

That one does have the inter-component rule that R1 JOIN R2 === R1 JOIN R3 (as I pointed out), no ?

"What went wrong" imo is that your decomposition did not match the original "spirit" of the operation. In which relation schemas get split in _exactly_ two, with the dependent attributes of the "small" FD (bc->e) moved _out of_ the schema. your three-way split is either not a split in exactly two, or it is two subsequent splits-in-two where the first does _not_ move any attribute "out of the schema" (precisely because it is still needed for the second split). Received on Sun May 05 2013 - 21:32:35 CEST

Original text of this message