Characteristics of the Database Approach

In this article, we will discuss the overview of the Database Approach and will mainly focus on its characteristics. Also, we will cover the Characteristics of the Database Approach in detail.

Overview of Database Approach

There are different characteristics of the database approach from the much older approach of programming with files. In a traditional file processing system, each user defines and implements its own modifications to the files needed for a selected software application as a part of programming the appliance. In the database approach, one repository maintains data which is defined once then accessed by various users in that database. In a file system, it will be independently like an application that is free to name elements. In comparison, during a database, the names or labels of knowledge are defined once and used repeatedly by queries, transactions, and applications. 

Characteristics of Database Approach

Some of the most important characteristics of the database approach to the file processing approach are the following as follows.

Approach-1 : Self-Describing Nature of a Database System

• One of the most fundamental characteristics of the database approach is that the database system contains not only the database itself but also an entire definition or description of the database structure and constraints also known as metadata of the database. 
• This definition is stored within the DBMS catalog, which contains information like the structure of every file, the sort and storage format of every data item, and various constraints/rules on the information. 
• The knowledge stored within the catalog is named meta-data, and it describes the structure of the first database The catalog is employed by the DBMS software and also by database users such as database administrators who required to know the information about the database structure. 
• A general-purpose DBMS software package is not written for a selected database application. Therefore, it must ask the catalog to understand the structure of the files during a specific database, like the sort and format of knowledge it will access. 
• The DBMS software must work equally well with any number of database applications, For example, a university database, a banking database, or a corporation database as long as because the database definition is stored within the catalog In traditional file processing, data definition is usually a part of the files. File processing software can access only specific databases, Database Management software can access various databases by extracting the database definitions or schemas from the catalog and using these definitions.
  

Approach-2 : Insulation between Programs and Data, and Data Abstraction

• In a traditional file processing system, the structure of database knowledge files is embedded within the application programs, so any changes to the structure of a file may require changing all programs that access that file. 
• Against this, DBMS access programs don’t require such changes in most cases, so independence is achieved between them. 
• The structure of knowledge files is stored within the DBMS catalog separately from the programs that access them. We call this property program-data independence. 
• The characteristic that allows program-data independence and program-operation independence is known as data abstraction. 
• A DBMS provides users with a conceptual representation of knowledge that doesn’t include much of the small print of how the information is stored or how the operations are implemented internally. Informally, a knowledge model may be a sort of data abstraction that won’t provide this conceptual representation. 
• The information model uses logical concepts, like objects, their properties, and their relationships between them, which will be easier for many users to know than memory concepts or storage concepts. Hence, the information model hides storage and implementation details that are not of interest to most database users, so unnecessary complications are hidden from them. 

Approach-3 : Support for Multiple Views of the Data

• A database sometimes has many users, each of whom may require a special perspective or view of the database. 
• A view could also be a subset of the database, or it’s going to contain virtual data that is derived from the database files but isn’t explicitly stored. 
• Some users might not get to remember whether the information they ask for is stored or derived. 
• A multi-user DBMS whose users have a spread of distinct applications must provide facilities for outlining multiple views. This provides many benefits for large databases such as the Aadhaar database.
  

Approach-4 : Sharing of knowledge and Multi-user Transaction Processing

• A multi-user DBMS, as its name implies, must allow multiple users to access the database at an equivalent time or concurrently. 
• This is often essential if data for multiple applications is to be integrated and maintained during a single database such as the latest feature of WhatsApp integration with Facebook. 
• The DBMS must implement concurrency control in the software to make sure that several users trying to update equivalent data do so in a controlled manner in order that the results of the updates are correct. 
• For instance, when several reservation agents attempt to assign a seat on an airline flight, the DBMS should make sure that each seat is often accessed by just one user agent at a single time for an assignment to a passenger. 
• These sorts of applications are generally called online transaction processing (OLTP) applications. A fundamental role of multi-user DBMS software is to make sure that concurrent transactions operate correctly and efficiently with no inconsistency. 
• The concept of a transaction has become central to several database applications. A transaction is an executing program or process that has one or more database accesses, like reading or updating of database records or inserting new records. 
• The isolation property ensures that every transaction appears to execute in isolation from other transactions, many transactions could also be executed concurrently without affecting each other. 
• The atomicity property ensures that either all the database operations during a transaction are executed or none are, these all ACID properties we know.