E-R Diagrams

E- R Diagrams is the process of describing the data,

relationships between the data, and the constraints
on the data. It is a detailed, logical representation of
the entities, associations and data elements for an
organization or business

•Proposed by 1976 by Peter Chen

•Represents conceptual level of database
•Represents entities and their relationships
 E-R Diagrams (Entity)
• Entity- An entity is a “object” or “Thing ”
about which organization wants to store data.
Entity are of two types.
– Concrete entity- which can be feel /observed
– Abstract entity- which can not be feel but exists in
the system
• Entity set – Set of similar entities e.g. cars,
students
– An entity set contains many similar entities
 E-R Diagrams (Entity)
Attributes
• Extension of Entity Set- Extension
Emp no Name
Entity
Set 117 Aaa
113 Bbb
110 ccc

• Attributes: common properties of the entities

in a entity sets
• Relationship – specify the relations among
entities from two or more entity sets
E-R Diagrams (Entity)
 E-R Diagram (terminology)

Attribute

Cardinality = 2
tuple/relational
instance
SID Name Major GPA
1234 John CS 2.8
5678 Mary EE 3.6

4 Degree

A Schema / Relation
 E-R Diagrams(Attributes)
Attributes
Attributes are the descriptive properties possessed by
entities. For each attribute there is a set of permitted
values called “Domain or value set”
• Attribute types:
– Simple
– Composite
– Single values
– Multiple Valued
– Null Attribute
– Derived
– Complex
 E-R Diagram(Attributes)
• Simple Attribute
– Attributes that can not be divided into subparts.
• Composite attributes
– Attributes that can be divided into subparts like
name (first name, Middle Name, Last name )
• Null Attribute
– Null is used when an entity does not have a value
for an attribute. Null means nothing, not even
zero. value is unknown or not decided.
 E-R Diagram (Attributes)
• Derived Attributes
– Attributes whose value can be derived from other
attributes such as age (present year-DOB) etc
• Complex Attributes
– When composite and multi-valued attributes are nested in
some arbitrary way then such attributes are called complex
attributes. In nesting , we enclose composite attributes
within () and multi-valued attributes within {} e.g
– {AddressPhone ({phone (areacode, phoneNumber), address
(streetName, State)}.
• Key Attributes
– It is an attribute or a combination of more than one
attribute that uniquely identifies an entity in entity set.
 E-R Diagram
• Weak Entity
– Entity may not have any key. Such entities are known as
weak entities . They are associated with the owner entities.
• Identifying Relationship
– Relationship of weak entity with parent entity
• Value set or domain
– Each attribute is associated with some value that the
attribute take.
– Mathematically domain is represented by A: E ->P(V)
where A is attribute of entity E which take the value from
power set of V
 E-R Diagram
• Relationship
– Relationship is association among several entities.
Whenever an attribute of one entity refers to
another entity that means there is some
relationship exists. These references are not
considered as attributes but as relationships.
– Mathematically relations can be viewed as 1)
predicate 2) set of ordered pairs. But in RDBMS
relations are modelled as set of ordered pairs
 E-R Diagram
• Degree of relationship
– Is the number of participating entities. It may be
one , two or more than two i.e. unary, binary ,
ternary or quaternary.
• Role Name
– It represents the role that entity play in a
relationship instance.
– Without role name we cannot identify which
entity doing what in a relationship.
 E-R Diagram
• Cardinality ratio
– Specifies the maximum number of relationship
instances that an entity can participate in
– Cardinality ratio can be 1:1, 1:N,N:M
• Recursive relationship
– If same entity type participate more than once in a
relationship with different roles, such relationship
is called recursive
 E-R Diagram (Structural Constraints)
• Participation Constraint/Existential
Dependencies/total Participation/Structural
Constraints
– It States whether an entity participate fully in
relationship set or partially. This constraint specifies
the minimum number of relationship instances that
each entity can participate.
– e.g suppose (e1,e2,e3,e4) is a set of employee and
(d1,d2,d3,d4) is a set of department then total
participation means that each employee must work
for some department .
E-R Diagram(Structural Constraints)
E1 D1
E2 D2
E3 D3
E4 d4

Work_for relationship

It means that employee entity exists only if it participate in at least

on “work_for” relationship.
 E-R Diagram (Keys)
• Properties of keys
– Uniqueness : attribute has unique value in the
relation for each tuple.
– Validity: No attribute in a key will be null.
 E-R Diagram (Keys)
• Super Key
– Is a set of one or more keys that when taken
collectively , allows us to identify uniquely an entity in
entity set.
– It functionally determines all other attributes
– If suppose {title,year ,name } is a key then any super
set of these attributes is a superkey. Such as {title,
year, address, phone},
{title,year ,name ,sal,designation}
– Key has to be minimal
• If {empno} is a key then {empno, empname},
{empno,empname, address} are all superkeys
 E-R Diagram (Keys)
