 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / General 1 / October 2003Transitive dependencies
Hi there, I'm having some trouble identifying transitive dependencies in the student table below StudId Name CourseCode CourseDesc Lecturer Grade Office 'S1234', 'Jack', 'C224', 'Database', 'Codd', 'D', 381 'S1234', 'Jack', 'C225', 'Algorithms', 'Djikstra', 'P', 380 'S2345', 'Jill', 'C224', 'Database', 'Codd', 'HD', 381 'S2345', 'Jill', 'C226', 'Architecture', 'Ritchie', 'HD', 390 'S4567', 'Jack', 'C226', 'Architecture', 'Ritchie', 'D', 390 'S4567', 'Jack', 'C224', 'Database', 'Codd', 'F', 381 'S9872', 'Howard', 'Cpol', 'Politics', 'Marx', 'F', 380 I've first tried to find the functional dependencies (they may or may not be correct) * StudId -> Name * StudId, CourseCode -> Name, CourseDesc, Lecturer, Grade, Office * CourseCode -> CourseDesc, Lecturer, Office * CourseDesc -> CourseCode, Lecturer, Office * Lecturer -> CourseCode, CourseDesc, Office I then thought that StudId, CourseCode -> Office, CourseDesc, Lecturer might be a transitive dependency within student. Is it? Before identifying transitive dependencies, you need to clearly identify the primary key. The primary key is an attribute (or attributes!) that uniquely identifies every record in the relation. Once you've done that, the transitive dependency should be apparent. Hint: Dr. Codd might well teach more that one Database course, but he will only have one office. > Hi there, > [quoted text clipped - 21 lines] > I then thought that StudId, CourseCode -> Office, CourseDesc, Lecturer > might be a transitive dependency within student. Is it? > Before identifying transitive dependencies, you need to clearly identify the > primary key. The primary key is an attribute (or attributes!) that uniquely > identifies every record in the relation. Once you've done that, the > transitive dependency should be apparent. Hint: Dr. Codd might well teach > more that one Database course, but he will only have one office. Well, StudId, CourseCode uniquely identifies every row - I think this is probably the primary key. I should have explained myself better: the reason I thought that StudId, CourseCode -> Office, CourseDesc, Lecturer was a transitive dependency was because CourseCode and Lecturer both depend on CourseDesc, and CourseDesc in turn depends on StudId, CourseCode. Similarly, Office depends on Lecturer and Lecturer depends on StudId, CourseCode. Have I understood the concepts correctly? I'd like to put the student table in *both* 2NF and 3NF. A transitive dependency is a situation where an attribute depends on another attribute that is not part of the primary key. So, if (StudID, CourseCode) is the PK, examine each of the other attributes to see if any are dependant on an attribute that is not part of the PK. > > Before identifying transitive dependencies, you need to clearly identify > the [quoted text clipped - 16 lines] > Have I understood the concepts correctly? I'd like to put the student table > in *both* 2NF and 3NF. > > Before identifying transitive dependencies, you need to clearly identify > the [quoted text clipped - 16 lines] > Have I understood the concepts correctly? I'd like to put the student table > in *both* 2NF and 3NF. You're confusing a partial dependency for a transitive dependency. A partial dependency is when an attribute is functionally dependent on only part of the primary key. In your base relation CourseDesc is only dependent on CourseID, Lecturer is only dependent on CourseID and Name is only dependent on StuID. All are partial dependencies. Office is dependent on Lecturer, Lecturer is dependent on CourseID, so Office is transitively dependent on CourseID. > You're confusing a partial dependency for a transitive dependency. > A partial dependency is when an attribute is functionally dependent on only [quoted text clipped - 6 lines] > Office is dependent on Lecturer, Lecturer is dependent on CourseID, so > Office is transitively dependent on CourseID. But isn't CourseID (CourseCode) functionally dependent on Lecturer? The definition that I'm looking at says that: If A -> B and B->C then C is transitively dependent on A via B *provided that* A is not functionally dependent on B or C. In the example you gave, A (CourseID) is *not* dependent on C (Office) but A *is* dependent on B (Lecturer) - for each value of Lecturer there's exactly one value of CourseID. > > You're confusing a partial dependency for a transitive dependency. > > A partial dependency is when an attribute is functionally dependent on [quoted text clipped - 17 lines] > *is* dependent on B (Lecturer) - for each value of Lecturer there's exactly > one value of CourseID. You're a step behind worrying about transitive dependencies. Get your relation into 2NF and take another look. > > You're confusing a partial dependency for a transitive dependency. > > A partial dependency is when an attribute is functionally dependent on [quoted text clipped - 17 lines] > *is* dependent on B (Lecturer) - for each value of Lecturer there's exactly > one value of CourseID. The example rkc gave you was perfect. A(CourseID) -> B(Lecturer) and B(Lecturer) -> C(Office) C is dependent on B and B is dependent on A So C is transitively dependent on A Also, as rkc stated, as did I in my first post, the transitive dependency has no significance until the relation is in 2NF. Do that by defining the primary key. THEN examine the transitive dependencies. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2010 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.