UNIT 2

E-R Model:

o ER model stands for an Entity-Relationship model. It is a high-level data

model. This model is used to define the data elements and relationship for
a specified system.
o It develops a conceptual design for the database. It also develops a very
simple and easy to design view of data.
o In ER modeling, the database structure is portrayed as a diagram called an
entity-relationship diagram.

For example, Suppose we design a school database. In this database, the

student will be an entity with attributes like address, name, id, age, etc. The
address can be another entity with attributes like city, street name, pin code, etc
and there will be a relationship between them.

R
VA
A
N
A
PP
A
TT
U
IM
XM
LA

Below picture clearly depicts about different notations we need while using ER
diagram in DBMS. They are –
 R
VA
A
N
A
PP
A
TT

Components of ER Diagram in dbms

U

As above image describes,

IM
XM

 Rectangle – It represents entity in the ER Model.

Ellipse – It represents attribute in the ER Model.
LA


 Diamond – It represents relationship between entity and attribute.
 Line – It links attribute(s) to entity set(s) and entity set(s) to relationship
set(s).
 Doubles Ellipses – It represents multivalued attributes.
 Dashed Ellipses – It denotes derived attributes.
 Double lines – It indicates total participation of an entity in a relationship
set.
 Double Rectangle – It represents weak entity set.
 Double Diamonds – It represents weak relationships.
 Multiple ellipses connected to single ellipse using lines – It represents
composite attribute
 Ellipse with line inside it – It represents single values attributes

Component of ER Diagram
 R
VA
A
N

1. Entity:
A
PP
A

An entity may be any object, class, person or place. In the ER diagram, an entity
TT

can be represented as rectangles.

U
IM

Consider an organization as an example- manager, product, employee,

department etc. can be taken as an entity.
XM
LA

a. Weak Entity

An entity that depends on another entity called a weak entity. The weak
entity doesn't contain any key attribute of its own. The weak entity is represented
by a double rectangle.
2. Attribute
The attribute is used to describe the property of an entity. Eclipse is used to
represent an attribute.

For example, id, age, contact number, name, etc. can be attributes of a student.

R
a. Key Attribute
VA
A
N
The key attribute is used to represent the main characteristics of an entity. It
A
PP

represents a primary key. The key attribute is represented by an ellipse with the
text underlined.
A
TT
U
IM
XM
LA

b. Composite Attribute

An attribute that composed of many other attributes is known as a composite

attribute. The composite attribute is represented by an ellipse, and those ellipses
are connected with an ellipse.
c. Multivalued Attribute

An attribute can have more than one value. These attributes are known as a
multivalued attribute. The double oval is used to represent multivalued attribute.

For example, a student can have more than one phone number.

d. Derived Attribute

An attribute that can be derived from other attribute is known as a derived

attribute. It can be represented by a dashed ellipse.

R
For example, A person's age changes over time and can be derived from

VA
another attribute like Date of birth. A
N
A
PP
A
TT
U
IM
XM
LA

1. Primary key
o It is the first key used to identify one and only one instance of an entity
uniquely. An entity can contain multiple keys, as we saw in the PERSON
table. The key which is most suitable from those lists becomes a primary
key.
o In the EMPLOYEE table, ID can be the primary key since it is unique for
each employee. In the EMPLOYEE table, we can even select
License_Number and Passport_Number as primary keys since they are
also unique.
o For each entity, the primary key selection is based on requirements and
 developers.

2. Candidate key
o A candidate key is an attribute or set of attributes that can uniquely identify
a tuple.
o Except for the primary key, the remaining attributes are considered a
candidate key. The candidate keys are as strong as the primary key.

For example: In the EMPLOYEE table, id is best suited for the primary key. The
rest of the attributes, like SSN, Passport_Number, License_Number, etc., are
considered a candidate key.

3. Super Key

R
VA
Super key is an attribute set that can uniquely identify a tuple. A super key is a
superset of a candidate key.
A
N
A

