Multiple choiceQuestion 1 · Recall
Loading…
By the end you can name the problems of storing data in separate files, and say which feature of a database management system (DBMS) solves each one.
Before databases, each application kept its own files. A school might have:
Each file is designed for one program. That is fine until the same fact has to live in more than one place — and in a school, it always does.
| Problem | What it looks like in practice |
|---|---|
| data redundancy | the same data is stored many times: a student's address appears in three files |
| data inconsistency | the copies disagree: the office updates an address, the library file still has the old one |
| program–data dependence | each program knows the file's exact layout, so changing a field means rewriting every program that uses it |
| data isolation | data is spread across files in different formats, so it is hard to combine "which students take physics and have an overdue book?" |
| poor security | rights are set per file, so there is no central control over who sees which fields |
| limited concurrent access | two users editing the same file can overwrite each other's changes |
| weak integrity checking | nothing stops a date of birth being stored as "31/02/2010" |
| no central backup or recovery | each file is backed up (or not) separately, and a crash can leave copies out of step |
| no ad hoc queries | a new question means writing a new program, not just asking the data |
Database management system (DBMS)
Software that sits between the users and the stored data, and manages that data centrally: storing it, controlling access, enforcing rules, keeping copies consistent, allowing queries, and providing backup and recovery.
The application programs no longer read the files directly; they ask the DBMS.
This mapping is what exam questions ask for, so learn it as pairs:
| Problem of files | DBMS feature that fixes it |
|---|---|
| redundancy | a single central database, with each fact stored once; normalisation removes repeated groups |
| inconsistency | one copy only, so an update happens in one place; the DBMS enforces referential integrity |
| program–data dependence | data independence: programs use the database structure through the DBMS, so fields can change without rewriting every program |
| data isolation | one query language (SQL) over all the data, so records from different tables can be combined |
| poor security | central access rights: users, passwords and permissions set per table or per field |
| concurrent access | concurrency control (locking and transactions) so two users cannot corrupt each other's changes |
| weak integrity | validation and integrity constraints: data types, NOT NULL, UNIQUE, primary and foreign keys, range checks |
| no backup | central backup and recovery, including transaction logs to restore a consistent state |
| no ad hoc queries | query tools and SQL, so new questions can be answered without new programs |
Imagine three teachers each keeping a private notebook of the same class list. When a student changes address, someone has to remember to tell all three — and someone always forgets.
A database is the single class register on the staffroom wall. There is one entry to correct, everyone reads the same entry, and the head can decide which teachers may write in it.
Where the analogy stops: a DBMS also protects against two people writing at the same moment, and can undo a half-finished change after a crash. Paper cannot.
Worked example: Worked example: the duplicated customer file
An online shop keeps customers.txt for its website and orders.txt for its accounts
software. A customer changes her address. The website is updated; the accounts file is not.
Explain the problems this causes and how a DBMS would prevent them.