Re: Sixth normal form

From: Brian Selzer <brian_at_selzer-software.com>
Date: Sat, 11 Aug 2007 14:54:56 GMT
Message-ID: <45kvi.45092$Um6.17838@newssvr12.news.prodigy.net>

"Jan Hidders" <hidders_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. Having spent uncountable hours cleaning up databases so that they can be integrated or converted, I have a particularly strong aversion to anything that permits nonsense in the database.

> -- Jan Hidders
>
Received on Sat Aug 11 2007 - 09:54:56 CDT