10 Benefits of Using DBMS Approach

The Advantages of Using DBMS Approach

This section will discuss the benefits of a DBMS as well as the capabilities that a great DBMS should have. These capabilities go beyond the four main characteristics described in Section 1.3. These capabilities must be used by the DBA to achieve a range of goals related to design, administration, and usage of large multiuser databases.

1. Controlling Redundancy

Traditional software development that uses file processing requires each user group to maintain its own files in order to manage its data processing applications. Consider the UNIVERSITY example in Section 1.2. Here, there might be two groups of users: the course registration staff and the accounting office.

The traditional method has each user keeping their own files about students. The registration office tracks grades and courses, while the accounting office records billing information and data about registration. Others may duplicate or add to the data.

Multiple times storing the same data can lead to many problems. The first is that a single logical upgrade is required, such as when a student is added to a student’s file. This is done once for every student file. This can lead to duplicate effort and storage space being wasted. Third, files that contain the same data can become inconsistent. It could happen when an update is applied to one file but not to another.

Although an update, such as adding a student to the database, is applied to all appropriate files it may cause inconsistent data regarding the student. This happens because each user group applies the updates independently. One user group might enter a student’s birthday incorrectly as “JAN191988”, while the other groups may enter the correct value of “JAN-29–1988”.

Database design integrates the views of different user groups. In order to achieve the best database design, each logical data item (such as student’s names or birth dates) should be stored in one location within the database. This is data standard. It ensures consistency and reduces storage space. (Data normalization is explained in Part 6).

In practice, however, it may be necessary to use controlled redundant to improve query performance. We may store Student_name or Course_number redundantly within a GRADE_REPORT (Figure 1.6(a),) because when we retrieve a GRADE_REPORT report record, we want to retrieve the student’s name and course numbers along with the grade, studentnumber, and section identifier.

We don’t have to search multiple files for this data by putting all data together. This is known as denormalization. The DBMS should be able to prevent inconsistencies between files in such cases.

This may be done by automatically checking that the Student_name-Student_number values in any GRADE_REPORT record in Figure 1.6(a) match one of the Name-Student_number val-ues of a STUDENT record (Figure 1.2). Similarly, the Section_identifier-Course_number values in GRADE_REPORT can be checked against SECTION records.

These checks can be made explicit to the DBMS at the time of database design. They are automatically enforced by DBMS when the GRADE_REPORT file has been updated.

Figure 1.6(b), which shows a GRADE_REPORT file that is inconsistent with Figure 1.2’s STUDENT file, is an example of such an error. How can you tell which part is inconsistant?

2. Restricting Unauthorized Access

Multiple users sharing a large database will likely mean that not all users have access to the information. Financial data, for example, is usually considered confidential and can only be accessed by authorized personnel. Some users may not be allowed to retrieve data.

Others are permitted to retrieve and update. You must control the access operation, whether it is retrieval or updating. Users or groups of users are typically given account numbers that are protected by passwords. They can then access the database.

The authorization and security subsystem should be provided by a DBMS. This is used by the DBA to create accounts or to restrict access. These restrictions should then be enforced automatically by the DBMS. We can also apply similar controls to the DBMS program.

You can allow only the dba staff to access certain privileged software, such as software for creating new accounts. Parametric users may also be allowed access to the database through predefined canned transactions that have been created for them.

3. Providing permanent storage for program objects

Databases can be used for persistent storage of program objects and data structure. This is the primary reason object-oriented databases exist. Complex data structures are common in programming languages, such as record types and class definitions in C++ and Java. If a program terminates, the values of variables and objects are deleted.

However, programmers can explain-itly store them in permanent files. This often requires converting complex structures into a file format that is suitable for storage.

If the programmer needs to access this data again, he or she must convert the file format to the object structure or program variable. Object-oriented databases systems can be used with programming languages like Java and C++.

The DBMS software automatically performs all necessary conversions. A complex object written in C++ can be saved permanently in an object-oriented DBMS. This object is considered persistent because it can be retrieved later by another C++ program.

Database systems must have the ability to store program objects and their data structures in a persistent manner. DBMS data structures were not compatible with programming languages’ data structures, and traditional database systems suffered from the impedance miss problem. Object-oriented databases systems often offer compatibility for one or more object-oriented languages.

4. Providing storage structures and search techniques for efficient query processing

Database systems should be able to efficiently execute queries and update queries. __S.70__ This is where indexes, an auxiliary file, are used. The indexes are usually based on modified tree or hash data structures, which can be used for disk search. To process a query’s database records, they must be copied from main memory to disk.

The DBMS may have a buffering module or caching module that stores a portion of the data-base in main storage buffers. The operating system handles disk-to-memory buffering. Most DBMSs, however, do their data buffering because it is so important for the performance of their DBMS.

The query process and optimization module within the DBMS are responsible for choosing the most efficient plan of execution for each query based upon the existing storage structures. Physical database design and tuning includes the selection of which indexes should be created and maintained. This is the responsibility of the DBA staff. In Part 8, we discuss query processing, optimization and tuning.

5. Backup-recovery subsystem

