Participation of an Entity Set in a

Relationship Set
Total participation (indicated by double line): every entity in the
entity set participates in at least one relationship in the relationship
set
E.g., participation of section in sec_course is total
 every section must have an associated course
Partial participation: some entities may not participate in any
relationship in the relationship set
Example: participation of instructor in advisor is partial

Database System Concepts - 6th Edition 7.1 ©Silberschatz, Korth and Sudarshan
 Roles

Entity sets of a relationship need not be distinct

Each occurrence of an entity set plays a “role” in the relationship
The labels “course_id” and “prereq_id” are called roles.

Database System Concepts - 6th Edition 7.2 ©Silberschatz, Korth and Sudarshan
 Keys for Relationship Sets

The combination of primary keys of the participating entity sets

forms a super key of a relationship set.
(s_id, i_id) is the super key of advisor
NOTE: this means a pair of entity sets can have at most one
relationship in a particular relationship set.
Must consider the mapping cardinality of the relationship set when
deciding what are the candidate keys
Need to consider semantics of relationship set in selecting the
primary key in case of more than one candidate key

Database System Concepts - 6th Edition 7.3 ©Silberschatz, Korth and Sudarshan
 Weak Entity Sets

An entity set that does not have a primary key is referred to as a

weak entity set.
The existence of a weak entity set depends on the existence of an
identifying entity set
It must relate to the identifying entity set via a total, one-to-many
relationship set from the identifying to the weak entity set
Identifying relationship depicted using a double diamond
The discriminator (or partial key) of a weak entity set is the set of
attributes that distinguishes among all the entities of a weak entity
set.
The primary key of a weak entity set is formed by the primary key of
the strong entity set on which the weak entity set is existence
dependent, plus the weak entity set’s discriminator.

Database System Concepts - 6th Edition 7.4 ©Silberschatz, Korth and Sudarshan
 Weak Entity Sets (Cont.)
We underline the discriminator of a weak entity set with a dashed
line.
We put the identifying relationship of a weak entity in a double
diamond.
Primary key for section – (course_id, sec_id, semester, year)

Database System Concepts - 6th Edition 7.5 ©Silberschatz, Korth and Sudarshan
 Weak Entity Sets (Cont.)
Note: the primary key of the strong entity set is not explicitly stored
with the weak entity set, since it is implicit in the identifying
relationship.

If course_id were explicitly stored, section could be made a strong

entity, but then the relationship between section and course would
be duplicated by an implicit relationship defined by the attribute
course_id common to course and section

Database System Concepts - 6th Edition 7.6 ©Silberschatz, Korth and Sudarshan
 The university is organized into departments. Each department is
identified by a unique name (dept name), is located in a particular
building, and has a budget.
Each department has a list of courses it offers. Each course has
associated with it a course id, title, dept name, and credits, and may
also have associated prerequisites.
Instructors are identified by their unique ID. Each instructor has
name, associated department (dept name), and salary.
Students are identified by their unique ID. Each student has a name,
an associated major department (dept name), and tot cred (total credit
hours the student earned thus far).

Database System Concepts - 6th Edition 7.7 ©Silberschatz, Korth and Sudarshan
 The university maintains a list of classrooms, specifying the name of the
building, room number, and room capacity.
• The university maintains a list of all classes (sections) taught. Each section is
identified by a course id, sec id, year, and semester, and has associated with it
a semester, year, building, room number, and time slot id (the time slot when the
class meets).
• The department has a list of teaching assignments specifying, for each
instructor, the sections the instructor is teaching.
• The university has a list of all student course registrations, specifying, for
each student, the courses and the associated sections that the student has
taken (registered for).

Database System Concepts - 6th Edition 7.8 ©Silberschatz, Korth and Sudarshan
 classroom (building, room number, capacity)
department (dept name, building, budget)
course (course id, title, credits)
instructor (ID, name, salary)
student (ID, name, tot cred)
section(course id, sec id, semester, year)

Database System Concepts - 6th Edition 7.9 ©Silberschatz, Korth and Sudarshan
 teaches (ID, course id, sec id, semester, year)
