Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Normalization by Composing, not just Decomposing

Re: Normalization by Composing, not just Decomposing

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Wed, 14 Apr 2004 01:59:06 +0200
Message-ID: <407c7ecc$0$562$e4fe514c@news.xs4all.nl>


Jan Hidders wrote:

[Date's 6NF]
> mAsterdam wrote:

>> Jan Hidders wrote:
>>>  It's not uncontroversial, by the way.
>> Could you share some of the controversy?

>
> Well, to start with, most experts on temporal databases that I know
> don't agree with Date's PACK/UNPACK approach and consider these algebra
> operators fundamentally flawed. This is because they don't correspond to
> easily implementable operators like the classical algebra operations. As
> it happens I don't agree completely with that criticism, but that is
> another matter.

Maybe we should just write them - or is the criticism about something else?

> Keep in mind that just because Date writes something in his
> "Introduction ..." or in of his other books, that does not mean that it
> is widely accepted by the research community and all the other experts.
> Usually it is the non-experts that are impressed the most by Chris
> Date's writings. You may also notice that Date doesn't get the
> definition of 5NF right in his "Introduction ...". Not a good start for
> somebody who wants to tell the world how 6NF should be defined.... But I
> digress.

Heh - when I read that chapter long time ago I constructed an example myself (about tracking manufactured parts placed by subcontractors at projects for garantee litigations), and I could not map it to Date's explanation. I never got around to discuss it with another reader :-)

> Another criticism is that 6NF is too strict. If there is no intervals
> anywhere it still says you have to normallize to INF, (all JDs are
> trivial) and not just to PJNF. Why would you do that? Sure, you could
> argue that we always want access to historical information, so we always
> have an interval, but why not be modest here and let the data modeler
> decide.

See below.
>

>>> ... Actually finding out what the elementary facts are is essentially 
>>> the same as normalizing to 5NF. 
>>
>> That is, only when you exclude intervals as key-attributes.
>> When you allow intervals as key-attributes (and... why not?)
>> it maps to 6NF.

>
> Oops, I'm afraid I have to backpedal a little here, so it is my turn to
> apologize. Splitting a relation into elementary facts is of course
> equivalent to normalizing to INF which is evidently not the same as
> normalizing to PJNF.
>
>> My take is that Date, Darwen and Lorenzos formulated 6NF the way they 
>> did to make it fairly obvious that 6NF is more strict than PJNF (5NF) 
>> (i.o.w. that every set of relations (relational variables) in 6NF is 
>> by definition also in 5NF so 6NF is another step on the lossless 
>> decomposition ladder). However, until I see an counterexample - 
>> preferably pizza orders related - I'll look at 6NF as an alternative 
>> predicate for the INF, the irreducable normal form (loose definition: 
>> just one non-key attribute) (BTW great
>> acronym, don't you think? :-).

>
> Hmmm, actually, you might be on to something there. My first thought was
> that *clearly* Date's 6NF is strictly stronger than INF, but then I
> realized the following. If there is a generalized JD (in Date's terms)
> then that means there is a classical JD on the unpacked relation. But
> from that it follows that the same JD also holds on the packed relation!
> So for every generalized JD on the (packed) relation there also holds
> the equivalent (w/o the ACL) classical JD on the (packed) relation. As a
> consequence Date's 6NF and INF are always equivalent.
>
> I wonder if Date et al. have realized that.

I think they did (just a hunch).
But it may depend on *not* letting the modeller decide. My bet is: there are more books in the making :-) Received on Tue Apr 13 2004 - 18:59:06 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US