A DBMS should have facilities to recover from software or hardware failures. Recovery is handled by the backup-recovery subsystem. The recovery subsystem, for example, is responsible for restoring the database to its state before the transaction began executing.

Alternately, the recovery subsystem can ensure that the transaction is resumed at the time it was stopped to ensure its full effect is recorded in database. In the event of a catastrophic failure of the disk, it is necessary to have a backup copy of your data. In Chapter 23, we will discuss backup and recovery.

6. Multi-user interfaces

A DBMS should offer a range of user interfaces because there are many users who have different technical knowledge. These interfaces include query languages for casual users, programming interfaces for programmers, forms, command codes, and menu-driven and natural language interfaces.

Graphical user interfaces (GUIs) are both menu-driven and forms-style interfaces. There are many languages and environments that can be used to specify GUIs. There are many options for Web GUI interfaces to databases, or Web-enabling them.

7. Representing complex relationships among data

Databases can contain many types of data that may be interrelated in different ways. Take the example in Figure 1.2. The record for Brown in the STUDENT file corresponds to four GRADE_REPORT records.

Each section record can be related to both a single course record and a number GRADE_REPORT files, one for each student who took that section. A DBMS must be able to handle complex relationships between data and can create new relationships as they occur. It also needs to be able to retrieve and update relevant data quickly and efficiently.

8. Enforcing integrity constraints

Many database applications must adhere to certain integrity restrictions. These constraints should be defined and enforced by a DBMS. A simple type of integrity constraint is to specify a data type for each item.

In Figure 1.3, for example, we stipulated that the Class data item in each STUDENT record must contain a single digit integer, and that Name must contain a string of not more than 30 alphabetic character.

An additional constraint, which is not in the current catalog, would be to limit the Class value between 1 and 5. Another type of constraint is to specify that records in one file must be linked to records in another.

In Figure 1.2, for example, we can say that each section must be related with a course record.

This is called a referential integrity constraint. These constraints are determined from the meaning of the semantics of data and the miniworld it represents. The database designers are responsible for identifying integrity constraints in database design.

Some constraints can be given to the DBMS, and then automatically enforced. Some constraints will need to be verified by updates programs or at data entry. These constraints are often called business rules for large applications.

An item can be entered incorrectly but still meet the integrity constraints. If a student gets a grade ‘A’, but a grade ‘C’ is entered in the database the DBMS cannot detect this error automatically since ‘C” is a valid Grade data type value. These data entry errors cannot be detected automatically (when the student gets the grade and complains), and can later be corrected by updating the database.

The DBMS would reject a grade of Z’ automatically because Z’ is not a valid data type for the Grade data type. In subsequent chapters, we will discuss each data model and introduce rules that apply to it implicitly.

In Chapter 7, the Entity-Relationship Model, for example, a relationship must include at least two entities. These rules are inherent rules to the data model and automatically assume the validity of the model.

9. Allowing Inferencing and Acts Using Rules

Some databases systems have the ability to define deduction rules that allow for the inference of new information from stored data. These systems are known as deductive database systems. The mini-world application may have complex rules that can be used to determine when a student is on probation. These rules can be declared as rules and can be compiled by the DBMS to determine which students are on probation.

To support these applications, a explicit procedural code would have to be created in a traditional DBMS. If the miniworld rules are changed, it’s generally easier to modify the declared deduction rules rather than to recode procedural program codes. It is possible to associate triggers and tables in relational databases.

Triggers are a type of rule that is activated by table updates. They allow for additional operations on other tables, such as sending messages or sending out alerts. These more complex procedures are commonly known as stored procedure. They are part of the database definition and can be invoked when certain conditions are met.

Active Database Systems provide more powerful functionality. These systems have active rules that can initiate actions whenever certain conditions or events occur.

10. Other Implications of the Database Approach

This section discusses additional benefits of the database approach for most organizations.

Potential to enforce standards. Database approach allows the DBA to establish and enforce standards for large organizations. This allows for communication and cooperation between different departments, projects, users, and employees within an organization.

Standardization can be used to define the names and formats for data elements, display formats and report structures. A centralized database environment allows the DBA to enforce standards more effectively than an environment where each user group is responsible for its own files and software.

Reduced time to develop an application. The data-base approach has a major selling point: it takes very little time to develop a new application, such as retrieving data from the database and printing a report. It may take longer to design and implement a multiuser database than it would to create a single file application.

However, it takes significantly less time to create new applications with DBMS facilities once a database has been set up. A DBMS takes one-sixth to one fourth of the time as a traditional file system.

Flexibility. As requirements change, it may be necessary for a database to be restructured. A new user group might emerge, for example, and they may need information that is not yet in the database.

It may be necessary to add files to the database, or to expand the data elements of an existing file. Modern DBMSs permit certain evolutionary changes to the database structure without affecting existing applications programs.

Access to up-to-date information. All users have access to the database via a DBMS. All users can see the update immediately after it is applied to their database. 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.

Economies of scale. The DBMS allows for consolidation of data and applications. This reduces the wasteful overlap of activities between data-processing staff in different departments or projects, as well as redundancy among applications.

Instead of each department purchasing its own equipment (lower-performance), this allows the entire organization to invest in better processors, storage devices, and communication gear. This lowers the overall cost of operations and management.