Entity Relationship Diagram

“A entity relationship diagram is a graphical representation of the overall logical structure of

a database.”

“A entity-relationship model is based on a perception of a real world. A real world consists

of a collection of basic objects and relationship among these objects.”

In E-R model, E-R diagrams are used to represent an E-R schema.

E-R Diagrams are in the base of popularity and wide-spread use of the E-R model.

E-R diagrams are simple and clear. They do not include any implementation detail.

The E-R model employs three basic notations:

1. Entity Set

2. Attributes

3. Relationship sets

Entity Set

“ An Entity is a ‘thing’ or object’ existing in the real world that is distinguishable from all
other object.”

For Example, any Customer of a bank is an entity. A customer , say ‘Riya’, exists in a real
world, as she is living thing. She can be distinguishable from other customer based on her
cust_id, name address and other data. Also, she is different from an employee , an account,
a loan, a transaction or a branch.

Concrete v/s Abstract Entities:

Concrete entity is a physically existing entity, such as a customer, an employee or a book.

Abstract entity has no physical existence, such as an account, a loan, or a subject.

Entity set:

“An entity set is a set of entities of the same type”

All entities in an entity set share the same properties.

For Example, in banking system, the set of all individual customers can be referred as an
entity set customer. Similarly, an entity set employee represents all individual employees of
a bank. So, a database for a banking application includes entity sets like customer,
employee, account, loan, and branch.

Disjoint ness:

Entity sets need not be disjoint.

This means that, a single entity can be a member or extension of more than one entity set.

For example, a single person can be customer as well as an employee of a bank. And if so,
then he/she is an extension of both the entity sets- customer as well as employee.

Attributes

“Attributes are descriptive properties possessed by each member of an entity set”

For Example, an entity set Customer has attributes like customer_id, name, address and
contact number denoted by c_id, cname, address, con_no respectively.

Types of Attributes:

1. Composite v/s Simple Attribute

2. Single v/s Multi-valued Attribute

3. Stored v/s Derived Attribute

Composite v/s Simple Attribute:

 Composite attribute can be divided into similar sub-parts.

 For Example, the address attribute can be divided into sub-parts such as Society,
City, pin-code. Also, Society can be further divided into street number and society
name.
 Composite attribute form a hierarchical structure.

 Simple attribute cannot be divided into sub-parts. Simple attributes are also referred
as atomic attribute.
 For example, cid,ano,balance,bname are simple attribute, as they cannot be divided
into sub-parts.
Single v/s Multi-valued Attribute:

 Single valued attributes have single data value for a particular entity.
 For example, cid and ano are single valued attributes. For any customer, there will be
only one customer id. Similarly, for any account, there will be only one account
number.
 Multi-valued attributes have multiple data values for a particular entity.
 For example, contact no is a multi-valued attributes, since any particular customer
can have zero, one or more contact numbers.

Stored v/s Derived Attribute:

 The value for derived attribute can be derived from the values of other related
attribute.
 Consider two attribute age and birth_date for customer entity set. Here, age can be
calculated by using birth date and current date. So, age is considered as a derived
attribute, while birth_date is considered as a stored attribute or base attribute.
 The value of a derived attribute is not stored in a database. But, it is computed from
stored attribute whenever required.

Relationship

“ A relationship is an association among several entities”

In banking application, each and every account is associated with some particular
customer. This kind of association is known as relationship.

For example, there is relationship between a customer, say ‘janaki’ and some account ,
say account with account number ‘A01’. This relationship indicates that ‘A01’ account is
owned by a customer ‘janaki’ .

Relationship Set :

“A relationship set is a set of relationship of the same type.”

For example, two other entities sets loan and branch. A relationship set Loan_branch
denotes the association between a bank loan and the branch. Similarly, Account_branch
relationship can associate each account with a particular branch to which it belongs.
 Cardinality Constraints

A cardinality constraint is also referred as mapping cardinality.

Cardinality constraints express the number of entities to which another entity can be
associated via a relationship set.

Based on mapping cardinalities, a binary relationship set can be divided into four categories:

