Entity - Relationship

MODEL
Entity relationship Model:
• E-R model is based on a perception of a real
world that consists of set of basic objects
called entities, and relationship among these
objects.

• It is a design or blueprint of a database that

can later be implemented as a database.
▪E-R model describes the logical structure of
a database with the help of a diagram, which
is known as E-R diagram.
▪An entity is a “thing” or “object” in the real
world that is distinguishable from all other
objects.

▪An entity may be anything object, class,

person or place which have some
characteristics or attributes
In this E-R diagram we have two
entities Student and college
 Entity type:
•An entity type defines a collection(or set)
of entities that have the same attributes.
Each entity type in the database is
described by its name and attributes.
•The collection of all entities of a particular
entity type in the database at any point in
time is called an entity set; the entity set is
usually referred to as using the same
name as entity type.
 Attributes
•An attribute describes the property of an
entity.

•An entity is represented by set of attributes.

•Attributes are descriptive properties

possessed by each member of an entity set.
Col_ID and Col_Name are attributes
of entity college
• For each attribute, there is a set of permitted values called the domain or value
set of the attribute.
Types of Attributes

❑ An attribute that cannot be further

subdivided into components is a simple
attribute.

Example: The roll number of a student, the id

number of an employee.
Composite attribute :
❑ An attribute that can be split into
components is a composite attribute.

Example: The address can be further split

into house number, street number, city, state,
country, and pin code, the name can also be
split into first name middle name, and last
name
❑ The attribute which takes up only a
single value for each entity instance is a
single-valued attribute.

❑ Example: The age of a student.

 Multi-valued attribute :
❑ The attribute which takes up more than a
single value for each entity instance is a
multi-valued attribute.

❑ Example: Phone number of a student:

Landline and mobile.
 Derived attribute :
An attribute that can be derived from other
attributes is derived attributes.

Example: Total and average marks of a

student.
 Stored attribute:
❑ The stored attribute are those attribute
which doesn’t require any type of further
update since they are stored in the
database.

❑ Example: DOB(Date of birth) is the stored

attribute.
 Key attribute:
❑ Key attributes are those attributes that can
uniquely identify the entity in the entity set.

❑ Example: Roll-No is the key attribute

because it can uniquely identify the
student.
Notation for E-R Diagram
❑ Rectangle: Represent Entity Types

❑ Double Rectangle: Represent Weak Entity

Types

❑ Diamonds: Represents Relationship Types

❑ Double Diamonds: Represents Identifying

Relationship Types
❑Ellipse: Represent Attributes

❑Ellipse with Underline Attribute: Represent

Key Attribute

❑Ellipse with dashed Underline Attribute:

Represent Partial Key Attribute

❑Double Ellipses: Represent Multivalued

Attributes
❑ Ellipse attached to ellipse: Represent
Composite Attributes

❑Dashed Ellipse: denote derived attributes

❑ Lines: Link Attributes

❑ Double Lines: Indicate Total Participation

 Relationship Constraints
Two types of Relationship Constraints:

❑Cardinality Ratio

❑Participation Constraints
•Cardinality tells how many times the entity of an
entity set participates in a relationship
❑ When a single instance of an entity is
associated with a single instance of another
entity, then it is called a one to one cardinality

• Example for one to one cardinality :

Assume that the only male can be married

to only one female and one female can be
married to only one male, this can be
viewed as one to one cardinality
❑ When is a single instance of an entity is
associated with more than one instance of
another entity then this type of relationship
is called one to many relationships

•Example for one to many cardinalities:

Many Orders can be placed to a single
customer but a single order can not be placed
to many customers.
 Many-to-one cardinality
❑ When more than one instance of an entity
is associated with single instance of another
entity then this type of relationship is called
many to one relationships

•Example for many to one cardinalities:

For example in the Real-world, many students can
study in a single college but the student cannot
apply to more than one college at the same time
 Many-to-many cardinality
