Database System Vs File System

Database System Vs File System:
Before the Database Management System come into existence organizations used to store the data in Files. Drawbacks using the File System to store the data are.

  1. Data redundancy and inconsistency: Multiple file formats, duplication of information in different files Difficulty in accessing data. Unnecessary repetition of data various copies of data may no longer agree.

  2. Difficulty in Accessing Data: Need to write a new program to carry out each new task and the data retrieval is not convenient and efficient.

  3. Data Isolation: Different files and formats and difficulty in accessing data.

  4. Integrity Problems: Validation entries – Difficulty in writing application programs to enforce Integrity. Integrity constraints (e.g. account balance > 0) become part of program code. Hard to add new constraints or change existing ones.

  5. Atomicity Problems: Failures may leave database in an inconsistent state with partial updates carried out. E.g. transfer of funds from one account to another should either complete or not happen at all. And problems of data restored during system failure.

  6. Concurrent access Anomalies: Data accessed by multiple users. Concurrent accessed needed for performance. Uncontrolled concurrent accesses can lead to inconsistencies. E.g. two people reading a balance and updating it at the same time.

  7. Security Problems: Not every user of the database system should be able to access all the data.


  • Consider part of a savings-bank enterprise that keeps information about all customers and savings accounts. One way to keep the information on a computer is to store it in operating system files. To allow users to manipulate the information, the system has a number of application programs that manipulate the files, including

  1.  A program to debit or credit an account.

  2.  A program to add a new account.

  3. A program to find the balance of an account.

  4. A program to generate monthly statements.

System programmers wrote these application programs to meet the needs of the bank.

New application programs are added to the system as the need arises. For example, suppose that the savings bank decides to offer checking accounts. As a result, the bank creates new permanent files that contain information about all the checking accounts maintained in the bank, and it may have to write new application programs to deal with situations that do not arise in savings accounts, such as overdrafts. Thus, as time goes by, the system acquires more files and more application programs.
The system stores permanent records in various files, and it needs different application programs to extract records from, and add records to, the appropriate files. Before database management systems (DBMS) came along, organizations usually stored information in such systems.Storing  Organizational information in a file-processing system has a number of major disadvantages:

  1. Data redundancy and inconsistency: The address and telephone number of a particular customer may appear in a file that consists of savings-account records and in a file that consists of checking-account records. This redundancy leads to higher storage and access cost. In addition, it may lead to data inconsistency; that is, the various copies of the same data may no longer agree. For example, a changed customer address may be reflected in savings-account records but not elsewhere in the system.

  2. Difficulty in accessing data: Suppose that one of the bank officers needs to find out the names of all customers who live within a particular postal-code area. The officer asks the data-processing department to generate such a list. Because there is no application program to generate that. The bank officer has now two choices: either obtain the list of all customers and extract the needed information manually or ask a system programmer to write the necessary application program. Both alternatives are obviously unsatisfactory.

  3. Data isolation: Because data are scattered in various files, and files may be in different formats, writing new application programs to retrieve the appropriate data is difficult.

  4. Integrity problems: The balance of a bank account may never fall below a prescribed amount (say, $25). Developers enforce these constraints in the system by adding appropriate code in the various application programs. However, when new constraints are added, it is difficult to change the programs to enforce them. The problem is compounded when constraints involve several data items from different files.

  5. Atomicity problems: A computer system, like any other mechanical or electrical device, is subject to failure. In many applications, it is crucial that, if a failure occurs, the data be restored to the consistent state that existed prior to the failure. Consider a program to transfer $50 from account A to account B. If a system failure occurs during the execution of the program, it is possible that the $50 was removed from account A but was not credited to account B, resulting in an inconsistent database state. Clearly, it is essential to database consistency that either both the credit and debit occur, or that neither occur. That is, the funds transfer must be atomic—it must happen in its entirety or not at all. It is difficult to ensure atomicity in a conventional file-processing system.

  6. Concurrent-access anomalies: For the sake of overall performance of the system and faster response, many systems allow multiple users to update the data simultaneously. In such an environment, interaction of concurrent updates may result in inconsistent data. Consider bank account A, containing $500. If two customers withdraw funds (say $50 and $100 respectively) from account A at about the same time, the result of the concurrent executions may leave the account in an incorrect (or inconsistent) state. Suppose that the programs executing on behalf of each withdrawal read the old balance, reduce that value by the amount being withdrawn, and write the result back. If the two programs run concurrently, they may both read the value $500, and write back $450 and $400, respectively. Depending on which one writes the value last, the account may contain $450 or $400, rather than the correct value of $350. To guard against this possibility, the system must maintain some form of supervision. But supervision is difficult to provide because data may be accessed by many different application programs that have not been coordinated previously.

  7. Security problems: Not every user of the database system should be able to access all the data. For example, in a banking system, payroll personnel need to see only that part of the database that has information about the various bank employees. They do not need access to information about customer accounts. But, since application programs are added to the system in an ad hoc manner, enforcing such security constraints is difficult. These difficulties, among others, prompted the development of database systems. In what follows, we shall see the concepts and algorithms that enable database systems to solve the problems with file- processing systems. In most of this book, we use a bank enterprise as a running example of a typical data-processing application found in a corporation.

View of Data:

  • A database system is a collection of interrelated files and a set of programs that allow users to access and modify these files. A user will not always require the complete data the responsibility of the database system is to provide only the data that is required to the user.