1

CHAPTER 2

ENTITY-RELATIONSHIP MODELING
The Entity Relationship Model (ER Model) models the real world situations as a
collection of entities and relationships amongst the entities.

Entity An Entity is an object (like a “CAR”) or a concept (like an “ACCOUNT”)

from the real world, which is distinguishable from other objects and other concepts. Each
Entity will be defined by a set of properties (called Attributes). For example entity
“ACCOUNT” may be defined by Attributes like “ACCOUNT-NUMBER”, “BRANCH-
NAME” and “BALANACE” etc.

Entity Set An Entity-Set refers to a collection of entities of the same kind. Each
entity in an Entity-Set will have the same set of attributes and the set of attributes will
distinguish it from other Entity Sets. No other entity set will have exactly the same set of
attributes. Some of the attributes of an entity set may overlap with other entity sets.

Relationship A Relationship refers to an association amongst Entity Sets. Like there

may be relationship “DEPOSITOR” between Entity Set “CUSTOMER” and Entity Set
“ACCOUNT”.

Relationship Set A Relationship Set refers to the collection of Relationships of the

same kind (i.e. having exactly same set of Attributes). A Relationship Set will inherit
some of the Attributes (properties) of the associating Entity Sets. Like the Relationship
Set “DEPOSITOR” between Entity Sets “CUSTOMER” and “ACCOUNT” will inherit
Attributes “CUSTOMER-ID” from “CUSTOMER” and Attribute “ACCOUNT-
NUMBER” from “ACCOUNT”. In addition, a Relationship Set may have some of its
own attributes called “Descriptive Attributes”; for example the relationship set
“DEPOSITOR” may have a descriptive attribute “DATE-OF-OPERATION”, indicating
the date on which a customer has last operated an account.

Domain of an Attribute

Each attribute has a set of permitted values called its domain or value set, like the
attribute ‘NAME’ may have a domain that is set strings of characters of specified
maximum length.

A database will consist of a set of Entity-sets and Relationship-Sets, each of

which will contain a number of entities of the same type or Relationships of the same
type. An entity in a database may be described by a set of (attribute, data value) pairs;
like a student in Entity-Set “STUDENT” may be described by {(ROLL-NUMBER,
0990013010), (NAME, ‘Karan Singh’), (DATE-OF-BIRTH, ‘10-DEC-1985’)}.

P S Gill
 2

Attribute Types:-

(i) Simple Vs Composite Attributes. A Simple attribute is the one, which

is not divisible into sub-parts like ‘BRANCH’. On the other hand, a Composite
attribute is the one, which can be divided into sub-parts like ‘DATE-OF-BIRTH’,
which may be divided into ‘birth-date’, ‘birth-month’ & ‘birth-year’.

(ii) Single-Valued Vs Multi-Valued Attributes. An attribute, which

can assume one value at a time, is called Single-Valued attribute; like ‘name’ of an
EMPLOYEE entity. On the other hand, an attribute, which may assume a set of
values at a time, is called multi-valued attribute; like attribute ‘dependant’ of an
Attribute Set “EMPLOYEE”, which may have none or one or multiple values,
depending upon the number of dependents of an employee.

(iii) Null Attribute. A null value is assigned to an attribute under any of

the following three conditions:-

(a) If the attribute value is not applicable to an entity; like SPOUSE-NAME

will not be applicable if an employee is unmarried.

(b) If value is applicable, but not specified; like TEL#- an employee may not
be owning a Telephone.

(c) If value is applicable and specified but not known to the agency entering
the information; like an employee may be owning a Telephone but the
number may not be known to the organization.

Null value can only be assigned to an Attribute, if assigning value to that attribute
is optional (not mandatory). The Mandatory attributes cannot be assigned a
“Null” value.

(iv) Derived Attribute Vs Stored Attribute. A derived attribute is the one,

whose value is not stored in the database, but is derived from the value of other
stored attributes; like the value of attribute ‘age’ can be derived from attribute
‘date-of-birth’ and current date obtained from the system.

Degree of Relationship Sets. Degree of a Relationship Set refers to the number of

Entity Sets participating in the Relationship. Most of the relationships are binary.

E-R Diagram Notations

Rectangle represents an entity set.

Ellipse represents an attribute.

P S Gill
 3

Diamond represents a relationship set.

Line links an attribute to an entity set or an entity set to a

relation set.

Double Line indicates total participation of an entity set in a

relation set.

Dashed Ellipse indicates derived attribute.

Double Ellipse indicates multi-valued attribute.

Double Rectangle indicates weak entity set.

Double Diamond indicates a relationship set with participation

of some weak entity sets.

RELATIONSHIP constraints

- Mapping Cardinalities
- Participation Constraint

Mapping Cardinalities. For a binary relationship set R between entity sets A and B,
the mapping cardinalities can be on of the following:-

(a) One-to-one. An entity in A is associated with at most one entity in B and an

entity in B is associated with at most one entity in A. It is represented in E-R Model as
follows:-

R
A B

One-to-one cardinality is represented by directed lines drawn from R to A & B both.

(b) One-to-many. One to many cardinality from A to B implies than an entity in A is

