Identify Many-to-Many (M:N) Relationships

A relationship is many-to-many (M:N) when one instance of entity A can be related to zero, one, or many instances of entity B, and one instance of B can be related to zero, one, or many instances of A.

A student may enroll in many classes;
a class may have many enrolled students.

• Symmetric “many” phrasing: Requirements describe “many on both sides,” e.g., employees work on many projects; projects have many employees.
• No clear ownership: Neither side naturally “owns” the other (contrast with 1:N where one side aggregates the other).
• Business facts about the association: You hear attributes that apply to the pairing, e.g., Quantity on an order line, Role on a project team, EnrolledOn for a student’s class.

• Crow’s Foot: a crow’s foot on both ends (|<{ —— }>|) with optionality shown by O (optional) or | (mandatory).
• UML: multiplicities 0..* ↔ 0..*.
• Chen: relationship diamond with “M” next to each participating entity.

• Repeating groups / arrays in a column: comma-separated IDs or names indicate “many” packed into one field.
• Repeating columns: patterns like Class1, Class2, Class3….
• Duplicate rows: rows duplicated just to record another related item.
• Misplaced attributes: putting Quantity in Order or Product rather than on the connection.

Degree is the number of participating entities (binary = 2, ternary = 3). Most modeling uses binary relationships. Connectivity is the maximum mapping (1 or many); cardinality annotations (e.g., 0..*, 1..3) refine minimum/maximum participation.

• 1:1 — each A maps to at most one B and vice versa (rare; often a split table).
• 1:N — A maps to many B; each B maps to one A (most common).
• M:N — many on both sides (what we’re detecting here).

Recursive and higher-degree (ternary) cases can also be M:N; in practice, they are decomposed into binary relationships for implementation.

Conceptually, you may draw an M:N without choosing a “parent.” When moving toward implementation, you will introduce an associative (intersection) entity to hold the pairs and any attributes of the association (e.g., Quantity, PriceAtOrder, Role, EnrolledOn).

• Do requirement sentences use plural on both sides? (orders contain products; products appear on orders)
• Would storing the link in either parent force repeating groups or duplicate rows?
• Are there attributes that clearly describe the pairing rather than either entity alone?
• In your ERD, do both ends show crow’s feet or 0..*?

• Orders ↔ Products (order lines carry Quantity, UnitPrice).
• Employees ↔ Projects (assignment carries Role, Hours).
• Authors ↔ Publications (authorship carries Sequence, Contribution%).

Many-to-many relationships are common in business (including the DistributedNetworks examples). Identification is the first step; physical resolution (via a junction entity) is covered in the next lesson.

Summary: You have an M:N when both sides can have many, the relationship needs its own attributes, and notation shows “many” on both ends. Recognize these early to avoid redundancy and to prepare for proper implementation with an associative entity.