Author: Konrad Zdanowski

Assistant Professor at Cardinal Stefan Wyszyński University

A Unified View on Database Normal Forms: From the Boyce-Codd Normal Form to the Second Normal Form (2NF, 3NF, BCNF)

Normal forms for relations is a required topic of a database curriculum. Besides avoiding anomalies, which is already a big issue¹, knowing them certainly helps to understand what is going on in your or someone else’s database design. Even if at some point you decide to abandon a normal form, you should know what you are doing and how to pay a price for that. Here, I want to discuss normal forms up to Boyce-Codd Normal Form (that is 2NF, 3NF and BCNF).

What Is the Actual Definition of First Normal Form (1NF)?

The First Normal Form (1NF) is exceptional. The other normal forms (2NF, 3NF, BCNF) talk about functional dependencies and 1NF has nothing to do with functional dependencies. Moreover, we have precise definitions for other normal forms and there is no generally accepted definition of 1NF. Does 1NF Equate to “Atomic Attributes”? When you look at various descriptions of 1NF the word that you see most often is atomic. It is common to say that a relation is in 1NF if all its attributes are atomic.

How (And How Not) to Decompose Relations

When you read about normalization you usually get the set of conditions that a database in the nᵗʰ normal form should satisfy and the set of rules, a sort of a cook-book, for obtaining that normal form. But why these rules are safe to apply to your denormalized relations is a skip material. Here, I would like to present some elementary concepts on how we decompose relations and what can go wrong.

“Concise Guide to Databases” – briefly about everything

There are books that you plan to read. Then, there are books that you actually started reading and then stopped. Then, there are books you started reading and you hope to finish sometime. The last database book I did read was “Concise Guide to Databases” by Peter Lake and Paul Crowther. As title suggests this is not a book that dwells deeply into one specific aspect of DB theory or technology, quite the opposite.