For example: In the above EMPLOYEE table, for(EMPLOEE_ID,

PP

EMPLOYEE_NAME), the name of two employees can be the same, but their
A

EMPLYEE_ID can't be the same. Hence, this combination can also be a key.
TT
U

The super key would be EMPLOYEE-ID (EMPLOYEE_ID, EMPLOYEE-NAME),

IM

etc.
XM

4. Foreign key
LA

o Foreign keys are the column of the table used to point to the primary key of
another table.
o Every employee works in a specific department in a company, and
employee and department are two different entities. So we can't store the
department's information in the employee table. That's why we link these
two tables through the primary key of one table.
o We add the primary key of the DEPARTMENT table, Department_Id, as a
new attribute in the EMPLOYEE table.
o In the EMPLOYEE table, Department_Id is the foreign key, and both the
tables are related.
5. Alternate key
There may be one or more attributes or a combination of attributes that uniquely
identify each tuple in a relation. These attributes or combinations of the attributes
are called the candidate keys. One key is chosen as the primary key from these
candidate keys, and the remaining candidate key, if it exists, is termed the
alternate key. In other words, the total number of the alternate keys is the total
number of candidate keys minus the primary key. The alternate key may or may
not exist. If there is only one candidate key in a relation, it does not have an
alternate key.

For example, employee relation has two attributes, Employee_Id and PAN_No,
that act as candidate keys. In this relation, Employee_Id is chosen as the primary
key, so the other candidate key, PAN_No, acts as the Alternate key.

6. Composite key

R
VA
Whenever a primary key consists of more than one attribute, it is known as a
A
composite key. This key is also known as Concatenated Key.
N
A

For example, in employee relations, we assume that an employee may be

PP

assigned multiple roles, and an employee may work on multiple projects

A

simultaneously. So the primary key will be composed of all three attributes,

TT

namely Emp_ID, Emp_role, and Proj_ID in combination. So these attributes act

U

as a composite key since the primary key comprises more than one attribute.
IM

7. Artificial key
XM
LA

The key created using arbitrarily assigned data are known as artificial keys.
These keys are created when a primary key is large and complex and has no
relationship with many other relations. The data values of the artificial keys are
usually numbered in a serial order.

For example, the primary key, which is composed of Emp_ID, Emp_role, and
Proj_ID, is large in employee relations. So it would be better to add a new virtual
attribute to identify each tuple in the relation uniquely.

3. Relationship
A relationship is used to describe the relation between entities. Diamond or
rhombus is used to represent the relationship.
Types of relationship are as follows:

a. One-to-One Relationship

When only one instance of an entity is associated with the relationship, then it is
known as one to one relationship.

For example, A female can marry to one male, and a male can marry to one
female.

R
b. One-to-many relationship
VA
A
N
When only one instance of the entity on the left, and more than one instance of
A
PP

an entity on the right associates with the relationship then this is known as a one-
to-many relationship.
A
TT

For example, Scientist can invent many inventions, but the invention is done by
U
IM

the only specific scientist.

XM
LA

c. Many-to-one relationship

When more than one instance of the entity on the left, and only one instance of
an entity on the right associates with the relationship then it is known as a many-
to-one relationship.

For example, Student enrolls for only one course, but a course can have many
students.
d. Many-to-many relationship

When more than one instance of the entity on the left, and more than one
instance of an entity on the right associates with the relationship then it is known
as a many-to-many relationship.

For example, Employee can assign by many projects and project can have many
employees.

R
VA
1. Entity : An entity is a thing in a real-world with independent existence.
An entity can exist independently and is distinguishable from other objects. It
A
N
can be identified uniquely.
A

An entity can be of two types :

PP

Tangible Entity : Entities that exist in the real world physically. Example:
A


TT

Person, car, etc.

 Intangible Entity : Entities that exist only logically and have no physical
U
IM

existence. Example: Bank Account, etc.

Example :
XM

 A student with a particular roll number is an entity.

LA

 A company with a particular registration number is an entity.

Note :
 An entity may be concrete like a student, a book, or abstract like a holiday
