Entity Relationship Model

 ER model Introduced by Chen in 1976

 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.
 It develops a conceptual design for the database. It also develops a very simple
and easy to design view of data.
 In ER modeling, the database structure is portrayed as a diagram called an
entity-relationship diagram.
Database design
• Requirement analysis
• Conceptual database design
• Logical database design
• Schema refinement
• Physical database design
• Applications and security design
Database design steps
• Requirement analysis
• What Data to be stored
• Applications to be built
• Operations (most frequent) subject to performance requirement
• Conceptual DB design
• Description of the data (including constraints)
• High level modeling tool such as ER
• Logical DB design
• Choose DBMS to implement
• Convert conceptual DB design into database schema
• Schema refinement (normalization)
• Physical DB design
• Analyze the workload
• Refine DB design to meet performance criteria (focus on Indexing and clustering)

• Security design
• Provides authentication
Steps in Designing an Entity-Relationship Schema

1. Identify entity types (entity type vs. attribute)

2. Identify relationship types
3. Identify and associate attributes with entity and relationship types
4. Determine attribute domains
5. Determine primary key attributes for entity types
6. Associate (refined) cardinality ratio(s) with relationship types
7. Design generalization/specialization hierarchies including
constraints.
 Example 1
Build an ER Diagram for the following information:
• Students
• Have an ID, Name, Login, Age, GPA
• Courses
• Have an ID, Name, Credit Hours
• Students enroll in courses
• Receive a grade
 Example 1

Name Login Age Id Name Credit

Id Gpa
Students Courses

Enrolled_In

Grade
ER model example
ER diagram for hospital management system
ER MODEL
Entity
• An entity is an object in real world which is distinguishable from other
• Entities are represented in the ER Diagram by a rectangular box.
Entity set
An entity set is a set of same type of entities.
Student, employee
Entity Sets-
Strong entity set
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.
Strong entity set
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.
Weak entity set
Strong entity set vs weak entity set
Strong entity set Weak entity set

A single rectangle is used for the representation of A double rectangle is used for the representation
a strong entity set. of a weak entity set.

It contains sufficient attributes to form its primary It does not contain sufficient attributes to form its
key. primary key.

A diamond symbol is used for the representation A double diamond symbol is used for the
of the relationship that exists between the two representation of the identifying relationship that
strong entity sets. exists between the strong and weak entity set.

A single line is used for the representation of the A double line is used for the representation of the
connection between the strong entity set and the connection between the weak entity set and the
relationship. relationship set.

Total participation may or may not exist in the Total participation always exists in the identifying
relationship. relationship.
Attribute
 Attribute is a characteristic/property of an entity.
 Attributes are represented in the ER Diagram by a oval or ellipse.
Attributes
Attributes
Key attribute
The key attribute is used to represent the main characteristics of an
entity. It represents a primary key. The key attribute is represented by
an ellipse with the text underlined.
Composite attributes
• Composite attributes can be divided into smaller subparts, which represent more basic attributes with
independent meanings.
Simple attributes
• Attributes that are not divisible are called simple or atomic attributes.
Single valued attributes, multivalued attributes
 Most attributes have a single value for a particular entity such attributes are called single-valued attribute.

 An attribute which allows multiple values is a multivalued attribute.

Derived attributes, stored attributes
 An attribute which can be derived from other attributes is known as derived attribute.
 Age (can be derived from DOB).
 An attribute for which its value can be directly stored onto the database is a Stored Attribute.
Entity and attributes
Relationship
Relationship defines an association among several entities.
A relationship set is a set of same type of relationships.
 relationship type is represented by a diamond and connecting the entities with
lines.
Relationship set
Strong relationship
• A strong relationship exists between two strong entity sets.
• It is represented using a diamond symbol.

• A weak or identifying relationship exists between the strong and weak

entity set.
• It is represented using a double diamond symbol.
Degree of a relationship set:

 The number of different entity sets participating in a relationship set is called as degree of a relationship set.

Unary relationship: When there is only ONE entity set participating in a relation, the relationship
is called as unary relationship.

Binary relationship:When there are TWO entity sets participating in a relation, the relationship is
called as binary relationship.

Ternary relationship:When there are THREE entity sets participating in a relation, the relationship
is called as binary relationship
Unary relationship
Binary relationship
Ternary relationship
Participation constraints
Total participation constraint
It specifies that each entity in the entity set must compulsorily
participate in at least one relationship instance in that relationship set
Total participation is represented using a double line between the
entity set and relationship set.

 
Partial participation
It specifies that each entity in the entity set may or may not participate
in the relationship instance in that relationship set.
 It is also called as optional participation.
Partial participation is represented using a single line between the
entity set and relationship set.
Cardinality/mapping cardinality constraints
 The number of times an entity of an entity set participates in a relationship set is known as cardinality.
One to one relationship
An entity in set A can be associated with at most one entity in set B.
An entity in set B can be associated with at most one entity in set A.
 

One student can enroll in at most one course.

