Assume a one-to-many relationship from table named "authors" to the table named "books". Where should the foreign key reside in an optimal design for this relationship?
In the "books" table
In the "authors" table
In both the tables
In a separate linking table
ANSWER
The foreign key should be placed in the "books" table, which is the many side of the relationship.
Official answer: ASource: ISRO's final answer key of 15 May 2026
One author can write many books, so "authors" is the "one" side and "books" is the "many" side of the relationship.
A foreign key is a column that holds a single, atomic value referring to the primary key of another table. In first normal form a cell cannot hold a list of values.
Each book belongs to exactly one author, so every row of "books" can store one author_id that references the primary key of "authors".
Putting the key in "authors" would need several book ids in one author row. That is a repeating group, which breaks 1NF. The alternative is to repeat the author row once per book, which causes redundancy and update anomalies.
Putting a foreign key in both tables stores the same relationship twice. The two copies can disagree, and the two tables then depend on each other circularly, so the design is not optimal.
A separate linking (junction) table is needed only for a many-to-many relationship. For one-to-many it adds an extra table and an extra join without any benefit.
So the foreign key goes on the many side, in the "books" table.
KEY IDEA
In a one-to-many relationship, the foreign key sits on the "many" side and points to the primary key of the "one" side.
WATCH OUT FOR
Putting the key on the "one" side, or adding a linking table. A linking table belongs only to many-to-many relationships, and a key on the "one" side would need a list of values in one cell.
From the ISRO CS 2025 paper. Every question of this paper · The full paper (PDF, ISRO) · All 3 ISRO Normal forms questions, with notes