associated with any number (Nil/ one/ many) of entities in B; however, an entity in B is
associated with at most one entity in A. It is represented in E-R Model as follows:-

P S Gill
 4

R
A B

(c) Many-to-one. Many to one cardinality from A to B implies that an entity in A is

associated with at most one entity in B; however, one entity in B can be associated with
any number of entities in A. It is represented in E-R Model as follows:-

R
A B

(d) Many-to-many. Many to many cardinality from A to B implies that an

entity in A can be associated with any number of entities in B and one entity in B can be
associated with any number of entities in A. It is represented in E-R Model as follows:-

R
A B

Example:-

One-to-One relationship from CUSTOMER to ACCOUNT implies that each customer

can have only one account and each account has to be Single.

DEPOSITOR
CUSTOMER ACCOUNT

(One-to-One Relationship)

One-to-Many relationship from CUSTOMER to ACCOUNT implies that each customer

can have any number (NIL or One or More than One) of accounts, but each account has
to be Single.

DEPOSITOR
CUSTOMER ACCOUNT

(One-to-Many Relationship)

Many-to-One relationship from CUSTOMER to ACCOUNT implies that each customer

can have only one accounts, but each account can be Joint (held by one or more).

DEPOSITOR
CUSTOMER ACCOUNT

P S Gill
 5

(Many-to-One Relationship)

Many-to-Many relationship from CUSTOMER to ACCOUNT implies that each

customer can have any number (Nil or One or More than One) accounts and each account
can be Joint (held by one or more).

DEPOSITOR
CUSTOMER ACCOUNT

(Many-to-Many Relationship)

Participation Constraints in Relationship Sets

- Total Participation
- Partial Participation

Total Participation

An Entity Set E is said to have total participation in relationship set R if each entity in E
is participating at least in one relationship through R. In E-R Diagram, the Total
Participation is represented by a “Double Line” drawn between the Entity Set symbol and
the Relationship Set symbol.

Partial Participation

An Entity Set E is said to have partial participation in relationship set R if some of the
entities in E are not participating in any relationship through R. In E-R Diagram, the
Partial Participation is represented by a “Single Line” drawn between the Entity Set
symbol and the Relationship Set symbol.

Example:- Suppose Entity Sets “CUSTOMER” and “ACCOUNT” are related by

Relationship Set “DEPOSITOR” and Entity Sets “CUSTOMER” and “LOAN” are
related by Relationship Set “BORROWER”. Suppose it is possible that a customer may
have only account or only loan or both, then the situation can be modeled as follows:-

CUSTOMER Partial DEPOSITOR Total Participation ACCOUNT

Participation

P S Gill
 6

Partial Participation

BORROWER

Total Participation

LOAN

Concept of Key

Super Key. A Super Key of an Entity Set or Relationship Set refers to the set of
attributes, which when taken collectively, will uniquely determine an entity within the
Entity Set or a Relationship within the Relationship Set. If K forms a Super Key (SK) of
an Entity Set E then any super set of K will also be a Super Key of E. So, a Super Key
may have some extraneous (unnecessary) attributes, which if removed, the balance set
may still form a Super Key of R.

Example :- Suppose each student in the Entity Set STUDENT (ROLL_NO, NAME,
BRANCH, FATHERS-NAME, ADDRESS, DOB, TEL-NO) has a unique value of
ROLL-NO. This implies that no two students can have same ROLL-NO. Then {ROLL-
NO, NAME} forms a super key of Entity-Set STUDENT. In this, the attribute NAME is
extraneous; which if removed, the balance set i.e. {ROLL-NO} still forms a Super Key of
STUDENT.

Candidate Key. A Super Key, whose no proper subset forms a Super Key, is called
a Candidate Key. Thus, Candidate Key is a minimal Super Key (i.e. a Super Key having
no extraneous attributes). An Entity Set may have more than one Candidate Keys.

Example:- The Entity Set STUDENT will have at least two Candidate Keys i.e.
{ROLL-NO} and {NAME, FATHERS-NAME, DOB, ADDRESS}.

Primary Key. Primary Key is one of the Candidate Keys that is designated by the
database designers as primary means of identifying entities within an entity set. In the E-
R Diagram, the Primary Key Attributes are underlined with a firm line.

Primary Key of a Relationship Set

Let R be a binary relationship set between Entity Sets E1 and E2. Let K1 and K2 be the
respective Primary Keys of E1 and E2. Then the Primary Key of Relationship Set R will
depend upon the cardinality mapping of the relationship set, as explained below:-

P S Gill
 7

(i) One to One Relationship

PK (R) = PK (E1)
or
= PK (E2)

(ii) One to Many Relationship from E1 to E2

Here E2 is called “Many-Side” Entity Set and E1 is called “One-Side” Entity-Set.
PK (R) = PK (E2) i.e. Primary Key of “Many-Side” Entity-Set.

(iii) Many to One Relationship from E1 to E2

Here E1 is called “Many-Side” Entity Set and E2 is called “One-Side” Entity-Set.
PK (R) = PK (E1) i.e. Primary Key of “Many-Side” Entity-Set.

(iv) Many to Many Relationship from E1 to E2

PK (R) = PK (E1)  PK (E2)

Example
CN AN
(i)
DEPOSITOR
CUSTOMER ACCOUNT

