1NF
1NF
Definition
A relation is in First Normal Form (1NF) if every attribute holds a single, atomic value per row — no repeating groups, no multi-valued cells, no nested tables. Every cell must contain exactly one value of the declared type.
The BEFORE Picture (Violates 1NF)
Imagine the registrar's office keeps a spreadsheet-style record per student instead of one row per enrollment:
| StudentID | StudentName | Courses |
|---|---|---|
| S1 | Asha | C1:Database Systems, C2:Operating Systems |
| S2 | Ravi | C1:Database Systems, C3:Computer Networks |
| S3 | Kiran | C1:Database Systems, C2:Operating Systems |
The Courses column holds a comma-separated list — a repeating group crammed into one cell. This violates 1NF: you cannot ask "which students are in C1?" with a simple WHERE Courses = 'C1', you cannot index individual course memberships, and you cannot enforce that a CourseID inside the string actually exists in a real Course table (no foreign key is possible into free text).
The AFTER Picture (1NF Achieved)
Split the multi-valued cell so each (student, course) pairing becomes its own atomic row — this is exactly the StudentCourse table this entire chapter has been using:
| StudentID | StudentName | CourseID | CourseName |
|---|---|---|---|
| S1 | Asha | C1 | Database Systems |
| S1 | Asha | C2 | Operating Systems |
| S2 | Ravi | C1 | Database Systems |
| S2 | Ravi | C3 | Computer Networks |
| S3 | Kiran | C1 | Database Systems |
| S3 | Kiran | C2 | Operating Systems |
Every cell now holds exactly one atomic value. CourseID can be a proper foreign key, WHERE CourseID = 'C1' works with a plain index, and standard relational operators (joins, aggregates) apply normally.
An Important Realization for This Chapter
The StudentCourse table used throughout 21.1-21.11 has always been in 1NF — every attribute in every row is already atomic. And yet it still suffered from redundancy and all three anomalies! This is the key lesson of 1NF: it is necessary but nowhere near sufficient. Being in 1NF only guarantees atomicity; it says nothing about which key each attribute is properly dependent on. That is exactly what 2NF (21.13) and 3NF (21.14) go on to fix.
Edge Cases
- A comma-separated list is the classic 1NF violation, but so is a JSON blob or XML fragment stuffed into a single column to represent multiple values — same underlying problem, different syntax.
- Splitting a name into
FirstName/LastNameis a design choice about granularity, not a 1NF requirement — 1NF only forbids multiple values of the same conceptual attribute in one cell (e.g., two course memberships), not a single compound value like a full name. - A repeating group implemented as
Course1, Course2, Course3columns (instead of a comma-separated string) is also a 1NF violation — it just disguises the multi-valued nature as several fixed columns instead of one delimited cell, and still can't handle a student with a fourth course.
Key Takeaways / Interview Angle
- Q: State 1NF in one sentence. Every attribute value must be atomic (single-valued) — no repeating groups or multi-valued cells.
- Q: Is the StudentCourse table used throughout this chapter in 1NF? Yes — it always has been; its problems (redundancy, anomalies) come from 2NF/3NF violations, not 1NF violations.
- Q: Why is `Course1, Course2, Course3` columns just as bad as a comma-separated list? Both encode a variable-length, multi-valued fact using a fixed, non-atomic structure — one just spreads it across columns instead of packing it into a delimiter-separated string; neither is queryable/indexable the relational way.