Re: boolean datatype ... wtf?

On Oct 1, 11:08 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> Erwin wrote:
> > On 1 okt, 02:24, Brian <br..._at_selzer-software.com> wrote:
>
> >>On Sep 30, 3:22 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>
> >>>Paul Mansour wrote:
>
> >>>>On Sep 30, 11:17 am, Tegiri Nenashi <tegirinena..._at_gmail.com> wrote:
>
> >>>>>On Sep 30, 3:32 am, Tony Andrews <tony.andrew..._at_gmail.com> wrote:
>
> >>>>>>create table applications_with_immobolisers (application_id
> >>>>>>references applications primary key);
> >>>>>>... etc.
>
> >>>>>>That may be the right approach in a theoretical true RDBMS, but I'm
> >>>>>>pretty sure it would get me sacked as a lunatic in any SQL-based DBMS
> >>>>>>team!
>
> >>>>>Ah, this is why one don't usually find any unary relation in SQL Dbms!
> >>>>>This is very odd from theoretical perspective as one might expect
> >>>>>there are many more unary relations than binary ones, many more binary
> >>>>>than ternary and so on (akin to Zipfian distribution). Well SQL made
> >>>>>creating a table more expensive than adding an column, that is one of
> >>>>>its many implementational sins.
>
> >>>>Isn't creating a new table conceptually more expensive than adding a
> >>>>column, regardless of the implementation? Perhaps this is why Date's
> >>>>well-known supplier and parts database has a S.STATUS column rather
> >>>>than a STATUS table, and P.COLOR column column rather than P.COLOR
> >>>>table, and all the attendent foreign keys.
>
> >>>Concepts are free.
>
> >>>If one uses 6NF for temporal data, little difference exists between
> >>>creating a new table or adding a column.
>
> >>Ignorance or irresponsibility?
>
> >>Is Badour exhibiting his complete ignorance to the consequences of
> >>decomposing a 5NF database scheme into one that is in 6NF?  Unless the
> >>5NF scheme was already in 6NF, the equivalent 6NF scheme will contain
> >>numerous additional cyclical referential constraints that were not
> >>present in the 5NF scheme.  Assuming that the introduction of the
> >>additional attribute doesn't violate 5NF, no additional constraints
> >>are required that aren't implied by the candidate key constraint on
> >>the 5NF relation scheme.  Introducing a 6NF relation scheme to the
> >>equivalent 6NF database scheme requires explicit declaration of a
> >>cyclical referential constraint.  If it isn't just plain ignorance,
> >>then doesn't such careless disregard of those consequences border on
> >>irresponsibility?  People here have the impression that Badour knows
> >>what he's talking about.  Deliberately or carelessly misleading those
> >>who look up to them is behaviour usually attributible to politicians
> >>and lawyers, con-men and thieves--predatory personalities.
>
> > 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.

BULLSHIT! If any of the dependencies were invalid, then the schema would not have been in 5NF.

For example, given a 5NF schema

{A,B,C,D} KEY {A,B} The notrivial functional dependencies,

AB -> CD, AB -> C, AB -> D

are implied by the key.

In the 6NF schema,

{A,B,C} KEY{A,B}, {A,B,D} KEY {A,B} The functional dependency AB -> CD is lost. If that dependency were invalid in the 5NF schema, {A,B,C,D} KEY {A,B}, then it would not be in 5NF because that dependency is implied by the key, so the correct 5NF schema would be,

{A,B,C} KEY {A,B}, {A,B,D} KEY {A,B}, which just happens to also be in 6NF.

In order for the functional dependency AB -> CD to be preserved, a cyclical inclusion dependency

{A,B,C}[A,B] = {A,B,D}[A,B]

must be introduced, because only when it is in force does the FD AB -> CD hold in the view formed by joining {A,B,C} and {A,B,D} for all {A,B} in {A,B,C} or {A,B,D}.

{A,B,C}[A,B] = {A,B,D}[A,B] is equivalent to the conjunction of the noncyclical inclusion dependencies,

{A,B,C}[A,B] IN {A,B,D}[A,B] AND {A,B,D}[A,B] IN {A,B,C}[A,B]
>
> 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.- Hide quoted text -

That wasn't your original observation. It still doesn't change the fact that you're wrong, however. Received on Fri Oct 01 2010 - 19:54:47 CEST