MODULE II

Dr. Geetha Mary A

Associate Professor,
SCOPE, VIT

Sources:
Pearson Education, Inc. 2011, Elmasri/Navathe, Fundamentals of Database Systems, Sixth Edition
McGraw Hill Education , 2010, Silberschatz, Korth and Sudarshan, Database System Concepts, Sixth edition
Topic Outline
 Overview of Database Design Process
 Example Database Application (COMPANY)
 ER Model Concepts
 Entities and Attributes
 Entity Types, Value Sets, and Key Attributes
 Relationships and Relationship Types
 Weak Entity Types
 Roles and Attributes in Relationship Types
 ER Diagrams - Notation
 ER Diagram for COMPANY Schema
 Alternative Notations – UML class diagrams, others
Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of
Technology, Vellore
Overview of Database Design Process

 Two main activities:

 Database design
 Applications design

 Focus of this topic is on database design

 To design the conceptual schema for a database
application
 Applications design focuses on the programs
and interfaces that access the database
 Generally considered part of software engineering
Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of
Technology, Vellore
Overview of Database Design Process

Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of

Technology, Vellore
ER Model has detailed descriptions of

 What are the entities and relationships in the

enterprise?

 What information about these entities and

relationships should we store in the database?

 What are the integrity constraints or business

rules that hold?

Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of

Technology, Vellore
 Example COMPANY Database
 We need to create a database schema design based on the following
(simplified) requirements of the COMPANY Database:
 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. A department may have several locations.
 Each department controls a number of PROJECTs. Each project
has a unique name, unique number and is located at a single
location.
Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of
Technology, Vellore
Example COMPANY Database
(Contd.)
 We store each EMPLOYEE’s social security number, address,
salary, sex, and birthdate.
 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 a number of DEPENDENTs.
 For each dependent, we keep track of their name, sex, birthdate,
and relationship to the employee.
Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of Technology, Vellore
 ER Model Concepts
 Entities and Attributes
 Entities are specific objects or things in the mini-world that are
represented in the database.
 For example the EMPLOYEE John Smith, the Research DEPARTMENT, the
ProductX PROJECT
 Attributes are properties used to describe an entity.
 For example an EMPLOYEE entity may have the attributes Name, SSN, Address,
Sex, BirthDate
 A specific entity will have a value for each of its attributes.
 For example a specific employee entity may have Name='John Smith',
SSN='123456789', Address ='731, Fondren, Houston, TX', Sex='M', BirthDate='09-
JAN-55‘
 Each attribute has a value set (or data type) associated with it – e.g.
integer, string, subrange, enumerated type, …
Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of Technology, Vellore
ER Schema diagram of company DB

Dr.Geetha Mary A, Asso Prof, SCOPE,

Vellore Institute of Technology, Vellore
 Entity Sets
 A database can be modeled as:
a collection of entities,
 relationship among entities.

 An entity is an object that exists and is distinguishable

from other objects.
 Example: specific person, company
 Entities have attributes
 Example: people have names and addresses
 An entity set is a set of entities of the same type that
share the same properties.
 Example: set of all persons, companies, trees, holidays
Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of
Technology, Vellore
Entity Sets customer and loan
customer-id customer- customer- customer- loan- amount
name street city number

Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of

Technology, Vellore
 Attributes

 Entity is represented by a set of attributes(properties)

Eg:

customer = (customer-id, customer-name, customer-street, customer-

city)
loan = (loan-number, amount)

 Domain – the set of permitted values for each attribute

Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of

Technology, Vellore
 Attribute Types
 Simple and Composite
 Single valued and multi valued

Ph.No: Land line, Mobile

 Stored versus Derived Attributes:
 Age calculated from DOB
 DOB  Stored attribute

Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of

Technology, Vellore
 Composite Attributes

Grouping together related attributes

Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of
Technology, Vellore
 Attribute Types
 Null Values:
 College Degrees of person, apartment number
 Complex Attributes:
 Composite attribute and multivalued attributes are nested in an
arbitrary way.
 Composite attribute  parentheses ()
 Multivalued attribute  braces { }
 Eg:
{AddressPhone( { Phone(AreaCode,PhoneNumber)},
Address(streetAddress(number,street,apartmentNumber),
city,state,zip) ) }
Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of
Technology, Vellore
 Entity Types and Key Attributes

 Entities with the same basic attributes are grouped

or typed into an entity type.
 For example, the entity type EMPLOYEE and
PROJECT.
 An attribute of an entity type for which each entity
must have a unique value is called a key attribute of
the entity type. Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of
Technology, Vellore

 For example, SSN of EMPLOYEE.

Entity Types and Key Attributes
 A key attribute may be composite.
 VehicleTagNumber is a key of the CAR entity
