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). The reason I want to pack together so many normal forms is that they can be understood better collectively: when you have them packed you can easily see the differences. In some aspects I will follow the approach from a recent book by C. J. Date,
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 isatomic. It is common to say that a relation is in 1NF if all its attributes are atomic. A good, theory oriented book by C.J. Date (
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.The concepts I want to present may seem a bit complicated but, on the other hand, they are so basic that you rarely see it written. Still, they are essential for understanding how the normalization process works. One may prepare a perfect meal just by following a recipe but no one can master the art of cooking without understanding what’s going on behind-the-scenes. The same holds true with databases.
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 isnota book that dwellsdeeplyinto one specific aspect of DB theory or technology, quite the opposite. So if you want to master one topic that you work on this is not the book for you. If you have to write a specific piece of code using this-and-that then this is not the book you need right now. However, you may be interested in this book if you are a database newcomer or if you want to get a bigger picture of databases in general. Also, if you want to look at new solutions in DB business that could suit your company then you may be interested in this book. Personally, I read this book out of curiousity.