Limitations of a File System

A file system serves a school or an office well enough while the data is small. The trouble starts as the number of files increases and the volume of data grows — the arrangement becomes progressively harder to handle. Six specific weaknesses explain why, and each one can be seen in the school's own STUDENT and ATTENDANCE files.

(A) Difficulty in Access

A file is only a container; it provides no mechanism of its own to retrieve data. Whatever data sits in a file system is reached through application programs written for the purpose. The person who writes those programs cannot anticipate every way in which the data might one day be needed. When a new, unanticipated requirement appears — a report in a different format, a new kind of search — the data cannot simply be pulled out in the required form; a fresh application program has to be written for it.

(B) Data Redundancy

Redundancy means the same data being duplicated in different places (different files). The school's files show it twice over:

• The student names are maintained in both the STUDENT file and the ATTENDANCE file.
• Within the STUDENT file itself, the students with roll numbers 3 and 5 have the same guardian, so the same guardian name is stored twice.

In a file system this duplication is difficult to avoid. It costs excess storage, and — more dangerously — it opens the door to data inconsistency.

(C) Data Inconsistency

Inconsistency occurs when copies of the same data kept in different places stop matching each other. Suppose a student wants the spelling of her name corrected: the change must be made in the SName column of both files. If a student leaves the school, the details must be deleted from both files. Since the two files are maintained by different people, a change may well be applied in one file and missed in the other — after which the student's name is simply different (inconsistent) in the two files, and neither reader knows which version to trust.

(D) Data Isolation

The STUDENT file and the ATTENDANCE file are both about students, yet nothing connects them — there is no link or mapping between the two files, because a file system does not support data mapping. The school therefore has to write separate programs to access each file.

The problem compounds in larger systems. When data files are created by different people at different times, each file may end up in its own format, since each was created in isolation. Writing a new application that draws data from files kept at multiple places then becomes genuinely hard: the programmer must first understand the underlying structure of every file involved.

(E) Data Dependence

Data in a file is stored in a specific format or structure. Application programs are written against that structure — so if the structure or format of the file is changed, every existing program that accesses the file must be changed as well, or it may stop working correctly. This tight coupling between the stored data and the programs is called data dependence. Its practical cost: updating the structure of one data file forces modifications in all the application programs that access it.

(F) Controlled Data Sharing

Different categories of users work with the same data — teachers, office staff, parents — and ideally not every user should be able to access all of it, or do everything with it. Guardians and office staff, for example, should be able to see the attendance data but not modify or delete it: they need limited, read-only access to the ATTENDANCE file, while only the teacher should be able to update attendance. Enforcing this kind of selective access control is very difficult in a file system, where files are reached through application programs rather than through any built-in permission mechanism.

The full ATTENDANCE file

The complete contents of the ATTENDANCE file (Table 7.2), maintained by the class teacher, show the shape of the data these limitations act upon:

| AttendanceDate | RollNumber | SName | AttendanceStatus |

|---|---|---|---| …