Unit -2

Chapter 7

Data Modeling Using the

Entity-Relationship (ER) Model
Chapter Outline
 Using High-Level Conceptual Data Models for
Database Design
 A Sample 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
Overview of Database Design Process
Steps:

 Requirements collection and Analysis

 Functional Analysis – user defined operations

 Conceptual Design

 Logical Design

 Physical Design
 Application Program Design
 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.
 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.
 Entity types, Entity sets, Attributes and Keys

• E-R modeling: A graphical technique for

understanding and organizing the data
independent of the actual database
implementation.

• Entities and Attributes:

Entity: Any thing that may have an independent

existence and about which we intend to collect
data.

Ex: particular person, car, house or employee.

 Attributes: Properties / characteristics that
describe entities

 The set of possible values for an attribute is

called the domain of the attribute.
Ex:- The domain of attribute marital status is
just the four values: single, married, divorced,
widowed
– for month - 12 values ranging from Jan to Dec

 Key attribute: The attribute (or combination of

attributes) that is unique for every entity instance
Ex:- the account number of an account, the
employee id of an employee etc.
 Key attribute of an entity type. – An attribute
whose value are distinct for each individual
entity in the entity set
Ex: Composite attribute
Types of Attributes
1. Simple Vs Composite attribute

Simple attribute: cannot be divided into

simpler components
E.g:

Composite attribute: can be split into

components
E.g: Address, Name
2. Single Vs Multi-valued Attributes

 Single valued : attributes have a single value

for a particular entity
Ex: Age attribute

Multi-valued: Attribute that can have many

values
Ex: Color attribute of a car
3. Stored Vs Derived attribute

Stored Attribute: Attribute that need to be

stored permanently.
Ex: name of an employee, Birth date

Derived Attribute: Attribute that can be

calculated based on other attributes
Ex: Age
 NULL values
 Used when particular entity may not have an
 Applicable value
 Do not know the value
 Value is missing

 Complex Attributes
 Arbitrary Nesting of Composite and Multivalued
attributes
 (),{}
Ex: If a person can have more than one residence and
each residence can have a single address and multiple
phones, an attribute Address_phone for a person can
be specified as
Address_phone ({Phone (Area_code, Phone_number)},
Address (Street_address (Number, Street,
Apartment_number), City, State, Zip) ) }
Entity Types, Entity Sets, Keys and Value sets
 Entity type: a collection of entities that have the
same attributes.
 Ex: employee, student, etc.,

 Entity set: Is a collection of entities of a same

type that share the same properties or attributes.
 The entity set is usually referred to using the
same name as the entity type.
 Ex: Employee – refers to both entity type as
well as the current set of all employee entities
in the db.
Two entity types, EMPLOYEE and COMPANY, and
some member entities of each.
 Initial Conceptual Design of the Company
Database
 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
requirements description
 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.
 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.
Relationship, Relationship Types, Relationship
sets, Roles and Structural Constraints.

 Relationship : Association between several

entities
ex: Employee – worksfor – Department

 Relationship type: A relationship type R among

n entity types E1, E2,…..En defines a set of
association among entities from these entity
types.

 Relationship set: is a set of relationships of the

same type
 Relationship instance: Associates n individual entities
and each entity in relationship is member of entity type.
 Ex: If works_for is the relationship between the
Employee entity and the Department entity, then
‘Ram works for CS Department’, ‘Shyam works for
electrical Department’ etc., are relationship instances
of the relationship works_for.

 Mathematically, the relationship set R is a set of

relationship instances ri, where each ri associates n
individual entities (e1, e2,… en) and each entity ej in ri is
a member of enity type Ej, 1 ≤ j ≤ n.

 Each of the individual entities e1, e2, …en is said to

participate in the relationship instance ri = (e1, e2, …
en).
Relationship Degree
 Degree of a Relationship
- Is the number of entity types involved in a
relationship.
 Types
• One - Unary
• Two - Binary
• Three - Ternary

Ex : employee manager-of employee is unary

