Database Management

Systems I

Conceptual Database Design: ER Modelling

Lecture 2 - 3
Objectives

 Database system development lifecycle

 Phases of database design

 Relational Database design

 Introduction to ER Modelling
Database Design

 How do we design a database for an

application?
 Design process - divided into 6 steps:

 Requirements Analysis
 Conceptual Database Design
 Logical Database Design
 Schema Refinement
 Physical Database Design
 Security Design
Requirements Analysis
 This step answers the following question:
 “What users want from the database?”
- What is going to be stored in the database?
- What applications are going to be built on top
the database?
- what are the most frequently asked queries?
Result:
A well-written concise document
enumerating the user’s requirements.
Requirement Analysis (contd.)

 Eg. Library database…

 Data to be stored can be…

 Record of all books in the library
 Record of members of the library
 Students
 Faculty
 Other members
 Record members’ borrowing information
Requirements Analysis (contd.)

Some applications on top of the

database can be…

 Renewal service (may be on-line)

 Borrowing-Lending service
 Resource reservation system (may be
on-line)
 Resource request service (may be on-
line)
Conceptual Database Design

The information gathered in the requirements

analysis phase is used to create a:

high-level description of the data in a

conceptual data model or Semantic Data
Model.

Eg. ER Model
Logical Database Design

 In this step, we determine the DBMS to

implement the database & also the data
model.

 We utilize the conceptual schema created

in the previous step and convert it into a
schema of a particular data model* (e.g.
Relational Data Model )

 *we will cover this in the next two lectures.

Schema Refinement

The schema created by the logical

database design phase is further
refined for potential problems such as
redundancies.
Physical Database Design

In this step, performance criteria are

taken into consideration and further
enhancements to the schema &
creation of indexes are considered.
Security Design

In this step, different user groups and

their roles are identified.

Appropriate levels of access are then

provided to the data ensuring that
users have access to only the
necessary data.
Entity-Relationship (ER) Model

Requirements gathering

Conceptual database design

high level data model(ER)created

The 2 main constructs of the ER model:

entities , relationships.

different books use different graphical notation.

ER Diagrams
NOTATION FOR ER
Symbol Meaning

ENTITY

WEAK ENTITY

RELATIONSHIP

IDENTIFYING RELATIONSHIP

ATTRIBUTE

KEY ATTRIBUTE

MULTIVALUED ATTRIBUTE

COMPOSITE ATTRIBUTE

DERIVED ATTRIBUTE
E1 R E2
TOTAL PARTICIPATION OF E2 IN R
1 N
E1 R E2
CARDINALITY RATIO 1:N FOR E1:E2 IN R
(min,max)
R E
STRUCTURAL CONSTRAINT (min, max) ON
PARTICIPATION OF E IN R
 Entity
 An entity is an object in the real world with an independent
existence (place, person, car, house, company, job, university, etc).

 A collection of similar entities is called an entity set.

 Graphically,
ENTITY Student

 First letter of each word in the entity name is uppercase

 E.g., Student

 Normally an entity is named using a ‘noun’ or ‘noun

phrase’
Attributes
 An entity is described using a set of
attributes
 Graphically, Oval.
attribute

name
 For example staff has 3 attributes
 Name
Staff position
 Position
 Salary
salary
 Entity Set

Example: name, id, age & salary are

attributes in Employee entity
salary
name
e1 salary
age id
e2
e3
age
e4
Employee
e5
e6 id
…

name
Employee Entity set
Domain of an Attribute

 The domain of an attribute specifies

the set of possible values that the
attribute can have.

age : integer values from 0 - 120

name: 20 character string

Composite Attributes

 Composite attributes can be

divided into smaller subparts.

Graphically, Employee
name

surname first_name middle_name

Your Turn!!

 Give an example of composite

attribute.
 Sub divide it into atomic attributes
Multi valued Atributes

 Attributes containing multiple values

are called multivalued attributes.
Double lines
Employee

phone
first_name
surname

(Direct phone ), extension, mobile no

Your Turn!!

 Give an example of multi valued

attribute.

 Assign data to it
Derived Attributes

 Some attributes can be derived - called

derived attributes. Dotted line
 For example, age is derived from date
of birth & current date.
Employee

name age