(One-to-One Relationship)

PK (DEPOSITOR) = CN or AN

CN AN
(ii)
DEPOSITOR
CUSTOMER ACCOUNT

(One-to-One Relationship)

PK (DEPOSITOR) = AN i.e. PK of ACCOUNT

CN AN
(iii)
DEPOSITOR
CUSTOMER ACCOUNT

P S Gill
 8

(One-to-One Relationship)

PK (DEPOSITOR) = CN i.e. PK of CUSTOMER

CN AN
(iv)
DEPOSITOR
CUSTOMER ACCOUNT

(One-to-One Relationship)

PK (DEPOSITOR) = {CN, AN} i.e. PK (CUSTOMER)  PK (ACCOUNT)

Concept of Weak Entity Set

An Entity Set is said to be a Weak Entity Set if it does not have sufficient attributes to
form its Primary Key. On the other hand, an entity set having a primary key of its own is
called a Strong Entity Set. A Weak Entity Set (say E 2) will be dependent for its existence
on a Strong Entity Set (say E 1) to form its Candidate Key. Then Entity Set E 2 is said to be
“Existence-Dependent” on E1 and E1 is said to be the “Owner Entity Set” of E 2. The
relationship R between E2 and E1 is called “Identifying Relationship”. The Weak Entity
Set E2 will have a set of attributes called its “Discriminator”, which together with the
Primary Key of E1 will form the Primary Key of E2.

E1
E2

Owner Entity Set Identifying Relationship Weak Entity Set

Example:-Suppose an Entity Set EMPLOYEE (EMP_ID, EMP_NAME, SALARY,

DEPENDENTS) has an attribute DEPENDENT which is multi-valued i.e. an employee
may have none or one or more than dependents. This situation can be best modeled as
follows:-
EMP-NAME
D-NAME RELATIO
N
EMP-ID
DOB
SALARY

P S Gill
 9

EMPLOYEE DEPENDENT

Owner Entity Set Identifying Relationship Weak Entity Set

- The Weak Entity Set DEPENDENT is Existence Dependent on the Strong Entity
Set EMPLOYEE.

- The Weak Entity Set “DEPENDENT” has a Discriminator Attribute D-NAME,

which along with primary key EMP-ID of EMPLOYEE, forms Primary Key of the weak
entity set DEPENDENT. In E-R Diagram, the Discriminator (also called Partial Key) of
a weak entity set is marked by underlining with a broken line.

Special Features of an Identifying Relationship

Normally, a situation modeled by Weak Entity Set will have following features:-

(i)The Identifying Relationship will be one-to-many from Owner Entity Set to Weak
Entity Set.

(ii) The Participation of Owner Entity Set in the Identifying Relationship will be
partial and the participation of the Weak Entity Set in the Identifying Relationship
will be Total.

Modeling of a Multi-valued Attribute as Weak Entity Set

In the above example, the Weak Entity Set DEPENDENT can also be modeled as a multi-
valued attribute of Entity Set EMPLOYEE. The multi-valued attribute can be used to
indicate the names of the dependents of employees. But suppose we want to indicate
other parameters of dependents like dependent’s relationship with the employee then the
multi-valued approach will not be suitable. In this case, the Weak Entity approach will be
the ideal choice, since then the weak entity set DEPENDENT can have any number of
attributes.

Extended E-R Features

Specialization. An entity set E may include some sub-groups of entities (say E 1,

E2, ….. En), such that each of these sub-groups may have some distinct attributes different
than the other sub-groups. There will be some attributes that will be common to all sub-
groups. The process of designating these sub-groups within an entity set is called
specialization;
A1 A2
P S Gill
 10

Higher Level Entity Set E

Or Super Class

A2 ISA C2
C1
A1 B1
En
E1 E2

Lower Level Entity Sets or Sub Classes

In the above example, an Entity Set E has been specialized into Sub-groups designated as
E1 , E2 ….. En. E is called “Super Class” or “Higher Level Entity Set” and the entity sets E 1
, E2 ….. En are called “Sub Classes” or “Lower Level Entity Sets” of E. The common
attributes of all sub entity sets are represented with the super entity sets. And the distinct
attributes of each sub entity set are represented with the sub entity set.

The relationship of Higher Level Entity Set with its Lower Level Entity Sets is called ISA
relationship. It is read as “is a”.

Inheritance of Attributes in Specialization

Each Sub Class will inherit the Attributes of its Super Class; plus it will have its own
distinct Attributes. Like in the above case, each lower entity set will inherit attributes A 1
and A2 of the Super Class E.

Example:- Consider an entity set ACCOUNT with attributes Account-Number and

Balance. The Entity Set ACCOUNT may be specialized into different types of accounts
like SAVINGS-ACCOUNT, CURRENT-ACCOUNT, FIXED-DEPOSIT (FD) and
RECURRING-DEPOSIT (RD). The SAVINGS-ACCOUNT may have an attribute Interest-
Rate and CURRENT-ACCOUNT may have attribute Over-Draft. Similarly, FD and RD
have distinct attributes of their own.

Account- Balance
Number

ACCOUNT
Mat-Date

Int-Rate Installment
Interest-Rate ISA

P S Gill
 11

