diff --git a/app/components/subjects.tsx b/app/components/subjects.tsx index 724b848..87979d3 100644 --- a/app/components/subjects.tsx +++ b/app/components/subjects.tsx @@ -125,7 +125,7 @@ const subjectCodes: Record = { }; // Available subjects -const available = ["ep", "c", "em1", "em2", "oops", "dsc", "coa", "os", "ml", "dops", "cd", "cle","ec"]; +const available = ["ep", "c", "em1", "em2", "oops", "dsc", "coa", "os", "ml", "dops", "cd", "cle","ec","dbms"]; export default function SubjectsSection() { return ( diff --git a/app/sem4/dbms/[chapter]/page.tsx b/app/sem4/dbms/[chapter]/page.tsx index 550df44..6582cf0 100644 --- a/app/sem4/dbms/[chapter]/page.tsx +++ b/app/sem4/dbms/[chapter]/page.tsx @@ -4,9 +4,9 @@ import { Ch1Content } from "../content/chapter1"; import { Ch2Content } from "../content/chapter2"; import { Ch3Content } from "../content/chapter3"; import BookmarkButton from "../../../components/BookmarkButton"; -// import { Ch4Content } from "../content/chapter4"; -// import { Ch5Content } from "../content/chapter5"; -// import { Ch6Content } from "../content/chapter6"; +import { Ch4Content } from "../content/chapter4"; +import { Ch5Content } from "../content/chapter5"; +import { Ch6Content } from "../content/chapter6"; // import { Ch7Content } from "../content/chapter7"; // import { Ch8Content } from "../content/chapter8"; @@ -24,19 +24,28 @@ const chapters = [ { id: "ch1", title: "Introduction to Databases", component: Ch1Content }, { id: "ch2", title: "Entity-Relationship Model", component: Ch2Content }, { id: "ch3", title: "Relational Model and SQL", component: Ch3Content }, - // { id: "ch4", title: "Normalization", component: Ch4Content }, - // { id: "ch5", title: "Transactions and Concurrency Control", component: Ch5Content }, - // { id: "ch6", title: "Indexing and Hashing", component: Ch6Content }, - // { id: "ch7", title: "Query Processing and Optimization", component: Ch7Content }, + { id: "ch4", title: "Normalization", component: Ch4Content }, + { + id: "ch5", + title: "Transactions and Concurrency Control", + component: Ch5Content, + }, + { id: "ch6", title: "Indexing and Hashing", component: Ch6Content } + // ,{ + // id: "ch7", + // title: "Query Processing and Optimization", + // component: Ch7Content, + // }, // { id: "ch8", title: "Recovery and Security", component: Ch8Content }, ]; type ChapterProps = { - params: { chapter: string }; + params: Promise<{ chapter: string }>; }; -export default function ChapterPage({ params }: ChapterProps) { - const currentIndex = chapters.findIndex((c) => c.id === params.chapter); +export default async function ChapterPage({ params }: ChapterProps) { + const { chapter: chapterId } = await params; + const currentIndex = chapters.findIndex((c) => c.id === chapterId); const chapter = chapters[currentIndex]; if (!chapter) { @@ -45,7 +54,8 @@ export default function ChapterPage({ params }: ChapterProps) { const ChapterComponent = chapter.component; const prevChapter = currentIndex > 0 ? chapters[currentIndex - 1] : null; - const nextChapter = currentIndex < chapters.length - 1 ? chapters[currentIndex + 1] : null; + const nextChapter = + currentIndex < chapters.length - 1 ? chapters[currentIndex + 1] : null; return (
@@ -58,7 +68,7 @@ export default function ChapterPage({ params }: ChapterProps) {

{chapter.title}

- +
@@ -71,7 +81,9 @@ export default function ChapterPage({ params }: ChapterProps) { Previous - ) :
} + ) : ( +
+ )} {nextChapter ? ( - ) :
} + ) : ( +
+ )}
@@ -100,7 +114,9 @@ export default function ChapterPage({ params }: ChapterProps) { {prevChapter.title} - ) :
} + ) : ( +
+ )} {nextChapter ? ( - ) :
} + ) : ( +
+ )}
); -} \ No newline at end of file +} diff --git a/app/sem4/dbms/components/sidebar.tsx b/app/sem4/dbms/components/sidebar.tsx index d958623..d0d2089 100644 --- a/app/sem4/dbms/components/sidebar.tsx +++ b/app/sem4/dbms/components/sidebar.tsx @@ -25,9 +25,9 @@ export default function Sidebar() { { id: "ch1", title: "Introduction to Databases" }, { id: "ch2", title: "Entity-Relationship Model" }, { id: "ch3", title: "Relational Model and SQL" }, - // { id: "ch4", title: "Normalization" }, - // { id: "ch5", title: "Transactions and Concurrency Control" }, - // { id: "ch6", title: "Indexing and Hashing" }, + { id: "ch4", title: "Normalization" }, + { id: "ch5", title: "Transactions and Concurrency Control" }, + { id: "ch6", title: "Indexing and Hashing" }, // { id: "ch7", title: "Query Processing and Optimization" }, // { id: "ch8", title: "Recovery and Security" }, ]; diff --git a/app/sem4/dbms/content/chapter0.tsx b/app/sem4/dbms/content/chapter0.tsx index 044002b..3d393cb 100644 --- a/app/sem4/dbms/content/chapter0.tsx +++ b/app/sem4/dbms/content/chapter0.tsx @@ -16,11 +16,14 @@ export const Ch0Content = () => {
  • What is a database and why we need it
    • -
  • File system vs database approach
    • +
  • File system vs database approach — comparison table
  • Advantages of DBMS over file systems
    • -
  • Types of databases: relational, hierarchical, network, object-oriented
    • -
  • Database users: end users, application programmers, DBA
    • -
  • DBMS architecture: 1-tier, 2-tier, 3-tier
    • +
  • Types of databases: relational, hierarchical, network, object-oriented, object-relational
    • +
  • Data models: relational, ER, object-based, network, hierarchical
    • +
  • Database users: naïve, sophisticated, application programmers, DBA, designers
    • +
  • DBMS architecture: 1-tier, 2-tier, 3-tier; three-schema (external/conceptual/internal)
    • +
  • Structure of DBMS: query processor, storage manager, disk storage components
    • +
  • Database design steps: requirements → conceptual → logical → schema refinement → physical → security
@@ -31,12 +34,14 @@ export const Ch0Content = () => { Module II: Entity-Relationship Model
    -
  • Entities, attributes, and relationships
    • -
  • Types of attributes: simple, composite, multivalued, derived
    • +
  • Entities, attributes, and relationships — ER diagram notation
    • +
  • Types of attributes: simple, composite, multivalued, derived, single-valued
  • Cardinality: one-to-one, one-to-many, many-to-many
  • Participation constraints: total and partial
    • -
  • ER diagram notation and conventions
    • -
  • Extended ER features: specialization, generalization, aggregation
    • +
  • Strong vs weak entities; identifying relationships
    • +
  • Relationship types: binary, recursive (unary), ternary
    • +
  • Extended ER: ISA hierarchies, specialization, generalization, aggregation
    • +
  • Conceptual design choices: entity vs attribute, entity vs relationship, binary vs ternary
@@ -47,12 +52,17 @@ export const Ch0Content = () => { Module III: Relational Model and SQL
    -
  • Relational model: tables, tuples, attributes, domains
    • -
  • Keys: primary, candidate, foreign, super key
    • -
  • Relational algebra operations
    • -
  • SQL basics: DDL, DML, DCL, TCL
    • -
  • Joins: inner, outer, natural, cross
    • -
  • Subqueries, views, and aggregation functions
    • +
  • Relational model: tables, tuples, attributes, domains, cardinality, degree
    • +
  • Keys: primary, candidate, foreign, super, composite, alternate, unique
    • +
  • Integrity constraints: domain, entity, referential, key constraints (NULL, NOT NULL, CHECK)
    • +
  • SQL data types: string (CHAR, VARCHAR), numeric (INT, FLOAT, DECIMAL), date/time
    • +
  • DDL: CREATE, ALTER, DROP, TRUNCATE — DML: SELECT, INSERT, UPDATE, DELETE
    • +
  • Querying: WHERE, ORDER BY, GROUP BY, HAVING, LIMIT
    • +
  • Joins: inner, outer (left/right/full), natural, cross
    • +
  • Relational algebra: σ, π, ∪, ∩, −, ×, ⋈
    • +
  • Subqueries, views — creating, using, and destroying
    • +
  • Foreign key violation handling: CASCADE, SET NULL, SET DEFAULT, NO ACTION
    • +
  • Transactions and constraints: DEFERRED vs IMMEDIATE constraint checking
@@ -60,15 +70,15 @@ export const Ch0Content = () => {

- Module IV: Normalization + Module IV: Normalization / Schema Refinement

    -
  • Functional dependencies and their types
  • Anomalies: insertion, deletion, update
    • +
  • Functional dependencies: full, partial, transitive; Armstrong's axioms
  • Normal forms: 1NF, 2NF, 3NF, BCNF
  • Decomposition: lossless join and dependency preservation
    • -
  • Multivalued dependencies and 4NF
    • -
  • Practical approach to normalization
    • +
  • Multi-valued dependencies and 4NF
    • +
  • Join dependencies and 5NF (Project-Join Normal Form)
@@ -80,17 +90,21 @@ export const Ch0Content = () => {
  • Transaction concept and ACID properties
    • -
  • Transaction states: active, partially committed, committed, failed, aborted
    • -
  • Concurrency problems: lost update, dirty read, unrepeatable read
    • -
  • Concurrency control techniques: locking, timestamps
    • -
  • Two-phase locking protocol
    • -
  • Deadlock detection and recovery
    • +
  • Transaction states: active → partially committed → committed / failed → aborted → terminated
    • +
  • Schedules: serial, non-serial, serializable (conflict and view)
    • +
  • Recoverability: irrecoverable, recoverable, cascadeless, strict schedules
    • +
  • Isolation levels: read uncommitted, read committed, repeatable read, serializable
    • +
  • Lock-based protocols: simplistic, pre-claiming, 2PL, strict-2PL
    • +
  • Timestamp-based protocols: basic TO, Thomas's write rule
    • +
  • Validation-based protocol; multiple granularity and intention locks
    • +
  • Recovery: log-based (deferred/immediate), checkpoints, ARIES algorithm
    • +
  • Database backup: full, incremental, differential
-
+

Module VI: Indexing and Hashing

@@ -141,9 +155,9 @@ export const Ch0Content = () => {

By the end of this course, you will understand how to design databases, write efficient SQL queries, normalize data, manage transactions, and - handle indexing and recovery — providing a strong foundation for + handle concurrency and recovery — providing a strong foundation for real-world database development and system design.

); -}; +}; \ No newline at end of file diff --git a/app/sem4/dbms/content/chapter1.tsx b/app/sem4/dbms/content/chapter1.tsx index 30ab5f7..badbd76 100644 --- a/app/sem4/dbms/content/chapter1.tsx +++ b/app/sem4/dbms/content/chapter1.tsx @@ -3,8 +3,8 @@ export const Ch1Content = () => {

This chapter covers the fundamental concepts of database systems — what - they are, why they exist, how they compare to file systems, and the - basic architecture of a DBMS. + they are, why they exist, how they evolved historically, how they + compare to file systems, the structure of a DBMS, and who uses it.

@@ -14,17 +14,29 @@ export const Ch1Content = () => { What is a Database?
    -
  • A database is an organized collection of related data stored and accessed electronically.
    • -
  • Data represents real-world information — student records, bank transactions, product inventory.
    • -
  • A DBMS (Database Management System) is software that manages and controls access to the database.
    • -
  • Examples of DBMS: MySQL, PostgreSQL, Oracle, MongoDB.
    • +
  • + A database is an organized collection of related data that describes + the activities of one or more organizations. +
    • +
  • + It stores both entities{" "} + (students, courses, faculty) and{" "} + relationships between them + (enrollment, teaching). +
    • +
  • + A DBMS (Database Management + System) is software that manages and controls access to the + database. +
    • +
  • Examples: MySQL, PostgreSQL, Oracle, MongoDB, MS SQL Server.

Real-world Example

{`University DB
-Tables: Students, Courses, Enrollments, Professors
+Tables: Students, Courses, Enrollments, Faculty
 Student Zubair (ID: 101) is enrolled in DBMS (CS401)
-taught by Prof. Sharma.`}
+taught by Prof. Sharma in Room 301.`}
@@ -32,17 +44,54 @@ taught by Prof. Sharma.`}

- File System vs DBMS + Brief History of DBMS

    -
  • Before DBMS, data was stored in flat files managed by the OS.
    • -
  • Data Redundancy: the same data repeated in multiple files.
    • -
  • Data Inconsistency: updating one file does not update others.
    • -
  • Data Isolation: data scattered in different formats, hard to access together.
    • -
  • DBMS solves all three by centralizing data and enforcing rules.
    • +
  • + Early computers used flat files and manual records — difficult to + search or update. +
    • +
  • + Late 1960s: IBM developed IMS{" "} + (Information Management System), based on the hierarchical model. +
    • +
  • + 1970: Edgar Codd at IBM + proposed the{" "} + relational data model — still + the dominant paradigm. +
    • +
  • + 1980s: Relational model consolidated; database systems gained + widespread use. +
    • +
  • + Late 1980s: SQL standardized; SQL:1999 adopted by ANSI and ISO. +
    • +
  • + Modern era: Data warehouses, NoSQL systems, and cloud databases + emerged. +
+
+ +
+ +
+

+ File System vs DBMS +

+ File system vs DBMS
-

Exam Tip: Always mention the 3 main problems of file systems — redundancy, inconsistency, and data isolation — when comparing with DBMS.

+

+ Exam Tip: Always mention the 3 core problems of file systems — + redundancy, inconsistency, and data isolation — when comparing with + DBMS. +

@@ -53,12 +102,36 @@ taught by Prof. Sharma.`} Advantages of DBMS
    -
  • Reduced Redundancy: data is stored once and shared.
    • -
  • Data Consistency: changes reflect everywhere automatically.
    • -
  • Data Integrity: constraints ensure data accuracy.
    • -
  • Data Security: access control limits who can read or modify data.
    • -
  • Concurrent Access: multiple users can safely access data at the same time.
    • -
  • Backup and Recovery: DBMS provides tools to recover from failures.
    • +
  • + Data Independence: abstract + view of data hides storage details from users. +
    • +
  • + Efficient Data Access:{" "} + sophisticated techniques for storing and retrieving data. +
    • +
  • + Data Integrity and Security:{" "} + constraints and access controls ensure accuracy and privacy. +
    • +
  • + + Concurrent Access & Crash Recovery: + {" "} + schedules access safely; protects from failures. +
    • +
  • + + Reduced Application Development Time: + {" "} + high-level interface speeds up development. +
    • +
  • + + Centralized Data Administration: + {" "} + DBA manages data shared by multiple users. +
@@ -66,17 +139,50 @@ taught by Prof. Sharma.`}

- Types of Databases + Data Models

    -
  • Relational: data in tables with rows and columns. Example: MySQL, PostgreSQL.
    • -
  • Hierarchical: tree-like structure. Example: IBM IMS.
    • -
  • Network: graph structure with multiple parent-child relationships.
    • -
  • Object-Oriented: stores objects like in OOP. Example: db4o.
    • -
  • NoSQL: designed for unstructured data at scale. Example: MongoDB, Redis.
    • +
  • + A data model is a collection + of high-level constructs that hide low-level storage details. +
    • +
  • + Relational Model: data in + tables (relations) with rows and columns. Foundation of SQL. + Example: MySQL, PostgreSQL. +
    • +
  • + + Entity-Relationship (ER) Model: + {" "} + high-level visual model — entities, attributes, and relationships. + Used for database design. +
    • +
  • + Object-Oriented Model: data + and relationships stored in objects (like OOP). Can store audio, + video, images. +
    • +
  • + Object-Relational Model:{" "} + hybrid of relational and OO — supports complex data types. +
    • +
  • + Hierarchical Model: first + DBMS model; tree structure with one parent per child. Example: IBM + IMS. +
    • +
  • + Network Model: extension of + hierarchical — a record can have multiple parents; uses a graph. + More flexible than hierarchical. +
-

Most university syllabi focus on relational databases. NoSQL is mentioned for awareness.

+

+ Most university syllabi focus on the relational model. Hierarchical + and network models are historical context. +

@@ -84,58 +190,125 @@ taught by Prof. Sharma.`}

- Database Users + + Three-Schema Architecture (Levels of Data Abstraction) +

    -
  • End Users: interact with the database through applications.
    • -
  • Application Programmers: write programs to access the database.
    • -
  • DBA (Database Administrator): manages performance, security, and backups.
    • -
  • Data Analysts: query the database to generate reports and insights.
    • +
  • + DBMS separates how data is stored from how users see it via 3 + levels. +
    • +
  • + Physical Level (Internal):{" "} + how data is physically stored on disk — file structures, indexes. +
    • +
  • + Logical Level (Conceptual):{" "} + what data is stored and the relationships — tables, constraints. + Programmers work here. +
    • +
  • + View Level (External): what + individual users or applications see — customized views for + different user groups. +
    • +
  • + This separation is called{" "} + Data Independence. +
-
-

Who does what?

- 
{`End User   → Uses a form to register for a course
-App Dev    → Writes INSERT INTO enrollments...
-DBA        → Creates tables, grants permissions, monitors performance`}
+
+

+ Physical independence = change storage without changing logic. + Logical independence = change logic without changing user views. +

+ Multi-level DBMS Architecture

- Three-Schema Architecture + Structure of DBMS

    -
  • DBMS uses a 3-level architecture to separate storage from how users see data.
    • -
  • Internal Level: how data is physically stored on disk.
    • -
  • Conceptual Level: the logical structure — tables, relationships, constraints.
    • -
  • External Level: what individual users or applications see (views).
    • -
  • This separation is called Data Independence.
    • +
  • + A DBMS is divided into two main components:{" "} + Query Processor and{" "} + Storage Manager. +
    • +
  • + Query Processor components:{" "} + DML Compiler (compiles DML to machine instructions), DDL Interpreter + (processes DDL into metadata tables), Embedded DML Pre-compiler, + Query Optimizer (executes optimized plan). +
    • +
  • + Storage Manager components:{" "} + Authorization Manager (role-based access), Integrity Manager (checks + constraints), Transaction Manager (concurrency control), File + Manager (manages file space), Buffer Manager (cache and memory + transfer). +
    • +
  • + Disk Storage: Data Files + (actual data), Data Dictionary (metadata/schema info), Indices + (faster retrieval). +
-
-

Physical independence = change storage without changing logic. Logical independence = change logic without changing user views.

-

- DBMS Languages + Types of Database Users

    -
  • DDL (Data Definition Language): define structure. Example: CREATE, ALTER, DROP.
    • -
  • DML (Data Manipulation Language): manipulate data. Example: INSERT, UPDATE, DELETE, SELECT.
    • -
  • DCL (Data Control Language): access control. Example: GRANT, REVOKE.
    • -
  • TCL (Transaction Control Language): manage transactions. Example: COMMIT, ROLLBACK.
    • +
  • + Naïve / Parametric Users: no + database knowledge; use pre-built applications. Example: bank + tellers, ticket booking users. +
    • +
  • + Sophisticated Users:{" "} + engineers, scientists, analysts — interact with DB but don't write + programs. +
    • +
  • + Application Programmers:{" "} + write programs using DML to access the database. +
    • +
  • + System Analysts: analyze + requirements of end users. +
    • +
  • + Database Designers: design + the appropriate schema structure. +
    • +
  • + DBA (Database Administrator):{" "} + superuser — defines schema, security, backup, recovery, monitors + performance. +
    • +
  • + Casual / Temporary Users:{" "} + access the database infrequently. +
-

Quick Examples

- 
{`DDL: CREATE TABLE students (id INT PRIMARY KEY, name VARCHAR(50));
-DML: INSERT INTO students VALUES (1, 'Zubair');
-DCL: GRANT SELECT ON students TO user1;
-TCL: COMMIT;`}
+

Who does what?

+ 
{`Naïve User      → Uses a form to register for a course
+App Programmer  → Writes INSERT INTO enrollments...
+DBA             → Creates tables, grants permissions,
+                  monitors performance, handles backups`}
@@ -143,12 +316,60 @@ TCL: COMMIT;`}

- DBMS Architecture: 1-Tier, 2-Tier, 3-Tier + Database Design Steps +

+
    +
  • + 1. Requirements Analysis:{" "} + understand what data to store, what applications to build, what + operations are frequent. +
    • +
  • + 2. Conceptual Design:{" "} + high-level ER diagram of data and constraints. +
    • +
  • + 3. Logical Design: convert ER + diagram to relational schema in chosen DBMS. +
    • +
  • + 4. Schema Refinement:{" "} + normalize relations to eliminate redundancy and anomalies. +
    • +
  • + 5. Physical Design: tune for + performance — indexes, partitions, storage structures. +
    • +
  • + + 6. Application & Security Design: + {" "} + design application code, access controls, and security policies. +
    • +
+
+ +
+ +
+

+ + DBMS Architecture: 1-Tier, 2-Tier, 3-Tier +

    -
  • 1-Tier: database and application on the same machine. Used for personal/local databases.
    • -
  • 2-Tier: client communicates directly with the database server.
    • -
  • 3-Tier: a middle application server sits between client and database. Used in web apps.
    • +
  • + 1-Tier: database and + application on the same machine. Used for personal/local databases. +
    • +
  • + 2-Tier: client communicates + directly with the database server. +
    • +
  • + 3-Tier: middle application + server sits between client and database. Standard for web apps. +

3-Tier Example

@@ -161,4 +382,4 @@ Database Server (MySQL / PostgreSQL)`}
); -}; \ No newline at end of file +}; diff --git a/app/sem4/dbms/content/chapter2.tsx b/app/sem4/dbms/content/chapter2.tsx index 810c554..cd74908 100644 --- a/app/sem4/dbms/content/chapter2.tsx +++ b/app/sem4/dbms/content/chapter2.tsx @@ -15,11 +15,16 @@ export const Ch2Content = () => { What is the ER Model?
    -
  • The ER Model is a blueprint for designing a database before coding.
    • -
  • It helps translate real-world requirements into a visual diagram.
    • +
  • A blueprint for designing a database — translates real-world requirements into a visual diagram.
  • Proposed by Peter Chen in 1976.
  • The ER Diagram (ERD) is later converted into relational tables.
    • +
  • Makes it easy for both developers and stakeholders to understand the system structure.
+
+

ER Model notation: Entity = Rectangle, Attribute = Ellipse, Relationship = Diamond. Lines connect attributes to entities.

+
+ ER Model diagram + ER Symbols
@@ -29,13 +34,19 @@ export const Ch2Content = () => { Entities and Entity Sets
    -
  • An Entity is a real-world object — a student, a course, an employee.
    • +
  • An Entity is a real-world object distinguishable from others — a student, course, machine, event.
  • An Entity Set is a collection of similar entities — all students, all courses.
    • -
  • Strong Entity: can exist independently. Example: Student.
    • -
  • Weak Entity: depends on another entity. Example: Dependent (of an employee).
    • +
  • Strong Entity: exists independently; has its own primary key. Represented by single rectangle.
    • +
  • Weak Entity: depends on a strong entity for its existence. Has a partial key, not a full primary key. Represented by double rectangle.
    • +
  • The primary key of a weak entity = PK of strong entity + partial key of weak entity (composite).
    • +
  • The relationship between strong and weak entity is called an Identifying Relationship — shown with a double diamond.
-
-

In ER diagrams: Strong entities use a single rectangle. Weak entities use a double rectangle.

+
+

Strong vs Weak Example

+ 
{`Customer (strong) — Borrows —► Loan (weak)
+Customer has Cust_ID (primary key).
+Loan has Loan_name (partial key only).
+Loan's full key = Cust_ID + Loan_name.`}
@@ -46,14 +57,15 @@ export const Ch2Content = () => { Attributes
    -
  • Simple: cannot be divided further. Example: Age.
    • -
  • Composite: can be divided into sub-parts. Example: Name → First Name, Last Name.
    • -
  • Multivalued: can have more than one value. Example: Phone Numbers.
    • -
  • Derived: calculated from other attributes. Example: Age from Date of Birth.
    • -
  • Key Attribute: uniquely identifies each entity. Example: Student ID.
    • +
  • Simple: atomic — cannot be divided. Example: Age, City.
    • +
  • Composite: made of sub-parts. Example: Name → First Name + Last Name; Address → House No + Street + Pin.
    • +
  • Multivalued: can hold multiple values. Example: Phone Numbers, College Degrees. Shown with double ellipse.
    • +
  • Derived: calculated from other attributes. Example: Age from Date of Birth. Shown with dashed ellipse.
    • +
  • Key Attribute: uniquely identifies each entity. Example: Student ID. Shown underlined.
    • +
  • Single-valued: holds exactly one value. Example: Customer ID, City.
-

In ERD: Multivalued = double ellipse. Derived = dashed ellipse. Key attribute = underlined.

+

ERD quick reference — Multivalued = double ellipse. Derived = dashed ellipse. Key attribute = underlined. Composite = ellipse with child ellipses.

@@ -61,15 +73,15 @@ export const Ch2Content = () => {

- Relationships + Relationships and Relationship Sets

    -
  • A Relationship represents an association between two or more entities.
    • -
  • Example: A Student enrolls in a Course.
    • -
  • Unary: self-referencing. Example: Employee manages Employee.
    • -
  • Binary: between two entities. Example: Student enrolls in Course.
    • -
  • Ternary: between three entities. Example: Doctor prescribes Medicine to Patient.
    • -
  • Relationships can also have attributes. Example: 'enrolls' can have a 'grade' attribute.
    • +
  • A Relationship is an association between two or more entities. Represented with a diamond.
    • +
  • A Relationship Set is a collection of similar relationships. Can have its own attributes.
    • +
  • Example: 'depositor' relationship between Customer and Account can have attribute 'access-date'.
    • +
  • Binary: between two entities. Example: Student enrolls in Course. Most common.
    • +
  • Recursive (Unary): entity relates to itself. Example: Employee manages Employee.
    • +
  • Ternary: between three entities. Example: Company produces Product in a Sector. Always analyze two at a time.
@@ -79,17 +91,82 @@ export const Ch2Content = () => {

Cardinality

-
    -
  • Cardinality defines how many entity instances participate in a relationship.
    • -
  • One-to-One (1:1): A person has one passport.
    • -
  • One-to-Many (1:N): One department has many employees.
    • -
  • Many-to-Many (M:N): A student enrolls in many courses; a course has many students.
    • -
-
+ +
+ +
+
    +
  • + One-to-One (1:1): + {" "}each entity on one side relates to exactly one on the other. + Example: One student can enroll in only one course. + Rare in real world. +
    • +
+ + One to one relationship +
+ +
+
    +
  • + One-to-Many (1:N): + {" "}one entity relates to many. + Example: An employee can have many dependents and one dependent can depend on one employee. +
    • +
+ + One to many relationship +
+ +
+
    +
  • + Many-to-One (N:1): + {" "}many relate to one. + Example: Every student can enroll only in one elective course but for an elective course there can be more than one student. +
    • +
+ + Many to one relationship +
+ +
+
    +
  • + Many-to-Many (M:N): + {" "}many relate to many. + Example: Student enrolls in many Courses; Course has many Students. +
    • +
+ + Many to many relationship +
+ +
+ +

Cardinality Notation

- 
{`1:1  →  Person ——— Passport
-1:N  →  Department ——< Employee
-M:N  →  Student >——< Course`}
+ + 
{`1:1  → EMPLOYEE  ——1—— MANAGES ——1—— DEPARTMENT
+      1:N  → EMPLOYEE  ——N—— WORKS-FOR ——1—— DEPARTMENT
+      M:N  → EMPLOYEE  ——M—— WORKS-ON ——N—— PROJECT`}
@@ -100,9 +177,10 @@ M:N → Student >——< Course`} Participation Constraints
    -
  • Total Participation: every entity must participate in the relationship. Shown with a double line.
    • +
  • Total Participation: every entity must participate in at least one relationship. Shown with a double line.
  • Partial Participation: some entities may not participate. Shown with a single line.
    • -
  • Example: Every employee must work for a department (total), but not every department must have a manager (partial).
    • +
  • Example: Every Loan must have a Customer (total — double line from Loan to Borrows). Not every Customer needs a Loan (partial — single line from Customer to Borrows).
    • +
  • Example: Every employee must manage a department is total; not every employee is a manager is partial.
@@ -113,15 +191,37 @@ M:N → Student >——< Course`} Extended ER Features
    -
  • Specialization: dividing an entity into sub-entities. Example: Employee → Manager, Engineer, Clerk. (Top-down)
    • -
  • Generalization: combining multiple entities into one. Example: Car + Truck → Vehicle. (Bottom-up)
    • -
  • Aggregation: treating a relationship as an entity to allow relationships with other entities.
    • -
  • Inheritance: sub-entities inherit attributes from the parent entity.
    • +
  • ISA Hierarchy: "A ISA B" means every A is also a B. Sub-entities inherit parent attributes.
    • +
  • Specialization: top-down — dividing an entity into sub-entities. Example: Employee → Manager, Engineer, Clerk.
    • +
  • Generalization: bottom-up — combining entities into one. Example: Car + Truck → Vehicle.
    • +
  • Aggregation: treating a relationship set as an entity, allowing relationships between relationships. Used when a relationship itself participates in another relationship.
+
+

Aggregation vs Ternary

+ 
{`Aggregation: Employee —[Monitors]—► {Projects —[Sponsors]— Departments}
+Use when the inner relationship (Sponsors) needs its own
+relationship with another entity (Monitors by Employee).
+
+Ternary: Employee —[Works_On]— Projects — Departments
+Use when all three are equally involved in one relationship.`}
+
-

Specialization is top-down. Generalization is bottom-up. Both lead to the same result in the ERD.

+

Specialization is top-down. Generalization is bottom-up. Both result in an ISA hierarchy. The choice between aggregation and ternary depends on whether a relationship needs to relate to another entity.

+ +
+ +
+

+ Conceptual Design Choices +

+
    +
  • Entity vs Attribute: if a concept has multiple values or sub-structure, model it as an entity, not an attribute. Example: Address with city/street should be an entity if you need to query by city.
    • +
  • Entity vs Relationship: if a concept connects two entities and has its own attributes, model it as a relationship. Watch out for redundancy when a relationship can replace two separate entity connections.
    • +
  • Binary vs Ternary: use ternary only when three entities are genuinely interdependent and two binary relationships would miss constraints. Use binary when two separate relationships are cleaner and more accurate.
    • +
+
); }; \ No newline at end of file diff --git a/app/sem4/dbms/content/chapter3.tsx b/app/sem4/dbms/content/chapter3.tsx index 7337aea..1343bab 100644 --- a/app/sem4/dbms/content/chapter3.tsx +++ b/app/sem4/dbms/content/chapter3.tsx @@ -16,21 +16,22 @@ export const Ch3Content = () => {
  • Data is organized in tables (relations) with rows and columns.
    • -
  • Each row is called a tuple and represents one record.
    • -
  • Each column is called an attribute and represents a property.
    • -
  • The set of allowed values for an attribute is called its domain.
    • -
  • The number of tuples in a table is called cardinality.
    • -
  • The number of attributes in a table is called degree.
    • +
  • Each row is a tuple (record). Each column is an attribute (field).
    • +
  • The set of allowed values for an attribute is its domain.
    • +
  • Cardinality: number of rows (tuples) in a table.
    • +
  • Degree (Arity): number of columns (attributes) in a table.
    • +
  • Relation Schema: specifies the relation's name, attribute names, and types. Example: Students(sid: string, name: string, age: integer, gpa: real).
    • +
  • Relation Instance: the actual data (set of tuples) at a given moment. No duplicate tuples.
-

Example Table: Students

- 
{`| ID  | Name    | Age | Dept |
-|-----|---------|-----|------|
-| 101 | Zubair  | 20  | CSE  |
-| 102 | Krishna | 21  | IT   |
-| 103 | Pushkar | 22  | CSE  |
-
-Degree = 4 (columns), Cardinality = 3 (rows)`}
+

Example: Students Relation

+ 
{`| sid   | name  | login      | age | gpa |
+|-------|-------|------------|-----|-----|
+| 53666 | Jones | jones@cs   | 18  | 3.4 |
+| 53688 | Smith | smith@ee   | 18  | 3.2 |
+| 53650 | Smith | smith@math | 19  | 3.8 |
+
+Degree = 5 (columns), Cardinality = 3 (rows)`}
@@ -43,12 +44,14 @@ Degree = 4 (columns), Cardinality = 3 (rows)`}
  • Super Key: any set of attributes that uniquely identifies a tuple.
  • Candidate Key: minimal super key — no unnecessary attributes.
    • -
  • Primary Key: the chosen candidate key used to identify tuples. Cannot be NULL.
    • -
  • Foreign Key: an attribute that references the primary key of another table. Used to link tables.
    • -
  • Composite Key: a primary key made of more than one attribute.
    • +
  • Primary Key: the chosen candidate key. Cannot be NULL. Shown underlined in schema.
    • +
  • Alternate Key: candidate keys not chosen as primary key.
    • +
  • Foreign Key: references the primary key of another table. Used to link tables and enforce referential integrity.
    • +
  • Composite Key: primary key made of two or more attributes.
    • +
  • Unique Key: like primary key but allows NULL values.
-

Exam Tip: Every primary key is a candidate key, and every candidate key is a super key — but not the other way around.

+

Hierarchy: Primary Key ⊂ Candidate Key ⊂ Super Key. Every PK is a CK, every CK is a super key — not vice versa.

@@ -56,51 +59,126 @@ Degree = 4 (columns), Cardinality = 3 (rows)`}

- Relational Algebra + Integrity Constraints

    -
  • Select (σ): filters rows based on a condition. Example: σ(Dept='CSE')(Students).
    • -
  • Project (π): selects specific columns. Example: π(Name, Age)(Students).
    • -
  • Union (∪): combines tuples from two relations (removes duplicates).
    • -
  • Intersection (∩): returns tuples common to both relations.
    • -
  • Difference (−): returns tuples in one relation but not the other.
    • -
  • Cartesian Product (×): combines every tuple of one relation with every tuple of another.
    • -
  • Join (⋈): combines related tuples from two relations based on a condition.
    • +
  • Domain Constraint: each attribute value must belong to its defined domain (data type and size). Example: age must be an integer, name must be VARCHAR(50).
    • +
  • Entity Integrity: primary key cannot be NULL. Every tuple must be uniquely identifiable.
    • +
  • Referential Integrity: foreign key value must match an existing primary key in the referenced table (or be NULL).
    • +
  • Key Constraints: NOT NULL (attribute must have a value), CHECK (value must satisfy a condition), UNIQUE (no duplicates).
+
+

Constraint Examples

+ 
{`CREATE TABLE Students (
+  sid   INT PRIMARY KEY,         -- entity integrity
+  name  VARCHAR(50) NOT NULL,    -- key constraint
+  age   INT CHECK (age > 0),     -- domain + check
+  gpa   FLOAT DEFAULT 0.0
+);
+
+CREATE TABLE Enrolled (
+  studid INT,
+  cid    VARCHAR(20),
+  grade  VARCHAR(5),
+  PRIMARY KEY (studid, cid),
+  FOREIGN KEY (studid) REFERENCES Students(sid)
+  ON DELETE CASCADE ON UPDATE NO ACTION
+);`}
+
+
+ +
+ +
+

+ Foreign Key Violation Handling +

+
    +
  • NO ACTION (default): reject the delete/update that would violate referential integrity.
    • +
  • CASCADE: when parent row is deleted/updated, automatically delete/update all child rows that reference it.
    • +
  • SET NULL: set the foreign key in child rows to NULL when parent is deleted.
    • +
  • SET DEFAULT: set foreign key to a default value when parent is deleted.
    • +
+
+

If a Students row is deleted, CASCADE deletes all Enrolled rows for that student. SET NULL would set studid to NULL — only valid if studid is not part of the primary key.

+

- SQL Basics + SQL Data Types

    -
  • DDL: CREATE, ALTER, DROP, TRUNCATE.
    • -
  • DML: SELECT, INSERT, UPDATE, DELETE.
    • -
  • DCL: GRANT, REVOKE.
    • -
  • TCL: COMMIT, ROLLBACK, SAVEPOINT.
    • +
  • String: CHAR(n) — fixed length; VARCHAR(n) — variable length up to n chars; BINARY(n) — binary byte strings.
    • +
  • Numeric: TINYINT, SMALLINT, INT, BIGINT, FLOAT(p), DOUBLE, DECIMAL(size, d).
    • +
  • Date/Time: DATE (YYYY-MM-DD), DATETIME (YYYY-MM-DD hh:mm:ss), TIMESTAMP, TIME, YEAR.
    • +
  • Boolean: BOOL / BOOLEAN — 0 is false, nonzero is true.
    • +
+
+ +
+ +
+

+ SQL Commands +

+
    +
  • DDL (Data Definition Language): CREATE, ALTER, DROP, TRUNCATE, RENAME, COMMENT.
    • +
  • DML (Data Manipulation Language): SELECT, INSERT, UPDATE, DELETE, MERGE.
    • +
  • DCL (Data Control Language): GRANT (give access), REVOKE (remove access).
    • +
  • TCL (Transaction Control Language): COMMIT, ROLLBACK, SAVEPOINT, SET TRANSACTION.

Basic SQL Examples

- 
{`-- Create table
-CREATE TABLE students (
-  id   INT PRIMARY KEY,
-  name VARCHAR(50),
-  dept VARCHAR(20)
-);
+          
{`-- DDL
+CREATE TABLE students (id INT PRIMARY KEY, name VARCHAR(50), dept VARCHAR(20));
+ALTER TABLE students ADD COLUMN gpa FLOAT;
+DROP TABLE students;
 
--- Insert data
+-- DML
 INSERT INTO students VALUES (101, 'Zubair', 'CSE');
-
--- Query data
 SELECT name, dept FROM students WHERE dept = 'CSE';
-
--- Update data
 UPDATE students SET dept = 'IT' WHERE id = 101;
+DELETE FROM students WHERE id = 101;
+
+-- DCL
+GRANT SELECT ON students TO user1;
+REVOKE SELECT ON students FROM user1;
+
+-- TCL
+BEGIN;
+UPDATE accounts SET balance = balance - 100 WHERE id = 1;
+UPDATE accounts SET balance = balance + 100 WHERE id = 2;
+COMMIT;`}

+
+
--- Delete data -DELETE FROM students WHERE id = 101;`} +
+ +
+

+ Querying — SELECT, WHERE, ORDER BY +

+
    +
  • A query is a question about the data — the answer is a new relation (result set).
    • +
  • Basic structure: SELECT → FROM → WHERE → GROUP BY → HAVING → ORDER BY → LIMIT.
    • +
  • WHERE: filters rows based on a condition.
    • +
  • ORDER BY: sorts results ASC (default) or DESC.
    • +
  • DISTINCT: removes duplicate rows from result.
    • +
  • Aliases: rename tables or columns using AS.
    • +
+
+

Query Example

+ 
{`-- Students and their enrolled courses
+SELECT S.name, E.cid
+FROM Students AS S, Enrolled AS E
+WHERE S.sid = E.studid;
+
+-- Result:
+-- Smith | Topology112
+-- Jones | History105`}
@@ -111,20 +189,20 @@ DELETE FROM students WHERE id = 101;`} Joins
    -
  • Inner Join: returns rows that have matching values in both tables.
    • -
  • Left Outer Join: returns all rows from the left table and matched rows from the right.
    • -
  • Right Outer Join: returns all rows from the right table and matched rows from the left.
    • -
  • Full Outer Join: returns all rows when there is a match in either table.
    • +
  • Inner Join: returns rows with matching values in both tables.
    • +
  • Left Outer Join: all rows from left table + matched rows from right.
    • +
  • Right Outer Join: all rows from right table + matched rows from left.
    • +
  • Full Outer Join: all rows from both tables; NULLs where no match.
  • Natural Join: automatically joins on columns with the same name.
    • -
  • Cross Join: returns the Cartesian product of both tables.
    • +
  • Cross Join: Cartesian product — every row of A × every row of B.
+ Types of joins

Join Example

- 
{`-- Inner Join: students with their enrolled courses
-SELECT students.name, courses.title
-FROM students
-INNER JOIN enrollments ON students.id = enrollments.student_id
-INNER JOIN courses ON enrollments.course_id = courses.id;`}
+ 
{`SELECT s.name, c.title
+FROM students s
+INNER JOIN enrollments e ON s.id = e.student_id
+INNER JOIN courses c     ON e.course_id = c.id;`}
@@ -135,20 +213,17 @@ INNER JOIN courses ON enrollments.course_id = courses.id;`} Aggregate Functions and GROUP BY
    -
  • COUNT(): counts number of rows.
    • -
  • SUM(): adds up values in a column.
    • -
  • AVG(): calculates the average.
    • -
  • MAX() / MIN(): finds the highest or lowest value.
    • +
  • COUNT( ), SUM( ), AVG( ), MAX( ), MIN( ) — operate on a set of rows.
  • GROUP BY: groups rows with the same value for aggregation.
    • -
  • HAVING: filters groups (like WHERE but for aggregated results).
    • +
  • HAVING: filters groups (like WHERE but after aggregation).

Aggregate Example

- 
{`-- Count students per department
-SELECT dept, COUNT(*) AS total
+          
{`SELECT dept, COUNT(*) AS total, AVG(gpa) AS avg_gpa
 FROM students
 GROUP BY dept
-HAVING COUNT(*) > 1;`}

+HAVING COUNT(*) > 1
+ORDER BY avg_gpa DESC;`}
@@ -159,10 +234,10 @@ HAVING COUNT(*) > 1;`} Subqueries and Views
    -
  • A subquery is a query nested inside another query.
    • -
  • Subqueries can be used in SELECT, FROM, or WHERE clauses.
    • -
  • A view is a virtual table based on the result of a SELECT query.
    • -
  • Views simplify complex queries and add a layer of security.
    • +
  • A subquery is a query nested inside another. Can appear in SELECT, FROM, or WHERE.
    • +
  • A view is a virtual table based on a SELECT query. Simplifies complex queries and adds security by hiding sensitive columns.
    • +
  • Views can be created with CREATE VIEW and dropped with DROP VIEW.
    • +
  • Tables can be dropped with DROP TABLE or modified with ALTER TABLE.

Subquery and View Example

@@ -175,7 +250,52 @@ CREATE VIEW cse_students AS SELECT name, age FROM students WHERE dept = 'CSE'; -- Use the view -SELECT * FROM cse_students;`} +SELECT * FROM cse_students; + +-- Drop table / view +DROP VIEW cse_students; +DROP TABLE students;`} +
+ + +
+ +
+

+ Relational Algebra +

+
    +
  • Select (σ): filters rows. Example: σ(dept='CSE')(Students).
    • +
  • Project (π): selects columns. Example: π(name, age)(Students).
    • +
  • Union (∪): combines rows from two relations, removes duplicates. Schemas must be compatible.
    • +
  • Intersection (∩): rows common to both relations.
    • +
  • Difference (−): rows in one but not the other.
    • +
  • Cartesian Product (×): every row of A with every row of B.
    • +
  • Join (⋈): combines related rows from two relations on a condition.
    • +
+
+ +
+ +
+

+ Transactions and Constraint Checking +

+
    +
  • A transaction is a program that runs against a database, containing one or more SQL statements.
    • +
  • By default, constraints are checked immediately after each SQL statement.
    • +
  • DEFERRED mode: constraint is checked only at COMMIT time. Useful for circular foreign key references where neither table can be inserted first.
    • +
+
+

Deferred Constraint Example

+ 
{`-- Students references Courses (honors FK)
+-- Courses references Students (grader FK)
+-- Can't insert either first with IMMEDIATE checking!
+
+SET CONSTRAINT honors_fk DEFERRED;
+INSERT INTO Students VALUES (...); -- temporarily inconsistent
+INSERT INTO Courses VALUES (...);  -- restores consistency
+COMMIT; -- both FKs checked here ✓`}
diff --git a/app/sem4/dbms/content/chapter4.tsx b/app/sem4/dbms/content/chapter4.tsx index f73052d..7af56d3 100644 --- a/app/sem4/dbms/content/chapter4.tsx +++ b/app/sem4/dbms/content/chapter4.tsx @@ -2,39 +2,82 @@ export const Ch4Content = () => { return (

- Normalization is the process of - organizing a database to reduce redundancy and improve data integrity by - breaking large tables into smaller, well-structured ones. + Normalization (also called Schema Refinement) is the + process of organizing a database to reduce redundancy and improve data integrity by + decomposing large tables into smaller, well-structured ones using normal forms.

- Why Normalize? + Problems Caused by Redundancy — Anomalies

    -
  • Insertion Anomaly: cannot add data without unrelated data. Example: can't add a course unless a student is enrolled.
    • -
  • Deletion Anomaly: deleting one record accidentally removes other useful data.
    • -
  • Update Anomaly: updating one value requires changing it in many places.
    • -
  • Normalization solves all three by removing redundant data dependencies.
    • +
  • Insertion Anomaly: cannot insert new data without adding unrelated data. Example: can't add a new course unless a student is enrolled.
    • +
  • Update Anomaly: same data stored in multiple rows — updating one row leaves others stale and inconsistent.
    • +
  • Deletion Anomaly: deleting one record accidentally removes other critical data. Example: deleting a project removes the only record of an employee.
+
+

Update Anomaly Example

+ 
{`EmpID | EmpName | DeptID | DeptName
+101   | Alice   | D1     | Sales
+102   | Bob     | D1     | Sales   ← same dept stored twice
+
+If D1 renamed to "Global Sales" but only row 1 updated:
+101 | Alice | D1 | Global Sales  ← inconsistent!
+102 | Bob   | D1 | Sales
+
+Fix: Split into Employee(EmpID, EmpName, DeptID)
+     and  Department(DeptID, DeptName)`}
+

- Functional Dependency + Keys — Quick Reference

    -
  • A Functional Dependency (FD) means one attribute determines another. Written as A → B.
    • -
  • Example: StudentID → StudentName (knowing the ID tells you the name).
    • -
  • Partial Dependency: a non-key attribute depends on part of a composite primary key.
    • -
  • Transitive Dependency: a non-key attribute depends on another non-key attribute.
    • +
  • Super Key: any set of attributes that uniquely identifies a tuple.
    • +
  • Candidate Key: minimal super key — no unnecessary attributes.
    • +
  • Primary Key: chosen candidate key. Cannot be NULL.
    • +
  • Alternate Key: candidate keys not chosen as primary key.
    • +
  • Foreign Key: references the primary key of another table. Links tables.
    • +
  • Composite Key: primary key made of two or more attributes.
    • +
  • Unique Key: like a primary key but allows NULL values.
-

Exam Tip: FDs are the foundation of all normal forms. Master them first.

+

Hierarchy: Primary Key ⊂ Candidate Key ⊂ Super Key. Every PK is a CK, every CK is a super key — but not vice versa.

+
+
+ +
+ +
+

+ Functional Dependency (FD) +

+
    +
  • Written as X → Y: knowing X uniquely determines Y. "X functionally determines Y."
    • +
  • Full FD: Y depends on the entire composite key X, not any subset.
    • +
  • Partial FD: Y depends on only part of a composite key. Violates 2NF.
    • +
  • Transitive FD: X → B and B → C, so X → C indirectly. Violates 3NF.
    • +
+
+

Types of FD

+ 
{`Full FD:       {AdmissionNo, CourseID} → Fee
+               (Fee needs both — full dependency)
+
+Partial FD:    {AdmissionNo, CourseID} → CourseName
+               but CourseID alone → CourseName (partial!)
+
+Transitive FD: EmpID → DeptID → DeptName
+               ∴ EmpID → DeptName (transitive)`}
+
+
+

Armstrong's Axioms — Reflexivity: If Y⊆X then X→Y. Augmentation: X→Y implies XZ→YZ. Transitivity: X→Y and Y→Z implies X→Z.

@@ -45,21 +88,20 @@ export const Ch4Content = () => { 1NF — First Normal Form
    -
  • A table is in 1NF if every column contains atomic (indivisible) values.
    • -
  • No repeating groups or arrays in a single column.
    • -
  • Each row must be unique (has a primary key).
    • +
  • Every attribute must contain atomic (indivisible) values.
    • +
  • No repeating groups, arrays, or multi-valued cells in a single column.
    • +
  • Each row must be uniquely identifiable (has a primary key).

Violation → Fix

{`❌ Not 1NF:
-StudentID | Courses
-101       | DBMS, OS, CN
-
-✅ 1NF:
-StudentID | Course
-101       | DBMS
-101       | OS
-101       | CN`}
+SID | NAME | CONTACT NO | COURSE +1 | ROHAN | 111-111-1111,123-456-7890 | OOPS + +✅ 1NF — split multi-valued contact into two columns: +SID | NAME | CONTACT_NO1 | CONTACT_NO2 | COURSE +1 | ROHAN | 111-111-1111 | 123-456-7890 | OOPS +2 | RAVI | 222-222-3222 | NULL | OOPS`}
@@ -72,19 +114,19 @@ StudentID | Course
  • Must be in 1NF.
  • No partial dependencies — every non-key attribute must depend on the entire primary key.
    • -
  • Applies only when the primary key is composite.
    • +
  • Only applies when the primary key is composite.

