Question
Does a Primary Key functionally determine every other attribute in the table?
My thought
Surely it has to doesn't it? Isn't that the point of primary keys?
Question
Does a Primary Key functionally determine every other attribute in the table?
My thought
Surely it has to doesn't it? Isn't that the point of primary keys?
In a table that is at least in 1st normal form, the primary key determines every attribute in the table. As you say, that is the point of primary keys (and candidate keys in general).
There is by definition a functional dependency between all superkeys (not just the primary key) of a relation and all attributes in that relation (not just non-key attributes).
A table's superkeys (UNIQUE NOT NULL sets of columns) are the column sets that "functionally determine every other attribute in the table". A table's candidate keys (superkeys containing no smaller superkeys) are important to normalization. A primary key is just a distinguished candidate key.
Why distinguish one?
Primary keys play no role in relational theory. The main practical role is for consistency in identifying rows/entities/associations by foreign keys in other tables.
Codd (contrary to theory) allowed NULL in candidate key columns. (As does SQL.) From his "Understanding Relations" articles:
A basic integrity principle associated with candidate keys is that, for every base relation, at least one of the candidate keys is prohibited from taking on null values.
Normally, it will not be necessary to prohibit null values in more than one candidate key -- hence, the common practice of designating precisely one such key as the primary key: i.e., the only candidate key for which null values are prohibited.
(DBMSs, CASE tools and ORMs often use primary keys for defaults associated with candidate keys, often physical/implementation ones. But this begs the question.)
So superkeys play the identification role, candidate keys are the special superkeys, and primary keys aren't particularly special candidate keys.