All the best

1. Data Modeling Using the Entity-Relationship
(ER) Data Model

2. 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

3. Database Design
• Two main activities in database design:
▫ Data requirements: user’s data
▫ Functional requirements: user’s functions
(transactions)
• Once all requirements have been collected and
analyzed, the next step is to create a conceptual
schema for the database. This step is call
conceptual design.
• Because these concepts do not include
implementation details, they usually easier to
understand and can be used to communicate with
users

4. Data Modeling
• A set of concepts to describe the structure of a database.
• The most important task in database development.
• A data model is a plan, or blueprint, for a database design.
• A data model is more generalized and abstract than a database
design.
• It is easier to change a data model than it is to change a database
design, so it is the appropriate place to work through conceptual
database problems.

5. A simplified diagram to illustrate the main phase of database design.
• Designers interview database users to understand and
document data requirements.
• User defined operations to be applied on the database
• Once all requirements have been collected and analyzed,
the next step is to create a conceptual schema for the
database. This step is call conceptual design.
• Conceptual schema; a permanent description of database
specifications.
• description of data, constraints, relationships
• No storage details needed
• By using the DBMS, we can transform conceptual
design from high-level data model into the
implementation data model. This step is called
logical Design or Data Model mapping
Requirement Collection and Analysis
Functional Requirements
Conceptual Design
Logical Design
• Internal Schema Design
• Internal Storage, Indexes, Access Path.
Physical Design

7. The Entity Relationship Model
•The Entity-Relationship model is a set of concepts and
graphical symbols that can be used to create conceptual
schemas
•The ER model is a high-level conceptual data model.
•Developed by Peter Chen of M.I.T. in 1976 in a landmark
paper, "The Entity-Relationship Model: Toward a Unified
View of Data," ACM Transactions on Database Systems, Vol. 1,
No. 1.

8. The Four Major Components of the
Entity Relationship (E-R) Model
Attributes
Entities
Relationships
Identifiers
• An entity is an object in the miniworld.
• The most basic object that the ER model represents is an entity
• An entity maybe an object with a physical existence (a person, a car,
house…) or it maybe an object with conceptual existance (a company, a job, or
a course)
• Each entity has Attributes --- the particular properties that describe it
• An Identifier is essentially a name of a database, table, or table column.
• A relationship is an association between entities

9. Entity
An entity is an object in the miniworld.

10. Attributes
Each entity has Attributes --- the particular
properties that describes the Entity.

11. Types of attribute occur in the ER
model
▫ Simple vs. Composite
▫ Single value vs. Multi-value
▫ Stored vs. Derived
▫ key vs. nonkey.

12. Composite vs. Simple Attributes
• Composite attributes can be divided into smaller
subparts.
▫ For example: Address attribute of the EMPLOYEE entity can be
further subdivided into street address, city, state, zip code
• Simple attributes can not be further divisible
▫ For example, street address can be subdivided into Number, street,
and apt#

13. Single value vs. Multi-value
• Attributes have a single value for a particular entity;
such attribute are called single-valued
- for example Manager of the Department
• In some cases an attribute can have a set of value for
the same entity Such attributes are called
multivalued
- for example, Locations of the Department

14. Stored vs. Derived
• In some cases, two (or more) attributes
are related --- for example, the Age and
Birth_date of a person
• The Age attribute is called a derived
attribute and is said to be derived
from the Birth_date attribute, which is
called a stored value
<- Date of Birth(Stored)
<- 19-08-1987
AGE(Derived)
30 years

15. NULL Values
• In some cases, a particular entity may
not have an applicable value for an
attribute
• For example, college degree,
• NULL can also be used if we do not
know the value of an attribute for a
particular entity---home phone

16. Complex Attributes
• Composite and Multivalued attributes together
generates a Complex Attributes
• Example
{address_phone({phone(Area_code,Phone_number
)},Address(street_address(number,street,Apartment
_number),City,State,Zip))}
• Grouping components of a composite attribute
between parentheses() and separating the
components with commas, and by displaying
multivalued attributes between braces{}. Such
attributes are called complex attributes.

17. Entity Type / Entity Set
Entity Type: EMPLOYEE
Attributes: Name, Age, Salary
Entity Set:
e1 = (John Smith, 55, 80000)
e2 = (Joe Doe, 40, 20000)
e3 = (Jane Doe, 27, 30000)
An entity type defines a collection of entities that have the same attributes

