CSE 207

DATABASE SYSTEMS
FINAL TERM EXAMINATION

Name: Umair Hossain

ID: 21225103103 INATKE: 49 SECTION: 07
ER Modeling
Entity-relationship (ER) modeling: is a technique used in database design to represent the structure of a
database and the relationships between different entities or tables within the database.
• Enables the structuring and organizing of the requirements collection process.
• Provides a way to graphically represent the requirements.
ER diagram (ERD): shows the relationship among the entity sets also helps to visualize the logical structure
of database.
• Serves as a blueprint for the database.

CUSTOMER
CustID CustName CustGender custBDate
1 Umair Male 18-09-23
2 Tomal Male 20-12-23

Uses of Entity Relationship Diagram

• The primary use of ER diagrams is to design a database by graphically defining the components of
entity relationship model.
• ER diagram helps you in identifying the entities, attributes associated with them and the relationship
between those entities that are required to design a particular database.
• ER diagram also helps you in debugging if there is any flaw or error in the logical structure of the
database or if there occurs an error in its deployment.

Symbols and Notations

Links to Entity sets

Total Participation

Rectangles illustrate the entity set.

Diamond illustrates the relationship between
the entity set.
Ellipse illustrates the attributes of an entity set.
Lines illustrate the association of attributes to
the entity set and the association of entity set to
the relationship set.

1|P age
Types of Entity
Entities: These are the main objects or concepts about which data is to be stored. Entities are typically
represented as rectangles in diagrams, and they correspond to database tables in the actual database.
• The basic building blocks of an ER diagram
• Represent various real-world notions, such as people, places, objects, events, items, and other
concepts
• Within one ERD each entity must have a different name
Entity instances (entity members): An entity instance represents a single, concrete piece of data that
corresponds to a particular entity type defined in the ER model.
• Entities themselves are depicted in the ER diagrams while entity instances are not.
• Entity instances are eventually recorded in the database that is created based on the ER diagram.

1. Strong Entity: Which have a primary key. The entity set that is defined by using its own set of attributes
can be referred to as a strong entity set.

Strong Entity

2. Weak Entity: Does not have a primary key and it is dependent on a strong entity. The entity set that
cannot be defined by using its own set of attributes that’s why it’s always associated with another entity
set which we refer as an identifier entity set or the owner entity set.

Weak Entity

Example:
oName oAmmount
cID Name
oID oDate

Customer Orders Order

ORDER
oID oName oAmmount oDate
01 -- -- --
CUSTOMER
01 -- -- --
cID cName 02 -- -- --
01 -- -- --
103 Umair
02 -- -- --
165 Tomal
ORDER
222 Umara
cID oID oName oAmmount oDate
103 01 -- -- --
165 01 -- -- --
103 02 -- -- --
222 01 -- -- --
165 02 -- -- --
2|P age
Types of Attributes
Attribute: are the properties or characteristics of entities. They are represented as ovals or ellipses and are
connected to the respective entity. Attributes become the columns in the database tables.
• Represents the details that will be recorded for each entity instance
• Within one entity, each attribute must have a different name
Unique Attribute: attribute whose value is different for each entity instance
• Every regular entity must have at least one unique attribute

01 Simple Attributes 05 Derived Attributes

02 Composite Attributes 06 Key Attributes
03 Single Valued Attributes 07 Stored Attributes
04 Multivalued Attributes

1) Simple Attributes
• Can’t be sub-divided further into any other components.
• Known as atomic attributes.

Roll_No

Student

2) Composite Attributes
• Can be further divided into different components.

First_name Last_name

Name

Student

3) Single Valued Attributes

• Consist of a single value for each entity.
• Can not store more than one value.

Roll_no DOB

Student

3|P age
4) Multivalued Attributes
• Can not store more than one value.

Roll_no Mobile

Student

5) Derived Attributes
• Can be derived from the values of other attributes.
AGE
Roll_no DOB

Student

6) Key Attributes
• Attributes that can identify and distinguish individual records or instances in a table or entity.

Roll_No

Student

7) Stored Attributes
• Attributes which value is fixed and will not change is future.

DOB

Student

4|P age
Types of Relationship
Relationship: ER modeling construct depicting how entities are related.
• Within an ER diagram, each entity must be related to at least one other entity via a relationship

Cardinality constraints: depict how many instances of one entity can be associated with instances of another
entity.
• Maximum cardinality
One (represented by a straight bar: I)
Many (represented by a crow’s foot symbol)
• Minimum cardinality (participation)
Optional (represented by a circular symbol: 0)
Mandatory (represented by a straight bar: I)

Four possible cardinality constraints

5|P age
1) One to One: A one-to-one relationship in a database means that each item in one category is linked to exactly
one item in another category, and vice versa. It's like each person having just one passport, and each passport
belonging to just one person.

