Database Management System

Every app you build will keep data somewhere, and the choice of how shapes everything after it. This topic explains why we use a DBMS instead of plain files and how a database separates what users see from how data sits on disk.

A table is only useful if you can point at exactly one row and link rows across tables. Keys are how a database guarantees uniqueness and connects data, and almost every DBMS interview starts with a question about them.

Jumping straight to CREATE TABLE leads to missing links and messy schemas. The ER model lets you sketch entities, attributes and relationships on paper first, and then convert that picture into tables with fixed rules.

Real operations like a money transfer are several steps that must succeed or fail together, even when the server crashes halfway. Transactions and the ACID properties are how databases make that promise, and every backend interview expects you to explain them.

A badly designed table stores the same fact many times, and then inserts, updates and deletes start corrupting data. Normalization is the step-by-step method for splitting tables so each fact lives in one place, and normal-form questions are a staple of DBMS rounds.

Databases serve many users at once, and without control two transactions can overwrite or misread each other's data. This topic covers the problems that arise, the isolation levels that trade safety for speed, and the locking that makes it work.

Without an index, finding one row means scanning the whole table from disk. Indexing explains how databases find rows in a few disk reads and what that speed costs on writes.

Not every system fits neatly into tables with fixed schemas on one big server. This topic covers the main NoSQL database types and the CAP theorem, which explains the trade-off every distributed database has to make.