One thing I always come back to is the original intent of normalization: To reduce the number of data anomalies that can occur during INSERT, UPDATE, and DELETE operations. Normally, if tables are up to 3NF, then INSERT would never be a problem due to the constraints set up by primary and foreign key relationships. But UPDATEs and DELETEs do create potential issues. So, if you are not going to update or delete a row from a table (or there is little likelihood), then it is safe to denormalize an otherwise 4th or 5th model “down” to 3rd.

I’d love to hear more about 2-and-a-half normal form too. And I admit, I have never used CRUD analysis for the purposes of spotting opportunities to denormalize. That’s a great tip!!

Query performance and data model simplicity are two often cited reasons to denormalize. The former is a much more reasonable reason than the latter. The latter, in fact, sounds like laziness!

OLTP systems can be complex and data integrity and quality should be a primary focus. There are solutions to solve the query and reporting performance and join complexity problem, ranging from views to operational data stores built for query speed.

Denormalized tables could potentially expose the database to anomalies especially if multiple systems interact with the database at different levels.

There is a threshold to how much you can normalize, though. You could normalize every entity up to higher and higher forms but at some point — the tipping point, if you will — maintainability and understandability will erode, rendering the model too difficult to use. You’ll enter the land of academia and theoretical models which might be far from practical.

The balance is really for the modeler to discover (based on many factors such as industry, business needs, application access, compliance concerns, data quality policies, etc.). I don’t think that there is a magic formula. Some entities in the model may be normalized to 5th, while others to 3rd.

Some scenarios where denormalization might be the answer for performance purposes: (a) to repeat attributes in a table row so that calculations can be performed without the need to join to other tables, (b) when repeating groups of rows exist, but must be processed as a group, rather than by the row, or (c) when certain attributes in a table are queries so often that it makes sense to include them in the table.

When denormalizing, consider these factors: (a) the possibility that data integrity will be jeopardized, (b) that performance gains will still not be significant enough to make the risk worthwhile, and (c) that other methods may be available to handle the performance issues associated with highly normalized data.

Personally, I think denormalization makes the most sense on tables that are read-only with a very controlled process for updates, deletes, and inserts. For example, I modeled a database 10 years ago that rests mostly in 4th normal form, with some entities in 5th, and others in 3rd, where necessary. I have a separate database in mostly 2nd form for reporting (I designed this data model before I was aware of dimensional modeling; although my design is similar, it is NOT a true dimensional model). This database is updated using triggers from the primary OLTP database. Not only does this work, but it works very well. Those denormalized tables are “read only” to everyone but the triggers. Yet, several applications use them for reporting and query purposes. It is very fast, while my OLTP database is very secure.