The Only DBMS & SQL Cheat Sheet You Need for Tech Interviews in 2026
Whether you're a CS student preparing for campus placements or a working professional switching to a product company — DBMS and SQL questions will show up in your interview. Every time.
The problem? Most resources are either 500-page textbooks or scattered blog posts that take hours to piece together.
This article covers every DBMS and SQL concept that actually gets asked in technical interviews — concise, structured, and straight to the point.
Why DBMS Still Gets Asked in 2026
Interviewers at companies like Google, Amazon, Microsoft, and mid-size product companies ask DBMS because it tests:
- How well you understand data at a fundamental level
- Whether you can design scalable systems
- If you can write efficient SQL under pressure
Skipping DBMS prep is one of the most common reasons candidates fail technical rounds.
1. ER Diagrams — The Foundation
An Entity Relationship diagram shows the logical structure of a database before it's built.
3 things interviewers check:
- Can you identify entities, attributes, and relationships?
- Do you know strong vs weak entity sets?
- Can you map cardinality correctly (1:1, 1:N, M:N)?
Common interview question: "Design an ER diagram for a hospital management system."
2. Keys — Always Asked, Often Confused
| Key Type | What It Means |
|---|---|
| Primary Key | Uniquely identifies each row, cannot be NULL |
| Candidate Key | Minimal set of attributes that can be primary key |
| Foreign Key | References primary key of another table |
| Composite Key | Primary key made of multiple columns |
| Unique Key | Unique but can have one NULL value |
| Super Key | Any set of attributes that uniquely identifies a row |
Most asked question: "What is the difference between Primary Key and Unique Key?"
Answer: Primary Key cannot be NULL. Unique Key can have one NULL.
3. Normalization — The #1 DBMS Interview Topic
Normalization removes redundancy and ensures data integrity.
1NF — Every cell must have a single atomic value. No repeating groups.
2NF — Must be in 1NF + no partial dependency. Every non-prime attribute must depend on the whole primary key, not part of it.
3NF — Must be in 2NF + no transitive dependency. Non-prime attributes should not depend on other non-prime attributes.
BCNF — Stricter than 3NF. For every functional dependency A→B, A must be a superkey.
Most asked question: "What is the difference between 3NF and BCNF?"
Answer: In 3NF, a non-prime attribute can determine another non-prime attribute if the determinant is a candidate key. BCNF removes even that exception.
4. ACID Properties — Memorize This Cold
| Property | What It Guarantees |
|---|---|
| Atomicity | Transaction completes fully or not at all |
| Consistency | Database stays valid before and after transaction |
| Isolation | Concurrent transactions don't interfere with each other |
| Durability | Committed data persists even after system failure |
Real-world example interviewers love: Bank transfer — if debit succeeds but credit fails, Atomicity ensures the entire transaction rolls back.
5. Transaction States
Active → Partially Committed → Committed → Terminated
If failure occurs: Active/Partially Committed → Failed → Aborted
6. Schedules & Serializability
Serial Schedule — Transactions execute one after another. Always consistent.
Non-Serial Schedule — Transactions execute concurrently. Not always consistent.
Serializable Schedule — A non-serial schedule that produces the same result as some serial schedule. This is what databases aim for.
Types:
- Conflict Serializable — can be converted to serial by swapping non-conflicting operations
- View Serializable — produces same final state as a serial schedule
7. SQL — The Practical Part
DDL vs DML vs DCL vs TCL
| Type | Commands |
|---|---|
| DDL | CREATE, ALTER, DROP, TRUNCATE, RENAME |
| DML | SELECT, INSERT, UPDATE, DELETE, MERGE |
| DCL | GRANT, REVOKE |
| TCL | COMMIT, ROLLBACK, SAVEPOINT |
JOINs — Always in Interviews
-- INNER JOIN: Only matching rows from both tables
SELECT * FROM Orders
INNER JOIN Customers ON Orders.CustomerID = Customers.CustomerID;
-- LEFT JOIN: All rows from left table + matching from right
SELECT * FROM Customers
LEFT JOIN Orders ON Customers.CustomerID = Orders.CustomerID;
-- FULL OUTER JOIN: All rows from both tables
SELECT * FROM Customers
FULL OUTER JOIN Orders ON Customers.CustomerID = Orders.CustomerID;
GROUP BY vs HAVING
-- WHERE filters rows BEFORE grouping
-- HAVING filters AFTER grouping
SELECT Country, COUNT(CustomerID)
FROM Customers
WHERE Country != 'USA' -- filters before group
GROUP BY Country
HAVING COUNT(CustomerID) > 5; -- filters after group
Most asked question: "What is the difference between WHERE and HAVING?"
Answer: WHERE filters individual rows before aggregation. HAVING filters grouped results after aggregation.
Aggregate Functions
SELECT
COUNT(ProductID), -- number of rows
SUM(Price), -- total
AVG(Price), -- average
MIN(Price), -- smallest
MAX(Price) -- largest
FROM Products;
8. Relational Algebra — For Theory Rounds
| Operator | Purpose |
|---|---|
| σ (Selection) | Filter rows based on condition |
| ∏ (Projection) | Select specific columns |
| ⋈ (Natural Join) | Join on common attributes |
| − (Minus) | Rows in R1 but not in R2 |
| ∪ (Union) | Rows in either R1 or R2 |
9. Indexing, B-Trees & B+ Trees
Primary Index — Built on ordered key field. Speeds up search significantly.
B-Tree — Every node (including internal nodes) stores data pointers.
B+ Tree — Only leaf nodes store data. Internal nodes store only keys. This makes B+ Trees faster for range queries and is why most modern databases (MySQL, PostgreSQL) use B+ Trees internally.
What Most Candidates Miss
Most candidates can define ACID. Few can explain why Isolation is hard to achieve in concurrent systems, or when BCNF decomposition causes dependency loss.
The difference between candidates who clear interviews and those who don't is depth — understanding the why behind each concept, not just the definition.
Want All of This in One Place?
I compiled everything covered in this article — plus transaction state diagrams, full SQL syntax reference, all JOIN types with examples, and normalization rules — into a clean 27-page PDF built specifically for placement and technical interview prep.
No fluff. Just the concepts, diagrams, and SQL examples that show up in real interviews.
👉 Get the DBMS & SQL Interview Preparation Notes – $5.99
Instant download. Used by CS students and working professionals preparing for product company interviews.
If this helped you, drop a comment with which topic you find hardest in DBMS — I'll cover it in detail in the next post.