Skip to content

Docs/dbms indexing query recovery #41

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
codewithzubair07 wants to merge 3 commits into
base: main
Choose a base branch
from
+290 −0
Open

Docs/dbms indexing query recovery #41

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
e7711ad
docs: add DBMS chapters 6, 7, 8 - indexing, query processing, recover…
jannatfirdous07 May 16, 2026
02e490a
docs: add DBMS to available subjects list
jannatfirdous07 May 22, 2026
03642e2
Merge branch 'main' into docs/dbms-indexing-query-recovery
codewithzubair07 May 22, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
83 changes: 83 additions & 0 deletions app/sem4/dbms/content/chapter6.tsx
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,83 @@
export const Ch6Content = () => {
return (
<div className="course-content">
<p className="p-text">
<span className="font-semibold">Indexing</span> and{" "}
<span className="font-semibold">Hashing</span> are techniques used to
speed up data retrieval in large databases without scanning every row.
</p>

<hr className="my-6 border-[#c7a669] opacity-40" />

<section>
<h3 className="section-heading">
<span className="section-subheading">Why Indexing?</span>
</h3>
<ul className="section-list">
<li>Without an index, every query scans the entire table — slow for large data.</li>
<li>An index is like a book&apos;s table of contents — it points directly to the data.</li>
<li>Indexes speed up SELECT queries but slightly slow down INSERT, UPDATE, DELETE.</li>
<li>Created using: <code>CREATE INDEX idx_name ON table(column);</code></li>
</ul>
</section>

<hr className="my-6 border-[#c7a669] opacity-40" />

<section>
<h3 className="section-heading">
<span className="section-subheading">Types of Indexes</span>
</h3>
<ul className="section-list">
<li><span className="font-semibold">Primary Index:</span> built on the primary key of an ordered file. One entry per data block.</li>
<li><span className="font-semibold">Secondary Index:</span> built on non-primary key fields. Points to exact records.</li>
<li><span className="font-semibold">Clustering Index:</span> records are physically ordered by the indexed field.</li>
<li><span className="font-semibold">Dense Index:</span> one index entry for every record in the file.</li>
<li><span className="font-semibold">Sparse Index:</span> one index entry per block, not per record. Requires ordered data.</li>
</ul>
<div className="tip-block">
<p>Dense index is faster to search but uses more space. Sparse index saves space but requires the file to be sorted.</p>
</div>
</section>

<hr className="my-6 border-[#c7a669] opacity-40" />

<section>
<h3 className="section-heading">
<span className="section-subheading">B-Tree and B+ Tree</span>
</h3>
<ul className="section-list">
<li>Most databases use <span className="font-semibold">B+ Trees</span> for indexing.</li>
<li><span className="font-semibold">B-Tree:</span> stores data in both internal nodes and leaf nodes.</li>
<li><span className="font-semibold">B+ Tree:</span> stores data only in leaf nodes; internal nodes store only keys for navigation.</li>
<li>Leaf nodes in B+ Tree are linked — great for range queries.</li>
<li>All operations (search, insert, delete) take O(log n) time.</li>
</ul>
<div className="example-block">
<p className="font-semibold mb-1">B+ Tree Structure</p>
<pre>{`Internal nodes: [10 | 20 | 30]
/ | | \\
Leaf nodes: [5,8] [12,15] [22,25] [35,40]
↔ ↔ ↔ ↔ (linked)`}</pre>
</div>
</section>

<hr className="my-6 border-[#c7a669] opacity-40" />

<section>
<h3 className="section-heading">
<span className="section-subheading">Hashing</span>
</h3>
<ul className="section-list">
<li>Hashing maps a key value directly to a bucket (storage location) using a hash function.</li>
<li>Best for <span className="font-semibold">exact match queries</span> — not range queries.</li>
<li><span className="font-semibold">Static Hashing:</span> fixed number of buckets. Can cause overflow if data grows.</li>
<li><span className="font-semibold">Dynamic Hashing (Extendible Hashing):</span> buckets grow and split as data increases.</li>
<li><span className="font-semibold">Collision:</span> two keys map to the same bucket — handled by chaining or open addressing.</li>
</ul>
<div className="tip-block">
<p>Use indexing (B+ Tree) for range queries. Use hashing for fast exact lookups.</p>
</div>
</section>
</div>
);
};
90 changes: 90 additions & 0 deletions app/sem4/dbms/content/chapter7.tsx
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,90 @@
export const Ch7Content = () => {
return (
<div className="course-content">
<p className="p-text">
<span className="font-semibold">Query Processing</span> is how the DBMS
takes a SQL query, understands it, and executes it efficiently.{" "}
<span className="font-semibold">Query Optimization</span> selects the
most efficient execution plan.
</p>

<hr className="my-6 border-[#c7a669] opacity-40" />

<section>
<h3 className="section-heading">
<span className="section-subheading">Steps in Query Processing</span>
</h3>
<ul className="section-list">
<li><span className="font-semibold">Parsing:</span> the SQL query is checked for syntax errors and converted into a parse tree.</li>
<li><span className="font-semibold">Translation:</span> the parse tree is converted into relational algebra expressions.</li>
<li><span className="font-semibold">Optimization:</span> the query optimizer picks the most efficient execution plan.</li>
<li><span className="font-semibold">Execution:</span> the chosen plan is executed and results are returned.</li>
</ul>
<div className="example-block">
<p className="font-semibold mb-1">Query Processing Pipeline</p>
<pre>{`SQL Query
↓ Parser
Parse Tree
↓ Translator
Relational Algebra Expression
↓ Optimizer
Execution Plan
↓ Evaluator
Query Result`}</pre>
</div>
</section>

<hr className="my-6 border-[#c7a669] opacity-40" />

<section>
<h3 className="section-heading">
<span className="section-subheading">Query Cost Estimation</span>
</h3>
<ul className="section-list">
<li>Cost is measured in terms of disk I/O, CPU time, and memory usage.</li>
<li>Disk I/O dominates — the optimizer minimizes the number of disk reads/writes.</li>
<li>The optimizer uses statistics (number of rows, distinct values, index availability) to estimate cost.</li>
</ul>
</section>

<hr className="my-6 border-[#c7a669] opacity-40" />

<section>
<h3 className="section-heading">
<span className="section-subheading">Join Algorithms</span>
</h3>
<ul className="section-list">
<li><span className="font-semibold">Nested Loop Join:</span> for each tuple in the outer relation, scan all tuples in the inner. Simple but slow for large tables.</li>
<li><span className="font-semibold">Block Nested Loop Join:</span> loads blocks instead of tuples — fewer disk reads.</li>
<li><span className="font-semibold">Merge Join:</span> both relations sorted on the join attribute, then merged. Efficient for sorted data.</li>
<li><span className="font-semibold">Hash Join:</span> hash both relations on the join attribute and match buckets. Very efficient for large unsorted data.</li>
</ul>
<div className="tip-block">
<p>Hash Join is generally the fastest for large datasets. Merge Join is best when data is already sorted.</p>
</div>
</section>

<hr className="my-6 border-[#c7a669] opacity-40" />

<section>
<h3 className="section-heading">
<span className="section-subheading">Query Optimization Techniques</span>
</h3>
<ul className="section-list">
<li><span className="font-semibold">Heuristic Optimization:</span> apply rules to rewrite the query into a more efficient form before execution.</li>
<li><span className="font-semibold">Push selections down:</span> apply WHERE filters as early as possible to reduce rows.</li>
<li><span className="font-semibold">Push projections down:</span> select only needed columns early to reduce data size.</li>
<li><span className="font-semibold">Cost-Based Optimization:</span> enumerate multiple plans, estimate their cost, and pick the cheapest.</li>
</ul>
<div className="example-block">
<p className="font-semibold mb-1">Heuristic Example</p>
<pre>{`-- Before optimization (filter happens after join):
Students ⋈ Enrollments WHERE Students.dept = 'CSE'

-- After optimization (filter before join):
σ(dept='CSE')(Students) ⋈ Enrollments`}</pre>
</div>
</section>
</div>
);
};
117 changes: 117 additions & 0 deletions app/sem4/dbms/content/chapter8.tsx
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,117 @@
export const Ch8Content = () => {
return (
<div className="course-content">
<p className="p-text">
<span className="font-semibold">Recovery</span> restores the database to
a consistent state after a failure.{" "}
<span className="font-semibold">Security</span> ensures only authorized
users can access or modify data.
</p>

<hr className="my-6 border-[#c7a669] opacity-40" />

<section>
<h3 className="section-heading">
<span className="section-subheading">Types of Failures</span>
</h3>
<ul className="section-list">
<li><span className="font-semibold">Transaction Failure:</span> logical error or deadlock causes a transaction to abort.</li>
<li><span className="font-semibold">System Failure:</span> power outage or OS crash — data in memory is lost but disk is safe.</li>
<li><span className="font-semibold">Media Failure:</span> disk crash — data on disk is lost. Requires backups.</li>
</ul>
</section>

<hr className="my-6 border-[#c7a669] opacity-40" />

<section>
<h3 className="section-heading">
<span className="section-subheading">Log-Based Recovery</span>
</h3>
<ul className="section-list">
<li>The DBMS maintains a <span className="font-semibold">log file</span> recording every change before it is applied to the database.</li>
<li>Each log record contains: transaction ID, data item, old value, new value.</li>
<li><span className="font-semibold">Undo:</span> if a transaction fails, old values from the log are restored.</li>
<li><span className="font-semibold">Redo:</span> if a committed transaction&apos;s changes weren&apos;t written to disk, they are reapplied.</li>
<li><span className="font-semibold">Write-Ahead Logging (WAL):</span> log must be written to disk before the actual data change.</li>
</ul>
<div className="tip-block">
<p>WAL is the golden rule of recovery — always log before you change.</p>
</div>
</section>

<hr className="my-6 border-[#c7a669] opacity-40" />

<section>
<h3 className="section-heading">
<span className="section-subheading">Checkpoints</span>
</h3>
<ul className="section-list">
<li>A checkpoint is a point where the DBMS writes all in-memory changes to disk and records this in the log.</li>
<li>During recovery, only transactions after the last checkpoint need to be redone or undone.</li>
<li>Checkpoints reduce recovery time significantly.</li>
</ul>
<div className="example-block">
<p className="font-semibold mb-1">Recovery After Crash</p>
<pre>{`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)`}</pre>
</div>
</section>

<hr className="my-6 border-[#c7a669] opacity-40" />

<section>
<h3 className="section-heading">
<span className="section-subheading">Shadow Paging</span>
</h3>
<ul className="section-list">
<li>An alternative to log-based recovery.</li>
<li>Maintains two page tables: <span className="font-semibold">current</span> and <span className="font-semibold">shadow</span>.</li>
<li>Changes go to the current page table. On commit, current replaces shadow.</li>
<li>On failure, just restore the shadow page table — no undo needed.</li>
<li>Simpler than logging but causes fragmentation and is rarely used in modern systems.</li>
</ul>
</section>

<hr className="my-6 border-[#c7a669] opacity-40" />

<section>
<h3 className="section-heading">
<span className="section-subheading">Database Security</span>
</h3>
<ul className="section-list">
<li><span className="font-semibold">Authentication:</span> verifying who the user is — username and password.</li>
<li><span className="font-semibold">Authorization:</span> controlling what an authenticated user can do.</li>
<li><span className="font-semibold">GRANT:</span> gives a user permission. Example: <code>GRANT SELECT ON students TO user1;</code></li>
<li><span className="font-semibold">REVOKE:</span> removes a permission. Example: <code>REVOKE SELECT ON students FROM user1;</code></li>
<li><span className="font-semibold">Views as Security:</span> expose only specific columns or rows to certain users.</li>
</ul>
</section>

<hr className="my-6 border-[#c7a669] opacity-40" />

<section>
<h3 className="section-heading">
<span className="section-subheading">SQL Injection</span>
</h3>
<ul className="section-list">
<li>A common attack where malicious SQL is inserted into an input field to manipulate the database.</li>
<li><span className="font-semibold">Prevention:</span> use prepared statements and parameterized queries — never concatenate raw user input into SQL.</li>
</ul>
<div className="example-block">
<p className="font-semibold mb-1">SQL Injection Example</p>
<pre>{`-- 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 = ?`}</pre>
</div>
</section>
</div>
);
};