Enterprise Rails

Chapter 6. Refactoring to Third Normal Form

We ended the last chapter with a simple set of tables and models that is seemingly impervious to invalid data. Through careful unit testing of both the data layer and the models in the application layer, we guaranteed that all references between tables will be valid and that each individual column can contain only appropriate data.

It’s tempting at this point to leave the realm of data modeling and begin writing a front-end for the theatre tickets website. We can imagine additional requirements for even the first version of our site, though, such as saving orders or knowing how many seats there are for sale in a given auditorium.

As secure as the physical layer we put together seems to be, the design itself is constricting. Features such as those just mentioned will be difficult to add in an elegant way. In this chapter, we will refactor the data model so that it is more open to future changes. First, the concept of third normal form (3NF) will be introduced. Applying 3NF will afford us the flexibility to add additional information to pieces of data that are bound currently, such as auditoriums and movie ratings. We will then add additional tables we know we will need relating to ticket orders; doing so presents more opportunities for refactoring.

Third Normal Form

In database theory, there are numerous normalization patterns, most of which are numbered ordinally: non-first normal form (NF²), first normal form (1NF), second normal form (2NF), ...