In relational schema design, what does it mean to say that a functional dependency X -> Y holds on a table, and how do you decide whether one actually holds for a given set of columns?

## The definition A relation has a set of attributes (columns). A **functional dependency** `X -> Y`, where X and Y are sets of attributes, asserts: > For any two rows r1 and r2 that may legally exist in the relation at the same time, if r1 and r2 are equal on every attribute of X, then they are equal on every attribute of Y. Read it as "X determines Y" or "Y is functionally dependent on X". It is exactly the mathematical notion of a function: one X value maps to at most one Y value, though many X values may map to the same Y value. ## Both sides are sets The left side is frequently composite. In an order-line table, neither `order_id` nor `line_no` alone determines `quantity`, but together they do: `(order_id, line_no) -> quantity`. The right side can also be a set, and `X -> {A, B}` is exactly equivalent to `X -> A` together with `X -> B`, so people usually write FDs with a single attribute on the right. ## Trivial vs non-trivial If Y is a subset of X the dependency holds automatically - `(a, b) -> a` is true of any data whatsoever. Such **trivial** FDs are true but useless; the interesting ones are non-trivial, where Y contains at least one attribute outside X. ## FDs come from the domain, not from the rows This is the single most-missed point. An FD is a *constraint*, a claim about all possible future states. Suppose a `users` table currently happens to have a distinct `phone` for every `country`. Running `SELECT country FROM users GROUP BY country HAVING count(DISTINCT phone) > 1` returns nothing - but that does not make `country -> phone` a real dependency; it is an accident of a small dataset. So data can only be used **negatively**. A query that finds two rows with the same X and different Y is a proof that the FD does *not* hold. The absence of such rows is weak evidence at best. Establishing an FD requires a business rule: "a person has exactly one national ID", "an invoice belongs to exactly one customer", "a product code determines its unit of measure". A closely related trap is **time**. Many apparent dependencies hold only at a point in time. `product_id -> price` is false in a table that stores historical order lines, because the price changes over the life of the product; it is true only if the column means "the price at the moment this row was written", which is a different attribute. ## Direction matters `employee_id -> email` says an employee has one email. It does not say an email belongs to one employee; that is the separate FD `email -> employee_id`. Both may hold, one may hold, or neither. Candidates who treat FDs as symmetric get key derivation wrong immediately. ## What an FD is not - **Not a foreign key.** A foreign key is a referential constraint between two tables; an FD is a constraint among columns within one relation. - **Not a correlation.** Statistical association is irrelevant; the FD is exact and absolute, with no tolerance for exceptions. - **Not implementation.** A `UNIQUE` constraint is one way an engine can enforce the FD `X -> everything`, but the FD exists in the design whether or not anyone declared a constraint. ## Why they matter Everything in schema theory is built on top of FDs. A **superkey** is a set X such that X determines all attributes. Decomposition rules test which FDs survive a split. The normal forms are stated purely as restrictions on which non-trivial FDs a relation is allowed to contain. Query optimizers use them too: knowing `X -> Y` lets a planner drop a redundant grouping column or prove that a join preserves row counts. Getting the FD set right is therefore the real work; the mechanical parts of normalization follow from it.