3.

1
Chapter 3

Data Modeling Using the Entity-
Relationship Model



2.2
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.3
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.4
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.5
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.6
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)

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




2.7
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.8
House No.
Address
Street-Address City
State Post Code
Street Name
An Example of a composite attribute



2.9
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.
College Degrees for Person: 0, 1, 2, 3,
Color for a Car: 1, 2, ..
Authors of Books
Phone Number



2.10
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.
Age from Birthdate
Annual Salary from Monthly Salary
NoOfEmployees ==> Count number of
employees in the Employee table.




2.11
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.12
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.13
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) = dom(Age) = {16, 17, 18, , 60}
dom(StudentMajors) = {math, cs, ce, med,
ee, me, nursing, }




2.14
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.15
Relationship Types
A relationship type is represented as diamond-
shaped box which is connected by straight lines



2.16
Degree of a relationship type is the number
of participating entity types: binary
relationships, ternary relationships, .
EMPLOYEE
COMPANY Works-for
Binary Relationships
Relationship Degree



2.17
SUPPLIER
PROJECT
PART
supplies
Ternary Relationships



2.18
COMPANY
PRODUCT
COUNTRY
Sells
Ternary Relationships



2.19
EMPLOYEE
Supervises
PERSON Marry
Binary
Recursive Relationships



2.20
Relationships
The role name signifies the role that a
participating entity from the entity type
plays in each relationship instance

entity e1 plays the role of a supervisor, while
entity e2 plays the role of a supervisee
EMPLOYEE
Supervises
supervisor
supervisee
e1
e2



2.21
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.22
EMPLOYEE
Works_for
COMPANY
N 1
An employee works for one company,
and a company has many employees
working for it
1:N



2.23
DEPARTMENT Has
MANAGER
1 1
A department has one manager and a
manager manages one department
1:1



2.24
EMPLOYEE
Works-on
PROJECT
M N
An employee works on many projects,
and a project has many employees
working on it
M:N



2.25
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.26
EMPLOYEE
Works-for
DEPARTMENT
N 1
Every employee must be related to a department
via WORKS-FOR relationship. A department
must have at least one employee.
Total participation.
Total participation



2.27
PERSON
Buys CAR
1
N
A person may buy a car and car
may be bought by a person

Partial participation



2.28
PROFESSOR DEPARTMENT
1 1
Manages
A professor may manage a department
(partial participation), but a department
must be managed by a professor (total
participation).
Total & Partial participation



2.29
EMPLOYEE
DEPARTMENT
Works-for
1 N
Start-Date
We may keep a start date attribute to record for each
employee the date he/she started work for a certain
department.
Attributes of Relationship Types



2.30
EMPLOYEE
DEPARTMENT
Works-for
Dependents
DEPENDENT
1
N
Fname
Sex
Birthdate
Relationship
identifying relationship
A weak entity type is an entity which
does not have any key attributes



2.31
Weak Entity Types
A weak entity type always has a total
participation with its identifying entity type
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.32
ER Notations
<Name>
<Name>
<Name>
<Name>
Entity Type
Attribute
Key Attribute
Multi-valued
attribute



2.33
ER Diagram Notations
Weak Entity Type
Relationship Type
Identifying Relationship Type
<Name>
<Name>
<Name>



2.34
Composite Attribute
ER Notations
Derived Attribute
partial key attribute
<Name>
<Name>
<Name>
<Name>
<Name>



2.35
Notations
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.36
E1 E2 R
Total participation of E2 in R
E1
R E2
1
N
Cardinality Ratio 1:N for E1 and E2 in R
ER Notations



2.37
Relationships
Several relationships may exist among the
same set of entity sets.
EMPLOYEE
DEPARTMENT
Works_in
Manages



2.38
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.39
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.40
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.41
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.42
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.43
ER Diagram (1)

Recursive relationship
is_married_to
PERSON
SSN
Name Age
1
1



2.44
ER Diagram (2)
binary relationship
advises PROFESSOR
SSN
Name
Age
1 m
STUDENT
SSN
Name Age



2.45
ER Diagram (3)

ternary relationship
Skill_used
SKILL
PROJECT
ENGINEER



2.46
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.
takes
STUDENT
1
m
COURSE
is_TA_of
n
1



2.47
Role of an Entity Set (2)
Case 2: Roles need to be explicitly given.
is_married_to
PERSON
1
1
wife husband
supervises
EMPLOYEE
1
m
supervisor supervisee



2.48
Attribute of Relationship (1)


Where to keep the grade information?
takes STUDENT
m n
COURSE
grade



2.49
Attribute of Relationship (2)
Another example:
orders
PART
PROJECT
SUPPLIER
Quantity
m
n r



2.50
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
takes STUDENT
(1, 5) (15, 60)
COURSE



2.51
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.
R
E
(min_card, max_card)



2.52
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.53
Cardinality Constraint (4)