Derived attribute
An exercise
stuNu stuName stuMajor stuDob stuHrs stuY stuGp stuAge
m r a

210345 Aunt Annie IT, Fine 14 Feb 23 2 3.26 19

6 Art 1983

300638 Bert Baxter IT 23 Jun 33 3 2.59 22

1 1980

200782 Corinne IT, 5 Oct 27 1 3.59 20

4 Creevey Education 1981

765080 David Doo Arts 28 Aug 16 1 0 16

2 1985

963596 Eli Edwards Arts, 15 Nov 35 2 2.73 19

2 Teaching 1982

211384 Fiona IT 30 Jul 28 2 3.27 21

3 Fawcett 1981
Tick where applicable

Attribute simple single- composit multivalu derived

valued e ed
stuNum          

stuName          

stuMajor          

stuDob          

stuHrs          

stuYr          

stuGpa          

stuAge          
 Key Attributes
 A key attribute minimal set of
attributes which uniquely identifies an
entity in the entity set. Underlined

salary name
e1
age id
e2
e3
e4
e5
Employee Entity set
e6
…
Primary Key

 There can be multiple key attributes

called candidate keys in a single
entity.
 A single candidate key is designated as
the primary key.
Name

Employee

Candidate
eid nic
key
Composite Key
 Sometimes, a group of attributes make
up the key. This is called a composite
key.

 Example :
Composite key = (First name + surname + tel)

Key = NIC
Relationship
 Relationship is an association among two or more entities.
Diamond
 Collection of similar relationships - relationship set .
 Shown as a line connecting the associated entities, labelled with
the name of the relationship.

 Normally a relationship is named using a ‘verb’ or ‘verb group’.

N 1
Employee Works in Department

relationship
Descriptive Atributes

A relationships can also have descriptive

attributes . Used to record information about the
relationship rather than any one of the participating
entities.
since

N 1
Employee Works in Department

Nimal works in accounts dept since 2008

Descriptive Attributes

1/2/97

111 1/2/99
D1
222
1/5/01
D2
333 1/2/87
D3
444
1/3/95

Departments
Employees
Work_in
Degree of Relationship type

 Degree of a relationship is the number of

participating entities in the relationship.

 Relationships can be classified based on their degree

into

 Binary – relationship with two participants

 Ternary – relationship with three participants
 Quaternary – relationship with four participants

 Eg??
A Ternary Relationship

 A diamond is used to represent ternary and quaternary

relationships

Employee Works in Department

Location
Cardinality
The cardinality ratio for a binary relationship
specifies the number of relationship instances
that an entity can participate in.

 There are three types of cardinality ratios for

binary relationships.

 one-to-one (1: 1)
 one-to-many (1 : N)
 many-to-many. (N : M)
One-to-One relationship

 An employee manages at most one

department. A department can have
only one manager managing it.

1 1
Employee Manages Department
Your Turn !!

 Give an example of a 1:1 relationship

One-to-Many relationship
 An employee works in at most one
department.

N 1
Employee Works in Department

 This is a one-to-many (or many-to-one)

relationship
Your Turn !!

 Give an example of a 1:N relationship

Many-to-many relationship

 Example: An employee can work on

several projects. A project can have
many employees working on it.
M N
Employee Works on Project
Your Turn !!

 Give an example of a N:M

relationship
ER Diagram
Participating Constraints

 Participating constraint specifies

whether the existence of an entity
depends on its being related to
another entity via the relationship
type.
Participation Constraints
 For example, if we specify that an employee
must always work for a department.
 Then we say that the relationship “works in”
is in total participation from employee
entity to department entity.

Employee Works in Department

(double lines)
Employee must work in a department total participation
Department may or may not have employees
E-R Model (contd.)

 If the relationship is not in total

participation, then it is known as in partial.

 For example, from Department to Employee

 Department may or may not have

Employees
Participation Constraints

Participation Constraint
Student?
Your Turn !
Your Turn !!!

 Identify the entities -> nouns

 Identify the relationships -> verbs

 Determine
 Cardinality

 Participation (total / partial)

Weak Entity
 Some entities cant exist on its own.
 It is existence-dependent on another entity,
i.e., it cannot exist without the entity with
which it has a relationship.

 It inherits at least part of their primary key

from the entity to which it is related.

 Entity types without any key attributes is called

weak entity types. Double lined box
 A weak entity is uniquely identified by
considering some of its attributes
with the primary key of another
entity called the identifying owner.
 he attributes in the weak entity
participating in the key are called
partial keys.
E-R Model (contd.)

 The owner entity and the weak entity

participates in an identifying relationship.

 The cardinality of the identifying relationship

is either one-to-one or one-to-many from
owner entity to weak entity.

 The weak entity must have total

participation in the identifying relationship.
E-R Model (contd.)
Identifying relationship
Weak entity

1 M
Employee Policy Departments

id name age

Strong entity Partial key

Recursive Relationship

 Entities participating in a relationship

need not be distinct. Such relationships
are called recursive relationships.

 Each entity in the relationship play a role

in the relationship. It is recommended to
state the role in recursive relationships.
E-R Model (contd.)

Example,
manages

supervisor subordinate

Employee
Your Turn !
 Draw an ER diagram for the following
requirements.

 A company database needs to store

information about employees (identified by
NIC, salary, position, phone, office);
 departments (identified by dno, with
department name and annual budget);
 children of employees (with name, and age
as attributes).
 Employees work in departments;
each department is managed by an
employee; a child must be identified
uniquely by name when the parent
(who is an employee; assume that
only parent works for the company) is
known. We are not interested about a
child once the parent leaves the
company.
 Alternate Notaation – Min..Max

 Used to specify the number of possible occurrences of each

participating entity type in a relationship.

 has two parts

 Min
 Max
 For example, (0,1)
 Min = 0
 Max = 1

 Max of a multiplicity range denotes Cardinality

 Min of the range denotes Participation constraint

 The (min,max) notation

(1,1)
(0,1)

1 1

Employee may or may not mange a department. He can at most

manage one department.
A department must be managed by an employee
 The (min,max) notation

(1,N)
(0,1)

N 1
Employee may or (NN
may not mange a department. He can at most
manage one department.
A department must be managed by an employee
Enhanced ER Modelling

 ER modelling does not capture all the semantics of

client’s domain, such as

 ‘ISA’ (‘is a’) relationship or specialization-

generalization
 ‘Manager’ entity type ‘is a’ subentity of ‘Staff’ entity.

 Enhanced ER models represent the above

relationships
 Therefore capture client’s domain more
comprehensively.
 Diagrammatic Representation of ‘ISA’
relationship
name
position
staffNo

salary
Staff

Specialization/generalization indicator

ISA
Manager & supervisor
Is of the type Staff
Manager Supervisor

bonus
mgrStartDate
 Your Turn !
 A university database contains information about
professors (identified by social security number, or SSN)
and courses (identified by course id). Professors teach
courses ;each of the following situations concerns the
Teaches relationship set. For each situation, draw an ER
diagram that describes it (assuming no further constraints
hold).

1. Professors can teach the same course in several semesters,

and each offering must be recorded.

2. Professors can teach the same course in several semesters,

and only the most recent such offering needs to be recorded.(
Assume this condition applies in all subsequent questions.)
3. Every professor must teach some course.

4. Every professor teaches exactly one

course (no more, no less)

5. Every professor teaches exactly one

course(no more , no less),and every
course must be taught by some professor
Your Turn!

 Considering the following requirements (in a

University), draw an ER diagram:

 The university keeps track of the each

student’s name (last name, first name &
other names), student number, national
identity card number, current address and
phone, permanent address and phone,
birthdate, sex, level, major department,
minor department (if any), program
(Bachelor’s, PGDIT, Master’s, …).
 Both student number and national
identity card numbers have unique
values for each student.
Your Turn! (contd.)
 Each department is described by a name,
department code, office number, office
phone, and college. Both name and code
have unique values for each department.

 Each course has a course name,

description, course number, number of
semester hours, level, and offering
department. Both course name and course
number are unique.
Your Turn! (contd.)

 Each section has an instructor, semester,

year, course and section number. The
section number distinguishes different
sections of the same course that are
taught during the same semester/year; its
values are 1, 2, 3, …, up to the number of
sections taught during each semester

 A grade report has a student, section,

letter grade and numeric grade (0 – 100)