Introduction to DBMS

Database Management Systems (DBMS) form a core part of any technical interview. Whether you’re aiming for a software dev role or a data engineering position, you cannot escape questions on ACID properties, Normalization, or Indexing.

---

Learning Objectives

After completing this chapter, you will be able to:

• Understand why we need a DBMS over file systems.
• Differentiate between schema and instance.
• Explain the three-schema architecture.
• Understand data independence and its types.
• Describe the core functions of a DBMS.
• Identify different types of databases.
• Prepare for the deeper chapters ahead.

---

What is a DBMS?

A Database Management System (DBMS) is software that manages databases. It provides a systematic way to store, retrieve, update, and secure data while handling concurrent access, crash recovery, and data integrity automatically.

Think of a DBMS as a smart librarian who not only stores books but also keeps a catalog, ensures no two members take the same book copy, recovers the catalog if pages tear, and lets you search by title, author, or genre instantly.

---

Why Not Just Use Files?

Before DBMS, data was stored in flat files. Here’s why that breaks at scale:

Problem	File System	DBMS Solution
Redundancy	Same data stored in multiple files	Centralized storage with controlled duplication
Inconsistency	Updating one file leaves others stale	Single source of truth with constraints
Concurrent access	File-level locking (one user blocks all)	Row-level locking, MVCC
Crash recovery	Manual — corrupted files lose data	Automatic logs, checkpoints, undo/redo
Security	OS-level file permissions only	User roles, views, encryption
Query capability	None — grep through files manually	SQL with joins, filters, aggregations

---

Core Functions of a DBMS

Function	What it does
Data Storage Management	Handles physical storage on disk — pages, blocks, files
Data Manipulation	INSERT, UPDATE, DELETE, SELECT via SQL
Data Security	Authentication, authorization, encryption, views
Data Integrity	Constraints (PK, FK, CHECK, UNIQUE, NOT NULL)
Transaction Management	ACID properties for reliable operations
Concurrency Control	Multiple users simultaneously without corruption
Backup and Recovery	Logs, checkpoints, undo/redo for crash safety
Data Independence	Changes in storage don’t affect applications

---

Types of Databases

By Data Model

Type	Description	Examples
Relational	Tables with rows and columns	MySQL, PostgreSQL, Oracle
Document	JSON-like documents	MongoDB, CouchDB
Key-Value	Simple key-value pairs	Redis, DynamoDB
Column-Family	Columns instead of rows	Cassandra, HBase
Graph	Nodes and edges	Neo4j, ArangoDB

By Usage

Type	Description
OLTP (Operational)	High-volume daily transactions (banking, e-commerce)
OLAP (Analytical)	Complex queries for reporting and analysis
Data Warehouse	Central repository for historical data from multiple sources

---

Database Lifecycle

Requirement Analysis → Conceptual Design (ER Model)
    → Logical Design (Relational Model) → Normalization
    → Physical Design (Indexes, Partitions) → SQL Implementation
    → Testing → Deployment → Maintenance

Each stage is essential. Skipping design leads to costly rework later.

---

What This Section Covers

This introduction section gives you the big picture:

1. Fundamental Intuition: Why DBMS? (DBMS vs. File System)
2. Core Concepts: Abstraction, independence, architecture
3. The Vocabulary: Schema, instance, metadata
4. DBMS vs RDBMS: What makes a DBMS “relational”

---

Learning Strategy

• Concepts First: Don’t memorize definitions. Understand the problem each concept solves.
• Interview Focus: Pay close attention to the HorizontalTab sections — they contain real-world interview questions.
• Progressive Depth: Start with 1-tier vs 3-tier architecture and move to B+ Trees and lock protocols.

Let’s begin by understanding why we stopped using simple text files to store data and switched to DBMS.

---

Interview Deep Dive

---

Key Takeaways

• A DBMS is software that manages databases with security, concurrency, and recovery.
• File systems fail at scale due to redundancy, inconsistency, and lack of concurrency.
• A DBMS provides data independence — changes at one level don’t affect higher levels.
• Schema is the blueprint; instance is the actual data.
• Different database types exist for different use cases (relational, document, graph).
• The database lifecycle ensures systematic development from requirements to maintenance.