Re: On Normalisation & the State of Normalisation

Thank you, Philip

> On Tuesday, 3 February 2015 23:44:52 UTC+11, com..._at_hotmail.com wrote:
> On Tuesday, February 3, 2015 at 4:16:26 AM UTC-8, Erwin wrote:
> > (which is how the normalization procedure really goes)
>
> Interestingly for this application: An envelope gets to a particular address. Ids do not appear on an envelope.

Yes.

> So after joining a correct set of tables and projecting out ids there must be a superkey among the remaining columns.

I understand where you are going with that. Both the auditors, and the metropolitan district superior of police prohibit "superkeys", on the basis that it causes human being to think like apes, and thus is an evil against society, condemned, etc. I completely agree.

AFAIC, the first three NFs are rock-solid. If taken to the fullness of the RM, then we do not need BCNF, 4NF, 5NF, they are all "definitions" of 3NF, that patch up holes, that only saboteurs and terrorists find and exploit. This is precisely why, I state, how I deliver, full Normalisation that satisfies any and all NFs that have not been "defined" yet. That was one reason that I was hired.

There are perfectly ordinary methods, within Normalisation (the first three NFs, taken to the fullness of their meaning re the RM, or in your terms BCNF, 4NF, 5NF, DKNF, ETNF, NFNF, etc, and any human intuitive logic that you may have at your disposal) and Relational Modelling (the RM, the IDEF1X Methodology that flows from the RM) to provide what the users need, without the cancer of "superkeys", and the various beastly dances attached to it.

AFAIC, the model fails, for a number of reasons, not identified by the readership thus far.

There is no point in "making it work" as is, via "superkeys" or posicle sticks. The faults must be corrected first, following that "superkeys", etc, will not be an option.

Cheers
Derek Received on Tue Feb 03 2015 - 15:09:01 CET