At 9:34 in this video the speaker says that all 3 functional dependencies are in Boyce Codd Normal Form. I don’t believe it because clearly GPA can’t determine the SSN, sName, address and all other attributes in the student table. Either I’m confused about the definition of Boyce Codd Normal Form or what a super key is? Does it only have to be able to uniquly identify certain attributes, not all attributes in the schema? For example GPA does determine priority (which is on the right side of the functional dependency) but not everything else.
For example if I had the relation R(A,B,C,D) and the FDs A->B would we say A is a superkey for B but I thought a super key is for the whole table? To add to my confusion I know for BCNF it can be a (primary) key but you can only have on primary key for the table. Ugh my brain hurts.
“… the speaker says that all 3 functional dependencies are in Boyce Codd Normal Form.”
To be in BC normal form is a property that can be had by RELATIONS (relation variables, more specifically, or relation schemas, if that term suits you better), not by functional dependencies. If you find someone talking so sloppily of normalization theory, leave and move onto more accurate explanations.
Whether or not a relation variable is indeed in BC normal form, depends on which functional dependencies are supposed to hold in it. That is why it is utter nonsense to say that functional dependencies are or are not in BC normal form.
“I don’t believe it because clearly GPA can’t determine the SSN, sName, address and all other attributes in the student table. Either I’m confused about the definition of Boyce Codd Normal Form or what a super key is? Does it only have to be able to uniquly identify certain attributes, not all attributes in the schema?”
An irreducible candidate key is that set (not necessarily unique) of attributes of the relation schema that is guaranteed to have unique combinations of attribute values in whatever relation values could validly appear in the relation variable in the database.
In your (A,B,C,D) example, if A->B is the only FD that holds, then the only candidate key is {A,C,D}.
“For example if I had the relation R(A,B,C,D) and the FDs A->B would we say A is a superkey for B”
It is sloppy and confusing to talk of A as being the “key” for B in such a case. People who pretend to be teaching others ought to know this, and people who don’t, ought not engage in any teaching until they do know this. It would be better to talk of A as the “determinant” for B in such contexts. The term “key” in the context of relational database design has a very well-defined and precise meaning, and using the same term for other meanings merely confuses people. As evidenced by your question.
“but I thought a super key is for the whole table?”
Yes you thought right.
Back to your (A,B,C,D) example. If we were to split that design into (A,B) and (A,C,D), then we would have a relation schema -the (A,B) one- of which we can say that “{A} is a key” in that schema.
That is actually precisely what the FD A->B means : if you take the projection -of the relation value that would appear in the database in the (A,B,C,D) schema- over the attributes {A,B}, then you should be getting a relation in which no A value appears twice (if it did, then that A value would correspond to >1 distinct B value, meaning that A could not possibly be a determinant for B after all).
“To add to my confusion I know for BCNF it can be a (primary) key but …”
Now you are being sloppy yourself. What does “it” refer to ?