Traditional File-Based Systems
It is almost a tradition that comprehensive database books introduce the database system
with a review of its predecessor, the file-based system. We will not depart from this tradition.
Although the file-based approach is largely obsolete, there are good reasons for studying it:
n Understanding the problems inherent in file-based systems may prevent us from repeating
these problems in database systems. In other words, we should learn from our earlier
mistakes. Actually, using the word ‘mistakes’ is derogatory and does not give any
cognizance to the work that served a useful purpose for many years. However, we have
learned from this work that there are better ways to handle data.
n If you wish to convert a file-based system to a database system, understanding how the
file system works will be extremely useful, if not essential.
File-Based Approach
File-based A collection of application programs that perform services for the
system end-users such as the production of reports. Each program defines
and manages its own data.
File-based systems were an early attempt to computerize the manual filing system that
we are all familiar with. For example, in an organization a manual file is set up to hold
all external and internal correspondence relating to a project, product, task, client, or
employee. Typically, there are many such files, and for safety they are labeled and stored
in one or more cabinets. For security, the cabinets may have locks or may be located
in secure areas of the building. In our own home, we probably have some sort of filing
system which contains receipts, guarantees, invoices, bank statements, and such like. When
we need to look something up, we go to the filing system and search through the system
starting from the first entry until we find what we want. Alternatively, we may have an
indexing system that helps locate what we want more quickly. For example, we may have
divisions in the filing system or separate folders for different types of item that are in some
way logically related.
The manual filing system works well while the number of items to be stored is small. It
even works quite adequately when there are large numbers of items and we have only to
store and retrieve them. However, the manual filing system breaks down when we have to
cross-reference or process the information in the files. For example, a typical real estate
agent’s office might have a separate file for each property for sale or rent, each potential
buyer and renter, and each member of staff. Consider the effort that would be required to
answer the following questions:
n What three-bedroom properties do you have for sale with a garden and garage?
n What flats do you have for rent within three miles of the city center?
n What is the average rent for a two-bedroom flat?
n What is the total annual salary bill for staff?
n How does last month’s turnover compare with the projected figure for this month?
n What is the expected monthly turnover for the next financial year?
Increasingly, nowadays, clients, senior managers, and staff want more and more information.
In some areas there is a legal requirement to produce detailed monthly, quarterly, and
annual reports. Clearly, the manual system is inadequate for this type of work. The filebased
system was developed in response to the needs of industry for more efficient data
access. However, rather than establish a centralized store for the organization’s operational
data, a decentralized approach was taken, where each department, with the assistance of
Data Processing (DP) staff, stored and controlled its own data. To understand what this
means, consider the DreamHome example.
The Sales Department is responsible for the selling and renting of properties. For example,
whenever a client approaches the Sales Department with a view to marketing his or her
property for rent, a form is completed, similar to that shown in Figure 1.1(a). This gives
details of the property such as address and number of rooms together with the owner’s
details. The Sales Department also handles inquiries from clients, and a form similar to
the one shown in Figure 1.1(b) is completed for each one. With the assistance of the DP
Department, the Sales Department creates an information system to handle the renting of
property. The system consists of three files containing property, owner, and client details,
as illustrated in Figure 1.2. For simplicity, we omit details relating to members of staff,
branch offices, and business owners.
The Contracts Department is responsible for handling the lease agreements associated
with properties for rent. Whenever a client agrees to rent a property, a form is filled in by
one of the Sales staff giving the client and property details, as shown in Figure 1.3. This
form is passed to the Contracts Department which allocates a lease number and completes
the payment and rental period details. Again, with the assistance of the DP Department,
the Contracts Department creates an information system to handle lease agreements. The
system consists of three files storing lease, property, and client details, containing similar
data to that held by the Sales Department, as illustrated in Figure 1.4.
The situation is illustrated in Figure 1.5. It shows each department accessing their own
files through application programs written specially for them. Each set of departmental
application programs handles data entry, file maintenance, and the generation of a fixed set
of specific reports. What is more important, the physical structure and storage of the data
files and records are defined in the application code.
We can find similar examples in other departments. For example, the Payroll Department
stores details relating to each member of staff’s salary, namely:
StaffSalary(staffNo, fName, lName, sex, salary, branchNo)
The Personnel Department also stores staff details, namely:
Staff(staffNo, fName, lName, position, sex, dateOfBirth, salary, branchNo)
It can be seen quite clearly that there is a significant amount of duplication of data in
these departments, and this is generally true of file-based systems. Before we discuss the
limitations of this approach, it may be useful to understand the terminology used in filebased
systems. A file is simply a collection of records, which contains logically related
data. For example, the PropertyForRent file in Figure 1.2 contains six records, one for each
property. Each record contains a logically connected set of one or more fields, where each
field represents some characteristic of the real-world object that is being modeled. In
Figure 1.2, the fields of the PropertyForRent file represent characteristics of properties, such
as address, property type, and number of rooms.
It is almost a tradition that comprehensive database books introduce the database system
with a review of its predecessor, the file-based system. We will not depart from this tradition.
Although the file-based approach is largely obsolete, there are good reasons for studying it:
n Understanding the problems inherent in file-based systems may prevent us from repeating
these problems in database systems. In other words, we should learn from our earlier
mistakes. Actually, using the word ‘mistakes’ is derogatory and does not give any
cognizance to the work that served a useful purpose for many years. However, we have
learned from this work that there are better ways to handle data.
n If you wish to convert a file-based system to a database system, understanding how the
file system works will be extremely useful, if not essential.
File-Based Approach
File-based A collection of application programs that perform services for the
system end-users such as the production of reports. Each program defines
and manages its own data.
File-based systems were an early attempt to computerize the manual filing system that
we are all familiar with. For example, in an organization a manual file is set up to hold
all external and internal correspondence relating to a project, product, task, client, or
employee. Typically, there are many such files, and for safety they are labeled and stored
in one or more cabinets. For security, the cabinets may have locks or may be located
in secure areas of the building. In our own home, we probably have some sort of filing
system which contains receipts, guarantees, invoices, bank statements, and such like. When
we need to look something up, we go to the filing system and search through the system
starting from the first entry until we find what we want. Alternatively, we may have an
indexing system that helps locate what we want more quickly. For example, we may have
divisions in the filing system or separate folders for different types of item that are in some
way logically related.
The manual filing system works well while the number of items to be stored is small. It
even works quite adequately when there are large numbers of items and we have only to
store and retrieve them. However, the manual filing system breaks down when we have to
cross-reference or process the information in the files. For example, a typical real estate
agent’s office might have a separate file for each property for sale or rent, each potential
buyer and renter, and each member of staff. Consider the effort that would be required to
answer the following questions:
n What three-bedroom properties do you have for sale with a garden and garage?
n What flats do you have for rent within three miles of the city center?
n What is the average rent for a two-bedroom flat?
n What is the total annual salary bill for staff?
n How does last month’s turnover compare with the projected figure for this month?
n What is the expected monthly turnover for the next financial year?
Increasingly, nowadays, clients, senior managers, and staff want more and more information.
In some areas there is a legal requirement to produce detailed monthly, quarterly, and
annual reports. Clearly, the manual system is inadequate for this type of work. The filebased
system was developed in response to the needs of industry for more efficient data
access. However, rather than establish a centralized store for the organization’s operational
data, a decentralized approach was taken, where each department, with the assistance of
Data Processing (DP) staff, stored and controlled its own data. To understand what this
means, consider the DreamHome example.
The Sales Department is responsible for the selling and renting of properties. For example,
whenever a client approaches the Sales Department with a view to marketing his or her
property for rent, a form is completed, similar to that shown in Figure 1.1(a). This gives
details of the property such as address and number of rooms together with the owner’s
details. The Sales Department also handles inquiries from clients, and a form similar to
the one shown in Figure 1.1(b) is completed for each one. With the assistance of the DP
Department, the Sales Department creates an information system to handle the renting of
property. The system consists of three files containing property, owner, and client details,
as illustrated in Figure 1.2. For simplicity, we omit details relating to members of staff,
branch offices, and business owners.
The Contracts Department is responsible for handling the lease agreements associated
with properties for rent. Whenever a client agrees to rent a property, a form is filled in by
one of the Sales staff giving the client and property details, as shown in Figure 1.3. This
form is passed to the Contracts Department which allocates a lease number and completes
the payment and rental period details. Again, with the assistance of the DP Department,
the Contracts Department creates an information system to handle lease agreements. The
system consists of three files storing lease, property, and client details, containing similar
data to that held by the Sales Department, as illustrated in Figure 1.4.
The situation is illustrated in Figure 1.5. It shows each department accessing their own
files through application programs written specially for them. Each set of departmental
application programs handles data entry, file maintenance, and the generation of a fixed set
of specific reports. What is more important, the physical structure and storage of the data
files and records are defined in the application code.
We can find similar examples in other departments. For example, the Payroll Department
stores details relating to each member of staff’s salary, namely:
StaffSalary(staffNo, fName, lName, sex, salary, branchNo)
The Personnel Department also stores staff details, namely:
Staff(staffNo, fName, lName, position, sex, dateOfBirth, salary, branchNo)
It can be seen quite clearly that there is a significant amount of duplication of data in
these departments, and this is generally true of file-based systems. Before we discuss the
limitations of this approach, it may be useful to understand the terminology used in filebased
systems. A file is simply a collection of records, which contains logically related
data. For example, the PropertyForRent file in Figure 1.2 contains six records, one for each
property. Each record contains a logically connected set of one or more fields, where each
field represents some characteristic of the real-world object that is being modeled. In
Figure 1.2, the fields of the PropertyForRent file represent characteristics of properties, such
as address, property type, and number of rooms.
No comments: