Re: boolean datatype ... wtf?

On 1 okt, 17:08, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> Erwin wrote:
>
> > Explain "cyclical referential constraint".
>
> > And explain "additional attribute".
>
> As a general observation, lower normal forms imply dependencies that
> "equivalent" higher normal forms do not imply. In that sense, the higher
> normal form is not really equivalent to the lower normal form. However,
> in general, we choose the higher normal form precisely because the
> dependencies implied by the lower normal form are invalid.
>
> BS assumes going from 5NF to 6NF that the additional dependencies
> implied by the 5NF design are valid and must be enforced, when the
> designer may have chosen 6NF precisely because those dependencies are
> invalid.
>
> None of BS's BS does anything to address my observation that proper
> support for 6NF demands a product where the addition of a table is no
> more costly than the addition of a column.- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -

Last things first: of course I agree with your last paragraph. In fact, I believe that in SIRA_PRISE, addition of a table is _AT MOST AS COSTLY_ as addition of an attribute. Thus: never more expensive, and oft times much cheaper.

First things last: I was inviting BS to demonstrate to us where there are "cyclical referential constraints" and/or "additional attributes" in the following equivalent designs, which are 5NF and 6NF, respecitvely:

(a)
VAR 5NF RELATION {K1:... K2:... A1:... A2:...} KEY {K1 K2}; (b)
VAR 6NF1 RELATION {K1:... K2:... A1:...} KEY {K1 K2}; VAR 6NF2 RELATION {K1:... K2:... A2:...} KEY {K1 K2}; CONSTRAINT A1A2ALWAYSPAIRED ISEMPTY(6NF1{K1 K2} XUNION 6NF2{K1 K2}); You said something about "the designer may have _chosen_ 6NF", but of course, if my constraint A1A2ALWAYSPAIRED simply does not apply, then there wasn't any "choice" to make to begin with. Received on Fri Oct 01 2010 - 20:21:19 CEST