Violation → Fix

- 
{`❌ Not 2NF (PK = StudentID + CourseID):
-StudentID | CourseID | StudentName | Grade
-101       | CS401    | Zubair      | A
+          
{`❌ Not 2NF (PK = SID + COURSE):
+SID | NAME  | CONTACT_NO1  | COURSE | MARKS | GRADE
+1   | ROHAN | 111-111-1111 | OOPS   | 80    | B+
 
-StudentName depends only on StudentID (partial dependency).
+NAME and CONTACT_NO1 depend only on SID — partial dependency!
 
-✅ 2NF: Split into two tables:
-Students(StudentID, StudentName)
-Enrollments(StudentID, CourseID, Grade)`}

+✅ 2NF: Decompose into two tables:
+Student(SID, NAME, CONTACT_NO1, CONTACT_NO2)
+Marks(SID, COURSE, MARKS, GRADE)`}
@@ -101,14 +143,16 @@ Enrollments(StudentID, CourseID, Grade)`}

Violation → Fix

{`❌ Not 3NF:
-StudentID | DeptID | DeptName
-101       | D01    | CSE
+SID | COURSE | MARKS | GRADE
+1   | OOPS   | 80    | B+
 
-DeptName depends on DeptID (not on StudentID) — transitive.
+FDs: {SID, COURSE} → MARKS → GRADE
+GRADE depends on MARKS (non-key) — transitive!
 
