Chapter No.

2
Database Design using ER Model
 Database Design Process
• There are six steps:
Step 1:
Requirement Analysis:
– What data should be stored?
– What applications must be built?
– What operations are most frequent and subjected to performance
requirements?
Step 2 :
Conceptual database design:
– High-level description of data to be stored and constraints.
– Often carried out using the ER model.
Step 3 :
Logical Database design:
– Choose a DBMS to implement our database design..
– Convert the conceptual database design into a database
schema for the chosen DBMS (e.g., convert ER schema into a
relational database schema)
• Step 4:
Schema Refinement:
– Analyze the collection of relations in our relational database.
– Identify the potential problems.
– Refine the schema.
Step 5:
Physical database design:
– Ensure that the design meets the performance requirement.
– Build index, clustering some tables etc..
– Redesign parts of the database schema.
Step 6:
Application and security design:
– Write application programs.
– Identify data that can be accessible by certain types of users.
– Take steps to ensure that access rules are enforced.
 2.1 Entity-Relationship Model
• Entity-Relationship (ER) model is a popular
conceptual data model.
• This model describes data to be stored and the
constraints over the data.
• E-R model views the real world as a collection of
entities and relationships among entities.
• Diagrams created by this process are called entity-
relationship diagrams, ER diagrams, or ERDs.
 Entities and attributes
• An entity is an object in the real world that is
distinguishable from other objects.
• An entity is described using a set of attributes
whose values are used to distinguish one
entity from another of the same type.
 Entity Types
• Strong (Regular) Entity:
An entity that exists independently of other
entity types
Ex: Employee.

• Weak Entity:
An entity types whose existence depends on some
other entity.
Ex: Dependents.
• Example:

Employee = (name, address, age, phone)

Employee 1 Employee 2

Name = Chetan Mane Name = Ramesh Sen

Address = Sr 41, Karve Road Address = 25, Big Street, Shatin

Age = 55 Age = 20

Phone = 1234-5667 Phone = 2338-7779

 Entity set
• An entity set is a collection of entities of the
same type.
e1
(Amit, 55, …)

e2
Employee = (name, address, age, phone) (Ajay, 20, …)

e3
(Raj, 33, …)
 Types of Attributes
• Simple Attribute:
Attributes that can’t be divided into subparts are
called Simple or Atomic attributes.
• Each entity has a single atomic value for the
attribute.
For example: SSN or Age.

• Composite Attribute:
The attribute that can be divided into smaller
subparts.
 For example:
Address (Apt#, House#, Street, City, State, ZipCode,
Country) or
Name (FirstName, MiddleName, LastName).
• Single-valued Attribute:
Attributes that can have single value at a particular
instance of time are called single valued.
• A person can’t have more than one age value.
• Therefore, age of a person is a single-values
attribute.
• Multi-valued Attribute:
An attribute can have more than one value at one time.
For example
Degree of a person is a multi-valued attribute since a person can
have more than one degree.
• In general, composite and multi-valued attributes may be
nested arbitrarily to any number of levels although this is
rare.
• For example:
Previous Degrees of a STUDENT is a composite multi-valued
attribute denoted by {Previous Degrees (College, Year,
Degree, Field)}.
Cell No
• Stored Attribute:
An attribute whose valued is stored in the database.
Any attribute can be a stored attribute.
Ex: Date of birth is the stored attribute.

• Derived Attribute:
An attribute whose values can be calculated from
related attribute values.
For Example:
i)Years Employed (using Employee Date of Joining).
ii)Age (using Date of Birth).
iii)Net Salary (using Gross Salary)
Representation of E-R Model
Meaning
Symbol
ENTITY TYPE

WEAK ENTITY TYPE

RELATIONSHIP TYPE

IDENTIFYING RELATIONSHIP TYPE

ATTRIBUTE

KEY ATTRIBUTE

MULTIVALUED ATTRIBUTE
 2.2 Relationships and Relationship
