Introduction to Databases
Press Next → or use ← → arrow keys
The Story — A Tale of Two Colleges
College B does it differently: all three offices read and write one shared record. Change Riya's name once, and every office instantly sees the truth — no duplicates, no contradictions.
A DBMS exists to let many users and programs share the same data safely — without duplication, contradiction, or data loss — while hiding the messy details of how that data is physically stored.
Vocabulary — Data, Database, DBMS
Data is the milk. The database is the bottle that organizes and holds it. The DBMS is the fridge that keeps it safe. Database + DBMS together = a Database System.
The Old World — File-Based Systems
Before the 1970s, applications stored data in their own flat files. Four habits defined that world:
In a file-based system, data and the programs that use it are inseparable. There is no central manager, no shared definition of what the data means, and no protection against two programs corrupting the same file at once.
How Data Is Organized — Files vs DBMS
On the left, each app hoards its own copy — so the same fact is stored three times and drifts out of sync. On the right, every app reads and writes one database: change it once, and everyone sees the change.
Nine Problems With File-Based Systems
DBMS vs File System — Full Comparison
| Aspect | File-Based System | DBMS |
|---|---|---|
| Data redundancy | High — copies everywhere | Controlled via normalization |
| Data consistency | Easily contradictory | Enforced by constraints |
| Data sharing | Difficult, file-by-file | Built-in, multi-user |
| Querying | Custom code each time | Standard SQL |
| Data independence | None — tightly coupled | Logical & physical |
| Integrity rules | Buried in each program | Central, declarative |
| Concurrency control | Absent — lost updates | Locking / MVCC |
| Crash recovery | Manual, often impossible | Transactions + logs |
| Security granularity | Coarse file permissions | Per-user / table / column |
| Setup cost | Very low | Higher — software + skills |
| Best for | Tiny, single-user data | Shared, mission-critical data |
A DBMS is not automatically "better" for everything. For a tiny, single-user, one-off task, a plain file is simpler and cheaper.
Characteristics of the Database Approach
The database approach means data is self-describing, shared, independent of programs and centrally protected — everything a pile of files can never be.
Where the DBMS Sits — The Central Gatekeeper
No program touches raw disk directly — every request flows through the DBMS. That single chokepoint is exactly what makes data independence, security and concurrency control enforceable.
Advantages of a DBMS
Disadvantages of a DBMS
When Is a Plain File Actually Fine?
- Data is shared by many users / programs
- Data is large and keeps growing
- Consistency & integrity really matter
- You need ad-hoc querying and reports
- Concurrent access is required
- Security and recovery are critical
- Data is tiny and rarely changes
- Only one program / user touches it
- It is a one-off or throwaway task
- No complex relationships exist
- No concurrent access is needed
- Speed of setup beats everything else
"Use a database" is not always right. A config file or CSV is perfectly respectable for small, private, simple data. Reach for a DBMS the moment sharing, scale, or safety enters the picture.
The Database Approach in Python (sqlite3)
One source of truth: Riya is stored once; marks reference her id, not her name.
import sqlite3
conn = sqlite3.connect('college.db')
# Structure defined once — the DBMS stores it in its catalog
conn.execute("CREATE TABLE students(id INTEGER PRIMARY KEY, name TEXT, dept TEXT)")
conn.execute("""CREATE TABLE marks(
sid INTEGER, subject TEXT, score INTEGER,
FOREIGN KEY(sid) REFERENCES students(id))""") # referential integrity
# Ask a brand-new question with SQL — no new program needed
rows = conn.execute("""SELECT s.name, s.dept, m.score FROM marks m
JOIN students s ON s.id = m.sid
WHERE m.subject = 'DBMS' ORDER BY m.score DESC""")
for name, dept, score in rows:
print(f" {name} ({dept}) -> {score}")
Wrap writes in a transaction (with conn:). If a bad row fails mid-way, the whole block
rolls back as if it never happened — protection a loose file can never give.
Key Takeaways — Rules 1 to 4
Key Takeaways — Rules 5 to 7
The fatal flaw of files is coupling; the gift of a DBMS is the chokepoint. Everything else in databases builds on these two ideas.
Bringing It Together — One Source of Truth
Hostel, Library and Exams are just views over one shared record. This single architectural choice — a database system instead of files — is why the whole field exists. Everything next (data models, the relational model, SQL, normalization, transactions) builds on it.
🗄️ End of tutorial · Press ← to review, or click Restart