❑ Here more than one instance of an entity is
associated with more than one instance of
another entity then it is called many to many
relationships

•Example for many to many cardinality:

In the Real world assume that a student can take
more than one course and the single course can be
taken by any number of students this relationship
will be many to many relationship
Participation Constraints
❑ Total Participation

❑Partial Participation
❑ Each entity in the entity set must participate
in the relationship.

❑Total Participation is shown by double line in

E-R diagram

❑If each student must enroll in a course, the

participation of student will be total.
 Partial Participation
❑ The entity in the entity set may or may not
participate in the relationship.

❑It is represented using a single line.

❑If some courses are not enrolled by any of

the student, the participation of course will
be partial.
Types of Entity Sets-
❑ A strong entity set is an entity set that
contains sufficient attributes to uniquely
identify all its entities.

❑ In other words, a primary key exists for a

strong entity set.

❑ Primary key of a strong entity set is

represented by underlining it.
 Symbols Used-
❑ A single rectangle is used for representing a
strong entity set.

❑ A diamond symbol is used for representing the

relationship that exists between two strong
entity sets.

❑ A single line is used for representing the

connection of the strong entity set with the
relationship set.
❑ A double line is used for representing the total
participation of an entity set with the
relationship set.

❑ Total participation may or may not exist in the

relationship.
 Weak Entity Set-
❑ A weak entity set is an entity set that does
not contain sufficient attributes to uniquely
identify its entities.

❑ In other words, a primary key does not exist

for a weak entity set.

❑ However, it contains a partial key called as

a discriminator.
❑ Discriminator can identify a group of entities
from the entity set.

❑ Discriminator is represented by underlining

with a dashed line.
NOTE-
❑ The combination of discriminator and primary
key of the strong entity set makes it possible to
uniquely identify all entities of the weak entity
set.

❑ Thus, this combination serves as a primary key

for the weak entity set.
❑ Clearly, this primary key is not formed by the
weak entity set completely.
❑ A double rectangle is used for representing a
weak entity set.

❑ A double diamond symbol is used for

representing the relationship that exists
between the strong and weak entity sets and
this relationship is known as identifying
relationship.
❑ A double line is used for representing the
connection of the weak entity set with the
relationship set.

❑ Total participation always exists in the

identifying relationship.
Primary key of Apartment
= Primary key of Building + Its own
discriminator
= Building number + Door number

Total participation always exists in

the identifying relationship.
Important Note-
In ER diagram, weak entity set is always present in
total participation with the identifying relationship
set.
So, we always have the picture like shown
here-
 The Enhanced ER Model
❑ As the complexity of data increased in the
late 1980s, it became more and more
difficult to use the traditional ER Model for
database modelling.

❑ Hence some improvements or

enhancements were made to the existing
ER Model to make it able to handle the
complex applications better.
Hence, as part of the Enhanced ER Model,
along with other improvements, three new
concepts were added to the existing ER
Model, they were:

1.Generalization

2.Specialization

3.Aggregration
 Generalization
❑ Generalization is a bottom-up approach in
which two lower level entities combine to form
a higher level entity.

❑ In generalization, the higher level entity can also

combine with other lower level entities to make
further higher level entity.
❑ It's more like Superclass and Subclass system,
but the only difference is the approach, which is
bottom-up. Hence, entities are combined to
form a more generalised entity, in other words,
sub-classes are combined to form a super-class.
For example, Saving and Current account
types entities can be generalised and an entity
with name Account can be created, which
covers both.
 Specialization
❑ Specialization is opposite to Generalization.

❑ It is a top-down approach in which one

higher level entity can be broken down into
two lower level entity.

❑ In specialization, a higher level entity may

not have any lower-level entity sets, it's
possible.
 Aggregration
Aggregration is a process when relation
between two entities is treated as a single
entity.
❑ In the diagram above, the relationship
between Center and Course together, is
acting as an Entity, which is in relationship
with another entity Visitor.

❑ Now in real world, if a Visitor or a Student

