A linked list lives in your program. A database outlives it.
CS205ES taught you to arrange data inside a running program's memory. This course asks what happens after the program exits — and why a folder of files is not a good enough answer once many people and many programs share the same data.
After this lesson
You should be able to
- Explain at least three problems a plain file system has that a DBMS solves.
- Describe what each of the five units adds, and how it builds on CS205ES.
The BST lives only while your program runs
In CS205ES, you built a binary search tree entirely inside your program's memory. It was fast, it was organised, and the moment the program ended, it vanished completely. If you wanted that data tomorrow, you had to rebuild it from scratch, or save it to a file and re-read that file yourself.
Now imagine an entire college needs the same student records — the fee office, the exam office, and the library, all at once, all day, every day. Each office writing its own file quickly creates three different copies of the truth: a student who paid a fee shows as unpaid in one file because nobody updated it there. A database exists to be the one shared, always-available, trustworthy copy that many programs read and write safely at the same time.
Three specific things a file system cannot promise
First, data redundancy and inconsistency — the same fact stored in two files can drift apart, exactly like the fee example above. Second, difficulty accessing data — answering "which students owe a fee and also have overdue library books" needs a new custom program every time, because plain files have no shared query language. Third, concurrent access anomalies — two programs writing the same file at once can corrupt it, with no built-in protection.
A DBMS (Database Management System) is software built specifically to remove these three problems — it gives every authorised program a shared, consistent, safely-concurrent view of the same data, through one query language instead of custom file-reading code.
The five units, as one story
Unit 1 finishes with how to model the real world as entities and relationships, before any table exists. Unit 2 turns that model into actual relational tables with rules, plus two formal query languages. Unit 3 is SQL — the language you actually type — plus normalization, the discipline that keeps a table design honest. Unit 4 covers transactions: how many operations happen safely as one unit even when things run at the same time or the power fails. Unit 5 closes with how data is actually stored and indexed on disk, so a table with a million rows can still be searched fast — a direct callback to the tree structures from CS205ES's Units 2 and 3.
Try it yourself
Think of a phone shop that currently keeps sales, stock, and customer complaints in three separate Excel files. List two concrete problems this setup will eventually hit, using the vocabulary from this lesson.
Need a hint?
What happens when a phone is marked sold in the sales file but still shows as in-stock in the stock file? What happens if two staff members edit the stock file at the same time?
Check the worked solution
This is data redundancy and inconsistency (the same phone's stock status disagrees across two files) and a concurrent access anomaly (two simultaneous edits to the stock file can silently overwrite one another). A DBMS solves both by making stock a single shared table with rules that keep every read and write consistent.
Quick check
Why can two programs writing the same plain file at the same time be dangerous in a way a DBMS is specifically designed to prevent?
Why this lesson exists
Syllabus mapping
Database System Applications, database System VS file System
Maps to course outcome CO1.