Employees has a partial participation.
Departments has a total participation.
manages EMPLOYEE
(0, 1) (1, 1)
DEPARTMENT



2.54
Representing 1-to-1, 1-to-m, m-to-m
Relationships

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



2.55


Company Database







An Example Database Application



2.56
An Example Database
Application
The Company database keeps track of a
companys
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.57
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 employees
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.58
An Example Database
Application
We want to keep track of the dependents of
each employee for insurance purposes.
We keep each dependents first name, sex, birth
date, and relationship to the employee









2.59
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.
DEPARTMENT
Name Number Locations
NumberOfEmployee



2.60
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
PROJECT
Name Number Location



2.61
ER diagram for the company
database
We store each employees name, social security number, address, salary, sex,
and birth date.
EMPLOYEE
Name SSN Address
Salary
Sex
BDate
Fname
Minit
Lname



2.62
ER diagram for the company
database
We want to keep track of the dependents of each employee for insurance
purposes. We keep each dependents first name, sex, birth date, and
relationship to the employee
DEPENDENT
Relationship
Sex
BDate
Fname



2.63
(0,1)
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
EMPLOYEE DEPARTMENT Manages
StartDate
(1,1)
manager
department
managed



2.64
employee
(1,1)
ER diagram for the company
database
An employee is assigned to one department.
EMPLOYEE DEPARTMENT Works_for
(1,N)
department



2.65
ER diagram for the company
database
A department controls a number of projects
DEPARTMENT PROJECT Controls
(0,N)
(1,1)
controlling
department
controlled
project



2.66
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
EMPLOYEE PROJECT Works_on
(0,N)
(1,N)
worker
project
Hours



2.67
ER diagram for the company
database
We keep track of the direct supervisor of each
employee
EMPLOYEE
Supervises
(0,N) (0,1)
supervisor
supervisee



2.68
ER diagram for the company
database
We want to keep track of the dependents of each
employee for insurance purposes.
EMPLOYEE DEPENDENT has
(0,N)
(1,1)
employee
dependent



2.69
Reduction of an E-R schema to Tables



2.70
S(s1, , , )
T(t1, )
Binary 1:1 relationship
Either choose S and place the primary key of
T as a foreign key in S.
S
R
T
r1
s1
t1
t1 r1
FK
1 1



2.71
T(t1, , , )
S(s1, )
Binary 1:1 relationship
Or choose T and place the primary key of S as
a foreign key in T.
S
R
T
r1
s1
t1
s1
r1
FK
* It is always better to choose the entity with total participation
1 1



2.72
DEPARTMENT MANAGER
manages
Dname location
No
Name
date
This
Department (Dname, location)
Manager (No, Name, Dname, date)
OR
Department (Dname, location, no, date)
Manager (No, Name)
This is better
Example: Binary 1:1 relationship
1 1



2.73
Binary 1:N relationship
T S R
1
N
t1
r1 r2 s1
S(s1, , t1, r1, r2)
T(t1, )
T(t1, , s1, r1, r2)
S(s1, )
We place the FK in the entity which has cardinality 1



2.74
Binary M:N relationship
E1
E2
R
M N
r1 r1
1 e
2 e
E1(e1, ..)
E2(e2, ..)
R(e1, e2, r1, r2)
Create a new relation R to represent R
e1 is FK in R references E1 and
e2 is FK in R references E2
Both form a PK for R



2.75
Multi-valued attributes
E1
e1
K
E1(K, )
R(K, e1)
K is a FK in R references E1
and
K and e1 form a PK for R



2.76
EMPLOYEE
SSN
Phone
EMPLOYEE(SSN, )
PHONE(SSN, Phone#)
Another solution, but above is better
EMPLOYEE(SSN, , phone1, phone2, phone3)
Multi-valued attributes



2.77
For each n-ary relationship R, n > 2,
create a new relation to represent R.
The primary key of R will be the
primary keys of all entity types that
participate in R

n-ary relationship R, n > 2,



2.78
E3 E2
E1
R
e1
e2
3 e
E1(e1, ) E2(e2, )
E3(e3, ) R(e1, e2, e3, r1)
r1
n-ary relationship R, n > 2,



2.79
Weak Entity Type
E
e1
e2 e3
r
W
w1
w2
w3
w5
w4
E(e1, e2, e3, )
W(e1, w1, w2,w4, w5)
e1 is a FK in W references E and
both w1 and e1 form a PK of W



2.80
An Example (1)








advises PROFFESOR
SSN
Name
Rank
1 m
STUDENT
SSN
Name GPA



2.81
An Example (2)
Two relations are sufficient:
Professors Students
SSN Name Rank SSN Name GPA PSSN
123 Jack Prof. 456 John 3.4 123
234 Ann Prof. 567 Carl 3.2 123
345 Bob Prof. 678 Ken 3.5 345