File System versus DBMS
The file based approach fails on redundancy, inconsistency, isolation, atomicity, concurrency, security and integrity. Each failure maps to one specific feature a DBMS provides, and that mapping is the most examined table in the subject.
- Concept
- The seven problems, one by one
- 1. Data redundancy
- 2. Data inconsistency
- 3. Difficulty of access
- 4. Data isolation
- 5. Integrity problems
- 6. Atomicity problems
- 7. Concurrent access and security
- The comparison table
- Where a file system is still the right choice
- Example
- Common mistakes
- Exam and interview questions
- Practice
- Conclusion
-
DBMS Fundamentals
- Data, Information and Databases
- What a DBMS Is and Why It Exists
- File System versus DBMS
- Advantages and Limitations of a DBMS
- Database Users and the Role of the DBA
- Three Level Architecture and Data Abstraction
- Logical and Physical Data Independence
- Schema, Instance and Metadata
- Database Applications and the Database System Environment
- Database Architecture
- Data Models
-
ER Model
- Entities, Entity Sets and Entity Types
- Types of Attributes in the ER Model
- Keys in the ER Model
- Relationships, Relationship Sets and Degree
- Cardinality and Participation Constraints
- Strong and Weak Entities
- Drawing and Reading ER Diagrams
- Extended ER: Generalisation, Specialisation and Aggregation
- Converting an ER Diagram into Relational Tables
- ER Design Projects
- Relational Model
- Relational Algebra
- Functional Dependencies
-
Normalisation
- Why Normalisation Exists: Anomalies and Redundancy
- First Normal Form
- Second Normal Form and Partial Dependency
- Third Normal Form and Transitive Dependency
- BCNF and BCNF Decomposition
- 4NF, 5NF, Multivalued and Join Dependencies
- Lossless Decomposition and Dependency Preservation
- Complete Worked Normalisation: Unnormalised to BCNF
- Denormalisation and When to Use It
Concept
Before databases, applications stored records in ordinary files and each program contained its own code for reading and writing them. That approach is called the file based system, and understanding exactly how it fails is the fastest way to understand why every DBMS feature exists.
The seven problems, one by one
1. Data redundancy
Each department keeps its own file. The accounts office stores a student address, the hostel office stores the same address, the library stores it again.
accounts.dat roll 21, Meera, 14 Anna Salai, Chennai
hostel.dat roll 21, Meera, 14 Anna Salai, Chennai
library.dat roll 21, Meera, 14 Anna Salai, Chennai
Three copies. Three chances to be wrong.2. Data inconsistency
Meera moves house. The hostel file is updated. The other two are not. The database now asserts two different addresses for one person, and no part of the system objects.
3. Difficulty of access
A new question — which hostel residents have unreturned library books? — needs a new program, because no general query facility exists. Every new question costs development time.
4. Data isolation
The three files are in different formats, written by different teams, possibly on different machines. Combining them is a project rather than a query.
5. Integrity problems
The rule marks must be between 0 and 100 lives inside whichever program happens to enforce it. A second program written later does not know the rule exists, and writes 150.
6. Atomicity problems
A transfer that updates two files crashes between them. There is no mechanism that knows the two writes belonged together, so the data is left half changed.
7. Concurrent access and security
Two clerks read the same balance of 10,000, each subtracts 2,000, each writes back 8,000. Two withdrawals happened and only one was recorded. Separately, file permissions are all or nothing — a user who can read the file can read every salary in it.
The comparison table
| Aspect | File based system | DBMS |
|---|---|---|
| Redundancy | High, uncontrolled | Controlled through design and keys |
| Consistency | Not enforced | Enforced by constraints |
| Data access | New program per question | Ad hoc queries |
| Data independence | None — programs depend on file layout | Logical and physical independence |
| Integrity | Coded into each application | Declared once, enforced by the system |
| Atomicity | Not available | Transactions |
| Concurrency | Unsafe or serialised by hand | Locking and isolation levels |
| Recovery | Restore whole files from a copy | Log based recovery to a consistent point |
| Security | File level only | Table, column and row level privileges |
| Metadata | Lives in program code | Stored in the system catalog |
| Backup | Manual, whole file | Built in, often online |
| Cost and overhead | Low | Higher: software, memory, expertise |
Where a file system is still the right choice
Answering this well separates a memorised answer from an understood one.
- A single user, single program, small dataset — a configuration file needs no DBMS.
- Large binary objects such as video, where the useful operations are read and stream, not query.
- Append only logs read sequentially by one tool.
- Environments where the overhead of installing and administering a DBMS exceeds the benefit.
Example
THE LOST UPDATE, in a file system
clerk A clerk B
read balance -> 10000
read balance -> 10000
10000 - 2000 = 8000
10000 - 2000 = 8000
write 8000
write 8000
Two withdrawals of 2,000. Final balance 8,000.
6,000 was expected. 2,000 has been created from nothing.
THE SAME SEQUENCE, in a DBMS
clerk A takes an exclusive lock on the row.
clerk B waits.
A writes 8,000 and commits, releasing the lock.
B now reads 8,000, writes 6,000 and commits.
Final balance 6,000. Correct.Common mistakes
- Saying a DBMS removes redundancy completely. It controls redundancy. Foreign keys repeat a value deliberately, and denormalisation repeats more on purpose.
- Listing only redundancy and security. The full list is seven problems; examiners award marks per point.
- Claiming a DBMS is always better. It costs money, memory and expertise. Name a case where a file is correct and the answer improves.
- Confusing data isolation with transaction isolation. In this list, isolation means files trapped in incompatible formats. In transactions, isolation is the I of ACID. Same word, different idea.
Exam and interview questions
- List and explain the seven drawbacks of the file based approach.
- Draw the table comparing file systems and a DBMS on at least eight aspects.
- Explain the lost update problem with a schedule, and state how a DBMS prevents it.
- Give two situations where a file system is still preferable to a DBMS.
- Distinguish data isolation from transaction isolation.
Practice
- Take a college with separate exam, fee and hostel offices. List every fact stored in more than one office and describe the inconsistency that follows a change of address.
- Write the lost update schedule for two clerks depositing rather than withdrawing, and show the incorrect result.
- For each of the seven problems, name the single DBMS feature that solves it.
Conclusion
Every feature of a DBMS is an answer to a specific failure of the file based approach. Learn the seven problems and their solutions as pairs, and most of the rest of this subject stops feeling like a list of unrelated topics.