-✅ 3NF: Split:
-Students(StudentID, DeptID)
-Departments(DeptID, DeptName)`}
+✅ 3NF: Decompose: +Marks(SID, COURSE, MARKS) +MarksGrade(LOMARKS, HIMARKS, GRADE) + e.g. 80-84 → B+, 85-89 → A, 90-100 → A+`}
@@ -119,12 +163,24 @@ Departments(DeptID, DeptName)`} BCNF — Boyce-Codd Normal Form
    -
  • A stricter version of 3NF.
    • -
  • For every FD A → B, A must be a superkey.
    • -
  • Handles cases where 3NF still has anomalies due to overlapping candidate keys.
    • +
  • Stricter version of 3NF.
    • +
  • For every FD X → Y, X must be a superkey.
    • +
  • Handles anomalies that 3NF misses when there are overlapping candidate keys.
    • +
  • BCNF decomposition always gives lossless joins but may lose dependency preservation.
+
+

BCNF Violation → Fix

+ 
{`Table: StudentID | CourseID | InstructorID | InstructorName
+
+FDs: StudentID → all attributes (StudentID is superkey ✅)
+     InstructorID → InstructorName (InstructorID NOT superkey ❌)
+
+✅ BCNF: Split into:
+StudentCourse(StudentID, CourseID, InstructorID)
+Instructor(InstructorID, InstructorName)`}
+
-

If a table is in BCNF, it is also in 3NF — but not vice versa. BCNF is stronger.

+

If a table is in BCNF it is also in 3NF — but not vice versa. BCNF is stronger.

@@ -132,14 +188,104 @@ Departments(DeptID, DeptName)`}

