Entity Relationship (ER) Model

 Conceptual modeling is very important phase in designing a DB

application
 High level conceptual data model
 Diagrammatic notations associated with ER model is called ER
diagram
 Main concepts – entity, attribute, relationship

Entity – Thing or any aspect in the real world

Attribute – Properties that further describes the entity
Example:

Types of attributes:
 Simple (atomic) – attributes that are not divisible.
o Example – mobile_no
Dr. P. Gayathri, Professor, SCOPE Page 1
  Composite – can be divided into smaller sub parts.
o Example – address – street_address, city, state, zip
o Forms hierarchy.
 Example – street_address – number, street,
apartment_number
o Value of composite attribute is the concatenation of values of
its constituent simple attributes

 Single-valued – have only one value for an entity.

o Example – place_of_birth
 Multi-valued – have set of values for an entity.
o Example – college_degree, e-mail, mobile_no
 Stored – takes values as input
o Example – name

Dr. P. Gayathri, Professor, SCOPE Page 2

  Derived – value is derived or calculated from one or set of
attributes.
o Example
 age – current_date and birth_date
 Number_of_employees – derived by counting the
number of employees related to that department

Note: Attributes can be:

 simple single-valued
 simple multi-valued
 composite single-valued
 composite multi-valued

Complex attribute:
 Nesting of composite and multi-valued attributes.
 Composite – have simple components – represented between
parenthesis and separating the components with commas
 Multivalued attribute – represented between { }
 Example:
o Assume that each person can have more than one residence
and each residence have single address and multiple phones.
o Let the attribute name be Address_phone

Dr. P. Gayathri, Professor, SCOPE Page 3

Null values for an attribute:
 not applicable and unknown category
 Sometimes, an entity may not have a applicable value for an
attribute
 In such cases, NULL can be used
 Example – apartment_number – applicable only for houses in
apartment buildings. Not for the independent houses.
 NULL can also be used, if we do not know the value
 Unknown category – 2 cases
o Attribute value exist but value is missing – Example: height
o Not known whether attribute value exist – Example:
home_phone

Entity type (intension or schema) – entity name with set of attributes

Entity set (extension) – Collection of all entities with the values of their
attributes at any point of time.

Dr. P. Gayathri, Professor, SCOPE Page 4

Key attributes of an entity type:
 Key or uniqueness constraint on attributes – important constraint
on the entities of an entity type
 An attribute that uniquely identifies an entity in the entity set is
called key attribute
 The value of key attribute can be used to identity each entity
uniquely
 Example – reg_no for student entity, emp_id for employee entity

Note:
 Sometimes, several attributes together form a key – combinations
of attribute values are distinct for each entity

Dr. P. Gayathri, Professor, SCOPE Page 5

  Example: car entity – vehicle_id and registration attribute.
Registration is a composite attribute formed from two simple
attributes
 Key – minimal
 Refer the figure given below for notations – Entity, attribute,
multi-valued, composite.
 Derived (not there in the figure. Notation – dashed ellipse)

Value sets (domains) of attributes:

 Set of values that can be assigned to an attribute of an entity
 Example
o name – set of strings of alphabetic characters separated by
blank characters
o emp_age – between 20 and 60

Dr. P. Gayathri, Professor, SCOPE Page 6

Weak entity type:
 Entity type without key attribute

Example Company DB application:

 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 the 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’s 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 also keep track of the direct supervisor of each
employee (who is another employee).
 We want to keep track of the dependents of each employee for
insurance purposes. We keep each dependent’s first name, sex,
birth date, and relationship to the employee.

Dr. P. Gayathri, Professor, SCOPE Page 7

Initial conceptual design of company DB:

We have not represented the following facts given in the scenario:

 An employee can work on several projects
 Number of hours per week an employee works on each project

Options:
 Can be represented in Employee entity using multivalued attribute
called works_on with project and hours as simple attributes

Dr. P. Gayathri, Professor, SCOPE Page 8

  Can be represented in Project entity using multivalued attribute
