Why is a relation whose only candidate key is a single column automatically in Second Normal Form, and what does that tell you about when to check for 2NF at all?
answer
- No proper non-empty subset of a one-attribute key
- Vacuously true, nothing to check
- Composite keys only: junction, order line, sensor plus time
- Surrogate id hides the natural key, does not fix it
- 2NF clean says nothing about 3NF
basics
~20 sA partial dependency means a non-key attribute depends on a proper subset of a candidate key. A one-attribute key has no non-empty proper subset, so no partial dependency can exist. Only composite candidate keys can violate 2NF.
solid answer
~50 s2NF forbids a non-prime attribute from depending on a **proper subset** of a candidate key. The only proper subset of a single-attribute key is the empty set, and a dependency from the empty set would mean the attribute is constant for the whole relation, which is not the case of interest. So once the relation is in 1NF, a single-attribute key makes 2NF hold vacuously. The practical consequence: **2NF is only worth checking when a candidate key is composite**. Junction tables, natural keys such as `(order_id, line_no)` or `(country, city)`, and time-series keys such as `(sensor_id, ts)` are where partial dependencies live. Two cautions. First, check *all* candidate keys, not the declared primary key. A table with a surrogate `id` primary key can still have a composite natural candidate key that carries partial dependencies. Second, a single-column key rules out 2NF violations only; the table can still fail 3NF or BCNF through a dependency whose determinant is a non-key attribute.
go deeper
State that there is no proper non-empty subset of a one-column key, so there is nothing that could be a partial dependency.
Add the practical screening rule: look at junction tables and natural composite keys, and remember the definition quantifies over all candidate keys.
Lead with the surrogate-key caveat and show a concrete example where a unique constraint reintroduces a composite candidate key and the 2NF violation with it.
Frame it as why key-arity heuristics are a poor proxy for data quality, and push the discussion toward where each fact is authoritative and how that is enforced.
## The formal reason Second Normal Form says: the relation is in 1NF, and no non-prime attribute is functionally dependent on a proper subset of any candidate key. A *proper subset* of a set S is a subset that is not S itself. If a candidate key is `{id}`, its subsets are `{}` and `{id}`. The second is not proper. The first, the empty set, would give a dependency of the form empty-set to A, which holds only when A takes the same value in every row of the relation, a degenerate case nobody models deliberately. So there is no proper subset that could serve as the determinant of a partial dependency, and the 2NF condition is satisfied trivially. It is satisfied *vacuously*, which is a stronger statement than "we checked and it was fine": there is nothing to check. ## What this means in practice Most operational tables in a typical application have a single-column primary key, often a surrogate integer or UUID. Those tables never have a 2NF problem, so scanning them for partial dependencies is wasted effort. Effort belongs where composite keys live: - **Junction or associative tables**: `enrollment(student_id, course_id)`, `role_permission(role_id, permission_id)`. - **Natural composite keys**: `order_line(order_id, line_no)`, `price(product_id, currency)`, `inventory(warehouse_id, sku)`. - **Time-series or partition-shaped keys**: `reading(sensor_id, taken_at)`, `daily_balance(account_id, as_of_date)`. In each of these, ask for every non-key column: does this fact belong to the pair, or to just one member of the pair? A sensor's location belongs to `sensor_id`, not to the reading. A course title belongs to `course_id`, not to the enrolment. ## The trap: candidate keys, not the primary key The definition quantifies over every candidate key, so "my primary key is one column" is not by itself the end of the analysis. Consider: `reading(id, sensor_id, taken_at, value, sensor_location)` with a surrogate `id` primary key and a UNIQUE constraint on `(sensor_id, taken_at)`. That unique constraint is an alternate candidate key, and it is composite. `sensor_location` is non-prime and depends on `sensor_id` alone, a proper subset of that candidate key. The relation therefore violates 2NF despite its single-column primary key. This is exactly why adding a surrogate key does not "fix" normalization. A surrogate key hides the natural key from the eye, not from the theory, and it certainly does not remove the duplicated location value or the update anomaly it creates. If you can rename a sensor's location and end up with two different locations for one `sensor_id`, the schema has the defect regardless of what the primary key column is called. In fairness, when the surrogate key is the *only* candidate key, because no natural uniqueness is declared or believed, then 2NF genuinely holds, and the redundancy question moves to 3NF. ## What a single-column key does not buy you 2NF is one of three classical conditions and the weakest one that involves keys. - It does **not** guarantee 3NF. `employee(emp_id, dept_id, dept_name)` has a single-column key and is in 2NF, yet `dept_id` to `dept_name` is a dependency whose determinant is a non-key attribute, so 3NF fails and the department name is still duplicated across employees. - It does **not** guarantee 1NF. If a column holds a comma-separated list or a repeating group, the relation fails earlier, and normal forms are cumulative. - It does **not** eliminate redundancy in general. Multi-valued and join dependencies, addressed by 4NF and 5NF, are independent of key arity. ## How to answer this in an interview Say the formal reason in one sentence, give the consequence (only composite keys can violate 2NF, so screen for them first), then volunteer the surrogate-key caveat unprompted. That last part is the differentiator: many candidates state the rule correctly but then conclude that sprinkling surrogate ids across a schema normalizes it, which inverts cause and effect. Normalization is about where facts live, not about the datatype or arity of the identifier column.
- Does adding a surrogate integer primary key to a table with partial dependencies fix the design?No. It can make the formal 2NF check pass if the natural composite key is no longer declared, but the duplicated values and their update anomalies remain unchanged. If the natural key is still a candidate key, for example through a unique constraint, the relation still violates 2NF outright.
- A table with a single-column primary key still repeats the same department name across many rows. Which normal form catches that?Third Normal Form. The determinant, dept_id, is a non-key attribute rather than part of a key, so the dependency is transitive rather than partial. 2NF is silent about it, which is a good reminder that the normal forms are cumulative checks, not alternatives.
saying these in an interview costs you the question
- Concluding that giving every table a surrogate id makes the schema normalized.
- Checking only the declared primary key and ignoring alternate composite candidate keys declared as unique constraints.
- Believing a table in 2NF is therefore free of redundancy.
- Saying a single-column key means the table is in 3NF or BCNF as well.