employee works-for department is binary
customer purchase item, shop keeper is a
ternary relationship
Role name

 A role name specifies what role an entity type

plays in a specific relationship
 Role names are sometimes used in ER-
diagrams to clarify the roles of the participating
entity types.
Recursive Relationship Type

 In a relationship where same entity type

participate more than once in a
relationship type in different roles
Ex: the SUPERVISION relationship

 EMPLOYEE participates twice in two

distinct roles:
 supervisor (or boss) role
 supervisee (or subordinate) role
Constraints on Binary Relationship Types

 Relationship types usually have certain

constraints that limit the possible combinations
of entities that may participate in the
corresponding relationship set.

 Two main types:

 Cardinality ratio

 Participation
Cardinality Ratios for Binary Relationships
 Specifies the maximum number of relationship
instances that an entity can participate in.
 Possible Cardinality ratios for binary relationship
types are :
– one-to-one (1:1)
– one-to-many (1:N)
– many-to-many (M:N)
Ex: employee head-of department (1:1)
student enrolls course (m:n)
lecturer offers course (1:n) assuming a
course is taught by a single lecturer
Participation Constraints and Existence Dependence

 Specifies whether the existence of an entity

depends on its being related to another entity via
the relationship type.

 Specifies the minimum number of relationship

instances that each entity can participate in, and
is some times called the minimum cardinality
constraints.

 Two types:
 Total participation

 Partial participation
Total Participation :
 Every entity instance must be connected through the
relationship to another instance of the other participating
entity types.
 Here the participation of Employee in works_for is called
total participation.
 Means, every entity in the total set of employee
entities must be related to a department entity via
Works_for.

 Total participation is also called as existence

dependency
Partial participation

 All instances need not participate.

Ex: Employee Head-of Department

Employee: partial
Department: total
 Attributes for relationship types
 Also a relationship type can have attributes.

E.g. in the case where the weekly number of

hours an employee works on a project should be
kept, that can be represented for each instance
of the relation “works-on”.
 If the relation is a 1:1 or 1:N relation, the
attribute can be stored at one of the participating
entities.
 When the relation is of the type M:N one must
store the attributes with the instance of the
relation.
Regular Entity type

 Regular Entity: Entity that has its own key

attribute.

 E.g.: Employee, student ,customer, policy holder

etc.

 Also called as Strong Entity Type.

Weak entity type:

 Entity that depends on other entity for its

existence and doesn’t have key attribute of its
own.

 Ex: DEPENDENTS of EMPLOYEE

 The relationship type that relates a weak entity

type to its owner is called identifying
relationship of the weak entity type.
 Has a partial key, which is the set of attributes
that can uniquely identify weak entities that are
related to the same owner entity.
 Relationship

•It has a label that explains the relationship.

•Usually the convention is to read the ER diagram from top

to bottom and from left to right.

•The relationship name is so chosen as to make sense when

read from left to right.

•The relationship above is read as student enrolls-in course

Case Study – ER Model For a College DB

Assumptions:

 A college contains many departments

 Each department can offer any number of courses
 Many instructors can work in a department
 An instructor can work only in one department
 For each department there is a Head
 An instructor can be head of only one department
 Each instructor can take any number of courses
 A course can be taken by only one instructor
 A student can enroll for any number of courses
 Each course can have any number of students
Steps in ER Modeling

 Identify the Entities

 Find relationships

 Identify the key attributes for every Entity

 Identify other relevant attributes

 Draw complete E-R diagram with all attributes including

Primary Key and Cardinality Ratios

 Review your results with your Business users

 Step 1: Identify the Entities
• DEPARTMENT
• STUDENT
• COURSE
• INSTRUCTOR

 Step 2: Find the relationships

• One course is enrolled by multiple students and one student enrolls

for multiple courses, hence the cardinality between course and
student is Many to Many.
• The department offers many courses and each course belongs to only
one department, hence the cardinality between department and
course is One to Many.
• One department has multiple instructors and one instructor belongs to
one and only one department , hence the cardinality between
department and instructor is one to Many.
• Each department there is a “Head of department” and one instructor is
“Head of department “,hence the cardinality is one to one .
• One course is taught by only one instructor, but the instructor teaches
many courses, hence the cardinality between course and instructor
is many to one.
 Step 3: Identify the key attributes