or a particular concept.
 An entity is represented by a set of attributes.
 In a particular relation in RDBMS, a particular record is called an entity.
2. Entity Type : It refers to the category that a particular entity belongs to.

Example :
 A table named student in a university database.
 A table named employee in a company database.
Note :
 The category of a particular entity in the relation in RDBMS is called the
entity type.
 It is represented by the name of the table and its schema.
3. Entity Set : An entity set is a collection or set of all entities of a particular
entity type at any point in time. The type of all the entities should be the same.

Example :
 The collection of all the students from the student table at a particular
instant of time is an example of an entity set.
 The collection of all the employees from the employee table at a particular
instant of time is an example of an entity set.
Note :
 Entity sets need not be disjoint. For example, the entity set of Article Writer
(all content creators for GeeksforGeeks) and the entity set of Article
Reader (all students who read the article of GeeksforGeeks) may have
members in common.
 The collection of all the entities in the relation of RDBMS is called an entity
set.
Relation With Table :
Consider a table student as follows :
Table Name : Student

R
Student_I Student_Nam Student_Ag Student_Gende
D e e r
VA
A
N
A

1 Avi 19 M
PP
A

2 Ayush 23 M
TT
U
IM

3 Nikhil 21 M
XM

4 Riya 16 F
LA

Entity : Each row is an entity.

Example :
1
1 Avi M
9

Entity Type : Each entity belongs to the student type. Hence, the type of
entity here is a student.
Entity Set : The complete data set of all entities is called entity set. For the
above table, the records with student id 1, 2, 3, 4 are the entity set.
Difference Table :
Entity Entity Type Entity Set

A thing in the real world with A category of a Set of all entities of a

independent existence particular entity particular entity type.
 Any particular row (a record) in The name of a relation All rows of a relation
a relation(table) is known as an (table) in RDBMS is an (table) in RDBMS is
entity. entity type entity set

Structural Constraints of Relationships in

ER Model
Prerequisite – ER Model To understand Structural Constraints, we must take a
look at Cardinality Ratios and Participation Constraints. Cardinality Ratios of
relationships : The entities are denoted by rectangle and relationships by
diamond.

R
There are numbers (represented by M and N) written above the lines which

VA
connect relationships and entities. These are called cardinality ratios. These
A
represent the maximum number of entities that can be associated with each
N
other through relationship, R. Types of Cardinality
A
PP
A
TT
U
IM
XM
LA

:T here can be 4

types of cardinality –
1. One-to-one (1:1) – When one entity in each entity set takes part at most
once in the relationship, the cardinality is one-to-one.
2. One-to-many (1: N) – If entities in the first entity set take part in the
relationship set at most once and entities in the second entity set take part
many times (at least twice), the cardinality is said to be one-to-many.
3. Many-to-one (N:1) – If entities in the first entity set take part in the
 relationship set many times (at least twice), while entities in the second
entity set take part at most once, the cardinality is said to be many-to-one.
4. Many-to-many (N: N) – The cardinality is said to be many to many if
entities in both the entity sets take part many times (at least twice) in the
relationship set.
Participation Constraints : Participation Constraints tell us that the
participation in a relationship can either be total or partial.

R
When each entity in an entity set participates in a relation, it is called Total

VA
Participation. However, when all entities in the given entity set do not
A
participate in a relation, it is called Partial Participation. Structural
N
Constraints : Structural Constraints are also called Structural properties of a
A

database management system (DBMS). Cardinality Ratios and Participation

PP

Constraints taken together are called Structural Constraints. The name

A

constraints refer to the fact that such limitations must be imposed on the data,
TT

for the DBMS system to be consistent with the requirements.

U
IM
XM
LA

The Structural constraints are represented by Min-Max notation. This is a