One course can be enrolled by at most one student.
One to one relationship
One-to-Many Cardinality
An entity in set A can be associated with any number (zero or more)
of entities in set B.
An entity in set B can be associated with at most one entity in set A.

One student can enroll in any number (zero or more) of courses.

One course can be enrolled by at most one student.
One to many relationship
Many-to-One Cardinality
An entity in set A can be associated with at most one entity in set B.
An entity in set B can be associated with any number (zero or more)
of entities in set A.

One student can enroll in at most one course.

One course can be enrolled by any number (zero or more) of students. 
Many to one relationship
 Many-to-Many Cardinality

An entity in set A can be associated with any number (zero or more) of entities in set B.
An entity in set B can be associated with any number (zero or more) of entities in set A.

One student can enroll in any number (zero or more) of courses.

One course can be enrolled by any number (zero or more) of students.
Many to many relationship
 Converting ER Diagrams to relational model
 .(converting er diagram into tables(attributes becomes column name for the table)

Roll_no First_name Last_name House_no Street City

 
 
 
 
Additional features of ER Model
• Key constraints
• Participation constraints
• Weak entities
• Class hierarchies(generalization, specialization)
• Aggregation
Key Constraints name
since
dname
ssn lot did budget

• Consider Works_In: An
employee can work in many Employees Manages Departments
departments; a dept can have Key Constraint
many employees.
• In contrast, each dept has at
most one manager, according
to the key constraint on
Manages.

1-to-1 Many-to 1 1-to-Many Many-to-Many

Participation constraints
Total participation constraint
It specifies that each entity in the entity set must compulsorily
participate in at least one relationship instance in that relationship set
Total participation is represented using a double line between the
entity set and relationship set.

 
Partial participation
It specifies that each entity in the entity set may or may not participate
in the relationship instance in that relationship set.
 It is also called as optional participation.
Partial participation is represented using a single line between the
entity set and relationship set.
 Participation Constraints
• Does every department have a manager?
• If so, this is a participation constraint: the participation of Departments in Manages is
said to be total (vs. partial).
• Every did value in Departments table must appear in a row of the Manages table (with
a non-null ssn value!)
since
name dname
ssn lot did budget

Employees Manages Departments

Partial Total w/key
constraint
Total
Works_In
Total

since
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.
 Weak Entities
A weak entity can be identified uniquely only by considering the primary key of
another (owner) entity.
Owner entity set and weak entity set must participate in a one-to-many relationship set (1
owner, many weak entities).
Weak entity set must have total participation in this identifying relationship set.

name
cost pname age
ssn lot

Primary Key
for weak entity
Employees Policy Dependents

Identifying Relationship Weak Entity

 name
ssn lot

class Hierarchies(IS A hierarchy) Employees

 As in C++, or other PLs, attributes are inherited. hourly_wages hours_worked

ISA
contractid

 Ifwe declare A ISA B, every A entity is also considered to be a B

Hourly_Emps Contract_Emps
entity.

• Overlap constraints: Can Joe be an Hourly_Emps as well as a Contract_Emps entity?

(Allowed/disallowed)
• Covering constraints: Does every Employees entity also have to be an Hourly_Emps or a
Contract_Emps entity? (Yes/no)
• Reasons for using ISA:
• To add descriptive attributes specific to a subclass.
• To identify entitities that participate in a relationship.
Generalization
Generalization is the process of extracting common properties from a set of entities and create a generalized entity from it. It is a bottom-up
approach in which two or more entities can be generalized to a higher level entity if they have some attributes in common.
Specialization
 specialization, an entity is divided into sub-entities based on their characteristics. It is a top-down approach
where higher level entity is specialized into two or more lower level entities
Aggregation

• An ER diagram is not capable of representing relationship between an entity and a relationship which may be
required in some scenarios. In those cases, a relationship with its corresponding entities is aggregated into a
higher level entity
• Aggregation is an abstraction through which relationships are treated as higher level entities.
 name
ssn lot

Aggregation Employees

Used when we have to model a

relationship involving (entitity Monitors until
sets and) a relationship set.
 Aggregation allows us to treat a Aggregation
relationship set as an entity set
started_on
for purposes of participation in dname
(other) relationships. pid pbudget did budget
 Monitors mapped to table like any
other relationship set. Projects Sponsors Departments

Aggregation vs. ternary relationship:

 Monitors is a distinct relationship,
 with a descriptive attribute.
 Also, can say that each sponsorship
 is monitored by at most one employee.
keys
Super key
• A super key is a set of attributes that can identify each tuple uniquely
in the given relation.
• A super key is not restricted to have any specific number of attributes.
• Thus, a super key may consist of any number of attributes.
Super key
• Example
• Consider the following Student schema
• Student ( roll , name , gender, age , address , class , section )

• Given below are the examples of super keys since each set can
uniquely identify each student in the Student table-
• ( roll , name , gender, age , address , class , section )
• ( class , section , roll )
• (class , section , roll , gender)
Candidate key
A set of minimal attributes that can identify each tuple uniquely in the
given relation is called as a candidate key.
• 
• Consider the following Student schema-
• Student ( roll , name , gender, age , address , class , section )

• 
• Given below are the examples of candidate keys since each set consists of
minimal attributes required to identify each student uniquely in the
Student table-
• ( class , section , roll )
Candidate key
• All the attributes in a candidate key are sufficient as well as necessary to
identify each tuple uniquely.
• Removing any attribute from the candidate key fails in identifying each tuple
uniquely.
• The value of candidate key must always be unique.
• The value of candidate key can never be NULL.
• It is possible to have multiple candidate keys in a relation.
• Those attributes which appears in some candidate key are called as prime
attributes.
• 
Primary key
• It is the minimal of candidate key.
• The value of primary key can never be NULL.
• The value of primary key must always be unique.
• The values of primary key can never be changed i.e. no updation is
possible.
• The value of primary key must be assigned when inserting a record.
• A relation is allowed to have only one primary key.
keys
Alternate key
• A candidate key not selected as a primary key is called
alternate or secondary key.
Foreign key
• It references the primary key in another table.
Foreign key
An attribute ‘X’ is called as a foreign key to some other attribute ‘Y’
when its values are dependent on the values of attribute ‘Y’.
The attribute ‘X’ can assume only those values which are assumed by
the attribute ‘Y’.
Here, the relation in which attribute ‘Y’ is present is called as
the referenced relation.
The relation in which attribute ‘X’ is present is called as
the referencing relation.
The attribute ‘Y’ might be present in the same table or in some other
table.
Foreign key
• Foreign key references the primary key of the table.
• Foreign key can take only those values which are present in the primary key
of the referenced relation.
• Foreign key may have a name other than that of a primary key.
• Foreign key can take the NULL value.
• There is no restriction on a foreign key to be unique.
• In fact, foreign key is not unique most of the time.
• Referenced relation may also be called as the master table or primary table.
• Referencing relation may also be called as the foreign table.
Partial key

Partial key is a key using which all the records of the table can not be
identified uniquely.
However, a bunch of related tuples can be selected from the table
using the partial key.
Partial key
Department ( Emp_no , Dependent_name , Relation )
 
 
Here, using partial key Emp_no, we can not identify a tuple uniquely but we can select a bunch of tuples from the table.
 

Emp_no Dependent_name Relation

E1 Suman Mother

E1 Ajay Father

E2 Vijay Father
E2 Ankush Son
Composite Key
 

• A primary key comprising of multiple attributes and not just a single

attribute is called as a composite key.
Unique Key
 

• It is unique for all the records of the table.

• Once assigned, its value can not be changed i.e. it is non-updatable.
• It may have a NULL value.
• Example: Aadhar number
Surrogate Key

It is unique for all the records of the table.

It is updatable.
It can not be NULL i.e. it must have some value.
Example: mobile number
Steps in Designing an Entity-Relationship Schema

1. Identify entity types (entity type vs. attribute)

2. Identify relationship types
3. Identify and associate attributes with entity and relationship types
4. Determine attribute domains
5. Determine primary key attributes for entity types
6. Associate (refined) cardinality ratio(s) with relationship types
7. Design generalization/specialization hierarchies including
constraints.
ER diagram for hospital managment system
ER diagram
ER diagram
ER model
Conceptual database design with ER
model
Conceptual design(ER Model is used at this stage.)
What are the entities and relationships in the enterprise
What information about these entities and relationships should we store in
the database
What are the integrity constraints or business rules that hold
A database `schema’ in the ER Model can be represented pictorially (ER
diagrams).
Can map an ER diagram into a relational schema.
Conceptual database design with ER model
Design choices:
Should a concept be modeled as an entity or an attribute?
Should a concept be modeled as an entity or a relationship?
Identifying relationships: Binary or ternary? Aggregation?
Entity vs. Attribute
• Should address be an attribute of Employees or an entity (connected
to Employees by a relationship)?
• Depends upon the use we want to make of address information, and
the semantics of the data:
• If we have several addresses per employee, address must be an entity
(since attributes cannot be set-valued).
• If the structure (city, street, etc.) is important, e.g., we want to retrieve
employees in a given city, address must be modeled as an entity (since
attribute values are atomic).
 Entity vs. Attribute
from to
name dname
• Works_In2 does not allow an ssn lot did budget
employee to work in a department for
two or more periods. Employees Works_In2 Departments

• Similar to the problem of wanting to

record several addresses for an
employee: we want to record several
values of the descriptive attributes for
each instance of this relationship. name dname
ssn lot did budget

Employees Works_In3 Departments

from Duration to
 Binary vs. Ternary Relationships name
ssn lot pname age
• If each policy is owned by Employees Dependents
Covers
just 1 employee:
• Key constraint on Policies Bad design
Policies
would mean policy can only
cover 1 dependent! policyid cost

name pname age

ssn lot
Dependents
Employees

Purchaser
Beneficiary

Better design
Policies

policyid cost