Editing Denormalization (section)

== Denormalization versus not normalized data ==
A denormalized data model is not the same as a data model that has not been normalized, and denormalization should only take place after a satisfactory level of normalization has taken place and that any required constraints and/or rules have been created to deal with the inherent anomalies in the design. For example, all the relations are in [[third normal form]] and any relations with [[Join dependency|join dependencies]] and [[Multivalued dependency|multi-valued dependencies]] are handled appropriately.

Examples of denormalization techniques include:
* "Storing" the count of the "many" elements in a [[One-to-many (data model)|one-to-many relationship]] as an attribute of the "one" relation
* Adding attributes to a relation from another relation with which it will be joined
* [[Star schema]]s, which are also known as fact-dimension models and have been extended to [[snowflake schema]]s
* Prebuilt summarization or [[OLAP cube]]s

With the continued dramatic increase in all three of storage, processing power and bandwidth, on all levels, denormalization in databases has moved from being an unusual or extension technique, to the commonplace, or even the norm.{{when|date=June 2024}} For example, one specific downside of denormalization was, simply, that it "uses more storage" (that is to say, literally more columns in a database). With the exception of truly enormous systems, increased storage requirements is considered a relatively small problem in the 2020s.