- Decomposition + Decomposition — Lossless Join

    -
  • Lossless Join: splitting a table and rejoining gives back the original data exactly.
    • -
  • Dependency Preservation: all original FDs can still be checked in the decomposed tables.
    • -
  • BCNF decomposition always gives lossless joins but may lose dependency preservation.
    • +
  • Lossless Join: joining decomposed tables gives back the original data exactly — no spurious (fake) tuples.
    • +
  • Lossy Join: the join produces extra tuples not in the original — information is lost.
    • +
  • Condition for lossless: R1 ∩ R2 must be a superkey in R1 or R2.
    • +
  • Dependency Preservation: all original FDs can still be checked without joining tables.
  • 3NF decomposition preserves both lossless join and dependency preservation.
    • +
  • BCNF decomposition always gives lossless join but may sacrifice dependency preservation.
+
+

Lossless Join Check

+ 
{`R(A, B, C) with FDs: A→B, B→C
+Decompose into R1(A,B) and R2(B,C)
+
+Common attribute: B
+Is B a superkey in R2(B,C)? YES (B→C)
+∴ Lossless decomposition ✅
+
+Lossy example — joining on StuName instead of StuID:
+generates spurious rows like (Alice, MTH101, Calculus)
+even though Alice never enrolled in Calculus ❌`}
+
+
+ +
+ +
+

