Cardinality & Participation

Constraint in DBMS
A.Bathsheba Parimala
Assistant Professor
Dept.of BCA& M.Sc(NT&IT)
St.Johns college,Palayamkottai
 Constraints

Relationship types usually have certain constraints that

limit the possible combinations of entities that may
participate in the corresponding relationship set.
Constraints ?
Why to use Constraints ?
• To limit the type of data that can go into a table
• To maintain the accuracy and integrity of the data inside table.

Most used constraints:

• NOT NULL
• UNIQUE
• PRIMARY KEY
• FOREIGN KEY
• CHECK
• DEFAULT
Type of Constraints

We can distinguish two main types of relationship

constraints:
• Cardinality constraints
• Participation constraints
 Employee Work for Department

Entity Relationship type

Entity

Every relation in relationship type is an association between employee

and department
Requirement Analysis:
• Every employee work for one department
• An department can have many employees
• New department need not have employee
Degree:
In every relationship how many entities are participating.
 Degree-2(binary)

E1 1
E2 2
D1
E3 3
D2
E4 4
D3
E5 5
E6 6

employee
Work for Department
ER diagram

N 1
Work For Department
Employee

Min/Max Representation

(1,1) (0,N)
Employee Work For Department

More info could be represented using MIN/Max Method

 Degree-2(binary)

E1
E2 1 D1
E3 2 D2
E4 3 D3
4 D4

Employee Manager Department

Requirement Analysis:
Every Department should have a manager & only one employee manages a department.

An Employee can manage only one department.

Cardinality

My Cardinal Is Bigger Than Yours

 Cardinality

The term cardinality actually has two different meanings

depending on the context of it’s usage – one meaning is in the
context of Data modeling and the other meaning is in the
context of SQL statements.
Relationship one table can have with another table
In The Context Of Data Modeling
It simply refers to the relationship that one table can have
with another table.
These relationships include: many-to-many, many-to-
one/one-to-many, or one-to-one – whichever one of these
characteristics a table has in relationship with another table is
said to be the cardinality of that table.
Example:
Suppose we have three tables that are used by a company to store employee
information: an Employee table, an Employee_Salary table, and a Department
table.
The Department table will have a one to many relationship with the Employee
table, because every employee can belong to only one department, but a
department can consist of many employees.
In other words, the cardinality of the Department table in relationship to the
employee table is one to many.
The cardinality of the Employee table in relationship to the Employee_Salary
table will be one to one, since an employee can only have one salary, and vice
versa.
There are three degrees of Cardinality, known as:
• One-to-One (1:1):One occurrence of an entity relates to only one occurrence in
another entity.

• One-to-Many (1:M): One occurrence in an entity relates to many occurrences

in another entity.

• Many-to-Many (M:N) Many occurrences in an entity relate to many

occurrences in another entity.
Cardinality in SQL

Uniqueness of data
 Cardinality in SQL
Cardinality refers to the uniqueness of data contained in a
column.
If a column has a lot of duplicate data (e.g. a column that
stores either "true" or "false"), it has low cardinality,
but if the values are highly unique (e.g. Social Security
numbers), it has high cardinality.
For example, let’s say we have a table with a “Gender”
column which has only two possible values of “Male” and
“Female”.
Then, that “Gender” column would have a cardinality of 2,
because there are only two unique values that could possibly
appear in that column .
Let’s say that we have a primary key column on
a table with 10,000 rows. What do you think the
cardinality of that column would be?

Primary key: It is a key in a relational database that is unique for

each record.
 It is 10,000.
Because it is a primary key column, we know that all of the
values in the column must be unique.

Cardinality of a primary key column will always be

equal to the number of records in the same table.
Participation Constraint
 Participation Constraint

There are two types of participation constraints—total and partial.

The participation of an entity set E in a relationship set R is said to be
total if every entity in E participates in at least one relationship in R.
If only some entities in E participate in relationships in R, the
participation of entity set E in relationship R is said to be partial.
 ER model

Double line indicates the total participation

constraint in an ER model.

Single line indicates the partial participation

constraint in an ER model.
Cardinality Constraints : At most

Participation Constraints : At least or Minimum

 Cardinality Constraints Participation

high
cardinality
Data SQL
Partial Total
modeling statements

low
cardinality

One-to-One

One-to-Many

Many-to-Many