LECTURE 1:

Entity Relationship MODEL

Some of the following slides are
from your text book or based on the
examples from your text book!
Think before doing it!
 Like most of the software projects, you need to think
before you do something.
 Before developing your database application, you need
to collect the requirements, and build a conceptual
model.
 ER model is a widely accepted standard for conceptual
DB design.
ER Model
 Key concepts of ER model
 Entities
 Relationships
 Entity:
 Is an object that exists and that can be distinguished
from other objects

Students Courses

Instructors
ER Model
 Entity Has attributes that describe
it

name address

id
 ER Model
 Entity set:
 Is the set of entities that share the
same properties

Instructors
Courses
Y. Saygın H. Yenigün
CS306 MATH204

A.Levi E. Savaş CS308

ER Model
 Entity sets may overlap
 Example?

Instructors
Students
ER Model
 Relationships:
 Relate two or more entities (such as Ali is

enrolled in CS306)
ER Model
 Relationships:
 Relate two or more entities (such as Mert is enrolled in
CS306)
 Relationship sets:
 Collection of all relationship sets with the same properties
(all student enrollments)
 ER Model

sid student
name

Rectangles : Entity sets

Ellipses : attributes
 ER Model
cname

sid student
Course
name
cid

Rectangles : Entity sets

Ellipses : attributes
 ER Model
cname

sid student Enrolled

Course
name
cid

Rectangles : Entity sets

Diamonds : Relationship Sets
Ellipses : attributes
ER Model
 Each entity set has attributes
 Each attribute has a domain (domain is the set of
permitted values)

sid student
name
ER Model
 Each entity set has attributes
 Each attribute has a domain (domain is the set of
permitted values)
 Each entity set has a key
 Keys are denoted by underlining the attribute name in
the ER diagram

sid student
name
 ER Model
cname

sid student Enrolled

Course
name
cid

 Relationship sets also have attributes

 ER Model
semester cname

sid student Enrolled

Course
name
cid

 Relationship sets also have attributes

 ER Model
semester cname

sid student Enrolled

Course
name
cid

 Degree of a relationship set is the number of entity sets

that participate in a relationship
 Binary relationship sets involve two entity sets
ER Model
 Ternary relationship sets involve three entity sets

customer borrows branch

loan
 ER Model
 We may have relationships among the entities that belong to
the same entity set (Unary Relationships)
 each entity has a role in such a relationship

sid student name

students

helps
ER Model
 We may have relationships among the entities that belong to
the same entity set (Unary Relationships)
 each entity has a role in such a relationship

sid student name

tutor tutee

helps
ER Model

eid employer ename

ER Model

eid employer ename

Reports_to
ER Model

eid employer ename

supervisor

Reports_to
ER Model

eid employer ename

supervisor subordinate

Reports_to
ER Model
 Ternary relationship sets

customer branch

loan
ER Model
 Ternary relationship sets

customer borrows branch

loan
 Mapping cardinalities
 One-to-One relationship (ex: manages relationship between
employees and departments)

Employees Departments

1-to-1
 Mapping cardinalities


One-to-Many: If an employee can manage multiple departments

1-to-1 1-to Many

 Mapping cardinalities


Many-to-One: If Multiple employees can manage a department
(but not vice versa)

1-to-1 1-to Many Many-to-1

 Mapping cardinalities


Many-to-Many: If An employee can managemultiple
departments and a department can be managed by multiple
employees.

1-to-1 1-to Many Many-to-1 Many-to-Many

 since
name dname
ssn lot did budget

 Consider the works_in Works_In

Employees Departments
relationship
 If an employee can work in
multiple departments and a
department can have
multiple employees
 What type of relationship is
that?

1-to-1 1-to Many Many-to-1 Many-to-Many

 since
name dname
ssn parking-lot did budget

 Consider the manages Employees Manages Departments

relationship

 If an employee can
manage multiple
departments but a
department has only
one manager

 What type of
relationship is that?

 This is called a key

constraint (denoted
with an arrow)
1-to-1 1-to Many Many-to-1 Many-to-Many
 since
dname name
did budget ssn parking-lot

 Consider the manages Departments Manages Employees

relationship

 If an employee can
manage multiple
departments but a
department has only
one manager

 What type of
relationship is that?

 This is called a key

constraint (denoted
with an arrow)
1-to-1 1-to Many Many-to-1 Many-to-Many
 since
dname name
did budget ssn parking-lot

 If an employee can Departments Manages Employees

manage only one
department and a
department has
only one manager

 What type of
relationship is
that?

1-to-1 1-to Many Many-to-1 Many-to-Many

 Participation Constraints
 If every department MUST have a manager, then there is a (total)
participation constraint
 The participation of Departments in Manages is total (otherwise it is
partial).

since
name dname
ssn lot did budget

Employees Manages Departments

Works_In

since
 Participation Constraints
 Participation constraints are denoted with a thick line (for example
each department must participate in the manages relationship,
therefore this is denoted with a thick line in the relationship)

since
name dname
ssn lot did budget

Employees Manages Departments

Works_In

since
 Participation Constraints
 If every employee MUST work in a department, then there is a
participation constraint on employee entity set

since
name dname
ssn lot did budget

Employees Manages Departments

Works_In

since
 Participation Constraints
 Plus, if every department MUST have employee(s) working in that
department, then there is a participation constraint on department
entity set

since
name dname
ssn lot did budget

Employees Manages Departments

Works_In

since
 name
ssn lot

ISA (`is a’) Hierarchies Employees

hourly_wages hours_worked

contractid

Hourly_Emps Contract_Emps
 name
ssn lot

ISA (`is a’) Hierarchies Employees

hourly_wages hours_worked
ISA
contractid

Hourly_Emps Contract_Emps
 name
ssn lot

Employees

hourly_wages hours_worked
ISA
contractid

Hourly_Emps Contract_Emps

 Overlap constraints: Can Serafettin be an Hourly Employee as

well as a Contract Employee?
 Covering constraints: Does every Employee also have to be an
Hourly Employee or a Contract Employee?
 Reasons for using ISA:
 To add descriptive attributes specific to a subclass.
 To identify entities that participate in a relationship.
 Specialization vs. generalization
 Weak Entities
 A weak entity can be identified uniquely only by
considering the primary key of another (owner) entity.

name
cost pname age
ssn lot

Employees Policy Dependents

 Weak Entities
 A weak entity can be identified uniquely only by
considering the primary key of another (owner) entity.
 A weak entity set is denoted by a rectangle with thick
lines

name
cost pname age
ssn lot

Employees Policy Dependents

 Weak Entities

 A weak entity can be identified uniquely only by

considering the primary key of another (owner) entity.
 A weak entity set is denoted by a rectangle with thick
lines
 The relationship between a week entity and the
owner entity is denoted by a diamond with thick lines.
name
cost pname age
ssn lot

Employees Policy Dependents

 Weak Entities

 A weak entity can be identified uniquely only by

considering the primary key of another (owner) entity.
 What can you say about the constraints on the
indentifying relationship? (i.e., participation and key
constraints)
name
cost pname age
ssn lot

Employees Policy Dependents

 Weak Entities
 A weak entity can be identified uniquely only by
considering the primary key of another (owner) entity.
 Owner entity set and weak entity set must participate in a
one-to-many relationship set (one owner, many weak
entities).
 Weak entity set must have total participation in this
identifying relationship set.
name
cost pname age
ssn lot

Employees Policy Dependents

Example:
 For the following entities: Banks, branches, accounts
and customers.
 Lets think of some attributes, relationships, and
constraints, then draw the ER diagram.
Example:
 Draw the ER diagram for the following specifications:
There are movies, actors, directors. Directors direct
movies, and actors play in movies. There are also studios
who own movies.
 Lets think of some attributes and constraints, then draw
the ER diagram.
Example:
 What if there is a remake of a movie?
 name
ssn lot

Aggregation Employees

 Used when we
have to model a Monitors until
relationship
involving (entitity
since
sets and) a started_on
dname
relationship set. pid pbudget did budget
 Aggregation allows
Projects Sponsors Departments
us to treat a
relationship set as
an entity set for  Aggregation vs. ternary relationship:
purposes of Monitors is a distinct relationship,
participation in with a descriptive attribute.
(other)
relationships. Also, can say that each sponsorship
is monitored by at most one employee.
 Conceptual Design Using the ER
Model

 Design choices:
 Should a concept be modeled as an entity or an
attribute?
 Should a concept be modeled as an entity or a
relationship?
 Identifying relationships: Binary or ternary? Aggregation?
 Constraints in the ER Model:
 A lot of data semantics can (and should) be captured.
 But some constraints cannot be captured in ER diagrams.
 Entity vs. Attribute

 Should address be an attribute of Employees or an

entity (connected to Employees by a relationship)?
 Depends upon the use we want to make of address
information, and the semantics of the data:

If we have several addresses per employee, address must be
an entity (since attributes cannot be set-valued).

If the structure (city, street, etc.) is important, e.g., we want
to retrieve employees in a given city, address must be
modeled as an entity (since attribute values are atomic).
 Entity vs. Attribute (Contd.)
from to
name dname
ssn lot did budget

Employees Works_In2 Departments

 Works_In2 does not
allow an employee to
work in a department
for two or more periods.
 Similar to the problem of
name dname
wanting to record several ssn lot did budget
addresses for an
employee: we want to Employees Works_In3 Departments
record several values of
the descriptive attributes
from Duration to
for each instance of this
relationship.
 Binary vs. Ternary Relationships
name
ssn lot pname age
 If each policy is
Employees Covers Dependents
owned by just 1
employee: Bad design Policies
 Key constraint on
Policies would policyid cost
mean policy can
only cover 1 name pname age
ssn lot
dependent!
Dependents
Employees

Purchaser
Beneficiary

Better design Policies

policyid cost
 Summary of Conceptual Design

 Conceptual design follows requirements analysis,

 Yields a high-level description of data to be stored
 ER model popular for conceptual design
 Constructs are expressive, close to the way people think about their
applications.
 Basic constructs: entities, relationships, and attributes (of entities
and relationships).
 Some additional constructs: weak entities, ISA hierarchies, and
aggregation.
 Note: There are many variations on ER model.
 Summary of ER (Contd.)

 Several kinds of integrity constraints can be expressed

in the ER model: key constraints, participation
constraints, and overlap/covering constraints for ISA
hierarchies. Some foreign key constraints are also
implicit in the definition of a relationship set.
 Some constraints cannot be expressed in the ER model.
 Constraints play an important role in determining the best
database design for an enterprise.
 Summary of ER (Contd.)
 ER design is subjective. There are often many ways
to model a given scenario! Analyzing alternatives
can be tricky, especially for a large enterprise.
Common choices include:
 Entity vs. attribute, entity vs. relationship, binary or n-ary
relationship, whether or not to use ISA hierarchies, and
whether or not to use aggregation.
 Ensuring good database design: resulting relational
schema should be analyzed and refined further
which we will study later on.
Second Step of the project
 Based on the requirements of your application
 Write down a list of entities of your application
 Draw the ER diagram including attributes and
relationships.
 Write down the constraints (key constraints,
participation constraints etc) that you have
specified in your ER diagram.