A table has composite primary key (StudentID, CourseID) and includes the attribute InstructorEmail, which depends only on CourseID. This violates which normal form?
AFirst Normal Form — because InstructorEmail may contain non-atomic values
BSecond Normal Form — because InstructorEmail has a partial dependency on the key
CThird Normal Form — because InstructorEmail depends on a non-key attribute
DNo normal form is violated — a non-key attribute may depend on any part of the key
InstructorEmail depends only on CourseID, not on the full composite key (StudentID, CourseID). This is a partial dependency — the defining violation of 2NF. The fix is to move InstructorEmail to a separate Courses table where CourseID is the sole primary key, so each instructor's email is stored once. If left in the enrollment table, updating an instructor's email requires updating every row for that course — a classic update anomaly.
Question 2 Multiple Choice
In a flat enrollment table, a student's only course enrollment is deleted to record a withdrawal. As a side effect, the student's name and contact information are also lost. This is an example of:
AAn update anomaly — the same data exists in multiple places and only one copy was updated
BAn insertion anomaly — new data cannot be inserted without providing unrelated information
CA deletion anomaly — deleting one fact unintentionally destroys another unrelated fact
DA 1NF violation — the row contained multiple values in a single column
A deletion anomaly occurs when removing one logical fact (the enrollment) inadvertently destroys another (the student's identity information), because both facts are entangled in the same row. This is a direct consequence of redundant storage — the student's name is only recorded via their enrollments, not in a dedicated Students table. Normalization to 2NF resolves this by separating student data from enrollment data so each fact lives in exactly one place.
Question 3 True / False
A table with a single-column primary key can still violate Second Normal Form if non-key attributes depend on primarily part of that key.
TTrue
FFalse
Answer: False
Partial dependencies — the 2NF violation — can only exist when the primary key is composite (two or more columns). A partial dependency means a non-key attribute depends on a proper subset of the key. With a single-column key, there are no proper subsets, so partial dependencies are structurally impossible. Tables with single-column primary keys are automatically in 2NF, though they can still violate 3NF if a non-key attribute depends on another non-key attribute.
Question 4 True / False
Storing a student's enrolled courses as 'CS101, CS202, CS303' in a single column violates First Normal Form.
TTrue
FFalse
Answer: True
1NF requires each cell to contain exactly one atomic, indivisible value. A comma-separated list in a single column stores multiple values as a single string, violating atomicity. This makes the data very difficult to work with: you cannot JOIN on individual courses, cannot set foreign key constraints on individual values, and queries require string-splitting logic. The fix is to create one row per student-course combination, where each cell holds a single CourseID.
Question 5 Short Answer
What is a partial dependency, and why does it cause update anomalies in a database table?
Think about your answer, then reveal below.
Model answer: A partial dependency occurs when a non-key attribute depends on only part of a composite primary key rather than the entire key. For example, if CourseName depends only on CourseID in a table with key (StudentID, CourseID), CourseName is stored redundantly in every row for that course. An update anomaly results: if the course name changes, every row containing that CourseID must be updated individually. If even one row is missed, the database contains conflicting values for the same fact — an inconsistency that normalization is designed to prevent.
The deeper issue is that partial dependencies encode two independent facts in one row: facts about the enrollment relationship AND facts about the course itself. 2NF separates these by decomposing the table so each fact lives in exactly one place. This 'one fact, one place' principle is why normalization eliminates anomalies: there is no longer a second copy to forget to update, no enrollment row to delete that takes course information with it.