RD
SAVINGS- Over-Draft
ACCOUNT Int-Rate

Mat-Date
CURRENT- FD
ACCOUNT

Specialization Constraints

Disjoint Vs Overlapping Specialization

Disjoint. It implies that an entity does not belong to more than one lower-
level entity set i.e. an account is either savings-account or current-account but not
both.

Overlapping. In overlapping generalizations, an entity may belong to more than

one lower-level entity sets within a single generalization.

Total Vs Partial Specialization

Total Each higher level entity must belong to a lower-level entity set.
Partial. Some higher-level entities may not belong to any lower-level entity set.

Generalization. Specialization is a top-down approach; whereas Generalization is

exactly inverse of that. Generalization refers to the process of fusing several distinct
entity sets into a single Higher Level Entity Set, on the basis of commonality of their
attributes. Then the fused sets form sub classes or lower level entity sets. The common
attributes of the Lower Level Entity Sets will be assigned to the Higher Level Entity Set.
Thus, generalization is a process, which proceeds in a bottom-up manner, in which
multiple entities are synthesized into a single higher-level entity set, on the basis of their
common features. The higher-level entity set is termed as super-class and lower level
entity set is termed as sub-class. As regards E-R Diagram, both Specialization and
Generalization are represented exactly in the same manner.

Aggregation. One limitation of E-R Model is that it fails to express relationships

among relationship sets or relationship between a relationship set on one side and an
entity set on the other side. Aggregation provides a solution in this case. Aggregation is
an abstraction through which relationships are treated as higher-level entities, which can
then participate in relationships with other Entity Sets or with other relationship sets. For
example the relationship between R1 and E3 as indicated below.

A1 A2 B1 B2

P S Gill
 12

E1 R1 E2
Aggregated Higher Level Entity Set “R1”

R2

E3

C1 C2 C3

Here, the Relationship Set R1 between Entity Set E1 and Entity Set E2 has been
aggregated as Higher Level Entity Set “R1”. This Higher Level Entity Set is participating
in a Relationship R2 with Entity Set E3. Thus, through aggregation, we are able to
represent a Relationship between Relationship Set R1 and Entity Set E3.

Example:- Suppose, we have Entity Sets “EMPLOYEE”, “BRANCH” and “JOB”

which are related through a Relationship “EBJ” which indicates, “which employee” is
performing “what jobs” at “which branch”. There will be multiple jobs at each at each
branch and assume that each employee may be performing multiple jobs at one of the
branches. Suppose, we want to relate another Entity Set “MANAGER” to indicate:-

(i)The set of Employees managed by a manager.

(ii)The set of jobs managed by a manager.

(iii)The Branches managed by a manager (assume a manager can manages only

one branch).

If we represent this scenario without use of aggregation, then the E-R Diagram will be as
follows:-
BRANCH
EMPLOYEE
EBJ

JOB
EM BM

P S Gill
 13

JM

MANAGER

The above Scenario can be better modeled by aggregating the Relationship Set “EBJ” a a
higher level Entity Set and the creating a relationship between this higher level entity set
and the Entity Set “MANAGER”, as indicated below:-

BRANCH

EMPLOYEE JOB

EBJ

Aggregated Higher-Level-Entity-Set “EBJ”

EBJM

MANAGER

This modeling represents the situation more realistically, wherein the Relationship Set
“EBJM” indicates “which combinations of employee-branch-job” are being managed by
each manager.

P S Gill
 14

Reduction of E-R Schema to Tables

An E-R Diagram can be reduced to a set of Tables, as explained below:-

(a) Tabular representation of a Strong Entity Set. A Strong Entity Set E will be
represented by a Table named “E”. The Table will have columns as follows:-

(i) Simple, Single-valued Attributes There will be a column for each

simple, single-valued attribute of Entity Set E.

(ii) Composite Attributes There will be a column for each sub-part of

a Composite Attribute; no column needs to be assigned for composite attribute as
such. For example for NAME comprising of First Name (FN), Middle Name
( MN) and Last Name (LN) there will be three columns for FN, MN and LN. No
column needs to be assigned for NAME. If NAME needs to be produced, it can
be done by combining the sub-parts.

P S Gill
 15

(iii) Derived Attributes No column needs to be assigned for the derived

attributes; since the values of these attributes are not stored in database.

(iv) Multi-Valued Attribute Each Multi-Valued Attribute (say M) will be

represented by a separate Table (say named E-M) which will have a column each
for the primary key attributes of E and a column for Attribute M. Each value of
the multi-valued attribute will be represented in a separate row in this table.

Let E be a Strong Entity Set with simple single-valued attributes a1,a2,……,an. This
Entity Set will be represented by a Table called E with n distinct columns, each of which
will correspond to one of the attributes. Let D1,D2,…Dn be the domains of attributes
a1,a2,….,an respectively. The Table E will comprise of a set of rows, which will be a
subset of the Cartesian Product D1 X D2 X…….Dn.

Example Age
DOB Tel_No

Name Cit
Univ_Roll_No
y
Stree
STUDENT H- t Pin
No
Addres
s

The derived attribute Age will not be represented in the STUDENT table. When required,
its value will be derived from DOB.

The Tel-No will be represented in a separate table (say named STUDENT-TEL-NO),

