UNIT-1

Database System Applications

Definition
A database system is a collection of organized data and software tools to manage, retrieve, and
update that data efficiently. It supports multiple applications by providing secure and reliable
data management.

Applications in Different Domains

1. Banking
o Use: Customer accounts, transaction management, loan processing.
o Example: ATMs rely on database systems for real-time transactions and balance
updates.
2. Airlines
o Use: Flight schedules, reservations, ticketing, and crew management.
o Example: Online booking platforms use databases to manage seat availability and
pricing.
3. Education
o Use: Student records, course registrations, attendance, and grading systems.
o Example: A university uses a database to store and retrieve student profiles and
exam results.
4. Healthcare
o Use: Patient records, appointment scheduling, billing, and medical research.
o Example: Hospitals use databases for electronic health records (EHR) and lab
results.
5. E-commerce
o Use: Inventory management, user accounts, order tracking, and recommendations.
o Example: Amazon uses databases to manage millions of products and user
preferences.
6. Telecommunications
o Use: Call records, billing, and customer support.
o Example: Telecom providers track customer usage and process billing.
7. Social Media
o Use: User profiles, posts, messages, and interactions.
o Example: Platforms like Facebook and Instagram manage user data and
connections using large-scale databases.
8. Government
o Use: Census data, tax records, and policy planning.
o Example: Governments use databases for voter registration and public welfare
programs.
 9. Research and Development
o Use: Managing datasets for experiments, publications, and simulations.
o Example: Scientific research organizations use databases to store and analyze
large-scale research data.

Advantages

 Efficient data storage and retrieval.

 Centralized data management for better control.
 Scalability for growing data needs.
 Enhanced security and integrity.

View of Data – Data Abstraction Levels

Definition
Data abstraction in a database system refers to the process of hiding the complexities of data
storage and representation from users. It provides different levels of abstraction to cater to
varying needs of end-users and system designers.

Levels of Data Abstraction

1. Physical Level
o Description: Deals with the physical storage of data in the database. It specifies
how data is stored on storage devices like disks.
o Purpose: Focuses on efficiency and storage management.
o Example: Data stored in files, blocks, or binary format.
o User: Database administrators (DBAs).
2. Logical Level
o Description: Describes the data structure, relationships, and constraints without
showing the physical details.
o Purpose: Focuses on what data is stored and its relationships.
o Example: A relational schema like Student(RollNo, Name, Age, Course)
describes the logical organization.
o User: Developers and database designers.
3. View Level
o Description: Provides a simplified, user-specific representation of the data. This
level abstracts both physical and logical complexities.
o Purpose: Enhances security by restricting access to sensitive data and simplifies
data interaction for end-users.
 o Example: A faculty member views only Student(Name, Course) but not
RollNo or Age.
o User: End-users and application programs.

Diagram
View Level
↑
Logical Level
↑
Physical Level

Benefits of Data Abstraction

1. Simplified User Interaction

End-users do not need to understand the physical storage or complex logical structure.
2. Security and Privacy
Different views limit access to specific data, enhancing security.
3. Data Independence
Changes at one level (physical or logical) do not affect the other levels:
o Physical Data Independence: Changes in storage do not affect the logical
schema.
o Logical Data Independence: Changes in logical schema do not affect views.

ER Diagrams, Additional Features of ER Model, and Conceptual Design

1. ER Diagrams
Entity-Relationship (ER) diagrams are graphical representations of entities, their attributes, and
relationships between them in a database system. They are used in the conceptual design phase
of database development.

Components of an ER Diagram

1. Entities
o Represented as rectangles.
o Types:
 Strong Entity: Can exist independently (e.g., Student).
  Weak Entity: Depends on a strong entity (e.g., OrderItem depends on
Order).
o Example: Student, Course.
2. Attributes
o Represented as ovals.
o Types:
 Simple Attributes: Indivisible (e.g., Name, Age).
 Composite Attributes: Can be divided (e.g., Name → First Name, Last
Name).
 Derived Attributes: Computed (e.g., Age from DOB).
 Multivalued Attributes: Can have multiple values (e.g., Phone
Numbers).
3. Relationships
o Represented as diamonds.
o Types:
 1:1 (One-to-One).
 1:N (One-to-Many).
 M:N (Many-to-Many).
o Example: A Student enrolls in a Course.
4. Cardinality
o Specifies the number of entities that can be associated in a relationship.
o Example: A department can have multiple employees (1:N).
5. Primary Key
o A unique identifier for an entity, often underlined in the ER diagram.

2. Additional Features of the ER Model

1. Generalization
o Process of abstracting common attributes of entities into a single higher-level
entity.
o Example: Car and Bike can be generalized as Vehicle.
2. Specialization
o Process of creating sub-entities from a higher-level entity based on specific
attributes.
o Example: Employee → Manager, Technician.
3. Aggregation
o Treating a relationship as an entity to establish further relationships.
o Example: A Project is assigned to multiple Employees, managed by a Manager.

3. Conceptual Design with the ER Model

The conceptual design phase involves:

 1. Identifying Entities
Determine the primary entities in the domain (e.g., Student, Course).
2. Identifying Relationships
Define how entities are related (e.g., Student enrolls in Course).
3. Defining Attributes
Assign attributes to each entity and relationship.
4. Defining Keys
Identify primary keys and foreign keys.
5. Constructing the ER Diagram
Combine all components into a clear and comprehensive diagram.

Example: ER Diagram for a Student-Course System

 Entities:
o Student (Attributes: StudentID, Name, Age).
o Course (Attributes: CourseID, Title, Credits).
 Relationships:
o Enrolls (Attributes: Grade).
o Cardinality: A student can enroll in multiple courses (1:N).

Benefits of Using ER Diagrams

 Simplifies database design by visualizing data structure.

 Ensures completeness and clarity in conceptual modeling.
 Facilitates communication among stakeholders.

Database Users and Administrator; Database System Structure

1. Database Users

Database users interact with the database system at various levels, depending on their roles and
requirements. They can be classified as follows:

Types of Users

1. Naive Users
 o Description: End-users who perform predefined tasks without knowing the database
internals.
o Example: Bank customers using ATMs to withdraw or deposit money.

2. Application Programmers
o Description: Developers who write application programs to interact with the database
using APIs or embedded SQL.
o Example: A software engineer developing a library management system.

3. Sophisticated Users
o Description: Users who interact with the database directly using query languages like
SQL.
o Example: Data analysts writing complex queries for report generation.

4. Specialized Users
o Description: Users who require advanced database functionalities, such as scientists and
engineers managing complex datasets.
o Example: A researcher storing large genomic datasets.

2. Database Administrator (DBA)

The DBA is responsible for managing the database system and ensuring its smooth operation.
Key responsibilities include:

1. Schema Definition
o Defining and modifying the database schema as per organizational needs.

2. Storage Management
o Allocating physical storage and managing database files.

3. Security and Authorization

o Ensuring data security by controlling user access.

4. Backup and Recovery

o Implementing procedures for data recovery in case of failures.

5. Performance Tuning
o Monitoring and optimizing database performance.

6. Data Integrity
o Enforcing constraints to maintain data consistency.
3. Database System Structure

A database system consists of various components working together to manage data efficiently.

Components

1. Query Processor
o Converts user queries into low-level instructions.
o Components:
 Parser: Checks query syntax and semantics.
 Query Optimizer: Finds the most efficient execution plan.
 Execution Engine: Executes the query.

2. Storage Manager
o Manages data storage and retrieval.
o Components:
 Buffer Manager: Caches data in memory for faster access.
 File Manager: Handles physical storage of data.
 Transaction Manager: Ensures ACID properties for transactions.

3. Database Schema
o Describes the logical structure of the database.

4. Database Instances
o The actual data stored in the database at a given time.

5. Concurrency Control System

o Manages simultaneous data access by multiple users.

6. Recovery Manager
o Ensures data recovery in case of system failure.

Diagram: Database System Structure

Users
↓
Query Processor
↓
Storage Manager
↓
Physical Database

Key Features
  Separation of Responsibilities: Clear division between users, DBA, and system components.
 Efficiency: Optimized query processing and storage management.
 Reliability: Robust recovery and concurrency control mechanisms.

Database Languages – DDL, DML, DCL

Database languages are used to define, manipulate, and control data in a database. They can be
categorized into three main types: DDL, DML, and DCL.

1. Data Definition Language (DDL)

DDL is used to define and manage the structure of a database, including schemas, tables,
indexes, and constraints.

Key Commands

1. CREATE
o Used to create database objects (tables, views, indexes, etc.).
o Example:
o CREATE TABLE Students (
o StudentID INT PRIMARY KEY,
o Name VARCHAR(50),
o Age INT
o );

2. ALTER
o Used to modify existing database objects.
o Example:
o ALTER TABLE Students ADD Email VARCHAR(100);

3. DROP
o Used to delete database objects permanently.
o Example:
o DROP TABLE Students;

4. TRUNCATE
o Used to delete all rows in a table while retaining its structure.
o Example:
o TRUNCATE TABLE Students;

5. RENAME
o Used to rename database objects.
o Example:
o RENAME TABLE Students TO Alumni;
2. Data Manipulation Language (DML)

DML is used to manipulate and retrieve data stored in the database.

Key Commands

1. SELECT
o Retrieves data from the database.
o Example:
o SELECT * FROM Students WHERE Age > 20;

2. INSERT
o Adds new rows to a table.
o Example:
o INSERT INTO Students (StudentID, Name, Age)
o VALUES (1, 'Alice', 22);

3. UPDATE
o Modifies existing data in a table.
o Example:
o UPDATE Students
o SET Age = 23
o WHERE StudentID = 1;

4. DELETE
o Removes rows from a table.
o Example:
o DELETE FROM Students WHERE Age < 18;

3. Data Control Language (DCL)

DCL is used to manage permissions and access control in a database.

Key Commands

1. GRANT
o Provides privileges to users or roles.
o Example:
o GRANT SELECT, INSERT ON Students TO User1;

2. REVOKE
o Removes previously granted privileges.
o Example:
o REVOKE INSERT ON Students FROM User1;
Comparison of DDL, DML, and DCL

Aspect DDL DML DCL

Purpose Define structure Manipulate data Manage permissions

Scope Schema and objects Rows in tables User access

Example Commands CREATE, ALTER, DROP SELECT, INSERT, UPDATE GRANT, REVOKE

Key Points

 DDL affects the structure of the database and is usually executed by administrators.
 DML is used by applications and users to interact with the data.
 DCL ensures data security by managing access privileges.

Relational Model: Integrity Constraints and Views

1. Relational Model

The relational model organizes data into relations (tables), which consist of rows (tuples) and
columns (attributes). It is based on mathematical concepts like sets and relations, and it provides
the foundation for modern relational databases.

2. Integrity Constraints

Integrity constraints are rules enforced on the relational database to ensure the accuracy and
consistency of data. These constraints prevent invalid data from being entered into the database.

Types of Integrity Constraints

1. Domain Constraints
o Definition: Ensure that the values in a column fall within a specified range or set.
o Example:
o CREATE TABLE Students (
o StudentID INT,
o Name VARCHAR(50),
o Age INT CHECK (Age >= 18)
o );
 2. Entity Integrity Constraint
o Definition: Ensures that each row in a table has a unique identifier, usually a primary
key.
o Example:
o CREATE TABLE Students (
o StudentID INT PRIMARY KEY,
o Name VARCHAR(50)
o );

3. Referential Integrity Constraint

o Definition: Ensures that foreign key values in a table match primary key values in
another table.
o Example:
o CREATE TABLE Enrollments (
o EnrollmentID INT PRIMARY KEY,
o StudentID INT,
o CourseID INT,
o FOREIGN KEY (StudentID) REFERENCES Students(StudentID),
o FOREIGN KEY (CourseID) REFERENCES Courses(CourseID)
o );

4. Key Constraints
o Definition: Ensure that certain attributes in a table uniquely identify tuples.
o Types: Primary Key, Candidate Key, and Unique Key.
o Example:
o CREATE TABLE Courses (
o CourseID INT PRIMARY KEY,
o Title VARCHAR(100) UNIQUE
o );

3. Views

A view is a virtual table in the database, created by a query that pulls data from one or more
tables. Views do not store data physically but provide a logical representation of the data.

Characteristics of Views

 They can include data from multiple tables through joins.

 Provide security by restricting user access to specific columns or rows.
 Simplify complex queries by encapsulating them in reusable structures.

Creating a View
CREATE VIEW StudentDetails AS
SELECT Students.StudentID, Students.Name, Enrollments.CourseID
FROM Students
JOIN Enrollments ON Students.StudentID = Enrollments.StudentID;
Querying a View
SELECT * FROM StudentDetails WHERE CourseID = 101;
Advantages of Views

1. Data Security: Limit access to specific parts of the database.

2. Simplification: Encapsulate complex queries for easier usage.
3. Data Independence: Changes in the underlying tables do not affect the view structure.

Comparison of Constraints and Views

Aspect Integrity Constraints Views

Purpose Ensure data accuracy and consistency Provide logical representation of data

Enforced On Tables and their data Query results

Examples Primary Key, Foreign Key, Domain Constraints Virtual tables with specific queries

Modifications Cannot bypass integrity constraints Data modifications depend on view types

Summary

 Integrity Constraints ensure database reliability by enforcing strict rules.

 Views provide flexibility and security by allowing customized data access.

UNIT-2
Relational Algebra: Selection, Projection, Set Operations, Renaming, Joins, and
Division

Relational Algebra is a formal query language that operates on relations (tables) to retrieve or
manipulate data. It provides operators to express queries concisely and mathematically.

