Characteristics of the Database Approach
In traditional file processing systems, each user or application typically defines and maintains its own data files. The structure of these files is hardcoded into the application programs, and data is often duplicated across systems. This leads to problems such as data redundancy, inconsistency, and inflexible data sharing.
In contrast, the database approach centralizes data storage in a single repository (the database) that is defined once and then accessed by various users and applications. The Database Management System (DBMS) manages access, structure, and integrity of the data, enabling more robust, consistent, and flexible data handling.
The main characteristics that distinguish the database approach from traditional file systems include:
Self-describing nature of a database system
Insulation between programs and data (data abstraction)
Support for multiple views of the data
Data sharing and multiuser transaction processing
1. Self-Describing Nature of a Database System
A key characteristic of the database approach is that the database system is self-describing. This means that:
The DBMS stores both the actual data and metadata—information describing the data structure—in a system catalog or data dictionary.
Metadata includes details such as the structure of tables, data types, constraints, relationships, and storage formats.
This separation of data and metadata enables the DBMS to manage, interpret, and enforce rules on the data consistently without depending on external programs.
In some NoSQL systems (e.g., document-based databases), metadata may be embedded within the data itself. These systems use self-describing data structures, such as JSON or XML, where field names and values are stored together, reducing reliance on a centralized catalog.
2. Insulation Between Programs and Data (Data Abstraction)
In traditional systems, application programs are tightly coupled to the file structure. Any change in file format (e.g., adding a field) would require updates to all associated programs.
In contrast, a DBMS offers program-data independence by storing data definitions separately from the programs that access them. This means that:
The data structure can be changed without altering application logic, provided the logical view remains consistent.
Programs interact with the logical structure of the data, not the physical storage details.
This capability is made possible through data abstraction, which allows the DBMS to present data at three levels:
- Physical level – How data is actually stored.
- Logical level – What data is stored and the relationships among data.
- View level – How users interact with data (customized views).
A data model (e.g., relational model, object model) is used to abstract complex storage details into logical concepts like tables, attributes, relationships, and constraints.
3. Support for Multiple Views of the Data
Different users often require different perspectives on the same data. A DBMS supports multiple views by allowing:
User-defined views, which are subsets of the database tailored to specific roles.
Virtual views, where derived data is generated dynamically based on queries but not explicitly stored.
Views improve security by controlling access to sensitive data, and they simplify interaction by presenting only relevant information to each user or application.
4. Data Sharing and Multiuser Transaction Processing
A major strength of the database approach is controlled data sharing in multiuser environments. This includes:
Concurrent access: Multiple users can access or modify the database simultaneously.
Concurrency control: DBMS ensures that concurrent transactions do not interfere with each other in a way that would compromise data integrity.
Transaction Processing and ACID Properties
A transaction is a sequence of one or more operations (e.g., read, write) that performs a logical unit of work. For example, transferring money from one bank account to another requires debiting one account and crediting another—both operations must succeed or fail together.
The DBMS ensures the correctness of transactions by enforcing the ACID properties:
Atomicity – A transaction is all-or-nothing. If one part fails, the whole transaction is rolled back.
Consistency – The database transitions from one valid state to another.
Isolation – Concurrent transactions appear to execute in isolation from each other.
Durability – Once a transaction is committed, its changes are permanent, even in the event of a crash.
These properties are essential for applications such as banking, inventory management, and online bookings where data accuracy and reliability are critical.