DBMS Fundamentals & File Systems
Before modern databases, data was managed using File Systems — data stored in various .txt or .csv files across different folders. While simple, this approach breaks down quickly at scale.
Learning Objectives
After completing this chapter, you will be able to:
- List the limitations of file-based data storage.
- Explain how a DBMS solves each limitation.
- Define data redundancy and data inconsistency.
- Understand concurrency and why it matters.
- Describe how DBMS ensures data security and integrity.
- Answer interview questions on DBMS vs File System.
The Problems with File Systems
1. Data Redundancy
The same information is stored in multiple files.
Example: A student’s name appears in Attendance.txt, Grades.txt, and Library.txt. If the student changes their name, every file must be updated.
Problem: Wasted storage, wasted effort.
2. Data Inconsistency
When redundant data is not updated everywhere, different files contain different values.
Example: Attendance.txt says “Rahul Sharma” but Grades.txt says “Rahul S.” Which one is correct?
Problem: No single source of truth.
3. Data Isolation
Data is scattered across files in different formats. Writing a new report requires custom code to parse each file format.
Problem: No unified query capability.
4. Integrity Problems
Enforcing rules like “Age must be > 18” requires application code. If one application forgets the check, bad data enters.
Problem: No centralized constraint enforcement.
5. Concurrent Access
Two users writing to the same file simultaneously can corrupt data. File-level locking allows only one writer at a time, blocking all other users.
Problem: Poor performance and data corruption.
6. Security Issues
File system permissions are coarse (read/write for entire files). There is no way to allow a user to see only specific columns.
Problem: No granular access control.
7. Crash Recovery
If the system crashes mid-write, the file may be left in a corrupted state. Recovery requires manual intervention and backups.
Problem: Data loss and manual recovery.
How DBMS Solves Each Problem
| File System Problem | DBMS Solution |
|---|---|
| Data Redundancy | Centralized storage with controlled normalization |
| Data Inconsistency | Single source of truth, constraints, transactions |
| Data Isolation | SQL — unified query language for all data |
| Integrity Problems | Declarative constraints (CHECK, FK, NOT NULL) |
| Concurrent Access | Locking, MVCC, transaction isolation |
| Security Issues | User roles, views, column-level permissions |
| Crash Recovery | WAL (Write-Ahead Logging), checkpoints, undo/redo |
The ACID Properties (Overview)
ACID is the foundation of reliable database transactions. We cover these in detail later, but here’s a quick reference:
| Property | Meaning | Example |
|---|---|---|
| Atomicity | All or nothing | Bank transfer: both debit and credit succeed, or neither |
| Consistency | Valid state before and after | Age constraint is always enforced |
| Isolation | Concurrent transactions don’t interfere | Two users booking the last seat get correct results |
| Durability | Committed data survives crashes | After commit, data is safe even with power failure |
When Would You Still Use a File System?
File systems are appropriate when:
- The application is very simple (personal config file, logger)
- No concurrent access is needed
- No complex queries are required
- Data volume is tiny
- Crash recovery is not critical
For anything beyond this, a DBMS is superior.
Interview Deep Dive
Q: In what scenario would you still prefer a File System over a DBMS?
A: If the application is very simple, has a small amount of data, and doesn’t require concurrent access or complex queries. Example: A personal configuration file or a simple logger. For anything else, DBMS is superior.
Q: How does a DBMS prevent Data Inconsistency?
A: By reducing Data Redundancy through normalization and enforcing constraints. Since data is stored in one place (or linked properly via foreign keys), changing it in one location reflects everywhere, preventing different versions of the same data.
Q: Give a real-world example of Atomicity in a DBMS.
A: A bank transfer. If you send 100toafriend,twothingsmusthappen:(1)100 is deducted from your account, (2) $100 is added to your friend’s account. If the system crashes after step 1, the DBMS rolls back the entire transaction so your money isn’t lost.
Q: What goes wrong if two users book the last flight seat simultaneously in a file system?
A: Both users read “1 seat available,” both write “0 seats available,” the second write overwrites the first, and both think they booked. A DBMS prevents this with row-level locking — the second transaction waits until the first commits.
Key Takeaways
- File systems suffer from redundancy, inconsistency, isolation, integrity, concurrency, security, and recovery problems.
- A DBMS solves all of these through centralized storage, constraints, SQL, locking, and logging.
- ACID properties (Atomicity, Consistency, Isolation, Durability) ensure reliable transactions.
- Choose a file system only for the simplest single-user applications.
- Every major application (banking, e-commerce, healthcare) uses a DBMS.
Premium Content
Unlock DBMS Fundamentals & File Systems and all premium lessons with a subscription.
From ₹199.99/year — See plans