Introduction to Databases: DBMS vs File Systems, Characteristics, Advantages & Disadvantages

The Story That Explains Why Databases Exist

Almost every application you use — banking, ticket booking, social media, your phone's contact list — sits on top of a database. Before we appreciate the DBMS, we need to understand the messy world that came before it: the file-based system.

First, the Vocabulary — Data, Database, DBMS

These three words get used interchangeably in casual talk, but in this subject they mean very precise things. Get these right and everything else clicks into place.

The Old World — File-Based Systems

Before DBMS software existed (roughly pre-1970s), each application program managed its own data in its own permanent files, stored directly on disk. Every program defined its own file format and wrote its own code to read and write those files.

Animated Diagram — File System vs DBMS

This picture is the heart of the whole topic. On the left, three programs each keep a private, duplicated copy of employee data. On the right, all three share one guarded, single source of truth.

The Problems With File-Based Systems

Because each program owns its own glued-on files, a predictable list of pains emerges. These are the classic disadvantages every textbook lists — here they are with plain explanations.

DBMS vs File System — The Full Comparison

Characteristics of the Database Approach

What exactly makes the "database approach" different from just dumping data into files? Four defining characteristics, straight from the classic definition (Elmasri & Navathe).

Animated Diagram — Where the DBMS Sits

Notice how the DBMS acts as a gatekeeper between users and the stored data and metadata. No program ever touches the raw disk directly — every request flows through the DBMS, which is exactly what enables data independence, security, and concurrency control.

Advantages of a DBMS

Disadvantages of a DBMS

A DBMS is powerful, but that power is not free. Knowing the costs is what separates a student from an engineer who chooses the right tool.

So When Is a Plain File Actually Fine?

Hands-On — The Database Approach in Python

Let's see the difference. Using Python's built-in sqlite3 module, we store customer and order data once, link them with a key (no redundancy), and ask a question with SQL instead of writing custom file-reading code.

Creating the Database & Querying It

import sqlite3

# Connect (creates the file the first time) — this is our single source of truth
conn = sqlite3.connect('college.db')
cur  = conn.cursor()

# Define structure ONCE. The DBMS stores this in its own catalog (self-describing).
cur.execute("""
    CREATE TABLE IF NOT EXISTS students (
        id    INTEGER PRIMARY KEY,
        name  TEXT    NOT NULL,
        dept  TEXT    NOT NULL
    )""")

# Orders reference the student by id — the name is NOT copied (no redundancy)
cur.execute("""
    CREATE TABLE IF NOT EXISTS marks (
        student_id INTEGER,
        subject    TEXT,
        score      INTEGER,
        FOREIGN KEY (student_id) REFERENCES students(id)
    )""")

# Insert data once
cur.executemany("INSERT OR IGNORE INTO students VALUES (?, ?, ?)", [
    (1, 'Riya',  'CSE'),
    (2, 'Aman',  'ECE'),
    (3, 'Neha',  'CSE'),
])
cur.executemany("INSERT INTO marks VALUES (?, ?, ?)", [
    (1, 'DBMS', 88),
    (2, 'DBMS', 73),
    (3, 'DBMS', 91),
])
conn.commit()

# Ask ANY question with SQL — no custom file parser needed
cur.execute("""
    SELECT s.name, s.dept, m.score
    FROM   students s
    JOIN   marks m ON s.id = m.student_id
    WHERE  m.score >= 80
    ORDER  BY m.score DESC""")

print("Top DBMS scorers:")
for name, dept, score in cur.fetchall():
    print(f"  {name:6s} ({dept})  ->  {score}")

conn.close()

Atomicity — All-or-Nothing Transactions

This is the protection a loose file can never give you. If anything fails mid-way, the whole block rolls back as if it never happened.

conn = sqlite3.connect('college.db')
try:
    with conn:                       # commits on success, rolls back on error
        conn.execute("UPDATE marks SET score = score + 5 WHERE subject = 'DBMS'")
        conn.execute("INSERT INTO marks VALUES (99, 'OS', 'oops')")  # bad row -> error
except sqlite3.Error as e:
    print(f"Transaction failed and was rolled back: {e}")

# The +5 update was UNDONE too — nothing partial survives
print("Scores are unchanged — atomicity protected the data.")
conn.close()

Bringing It Together

Golden Rules