Is one-to-many different from many-to-one?

They describe opposite directions of the same relationship. Always identify which entity is being considered first.

Does a one-to-many relationship require at least one child?

Not by that maximum-cardinality label alone. Minimum participation must also be specified.

Can a many-to-many relationship have its own attributes?

Yes. An associative entity can record information about each association, such as role or effective period.

AI Glossary / Data engineering and architecture / Beginner

Cardinality (data modeling)

Definition

In data modeling, cardinality describes how many instances of one entity may or must be associated with an instance of another. Common relationship patterns are one-to-one, one-to-many and many-to-many, often supplemented by minimum and maximum participation limits.

What it means

A model might say that one customer can have many orders and each order belongs to one customer. Those statements describe the two directions of a relationship. They do not mean that every customer must already have several orders.

Minimum participation adds another question: can a customer have no orders, and can an order exist without a customer? Notations such as 0..many and 1..1 make optionality and required participation visible. Diagram conventions differ, so the legend and direction of reading matter.

The word has other database meanings. A query's cardinality can mean its number of rows, while column cardinality can mean its number of distinct values. This entry focuses on permitted relationships in a data model, not those statistical counts.

How it works

Modelers define what each entity instance represents and describe the business rules connecting instances. For each direction, they ask for the minimum and maximum number of permitted links. Examples and counterexamples help expose hidden assumptions.

A relational implementation often represents one-to-many links with a foreign key on the many side. A uniqueness constraint can restrict the maximum to one in appropriate designs, while nullability can express some optional relationships. These constraints do not automatically enforce every minimum-participation rule on the opposite side.

Many-to-many relationships are commonly represented with an associative table. That table can hold attributes of the relationship itself, such as an assignment date. Its own key must reflect whether repeated associations are allowed. The diagram describes intended rules; the schema and application must actually enforce them.

Three practical examples

A library model distinguishes a book title from its physical copies, allowing one title to describe several copies.
A project system records many employees on many projects through an assignment entity.
A reporting team checks a customer-to-order relationship before combining customer-level and order-level measures.

Think of it this way

Think of a guest list and a table-seating plan. You must define whether each guest has exactly one assigned seat and whether a table can hold several guests. Those rules govern permitted arrangements rather than merely describing how many guests happen to be seated today.

The analogy changes if the model covers several dinners or allows guests to change seats. Similarly, data cardinality depends on the entity definition and time scope. A relationship that is one-to-one at a moment may be one-to-many across its history.

Worked example

Consider a fictional project model. Employee E1 works on projects P1 and P2; employee E2 also works on P1. The employee-project relationship is many-to-many under a rule allowing each employee several projects and each project several employees.

An Assignment table can contain the pairs E1 - P1, E1 - P2 and E2 - P1. If only one current assignment per employee-project pair is permitted, that pair can be constrained as unique. If the system records separate periods or roles, the row definition and key need further thought.

Now join employees to assignments. E1 appears twice in the joined result. Summing an employee-level allowance of 100 for E1 and 150 for E2 over those joined rows would produce 350 instead of the intended 250. The relationship is not necessarily wrong; the aggregation is at the wrong grain. Correct cardinality helps identify this risk.

Illustrative case study

Illustrative case study: A fictional equipment rental company initially models each item as having exactly one rental agreement. That works for a snapshot of currently rented items but fails when the system needs to preserve years of rental history.

The team separates equipment items from rental occurrences. It allows an item to participate in many rental occurrences over time and separately defines the rule preventing overlapping active rentals. It also allows newly purchased items to have no rental history.

This invented case illustrates why time scope and participation limits must be explicit. A one-to-many diagram alone does not enforce the no-overlap rule; that additional temporal constraint needs its own implementation and tests.

Common misconceptions and mistakes

Inferring a business relationship solely from a small current dataset.
Treating “many” as a requirement that every instance already has multiple links.
Ignoring optionality or reading diagram endpoints in the wrong direction.
Assuming a foreign key guarantees every parent has at least one child.
Summing measures after a join without checking whether the relationship duplicates their original rows.

Business use

For businesses, cardinality is part of agreeing what the organization means by customers, orders, assignments and other records. Incorrect assumptions can block legitimate transactions, admit invalid data or distort reports. Review the model with people who understand exceptions and changes over time.

For AI pipelines, relationship mistakes can duplicate training examples or attach the wrong contextual records to a person or transaction. Document the grain of each dataset and check join results against expected relationship rules. Treat automated relationship suggestions as hypotheses to verify, especially when historical data contains duplicates or incomplete links.

Check your understanding

A foreign key ensures each order's customer reference exists. Does that alone require every customer to have an order?

Answer: No. It validates references from orders to customers, but does not create or require an order for every customer.

Related terms

Entity-Relationship Model
One-to-many (data model)
Many-to-many (data model)
Foreign key
Referential integrity
One-to-many
Many-to-many
Optionality
Associative entity
Data grain
Join cardinality

Learn next

Read each relationship in both directions using “each X may or must relate to at least ... and at most ... Y”. Then test a zero-link case, multiple-link case and historical change against the proposed rules.

Sources

Primary sources: IBM, Entity relationship diagrams and relationship cardinality: https://www.ibm.com/think/topics/entity-relationship-diagram ; IBM Cognos, minimum-maximum cardinality and double-counting considerations: https://www.ibm.com/docs/en/cognos-analytics/11.2.x?topic=cardinality-in-generated-queries ; PostgreSQL constraints and foreign keys: https://www.postgresql.org/docs/18/ddl-constraints.html . Relevant returned or indexed explanations reviewed. Assignment calculation and rental case are original examples.

Previous: Capture group Next: Carrier cloud