Name issue_date
Address nID
pID

1 1
Person Has a NID

PERSON NID
pID Name Address pID nID Issue_date
01 Umair Barishal 01 103…. --
01 Shipon Kushtia 01 067…. --
02 Rohan Madaripur 02 292…. --

2) One to Many: In this relationship, each record in one entity is associated with one or more records in another
entity, but each record in the second entity is associated with only one record in the first entity.

sName sDept
pID Name
sID sMark

1 M
Project Assigned Student

STUDENT
PROJECT pID sID sName sDept sMark
01 067 Shipon -- --
pID Name
01 103 Umair -- --
01 A 01 165 Tomal -- --
02 B 02 222 Umara -- --
02 292 Rohan -- --
02 300 Mahi -- --

6|P age
3) Many to One: is a type of relationship in a database where multiple records in one entity are associated with
a single record in another entity.

sName sDept
pID Name
sID sMark

M 1
Student Assigned Project

STUDENT PROJECT
sID sName sDept sMark sID pID Name
067 Shipon -- -- 067 01 A
103 Umair -- -- 103 01 A
165 Tomal -- -- 165 01 A
222 Umara -- -- 222 01 A
292 Rohan -- -- 292 01 A
300 Mahi -- -- 300 01 A

4) Many to Many: is a type of relationship in a database where multiple records in one entity can be associated
with multiple records in another entity.

cName Address
pID Name
cID Phone

M N
Customer Buys Product

STUDENT PRODUCT
cID cName Address Phone pID Name
067 Shipon -- -- 01 A
103 Umair -- -- 02 B
165 Tomal -- -- 03 C
222 Umara -- --
292 Rohan -- --
300 Mahi -- --
ORDER
cID pID
067 A
067 B
103 C
222 C
103 A
7|P age
Degree of Relationship
The degree of a relationship is the number of entity types that participate(associate) in a relationship.

01 Unary (Degree 1) 03 Ternary (Degree 3)

02 Binary (Degree 2) 04 N-ary (n Degree)

Unary (Degree 1): A unary relationship, or degree-1 relationship, exists when entity in a database is connected
to itself.

Binary (Degree 2): A binary relationship, or "degree-2" relationship, exists when exactly two entity type
participates. When such a relationship is present, we say that the degree is 2.

Ternary (Degree 3): A ternary relationship, or "degree-3" relationship, exists when exactly three entity type
participates.

N-ary (n Degree): A N-ary relationship, or "n degree" relationship, exists when ‘n’ number of entities are
participating.

Naming Convention for ER Diagram: Names should be Unique, Brief and Meaningful.

8|P age
Participation Constraints
It specifies the existence of an entity when it is related to another entity in a relational type.
Types of participation:
1. Total Participation 2. Partial Participation

Total Participation: In a total participation relationship, every entity in the entity set must participate in the
relationship.

Course Enroll Student

Partial Participation: In a partial participation relationship, entities in the entity set have the option to
participate in the relationship.

Course Enroll Student

Relational Model
It is an abstract model used to organize and manage the data stored in a database.
Components

01 Relation 05 Degree
02 Tuple 06 Cardinality
03 Attribute 07 Relational Schema STUDENT
04 Attribute Domain 08 Relational Instance cID cName Address
09 Relation Key 067 Shipon --
• Primary Key 103 Umair --
• Foreign Key 165 Tomal --
• Super Key 222 Umara --
• Candidate Key 292 Rohan --
• Composite Key 300 Mahi --
• Alternate Key

Integrity Constraints
Integrity constraints are pre-defined set of rules that are applied on the table columns/attributes to ensure that
the overall validity and consistency of the data present in the database table/relation.
Types of Integrity Constraint:
1) Domain Constraint
2) Entity Integrity Constraint
• Primary Key value can’t be null.
3) Relational Integrity Constraint
• Specified between two tables.
4) Key Constraint

9|P age
Normalization
• It is the process of organizing the data in the database.
• It is used to remove or reduce the redundancy from a relation.
• Redundancy in the relation may cause insertion, deletion and update anomalies.
Definition: In database management system (DBMS) normal forms are a series of guidelines that help to
ensure that the design of database is efficiently organized and free from data anomalies.

EMPLOYEE
emp_ID emp_Name emp_Number emp_dept dept_Mgr
067 Shipon 017-- Eng. FH
103 Umair 018-- HR. MR
165 Tomal 016-- Marketing. MJ
222 Umara 015-- Eng. FH
292 Rohan 019-- Marketing. MJ
300 Mahi 017-- Eng. FH
067 Shipon 017-- Eng. FH