which will have a column for Primary Key of STUDENT i.e. Roll-No and a column for
Tel-No. Suppose, a student has more than one Tel-No then his Roll-No will appear that
many times in this table.

The Above E-R Diagram will be reduced to following two Tables:-

STUDENT
Univ_Roll_No Name DOB H-No Street City Pin

P S Gill
 16

STUDENT-TEL-NO
Univ_Roll_No Tel_No

(b) Tabular representation of Relationship Sets. Let R be a Relation Set and

let a1, a2,…..am be the set of attributes formed by the union of the primary keys of all the
Entity Sets participating in Relation R and let the descriptive attributes of R (if any) be
b1,b2,…..bn. Then the Relation R will be represented by a Table named say “R”, which
will (m+n) columns, each column representing one of the attributes from the set {a 1, a2,
……am} U {b1,b2,….bn}.
Date-of-Operation

Example
C-
Account-No Branch-Name
Address
C-Id
Balance
C-Name

ACCOUNT
CUSTOMER DEPOSITOR

The Relationship Set DEPOSITOR will be represented by a table named DEPOSITOR.

The Entity Sets CUSTOMER and ACCOUNT have Primary Keys C-Id and Account-No
respectively, which will also form part of the DEPOSITOR table. In addition, the
DEPOSITOR table will have a column for its Descriptive Attribute “date-of-Operation”.
The above E-R Diagram will be reduced to the following set of tables:-

CUSTOMER
C-Id C-Name C-address

ACCOUNT
Account-Number Balance Branch-Name

P S Gill
 17

DEPOSITOR
C-Id Account-Number Date-of-Operation

Shifting of Descriptive Attributes of a Relationship Set and Merging of Relationship

Set Table with the tables of participating Entity Sets. Depending on the Cardinality
Mapping of the participating Entity Sets, the Descriptive Attributes of the Relationship
set can be shifted to one of the participating Entity Sets. Also, a Relationship Set Table
can be combined with the table of one of the participating Entity Sets, as per the
following conditions:-

(1) One-to-One Relationship Suppose there is a One-to-One relationship between

two entity sets, then the rows in the Relationship Set table will have one-to-one mapping
with the rows in the tables of the participating entity sets. Under this condition, it is
possible to shift the descriptive attributes of the relationship set to any of the participating
Entity Sets and also it is possible to merge the table of the Relationship Set with the table
of any of the participating Entity Sets, without loss of any information.

Example:-

Date-of-Operation

C- Account-No Branch-Name
Address
C-Id
Balance
C-Name

ACCOUNT
CUSTOMER DEPOSITOR

As indicated above, there is One-to-One Relationship between CUSTOMER and

ACCOUNT i.e. Each Customer has at most one account and each account is “Single”
(i.e. owned by only one customer).

CUSTOMER
C-Id C-Name C-address
C-001 Ajay 320, Sector-26, Noida

P S Gill
 18

C-220 Vijay 110,Sector-8, RKP

C-310 Ram 120,Sector-25, Noida
C-505 Shyam 303,Sector-22, RKP

ACCOUNT
Account-Number Balance Branch-Name
A-101 10000 Sec-18
A-203 30000 Sec-26
A-305 50000 CP
A-310 25000 RKP

DEPOSITOR
C-Id Account-Number Date-of-Operation
C-001 A-310 10-Jan-2007
C-220 A-101 23-Dec-2006
C-310 A-203 03-Feb-2007
C-505 A-305 27-Dec-2007

As obvious, the rows in DEPOSITOR table are having one-to-one mapping with the rows
in the CUSTOMER Table and also with the rows in the ACCOUNT Table. That is, the
first row of DEPOSITOR maps onto the fourth row of ACCOUNT, the second row of
DEPOSITOR maps onto the first row of ACCOUNT, the third row of DEPOSITOR maps
onto the second row of ACCOUNT and the last row of DEPOSITOR maps onto the third
row of ACCOUNT. Thus, the descriptive attribute Date-Of-Operation of the Relationship
Set DEPOSITOR can be shifted to either CUSTOMER or ACCOUNT. Also, the
DEPOSITOR Table can be combined either with the CUSTOMER Table or with the
ACCOUNT Table, without losing any information. The combined table will have union
of the columns of the two merged tables. Suppose, DEPOSITOR Table is merged with
the CUSTOMER Table, then the CUSTOMER Table will also include attributes
Account_Number and Date_Of_Operation . The resulting set of tables will then be:-

CUSTOMER
C-Id C-Name C-address Account- Date-of-
Number Operation
C-001 Ajay 320, Sector-26, Noida A-310 10-Jan-2007
C-220 Vijay 110,Sector-8, RKP A-101 23-Dec-2006
C-310 Ram 120,Sector-25, Noida A-203 03-Feb-2007
C-505 Shyam 303,Sector-22,RKP A-305 27-Dec-2007

ACCOUNT
Account-Number Balance Branch-Name
A-101 10000 Sec-18
A-203 30000 Sec-26
A-305 50000 CP

P S Gill
 19

A-310 25000 RKP

The combined CUSTOMER Table now includes the Primary Key (AN) of ACCOUNT
and descriptive attribute Date_Of_Operation of DEPOSITOR.

