First Normal Form (1NF)

A relation is in First Normal Form when every cell holds exactly one value from its column's domain, because the relational algebra that SQL is built on only knows how to compare, join, and index single scalar values — the moment a cell holds "Math, Science" the engine treats it as one opaque string, so WHERE Courses = 'Math' silently misses it, an index over the column is useless, and there is no row the database can point at to delete just one enrollment. 1NF is the structural precondition that makes the rest of relational querying actually work.

What 1NF actually requires

The rule is narrow and it is purely about the shape of a cell, not about uniqueness of values:

1. Each cell contains a single, atomic value — no comma-lists, arrays, nested tuples, or JSON blobs you intend to query into.
2. Each column draws from one domain (one type), so all values in Contact_Number are phone numbers, not a mix of phones and emails.
3. There are no repeating groups — you cannot model "up to three phones" as columns Phone1, Phone2, Phone3.

That is the whole list. 1NF does not say column values must be unique across rows; after you fix a multivalued cell, the same name or ID will legitimately repeat down a column.

Why the naive "each column value must be unique" rule is wrong. An earlier version of this page listed "all entries in a column should be unique for each row." That is a misstatement — it contradicts its own worked example, where Alice Smith appears in two rows once her two phone numbers are split out. Uniqueness is a property of keys (a candidate key identifies a row), not of every column. 1NF only governs whether a single cell is atomic.

Worked example 1: comma-separated phone numbers

Here is a Student table that violates 1NF. Contact_Number packs two phones into one cell as a comma list:

Trace the transformation cell by cell: row 101 carries two phones, so it becomes two rows that share the same student data; row 102 has one phone and stays a single row; row 103 splits into two. The atomic result:

Notice Alice Smith now appears twice — that is correct and expected, not a 1NF violation. But look at what happened to the key: Student_ID alone no longer identifies a row (101 maps to two rows). The new candidate key is the composite (Student_ID, Contact_Number). Splitting a multivalued column always pushes the key wider, and that widened key is exactly what the next step, 2NF, scrutinizes.

Worked example 2: multi-value Courses

A Student_Course table where one student's enrollments are crammed into a single Courses cell:

Decompose each cell into its members — Alice's two courses become two rows, Carol's three become three — keeping the rest of the row identical:

Now WHERE Course = 'Math' returns Alice and Carol correctly, an index on Course is meaningful, and dropping Carol from History is one targeted DELETE instead of a fragile string edit. The candidate key is the composite (Student_ID, Course): it takes both columns together to pin down a single enrollment. (Name now repeats and in fact depends only on Student_ID, not the full key — a partial dependency. 1NF tolerates it; 2NF is the form that removes it by splitting Name back into its own Student table.)

Where this sheet goes next: the 2NF and 3NF pages continue with the same three students in a fresh, already-1NF enrollment sheet — courses recorded as catalog IDs (C101, C102, C103) rather than this page's subject names and the department columns (Department_ID, Department_Name, Department_Location) added to the sheet — and carry the one messy table through both remaining splits, ending as a fully normalized Student / Department / Enrollment schema.

Pitfalls

• Pretending a delimited string is atomic. A tags VARCHAR holding "red,green,blue" is a repeating group in disguise. WHERE tags = 'red' fails and LIKE '%red%' falsely matches "tired" and can't use an index. If you query into it, it isn't atomic.
• Numbered columns are repeating groups too. Phone1, Phone2, Phone3 looks tidy but is the same violation spread sideways — it caps cardinality arbitrarily, wastes nulls, and forces OR across three columns to find one number. The fix is rows, not more columns.
• Forgetting the key changed. After decomposition the old single-column key is no longer unique. If you leave the primary key declared as Student_ID, inserts fail or the DB rejects the second phone. You must redeclare the composite key — and that is precisely the setup 2NF and 3NF operate on.
• "Atomic" is domain-dependent, not absolute. A full name "Alice Smith" is atomic if you never query first vs. last name; it is a repeating group if your app sorts by surname. Atomicity is judged against how the data is used, not by whether a value could be split further — otherwise every string is non-atomic.
• JSON/array columns are a deliberate de-normalization, not 1NF. Postgres jsonb and array types are useful, but treating one as a queryable list of facts reintroduces every 1NF problem. Reach for them only when the blob is opaque to your queries.

Takeaways

• 1NF is one rule: every cell is a single atomic value, with no repeating groups (neither comma-lists nor Col1/Col2/Col3).
• It does not require column values to be unique — repeated names and IDs across rows are normal and correct after decomposition.
• Splitting a multivalued column widens the primary key into a composite, which is the foundation 2NF and 3NF build on.
• "Atomic" is defined by how you query the data, not by whether a value is theoretically divisible.

Sources: E. F. Codd, "A Relational Model of Data for Large Shared Data Banks" (CACM, 1970); C. J. Date, An Introduction to Database Systems (8th ed.), on the use-dependent meaning of atomicity and the myth of absolute first normal form; Silberschatz, Korth & Sudarshan, Database System Concepts (7th ed.), Ch. 7 on normal forms and keys. Re-authored and deepened for this guide — corrected the false "each column value must be unique" requirement, added two fully traced before/after decompositions, the key-widening point, and a diagram.