pair of numbers(m, n) that appear on the connecting line between the entities
and their relationships. The minimum number of times an entity can appear in
a relation is represented by m whereas, the maximum time it is available is
denoted by n. If m is 0 it signifies that the entity is participating in the relation
partially, whereas, if m is either greater than or equal to 1, it denotes total
participation of the entity. Note – Number of times an entity participates in a
relationship is same as the number appearance of the entity in the tuples.

Degree of Relationship
In DBMS, a degree of relationship represents the number of entity types that
are associated with a relationship. For example, we have two entities, one is a
student and the other is a bag and they are connected with the primary key
and foreign key. So, here we can see that the degree of relationship is 2 as 2
entities are associating in a relationship.
Types of degree
Now, based on the number of linked entity types, we have 4 types of degrees
of relationships.
1. Unary
2. Binary
3. Ternary
4. N-ary
Let’s discuss them one by one with the help of examples.
Unary (Degree 1)
In this type of relationship, both the associating entity types are the same. So,
we can say that unary relationships exist when both entity types are the same
and we call them the degree of relationship is 1. In other words, in a relation
only one entity set is participating then such type of relationship is known as a

R
VA
unary relationship.
Example: In a particular class, we have many students, there are monitors
A
too. So, here class monitors are also students. Thus, we can say that only
N
A

students are participating here. So the degree of such type of relationship is 1.

PP
A
TT
U
IM
XM
LA

Binary (Degree 2)
In a Binary relationship, there are two types of entity associates. So, we can
say that a Binary relationship exists when there are two types of entity and we
call them a degree of relationship is 2. Or in other words, in a relation when
two entity sets are participating then such type of relationship is known as a
binary relationship. This is the most used relationship and one can easily be
converted into a relational table.
Example: We have two entity types ‘Student’ and ‘ID’ where each ‘Student’
has his ‘ID’. So, here two entity types are associating we can say it is a binary
relationship. Also, one ‘Father’ can have many ‘daughters’ but each ‘daughter’
should belong to only one ‘father. We can say that it is a one-to-many binary
relationship.

Ternary (Degree 3)
In the Ternary relationship, there are three types of entity associates. So, we
can say that a Ternary relationship exists when there are three types of entity
and we call them a degree of relationship is 3. Since the number of entities
increases due to this, it becomes very complex to turn E-R into a relational
table. Now let’s understand with the examples.
Example: We have three entity types ‘Teacher’, ‘Course’, and ‘Class’. The
relationship between these entities is defined as the teacher teaching a
particular course, also the teacher teaches a particular class. So, here three

R
entity types are associating we can say it is a ternary relationship.

VA
A
N
A
PP
A
TT
U
IM
XM
LA

N-ary (n Degree)
In the N-ary relationship, there are n types of entity that associates. So, we
can say that an N-ary relationship exists when there are n types of entities.
There is one limitation of the N-ary relationship, as there are many entities so
it is very hard to convert into an entity, rational table. So, this is very
uncommon, unlike binary which is very much popular.
Example: We have 5 entities Teacher, Class, Location, Salary, Course. So,
here five entity types are associating we can say an n-ary relationship is 5.
What is Cardinality?
In Mathematics, cardinality means the number of members in a set. But in DBMS,

R
the definition of cardinality is different. The uniqueness of data present in a

VA
column is called cardinality.
A column with a high cardinality means that a significant percentage of the values
A
N
are unique. Low cardinality refers to a column with a large number of repeated
A

values.
PP

Now let’s have a look at the concept of mapping cardinality.

Why is Cardinality Important in Database?
A
TT

Cardinality is important in the Database as it creates links between different

U

entities inside a table. It has a huge impact on the query execution plan, that is,
IM

the number of steps a user takes to search for a particular value/object inside the
XM

database.
Cardinality is also critical in optimizing database performance. The database
LA

optimizer can select the most efficient query execution plan by precisely
assessing the cardinality of distinct characteristics or columns in a table. A
greater cardinality indicates more distinct values, leading to improved selectivity
and faster query execution. A reduced cardinality, on the other hand, may
suggest a limited number of distinct values, allowing the database to use
specialized optimization techniques such as index selection and join algorithms.
What is Mapping Cardinality?
Mapping cardinality refers to the relationship between two entities in a database.
It specifies how many instances of one entity can be linked to instances of
another entity. It aids in understanding the nature and limits of relationships,
allowing for appropriate database design and ensuring data integrity throughout
data manipulation procedures.