(2) One-To-Many Relationship Suppose there is a One-to-Many relationship

between CUSTOMER and ACCOUNT i.e. each customer can have many accounts, but
each account has to be single.

Date-of-Operation
Example
C-
Account-No Branch-Name
Address
C-Id
Balance
C-Name

ACCOUNT
CUSTOMER DEPOSITOR

CUSTOMER
C-Id C-Name C-address
C-001 Ajay 320, Sector-26, Noida
C-220 Vijay 110,Sector-8, RKP
C-310 Ram 120,Sector-25, Noida
C-505 Shyam 303,Sector-22,RKP

ACCOUNT
Account-Number Balance Branch-Name
A-101 10000 Sec-18
A-203 30000 Sec-26
A-305 50000 CP
A-310 25000 RKP
A-550 35000 CP
A-670 60000 Sec-18

DEPOSITOR
C-Id Account-Number Date-of-Operation
C-001 A-310 10-Jan-2007
C-220 A-101 23-Dec-2006
C-310 A-203 03-Feb-2007
C-505 A-305 27-Dec-2007
C-101 A-550 22-Dec-2006

P S Gill
 20

C-310 A-670 01-Jan-2007

The rows in the DEPOSITOR table have one-to-one mapping onto the rows in
ACCOUNT Table i.e. with the “Many-Side Entity Set” Table. That is, the first row of
DEPOSITOR maps onto the fourth row of ACCOUNT, the second row of DEPOSITOR
maps onto the first row of ACCOUNT, the third row of DEPOSITOR maps onto the
second row of ACCOUNT, the fourth row of DEPOSITOR maps onto the third row of
ACCOUNT, the fifth row of DEPOSITOR maps onto the fifth row of ACCOUNT and the
last row of DEPOSITOR maps onto the last row of ACCOUNT table. Thus, the
descriptive attribute Date-Of-Operation can be shifted to ACCOUNT (The “Many-Side”
Entity Set) and the DEPOSITOR Table can be with the ACCOUNT Table (i.e. with the
table of the “Many-Side” Entity Set), without losing any information. The resultant
ACCOUNT table will also include the Primary Key C-Id of CUSOMER table and
descriptive attribute DOO of the DEPOSITOR table. The resulting set of tables will then
be:-

CUSTOMER
C-Id C-Name C-address
C-001 Ajay 320, Sector-26, Noida
C-220 Vijay 110,Sector-8, RKP
C-310 Ram 120,Sector-25, Noida
C-505 Shyam 303,Sector-22,RKP
ACCOUNT
Account- Balance Branch-Name Customer_Id Date_of_Operation
Number
A-101 10000 Sec-18 C-220 23-Dec-2006
A-203 30000 Sec-26 C-310 03-Feb-2007
A-305 50000 CP C-505 27-Dec-2007
A-310 25000 RKP C-101 10-Jan-2007
A-550 35000 CP C-101 22-Dec-2006
A-670 60000 Sec-18 C-310 01-Jan-2007

(3) Many-to-One Relationship Suppose there is many-to-one relationship between

CUSTOMER and ACCCOUNT, which implies that each account can be “Joint” but each
customer can hold only one account. In this case, the table DEPOSITOR can be
combined with “Many-Side” Entity-Set table CUSTOMER.

Date-of-Operation
Example
C-
Account-No Branch-Name
Address
C-Id
Balance
C-Name

ACCOUNT
CUSTOMER
P S Gill
 21

DEPOSITOR

CUSTOMER
C-Id C-Name C-address
C-001 Ajay 320, Sector-26, Noida
C-220 Vijay 110,Sector-8, RKP
C-310 Ram 120,Sector-25, Noida
C-505 Shyam 303,Sector-22, RKP

ACCOUNT
Account-Number Balance Branch-Name
A-101 10000 Sec-18
A-203 30000 Sec-26

DEPOSITOR
C-Id Account-Number Date-of-Operation
C-001 A-101 10-Jan-2007
C-220 A-203 23-Dec-2006
C-310 A-101 03-Feb-2007
C-505 A-203 27-Dec-2007
The rows in the DEPOSITOR table have one-to-one mapping onto the rows in
CUSTOMER Table i.e. with the “Many-Side Entity Set” Table. Thus, the descriptive
attributes of DEPOSITOR can be shifted to “Many-Side” Entity Set CUSTOMER and
the DEPOSITOR Table can be with the CUSTOMER Table, without losing any
information. The resultant CUSTOMER table will also include the Primary Key
Account_Number of ACCOUNT table and descriptive attribute DOO of the
DEPOSITOR table. The resulting set of tables will then be:-

CUSTOMER
C-Id C-Name C-address Account_Number DOO
C-001 Ajay 320, Sector-26, Noida A-101 10-Jan-2007
C-220 Vijay 110,Sector-8, RKP A-203 23-Dec-2006
C-310 Ram 120,Sector-25, Noida A-101 03-Feb-2007
C-505 Shyam 303,Sector-22, RKP A-203 27-Dec-2007

ACCOUNT
Account-Number Balance Branch-Name
A-101 10000 Sec-18
A-203 30000 Sec-26