+ Multi-Valued Dependency (MVD) and 4NF +

+
    +
  • An MVD (written X →→ Y) exists when X determines a set of values for Y, independently of other attributes.
    • +
  • Occurs when a table has more than one independent one-to-many relationship.
    • +
  • 4NF: must be in BCNF and have no non-trivial multi-valued dependencies.
    • +
  • Fix: decompose each MVD into its own table.
    • +
+
+

MVD Example → 4NF Fix

+ 
{`Table: StudentID | Course | Hobby
+1        | Math   | Painting
+1        | Science| Painting
+1        | Math   | Chess
+1        | Science| Chess
+
+MVDs: StudentID →→ Course
+      StudentID →→ Hobby (independent of each other!)
+
+❌ Redundancy: every course × hobby combination stored.
+
+✅ 4NF — split into:
+StudentCourse(StudentID, Course)
+  1 | Math
+  1 | Science
+
+StudentHobby(StudentID, Hobby)
+  1 | Painting
+  1 | Chess`}
+
+
+ +
+ +
+

+ 5NF — Fifth Normal Form (Project-Join NF) +

+
    +
  • Must be in 4NF.
    • +
  • No join dependencies — cannot decompose further without introducing spurious tuples.
    • +
  • Addresses cyclic relationships among three or more entities.
    • +
  • A row in the original table exists only when all three pairwise relationships hold simultaneously.
    • +