called workers with employee and hours as simple attributes

We choose first option. Refer below figure for final initial schema of
Employee entity.

Note: Refer corresponding figure

 Department
 Location – multivalued (given in scenario)
 Key attribute – name and number (given)
 Project
 Key attribute - name and number (given)
 Employee
 Composite attribute – Name (not specified in the scenario but
based on the consultation with user, designer can decide)
 Address – can also be a composite attribute if required.
 Key attribute – Ssn
Dr. P. Gayathri, Professor, SCOPE Page 9
Relationship:
 Association between entity types
 Initial conceptual design of company DB has several implicit
relationships among various entity types.
 Example:
o manager attribute of Department refers to employee who
manages the department

o The attribute Controlling_department of Project refers to the

department that controls the project.
o The attribute supervisor of employee refers to another
employee
o The attribute department of Employee refers to the
department for which the employee works. And so on…..
 In ER model, these references should not be represented as
attributes but as relationships.
 Relationships – represented as diamond shaped box in ER model

Dr. P. Gayathri, Professor, SCOPE Page 10

Degree of relationship type:
 Number of participating entity types
 Example – works_for relationship in below figure is of degree 2

 Binary relationship – degree 2 – commonly used

 Ternary relationship – degree 3
 Relationship can be of any degree
 Example – Ternary

Dr. P. Gayathri, Professor, SCOPE Page 11

Role names and Recursive relationships:

 In the above figure, Employee plays the role of employee or worker

and Department plays the role of department or employer
 Roles not necessary – when participating entity types are distinct in
the relationship type.
 Because participating entity type name can be used as role name.
 Sometimes, same entity type may participate more than once in a
relationship type in different roles.
 In such cases, role name is essential
 Such relationships are called recursive relationships.
 Example: 1 – supervisor role and 2 – subordinate role
 Each instance in Supervision relationship type associates two
employee entities
 One plays the role of supervisor and other play the role of
supervisee (subordinate)
 e1 supervises e2 and e3; e5 supervises e1 and e4

Dr. P. Gayathri, Professor, SCOPE Page 12

Constraints on relationship types:
 2 types – cardinality ratio and participation
Cardinality ratios for binary relationship:
 In the figure given below, works_for is a binary relationship type
 Cardinality ratio of this relationship is 1:N –
Department:Employee – Each department can be related to any
number of employees but an employee can be related to only one
department.

Dr. P. Gayathri, Professor, SCOPE Page 13

Types of binary relationships:
1. 1:1 – one to one
2. 1:N – one to many – Example – Above figure –
Department:Employee
3. N:1 – many to one – Example – Above figure –
Employee:Department
4. M:N – many to many
Example – 1:1

Example – M:N

Dr. P. Gayathri, Professor, SCOPE Page 14

Note:
 Cardinality ratios for binary relationships are represented in ER
diagram by displaying 1, M, N on the diamond box for
relationship.

Participation constraints:
 Specifies whether existence of an entity in the entity set depends
on its relationship to another entity via the relationship type
 Sometimes, called as minimum cardinality constraint
 2 types – Total (existence dependency) and Partial

Example – Total:
 Every entity in the Employee entity set is related to Department via
works_for relationship type
 Participation of employee in works_for relationship is total
 In ER diagram, total participation is represented as double line
between entity type and relationship

Dr. P. Gayathri, Professor, SCOPE Page 15

Example – Partial:
 We do not expect every employee entity to manage a department
 So an entity may or may not participate in the relationship type but
still it exists.
 In ER diagram, partial participation is represented as single line
between entity type and relationship.

Structural constraints:
 Cardinality ratio and participation constraint taken together is
called as structural constraints of relationship type.

Attributes of relationship types:

 Relationship types can also have attributes like entity types

Dr. P. Gayathri, Professor, SCOPE Page 16

  Example:
