Chapter 3: Entity-Relationship Model

2.1
 Entity Relationship Model (ER)

 ER model was proposed by Peter Chen

in 1976

 ER model has become the standard tool

for conceptual schema design

 ER model consists of three basic

constructs: entities, attributes and
relationships.

2.2
 What is an entity ?
An entity is a “thing” in the real world with
an independent existence.

It may be an object with physical existence

(e.g. person, car, house, employee), or it
may be an object with conceptual
existence (company, job, university,
course).

2.3
 Entity and Entity Set
 Two types of entities:
 Strong entity: can exist independently (or can
uniquely identify itself)
 Weak entity: existence depends on the
existence of other (strong) entity or entities
 Examples:
 An employee is a strong entity but the
dependents of the employee could be weak
entities
 An account in a bank is a strong entity but a
transaction could be a week entity

2.4
 Entity and Entity Set
 An entity type defines a set of entities that have
the same attributes.
 STUDENT is an entity type ( Schema)

 An entity set is a collection of entities of the same

entity type
 Examples:
 Rema, Ali, Amal, Samer, Rana are entity set
of an entity type STUDENT

2.5
 Attributes
 An entity has a set of attributes that describes it.
 Person(SSN, Name, Address, Job-description,
Salary).
 An entity will have a value for each of its attributes
 (999-010-201, John Smith, ‘20 Alebany Rd,
Cardiff, UK’, ‘Manager’, 2500)
 Definition: The properties of an entity set are called
attributes of the entity set.
 Students: SSN, Name, Address, GPA, Status, ...
 Books: Title, ISBN, Authors, Publisher, Year, ...
 For a given application, only a limited number of
attributes of an entity set are of interest

2.6
 Types of Attributes
 Simple (or atomic) attribute is a one which
cannot be divided into smaller parts.
 Examples: SSN, GPA, Salary.
 Composite attribute is an attribute which can
be divided into smaller subparts, these
subparts represent more basic attributes with
independent meanings of their own.
 Examples: Name: First_Name,
Middle_Name, Last_Name
 Address: Street_Address, City, State, Zip
code

2.7
 An Example of a composite attribute

Address

Street-Address City State Post Code

House No. Street Name

2.8
 Types of Attributes
 A single-valued attribute is a one which has
one (single) value for a particular entity.
 Example: Age, BirthDate
 A multi-valued attribute is a one which may
have one or more values for the same entity.
Multi-valued attributes may have lower and
upper bounds on the number of values for an
individual entity.
 College Degrees for Person: 0, 1, 2, 3, …
 Color for a Car: 1, 2, …..
 Authors of Books
 Phone Number

2.9
 Types of Attributes
 A stored attribute is a one whose value is
explicitly stored in the database.
 e.g. name, birth-date.
 Derived-attributes: whose values are computed
from other attributes.
 Examples: Age from Birthdate
 Annual Salary from Monthly Salary
 NoOfEmployees ==> Count number of
employees in the Employee table.

2.10
 Null Values
 An attribute may have null as its value.
 Null may mean
 not applicable (college degree)
 Unknown

 Missing (height of Smith)

 Not known (home phone for Smith).

2.11
 Keys
 Key attribute is an attribute whose values are
distinct (unique) for a given entity type.
 Keys may be
 simple: one attribute (SSN), or
 composite: a set of attributes whose values
together uniquely identify an entity type
 Name(first name, father name, grandfather
name, family name)

2.12
 Value Sets or Domains
 A value set V or domain for a simple attribute A
specifies the set of values that may be assigned to
that attribute for each individual entity.
 e.g. Employee.Age Age >=16 and Age <=60

 ==> V(Age) = {16, 17, 18, …, 60}

