Q.What are the limitations of file system that can be overcome by a relational DBMS?

For decades, organisations kept records the way an old office keeps them: in files. A school might have one file of student details, another of fee payments, another of exam results — each created and read by its own program. This file-based approach works at small scale, but it carries built-in weaknesses that grow more painful as data grows. Understanding these limitations is the whole motivation for databases, so they deserve a careful look.

The first trouble is data redundancy — the same fact stored in several places. The student's name and address sit in the admissions file, again in the fees file, again in the examination file. Redundancy wastes storage, but the deeper injury follows immediately: data inconsistency. When the student's address changes, it must be corrected in every file. Miss one, and the organisation now holds two different addresses with no way to know which is true. The files have begun to contradict each other.

Beyond redundancy, flat files struggle in several distinct ways:

• Difficult access to data. Every new question needs a new program. If nobody wrote a program to list students with pending fees who also failed an exam, that answer simply cannot be produced without fresh programming — the file will not answer questions it was not designed for.
• Data isolation. Related information is scattered across separate files, often in different formats, so combining it is laborious.
• Program-data dependence. Each program is written around the exact layout of its file. Change the file's structure — add one field — and every program reading it must be rewritten.
• No proper concurrent access. When two clerks update the same file at the same moment, one update can silently overwrite the other, corrupting the record.
• Weak security. Access control is all-or-nothing at the file level. There is no clean way to let a clerk see names but not salaries when both live in the same file. …