1. One-to-One

2. One-to-Many

3. Many-to-One

4. Many-to-Many

1. One-to-One:

An entity in E1 is associated with at most one entity of E2. And, an entity in E2 is

associated with at most one entity of E1.

An Example: In banking system, no multiple accounts are allowed, no join accounts

are allowed. In this situation, one customer can have only one account and one account can
be associated with only one customer.

2. One-to-Many

An entity in E1 is associated with zero or more entities of E2. and an entity in E2 is

associated with at most one entity of E1.

For Example, multiple accounts are allowed, but no join accounts are allowed. So,
one customer can have any number of accounts, but one account will have only one
customer.

3. Many-to-One

An entity in E1 is associated with at most one entity of E2. and an entity in E2 is

associated with zero or more entity of E1.

For example, No multiple accounts are allowed, but join accounts are allowed. So
One customer can have only one account , but one account can be associated with any
number of accounts.

4. Many-to-Many
 An entity in E1 is associated with zero or more entities of E2. Ans, an entity in E2 is
associated with zero or more entities of E1.

An example, Multiple accounts, as well as, joins accounts- both are allowed.

In this situation, one customer can have any number of accounts, and one account
can have any number of customers.

Key Constraints
Each and every entity in any entity set is different from other one.

From database perspective, this difference is represented by values of attributes for each
entity. No any two entities set will have exactly the same values for all attributes.

There must be some way to uniquely identify an entity within an entity set.

There are several keys :

1. Super Key

2. Candidate Key

3. Primary Key

Super Key :

o A super key is a set of one or more attributes that allows identifying each
entity uniquely in the entity set.
 o For example, the cid attribute of the entity set customer can distinguish one
customer from another. So, cid is a super key for customer entity set.

Candidate Key :

o “A Super key for which no subset is a super key is called a candidate key.”
o In other word, candidate key is a minimal super key
o A candidate key is also referred as ‘key’ only.
o A candidate key is sufficient to identify each and every entity uniquely within
an entity set.
o For example, combination of cid and contact_no is a super key for entity set
customer. But, only cid can alone identity entities uniquely. So, here
contact_no is a redundant attribute in super key. After removing all such
redundant attributes from a super key, the remaining attributes are
considered as a candidate key. So, here cid is a candidate key.
o Sometimes, there can be more than one candidate keys for the same entity
set.
o For example, for customer entity set, {cid} as well as { cname, address} are
candidate key.

Primary Key :

o “A Primary key is a candidate key that is chosen by the database designer to

identify entities uniquely in an entity set.”
o For example, if database designers chose candidate key cid to identify all
customers uniquely, then cid is a primary key of the entity set.
o Primary keys are indicated in E-R diagram by underlining the attributes which
constitute a primary key.
 Notations used in E-R diagram

Example:
Consider a relationship set “depositor” having two entity set “Customer” and “Account”

An entity set Customer has attribute like Custmor_id, Customer_name, Customer_street,

Customer_city.

An entity set Account has Account_number , Balance.

An depositor itself has an attribute access_date.

Role and Recursive Relationship

A role that an entity plays in a relationship is generally implicit and need not to be
represented. But, Sometimes it is necessary to specify a role of an entity explicitly, such as in
recursive relationship sets.

The role of an entity can be denoted by labelling the lines that connect diamonds to
rectangles.
 Multiple Relationships

A ternary relationship set Works_in having three entity set Employee,

Department, and Location. This relationship set represent which employee is
working in which Department at which location.

An employee may be associated with more than one department, and he

might have different location durations in different departments. To illustrate
this kind of data requirements, there is a need of ternary relationship.

Weak Entity Sets

An entity set that does not have sufficient attributes to form a primary key is called a weak
entity set.

An entity set having sufficient attributes to form a primary key is called a strong entity set.

Existence of a weak entity depends on the strong entity.

For example, in above example of ternary relationship set, the entity set location is a weak
entity set. It depends on the entity set employee.

Such kind of weak entity sets are denoted by outline rectangles.