In this article, we discuss some of the advantages of using the DBMS approach and the capabilities that a good DBMS should possess.
Recommended Book: Database Management System
These capabilities are in addition to the four main characteristics (known as ACID properties) discussed in the upcoming articles in detail.
The DBA must utilize these capabilities to accomplish a variety of objectives related to the design, administration, and use of a large multiuser database.
Following are some of the advantages of using the DBMS approach:
1)Controlling Redundancy
Traditional file approach: In traditional software development utilizing file processing, every user group maintains its own files for handling its data-processing applications.
For example: Suppose we have two groups of users might be the course registration personnel and the accounting office for the College database. In the traditional approach, each group independently keeps files on students. The accounting office keeps data on registration and related billing information, whereas the registration office keeps track of student courses and grades. Other groups may further duplicate some or all of the same data in their own files.
This redundancy in storing the same data multiple times leads to several problems.
First, there is the need to perform a single logical update such as entering data on a new student multiple times, once for each file where student data is recorded. This leads to duplication of effort.
Second, storage space is wasted when the same data is stored repeatedly, and this problem may be serious for large databases.
Third, files that represent the same data may become inconsistent. This may happen because an update is applied to some of the files but not to others. Even if an update-such as adding a new student is applied to all the appropriate files, the data concerning the student may still be inconsistent because the updates are applied independently by each user group.
For example, one user group may enter a student’s birth date erroneously as ‘JAN-19-1988’, whereas the other user groups may enter the correct value of ‘JAN-29-1988’.
Database approach: In the database approach, the views of different user groups are integrated during database design.
Ideally, we should have a database design that stores each logical data item such as a student’s name or birth date in only one place in the database. This ensures consistency and saves storage space.
However, in practice, it is sometimes necessary to use controlled redundancy to improve the performance of queries.
GRADE_REPORT(Consistent data)
| Student_number | Student_name | Section_identifier | Course_number | Grade |
| 17 | Smith | 112 | MATH2410 | B |
| 17 | Smith | 119 | CS1310 | C |
| 8 | Brown | 85 | MATH2410 | A |
| 8 | Brown | 92 | CS1310 | A |
| 8 | Brown | 102 | CS3320 | B |
| 8 | Brown | 135 | CS3380 | A |
GRADE_REPORT(Inconsistent record)
| Student_number | Student_name | Section_identifier | Course_number | Grade |
| 17 | Brown | 112 | MATH2410 | B |
For example, we may store Student name and Course_number redundantly in a GRADE REPORT file (in above table A) because whenever we retrieve a GRADE REPORT record, we want to retrieve the student name and course number along with the grade, student number, and section identifier.
By placing all the data together, we do not have to search multiple files to collect this data.
In such cases, the DBMS should have the capability to control this redundancy in order to prohibit inconsistencies among the files.
2) Restricting Unauthorized Access
This is the most important advantage of using the DBMS approach nowadays, due to the increase of the digital world.
When multiple users share a large database, it is likely that most users will not be authorized to access all information in the database.
For example, financial data is often considered confidential, and only authorized persons are allowed to access such data.
In addition, some users may only be permitted to retrieve data, whereas others are allowed to retrieve and update.
Hence, the type of access operation retrieval or update must also be controlled. Typically, users or user groups are given account numbers protected by passwords, which they can use to gain access to the database.
DBMS should provide a security and authorization subsystem, which the DBA uses to create accounts and to specify account restrictions.
Then, the DBMS should enforce these restrictions automatically.
Notice that we can apply similar controls to the DBMS software.
For example, only the DBA’s staff may be allowed to use certain privileged software, such as the software for creating new accounts. Similarly, parametric users may be allowed to access the database only through the canned transactions developed for their use.
3) Providing Persistent Storage for Program Objects
Databases can be used to provide persistent storage for program objects and data structures.
This is one of the main reasons for object-oriented database systems.
Programming languages typically have complex data structures, such as class definitions in C++ or Java.
The values of program variables are discarded once a program terminates unless the programmer explicitly stores them in permanent files, which often involves converting these complex structures into a format suitable for file storage.
When the need arises to read this data once more, the programmer must convert from the file format to the program variable structure.
Object-oriented database systems are compatible with programming languages such as C++ and Java, and the DBMS software automatically performs any necessary conversions.
Hence, a complex object in C++ can be stored permanently in an object-oriented DBMS. Such an object is said to be persistent since it survives the termination of program execution and can later be directly retrieved by another C++ program.
The persistent storage of program objects and data structures is an important function of database systems.
Traditional database systems often suffered from the so-called impedance mismatch problem, since the data structures provided by the DBMS were incompatible with the programming language’s data structures.
Object-oriented database systems typically offer data structure compatibility with one or more object-oriented programming languages.
4) Providing Storage Structures for Efficient
Database systems must provide capabilities for efficiently executing queries and updates.
Because the database is typically stored on a disk, the DBMS must provide specialized data structures to speed up disk search for the desired records.
Auxiliary files called indexes are used for this purpose.
Indexes are typically based on tree data structures or hash data structures suitably modified for disk search.
In order to process the database records needed by a particular query, those records must be copied from disk to memory.
Therefore, the DBMS often has a buffering module that maintains parts of the database in main memory buffers.
In other cases, the DBMS may use the operating system to do the buffering of disk data.
The query processing and optimization module of the DBMS is responsible for choosing an efficient query execution plan for each query based on the existing storage structures. The choice of which indexes to create and maintain is part of physical database design and tuning, which is one of the responsibilities of the DBA staff.
5) Providing Backup and Recovery
DBMS must provide facilities for recovering from hardware or software failure.
The backup and recovery subsystem of the DBMS is responsible for recovery.
For example, if the computer system fails in the middle of a complex update transaction, the recovery subsystem is responsible for making sure that the database is restored to the state it was in before the transaction started executing.
Alternatively, the recovery subsystem could ensure that the transaction is resumed from the point at which it was interrupted so that its full effect is recorded in the database.
6) Providing Multiple User Interfaces
Because many types of users with varying levels of technical knowledge use a database, a DBMS should provide a variety of user interfaces.
These include query languages for casual users, programming language interfaces for application programmers, forms and command codes for parametric users, and menu-driven interfaces and natural language interfaces for standalone users.
Both form-style interfaces and menu-driven interfaces are commonly known as graphical user interfaces (GUI).
Many specialized languages and environments exist for specifying GUls. Capabilities for providing Web GUI interfaces to a database or Web-enabling a database are also quite common.
7) Representing Complex Relationships among Data
A database may include numerous varieties of data that are interrelated in many ways.
A DBMS must have the capability to represent a variety of complex relationships among the data, to define new relationships as they arise, and to retrieve and update related data easily and efficiently.
8) Enforcing Integrity Constraints
Most database applications have certain integrity constraints that must hold for the data.
A DBMS should provide capabilities for defining and enforcing these constraints.
The simplest type of integrity constraint involves specifying a data type for each data item.
A data item may be entered erroneously and still satisfy the specified integrity constraints. For example, if a student receives a grade of A’ but a grade of ‘C’ is entered in the database, the DBMS cannot discover this error automatically because ‘C’ is a valid value for the Grade data type. Such data entry errors can only be discovered manually (when the student receives the grade and complains) and corrected later by updating the database.
However, a grade of ‘Z’ would be rejected automatically by the DBMS because ‘Z’ is not a valid value for the Grade data type.
9) Permitting Inferencing and Actions Using Rules
Some database systems provide capabilities for defining deduction rules for inferencing new information from the stored database facts. Such systems are called deductive database systems.
For example, there may be complex rules in the mini world application for determining when a student is on probation. These can be specified declaratively as rules, which when compiled and maintained by the DBMS can determine all students on probation.
In a traditional DBMS, an explicit procedural program code would have to be written to support such applications.
But if the mini world rules change, it is generally more convenient to change the declared deduction rules than to recode procedural programs.
In today’s relational database systems, it is possible to associate triggers with tables.
A trigger is a form of a rule activated by updates to the table, which results in performing some additional operations to some other tables, sending messages, and so on.
More involved procedures to enforce rules are popularly called stored procedures. They become a part of the overall database definition and are invoked appropriately when certain conditions are met.
More powerful functionality is provided by active database systems, which provide active rules that can automatically initiate actions when certain events and conditions occur.
10) Potential for Enforcing Standards
The database approach permits the DBA to define and enforce standards among database users in a large organization.
This facilitates communication and cooperation among various departments, projects, and users within the organization.
Standards can be defined for names and formats of data elements, display formats, report structures, terminology, and so on.
The DBA can enforce standards in a centralized database environment more easily than in an environment where each user group has control of its own files and software.
Below are some of the other advantages of using the DBMS approach:
11) Reduced Application Development Time
A prime selling feature of the database approach is that developing a new application such as the retrieval of certain data from the database for printing a new report takes very little time.
Designing and implementing a new database from scratch may take more time than writing a single specialized file application.
However, once a database is up and run substantially less time is generally required to create a new application using DBMS facilities.
Development time using a DBMS is estimated to be one-sixth to one-fourth of that for a traditional file system.
12) Flexibility
This is the important advantage of using the DBMS approach.
It may be necessary to change the structure of a database as requirements change.
For example, a new user group may emerge that needs information not currently in the database.
In response, it may be necessary to add a file to the database or to extend the data elements in an existing file.
Modern DBMSs allow certain types of evolutionary changes to the structure of the database without affecting the stored data and the existing application programs.
13) Availability of Up-to-Date Information
A DBMS makes the database available to all users.
As soon as one user’s update is applied to the database, all other users can immediately see this update.
This availability of up-to-date information is essential for many transaction processing applications, such as reservation systems or banking databases, and it is made possible by the concurrency control and recovery subsystems of a DBMS.
The last one is the most important advantages of using the DBMS approach:
14) Economies of Scale
The DBMS approach permits consolidation of data and applications, thus reducing the amount of wasteful overlap between activities of data-processing personnel in different projects or departments as well as redundancies among applications.
This enables the whole organization to invest in more powerful processors, storage devices, or communication gear, rather than having each department purchase its own (weaker) equipment.
This reduces overall costs of operation and management.
Recommended Post
If you find any error or mistake in the ‘advantages of using the DBMS approach’ article then you can simply comment below or you can mail us by click here.
Thank you!