What is the goal of normalization in database design?

Concept

Database normalization is the systematic decomposition of a relational schema into smaller tables guided by functional dependencies (1NF -> 2NF -> 3NF -> BCNF). Its governing design objective, as stated in relational database theory, is to eliminate insertion, deletion, and update anomalies that occur when a single fact is stored redundantly across multiple rows — not merely to shrink storage size or speed up queries.

Application

Applying that principle here: storing a fact once and referencing it via a key removes the possibility that inserting a new record forces an unrelated fact to be entered, that deleting a record erases a fact that should have survived, or that updating a fact requires touching several rows to keep the data consistent. Reducing redundancy is the mechanism decomposition uses, but avoiding these three named anomalies is the design goal that mechanism serves.

Contrasting the other options

• 'To increase data redundancy' runs opposite to what normalization does: functional-dependency decomposition is used to shrink the number of stored copies of a fact, not increase them.

• 'To optimize query performance' names a possible side effect, not the design objective: a normalized schema is usually split into more tables, which typically requires more joins per query — organizations often denormalize deliberately afterward to regain query speed.

• 'All of these' would require every listed statement to hold at once; since the query-performance statement does not hold as a general design objective, the combined claim fails.

So the option that matches relational database theory's stated purpose of normalization is reducing data anomalies — insertion, deletion, and update anomalies — through functional-dependency-driven decomposition.