takes (ID, course id, sec id, semester, year, grade)
prereq (course id, prereq id)
advisor (s ID, i ID)
sec_ course (course id, sec id, semester, year)
sec_ time slot (course id, sec id, semester, year, time slot id)
sec class (course id, sec id, semester, year, building, room number)
inst dept (ID, dept name)
stud dept (ID, dept name)
course dept (course id, dept name)

Database System Concepts - 6th Edition 7.10 ©Silberschatz, Korth and Sudarshan
 E-R Diagram for a University Enterprise

Database System Concepts - 6th Edition 7.11 ©Silberschatz, Korth and Sudarshan
 How about doing an ER design
interactively on the board?
Suggest an application to be modeled.

Database System Concepts, 6th Ed.

©Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use
 Banking Enterprise..

Major characteristics of the banking enterprise.

Bank employees are identified by their employee-id
values. The bank administration stores the name and
telephone number of each employee, the names of the
employee’s dependents, and the employee-id number of
the employee’s manager. The bank also keeps track of
the employee’s start date and, thus, length of
employment.
A customer may be associated with a particular banker,
who may act as a loan officer or personal banker for that
customer

Database System Concepts - 6th Edition 7.13 ©Silberschatz, Korth and Sudarshan
 Banking Enterprise..

Major characteristics of the banking enterprise.

The bank offers accounts—saving account. Accounts can
be held by more than one customer, and a customer can
have more than one account. Each account is assigned a
unique account number. The bank maintains a record of
each account’s balance, and the most recent date on
which the account was accessed by each customer
holding the account.
Customers may have accounts and can take out loans.

Database System Concepts - 6th Edition 7.14 ©Silberschatz, Korth and Sudarshan
 Banking Enterprise..

Major characteristics of the banking enterprise.

A loan originates at a particular branch and can be held
by one or more customers. A loan is identified by a
unique loan number. For each loan, the bank keeps track
of the loan amount and the loan payments. Although a
loan payment number does not uniquely identify a
particular payment among those for all the bank’s loans, a
payment number does identify a particular payment for a
specific loan. The date and amount are recorded for each
payment.

Database System Concepts - 6th Edition 7.15 ©Silberschatz, Korth and Sudarshan
 E-R Diagram for a Banking Enterprise

06-Feb-20 2:43
Database System Concepts - 6th Edition 7.16 ©Silberschatz, Korth and Sudarshan
 E-R Diagram for a Banking Enterprise

06-Feb-20 2:43
Database System Concepts - 6th Edition 7.17 ©Silberschatz, Korth and Sudarshan
E-R Model: Redundant Attributes, E-R
Diagrams

Database System Concepts, 6th Ed.

©Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use
 Redundant Attributes
Suppose we have entity sets
instructor, with attributes including dept_name
department
and a relationship
inst_dept relating instructor and department
Attribute dept_name in entity instructor is redundant since there
is an explicit relationship inst_dept which relates instructors to
departments
The attribute replicates information present in the relationship, and
should be removed from instructor
BUT: when converting back to tables, in some cases the attribute
gets reintroduced, as we will see.

Database System Concepts - 6th Edition 7.19 ©Silberschatz, Korth and Sudarshan
 Alternative Notation for Cardinality Limits

Cardinality limits can also express participation constraints

Database System Concepts - 6th Edition 7.20 ©Silberschatz, Korth and Sudarshan
 E-R Diagram with a Ternary Relationship

Database System Concepts - 6th Edition 7.21 ©Silberschatz, Korth and Sudarshan
 Cardinality Constraints on Ternary
Relationship
We allow at most one arrow out of a ternary (or greater degree)
relationship to indicate a cardinality constraint
E.g., an arrow from proj_guide to instructor indicates each student has
at most one guide for a project
If there is more than one arrow, there are two ways of defining the
meaning.
E.g., a ternary relationship R between A, B and C with arrows to B
and C could mean
1. each A entity is associated with a unique entity from B and C or
2. each pair of entities from (A, B) is associated with a unique C
entity, and each pair (A, C) is associated with a unique B
Each alternative has been used in different formalisms
To avoid confusion we outlaw more than one arrow

Database System Concepts - 6th Edition 7.22 ©Silberschatz, Korth and Sudarshan