diff --git a/app/sem4/dbms/content/chapter6.tsx b/app/sem4/dbms/content/chapter6.tsx
new file mode 100644
index 0000000..7bb75e0
--- /dev/null
+++ b/app/sem4/dbms/content/chapter6.tsx
@@ -0,0 +1,83 @@
+export const Ch6Content = () => {
+ return (
+
+
+ Indexing and{" "}
+ Hashing are techniques used to
+ speed up data retrieval in large databases without scanning every row.
+
+
+
+
+
+
+ Why Indexing?
+
+
+ - Without an index, every query scans the entire table — slow for large data.
+ - An index is like a book's table of contents — it points directly to the data.
+ - Indexes speed up SELECT queries but slightly slow down INSERT, UPDATE, DELETE.
+ - Created using:
CREATE INDEX idx_name ON table(column);
+
+
+
+
+
+
+
+ Types of Indexes
+
+
+ - Primary Index: built on the primary key of an ordered file. One entry per data block.
+ - Secondary Index: built on non-primary key fields. Points to exact records.
+ - Clustering Index: records are physically ordered by the indexed field.
+ - Dense Index: one index entry for every record in the file.
+ - Sparse Index: one index entry per block, not per record. Requires ordered data.
+
+
+
Dense index is faster to search but uses more space. Sparse index saves space but requires the file to be sorted.
+
+
+
+
+
+
+
+ B-Tree and B+ Tree
+
+
+ - Most databases use B+ Trees for indexing.
+ - B-Tree: stores data in both internal nodes and leaf nodes.
+ - B+ Tree: stores data only in leaf nodes; internal nodes store only keys for navigation.
+ - Leaf nodes in B+ Tree are linked — great for range queries.
+ - All operations (search, insert, delete) take O(log n) time.
+
+
+
B+ Tree Structure
+
{`Internal nodes: [10 | 20 | 30]
+ / | | \\
+Leaf nodes: [5,8] [12,15] [22,25] [35,40]
+ ↔ ↔ ↔ ↔ (linked)`}
+
+
+
+
+
+
+
+ Hashing
+
+
+ - Hashing maps a key value directly to a bucket (storage location) using a hash function.
+ - Best for exact match queries — not range queries.
+ - Static Hashing: fixed number of buckets. Can cause overflow if data grows.
+ - Dynamic Hashing (Extendible Hashing): buckets grow and split as data increases.
+ - Collision: two keys map to the same bucket — handled by chaining or open addressing.
+
+
+
Use indexing (B+ Tree) for range queries. Use hashing for fast exact lookups.
+
+
+
+ );
+};
\ No newline at end of file
diff --git a/app/sem4/dbms/content/chapter7.tsx b/app/sem4/dbms/content/chapter7.tsx
new file mode 100644
index 0000000..a26f921
--- /dev/null
+++ b/app/sem4/dbms/content/chapter7.tsx
@@ -0,0 +1,90 @@
+export const Ch7Content = () => {
+ return (
+
+
+ Query Processing is how the DBMS
+ takes a SQL query, understands it, and executes it efficiently.{" "}
+ Query Optimization selects the
+ most efficient execution plan.
+
+
+
+
+
+
+ Steps in Query Processing
+
+
+ - Parsing: the SQL query is checked for syntax errors and converted into a parse tree.
+ - Translation: the parse tree is converted into relational algebra expressions.
+ - Optimization: the query optimizer picks the most efficient execution plan.
+ - Execution: the chosen plan is executed and results are returned.
+
+
+
Query Processing Pipeline
+
{`SQL Query
+ ↓ Parser
+Parse Tree
+ ↓ Translator
+Relational Algebra Expression
+ ↓ Optimizer
+Execution Plan
+ ↓ Evaluator
+Query Result`}
+
+
+
+
+
+
+
+ Query Cost Estimation
+
+
+ - Cost is measured in terms of disk I/O, CPU time, and memory usage.
+ - Disk I/O dominates — the optimizer minimizes the number of disk reads/writes.
+ - The optimizer uses statistics (number of rows, distinct values, index availability) to estimate cost.
+
+
+
+
+
+
+
+ Join Algorithms
+
+
+ - Nested Loop Join: for each tuple in the outer relation, scan all tuples in the inner. Simple but slow for large tables.
+ - Block Nested Loop Join: loads blocks instead of tuples — fewer disk reads.
+ - Merge Join: both relations sorted on the join attribute, then merged. Efficient for sorted data.
+ - Hash Join: hash both relations on the join attribute and match buckets. Very efficient for large unsorted data.
+
+
+
Hash Join is generally the fastest for large datasets. Merge Join is best when data is already sorted.
+
+
+
+
+
+
+
+ Query Optimization Techniques
+
+
+ - Heuristic Optimization: apply rules to rewrite the query into a more efficient form before execution.
+ - Push selections down: apply WHERE filters as early as possible to reduce rows.
+ - Push projections down: select only needed columns early to reduce data size.
+ - Cost-Based Optimization: enumerate multiple plans, estimate their cost, and pick the cheapest.
+
+
+
Heuristic Example
+
{`-- Before optimization (filter happens after join):
+Students ⋈ Enrollments WHERE Students.dept = 'CSE'
+
+-- After optimization (filter before join):
+σ(dept='CSE')(Students) ⋈ Enrollments`}
+
+
+
+ );
+};
\ No newline at end of file
diff --git a/app/sem4/dbms/content/chapter8.tsx b/app/sem4/dbms/content/chapter8.tsx
new file mode 100644
index 0000000..9f91f13
--- /dev/null
+++ b/app/sem4/dbms/content/chapter8.tsx
@@ -0,0 +1,117 @@
+export const Ch8Content = () => {
+ return (
+
+
+ Recovery restores the database to
+ a consistent state after a failure.{" "}
+ Security ensures only authorized
+ users can access or modify data.
+
+
+
+
+
+
+ Types of Failures
+
+
+ - Transaction Failure: logical error or deadlock causes a transaction to abort.
+ - System Failure: power outage or OS crash — data in memory is lost but disk is safe.
+ - Media Failure: disk crash — data on disk is lost. Requires backups.
+
+
+
+
+
+
+
+ Log-Based Recovery
+
+
+ - The DBMS maintains a log file recording every change before it is applied to the database.
+ - Each log record contains: transaction ID, data item, old value, new value.
+ - Undo: if a transaction fails, old values from the log are restored.
+ - Redo: if a committed transaction's changes weren't written to disk, they are reapplied.
+ - Write-Ahead Logging (WAL): log must be written to disk before the actual data change.
+
+
+
WAL is the golden rule of recovery — always log before you change.
+
+
+
+
+
+
+
+ Checkpoints
+
+
+ - A checkpoint is a point where the DBMS writes all in-memory changes to disk and records this in the log.
+ - During recovery, only transactions after the last checkpoint need to be redone or undone.
+ - Checkpoints reduce recovery time significantly.
+
+
+
Recovery After Crash
+
{`Checkpoint at T=10
+T1 committed at T=8 → already safe, skip
+T2 committed at T=12 → redo (may not be on disk)
+T3 active at crash → undo (was never committed)`}
+
+
+
+
+
+
+
+ Shadow Paging
+
+
+ - An alternative to log-based recovery.
+ - Maintains two page tables: current and shadow.
+ - Changes go to the current page table. On commit, current replaces shadow.
+ - On failure, just restore the shadow page table — no undo needed.
+ - Simpler than logging but causes fragmentation and is rarely used in modern systems.
+
+
+
+
+
+
+
+ Database Security
+
+
+ - Authentication: verifying who the user is — username and password.
+ - Authorization: controlling what an authenticated user can do.
+ - GRANT: gives a user permission. Example:
GRANT SELECT ON students TO user1;
+ - REVOKE: removes a permission. Example:
REVOKE SELECT ON students FROM user1;
+ - Views as Security: expose only specific columns or rows to certain users.
+
+
+
+
+
+
+
+ SQL Injection
+
+
+ - A common attack where malicious SQL is inserted into an input field to manipulate the database.
+ - Prevention: use prepared statements and parameterized queries — never concatenate raw user input into SQL.
+
+
+
SQL Injection Example
+
{`-- Vulnerable query:
+"SELECT * FROM users WHERE name = '" + input + "'"
+
+-- Attacker enters: ' OR '1'='1
+-- Resulting query (returns all users!):
+SELECT * FROM users WHERE name = '' OR '1'='1'
+
+-- Safe fix (prepared statement):
+SELECT * FROM users WHERE name = ?`}
+
+
+
+ );
+};
\ No newline at end of file