Normal Form

This is a (possibly apocryphal) story I have heard regarding why DrCodd decided to call the various Normal Forms "Normal". It might be more apocryphal than it was when I heard it, because my memory is not what it could be. If anyone knows better, please speak up.

When Codd was developing the theory of relational databases, he was of course thinking in terms of "relations" rather than "tables". He wanted to have a good term for the process of factoring relations to eliminate redundancy, but nothing sprang immediately to mind.

It happened that, as he was contemplating this element of nomenclature, he saw a report on television that spoke of Nixon "normalizing relations" with China. "Aha!" he thought to himself. "If Nixon can normalize relations, then by God so can I!"

Hence the term "normalizing" as it is applied to relational databases, and the various "Normal Forms".

• http://web.archive.org/web/20011106224231/http://www.prestwood.com/forums/database/info/normalize.html -- supports this story to some extent.

---

I find this dubious. "normal form" is a standard phrase in mathematics; for instance, each permutation has a normal form (namely, a standard way to write it). Is there an online version of Codd's original (1970) paper?

-- JamesWilson

Yes, at http://www.acm.org/classics/nov95/toc.html. -- SeanOleary

---

There seems to be two parts to database normalization. One is factoring out the repetition (OnceAndOnlyOnce). There does not seem to be much dispute over this aspect. But, there is dispute over splitting tables into smaller tables to offer a field grouping. For example, in an Employee table there might be a few fields that are only used if the employee is a manager. Some designers will create a second table called Managers and put those dedicated fields in it. The problems I see with this is that it creates more tables to manage, and future requirement changes may give non-managers access to perks that only managers used to receive. Thus, I avoid one-to-zero-or-one relationships usually. Similar issues may apply to normalization outside of databases.