+
+

5NF Example

+ 
{`Original: Employee | Project  | Skill
+          Alice    | Project1 | Java
+          Alice    | Project1 | SQL
+          Alice    | Project2 | Java
+          Bob      | Project2 | Python
+
+A row exists IFF:
+  (1) Employee works on Project  [EmpProject table]
+  (2) Project  requires Skill    [ProjectSkill table]
+  (3) Employee has Skill         [EmpSkill table]
+
+✅ 5NF: split into three tables:
+EmpProject(Employee, Project)
+ProjectSkill(Project, Skill)
+EmpSkill(Employee, Skill)
+
+Splitting into only 2 tables creates spurious rows!
+e.g. joining EmpProject × EmpSkill gives
+(Alice, Project2, SQL) which is FAKE. ❌`}
+
+
+

Normal form ladder: 1NF → 2NF → 3NF → BCNF → 4NF → 5NF. Each level eliminates a specific type of dependency problem.

+
); diff --git a/app/sem4/dbms/content/chapter5.tsx b/app/sem4/dbms/content/chapter5.tsx index aa54577..9889ae5 100644 --- a/app/sem4/dbms/content/chapter5.tsx +++ b/app/sem4/dbms/content/chapter5.tsx @@ -2,9 +2,9 @@ export const Ch5Content = () => { return (

- A transaction is a sequence of - database operations treated as a single unit. Concurrency control ensures - multiple transactions run simultaneously without conflicts. + A transaction is a sequence of database operations + treated as a single unit. This chapter covers ACID properties, schedules, serializability, + recoverability, concurrency control protocols, and log-based recovery.

@@ -14,13 +14,13 @@ export const Ch5Content = () => { ACID Properties
    -
  • Atomicity: all operations succeed, or none do. No partial execution.
    • -
  • Consistency: the database moves from one valid state to another.
    • -
  • Isolation: concurrent transactions do not interfere with each other.
    • -
  • Durability: once committed, changes persist even after a crash.
    • +
  • Atomicity: all operations succeed, or none do ("all or nothing"). Example: transferring $100 — both debit and credit must succeed together.
    • +
  • Consistency: transaction moves database from one valid state to another. Total balance must remain the same before and after a transfer.
    • +
  • Isolation: concurrent transactions do not interfere. T2 should not read data being modified by T1 until T1 completes.
    • +
  • Durability: once committed, changes persist even after a crash. Recovery manager ensures durability.
-

Exam Tip: ACID is one of the most asked topics. Remember all four with the mnemonic: All Changes Isolated & Durable.

+

Mnemonic: All Changes Isolated & Durable. ACID is one of the most exam-asked topics — know all four with examples.

@@ -31,16 +31,58 @@ export const Ch5Content = () => { Transaction States
    -
  • Active: transaction is currently executing.
    • -
  • Partially Committed: last operation executed, not yet written to disk.
    • -
  • Committed: all changes written permanently to the database.
    • -
  • Failed: normal execution cannot continue.
    • -
  • Aborted: transaction rolled back; database restored to previous state.
    • +
  • Active: transaction is executing; R/W operations stored in buffer (not yet in DB).
    • +
  • Partially Committed: last operation executed; results still in buffer, not yet written to DB.
    • +
  • Committed: all changes written permanently to DB. Cannot be rolled back — only reversed by a compensating transaction.
    • +
  • Failed: cannot continue due to logical errors or system errors.
    • +
  • Aborted: transaction rolled back; DB restored to previous consistent state.
    • +
  • Terminated: final state after committed or aborted. Life cycle ends.
    • +
+ States of transaction + + +
+ +
+

+ Types of Schedules +

+ Schedules +
    +
  • Serial Schedule: transactions execute one after another — no concurrency. Always correct but low throughput.
    • +
  • Non-Serial Schedule: transactions interleaved. Better throughput; may produce incorrect results.
    • +
  • Serializable Schedule: a non-serial schedule whose result is equivalent to some serial schedule. Correct and concurrent.
    • +
+
+

Serial vs Non-Serial

+ 
{`Serial (S1): T1 runs completely, then T2 runs completely.
+Non-serial (S2): T1 and T2 interleaved — operations mixed.
+Serializable: S2 produces same result as some serial order.`}
+
+
+ +
+ +
+

+ Conflict Serializability +

+
    +
  • Two operations conflict if: (1) they belong to different transactions, (2) they access the same data item, (3) at least one is a Write.
    • +
  • A schedule is conflict serializable if it can be converted to a serial schedule by swapping non-conflicting operations.
    • +
  • Test using a Precedence Graph: draw a node per transaction; add edge Ta→Tb if an operation of Ta conflicts with a later operation of Tb.
    • +
  • If the precedence graph has no cycle → conflict serializable. Cycle → not conflict serializable.
-

State Flow

- 
{`Active → Partially Committed → Committed
-Active → Failed → Aborted`}
+

Precedence Graph Example

+ 
{`S: R1(A), R2(A), R1(B), R2(B), R3(B), W1(A), W2(B)
+
+Conflicting pairs:
+  R2(A), W1(A) → T2→T1
+  R1(B), W2(B) → T1→T2
+  R3(B), W2(B) → T3→T2
+
+Graph: T2→T1→T2 (cycle!) ∴ NOT conflict serializable ❌`}
@@ -48,46 +90,105 @@ Active → Failed → Aborted`}

- Concurrency Problems + View Serializability

    -
  • Lost Update: two transactions read and update the same data; one update overwrites the other.
    • -
  • Dirty Read: a transaction reads data written by another transaction that has not committed yet.
    • -
  • Unrepeatable Read: a transaction reads the same row twice and gets different values because another transaction updated it.
    • -
  • Phantom Read: a transaction re-executes a query and finds new rows added by another transaction.
    • +
  • Two schedules S1 and S2 are view equivalent if they satisfy three rules.
    • +
  • Rule 1 – Initial Read: the first read on each data item must be by the same transaction in both schedules.
    • +
  • Rule 2 – Updated Read: if Ta reads a value written by Tb in S1, the same must hold in S2.
    • +
  • Rule 3 – Final Write: the last write on each data item must be by the same transaction in both schedules.
    • +
  • A schedule is view serializable if it is view equivalent to some serial schedule.
    • +
  • Every conflict serializable schedule is also view serializable — but not vice versa.
+
+

Conflict serializable ⊂ View serializable. If you can prove conflict serializability, view serializability follows automatically.

+

- Locking + Recoverability

    -
  • Shared Lock (S): allows reading. Multiple transactions can hold a shared lock simultaneously.
    • -
  • Exclusive Lock (X): allows reading and writing. Only one transaction can hold it; no other locks allowed.
    • -
  • A transaction must acquire the appropriate lock before accessing data.
    • +
  • Dirty Read: a transaction reads data written by another transaction that has not yet committed.
    • +
  • Irrecoverable Schedule: Ta does a dirty read from Tb, and Ta commits before Tb commits/aborts. Cannot undo — irrecoverable.
    • +
  • Recoverable Schedule: Ta does a dirty read from Tb, but Ta's commit is delayed until Tb commits or aborts. Recovery is possible.
    • +
  • Cascadeless Schedule: transactions only read committed data — no dirty reads at all. Prevents cascading rollbacks.
    • +
  • Strict Schedule: a transaction can neither read nor write a data item until the last transaction that wrote it has committed or aborted. Easiest to recover.
+
+

+ Isolation Levels +

+
    +
  • Dirty Read: reading uncommitted data from another transaction.
    • +
  • Non-Repeatable Read: reading the same row twice gets different values because another transaction updated it (committed) between the reads.
    • +
  • Phantom Read: re-executing a query finds new rows added/deleted by another committed transaction. Row count changes, not values.
    • +
+
+

Isolation Levels Table

+ 
{`Level             | Dirty Read | Non-Repeatable | Phantom
+------------------|------------|----------------|--------
+Read Uncommitted  | May occur  | May occur      | May occur
+Read Committed    | ✗ Never   | ✗ Never        | May occur
+Repeatable Read   | ✗ Never   | ✗ Never        | May occur
+Serializable      | ✗ Never   | ✗ Never        | ✗ Never`}
+
+
+

Serializable is the highest and safest isolation level. Non-Repeatable Read = UPDATE by another transaction. Phantom Read = INSERT/DELETE by another transaction.

+
+
+ +
+ +
+

+ Lock-Based Protocols +

+
    +
  • Shared Lock (S): allows reading. Multiple transactions can hold shared locks simultaneously. Use lock-S instruction.
    • +
  • Exclusive Lock (X): allows read and write. Only one transaction; no other lock allowed. Use lock-X instruction.
    • +
  • Compatibility: S+S = allowed. S+X = blocked. X+X = blocked. X+S = blocked.
    • +
  • Simplistic Protocol: lock each item before operation, release immediately after. Simple but may not ensure serializability.
    • +
  • Pre-claiming Protocol: claim all needed locks before transaction starts. If all granted, proceed; else rollback and wait.
    • +
+
+ + Transaction compatibility lock matrix + +
+

Two-Phase Locking (2PL)

    -
  • A protocol to ensure serializability (correct concurrent execution).
  • Growing Phase: locks are acquired; no lock is released.
    • -
  • Shrinking Phase: locks are released; no new lock is acquired.
    • -
  • 2PL guarantees conflict serializability but can cause deadlocks.
    • +
  • Shrinking Phase: locks are released; no new lock can be acquired.
    • +
  • The point where the first lock is released is the lock point.
    • +
  • 2PL guarantees conflict serializability but can cause deadlocks and cascading aborts.
    • +
  • Strict 2PL: holds all exclusive locks until commit — no shrinking phase for X-locks. Prevents cascading aborts.
-
-

Once a transaction releases its first lock, it enters the shrinking phase and cannot acquire new locks.

+
+

2PL Example — T1

+ 
{`Time 0: LOCK-S(A)       ← Growing phase starts
+Time 4: LOCK-X(B)
+Time 9: UNLOCK(A)       ← Shrinking phase starts
+Time 11: UNLOCK(B)      ← Lock point was at step 4
+Time 15: COMMIT
+
+T1 growing: steps 0–4, shrinking: steps 9–11`}
+ 2PL mechanism +
@@ -95,16 +196,38 @@ Active → Failed → Aborted`} Deadlock
    -
  • A deadlock occurs when two or more transactions wait for each other to release locks — forming a cycle.
    • -
  • Detection: use a wait-for graph; a cycle means deadlock.
    • -
  • Prevention: use timestamps (wait-die or wound-wait schemes).
    • +
  • Deadlock occurs when two or more transactions wait for each other to release locks — a circular wait.
    • +
  • Detection: use a wait-for graph — a cycle means deadlock exists.
    • +
  • Prevention using timestamps:
    • +
  • Wait-Die: older transaction waits for younger; younger transaction is aborted (dies) if it waits for older.
    • +
  • Wound-Wait: older transaction preempts (wounds) the younger; younger waits if older needs its resource.
  • Recovery: abort one transaction (the victim) to break the cycle.

Deadlock Example

{`T1 holds Lock(A), waits for Lock(B)
 T2 holds Lock(B), waits for Lock(A)
-→ Deadlock! Neither can proceed.`}
+→ Circular wait = Deadlock! +Solution: Abort T1 (victim) → T2 can proceed.`} +
+
+ +
+ +
+

+ Timestamp-Based Protocol +

+
    +
  • Each transaction gets a unique timestamp TS(T) when it enters the system.
    • +
  • R-timestamp(X): timestamp of the youngest (most recent) transaction that read X.
    • +
  • W-timestamp(X): timestamp of the youngest transaction that wrote X.
    • +
  • Basic TO — Read(X) by Ti: rejected if W_TS(X) > TS(Ti) (a younger transaction already wrote X). Else allowed.
    • +
  • Basic TO — Write(X) by Ti: rejected if TS(Ti) < R_TS(X) or TS(Ti) < W_TS(X). Ti is rolled back.
    • +
  • Thomas's Write Rule: if W_TS(X) > TS(Ti), ignore (skip) the write but continue Ti — the write is outdated. More permissive than basic TO.
    • +
+
+

Basic TO rejects and rolls back outdated writes. Thomas's Write Rule simply ignores them and lets the transaction continue — reducing unnecessary rollbacks.

@@ -112,13 +235,106 @@ T2 holds Lock(B), waits for Lock(A)

- Timestamp-Based Concurrency Control + Validation-Based Protocol (Optimistic CC) +

+
    +
  • No concurrency checking during execution — check only at the end.
    • +
  • Phase 1 – Read: read data into local temporary variables; perform all writes on temp variables (not actual DB).
    • +
  • Phase 2 – Validation: check whether copying temp results to DB would violate serializability.
    • +
  • Phase 3 – Write: if valid, write temp results to DB. If not, discard and rollback.
    • +
  • TS(T) = Validation(T) — serializability order determined at validation time, not start.
    • +
  • Best for workloads with low conflict — high concurrency without locking overhead.
    • +
+
+ +
+ +
+

+ Multiple Granularity +

+
    +
  • Data can be locked at different granularity levels: Database → Table → Record → Field value.
    • +
  • Locking at a higher level (e.g., whole table) = lower concurrency but fewer lock records.
    • +
  • Locking at a lower level (e.g., individual record) = higher concurrency but more lock overhead.
    • +
  • Intention Locks signal intent along the path from root to desired node.
    • +
  • IS (Intention Shared): will request shared locks on descendants.
    • +
  • IX (Intention Exclusive): will request exclusive locks on descendants.
    • +
  • SIX (Shared + Intention Exclusive): current node is shared, but will exclusively lock some descendants.
    • +
  • Locks are acquired top-down (root first); released bottom-up (leaves first).
    • +
+
+ Compatibility table for intention locks + +
+ +
+

+ Log-Based Recovery +

+
    +
  • The log file records every start, modification, commit, and abort of every transaction on stable storage.
    • +
  • Log entries: <Ti, Start>, <Ti, X, OldValue, NewValue>, <Ti, Commit>, <Ti, Abort>.
    • +
  • Deferred Modification: changes are only saved in the log; actual DB updated only after commit. On failure: no UNDO needed, may need REDO.
    • +
  • Immediate Modification: DB is modified immediately after each operation (also recorded in log). On failure: may need both UNDO (uncommitted) and REDO (committed but not flushed).
    • +
  • WAL (Write-Ahead Logging): log entry must be written to stable storage BEFORE the corresponding DB change. Foundation of ARIES.
    • +
+
+

Log Example

+ 
{`
+    ← A changed from 400 to 300
+    ← B changed from 700 to 800
+
+
+On crash: redo T1 (committed). 
+If T1 had no commit record: undo T1.`}
+
+
+ +
+ +
+

+ Checkpoints +

+
    +
  • A checkpoint is a bookmark — a point where all prior log entries have been flushed to the DB.
    • +
  • Reduces recovery time: only transactions after the last checkpoint need to be considered.
    • +
  • On recovery: read log backward from end to last checkpoint. Transactions with commit → REDO list. Transactions with start but no commit → UNDO list.
    • +
+ Recovery using check point +
+ +
+ +
+

+ ARIES Algorithm +

+
    +
  • ARIES = Algorithm for Recovery and Isolation Exploiting Semantics. Uses write-ahead logging (WAL): a +family of techniques for providing atomicity and durability (two of the ACID properties) in +database systems. The change done by the transactions are first recorded in the log file and +written to stable storage at remote location, before the changes are written to the database.
    • +
  • Phase 1 – Analysis: scan log forward from last checkpoint to find dirty pages, active transactions at crash time, and start point for REDO.
    • +
  • Phase 2 – Redo: replay history from smallest LSN of a dirty page — re-apply all logged updates to reconstruct DB state at crash time.
    • +
  • Phase 3 – Undo: scan log backward — undo all updates of loser (incomplete) transactions in reverse chronological order.
    • +
+
+ Aries algorithm + +
+ +
+

+ Database Backup

    -
  • Each transaction is assigned a unique timestamp when it starts.
    • -
  • Operations are ordered by timestamp to ensure serializability.
    • -
  • Wait-Die: older transaction waits; younger is aborted (dies).
    • -
  • Wound-Wait: older transaction aborts the younger (wounds it); younger waits if it's older.
    • +
  • Full Backup: exact copy of entire database every time. Fastest to restore; slowest to back up.
    • +
  • Incremental Backup: backs up only files changed since the last full backup. Faster backups; more complex restore (need full + all incremental).
    • +
  • Differential Backup: backs up everything changed since last full backup; does not clear archive bit. Simpler restore than incremental (need full + latest differential).
    • +
  • Online Backup: DB updates both primary and remote simultaneously — automatic failover on crash.
    • +
  • Offline Backup: remote DB updated manually at scheduled intervals.
diff --git a/app/sem4/dbms/content/chapter6.tsx b/app/sem4/dbms/content/chapter6.tsx new file mode 100644 index 0000000..13e51b3 --- /dev/null +++ b/app/sem4/dbms/content/chapter6.tsx @@ -0,0 +1,182 @@ +export const Ch6Content = () => { + return ( +
+

+ Indexing and Hashing are + techniques used to speed up data retrieval. Without them, every query would require scanning + the entire table — indexes allow the DBMS to jump directly to relevant records. +

+ +
+ +
+

+ Why Indexing? +

+
    +
  • Without an index, a query must do a full table scan — reading every row to find matches. Very slow for large tables.
    • +
  • An index is a separate data structure that maps search key values to the disk locations of matching records.
    • +
  • The attribute(s) used to build an index are called the search key.
    • +
  • Trade-off: indexes speed up reads but slow down writes (INSERT/UPDATE/DELETE must update the index too) and consume extra disk space.
    • +
+
+

Exam Tip: An index search key is not necessarily the same as the relation's primary key — any attribute can be indexed.

+
+
+ +
+ +
+

+ Types of Indexes +

+
    +
  • Primary Index (Clustering Index): built on the ordering field of a sequentially ordered file. One entry per data block. File is physically ordered by this field.
    • +
  • Secondary Index (Non-Clustering Index): built on a non-ordering field. Multiple entries may point to the same block. File is NOT physically ordered by this field.
    • +
  • Dense Index: one index entry for every record in the data file. Faster lookup; more space.
    • +
  • Sparse Index: one index entry per data block (not every record). Less space; only works if data is sorted. Must scan within block after finding entry.
    • +
  • Multilevel Index: the index itself is too large → build an index on the index. Forms a tree. Reduces search to O(log n) block accesses.
    • +
+
+

Dense vs Sparse

+ 
{`Dense:  index entry for every record
+  [10] → Block 1
+  [20] → Block 1
+  [30] → Block 2  ← one entry per record
+
+Sparse: index entry for every block
+  [10] → Block 1  ← covers records 10–20
+  [30] → Block 2  ← covers records 30–40
+  (data must be sorted for sparse to work)`}
+
+
+ +
+ +
+

+ B-Tree Index +

+
    +
  • A B-Tree is a balanced, self-adjusting tree where every leaf is at the same depth.
    • +
  • Each node holds search key values and pointers to children or data records.
    • +
  • Supports equality search, range queries, and ordered traversal.
    • +
  • On insert/delete, the tree rebalances automatically — always stays balanced.
    • +
  • Node occupancy is kept between ⌈n/2⌉ and n keys (where n is the order of the tree).
    • +
+
+

B-Tree Structure

+ 
{`             [30 | 70]
+            /    |    \
+      [10|20] [40|60] [80|90]
+      /\ /\   /\ /\   /\ /\
+    data records at leaf level`}
+
+
+ +
+ +
+

+ B+ Tree Index +

+
    +
  • A variation of B-Tree where all data pointers are in the leaf nodes only. Internal nodes hold only search keys for routing.
    • +
  • Leaf nodes are linked together in a linked list — enables efficient range scans.
    • +
  • Most practical DBMS indexes (MySQL InnoDB, PostgreSQL) use B+ Trees.
    • +
  • Insertion: find leaf, insert key; if leaf overflows, split and propagate up.
    • +
  • Deletion: find and remove key; if node underflows, merge or redistribute with sibling.
    • +
+
+

B+ Tree vs B-Tree

+ 
{`B-Tree:  data pointers at ALL nodes (internal + leaf)
+B+ Tree: data pointers ONLY at leaf nodes
+         leaf nodes linked: [...10→][...30→][...60→]
+         → range query "WHERE age BETWEEN 20 AND 50"
+           just scans the linked leaf list`}
+
+
+

B+ Tree is preferred over B-Tree in practice because the linked leaf list makes range queries extremely efficient — no need to traverse up and down the tree.

+
+
+ +
+ +
+

+ Hashing +

+
    +
  • Hashing maps a search key value to a bucket (disk page) using a hash function h(K).
    • +
  • Ideal for equality searches (WHERE id = 101). Does NOT support range queries.
    • +
  • A bucket is a unit of storage containing one or more records.
    • +
  • Collision: two different keys hash to the same bucket. Handled by chaining (overflow buckets) or open addressing.
    • +
  • Hash function goal: distribute records uniformly across all buckets to minimize collisions.
    • +
+
+

Hash Example

+ 
{`h(K) = K mod 5
+  h(101) = 1 → Bucket 1
+  h(203) = 3 → Bucket 3
+  h(106) = 1 → Bucket 1 (collision! → overflow bucket)`}
+
+
+ +
+ +
+

+ Static Hashing +

+
    +
  • Fixed number of buckets M. Hash function: h(K) = K mod M.
    • +
  • Problem: if data grows, buckets overflow. If data shrinks, many buckets are empty — wasted space.
    • +
  • Overflow handled by chaining: link overflow buckets to the primary bucket.
    • +
  • Performance degrades as overflow chains grow — may require periodic reorganization.
    • +
+
+ +
+ +
+

+ Dynamic Hashing (Extendible Hashing) +

+
    +
  • Number of buckets grows and shrinks dynamically as data is inserted or deleted.
    • +
  • Uses a directory of pointers to buckets. Directory doubles in size when a bucket overflows.
    • +
  • Global depth: number of bits used to index the directory.
    • +
  • Local depth: number of bits used to index a specific bucket. When local depth = global depth and bucket overflows → directory doubles.
    • +
  • Avoids performance degradation of static hashing without full reorganization.
    • +
+
+

Extendible hashing doubles the directory (not the data pages) on overflow — directory doubling is cheap. Only the overflowing bucket is actually split.

+
+
+ +
+ +
+

+ Indexing vs Hashing — Comparison +

+
    +
  • Hashing is best for exact equality lookups (point queries). O(1) average access.
    • +
  • B+ Tree Indexing supports both equality AND range queries. O(log n) access.
    • +
  • Use hashing when queries are predominantly equality-based and data size is somewhat predictable.
    • +
  • Use B+ Tree when range queries are needed, or data is accessed in sorted order.
    • +
  • Most real-world DBMS use B+ Trees as the default index structure.
    • +
+
+

When to Use Which

+ 
{`Hashing:   WHERE student_id = 101          ← exact match ✓
+           WHERE age BETWEEN 18 AND 25     ← NOT supported ✗
+
+B+ Tree:   WHERE student_id = 101          ← exact match ✓
+           WHERE age BETWEEN 18 AND 25     ← range query ✓
+           ORDER BY name                   ← sorted access ✓`}
+
+
+
+ ); +}; \ No newline at end of file diff --git a/public/sem4/dbms/2pl.png b/public/sem4/dbms/2pl.png new file mode 100644 index 0000000..eed8362 Binary files /dev/null and b/public/sem4/dbms/2pl.png differ diff --git a/public/sem4/dbms/ER_model.png b/public/sem4/dbms/ER_model.png new file mode 100644 index 0000000..8da696f Binary files /dev/null and b/public/sem4/dbms/ER_model.png differ diff --git a/public/sem4/dbms/ER_symbols.png b/public/sem4/dbms/ER_symbols.png new file mode 100644 index 0000000..870088c Binary files /dev/null and b/public/sem4/dbms/ER_symbols.png differ diff --git a/public/sem4/dbms/aries.png b/public/sem4/dbms/aries.png new file mode 100644 index 0000000..762085f Binary files /dev/null and b/public/sem4/dbms/aries.png differ diff --git a/public/sem4/dbms/dbms_schedules.png b/public/sem4/dbms/dbms_schedules.png new file mode 100644 index 0000000..d518c3b Binary files /dev/null and b/public/sem4/dbms/dbms_schedules.png differ diff --git a/public/sem4/dbms/filesystem_vs_dbms.png b/public/sem4/dbms/filesystem_vs_dbms.png new file mode 100644 index 0000000..320b30e Binary files /dev/null and b/public/sem4/dbms/filesystem_vs_dbms.png differ diff --git a/public/sem4/dbms/intention_compatibility.png b/public/sem4/dbms/intention_compatibility.png new file mode 100644 index 0000000..d2c4bef Binary files /dev/null and b/public/sem4/dbms/intention_compatibility.png differ diff --git a/public/sem4/dbms/joins_dbms.png b/public/sem4/dbms/joins_dbms.png new file mode 100644 index 0000000..e0ba5f5 Binary files /dev/null and b/public/sem4/dbms/joins_dbms.png differ diff --git a/public/sem4/dbms/lock_matrix.png b/public/sem4/dbms/lock_matrix.png new file mode 100644 index 0000000..9d759ec Binary files /dev/null and b/public/sem4/dbms/lock_matrix.png differ diff --git a/public/sem4/dbms/many_to_many.png b/public/sem4/dbms/many_to_many.png new file mode 100644 index 0000000..3253912 Binary files /dev/null and b/public/sem4/dbms/many_to_many.png differ diff --git a/public/sem4/dbms/many_to_one.png b/public/sem4/dbms/many_to_one.png new file mode 100644 index 0000000..ed5ede1 Binary files /dev/null and b/public/sem4/dbms/many_to_one.png differ diff --git a/public/sem4/dbms/multi-archDBMS.png b/public/sem4/dbms/multi-archDBMS.png new file mode 100644 index 0000000..7ec861e Binary files /dev/null and b/public/sem4/dbms/multi-archDBMS.png differ diff --git a/public/sem4/dbms/one_to_many.png b/public/sem4/dbms/one_to_many.png new file mode 100644 index 0000000..5b03a8a Binary files /dev/null and b/public/sem4/dbms/one_to_many.png differ diff --git a/public/sem4/dbms/one_to_one.png b/public/sem4/dbms/one_to_one.png new file mode 100644 index 0000000..055e857 Binary files /dev/null and b/public/sem4/dbms/one_to_one.png differ diff --git a/public/sem4/dbms/recovery.png b/public/sem4/dbms/recovery.png new file mode 100644 index 0000000..1c753bf Binary files /dev/null and b/public/sem4/dbms/recovery.png differ diff --git a/public/sem4/dbms/transaction_states.png b/public/sem4/dbms/transaction_states.png new file mode 100644 index 0000000..28734aa Binary files /dev/null and b/public/sem4/dbms/transaction_states.png differ