(4) Many-to-Many Relationship Suppose there is many-to-many relationship

between CUSTOMER and ACCCOUNT, which implies that each account can be “Joint”
but each customer can hold many accounts. In this case, the table DEPOSITOR cannot be
combined with any Entity Set and it has be created as a separate table. Since, if we

P S Gill
 22

combine then we have to combine with both the Entity Sets and that would add
unnecessary data redundancy, which is not acceptable.

Date-of-Operation
Example
C-
Account-No Branch-Name
Address
C-Id
Balance
C-Name

ACCOUNT
CUSTOMER DEPOSITOR

CUSTOMER
C-Id C-Name C-address
C-001 Ajay 320, Sector-26, Noida
C-220 Vijay 110,Sector-8, RKP
C-310 Ram 120,Sector-25, Noida
C-505 Shyam 303,Sector-22, RKP

ACCOUNT
Account-Number Balance Branch-Name
A-101 10000 Sec-18
A-203 30000 Sec-26
A-305 50000 CP
A-310 25000 RKP

DEPOSITOR
C-Id Account-Number Date-of-Operation
C-001 A-101 10-Jan-2007
C-220 A-203 23-Dec-2006
C-310 A-101 03-Feb-2007
C-505 A-203 27-Dec-2007
C-101 A-305 30-Dec-2007
C-505 A-310 02-Jan-2007

Now, the rows in the DEPOSITOR table do not have one-to-one mapping with
CUSTOMER table and also with the ACCOUNT table. So, the DEPOSITOR table can
neither be merged with CUSTOMER table nor with ACCOUNT table. Thus, there has to
be a separate table for DEPOSITOR as indicated above. Also, the descriptive attributes of
the Relationship Set cannot be shifted to the participating Entity Sets; the descriptive
attributes have to remain with the relationship set itself.

P S Gill
 23

(c) Tabular representation of Weak Entity Sets. Let A be a Weak Entity Set
with descriptive Attributes a1,a2,……,am. Let B be the Strong Entity Set on which A is
existence dependent. Let the primary key of B consist of attributes b1,b2,….bn. The
Entity Set A is represented by a Table called A with (m+n) columns, each column
representing one of the attributes from the set {a1,a2,……am} U {b1,b2,….bn}.

Example: Payment-Date
Payment-
Amoun No
Loan-No t Installmen
t

LOAN- PAYMENT
LOAN PAYMENT

There will be Tables LOAN and PAYMENT; the PAYMENT table will also include the
Primary Key of Loan i.e. Loan-No. The Primary Key of table PAYMENT will be
{Loan-No, Payment-No} where the attribute Payment-No is called a “Discriminator” or
“Partial Key” of the table PAYMENT.

Redundancy of Tables in Weak Entity Sets The Table for Identifying

Relationship LOAN-PAYMENT is not required because if we create such a table, it will
have only two attributes i.e. Loan-No and Payment-No, which as such form part of table
PAYMENT. Thus, no table needs to be created for an Identifying Relationship. In case
there exists a Descriptive Attribute of an Identifying that can be shifted to the “Many-
Side Entity Set” i.e. the Weak Entity Set.

(e) Tabular representation of Generalization. The steps involved are:-

Create a Table each for the higher-level entity set and for each lower-level entity
set. The table for lower-level entity set will include its own attributes plus all the
Primary-Key attributes of its higher-level entity set.

Account- Balance
Number

ACCOUNT
Mat-Date

Int-Rate Installment
Interest-Rate ISA

RD
SAVINGS- Over-Draft
ACCOUNT Int-Rate

P S Gill
 24

Mat-Date
CURRENT- FD
ACCOUNT

For example, in the above case there will five tables i.e. ACCOUNT, SAVINGS-
ACCOUNT, CURRENT-ACCOUNT, FD and RD. The table ACCOUNT will have
columns Account-Number and Balance; and table SAVINGS-ACCOUNT will have
columns Account-Number and Interest Rate; and table CURRENT-RATE will have
columns Account-Number and Over-Draft. Same is applicable to the tables FD and RD.

Combining of Tables in Generalization If a generalization is “Total”, which implies

that each entity in the super-class (higher-level entity set) is a member of at least one sub-
class (lower-level entity set), no table is required to be created for the higher-level entity
set. Instead a table needs to be created for each lower-level entity set; and each such table
will also include all the attributes of higher-level entity set, in addition to its own distinct
attributes. For example, the table SAVINGS-ACCOUNT will also have columns Account-
Number, Balance and Interest-Rate; and the table CURRENT-ACCOUNT will also have
the columns Account-Number, Balance and Over-Draft. The same is applicable for FD
and RD tables.

(f) Tabular representation of Aggregation. Take the following Example:-

B-Name
E- B#
E# Name
BRANCH J#

EMPLOYEE JOB

EBJ

Aggregated Higher-Level-Entity-Set “EBJ”

Mgr- EBJM
Id

MANAGER
P S Gill
 25

In the above scenario, there will be tables for Entity Sets EMPLOYEE, BRANCH, JOB
and MANAGER. There will be one table for Relationship Set EBJM having Attributes
E#, B#, J# and Mgr-Id. No table is required for the Relationship Set EBJ because this
table would be a subset of table EBJM.

