Junction Table (Bridge Table) in Database Design
Fast recall
Quick revision
Core answer
Understanding of how to implement many-to-many relationships in relational databases
Thinking a many-to-many relationship can be stored with just a foreign key in one table or as a comma-separated list
Explain that the junction table can store relationship-specific attributes and show a real Spring Boot entity mapping with at-ManyToMany
Interview-ready guide
Interview answer
A junction table is how you implement a many-to-many relationship in a relational database.
You can't store M:N directly because foreign keys only support one-to-many. So you create a bridge table that sits between the two entities. It contains foreign keys to both sides, turning one M:N into two 1:N relationships.
For example, students and courses. A student can take many courses and a course has many students. You'd create an enrollments table with student_id and course_id as foreign keys.
The primary key would be the combination of both columns—that's called a composite key—and it prevents a student from being enrolled in the same course twice. The cool thing about junction tables is you can also store attributes about the relationship itself. Like in enrollments, you might add an enrolled_date or a grade column.
Those don't belong to the student or the course—they belong to the act of enrolling. In Spring Boot with JPA, you can use the at-ManyToMany annotation and Hibernate will create the junction table automatically. But if you need those relationship attributes, you should create an explicit entity class for the junction table, like an Enrollment class with at-ManyToOne relationships to both Student and Course.
That gives you full control.
Junction Table (Bridge Table) in Database Design
Direct Answer
A junction table (bridge table) represents a many-to-many relationship as two one-to-many relationships. It contains foreign keys that reference keys in the related tables and may contain relationship attributes. The foreign-key pair must normally be unique; this can be the composite primary key or a UNIQUE constraint beside a surrogate key.
Code Example
-- Two entities with M:N relationship
CREATE TABLE author (
author_id BIGSERIAL PRIMARY KEY,
name VARCHAR(100) NOT NULL
);
CREATE TABLE book (
book_id BIGSERIAL PRIMARY KEY,
title VARCHAR(200) NOT NULL,
isbn VARCHAR(13) UNIQUE
);
-- Junction table: author_book
CREATE TABLE author_book (
author_id BIGINT NOT NULL,
book_id BIGINT NOT NULL,
contribution_role VARCHAR(50) DEFAULT 'author', -- Relationship attribute
royalty_percentage DECIMAL(5,2), -- Another relationship attribute
PRIMARY KEY (author_id, book_id), -- Composite PK prevents duplicates
CONSTRAINT fk_author FOREIGN KEY (author_id) REFERENCES author(author_id) ON DELETE CASCADE,
CONSTRAINT fk_book FOREIGN KEY (book_id) REFERENCES book(book_id) ON DELETE CASCADE
);
-- Query: Find all books by an author
SELECT b.title, ab.contribution_role
FROM book b
JOIN author_book ab ON b.book_id = ab.book_id
WHERE ab.author_id = 42;
Common Mistakes & Pitfalls
- Storing M:N as comma-separated values: A course_ids string cannot enforce a foreign key for each item and makes relational queries harder.
- Forgetting pair uniqueness: Use a composite primary key or a UNIQUE constraint on the two foreign keys when duplicate links are not valid.
- Choosing CASCADE by habit:
ON DELETE CASCADE,RESTRICT, or another action should match the lifecycle rule; a valid foreign key does not leave dangling references.
Check your understanding
Answer these without looking back at the article.
- How do you map a junction table in JPA with @ManyToMany?
- Can a junction table have its own primary key?
- What is the difference between @ManyToMany and two @OneToMany relationships?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.