Database Cardinality and Participation Constraints Notation Explained

If you've ever stared at an entity-relationship diagram and wondered what those lines, symbols, and labels actually mean, you're not alone. Understanding database cardinality and participation constraints notation is the difference between building a database that works correctly and one that quietly corrupts your data. These notations tell you exactly how entities relate to each other how many records connect, and whether a connection is required or optional. Getting this wrong leads to broken queries, orphaned records, and models that don't match reality. This article breaks down the notation so you can read, write, and explain it with confidence.

What are cardinality and participation constraints in a database?

Cardinality and participation constraints are rules defined during database design that describe the nature of relationships between entities in an entity-relationship (ER) model.

Cardinality defines the numerical relationship between two entities. It answers: how many instances of one entity can be associated with instances of another entity? The three main types are:

One-to-One (1:1) Each record in Entity A relates to exactly one record in Entity B, and vice versa. Example: one person has one passport number.
One-to-Many (1:N) One record in Entity A can relate to many records in Entity B, but each B record relates to only one A. Example: one department has many employees.
Many-to-Many (M:N) Records in both entities can relate to multiple records in the other. Example: students enroll in many courses, and courses have many students.

Participation constraints (also called existence constraints) define whether every instance of an entity must participate in a relationship. There are two types:

Total participation Every instance of the entity must be involved in the relationship. Represented by a double line in Chen notation. Example: every employee must belong to a department.
Partial participation Some instances may not participate in the relationship. Represented by a single line. Example: not every employee manages a department.

Together, these constraints tell the database designer and anyone reading the schema exactly what rules the data must follow. If you're still getting comfortable with ER diagrams overall, our guide on how to read database schema diagrams covers the broader picture.

How do you read cardinality notation in ER diagrams?

Cardinality notation varies depending on which diagramming style you're using. The two most common are Chen notation and Crow's Foot notation. We compare them in detail in our article on Crow's Foot notation vs. Chen notation, but here's the short version.

Chen notation

In Chen notation (the original ER model style introduced by Peter Chen in 1976), cardinality is written as labels directly on the relationship line:

1 for "one"
N or M for "many"

A line between two entities might read "1" on one side and "N" on the other, indicating a one-to-many relationship. Participation is shown by the style of the connecting line itself a double line means total participation, and a single line means partial participation.

Crow's Foot notation

Crow's Foot notation uses graphical symbols instead of text labels. You'll typically see three symbols:

A single line (|) represents "one" (exactly one)
A crow's foot (∞ or three-pronged fork) represents "many" (one or more)
A circle (○) represents "zero" (optional)

So a line connecting "Employee" to "Department" might show a crow's foot on the Employee side and a single bar on the Department side, meaning one department has many employees. If there's a circle before the crow's foot, it means "zero or many" participation is partial.

The combination of these symbols is what makes Crow's Foot popular: it packs both cardinality and participation into a compact visual notation. For a full breakdown of the symbols themselves, see our reference on database schema notation symbols and their meanings.

What's the difference between cardinality and participation constraints?

This is one of the most common points of confusion, so let's clarify it plainly.

Cardinality answers: "How many?" Is it one-to-one, one-to-many, or many-to-many?

Participation answers: "Must it exist?" Is the relationship mandatory (total) or optional (partial) for a given entity?

They describe different aspects of the same relationship. Consider this example:

Take the relationship between Employee and Project:

Cardinality: One-to-many one project can have many employees assigned to it.
Participation (Employee side): Partial not every employee is assigned to a project.
Participation (Project side): Total every project must have at least one employee assigned.

Without specifying both, your schema is incomplete. Cardinality without participation leaves ambiguity about whether records are required. Participation without cardinality leaves ambiguity about how many related records are allowed.

How do you write cardinality and participation in different notation styles?

Here's a practical reference table showing how the same relationship looks across notation systems:

One-to-One, Total Participation on Both Sides

Chen: Two entities connected by a double line, labeled "1" on each end.
Crow's Foot: A single bar (|) on both sides, with no circle (meaning exactly one, mandatory).
Min-Max notation: (1,1) on both sides meaning minimum 1, maximum 1.

One-to-Many, Total on "One" Side, Partial on "Many" Side