• Deptname is the key attribute for the Entity
“Department”, as it identifies the Department uniquely.
• Course# (CourseId) is the key attribute for “Course”
Entity.
• Student# (Student Number) is the key attribute for
“Student” Entity.
• Instructor Name is the key attribute for “Instructor” Entity.

 Step 4: Identify other relevant attributes

• For the department entity, the relevant attribute is
location
• For course entity, course name, duration, prerequisite
• For instructor entity, room#, telephone#
• For student entity, student name, date of birth
Step 5: Draw complete E-R diagram with all attributes including Primary Key
 A banking scenario
 Banks have customers.
 Customers are identified by name, custid, phone number
and address.
 Customers can have one or more accounts
 Accounts are identified by an account number, account
type (savings, current) and a balance.
 Customers can avail loans.
 Loans are identified by loan id, loan type (car, home,
personal) and an amount.
 Banks are identified by a name, code and the address of
the main office.
 Banks have branches.
 Branches are identified by a branch number, branch
name and an address.
 Accounts and loans are related to the banks’ branches.
 Step 1: Identify the Entities
• BANK
• BRANCH
• LOAN
• ACCOUNT
• CUSTOMER

 Step 2: Find the relationships

• One Bank has many branches and each branch belongs to only one
bank, hence the cardinality between Bank and Branch is One to Many.
• One Branch offers many loans and each loan is associated with one
branch, hence the cardinality between Branch and Loan is One to Many.
• One Branch maintains multiple accounts and each account is
associated to one and only one Branch, hence the cardinality between
Branch and Account is One to Many
• One Loan can be availed by multiple customers, and each Customer
can avail multiple loans, hence the cardinality between Loan and
Customer is Many to Many.
• One Customer can hold multiple accounts, and each Account can be
held by multiple Customers, hence the cardinality between Customer
and Account is Many to Many
 Solution Step 2: Identify relationships between entities
• Bank has Branch
• Branch maintains accounts
• Branch offers loans
• Account is held by customer
• Loan is availed by customer
 Solution Step 2: Analyze cardinality of relationships
•Bank has Branch : A bank has many branches->1:N
•Branch maintains accounts: One branch maintains
many accounts-> 1:N
•Branch offers loans : One branch offers many loans -
> 1:N
•Account is held by customer -> M:N
•Loan is availed by customer -> M:N
 Step 3: Identify the key attributes
• BankCode (Bank Code) is the key attribute for the Entity “Bank”, as
it identifies the bank uniquely.
• Branch# (Branch Number) is the key attribute for “Branch” Entity.
• Customer# (Customer Number) is the key attribute for “Customer”
Entity.
• Loan# (Loan Number) is the key attribute for “Loan” Entity.
• Account No (Account Number) is the key attribute for “Account”
Entity.

 Step 4: Identify other relevant attributes

• For the “Bank” Entity, the relevant attributes other than
“BankCode” would be “Name” and “Address”.
• For the “Branch” Entity, the relevant attributes other than “Branch#”
would be “Name” and “Address”.
• For the “Loan” Entity, the relevant attribute other than “Loan#”
would be “Loan Type”.
• For the “Account” Entity, the relevant attribute other than “Account
No” would be “Account Type”.
• For the “Customer” Entity, the relevant attributes other than
“Customer#” would be “Name”, “Telephone#” and “Address”.
Merits and Demerits of ER Modeling:

 Merits
• Easy to understand. Represented in Business Users
Language.
• Can be understood by non-technical specialist.
• Intuitive and helps in Physical Database creation.
• Can be generalized and specialized based on needs.
• Can help in database design.
• Gives a higher level description of the system.

 Demerits