o To know about how many number of hours an employee
works on a particular project, we can add hours attribute for
works_on relationship type
o Start_date attribute can be include for manages relationship
type to known about the date on which manager started
managing the department

Dr. P. Gayathri, Professor, SCOPE Page 17

Note:
 Attributes of 1:1 relationship type can be migrated to one of the
participating entity types.
 Example – the start_date attribute for manages relationship can be
an attribute of either employee or department entity type because
manages is a 1:1 relationship type

 For 1:N or N:1 relationship type, relationship attribute can be

migrated to the entity type on the N-side of the relationship
 Example – N:1 – if works_for relationship also has an attribute
start_date that indicates when an employee started working for a
department, this attribute can be added as attribute to employee
entity type
 In both 1:1 and 1:N or N:1 relationship types, the decision about
where to place the relationship attributes is made by schema
designer.

Dr. P. Gayathri, Professor, SCOPE Page 18

  For M:N relationship type, relationship attributes must be specified
as relationship attributes.
 Cannot be migrated to entity types as attributes may be determined
only by the combination of participating entities.
 Example – M:N – hours attribute for works_on relationship is
determined by the employee and project combination.

Dr. P. Gayathri, Professor, SCOPE Page 19

Weak entity types:
 Entity types that do not have key attributes of their own
 Entity types with key attribute – strong entity types
 Entities belonging to weak entity type are identified by relating
them to entities of another entity type in combination with one
of their attribute values.
 We call this another entity type as identifying or owner entity
type
 Relationship type that relates weak entity to its owner entity is
called identifying relationship of weak entity
 Weak entity always has total participation constraint (existence
dependency) with the identifying relationship
 Example:
o Entity type dependent is a weak entity type as it does not
have key to uniquely identity the entities
o Two dependents of two distinct employees may have same
values for name, birth_date, sex, relationship
o But they are distinct entities
o They can be identified as distinct entities only after relating
them with the employee entity.
 It is not that every total participation results in weak entity type
 Example:

Dr. P. Gayathri, Professor, SCOPE Page 20

 o Employee entity cannot exist unless it is related to
department entity.
o So it has total participation with department entity.
o But it is not a weak entity as it has its own key i.e.
emp_number.
 Weak entity has partial key – set of attributes that can uniquely
identify weak entities related to the same owner entity.
 Assume that no two dependents of same employee have same
name. Then the name attribute of dependent can be used as partial
key.
 In ER model, double lined box is used to represent weak entity and
double lined diamond for identifying relationship
 For partial key dotted underline.

Refined ER design for Company DB:

 Relationship types in our design
1. Manages
 1:1 between Employee and Department
 Employee participation is partial
 Department participation is total
 Attribute start_date is assigned to relationship type
2. Works_for
 1:N between department and employee

Dr. P. Gayathri, Professor, SCOPE Page 21

  Both are total participation
3. Controls
 1:N between department and project
 Project – total
 Department - partial
4. Supervision
1:N between employee and employee
Both – partial
5. Works_on
 M:N between employee and project
 Both – total
 Attribute hours is assigned to relationship type
6. Dependents_of
 1:N between employee and dependent
 Employee – partial
 Dependent – total
 Attributes removed after specifying the above relationship types.
o Manager and manager_start_date from department
o Controlling_department from project
o Department, supervisor, works_on from employee
o Employee from dependent
 Thus redundancies are removed

Dr. P. Gayathri, Professor, SCOPE Page 22

Dr. P. Gayathri, Professor, SCOPE Page 23
Alternative ER notation for structural constraints:
 (min,max) notation where 0≤min≤max and max≥1
 Meaning of numbers – each entity e in E must participate in atleast
min and atmost max relationship instances in R at any point of
time.
 Min = 0 means partial and Min > 0 means total participation
 Use either cardinality ratio / single line / double line notation or
(min,max) notation

Dr. P. Gayathri, Professor, SCOPE Page 24

Summary of notations:

Dr. P. Gayathri, Professor, SCOPE Page 25