type with components (Number, State).
 An entity type may have more than one key.
 The CAR entity type may have two keys:
 VehicleIdentificationNumber (popularly called VIN)
 VehicleTagNumber (Number, State),

 Each key is underlined

Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of
Technology, Vellore
 Displaying an Entity type
 In ER diagrams, an entity type is displayed in a
rectangular box
 Attributes are displayed in ovals
 Each attribute is connected to its entity type
 Components of a composite attribute are connected to the
oval representing the composite attribute
 Each key attribute is underlined
 Multivalued attributes displayed in double ovals
Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of
Technology, Vellore
 See CAR example on next slide
Entity Type CAR with two keys and a
corresponding Entity Set
Key
attributes

Entity set

Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of

Technology, Vellore
 Entity Set

 Each entity type will have a collection of entities stored in

the database
 Called the entity set

 Previous slide shows three CAR entity instances in the entity

set for CAR
 Same name (CAR) used to refer to both the entity type and
the entity set
 Entity set is the current state of the entities of that type that
are stored in the database
Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of
Technology, Vellore
 Initial Design of Entity Types for the
COMPANY Database Schema

 Based on the requirements, we can identify four

initial entity types in the COMPANY database:
 DEPARTMENT
 PROJECT
 EMPLOYEE
 DEPENDENT

 Their initial design is shown on the following slide

 The initial attributes shown are derived from the
Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of
requirements description Technology, Vellore
Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of
Technology, Vellore Initial Design of Entity Types:
EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT
 Weak Entity Types
 An entity that does not have a key attribute
 A weak entity must participate in an identifying relationship type with an owner
or identifying entity type
 Entities are identified by the combination of:
 A partial key of the weak entity type
 The particular entity they are related to in the identifying entity type
 Example:
 A DEPENDENT entity is identified by the dependent’s first name, and the
specific EMPLOYEE with whom the dependent is related
 Name of DEPENDENT is the partial key
 DEPENDENT is a weak entity type
 EMPLOYEE is its identifying entity type via the identifying relationship type
Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of
DEPENDENT_OF Technology, Vellore
 Weak Entity Sets
 Is an entity set that does not have a primary key
 Payment-number, payment date, payment amount
 Must be associated with a identifying entity set
 Loan
 Identifying relationship depicted using a double diamond
 The discriminator is a set of attributes that allows the
distinction.
 Payment-number
 The primary key of a weak entity set is formed by the
primary key of the identifying entity set , plus the weak
entity set’s discriminator.
 {loan-number,payment-number}
Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of
Technology, Vellore
 Weak Entity Sets (Cont.)
 weak entity set is depicted by double rectangles.
 discriminator of a weak entity set is underlined with a dashed
line.
 payment-number – discriminator of the payment entity set
 Primary key for payment – (loan-number, payment-number)

Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore

Institute of Technology, Vellore
Entity-Relationship (E-R) Modeling

 Relationship
 An association between the instances of one or more
entity types that is of interest to the organization

 Association indicates that an event has occurred or

that there is a natural link between entity types

 Relationships are always labeled with verb phrases

Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of

Technology, Vellore
Naming and Defining Relationships

 Relationship name is a verb phrase

 Avoid vague names

 Guidelines for defining relationships

 Definition explains what action is being taken and why it is
important

 Give examples to clarify the action

 Optional participation should be explained

 Explain reasons for any explicit maximum cardinality

Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of
Technology, Vellore
Naming and Defining Relationships

 Guidelines for defining relationships

 Explain any restrictions on participation in the
relationship

 Explain extent of the history that is kept in the

relationship

 Explain whether an entity instance involved in a

relationship instance can transfer participation to
another relationship instance
Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of
Technology, Vellore
Relationships

 Relationship Types and Sets

 Relationship Degree

 Entity Roles and Recursive Relationships

 Relationship Constraints

 Attributes of Relationship Types

Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of

Technology, Vellore
 Relationship Types and Sets

A Relationship is an association among two or more entities

(e.g John works in Pharmacy department)

 A Relationship Type defines the relationship, and a

Relationship Set represents a set of relationship instances

 A Relationship Type thus defines the structure of the

Relationship Set

Relationship Type and corresponding Set are customarily referred to

by the same name
Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of
Technology, Vellore
 Relationship Degree
 The degree of a relationship type is the Departments
number of participating entity types
– 2 entities: Binary Relationship
3 entities: Ternary Relationship Works_In Binary
n entities: N-ary Relationship
– Same entity type could participate in
multiple relationship types Employees

Multiple
Supplier Supply Project Assigned_to

Ternary

Part

Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of

Technology, Vellore
 Entity Roles

 Each entity type that participates Departments

in a relationship type plays a employer

particular role in the relationship
type Works_In
Role
Names
 The role name signifies the role
