Re: Normalization by Composing, not just Decomposing

Dawn M. Wolthuis wrote:

> If I am understanding correctly, the process of normalization for any set of
> data attributes is a process of decomposing from one large set to several
> smaller ones. That makes sense when starting from scratch.
>
> But tests for determining whether data is normalized also seem to focus on
> whether it has been fragmented sufficiently and do not take into account
> whether the data has been TOO fragmented.

Lossless decomposition is the magic word. Slicing the data from information needs *without* losing information. Having said that, I think your thread on Order & meaning at least intuitively shows that when moving information from utterances in natural language into datastructures *some* of it's meaning is lost anyway.
Furthermore, a heavy burden is placed on 1. stating the inforation needs - it should be done perfectly, and
2. keeping everything connected, to indeed have a decomposition that is lossless.

Anyway, the irreducible normal form (one non-key attribute only) was recently mentioned again by Chris Date as the 6th normal form. I can't find my books on it, so I must do this from memory, please forgive the inacuracies:
AFAIK it (irreducible normal form - by another name) first popped up in NIAM (when it was called Nijssen's Information Analysis Method, late 1970's, after one of its originators, prof Nijssen. Now the N stand for Natural) - I don't remember what is was called in that context - something like 'elementary sentence'. NIAM is mentioned at the ORM site Jan Hidders kindly referred us to, http://www.orm.net, so maybe I can find the origins there.

> More progressive relational modelers might decide it is OK to model the
> relation-valued attribute of Nick Names within the first relation. But
> either option would then be acceptable and considered normalized (using
> newer definitions of 1NF).

 From here on I did not get your points, sorry. I don't know Pick (only from your example), and though I like XML, winning some over HTML as a markup language, maturity for modelling data along those lines is beyond the horizon, IMHO.

> If it is dependent on the key, the whole key, and nothing but the key, then
> don't split it out!

There are some anomalies which sometimes make it necessary to split beyond BCNF (i.e. Boyce-Codd normal form, easily to recognize with the phraze: all non-key attributes are dependent on the key, the whole key, and nothing but the key.

> ... In other words, there ought to be some "rules" that govern when we ought not
> split out data attributes, in general, as well as when we should decompose
> them.
>
> Or am I missing something?

Maybe the magic *lossless* I just mentioned?

> Perhaps what I skimmed includes this, but I just
> didn't pick it up. I know I haven't read everything out there -- are there
> other places where normalization or rules related to data modeling are not
> focussed exclusively on when to split attributes out, but also include
> bringing them together when they have already been unnecessarily decomposed?
Received on Thu Apr 08 2004 - 23:47:53 CEST