Chen: Double line on the "1" side, single line on the "N" side, labeled accordingly.
Crow's Foot: Single bar (|) on the "one" side; circle then crow's foot (○∞) on the "many" side.
Min-Max notation: (1,1) on the "one" side, (0,N) on the "many" side.

Many-to-Many, Total on Both Sides

Chen: Double lines on both sides, labeled "M" and "N."
Crow's Foot: Crow's foot on both sides with no circles.
Min-Max notation: (1,N) on both sides.

The min-max notation is the most precise. It explicitly states the minimum and maximum number of times an entity can participate. For example, (0,5) means "between zero and five." This format removes the ambiguity that sometimes comes with interpreting symbols.

Why do cardinality and participation constraints matter for your database?

These constraints aren't just academic exercises. They directly affect how your database behaves in production:

Data integrity. If participation is total but your schema allows nulls, you'll end up with orphaned or incomplete records. The constraint should map to foreign key rules and NOT NULL settings.
Query correctness. Knowing whether a relationship is optional helps you choose between INNER JOIN and LEFT JOIN. Get this wrong and your reports silently drop data.
Application logic. If an employee doesn't have to belong to a department (partial participation), your app needs to handle that case. If it's total, the app can safely assume the relationship exists.
Schema validation. Constraints encoded in the ER diagram should translate directly to database rules CHECK constraints, foreign keys with ON DELETE rules, and junction table designs for many-to-many relationships.

What are common mistakes when reading or writing these constraints?

Even experienced developers make errors with cardinality and participation. Here are the ones that come up most often:

Confusing "many" with "more than one." In ER modeling, "many" (N) means "zero or more" unless participation is specified as total. Don't assume N means at least two.
Forgetting participation on both sides. A relationship between Employee and Department has participation constraints on each entity. Only specifying one side leaves the diagram incomplete.
Not translating constraints to the physical schema. A beautifully annotated ER diagram is useless if the actual database tables don't enforce the rules. Total participation should map to NOT NULL foreign keys. Many-to-many should map to a junction table.
Mixing up notation systems. A crow's foot symbol means nothing in a Chen diagram and vice versa. Always be clear about which notation you're using, especially when collaborating with a team.
Assuming Crow's Foot always shows participation. Some diagramming tools omit the circle (zero) symbol and only show the crow's foot (many). If you see a crow's foot without a circle, confirm whether "zero" is intended or if the tool simply doesn't support optional participation markers.

How do you apply these constraints when building an actual database?

Let's walk through a concrete example. Suppose you're designing a library system with Member, Book, and Borrowing entities.

Member to Borrowing:

Cardinality: One-to-many one member can have many borrowings.
Participation (Member): Partial a member might have zero borrowings (new member).
Participation (Borrowing): Total every borrowing must belong to a member.
In the database: The Borrowing table has a member_id foreign key that is NOT NULL. The Member table has no foreign key to Borrowing.

Book to Borrowing:

Cardinality: One-to-many one book can appear in many borrowing records (over time).
Participation (Book): Partial a book might never be borrowed.
Participation (Borrowing): Total every borrowing record must reference a book.
In the database: The Borrowing table has a book_id foreign key that is NOT NULL.

The Borrowing entity acts as a junction table that resolves the many-to-many relationship between Member and Book, while also storing relationship-specific data like borrow date and return date.

Where can you learn more about ER diagram notation?

The original ER model was proposed by Peter Chen in his 1976 paper "The Entity-Relationship Model Toward a Unified View of Data." It remains one of the most cited papers in database design. The ACM Digital Library hosts a copy if you want to read the foundational work directly.

For a practical overview of notation symbols across systems, check our guide on database schema notation symbols. And if you need help choosing between the two main diagramming styles, our comparison of Crow's Foot vs. Chen notation covers the tradeoffs.

Quick checklist: applying cardinality and participation correctly

Identify each relationship between your entities and write down the cardinality (1:1, 1:N, or M:N).
For each side of the relationship, decide if participation is total (mandatory) or partial (optional).
Choose a notation system and stay consistent Chen, Crow's Foot, or min-max.
Translate total participation into NOT NULL foreign keys in your physical schema.
Translate many-to-many relationships into a junction table with foreign keys to both entities.
Review your ER diagram with a colleague before implementing notation errors caught on paper are far cheaper than those caught in production.
Use a diagramming tool (like dbdiagram.io, Lucidchart, or draw.io) to create and version-control your ER diagrams alongside your code.