COMP232 DBMS Lecture 5 - Database Design (1).pptx

Database
Management System
[COMP 232, Credit: 3, September 2024]
Sanjog Sigdel,
Lecturer, DoCSE
Kathmandu University

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
Sanjog Sigdel, September 2024

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

● 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,
One-to-Many 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
Many-to-One Relationship

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

● 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
Total and Partial Participation

ER Diagram Example
Department
Offers
Courses
teaches
enrollm
ent
advisor
Professor
Courses
major
faculty

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.
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)
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
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
Design Issues

Example: Ternary Relationship
● 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.
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.
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.
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.
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
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
Design Issues

Design Issues
Database Management System | COMP 232 | September 2024
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
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.
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
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)
23

COMP232 DBMS Lecture 5 - Database Design (1).pptx

More Related Content

Similar to COMP232 DBMS Lecture 5 - Database Design (1).pptx (20)

Recently uploaded (20)

COMP232 DBMS Lecture 5 - Database Design (1).pptx