Must the determinant be a primary key?

No. Full dependency is a property of a functional dependency, although composite-key analysis is a common use.

Does “determines” mean one value causes another?

No. It means the same determinant values cannot legally correspond to different dependent values.

Can a sample prove a full dependency?

A sample can reveal violations, but the intended rule must apply to all legal data states, including cases not yet observed.

AI Glossary / Data engineering and architecture / Intermediate

Full functional dependency

Definition

A full functional dependency holds when a set of attributes determines another attribute or set of attributes, and no proper subset of that determining set is sufficient. If X determines Y, written X → Y, the dependency is full when every attribute in X is needed for that determination. The concept is especially useful when examining composite keys and distinguishing full dependence from partial dependence.

What it means

A course title may depend on CourseID alone, while a learner's grade for a course may depend on both LearnerID and CourseID, under a rule allowing one grade per learner-course pair. Storing those facts together does not make their dependencies identical. Full dependency asks whether the entire determinant is necessary, rather than whether the attribute merely appears in a table with a composite key.

How it works

Start with the business rules defining legal data states. Establish that equal X values require equal Y values. Then test whether removing any part of X would still determine Y. If a smaller determinant works, the dependency is partial with respect to X rather than full. A sample can disprove a proposed dependency by showing a counterexample, but a small sample cannot establish that the dependency must hold in every legal state. Normalization uses these semantic rules, not accidental uniqueness in today's data.

Three practical examples

Enrollment design: a final grade can depend on the learner-course pair, while the course title depends only on the course.
Order processing: a line quantity may depend on an order and line number together, while the order date depends on the order alone.
AI dataset organization: an annotation result may depend on document version, reviewer, and task, whereas the reviewer's display name depends on the reviewer identifier.

Think of it this way

Think of a locker that requires two distinct parts of a combination. Both parts are necessary to identify the intended locker. The analogy is limited because functional dependency is about a rule over data, not a security mechanism. A determinant can contain more than two attributes, and “determines” means uniqueness of the associated value, not causation or the ability to calculate it from a formula.

Worked example

Assume each learner receives one final grade per course. The toy records are (L1,C1,80), (L1,C2,90), and (L2,C1,70). LearnerID alone does not determine Grade because L1 has both 80 and 90. CourseID alone does not determine Grade because C1 has both 80 and 70. Under the stated uniqueness rule, (LearnerID,CourseID) determines Grade, and neither component alone does, so the dependency is full. Now add CourseTitle, with C1 always called “Data Basics” and C2 “AI Practice.” CourseTitle depends on CourseID alone, making its dependency on the pair partial. If repeat attempts are allowed, the assumed pair may no longer determine Grade; an AttemptID or equivalent rule is required. The dependency changes when the underlying business rule changes.

Illustrative case study

Fictional example: Pine Academy combines learner details, course details, and grades in one table. A review identifies names and titles that depend on only one part of the enrollment key. The team separates learner and course facts from enrollment facts and checks that the joins reproduce the intended information. It also clarifies how repeat attempts are identified. This invented case illustrates dependency analysis; it does not claim that adding tables is always beneficial or that a particular sample proves the full set of business dependencies.

Common misconceptions and mistakes

Do not equate functional dependency with statistical correlation or causation. Do not assume an attribute fully depends on a key simply because a primary-key constraint exists. Avoid checking only one selected primary key when formal normalization requires considering relevant candidate keys and non-prime attributes. Also distinguish full dependency from transitive dependency: these describe different structural issues. A table can avoid partial dependencies and still have other forms of redundancy that require further analysis.

Business use

Understanding full dependencies helps teams store facts at the right level and avoid repeated updates. Identify the meaning of one row, list candidate keys, and classify which attributes depend on which determinants. Confirm these rules with domain owners and test edge cases, including repeated events and time-dependent values. In AI pipelines, dependencies help define stable joins and prevent mixing facts at incompatible grains. They do not replace checks for label accuracy, information leakage, or changing real-world relationships.

Check your understanding

In OrderLine(OrderID,LineNo,OrderDate,Quantity), OrderDate is determined by OrderID alone. Is its dependency on (OrderID,LineNo) full?

Answer: No. LineNo is unnecessary for determining OrderDate, so the dependency on the pair is partial. Quantity may have a full dependency on the pair if the business rules make both components necessary.

Related terms

Learn next

write a small relation with a two-part candidate key and at least two non-key attributes. State the business dependencies before examining the rows. Remove each key component in turn and determine which attributes remain determined, then propose a decomposition for any partial dependencies.

Candidate key

Sources

Sources: Broadcom CA 2E Data Modeling, 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. Examples and the distinction between business rules and observed samples are original explanatory synthesis. 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: Frontier Next: Full joint probability distribution