EBJM
E# B# J# Mgr-Id

E-R DIAGRAM OF AN AIRLINE RESERVATION SYSTEM

CAPACITY
AC_NO AC_TYPE

AIRCRAFT
TO_PLACE

FROM_PLAC ETD DATE ATD

CREW_NAM
E E
FLT_NO ATA
ETA
DESIGNATION
FLT_SCHEDULE FLIGHT CREW-ID

FLT_ CREW
CREW
C_DATE

CONFIRMED
CANCELLATION RESERVATION
SEAT_NO

TICKET_N
O ISSUE_DATE
AMOUNT
VOUCHER
_NO
FARE

P S Gill
 26

TICKET
REFUND
P_ADDRES
S
P_TEL_NO
P_NAME

PASSENGER

Where ETD: Estimated Time of Departure (i.e. scheduled take-off time).

ETA: Estimated Time of Arrival (i.e. scheduled landing time at the destination)
ATD: Actual Time of Departure. Initially, it will have a NULL value. It will get
defined after aircraft actually takes-off.
ATA: Actual Time of Arrival. Initially, it will have a NULL value. Its value will
get defined only after aircraft actually lands at the destination.

The above E-R Diagram can be reduced to the following set of tables:-

FLIGHT_SCHEDULE (FLT_NO, FROM_PLACE, TO_PLACE, ETD, ETA)

AIRCRAFT (AC_NO, AC_TYPE, CAPACITY)
CREW (CREW_ID, CREW_NAME, DESIGNATION)
FLIGHT (FLT_NO, DATE, AC_NO, ATD, ATA)
FLT_CREW (FLT_NO, DATE, CREW_ID)
TICKET (TICKET_NO, ISSUE_DATE, FARE, P_NAME, P_ADDR, P_TEL_NO)
RESERVATION (TICKET_NO, FLT_NO, DATE, CONFIRMED, SEAT_NO)
CANCELLATION (TICKET_NO, FLT_NO, DATE, VOUCHER_NO, C_DATE)
REFUND (VOUCHER_NO, AMOUNT)

Since, there is one-to-one relationship between TICKET and PASSENGER, a common

table TICKET will suffice for these two entity sets. Even the CANCELLATION table can
be combined with RESERVATION table, since there is many-to-one relationship between
RESERVATION and REFUND.

The SEAT_NO will get defined only after a passenger checks in for a flight.

P S Gill
 27

E-R DIAGRAM FOR VEHICLE INSURANCE

O_ADDRESS
O_TEL_NO

O-NAME

OWNER
PREMIUM

COLOR EXPIRY_DATE

MODEL
REG_NO
BONUS
POLICY_NO
MAKE

VEHICLE INSURANCE_POLICY

P_DAT
A_DATE E
A_REPORT_NO PAYMENT_
VOUCHER P_AMOUN
_NO T
PLACE

ACCIDENT CLAIM_PAYMENT

S_REPORT_NO
ASSESSED
_DAMAGE

SURVEYOR REPORT

REPAIR_ITEM
COST

P S Gill
 28

REF_NO

REPAIRS

Exercises

Ex.2.1 Explain the concept of Entity Sets and Relationship Sets.

Ex.2.2 Distinguish between the following:-

(a) Simple and Composite Attributes

(b) Single-Valued and Multi-Valued Attributes
(c) Stored and Derived Attributes

Ex.2.3 Explain the concept of Super Keys, Candidate Keys and Primary Keys of
an Entity Set. Explain the determination of Primary Key of a binary Relationship set.
How is it influenced by the Cardinality Mapping of the Entity Sets participating in the
Relationship Set?

Ex.2.4 Explain the concept Weak Entity Sets and Identifying Relationships.
Explain how a multi-valued attribute can be better modeled as a Weak Entity Set.

Ex.2.5 Explain the concepts of Specialization and Generalization. What are the
different types constraints involved in specialization? Distinguish between Total & Partial
Specialization and between Disjoint & Overlapping Specialization.

Ex.2.6 With an example illustrate how a Relationship Set can be aggregated as a

higher-level entity set, which can then participate in relationships with other relationship
sets and entity sets.

Ex.2.7 Draw E-R diagrams to indicate the following relationships between entity set
Operator and entity set Machine:-

(a) Each Machine can be operated by many Operators but each Operator can
operate only one machine.

(b) An operator can operate many machine and each machine can be operated
by many Operators.

Ex.2.7 Make E-R Diagrams for the following real-world situations (Indicate clearly
entity sets, relationship sets, cardinalities, attributes and candidate Keys. Also indicate

P S Gill
 29

any weak entity sets, specialization, generalization and aggregation etc.) Also reduce the
E-R diagrams to Tables:-

(a) An organization having a set of employees to execute a set of projects.

Each employee may be working on more than one project, each project is
managed by a manager and a manager is also one of the employees.

(b) A Tourist Management System catering to booking of hotels, taxies &

guides. It should also cater for cancellations, billing, payments etc.

(c) Preparation of time table of an Engineering College, catering for a number

of Sections (Year/Branch/Section), a number of courses, a number of
faculty members teaching the courses and a number of class rooms (ignore
labs). Make use of Aggregation and identify candidate keys.

P S Gill