What is Mapping Cardinalities in ER Diagrams (original) (raw)

Last Updated : 23 Jul, 2025

Mapping cardinality (or cardinality ratio) in an **ER diagram tells us how many instances of one entity can be associated with how many instances of another entity through a relationship.

That is for each instance of Entity A, how many instances of Entity B can it relate to, and vice versa

**Example:

Example of Mapping Cardinalities

• The attribute Manager of the department refers to an employee who manages the department.
• In the ER model, these references are represented as relationships.

Mapping cardinality helps:

• Define relationship constraints.
• Normalize database design.
• Inform foreign key placement and table structure during relational mapping.

Relationship

**The relationship in the ER model is represented using a diamond-shaped box.

In the Entity-Relationship (ER) model, relationships represent how two or more entities interact with each other. These relationships are often depicted as a diamond-shaped box connecting the related entities. For instance, a customer buying products is a common business relationship where the customer and the product are two entities, and the act of buying forms the relationship.

Each relationship can have attributes, such as a timestamp recording when a customer buys a product. Thus, relationships can have their own unique characteristics that further define the interaction between entities.

**Example:

Example of Relationship in DBMS

****'Buys'** is a relationship between customer entity and products. This relationship can be read as 'A customer buys a product/products.

**Therefore, a relationship is a way to connect multiple entities.

• When a customer buys a product, there is a timestamp associated with it, so the attribute "Time" will be an attribute of 'Buys'.
• All the database concepts can be easily understood from the concepts of sets and relations.
• According to the Set-theoretic perspective, it will be represented as

Example

By interpreting this, we can understand that many customers can buy the same type of product and many products can be bought by many customers. And there are some products which are not bought by any customer and there are some customers who do not buy any product.

**According to the Relation/table perspective or relational model:
It can be represented as

Many to many Relationship

As the relationship is many to many (M: N) between customer and product, therefore we require separate tables/ relations for 'buys'.
In buys relation, Cust_id and Prod_id are the foreign key to the customer and product.

Mapping Cardinality/Cardinality Ratio

Mapping cardinality is the maximum number of relationship instances in which an entity can participate.

**Example:

Entity type employee is related to department entity type by works_for relationship

Mathematically, here (e1, e2,e3...) are instances of an entity set Employee and (d1,d2, d3 ....) are the instances of entity type department and (r1, r2, r3 ...) are relationship instances of relationship type.

Each instance ri(where i = 1,2,3,....) in R, is an association of entities, and the association includes exactly one entity from each participating entity type. Each such relationship instance, ri represents that the entities participating in ri are related in some way by any constraint/condition provided by the user to a designer.

• In works_for binary relationship type Department: Employee is of cardinality (N:1), this means each department can be related to any number of employees but an employee can be related to (works for) only one department.
• The possible cardinality ratios of binary relationship types are (1:1, 1:N, N:1, N:M).

Participation or existence constraint:

It represents the minimum number of relationship instances that each entity can participate in and it is also called the minimum cardinality constraint. There are two types of participation constraints, which are **total and partial.

If **every employee must work in a department, then all employees are **required to be linked to a department.

• This is called **total participation (also known as **existence dependency).
• In the ER diagram, it's shown using a **double line.

If a **department can exist without any employees, then not all departments need to be linked to employees.

• This is called **partial participation.
• In the ER diagram, it's shown using a **single line.

The cardinality ratio and participation constraint together is called structural constraint of the relationship type.
All possible cardinality ratios for binary relationships are explained below with an example.

1. One to one relationship (1:1)

**One item is connected to **only one other item,
and **that item is also connected to only one in return.

It is represented using an arrow(⇢,⇠)(There can be many notations possible for the ER diagram).
**Example:

One to One relationship

In this ER diagram, both entities customer and driving license having an arrow which means the entity Customer is participating in the relation "has a" in a one-to-one fashion. It could be read as 'Each customer has exactly one driving license and every driving license is associated with exactly one customer.

**The set-theoretic perspective of the ER diagram is

one to one relationship

There may be customers who do not have a credit card, but every credit card is associated with exactly one customer. Therefore, the entity customer has total participation in a relation.

2. One to many relationship (1:M)

**One item is connected to **many items,
but each of those **many items is connected to only that one.

**Example:

one to many relationship

This relationship is one to many because "There are some employees who manage more than one team while there is only one manager to manage a team".
**The set-theoretic perspective of the ER diagram is:

ER diagram

3. Many to one relationship (M:1)

**Many items from one group are connected to **just one item in another group.

**Example:

Many to one relationship

This is a **one-to-many relationship, but the difference comes from ****who must participate .**The set-theoretic perspective of the ER diagram is:

• A **customer can have **many credit cards, but **some customers might not have any. So, **customer participation is partial.
• **Every credit card must be linked to one customer. So, **credit card participation is total.
• Also, a **credit card belongs to only one customer — it **cannot be shared by multiple customers.

ER diagram

4. Many to many relationship (M:N)

One entity in the first set can be related to **many entities in the second set,
**and One entity in the second set can also be related to **many entities in the first set.

**Example:
A customer can buy any number of products and a product can be bought by many customers.

Many to many Relationship

The set-theoretic perspective of the ER diagram is:

ER diagram

Any of the four cardinalities of a binary relationship can have both sides partial, both total, and one partial, and one total participation, depending on the constraints specified by user requirements.

Relationship Table

**Related articles:

• Database Management System
• one-to-one
• one-to-many
• Entity-Relationship (ER) model