visits a Coaching Center, he/she will never
enquire about the center only or just about
the course, rather he/she will ask enquire
about both.
 E-R diagram of College
management system
Problem Statement:
• A college contain many departments.
• Each department can offer any number of courses.
• Many instructor can work in a department.
• An instructor can work only in one department, for
each department there is a head.
• An instructor can be head of only one department.
• Each instructor can take any number of courses.
• A course can be taken by only one instructor.
• An student can enroll for any number of courses.
• Each course can have any number of students.
 Solution
Step 1 − Identifying the entity sets.

•Department
•Course
•Student
•Instructor
Step 2 − Identifying the attributes for the given
entities

•Department − the relevant attributes are

department_Name and location.

•Course − The relevant attributes are course_ID,

course Name, Duration.

•Instructor − The relevant attributes are

Instructor_ID, First_name, Last_name, Phone.

•Student − The relevant attributes are Student_ID,

First_name, Last_name, Phone.
Step 3 − Identifying the Key attributes

•“Department_Name” is the key attribute for

Department entity.

•“Course_ID” is the key attribute for Course

entity.

•“Instructor_ID” is the key attribute for the

Instructor entity.

•“Student_ID” is the key attribute for Student

entity.
Step 4 − Identifying the relationship between
entity sets

One department offer many courses but one

particular course can be offered by only one
department. Hence the relationship between
department and course is one to many.
•One department has many instructors but
one instructor belongs to one and only one
department, hence the relationship between
department and instructor is one to many.
•One Course can be enrolled by many students
and one student can enroll for many courses.
Hence the relationship between course and
student is many to many.
•One department has only one head and one
head can be the head of only one department.
Hence the relationship is one to one.
•One course is taught by only one instructor
but one instructor teaches many courses
hence the relationship between course and
instructor is many to one.
Step 5 − Complete ER model
Problem Statement:
The company database keep track of
company employees, departments and
projects.

▪The company is organized into departments.

Each department has a unique name, a
unique number and a particular employee
who manages the department, we keep track
of start date when that employee began
managing the department. A department
may have several locations.
•A department controls a number of projects,
each of which has a unique name, a unique
number and a single location.

•We store each employee name, social security

number, address, salary, sex(gender) and
birth date. An employee is assigned to one
department, but may work on several
projects, which are not necessarily controlled
by the same department. We keep track of the
current number of hours per week that an
employee works on each project.
•We want to keep track of the dependents of
each employee for insurance purposes. We
keep each dependents first name, sex, birth
date, and relationship to the employee.
Entities and their Attributes are

•Employee Entity : Attributes of Employee

Entity are Name, SSn , Address, sex, Birth date,
Address and Salary.
SSn is Primary Key for Employee Entity.

•Department Entity : Attributes of Department

Entity are D_no, Name and Location.

•D_no is Primary Key for Department Entity.

•Project Entity : Attributes of Project Entity are
P_No, P_Name and Location.

•P_No is Primary Key for Project Entity.

•Dependent Entity : Attributes of Dependent

Entity are Name, sex, B_date and relationship.
 Converting ER Diagrams to Tables-
➢ ER diagram is converted into the tables in
relational model.

➢ This is because relational models can be

easily implemented by RDBMS like MySQL ,
Oracle etc.
Tabular Representation of Strong entity
set:
➢ Attributes of the table will be the attributes
of the entity set.

➢ The primary key of the table will be the key

attribute of the entity set.
 Roll_no Name Sex

Schema : Student ( Roll_no , Name , Sex )

 COMPOSITE ATTRIBUTE
❑A entity set with any number of composite
attributes will require only one table in relational
model.

❑Create a separate attribute for each of the

composite attribute.

❑Example: An address is a composite attribute and

its components are street and city and house
number. The table generated would then contain
columns address-street, address-city and
address-house number there is no separate
column for address.
Example-

Roll_no First_name Last_name House_no Street City

