Re: Sixth normal form
From: Brian Selzer <brian_at_selzer-software.com>
Date: Fri, 17 Aug 2007 17:15:18 GMT
Message-ID: <GIkxi.46656$Um6.36828_at_newssvr12.news.prodigy.net>
>> "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.
>> 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.
Date: Fri, 17 Aug 2007 17:15:18 GMT
Message-ID: <GIkxi.46656$Um6.36828_at_newssvr12.news.prodigy.net>
"Jan Hidders" <hidders_at_gmail.com> wrote in message news:1187247448.870426.256440_at_b79g2000hse.googlegroups.com...
> 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
>
Received on Fri Aug 17 2007 - 19:15:18 CEST