Which normal form specifically addresses removing partial dependencies of non-key attributes on a candidate key?

Prepare for the 241 Computer Science Certification Exam with comprehensive flashcards and multiple choice questions. Enhance knowledge with explanations and hints to excel in your test journey!

Multiple Choice

Which normal form specifically addresses removing partial dependencies of non-key attributes on a candidate key?

Explanation:
When a table’s primary key is made of more than one attribute, a partial dependency can occur when a non-key attribute depends on just part of that composite key. Second Normal Form specifically targets and eliminates these partial dependencies. It requires that every non-prime (non-key) attribute be fully functionally dependent on the entire candidate key, meaning it should rely on all parts of the composite key, not just a portion of it. In practice, if you find a non-key attribute that depends only on one part of a composite key, you decompose the table so that that attribute’s dependency is resolved by separating it into its own relation. For example, if CourseName depends only on CourseID (a part of the key (StudentID, CourseID)), you’d split CourseName into a separate Course relation and keep Enrollment with the combined key and the remaining attributes. The other normal forms address different issues: 1NF is about having atomic attribute values, 3NF handles transitive dependencies (non-key attributes depending on other non-key attributes), and BCNF tightens rules on determinants even further.

When a table’s primary key is made of more than one attribute, a partial dependency can occur when a non-key attribute depends on just part of that composite key. Second Normal Form specifically targets and eliminates these partial dependencies. It requires that every non-prime (non-key) attribute be fully functionally dependent on the entire candidate key, meaning it should rely on all parts of the composite key, not just a portion of it.

In practice, if you find a non-key attribute that depends only on one part of a composite key, you decompose the table so that that attribute’s dependency is resolved by separating it into its own relation. For example, if CourseName depends only on CourseID (a part of the key (StudentID, CourseID)), you’d split CourseName into a separate Course relation and keep Enrollment with the combined key and the remaining attributes.

The other normal forms address different issues: 1NF is about having atomic attribute values, 3NF handles transitive dependencies (non-key attributes depending on other non-key attributes), and BCNF tightens rules on determinants even further.

Subscribe

Get the latest from Passetra

You can unsubscribe at any time. Read our privacy policy