Types
• A relationship relates two or more distinct entities
with a specific meaning.
• 1.For example:
• EMPLOYEE John Smith works on the ProductX
PROJECT or
• EMPLOYEE Franklin Wong manages the Research
DEPARTMENT.
Example relationship instances of the WORKS_FOR relationship
between EMPLOYEE and DEPARTMENT
EMPLOYEE WORKS_FOR DEPARTMENT

r1
e1   d1

e2  r2

e3  r3  d2

e4  r4
 d3
e5 
r5
e6 
r6
e7 
r7
Example relationship instances of the WORKS_ON relationship
between EMPLOYEE and PROJECT

r9
r1
e1   p1

e2  r2

e3  r3  p2

e4  r4
 p3
e5 
r5
e6 
r6
e7 
r 8 r7
EMPLOYEE PROJECT
WORKS_ON
• More than one relationship type can exist with the
same participating entity types.
• For example:
• MANAGES and WORKS_FOR are distinct
relationships between EMPLOYEE and
DEPARTMENT, but with different meanings and
different relationship instances.
2.For EXample:

Lecture = ( John, Ada, David, Peter )

Course = ( Java, VB, C, C++ )

Lectuer teach Course

John Java

Ada VB

David C

Peter C++
• A relationship set is a collection of similar relationships.
• Example:
{(John, C++), (David, C),(David,Java)}

Lectuer teach Course

John C

Ada C++

David VB

Peter Java
 2.3 Detailed Conceptual Design:
Dept.:
Dept No unique identifier of a dept. Identifier
Dept Name name of a department Unique
Location location of a department Multi-valued
Phone phone no. of a department
Employees no. of employees in a dept. Derived
Dept No

Dept Name

Department Location
Phone
Employees
Project:
Name
Number
Location

Proj No unique identifier of a project Identifier

Proj Name name of a project Unique
Location location of a project

Proj No

Project Proj Name

Location
 Employee:

Emp No unique identifier of an emp. Identifier

Emp Name name of an employee Composite
First Name first name of an employee
Mid Initials middle initials of an employee
Last Name last name of an employee
NID national id of an employee Unique
Address address of an employee
Salary salary of an employee
Gender sex of an employee
DOB birth date of an employee
Employee:
First Name
Emp No
Mid Initials
Emp Name
Last Name
Employee NID

Address

Salary

Gender
DOB
Dependent:

Name Sex Birth Date Relationship

Depd Name name of a dependent Part of Key

Gender sex of a dependent
DOB birth date of a dependent
Relation relationship of a dependent to an employee
Depd Name
Gender
Dependent DOB
Relation
 Example: COMPANY Database

• Requirements of the Company:

• The company is organized into DEPARTMENTs.
• Each department has a name, number and an employee
who manages the department.
• We keep track of the start date of the department
manager.
• Each department controls a number of PROJECTs.
• Each project has a name, number and is located at a single
location.
• We store each EMPLOYEE’s social security number,
address, salary, sex, and birth date.
• Each employee works for one department but may work
on several projects.
• We keep track of the number of hours per week that an
employee currently works on each project.
• We also keep track of the direct supervisor of each
employee.
• Each employee may have/has a number of DEPENDENTs.
• For each dependent, we keep track of their name, sex,
birthdate, and relationship to employee.
 ER-Diagram of Company Database:
supervises Works_for D_no D_name
Ssn

Employee Department
manages

Name
Add

have controls
Works_on

Dependents Hours Projects

Name Sex DOB P_no Pname Loc

 Constraints on Relationships

• Constraints on Relationship Types:

( Also known as ratio constraints )

Maximum Cardinality:
• One-to-one (1:1)
• One-to-many (1:N) or Many-to-one (N:1)
• Many-to-many
Minimum Cardinality:
(Also called participation constraint or existence
dependency constraints)
• zero (optional participation, not existence-dependent)
• one or more (mandatory, existence-dependent)
 Many-to-one (N:1) RELATIONSHIP
EMPLOYEE WORKS_FOR DEPARTMENT

r1
e1   d1

e2  r2

e3  r3  d2

e4  r4
 d3
e5 
r5
e6 
r6
e7 
r7
 Many-to-many (M:N) RELATIONSHIP