• Physical design derived from E-R Model may have
some amount of ambiguities or inconsistency.
• Sometime diagrams may lead to misinterpretations
 Exercise 2.7 The Prescriptions-R-X chain of
pharmacies has ordered to give you a free
lifetime supply of medicines if you design its
database. Given the rising cost of health care,
you agree. Here's the information that you
gather:
 Patients are identified by an SSN, and their names,
addresses, and ages must be recorded.
 Doctors are identified by an SSN. For each doctor,
the name, specialty, and years of experience must
be recorded.
 Each pharmaceutical company is identified by name
and has a phone number.
 For each drug, the trade name and formula must be
recorded.
 Each drug is sold by a given pharmaceutical company, and
the trade name identifies a drug uniquely from among the
products of that company. If a pharmaceutical company is
deleted, you need not keep track of its products any longer.
 Each pharmacy has a name, address, and phone number.
 Every patient has a primary physician. Every doctor has at
least one patient.
 Each pharmacy sells several drugs and has a price for
each. A drug could be sold at several pharmacies, and the
price could vary from one pharmacy to another.
 Doctors prescribe drugs for patients. A doctor could
prescribe one or more drugs for several patients, and a
patient could obtain prescriptions from several doctors.
 Each prescription has a date and a quantity associated
with it. You can assume that if a doctor prescribes the
same drug for the same patient more than once, only the
last such prescription needs to be stored.
 Pharmaceutical companies have long-term contracts with
pharmacies. A pharmaceutical company can contract with
several pharmacies, and a pharmacy can contract with
several pharmaceutical companies. For each contract,
you have to store a start date, an end date, and the text of
the contract.
 Pharmacies appoint a supervisor for each contract. There
must always be a supervisor for each contract, but the
contract supervisor can change over the lifetime of the
contract.
 Draw an ER diagram that captures the above
information. Identify any constraints that are not
captured by the ER diagram.
 Exercise 2.8 : Although you always wanted to be an artist, you ended
up being an expert on databases. So now you set up a database
company, ArtBase, that builds a product for art galleries. The core of this
product is a database with a schema that captures all the information
that galleries need to maintain.
 Galleries keep information about artists, their names (which are unique),
birthplaces, age, and style of art.
 For each piece of artwork, the artist, the year it was made, its unique
title, its type of art (e.g., painting, lithograph, sculpture, photograph), and
its price must be stored. Pieces of artwork are also classified into groups
of various kinds, for example, portraits, still lifes, works by Picasso, or
works of the 19th century; a given piece may belong to more than one
group.
 Each group is identified by a name (like those above) that describes the
group.
 Finally, galleries keep information about customers. For each customer,
galleries keep their unique name, address, total amount of dollars they
have spent in the gallery (very important!), and the artists and groups of
art that each customer tends to like.
 Draw the ER diagram for the Art Gallary database.
Proper Naming of Schema Constructs

 When designing a database schema, the choice

of names for entity types, attributes, relationship
types, and (particularly) roles is not always
straightforward.
 One should choose names that convey, as much
as possible, the meanings attached to the
different constructs in the schema.
 We choose to use singular names for entity
types, rather than plural ones, because the entity
type name applies to each individual entity
belonging to that entity type.
 In our ER diagrams, we will use the convention
that entity type and relationship type names are
uppercase letters, attribute names have their
initial letter capitalized, and role names are
lowercase letters.
 As a general practice, given a narrative
description of the database requirements, the
nouns appearing in the narrative tend to give
rise to entity type names, and the verbs tend to
indicate names of relationship types.
 Attribute names generally arise from additional
nouns that describe the nouns corresponding to
entity types.
 Another naming consideration involves
choosing binary relationship names to
make the ER diagram of the schema
readable from left to right and from top to
bottom.
 Draw an ER diagram for:

- Online Book store database

Book, Author, Publisher, Customer, Shopping_cart, Stock
- Cricket Team statistics
- Library database
Branch, Book, Author, Publisher, Borrower
- Hospital management
- Movie database
Hospital
Management
System
Match play Player
ed

Played Played
by Player _in
_of

Team Ground