18. Key Attributes
• An important constrain on the entities of an
entity type is the KEY on attributes
• An attribute of an entity type for which each
entity must have a unique value is called a key
attribute of the entity type.
For example, USN of the STUDENTS
• The entity types that do not have key attributes of
their own are called weak entity types.`

19. Summary of notation for ER diagrams
SYMBOL MEANING

20. SYMBOL MEANING

21. Conceptual Design of the Company Database
• COMPANY database keeps track of a company’s
employees, departments, projects and Dependents
• Suppose that after the requirements collection and
analysis phase, the database designers provide the
following description of the miniworld—the part of the
company that will be represented in the database. The
company is organized into departments. Each
department has a unique name, a unique number, and
a particular employee who manages the department.
We keep track of the start date when that employee
began managing the department. A department may
have several locations.

22. • A department controls a number of projects, each
of which has a unique name, a unique number,
and a single location.
• We store each employee’s name, Social Security
number,2 address, salary, sex and birth date.
• Each employees are having some dependents. We
keep each dependent’s first name, sex, birth date,
and relationship to the employee.

23. 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

24. Department
▫ 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.

25. Project
▫ Each department controls a number of PROJECTs. Each
project has a unique name, unique number and is
located at a single location.

26. EMPLOYEE
▫ We store each EMPLOYEE’s name, 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.

27. Dependent
• We want to keep track of the dependents of each
employee for insurance purposes. We keep each
dependent’s first name, sex, birth date, and
relationship to the employee.

28. EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT

29. Relationship Type
▫ Is the schema description of a
relationship.
▫ Association among the entities.
▫ Identifies the relationship name and
the participating entity types
▫ Also identifies certain relationship
constraints

30. Relationship Set
• Relationship Set:
▫ The current set of relationship instances
represented in the database
▫ The current state of a relationship type

31. -A relationship relates two or more distinct
entities with a specific meaning
• For example, EMPLOYEE E1 the
PROJECT X or EMPLOYEE E2 the
Research DEPARTMENT.
-Relationships of the same type are grouped or
typed into a relationship type.
• For example, the WORKS_ON relationship type in
which EMPLOYEEs and PROJECTs participate, or
the MANAGES relationship type in which
EMPLOYEEs and DEPARTMENTs participate.
Works For
Manages

32. Some instances of the WORKS_FOR relationship between
EMPLOYEE and DEPARTMENT
ENTITY TYPE
ENTITIES
RRELATIONSHIP TYPE
RELATIONSHIP INSTANCES

33. The degree of a relationship type is the number of participating entity types
In a relationship type.
ENTITY TYPE
ENTITIES
RRELATIONSHIP TYPE
RELATIONSHIP INSTANCE
Entity Type 2
Entity Type 1 Participation
Here 2 entity
types are
participated in on
relationship type
hence The
WORKS_FOR
relationship is of
degree two. A
relationship type
of degree two is
called Binary.
THE DEGREE OF A RELATIONSHIP TYPE

34. Here 3 entity types are
participated in on
relationship type hence
The SUPPLY relationship
is of degree Three. A
relationship type of degree
three is called Ternary.

35. Identifying Relationship
An Identifying Relationship is a relationship between a
strong and a weak entity type, where the key of the
strong entity type is required to uniquely identify
instances of the weak entity type.
Example: Name of the Dependents can be Identified By
the Employee SSN.

36. Relationship
• In ER diagrams, we represent the relationship
type as follows:
▫ Diamond-shaped box is used to display a
relationship type
▫ Connected to the participating entity types via
straight lines

37. Relationship between EMPLOYEE and
DEPARTMENT

38. Conceptual Design of the Company Database
• COMPANY database keeps track of a company’s
employees, departments, projects and Dependents
• Suppose that after the requirements collection and
analysis phase, the database designers provide the
following description of the miniworld—the part of the
company that will be represented in the database. The
company is organized into departments. Each
department has a unique name, a unique number, and
a particular employee who manages the department.
We keep track of the start date when that employee
began managing the department. A department may
have several locations.

39. • A department controls a number of projects, each
of which has a unique name, a unique number,
and a single location.
• We store each employee’s name, Social Security
number,2 address, salary, sex and birth date.
• Each employees are having some dependents. We
keep each dependent’s first name, sex, birth date,
and relationship to the employee.

40. Refining the COMPANY database schema by
introducing relationships
• By examining the requirements, six relationship types are
identified
• All are binary relationships( degree 2)
• Listed below with their participating entity types:
▫ WORKS_FOR (between EMPLOYEE, DEPARTMENT)
▫ MANAGES (also between EMPLOYEE, DEPARTMENT)
▫ CONTROLS (between DEPARTMENT, PROJECT)
▫ WORKS_ON (between EMPLOYEE, PROJECT)
▫ SUPERVISION (between EMPLOYEE (as subordinate)
EMPLOYEE (as supervisor))
▫ DEPENDENTS_OF (between EMPLOYEE, DEPENDENT)

41. Entity Roles
• Each entity type in a relationship type plays a
particular role that is described by a role name.
Role names are especially important in recursive
relationship types where the same entity
participates in more than one role:
Manager
Member

42. Recursive Relationship
• In some cases, the same
entity type participates more
than once in a relationship
type in different roles
• Example Employee and
supervised
Supervisor 1 N Supervisee

43. Supervisor
Supervisee
Recursive Relationship

44. Structural Constraints on a Relationship
▫ Cardinality ratio: Limits the number of
relationship instances an entity can
participate in.
▫ Participation constraint:If each entity
of an entity type is required to participate
in some instance of a relationship type,
then that participation is total; otherwise,
it is partial.

45. Constrains on Relationship types
• Sometimes if we want to describe “each employee must
work for exactly one department”, then we would like to
describe this constrain in the schema
• The cardinality ratio for a binary relationship specifies
the max number of relationship instances that an entity
can participate in.
• For example:
▫ In the WORKS_FOR binary relationship,
DEPARTMENT:EMPLOYEE is of cardinality ratio is 1:N,
meaning each department can be related to any number of
employees, but an employee can only be related to one
department

46. ▫ Maximum Cardinality
 One-to-one (1:1)
 One-to-many (1:N) or Many-to-one
(N:1)
 Many-to-many (M:N)

47. Cardinality Ratio 1:1

48. Cardinality Ratio 1:N

49. Cardinality Ratio M:N

50. Participation constraint:
The participation constraint specifies whether the
existence of an entity depends on its being related
to another entity via the relationship type. This
constraint specifies the minimum number of
relationship instances that each entity can
participate in, and is some times called the
minimum cardinality constraint.
There are 2 types of participation constraints
 Total Participation
 Partial Participation

51. Total Participation

52. • Total Participation: The participation of
DEPARTMENT in MANAGES is called total
participation, meaning that every entity in the total
set of DEPARTMENT entities must be related to a
EMPLOYEE entity via MANAGES.
• Partial participation, meaning that every entity in
the total set of EMPLOYEE entities may not related
to a DEPARTMENT entities via MANAGES.

54. 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.

55. Summary of notation for ER diagrams
SYMBOL MEANING

56. COMPANY DATABASE
• COMPANY database keeps track of a company’s
employees, departments, projects and Dependents
• Suppose that after the requirements collection and
analysis phase, the database designers provide the
following description of the miniworld—the part of the
company that will be represented in the database.
The company is organized into departments. Each
department has a unique name, a unique number,
and a particular employee who manages the
department. We keep track of the start date when
that employee began managing the department. A
department may have several locations.

57. • A department controls a number of projects, each
of which has a unique name, a unique number,
and a single location.
• We store each employee’s name, Social Security
number,2 address, salary, sex and birth date.

58. STEP 1 :Identify the Entity Type
Employee
Department
Project
Dependent

59. STEP 3:Other relevant attributes
Employee: bdate, sex, address, salary
Department: name, locations, no of employees
Project: name, location
Dependent: sex, birthdate, relationship
STEP 2:Key attributes
Employee:
Department:
Project:
Dependent:
ssn
number
number
name

60. STEP 4 : Identify the relations
MANAGES a 1:1 relationship type between EMPLOYEE and
DEPARTMENT. EMPLOYEE participation is partial. DEPARTMENT
participation is not clear From the requirements. We question the users,
who say that a department must have a manager at all times, which implies
total participation. The attribute Start date is assigned to this relationship
type.
WORKS_FOR, a 1:N relationship type between DEPARTMENT and
EMPLOYEE. Both participations are total.
CONTROLS, a 1:N relationship type between DEPARTMENT and PROJECT. The
participation of PROJECT is total, whereas that of DEPARTMENT is determined to
be partial, after consultation with the users indicates that some departments may
control no projects.

61. SUPERVISION, a 1:N relationship type between EMPLOYEE (in the
supervisor role) and EMPLOYEE (in the supervisee role). Both
participations are determined to be partial, after the users indicate that not
every employee is a supervisor and not every employee has a supervisor.
WORKS_ON, determined to be an M:N relationship type with attribute
Hours, after the users indicate that a project can have several employees
working on it. Both participations are determined to be total.
DEPENDENTS_OF, a 1:N relationship type between EMPLOYEE and
DEPENDENT, which is also the identifying relationship for the weak entity
type DEPENDENT. The participation of EMPLOYEE is partial, whereas
that of DEPENDENT is total.

62. ER Diagram of Company Database
Entity Type
Attributes
Relationship

63. HOTEL MANAGEMENT
There are many hotels in a country. Each hotel is identified by
its id, name and star rate. Each hotel provides many rooms.
Rooms are identified by Room no. and type.
Each room is rented for a cost. Cost is identified by its id and
amount. A hotel has many facilities available with it. Facilities
are identified by its id and name.
A hotel is located at a particular location. Location is identified
by street, town and pin code.
Identify the entities, relationships, key attributes and other
attributes. Design an ER diagram of this.
STEP 1 :Identify the Entity Type
1.Hotel
2.Rooms
3.Cost
4.Facilities
5.Location

64. STEP 2: Key attribute
STEP 3: Other attributes
Hotel-name, star rate
Rooms-type
Cost-amount
Facilities-Fname
Location-street, town
Hotel-hotel id
Rooms-Room no.
Cost-costid
Facilities-Fid
Location-pincode

65. Step 4: RELATIONSHIPS

66. STEP 5:
ER DIAGRAM

67. Entity Relationship (ER) model for a college database .
We have the following statements.
• 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

68. Step 1 : Identify the Entities
• Department
• Course
• Instructor
• Student

69. Step 2: Identify the key attributes
• "Departmen_Name" can identify a department
uniquely. Hence Department_Name is the key
attribute for the Entity "Department".
• Course_ID is the key attribute for "Course" Entity.
• Student_ID is the key attribute for "Student"
Entity.
• Instructor_ID is the key attribute for "Instructor"
Entity.

70. Step 3 : Identify the relationships
• One department offers many courses. But one
particular course can be offered by only one
department. hence the cardinality between
department and course is One to Many (1:N)
• One department has multiple instructors . But
instructor belongs to only one department. Hence
the cardinality between department and
instructor is One to Many (1:N)

71. • One department has only one head and one head
can be the head of only one department. Hence
the cardinality is one to one. (1:1)
• One course can be enrolled by many students and
one student can enroll for many courses. Hence
the cardinality between course and student is
Many to Many (M:N)
• One course is taught by only one instructor. But
one instructor teaches many courses. Hence the
cardinality between course and instructor is Many
to One (N :1)

72. Step 4: Identify other relevant
attributes
• For the department entity, other attributes are
location
• For course entity, other attributes are
course_name,duration
• For instructor entity, other attributes are
first_name, last_name, phone
• For student entity, first_name, last_name, phone

73. Step 5: Draw complete ER diagram

74. 1 1
1

75. Library Database
• BOOK : Book_id, Title, Publisher_Name, Pub_Year
• BOOK_AUTHORS : Book_id, Author_Name
• PUBLISHER : Name, Address, Phone
• BOOK_COPIES: Book_id, Branch_id, No-of_Copies
• BOOK_LENDING : Book_id, Branch_id, Card_No, Date_Out,
Due_Date
• LIBRARY_BRANCH :Branch_id, Branch_Name, Address

77. 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

78. • 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
Minimum Maximum
Maximum
Minimum
The (min,max) notation for relationship constraints
Cardinality Ratio
1 1

79. ▫ 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 (1,n) for participation of DEPARTMENT in
WORKS_FOR
The (min,max) notation for relationship constraints
Cardinality Ratio
1 N

81. COMPANY ER Schema Diagram using (min, max) notation

82. Relationships of Higher Degree
• Relationship types of degree 2 are called binary
• Relationship types of degree 3 are called ternary
and of degree n are called n-ary
• In general, an n-ary relationship is not equivalent
to n binary relationships
• Constraints are harder to specify for higher-
degree relationships (n > 2) than for binary
relationships

83. Example of a ternary relationship
S - Supplier
S - Supply
P - Parts
J - Projects

84. BLOOD BANK MANAGEMENT SYSTEM

85. BLOOD BANK MANAGEMENT SYSTEM
A Blood Bank stores blood of various blood groups . Many donors donate blood
,each of different blood group/type. A donor may donate blood more than once and
he is identified by a donor id(DID),name, sex, age , address and phone number.
The blood donated by the donor is characterized by blood type , code and cost.
Before each donor donates his blood , he is required to register himself as a donor
with the receptionist who works at the Blood Bank. The receptionist is identified by
employee id, name , address and phone number. The Blood Banks receives orders
for blood from many hospitals for emergency purposes and other surgical
requirements and each blood bank issues the same of required blood type. Each
blood bank has it’s own blood bank number(BNO) , issues, orders and blood types
stored. The Blood Bank is managed by the blood bank manager who is identified
by employee id , name , email_id and phone number .He is responsible for the
proper management of the blood bank . The hospitals are identified by name,
address and phone number. Represent this using an ER diagram.

86. STEP 1 : Identifying the entities
1. Donor
2. Blood
3. Receptionist
4. Blood Bank
5. Blood Bank Manager
6. Hospital

87. STEP 2: Identify the key attributes.
1. Donor – donor id(DID)
2.Blood – code
3.Receptionist – employee id(empid)
4.Blood Bank–Blood Bank number(BNO)
5.Blood Bank Manager – employee id(empid)
6.Hospital – name, phone number(phno)
STEP 3 : Identify other relevant attributes
1. Donor – name, age, sex, address, phone number(phno)
2. Blood – blood type, cost
3. Receptionist – name, address, phone number(phno)
4. Blood Bank– issues, orders , blood type
5. Blood Bank Manager – name ,email _id , phone number(phno)
6. Hospital-address

88. STEP 4 : Identify the relationships.
1. A donor may donate blood any number of times. So cardinality is
1:N.
2. Many donors may register blood donation with a single
receptionist. So cardinality is N:1.
3. Blood of different type in large numbers is stored in a single Blood
Bank . So cardinality is N:1.
4. Blood Bank is managed by an blood bank -manager. So cardinality
is 1:1.
5. A receptionist works in a Blood Bank . So cardinality is 1:1.
6. Hospitals may order blood from different Blood Banks . So
cardinality is N:M

91. HOSPITAL MANAGEMENT SYSTEM

93. MOTOR VEHICLE BRANCH ADMINISTRATION
The motor vehicle branch administrators driving tests and issues
driver’s licenses. Any person who wants driver’s license must
first take a learners exam at any motor vehicle branch in the
province. If he/she fails the exam , he can take the exam again
any time after a week of the failed exam date, at any branch. If
he passes the exam ,he will be issued a license(learners type)
with a unique license number. A learners license may contain a
single restriction on it. The person may take his driver’s exam at
any branch any time before the learners license expiry
date(which is usually set at six months after the license issue
date).If he passes the exam, the branch issues him a driver’s
license .A driver’s license must also record if the driver has
completed driver’s education ,for insurance purpose. Each
driver should own a vehicle .If he has no money he can lend it
through loan.

94. Create a E-R diagram following these steps.
1. Find out the entities.
2. Find out the relationships among the
entities?
3. Find out the attributes of the entities and the
relationships?
4. Figure out constraints between entities and
relationships?

95. ENTITIES:
Driver
Branch
License
Vehicle
Loan
IDENTIFY RELATIONSHIPS:

96. IDENTIFYING KEY ATTRIBUTES AND OTHER RELEVANT
ATTRIBUTES
Driver: driver sin, driver name
Branch: branch id, branch name, branch address, branch
phone, branch city, branch postal_code.
Vehicle: vehicle no, vehicle type
Loan: loan no, loan type ,loan date
LICENSE: LICENSE NO,LICENSE CLASS,LICENSE EXPIRY.