• Candidate key
– They are the subset of super keys
– They may be more than one
– They are the candidate for primary key
– Designers are interested in a super key for which no
proper subset is a super key itself.
• e.g. If {a} uniquely represents an entity and {b,c} also
represents an entity then we can say that {a} or {b,c} can
act as candidate keys. But combination {a,b} can also
uniquely represents an entity, but according to the
definition of candidate key no proper subset should be
super key and here {a} which is an one element of proper
subset of {a,b} and is a super key so we can not take {a} as
candidate key.
– Proper subset of {a,b,c} is {{ab},{bc},{ca}, a,b,c}.
 E-R Diagram(Keys)
• Alternate Key
– Among several keys we select one as primary key
and rest of keys are alternate keys
• Primary key
– Is a candidate key chosen by designer with the
constraint that it must uniquely identify an entity
in an entity set.
– Value of primary key must not be duplicate
– Value of primary key can not be null.
 E-R Diagram (Keys)
• Prime attributes
– Prime attribute ate the attributes that are the member
of candidate key. e.g. Suppose {a,b,c} is a candidate
key then A,B,C are prime attributes
– Rest of attributes that are not prime are called non-
prime attributes
• Abstraction
– Is a simplification mechanism used to hide superfluous
details of a set of objects.
– Abstractions helps to concentrate on properties that
are of interest to the application
 E-R Diagram( Symbols)
• (Composite Attributes)
Attributes
• {Multi-valued Attributes}
•
Entity Role Role

•
Relations
hip 1 N
Total
Participation

Partial Participation
Multi-valued attribute
 E-R Diagram( Symbols)
Weak Entities

key
Composite Partial Key
Attributes --------------

Identifying Relationship
Identifying relationships exist when the primary key
of the parent entity is included in the primary
key of the child entity.
E-R Diagram( Symbols)

Total Participation
 E-R Diagram( Symbols)
One or more

Zero or more

One and only one

Zero or one

More One
 E-R Diagram( Steps)
• Problem
– A company is organized into departments , each
department has a unique name , unique number
and a particular employee who manages the
department. Department has several locations and
we keep track of the startdate when that
employee began managing the department.
– A department controls a number of projects . Each
of which has a unique name, unique number and a
single location.
– We store each employee’s name, employee
number, address, salary, sex, and date of birth.
 E-R Diagram( Steps)
– 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 number of hours per week that
an employee work on each project , we also keep
track of the direct supervisor of each employee.
– We keep track of the dependent of each employee
for insurance purpose and store/ manage
dependent first name, sex, DOB and relationship
to the employee
 E-R Diagram( Steps)
• Step-1
– Identify the entity and their attributes
– Identify multivalued /composite /complex attributes.
– e.g. In above problem following are entities with
attributes Multi-valued attribute
• Department : name, number, {locations}, manager, startdate
• Project: name, number, location, controlling department.
• Employee: name (FN, MN, LN), eno, sex, address, salary,
Composite Attribute Complex attribute
DOB,dept, supervisor, {work-on(project,hours)}
 E-R Diagram( Steps)
• Step-2
– Identify the relationship. Rule is: If an attribute of one entity refers to another
entity , some relationship exists. In E-R diagram references should not be
represented as attribute but as relationship. e.g.
 E-R Diagram( Steps)
• Step-3
– Draw relationship matrix
entity1 entity2
Entity 1:M
1
entity2 M:N M:1
• Step-4
– Decide the degree of relationship. i.e number of
participating entities.
– Convert higher degree to lower either binary or
ternary
 E-R Diagram( Steps)
• Step-5: Relationship as an attribute
– Here we decide whether we need separate
relationship (table) with attribute or can we
represent the relationship as an attribute.
• Step-6: Role name and recursive relationship
– Identity the role of each entity type that
participate in a relationship. Some entities
participate more than once in a relationship with
different roles
 E-R Diagram( Steps)
