Data Modeling & Schema Design

Functional Dependencies

A functional dependency X → Y states that any two legal tuples agreeing on X must agree on Y. Dependencies capture stable business rules, support candidate-key derivation, and reveal where one relation mixes facts with different determinants.
  • Dependencies are assertions about every legal state, not coincidences in sample data.
  • A determinant need not be a declared key.
  • Attribute closure tests whether a set determines all attributes.
  • A candidate key is a minimal superkey: every attribute in it must be necessary for reaching the full closure.
  • Armstrong's reflexivity, augmentation, and transitivity rules derive exactly the dependencies implied by a set.
  • A minimal cover simplifies normalization by using singleton right sides and removing extraneous attributes and redundant dependencies.

Closure and candidate keys for an order-line relation

Let R(order_id, line_no, customer_id, placed_at, product_id, sku, quantity, unit_price) obey F = {order_id → customer_id, placed_at; product_id → sku; sku → product_id; (order_id, line_no) → product_id, quantity, unit_price}. The last rule identifies a line within its order; the first two encode header and product facts.

Deriving `(order_id, line_no)+`
StepDependency appliedClosure after step
0Seed{order_id, line_no}
1order_id → customer_id, placed_atAdd customer_id, placed_at
2(order_id, line_no) → product_id, quantity, unit_priceAdd product_id, quantity, unit_price
3product_id → skuAdd sku; all attributes reached
Closure and minimality checks for `(order_id, line_no)`
Starting setWhat its closure missesConclusion
{order_id}line_no, product_id, sku, quantity, unit_priceline_no is necessary
{line_no}Header identity and all attributes outside the local line numberorder_id is necessary
{order_id, line_no}NothingCandidate key
{order_id, line_no, sku}Nothing, but sku is removableSuperkey, not candidate key