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

xyzzy wrote:

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.

xyzzy wrote:

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.

xyzzy wrote:

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.

xyzzy wrote:

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.

xyzzy wrote:

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.

xyzzy wrote:

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.

xyzzy wrote:

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.

xyzzy wrote:

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.

xyzzy wrote:

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.