• Step-7: Cardinality Ratio
– Specify maximum number of relationship instances that an
entity can participate in.
• Step-8: structural constraints (participation
constraint/existential dependencies/minimal
cardinality constraint/total participation
– Here we decide whether the existence of an entity depends
on its being related to another entity via the relationship
type
– e.g. If company policy says that the every employee must
work for the department, then the employee entity exists
only if it participates in at least one work_for relationship
instance.
 E-R Diagram( Steps)
• Step-9
– Decide whether attributes of relationship should
merged with participating entities or not
– Rules
• For 1:1 relationship type, attribute can be migrated to one
of the participating entity type.
• For 1:N relationship type, attribute of a relationship can be
migrated to the entity type of N-side of the relationship
• For M:N relationship type, attributes of relationship can not
be migrated to any of participating entity because these
attributes determined by the combination of participating
entities in a relationship instance and not by single entity.
 E-R Diagram( Steps)
• Step-10
– Identify weak entities, partial keys, owner entity
and identifying relationship of weak entity. They
sometime are represented by complex attributes.
• Step-11
– After specifying the relationships, we remove the
attribute, that have been refined into relationship
from all entity type to have the least possible
redundancy at conceptual level.
Figure 3.2 ER schema diagram for the company database
 E-R Diagram (Advantages)
• Conceptually it is very simple – Making the ER Diagram is a very
easy process. You just know about the notations about various
types of entities, their attributes and the relationships between
these entities.
• Better visual representation – The E-R model gives graphical and
diagrammatic representation of various entities, their attributes
and relationships between entities. So, It helps in the clear
understanding of the data structure and in minimizing redundancy
and other problems.
• Effective Communication Tool – It is an effective communication
tool among users, domain experts and database designers.
• It is highly integrated with relational model, so converting ER
Diagrams to tables is very simple.
• Easy conversion to any Data Model – Conversion of ER Diagram to
any other data model like network model, hierarchical model and
the relational model is very easy.
 E-R Diagram (limitations)
• Limited Constraints and Specifications
• Loss of Information Content – Example – FAN Trap,
CHASM Trap (may be)
• Limited Relationship Representation – (only Binary
Relationship)
• No industry standard for notation – i.e. there is no
industry standard notation for developing an E-R
diagram.
• Popular for high-level design – The E-R data model is
especially popular for high level design.
• No representation of data manipulation
 E-R Diagram :Problems
• Fan Trap (Misinterpretation of relationship):
– A fan trap may exist where two or more one-to-
many (1:N) relationship fan out from the same
entity.
– Fan trap is associated with the misinterpretation
of correct relationship among entities.
 E-R Diagram :Problems
– In this model a branch has several sales people. A
branch also has several customers. But the above
data model says nothing about which sales person
is responsible for which customer.
– We have to Join the three tables and that will
increase the number of records
– Solution is to reconstruct the E-R diagram as
 E-R Diagram :Problems
if a customer is assigned to a branch, but has not
yet bought anything? This question takes us to
the next trap.
• Chasm Trap (nonexistence of pathway
between certain entities):
– Where a model suggests the existence of a
relationship between entity types, but pathway
does1 not exist between
1
certain entity
occurrences”
 E-R Diagram :Problems
• A chasm trap can be more difficult to spot. The
above data model (Branches - Sales people -
Customers) may in fact contain a chasm trap.
• The chasm trap appears only if there is missing
data in the middle table,

e.g. if you have a customer who belongs to a branch

but has not yet been assigned a sales person. Then
the link between the customer and the branch will
be broken and it will not be possible to see to which
branch the customer belongs.
 E-R Diagram :Problems

if you want this link, you can create it by adding

dummy records labelled 'No sales person' to
the Sales people table – one record per
branch – and link unassigned customers to
these
 EER (Generalization & Specialization)
• Subclass and Superclass
– Subclass and Superclass relationship leads the
concept of Inheritance (Specialization).
 Extended E-R Diagram
• Specialization (is-a) It is a top-down approach
in which one higher level entity can be broken
down into two lower level entity
– Membership to the subclass may be
• Condition defined: whether entity satisfy some
condition e.g account_Type=“saving”
– User Defined
• Constraint defined by users
 Extended E-R Diagram
– Disjoint d
• Requires entity belong to only one lower level entity set
– Overlapping O
• Entity may belong to more than one lower-level entity
set.
– Completeness constraint
• Total G/S : each higher level entity must belong to
lower level entity
• Partial G/S: each higher level entity may or may not
belong to lower level entity
 Generalization
• Generalization is a bottom-up approach in
which two lower level entities combine to
form a higher level entity
Is-a
 Aggregation
• Aggregation is a process when relation
between two entities is treated as a single
entity.
– In E-R diagram we cannot express relationship
among relationship and hence we need
aggregation
– not capable of representing relationship between
an entity and a relationship
Aggregation
Specialization
Generalization
 Mapping
• Regular entity (convert regular entity into
relation /table) Simple
attribut
es
Relation
Composit
e
Convert Composite to simple Attributes

If more than one key were identified then

These additional keys become secondary
keys
 Weak Entities
Simple
Attributes

R
Owner Entity Weak Entity

Primary Key
 Mapping of 1:1
• Foreign key approach
• Merged relationship approach
• Cross reference or relationship relation
approach
 Foreign key approach

T R 1 S
1

PK

• Add primary key of ‘T’ in ‘S’ as foreign key

• Choose an entity with total participation in “R”
in the role of “S” to avoid null values.
• Another possibility is to have ‘FK’ in both relations
‘S’ and ‘T’ redundantly. But this induces
consistency problems
 Merged relationship
• Approach is followed when the both
participations in ‘R’ are total
• In this we merge both entities ‘T’ and ‘S’ and
relationship ‘R’ into a single relation
Cross relationship/relationship relation
• Used in M:N relationship
• Setup a third relation ‘R’ for purpose of cross
referencing.
• Add primary keys of ‘S’ and ‘T’ in this third
newly created table
 1:M
Simple attributes

R 1
N
S T

Primary Key

• Include ‘PK’ of ‘T’ as foreign key in ‘S’ and add

all simple attributes of ‘R’ as attributes of ‘S’
 1:M
S R T

All Keys
PK
New Relation

New key of this table will be the

‘PK’ of S
Thanks