Limitations of the File-Based Approach

 


Limitations of the File-Based Approach


This brief description of traditional file-based systems should be sufficient to discuss the limitations of this approach .


 1 . Separation and isolation of data

When data is isolated in separate files, it is more difficult to access data that should be available.

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.


2 . 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 .

Uncontrolled duplication of data is undesirable for several reasons, including:

  • Duplication is wasteful. It costs time and money to enter the data more than once. 
  • It takes up additional storage space, again with associated costs. Often, the duplication of data can be avoided by sharing data files. 
  • Perhaps more importantly, duplication can lead to loss of data integrity; in other words, the data is no longer consistent. 


3. .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: 

  • Open the original PropertyForRent file for reading; 
  • Open a temporary file with the new structure; 
  • 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; 
  • Delete the original PropertyForRent file; 
  • Rename the temporary file as PropertyForRent.

Clearly, this could be very time-consuming and subject to error. This characteristic of file-based systems is known as program–data dependence. 


4 . 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.

5 . Fixed queries/proliferation of application programs

  • There was no provision for security or integrity.
  • Recovery, in the event of a hardware or software failure, was limited or non-existent.
  • 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.


Comments

Post a Comment

Popular posts from this blog

The Three-Level ANSI-SPARC Architecture

Image
  The Three-Level ANSI-SPARC Architecture For our purposes, the fundamental point of these and later reports is the identification of three levels of abstraction, that is, three distinct levels at which data items can be described. The levels form a three-level architecture comprising an external, a conceptual, and an internal level . The way users perceive the data is called the external level.  The way the DBMS and the operating system perceive the data is the internal level, where the data is actually stored using the data structures and file organizations . The conceptual level provides both the mapping and the desired independence between the external and internal levels.  The objective of the three-level architecture is to separate each user’s view of the database from the way the database is physically represented. There are several reasons why this separation is desirable: Each user should be able to access the same data, but have a different customized view of the data. Each
Read more

Relational Data Model:-Brief History, Terminology in Relational Data Structure, Relations, Properties of Relations, Keys, Domains, Integrity Constraints over Relations

Image
  Relational Data Model:-Brief History, Terminology in Relational Data Structure, Relations, Properties of Relations, Keys, Domains, Integrity Constraints over Relations What is Relational Model? Relational Model  represents the database as a collection of relations. A relation is nothing but a table of values. Every row in the table represents a collection of related data values. These rows in the table denote a real-world entity or relationship. The table name and column names are helpful to interpret the meaning of values in each row. The data are represented as a set of relations. In the relational model, data are stored as tables. However, the physical storage of the data is independent of the way the data are logically organized. The History of the Relational Model The relational model for database introduced by a gentleman named E.F. Codd. Codd developed the model in a 1970 research paper. His concepts were put into practice in the late 70's in an IBM product called  System
Read more