worker
that a participating entity from
the entity type plays in each Employees
relationship instance, i.e. it
explains what the relationship
meansDr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of
Technology, Vellore
Recursive Relationships

 Same entity type can participate more than once in the same
relationship type under different “roles”

 Such relationships are called “Recursive Relationships”

Employees

Recursive Supervisor Subordinate

Relationship

Supervision

Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of

Technology, Vellore
Relationship Constraints

What are Relationship Constraints ?

 Constraints on the relationship type limit the

possible combination of entities that may participate
in the corresponding relationship set

Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of

Technology, Vellore
Kinds of Constraints

What kind of constraints can be defined in the ER

Model?
 Cardinality Constraints
 Participation Constraints
Together called “Structural Constraints”

Constraints are represented by

specific notation in the ER diagram

Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of

Technology, Vellore
 Possible Cardinality Ratios
 The “Cardinality Ratio” for a binary
relationship specifies the number of Departments

relationship instances that an entity

can participate in Works_In
– Works-In is a binary relationship
– Participating entities are
Employees
DEPARTMENT : EMPLOYEE
– One department can have
Many employees -
Cardinality Ratio is 1 : N Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of
Technology, Vellore
Possible Cardinality Ratios
. .
 1–to-1 (1 : 1) . .
– Both entities can . .
participate in only one
1-to-1
relationship instance .
 1-to-Many, Many-to-1
. . . .
. . .
(1 : N, N : 1) . . .
– One entity can . .
participate in many
.
1- to - Many Many - to -
relationship instances 1
 Many-to-Many (N: M) . .
– Both entities can participate in
many relationship instance . .
. .
Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of
Technology, Vellore
.
Many-to-Many
Example Cardinality Constraints

How many Employees can work in a Department?

One employee can work in only one department

How many Employees can be employed by a Department?

One department can employ many employees

How many managers can a department have?

One department can have only one manager

How many departments can an employee manage?

One employee can have manage only one department

Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of
Technology, Vellore
Representing Cardinality

N Works_In 1

Employees Departments

1 Manages 1

One employee can work in only one department

One department can employ many employees

One department can have only one manager

One employee can manage only one department

Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of
Technology, Vellore
Existence Dependency
 Existence dependency indicates whether
the existence of an entity depends on its Departments

relationship to another entity via the

relationship type Works_In

– Every employee must work for

a department - EMPLOYEE is Employees

existentially dependent on
DEPARTMENT via the Works In
relationship type
Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of
Technology, Vellore
Kinds of participating constraints

 TOTAL Participation (Existence Dependency)

Constraint : Every employee must work for a

department

 PARTIAL Participation

Constraint : Not every employee is a manager

Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of

Technology, Vellore
Representing Participation
Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of
Technology, Vellore

N Works_In 1

Employees Departments

1 Manages 1

Every employee must work for a department

Every department must have a manager
Every department must have employees
Not every employee is a manager
 Attributes of Relationship types
 A relationship type can have attributes:
 For example, HoursPerWeek of WORKS_ON
 Its value for each relationship instance describes the number
of hours per week that an EMPLOYEE works on a PROJECT.
A value of HoursPerWeek depends on a particular
(employee, project) combination
 Most relationship attributes are used with M:N relationships
 In 1:N relationships, they can be transferred to the entity
type on the N-side of the relationship
Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of
Technology, Vellore
Recursive Relationship Type is: SUPERVISION
(participation role names are shown)

Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of

Technology, Vellore
 Alternative (min, max) notation for
relationship structural constraints:
 Specified on each participation of an entity type E in a relationship type
R
 Specifies that each entity e in E participates in at least min and at most
max relationship instances in R
 Default(no constraint): min=0, max=n (signifying no limit)
 Must have minmax, min0, max 1
 Derived from the knowledge of mini-world constraints
 Examples:
 A department has exactly one manager and an employee can manage
at most one department.
 Specify (0,1) for participation of EMPLOYEE in MANAGES
 Specify (1,1) for participation of DEPARTMENT in MANAGES
 An employee can work for exactly one department but a department
can have any number of employees.
 Specify (1,1) for participation of EMPLOYEE in WORKS_FOR
 Specify (0,n) for participation of DEPARTMENT in WORKS_FOR
Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of
Technology, Vellore
The (min,max) notation for relationship
constraints

Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of

Technology, Vellore
Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore
Institute of Technology, Vellore

max) notation
COMPANY ER Schema Diagram using (min,
Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of
Technology, Vellore
Summary of notation for ER diagrams
Alternative diagrammatic notation

ER diagrams is one popular example for displaying

database schemas
Many other notations exist in the literature and in
various database design and modeling tools
UML class diagrams is representative of another
way of displaying ER concepts that is used in several
commercial design tools
Dr.Geetha Mary A, Asso Prof, SCOPE, Vellore Institute of
Technology, Vellore