Re: Automatic Normalisation

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Wed, 22 Oct 2008 21:45:42 -0300
Message-ID: <48ffc94a$0$5481$9a566e8b_at_news.aliant.net>


xyzzy wrote:

> The rules governing whether a given relvar coupled with dependency
> rules are in a normal form are well defined.
>
> Unfortunately, many of the FDs are actually business rules in the
> designer's head, not easily expressed in the form FD A -> B etc. The
> easiest way to normalise data is (still) using pen and paper AFAIK!
> Possibly sketching an ERD or something.
>
> If you can list the attributes you need to track, and if you can
> identify the attributes' inter-dependencies, it should be possible to
> deduce any desired NF mechanically from the rules.
>
> I have searched the forum (and the FAQ, which appears to have been a
> non-starter) without success. I Googled 'automatic normalisation' and
> it looks like some people (mainly academics) have had a go at this.
> My question is, does anybody in this forum know of, of have any
> experience with software that guides the designer to the correct
> solution. Are any of them worth trying out?
>
> Alternatively, if there isn't anything, why can't it be done?
>
> Thanks

For the higher normal forms, more than one design will achieve the normal form with exactly the same information. Thus, normalization is not entirely deterministic.

Choice of candidate keys is a tradeoff among simplicity, stability, irreducibility, uniqueness and familiarity. How would one go about automating the value judgement involved in the tradeoff?

Different methodologies exist for identifying the information needing management and the functional dependencies among data. ORM springs to mind as a graphical variant. Once these are described, tools exist that will do the mechanical parts of spitting out a normalized design. At one time, the version of Visio that came with the Enterprise Architect version of Visual Studio would do that sort of thing. Perhaps it still does.

Because normalization is so mechanical and so well-understood, it is seldom what makes a difference between a good design and a poor design in any case; although, it often shows the difference between a competent designer and an incompetent one. Received on Thu Oct 23 2008 - 02:45:42 CEST

Original text of this message