2.13
 Complex Attribute
 {AddressPhone({Phone(AreaCode, Phone#)},
Address(StreetAddress(No, Name, AptNo), City,
State))}
 The above example states that a person may have
several residences and each residence may have
several phones. Phone numbers consist of area
code and phone number. Address, by contrast,
consists of street, city and state. Street address is a
composite attribute which consists of street
number, name and apartment number.
 ( ) : indicates a composite attribute
 { }: indicates a multi-valued attribute.

2.14
 Relationship Types
 Each entity type E1, E2, …, En is said to participate
in the relationship type R.
 A relationship type is represented as diamond-
shaped box which is connected by straight lines.

2.15
 Relationship Degree

Degree of a relationship type is the number

of participating entity types; binary
relationships, ternary relationships, ….

EMPLOYEE WORKS-FOR COMPANY

Binary Relationships

2.16
 Ternary Relationships

SUPPLIER SUPPLY PROJECT

PART

2.17
 Ternary Relationships

COMPANY SELLS PRODUCT

COUNTRY

2.18
 Recursive Relationships

EMPLOYEE Supervises

PERSON Marry

2.19
 Relationships
 The role name signifies the role that a
participating entity from the entity type plays in
each relationship instance. Going back to the
previous example, the entity e1 plays the role of
a supervisor, while entity e2 plays the role of a
supervisee.

2.20
 Cardinality Ratio
Specifies the number of relationship instances that an
entity can participate in. Common cardinality ratios
for binary relationship types are 1:1,1:N, and M:N.

2.21
 N 1 COMPANY
EMPLOYEE WORKS-FOR

An employee works for one company,

and a company has many employees
working for it.

2.22
 1 1 MANAGER
DEPARTMENT HAS

A department has one manager and a

manager manages one department.

2.23
 M N PROJECT
EMPLOYEE WORKS-ON

An employee works on many projects,

and a project has many employees
working on it.

2.24
 Participation Constraints
Specifies whether the existence of an entity
depends on its being related to another entity
via the relationship type. There is total and
partial participation.

2.25
 Total participation

N 1
EMPLOYEE WORKS-FOR DEPARTMENT

Total
participation.

Every employee must be related to a

department via WORKS-FOR relationship.

2.26
 Partial participation

1 N
PERSON Buys CAR

A person may buy a car and car

may be bought by a person

2.27
 Total & Partial participation

1 N
PROFESSOR Manages DEPARTMENT

A professor may manage a department

(partial participation), but a department
must be managed by a professor (total
participation).
2.28
 Attributes of Relationship Types

N 1
EMPLOYEE Works-for DEPARTMENT

Start-Date

We may keep a start date attribute to record for

each employee the date he or she started work for
a certain department.

2.29
A weak entity type is an entity which does not have
any key attributes

Employee Works-for Department

1
identifying relationship
Dependents
Fname

N Sex

Dependent
Birthdate
Relationship
2.30
 Weak Entity Types

1. A weak entity type always has a total participation

with its identifying entity type.
2. A Weak entity type has a partial key, i.e. this key is
enough to identify its extension within the scope of
its identifying entity type. In the previous example,
the first name is enough to identify kids within a
single family, but is not enough to identify entities
as stand alone entities (two families may use
identical names for their kids).

2.31
 ER Notations

<Name> Entity Type

<Name> Attribute

<Name> Key Attribute

Multi-valued
<Name>
attribute

2.32
 ER Diagram Notations

<Name> Weak Entity Type

<Name> Relationship Type

<Name> Identifying Relationship Type

2.33
 ER Notations
<Name> <Name>

<Name> Composite Attribute

<Name> Derived Attribute

<Name> partial key attribute

2.34
 Entity Types: singular name, capital letters
 Relationship Types: usually singular verbs,
capital letters.
 Attribute: nouns, capitalized.
 Role names: are in lowercase letters.
 ER diagrams are drawn such that they are
readable from left to right and top to bottom
(Except weak entity types).

2.35
 ER Notations

E1 R E2 Total participation of E2 in R

1 N
E1 R E2

Cardinality Ratio 1:N for E1 and E2 in R

2.36
 Relationships
 Several relationships may exist among the same
set of entity sets.

m Works_in 1

Employees Departments
1 1
Manages

2.37
 Degree of a Relationship (1)

Definition: The degree of a relationship is the

number of entity sets participating the
relationship.
 Recursive relationship
Examples:
Supervises on Employees
is_prerequisite_of on Courses
is_classmate_of on Students

2.38
 Degree of a Relationship (2)
 Binary relationship (degree = 2)
 Examples:

 takes between Students and Courses

 owns between Persons and Cars

 Ternary relationship (degree = 3)

 Examples:

 orders among Customers, Parts and Suppliers

 skill_used among Engineers, Skills and

Projects

2.39
 Cardinality (1)
 One-to-one (1-to-1) relationship between E1 and
E2:
 for each entity in E1, there is at most one
associated entity in E2, and vice versa.
 Examples of 1-to-1 relationships:
 Binary 1-to-1 relationship

 manages between Employees and Departments

 recursive 1-to-1 relationship
 is_married_to on Persons

2.40
 Cardinality (2)

 One-to-many (1-to-m) relationship from E1 to

E2: for each entity of E1, there are zero or more
associated entities of E2, but for each entity of
E2, there is at most one associated entity of E1
 Examples of 1-to-m relationships:
 binary 1-to-m relationship

 advises between Professors and Students

 recursive 1-to-m relationship
 is_mother_of on Persons

 Many-to-one (m-to-1) relationship from E1 to

E2: same as 1-to-m relationship from E2 to E1
2.41
 Cardinality (3)

 Many-to-many (m-to-m) relationship between E1

and E2: for each entity in E1, there are zero or
more associated entities in E2, and vice versa

 Examples of m-to-m relationships:

 binary m-to-m relationship

 takes between Students and Courses

 recursive m-to-m relationship
 is_component_of on Parts

2.42
 ER Diagram (1)

Recursive relationship

is_married_to
1 1

Person

SSN Name Age

2.43
 ER Diagram (2)

binary relationship

1 m
Professor advises Student

SSN Name Age SSN Name Age

2.44
 ER Diagram (3)

ternary relationship

Engineer

Skill_used

Skill Project
2.45
 Role of an Entity Set (1)

Definition: The role of an entity set in a relationship is the

function it performs in the relationship.
Case 1: Role can be determined from properly chosen
names.

m takes n

Student Course
1 is_TA_of 1

2.46
 Role of an Entity Set (2)

Case 2: Roles need to be explicitly given.

is_married_to supervises
1 1 1 m

wife husband supervisor supervisee

Person Employee

2.47
 Attribute of Relationship (1)

Where to keep the grade information?

m n
Student takes Course

grade

2.48
 Attribute of Relationship (2)

Another example:

Supplier
m Quantity
orders
n r

Part Project
2.49
 Cardinality Constraint (1)
 One in ER model means zero or one
 Many in ER model means zero or more
 Cardinality constraints make them more precise

(1, 5) (5, 60)

Student takes Course

2.50
 Cardinality Constraint (2)
 General format:

 0  min_card  max_card
 Interpretation:

 Each entity in E may involve between min_card and

max_card relationships in R.

(min_card, max_card)
E R

2.51
 Cardinality Constraint (3)
 Definition:
 If every entity in E involves at least one
relationship in R (i.e., min_card >= 1), E is said
to have total participation in R
 If min_card = 0, E is said to have partial
participation in R

2.52
 Cardinality Constraint (4)

Employees has a partial participation.

Departments has a total participation.

(0, 1) (1,1)
Employee manages Department

2.53
 Representing 1-to-1, 1-to-m, m-to-m
Relationships

(0, 1) (0, 1)
one-to-one: E R F
(0, m) (0, n)
many-to-many: E R F
(0, m) (0,1)
one-to-many: E R F

1 m
E R F
2.54
An Example Database Application

Company Database

2.55
 An Example Database Application
 The Company database keeps track of a company’s
 Employees, Departments, Projects
 The following are the requirements and
specifications
 The company is organized into departments.
 Each department has a:
 unique name, unique number
 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

2.56
 An Example Database Application
 A department controls a number of projects, each
of which has a
 unique name, unique number, and single
location
 We store each employee’s
 name, social security number, address, salary,
sex, and birth date.
 An employee is assigned to one department but
may work on several projects, which are not
necessarily controlled by the same department
 We keep track of the number of hours per week
that an employee works on each project
 We keep track of the direct supervisor of each
employee

2.57
 An Example Database Application
 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

2.58
 ER diagram for the company database
Each department has a unique name, a unique number, particular employee
who manages the department. A department may have several locations.

Name Number Locations

DEPARTMENT NumberOfEmployee

2.59
 ER diagram for the company database
A department controls a number of projects, each of which has a unique
name, unique number, and single location

Name Number Location

PROJECT

2.60
 ER diagram for the company database
We store each employee’s name, social security number, address, salary,
sex, and birth date.

Minit Lname
Fname

Name SSN Address

Sex
EMPLOYEE Salary
BDate

2.61
 ER diagram for the company database
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

Fname Relationship

Sex
BDate
DEPENDENT

2.62
 ER diagram for the company database
Each department has a particular employee who manages the department
We keep track of the start date when that employee began managing the
department

(0,1) (1,1)
EMPLOYEE MANAGES DEPARTMENT
manager
department
managed

StartDate

2.63
 ER diagram for the company database
An employee is assigned to one department.

(1,1) (1,N)
EMPLOYEE WOKES-FOR DEPARTMENT
employee department

2.64
 ER diagram for the company database
A department controls a number of projects

(0,N) (1,1)
DEPARTMENT CONTROLS PROJECT
controlling controlled
department project

2.65
 ER diagram for the company database
An employee is assigned to one department but may work on several
projects, which are not necessarily controlled by the same department. We
keep track of the number of hours per week that an employee works on each
project

(0,N) (1,N)
EMPLOYEE WORKS_ON PROJECT
worker project

Hours

2.66
 ER diagram for the company database
We keep track of the direct supervisor of each
employee
EMPLOYEE

(0,N) (0,1)
supervisor supervisee

SUPERVISION

2.67
 ER diagram for the company database
We want to keep track of the dependents of each
employee for insurance purposes.

(0,N) (1,1)
EMPLOYEE HAS DEPENDENT
employee dependent

2.68
End of Chapter 3

2.69