Re: Sixth normal form
Date: Sat, 11 Aug 2007 14:54:56 GMT
Message-ID: <45kvi.45092$Um6.17838_at_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 - 16:54:56 CEST