Re: Sixth normal form

On 11 aug, 16:54, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> "Jan Hidders" <hidd..._at_gmail.com> wrote in message
>
> news:1186829994.330618.293020_at_d55g2000hsg.googlegroups.com...
>
>
>
> > On Aug 10, 10:41 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> >> "Jan Hidders" <hidd..._at_gmail.com> wrote in message
>
> >>news:1186751333.018671.305210_at_j4g2000prf.googlegroups.com...
>
> >> > On 9 aug, 04:15, "Brian Selzer" <br..._at_selzer-software.com> wrote:
>
> >> >> The closure of the set of functional dependencies
> >> >> includes A --> C, which can only be preserved by the inclusion
> >> >> dependency,
> >> >> {A,B}[B] IN {B,C}[B].
>
> >> > Not necessarily. That depends on your definition of FDs over
> >> > attributes in different relations. The usual definition in
> >> > normalization theory is that they hold for a schema if they hold for
> >> > the natural join of all relations in the schema. In that case the FD
> >> > is preserved also without the inclusion dependency.
>
> >> I don't agree with the usual definition. It isn't strict enough, in my
> >> opinion.
>
> >> (1) A --> B /and/ B --> C; therefore A --> C.
> >> (2) A --> B /or/ B --> C; therefore A -/-> C.
>
> >> (1) is preserved by the IND {A, B}[B] IN {B, C}[B]; (2) is what is
> >> without
> >> the IND.
> >> While it is true that A --> C in {A, B} JOIN {B, C}, without the IND
> >> there
> >> can still exist values for A that do not determine a value for C.
>
> > Which sometimes is and sometimes isn't a problem. Just as not having
> > the inclusion dependencies in both directions may sometimes be a
> > problem but usually isn't. It's really quite simple. If you want to be
> > really equivalent you need both inclusion dependencies. Omitting one
> > or both gives you a more liberal schema which might be a good thing
> > because it now let's you represent information that you couldn't
> > before, but it might also be a bad thing because, as your example
> > nicely demonstrated, you now allow the violatio of constraints that
> > might be necessary for certain information to make sense.
>
> > With all respect, but why you are so insistent on making this
> > complicated and why you are so fixated on finding the one right way of
> > normalizing (which of course there isn't) is really beyond my
> > comprehension.
>
> I think it is important. I think that a database schema that has each
> cyclical dependency contained within a relation schema is "better" than one
> that doesn't. There are several reasons, some theoretical but mostly
> practical, but there isn't space in this post to go into them.

That is not the main point of our disagreement. The question was wether there is something special going on when going to 6NF.

> I think that
> 6NF is a mistake, despite its usefulness for temporal databases. If a
> database schema is already in 5NF, then a more "liberal" schema must contain
> nonsense. If a dependent attribute cannot always have a value, then the
> schema cannot be in 5NF. Decomposing a 5NF schema into several 6NF schemata
> without the necessary cyclical referential constraints is akin to permitting
> nulls (or more precisely, I-marks) for every dependent attribute in the 5NF
> schema.

Again. All this is also true for the other normal forms. In all cases you need cyclic inclusion dependencies if you want to be exactly equivalent. If you are not, then there is always the risc of allowing data that does not make sense in the given business context. Wether this risc exists or not is not something you can decide by a few quick and simple rules.

• Jan Hidders