1. Selection (σ)

 Definition: Filters rows (tuples) that satisfy a given condition.

  Symbol: σ\sigma
 Syntax:
σcondition(Relation)\sigma_{condition}(Relation)
 Example: Retrieve students older than 20 from a Students table.
σAge>20(Students)\sigma_{Age > 20}(Students)

SQL Equivalent:

SELECT * FROM Students WHERE Age > 20;

2. Projection (π)

 Definition: Selects specific columns (attributes) from a table.

 Symbol: π\pi
 Syntax:
πattributes(Relation)\pi_{attributes}(Relation)
 Example: Retrieve only Name and Age from the Students table.
πName,Age(Students)\pi_{Name, Age}(Students)

SQL Equivalent:

SELECT Name, Age FROM Students;

3. Set Operations

Relational algebra supports set operations on relations with the same schema.

Union ( ∪ )

 Combines tuples from two relations, removing duplicates.

 Syntax:
Relation1∪Relation2Relation1 \cup Relation2
 Example: Combine two tables of student lists.

Intersection ( ∩ )

 Retrieves tuples common to both relations.

 Syntax:
Relation1∩Relation2Relation1 \cap Relation2
 Example: Find students enrolled in both Math and Science.

Difference ( − )

 Retrieves tuples in one relation but not in the other.

  Syntax:
Relation1−Relation2Relation1 − Relation2
 Example: Find students enrolled in Math but not in Science.

4. Renaming (ρ)

 Definition: Renames a relation or its attributes.

 Symbol: ρ\rho
 Syntax:
ρnew_name(Relation)\rho_{new\_name}(Relation)
 Example: Rename Students table to EnrolledStudents.
ρEnrolledStudents(Students)\rho_{EnrolledStudents}(Students)

SQL Equivalent:

SELECT * FROM Students AS EnrolledStudents;

5. Joins

Joins combine tuples from two relations based on a related attribute.

Types of Joins

1. Theta Join (R⋈θSR \bowtie_{\theta} S)

o Combines tuples satisfying a condition θ\theta.
o Example: Retrieve students and their courses based on StudentID.
Students⋈Students.StudentID=Enrollments.StudentIDEnrollmentsStudents \
bowtie_{Students.StudentID = Enrollments.StudentID} Enrollments

2. Equi-Join
o A special case of theta join where θ\theta is equality.

3. Natural Join (R⋈SR \bowtie S)

o Automatically joins based on common attribute names.

4. Outer Joins
o Includes unmatched tuples in results.
o Types: Left, Right, and Full Outer Join.

SQL Equivalent for Natural Join:

SELECT *
FROM Students
NATURAL JOIN Enrollments;
6. Division (÷)

 Definition: Retrieves tuples from one relation that match all values in another relation.
 Syntax:
R÷SR \div S
 Use Case: Find entities related to all items in another set.

Example:
Relation RR: Students and Courses they have completed.
Relation SS: Required courses for certification.

Result: Students who have completed all required courses.

Examples and SQL Equivalents

1. Selection and Projection Combined:

Retrieve names of students older than 20:
πName(σAge>20(Students))\pi_{Name}(\sigma_{Age > 20}(Students))
SQL:
2. SELECT Name FROM Students WHERE Age > 20;

3. Join Example:
Retrieve student names along with their enrolled courses:
πStudents.Name,Courses.CourseName(Students⋈Enrollments⋈Courses)\
pi_{Students.Name, Courses.CourseName}(Students \bowtie Enrollments \bowtie
Courses)
SQL:
4. SELECT Students.Name, Courses.CourseName
5. FROM Students
6. JOIN Enrollments ON Students.StudentID = Enrollments.StudentID
7. JOIN Courses ON Enrollments.CourseID = Courses.CourseID;

8. Division Example:
Find students who have enrolled in all courses.
Students÷CoursesStudents \div Courses

Relational Algebra Summary

Operator Purpose Example

Selection (σ) Filter rows based on σAge>20(Students)\sigma_{Age > 20}(Students)

 Operator Purpose Example

condition

Projection
Select specific columns πName,Age(Students)\pi_{Name, Age}(Students)
(π)

Set Union, Intersection,

Students1∪Students2Students1 \cup Students2
Operations Difference

Rename relations or
Renaming (ρ) ρEnrolledStudents(Students)\rho_{EnrolledStudents}(Students)
attributes

Combine tuples from

Joins Students⋈EnrollmentsStudents \bowtie Enrollments
multiple relations

Find entities related to all

Division (÷) Students÷CoursesStudents \div Courses
values in set

Relational Calculus: Tuple Relational Calculus (TRC) and Domain Relational

Calculus (DRC)

Relational Calculus is a declarative query language used in relational databases. Unlike

relational algebra, it focuses on what to retrieve rather than how to retrieve it. Relational calculus
has two main forms: Tuple Relational Calculus (TRC) and Domain Relational Calculus
(DRC).

1. Tuple Relational Calculus (TRC)

 Definition: A non-procedural query language that uses tuples to specify queries.

 Queries are expressed in terms of tuple variables, which represent rows in a table.

Syntax:

{t ∣ P(t)}\{ t \ | \ P(t) \}

 tt: Tuple variable.

 P(t)P(t): A condition (predicate) that tt must satisfy.

Example:

{t.Name ∣ t∈Students∧t.Age>20}\{ t.Name \ | \ t \in Students \land t.Age > 20 \}

Retrieve names of students older than 20 from the Students table:
SQL Equivalent:

SELECT Name FROM Students WHERE Age > 20;

Predicates in TRC

1. Conditions:

Logical operators: ∧\land (AND), ∨\lor (OR), ¬\neg (NOT).

o Comparisons: =,<,>,≤,≥,≠=, <, >, \leq, \geq, \neq.

Quantifiers: ∃\exists (there exists), ∀\forall (for all).

o
o

2. Examples of Predicates:

∃s(s∈Courses∧s.CourseID=t.CourseID)\exists s (s \in Courses \land s.CourseID =

o t.Age>20t.Age > 20: Select tuples where age is greater than 20.
o
t.CourseID): Select tuples with matching course IDs.

2. Domain Relational Calculus (DRC)

 Definition: A non-procedural query language that uses domain variables to represent individual
attribute values.
 Queries are expressed in terms of attribute variables and conditions.

Syntax:

{<x1,x2,...,xn> ∣ P(x1,x2,...,xn)}\{ <x_1, x_2, ..., x_n> \ | \ P(x_1, x_2, ..., x_n) \}

 x1,x2,...,xnx_1, x_2, ..., x_n: Domain variables representing column values.

 P(x1,x2,...,xn)P(x_1, x_2, ..., x_n): A condition that must be satisfied.

Example:

{x ∣ (x,y,z)∈Students∧z>20}\{ x \ | \ (x, y, z) \in Students \land z > 20 \}

Retrieve names of students older than 20 from the Students table:

Here, xx represents Name, yy represents StudentID, and zz represents Age.

SQL Equivalent:

SELECT Name FROM Students WHERE Age > 20;

Comparison of TRC and DRC

 Aspect Tuple Relational Calculus (TRC) Domain Relational Calculus (DRC)

Focus Works with tuples (entire rows). Works with domain variables (column values).

Representation Uses tuple variables. Uses domain variables.

Syntax ({t\ \ P(t) } )

Example ( { t.Name \ \ t \in Students \land t.Age > 20 } )

Ease of Use Easier for queries involving entire rows. Better for column-specific operations.

Key Features of Relational Calculus

1. Declarative Nature
o Focuses on describing the result rather than the process to obtain it.

2. Safety of Expressions
o Queries must be safe, meaning they do not produce infinite results.

3. Relational Completeness
o Relational calculus is as expressive as relational algebra. Any query expressible in one
can be expressed in the other.

Example Queries

1. Find students enrolled in a specific course (TRC)

{t ∣ t∈Enrollments∧t.CourseID=101}\{ t \ | \ t \in Enrollments \land t.CourseID = 101 \}

SQL Equivalent:

SELECT * FROM Enrollments WHERE CourseID = 101;

2. Find students older than 20 (DRC)

{<x> ∣ (x,y,z)∈Students∧z>20}\{ <x> \ | \ (x, y, z) \in Students \land z > 20 \}

SQL Equivalent:

SELECT Name FROM Students WHERE Age > 20;

Conclusion
  Tuple Relational Calculus (TRC) is row-oriented, while Domain Relational Calculus (DRC) is
attribute-oriented.
 Both are declarative and equivalent in expressive power.
 Relational Calculus forms the theoretical basis for SQL and is essential for understanding the
mathematical foundation of relational databases.

Nested Queries, Correlated Nested Queries, and Aggregative Operators

Nested queries and correlated nested queries are important concepts in relational databases, often
used to perform complex filtering and comparisons between relations. Aggregative operators
provide powerful means to perform calculations like sums, averages, counts, and more, on data
sets.

1. Nested Queries

A nested query (or subquery) is a query that is embedded within another query. The inner query
is executed first, and its result is used by the outer query.

Types of Nested Queries:

1. Single-row Subqueries: Return a single value, and the outer query uses this value in a
comparison.
o Example: Find students whose age is greater than the average age of all students.
2. SELECT Name
3. FROM Students
4. WHERE Age > (SELECT AVG(Age) FROM Students);

5. Multi-row Subqueries: Return multiple rows of values, often used with IN, ANY, or ALL
operators.
o Example: Find students who have enrolled in a course with ID 101.
6. SELECT Name
7. FROM Students
8. WHERE StudentID IN (SELECT StudentID FROM Enrollments WHERE CourseID =
101);

9. Multi-column Subqueries: Return multiple columns, which can be used in the outer
query with appropriate comparison operators.
o Example: Find students who are enrolled in the same course as a specific student.
10. SELECT Name
11. FROM Students
12. WHERE (StudentID, CourseID) IN (SELECT StudentID, CourseID FROM
Enrollments WHERE StudentID = 102);
Key Points about Nested Queries:

 The inner query is executed first.

 The outer query uses the result of the inner query for its processing.
 A nested query can be used in the SELECT, FROM, WHERE, or HAVING clauses.

2. Correlated Nested Queries

A correlated nested query is a type of subquery where the inner query refers to columns of the
outer query. The inner query is evaluated once for each row processed by the outer query.

Example: Find students whose grade in any course is higher than the average grade
in that course.
SELECT Name
FROM Students S
WHERE EXISTS (
SELECT 1
FROM Enrollments E
WHERE E.StudentID = S.StudentID
AND E.Grade > (SELECT AVG(Grade) FROM Enrollments WHERE CourseID =
E.CourseID)
);

In this example, the inner query inside the EXISTS clause depends on the outer query because
S.StudentID is referenced in the subquery. The inner query is evaluated for each student.

Key Points about Correlated Nested Queries:

 The inner query is evaluated multiple times, once for each row of the outer query.
 The inner query refers to outer query columns.
 They are generally more expensive in terms of performance, as the subquery is executed for
every row.

3. Aggregative Operators

Aggregative operators (also known as aggregate functions) perform a calculation on a set of

values and return a single value. These are often used to summarize data, perform calculations
like sums, averages, counts, etc.

Common Aggregative Operators:

1. COUNT(): Returns the number of rows or non-NULL values in a specified column.

o Example: Count the number of students enrolled in a course.
2. SELECT COUNT(*)
 3. FROM Enrollments
4. WHERE CourseID = 101;

5. SUM(): Returns the sum of a specified numeric column.

o Example: Find the total grade points of all students.
6. SELECT SUM(GradePoints)
7. FROM Enrollments;

8. AVG(): Returns the average of a specified numeric column.

o Example: Find the average grade of students in a course.
9. SELECT AVG(Grade)
10. FROM Enrollments
11. WHERE CourseID = 101;

12. MIN(): Returns the minimum value in a specified column.

o Example: Find the lowest grade in a course.
13. SELECT MIN(Grade)
14. FROM Enrollments
15. WHERE CourseID = 101;

16. MAX(): Returns the maximum value in a specified column.

o Example: Find the highest grade in a course.
17. SELECT MAX(Grade)
18. FROM Enrollments
19. WHERE CourseID = 101;

20. GROUP BY: Used with aggregate functions to group rows that have the same values in
specified columns.
o Example: Find the total number of students in each course.
21. SELECT CourseID, COUNT(*)
22. FROM Enrollments
23. GROUP BY CourseID;

24. HAVING: Used to filter the results of aggregate functions.

o Example: Find courses with more than 50 students enrolled.
25. SELECT CourseID, COUNT(*)
26. FROM Enrollments
27. GROUP BY CourseID
28. HAVING COUNT(*) > 50;

Combining Nested Queries and Aggregative Operators

You can combine nested queries with aggregative operators to perform complex calculations.

Example: Find the students whose grades are above the average grade of their
respective courses.
SELECT Name
FROM Students S
WHERE EXISTS (
 SELECT 1
FROM Enrollments E
WHERE E.StudentID = S.StudentID
AND E.Grade > (SELECT AVG(Grade) FROM Enrollments WHERE CourseID =
E.CourseID)
);

In this case, the nested query finds the average grade for each course, and the outer query checks
if the student's grade is higher than the average for that course.

Summary

Concept Description

A query within another query.

Nested Queries Can be single-row, multi-row,
or multi-column.

A subquery that references

columns from the outer query.
Correlated Nested Queries
Evaluated once for each row in
the outer query.

Functions like COUNT, SUM,

AVG, MIN, MAX that perform
calculations on data. Often
Aggregative Operators
used with GROUP BY and
HAVING to summarize and
filter data.

- Use nested queries to