r9
r1
e1   p1

e2  r2

e3  r3  p2

e4  r4
 p3
e5 
r5
e6 
r6
e7 
r 8 r7
Representation of Relation ships:
Alternative Representation of Relation ships:
• Participation Constraints:
Two types of participation constraints are there they
are total participation constraint and partial
participation constraint.
• The entity set department in the relation set
manages is said to be total as every department is
managed by an employee.
• And a participation which is not total is partial
participation.
• For Example:
The participation of entity set employee in manages is
partial since not every employee get to manage a
department.
 Example of Participation constraints:

Name
SSN
Loc D_id Dname

Employee manages Department

Since Budget
 Class Hierarchy:
Some times we classify the entity set into subclasses.

• For example:
We might want to divide employee set into
Hourly_emp set and Contract_emp set to
differentiate on the basis on which they are paid.
• We have attributes like Hourly_worked and
Hourly_wages. And Contract_id for contract
employee.
• So here the attributes of employee entity set are
inherited by
 the Hourly entity set and Contract entity set
with their own additional attributes.
• This concept is called inheritance, used in
programing languages such as C++, Java…
• So a query that asks for all employee entities
must consider all Hourly employee and
Contract employee entries as well.
 Example of Class Hierarchy:
Ename
Eid Lot

Employee

ISA

Hourly_emp Contract_emp

Hourly_wages Hours_worked Contract_id

A class hierarchy can be viewed in one of the
two ways:
• Specialization and Generalization.
• Employee specialized into subclasses i.e
specialization is the process of identifying
subsets of an entity set
• So super class is defined first and then sub-
classes specific attributes and relation sets are
then added.
• The process of identifying subsets of an
entity set that share some distinguishing
characteristics is specialization.
• 2.For Example:
We might identify a subset of students as
Undergraduate, another one as
Postgraduate

Student

Undergraduate Postgraduate
 Example of Specialization:
Ename
Sid total

Student

ISA

Under Graduate Post Graduate

GPA College Study_mode C_title

 2.4 Generalization
• Specialization is a top-down approach
Identifying subsets of an entity set that share some distinguishing
characteristics.

• Generalization is bottom-up approach

Find out the common set of features shared by different entity
sets.

• In simple, generalization is an inversion of specialization.

• That is the Hourly and Contract employees are generalized
by Employee.
• As another example Motorboats and Cars may be
generalized into an entity set Motor_vehicles.
• Generalization consists of identifying some common
characteristics of a collection of entity set, and
creating new entity set that contains entities
possessing their common characteristics.
• Here typically, the subclasses are defined first super
class is defined next and relation ship sets involving
super class are defined.
• It is the inverse of specialization approach.
 2.4 Aggregation
• A relationship set (identified by dash box)
participates in another relationship set is known as
aggregation.
• Aggregation is used when we need to express a
relation among relation.
 Motivation
• Sometimes, we have to model a
relationship between a collection of
entities and relationships

• In the figure sponsors relationship set

and its participating entities in dash box
are in aggregation as they participate
with another relationship set monitors.
ER-Diagram: Ename

Eid Employee Salary

monitors Until

Startdate Since

Projects Department
sponsors

Pid Pbudget Did Dname

 How could we represent relationship among
relationships?

Customer borrower Loan

Loan-

officer
Employee

•Each customer-loan pair may have a bank employee who is the loan officer for that
particular pair.
•There is redundant information in the figure, since every customer-loan pair in
loan-officer is also in borrower.
•Not a good choice.
 How could we represent relationship
among relationships?

Customer Loan

combine
relation

Employee

•Combine 2 relationship into 1

–Obscure the logical structure
–For every customer-loan pair, exactly one loan officer must be
assigned
–Still not a good choice
 The aggregation solution
• Aggregation is an abstraction through which
relationships are treated as higher-level entities.
– Regard the whole relationship, including relationship set
borrower, entity set customer and loan as a single high-level
entity

Customer borrower
Loan
E-R Diagram of Aggregation

Customer borrower
Loan

Loan-
officer

Employee