Limitations of the File-Based Approach
This brief description of traditional file-based systems should be sufficient to discuss the
limitations of this approach. We list five problems in Table 1.1.
Separation and isolation of data
When data is isolated in separate files, it is more difficult to access data that should be
available. For example, if we want to produce a list of all houses that match the requirements
of clients, we first need to create a temporary file of those clients who have ‘house’
as the preferred type. We then search the PropertyForRent file for those properties where the
property type is ‘house’ and the rent is less than the client’s maximum rent. With file
systems, such processing is difficult. The application developer must synchronize the processing
of two files to ensure the correct data is extracted. This difficulty is compounded
if we require data from more than two files.
Duplication of data
Owing to the decentralized approach taken by each department, the file-based approach
encouraged, if not necessitated, the uncontrolled duplication of data. For example, in
Figure 1.5 we can clearly see that there is duplication of both property and client details in
the Sales and Contracts Departments. Uncontrolled duplication of data is undesirable for
several reasons, including:
n Duplication is wasteful. It costs time and money to enter the data more than once.
n It takes up additional storage space, again with associated costs. Often, the duplication
of data can be avoided by sharing data files.
n Perhaps more importantly, duplication can lead to loss of data integrity; in other words,
the data is no longer consistent. For example, consider the duplication of data between
the Payroll and Personnel Departments described above. If a member of staff moves
house and the change of address is communicated only to Personnel and not to Payroll,
the person’s payslip will be sent to the wrong address. A more serious problem occurs
if an employee is promoted with an associated increase in salary. Again, the change
is notified to Personnel but the change does not filter through to Payroll. Now, the
employee is receiving the wrong salary. When this error is detected, it will take time
and effort to resolve. Both these examples illustrate inconsistencies that may result
from the duplication of data. As there is no automatic way for Personnel to update
the data in the Payroll files, it is not difficult to foresee such inconsistencies arising.
Even if Payroll is notified of the changes, it is possible that the data will be entered
incorrectly.
Data dependence
As we have already mentioned, the physical structure and storage of the data files and
records are defined in the application code. This means that changes to an existing structure
are difficult to make. For example, increasing the size of the PropertyForRent address
field from 40 to 41 characters sounds like a simple change, but it requires the creation of
a one-off program (that is, a program that is run only once and can then be discarded) that
converts the PropertyForRent file to the new format. This program has to:
n open the original PropertyForRent file for reading;
n open a temporary file with the new structure;
n read a record from the original file, convert the data to conform to the new structure, and
write it to the temporary file. Repeat this step for all records in the original file;
n delete the original PropertyForRent file;
n rename the temporary file as PropertyForRent.
In addition, all programs that access the PropertyForRent file must be modified to conform
to the new file structure. There might be many such programs that access the
PropertyForRent file. Thus, the programmer needs to identify all the affected programs,
modify them, and then retest them. Note that a program does not even have to use the
address field to be affected: it has only to use the PropertyForRent file. Clearly, this could
be very time-consuming and subject to error. This characteristic of file-based systems is
known as program–data dependence.
Incompatible file formats
Because the structure of files is embedded in the application programs, the structures are
dependent on the application programming language. For example, the structure of a file
generated by a COBOL program may be different from the structure of a file generated by
a ‘C’ program. The direct incompatibility of such files makes them difficult to process
jointly.
For example, suppose that the Contracts Department wants to find the names and
addresses of all owners whose property is currently rented out. Unfortunately, Contracts
does not hold the details of property owners; only the Sales Department holds these.
However, Contracts has the property number (propertyNo), which can be used to find the
corresponding property number in the Sales Department’s PropertyForRent file. This file
holds the owner number (ownerNo), which can be used to find the owner details in the
PrivateOwner file. The Contracts Department programs in COBOL and the Sales Department
programs in ‘C’. Therefore, to match propertyNo fields in the two PropertyForRent files
requires an application developer to write software to convert the files to some common
format to facilitate processing. Again, this can be time-consuming and expensive.
Fixed queries/proliferation of application programs
From the end-user’s point of view, file-based systems proved to be a great improvement
over manual systems. Consequently, the requirement for new or modified queries grew.
However, file-based systems are very dependent upon the application developer, who has
to write any queries or reports that are required. As a result, two things happened. In some
organizations, the type of query or report that could be produced was fixed. There was no
facility for asking unplanned (that is, spur-of-the-moment or ad hoc) queries either about
the data itself or about which types of data were available.
In other organizations, there was a proliferation of files and application programs.
Eventually, this reached a point where the DP Department, with its current resources,
could not handle all the work. This put tremendous pressure on the DP staff, resulting
in programs that were inadequate or inefficient in meeting the demands of the users,
documentation that was limited, and maintenance that was difficult. Often, certain types of
functionality were omitted including:
n there was no provision for security or integrity;
n recovery, in the event of a hardware or software failure, was limited or non-existent;
n access to the files was restricted to one user at a time – there was no provision for shared
access by staff in the same department.
In either case, the outcome was not acceptable. Another solution was required.
This brief description of traditional file-based systems should be sufficient to discuss the
limitations of this approach. We list five problems in Table 1.1.
Separation and isolation of data
When data is isolated in separate files, it is more difficult to access data that should be
available. For example, if we want to produce a list of all houses that match the requirements
of clients, we first need to create a temporary file of those clients who have ‘house’
as the preferred type. We then search the PropertyForRent file for those properties where the
property type is ‘house’ and the rent is less than the client’s maximum rent. With file
systems, such processing is difficult. The application developer must synchronize the processing
of two files to ensure the correct data is extracted. This difficulty is compounded
if we require data from more than two files.
Duplication of data
Owing to the decentralized approach taken by each department, the file-based approach
encouraged, if not necessitated, the uncontrolled duplication of data. For example, in
Figure 1.5 we can clearly see that there is duplication of both property and client details in
the Sales and Contracts Departments. Uncontrolled duplication of data is undesirable for
several reasons, including:
n Duplication is wasteful. It costs time and money to enter the data more than once.
n It takes up additional storage space, again with associated costs. Often, the duplication
of data can be avoided by sharing data files.
n Perhaps more importantly, duplication can lead to loss of data integrity; in other words,
the data is no longer consistent. For example, consider the duplication of data between
the Payroll and Personnel Departments described above. If a member of staff moves
house and the change of address is communicated only to Personnel and not to Payroll,
the person’s payslip will be sent to the wrong address. A more serious problem occurs
if an employee is promoted with an associated increase in salary. Again, the change
is notified to Personnel but the change does not filter through to Payroll. Now, the
employee is receiving the wrong salary. When this error is detected, it will take time
and effort to resolve. Both these examples illustrate inconsistencies that may result
from the duplication of data. As there is no automatic way for Personnel to update
the data in the Payroll files, it is not difficult to foresee such inconsistencies arising.
Even if Payroll is notified of the changes, it is possible that the data will be entered
incorrectly.
Data dependence
As we have already mentioned, the physical structure and storage of the data files and
records are defined in the application code. This means that changes to an existing structure
are difficult to make. For example, increasing the size of the PropertyForRent address
field from 40 to 41 characters sounds like a simple change, but it requires the creation of
a one-off program (that is, a program that is run only once and can then be discarded) that
converts the PropertyForRent file to the new format. This program has to:
n open the original PropertyForRent file for reading;
n open a temporary file with the new structure;
n read a record from the original file, convert the data to conform to the new structure, and
write it to the temporary file. Repeat this step for all records in the original file;
n delete the original PropertyForRent file;
n rename the temporary file as PropertyForRent.
In addition, all programs that access the PropertyForRent file must be modified to conform
to the new file structure. There might be many such programs that access the
PropertyForRent file. Thus, the programmer needs to identify all the affected programs,
modify them, and then retest them. Note that a program does not even have to use the
address field to be affected: it has only to use the PropertyForRent file. Clearly, this could
be very time-consuming and subject to error. This characteristic of file-based systems is
known as program–data dependence.
Incompatible file formats
Because the structure of files is embedded in the application programs, the structures are
dependent on the application programming language. For example, the structure of a file
generated by a COBOL program may be different from the structure of a file generated by
a ‘C’ program. The direct incompatibility of such files makes them difficult to process
jointly.
For example, suppose that the Contracts Department wants to find the names and
addresses of all owners whose property is currently rented out. Unfortunately, Contracts
does not hold the details of property owners; only the Sales Department holds these.
However, Contracts has the property number (propertyNo), which can be used to find the
corresponding property number in the Sales Department’s PropertyForRent file. This file
holds the owner number (ownerNo), which can be used to find the owner details in the
PrivateOwner file. The Contracts Department programs in COBOL and the Sales Department
programs in ‘C’. Therefore, to match propertyNo fields in the two PropertyForRent files
requires an application developer to write software to convert the files to some common
format to facilitate processing. Again, this can be time-consuming and expensive.
Fixed queries/proliferation of application programs
From the end-user’s point of view, file-based systems proved to be a great improvement
over manual systems. Consequently, the requirement for new or modified queries grew.
However, file-based systems are very dependent upon the application developer, who has
to write any queries or reports that are required. As a result, two things happened. In some
organizations, the type of query or report that could be produced was fixed. There was no
facility for asking unplanned (that is, spur-of-the-moment or ad hoc) queries either about
the data itself or about which types of data were available.
In other organizations, there was a proliferation of files and application programs.
Eventually, this reached a point where the DP Department, with its current resources,
could not handle all the work. This put tremendous pressure on the DP staff, resulting
in programs that were inadequate or inefficient in meeting the demands of the users,
documentation that was limited, and maintenance that was difficult. Often, certain types of
functionality were omitted including:
n there was no provision for security or integrity;
n recovery, in the event of a hardware or software failure, was limited or non-existent;
n access to the files was restricted to one user at a time – there was no provision for shared
access by staff in the same department.
In either case, the outcome was not acceptable. Another solution was required.
No comments: