ENHANCED ENTITYRELATIONSHIP MODEL

Textbook: 7.5-7.11

Review
The Entity Relationship data model
Entities and attributes
Key attributes (candidate and primary keys)
Relationships
Participation and cardinality constraints

Attributes
Simple
Composite
Single-valued
Multivalued
Derived
For any attribute there is a set of possible values

defined, called the attribute domain

Relationship degree
UNARY
between instances from one entity set
BINARY
between instances from two entity sets
TERNARY
between instances from three entity set
N-ARY
among entities from more than three entity sets

Relationship degree (2)

TERNARY
between instances from three entity set
N-ARY
among entities from more than three entity sets

Participation
Some courses are not

Every student takes

taken by any student

(partial participation)

at least one course

(total participation)

students
Dave

courses
takes
2002ICT

Ken
Lisa

2506ICT
1234ICT
3502ICT

Participation constraints
Every student takes

Some courses are not

at least one course

(total participation)

taken by any student

(partial participation)

total participation of

partial participation of

Student in Take

Course in Take

Cardinality
Measures how many instances of entity set B can be

related to an entity instance of entity set A

students
Dave
Ken
John
Lisa
Tom

schools

belongs to
ICT
ENG
CHE
PHY

Cardinality constraints
Employee

has

Spouse

Customer

1
(0,M)

places

N
(1,1)

Student

M
(1:M)

enrolls

N
(0:N) Subject

Order

(min, max) notation (2)

students
Dave
Ken
John
Lisa
Tom

schools
belongs to
ICT
ENG
CHE
PHY

Some notes
ERD design is subjective, there can be more than one

correct ERDs meeting system requirements

There is no guarantee that every semantic constraint can
be represented in ERD
The ERD should be verified against normalization (lecture
later).
Pay attention to "clarity" when drawing ERD, e.g.,
avoid line crossings as much as possible,
use meaningful entity/relationship names,
usually read in top-down and left-right order.

Overview
Weak entity types,

weak entity
identifying entity
identifying relationship
Constraint on higher order relationship types
Roles
Attributes of relationship types
Generalization and specialization

Weak entity types

Weak entity types are entity types which have no key

attributes of their own

Employee
SSN

Depends
on

Name

Dependent
DName

partial key
Primary key partially or totally derived from identifying/

owner entity
E.g., the primary key of Dependent is {SSN, DName}

Weak entity types (2)

Need an
identifying entity

Need an identifying
relationship

Must be total
participation

Must be 1
Employee
SSN

Weak entity

Depends
on

Name

Dependent
DName

partial key

Higher order relationships

Ternary relation: Supplier supplies Part to Project

s1

p1

proj1

s2

p1

proj2

Higher order relationships

Ternary relation: Supplier supplies Part to Project

s1

p1

p1

proj1

s2

p1

p1

proj2

Supplies can not be decomposed into two elementary

fact types: e.g. s1 supplies p1 and p1 is used by proj1

loses information about which supplier supplied p1 to
proj1 ! (e.g. it could be that s2 supplied p1 to proj1)

Constraints on higher order relations

Assume that if a supplier supplies a part to a project then

it is not allowed to supply anything to any other project.

Assume also that every project must have at least one
part supplied to it, and parts may be represented in the
database even if no project uses them at the moment.
Supplier

(0,1)

Supplies
(0,N)

Part

(1,N)

Project

Constraints on higher order relations

Assume that if a supplier supplies a part to a project then

it is not allowed to supply anything to any other project.

Assume also that every project must have at least one
part supplied to it, and parts may be represented in the
database even if no project uses them at the moment.
Supplier

(0,1)

Supplies
(0,N)

Part

(1,N)

Project

Constraints on higher order relations

Assume that if a supplier supplies a part to a project then

it is not allowed to supply anything to any other project.

Assume also that every project must have at least one
part supplied to it, and parts may be represented in the
database even if no project uses them at the moment.
Supplier

(0,1)

Supplies
(0,N)

Part

(1,N)

Project

Alternatives
For each course in each school, there are a unique

teacher that teaches the course using a unique textbook.

Text
1
Teacher

teaches

School

M
Course
A course in a school uniquely identify a teacher and a
textbook.

Alternatives for higher order relationship

What if we can represent binary relationship types only?

(e.g. a CASE tool often places this restriction)

Supplier

(0,1)

Supplies
(0,N)

Part

(1,N)

Project

Alternatives for higher order relationship

Supplier

(0,1)
(1,1)

Supplies

(1,N)
(1,1)

Project

(1,1)
(0,N)

Part
Supplies becomes an entity (think of it as a supply

contract)
The PK of Supplies is the combination of PKs of
Supplier, Part, and Project.

Alternatives for higher order relationship

Supplier

(0,1)

Ha
Ha
Supply
s (1,1)
s
(1,1)

(1,N)

Project

(1,1)

Ha
s
(0,N)

Part
Supply is a weak entity type, with the owner entity type

Supplier (Why not Part and Project?)

Alternatively we can invent a new PK for Supplies (e.g.
contract number)

Roles
Unary relation: Employee supervises Employee
Who supervises whom?
E.g. John Supervises Paul and Mary
Role name

Employee
(0,1)

(0,N)
Supervisor
Supervises

Supervisee

Attributes of relationship types

Price is not an attribute of any of the entities, it is an

attribute of the relationship type Supplies. (The price is

determined for the deal)
Price

Supplier

(0,1)

Supplies
(0,N)

Part

(1,N)

Project

Understanding ER diagram

Class and subclass

Staff is subclass of person, student is subclass of person
Part-time staff, fulltime staff, casual staff are all

subclasses of staff
Overseas student, local student, postgraduate student,
undergraduate student, research student, coursework
student are all students
Subclass

Class

Relationship between class and its subclasses is called

class/subclass relationship, also known as ISA

relationship.

Generalization and specialization

Resemblance between a class and its subclasses

Address

Name

SSN

Staff

Address

Name

SSN

Manager
Level

Inheritance
Attributes SSN, Name, Address are inherited from

Staff
Address

Name
Staff

SSN
specialization

generalization
Manager
Level

Alternative notation
Address

Name

SSN

Staff

Manager
Level

Derived type
Attributes SSN, Name, Address are inherited from

Staff
Address

Name

SSN

Staff
Address = Brisbane
Local
Staff

Why ISA relationship?

Class/subclasses are used to avoid describing different

types of things within a single entity with the resultant

mismatch.
Certain attributes may apply to the entities in the
subgroup. For example:
only sales_personnel have a car_allowance all other
staff need this value to be null.
Only entities in the subgroup participates in some
relationship with some other entities. Eg
only technicians Maintains equipment

Constraints on ISA relationship

An ISA relationship can be
Total or partial
Disjoint or overlapping

Staff
Overlapping
subclasses
represented by o

Total participation by
double line

Disjoint
subclasses by d

Reservist
Manager

Engineer

Full-time

Part-time

Partial generalization / specialization

Technician

Others

Salesman

Staff

Staff
Single line means
partial generalization

Technician

d stands for disjoint

Salesman

Total generalization / specialization

Part-time

Full-time

Staff
Double line means
total generalization

Full-time

Part-time

Staff

Overlapping specialization
Engineer

Manager

Staff

Staff
o

Manager

o stands for
overlapping
Engineer

Summary
Weak Entity types,
Constraint on higher order relationship types
Roles
Attributes of relationship types
Enhanced ER
Generalization and specialization hierarchies