compare a value to a subset of
data.- Use correlated nested
queries to evaluate conditions
Common Use Cases
across related data.- Use
aggregative operators to
summarize data and calculate
totals.

Triggers and Active Databases

In relational database systems, triggers and active databases play

important roles in managing data integrity, automating actions, and
 Concept Description

ensuring that certain conditions are met. Triggers are used to

automatically execute predefined actions when certain events
occur in the database. Active databases extend the capabilities of
regular databases by allowing the system to react to changes in the
data dynamically.

1. Triggers in Databases

A trigger is a set of SQL statements that are automatically

executed in response to certain events on a particular table or view
in a database. Triggers are used for enforcing business rules,
auditing changes, and synchronizing tables, among other things.

Components of a Trigger:

1. Event: The action that activates the trigger. Examples include

INSERT, UPDATE, and DELETE.
2. Condition: A Boolean expression that determines whether the
trigger should be fired or not.
3. Action: The SQL statements or operations that are executed
when the event occurs and the condition is satisfied.

Types of Triggers:

1. BEFORE Trigger:
o Fired before the actual operation (insert, update, or
delete) is performed.
o Useful for validating or modifying data before it is
written to the database.

2. AFTER Trigger:
o Fired after the operation has been completed.
o Useful for actions that depend on the completion of the
operation, such as logging or cascading changes.

3. INSTEAD OF Trigger:
o Fired in place of the operation that would have
occurred.
o Often used to override default behaviors, such as
updating a view instead of directly modifying the
underlying table.
 Concept Description

Trigger Syntax:

The syntax for creating a trigger varies depending on the DBMS

being used (e.g., MySQL, PostgreSQL, SQL Server). Below is a
general example using SQL syntax:

CREATE TRIGGER trigger_name

AFTER INSERT ON table_name
FOR EACH ROW
BEGIN
-- Actions to be executed when the trigger is fired
UPDATE another_table SET column_name = NEW.value
WHERE condition;
END;
Example: Create a Trigger to Update an Audit Table on
Insert

Assume we have a table Students and an audit table AuditLog.

We can create a trigger to automatically log every insertion into
the Students table.

CREATE TRIGGER LogStudentInsert

AFTER INSERT ON Students
FOR EACH ROW
BEGIN
INSERT INTO AuditLog (Action, TableName,
ActionTime)
VALUES ('INSERT', 'Students', NOW());
END;

This trigger logs every insertion into the Students table in the
AuditLog table with the action type and timestamp.

2. Active Databases

An active database is a type of database that supports triggers and

other rule-based mechanisms for reacting to certain events. An
active database system is capable of responding to changes in the
database and automatically executing predefined rules or actions
without human intervention.

Key Concepts in Active Databases:

1. Event-Condition-Action (ECA) Rule:

An active database system is often based on the Event-
 Concept Description

Condition-Action model. In this model:

o Event: A change in the database (e.g., insertion,
deletion, update).
o Condition: A condition that needs to be checked before
the action is taken.
o Action: The operation that is executed if the condition
is true.

2. Active Rule:
An active rule is a rule that specifies an action that should
occur in response to a specific event, provided the
condition is met. Active rules can be implemented using
triggers in relational databases.
3. Persistent vs. Temporary Triggers:
o Persistent triggers: Exist permanently in the system
until explicitly dropped. They are defined by the
database administrator and remain active until
removed.
o Temporary triggers: Only exist for the duration of the
session or until the transaction is completed.

Example of Active Rule:

 Event: An INSERT operation on the Orders table.

 Condition: The OrderAmount must be greater than $1000.
 Action: If the condition is satisfied, send an email to the sales
team.

CREATE TRIGGER HighValueOrder

