An atomic value is one that cannot be broken down further while retaining its business meaning. A full name such as “Peter A. Carter” is not atomic when the application needs its first name, middle initial, or last name separately; individual characters do not count because they lack that context. section 4.1.2
Mistake: storing a full customer name
A CustomerName column can seem convenient until a mail merge needs “Dear Robert,”. Extracting the first name requires string parsing, making queries harder to write, read, and run than selecting a dedicated FirstName column. section 4.1.2
SELECT SUBSTRING(CustomerName, 0, CHARINDEX(' ', CustomerName, 1))
FROM Customers ;
This query illustrates the extra parsing required when first and last names are stored together rather than as meaningful separate attributes. section 4.1.2
Use atomic values as part of a practical 1NF check:
- Split a compound attribute when its meaningful parts must be stored, selected, or managed independently. section 4.1.2
- Move repeating groups of attributes into a different entity rather than packing a collection into one row. section 4.1.3
- Give attributes unique names; attribute and row order should not carry meaning. section 4.1.3
- Confirm business meaning and rules with an application owner or business analyst before deciding what a value represents. section 4.1.3
Atomicity is not a demand to split every stored value indefinitely. Deliberate denormalization can be appropriate after normalization, including storing address data as JSON or working with analytical data and staging tables. The decision should be intentional and weighed against the cost of harder queries and maintenance. section 4.1.2 section 4.1.3
Atomic attributes support normalization, but they do not solve every design problem. Duplicating category details across subcategories wastes space and makes reads, memory use, indexes, inserts, and updates less efficient; separate entities linked by primary and foreign keys avoid that repetition. section 4.1.2 section 4.1.3
