Database

Kathmandu University
Management
System
[COMP 232, Credit: 3, June 2025]
Pratit Raj Giri
DoCSE
Course Contents
1. Introduction: Database Systems Applications, Database System versus File systems,
View of Data, Database Languages, Database Users and Administrators, Transaction
Management, Database Architecture. [3 Hrs]

2. Database Design: Design Process, Entity Relationship Model, Constraints, Keys,

Entity-Relationship Diagram, Design Issues, Weak Entity Sets, Extended E-R
features, Design of an E-R Database Schema, Reduction of an E-R Schema to tables.
[6 Hrs.]

Database Management System | COMP 232 | September 2024 2

 Recap of past lecture
- Mapping Cardinality Constraint
- Primary Key
- Weak Entity Sets

Database Management System | COMP 232 | September 2024 3

 One-to-Many Relationship
● one-to-many relationship between an instructor and a student
○ an instructor is associated with several (including 0) students via
advisor
○ a student is associated with at most one instructor via advisor,

Database Management System | COMP 232 | September 2024 4

 Many-to-One Relationship
● In a many-to-one relationship between an instructor and a student,
○ an instructor is associated with at most one student via advisor,
○ and a student is associated with several (including 0) instructors via
advisor

Database Management System | COMP 232 | September 2024 5

 Many-to-Many Relationship
● An instructor is associated with several (possibly 0) students via advisor
● A student is associated with several (possibly 0) instructors via advisor

Database Management System | COMP 232 | September 2024 6

 Total and Partial Participation
● Total participation (indicated by double line): every entity in the entity set
participates in at least one relationship in the relationship set

participation of student in advisor relation is total

○ every student must have an associated instructor
● Partial participation: some entities may not participate in any relationship in
the relationship set
○ Example: participation of instructor in advisor is partial

Database Management System | COMP 232 | September 2024 7

 Department ER Diagram Example
Offers

faculty
major

teache
s
Courses
Professor

enroll
ment
advisor

Courses

Database Management System | COMP 232 | September 2024 8

9
 Design Issues
Design choices:

1. Should a concept be modeled as an entity or an attribute?

2. Should a concept be modeled as an entity or a relationship?
3. Identifying relationships: Binary or ternary? Aggregation?

Constraints in the ER Model:

4. A lot of data semantics can (and should) be captured.

5. But some constraints cannot be captured in ER diagrams.

Database Management System | COMP 232 | September 2024 10

 Design Issues
Use of entity sets vs. attributes

- Use of phone as an entity allows extra information about phone numbers.

- Should phone be an attribute of Employees or an entity (connected to
inst_phone by a relationship)?
- Depends upon the use we want to make of phone information, and the
semantics of the data:
- If we have several phone per employee, phone must be an entity (since
attributes cannot be set-valued)

Database Management System | COMP 232 | September 2024 11

 Design Issues
Use of entity sets vs. relationship sets
Possible guideline is to designate a relationship set to describe an action that occurs
between entities

Database Management System | COMP 232 | September 2024 12

 Design Issues
Binary versus n-ary relationship sets
Although it is possible to replace any nonbinary (n-ary, for n > 2) relationship set
by a number of distinct binary relationship sets, a n-ary relationship set shows more
clearly that several entities participate in a single relationship.

e.g., attribute date as attribute of advisor or as attribute of student

Database Management System | COMP 232 | September 2024 13

Example: Ternary Relationship Design Issues
● Entities:
○ Student (e.g., student_id, name)
○ Course (e.g., course_id, course_name)
○ Instructor (e.g., instructor_id, name)
● Ternary Relationship:
○ Enrolled captures that a student is enrolled in a course taught by a specific instructor.

In this case, the relationship is best modeled as a ternary relationship because all three entities are
directly connected in a meaningful way that depends on all of them.

Database Management System | COMP 232 | September 2024 14

 Design Issues
Benefits of an n-ary Relationship
● Clearer Representation of Participation:
● Preventing Redundancy and Ambiguity:

If we were to decompose this relationship into multiple binary

relationships, we might need to create:

1. A relationship between Student and Course.

2. A relationship between Course and Instructor.
3. Possibly, a relationship between Student and Instructor.

Database Management System | COMP 232 | September 2024 15

 Design Issues
Benefits of an n-ary Relationship
● Clearer Representation of Participation
● Accurate Modeling of Real-World Constraints:
● Preventing Redundancy and Ambiguity:

If we were to decompose this relationship into multiple binary

relationships, we might need to create:

1. A relationship between Student and Course.

2. A relationship between Course and Instructor.
3. Possibly, a relationship between Student and Instructor.

Database Management System | COMP 232 | September 2024 16

 Design Issues
Drawbacks of Using Binary Relationships

● Loss of Context
● Increased Complexity

Managing multiple binary relationships often requires extra joins in SQL

queries, which can lead to more complex database operations and lower query
performance. These joins are not as efficient as directly working with a
single, well-defined n-ary relationship.

Database Management System | COMP 232 | September 2024 17

 Design Issues
Cardinality Constraints on Ternary Relationship

- We allow at most one arrow out of a ternary (or greater degree) relationship to
indicate a cardinality constraint
- 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 Management System | COMP 232 | September 2024 18

 Design Issues
Converting Non-Binary Relationships to Binary Form

- In general, any non-binary relationship can be represented using binary

relationships by creating an artificial entity set.
- Replace R between entity sets A, B and C by an entity set E, and three
relationship sets:

1. RA, relating E and A 2. RB, relating E and B

3. RC, relating E and C

- Create a special identifying attribute for E

Database Management System | COMP 232 | September 2024 19

 Design Issues
Converting Non-Binary Relationships to Binary Form

- Add any attributes of R to E

- For each relationship (ai , bi , ci) in R, create

1. a new entity ei in the entity set E 2. add (ei , ai ) to RA

3. add (ei , bi ) to RB 4. add (ei , ci ) to RC

Database Management System | COMP 232 | September 2024 20

 Reduction to Relational Schemas
● Entity sets and relationship sets can be expressed uniformly as relation schemas
that represent the contents of the database.
● A database which conforms to an E-R diagram can be represented by a collection
of schemas.
● For each entity set and relationship set there is a unique schema that is assigned the
name of the corresponding entity set or relationship set.
● Each schema has a number of columns (generally corresponding to attributes),
which have unique names.

Database Management System | COMP 232 | September 2024 21

 Reduction to Relation Schemas
A strong entity set reduces to a schema with the same attributes

student(ID, name, tot_cred)

A weak entity set becomes a table that includes a column for the primary key of the
identifying strong entity set

section ( course_id, sec_id, sem, year )

Example

Database Management System | COMP 232 | September 2024 22

 Representation of Entity Sets with Multivalued Attributes

- A multivalued attribute M of an entity E is represented by a separate schema EM

- Schema EM has attributes corresponding to the primary key of E and an attribute
corresponding to multivalued attribute M
- Example: Multivalued attribute phone_number of instructor is represented by a
schema:

inst_phone= ( ID, phone_number)

- Each value of the multivalued attribute maps to a separate tuple of the relation on
schema EM

For example, an instructor entity with primary key 22222 and phone
numbers 456-7890 and 123-4567 maps to two tuples:
(22222, 456-7890) and (22222, 123-4567)

Database Management System | COMP 232 | September 2024 23