Schema : Student ( Roll_no , First_name , Last_name

House_no , Street , City )
 Multivalued Attribute
➢An entity set with any number of multi
valued attributes will require two tables in
relational model.

➢One table will contain all the simple

attributes with the primary key.

➢Other table will contain the primary key

and all the multi valued attributes.
Roll_no City Roll_no Mobile_no
Translating Relationship Set into a Table-

A relationship set will require one table in

the relational model.
Attributes of the table are-
•Primary key attributes of the
participating entity sets
•Its own descriptive attributes if any.
Set of non-descriptive attributes will be
the primary key.
•
Example-

Emp_no Dept_id since

Schema : Works in ( Emp_no , Dept_id , since )

Relationship With Cardinality Ratio m:n

Here, three tables will be

required-
1.A ( a1 , a2 )
2.R ( a1 , b1 )
3.B ( b1 , b2 )
Here, two tables will be required-
1.A ( a1 , a2 )
2.BR ( a1 , b1 , b2 )

NOTE- Here, combined table will be drawn for the entity set
B and relationship set R.
 Relationship With Cardinality Ratio m:1

Here, two tables will be required-

1.AR ( a1 , a2 , b1 )
2.B ( b1 , b2 )

NOTE- Here, combined table will be drawn for the entity

set A and relationship set R.
Relationship With Cardinality Ratio 1:1

Here, two tables will be required. Either combine ‘R’ with

‘A’ or ‘B’

Way-01:
1.AR ( a1 , a2 , b1 )
2.B ( b1 , b2 )

Way-02:
1.A ( a1 , a2 )
2.BR ( a1 , b1 , b2 )
➢ For binary relationship with cardinality ration m : n ,
separate and individual tables will be drawn for
each entity set and relationship.

➢ For binary relationship with cardinality ratio either

m : 1 or 1 : n , always remember “many side will
consume the relationship” i.e. a combined table will
be drawn for many side entity set and relationship
set.

➢ For binary relationship with cardinality ratio 1 : 1 ,

two tables will be required. You can combine the
relationship set with any one of the entity sets.
Relationship With Cardinality Constraint
and Total Participation Constraint From
One Side-

Because cardinality ratio = 1 : n ,

so we will combine the entity
set B and relationship set R.
Then, two tables will be
required-
1.A ( a1 , a2 )
2.BR ( a1 , b1 , b2 )
Relationship With Cardinality Constraint
and Total Participation Constraint From
Both Sides-
➢ If there is a key constraint from both the sides of
an entity set with total participation, then that
binary relationship is represented using only
single table.

Here, Only one table is required.

•ARB ( a1 , a2 , b1 , b2 )
Tabular Representation of Weak entity
set:
➢Weak entity set always appears in
association with identifying relationship
with total participation constraint.

➢The weak entity set becomes the table

and all the attributes of weak entity and
primary key of strong entity to which this
weak entity is related becomes column of
the table.
Here, two tables will be
required-
1.A ( a1 , a2 )
2.BR ( a1 , b1 , b2 )
 Practice Problems
Find the minimum number of tables required
for the following ER diagram in relational
model-
Problem-01:
Solution-

Applying the rules, minimum 3 tables will

be required-
•MR1 (M1 , M2 , M3 , P1)
•P (P1 , P2)
•NR2 (P1 , N1 , N2)
Problem-02:
Solution-

Applying the rules, minimum 5 tables will

be required-
• BR1R4R5 (b1 , b2 , a1 , c1 , d1)
• A (a1 , a2)
• R2 (a1 , c1)
• CR3 (c1 , c2 , d1)
• D (d1 , d2)
Problem-03:
Solution-

Applying the rules that we have learnt,

minimum 6 tables will be required-

•Account (Ac_no , Balance , b_name)

•Branch (b_name , b_city , Assets)
•Loan (L_no , Amt , b_name)
•Borrower (C_name , L_no)
•Customer (C_name , C_street , C_city)
•Depositor (C_name , Ac_no)