EMPLOYEE
emp_ID emp_Name emp_Number dep_ID DEPT
067 Shipon 017-- 01 dep_ID dep_Name dep_Mgr
103 Umair 018-- 02 01 Eng. FH
165 Tomal 016-- 03 02 HR. MR
222 Umara 015-- 01 03 Marketing. MJ
292 Rohan 019-- 03 04 Sales UM
300 Mahi 017-- 01

First Normal Form (1NF)

An attribute of a relation can’t hold multiple values or for the first normal form a relation can’t contain multi-
valued attributes and each column should have unique name. The first normal form helps to eliminate duplicate
data and simplify queries.
STUDENT
Rules:
1) In column multi-values are not allowed. s_ID s_Name s_Course
2) Attributes domain should be same. 103 Umair Compiler,DBMS
3) Every column will have a unique name. 222 Umara Algorithm
292 Tasnia Math,DBMS
4) Doesn’t matter in which order data is stored.
300 Mahi Architecture
1) 2)
s_ID s_Name s_Course s_ID s_Name s_Course1 s_Course2
103 Umair Compiler 103 Umair Compiler DBMS
103 Umair DBMS 222 Umara Algorithm Null
222 Umara Algorithm 292 Tasnia Math DBMS
292 Tasnia Math 300 Mahi Architecture Null
292 Tasnia DBMS
300 Mahi Architecture
s_ID s_Cpurse
3) s_ID s_Name 103 Compiler
103 Umair 103 DBMS
222 Umara 222 Algorithm
292 Tasnia 292 Math
300 Mahi 292 DBMS
300 Architecture
10 | P a g e
Second Normal Form (2NF)
Rules:
1) Table should be in 1NF first.
2) Partial dependency not allowed, need to remove partial dependency.

s_ID s_Name s_Address course_ID course_Name Credit Grade

103 Umair -- 1 Compiler 3 A
103 Umair -- 2 DBMS 3 A-
222 Umara -- 3 Algorithm 3 A
292 Tasnia -- 4 Math 3 B+
292 Tasnia -- 2 DBMS 3 A
300 Mahi -- 5 Architecture 3 A+

course_ID course_Name Credit s_ID course_ID Grade

s_ID s_Name s_Address
1 Compiler 3 103 1 A
103 Umair --
2 DBMS 3 103 2 A-
222 Umara --
3 Algorithm 3 222 3 A
292 Tasnia --
4 Math 3 292 4 B+
300 Mahi --
5 Architecture 3 292 2 A
300 5 A+

Third Normal Form (3NF)

Rules:
1) Table should be in 2NF first.
2) Transitive dependency not allowed, need to remove transitive dependency.

course_ID teacher_ID teacher_Name Credit

207 1 ASK 3
208 1 ASK 1.5
241 2 PRG 3
323 3 ANAZ 3

course_ID teacher_ID Credit teacher_ID teacher_Name

207 1 3 1 ASK
208 1 1.5 1 ASK
241 2 3 2 PRG
323 3 3 3 ANAZ

Boyce-Codd Normal Form (BCNF)

Even when a database is in 3rd NF, still there could be anomalies resulted if it has more than one candidate
Key. Sometimes BCNF is also called 3.5NF
student_ID Course Instructor
Rules:
101 DBMS A
1) Table should be in 3NF first.
102 Compiler B
2) Key column can be depended on no key column. 101 Compiler C
student_ID Instructor_ID 103 Algorithm D
102 DBMS A
101 01
instructor_ID Name Course
102 02
01 ASK DBMS 101 02
02 ANAZ Compiler 103 03
03 PRZ Algorithm 102 01
11 | P a g e
Fourth Normal Form (4NF)
Rules:
1) Table must be in BCNF first.
2) There will be no multi-valued dependency. Course Instructor Supervisor
C++ A S1
Course Instructor Supervisor C++ A S1
A S1 C++ B S2
C++
B S2 C++ B S2
C DBMS C S3
DBMS S3
D DBMS D S3

Course Instructor Course Supervisor

C++ A C++ S1
C++ B C++ S2
DBMS C DBMS S3
DBMS D

Fifth Normal Form (5NF)

Rules:
A relation is in 5NF if it is in 4NF along with lossless decomposition.
S_ID Name Address
1 A DHK
2 B BSL
3 C RAJ

S_ID Name Name Address S_ID Name Address

1 A A DHK 1 A DHK
2 B B BSL 1 A RAJ
3 C C RAJ 2 B BSL
3 C DHK
3 C RAJ
R1 R2
R1 Join R2

Losey Decompression

S_ID Name Address

1 A DHK
2 B BSL
3 C RAJ

S_ID Name S_ID Address S_ID Name Address

1 A 1 DHK 1 A DHK
2 B 2 BSL 2 B BSL
3 C 3 RAJ 3 C RAJ

R1 R2 R1 Join R2

Lossless Decompression