Types of Cardinality in DBMS

When one attribute of a particular entity refers to another attribute of another
entity, some relationship exists between both entities. How the elements of one
entity are related to another entity can be defined using the Mapping Cardinality.
There are four types of Mapping cardinality in a database, which are:
 One-to-One cardinality (1:1)

 One-to-Many cardinality (1)

 Many-to-One cardinality (m:1)

 Many-to-Many cardinality (m)

Let's discuss each of these in detail in the upcoming sections.

1. One-to-One Cardinality (1:1)
An entity in A is associated with at most one entity in B in this form of cardinality
mapping.

R
VA
A
N
A
PP
A
TT
U
IM

Let's have a look at the example for more clarity.

XM
LA

Here, this relationship is one-to-one relationship because one team is led by one
team leader.
2. One-to-Many Cardinality (1)
An entity set A is associated with any number of entities in B (including zero), and
each entity in B is associated with just one entity in A.
Let's have a look at the example for more clarity.

R
VA
A
N
A

Here, this is one-to-many relationship because one team has many team
PP

members.
3. Many-to-One Cardinality (m:1)
A
TT

An entity set in A can only be associated with one entity in B. In contrast, an entity
U

set in B can be associated with any number of entities in A, including zero.

IM
XM
LA

Let's have a look at the example for more clarity.

Here, this many-to-one relationship because many employees work in Coding
Ninja.
4. Many-to-Many Cardinality (m)
Any entity in A and B is associated with many entities in B and A, respectively,
which means many rows in the first table are associated with many rows in the
second table.

R
VA
A
N
A
PP
A
TT
U

Consider this example for better understanding.

IM
XM
LA

Here, this is many-to-many relationship because many employees works on

many projects.
Appropriate Mapping Cardinality
The proper mapping cardinality for a given relation set is obviously determined by
the context in which the relation set is modeled.
 We can mix relational tables with multiple involved tables if the cardinality is
one-to-many or many-to-one

 We can't mix any two tables if the cardinality is many-to-many

 If we have a one-to-one relation and one entity has complete participation,

 we can mix that entity with a relation table, and if both entities have complete
participation, we can build one table by combining the two entities and their
relation
Weak Entity Set in ER diagrams
An entity type should have a key attribute which uniquely identifies each entity
in the entity set, but there exists some entity type for which key attribute can’t
be defined. These are called Weak Entity type.
The entity sets which do not have sufficient attributes to form a primary key
are known as weak entity sets and the entity sets which have a primary key
are known as strong entity sets.
As the weak entities do not have any primary key, they cannot be identified on
their own, so they depend on some other entity (known as owner entity). The
weak entities have total participation constraint (existence dependency) in its
identifying relationship with owner identity. Weak entity types have partial
keys. Partial Keys are set of attributes with the help of which the tuples of the
weak entities can be distinguished and identified.
Weak entity is depend on strong entity to ensure the existence of weak

R
entity. Like strong entity, weak entity does not have any primary key, It has

VA
partial discriminator key. Weak entity is represented by double rectangle. The
A
relation between one strong and one weak entity is represented by double
N
diamond.
A
PP
A
TT
U
IM
XM
LA

Weak entities are represented with double rectangular box in the ER

Diagram and the identifying relationships are represented with double
diamond. Partial Key attributes are represented with dotted lines.
Example-1:
In the below ER Diagram, ‘Payment’ is the weak entity. ‘Loan Payment’ is the
identifying relationship and ‘Payment Number’ is the partial key. Primary Key
of the Loan along with the partial key would be used to identify the records.

R
VA
A
N
A
PP
A
TT
U
IM
XM
LA
LA
XM
IM
U
TT
A
PP
A
N
A
VA
R