AFTER INSERT ON Orders
FOR EACH ROW
WHEN (NEW.OrderAmount > 1000)
BEGIN
-- Code to send an email to the sales team
EXECUTE PROCEDURE SendEmail('Sales Team', 'High
value order placed');
END;

3. Use Cases of Triggers and Active Databases

1. Data Integrity Enforcement:

 Example: Enforce a rule that all employees must have a unique

email address.
 Concept Description

o Use an AFTER INSERT trigger to check if the email

already exists in the database.

2. Auditing and Logging:

 Example: Automatically log every change made to critical data

in the database, such as salary or personal details.
o Use triggers to capture insert, update, and delete
operations and log them in an audit table.

3. Cascading Updates and Deletes:

 Example: If a Department record is deleted, automatically

delete all employees associated with that department.
o Use a BEFORE DELETE trigger to ensure referential
integrity.

4. Synchronization:

 Example: Keep data in multiple tables synchronized. For

instance, update a Stock table every time a new product is
added.
o Use an AFTER INSERT trigger to update related tables.

4. Advantages of Triggers and Active Databases

1. Automation:
o Triggers help automate repetitive tasks like logging,
validation, and updates without manual intervention.

2. Consistency:
o Ensures that rules (like data integrity) are always
followed automatically, improving data consistency.

3. Data Integrity:
o Enforces business rules and constraints, ensuring the
database remains in a valid state.

4. Performance:
o Active databases, through the use of triggers, can
improve performance by automatically handling tasks
that would otherwise require additional queries or
human intervention.
 Concept Description

5. Real-time Reaction:
o Triggers allow for real-time responses to changes in the
database, which is critical for dynamic systems that
need to react quickly to changes in data.

5. Disadvantages of Triggers and Active Databases

1. Performance Overhead:
o Triggers add overhead to database operations,
especially if they are complex or if they fire on every
insert/update/delete operation.

2. Complex Debugging:
o Triggers can sometimes make it difficult to trace errors,
especially when multiple triggers are firing in response
to a single event.

3. Maintenance Complexity:
o Managing and maintaining triggers can become
challenging as the system grows. Overuse of triggers
can result in tightly coupled logic, which can be hard to
modify later.

4. Unintended Consequences:
o A poorly designed trigger can lead to unexpected side
effects, like infinite loops or cascading operations that
negatively affect the database's performance.

Conclusion

Feature Trigger Active Database

SQL statement executed

Database that reacts to changes
Definition automatically on data
using rules (ECA).
events.

Events trigger active rules,

Insert, Update, Delete
Events including insert, update, delete,
events.
etc.
 Concept Description

Often involves
Conditions determine when rules
Condition conditional checks on
should be fired.
data.

Actions like data Rules execute actions like

Action manipulation, logging, updating related tables or sending
etc. notifications.

Real-time reaction to changes,

Logging changes,
Example like sending an email when a
enforcing constraints.
high-value order is placed.

Triggers and active databases are powerful tools for automating

and managing data processes. By understanding and leveraging
these features, developers can significantly enhance the
functionality and efficiency of database systems.

Would you like further examples or a deeper dive into any of these
topics?

UNIT-3
Problems Caused by Redundancy in Databases

Data redundancy refers to the unnecessary duplication of data in a database. While some
redundancy might be necessary in certain scenarios (e.g., for performance optimization or
reporting purposes), excessive or uncontrolled redundancy can lead to several issues, especially
in relational databases where normalization techniques are employed to avoid it.

Below are the primary problems caused by redundancy in databases:

1. Inconsistency of Data

One of the major problems caused by redundancy is data inconsistency. When the same data
appears in multiple places, there is a risk that it could be updated in one place but not in others.
This results in conflicting data across the database.
Example:

If a customer’s address is stored in two different tables (e.g., one for orders and one for customer
details), and the address changes in the customer details table but not in the orders table, the
system may show inconsistent information about the customer’s address.

 Impact: Inconsistencies can cause incorrect reports, billing errors, or problems in business
processes that rely on accurate data.

2. Wasted Storage Space

Excessive redundancy leads to unnecessary use of disk space. When the same information is
stored in multiple places, the database will occupy more storage, which could be better utilized
for other data.

Example:

A customer’s phone number is stored in each order record they make. If the customer makes 100
orders, their phone number will be stored 100 times in the database, consuming unnecessary
space.

 Impact: This increases storage costs and reduces the efficiency of the database, especially for
large datasets.

3. Increased Complexity in Data Maintenance

Managing redundant data increases the complexity of database maintenance. Whenever data
needs to be updated, inserted, or deleted, the redundant copies must also be maintained
consistently. Failure to do so can lead to errors and inefficiencies.

Example:

If an employee's information (name, address, salary) is stored in multiple tables across a

database, then every time an employee's address or salary changes, every occurrence of that
information in the database must be updated.

 Impact: The chances of missing an update or introducing errors increase, which can lead to
incorrect or outdated data being used across different parts of the application.

4. Data Anomalies
Data anomalies occur when operations like insertion, update, or deletion result in errors due to
redundant data. These anomalies can be classified into three main types:

 Insertion Anomaly: When redundant data prevents the insertion of new data.
o Example: A new product cannot be added to the database because the database
requires duplicate customer information, which is not yet available.

 Update Anomaly: When redundant data leads to inconsistencies during updates.

o Example: If a customer's phone number changes and it's stored in multiple places,
forgetting to update it in one place can result in different phone numbers being stored
for the same customer.

 Deletion Anomaly: When deleting redundant data causes the loss of important
information.
o Example: If a customer’s order is deleted from a table, and that is the only record of
their information, we might lose all customer information just because of the deletion of
an order.

 Impact: Anomalies compromise the integrity and reliability of the data, which could
negatively impact decision-making, reporting, or overall database operations.

5. Reduced Data Integrity

Excessive redundancy compromises the integrity of the database because it becomes harder to
enforce consistency constraints (like primary keys or foreign keys). If the same data is stored in
multiple places, ensuring that it follows the rules for valid data (e.g., no duplicate records, proper
relationships between entities) becomes more difficult.

Example:

If a customer's order is stored in multiple tables and the system doesn't ensure that the customer
ID in the orders table matches the one in the customers table, it could allow an invalid order
entry.

 Impact: Data integrity violations can lead to inaccurate, unreliable, and inconsistent data, which
is detrimental to the system's trustworthiness.

6. Performance Degradation

Redundant data can degrade the performance of the database, especially for queries and updates.
When data is spread across multiple places, queries need to search through and aggregate
redundant records, leading to longer processing times.
Example:

When performing a query to retrieve customer orders, if redundant customer information exists
in each order, the database will take longer to retrieve all relevant data because it must handle
more records.

 Impact: Increased query execution time and slower system performance, which can lead to
inefficiencies and poor user experience.

7. Difficulty in Data Analysis and Reporting

Redundant data complicates data analysis and reporting because aggregating or summarizing
data becomes more difficult. Analysts or reporting tools may need to account for duplicates,
which can lead to incorrect or misleading conclusions.

Example:

If sales data contains redundant entries for the same sale (due to multiple copies of customer
information), the total sales value could be inflated.

 Impact: Misleading reports, inaccurate insights, and incorrect business decisions based on faulty
data.

8. Inability to Enforce Normalization

Normalization is the process of organizing the database to minimize redundancy and

dependency. Without normalization, maintaining a clean and efficient database structure
becomes challenging.

 Impact: Failure to normalize data leads to redundant storage and other problems such as
inconsistencies, anomalies, and inefficient queries.

9. Backup and Recovery Issues

With redundant data, backup and recovery processes become more complex. Redundant copies
of the same data need to be managed carefully to ensure that data is not corrupted or lost during
backup or restoration.
Example:

If redundant data is not properly synchronized across different backup copies, the recovery
process may result in incomplete or inconsistent data.

 Impact: Increased complexity in backup and recovery procedures, and potential data integrity
issues during recovery.

Solutions to Redundancy Issues

To avoid the problems caused by redundancy, Normalization is applied to a database during its
design phase. Some common normalization forms (like 1NF, 2NF, 3NF) help remove
redundancy and ensure the database is structured efficiently.

1. Eliminate Unnecessary Data: Store data in a way that each piece of information appears only
once. Use foreign keys to reference data in different tables.
2. Apply Normalization: Follow normalization rules to organize data in such a way that redundancy
is minimized, ensuring that data is stored logically.
3. Decompose Tables: Divide large tables into smaller ones based on the logical relationships
between the data.
4. Use Views: Instead of storing data redundantly, use views to present data in a useful format
without physically duplicating the data.

Conclusion

Problem Impact

Inconsistency of Data Leads to conflicting and unreliable information.

Wasted Storage Space Increases storage costs and reduces database efficiency.

Increased Complexity in Makes it harder to maintain and update the database

Maintenance consistently.

Data Anomalies Results in insertion, update, and deletion errors.

Reduced Data Integrity Compromises the reliability and validity of the data.

Performance Degradation Leads to slower query performance and inefficient operations.

Difficulty in Data Analysis Produces incorrect or misleading reports.

Inability to Enforce Normalization Results in an inefficient database structure.

 Problem Impact

Increases the risk of corrupted or inconsistent data during

Backup and Recovery Issues
recovery.

Decompositions in Databases: Problems

In database design, decomposition refers to the process of breaking down a large, complex
relation (table) into smaller, more manageable sub-relations while maintaining the integrity and
consistency of the data. This process is often employed to achieve normalization, where data
redundancy is minimized, and data integrity is preserved.

While decomposition is an essential step in database normalization, it can present several

problems and challenges. These problems primarily arise when the decomposition is not done
carefully, leading to issues related to data redundancy, integrity, and performance.

1. Loss of Information (Lossless Decomposition)

The primary goal of decomposition is to break a table into smaller relations without losing any
information. However, if the decomposition is not done properly, it can lead to the loss of
information.

Lossless Decomposition:

A decomposition is lossless if, by joining the decomposed tables, you can recover the original
table without any loss of data.

 Problem: If a decomposition is not lossless, you may not be able to reconstruct the original
relation after performing a natural join on the decomposed relations. This is often a result of
improper handling of functional dependencies or candidate keys during decomposition.

Example:

Consider a relation R(A, B, C) with the following functional dependency:

 A -> B (A determines B)

If we decompose R into R1(A, B) and R2(B, C), the relation R1 contains the attribute B, but we
cannot fully reconstruct R because A does not determine C directly, leading to loss of information.
  Impact: Loss of information means that querying or reconstructing the data from the
decomposed relations may lead to incomplete or incorrect results.

Solution: Use Lossless Join Decomposition criteria (such as the chase procedure or using
candidate keys) to ensure that the decomposition retains all the necessary information.

2. Redundancy and Anomalies in the Decomposed Relations

While decomposition is meant to eliminate redundancy and anomalies, it can also lead to new
forms of redundancy or anomalies in the decomposed relations.

Problems:

 Insertion Anomalies: Redundancy can lead to difficulties when inserting new data. For instance,
when inserting a new tuple into a decomposed relation, you may need to repeat information in
multiple relations, leading to possible redundancy.
 Update Anomalies: If a value is updated in one of the decomposed relations, the corresponding
values in other relations must also be updated. Failure to update all occurrences can lead to
inconsistency.
 Deletion Anomalies: Deleting a tuple in one relation might inadvertently lead to the loss of
important information if that information is needed for other relations.

Example:

Consider a relation Student(CourseID, StudentID, Instructor) that is decomposed into

two relations:

 Student(CourseID, StudentID)
 Instructor(CourseID, Instructor)

When inserting a new student, you may need to insert a tuple into both relations. If you forget to
insert it into one of the relations, or if the insertion is incomplete, data redundancy and anomalies
occur.

 Impact: Decomposition that leads to redundancy or anomalies reduces the benefits of

normalization and compromises the integrity of the database.

Solution: Carefully analyze the functional dependencies and use Boyce-Codd Normal Form
(BCNF) or Fourth Normal Form (4NF) to avoid these issues.

3. Loss of Referential Integrity

Decomposition can lead to referential integrity problems, especially when foreign keys are
used. After decomposing a relation, foreign keys may become invalid, or relationships between
the decomposed relations may be lost.

Problem:

 When you decompose a relation, foreign key constraints that were previously valid may no
longer be enforceable, especially if the decomposed relations no longer maintain the necessary
relationships.
 A foreign key in one relation may point to a primary key in another relation, but decomposing
the relations without maintaining these keys can lead to invalid or orphaned references.

Example:

Consider a relation Employee(DeptID, EmpID, EmpName) where DeptID is a foreign key that
refers to a department table Department(DeptID, DeptName). After decomposing the
Employee relation, you may accidentally break the foreign key relationship or leave orphaned
entries in the Employee table.

 Impact: The integrity of the data is compromised, leading to orphan records or invalid
relationships.

Solution: Ensure that foreign key relationships are maintained during decomposition, and verify
that referential integrity is preserved in the decomposed relations.

4. Increased Complexity in Queries

Decomposing a large relation into smaller ones can lead to more complex queries, as multiple
joins may be required to retrieve the same information that was previously available in a single
relation.

Problem:

 When you query the decomposed relations, you may need to join multiple tables, which can
increase the complexity of the query.
 Complex joins may also negatively impact query performance, especially for large databases
with many relations.

Example:

A database for a university has a Student relation that stores student data along with their
enrolled courses and grades. After decomposition, the data might be split into:

 Student(StudentID, Name)
 Enrollment(StudentID, CourseID)
  Grades(StudentID, CourseID, Grade)

To retrieve a student's name, course, and grade, you would need to perform multiple joins, which
can slow down query performance, particularly if the number of students and courses is large.

 Impact: Complex queries may require more computational resources, slowing down the system
and making it harder to maintain.

Solution: Use views or materialized views to simplify the query process or optimize the
database schema to minimize the need for excessive joins.

5. Violation of Functional Dependencies

When decomposing a relation, it is important to ensure that functional dependencies are

preserved. If the decomposition violates lossless join decomposition or does not preserve
functional dependencies, it can lead to problems where the original dependencies cannot be
reconstructed from the decomposed relations.

Problem:

 If the decomposition is not done in a way that preserves the functional dependencies, the
relationship between the attributes might be lost, and it becomes difficult to enforce business
rules or ensure data integrity.

Example:

Consider a relation Employee(EmpID, EmpName, DeptID) with a functional dependency EmpID

-> EmpName. If we decompose the relation into Employee1(EmpID, DeptID) and
Employee2(DeptID, EmpName), we might lose the direct relationship between EmpID and
EmpName, leading to difficulties when trying to rejoin the relations.

 Impact: Violating functional dependencies can lead to incorrect data retrieval and difficulties
when trying to enforce consistency or perform joins between decomposed relations.

Solution: Ensure that the decomposition preserves functional dependencies and that Boyce-
Codd Normal Form (BCNF) or at least Third Normal Form (3NF) is achieved during
decomposition.

Conclusion

Decomposing a relation is a necessary step in normalizing a database, but it comes with its own
set of challenges. These problems primarily arise when the decomposition is not performed
carefully or when the decomposition does not preserve the necessary properties of the original
relation (e.g., lossless join, functional dependencies). Addressing these issues requires a thorough
understanding of normalization and careful design decisions to ensure the integrity and
performance of the database are not compromised.

Problem Impact

Loss of Information Leads to incomplete or incorrect data when joining decomposed tables.

Causes insertion, update, and deletion anomalies due to duplicated

Redundancy and Anomalies
data.

Loss of Referential Integrity Foreign key relationships become invalid, leading to orphaned data.

Increased Complexity in Queries become more complex, leading to slower performance and
Queries higher maintenance costs.

Violation of Functional Breaks the logical relationships between attributes, leading to data
Dependencies integrity issues.

Function Dependencies in Databases

In database design, functional dependencies (FDs) are a key concept in the relational model and
normalization process. A functional dependency describes a relationship between two sets of
attributes in a relation, where one set of attributes (called the determinant) uniquely determines
the value of another set of attributes (called the dependent attributes).

Definition of Functional Dependency:

A functional dependency is denoted as:

 X→Y

This means that the value of attribute set X uniquely determines the value of attribute set Y. In
other words, for every unique value of X, there is exactly one corresponding value of Y.

1. Types of Functional Dependencies

Functional dependencies can be classified based on how the attributes are involved:
1.1. Full Functional Dependency

A full functional dependency occurs when an attribute is functionally dependent on a set of

attributes and not just a part of that set.

 Example:
Suppose we have a relation Employee(EmpID, DeptID, EmpName, DeptName). If the
EmpID and DeptID together uniquely determine the DeptName (i.e., every employee in a
department has a unique department name), this is a full functional dependency:
 {EmpID, DeptID} → DeptName

 Key Point: Both attributes are required to determine the dependent attribute (DeptName).

1.2. Partial Functional Dependency

A partial functional dependency occurs when an attribute is functionally dependent on only a

part of a composite primary key (i.e., a primary key consisting of multiple attributes).

 Example:
If we have a composite primary key (EmpID, DeptID) and the EmpName depends only on
EmpID (and not on the combination of EmpID and DeptID), then this is a partial
dependency:
 EmpID → EmpName

 Key Point: In a normalized database, partial dependencies should be eliminated to avoid

redundancy.

1.3. Transitive Dependency

A transitive dependency occurs when one attribute is dependent on a second attribute, and the
second attribute is dependent on a third attribute. This can lead to indirect dependencies.

 Example:
If we have a relation Student(StudentID, CourseID, InstructorName) and the
InstructorName depends on CourseID (i.e., each course has one instructor), and
CourseID depends on StudentID (i.e., each student enrolls in one course), then the
dependency of InstructorName on StudentID is transitive:
 StudentID → CourseID → InstructorName

 Key Point: In a normalized design, transitive dependencies should be removed to ensure

the database is in Third Normal Form (3NF).

1.4. Trivial Functional Dependency

A trivial functional dependency is one where the dependent set is a subset of the determinant set.
These are essentially the most basic dependencies and don’t add any real constraint.
  Example: For a relation R(A, B, C), the following are trivial dependencies:
o A → A
o A, B → A

 Key Point: Trivial dependencies are usually ignored during the normalization process
because they don’t contribute to the overall structure of the database.

1.5. Multivalued Dependency

A multivalued dependency (MVD) occurs when one attribute set determines another attribute
set, but the second attribute set can have multiple values for each value in the first set.

 Example:
If we have a relation Student(StudentID, Hobby, Language), and a student can have
multiple hobbies and languages, then StudentID determines Hobby and StudentID
determines Language. Each student could have multiple hobbies and languages
independently.
 Key Point: Multivalued dependencies are handled in Fourth Normal Form (4NF).

2. Importance of Functional Dependencies in Normalization

Functional dependencies play a crucial role in the normalization process, which aims to reduce
data redundancy and dependency by organizing a database into multiple related tables. The goal
of normalization is to eliminate various types of undesirable dependencies, such as partial and
transitive dependencies, by decomposing relations into smaller, more manageable sub-relations.

3. Functional Dependencies in Normal Forms

Different normal forms use functional dependencies to ensure that the database design is free
from various types of redundancy and anomalies:

3.1. First Normal Form (1NF)

 Requirement: The relation should have atomic (indivisible) values, meaning no repeating groups
or arrays.
 Functional Dependency: While 1NF does not focus on functional dependencies, ensuring
atomicity lays the groundwork for further normalization.
3.2. Second Normal Form (2NF)

 Requirement: The relation should be in 1NF, and there should be no partial

dependencies. This means that all non-prime attributes must depend on the entire
primary key, not just a part of it.
 Functional Dependency: In 2NF, any partial dependency (where an attribute depends on
only part of a composite key) is removed.

3.3. Third Normal Form (3NF)

 Requirement: The relation should be in 2NF, and there should be no transitive

dependencies. Non-prime attributes must not depend on other non-prime attributes.
 Functional Dependency: In 3NF, transitive dependencies are eliminated, ensuring that
every non-prime attribute depends only on the primary key.

3.4. Boyce-Codd Normal Form (BCNF)

 Requirement: The relation should be in 3NF, and for every non-trivial functional dependency,
the determinant should be a candidate key. This eliminates even more complex forms of
redundancy than 3NF.

3.5. Fourth Normal Form (4NF)

 Requirement: The relation should be in BCNF, and there should be no multivalued

dependencies.
 Functional Dependency: Multivalued dependencies are removed in 4NF, which ensures the
independence of attribute sets.

4. Examples of Functional Dependencies

Let’s consider an example of a relation Employee(EmpID, EmpName, DeptID, DeptName,

EmpSalary) to understand how functional dependencies apply:

 EmpID → EmpName: The employee ID determines the employee’s name.

 DeptID → DeptName: The department ID determines the department name.
 EmpID, DeptID → EmpSalary: The combination of employee ID and department ID determines
the salary of the employee (assuming an employee can work in multiple departments, each with
a different salary).

If this relation were to be normalized, we would break it into smaller relations:

1. Employee(EmpID, EmpName)
2. Department(DeptID, DeptName)
3. EmployeeSalary(EmpID, DeptID, EmpSalary)
5. Practical Considerations

 Identifying Functional Dependencies: Identifying FDs in real-world databases can be

challenging, especially for large datasets. A thorough understanding of business rules and logic is
required to accurately define functional dependencies.
 Decomposition with Functional Dependencies: When decomposing relations to achieve higher
normal forms, functional dependencies guide the design decisions to ensure that data integrity
is preserved while eliminating redundancy.
 Performance Considerations: While normalization helps to reduce redundancy and improve
data integrity, it can sometimes lead to performance issues due to the increased number of
joins required for queries. This is particularly relevant in large databases, where denormalization
(intentionally introducing some redundancy for performance optimization) might be considered.

Conclusion

Type of Functional Dependency Description

Full Functional Dependency Entire set of attributes (composite key) determines another attribute.

Partial Functional Dependency Attribute depends on part of a composite key.

Transitive Dependency One attribute depends on another indirectly through a third attribute.

Trivial Dependency Dependent set is a subset of the determinant set (e.g., A → A).

One attribute set determines another attribute set with multiple

Multivalued Dependency
values.

Functional dependencies are foundational in understanding how data should be structured and
how normalization works to eliminate redundancy and improve the reliability of the database.

All Normal Forms in Database Design

Normalization is the process of organizing the attributes (columns) in a relational database to

minimize redundancy and dependency by applying a series of rules called normal forms (NF).
There are several normal forms, each building on the previous one. Here, we'll discuss First
Normal Form (1NF), Second Normal Form (2NF), Third Normal Form (3NF), Boyce-Codd
Normal Form (BCNF), and Fourth Normal Form (4NF), along with examples of how they
apply to a relation and the concept of Lossless Join Decomposition.
1. First Normal Form (1NF)

Definition:

A relation is in 1NF if:

 It has only atomic values (indivisible).

 Each record (row) is unique.
 There are no repeating groups or arrays.

Example:

Consider the following relation Student with multiple phone numbers in a single field:

StudentID Name Phone Numbers

1 Alice 123-456, 789-012

2 Bob 234-567, 890-123

To bring this into 1NF, we need to eliminate the repeating groups (Phone Numbers):

StudentID Name Phone Number

1 Alice 123-456

1 Alice 789-012

2 Bob 234-567

2 Bob 890-123

Now, each field contains atomic values, and there are no repeating groups.

Candidate Key:

In this relation, StudentID along with Phone Number is a candidate key, as the combination
uniquely identifies each record.

2. Second Normal Form (2NF)

Definition:

A relation is in 2NF if:

  It is in 1NF.
 It has no partial dependencies, meaning every non-prime attribute is fully functionally
dependent on the entire primary key (not just part of it).

Example:

Consider the following relation StudentCourse:

StudentID CourseID StudentName Instructor

1 CS101 Alice Dr. Smith

2 CS102 Bob Dr. Johnson

3 CS101 Charlie Dr. Smith

In this case, (StudentID, CourseID) is the composite primary key. However, StudentName
depends only on StudentID and not on the whole primary key. This is a partial dependency.

To bring this into 2NF, we break the relation into two:

1. Student(StudentID, StudentName)
2. Enrollment(StudentID, CourseID, Instructor)

Now, StudentName is fully dependent on the StudentID, and there is no partial dependency.

Candidate Key:

For Enrollment, the candidate key is (StudentID, CourseID), and for Student, the candidate
key is StudentID.

3. Third Normal Form (3NF)

Definition:

A relation is in 3NF if:

 It is in 2NF.
 It has no transitive dependencies, meaning no non-prime attribute depends on another non-
prime attribute.

Example:

Consider the relation StudentCourse from the previous example:

StudentID CourseID Instructor InstructorEmail

1 CS101 Dr. Smith smith@university

2 CS102 Dr. Johnson johnson@university

3 CS101 Dr. Smith smith@university

In this case, InstructorEmail is dependent on Instructor, and Instructor is a non-prime

attribute (not part of the primary key). This creates a transitive dependency.

To bring this into 3NF, we remove the transitive dependency by creating a separate table for
Instructor:

1. StudentCourse(StudentID, CourseID, InstructorID)

2. Instructor(InstructorID, InstructorName, InstructorEmail)

Now, InstructorEmail is directly dependent on the primary key InstructorID, and the transitive
dependency is eliminated.

Candidate Key:

For StudentCourse, the candidate key is (StudentID, CourseID), and for Instructor, the
candidate key is InstructorID.

4. Boyce-Codd Normal Form (BCNF)

Definition:

A relation is in BCNF if:

 It is in 3NF.
 For every non-trivial functional dependency, the determinant is a candidate key (i.e., all
attributes that determine other attributes must be candidate keys).

Example:

Consider the relation StudentCourse:

StudentID CourseID InstructorID InstructorName

1 CS101 1 Dr. Smith

2 CS102 2 Dr. Johnson

StudentID CourseID InstructorID InstructorName

3 CS101 1 Dr. Smith

In this case, InstructorID → InstructorName is a functional dependency, but InstructorID is

not a candidate key (because (StudentID, CourseID) is the candidate key).

To bring this into BCNF, we decompose the relation:

1. StudentCourse(StudentID, CourseID, InstructorID)

2. Instructor(InstructorID, InstructorName)

Now, the dependency InstructorID → InstructorName is valid because InstructorID is the

candidate key in the Instructor relation.

Candidate Key:

For StudentCourse, the candidate key is (StudentID, CourseID), and for Instructor, the
candidate key is InstructorID.

5. Fourth Normal Form (4NF)

Definition:

A relation is in 4NF if:

 It is in BCNF.
 It has no multivalued dependencies (MVDs), where one set of attributes determines multiple
independent sets of attributes.

Example:

Consider the relation StudentHobbyLanguage:

StudentID Hobby Language

1 Reading English

1 Painting French

2 Running Spanish

2 Writing French
Here, a multivalued dependency exists: StudentID → Hobby and StudentID → Language.
These are independent, meaning a student can have multiple hobbies and multiple languages, but
they are not related.

To bring this into 4NF, we decompose the relation into two:

1. StudentHobby(StudentID, Hobby)
2. StudentLanguage(StudentID, Language)

Now, there is no multivalued dependency, and the relation is in 4NF.

Candidate Key:

For both StudentHobby and StudentLanguage, the candidate key is StudentID.

Lossless Join Decomposition

A lossless join decomposition ensures that when a relation is decomposed into two or more sub-
relations, the original relation can be reconstructed by performing a natural join on the sub-
relations without losing any information.

Example:

Consider the relation Employee(EmpID, DeptID, EmpName, DeptName):

 After decomposing into two relations:

1. Employee1(EmpID, DeptID, EmpName)
2. Employee2(DeptID, DeptName)

If we join these two relations on DeptID, we can recover the original Employee relation. This is a
lossless join decomposition because no information is lost, and we can accurately reconstruct
the original table.

Lossless Join Decomposition Criterion:

To ensure a lossless join decomposition, the following must hold:

 The intersection of the decomposed relations should include a candidate key or at least a part
of the primary key.

Conclusion: Summary Table

 Normal
Main Criteria Example Relation Candidate Key
Form

Atomic values, no
1NF Student(StudentID, Name, Phone) StudentID
repeating groups

No partial dependencies
StudentCourse(StudentID, CourseID, (StudentID,
2NF (Fully functionally StudentName) CourseID)
dependent)

No transitive StudentCourse(StudentID, CourseID, (StudentID,

3NF InstructorID) CourseID)
dependencies

Determinants must be StudentCourse(StudentID, CourseID, (StudentID,

BCNF InstructorID) CourseID)
candidate keys

No multivalued StudentHobbyLanguage(StudentID,
4NF Hobby, Language)
StudentID
dependencies

In summary, normalization ensures that relations are designed in a way that reduces redundancy
and dependency, leading to more efficient and consistent databases. The lossless join
decomposition criterion guarantees that decomposing a relation does not lead to any loss of
information, allowing the original relation to be reconstructed.

UNIT-4

Transaction State in Database Management Systems

A transaction in a Database Management System (DBMS) is a sequence of operations that are

executed as a single unit of work. The concept of transaction state describes the various stages
through which a transaction passes during its execution. The state of a transaction refers to its
current condition in terms of its execution progress.

Transaction States

A transaction typically goes through several states during its lifecycle:

1. Active:
o In this state, the transaction is actively executing and performing operations like
reading or writing data.
o This is the state when the transaction is being processed and has not yet reached its
commit or abort decision point.
o Example: A user initiates a transaction to transfer money from one account to another.

2. Partially Committed:
o After the execution of the final operation, but before the commit, the transaction enters
the partially committed state.
o In this state, all the operations have been executed, but the transaction has not yet
been permanently saved to the database.
o Example: The money transfer transaction has completed all its operations, but the
system has not yet confirmed it as a permanent change.

3. Committed:
o In this state, the transaction has been successfully completed, and all its changes are
permanently reflected in the database.
o Once a transaction is committed, its effects are persistent, and the data is made durable
(i.e., saved to disk).
o Example: The money transfer transaction is confirmed, and the updated balance is
saved permanently.

4. Failed:
o A transaction can enter the failed state if it encounters some error or failure during
execution, preventing it from completing successfully.
o For example, it could happen if there is a system crash, a constraint violation, or an
invalid operation during transaction processing.
o Example: The money transfer failed due to insufficient funds.

5. Aborted:
o If a transaction fails or an error occurs after partial execution, the transaction enters the
aborted state.
o In this state, all changes made by the transaction are rolled back (undone), and the
database is restored to its state before the transaction began.
o This ensures that partial changes don't leave the database in an inconsistent or invalid
state.
o Example: The transaction is aborted, and the money transfer operation is undone, so no
funds are transferred between accounts.

6. Terminated:
o This is the final state for a transaction. It occurs after a transaction either successfully
commits or fails and is rolled back (aborted).
o Once a transaction reaches the terminated state, it cannot be restarted, and any
ongoing operations associated with it are considered complete.
State Transitions

The state of a transaction can transition from one state to another based on various conditions:

 Active → Partially Committed: After the transaction completes its operations but before it is
committed.
 Partially Committed → Committed: If no errors occur and the transaction is confirmed, it is
committed and changes become permanent.
 Active → Failed: The transaction encounters an error or exception during execution.
 Failed → Aborted: The transaction is rolled back, and changes made so far are undone.
 Partially Committed → Aborted: If a failure occurs before the transaction is committed, it is
aborted, and all changes are undone.

ACID Properties and Transaction States

The state of a transaction is crucial in maintaining the ACID (Atomicity, Consistency, Isolation,
Durability) properties:

1. Atomicity:
o Ensures that a transaction is treated as a single unit of work. If a transaction fails, all its
changes are rolled back (no partial updates). This is reflected in the aborted state.

2. Consistency:
o Ensures that a transaction transforms the database from one consistent state to
another. A transaction should either commit (if successful) or abort (if an error occurs),
maintaining the consistency of the database.

3. Isolation:
o Guarantees that transactions are isolated from one another. Even if two transactions
are running concurrently, each transaction should not interfere with the others.
Transactions in the active state are isolated from others.

4. Durability:
o Ensures that once a transaction is committed, its changes are permanent, even in the
event of a system crash. The committed state ensures durability by making changes
permanent.

Transaction Lifecycle Example

Let's consider a money transfer transaction from Account A to Account B:

1. Active: The transaction starts, and funds are being deducted from Account A.
 2. Partially Committed: The funds have been deducted, but the transfer to Account B has not yet
been recorded.
3. Committed: The funds are successfully transferred to Account B, and the transaction is
committed, ensuring that changes are permanent.
4. Failed: If there is an error (e.g., insufficient funds), the transaction moves to the failed state.
5. Aborted: After the failure, the transaction is aborted, and any changes are rolled back to
maintain database integrity.
6. Terminated: The transaction is complete, either by being committed or aborted, and is now in
the terminated state.

Conclusion

Understanding the transaction state is fundamental to ensuring that database systems maintain
integrity, consistency, and reliability during transaction processing. The proper management of
transaction states (from Active to Terminated) is key to upholding the ACID properties, which
guarantee that the database functions correctly in the presence of errors, failures, and concurrent
transactions.

ACID Properties in Database Systems

The ACID properties are a set of four properties that ensure that database transactions are
processed reliably and guarantee the integrity of the database. These properties are essential for
maintaining consistency, correctness, and reliability of the database even in the presence of
system failures, errors, or concurrent transactions.

The four ACID properties are:

1. Atomicity
2. Consistency
3. Isolation
4. Durability

1. Atomicity

 Definition: The atomicity property ensures that a transaction is treated as a single,

indivisible unit of work. This means that all operations in the transaction are completed
successfully, or none of them are. If a transaction fails at any point during its execution,
all the changes made by the transaction are rolled back, and the database is restored to its
previous state.
 Example: If a transaction involves transferring money from one bank account to another,
both the debit from Account A and the credit to Account B must happen as a single unit.
If the debit succeeds but the credit fails, atomicity ensures that the debit is rolled back,
and no partial changes are left in the system.
 o Commit: If the transaction completes successfully, it is committed, meaning all changes
are applied.
o Rollback: If there is a failure, the transaction is rolled back, and no changes are made to
the database.

2. Consistency

 Definition: The consistency property ensures that a transaction will bring the database
from one consistent state to another. After a transaction, the database must remain in a
valid state according to predefined rules, constraints, and business logic. It must satisfy
all integrity constraints, such as unique keys, foreign keys, and other rules that are
defined for the database.
 Example: In a banking system, there may be a rule that the balance of an account cannot
be negative. If a transaction tries to withdraw more money than the available balance,
consistency ensures that the transaction fails and the database remains in a consistent
state.

3. Isolation

 Definition: The isolation property ensures that transactions are executed in isolation from
one another. Even if multiple transactions are running concurrently, each transaction
should not interfere with the others. Intermediate results of a transaction should not be
visible to other transactions until the transaction is complete (committed).
 Levels of Isolation: The isolation level can vary, and different database systems provide
multiple levels of isolation, each with a different trade-off between performance and
correctness:
o Read Uncommitted: Transactions can read data that is not yet committed (uncommitted
dirty data).
o Read Committed: Transactions can only read committed data.
o Repeatable Read: Transactions ensure that data read during the transaction cannot be
changed by other transactions.
o Serializable: The highest level of isolation, where transactions are executed in such a
way that the results are the same as if they were executed sequentially.

 Example: If two transactions are attempting to update the same record in a database,
isolation ensures that they do not simultaneously modify the record, avoiding conflicts or
inconsistencies.

4. Durability

 Definition: The durability property ensures that once a transaction has been committed,
its effects are permanent, even in the case of a system failure, crash, or power loss. Once
 the transaction has been completed, all changes are saved to non-volatile storage (disk or
database), and they are guaranteed to persist.
 Example: If a user commits a transaction that updates an employee's salary, the new
salary will be permanently stored in the database. Even if the system crashes immediately
after the commit, the updated salary will not be lost, and the transaction will not need to
be reapplied.

Serializability in Database Systems

Serializability is a key concept in the context of concurrent transactions. It refers to the ability
to ensure that the result of executing multiple transactions concurrently is equivalent to executing
them one at a time, in some serial order.

Serializability is a strict form of isolation that guarantees the correctness of concurrent

transactions by ensuring that the final state of the database is the same as if the transactions were
executed sequentially (one after the other).

Types of Serializability:

1. Conflict Serializability:
o This is the most common type of serializability. It ensures that the concurrent execution
of transactions results in a state that could be obtained by some serial execution of the
same transactions, where a serial execution means that each transaction is executed
one at a time.
o Two operations are said to conflict if they:
 Belong to different transactions.
 Access the same data item.
 At least one of the operations is a write operation.
o Example:
 Transaction 1: Write(X)
 Transaction 2: Read(X)
 These two operations conflict because one writes and the other reads the same
data item, X. To preserve consistency, they should be executed in such a way
that their effects are serialized.

2. View Serializability:
o View serializability is a more general concept of serializability. It ensures that the final
result of the transaction execution (the view of the database) is the same as if the
transactions were executed serially. It is less strict than conflict serializability.
o This means that the transactions can be interleaved in a way that the final database
state is equivalent to some serial execution of the transactions, even if operations within
the transactions do not conflict directly.
Ensuring Serializability:

Serializability can be enforced using various concurrency control mechanisms, such as:

 Locking: Ensuring that transactions obtain locks on data items before accessing them to
avoid conflicts.
o Example: When one transaction locks a record, others must wait until the lock is
released.

 Timestamp Ordering: Assigning a timestamp to each transaction and ensuring that

transactions are executed in the order of their timestamps.
o Example: If Transaction 1 arrives before Transaction 2, the system ensures that the
database state after their execution is the same as if Transaction 1 had executed first.

 Two-Phase Locking (2PL): Ensuring that transactions follow a two-phase locking

protocol where they first acquire locks (growing phase) and then release locks (shrinking
phase). This protocol guarantees conflict serializability.

Example of Serializability

Consider the following transactions on a simple account database:

 Transaction T1:
1. Read(A)
2. A = A + 100 (deposit $100)
3. Write(A)
 Transaction T2:
1. Read(A)
2. A = A - 50 (withdraw $50)
3. Write(A)

If these transactions are executed concurrently, we must ensure that their interleaving produces
the same result as if they were executed serially, i.e., one after the other. A possible serial order
might be:

 T1 → T2:
o T1 deposits $100 first, then T2 withdraws $50, resulting in the final balance being $50
more than before.

Alternatively:

 T2 → T1:
o T2 withdraws $50 first, then T1 deposits $100, resulting in the final balance being $50
more than before.
In this case, the transactions can be serialized without causing any inconsistency, and both
execution orders are valid.

Conclusion

The ACID properties guarantee that database transactions are executed reliably and correctly,
maintaining the integrity of the data. Serializability, on the other hand, ensures that concurrent
transactions are executed in a manner that produces consistent results, as if they had been
executed one at a time. Both concepts are fundamental to ensuring that a database system
behaves in a predictable, reliable, and correct manner when dealing with multiple transactions.

Lock-Based Protocols, Timestamp-Based Protocols, Validation-Based Protocols,

and Multiple Granularity in Database Systems

In Database Management Systems (DBMS), concurrency control mechanisms are employed

to ensure that concurrent transactions do not violate the ACID properties, especially Isolation.
These mechanisms help in preventing conflicts such as lost updates, temporary inconsistency,
and uncommitted data being read by other transactions. The four common types of concurrency
control protocols are:

1. Lock-Based Protocols
2. Timestamp-Based Protocols
3. Validation-Based Protocols
4. Multiple Granularity Protocols

Each of these protocols helps in ensuring serializability and maintaining the integrity of the
database during concurrent transaction execution.

1. Lock-Based Protocols

Lock-based protocols use locks to control access to data. A lock is a mechanism that prevents
other transactions from accessing a data item while it is being modified. Locking ensures that a
transaction can read or write a data item without interference from other transactions. The
primary goal of a lock-based protocol is to ensure serializability, which means that the result of
executing transactions concurrently is the same as if they were executed serially.
Types of Locks:

 Exclusive Lock (X-lock):

o An exclusive lock is placed on a data item when a transaction intends to modify it (i.e.,
for writing). When a transaction holds an exclusive lock on a data item, no other
transaction can either read or modify that item.
 Shared Lock (S-lock):
o A shared lock is placed when a transaction intends to read a data item. Multiple
transactions can acquire shared locks on the same data item, allowing them to read it
simultaneously, but none of them can modify it until the shared lock is released.
 Lock Compatibility:
o S-lock and S-lock: Compatible (multiple transactions can read the data concurrently).
o S-lock and X-lock: Not compatible (a transaction can’t read data while another is
writing).
o X-lock and X-lock: Not compatible (one transaction can’t modify data while another is
modifying it).

Two-Phase Locking (2PL):

 The two-phase locking protocol is a popular lock-based protocol that guarantees serializability.
It has two phases:
1. Growing Phase: A transaction can acquire locks but cannot release any locks.
2. Shrinking Phase: A transaction can release locks but cannot acquire new ones.
 This ensures that once a transaction starts releasing locks, it will not acquire any more, and no
conflicting transactions can interfere with the ones that have already locked the data.

Example:

If two transactions, T1 and T2, want to access the same data item:

 T1 may acquire an exclusive lock to modify the item.

 T2 must wait until T1 releases the lock before accessing or modifying the item.

2. Timestamp-Based Protocols

Timestamp-based protocols use timestamps to determine the serializability order of transactions.

Each transaction is assigned a unique timestamp when it starts. The protocol ensures that
transactions are executed in such a way that the final outcome is equivalent to one where
transactions are executed in timestamp order.

How it Works:

 Each transaction is assigned a timestamp when it is initiated.

 The system tracks read and write timestamps for each data item:
o Read Timestamp: The timestamp of the last transaction that read a data item.
 o Write Timestamp: The timestamp of the last transaction that modified a data item.

The protocol prevents a transaction from performing actions that would violate the timestamp
order, ensuring serializability. If a conflict arises, the transaction with the older timestamp is
allowed to proceed, and the newer transaction may be rolled back.

Types of Timestamp-Based Protocols:

 Basic Timestamp Ordering (BTO):

o Transactions are processed based on their timestamps, and actions are permitted only if
they do not conflict with earlier transactions. For example, if a transaction reads a data
item, it is not allowed to write it if a newer transaction has already written to it.
 Thomas’ Write Rule:
o An optimization of basic timestamp ordering, where it allows some out-of-order writes
under specific conditions. If a transaction tries to write a data item that has already
been written by a transaction with a later timestamp, and that transaction has not yet
been committed, the write is ignored.

Example:

 Transaction T1 is assigned timestamp 1, and T2 is assigned timestamp 2.

 If T1 reads data item X before T2 writes it, T1 can safely access X.
 If T2 writes X before T1, T1 will be rolled back to maintain timestamp order.

3. Validation-Based Protocols

Validation-based protocols work by allowing transactions to execute freely during the

validation phase, without interference from other transactions. However, when the transaction
reaches the validation phase (before committing), it is checked to ensure that no conflicts have
occurred with other transactions.

How it Works:

1. Read Phase: Transactions perform their operations (read or write) on data items without any
restriction.
2. Validation Phase: Before a transaction is committed, the system checks whether it conflicts with
any other concurrent transactions. If conflicts are found, the transaction is rolled back.
3. Commit Phase: If no conflict is detected during the validation phase, the transaction is allowed
to commit.

The key idea is that transactions are only validated for serializability when they attempt to
commit, which allows more concurrency compared to other protocols.
Example:

 Transaction T1 reads data item X.

 Transaction T2 reads data item X and writes to Y.
 In the validation phase, if T1 and T2 have conflicting operations (e.g., T2 writes to Y after T1
reads X), one of the transactions is aborted and restarted.

4. Multiple Granularity Locking

Multiple Granularity Locking is an extension of the locking mechanism that allows transactions
to lock data at different levels of granularity. Instead of locking an individual data item,
transactions can lock entire data structures, such as tables, rows, or even columns, depending
on the level of granularity required.

Types of Granularity:

 Database-level: Locks the entire database.

 Table-level: Locks an entire table.
 Row-level: Locks a single row in a table.
 Column-level: Locks a single column of a table.
 Field-level: Locks a specific field or attribute.

Advantages:

 Reduced Locking Overhead: By locking at a higher level (e.g., a table or database), fewer locks
are needed, reducing the overhead of managing locks.
 Increased Concurrency: By locking at a finer level (e.g., row-level), more transactions can be
executed concurrently without interfering with each other.

How it Works:

 Compatibility: Locks at a higher granularity (e.g., table-level) are not compatible with
locks at a finer granularity (e.g., row-level) within the same table. The system ensures
that no conflict arises between transactions that request different levels of locking.
 Parent-Child Relationship: Locks at a higher level (e.g., table-level) include all locks
on the lower-level data (e.g., row-level locks). Thus, acquiring a table-level lock
implicitly acquires row-level locks.

Example:

 Transaction T1 acquires a row-level lock on a record in a table.

 Transaction T2 wants to update an entire table, so it acquires a table-level lock.
 The two locks are incompatible, meaning that T2 will have to wait until T1 releases the row-level
lock.
Conclusion

Each of these concurrency control protocols—Lock-Based, Timestamp-Based, Validation-

Based, and Multiple Granularity Locking—addresses the challenges of managing concurrent
transactions and ensuring database consistency and isolation.

 Lock-based protocols provide strict control over data access to avoid conflicts.
 Timestamp-based protocols ensure that transactions are executed in a serializable order by
using timestamps.
 Validation-based protocols allow transactions to execute freely, only validating them when
committing.
 Multiple granularity allows flexible locking strategies, with varying levels of granularity to
balance concurrency and performance.

By using these protocols, DBMSs can effectively manage concurrency while maintaining
serializability and ensuring that the ACID properties are respected.

Buffer Management and Remote Backup Systems in Database Management

Systems

In Database Management Systems (DBMS), Buffer Management and Remote Backup

Systems are two essential components for ensuring system performance, reliability, and data
durability. These systems help in optimizing data access, managing memory efficiently, and
safeguarding data in the case of system failures or disasters.

1. Buffer Management

Buffer management refers to the management of memory buffers in a DBMS that temporarily
holds data read from or written to disk. Disk accesses are typically slow compared to memory
accesses, so efficient buffer management is crucial for improving the performance of the
database system. A buffer pool is used to store the most frequently accessed data pages in
memory to reduce disk I/O.

Key Concepts in Buffer Management:

1. Buffer Pool:
o The buffer pool is a portion of main memory (RAM) allocated by the DBMS to
temporarily hold data pages that are being actively read or written by transactions.
 o The buffer pool size can be adjusted depending on the available system memory. A
larger buffer pool generally improves performance because more data can be held in
memory, reducing the need to access disk frequently.

2. Pages:
o A database is stored on disk as a collection of data pages. These pages are the smallest
unit of data transfer between disk and memory.
o When a transaction needs to access data, the DBMS reads the corresponding data pages
from disk into the buffer pool.

3. Replacement Policies:
o Since the buffer pool has limited size, it cannot store all the pages of the database at
once. When the buffer pool is full and new pages need to be read, replacement policies
determine which pages should be evicted from memory.
o Common buffer replacement policies include:
 Least Recently Used (LRU): Evicts the page that has not been accessed for the
longest time.
 First In First Out (FIFO): Evicts the oldest page in memory.
 Most Recently Used (MRU): Evicts the most recently accessed page (less
common).
 Clock: A more efficient approximation of LRU, where pages are arranged in a
circular queue and marked for eviction if they have not been recently accessed.

4. Dirty Pages:
o When a transaction updates a page, the modified page is considered dirty because it has
been changed in memory but not yet written back to the disk.
o The DBMS must periodically flush dirty pages from the buffer pool to the disk to ensure
that the changes are saved. This can be done through background processes or when a
transaction commits.

5. Write-Ahead Logging (WAL):

o To ensure durability and recoverability, the DBMS often uses a Write-Ahead Logging
(WAL) protocol. This means that before any modifications are made to the data pages,
the corresponding changes are first written to a log. Once the changes are written to the
log, the data pages can be updated in the buffer pool.
o If the system crashes before the changes are written to disk, the WAL ensures that the
changes can be recovered from the log.

Buffer Management Example:

Consider a scenario where a transaction requests access to a specific data item. If the data item is
not already in the buffer pool:

 The DBMS reads the corresponding page from disk into the buffer pool.
 If the buffer pool is full, the DBMS evicts a page based on its buffer replacement policy (e.g.,
LRU).
 If the evicted page is dirty, it is written back to disk before being replaced.
Efficient buffer management is crucial for reducing the number of disk I/O operations, as
frequent disk access can significantly degrade performance.

2. Remote Backup Systems

Remote backup systems refer to strategies used to back up and restore data in a DBMS to
ensure data durability and availability in case of disasters, hardware failures, or human errors.
By backing up the database to an external location, remote backup systems provide a safeguard
against data loss, ensuring that the system can recover to a consistent state after a failure.

Key Concepts in Remote Backup Systems:

1. Types of Remote Backups:

o Full Backup: A complete copy of the entire database. This is the most comprehensive
backup but also the most time-consuming and space-intensive.
 Example: A full backup of a database might be performed once a day, during off-
peak hours.
o Incremental Backup: A backup of only the data that has changed since the last backup
(whether full or incremental). This saves storage space and reduces backup time, but it
may require more time during recovery.
 Example: If a full backup was made on Monday, an incremental backup on
Tuesday would only include changes since Monday.
o Differential Backup: A backup of all the data that has changed since the last full backup.
Unlike incremental backups, differential backups do not reset after each backup, so the
size of the backup grows over time.
 Example: If a full backup was made on Monday, a differential backup on
Tuesday would include all changes since Monday, and a differential backup on
Wednesday would include all changes since Monday.

2. Backup Strategies:
o Local Backup: Involves backing up data to storage devices located within the same
physical location as the primary database, such as external hard drives or network-
attached storage (NAS).
o Remote Backup: Refers to backing up data to an off-site location, either over the
internet or via private communication lines. This provides disaster recovery capabilities
in the event of natural disasters or on-site failures.

3. Offsite Backup Locations:

o Cloud Backup: Cloud storage services (e.g., AWS, Azure, Google Cloud) are used to back
up database data remotely. This offers the advantage of scalability, accessibility, and
redundancy.
o Tape Storage: In some systems, data backups are written to magnetic tape, which is
then stored offsite. While this method is less common now due to slower recovery
times, it can still be useful for long-term storage.
 o Distributed Systems: Some DBMSs use geographically distributed data centers to create
redundancy and back up data in multiple locations for better disaster recovery.

4. Backup Scheduling and Automation:

o Automated backup systems are typically scheduled to run at specific intervals, such as
daily, weekly, or during off-peak hours. This ensures that backups are always up-to-date
without manual intervention.
o Backup Window: The period during which backups are taken (e.g., during the night),
and the system must balance the need for timely backups with minimizing the impact
on performance during regular operations.

5. Backup and Restore Process:

o Backup: The database is copied from the primary storage to backup storage. The DBMS
may use tools or built-in functions to create the backup.
o Restore: In case of failure, the database can be restored from backup, either partially or
fully, to a specific point in time. The DBMS uses the backup files and recovery logs to
bring the database back to a consistent state.

6. Point-in-Time Recovery (PITR):

o Remote backup systems often support point-in-time recovery, allowing the system to
be restored to a specific moment, such as just before a failure occurred. This is often
achieved using transaction logs that track changes to the database.
o Example: If a failure occurs at 3 PM, and the last backup was at 1 PM, the DBMS can use
the transaction logs from 1 PM to 3 PM to restore the database to its state at 3 PM.

7. Encryption and Security:

o Backup data, especially when transferred to remote locations (e.g., cloud), must be
encrypted to protect against unauthorized access. Security protocols like SSL/TLS are
used to secure data during transit.

Example:

A company performs nightly full backups of its database to an offsite cloud server (remote
backup). During the day, incremental backups are taken every 6 hours. In the event of a server
failure, the database can be restored from the last full backup and then updated with the most
recent incremental backups, ensuring minimal data loss.

Conclusion

Buffer Management and Remote Backup Systems are vital components for ensuring high
performance, reliability, and data durability in a DBMS.

 Buffer Management improves data access performance by managing memory buffers

efficiently, reducing the need for frequent disk I/O operations.
  Remote Backup Systems provide data redundancy and disaster recovery, ensuring that the
database can be recovered in case of failures, errors, or natural disasters.

Both play essential roles in maintaining the availability, integrity, and resilience of a database
system. Properly implementing these systems can significantly enhance a DBMS’s overall
reliability and operational efficiency.

UNIT-5
File Organization and Indexing Types in Database Management Systems

In Database Management Systems (DBMS), file organization refers to the way data is stored
on the disk, and indexing is a technique used to improve the speed of data retrieval operations.
These two concepts are crucial for optimizing the performance of a DBMS, especially when
dealing with large volumes of data. Let’s explore both topics in detail:

1. File Organization

File organization refers to the way records are stored in a file system on disk. Efficient file
organization reduces the time required to access and manipulate data, thus improving the overall
performance of the database.

Types of File Organization:

1. Heap File Organization:

o In heap file organization, records are stored in no particular order, and new records are
simply appended to the end of the file.
o Advantages:
 Simple to implement.
 Efficient for small databases where the number of records is not very large.
o Disadvantages:
 Searching and retrieving data is slow since the entire file may need to be
scanned.
 Not suitable for large databases with frequent search or update operations.
 Example: A heap file might store customer records in the order they are entered. If a new
record is added, it’s simply placed at the end of the file without any sorting.

2. Sequential File Organization:

o In sequential file organization, records are stored in a specific order, usually based on a
key attribute (e.g., primary key).
o Advantages:
 Searching is more efficient because records are stored in sorted order.
 Efficient for read-heavy applications where the data retrieval happens in a
sequential manner.
o Disadvantages:
 Insertions and deletions are costly because the file may need to be reorganized.
 Not efficient for applications requiring frequent updates or random access to
records.

Example: A sorted file might store employee records sorted by employee ID. To insert a
new employee, the system might need to find the correct position and shift the existing
records.

3. Hashed File Organization:

o In hashed file organization, a hash function is used to calculate the location of each
record based on a key attribute. The hash function maps the key value to a specific
location in the file.
o Advantages:
 Very fast for accessing records when the key is known.
 Ideal for equality searches (e.g., finding a specific record).
o Disadvantages:
 Not suitable for range queries (e.g., retrieving records within a certain range of
values).
 Hash collisions can occur, requiring additional handling (e.g., chaining or open
addressing).

Example: A hash function could be applied to the employee ID to determine where the
corresponding employee record will be placed in the file. For example, the hash value of
employee ID 12345 could point to the specific block in the file where the record is stored.

4. Clustered File Organization:

o In clustered file organization, records that are likely to be accessed together are stored
physically close to each other on disk. This is done by grouping related records (based on
common attributes) into the same block or disk page.
o Advantages:
 Reduces disk I/O operations by minimizing the number of disk accesses required
for related records.
 Suitable for applications where records with certain attributes are often queried
together.
o Disadvantages:
 May lead to wasted space if records are not accessed in the expected patterns.
  Insertion of new records may require reorganizing the file.

Example: In a clustered file, customer records and their corresponding order records
could be stored in the same block because they are frequently accessed together.

5. B-tree/B+ Tree File Organization:

o A B-tree or B+ tree is a type of self-balancing tree data structure that maintains sorted
data and allows efficient insertion, deletion, and search operations.
o Advantages:
 Supports both equality and range queries.
 Balanced structure ensures that all operations (search, insert, delete) are
efficient and take logarithmic time.
o Disadvantages:
 More complex than other file organizations.

Example: A B+ tree can be used for indexing large databases, and records in the tree will
be sorted, allowing efficient access to both specific records and ranges of records.

2. Indexing Types

Indexing is a technique that enhances the speed of data retrieval operations by providing an
efficient way to look up records based on a key. An index is a data structure that maps keys to
corresponding data locations. There are several types of indexing techniques, each suited for
different use cases.

Types of Indexing:

1. Primary Index:
o A primary index is created on the primary key of a table, ensuring that the index's key is
unique. Each record in the file has a unique value for the indexed attribute.
o Advantages:
 Fast retrieval of records based on the primary key.
 Supports efficient range queries.
o Disadvantages:
 Primary index requires that the table be sorted by the primary key, which can be
expensive for large tables.

Example: A primary index on the employee table using employee ID would allow fast
lookups by employee ID.

2. Secondary Index:
o A secondary index is created on non-primary key attributes, providing a way to access
records based on fields other than the primary key. The index may not enforce
uniqueness.
o Advantages:
  Allows fast access to data based on non-primary key attributes.
 Useful for queries that require searching based on multiple attributes.
o Disadvantages:
 Secondary indexes require extra storage.
 May require additional maintenance during updates, inserts, or deletes.

Example: A secondary index on the employee table based on the department field allows
fast retrieval of employees belonging to a specific department.

3. Clustered Index:
o A clustered index is one where the physical order of the records in the file is the same
as the order of the index. In a clustered index, the data is stored in sorted order based
on the indexed attribute.
o Advantages:
 Provides efficient access to records in sorted order.
 Especially useful for range queries.
o Disadvantages:
 There can be only one clustered index per table, as the data rows can only be
sorted in one order.
 Insertion of records may be slower as the data file needs to be reordered.

Example: A clustered index on employee ID would physically sort the employee records
based on the employee ID.

4. Non-Clustered Index:
o A non-clustered index is an index where the order of the index is different from the
physical order of records in the file. The index contains pointers to the data records
rather than the records themselves.
o Advantages:
 Allows multiple non-clustered indexes on a table.
 Faster search on non-primary key columns.
o Disadvantages:
 Requires additional storage for the index structure.
 Slightly slower compared to clustered indexes for range queries.

Example: A non-clustered index on the employee’s last name allows fast lookups of
employees by last name, but the records may not be physically sorted by last name.

5. Hash Indexing:
o Hash indexing is a type of indexing where a hash function is applied to the key to
determine the location of the record in the index. This type of index is suitable for
equality queries (e.g., find records with a specific key value).
o Advantages:
 Extremely fast for exact match queries.
 Provides constant-time retrieval for hash collisions.
o Disadvantages:
 Inefficient for range queries (since the data is not ordered).
  Requires handling hash collisions using techniques like chaining or open
addressing.

Example: A hash index on an employee’s social security number would allow for fast
retrieval of a record based on the social security number.

6. B-Tree and B+ Tree Indexing:

o B-Tree and B+ Tree are self-balancing tree data structures. B-Tree is used for indexing in
DBMS to ensure that data is efficiently accessed through both equality and range
queries.
o Advantages:
 Supports both equality and range queries efficiently.
 Keeps the data sorted, ensuring that searches, inserts, updates, and deletions
are fast (logarithmic time).
o Disadvantages:
 More complex than other indexing methods.

Example: A B+ tree index on employee IDs ensures that both exact matches and range
queries (e.g., finding employees with IDs between 1000 and 2000) are performed
efficiently.

Conclusion

 File organization determines how data is stored on disk, impacting the efficiency of data
retrieval and updates.
 Indexing provides a mechanism to quickly look up records based on specific attributes, greatly
enhancing query performance, especially in large databases.

Choosing the right file organization and indexing technique depends on the specific use case,
query types (e.g., range vs. equality), and the overall size and complexity of the database.
Efficient file organization and indexing are critical to achieving high performance in a DBMS.

Hash-Based Indexing and Tree-Based Indexing in Database Management

Systems

In Database Management Systems (DBMS), indexing is a technique used to improve the speed
of data retrieval operations. The indexing methods can be broadly categorized into Hash-based
indexing and Tree-based indexing. Both of these methods are used to efficiently access and
manage large volumes of data, but they differ in their underlying structures and use cases.
1. Hash-Based Indexing

Hash-based indexing is a method of indexing that uses a hash function to map the search key
to a specific location in the index. This technique is particularly effective for equality searches
(i.e., when looking for records that exactly match a given key value).

How It Works:

 A hash function is applied to the key value of each record.

 The hash function generates a hash value, which is then used to determine the position of the
record in the file or index.
 The hash function is designed to distribute records evenly across the index to minimize collisions
(i.e., cases where two different keys hash to the same index location).
 In case of a collision, techniques like chaining (using linked lists) or open addressing (finding
another open slot) are used to resolve the issue.

Advantages:

 Fast lookups: For exact-match queries (e.g., "find the employee with ID 123"), hash-based
indexing offers constant-time lookup.
 Efficient storage: The hash index structure is compact and requires less storage than other
indexing methods.

Disadvantages:

 Not suitable for range queries: Since the data is not stored in any particular order, hash indexes
are inefficient for queries that involve range conditions (e.g., finding all employees with IDs
between 1000 and 2000).
 Collision handling: Handling hash collisions can add complexity and impact performance if not
handled efficiently.

Example:

 Suppose we are using hash-based indexing on an employee table with an employee ID as the
key. The hash function maps the employee ID to a specific location in the index. For an exact
match query like "Find the employee with ID 1001," the index can directly locate the
corresponding record without scanning the entire table.

Hashing Methods:

1. Static Hashing: In static hashing, the hash function maps keys to a fixed-size table. If the table is
full, there may be a need to resize or reorganize the index.
2. Dynamic Hashing: In dynamic hashing, the size of the hash table grows or shrinks dynamically
based on the number of entries, improving scalability.
3. Extendable Hashing: A type of dynamic hashing where the directory grows and shrinks in a
binary fashion. This method provides more flexibility in handling overflow.
 4. Linear Hashing: This method handles collisions by incrementally expanding the hash table. It
reduces the cost of rehashing compared to extendable hashing.

2. Tree-Based Indexing

Tree-based indexing utilizes tree data structures, like B-trees and B+ trees, to store and
organize the index. Tree-based indexes provide sorted order of keys, making them efficient for
both equality and range queries. These indexes are often preferred for applications that require
ordered data or efficient range searches.

How It Works:

 Tree-based indexes maintain a hierarchical structure, where each node contains one or more
keys and pointers to child nodes.
 In a B-tree or B+ tree, the data is kept sorted at all levels of the tree, allowing for efficient
searches.
 Leaf nodes of the tree contain the actual records or pointers to the records in the database.
 Internal nodes of the tree store key values that act as guides to find the correct leaf node where
the data resides.

Advantages:

 Efficient range queries: Since the keys are stored in sorted order, both exact-match and range
queries (e.g., finding records with a key between a specific range) can be performed efficiently.
 Balanced structure: B-trees and B+ trees are self-balancing, meaning that all leaf nodes are at
the same depth, ensuring that search operations are fast (logarithmic time).
 Flexible: Can handle both point queries (e.g., find a specific record) and range queries (e.g., find
all records within a range).

Disadvantages:

 More complex: Tree-based indexing requires more overhead than hash indexing and is more
complex to implement.
 Storage overhead: Each node in the tree requires additional storage for pointers and keys,
which may lead to higher storage costs.
 Slower updates: Inserting or deleting records in a tree-based index requires maintaining the
balance of the tree, which can be time-consuming.

Types of Tree-Based Indexing:

1. B-Tree Indexing:
o A B-tree is a self-balancing search tree in which each node can contain more than one
key and can have more than two children.
o The tree is kept balanced so that all leaf nodes are at the same level, ensuring efficient
search, insert, and delete operations.
 o Advantages: B-trees are ideal for systems where the database is stored on disk, as they
minimize the number of disk accesses by maximizing the number of keys stored per
node.
o Disadvantages: Insertion and deletion operations can be more complex due to the need
to maintain balance.

Example: A B-tree index on employee IDs allows for fast searches (e.g., "Find employee
with ID 1234") and range queries (e.g., "Find all employees with IDs between 1000 and
2000").

2. B+ Tree Indexing:
o A B+ tree is a variation of the B-tree where all the actual data is stored in the leaf nodes.
Internal nodes store only keys that guide the search.
o The leaf nodes are linked in a linked-list fashion to allow efficient range queries.
o Advantages: The B+ tree is efficient for both exact-match and range queries because
the leaf nodes are organized in a linked list, allowing for fast traversal of consecutive
records.
o Disadvantages: Slightly more storage overhead due to the linked-list structure.

Example: A B+ tree index on a student table could allow efficient querying for students
by student ID or for retrieving all students whose IDs are in a specific range.

Comparison Between Hash-Based Indexing and Tree-Based Indexing

Feature Hash-Based Indexing Tree-Based Indexing (B-tree/B+ tree)

Equality searches (e.g., find exact

Best For Equality and range queries
match)

Query Type Exact match only Exact match and range queries

Data Ordering No specific order Sorted order of keys

Performance for Range Poor (not suitable for range

Efficient (supports range queries)
Queries queries)

Hash collisions may occur, need

Collisions No collisions (data is well-structured)
resolution

Insertion/Deletion Simple but may require resizing (in More complex (due to balancing
Complexity dynamic hashing) operations)

Higher (due to tree structure and

Storage Overhead Low
pointers)

Example Use Case Lookup by ID (e.g., employee ID) Range queries and ordered searches
 Feature Hash-Based Indexing Tree-Based Indexing (B-tree/B+ tree)

(e.g., employees by salary)

Conclusion

 Hash-based indexing is best suited for exact match queries where the search key is known, and
it provides fast access. However, it is inefficient for range queries.
 Tree-based indexing, particularly B-trees and B+ trees, is more versatile and suitable for both
equality and range queries due to their ordered structure and efficient search algorithms.

Both indexing techniques have their strengths and are chosen based on the specific use case and
query requirements of the database system.

ISAM (Indexed Sequential Access Method) and B+ Trees in Database

Management Systems

Both ISAM and B+ Trees are indexing techniques used in database management systems to
facilitate fast retrieval of records based on a search key. They help optimize query performance
by organizing data in a way that minimizes the number of disk accesses. Let's look into both
ISAM and B+ Trees in detail, their characteristics, and their applications.

1. ISAM (Indexed Sequential Access Method)

ISAM is a traditional indexing method that was widely used before more advanced techniques
like B+ Trees became popular. It uses a combination of a sequential access file and an index to
speed up data retrieval.

How ISAM Works:

 ISAM uses two components for indexing:

1. Primary Index: This index is built on the search key and points to the block (or page) of
the data file where the actual record is stored. It is a dense index, meaning every record
in the file has an entry in the index.
2. Data File: The data file is stored sequentially (sorted on the search key) and records are
grouped into blocks.
 The primary index provides fast access to the data file by reducing the search space for finding
records.
Key Features of ISAM:

 Static Index Structure: The index is built once and remains static. If data grows beyond the initial
allocation, the index and data file need to be rebuilt, which makes ISAM inefficient for databases
with frequent insertions or deletions.
 Sequential Access: The records are stored in a sequential manner, which makes it efficient for
queries that retrieve a set of records in order (range queries).
 Dense Indexing: Every record in the data file has an entry in the index, ensuring quick access to
specific records.

Advantages of ISAM:

 Efficient for range queries: Since the data is stored sequentially, range queries (e.g., retrieving
records with keys in a specific range) are efficient.
 Simple structure: ISAM’s simple design makes it easy to implement and understand.

Disadvantages of ISAM:

 Static Index: ISAM’s major drawback is that it is not dynamic. If there are frequent updates
(inserts, deletions), the index and data file need to be reorganized.
 Limited flexibility: The index is built for a single access path (primary key), and adding multiple
secondary indexes is complex and inefficient.
 Rebuilding needed for growth: As the data file grows, the index becomes inefficient, requiring a
rebuild of both the index and the data file.

Use Case:

 ISAM is best suited for applications where data does not change frequently, and the queries
mostly involve reading records in sorted order or retrieving records based on exact matches.

2. B+ Trees

A B+ Tree is a type of self-balancing tree structure and a variant of the B-Tree. It is widely
used in modern database systems for indexing because of its efficiency in handling both range
queries and point queries.

How B+ Trees Work:

 The B+ Tree is a balanced tree structure where each node can store multiple keys and pointers.
It is designed to minimize the number of disk accesses required for data retrieval.
 The internal nodes contain only keys (which act as separators for child nodes), while the leaf
nodes store the actual data records or pointers to data.
 Leaf nodes are linked together in a linked list, allowing for efficient sequential access to the
data.
Key Features of B+ Trees:

 Balanced Structure: The B+ tree is self-balancing, meaning that all leaf nodes are at the same
level, ensuring efficient operations.
 Multi-level Indexing: Each node can store multiple keys, allowing B+ trees to index large
datasets efficiently with fewer levels.
 Range Queries: The leaf nodes are linked in a linked list, making it very efficient for range
queries (finding all records between two given keys).
 Ordered: The data in the B+ tree is stored in sorted order, enabling efficient searches, insertions,
and deletions.

Advantages of B+ Trees:

 Efficient for both range queries and point queries: B+ trees support both types of queries
efficiently because of their balanced structure and sorted order.
 Efficient for large data sets: The tree’s branching factor (the number of children each node can
have) allows it to handle large volumes of data while minimizing disk I/O.
 Dynamic: Unlike ISAM, B+ trees allow dynamic insertions and deletions without requiring a
rebuild of the entire structure.
 Optimized for disk access: The tree structure is designed to minimize the number of disk
accesses needed to retrieve data, which is crucial for large databases.

Disadvantages of B+ Trees:

 Complex structure: B+ trees are more complex to implement than ISAM due to the balancing
and the need to maintain linked lists at the leaf level.
 Higher storage overhead: Because the internal nodes only store keys (not data), the number of
nodes and pointers can increase, resulting in higher storage costs.

Use Case:

 B+ trees are commonly used in relational database management systems (RDBMS), file
systems, and other applications where fast retrieval of large datasets is required. They are
especially suitable for applications with frequent insertions, deletions, and queries that involve
both point queries and range queries.

Comparison Between ISAM and B+ Trees

Feature ISAM B+ Trees

Index Structure Static, non-dynamic Dynamic, self-balancing

Dense index and sequential data Multi-level index and sorted leaf
Storage
file nodes
 Feature ISAM B+ Trees

Efficient for both range and point

Efficiency Efficient for range queries
queries

Handling of Handles insertions and deletions

Requires rebuild of index and file
Insertions/Deletions efficiently

Performance for Range Excellent (leaf nodes are linked for fast
Good (sequential data access)
Queries range access)

Performance for Point

Good for exact-match queries Excellent for exact-match queries
Queries

Complexity Simple to implement More complex to implement

Best for static datasets with Best for dynamic datasets with
Use Case
infrequent updates frequent updates

Conclusion

 ISAM is a simple and effective indexing technique, but it suffers from inefficiencies when dealing
with large datasets that change frequently. It is suitable for applications with stable data that do
not require frequent updates.
 B+ Trees, on the other hand, are a more modern and flexible indexing method that is capable of
handling large volumes of data with dynamic updates. They are highly efficient for both point
and range queries, making them the preferred choice in most modern database systems.

The choice between ISAM and B+ Trees depends on the application’s specific needs,
particularly the frequency of data updates and the types of queries being executed.

Static Hashing, Extendable Hashing, and Linear Hashing in Database

Management Systems

Hashing is an indexing technique that uses a hash function to map a key to a specific location in
an index or data file, facilitating fast data retrieval. However, hashing methods need to handle
issues such as collisions (when two different keys hash to the same location) and growth (when
the number of records exceeds the capacity of the hash table). Three common types of hashing
are Static Hashing, Extendable Hashing, and Linear Hashing, each designed to address
different challenges in hash-based indexing.
1. Static Hashing

Static Hashing refers to the simplest form of hashing, where a hash function is applied to the
key to determine the location in the hash table. The size of the hash table is fixed at the time of
creation, and the structure does not adapt to changes in the dataset size.

How Static Hashing Works:

 A hash function is applied to a key to generate a hash value, which is then mapped to a specific
location in the hash table.
 The hash table is of fixed size, meaning it can store only a predefined number of records.
 Each location in the table may store one record (or a bucket can hold multiple records if
collisions occur).

Challenges in Static Hashing:

 Fixed Size: Once the hash table is created, its size cannot be changed. If the number of records
grows beyond the table’s capacity, the table becomes overloaded, and performance degrades.
 Collision Handling: If two records hash to the same location (a collision), methods like chaining
(linked lists) or open addressing (finding the next available slot) are used to resolve it.

Advantages:

 Simple Implementation: Static hashing is easy to implement and understand.

 Efficient for Small, Stable Datasets: It is effective for datasets where the number of records
does not change significantly.

Disadvantages:

 Inflexibility: Static hashing is not scalable since the size of the hash table cannot grow to
accommodate more records.
 Inefficient for Large Datasets: If the data grows beyond the capacity, resizing the table is
required, which can be costly in terms of time and storage.

2. Extendable Hashing

Extendable Hashing is a dynamic hashing technique designed to handle the growing number of
records more efficiently than static hashing. It allows the hash table to grow dynamically as
more records are inserted, and it can handle collisions more effectively.

How Extendable Hashing Works:

 Directory Structure: Extendable hashing uses a directory that maps hash values to actual data
storage locations. The directory stores pointers to buckets where data is stored.
  Buckets: Each bucket contains a group of records, and the directory maps hash values to these
buckets.
 Dynamic Growth: When the number of records increases and a bucket overflows, the hash table
doubles in size, and the hash function is applied to more bits of the key. This expands the
directory and redistributes the records to maintain balance.

Key Features of Extendable Hashing:

 Directory Expansion: When the hash table overflows, the directory grows dynamically (typically
doubling in size) to accommodate more records. This allows for efficient storage of increasing
datasets.
 Bucket Splitting: When a bucket overflows, it is split into two, and the directory is updated to
reflect the new structure. The records are redistributed between the two new buckets.
 Bucket Indexing: The hash function can be applied progressively (using more bits of the hash
value), which helps in redistributing records.

Advantages of Extendable Hashing:

 Dynamic Resizing: The hash table grows as needed, making it suitable for applications with
growing data.
 Efficient for Collisions: Extendable hashing handles collisions effectively by splitting buckets and
dynamically expanding the hash table.

Disadvantages:

 Complexity: The directory structure and bucket splitting introduce complexity in

implementation and maintenance.
 Directory Overhead: As the directory expands, it requires additional memory, which can lead to
overhead in terms of space.

3. Linear Hashing

Linear Hashing is another dynamic hashing technique that allows the hash table to grow as the
data increases but uses a different approach to manage the expansion. Unlike extendable hashing,
where the entire directory grows when a bucket overflows, linear hashing grows the hash table
incrementally, one bucket at a time.

How Linear Hashing Works:

 Hash Function: Initially, the hash table is created with a specific number of buckets, and a hash
function is applied to the key to determine the appropriate bucket.
 Incremental Expansion: When a bucket overflows, the hash table is incrementally expanded by
adding one more bucket at a time. This is done by applying a new hash function to some of the
records.
  Split Phase: When an overflow occurs, the records in a bucket are redistributed between the
current bucket and a newly created bucket. The expansion of the hash table happens in a linear
fashion, one bucket at a time.
 Overflow Handling: Linear hashing allows for overflow handling by creating new buckets as
needed without completely reorganizing the existing table.

Key Features of Linear Hashing:

 Incremental Growth: The hash table grows one bucket at a time, making it more gradual and
less resource-intensive than other dynamic hashing methods.
 Resizing: When the number of records exceeds the table's capacity, new buckets are added, and
records are redistributed progressively.

Advantages of Linear Hashing:

 Gradual Expansion: Linear hashing expands the hash table incrementally, which avoids the
overhead of large-scale resizing.
 Efficient Overflow Handling: Overflowed records are redistributed without requiring the entire
hash table to be reorganized.
 Scalability: It is well-suited for applications where the dataset grows steadily and requires
dynamic expansion.

Disadvantages:

 Non-Uniform Bucket Distribution: As buckets are split one by one, some parts of the hash table
may remain underutilized while others become overloaded.
 Complexity: The need to manage and apply new hash functions incrementally makes linear
hashing more complex to implement than static hashing.

Comparison Between Static Hashing, Extendable Hashing, and Linear Hashing

Feature Static Hashing Extendable Hashing Linear Hashing

Fixed size, must be Directory doubles in size

Resizing Expands one bucket at a time
rebuilt when full dynamically

Handling Chaining or open Bucket splitting and Bucket splitting and linear
Collisions addressing directory expansion growth

Efficient for small, stable Efficient for dynamic Efficient for large, growing
Efficiency
datasets datasets datasets

Simple, easy to More complex due to More complex due to

Complexity
implement directory expansion incremental splitting

Overhead Low Higher due to directory Moderate, as only one bucket

 Feature Static Hashing Extendable Hashing Linear Hashing

structure grows at a time

Gradual data growth with

Best Use Case Small, stable data sets Large dynamic datasets
incremental expansion

Conclusion

 Static Hashing is simple and effective for small, stable datasets but lacks flexibility when the
dataset grows.
 Extendable Hashing allows for dynamic resizing and handles growing datasets efficiently, but it
involves complexity due to the directory structure and bucket splitting.
 Linear Hashing provides a more gradual and incremental approach to resizing, making it well-
suited for applications with steady growth and moderate expansion.

Each of these hashing techniques offers advantages depending on the application’s requirements
for performance, complexity, and scalability.