Traditional file processing system or simple file processing system refers to the first
computer-based approach of handling the commercial or business applications. That is
why it is also called a replacement of the manual file system. Before the use computers,
the data in the offices or business was maintained in the files (well in that perspective
some offices may still be considered in the pre-computer age). Obviously, it was
laborious, time consuming, inefficient, especially in case of large organizations.
Computers, initially designed for the engineering purposes were though of as blessing,
since they helped efficient management but file processing environment simply
transformed manual file work to computers. So processing became very fast and efficient,
but as file processing systems were used, their problems were also realized and some of
them were very severe as discussed later.
It is not necessary that we understand the working of the file processing environment for
the understanding of the database and its working. However, a comparison between the
characteristics of the two definitely helps to understand the advantages of the databases
and their working approach. That is why the characteristics of the traditional file
processing system environment have been discussed briefly here.
A typical file processing environment
The diagram presents a typical traditional file processing environment. The main point
being highlighted is the program and data interdependence, that is, program and data
depend on each other, well they depend too much on each other. As a result any change
in one affects the other as well. This is something that makes a change very painful or
problematic for the designers or developers of the system. What do we mean by change
and why do we need to change the system at all. These things are explained in the
following.
The systems (even the file processing systems) are created after a very detailed analysis
of the requirements of the organizations. But it is not possible to develop a system that
does not need a change afterwards. There could be many reasons, mainly being that the
users get the real taste of the system when it is established. That is, users tell the analysts
or designers their requirements, the designers design and later develop the system based
on those requirements, but when system is developed and presented to the users, it is only
then they realize the outcome of the effort. Now it could be slightly and (unfortunately)
sometimes very different from what they expected or wanted it to be. So the users ask
changes, minor or major. Another reason for the change is the change in the requirements.
For example, previously the billing was performed in an organization on the monthly
being highlighted is the program and data interdependence, that is, program and data
depend on each other, well they depend too much on each other. As a result any change
in one affects the other as well. This is something that makes a change very painful or
problematic for the designers or developers of the system. What do we mean by change
and why do we need to change the system at all. These things are explained in the
following.
The systems (even the file processing systems) are created after a very detailed analysis
of the requirements of the organizations. But it is not possible to develop a system that
does not need a change afterwards. There could be many reasons, mainly being that the
users get the real taste of the system when it is established. That is, users tell the analysts
or designers their requirements, the designers design and later develop the system based
on those requirements, but when system is developed and presented to the users, it is only
then they realize the outcome of the effort. Now it could be slightly and (unfortunately)
sometimes very different from what they expected or wanted it to be. So the users ask
changes, minor or major. Another reason for the change is the change in the requirements.
For example, previously the billing was performed in an organization on the monthly
basis, now company has decided to bill the customers after every ten days. Since the bills
are being generated from the computer (using file processing system), this change has to
be incorporated in the system. Yet another example is that, initially bills did not contain
the address of the customer, now the company wants the address to be placed on the bill,
so here is change. There could be many more examples, and it is so common that we can
say that almost all systems need changes, so system development is always an on-going
process.
So we need changes in the system, but due to program-data interdependence these
changes in the systems were very hard to make. A change in one will affect the other
whether related or not. For example, suppose data about the customer bills is stored in the
file, and different programs use this file for different purposes, like adding data into the
bills file, to compute the bill and to print the bill. Now the company asks to add the
customers’ address in the bills, for this we have to change the structure of the bill file and
also the program that prints the bill. Well, this was necessary, but the painful thing is that
the other programs that are using these bills files but are not concerned with the printing
of the bills or the change in the bill will also have to be changed, well; this is needless
and causes extra, unnecessary effort.
Another major drawback in the traditional file system environment is the non-sharing of
data. It means if different systems of an organization are using some common data then
rather than storing it once and sharing it, each system stores data in separate files. This
creates the problem of redundancy or wastage of storage and on the other hand the
problem on inconsistency. The change in the data in one system sometimes is not
reflected in the same data stored in other system. So different systems in organization;
store different facts about same thing. This is inconsistency as is shown in figure below.
are being generated from the computer (using file processing system), this change has to
be incorporated in the system. Yet another example is that, initially bills did not contain
the address of the customer, now the company wants the address to be placed on the bill,
so here is change. There could be many more examples, and it is so common that we can
say that almost all systems need changes, so system development is always an on-going
process.
So we need changes in the system, but due to program-data interdependence these
changes in the systems were very hard to make. A change in one will affect the other
whether related or not. For example, suppose data about the customer bills is stored in the
file, and different programs use this file for different purposes, like adding data into the
bills file, to compute the bill and to print the bill. Now the company asks to add the
customers’ address in the bills, for this we have to change the structure of the bill file and
also the program that prints the bill. Well, this was necessary, but the painful thing is that
the other programs that are using these bills files but are not concerned with the printing
of the bills or the change in the bill will also have to be changed, well; this is needless
and causes extra, unnecessary effort.
Another major drawback in the traditional file system environment is the non-sharing of
data. It means if different systems of an organization are using some common data then
rather than storing it once and sharing it, each system stores data in separate files. This
creates the problem of redundancy or wastage of storage and on the other hand the
problem on inconsistency. The change in the data in one system sometimes is not
reflected in the same data stored in other system. So different systems in organization;
store different facts about same thing. This is inconsistency as is shown in figure below.
good work
ReplyDelete