Does partial mean the dependency holds for only some rows?

No. It means a smaller part of the determinant is sufficient under the stated rule.

Is every dependency on part of a composite key a 2NF violation?

The formal 2NF condition concerns non-prime attributes and candidate keys; the attribute's role matters.

Can a single-column chosen primary key hide design problems?

Yes. Other candidate keys and semantic dependencies can still matter, so a surrogate key is not a substitute for analysis.

AI Glossary / Data engineering and architecture / Intermediate

Partial Dependency

Definition

A partial dependency is a functional dependency in which an attribute depends on a proper subset of a larger determinant, commonly part of a composite candidate key. For example, a course title depends on CourseID even when an enrollment row is identified by LearnerID and CourseID together. Partial dependencies involving non-prime attributes are central to understanding second normal form.

What it means

A table can combine facts at different levels. An enrollment date may describe a particular learner-course relationship, while the course title describes the course alone. Repeating the title in every enrollment row makes a course fact depend operationally on many relationship records. The phrase partial dependency identifies that mismatch relative to the composite key; it does not mean the relationship is uncertain or only sometimes true.

How it works

List the candidate keys and functional dependencies that follow from the business rules. For each relevant non-prime attribute, ask whether a proper subset of a candidate key determines it. If so, the attribute is partially dependent on that key. A conventional remedy places the subset-dependent fact in a relation keyed by that subset and preserves the original relationship through a reference. Check that the decomposition is appropriate and lossless. Do not infer dependencies solely from accidental patterns in a small dataset.

Three practical examples

Education: CourseTitle is separated from enrollment records because it depends on CourseID, not on the full learner-course pair.
Ordering: OrderDate belongs with the order rather than being maintained independently in every order-line record.
AI evaluation: a model-run description belongs with RunID rather than being redundantly maintained in every run-example measurement row.

Think of it this way

Think of a label on every seat reservation that repeats the theater's address. The reservation identifies a person and a performance, but the address is a fact about the theater. The analogy is limited because a real address can vary by venue or time, so the actual determinant must be established carefully. A plausible story is not a substitute for a precise dependency in the data model.

Worked example

Assume OrderLine is identified by (OrderID,LineNo), and each order has one OrderDate. The toy rows (O1,1,10 June,Quantity 2) and (O1,2,10 June,Quantity 5) repeat the date. OrderID alone determines OrderDate, so its dependency on (OrderID,LineNo) is partial. Quantity may require the full pair because different lines can have different quantities and line numbers repeat across orders. A decomposition into Order(OrderID,OrderDate) and OrderLine(OrderID,LineNo,Quantity) stores the date once. Updating O1's date then changes one order fact. If the field instead means an independently scheduled delivery date for each line, the dependency may be different. The diagnosis must follow the field's actual meaning rather than its convenient name.

Illustrative case study

Fictional example: Rowan Assessments stores an evaluation run's model label beside every example score. Some labels are corrected while others remain stale. The team confirms that the label describes the run, separates it into a run table, and retains scores at their own grain. It also documents which labels are historical snapshots and which are current descriptions. This invented case illustrates dependency analysis and temporal care; it does not claim that all repeated labels should always be removed from analytical exports.

Common misconceptions and mistakes

Do not confuse partial dependency with a partially populated field, a weak statistical association, or a foreign key. Do not analyze only the chosen primary key if other candidate keys matter to the formal normal-form test. Avoid claiming that adding a surrogate identifier automatically removes the underlying dependencies. It may change the declared key but leave repeated facts and candidate-key relationships intact. Also distinguish partial dependencies from transitive dependencies, which involve a different route of determination.

Business use

Recognizing partial dependencies helps prevent inconsistent updates and makes independent entity lifecycles easier to represent. Define the grain and candidate keys before restructuring tables. Confirm the meaning of repeated attributes, especially time-sensitive descriptions. For AI systems, keep run-level metadata separate from example-level measurements where that matches the underlying facts, then create deliberate joined exports when needed. Document whether those exports are snapshots or maintained current views so repeated values remain interpretable rather than becoming uncontrolled copies.

Check your understanding

In Enrollment(LearnerID,CourseID,CourseTitle,Grade), CourseID determines CourseTitle. Is CourseTitle fully dependent on the learner-course pair?

Answer: No. LearnerID is unnecessary to determine it, so the dependency on that pair is partial. Grade may depend on the full pair under a one-grade-per-enrollment rule.

Related terms

Learn next

identify a composite candidate key in a small relation and classify each non-key attribute by its smallest justified determinant. Propose a decomposition for a partial dependency and test whether the original facts can be reconstructed without losing or inventing relationships.

Candidate key

Sources

Sources: Broadcom CA 2E, Full Functional Dependence, https://ftpdocs.broadcom.com/cadocs/0/CA%202E%20Release%208%206%2000-ENU/Bookshelf_Files/HTML/CA2E_DataModel_ENU/1527316.html ; Ontario Tech University, Functional Dependencies, https://csci3030u.science.ontariotechu.ca/chapter_3/chapter_3_section_1.html ; BCcampus, Normalization, https://opentextbc.ca/dbdesign01/chapter/chapter-12-normalization/ . Primary vendor and institutional teaching excerpts consulted. The order-line and evaluation examples are original; candidate-key and non-prime qualifications are retained for accurate 2NF context. Editorial source note: the Ontario Tech teaching page is secondary and model-attributed; it is not counted as primary verification. Other sources listed above provide the independent cross-checks.

Previous: Partial correlation Next: Partial derivative