When a Normalized Design Is Still a Bad Design

Learning outcomes

A schema can satisfy 3NF and still be a bad design. Normal forms address specific dependency-based redundancy problems; they do not automatically solve poor naming, wrong entity boundaries, missing temporal semantics, weak integrity, unusable APIs, performance bottlenecks, privacy risks, or misunderstood business rules.

Normalization cannot fix wrong requirements

Suppose the model says each Asset has exactly one owner forever. You can normalize that model perfectly and still be wrong if ownership changes over time or co-ownership exists.

Wrong entity boundaries

Imagine Person and Customer are modeled as separate entities even though Customer is merely a role a Person or Organization can play. The tables may each be in 3NF yet duplicate identities and create synchronization problems.

Over-normalized lookup tables

Some designs create a table for every tiny code:

YesNoLookupGenderLookupBooleanLookupPriorityLookupSortDirectionLookup

Formal normalization does not require a separate relation for every finite domain. A check constraint or domain type may be simpler when values have no independent metadata or lifecycle.

Excessive one-to-one fragmentation

A design may split one concept across many 1:1 tables:

CustomerCoreCustomerNameCustomerStatusCustomerCreatedAtCustomerPreferences

All tables can be normalized while the design becomes expensive to query and difficult to understand. Split for meaningful lifecycle, security, optionality, scale, or subtype reasons—not mechanically.

Missing historical semantics

A 3NF Asset table with:

asset_idcustomer_id

may correctly represent current ownership but cannot answer who owned the asset last year. If history is a requirement, normalization alone will not invent temporal structures.

Missing transaction semantics

Normalized tables can still permit inconsistent multi-table states if transaction boundaries are poorly designed. For example, WorkOrder may be marked closed while an active assignment remains open unless the close operation enforces all required invariants atomically.

Performance is a separate dimension

A normalized OLTP schema may require joins for common reads. That is often acceptable and indexable. In other workloads, deliberate denormalization, materialized views, caches, or star schemas may be justified.

The important point is to denormalize intentionally after understanding the source-of-truth model and consistency cost.

Normalized but poorly indexed

3NF says nothing about indexes. A perfectly normalized WorkOrder table with no useful index on asset_id may perform poorly for asset-history queries.

Normalized but insecure

Normal forms do not prevent:

• storing unnecessary sensitive data;
• cross-tenant references;
• weak authorization boundaries;
• overly broad database privileges;
• retaining personal data longer than necessary.

Normalized but badly named

T1(id, x, y)T2(id, t1_id, z)

can be normalized and still be almost useless to humans. Naming remains part of design quality.

Normalized but missing constraints

This relation can be structurally normalized:

PartUsage(  part_usage_id,  work_order_id,  part_id,  quantity)

but still allow negative quantities or references to nonexistent parts if constraints are absent.

Normalized but wrong grain

Suppose PartUsage intends one row per individual inventory issue, but the key enforces only one row per work_order + part. The relation can look normalized while collapsing multiple events into one aggregate fact.

Normalization and reporting grain

Normalized schemas often contain several child relations. Joining them carelessly can multiply rows. Reporting models need explicit grain, aggregation strategy, and semantic layers.

When denormalization is valid

Examples:

• precomputed summary totals;
• materialized views;
• read-optimized search documents;
• warehouse fact/dimension models;
• immutable event snapshots.

But every duplicate fact needs an owner and refresh strategy.

Design review after normalization

WorkshopHub example: normalized but incomplete

Assume these 3NF tables exist:

CustomerAssetWorkOrderTechnicianWorkOrderAssignmentPartPartUsageWorkOrderStatus

Open questions still include:

• Does Asset ownership require history?
• Can technician assignments overlap?
• Who is allowed to close a work order?
• How are status transitions audited?
• What indexes support common queries?
• How are soft deletion and retention handled?

Do not normalize beyond useful semantics

Normalization is not a contest to maximize table count. The objective is to represent independent facts cleanly and reduce harmful redundancy while preserving understandable, enforceable, performant semantics.

Chapter 8 final checkpoint

Summary and next chapter

Chapter 8 applied 1NF, 2NF, and 3NF from structural foundations through dependency-based decomposition, then showed their limits. Chapter 9 goes deeper into advanced normalization: BCNF, multivalued dependencies and 4NF, join dependencies and 5NF, reference-data design, and choosing a practical normal form.

References

• C. J. Date, Database Design and Relational Theory.
• Martin Kleppmann, Designing Data-Intensive Applications.
• Ramez Elmasri and Shamkant B. Navathe, Fundamentals of Database Systems.
• Martin Fowler, Patterns of Enterprise Application Architecture.