State the formal definition of Third Normal Form in terms of functional dependencies, and explain why it includes the clause allowing the dependent attribute to be prime.

## The definition, precisely Let R be a relation with a set F of functional dependencies. R is in **Third Normal Form** if, for every non-trivial dependency X to A in F (non-trivial meaning A is not contained in X), at least one holds: 1. **X is a superkey of R** (X functionally determines all attributes of R), or 2. **A is a prime attribute** (A belongs to at least one candidate key of R). Most textbook statements decompose the right-hand side to a single attribute, which is why the clause reads "A is prime" rather than "A is a set of prime attributes". This formal version is equivalent to the informal one, that no non-prime attribute is transitively dependent on a candidate key, but it is much easier to apply mechanically: enumerate the candidate keys, then test every dependency against the two clauses. ## Why clause 2 exists Drop clause 2 and you get **Boyce-Codd Normal Form**: every non-trivial dependency must have a superkey determinant. BCNF is cleaner conceptually and removes more redundancy. The price is that a lossless BCNF decomposition may fail to be **dependency preserving**, meaning some original dependency can no longer be enforced by checking keys within a single resulting relation. Enforcing it would require a join at every write, which no engine does with a declarative constraint. The classical example: `ADDRESS(street, city, zip)` under the simplifying assumptions that a zip code lies in exactly one city, and that street plus city identifies a zip. - Dependencies: `(street, city)` to `zip`, and `zip` to `city`. - Candidate keys: `(street, city)` and `(street, zip)`. - Prime attributes: `street`, `city`, `zip`. Every attribute is prime here. Test `zip` to `city`. Is `zip` a superkey? No, it does not determine `street`. Is `city` prime? Yes, it is in the key `(street, city)`. Clause 2 rescues it, so the relation is in 3NF but not in BCNF. To reach BCNF you would decompose into `ZIP_CITY(zip, city)` and `STREET_ZIP(street, zip)`. That is lossless, but the dependency `(street, city)` to `zip` now spans both relations: neither one can enforce it with a key constraint, so two rows could assert different zips for the same street and city without any single relation being violated. You lost a real business rule from the declarative schema. ## The guarantee 3NF buys There is a synthesis algorithm (from a minimal, or canonical, cover of the dependency set) that produces, for any relation schema, a decomposition that is simultaneously **in 3NF**, **lossless-join**, and **dependency-preserving**. Sketch: compute a minimal cover of F; create one relation per dependency in the cover, combining dependencies with the same determinant; if no resulting relation contains a candidate key of the original, add one relation consisting of a candidate key. The last step secures losslessness; one relation per cover dependency secures preservation. BCNF has only a lossless-join guarantee. A dependency-preserving BCNF decomposition does not always exist, and the address example above is a proof by counterexample. That asymmetry is the entire practical reason 3NF is the normal form named in design standards and interview answers, while BCNF is treated as "go further when it is free". ## Applying the definition in an interview 1. Derive the candidate keys from the dependency set, using attribute closure. Do not accept the declared primary key. 2. Mark every attribute appearing in any candidate key as prime. 3. For each non-trivial dependency, test clause 1, then clause 2. A dependency failing both is a violation and names the decomposition you need. This mechanical procedure is more reliable under pressure than hunting for chains, because chains are easy to miss when there are several candidate keys. ## The residual redundancy 3NF tolerates Be honest about the cost. Because clause 2 permits a non-superkey to determine a prime attribute, a 3NF relation can still repeat data. In `ADDRESS`, the fact "zip 10001 is in New York" is stored on every street row with that zip, and an update anomaly is possible: a partial update can leave two cities for one zip. 3NF does not stop that; only BCNF does, at the cost of the lost dependency. The design judgement is therefore explicit rather than automatic. If the tolerated dependency is over a stable, small domain such as zip codes, the residual redundancy is cheap and you keep 3NF plus the declarative constraint. If it is over volatile data with frequent updates, you may prefer BCNF and enforce the lost dependency in application logic or a trigger, accepting that the enforcement is no longer declarative. ## Common confusions - "Prime" means part of *some* candidate key, not part of the primary key. With multiple candidate keys the prime set is larger than people expect, and that changes the verdict. - Trivial dependencies, where the right side is contained in the left, are excluded; otherwise every relation would fail. - 3NF is defined over all candidate keys, so a relation can pass with respect to one key and fail with respect to another only if you applied the definition wrongly; the quantifier is over dependencies, not keys.