An ERD for a training system shows crow's-foot symbols at both ends of the line between Student and Course: a student can enroll in many courses, and a course can have many students. How should this relationship be implemented in a relational database?
Select an answer to reveal the explanation.
Short Explanation
A many-to-many is a dance where everybody can partner with everybody, so you need a dance card to track the pairs. That card is the junction table, one row per student-course pair. Stick one foreign key on either side and you've limited everybody to a single partner.
Full Explanation
In crow's-foot notation, the crow's foot at an end of a relationship line means many, so crow's feet at both ends describe a many-to-many relationship. Relational tables cannot represent this directly with a single foreign key, because a foreign key column in one row can point to only one parent row. The standard implementation is a junction, or associative, table, such as Enrollment, containing a foreign key to Student and a foreign key to Course, usually with a composite primary key or unique constraint on the pair, and often attributes of the relationship such as enrollment date or grade. A single course ID column in the student table lets each student enroll in only one course, turning the design into many-to-one. A single student ID column in the course table similarly limits each course to one student. Combining both entities into one wide table creates massive redundancy and update anomalies, repeating student and course details for every pairing and violating normalization. Exam caveat: the junction table turns one many-to-many relationship into two one-to-many relationships, which is how it appears in the physical design. Operational check: create the Enrollment table with both foreign keys and a unique constraint on the pair, then confirm a duplicate enrollment insert is rejected.