问题
So, I believe I have the understanding of Fully Functional Dependencies, and Partial Dependencies. I'll provide a brief explanation, in case I'm doing something wrong I don't end up too far down the rabbit hole.
I am working with a table that has a composite Primary Key composed of two attributes, with a total of 10 attributes in the table, in 1NF form.
In my situation, a fully functional dependency involves the dependent relying on BOTH attributes in my Primary Key. A partial dependency relies on either one of the attributes from the Primary key. A transitive dependency involves two or more non-key attributes in a functional dependence where one of the non-key attributes is dependent on a key attribute (from my PK).
Assuming that I'm not mistaken and regardless of my understanding, pulling the transitive dependencies out of the table is wracking my brain. It seems like you would do this AFTER normalization, but my assignment requires us to 'Identify all functional dependencies' before we draw the dependency diagram, after which we normalize the tables.
I will list the attributes in the table, and then the business rules provided - parenthesis identify the PK attributes:
(Student ID), Student Name, Student Address, Student Major, (Course ID), Course Title, Instructor ID, Instructor Name, Instructor Office, Student_crse_grade
Only one class is taught for each course ID.
Students may take up to 4 courses.
Each course may have a maximum of 25 students.
Each course is taught by only one Instructor.
Each student may have only one major.
回答1:
From your question it seems that you do not have a clear understanding of basics.
Application relationships & situations
First you have to take what you were told about your application (including a priori rules) and identify the application relationships (aka associations). Each gets a (base) table (aka relation) variable. Such an application relationship is characterized by a row membership criterion (aka predicate) (aka meaning). Eg suppose criterion "student [student_id] takes course [course_title]" has table variable TAKES. The parameters of the criterion are the columns of its table. We can use a table name with columns (like an SQL declaration) as a shorthand for the criterion. Eg TAKES(student_id,course_title). A criterion plus a row makes a statement (proposition) about a situation. Eg row (17,'CS101') gives "student 17 takes course 'CS101'" ie TAKES(17,'CS101'). Rows that give a true statement go in the table and rows that make a false one stay out.
If we can rephrase a criterion as the AND/conjunction of two others then we only need the tables with those other criteria. This is because JOIN is defined so that the JOIN of two tables containing the rows making their criteria true returns the rows that make the AND/conjunction of their criteria true. So we can JOIN the two tables to get back the original. (This is what normalization is doing by decomposing tables into components.)
-- student with id [si] has name [sn] and address [sa] and major [sm]
and takes course [ci] with title [ct]
from instructor with id [ii] and name [in] and office [io]
with grade [scg]
T(si,sn,sa,sm,ci,ct,ii,in,io,scg)
-- student with id [si] has name [sn] and address [sa] and major [sm]
and takes course [ci] with grade [scg]
SG(si,sn,sa,sm,ci,scg)
-- course [ci] with title [ct]
is taught by instructor with id [ii] and name [in] and office [io]
CI(ci,ct,ii,in,io,scg)
-- T(si,sn,sa,sm,ci,ct,ii,in,io,scg)
IFF SG(si,sn,sa,sm,ci,scg) AND CI(ci,ct,ii,in,io,scg)
T = SG JOIN CI
Together the application relationships and situations that can arise determine both the rules and constraints! They are just things that are true of every application situation or every database state (ie values of one or more base tables) (which are are a function of the criteria and the possible application situations.)
Then we normalize to reduce redundancy. Normalization replaces a table variable by others whose predicates AND/conjoin together to the original's when this is beneficial.
The only time a rule can tell you something that you don't know already know from the (putative) criteria and (putative) situations is when you don't really understand the criteria or what situations can turn up, and the a priori rules are clarifying something about that. A person giving you rules is already using application relationships that they assume you understand and they can only have determined that a rule holds by using them and all the application situations that can arise (albeit informally)!
(Sadly many presentations of information modeling don't even mention application relationships. Eg: If someone says "there is a X:Y relationship" then they must already have in mind a particular binary application relationship between entities; knowing it and what application situations can arise, they are reporting that it has a certain cardinality in a certain direction. This will correspond to some application relationship and table using column sets that identify entities. Plus some presenations/methods call FKs "relationships"--confusing them with those relationships.)
Check out Object-Role Modeling or (Nijssen's presentations of--not the wrong interpretations of--) his NIAM.
FDs & CKs
Given the criterion for putting rows into or leaving them out of a table and all possible situations that can arise, only some values (sets of rows) can ever be in a table variable.
For every subset of columns you need to decide which other columns can only have one value for a given subrow value for those columns. When it can only have one we say that the subset of columns functionally determines that column. We say that there is a FD (functional dependency) columns->column. This is when we can express the table's predicate as "... AND column=F(columns)" for some function F. But every superset of that subset will also functionally determine it, so that cuts down on cases. Conversely, if a given set does not determine a column then no subset of the set does. Also, you may think in terms of column sets being unique; then all other columns are functionally dependent on that set. Such a set is called a superkey.
Only after you have determined the FDs can you determine the CKs (candidate keys)! A CK is a superkey that contains no smaller superkey. (That a CK and/or superkey is present is also a constraint.) We can pick a CK as PK (primary key). PKs have no other role in relational theory.
A partial dependency relies on either one of the attributes from the Primary key.
Don't use "involve" or "relies on" to give a definition. Say, "when" or "iff" ("if and only if").
Read a definition. A FD that holds is partial when/iff using a proper subset of the determinant gives a FD that holds with the same determined column; otherwise it is full. Note that this does not involve CKs. A relation is in 2NF when all non-prime attributes are fully functionally dependent on every CK.
A transitive dependency involves two or more non-key attributes in a functional dependence where one of the non-key attributes is dependent on a key attribute (from my PK).
Read a definition. S -> T is transitive when/iff there is an X where S -> X and X -> T and not(X -> S) and not(X = T). Note that this does not involve CKs. A relation is in 3NF when all non-prime attributes are non-transitively dependent on every CK.
"1NF" has no single meaning.
回答2:
I am inferring a functional dependency that was not listed in your business rules. Namely that instructor ID determines instructor name.
If this is true, and if you have both instructor ID and instructor name in the Course table, then this is not in 3NF, because there is a transitive dependency between Course ID, Instructor ID, and Instructor Name.
Why is this harmful? Because duplicating the instructor name in each course an instructor teaches makes updating an instructor name difficult, and possible to do in an inconsistent manner. Inconsistent instructor name is just another bug you have to watch out for, and 3NF obviates the problem. The same argument could be made for Instructor office.
来源：https://stackoverflow.com/questions/27393366/identifying-transitive-dependencies