What does it mean when we say that one attribute of a relation is functionally dependent on a second attribute of that relation?

A. A Functional Dependency describes a relationship between attributes in a single relation.
B. An attribute B is functionally dependent on attribute A if a value of attribute A specifically determines one value of attribute B.
1. Example: Employee_Name is functionally dependent on Social_Security_Number because Social_Security_Number can be used to determine the value of Employee_Name.
C. We use the symbol -> to indicate a functional dependency.
-> is read functionally determines
1. Examples:
Student_ID Student_Major
Student_ID, Course#, Semester# Grade
SKU Compact_Disk_Title, Artist
Model, Options Car_Price
Course_Number, Section Professor, Classroom, Number of Students

D. The attributes listed on the left hand side of the -> are called determinants.
1. One can read A -> B as:
a) "A determines B" or
b) "B is functionally dependent on A"

E. A key functionally determines a tuple (row)
1. i.e., a key is a determinant for a tuple;
a) We'll learn more about keys on the next page;
2. Be careful note 1: Not all determinants are keys—for example, composite keys contain more than one determinant; any one of them cannot uniquely identify the tuple.
3. Be careful note 2: don't confuse computational tasks with functional dependencies. For example, even if this is true:
Sales * sales_tax_rate = sales_tax_amount
we won't create the functional dependency:
Sales, sales_tax_rate sales_tax_amount
because we don't need to look up the sales_tax_amount in a relation, we can just compute it.

A. A relation is in second normal form (2NF) if:
1. It is already in First Normal Form
2. all of its non-key attributes are dependent on all of the key, i.e., there are no partial dependencies
B. Relations that have a single attribute for a key are automatically in 2NF!!!
1. If there is only one attribute in the key, then there can be no partial dependencies;
2. This is one reason why we often use artificial identifiers as keys
C. Steps to normalize to 2NF
1. create a new relation with the attributes (both determinants and dependents) from the partial dependency)
a) remove any duplicate tuples from this new relation;
2. modify the original relation by removing the dependent attributes from the partial dependency;
a) keep the determinant in the modified relation;
D. In the previous 1NF relation, we have the following dependencies on the determinants, SSN and CrsCode:
SSN, CrsCode Grade
SSN Lname, Major, Advisor
CrsCode Course#, CrsName, Credits, Section, Faculty, FacDept

1. If we say the SSN, CrsCode is the key of this relation, it is obvious that there are attributes that are dependent only on SSN, or only on CrsCode, and so the previous relation is NOT in 2NF. So we break it up by making a relation for each determinant above. In these relations each non-key field is dependent on the entire key of that relation (see next page).
E. The algorithm to convert to 2nf:
CREATE the new relation and give it an appropriate name
COPY the determinant of the partial dependency into the new relation, and make it the primary key of that relation;
CUT the dependent fields of the partial dependency out of the old relation, and paste them into the new relation;
Eliminate the redundant tuples in the new relation;

A. A relation is in BCNF if
1. It is already in third normal form (3 NF)
2. Every determinant is a candidate key.
B. Consider relation R containing attributes A, B and C where
. A B and B C
. A is the primary key of R, and contains as least two fields, say C and D;
. B is a non-key field in R but a determinant of C;
. C is a subset of the primary key A;
. This creates a looping dependency, because we will have:
. C, D B and B C
. Thus, relation R is in 3rd normal form, because there are no transitive dependencies, but we still have a determinant that is not a key (That is, B).

C. Recall that not all determinants are keys.
1. Those determinants that are keys we initially call candidate keys.
2. Eventually, we select a single candidate key (which may have more than one attribute) to be the primary key for the relation.

Sets with similar terms

"S (functionally) determines T" means that all appearances of a particular subtuple value for attribute set S have the same subtuple value for attribute set T. If we say an attribute X is determining or determined then it's understood that we really mean that set {X} is determining/determined.

A superkey is a set of attributes that determines every attribute. A CK (candidate key) is a superkey that contains no smaller superkey. There can be many CKs. One CK can be chosen as PK (primary key). (PKs play no role in relational theory.)

Since there can only be one PK, it's odd that you talk about a relation value or variable having more than one. Maybe you mean two CKs. Maybe you mean a 2-attribute PK.

It happens that if every subtuple value for a set of attributes appears just once then it is a superkey. (Each single-attribute superkey is a CK unless {} is the CK, which happens when the relation is limited to one tuple.) So it determines all attributes. But in general the dependencies tell us what the superkeys & CKs are.

So if each of A and B are CKs then each determines C and D, ie {C} and {D}. And if {A,B} is a PK then it determines C and D, ie {C} and {D}. It happens that if both T1 and T2 are determined by S then T1 U T2 is too. So either way, the CK(s) here determine(s) {C,D} also.

PS There is an ambiguity in English where it is not clear whether "both C and D are functionally dependent" means that C is dependent and D is dependent or that {C,D} is dependent. Similarly for "are functionally dependent on both A and B". So it is clearer to say "the set ..." rather than just using "both" and/or "and".

What does it mean to say that one attribute of a table is functionally dependent on another?

What is the meaning of functionally dependent?

What does it mean for a column to be functionally dependent on another column?

What are the functional dependencies in the relation?