12 | P a g e
Advantage and Disadvantage of Normalization

Advantages:
Data Consistency: Normalization helps maintain consistent and error-free data.
Efficient Retrieval: It makes it easier to find specific information in the database.
Saves Space: Normalized databases use less storage space due to reduced redundancy.
Easier Updates: Changes to data are easier to manage without affecting the entire database.
Scalability: Normalization allows for easy expansion of the database.

Disadvantages:
Complexity: Highly normalized databases can be complex and harder to work with.
Performance: In some cases, it can slow down data retrieval due to multiple tables joins.
Complex Queries: Queries in normalized databases may be more complex to write and optimize.
Space for Indexes: Indexes may require extra storage space.
Data Duplication Risk: Over-normalization can sometimes lead to data duplication and inefficiency.

Transaction
A transaction is a unit of program execution that accesses and possibly updates various data items — taking
place wholly or not at all.

Example: transaction to transfer $50 from account A to account B.

1. read(A)
2. A := A – 50
3. write(A)
4. read(B)
5. B := B + 50
6. write(B)

Two main issues to deal with:

1. Failures of various kinds, such as hardware failures and system crashes
2. Concurrent execution of multiple transactions

Atomicity Requirement
• If the transaction fails after step 3 and before step 6, money will be “lost” leading to an inconsistent
database state
▪ Failure could be due to software or hardware
• The system should ensure that updates of a partially executed transaction are not reflected in the database

Durability Requirement: once the user has been notified that the transaction has completed (i.e., the transfer
of the $50 has taken place), the updates to the database by the transaction must persist even if there are software
or hardware failures.

Consistency Requirement: The sum of A and B is unchanged by the execution of the transaction (Example).
In general, consistency requirements include
• Explicitly specified integrity constraints such as primary keys and foreign keys
• Implicit integrity constraints
• e.g., sum of balances of all accounts, minus sum of loan amounts must equal value of cash-in-hand
• A transaction must see a consistent database.
• During transaction execution the database may be temporarily inconsistent.
13 | P a g e
• When the transaction completes successfully the database must be consistent
• Erroneous transaction logic can lead to inconsistency

Isolation requirement: if between steps 3 and 6, another transaction T2 is allowed to access the partially
updated database, it will see an inconsistent database (the sum A + B will be less than it should be).
T1 T2
1. read(A)
2. A := A – 50
3. write(A)
read(A), read(B), print(A+B)
4. read(B)
5. B := B + 50
6. write(B)

• Isolation can be ensured trivially by running transactions serially

• That is, one after the other.
• However, executing multiple transactions concurrently has significant benefits, as
we will see later.

ACID Properties
A transaction is a unit of program execution that accesses and possibly updates various data items. To preserve
the integrity of data the database system must ensure:B
Atomicity: Either all operations of the transaction are properly reflected in the database or none are.
Consistency: Execution of a transaction in isolation preserves the consistency of the database.
Isolation: Although multiple transactions may execute concurrently, each transaction must be unaware of
other concurrently executing transactions. Intermediate transaction results must be hidden from other
concurrently executed transactions.
• That is, for every pair of transactions Ti and Tj, it appears to Ti that either Tj, finished execution before
Ti started, or Tj started execution after Ti finished.
Durability: After a transaction completes successfully, the changes it has made to
the database persists, even if there are system failures.

Transaction State
Active: the initial state; the transaction stays in this state while it is executing
Partially committed: after the final statement has been executed.
Failed: after the discovery that normal execution can no longer proceed.
Aborted: after the transaction has been rolled back and the database restored to its state prior to the start of
the transaction. Two options after it has been aborted:
• Restart the transaction
• Can be done only if no internal logical error
• Kill the transaction
Committed: after successful completion.

14 | P a g e
Transaction State

Concurrent Executions
Multiple transactions are allowed to run concurrently in the system. Advantages are:
• Increased processor and disk utilization leading to better transaction throughput
• E.g., one transaction can be using the CPU while another is reading from or writing to the disk
• Reduced average response time for transactions short transactions need not wait behind long ones.

Concurrency control schemes – mechanisms to achieve isolation

• That is, to control the interaction among the concurrent transactions in order to prevent them from
destroying the consistency of the database
• Will study in Chapter 15, after studying notion of correctness of concurrent executions.

Schedules
Schedule: a sequence of instructions that specify the chronological order in which instructions of concurrent
transactions are executed.
• A schedule for a set of transactions must consist of all instructions of those transactions.
• Must preserve the order in which the instructions appear in each individual transaction.
• A transaction that successfully completes its execution will have a commit instruction as the last
statement
• By default, transaction assumed to execute commit instruction as its last step.
• A transaction that fails to successfully complete its execution will have an abort instruction as the last
statement

15 | P a g e
16 | P a g e