DBMS & SQL Cheat Sheet You Need for Tech Interviews in 2026

Juhi Singhal — Sun, 21 Jun 2026 10:43:33 +0000

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.

DEV Community: Juhi Singhal