A relational database cannot store a many-to-many relationship directly - it needs a junction table (also called a join or link table) in the middle. Schemity does the fiddly parts for you, so an auto junction table is mostly automatic even though you place it deliberately.

The problem it solves

Say students and courses have a many-to-many relationship. You cannot put a foreign key on either side alone. You need a student_courses entity holding student_id and course_id, with both forming a composite primary key.

How to create one

  1. Add a new entity to sit between the two parents, and leave it without fields.
  2. Draw a relationship from the first parent to this entity, and another from the second parent to it.

As you draw those two relationships, Schemity:

  • adds a foreign key field to the junction entity for each parent,
  • makes the two foreign keys a composite primary key, so each pairing is unique, and
  • detects the entity as a junction table (when all its fields are foreign keys or PK foreign keys) and gives it a sensible auto-generated name following your naming convention, for example students_courses.

Adjusting the result

The junction entity is a normal entity. You can:

  • Rename it to match your conventions.
  • Add extra columns - a junction table often carries its own attributes, like enrolled_at or role.
  • Add a composite unique constraint if the pairing needs extra scoping.

Why this matters

Modeling N:N correctly is one of the most common places ERDs go wrong. Letting Schemity wire up the foreign keys and composite key keeps your 1:N vs N:N relationships honest and your schema normalized.

Next

Organize a growing schema with Context Views.